okstra 0.202.0 → 0.205.0

package/runtime/prompts/profiles/release-handoff.md

@@ -1,115 +1,115 @@
 # Release Handoff Profile
 
-```yaml
-roles: []
-```
-
-- Record the handoff shape in `releaseHandoff.handoffScope`: `mode` always, plus `stages`
-  and `collectorBranch` in stage-group mode. The report is the only place a reader learns
-  which stages shipped — the collector branch name does not say.
-- Purpose: take an `accepted` final-verification verdict for an already-committed implementation branch and turn it into a delivered push and/or pull request, with explicit user selection at every mutating step. Two modes: **whole-task** (default — the verified task branch becomes one PR) and **stage-group** (a user-selected subset of verified stages is merged into a collector branch and becomes one PR).
+- Record the handoff shape in `releaseHandoff.handoffScope`: the `stages` this run delivered and
+  the `releaseBase` the user picked. The report is the only place a reader learns which stages
+  shipped and in what order their PRs must be merged — the branch names do not say.
+- Purpose: take a release-ready single-stage final-verification verdict for each already-committed implementation stage and turn it into a delivered push and/or pull request, with explicit user selection at every mutating step. **One stage is one PR.** The PR head is that stage's stack branch (`<prefix>-<task-id>-s<N>`); nothing is squashed, rebased, or collected into a bundle branch.
 - **Execution model: single-lead, no worker dispatch.** This phase is a thin orchestrator over `git` / `gh`; it does NOT dispatch teammates, does NOT dispatch analysis or drafter sub-agents, and does NOT run convergence. The host-native Okstra lead performs every step inline (drafting PR text, asking the user, running git / gh, writing the final report) — see "Lead-only contract" below.
 - Worker roster: none — this profile intentionally has no `- Required workers:` block; the run is executed entirely by the Okstra lead.
 - Lead-only contract (replaces the shared team contract for this phase):
-  - The host-native Okstra lead is the sole agent for this run. No worker dispatch, no teammates, no parallel sub-agents, no convergence loop.
-  - The lead drafts the PR title and PR body **inline** by reading the run brief, the cited final-verification report, `git log --oneline <base>..HEAD`, and `git diff <base>..HEAD --stat`. No drafter worker is dispatched.
+  - The host-native Okstra lead is the sole agent for this run. No worker dispatch, no teammates, no parallel sub-agents, no convergence loop. Do NOT run `okstra convergence` in any form: prepare already wrote this run's convergence state as "not run — fewer than two analysers", which is the record report assembly reads. **Enforced:** `okstra_ctl.render._initialize_lead_only_convergence` writes it when the run has no analysers, and leaves an existing state alone.
+  - The lead drafts each stage's PR title and PR body **inline** by reading the run brief, that stage's cited final-verification report, `git log --oneline <stage base>..<stage head>`, and `git diff <stage base>..<stage head> --stat`. No drafter worker is dispatched.
   - The lead authors the final-report file directly (no `Report writer worker` dispatch). The report still conforms to the standard `templates/reports/final-report-v2.template.md` structure, including the `## 5.6 Release Handoff Deliverables` section.
   - The shared anti-escalation rule from the common contract still applies: do not start any other lifecycle phase from inside this run.
   - The shared "authority & permissions assumption" rule from the common contract still applies: assume the user holds every permission needed; do not block on hypothetical approvals.
 - Pre-handoff entry gate (mandatory — refuse to start if any item fails):
-  - the run's input document (`release-handoff-input.md`, generated by prepare in place of a task brief — briefs belong to entry phases only) carries a `## Source Verification Report` section with `Mode`, `Stages`, and one table row per cited `final-verification` final-report. The run context exposes the same selection as `HANDOFF_MODE` (`whole-task` | `stage-group`) and `HANDOFF_STAGES` (csv, empty for whole-task).
-  - **whole-task mode** (`HANDOFF_MODE=whole-task`): the lead opens the cited report and confirms its `verificationScope` is `whole-task` and its verdict is release-ready — `Verdict Token` exactly `accepted`, or exactly `conditional-accept` with every **Conditional Acceptance Condition** row declaring `blocksReleaseHandoff: false`. The rule lives in `okstra_ctl.release_gate.release_handoff_allowed`; the lead reads the report against it and does not invent a third case.
-  - **stage-group mode** (`HANDOFF_MODE=stage-group`): the lead opens each cited single-stage report and confirms every verdict is release-ready by the same rule as whole-task mode. Eligibility was already enforced at prepare time (`okstra_ctl.handoff.compute_eligibility`) and is re-enforced by `okstra handoff assemble` — the lead never hand-computes it.
-  - if the verdict is `blocked`, a `conditional-accept` carrying any condition that blocks release, or any other token (including ambiguous phrasing like "looks good"), the run MUST end immediately with status `blocked` and a routing recommendation back to `error-analysis` or `implementation-planning`. Do NOT prompt the user; Do NOT run any git command.
-  - when the cited verdict is `conditional-accept`, the lead MUST carry every **Conditional Acceptance Condition** row into the PR body under a heading naming them as unresolved — id, condition, and the evidence the reviewer would need. These conditions are the whole reason a non-`accepted` verdict was allowed through; a PR body that drops them turns a recorded condition into a silent one.
+  - the run's input document (`release-handoff-input.md`, generated by prepare in place of a task brief — briefs belong to entry phases only) carries a `## Source Verification Report` section with `Stages` and one table row per cited `final-verification` final-report. The run context exposes the same selection as `HANDOFF_STAGES` (csv, never empty — prepare defaults it to every eligible stage).
+  - the lead opens each cited single-stage report and confirms its `verificationScope` is `single-stage` and its verdict is release-ready — `Verdict Token` exactly `accepted`, or exactly `conditional-accept` with every **Conditional Acceptance Condition** row declaring `blocksReleaseHandoff: false`. The rule lives in `okstra_ctl.release_gate.release_handoff_allowed`; the lead reads the reports against it and does not invent a third case. Eligibility was already enforced at prepare time (`okstra_ctl.handoff.compute_eligibility`) and is re-enforced by `okstra handoff pr-plan` — the lead never hand-computes it.
+  - if any cited verdict is `blocked`, a `conditional-accept` carrying a condition that blocks release, or any other token (including ambiguous phrasing like "looks good"), the run MUST end immediately with status `blocked` and a routing recommendation back to `error-analysis` or `implementation-planning`. Do NOT prompt the user; Do NOT run any git command.
+  - when a cited verdict is `conditional-accept`, the lead MUST carry that stage's **Conditional Acceptance Condition** rows into **that stage's** PR body under a heading naming them as unresolved — id, condition, and the evidence the reviewer would need. These conditions are the whole reason a non-`accepted` verdict was allowed through; a PR body that drops them turns a recorded condition into a silent one.
   - the lead MUST capture `git status --short` and confirm the working tree is clean. Dirty state aborts the run; release-handoff packages the commits produced by `implementation`, it does not stage or commit changes.
-  - the lead MUST capture `git rev-parse --abbrev-ref HEAD` and record it as the **feature branch**. If the current branch is itself `main`, `master`, `prod`, `preprod`, `staging`, or `dev`, the run MUST end immediately — release-handoff never operates on a base branch.
-  - the lead MUST confirm `git log --oneline <base>..HEAD` contains at least one implementation commit. If it is empty, the run MUST end with status `blocked` and route back to `implementation`.
-  - In whole-task mode, compare `git rev-parse <handoff-branch>` with `finalVerification.sourceImplementationReport.capturedHeadSha` in the cited latest verification report, both at entry and immediately before pushing. Any mismatch stops delivery and requires final-verification again. In stage-group mode, run `okstra handoff eligible` again before pushing and confirm each selected stage is still eligible; assemble already checks the recorded verified commits. Record the compared commits and eligibility output in Executed Commands. These pre-push comparisons are lead instructions; the automated entry and assembly checks are enforced by `okstra_ctl.handoff_verification` and the handoff tests.
+  - the lead MUST capture `git rev-parse --abbrev-ref HEAD` and record it as the run's current branch. It is evidence, not a PR head: every PR head comes from `okstra handoff pr-plan`. If the current branch is `main`, `master`, `prod`, `preprod`, `staging`, or `dev`, record it and do not push it — release-handoff never pushes a base branch.
+  - before pushing, run `okstra handoff pr-plan` again if anything mutated since entry, and confirm each selected stage is still present in its output. `pr-plan` re-checks eligibility and each stage's recorded verified commit. Record the pr-plan output in Executed Commands. These pre-push comparisons are lead instructions; the automated entry checks are enforced by `okstra_ctl.handoff_verification` and the handoff tests.
+- **Commit history is preserved — structurally, not as a preference.** These PRs are a stack: stage N's PR base is stage N-1's branch. Squash-merging a PR in the stack replaces its commits with a new one, so the next PR's base points at commits that no longer exist on the target branch and its diff re-shows the predecessor's changes. Therefore: okstra never rebases, squashes, amends, or cherry-picks a stage branch, and the merge policy — **merge commit or rebase-merge, never squash, and merge in ascending stage order** — is stated to the operator in the final report's `Stage PR Plan` and next-action narrative. It does NOT go into the PR body: the reviewer of one stage's PR is not the person merging the stack, and the block was noise they deleted by hand (2026-09-24, dev-10860 PRs #1487-#1490).
 - User interaction protocol (Okstra lead — performed in order, using the selected runtime adapter's interactive prompt):
   1. **Action selection** — present three choices and capture exactly one:
-     - `local checkout` — bring a verified branch into the MAIN worktree for local testing (no push, no PR). Two targets: the whole-task branch (whole-task mode only), or a single stage's stack branch (`--stage N`, available in both modes since stage branches survive verification). See step 1c. When `HANDOFF_MODE` is `stage-group`, offer only the per-stage target.
-     - `push + PR` — push the feature branch, then open or reuse a pull request.
+     - `local checkout` — bring one stage's branch into the MAIN worktree for local testing (no push, no PR). See step 1c.
+     - `push + PR` — push the selected stage branches and open or reuse one pull request per stage.
      - `skip` — cancel delivery actions for now: record that release-handoff was intentionally skipped and end the run without any git command.
      If the user picks `skip`, route directly to the final-report self-review pass.
-  1c. **Local checkout execution** (only when the user picked `local checkout`) — first ask which target — when `HANDOFF_MODE` is `whole-task`, offer both the whole-task branch and one stage's stack branch; when it is `stage-group`, offer only the per-stage target — listing the selectable stage numbers (from the approved plan's Stage Map, since the run input document carries no Stage Map). Then confirm with the user that okstra will remove the corresponding okstra worktree (when it still exists) and `git checkout <branch>` in the MAIN worktree, and that the base branch is never modified. On confirmation run:
-      `okstra handoff local-checkout --project-root <project root> --project-id <id> --task-group <g> --task-id <t>` — append `--stage <N>` for the per-stage target.
-      Exit 1 means a precondition failed (MAIN worktree dirty, registry entry missing, another run of this task still `in-progress`, the target branch already deleted, or checkout failed): show the error verbatim and re-ask the action selection. On success the okstra worktree for that target no longer exists — if the lead's cwd was inside it, EVERY subsequent step (final-report authoring included) MUST use absolute paths or run from the MAIN worktree. Then route to the final-report self-review pass.
-  - **stage-group mode step order** (overrides the default Q1→Q3 sequence): after Q1 picks `push + PR`, run (1) base-branch selection first — identical to Q2 below, because the dependency-closure check needs `origin/<base>`; (2) G2 stage confirmation (step 1g); (3) assemble (step 2g); then Q2b and Q3 as usual, with the collector branch as the PR head.
-  1g. **G2 — stage confirmation**: the stage selection already happened before the run (wizard `handoff_stage_pick`, or the CLI `--stages` flag) and is fixed in `HANDOFF_STAGES`. Display it as a one-line confirmation (`PR target stage: <csv> — proceeding`) and proceed; do NOT re-ask the multi-select. Only if `HANDOFF_MODE` is `stage-group` but `HANDOFF_STAGES` is empty (defensive, should not happen) run `okstra handoff eligible --plan-run-root <plan-run-root> --approved-plan <approved plan path>` and ask the user to pick from the eligible stages.
-  2g. **assemble**: run `okstra handoff assemble --plan-run-root <...> --approved-plan <...> --project-root <project root> --project-id <id> --task-group <g> --task-id <t> --work-category <c> --stages <csv> --base <chosen-base>`. Exit 2 means a stage-vs-stage merge conflict: show the `conflicts` paths and stop (route: reshape the group or resolve manually). Exit 1 means an eligibility/closure violation: show the error verbatim and re-ask G2. On success the returned `branch` is the PR head branch for every subsequent step.
-  2. **PR base branch** (only when the user picked `push + PR`) — present four options and capture exactly one:
+  1c. **Local checkout execution** (only when the user picked `local checkout`) — first ask which stage, listing the stage numbers from `HANDOFF_STAGES` (a stage outside that list is still checkoutable; offer the approved plan's Stage Map numbers when the user asks for one, since the run input document carries no Stage Map). Then confirm with the user that okstra will remove that stage's okstra worktree (when it still exists) and `git checkout <branch>` in the MAIN worktree, and that no base branch is modified. On confirmation run:
+      `okstra handoff local-checkout --project-root <project root> --project-id <id> --task-group <g> --task-id <t> --stage <N>`
+      Exit 1 means a precondition failed (MAIN worktree dirty, registry entry missing, a run still holds the stage, the target branch already deleted, or checkout failed): show the error verbatim and re-ask the action selection. On success the okstra worktree for that stage no longer exists — if the lead's cwd was inside it, EVERY subsequent step (final-report authoring included) MUST use absolute paths or run from the MAIN worktree. Then route to the final-report self-review pass.
+  2. **Release base branch** (only when the user picked `push + PR`) — present these options and capture exactly one:
      - `preprod`
      - `main`
      - `direct input` (free-form branch name; lead validates the name exists on origin via `git ls-remote --heads origin <name>` and re-asks on failure)
-     The chosen base MUST NOT equal the feature branch. If it does, re-ask.
-  2b. **Pre-merge conflict probe** (only when the user picked `push + PR`) — before the push/PR step, the lead MUST refresh the base ref and probe for merge conflicts against it:
-     - run `git fetch origin <chosen-base>` (read-only on the local working tree).
-     - run `git merge-tree --write-tree <handoff-branch> origin/<chosen-base>`. Use the verified task branch in whole-task mode or the branch returned by assemble in stage-group mode, regardless of the current directory's HEAD. Exit 0 means clean. Exit 1 with a result-tree object ID on the first stdout line means a merge conflict. A missing result tree, or any other exit code, is an execution error: stop and report it, without offering permission to proceed as if it were a content conflict. An invalid ref can also return exit 1, so the exit code alone is insufficient.
-     - If no conflict is detected, proceed silently to Q3 (do NOT add a confirmation prompt — keep the happy path frictionless).
-     - If a conflict IS detected, present the conflicting paths (parsed from the `merge-tree` output) and capture exactly one:
-       - `proceed anyway` — continue to Q3; the PR will be opened with conflicts and the final report MUST flag this in `Merge Conflict Probe`.
-       - `change base branch` — return to Q2 and re-ask the base selection.
+     This is the release base for the run, not necessarily each PR's base: a stage that sits on another stage targets that stage's branch. The chosen base MUST NOT be one of the stage branches. If it is, re-ask.
+  2p. **PR plan** (only when the user picked `push + PR`) — run
+      `okstra handoff pr-plan --plan-run-root <...> --approved-plan <...> --project-root <project root> --project-id <id> --task-group <g> --task-id <t> --work-category <c> --stages <HANDOFF_STAGES> --base <chosen-base>`.
+      It returns one row per stage with `head_branch`, `head_commit`, `base_kind` (`release-base` | `stage` | `merge-base`), `base_branch` and `base_commit`. Exit 2 means the predecessors of a multi-dependency stage conflict with each other: show the `conflicts` paths and stop (route: resolve manually, then retry). Exit 1 means an eligibility or dependency violation — most often a stage whose predecessor is neither in this run nor already PR'd nor merged into the release base: show the error verbatim and re-ask the action selection. On success these rows are authoritative for every subsequent step; the lead does not recompute a base by hand.
+      A `merge-base` row means `pr-plan` created a branch merging that stage's predecessors. That branch is a PR base only — it is never a PR head — and it MUST be pushed before the PR that targets it.
+      The output also carries `push_plan` and `warnings`. `push_plan` is every branch the PRs sit on, already in push order (each `merge-base` first, then the stage heads in ascending order), with the `commit` it must reach and an `action` of `create` (origin does not have it), `fast-forward` (origin is behind) or `up-to-date` (origin already has that commit — do not push it). GitHub resolves a PR's head and base by name on origin, so this list, not the local branch set, is what makes the stack real. A `warnings` row means `pr-plan` fast-forwarded a local branch to origin because origin was ahead: the commits origin adds are outside what this run verified. Quote every `warnings` row verbatim in Executed Commands and say so in the branch/PR explanation — the user is deciding whether to release commits this run did not verify. `pr-plan` refuses outright when a branch moved outside okstra or diverged from origin, since only a force push could deliver it.
+  2b. **Pre-merge conflict probe** (only when the user picked `push + PR`) — before pushing, for each planned stage in ascending order:
+     - run `git fetch origin <chosen-base>` once (read-only on the local working tree).
+     - run `git merge-tree --write-tree <head_branch> <base_branch>` for that stage, using the `base_branch` from the pr-plan row (`origin/<chosen-base>` for a `release-base` row). Exit 0 means clean. Exit 1 with a result-tree object ID on the first stdout line means a merge conflict. A missing result tree, or any other exit code, is an execution error: stop and report it, without offering permission to proceed as if it were a content conflict. An invalid ref can also return exit 1, so the exit code alone is insufficient.
+     - If no stage conflicts, proceed silently to Q3 (do NOT add a confirmation prompt — keep the happy path frictionless).
+     - If any stage conflicts, present the conflicting stage(s) and their paths (parsed from the `merge-tree` output) and capture exactly one:
+       - `proceed anyway` — continue to Q3; the affected PRs will be opened with conflicts and the final report MUST flag this in `Merge Conflict Probe`.
+       - `change base branch` — return to Q2 and re-ask the base selection (and re-run pr-plan).
        - `cancel` — end the run without push or PR; record the cancellation in the final report.
      - The probe is read-only. It MUST NOT run `git merge`, `git rebase`, `git pull`, or any command that mutates the working tree or local refs.
-  3. **PR title + PR body confirmation** — show the lead's inline draft verbatim, together with the filled-body self-check result (either `body self-check: clean` or the list of hits with their lines, per the drafting rules below), and capture one of:
-     - `use as-is` — proceed with the drafted text.
-     - `edit then proceed` — accept inline edits from the user, then proceed with the edited text.
+  3. **PR title + PR body confirmation** — draft every selected stage's title and body first, then show all of them verbatim in ONE question, each with the filled-body self-check result (either `body self-check: clean` or the list of hits with their lines, per the drafting rules below), and capture one of:
+     - `use as-is` — proceed with the drafted text for every stage.
+     - `edit then proceed` — accept inline edits from the user (the user may edit any subset), then proceed with the edited text.
      - `cancel` — end the run without executing push or PR commands; record the cancellation in the final report.
-- Inline drafting rules (Okstra lead):
-  - read the run brief, the cited final-verification report, `git log --oneline <base>..HEAD`, and `git diff <base>..HEAD --stat` to ground the drafted text in actual committed changes. In stage-group mode the draft is grounded on `git log <implementation_base_commit>..<collector HEAD>` / `git diff <implementation_base_commit>..<collector HEAD> --stat`, with source material = each selected stage's implementation report + its single-stage verification report.
+- Inline drafting rules (Okstra lead) — applied once per stage:
+  - read the run brief, that stage's cited final-verification report and its implementation report, `git log --oneline <base_commit>..<head_commit>`, and `git diff <base_commit>..<head_commit> --stat` (both from the stage's pr-plan row) to ground the drafted text in the commits that PR actually carries. A stacked PR's diff is that stage alone — do not describe a predecessor's work in it.
   - **PR body template** — the run context exposes `PR_TEMPLATE_PATH` and `PR_TEMPLATE_SOURCE`. The path MUST be an okstra-owned project artifact under `<PROJECT_ROOT>/.okstra/**`, or a file the prepare step already materialised into this run's artifact directory. If the resolved file is missing or outside that boundary at draft time, abort with a clear error — do NOT invent a structure. Otherwise the lead MUST `Read` it verbatim, strip HTML comments, and fill in the placeholders, treating the template (never a hard-coded section list) as the source of truth for the structure.
-  - produce **two artifacts** before showing them to the user:
-    1. **PR title** — by default the subject of the most recent implementation commit, or a concise Conventional Commits-style summary of the committed range.
-    2. **PR body** — markdown filled from `PR_TEMPLATE_PATH`. The user-confirmation step's diff (Q3 `edit then proceed`) is computed against the filled template, not against the raw template file.
-  - **Filled-body self-check (runs on the drafted body, before Q3 shows it).** "Fill in the placeholders" is only observable if someone checks that they were filled, so scan the drafted body for these and carry the result into Q3: a residual HTML comment or template marker (`<!-- … -->`, `_Describe your changes…_`, a bare `TODO` / `FIXME` the diff did not introduce), an unchecked `- [ ]` box with no inline N/A justification, a section heading whose body is empty, and a whole body short enough to carry no substance. Each hit is reported to the user with its line — never silently left in, and never auto-filled with invented content. The user remains free to accept it; the point is that they see it before choosing `use as-is`.
+  - produce **two artifacts per stage** before showing them to the user:
+    1. **PR title** — by default the subject of that stage's most recent implementation commit, or a concise Conventional Commits-style summary of the stage's committed range.
+    2. **PR body** — markdown filled from `PR_TEMPLATE_PATH`, and nothing else. Do NOT append a stack plan, a stage checklist, a sentence about where this PR stops in the stack, or a merge-policy line: the stack's shape and merge rule belong to the final report and the closeout, not to a reviewer's PR. The user-confirmation step's diff (Q3 `edit then proceed`) is computed against the filled template, not against the raw template file.
+  - **Filled-body self-check (runs on each drafted body, before Q3 shows it).** "Fill in the placeholders" is only observable if someone checks that they were filled, so scan the drafted body for these and carry the result into Q3: a residual HTML comment or template marker (`<!-- … -->`, `_Describe your changes…_`, a bare `TODO` / `FIXME` the diff did not introduce), an unchecked `- [ ]` box with no inline N/A justification, a section heading whose body is empty, and a whole body short enough to carry no substance. Each hit is reported to the user with its line — never silently left in, and never auto-filled with invented content. The user remains free to accept it; the point is that they see it before choosing `use as-is`.
 - Allowed actions during the run (Okstra lead only):
   - read-only inspection: `git status`, `git status --short`, `git diff`, `git log`, `git rev-parse`, `git ls-remote --heads origin <name>`, `gh pr list --head <branch>`, `gh pr view <url>`.
-  - merge-conflict probe (only when the user picked `push + PR`): `git fetch origin <chosen-base>` and the exact `git merge-tree` command from step 2b. Both preserve the working tree and branch tips.
-  - feature-branch push (only when the user picked `push + PR`): `git push -u origin <current-branch>`. The pushed ref MUST be the feature branch — never the chosen base branch. (stage-group mode: the collector branch returned by assemble)
-  - PR creation (only when the user picked `push + PR` AND no PR with the same head already exists on origin): `gh pr create --base <chosen-base> --head <current-branch> --title "<title>" --body "<body>"`. The title and body are the user-confirmed PR draft.
-  - PR reuse: if `gh pr list --head <branch> --state open --json url --jq '.[0].url'` returns a URL, treat that PR as already existing — record the URL in the final report and SKIP `gh pr create`.
-  - after `gh pr create` succeeds (or an existing PR is reused), the lead MUST run `okstra handoff record-pr --plan-run-root <...> --stages <csv> --branch <head branch> --url <pr url>` and quote the command + exit code in the final report. This applies to BOTH modes — whole-task runs record `--stages` as the full Stage Map list — so duplicate-PR prevention for both modes converges on a single consumers ledger.
-  - stage-group helpers: `okstra handoff eligible`, `okstra handoff assemble`, `okstra handoff record-pr`. The assemble step is the ONLY path that may create commits (merge commits on the collector branch) in this phase.
+  - merge-conflict probe (only when the user picked `push + PR`): `git fetch origin <chosen-base>` and the exact `git merge-tree` commands from step 2b. Both preserve the working tree and branch tips.
+  - branch push (only when the user picked `push + PR`): `git push -u origin <branch>` for each `push_plan` row whose `action` is `create` or `fast-forward`, in the order `push_plan` lists them (each `merge-base` branch before the PR that targets it, then the stage heads in ascending order). Skip an `up-to-date` row — origin already holds that commit. The pushed ref MUST come from a `push_plan` row — never the release base branch, and never a ref that list does not name.
+  - PR creation, one per stage (only when the user picked `push + PR` AND no PR with the same head already exists on origin): `gh pr create --base <row base_branch> --head <row head_branch> --title "<title>" --body "<body>"`. The title and body are the user-confirmed PR draft for that stage. Open them in ascending stage order so each base branch already exists on origin.
+  - PR reuse: if `gh pr list --head <branch> --state open --json url --jq '.[0].url'` returns a URL, treat that PR as already existing — record the URL in the final report and SKIP `gh pr create` for that stage.
+  - after each `gh pr create` succeeds (or an existing PR is reused), the lead MUST run `okstra handoff record-pr --plan-run-root <...> --stage <N> --branch <head branch> --base <base branch> --url <pr url>` and quote the command + exit code in the final report. One record-pr call per stage — the consumers ledger is what stops the same stage being PR'd twice.
+  - stage helpers: `okstra handoff eligible`, `okstra handoff pr-plan`, `okstra handoff record-pr`, `okstra handoff local-checkout`. `pr-plan` is the ONLY path that may create commits in this phase (merge commits on a `merge-base` branch, and only for a multi-dependency stage).
 - Forbidden actions (any occurrence → terminal status `contract-violated`):
 {{PHASE_FORBIDDEN_ACTIONS}}
 - Required deliverable shape (final report, in addition to the standard sections):
-  - **Source Verification Report**: relative path of the originating `final-verification` final-report file plus the literal quoted `Verdict Token` row, and — when that token is `conditional-accept` — every Conditional Acceptance Condition row quoted with its `blocksReleaseHandoff` value.
-  - **Feature Branch & Working-Tree State**: branch name from `git rev-parse --abbrev-ref HEAD`, output of `git status --short` at run start.
+  - **Source Verification Reports**: one row per selected stage — relative path of that stage's originating `final-verification` final-report plus the literal quoted `Verdict Token` row, and — when that token is `conditional-accept` — every Conditional Acceptance Condition row quoted with its `blocksReleaseHandoff` value.
+  - **Feature Branch & Working-Tree State**: the branch from `git rev-parse --abbrev-ref HEAD` at run start and the output of `git status --short` at run start.
+  - **Stage PR Plan**: the pr-plan rows — stage, head branch, head commit, base kind, base branch, base commit — plus, for every `merge-base` row, which predecessor stages it merges and the merge commits it created. This is the table a reader uses to merge the stack in the right order, so it carries the merge rule with it: merge in ascending stage order, with a merge commit or rebase-merge, never a squash.
+  - **User narrative `nextAction`**: when this run opened or reused any PR, it names the merge order (ascending stage number) and the merge rule (merge commit or rebase-merge, never squash), and says why — squashing one PR in the stack invalidates the next PR's base. This is where the operator reads the rule; the PR bodies do not carry it.
   - **User Selections**: a block recording each prompt and the user's verbatim answer.
     - Q1 action: `local checkout` | `push + PR` | `skip`.
-    - Q1c checkout target (only when Q1 is `local checkout`): `whole-task branch` | `stage <N> stack branch`, plus the `--stage <N>` value this answer produced (or `no --stage` for the whole-task branch). Record it in the `User Selections` row `H1c` (`userSelections.h1c`); omit the row entirely when Q1 was not `local checkout`.
-    - Q2 PR base (if applicable): the chosen branch and how it was selected (menu pick vs free-form input).
-    - Q2b merge-conflict probe (if applicable): `not-run` | `clean` (no conflict, no prompt shown) | `proceed anyway` | `change base branch` | `cancel`. Record it in both the `User Selections` row `H2b` and the `Merge Conflict Probe` deliverable. When a conflict was detected, list the conflicting paths.
+    - Q1c checkout stage (only when Q1 is `local checkout`): the `--stage <N>` value this answer produced. Record it in the `User Selections` row `H1c` (`userSelections.h1c`); omit the row entirely when Q1 was not `local checkout`.
+    - Q2 release base (if applicable): the chosen branch and how it was selected (menu pick vs free-form input).
+    - Q2b merge-conflict probe (if applicable): `not-run` | `clean` (no conflict, no prompt shown) | `proceed anyway` | `change base branch` | `cancel`. Record it in both the `User Selections` row `H2b` and the `Merge Conflict Probe` deliverable. When a conflict was detected, list the conflicting stages and paths.
     - Q3 title/body: `use as-is` | `edit then proceed` (with a diff between the lead's draft and the final text) | `cancel`.
   - **Executed Commands**: every git / gh command the lead actually ran, with its exit code and a one-line stdout/stderr summary. Read-only inspection commands MAY be summarised; mutating commands MUST be listed verbatim.
-  - **Commit List**: each existing implementation commit in `git log <base>..HEAD`, with short/full SHA, subject line, and touched files. Release-handoff MUST NOT create new commits.
+  - **Commit List**: per stage, each implementation commit in `git log <base_commit>..<head_commit>`, with short/full SHA, subject line, and touched files. Release-handoff MUST NOT create new commits other than a `merge-base` branch's merge commits.
   - **Merge Conflict Probe**: one of
     - `- Not run (user picked local checkout or skip).`
-    - `- Clean — no conflicts against <base> at <origin/base SHA>.`
-    - `- Conflicts detected against <base> at <origin/base SHA>; user chose <proceed anyway | change base branch | cancel>. Conflicting paths: <list>.`
-  - **Pull Request Outcome**: one of
+    - `- Clean — every stage merges cleanly into its PR base at <origin/base SHA>.`
+    - `- Conflicts detected for stage(s) <list> against <base> at <origin/base SHA>; user chose <proceed anyway | change base branch | cancel>. Conflicting paths: <list>.`
+  - **Pull Request Outcomes**: one row per selected stage, each one of
     - `- No PR action requested.` (user picked `local checkout` or `skip`)
-    - `- PR created: <url>` with title and base branch
-    - `- PR reused: <url>` when an existing PR was found via `gh pr list`
-    - `- PR creation skipped: <reason>` for any user-driven cancellation
+    - `- Stage <N> PR created: <url>` with title and base branch
+    - `- Stage <N> PR reused: <url>` when an existing PR was found via `gh pr list`
+    - `- Stage <N> PR creation skipped: <reason>` for any user-driven cancellation
   - **Local Checkout Outcome**: one of
     - `- Not run (user picked push + PR or skip).`
-    - `- Checked out <branch> into <main worktree path>; okstra worktree <path> removed. Next: to run a local test and then open a PR, re-enter release-handoff via okstra-run → push + PR.`
-    - `- Checked out <branch> into <main worktree path>; no okstra worktree removed (already torn down — the branch survived). Next: to run a local test and then open a PR, re-enter release-handoff via okstra-run → push + PR.`
+    - `- Checked out <branch> (stage <N>) into <main worktree path>; okstra worktree <path> removed. Next: to run a local test and then open a PR, re-enter release-handoff via okstra-run → push + PR.`
+    - `- Checked out <branch> (stage <N>) into <main worktree path>; no okstra worktree removed (already torn down — the branch survived). Next: to run a local test and then open a PR, re-enter release-handoff via okstra-run → push + PR.`
     - Pick between the two `Checked out` variants by the command's `removedWorktree` field: a non-empty path takes the first, an empty string takes the second. Never write a removal that did not happen.
-  - **Stage Group** (stage-group mode only): selected stages, each stage's single-stage verification report path + quoted `Verdict Token` row, collector branch name, merge commit SHAs from assemble, and the dependency-closure verdict (from the assemble output / error).
-  - **Routing recommendation**: explicit `done` token, since release-handoff is the terminal lifecycle phase. If the run ended in `skip` or `cancel`, the recommendation MUST also state whether re-entry into release-handoff is appropriate.
+  - **Routing recommendation**: explicit `done` token, since release-handoff is the terminal lifecycle phase. If the run ended in `skip` or `cancel`, or delivered only some of the selected stages, the recommendation MUST state which stages still need a PR and that re-entry into release-handoff is appropriate.
 - Self-review pass before finalising the report (the Okstra lead runs this):
-  1. **Entry-gate audit** — section 2 cites the originating final-verification report path and the literal `Verdict Token` row with a release-ready value. If either is missing, or a `conditional-accept` run's PR body omits the conditions, the run is invalid and MUST be re-routed to `final-verification`.
+  1. **Entry-gate audit** — the report cites, for every stage it delivered, that stage's final-verification report path and the literal `Verdict Token` row with a release-ready value. If any is missing, or a `conditional-accept` stage's PR body omits its conditions, the run is invalid and MUST be re-routed to `final-verification`.
   2. **User-selection traceability** — every executed mutating command maps to a user selection captured in the report. Any mutating command without a corresponding user answer is a contract violation.
   3. **Forbidden-action audit** — scan the run's session transcripts (`git`, `gh` invocations) for every entry in the Forbidden actions list above. Any occurrence means the run has crossed into unsafe territory and MUST be flagged as `contract-violated`.
-  4. **Push-target audit** — for every `git push` recorded, confirm the refspec resolves to the feature branch, not the base branch.
-  5. **Idempotency check** — if a PR with the same head already existed at run start, confirm the report records `PR reused` rather than a fresh `gh pr create` invocation.
-  6. **Merge-conflict probe audit** — for any `push + PR` run, confirm the report's `Merge Conflict Probe` section is present and either records `Clean` or records `Conflicts detected` with the user's verbatim choice. A missing or unparseable probe entry on a `push + PR` run is a contract violation.
+  4. **Push-target audit** — for every `git push` recorded, confirm the refspec resolves to a branch that appears in the pr-plan output, not to the release base branch.
+  5. **Stack-integrity audit** — for every PR opened, confirm its base is the `base_branch` of that stage's pr-plan row and that the base branch was pushed first. A stacked PR opened against the release base instead of its predecessor ships the predecessor's diff twice. Confirm too that no PR body carries a stack plan or merge-policy block — that text belongs to the report and the closeout.
+  6. **Idempotency check** — for every stage whose PR already existed at run start, confirm the report records `PR reused` rather than a fresh `gh pr create` invocation.
+  7. **Merge-conflict probe audit** — for any `push + PR` run, confirm the report's `Merge Conflict Probe` section is present and either records `Clean` or records `Conflicts detected` with the user's verbatim choice. A missing or unparseable probe entry on a `push + PR` run is a contract violation.
 - Non-goals:
-  - re-litigating the final-verification verdict — release-handoff trusts the cited release-ready verdict and does not reopen acceptance checks. Carrying a conditional-accept's conditions into the PR body is transcription, not verification: the lead does not check whether a condition has been satisfied.
-  - creating, amending, squashing, or rewriting commits. Commit production belongs to `implementation`.
-  - opening additional PRs, releases, or deployments beyond the single PR the user chose to create.
-  - merging the PR. Merging is a separate, manual step performed by the user (or by repo automation) after release-handoff ends; the lead MUST NOT call `gh pr merge`.
+  - re-litigating a final-verification verdict — release-handoff trusts the cited release-ready verdicts and does not reopen acceptance checks. Carrying a conditional-accept's conditions into the PR body is transcription, not verification: the lead does not check whether a condition has been satisfied.
+  - creating, amending, squashing, rebasing, or rewriting commits. Commit production belongs to `implementation`; the only commits this phase may create are the merge commits `okstra handoff pr-plan` makes on a `merge-base` branch.
+  - bundling several stages into one PR, or building a branch that collects every stage. One stage is one PR.
+  - opening releases or deployments beyond the per-stage PRs the user chose to create.
+  - merging the PRs. Merging is a separate, manual step performed by the user (or by repo automation) after release-handoff ends; the lead MUST NOT call `gh pr merge`.
   - escalating beyond the menu choices on user phrasing — every mutating action requires an explicit menu selection.

package/runtime/prompts/profiles/requirements-discovery.json

@@ -0,0 +1,39 @@
+{
+  "schemaVersion": "1.0",
+  "id": "requirements-discovery",
+  "roles": [
+    {
+      "mode": "static",
+      "roleId": "analyser",
+      "dutyId": "discovery-worker",
+      "min": 2,
+      "recommended": 3,
+      "max": 5
+    },
+    {
+      "mode": "static",
+      "roleId": "critic",
+      "dutyId": "scope-critic",
+      "min": 0,
+      "recommended": 1,
+      "max": 1
+    },
+    {
+      "mode": "static",
+      "roleId": "report-writer",
+      "dutyId": "report-writer",
+      "min": 1,
+      "recommended": 1,
+      "max": 1
+    },
+    {
+      "mode": "dynamic",
+      "roleId": "verifier",
+      "dutyId": "reverification-worker",
+      "sourceRoleIds": [
+        "analyser"
+      ],
+      "activation": "per-selected-source"
+    }
+  ]
+}

package/runtime/prompts/profiles/requirements-discovery.md

@@ -1,30 +1,5 @@
 # Requirements Discovery Profile
 
-```yaml
-roles:
-  - role: analyser
-    min: 2
-    recommended: 3
-    max: 5
-    duty: discovery-worker
-  - role: critic
-    min: 0
-    recommended: 1
-    max: 1
-    duty: scope-critic
-  - role: report-writer
-    min: 1
-    recommended: 1
-    max: 1
-    duty: report-writer
-  - role: verifier
-    min: 0
-    recommended: 0
-    max: 0
-    duty: reverification-worker
-    dynamic: true
-```
-
 - Purpose: classify the work request, identify missing requirement evidence, and route the task to the safest next lifecycle phase before implementation starts
 - Required workers:
   - claude

package/runtime/prompts/profiles/technical-verification.json

@@ -0,0 +1,39 @@
+{
+  "schemaVersion": "1.0",
+  "id": "technical-verification",
+  "roles": [
+    {
+      "mode": "static",
+      "roleId": "analyser",
+      "dutyId": "technical-verification-worker",
+      "min": 2,
+      "recommended": 2,
+      "max": 5
+    },
+    {
+      "mode": "static",
+      "roleId": "critic",
+      "dutyId": "scope-critic",
+      "min": 0,
+      "recommended": 1,
+      "max": 1
+    },
+    {
+      "mode": "static",
+      "roleId": "report-writer",
+      "dutyId": "report-writer",
+      "min": 1,
+      "recommended": 1,
+      "max": 1
+    },
+    {
+      "mode": "dynamic",
+      "roleId": "verifier",
+      "dutyId": "reverification-worker",
+      "sourceRoleIds": [
+        "analyser"
+      ],
+      "activation": "per-selected-source"
+    }
+  ]
+}

package/runtime/prompts/profiles/technical-verification.md

@@ -1,30 +1,5 @@
 # Technical Verification Profile
 
-```yaml
-roles:
-  - role: analyser
-    min: 2
-    recommended: 2
-    max: 5
-    duty: technical-verification-worker
-  - role: critic
-    min: 0
-    recommended: 1
-    max: 1
-    duty: scope-critic
-  - role: report-writer
-    min: 1
-    recommended: 1
-    max: 1
-    duty: report-writer
-  - role: verifier
-    min: 0
-    recommended: 0
-    max: 0
-    duty: reverification-worker
-    dynamic: true
-```
-
 - Purpose: collect experimental evidence for unresolved technical facts before a new implementation comparison.
 - Required workers:
   - claude

package/runtime/prompts/wizard/prompts.ko.json

@@ -101,7 +101,7 @@
       "echo_template": "task-type: {value}"
     },
     "selected_direction_pick": {
-      "label": "상세 계획의 입력으로 사용할 확정 구현 방향 보고서를 선택하세요 (같은 task의 최신 3개). 고른 보고서의 user-responses/ 답변(방향 선택·C-NNN 답)이 함께 전달됩니다 — clarification-response 단계는 필요 없습니다",
+      "label": "상세 계획의 입력으로 쓸 확정 구현 방향 보고서를 고르세요 (같은 task 의 최신 3개). 고른 보고서에 딸린 답변 — 어느 방향을 골랐는지와 확인 질문(C-NNN) 답 — 이 함께 전달되므로 뒤의 clarification 단계는 건너뜁니다",
       "echo_template": "selected-direction: {value}",
       "errors": {
         "none": "같은 task에서 선택할 implementation-option-selection 최종 보고서를 찾을 수 없습니다.",
@@ -189,37 +189,34 @@
       "echo_template": "analysis-target: {value}"
     },
     "handoff_stage_pick": {
-      "label": "PR 로 내보낼 범위를 선택하세요 (복수 선택 가능 — 검증 accepted + 미-PR stage 만 표시). 제외된 stage: {blocked}",
-      "echo_template": "handoff-scope: {value}",
+      "label": "PR 을 열 stage 를 선택하세요 (복수 선택 가능, stage 하나가 PR 하나 — 검증 accepted + 미-PR stage 만 표시). 제외된 stage: {blocked}",
+      "echo_template": "handoff-stages: {value}",
       "labels": {
-        "whole_task": "전체 task — whole-task 검증 기반 단일 PR (단독 선택)",
         "stage": "stage {stage} (depends-on: {deps})",
-        "blocked_none": "없음"
+        "blocked_none": "없음",
+        "all_stages": "전체 stage ({stages}) — 자격 있는 stage 마다 PR 하나"
       },
       "echo_variants": {
-        "whole_task": "handoff scope: 전체 task (whole-task 검증 기반)",
-        "stage_group": "handoff scope: stage-group ({stages})"
+        "stages": "handoff stages: {stages}"
       },
       "errors": {
         "no_plan": "release-handoff 는 이 task 의 implementation-planning final-report 가 필요합니다 — implementation-planning → implementation → final-verification 을 먼저 진행하세요.",
         "plan_not_approved": "최신 plan 이 approved 상태가 아닙니다: {plan} — implementation 이 완료된 task 에서만 release-handoff 를 시작할 수 있습니다.",
-        "nothing_eligible": "PR 로 내보낼 수 있는 범위가 없습니다 — 제외 사유: {blocked}. 단독-stage final-verification 의 accepted 기록(okstra handoff record-verified) 또는 whole-task 검증을 먼저 완료하세요.",
-        "none_selected": "최소 1개의 범위를 선택하세요",
-        "whole_task_exclusive": "'전체 task' 는 단독 선택만 가능합니다 — stage 묶음을 원하면 stage 번호들만 선택하세요",
-        "whole_task_missing": "accepted whole-task final-verification 보고서가 없습니다",
+        "nothing_eligible": "PR 로 내보낼 수 있는 stage 가 없습니다 — 제외 사유: {blocked}. final-verification 의 accepted 판정을 `okstra handoff record-verified` 로 먼저 기록하세요 — 단독-stage 판정과 전체 task 판정 모두 근거가 됩니다.",
+        "none_selected": "최소 1개의 stage 를 선택하세요",
         "not_eligible": "eligible 하지 않은 stage: {bad} (선택 가능: {eligible})"
       }
     },
     "brief_carry": {
-      "label": "이 task 에 carry-in 할 brief 가 없습니다. {task_type} 는 entry phase 의 brief 를 이어받는 단계입니다 — 어떻게 진행할까요?",
+      "label": "이 task 에는 이어받을 brief 가 없습니다. {task_type} 는 앞 단계가 쓴 brief 를 물려받아 도는 단계라 그 brief 없이는 시작할 수 없습니다 — 어떻게 할까요?",
       "echo_template": "brief-carry: {value}",
       "options": {
-        "__switch_entry__": "entry phase 로 전환 (추천) — requirements-discovery / error-analysis / improvement-discovery 부터 시작",
+        "__switch_entry__": "brief 를 처음 쓰는 단계부터 시작 (추천) — requirements-discovery / error-analysis / improvement-discovery",
         "__free_input__": "brief 경로 직접 입력",
         "__abort__": "중단"
       },
       "echo_variants": {
-        "switch_entry": "brief-carry: entry phase 로 전환 — task-type 을 다시 선택합니다",
+        "switch_entry": "brief-carry: brief 를 처음 쓰는 단계로 전환 — task-type 을 다시 선택합니다",
         "abort": "brief-carry: 중단"
       }
     },
@@ -402,7 +399,7 @@
       }
     },
     "clarification_pick": {
-      "label": "clarification-response 를 넘길까요? (follow-up 시에만 — final-report 선택 시 user-responses/ 폴더의 답변도 함께 첨부됩니다)",
+      "label": "지난 run 이 남긴 확인 질문(C-NNN)에 답한 파일을 이번 입력으로 넘길까요? 이어서 도는 run 에서만 해당합니다 — 최근 final-report 를 고르면 그 리포트에 딸린 답변도 함께 전달됩니다",
       "echo_template": "clarification(pick): {value}",
       "options": {
         "__skip__": "없음 (건너뛰기)",
@@ -590,7 +587,7 @@
       "echo_template": "related-tasks: {value}"
     },
     "clarification": {
-      "label": "clarification-response 파일 경로 (follow-up 시에만, 없으면 빈 줄)",
+      "label": "지난 run 의 확인 질문에 답한 파일 경로 (이어서 도는 run 에서만, 없으면 빈 줄)",
       "echo_template": "clarification: {value}"
     },
     "pr_template": {
@@ -670,7 +667,6 @@
     "reverify_scope_user_carry_all": "  reverify-scope: carry-all (사용자 지정 — 재검증 없이 직전 판정 전부 이월, 새 stage 만 검증; 브랜치가 움직였으면 full 로 내려감)",
     "reverify_scope_user_stages": "  reverify-scope: stage {stages} 재검증 지정 (사용자 지정 — 하위 stage 포함, 나머지는 직전 판정 이월)",
     "stage_whole_task": "전체 task",
-    "handoff_scope_whole_task": "전체 task (whole-task 검증 기반)",
-    "handoff_scope_stage_group": "stage-group ({stages})"
+    "handoff_scope_stages": "stage {stages} (stage 당 PR 1건)"
   }
 }

package/runtime/python/okstra_ctl/adapters/hosts/antigravity/relay.md

@@ -89,6 +89,7 @@ Render every numbered item as its option label followed by its description verba
 - For convergence reverify, consume the persisted round plan exactly. This adapter may map and transport each returned batch, but it cannot change batch membership and does not classify findings or branch on task type, provider, or model identity.
 - The current Antigravity session is the lead. Never launch another provider as a replacement lead.
 - The prepared run manifest and team-state are the assignment authority. Keep `runner=native-session` assignments in the current host and route `runner=cli-wrapper` assignments through the registered wrapper.
+- This host declares no worker session contract. A `runner=native-session` worker therefore receives no host session rules beyond its duty contract, the selected preamble, and the task instructions; the dispatch prompt carries no `**Host Session Contract Path:**` header. Declaring one means adding `workerSessionContract` to this adapter's `manifest.json` and descriptor — it is never installed into a host-global discovery path.
 - Do not infer the current host from an installed `agy` binary. The `antigravity` runtime must come from the active host skill or an explicit runtime flag.
 - Unsupported workers or unavailable models fail before dispatch; do not change the provider, model, or runner silently.
 - Reverify and critic retries use fresh attempts and persist the core-supplied `dispatchKind`.

package/runtime/python/okstra_ctl/adapters/hosts/claude-code/adapter.py

@@ -42,6 +42,9 @@ DESCRIPTOR = HostDescriptor(
     session_accounting="claude-jsonl",
     has_claude_session=True,
     relay_contract=str(Path(__file__).with_name("relay.md").resolve()),
+    worker_session_contract=str(
+        Path(__file__).with_name("worker-session.md").resolve()
+    ),
     initial_prompt_delivery_mode="eager-include",
 )
 

package/runtime/python/okstra_ctl/adapters/hosts/claude-code/manifest.json

@@ -1 +1 @@
-{"schemaVersion": 1, "id": "claude-code", "factory": "adapter.py:create_adapter", "nativeProviderId": "claude", "requiredExecutables": ["claude"], "relayContract": "relay.md"}
+{"schemaVersion": 1, "id": "claude-code", "factory": "adapter.py:create_adapter", "nativeProviderId": "claude", "requiredExecutables": ["claude"], "relayContract": "relay.md", "workerSessionContract": "worker-session.md"}

package/runtime/python/okstra_ctl/adapters/hosts/claude-code/relay.md

@@ -158,7 +158,7 @@ The `confirm` prompt's `label` is the selection summary (one line per resolved i
 | `read_artifacts` | Use the host file-read primitive and preserve the core contract's read order. |
 | `write_artifact` | Use the host file-write primitive only for paths authorized by the active lifecycle phase. |
 | `prompt_user` | Use `AskUserQuestion` for approvals and clarifications that fit `nativeLimits`. Do not print a numbered list in chat while that tool is available. Emit the question as the last thing in that turn: assistant text emitted after the call renders below the question and separates it from the user's answer. Do not infer an answer from silence. |
-| `dispatch_worker` | First verify the materialized invocation metadata. Dispatch `runner=native-session` through `Agent(name: "<role>", run_in_background: true)` without `team_name`, with `hostModelValue` and a summon message only — never the prompt body. The summon is exactly: `Your complete dispatch instructions are the document at <absolute promptPath>. Read that document in full before doing anything else — every line, continuing with offset until end of file — then execute it exactly. Do not act on this message alone.` The verified `promptPath` is already persisted and metadata-verified; inlining its body into the `Agent` call duplicates it in the lead context and lets the two copies drift. Dispatch `runner=cli-wrapper` with the deterministic shell command `okstra worker-dispatch --project-root <root> --run-manifest <path> --workers <ids>`; never wrap that process in another `Agent(...)` call. **Not in a cmux run:** when the run manifest's `terminalBackend` is `cmux-pane`, `prompts/lead/adapters/cmux.md` overrides this row. |
+| `dispatch_worker` | First verify the materialized invocation metadata. Dispatch `runner=native-session` through `Agent(name: "<role>", run_in_background: true)` without `team_name`, with `hostModelValue` and a summon message only — never the prompt body. The summon is exactly: `Your complete dispatch instructions are the document at <absolute promptPath>. Read that document in full before doing anything else — every line, continuing with offset until end of file — then execute it exactly. Do not act on this message alone. If this message carries no such path, return `CLAUDE_PROMPT_PATH_MISSING: dispatch prompt document path was not provided` and do nothing else.` The verified `promptPath` is already persisted and metadata-verified; inlining its body into the `Agent` call duplicates it in the lead context and lets the two copies drift. The summon carries the read requirement because nothing else can: every other rule the worker follows lives inside the document it is being told to open. This host declares a worker session contract (`worker-session.md`), which the materialized prompt delivers to `runner=native-session` workers as `**Host Session Contract Path:**`. Dispatch `runner=cli-wrapper` with the deterministic shell command `okstra worker-dispatch --project-root <root> --run-manifest <path> --workers <ids>`; never wrap that process in another `Agent(...)` call. **Not in a cmux run:** when the run manifest's `terminalBackend` is `cmux-pane`, `prompts/lead/adapters/cmux.md` overrides this row. |
 | `await_workers` | Arm one background shell poll for the pending Result Paths; the spawn acknowledgement is not completion. |
 | `redispatch_worker` | Materialize and verify a fresh invocation, then use a fresh native `Agent(...)` session or `okstra worker-dispatch` attempt according to the persisted runner. |
 | `shutdown_workers` | For each confirmed-complete worker selected for cleanup, send `SendMessage(to: <name>, message: { type: "shutdown_request" })` to idle the roster member **and** call `TaskStop(task_id: "<name>")` to stop its background task. Both are required; neither subsumes the other. |
@@ -169,14 +169,15 @@ The `confirm` prompt's `label` is the selection summary (one line per resolved i
 
 - The session owns one implicit team. `TeamCreate` and `TeamDelete` are absent on current Claude Code builds; never probe for them and never pass `team_name`.
 - Set `name` to the core-assigned functional role label so token attribution can match `agentName`.
-- Map a `runner=native-session` Claude assignment to the real host execution definition for its function (`claude-worker`, `report-writer-worker`, or `translator-worker`). A CLI-wrapper assignment has no Claude agent definition; `worker-dispatch` starts its registered provider process directly.
+- A `runner=native-session` Claude assignment opens a general-purpose session: pass no `subagent_type`. okstra registers no agent definitions in this host's discovery path, so there is none to name (ADR-0017). Everything the worker must do reaches it through the summon message and the document that message points at. A CLI-wrapper assignment does not enter this layer at all; `worker-dispatch` starts its registered provider process directly.
+- The native worker primitive for this host is the `Agent` tool. Host session rules — working directory, shell invocation, MCP call shape, and when to return — are owned by this host's worker session contract, not by an execution definition, so they reach a native worker through `**Host Session Contract Path:**` and never reach a CLI-wrapper worker.
 - For `runner=native-session`, pass the persisted `hostModelValue` as the `model` argument. For `runner=cli-wrapper`, `worker-dispatch` passes the persisted `modelExecutionValue` to the provider process. Never interchange the two fields.
 - Immediately before every native host primitive, run `okstra agent-prompt record-dispatch` with the project root, run manifest, verified metadata path, and `--enforcement-mode host-native-spec-link-gate`. After the Result Path exists, run `okstra agent-prompt link-result` with `--dispatch-id <invocationId>:attempt-1` and that path before accepting or parsing it. CLI-wrapper calls are recorded by `worker-dispatch` itself.
 - A resumed lead can dispatch a fresh worker; resume is not a valid reason to omit a rostered role.
 
 ### Dispatch-time model enforcement
 
-- A native Claude execution definition declares `model: inherit`; the lead MUST override it with the verified assignment's `hostModelValue`.
+- A native call inherits nothing: pass the verified assignment's `hostModelValue` as the `model` argument on every dispatch.
 - CLI-wrapper assignments never enter the Agent layer. `okstra worker-dispatch` validates the metadata and passes `modelExecutionValue` to the registered provider script.
 - Missing or unsupported family-token mapping is a pre-dispatch contract failure. Never inherit the lead model, choose a nearby alias, or switch provider silently.
 - Every analysis dispatch sets `name: "<workerId>-worker"`; convergence retries append `-reverify-r<N>`, implementation uses the functional `-executor` / `-verifier` suffix, and report writing uses `report-writer`. These values are retained as `agentName` in session JSONL for usage attribution.