docs: fix stale planner→architect slice-ownership refs [doc-updater]

docs/architecture/slice-dag.md

@@ -74,7 +74,7 @@ pass either.
 
 | Field | Type | Default | Purpose |
 |-------|------|---------|---------|
-| `serialized_chain_order` | `list[str]` | `[]` | Planner-emitted ordering for would-be multi-parent slices. When the planner identifies a slice that would naturally have >1 parents, it serialises the upstream cluster into a chain and records the chosen order on the downstream slice. |
+| `serialized_chain_order` | `list[str]` | `[]` | Architect-emitted ordering for would-be multi-parent slices (#2809). When the architect identifies a slice that would naturally have >1 parents, it serialises the upstream cluster into a chain and records the chosen order on the downstream slice. |
 | `parent_branch_at_creation` | `str \| None` | `None` | Git branch the slice's integration branch was forked off when its worktree was provisioned. Read by the stacked-PR reconciler when the parent's branch has been deleted by a merge so it can compute the correct rebase target. |
 
 ## Plan Parser & Forest Validation
@@ -97,7 +97,7 @@ def validate_forest(slices: list[Slice]) -> list[str]:
 
 The orchestrator's `_populate_contract_from_plan` route invokes
 `validate_forest()`, stashes any returned errors on
-`Contract.plan_review_feedback` (so the plan reviewer NACKs the planner),
+`Contract.plan_review_feedback` (so the plan reviewer NACKs the architect, #2809),
 **and then raises a structured `ForestValidationError`**. Slices are not
 written to the contract in this case — leaving `contract.slices` empty
 so downstream code visibly fails fast.
@@ -617,7 +617,7 @@ of the three callables (refine-phase decision-15) — every gateway call
 flows through the same per-agent allowlists the slice's regular agent
 team uses.
 
-## Planner & plan-reviewer prompt updates
+## Architect, planner & plan-reviewer prompt updates
 
 The dynamic prompt builders for `task_planner` and `reviewer_plan` were
 extended to teach the agents the new schema and constraints:
@@ -741,9 +741,9 @@ during refine. The most consequential are referenced inline above:
 - **decision-16** — stacked-PR rebase: GitHub auto-retarget primary path,
   reconciler safety net.
 - **decision-17** — auto-serialization for would-be multi-parent slices:
-  planner-supplied `serialized_chain_order` is the source of truth.
+  architect-supplied `serialized_chain_order` is the source of truth (#2809).
 - **decision-18** — forest constraint enforced at plan ingestion only;
-  multi-parent slices NACK the planner.
+  multi-parent slices NACK the architect (#2809).
 - **decision-20** — implement-phase run-loop wire-up (TASK-4-2,
   TASK-4-4, TASK-5-1 invocation, TASK-5-3 scheduling). Operator chose
   **opt-2** ("require the wire-up to land here before consensus"); the

docs/reference/orchestrator-cli.md

@@ -300,7 +300,7 @@ All tools require `task_id` (the pipeline ID). Additional parameters:
 | `populate_contract` | `no_draft_path` | 404 | No draft path configured for this pipeline |
 | `populate_contract` | `parse_failed` | 422 | `parse_plan` returned `success=False` — e.g., empty plan document, missing or malformed `yaml-tasks` appendix, or other parser-rejected input |
 | `populate_contract` | `empty_result` | 422 | Parse succeeded but produced no slices/tasks **and** no PR metadata (`changed=False`); a draft yielding only a `pr_title` would still come back as `POPULATED` |
-| `populate_contract` | `forest_violation` | 422 | Plan emitted a multi-parent slice DAG (#2137). **Response body shape is `{"error": "forest_violation", "errors": [...]}` — note the key is `error`, not `reason`** (clients switching only on `reason` will miss this case). The structured errors are also stashed on `contract.plan_review_feedback` so the plan reviewer NACKs the planner |
+| `populate_contract` | `forest_violation` | 422 | Plan emitted a multi-parent slice DAG (#2137). **Response body shape is `{"error": "forest_violation", "errors": [...]}` — note the key is `error`, not `reason`** (clients switching only on `reason` will miss this case). The structured errors are also stashed on `contract.plan_review_feedback` so the plan reviewer NACKs the architect (#2809) |
 | `populate_contract` | `contract_load_failed` | 500 | Existing contract on disk could not be loaded prior to population (the load happens first; if it fails the populator never runs) |
 | `populate_contract` | `egg_contracts_unavailable` | 500 | `egg_contracts` package failed to import in the orchestrator process (the endpoint runs orchestrator-side, not in the agent sandbox) |
 | `populate_contract` | `unexpected_exception` | 500 | Unexpected internal error inside the populator helper (`_populate_contract_from_plan`'s catch-all) |

docs/templates/analysis.md

@@ -58,11 +58,11 @@ facts only the operator can answer (product intent, scope boundaries, external
 commitments, user-visible behavior). Do **not** register decisions about:
 
 - **Work decomposition / slice-DAG shape / PR packaging** — these belong to the
-  plan phase. The planner owns the slice-DAG shape (see
+  plan phase. The **architect** owns the slice-DAG shape (#2809) (see
   [Slice-DAG Implement Phase](../architecture/slice-dag.md)) and the operator
   approves it at the plan HITL gate. If the task spans multiple independently-
   implementable parts, name them in `## Problem Statement` or `## Constraints`
-  as advisory context — the planner will propose a slice shape from that.
+  as advisory context — the architect will propose a slice shape from that.
 - **Implementation strategy** the planner can derive from the analysis (migration
   approach, fallback design, detector shape). Surface these as Options Considered
   / Recommended Approach, not as `add-decision` items.

docs/templates/plan.md

@@ -166,7 +166,7 @@ slices:
 > implementable and gets its own integration branch, agent team, BRC
 > consensus, and PR. The slice DAG must be a **forest** — each slice has
 > at most one DAG parent. Multi-parent slices are rejected at plan
-> ingestion. When a planner identifies a would-be multi-parent slice, it
+> ingestion. When the architect identifies a would-be multi-parent slice, it
 > serialises the upstream cluster into a chain and records the chosen
 > order on the downstream slice's `serialized_chain_order: list[str]`
 > field. See [Slice-DAG Implement Phase](../architecture/slice-dag.md)