okstra 0.82.0 → 0.83.0

package/runtime/agents/workers/codex-worker.md

@@ -69,7 +69,7 @@ The wrapper exists because Claude Code's Bash permission matcher rejects simple-
    - First, look for a `**Model:** Codex worker, <execution-value>` line in the lead prompt and use `<execution-value>`.
    - If only a display model is listed, look up the canonical execution value from the referenced task bundle metadata (`task-manifest.json` → `resultContract.requiredWorkerRoles[]` for the codex role).
    - If no assigned model execution value can be determined, immediately return `CODEX_MODEL_MISSING: assigned Codex model execution value was not provided`. Do NOT fall back to training-data defaults — historical Codex defaults like `o4-mini` are NOT acceptable substitutes for the assigned model. Returning the sentinel is the correct behavior; the lead is responsible for fixing its prompt and redispatching.
-   - This rule applies equally to convergence reverify rounds. The reverify prompt MUST carry the same `**Model:**` line as the initial run (see `okstra-convergence` skill, "Required reverify-prompt anchor headers"). If the line is absent in a reverify prompt, return `CODEX_MODEL_MISSING` rather than guessing.
+   - This rule applies equally to convergence reverify rounds. The reverify prompt MUST carry the same `**Model:**` line as the initial run (see the convergence resource at `prompts/lead/convergence.md`, "Required reverify-prompt anchor headers"). If the line is absent in a reverify prompt, return `CODEX_MODEL_MISSING` rather than guessing.
 
 7. If installed, dispatch the wrapper as a **background** Bash command and poll for completion. The two-minute foreground Bash timeout is insufficient for implementation-phase Codex runs and forced workers into ad-hoc background dispatch with lost output. The polling contract below is the formal replacement.
 
@@ -91,7 +91,7 @@ The wrapper exists because Claude Code's Bash permission matcher rejects simple-
         - Otherwise (mtime stale `> 90s`, OR grace already applied): call `KillShell(shell_id: <shell_id>)`, then record a `cli-failure` event with `--error-type cli-failure`, `--exit-code 124`, `--duration-ms <observed_ms>`, `--message "okstra-codex-exec.sh exceeded polling cap (grace=<applied|not-applied>, last_mtime_age=<n>s)"`, and return `CODEX_CLI_TIMEOUT: codex exec exceeded polling cap`.
      4. Otherwise continue polling. Read `current_ts` cheaply via another `Bash` call (`date +%s`) at most once per poll iteration.
    - Do NOT abort the loop on transient `running` status. Only `completed` or the polling cap (initially 30min, optionally extended once to 35min by mtime grace) end it.
-   - **No external timeout from Lead.** This polling loop is the SINGLE timeout authority for this dispatch. Lead MUST NOT impose a separate Agent-call timeout that would terminate this subagent before the polling cap is reached (see okstra-team-contract "No external timeout on wrapper subagents").
+   - **No external timeout from Lead.** This polling loop is the SINGLE timeout authority for this dispatch. Lead MUST NOT impose a separate Agent-call timeout that would terminate this subagent before the polling cap is reached (see team-contract "No external timeout on wrapper subagents").
    - Do NOT issue parallel `BashOutput` calls or speculate about progress between polls.
    - **No standalone `sleep` between polls.** The harness blocks `sleep` calls of 5 seconds or longer as a circumvention vector and explicitly forbids chaining shorter sleeps to work around it. `BashOutput` itself is the wait primitive — calling it again immediately after a `running` status is correct. If you find yourself wanting to "slow down" the loop, that desire is a leftover from the retired 60-second-cadence rule and should be ignored.
 
@@ -104,7 +104,7 @@ The wrapper exists because Claude Code's Bash permission matcher rejects simple-
    c. **Result-file existence check (exit 0 only).** If `exit_code == 0` BUT no file exists at the extracted Result Path, the Codex CLI returned 0 without producing the analysis artifact. Observed failure mode: the CLI streams analysis prose on stdout, hits its token budget or a sandbox EPERM mid-`Write`, and exits 0 with the artifact never persisted. Forwarding the partial stdout silently degrades lead synthesis (the case that motivated this rule), so this path is required.
       1. Capture the final ~10 lines of the wrapper's live log for diagnostics — single Bash call: `tail -n 10 "${prompt_path%.md}.log"` (substitute the literal absolute prompt-history path; the wrapper writes the log next to it per the §"trace pane" comment in `okstra-codex-exec.sh`). Write the captured lines to a temp file (e.g. `<errors-sidecar-dir>/codex-result-missing-tail.txt`) so `--stderr-excerpt-file` can reference it.
       2. Record a `cli-failure` event directly to the run-level error log via the exact `okstra error-log append-observed` template in §"Error reporting" — substitute `--exit-code 0`, `--duration-ms <observed-ms>`, `--message "okstra-codex-exec.sh exited 0 but no result file at <abs-path>"`, and `--stderr-excerpt-file <temp-tail-path>`.
-      3. Return `CODEX_RESULT_MISSING: codex exited 0 but result file absent at <abs-path>` instead of the raw stdout. The lead is responsible for deciding redispatch per `okstra-team-contract` "Lead Redispatch Policy on Result-Missing".
+      3. Return `CODEX_RESULT_MISSING: codex exited 0 but result file absent at <abs-path>` instead of the raw stdout. The lead is responsible for deciding redispatch per `team-contract` "Lead Redispatch Policy on Result-Missing".
 
    d. **Normal return.** Otherwise (`exit_code == 0` AND result file exists), return the wrapper's accumulated stdout from `BashOutput`, prefixed by exactly one model-identity line copied verbatim from the `**Model:** Codex worker, <execution-value>` line in the lead prompt (per Worker Preamble → "Return message to the lead"):
       ```
@@ -156,7 +156,7 @@ The CLI writes a Reading Confirmation block to the **audit sidecar** at `runs/<t
 
 When returning results, start the file with a YAML frontmatter block, then organize the body into the following sections in this exact order.
 
-**Frontmatter (mandatory)** — set `workerId: "codex"`. Copy `id`, `aliases`, `taskType`, `task-id`, `task-group`, `project-id`, `date` verbatim from the primary input (`analysis-packet.md`; fall back to `analysis-material.md` only if the packet is missing a field). Full schema and a concrete example live in the `okstra-team-contract` skill's "Result Frontmatter" subsection.
+**Frontmatter (mandatory)** — set `workerId: "codex"`. Copy `id`, `aliases`, `taskType`, `task-id`, `task-group`, `project-id`, `date` verbatim from the primary input (`analysis-packet.md`; fall back to `analysis-material.md` only if the packet is missing a field). Full schema and a concrete example live in the team-contract resource (`prompts/lead/team-contract.md`) "Result Frontmatter" subsection.
 
 1. **Findings** - what Codex identified
 2. **Missing Information or Assumptions** - gaps in the analysis
@@ -168,9 +168,9 @@ Include file paths and line numbers when discussing code evidence.
 
 **Item IDs (mandatory).** Every row in sections 1–5 (and any optional section 6) MUST carry a worker-internal item ID unique within this file. Codex tends to use hierarchical numbering (`1.1`, `1.2`, `1.3`, ...); that shape is fine — keep what's natural. What matters is that each item is addressable. The lead's §6.1 / §6.2 / §2.1 synthesis preserves these IDs as `codex:<your-id>` entries in its `Source items (worker:item)` column. See `prompts/profiles/_common-contract.md` "Cross-worker traceability" SSOT.
 
-**Ticket tagging:** For runs whose task type is `requirements-discovery`, `error-analysis`, `implementation-planning`, or `implementation`, every item in sections 1–5 MUST carry a ticket identifier. Use the `Ticket ID` column in table-form items and the `[TICKETID: <id>]` prefix in bullet/numbered items. Fill priority: `Issue / Ticket` from the input → `Task ID` (no prefix, e.g. `8852`) → `unknown`. Multiple tickets are comma-separated. Full rules live in the `okstra-team-contract` skill's Ticket Tagging section.
+**Ticket tagging:** For runs whose task type is `requirements-discovery`, `error-analysis`, `implementation-planning`, or `implementation`, every item in sections 1–5 MUST carry a ticket identifier. Use the `Ticket ID` column in table-form items and the `[TICKETID: <id>]` prefix in bullet/numbered items. Fill priority: `Issue / Ticket` from the input → `Task ID` (no prefix, e.g. `8852`) → `unknown`. Multiple tickets are comma-separated. Full rules live in the team-contract resource (`prompts/lead/team-contract.md`) Ticket Tagging section.
 
-This contract mirrors the `okstra-team-contract` skill's Worker Output Contract — that skill is the authoritative source if the two ever diverge.
+This contract mirrors the team-contract resource (`prompts/lead/team-contract.md`) Worker Output Contract — that resource is the authoritative source if the two ever diverge.
 
 ## Error reporting
 
@@ -195,7 +195,7 @@ and the run-level error log staying empty.
    extracted from the `**Errors sidecar path:**` header. If the file does
    not exist, create it with `{"schemaVersion": 1, "errors": []}` then
    append. The sidecar follows the schema in
-   `skills/okstra-team-contract/SKILL.md` (Optional errors sidecar). Lead
+   `prompts/lead/team-contract.md` (Optional errors sidecar). Lead
    will dump it to the run error log after this subagent terminates.
 
 2. **CLI failure (lead-observed)** — if the wrapper's final `BashOutput`
@@ -234,7 +234,7 @@ pre-flight terminal status, not a runtime CLI error.
 - Ignore stderr warnings from MCP integration.
 - Return error messages as-is on failure.
 - Do not summarize or modify Codex results beyond prepending the single `**Model:**` line on a normal return (step 8d).
-- Sections 1–5 of the worker output are the common core shared with the Claude and Gemini workers — the dispatched prompt asks identical questions for all three roles, and the Codex CLI must answer all of them, not only implementation-feasibility findings. Your specialization (implementation realism, code-path implications, edge cases, technical trade-offs) belongs only in optional Section 6 as additive depth. A Codex result whose Findings section is populated solely with implementation-feasibility items is in breach of contract; see `skills/okstra-team-contract/SKILL.md` "Worker Output Contract".
+- Sections 1–5 of the worker output are the common core shared with the Claude and Gemini workers — the dispatched prompt asks identical questions for all three roles, and the Codex CLI must answer all of them, not only implementation-feasibility findings. Your specialization (implementation realism, code-path implications, edge cases, technical trade-offs) belongs only in optional Section 6 as additive depth. A Codex result whose Findings section is populated solely with implementation-feasibility items is in breach of contract; see `prompts/lead/team-contract.md` "Worker Output Contract".
 
 ## Stage evidence emission (BLOCKING, implementation task only)
 

package/runtime/agents/workers/gemini-worker.md

@@ -69,7 +69,7 @@ The wrapper exists because Claude Code's Bash permission matcher rejects simple-
    - First, use the value explicitly assigned in the lead prompt.
    - If the lead prompt only lists the display model, use the canonical execution value from the referenced task bundle metadata (`task-manifest.json` → `resultContract.requiredWorkerRoles[]` for the gemini role).
    - If no assigned model execution value can be determined, immediately return `GEMINI_MODEL_MISSING: assigned Gemini model execution value was not provided`. Do NOT fall back to training-data defaults — historical Gemini defaults like `gemini-1.5-flash` are NOT acceptable substitutes for the assigned model. Returning the sentinel is the correct behavior; the lead is responsible for fixing its prompt and redispatching.
-   - This rule applies equally to convergence reverify rounds. The reverify prompt MUST carry the same `**Model:**` line as the initial run (see `okstra-convergence` skill, "Required reverify-prompt anchor headers"). If the line is absent in a reverify prompt, return `GEMINI_MODEL_MISSING` rather than guessing.
+   - This rule applies equally to convergence reverify rounds. The reverify prompt MUST carry the same `**Model:**` line as the initial run (see the convergence resource at `prompts/lead/convergence.md`, "Required reverify-prompt anchor headers"). If the line is absent in a reverify prompt, return `GEMINI_MODEL_MISSING` rather than guessing.
 
 7. If installed, dispatch the wrapper as a **background** Bash command and poll for completion. The two-minute foreground Bash timeout is insufficient for implementation-phase Gemini runs and forced workers into ad-hoc background dispatch with lost output. The polling contract below is the formal replacement.
 
@@ -91,7 +91,7 @@ The wrapper exists because Claude Code's Bash permission matcher rejects simple-
         - Otherwise (mtime stale `> 90s`, OR grace already applied): call `KillShell(shell_id: <shell_id>)`, then record a `cli-failure` event with `--error-type cli-failure`, `--exit-code 124`, `--duration-ms <observed_ms>`, `--message "okstra-gemini-exec.sh exceeded polling cap (grace=<applied|not-applied>, last_mtime_age=<n>s)"`, and return `GEMINI_CLI_TIMEOUT: gemini exec exceeded polling cap`.
      4. Otherwise continue polling. Read `current_ts` cheaply via another `Bash` call (`date +%s`) at most once per poll iteration.
    - Do NOT abort the loop on transient `running` status. Only `completed` or the polling cap (initially 30min, optionally extended once to 35min by mtime grace) end it.
-   - **No external timeout from Lead.** This polling loop is the SINGLE timeout authority for this dispatch. Lead MUST NOT impose a separate Agent-call timeout that would terminate this subagent before the polling cap is reached (see okstra-team-contract "No external timeout on wrapper subagents").
+   - **No external timeout from Lead.** This polling loop is the SINGLE timeout authority for this dispatch. Lead MUST NOT impose a separate Agent-call timeout that would terminate this subagent before the polling cap is reached (see team-contract "No external timeout on wrapper subagents").
    - Do NOT issue parallel `BashOutput` calls or speculate about progress between polls.
    - **No standalone `sleep` between polls.** The harness blocks `sleep` calls of 5 seconds or longer as a circumvention vector and explicitly forbids chaining shorter sleeps to work around it. `BashOutput` itself is the wait primitive — calling it again immediately after a `running` status is correct. If you find yourself wanting to "slow down" the loop, that desire is a leftover from the retired 60-second-cadence rule and should be ignored.
 
@@ -104,7 +104,7 @@ The wrapper exists because Claude Code's Bash permission matcher rejects simple-
    c. **Result-file existence check (exit 0 only).** If `exit_code == 0` BUT no file exists at the extracted Result Path, the Gemini CLI returned 0 without producing the analysis artifact. Observed failure mode: the CLI streams analysis prose on stdout, hits its token budget or a sandbox EPERM mid-`Write`, and exits 0 with the artifact never persisted. Forwarding the partial stdout silently degrades lead synthesis (the case that motivated this rule), so this path is required.
       1. Capture the final ~10 lines of the wrapper's live log for diagnostics — single Bash call: `tail -n 10 "${prompt_path%.md}.log"` (substitute the literal absolute prompt-history path; the wrapper writes the log next to it per the §"trace pane" comment in `okstra-gemini-exec.sh`). Write the captured lines to a temp file (e.g. `<errors-sidecar-dir>/gemini-result-missing-tail.txt`) so `--stderr-excerpt-file` can reference it.
       2. Record a `cli-failure` event directly to the run-level error log via the exact `okstra error-log append-observed` template in §"Error reporting" — substitute `--exit-code 0`, `--duration-ms <observed-ms>`, `--message "okstra-gemini-exec.sh exited 0 but no result file at <abs-path>"`, and `--stderr-excerpt-file <temp-tail-path>`.
-      3. Return `GEMINI_RESULT_MISSING: gemini exited 0 but result file absent at <abs-path>` instead of the raw stdout. The lead is responsible for deciding redispatch per `okstra-team-contract` "Lead Redispatch Policy on Result-Missing".
+      3. Return `GEMINI_RESULT_MISSING: gemini exited 0 but result file absent at <abs-path>` instead of the raw stdout. The lead is responsible for deciding redispatch per `team-contract` "Lead Redispatch Policy on Result-Missing".
 
    d. **Normal return.** Otherwise (`exit_code == 0` AND result file exists), return the wrapper's accumulated stdout from `BashOutput`, prefixed by exactly one model-identity line copied verbatim from the `**Model:** Gemini worker, <execution-value>` line in the lead prompt (per Worker Preamble → "Return message to the lead"):
       ```
@@ -156,7 +156,7 @@ The CLI writes a Reading Confirmation block to the **audit sidecar** at `runs/<t
 
 When returning results, start the file with a YAML frontmatter block, then organize the body into the following sections in this exact order.
 
-**Frontmatter (mandatory)** — set `workerId: "gemini"`. Copy `id`, `aliases`, `taskType`, `task-id`, `task-group`, `project-id`, `date` verbatim from the primary input (`analysis-packet.md`; fall back to `analysis-material.md` only if the packet is missing a field). Full schema and a concrete example live in the `okstra-team-contract` skill's "Result Frontmatter" subsection.
+**Frontmatter (mandatory)** — set `workerId: "gemini"`. Copy `id`, `aliases`, `taskType`, `task-id`, `task-group`, `project-id`, `date` verbatim from the primary input (`analysis-packet.md`; fall back to `analysis-material.md` only if the packet is missing a field). Full schema and a concrete example live in the team-contract resource (`prompts/lead/team-contract.md`) "Result Frontmatter" subsection.
 
 1. **Findings** - what Gemini identified
 2. **Missing Information or Assumptions** - gaps in the analysis
@@ -168,9 +168,9 @@ Include file paths and line numbers when discussing code evidence.
 
 **Item IDs (mandatory).** Every row in sections 1–5 (and any optional section 6) MUST carry a worker-internal item ID unique within this file. Gemini may use `F-1`, `F-2`, ... or numbered hierarchical IDs — either is fine. What matters is that each item is addressable. The lead's §6.1 / §6.2 / §2.1 synthesis preserves these IDs as `gemini:<your-id>` entries in its `Source items (worker:item)` column. See `prompts/profiles/_common-contract.md` "Cross-worker traceability" SSOT.
 
-**Ticket tagging:** For runs whose task type is `requirements-discovery`, `error-analysis`, `implementation-planning`, or `implementation`, every item in sections 1–5 MUST carry a ticket identifier. Use the `Ticket ID` column in table-form items and the `[TICKETID: <id>]` prefix in bullet/numbered items. Fill priority: `Issue / Ticket` from the input → `Task ID` (no prefix, e.g. `8852`) → `unknown`. Multiple tickets are comma-separated. Full rules live in the `okstra-team-contract` skill's Ticket Tagging section.
+**Ticket tagging:** For runs whose task type is `requirements-discovery`, `error-analysis`, `implementation-planning`, or `implementation`, every item in sections 1–5 MUST carry a ticket identifier. Use the `Ticket ID` column in table-form items and the `[TICKETID: <id>]` prefix in bullet/numbered items. Fill priority: `Issue / Ticket` from the input → `Task ID` (no prefix, e.g. `8852`) → `unknown`. Multiple tickets are comma-separated. Full rules live in the team-contract resource (`prompts/lead/team-contract.md`) Ticket Tagging section.
 
-This contract mirrors the `okstra-team-contract` skill's Worker Output Contract — that skill is the authoritative source if the two ever diverge.
+This contract mirrors the team-contract resource (`prompts/lead/team-contract.md`) Worker Output Contract — that resource is the authoritative source if the two ever diverge.
 
 ## Error reporting
 
@@ -195,7 +195,7 @@ and the run-level error log staying empty.
    extracted from the `**Errors sidecar path:**` header. If the file does
    not exist, create it with `{"schemaVersion": 1, "errors": []}` then
    append. The sidecar follows the schema in
-   `skills/okstra-team-contract/SKILL.md` (Optional errors sidecar). Lead
+   `prompts/lead/team-contract.md` (Optional errors sidecar). Lead
    will dump it to the run error log after this subagent terminates.
 
 2. **CLI failure (lead-observed)** — if the wrapper's final `BashOutput`
@@ -234,7 +234,7 @@ pre-flight terminal status, not a runtime CLI error.
 - Always specify the assigned `-m` value for the current run.
 - Return error messages as-is on failure.
 - Do not summarize or modify Gemini results beyond prepending the single `**Model:**` line on a normal return (step 8d).
-- Sections 1–5 of the worker output are the common core shared with the Claude and Codex workers — the dispatched prompt asks identical questions for all three roles, and the Gemini CLI must answer all of them, not only requirement-interpretation findings. Your specialization (requirement interpretation, consistency, safety, documentation quality, alternative viewpoints) belongs only in optional Section 6 as additive depth. A Gemini result whose Findings section is populated solely with requirement-interpretation items is in breach of contract; see `skills/okstra-team-contract/SKILL.md` "Worker Output Contract".
+- Sections 1–5 of the worker output are the common core shared with the Claude and Codex workers — the dispatched prompt asks identical questions for all three roles, and the Gemini CLI must answer all of them, not only requirement-interpretation findings. Your specialization (requirement interpretation, consistency, safety, documentation quality, alternative viewpoints) belongs only in optional Section 6 as additive depth. A Gemini result whose Findings section is populated solely with requirement-interpretation items is in breach of contract; see `prompts/lead/team-contract.md` "Worker Output Contract".
 
 ## Stage evidence emission (BLOCKING, implementation task only)
 

package/runtime/agents/workers/report-writer-worker.md

@@ -30,7 +30,7 @@ If you find yourself thinking "I'll just write the markdown directly" — stop.
 
 ## Worker Result File (MANDATORY)
 
-You also write an audit sidecar at the path the lead registers as `**Worker Result Path:**` (default: `runs/<task-type>/worker-results/report-writer-worker-<task-type>-<seq>.md`). The validator checks this file exists whenever the role's terminal status is `completed`. Schema: short YAML frontmatter (`workerId: "report-writer"`, plus the canonical fields copied verbatim from `analysis-material.md` per `okstra-team-contract`) followed by:
+You also write an audit sidecar at the path the lead registers as `**Worker Result Path:**` (default: `runs/<task-type>/worker-results/report-writer-worker-<task-type>-<seq>.md`). The validator checks this file exists whenever the role's terminal status is `completed`. Schema: short YAML frontmatter (`workerId: "report-writer"`, plus the canonical fields copied verbatim from `analysis-material.md` per `team-contract`) followed by:
 
 1. The canonical data.json path you wrote (project-relative).
 2. The rendered markdown path produced by the renderer (project-relative).
@@ -124,7 +124,7 @@ If any tool call fails (Write of the prompt history file, mkdir, MCP call, Read
 runs/<task-type>/worker-results/report-writer-worker-errors-<task-type>-<seq>.json
 ```
 
-Schema follows `okstra-team-contract` (Optional errors sidecar). Create the file with `{"schemaVersion": 1, "errors": []}` if missing, then append. Lead will dump it to the run error log after this subagent terminates.
+Schema follows `team-contract` (Optional errors sidecar). Create the file with `{"schemaVersion": 1, "errors": []}` if missing, then append. Lead will dump it to the run error log after this subagent terminates.
 
 There is NO `cli-failure` category for this worker — it has no external CLI to invoke. Treat MCP errors and Bash errors uniformly as `tool-failure`.
 

package/runtime/bin/lib/okstra/globals.sh

@@ -5,7 +5,6 @@ PROMPT_TEMPLATE="$WORKSPACE_ROOT/prompts/launch.template.md"
 TASK_INDEX_TEMPLATE="$WORKSPACE_ROOT/templates/project-docs/task-index.template.md"
 FINAL_REPORT_TEMPLATE_SOURCE="$WORKSPACE_ROOT/templates/reports/final-report.template.md"
 RUN_VALIDATOR_PATH="$WORKSPACE_ROOT/validators/validate-run.py"
-SOURCE_CLAUDE_OKSTRA_SKILL="$WORKSPACE_ROOT/agents/SKILL.md"
 OKSTRA_ROOT=""
 OKSTRA_TASKS_ROOT=""
 OKSTRA_DISCOVERY_DIR=""

package/runtime/bin/okstra-wrapper-status.py

@@ -16,7 +16,7 @@ Consumers:
   absent.
 * Lead: cross-check `started_ts` / `ended_ts` to distinguish "wrapper hung
   before CLI launched" from "CLI finished but never wrote artifact" when
-  applying the redispatch policy (see okstra-team-contract "Lead Redispatch
+  applying the redispatch policy (see team-contract "Lead Redispatch
   Policy on Result-Missing").
 
 Failures are deliberately non-fatal for the caller — the wrapper's main

package/runtime/{skills/okstra-coding-preflight → prompts/coding-preflight}/languages/python.md

@@ -1,6 +1,6 @@
 # Python Conventions
 
-If a project-level Python style skill or repo-local `CONTRIBUTING.md` / `pyproject.toml` config exists, **it wins**. This file is the fallback.
+If a project-level Python style guide or repo-local `CONTRIBUTING.md` / `pyproject.toml` config exists, **it wins**. This file is the fallback.
 
 ## Core principles
 
@@ -127,7 +127,7 @@ Separate domain logic from infrastructure; keep business rules independent of fr
 - `interfaces/` — HTTP, CLI, workers, event handlers
 - `tests/` — unit, integration, e2e
 
-When the project is ports-and-adapters, also read [../architecture/hexagonal.md](../architecture/hexagonal.md).
+When the project is ports-and-adapters, also read [../architectures/hexagonal.md](../architectures/hexagonal.md).
 
 ## Security
 

package/runtime/{skills/okstra-coding-preflight → prompts/coding-preflight}/languages/rust.md

@@ -1,6 +1,6 @@
 # Rust Conventions
 
-If a project-level `rust-guidelines` skill or repo-local `CONTRIBUTING.md` exists, **it wins**. This file is the fallback.
+If a project-level `rust-guidelines` ruleset or repo-local `CONTRIBUTING.md` exists, **it wins**. This file is the fallback.
 
 ## Style guide
 

package/runtime/{skills/okstra-coding-preflight/SKILL.md → prompts/coding-preflight/overview.md}

@@ -1,11 +1,4 @@
----
-name: okstra-coding-preflight
-description: Provides language-specific coding conventions, idioms, and test-writing guidance for Java, Kotlin, JavaScript, TypeScript, Node.js, Python, SQL, and Rust. okstra lead/workers MUST consult this skill before writing, editing, refactoring, or testing code in any of these languages — including any new file, function, or test — even when the task seems simple enough to handle directly. Detect the target language from the file extension, project config (package.json/Cargo.toml/pyproject.toml/pom.xml/build.gradle), or task brief, and apply the matching conventions.
-user-invocable: false
-hide: true
----
-
-# okstra Code Preflight
+# Okstra Coding Preflight
 
 ## These apply to every worker writing or editing project code (executor and verifiers alike). Enforcement is self-check: the agent runs each rule's check immediately before reporting "done"; skipping a check is itself a contract violation.
 
@@ -16,42 +9,38 @@ hide: true
 5. **Function length cap — 50 lines** — A single function/method body must stay within 50 lines, counting only effective code (exclude blank lines, comments, and pure data declarations such as large enums, lookup tables, or constant maps). Crossing the cap is an extraction signal, not a style nit. *Self-check: for any function newly added or substantially edited, count effective body lines; if over 50, split before declaring complete, or surface the violation and confirm with the user.*
 
 
-## Quick start
+## Routed resource selection
 
-Before writing or editing **any** code:
+Read `clean-code.md` for the language-agnostic principles, then select language, framework, and architecture resources in three ordered stages. Each stage is a list of rules; a rule has one or more conditions; if ANY condition matches, include that rule's resource. Iterate EVERY rule in a stage — do not stop at the first match, because one change set can touch multiple languages, frameworks, or architectures. De-duplicate the final set, then state in one sentence which resources you applied (e.g., *"Applying TS + Node server + hexagonal; domain at src/domain/."*).
 
-1. Identify the target language (file extension, project config, or explicit user request).
-2. Read the matching language reference from `languages/`.
-3. Read [clean-code.md](clean-code.md) for the language-agnostic principles.
-4. **Check for architecture overlays.** If the project uses ports-and-adapters (signals: `domain/` + `ports/` + `adapters/` folders, `*.port.*` files, NestJS hex split), also read [architecture/hexagonal.md](architecture/hexagonal.md). Record the detected layout in one line so later edits don't re-discover it.
-5. In **one short sentence** to the user, state which conventions you will apply (e.g., *"Applying Kotlin conventions + hexagonal overlay; domain at `src/domain/`."*).
-6. Then write code.
+### Stage 1 — Language (iterate all rules)
 
-If the language is not listed below, stop and ask the user for the canonical style guide they want to follow before writing code.
+| Resource | Include when any condition matches |
+|---|---|
+| [languages/javascript-typescript.md](languages/javascript-typescript.md) | a touched file is `.js`, `.jsx`, `.ts`, `.tsx`, `.mjs`, `.cjs`; or a JS package manifest (`package.json`) implies JS/TS work |
+| [languages/python.md](languages/python.md) | a touched file is `.py`; or manifests include `pyproject.toml`, `requirements.txt`, `setup.py`, `setup.cfg` |
+| [languages/rust.md](languages/rust.md) | a touched file is `.rs`; or `Cargo.toml` is in scope |
+| [languages/java.md](languages/java.md) | a touched file is `.java`; or manifests include `pom.xml` / `build.gradle` |
+| [languages/kotlin.md](languages/kotlin.md) | a touched file is `.kt` / `.kts`; or manifests include `build.gradle.kts` |
+| [languages/sql.md](languages/sql.md) | a touched file is `.sql`; migration directories are touched; `prisma/schema.prisma` is touched; or embedded query strings / ORM query builders change |
 
-## Language router
+### Stage 2 — Framework / runtime (iterate all rules)
 
-| Language | Reference | Triggers |
-|---|---|---|
-| Java | [languages/java.md](languages/java.md) | `.java`, `pom.xml`, `build.gradle` |
-| Kotlin | [languages/kotlin.md](languages/kotlin.md) | `.kt`, `.kts`, `build.gradle.kts` |
-| JavaScript / TypeScript | [languages/javascript-typescript.md](languages/javascript-typescript.md) | `.js`, `.ts`, `.tsx`, `.jsx` |
-| Node.js (server) | [languages/nodejs.md](languages/nodejs.md) | `package.json` with server entry, `express`, `fastify`, `nestjs` |
-| Python | [languages/python.md](languages/python.md) | `.py`, `pyproject.toml`, `requirements.txt`, `setup.py`, `setup.cfg` |
-| SQL | [languages/sql.md](languages/sql.md) | `.sql`, migration directories, `prisma/schema.prisma`, raw queries embedded in code |
-| Rust | [languages/rust.md](languages/rust.md) | `.rs`, `Cargo.toml` |
+| Resource | Include when any condition matches |
+|---|---|
+| [frameworks/node-server.md](frameworks/node-server.md) | `package.json` or its dependencies/scripts show server-side Node work (`express`, `fastify`, `nestjs`, server entrypoints, API routes, CLI services); or a touched file is a Node runtime module |
 
-For Node.js work, load **both** `javascript-typescript.md` and `nodejs.md`.
+Node.js server work also matches Stage 1's JavaScript/TypeScript rule — load both `languages/javascript-typescript.md` and `frameworks/node-server.md`.
 
-## Architecture overlays
+### Stage 3 — Architecture (iterate all rules)
 
-Loaded **in addition to** the language reference when the project matches. Overlays add architectural rules that cut across languages.
+| Resource | Include when any condition matches |
+|---|---|
+| [architectures/hexagonal.md](architectures/hexagonal.md) | ports-and-adapters / hexagonal signals: `domain/` + `ports/` + `adapters/` (or `core/` + `infrastructure/` + `application/`), `*.port.*` files, NestJS hex split, or `abstract class` files at a domain boundary |
 
-| Overlay | Reference | When to load |
-|---|---|---|
-| Hexagonal (ports & adapters) | [architecture/hexagonal.md](architecture/hexagonal.md) | Project has `domain/` + `ports/` + `adapters/` (or equivalent: `core/`, `infrastructure/`, `application/`), `*.port.*` files, or `abstract class` files at a domain boundary. Confirm once with the user if ambiguous. |
+If a layout looks hexagonal but is non-standard, ask one question — *"does this project follow ports-and-adapters? where is the domain?"* — and record the answer. Architecture overlays default to none when no rule matches.
 
-If you suspect an overlay applies but the layout is non-standard, ask one question — *"does this project follow ports-and-adapters? where is the domain?"* — and record the answer.
+If no Stage 1 language rule matches (an unlisted language), stop and ask the user for the canonical style guide before writing code — do not invent a default.
 
 ## Mandatory pre-write checks (every language)
 
@@ -61,7 +50,7 @@ If you suspect an overlay applies but the layout is non-standard, ask one questi
 - [ ] **Testing discipline:** the test does not stub/spy methods on the SUT itself (collaborators are fine), and assertions are on outcomes (return values, state, events, boundary calls) — not on which internal helper was called.
 - [ ] **Hexagonal overlay (if loaded):** no business logic inside any port body, adapter methods are I/O only (no post-fetch JS filtering on domain state, no `findValid*`/`findActive*` adapter names hiding rules), all domain objects declared under `domain/`.
 - [ ] Existing code searched: `grep` for the symbol / file / identifier you are about to add. Do not duplicate.
-- [ ] Project conventions checked: `.editorconfig`, `CONTRIBUTING.md`, formatter config (`.prettierrc`, `rustfmt.toml`, `ktlint`, `google-java-format`, etc.). **Project rules override this skill on conflict.**
+- [ ] Project conventions checked: `.editorconfig`, `CONTRIBUTING.md`, formatter config (`.prettierrc`, `rustfmt.toml`, `ktlint`, `google-java-format`, etc.). **Project rules override this resource pack on conflict.**
 
 ## Completion sweep (before declaring a multi-file change done)
 
@@ -73,6 +62,6 @@ Per-file checks miss cross-cutting issues; each commit can be individually clean
 
 ## Boundaries
 
-- This skill does **not** auto-format. Run the project's formatter yourself.
-- This skill does **not** replace repo-local rules. Repo rules win on conflict.
-- This skill does **not** cover every language. If the target language is missing, stop and ask.
+- This preflight does **not** auto-format. Run the project's formatter yourself.
+- This preflight does **not** replace repo-local rules. Repo rules win on conflict.
+- This preflight does **not** cover every language. If the target language is missing, stop and ask.

package/runtime/prompts/launch.template.md

@@ -5,7 +5,7 @@
 
 ## Progress reporting (BLOCKING)
 
-Emit one `PROGRESS: <phase-id> <verb-phrase>` line as plain user-facing text at every checkpoint enumerated in `agents/SKILL.md` "Progress reporting (BLOCKING)" — phase-1-intake start/complete, phase-2-prompts, phase-3-team-create, phase-4-dispatch (per worker), phase-5-collect (per worker), phase-5.5-convergence (per round), phase-6-synthesis, phase-7-persist, and final `complete`. One line per checkpoint, never batched, never replaced with prose. This is the only signal the user has during multi-minute silent windows.
+Emit one `PROGRESS: <phase-id> <verb-phrase>` line as plain user-facing text at every checkpoint enumerated in the okstra lead contract (`{{OKSTRA_LEAD_CONTRACT_PATH}}` "Progress reporting (BLOCKING)") — phase-1-intake start/complete, phase-2-prompts, phase-3-team-create, phase-4-dispatch (per worker), phase-5-collect (per worker), phase-5.5-convergence (per round), phase-6-synthesis, phase-7-persist, and final `complete`. One line per checkpoint, never batched, never replaced with prose. This is the only signal the user has during multi-minute silent windows.
 
 ## Current Phase Boundary
 
@@ -18,7 +18,7 @@ Emit one `PROGRESS: <phase-id> <verb-phrase>` line as plain user-facing text at
 {{STAGE_BATCH_DIRECTIVE}}
 {{VERIFICATION_TARGET}}
 - Phase advancement requires a new okstra invocation launched with `--task-type {{WORKFLOW_NEXT_RECOMMENDED_PHASE}}` after this run's final report is written and approved. The lead must not write source code, run builds/migrations/deployments, or otherwise produce artifacts of a different phase from inside this run.
-- See `Lifecycle Phase Boundaries` in the okstra skill (`agents/SKILL.md`) for the canonical rules and the phase-transition checklist.
+- See `Lifecycle Phase Boundaries` in the okstra lead contract (`{{OKSTRA_LEAD_CONTRACT_PATH}}`) for the canonical rules and the phase-transition checklist.
 
 {{TEAM_CREATION_GATE}}
 
@@ -39,6 +39,8 @@ Emit one `PROGRESS: <phase-id> <verb-phrase>` line as plain user-facing text at
 
 {{LEAD_SESSION_BLOCK}}
 
+{{OKSTRA_RUNTIME_RESOURCES}}
+
 ## Run Paths
 
 - Team state: `{{TEAM_STATE_RELATIVE_PATH}}`
@@ -59,7 +61,7 @@ Emit one `PROGRESS: <phase-id> <verb-phrase>` line as plain user-facing text at
   - `**Errors log path:** <absolute run-level errors log path>`
   - `**Errors sidecar path:** <absolute per-worker sidecar path matching the dispatched worker>`
 - These lines are the canonical contract — worker subagents extract them verbatim and pass them to `okstra error-log append-observed --out ...` (run-level cli-failure / contract-violation events) and to their internal sidecar writes (worker-reported tool-failure events) respectively.
-- After each worker terminates, dump its sidecar into the run-level errors log via `okstra error-log append-from-worker --sidecar <sidecar-path> --out <run-errors-log-path> --task-key {{TASK_KEY}} --agent <worker-id> --agent-role worker --model <assigned-model-execution-value>` (per `okstra-team-contract` Worker Output Contract).
+- After each worker terminates, dump its sidecar into the run-level errors log via `okstra error-log append-from-worker --sidecar <sidecar-path> --out <run-errors-log-path> --task-key {{TASK_KEY}} --agent <worker-id> --agent-role worker --model <assigned-model-execution-value>` (per the team-contract resource — `{{OKSTRA_TEAM_CONTRACT_PATH}}` — Worker Output Contract).
 
 ## Executor Worktree
 

package/runtime/{skills/okstra-context-loader/SKILL.md → prompts/lead/context-loader.md}

@@ -1,15 +1,8 @@
----
-name: okstra-context-loader
-description: Use when okstra Phase 1 starts, or when the user asks for an okstra task bundle path, task-manifest location, or the current/latest okstra run artifacts.
-user-invocable: false
-hide: true
----
-
-# OKSTRA Context Loader
+# Okstra Context Loader Contract
 
 ## When to Use
 
-- When starting okstra Skill Phase 1 (Task-bundle intake)
+- When starting okstra lead Phase 1 (Task-bundle intake)
 - When the user needs to know the okstra task bundle path
 - When you need to derive all artifact paths based on `task-manifest.json`
 
@@ -67,7 +60,7 @@ hide: true
 | `historyTimelinePath` | timeline path |
 | `resultContract` | team contract and expected artifact metadata |
 | `resultContract.requiredWorkerRoles[*].promptPath` | worker prompt history path by role |
-| `convergence` | convergence loop settings (`enabled`, `maxRounds`, `verificationMode`). See [okstra-convergence](../okstra-convergence/SKILL.md) for the authoritative defaults — do not re-document the `maxRounds` value here. |
+| `convergence` | convergence loop settings (`enabled`, `maxRounds`, `verificationMode`). See [convergence](./convergence.md) for the authoritative defaults — do not re-document the `maxRounds` value here. |
 
 ## Step 3: Directory Structure Rules
 
@@ -135,9 +128,9 @@ Read source files lazily:
 
 After reading `task-brief.md`, extract the frontmatter `reporter-confirmations` field (`complete | partial | pending | skipped`). This precondition is shared across every consuming phase — see `prompts/profiles/_common-contract.md` "Brief consumption" block for the authoritative handling matrix.
 
-- `complete` or `partial` → proceed to Step 5 and hand off to `okstra-team-contract`.
+- `complete` or `partial` → proceed to Step 5 and hand off to `team-contract`.
 - `skipped` → proceed, but flag the unmarked `intent-check:` / `conversion-block:` rows for promotion by the phase profile.
-- `pending` (or field missing) → emit `REPORTER_CONFIRMATION_PENDING` and STOP. Do not invoke `okstra-team-contract` or any analyser. The operator must rerun `okstra-brief` Step 6.5 before Phase 2 can start.
+- `pending` (or field missing) → emit `REPORTER_CONFIRMATION_PENDING` and STOP. Do not invoke `team-contract` or any analyser. The operator must rerun `okstra-brief` Step 6.5 before Phase 2 can start.
 
 ## Step 5: Read Run Manifest and Team State
 
@@ -149,7 +142,7 @@ After reading `task-brief.md`, extract the frontmatter `reporter-confirmations`
 
 ## Output
 
-Information to be obtained after executing this skill:
+Information produced after completing this contract:
 - task key, task type, work category, workflow lifecycle snapshot, analysis profile
 - List of selected workers and model assignments by role
 - Absolute/relative paths of all artifacts (including latest-task pointer, task catalog, prompt directory, per-worker prompt history files, resume command, and timeline)
@@ -157,5 +150,5 @@ Information to be obtained after executing this skill:
 - Current run status and presence of existing worker results
 - Current run prompt history contract for attempted workers
 - Candidate `teamName` for Phase 3 hand-off: `okstra-<task-key>` (with task-key slugified per Step 1's slug rule); implementation stage runs append `-s<N>` — the launch prompt's Team Creation Gate block carries the final name verbatim
-- Current Claude `lead.sessionId` (the in-flight Claude Code session) — required by `okstra-team-contract` when registering the lead in `team-state.json`
+- Current Claude `lead.sessionId` (the in-flight Claude Code session) — required by `team-contract` when registering the lead in `team-state.json`
 - Resume command path: from `task-manifest.json` → `latestResumeCommandPath` (fallback: latest `runs/<task-type>/sessions/claude-resume-*.sh` by mtime). Never reconstruct the filename — the `<seq>` counter is category-local and may diverge from `manifests/`.

package/runtime/{skills/okstra-convergence/SKILL.md → prompts/lead/convergence.md}

@@ -1,11 +1,4 @@
----
-name: okstra-convergence
-description: Use when okstra Phase 5.5 needs iterative cross-verification between workers, or when worker findings must be classified by consensus level before final synthesis.
-user-invocable: false
-hide: true
----
-
-# OKSTRA Convergence
+# Okstra Convergence Contract
 
 ## Index
 
@@ -29,15 +22,15 @@ hide: true
 
 ## Scope and Terminology (BLOCKING)
 
-This skill governs **Phase 5.5 (Convergence loop)** — a *lead operating phase* inside a single okstra run, not a task-type lifecycle phase. The 6 task-type lifecycle phases (`requirements-discovery` → `error-analysis` → `implementation-planning` → `implementation` → `final-verification` → `release-handoff`, see [okstra/SKILL.md](../../SKILL.md) "Lifecycle Phase Boundaries") are unchanged by this skill. The lead operating phases (Phase 1 Intake → Phase 7 Persist, see [okstra/SKILL.md](../../SKILL.md) "Quick Reference") describe how the lead drives a *single* task-type run.
+This contract governs **Phase 5.5 (Convergence loop)** — a *lead operating phase* inside a single okstra run, not a task-type lifecycle phase. The 6 task-type lifecycle phases (`requirements-discovery` → `error-analysis` → `implementation-planning` → `implementation` → `final-verification` → `release-handoff`, see [okstra-lead-contract](./okstra-lead-contract.md) "Lifecycle Phase Boundaries") are unchanged by this contract. The lead operating phases (Phase 1 Intake → Phase 7 Persist, see [okstra-lead-contract](./okstra-lead-contract.md) "Quick Reference") describe how the lead drives a *single* task-type run.
 
 **`contested` is a final classification only.** It is NEVER an intermediate queue label. The verification queue carries findings that are *unique to a single worker* (entered in Round 0) or *mixed/unresolved after a re-verification round* (carried forward). The `contested` label is assigned only when the **last executed round** completes and the queue is still non-empty.
 
-When this skill says "queue" without qualifier, it means the *verification queue*: the set of findings that are still candidates for re-verification in subsequent rounds. The queue shrinks monotonically as findings get classified as `full-consensus`, `partial-consensus`, or `worker-unique`. Findings classified into any of these three categories MUST NOT appear in any subsequent round's reverify prompt, for any worker.
+When this contract says "queue" without qualifier, it means the *verification queue*: the set of findings that are still candidates for re-verification in subsequent rounds. The queue shrinks monotonically as findings get classified as `full-consensus`, `partial-consensus`, or `worker-unique`. Findings classified into any of these three categories MUST NOT appear in any subsequent round's reverify prompt, for any worker.
 
 ## When to Use
 
-- When the okstra skill Phase 5.5 (convergence loop) begins
+- When okstra lead Phase 5.5 (convergence loop) begins
 - Immediately after all workers have completed Phases 4 and 5
 - When findings need to be systematically classified by consensus level
 
@@ -71,7 +64,7 @@ Configure this in the `convergence` block of `task-manifest.json`. If the block
 
 Read the worker result files generated in Phase 4/5 and extract individual findings.
 
-**Convergence scope.** Convergence operates on sections 1–5 of the worker output (the common core, see `okstra-team-contract` "Worker Output Contract"). Section 6 ("Specialization Lens") is additive worker-specific depth and MUST NOT be fed into the consensus grouping, the verification queue, or the round-N reverify prompts. Carry Section 6 forward into the final report verbatim through the report-writer worker — do not let it inflate `unique` counts or trigger spurious `verification-error` statuses.
+**Convergence scope.** Convergence operates on sections 1–5 of the worker output (the common core, see `team-contract` "Worker Output Contract"). Section 6 ("Specialization Lens") is additive worker-specific depth and MUST NOT be fed into the consensus grouping, the verification queue, or the round-N reverify prompts. Carry Section 6 forward into the final report verbatim through the report-writer worker — do not let it inflate `unique` counts or trigger spurious `verification-error` statuses.
 
 1. In the "Findings" section of each worker's results, identify individual items by number (F-001, F-002, ...) and parse the ticket identifier attached to each item:
    - For table-form findings, read the `Ticket ID` column.
@@ -199,7 +192,7 @@ Disadvantages: 2–3 times the cost, increased time
 
 ## Adversarial Verification Mode
 
-Active only when `config.adversarial == true` (default for `requirements-discovery`, `error-analysis`, and `implementation-planning`; see §"Configuration"). When `false`, every rule in this section is inert and the collaborative behaviour documented elsewhere in this skill applies unchanged.
+Active only when `config.adversarial == true` (default for `requirements-discovery`, `error-analysis`, and `implementation-planning`; see §"Configuration"). When `false`, every rule in this section is inert and the collaborative behaviour documented elsewhere in this contract applies unchanged.
 
 In adversarial mode the verifier's job inverts: instead of confirming a peer's finding, the verifier **tries to break it**, and the burden of proof sits on the claim — a finding survives only if refutation attempts fail.
 
@@ -277,7 +270,7 @@ Agent(
 For `tmux-pane` backend runs, do not use the Agent snippet. For each reverify round, write a jobs file at `runs/<task-type>/state/reverify-jobs-r<N>-<task-type>-<seq>.json` with `dispatchKind: "reverify-r<N>"` and worker entries containing `workerId`, `provider`, `role`, `modelExecutionValue`, `promptPath`, `resultPath`, `workerResultPath`, and `completionPaths`; then run `okstra team dispatch --project-root <dir> --run-manifest <path> --dispatch-kind reverify-r<N> --jobs-file <jobs-file>` followed by `okstra team await --project-root <dir> --run-manifest <path>`.
 
 
-**Completion detection per round (BLOCKING).** Each round dispatches a variable set (1..N) of reverify workers asynchronously; the `Agent(... team_name ...)` calls return `Spawned successfully` immediately, which is NOT completion. Lead MUST detect each round's completion via the self-scheduled polling protocol in [okstra-team-contract](../okstra-team-contract/SKILL.md) "Worker-completion detection (self-scheduled polling)", with the pending set reconstructed from that round's dispatched workers' Result Paths — do NOT restate the algorithm here. Lead MUST NOT treat the spawn ack as completion and MUST NOT end its turn with a prose "waiting" statement.
+**Completion detection per round (BLOCKING).** Each round dispatches a variable set (1..N) of reverify workers asynchronously; the `Agent(... team_name ...)` calls return `Spawned successfully` immediately, which is NOT completion. Lead MUST detect each round's completion via the self-scheduled polling protocol in [team-contract](./team-contract.md) "Worker-completion detection (self-scheduled polling)", with the pending set reconstructed from that round's dispatched workers' Result Paths — do NOT restate the algorithm here. Lead MUST NOT treat the spawn ack as completion and MUST NOT end its turn with a prose "waiting" statement.
 
 ### Required reverify-prompt anchor headers (BLOCKING)
 
@@ -306,7 +299,7 @@ For Codex/Gemini wrapper subagents, the `**Model:** <role>, <modelExecutionValue
 Reverify prompts MUST NOT inject the Phase 2 `[Required reading]` clause:
 
 - **Lightweight mode**: the clause directly contradicts the "Do NOT re-analyze the original source materials" instruction below. Including it forces workers to re-read the entire instruction-set per round per worker (3 workers × 2 rounds × 5+ files in the worst case) for no quality gain.
-- **Full-reanalysis mode**: workers DO need to re-read source materials, but only the analysis-worker file list (no `final-report-template.md`). If lead chooses to inject a reading clause here, it MUST mirror the audience-scoped enumeration in [okstra/SKILL.md](../../SKILL.md) Phase 2 (no template).
+- **Full-reanalysis mode**: workers DO need to re-read source materials, but only the analysis-worker file list (no `final-report-template.md`). If lead chooses to inject a reading clause here, it MUST mirror the audience-scoped enumeration in [okstra-lead-contract](./okstra-lead-contract.md) Phase 2 (no template).
 
 This is the single largest avoidable cost in `requirements-discovery`, `error-analysis`, and `implementation-planning` runs. Treat as BLOCKING.
 
@@ -584,7 +577,7 @@ Critic output lives in the run's `worker-results/` directory (`runs/final-verifi
 
 ## Output
 
-Information to be passed to Phase 6 after executing this skill:
+Information to be passed to Phase 6 after completing this contract:
 
 - Final classification of all findings (4-category)
 - Round history and votes per worker for each finding
@@ -594,7 +587,7 @@ Information to be passed to Phase 6 after executing this skill:
 
 ## Convergence Disabled
 
-If `convergence.enabled: false`, this skill is skipped. Phase 6 operates using the existing consensus/divergence method.
+If `convergence.enabled: false`, this contract is skipped. Phase 6 operates using the existing consensus/divergence method.
 
 ## Plan-body verification mode (implementation-planning only)
 
@@ -606,7 +599,7 @@ Plan-body verification runs **after** finding convergence and **after** the repo
 
 ```
 Phase 4   workers produce independent analyses (Findings F-001…)
-  → Phase 5.5   FINDING convergence (this skill, sections "Convergence Algorithm" through "Convergence State Artifact")
+  → Phase 5.5   FINDING convergence (this contract, sections "Convergence Algorithm" through "Convergence State Artifact")
   → Phase 6   report-writer authors final-report draft (consolidated Option Candidates / Stepwise Execution Order / Dependency / Validation Checklist / Rollback)
   → PLAN-BODY VERIFICATION ROUND ← new — described below
   → User Approval gate (top-of-report `- [ ] Approved` marker is rendered only when this round's Gate result is `passed` or `passed-with-dissent`)
@@ -624,7 +617,7 @@ The finding queue (Phase 5.5) and the plan-item queue (this section) are **disjo
 - The two rounds write to **different state files**: `runs/<task-type>/state/convergence-<task-type>-<seq>.json` (findings, see §"Convergence State Artifact") vs. `runs/<task-type>/state/plan-body-verification-<task-type>-<seq>.json` (plan items, see §"`plan-body-verification.json` schema").
 - Aggregation logic (verdict counting, classification) MUST NOT carry votes from one queue into the other.
 
-Mixing the two queues — for example, parsing a Phase 6 draft's Stepwise Execution Order step as if it were an `F-*` finding — is a contract violation. Future Claude reading this skill: if you find yourself tempted to "just reuse the finding queue for plan items, they're similar enough", stop. They are not similar enough; the verdict semantics differ (see §"Plan-body verdict semantics" below).
+Mixing the two queues — for example, parsing a Phase 6 draft's Stepwise Execution Order step as if it were an `F-*` finding — is a contract violation. Future Claude reading this contract: if you find yourself tempted to "just reuse the finding queue for plan items, they're similar enough", stop. They are not similar enough; the verdict semantics differ (see §"Plan-body verdict semantics" below).
 
 ### Configuration