# Execute Decisions

Define how to apply approved mutations to pib-db.

**Default (absent/empty):** Direct pib_* MCP calls (or CLI fallback),
routed by type — kind decides the verb:

- **close (action):** `pib_complete_action` — gated; stamps
  `resolution='verified'`. Never `pib_update_action` with
  `status='done'` (refused) and never the raw CLI against the gate.
- **close (project):** `pib_complete_project` — fid-only first to get
  the walk sheet (mutates nothing), then re-call with the per-child
  map `[{fid, seen_status, answer}]` after the operator answers each
  child (`parent-outcome` | `reparent:<prj-fid>` | `delete`).
  `seen_status` echoes the sheet — never fabricate it.
- **close (area):** does not exist. An area never completes; the write
  boundary refuses `status='done'`. Use archive (`dropped`) or
  reclassify first if it is really a finished outcome.
- **archive:** container → `pib_update_project` with `status`
  `someday`/`dropped`; action → `pib_update_action` with
  `status='deferred'` plus a note saying why. Parking an AREA
  (`paused`/`someday`/`dropped`) that still holds live child projects
  is refused — it would hide their parent from every container list
  while they hold live work. Finish or move the children first.
- **merge:** update the surviving item's notes to absorb the
  duplicate's unique content; append a supersede marker to the
  duplicate (`_Superseded by act:XXXX (spring-clean merge)_`) and set
  it `status='deferred'`. There is NO delete for standalone actions
  (act:5922d741) — do not instruct one, do not reach for raw SQL (the
  guard refuses it). Re-point dependency edges to the survivor
  (`pib_list_dependencies`, `pib_remove_dependency`,
  `pib_add_dependency`).
- **split:** the carved effort NESTS inside the container it came from.
  `pib_create_project` with `kind='project'`, the outcome in notes, and
  `parentFid=<the area being split>` — then `pib_update_action` with
  `projectFid=<the new project>` for each action that belongs to that
  finish line. The area keeps the standing responsibility, the project
  carries the finish line, and the area read rolled up still accounts
  for every carved action. Never create the project as a root sibling:
  that is the sideways move this disposition used to perform, and it is
  why the area appeared to shrink while nothing gained a home.
- **reclassify:** `pib_update_project` with `kind` — one container per
  call, each individually operator-approved, never batched. Promotion
  to `kind='project'` requires the outcome stated in notes ("done
  when …") — supply it in the same call if the container doesn't
  already carry one — and is REFUSED for an area that holds child
  projects (a project cannot contain another project; the refusal names
  the children). Demoting a project that names an area is refused
  unless the same call clears it (`kind='area'` with `parentFid=null`),
  because an area is always a root. Demoting a done container to area
  is refused; reopen first.
- **reparent:** for an ACTION, `pib_update_action` (or `update-action`)
  with `projectFid` — camelCase; snake_case `project_fid` is not a
  declared param and is silently dropped. For a PROJECT moving between
  areas, `pib_update_project` with `parentFid` (CLI `--parent prj:X`,
  or `--parent ""` to clear). The target must exist, must be an area,
  and must not be done; open work cannot enter a done container — the
  writers refuse either way.
- **create-container:** `pib_create_project`. Defaults to
  `kind='area'`. A real project needs `kind='project'` AND its outcome
  in notes; an area states no outcome (demanding one teaches
  fabrication). A project should also name the area it serves
  (`parentFid`, CLI `--parent prj:X`) unless it genuinely belongs to
  none — a project with no area is legal, just unhomed. An area never
  takes a parent.

## Safeguards

All mutations are logged to the conversation. No bulk anything for
kind judgments: reclassifications and walk maps are per-item operator
decisions. Walk `delete` answers are individually approved as part of
the per-child conversation. Container status changes (active →
dropped) require explicit confirmation even in batch mode. A gate
refusal (done area, open children, outcome-less promotion,
hierarchy-in-title, or any illegal containment — project under
project, parented area, project under a done area, promoting an area
that holds projects, parking an area with live children) is surfaced
to the operator verbatim — it names the supported fix; never work
around it.