inbound_approve
Write · Conductor only
Approves staged inbound items into agreed state. Tasks insert as fresh entries through real creation; knowledge merges additively with type conflicts skipped and relations gated on both endpoints.
Arguments, result and boundaries
- Arguments
- Required: `kind`, `item_ids`. Optional: `reason`. - `kind`. Note: tasks or knowledge. - `item_ids`. Note: JSON array string of namespaced ids (t:N tasks, e:N entities, r:N relations); must match kind. Every id must exist and be pending or the whole call fails with nothing applied. - `reason`. Note: Recorded as the decide reason on each item.
- Result
- Object with approved array (id plus task_id for tasks) and skipped array (id plus reason).
- Boundaries
- Conductor role required. Approved content is created under the approver identity within the selected profile boundary, so approver scope and validation apply exactly as for direct creation.
- Lifecycle
- Strict eligibility pre-check first, then entities before relations: tasks are created fresh through the real creation path; entities merge additively (type conflicts skip, only new observations merge); relations need both endpoints pre-existing or approved in the same batch. Each item is marked decided with a decision history event.
- Errors
- Non-conductor callers get a requires-conductor error payload. Invalid kind, malformed ids, kind/id mismatch, or any ineligible item fails the whole call with nothing applied. Type conflicts and missing relation endpoints land in skipped, not errors.
- Example
- ```json { "item_ids": "[\"t:1\"]", "kind": "tasks" } ``` Result shape: ```json { "approved": [ { "id": "t:1", "task_id": "<uuid>" } ], "skipped": [] } ```