okstra 0.174.0 → 0.176.0

package/runtime/prompts/lead/team-contract.md

@@ -13,19 +13,23 @@ Okstra tasks use one lead plus the exact worker assignments selected in the prep
 
 ### Role Definitions
 
-**All analysis workers (Claude / Codex / Antigravity) share an identical core responsibility.** Specialization is additive — it lives in optional Section 6 of the worker output, NOT in differentiated core questions. This is intentional: cross-verification only converges if all three workers are answering the same questions against the same brief. Disjoint per-worker scopes produce union-of-perspectives, not triangulation.
+The start screen assigns a **model ref** (`provider/model`) to each **canonical role** slot: `leader`, `analyser`, `critic`, `designer`, `planner`, `implementer`, `verifier`, `report-writer`, `translator`. A provider name is the front of a model ref, not a role. Every `analyser` in the run shares an identical core responsibility. Specialization is additive — it lives in optional Section 6 of the worker output, NOT in differentiated core questions. Cross-verification only converges if every rostered analyser answers the same questions against the same brief.
 
-| Role | Core responsibility | Specialization lens (Section 6 only) | Assignment key | Notes |
-|------|------|------|---------------|------|
-| Lead | orchestration + convergence supervision + final-report review/approval | runtime-specific | -- | Does not author the final report when `Report writer worker` is rostered |
-| Claude worker | Answer every brief question across feasibility, requirement interpretation, hidden assumptions, and alternatives — with file:line evidence | broad reasoning depth, hidden assumptions, execution-risk surfacing | claude-worker | `agents/workers/claude-worker.md` |
-| Codex worker | Same core responsibility as Claude worker — identical questions, identical sections 1–5 | implementation realism, code-path implications, edge cases, technical trade-offs | codex-worker | final prompt composed from the invocation duty and task instructions; CLI execution uses `worker-dispatch` |
-| Antigravity worker | Same core responsibility as Claude worker — identical questions, identical sections 1–5 | requirement interpretation, consistency, safety, alternative viewpoints | antigravity-worker | final prompt composed from the invocation duty and task instructions; CLI execution uses `worker-dispatch` |
-| Report writer worker | **Authors** the final-report file in Phase 6. NOT an analysis worker. | — | report-writer-worker | `agents/workers/report-writer-worker.md`. Excluded from Phase 4/5 and convergence |
+| Canonical role | Core responsibility | Notes |
+|------|------|------|
+| `leader` | orchestration + convergence supervision + final-report review/approval | Does not author the final report when `report-writer` is rostered |
+| `analyser` | Answer every brief question across feasibility, requirement interpretation, hidden assumptions, and alternatives — with file:line evidence | Same sections 1–5 for every model ref |
+| `critic` | Audit coverage gaps or challenge acceptance, per the attached duty | Not an analysis voter |
+| `designer` | Compare or validate implementation directions | Used by `implementation-option-selection` |
+| `planner` | Produce an executable plan without writing the implementation | Used by `implementation-planning` |
+| `implementer` | Sole change author for one approved stage | Used by `implementation` |
+| `verifier` | Independent review of the assigned duty's subject | Duty varies by task type |
+| `report-writer` | **Authors** the final-report file in Phase 6 | Excluded from Phase 4/5 and convergence |
+| `translator` | Translates the designated sidecar only | Phase 7 |
 
-**Model assignment has no default.** The model for every role comes from `resultContract.requiredWorkerRoles[*].modelExecutionValue` in `task-manifest.json` (and lead model metadata). There is no per-role hard-coded fallback — see "Model Assignment Rules" below.
+**Dispatch does not invent a missing model assignment.** Launch-time empty slots are filled by the model default chain before the run starts. At dispatch the model for every role comes from `resultContract.requiredWorkerRoles[*].modelExecutionValue` in `task-manifest.json` (and lead model metadata). There is no per-role hard-coded fallback — see "Model Assignment Rules" below.
 
-**Dispatch-prompt invariant.** Lead's dispatch prompt body for Claude / Codex / Antigravity workers MUST be byte-identical except for the role label and any wrapper-specific path headers (e.g. `**Worktree:**`, `**Errors sidecar path:**`). Lead MUST NOT bias the brief by inserting per-worker emphasis sentences ("you focus on X") into the body. Bias-by-prompt reproduces the historical failure mode where Claude commented only on assumptions, Codex only on code paths, and Antigravity only on requirements — leaving convergence with nothing to converge on.
+**Dispatch-prompt invariant.** Lead's dispatch prompt body for every rostered analysis worker MUST be byte-identical except for the role label and any wrapper-specific path headers (e.g. `**Worktree:**`, `**Errors sidecar path:**`). The role label is the ONLY identity form the normalizer erases, and it erases exactly the label `worker_prompt_body.analysis_worker_label` renders for the run's own worker ids — so a provider outside that function's display map (`grok`, `kimi`, an installed adapter) is covered as it comes. Naming the worker any other way (a model name, a host name, a provider's product name) survives normalization and fails the equality group before publication. **Enforced:** `okstra_ctl.worker_prompt_contract.normalise_analysis_prompt`, pinned by `tests/contract/test_analysis_prompt_identity_normalization.py`. Lead MUST NOT bias the brief by inserting per-worker emphasis sentences ("you focus on X") into the body. Bias-by-prompt reproduces the historical failure mode where Claude commented only on assumptions, Codex only on code paths, and Antigravity only on requirements — leaving convergence with nothing to converge on.
 
 Disjoint initial scopes are invalid triangulation. Every selected analysis worker owns the same common verification requirements; provider diversity supplies independent observations, not separate coverage slices. Do not shard the common scope by worker, provider, or model. Worker-specific depth belongs only in the non-voting Specialization Lens after the shared analysis is complete.
 
@@ -65,7 +69,7 @@ Only workers selected from `recommendedWorkers` in `task-manifest.json` and `res
 
 `okstra_ctl.initial_prompt_materialization` is the canonical owner of roster-derived initial prompt rendering, validation, and immutable publication. Code-backed `dispatch_worker` mappings leave missing roster prompts to `materialize_initial_prompts()` and pass the selected adapter's declared `initialPromptDeliveryMode`; they do not compose or overwrite those prompts themselves. Native in-process dispatch uses the same headers and the adapter's declared `lazy-path-reference` mode, persists the prompt before dispatch, and remains outside reverify and critic handling.
 
-Every worker prompt MUST start with the anchor headers rendered by `okstra_ctl.worker_prompt_headers.worker_prompt_headers()` (the generating SSOT — never hand-author or reorder them). Every persisted initial prompt also carries exactly one non-empty `**Prompt Delivery Mode:** <mode>` header whose value is `eager-include` or `lazy-path-reference`. Redispatch reuses that persisted initial prompt byte-for-byte; it never regenerates or overwrites it. The generated absolute `**Audit sidecar path:**` is derived by `audit_sidecar_rel()` from the canonical worker result path; workers write to that header and never synthesize a `runs/<task-type>/...` destination. Their meaning and extraction rules for workers are documented in the worker preamble §"Anchor headers". Phase-specific extra headers (implementation worktree, final-verification target snapshot, improvement-discovery grilling log) are listed there too.
+Every worker prompt MUST start with the anchor headers rendered by `okstra_ctl.worker_prompt_headers.worker_prompt_headers()` (the generating SSOT — never hand-author or reorder them). Every persisted initial prompt also carries exactly one non-empty `**Prompt Delivery Mode:** <mode>` header whose value is `eager-include` or `lazy-path-reference`. Redispatch reuses that persisted initial prompt byte-for-byte; it never regenerates or overwrites it. The generated absolute `**Audit sidecar path:**` is derived by `audit_sidecar_rel()` from the canonical worker result path; workers write to that header and never synthesize a `runs/<task-type>/...` destination. Their meaning and extraction rules for workers are owned by `okstra_ctl.worker_prompt_headers.worker_prompt_headers()`. Phase-specific extra headers (implementation worktree, final-verification target snapshot, improvement-discovery grilling log) are emitted there too.
 
 The `**Coding preflight pack:**` anchor is emitted only for the `implementation-executor` and `implementation-verifier` audiences. An implementation report-writer never receives it. A pane display role named `verifier` during `final-verification` is still an initial analysis worker; it neither receives implementation conventions nor becomes a Phase 5.5 reverify dispatch. Reverify is identified by the `-reverify-r<N>-` prompt/result path contract in [convergence](./convergence.md).
 
@@ -99,7 +103,7 @@ Audience-scoped file enumeration (performance optimization — mandatory):
 
 | Recipient | Files the lead lists under `## Inputs` |
 |---|---|
-| Claude / Codex / Antigravity analysis workers | `analysis-packet.md` as primary input; for `final-verification`, no source/fallback list is copied into the prompt |
+| Any rostered analysis worker | `analysis-packet.md` as primary input; for `final-verification`, no source/fallback list is copied into the prompt |
 | Report writer worker (Phase 6) | task-brief, analysis-profile, analysis-material, reference-expectations, clarification-response (if carry-in), **plus** the instruction-set-local `final-report-template.md` (phase-stripped) and `final-report-schema.json` (per-task-type excerpt) — NOT the full `templates/reports/...` / `schemas/...` sources |
 | Reverify dispatches | none — the lead provides only the items to reverify |
 
@@ -164,7 +168,7 @@ After each worker attempt returns (regardless of role), Lead MUST verify the can
 - The result file exists but its audit sidecar does not, at `runs/<task-type>/worker-results/<worker>-audit-<task-type>-<seq>.md`. Workers write both in the same step, so a result without a sidecar means the Reading Confirmation block — the only evidence the worker read its inputs — was never produced. `validate-run.py` fails the run on this at Phase 7 either way (`validate_worker_results_audit`); checking it here spends the existing one-retry budget while the role can still be re-dispatched, instead of surfacing hours later when the worker session is gone.
 - `okstra worker-audit-check --run-dir <runs/<task-type>/> --task-type <t> --seq <n> --worker <id>` exits 2 on a backticked `path:line` citation in the worker's result that has no matching Evidence read row in its audit sidecar. Run it the moment you collect each result. Phase 7 enforces the same rules from the same implementation (`okstra_ctl.worker_audit_ledger`), but by then the worker session is gone and the only remaining moves are editing the result yourself — which destroys the audit chain the ledger exists to provide — or ending the run `contract-violated`. While the session is alive, `SendMessage` to the worker so it corrects its own citation; that costs about a minute against a re-dispatch or a failed run.
 
-The same audit check parses command evidence from canonical rows such as `- Evidence command: {"command":"npm run check","cwd":"<project-root>","exitCode":0,"outputSummary":"all checks passed"}`. Workers record only commands that produced or verified a conclusion, not exploratory `rg`, `ls`, or file-opening commands. Environment variable values, tokens, credentials, and authorization headers are excluded. A malformed row or potential sensitive material is a contract failure returned by `okstra_ctl.worker_audit_ledger`; send the failure to the worker while its session is still available.
+The same audit check parses command evidence from canonical rows such as `- Evidence command: {"command":"npm run check","cwd":"<project-root>","exitCode":0,"outputSummary":"all checks passed"}`. Workers record only commands that produced or verified a conclusion, not exploratory `rg`, `ls`, or file-opening commands. A malformed row is a contract failure returned by `okstra_ctl.worker_audit_ledger`; send the failure to the worker while its session is still available. Nothing scans these rows for secrets, so a row is never refused for how a setting is named — `AUTH_MODE=off` and `TOKEN_TTL=60` record verbatim. Do not tell a worker to drop or paraphrase a row on those grounds: a worker that cannot record the command it ran has no way to satisfy the evidence ledger that demands it.
 
 **One-retry policy:**
 

package/runtime/prompts/profiles/_implementation-deliverable.md

@@ -37,7 +37,7 @@ are collected and convergence finished. Phase 1-5 do not need it.
   evidence and add one `recommendedNextSteps` item with environment
   prerequisites and the expected `QA-RESULT`. This is user-owned verification;
   do not route back or fail implementation solely for this advisory.
-- **Routing recommendation for `final-verification`**: brief note on whether the changes are ready for final-verification phase or need a new error-analysis / planning loop first.
+- **Routing recommendation**: `implementation.routingRecommendation` is an **object** with exactly two fields — `target`, one of `final-verification`, `error-analysis`, `implementation-planning`, `implementation`, and `rationale`, one or two sentences on why that target and nothing else. It is not a prose note: Phase 7 projects `workflow.nextRecommendedPhase` from `target` alone, so a phase named only in the prose does not route the task. Pick `final-verification` when this stage's plan items landed and validation passed; `error-analysis` when a failure's cause is not understood; `implementation-planning` when the approved plan itself no longer fits the evidence; `implementation` when work remains inside this stage and the next run is a fix run. **Enforced:** `schemas/final-report-v2.0.schema.json` rejects a `target` outside the enum, a missing `rationale`, and a string in place of the object.
 - **Follow-up tasks (Section 4 of the final report)**: every item discovered during this run that was *not* delivered MUST appear in the final report's `## 4. Follow-up Tasks` table with a concrete `Origin`, `New Task ID`, `Suggested task-type`, `Scope`, and `Reason / Why deferred`. Sources include: out-of-scope discoveries that the executor consciously chose not to fold into this run, verifier concerns the executor declined to fix in-place, scope-boundary items from the approved plan that turned out to need their own ticket, and any unresolved `## 1. Clarification Items` row carried over from the approved plan (`Status` ∈ `{open, answered}` at approval time). An empty section is acceptable but only when expressed as the single line `- No follow-up tasks.` — silence is treated as a contract violation. Rows with `Auto-spawn? = yes` will be materialised by `scripts/okstra-spawn-followups.py` in Phase 7; rows with `Auto-spawn? = no` MUST also appear in `Section 3. Recommended Next Steps` so the user knows to act manually.
 
 ## Self-review pass before finalising the report (the Okstra lead runs this; do not delegate it)

package/runtime/prompts/profiles/_implementation-executor.md

@@ -7,11 +7,8 @@ until Phase 5 ends, then drop from active context for Phase 6/7.
 
 # Implementation profile — Executor sidecar
 
-> **When to read**: lead reads this file ONCE at the start of Phase 5 (after Stage Map parse, before issuing the Executor's first `Edit` / `Write`). The body governs ONLY the Executor role's behaviour. Verifier / report-writer behaviour lives in sibling sidecars.
-
 ## Executor role binding (carried over from the thin core)
 
-- **Executor dispatch labelling.** The core functional role label is `<provider>-executor` (e.g. `codex-executor`). Provider, role, and model identity are owned by `prompts/lead/okstra-lead-contract.md` "Model assignments"; the selected runtime adapter owns provider-native dispatch-label mapping (including any `name` / `**Pane role:**` fields) and token-attribution wiring under its "Semantic operation mapping". This functional label is NOT what the run's PROGRESS checkpoints carry: `phase-4-dispatch` / `phase-5-collect` name the roster role team-state records (`Codex worker`), because that is the entry the Phase 7 conformance check matches them against.
 - The `Executor` (bound in `implementation.md` thin core) is the **only worker permitted to mutate project files**. All other workers run read-only. A `runner=native-session` executor uses the selected host adapter's native edit and command primitives. A `runner=cli-wrapper` executor mutates files inside its provider CLI's auto-edit mode. The safety rules in this sidecar apply identically to both runners.
 - When the thin core's Task worktree block resolves status to `created` or `reused`, the Executor MUST run every Edit / Write / build / test / commit command with the worktree path as cwd. Treat it as `project_root` for the duration of this run. Do NOT mutate the caller's original checkout. Do NOT `cd` out of the worktree to reach files. If a file outside the worktree is genuinely needed, treat it as a planning gap: record it in `Out-of-plan edits` and continue.
   - **How to set the working directory**: every command and native edit MUST target `{{EXECUTOR_WORKTREE_PATH}}`, never the lead session's original project directory. The selected runtime adapter owns the exact native command syntax. Provider CLI wrappers inject the worktree at the CLI layer. For tools that accept an explicit working-directory flag (`git -C <path>`, `cargo --manifest-path`, `pytest --rootdir`), prefer that form.

package/runtime/prompts/profiles/_implementation-verifier.md

@@ -5,14 +5,10 @@ at Phase 5, BEFORE constructing the verifier worker dispatch prompts.
 
 # Implementation profile — Verifier sidecar
 
-> **When to read**: lead reads this file ONCE in Phase 5, between executor stage completion and the first verifier dispatch. Carries the two-tier command lookup, deny-list, discrepancy rule, and verifier-specific forbidden actions.
+## Verifier independence
 
-## Verifier roles (resolved at run-prep time)
-
-- **Verifier dispatch labelling.** The core functional role label is `<provider>-verifier` (here, and identically in `final-verification`). Provider, role, and model identity are owned by `prompts/lead/okstra-lead-contract.md` "Model assignments"; the selected runtime adapter owns provider-native dispatch-label mapping (including any `name` / `**Pane role:**` fields) and token-attribution wiring under its "Semantic operation mapping". This functional label is NOT what the run's PROGRESS checkpoints carry: `phase-4-dispatch` / `phase-5-collect` name the roster role team-state records (`Claude worker`, `Codex worker`), because that is the entry the Phase 7 conformance check matches them against.
-- The verifier slots are `Claude verifier` and `Codex verifier`, plus `Antigravity verifier` **only when `antigravity` is in the resolved `--workers` roster**. Every verifier in the resolved roster is dispatched except the one whose worker ID holds the executor role this run: that ID materializes as the executor on every dispatch (`scripts/okstra_ctl/worker_prompt_policy.py`), so the executor's own provider has no separate verifier session in the current plumbing — a follow-up design item. Independence still holds where it counts: every verdict comes from a fresh CLI session with no shared context, never from the session that wrote the diff. Verifiers MUST NOT call Edit, Write, or any Bash command that mutates files outside the run's artifact directories. If a verifier wants a fix, it records the recommendation in its worker result; it does not apply the fix itself.
-- Session isolation — not model-variant divergence — is the primary self-review safeguard: each verifier is a separate CLI invocation with its own context window, so a verifier reusing the executor's model variant is acceptable. Different model variants (e.g. executor=opus / Claude verifier=sonnet) remain recommended when available.
-- Phase-specific model defaults override the shared defaults: `Claude verifier`=`opus`, `Codex verifier`=`gpt-5.6-sol`, `Antigravity verifier`=`gemini-3.1-pro` (only when present in the roster). The `Executor`'s model is taken from the provider-specific worker model corresponding to `--executor`: claude→`--claude-model` (default `opus`), codex→`--codex-model` (default `gpt-5.6-sol`), antigravity→`--antigravity-model` (default `gemini-3.1-pro`).
+- Every verdict comes from a fresh session with no shared context, never from the session that wrote the diff. Verifiers MUST NOT call Edit, Write, or any Bash command that mutates files outside the run's artifact directories. If a verifier wants a fix, it records the recommendation in its worker result; it does not apply the fix itself.
+- Session isolation is the primary self-review safeguard: each verifier is a separate invocation with its own context window. Reusing the executor's model is acceptable. The model comes from the run's stored assignment.
 - Verifiers read from the SAME working tree path the Executor used so they observe the exact diff the Executor produced. Verifiers remain strictly read-only there.
 
 ## Verifier QA duties (independent re-run mandate)

package/runtime/prompts/profiles/change-impact-analysis.md

@@ -1,5 +1,25 @@
 # Change Impact Analysis Profile
 
+```yaml
+roles:
+  - role: analyser
+    min: 2
+    recommended: 2
+    max: 5
+    duty: analysis-worker
+  - 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: assess the read-only impact of a proposed change, including preserved behavior, affected dependencies, and constraints that a later planning phase must resolve
 - Required workers:
   - claude

package/runtime/prompts/profiles/error-analysis.md

@@ -1,5 +1,30 @@
 # Error Analysis Profile
 
+```yaml
+roles:
+  - role: analyser
+    min: 2
+    recommended: 2
+    max: 5
+    duty: diagnosis-worker
+  - role: critic
+    min: 0
+    recommended: 0
+    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: analyse reported errors or incidents and identify likely causes, missing evidence, and validation paths
 - Required workers:
   - claude
@@ -17,13 +42,14 @@
   - any `intent-inference` augmentation that re-characterises the symptom (e.g. classifying a vague reporter phrase like "it sometimes doesn't work" as "intermittent failure on a specific code path") is a **hypothesis**, not a confirmed symptom. If `[CONFIRMED …]` appears on the matching `intent-check:` row, treat that confirmation as the symptom. Otherwise follow the precondition's `skipped` branch above and keep the inference labelled as a hypothesis in the root-cause analysis.
   - `conversion-block:` rows mean the brief could not map a reporter statement to project vocabulary; never invent the missing mapping in this phase.
 - Worker diagnosis procedure:
+  - **Ticket Tagging.** Tag every section 1–5 item with its related ticket. Use `Issue / Ticket`, fall back to Task ID, then `unknown`; comma-separate multiple tickets.
   - **Symptom lock:** state the reporter's symptom verbatim, then translate it into one observable failure condition. If no observable condition can be derived from the brief, record that gap as the first blocker instead of guessing.
   - **Pass condition lock:** the brief's `EB-NNN` items state what the system must do once the defect is gone. State, per id, the observation that would show the symptom resolved — this is the upper bound on the fix. A diagnosis that leaves "how far do we fix this" open is what lets the later plan expand. Record each as an `endStateCoverage` row whose `coveredBy` names the root-cause candidate or next diagnostic that accounts for it. **Enforced:** `validators/validate-run.py` `_validate_end_state_coverage`.
   - **Reproduction status:** classify the run as `reproduced`, `not-reproduced`, or `blocked-before-repro`. Cite the command/log/file evidence used. If no command can be run safely in this phase, explain the read-only evidence path and the exact material needed next.
   - **Falsifiable cause candidates:** every root-cause candidate must include supporting evidence, the strongest falsifying evidence checked, confidence, and the next diagnostic action that would disprove it. A candidate that cannot be falsified is too vague for this phase.
   - **Graph-aware scope:** a graph edge can explain ordering or duplication, but it is not proof of cause by itself. Cite code/log evidence before claiming an upstream related task caused the current symptom.
   - **Sharp next diagnostic:** end with the single highest-value diagnostic command, log capture, or file inspection that should happen next, plus the expected signal that would confirm or reject the leading cause.
-  - **Fix-design boundary:** do not design the implementation fix beyond what is necessary to validate the cause. If the cause is credible, route to `implementation-option-selection` with the verified evidence; if the cause is still unclear, route to another `error-analysis` run with the next diagnostic.
+  - **Fix-design boundary:** do not design the implementation fix beyond what is necessary to validate the cause. If the cause is credible, recommend `implementation-option-selection` with the verified evidence; if the cause is still unclear, recommend another `error-analysis` run with the next diagnostic. The lead's Phase Routing settles the next phase.
 - Structured diagnosis and routing contract:
   - `errorAnalysis` is the source of truth for reproduction status, `EA-NNN` cause candidates, the sharp next diagnostic, and the next route.
   - A route to `implementation-option-selection` requires a credible leading cause referenced by `routing.leadingCauseId` and `begin-option-selection` as the direction. A route back to `error-analysis` requires the sharp next diagnostic and `continue-investigation` as the direction.

package/runtime/prompts/profiles/feature-analysis.md

@@ -1,5 +1,25 @@
 # Feature Analysis Profile
 
+```yaml
+roles:
+  - role: analyser
+    min: 2
+    recommended: 2
+    max: 5
+    duty: analysis-worker
+  - 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: analyse a confirmed feature target's behavior, rules, state changes, external calls, and test coverage scope without designing or changing an implementation
 - Required workers:
   - claude

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

@@ -1,5 +1,24 @@
 # Final Verification Profile
 
+```yaml
+roles:
+  - role: verifier
+    min: 2
+    recommended: 2
+    max: 5
+    duty: acceptance-verifier
+  - role: critic
+    min: 0
+    recommended: 0
+    max: 1
+    duty: acceptance-critic
+  - role: report-writer
+    min: 1
+    recommended: 1
+    max: 1
+    duty: report-writer
+```
+
 - Purpose: analyse completed work and identify remaining defects, omissions, and delivery risk before final acceptance
 - Required workers:
   - claude
@@ -63,7 +82,7 @@
   - **Validation Evidence**: for every requirement in the originating plan or task brief, cite the artifact (commit SHA, test output, log line, MCP SELECT result) that demonstrates coverage. Paraphrased "verified" claims without an artifact are rejected.
   - **Read-only command log**: any pre-existing test/validation command touched during this run MUST be listed with its exact command line and one honest status — `executed` (ran; carries its exit code) / `advisory` (external Tier 3 did not PASS; carries observed/expected results and remains user-owned) / `env-unavailable` (should run but cannot in this environment — missing replica DB, container, or service; carries the reason, never a faked pass) / `not-configured` (no such qa-command tier) / `rejected` (a mutating/denied token — skipped, carries the denied token). A check that could not run locally is recorded as `env-unavailable` or `advisory` according to the external QA policy — never silently dropped and never reported as `executed` with an invented exit code. Mutating-command prohibition is the shared read-only boundary (see Non-goals); it is not restated per row.
   - **Could-not-verify roll-up (§5.8.9)**: the template mechanically aggregates every not-confirmed check into one scannable list — `gap` requirement-coverage rows, `advisory` / `not-configured` / `env-unavailable` / `rejected` command rows, and `blocked` manual tests. You do not hand-author it, but you MUST give those rows their honest status so nothing unverified hides across sections: a check silently recorded as `executed`/`covered` will not surface in the roll-up. This is okstra's answer to "say what could not be verified this run."
-  - **Routing recommendation**: the next safe phase — one of `release-handoff`, `done`, `error-analysis`, `implementation-option-selection`, `implementation-planning` — tied to the verdict and blocker list. `release-handoff` is allowed ONLY when the Verdict Token is `accepted`. `release-handoff` is additionally allowed ONLY when the verification scope (the `Verification scope:` line of the injected `VERIFICATION_TARGET` block, recorded as the report's `verificationScope` field) is `whole-task`; a `single-stage` accepted run routes to `release-handoff(stage-group)` (or `implementation` / `done`); plain `release-handoff` remains whole-task-only. Enforcement: `validators/validate-run.py` rejects a `single-stage` report whose routing cites plain `release-handoff`.
+  - **Routing recommendation**: `finalVerification.routingRecommendation` is an **object** with exactly two fields — `target`, one value of the enum below, and `rationale`, the sentence tying that choice to the verdict and the blocker list. Free routing prose is not the field; a target named only in the prose does not route the task, because Phase 7 projects `workflow.nextRecommendedPhase` from `target` alone. The seven allowed targets are `release-handoff`, `release-handoff(stage-group)`, `error-analysis`, `implementation-option-selection`, `implementation-planning`, `implementation`, and `done`. Both `release-handoff` forms are allowed ONLY when the Verdict Token is `accepted`. Plain `release-handoff` is additionally allowed ONLY when the verification scope (the `Verification scope:` line of the injected `VERIFICATION_TARGET` block, recorded as the report's `verificationScope` field) is `whole-task`; a `single-stage` accepted run routes to `release-handoff(stage-group)` (or `implementation` / `done`) instead. `done` ends the lifecycle here. Enforcement: `schemas/final-report-v2.0.schema.json` rejects a `target` outside the enum, a missing `rationale`, and a string in place of the object; `validators/validate-run.py` rejects a missing `target`, a non-`accepted` verdict routed to either `release-handoff` form, and a `single-stage` report whose routing cites plain `release-handoff`.
   - **Verified-row recording** (single-stage scope only): when the Verdict Token is `accepted`, the lead MUST run `okstra handoff record-verified --plan-run-root <plan-run-root> --stage <N> --report-path <final-report.md path> --data-json <final-report data.json path>` and quote the command + exit code in the report. The helper re-validates taskType/scope/verdict from data.json, so a non-accepted or whole-task report is rejected at the tool layer. **Enforced:** `validators/validate-run.py` `_validate_verified_row_recorded` requires a `verified` row in `runs/implementation-planning/consumers.jsonl` for every accepted stage — the helper validated its own inputs but nothing checked it had ever run, leaving reports that said `accepted` while the registry said unverified, so the stage was never offered for a stage-group PR.
 - Clarification request policy (phase-specific addendum — shared policy is in `_common-contract.md`):
   - populate `## 1. Clarification Items` only when a blocker hinges on information only the user can supply (deployment intent, intended target environment, business-rule interpretation); use `Blocks=next-phase` for items that gate continuing to release-handoff

package/runtime/prompts/profiles/implementation-option-selection.md

@@ -1,5 +1,25 @@
 # Implementation Option Selection Profile
 
+```yaml
+roles:
+  - role: designer
+    min: 3
+    recommended: 3
+    max: 5
+    duty: direction-selection-worker
+  - 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: compare feasible implementation directions before planning, preserving a read-only record of the evidence and trade-offs that selects the direction to plan
 - Required workers:
   - claude

package/runtime/prompts/profiles/implementation-planning.md

@@ -1,5 +1,30 @@
 # Implementation Planning Profile
 
+```yaml
+roles:
+  - role: planner
+    min: 2
+    recommended: 2
+    max: 5
+    duty: planning-worker
+  - role: critic
+    min: 0
+    recommended: 0
+    max: 1
+    duty: acceptance-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: turn an upstream-selected direction into an executable plan; legacy reruns may retain candidate comparison
 - Required workers:
   - claude
@@ -16,6 +41,7 @@
   - never plan around an unconfirmed `intent-inference` augmentation as if it were a settled requirement. Treat the inference as settled ONLY when a `[CONFIRMED …]` marker sits on the matching `intent-check:` row after the precondition runs; absent the marker it stays a `Blocks=approval` clarification item per the precondition's `skipped` branch.
   - `conversion-block:` rows are handled by the precondition; planning around an untranslated reporter phrase is forbidden until it is resolved.
 - Worker planning procedure:
+  - **Ticket Tagging.** Tag every section 1–5 item with its related ticket. Use `Issue / Ticket`, fall back to Task ID, then `unknown`; comma-separate multiple tickets.
   - route by the planning input contract before analysis. A run carrying `selected-direction.json` uses the selected-direction procedure. Only a legacy rerun without that snapshot uses candidate comparison.
   - **Selected-direction planning procedure** — perform these steps in order and no others:
     1. Read `selected-direction.json` and the original requirements ledger end-to-end.

package/runtime/prompts/profiles/implementation.md

@@ -1,5 +1,24 @@
 # Implementation Profile
 
+```yaml
+roles:
+  - role: implementer
+    min: 1
+    recommended: 1
+    max: 1
+    duty: implementation-executor
+  - role: verifier
+    min: 2
+    recommended: 2
+    max: 3
+    duty: implementation-verifier
+  - role: report-writer
+    min: 1
+    recommended: 1
+    max: 1
+    duty: report-writer
+```
+
 - Purpose: realise the approved `implementation-planning` deliverable as actual source changes, with cross-model verification, while keeping the run reversible
 - **Run-level fixed cost:** the verifier set, Phase 5.5 convergence, and the Phase 6 report-writer run exactly once per implementation run, over this run's single stage diff — never once per step.
 - **Fix run (profile carries a "Fix-Run Carry" block):** the executor's scope is the carried blocking findings plus the previous routing recommendation — it MUST NOT re-execute plan steps the previous run completed. Verifiers apply the "Fix-run incremental scope" section of `_implementation-verifier.md`; the report writer applies "Fix-run incremental authoring" in `report-writer.md`. The full validation-command re-run is NOT reduced.

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

@@ -1,5 +1,25 @@
 # Improvement Discovery Profile
 
+```yaml
+roles:
+  - role: analyser
+    min: 3
+    recommended: 3
+    max: 5
+    duty: discovery-worker
+  - 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: scan a codebase scope through a fixed lens whitelist and surface ranked improvement candidates with multi-worker consensus classification
 - Required workers:
   - claude
@@ -41,7 +61,7 @@
   - Stop conditions (OR): all questions resolved / budget exhausted / user signals proceed.
   - Lead persists the round at `<RUN_DIR>/state/phase-1.5-grilling.md` with one section per question (question / recommended / user answer) and a closing `Resolved scope` / `Resolved lenses` block. Worker prompts use this resolved block as the authoritative scope and lens definition.
   - The same log includes `## Primary Pass Assignments` with a `Worker ID | Primary lens` table. It contains every selected analyser exactly once in `requiredWorkerRoles` order; the lead derives it from the resolved roster and lenses rather than provider catalog order.
-  - After writing the log and before Phase 4 dispatch, the lead injects its **absolute path** into every analyser prompt as the `**Phase 1.5 Grilling Log:** <absolute-path>` anchor header (see `templates/worker-prompt-preamble.md` §"Anchor headers"). This is the improvement-discovery counterpart to the `**Worktree:**` / `**Verification …:**` anchors that implementation / final-verification inject: workers read the log from this explicit path rather than re-deriving `<RUN_DIR>`. The path is byte-identical across all analysers, so it does not break the dispatch-prompt invariant.
+  - After writing the log and before Phase 4 dispatch, the lead injects its **absolute path** into every analyser prompt as the `**Phase 1.5 Grilling Log:** <absolute-path>` anchor header (see `okstra_ctl.worker_prompt_headers.worker_prompt_headers()`). This is the improvement-discovery counterpart to the `**Worktree:**` / `**Verification …:**` anchors that implementation / final-verification inject: workers read the log from this explicit path rather than re-deriving `<RUN_DIR>`. The path is byte-identical across all analysers, so it does not break the dispatch-prompt invariant.
 - Decision-tree walk (bounded):
   - When candidates branch on a structural question (e.g. "is module X meant to own this responsibility?"), resolve via `Read` / `Grep` first. Only escalate to the user inside the Phase 1.5 budget.
 - Expected output emphasis:

package/runtime/prompts/profiles/project-analysis.md

@@ -1,5 +1,25 @@
 # Project Analysis Profile
 
+```yaml
+roles:
+  - role: analyser
+    min: 2
+    recommended: 2
+    max: 5
+    duty: analysis-worker
+  - 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: map a bounded project area so later work can navigate components, dependencies, entry points, repositories, and external integrations without changing the source
 - Required workers:
   - claude

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

@@ -1,5 +1,9 @@
 # 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.

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

@@ -1,5 +1,30 @@
 # Requirements Discovery Profile
 
+```yaml
+roles:
+  - role: analyser
+    min: 2
+    recommended: 2
+    max: 5
+    duty: discovery-worker
+  - role: critic
+    min: 0
+    recommended: 0
+    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
@@ -17,7 +42,8 @@
   - `intent-inference` augmentations whose paired `intent-check:` row carries `[CONFIRMED …]` are treated as **confirmed**; trust the confirmation text in `## Reporter Confirmations` over the original inference if they differ. Unconfirmed `intent-inference` rows under `reporter-confirmations: skipped` follow the precondition's `skipped` branch above.
   - `conversion-block:` rows are explicit "translation failed" signals — never attempt to resolve them by inference here; the precondition above already handled them.
 - Worker discovery procedure:
-  - classify the request and cite the evidence that determines both its work category and safest next phase
+  - **Ticket Tagging.** Tag every section 1–5 item with its related ticket. Use `Issue / Ticket`, fall back to Task ID, then `unknown`; comma-separate multiple tickets.
+  - classify the request and cite the evidence that supports a recommended work category and safest next phase. The lead's Phase Routing settles the next phase.
   - identify independently startable decomposition candidates without publishing or rendering fan-out artifacts; preserve every directed dependency from `Related Task Graph`
   - resolve codebase-answerable ambiguity by inspection and record file:line evidence; return only human-owned decisions as clarification candidates with the evidence already checked
   - state the reporter's rejection criteria, missing routing inputs, and the evidence boundary behind each recommendation

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

@@ -480,6 +480,39 @@
         "no": "아니오 — 단계별로 다시 입력"
       }
     },
+    "leader_session": {
+      "label": "리더는 현재 세션 모델을 씁니다 (읽기 전용): {model_ref}{effort_suffix}",
+      "echo_template": "leader-session: {value}",
+      "options": {
+        "continue": "계속"
+      },
+      "effort_suffix": " · effort {effort}"
+    },
+    "role_count": {
+      "label": "{role} 역할 인스턴스 수를 선택하세요 ({minimum}..{maximum}, 적정 {default})",
+      "echo_template": "role-count: {value}",
+      "options": {
+        "count": "{count}개{default_suffix}",
+        "default_suffix": " (적정)"
+      }
+    },
+    "role_add": {
+      "label": "선택 역할 {role} 을(를) 이번 run 에 추가할까요? (최대 {maximum}개, 기본: 추가 안 함)",
+      "echo_template": "role-add: {value}",
+      "options": {
+        "skip": "추가 안 함{default_suffix}",
+        "add": "{count}개 추가",
+        "default_suffix": " (기본)"
+      }
+    },
+    "role_model": {
+      "label": "{role} 역할 {ordinal}/{count} 인스턴스의 모델을 선택하세요",
+      "echo_template": "role-model: {value}",
+      "options": {
+        "model": "{model_ref} — {display}{default_suffix}",
+        "default_suffix": " (기본 후보)"
+      }
+    },
     "defaults_or_custom": {
       "label": "역할별 모델 선택 단계입니다 (참여 워커 구성을 바꾸는 게 아닙니다).\n이번 run 에서 모델을 고를 역할:\n{role_models}\n· 기본값으로 진행 — 위 추천 모델을 그대로 쓰고, directive·관련 task 없이 바로 넘어갑니다.\n· 커스터마이즈 — 위 역할별 모델을 직접 고르고, 추가 directive·관련 task 도 지정합니다.\n(추천 값은 runtime 기본값으로 해소됩니다. 분석에 참여하지 않는 역할은 위 목록에 나오지 않습니다 — 예: antigravity 는 implementation 의 executor 로 선택했을 때만 표시됩니다.)",
       "echo_template": "customize: {value}",
@@ -587,6 +620,8 @@
   },
   "confirmation": {
     "header": "선택 확인:",
+    "static_role": "  static-role   : {role}#{ordinal} / {model}",
+    "dynamic_role": "  dynamic-role  : {role} / reuse selected participant model",
     "workers_implementation_default": "  workers       : (프로필 기본 — executor + verifier 2 + report-writer)",
     "base_ref_stage_isolated": "  base-ref      : (stage 격리 — 의존 stage 기준으로 run 준비 시점에 자동 해소)",
     "base_ref_reuse_task_dir": "  base-ref      : (기존 `{task_key}` 디렉터리 재사용 — 최초 base 유지)",

package/runtime/python/okstra_ctl/adapters/dispatch/cli_wrapper.py

@@ -4,6 +4,7 @@ from __future__ import annotations
 from collections.abc import Mapping
 
 from ... import dispatch_core
+from ...domain.worker_exec import WorkerWriteCapability
 from ...ports.worker_dispatch import WorkerDispatchPlan, WorkerDispatchRequest
 
 
@@ -17,6 +18,9 @@ class CliWrapperDispatchPort:
         default_backend: str = dispatch_core.BACKEND_CLI_WRAPPER,
         cli_wrapper_assignments_only: bool = False,
         default_provider_by_worker_id: Mapping[str, str] | None = None,
+        worker_write_capability: WorkerWriteCapability = WorkerWriteCapability(
+            "none"
+        ),
     ) -> None:
         self._supported_worker_wrappers = supported_worker_wrappers or {}
         self._unsupported_worker_label = unsupported_worker_label
@@ -26,6 +30,7 @@ class CliWrapperDispatchPort:
         self._default_provider_by_worker_id = dict(
             default_provider_by_worker_id or {}
         )
+        self._worker_write_capability = worker_write_capability
 
     def build_plan(self, request: WorkerDispatchRequest) -> WorkerDispatchPlan:
         backend_plan = None
@@ -52,3 +57,6 @@ class CliWrapperDispatchPort:
             backend_plan=backend_plan,
             dispatch_mode="render-only",
         )
+
+    def worker_write_capability(self) -> WorkerWriteCapability:
+        return self._worker_write_capability

package/runtime/python/okstra_ctl/adapters/dispatch/cmux.py

@@ -4,6 +4,7 @@ from __future__ import annotations
 from collections.abc import Mapping
 
 from ... import dispatch_core
+from ...domain.worker_exec import WorkerWriteCapability
 from ...ports.worker_dispatch import (
     WorkerDispatchPlan,
     WorkerDispatchPort,
@@ -25,6 +26,9 @@ class CmuxDispatchPort:
         required_lead_runtime: str | None = None,
         cli_wrapper_assignments_only: bool = False,
         default_provider_by_worker_id: Mapping[str, str] | None = None,
+        worker_write_capability: WorkerWriteCapability = WorkerWriteCapability(
+            "none"
+        ),
     ) -> None:
         self._backend_port = CliWrapperDispatchPort(
             supported_worker_wrappers=supported_worker_wrappers,
@@ -33,6 +37,7 @@ class CmuxDispatchPort:
             default_backend=dispatch_core.BACKEND_CMUX_PANE,
             cli_wrapper_assignments_only=cli_wrapper_assignments_only,
             default_provider_by_worker_id=default_provider_by_worker_id,
+            worker_write_capability=worker_write_capability,
         )
 
     def build_plan(self, request: WorkerDispatchRequest) -> WorkerDispatchPlan:
@@ -46,6 +51,9 @@ class CmuxDispatchPort:
             relay_contract=CMUX_RELAY_CONTRACT,
         )
 
+    def worker_write_capability(self) -> WorkerWriteCapability:
+        return self._backend_port.worker_write_capability()
+
 
 def dispatch_port_for_terminal_backend(
     terminal_backend: str,

package/runtime/python/okstra_ctl/adapters/dispatch/native_team.py

@@ -1,13 +1,26 @@
 """Native host-team dispatch planning."""
 from __future__ import annotations
 
+from ...domain.worker_exec import WorkerWriteCapability
 from ...ports.worker_dispatch import WorkerDispatchPlan, WorkerDispatchRequest
 
 
 class NativeTeamDispatchPort:
+    def __init__(
+        self,
+        *,
+        worker_write_capability: WorkerWriteCapability = WorkerWriteCapability(
+            "none"
+        ),
+    ) -> None:
+        self._worker_write_capability = worker_write_capability
+
     def build_plan(self, request: WorkerDispatchRequest) -> WorkerDispatchPlan:
         return WorkerDispatchPlan(
             mode="native-team",
             request=request,
             dispatch_mode="team",
         )
+
+    def worker_write_capability(self) -> WorkerWriteCapability:
+        return self._worker_write_capability