okstra 0.107.0 → 0.107.2

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "okstra",
-  "version": "0.107.0",
+  "version": "0.107.2",
   "description": "Multi-agent cross-verification orchestrator runtime + Claude Code skills.",
   "license": "MIT",
   "author": "devonshin",

package/runtime/BUILD.json

@@ -1,5 +1,5 @@
 {
-  "package": "0.107.0",
-  "builtAt": "2026-07-01T03:36:52.358Z",
+  "package": "0.107.2",
+  "builtAt": "2026-07-01T09:21:00.281Z",
   "repoRoot": "/home/runner/work/okstra/okstra"
 }

package/runtime/bin/okstra-team-reconcile.sh

@@ -12,8 +12,16 @@
 # are left for graceful shutdown). It no-ops when tmux is unavailable or nothing
 # is stale.
 #
-# Usage: okstra-team-reconcile.sh [--list] <team-name>
-#   --list   report what WOULD be deactivated; do not write (alias --dry-run).
+# Usage:
+#   okstra-team-reconcile.sh [--list] <team-name|team-dir|config.json>
+#   okstra-team-reconcile.sh [--list] --project-root <dir> [--fallback-team <label>]
+#   okstra-team-reconcile.sh [--list] --session-end   # reads SessionEnd JSON on stdin
+#
+#   --project-root  resolve the CURRENT live session's roster (robust to the
+#                   phase-3 lead.sessionId snapshot drifting across resume), then
+#                   reconcile and print `dismissible-member: <name>` lines.
+#   --session-end   SessionEnd-hook net: reconcile the ending session's roster.
+#   --list          report what WOULD be deactivated; do not write (alias --dry-run).
 #
 # Failures are non-fatal to the run — teardown must never block on this.
 set -u

package/runtime/prompts/lead/convergence.md

@@ -648,7 +648,7 @@ From the report-writer's draft of `## 5.4 Implementation Plan Deliverables`, lea
 
 Each plan item inherits the `[TICKETID: ...]` tag of its source section (per the standard ticket-tagging contract).
 
-When extracting each item, lead also captures a **`subject`** — a plain one-line label (≤12 words) describing *what that item is* in the reader's terms, e.g. `P-Opt-1` → "Option A: upload v2 를 신규 모듈로 분리", `P-Step-1.1` → "Stage 1 Step 2: `npm run test:v2` 로 회귀 검증". This is a label-capture, not new analysis. The `subject` is what §5.5.9 renders as the per-item heading so the reader knows *what* each AGREE/DISAGREE is about without cross-referencing §4.5; a bare `P-*` ID with no subject is a contract violation.
+When extracting each item, lead also captures a **`subject`** — a plain one-line label (≤12 words) describing *what that item is* in the reader's terms, e.g. `P-Opt-1` → "Option A: upload v2 를 신규 모듈로 분리", `P-Step-1.1` → "Stage 1 Step 2: `npm run test:v2` 로 회귀 검증". This is a label-capture, not new analysis. The `subject` is what §5.5.9 renders as the per-item heading so the reader knows *what* each AGREE/DISAGREE is about without cross-referencing §4.5; a bare `P-*` ID with no subject is a contract violation. **Enforced:** `validators/validate-run.py` `_validate_plan_item_subject_substance` fails a subject that is a placeholder — under 3 chars, equal to the item id, or shaped like a bare `P-*` id.
 
 ### Plan-body verdict semantics
 
@@ -679,9 +679,9 @@ When `config.adversarial == true` (the default for `implementation-planning`; se
 - The burden of proof sits on the plan: an item earns `AGREE` only if the verifier actively tried to break it and could not.
 - The verifier MUST open the file paths / symbols / commands the item cites and confirm they exist and are executable as written. This is the one allowed widening of the lightweight "judge from internal consistency and stated commands / paths" rule — confirming the existence of cited paths is not "re-analyzing the original requirements".
 - If a cited path / command / validation signal cannot be confirmed, the verifier responds `DISAGREE(<kind>)` with the applicable breakage kind (a–e); uncertainty resolves toward DISAGREE, not AGREE.
-- For `P-Req-*` items, a single `DISAGREE(f)` is approval-blocking even in a two-worker roster. Requirement coverage is a hard gate: one verified contradiction between a requirement row and its cited plan item creates a `majority-disagree` classification for gate purposes and MUST become a `Blocks=approval` clarification row.
+- **Single-vote-blocking kinds.** A single `DISAGREE` is approval-blocking on its own — no majority needed — when the breakage kind is `a` (cited path/symbol mismatch) or `d` (rollback violates commit/dependency order) on *any* plan item, or `f` (requirement-coverage mismatch) on a `P-Req-*` item. These defects are concrete, safety-critical, and adversarially verifiable (the verifier confirmed the cited path / order / requirement), so one correct dissent must not be outvoted. Each creates a `majority-disagree` classification and MUST become a `Blocks=approval` clarification row. Kinds `b` / `c` / `e` still need a majority — `b` especially is prone to planning-vs-implementation environment false positives. **Enforced:** `validators/validate-run.py` `_classify_plan_item_gate` (`_SINGLE_VOTE_BLOCKING_KINDS = {a, d}` + the P-Req `f` rule).
 
-Plan-body verification stays **lightweight** even under this posture — the `verificationMode = "full-reanalysis"` forcing in §"Adversarial Verification Mode" applies to finding convergence only (see §"Mode constraint"); the adversarial posture here only changes verifier behaviour, not the mode. This raises verification *quality* (active refutation, plan-side burden) without changing the gate *threshold* — a single dissent still does not block approval; a majority is required (deliberate design decision).
+Plan-body verification stays **lightweight** even under this posture — the `verificationMode = "full-reanalysis"` forcing in §"Adversarial Verification Mode" applies to finding convergence only (see §"Mode constraint"); the adversarial posture here only changes verifier behaviour, not the mode. This raises verification *quality* (active refutation, plan-side burden). The gate *threshold* stays majority-based for the majority-gated kinds (`b`/`c`/`e`), with the single-vote-blocking exception above for the concrete, safety-critical kinds (`a`/`d`, and `f` on P-Req). A majority requires at least two participating (non-error) votes, so a lone surviving `DISAGREE` whose peer returned a non-result does NOT block on a majority-gated kind — a worker failure must not make the gate stricter than a healthy roster would.
 
 ### Round protocol (single round at default `maxRounds=1`)
 
@@ -692,20 +692,20 @@ Plan-body verification stays **lightweight** even under this posture — the `ve
    - `full-consensus` — all participating analysers `AGREE` (SUPPLEMENT counts as agree on the item itself).
    - `partial-consensus` — majority `AGREE`, dissenting `DISAGREE` recorded.
    - `dissent-isolated` — only one worker `DISAGREE`s, others `AGREE` — treat as `partial-consensus` for gate purposes; record dissent. (Distinct from finding-convergence `worker-unique`, which means the *opposite*: only one worker AGREEs. Plan-body classifications use this dedicated label to avoid the collision.)
-   - `majority-disagree` — majority of analysers `DISAGREE` on this item, OR any analyser emits `DISAGREE(f)` for a `P-Req-*` item. This classification **blocks the Approval marker**.
+   - `majority-disagree` — a *majority* of analysers `DISAGREE` (majority needs ≥2 participating non-error votes), OR any single-vote-blocking kind fires: one `DISAGREE(a)` / `DISAGREE(d)` on any item, or one `DISAGREE(f)` on a `P-Req-*` item (see §"Single-vote-blocking kinds"). This classification **blocks the Approval marker**.
    - `contested` only meaningful when `maxRounds > 1`; at default `maxRounds=1`, fold any unresolved item into `partial-consensus`.
 5. Gate result resolution:
    - any `majority-disagree` item present AND `gating=true` → `blocked-by-disagreement`
    - all dispatches non-result → `aborted-non-result`
    - any `partial-consensus` / `dissent-isolated` present, no `majority-disagree` → `passed-with-dissent`
    - all items `full-consensus` → `passed`
-6. Lead writes `runs/<task-type>/state/plan-body-verification-<task-type>-<seq>.json` (schema below) and populates `### 5.5.9 Plan Body Verification` in the final report's data.json (`implementationPlanning.planBodyVerification`, schema `schemas/final-report-v1.0.schema.json`; template at `templates/reports/final-report.template.md`). The §5.5.9 body is **grouped by plan item**: `planItems[]`, each carrying its `id`, its plain-language `subject` (rendered as the item heading), an optional `sourceSection`, and a `verdicts[]` list (`worker / verdict / breakageKind / note`) — one verdict row per worker under that item. The renderer prints three fixed legends (gate values, verdict tokens, breakage kinds a–f) so the reader can decode every cell without opening this spec. The older flat `#### Verdict details` table (`Plan item / Worker / …`, one row per plan-item × worker pair) is superseded by the grouped layout — it hid *what* each vote was about behind a bare `P-*` ID; the subject heading is the fix. The validator's `Plan Body Verification` + `Gate result:` substring checks still gate this section.
+6. Lead writes `runs/<task-type>/state/plan-body-verification-<task-type>-<seq>.json` (schema below) and populates `### 5.5.9 Plan Body Verification` in the final report's data.json (`implementationPlanning.planBodyVerification`, schema `schemas/final-report-v1.0.schema.json`; template at `templates/reports/final-report.template.md`). The §5.5.9 body is **grouped by plan item**: `planItems[]`, each carrying its `id`, its plain-language `subject` (rendered as the item heading), an optional `sourceSection`, an optional `clarificationId` (the `C-<N>` this item blocks on when `majority-disagree`), and a `verdicts[]` list (`worker / verdict / breakageKind / note`) — one verdict row per worker under that item. The renderer prints three fixed legends (gate values, verdict tokens, breakage kinds a–f) so the reader can decode every cell without opening this spec. The older flat `#### Verdict details` table (`Plan item / Worker / …`, one row per plan-item × worker pair) is superseded by the grouped layout — it hid *what* each vote was about behind a bare `P-*` ID; the subject heading is the fix. The validator's `Plan Body Verification` + `Gate result:` substring checks still gate this section.
 7. For every `majority-disagree` item, lead adds a row to `## 1. Clarification Items` with:
    - new `C-<N>` ID (numbering continues from any existing rows)
    - `Statement` summarising the disagreement and the worker breakage `<kind>`
    - `Kind` chosen per the standard policy (usually `decision` for option-level conflicts, `data-point` for path/symbol mismatches)
    - `Blocks=approval`
-   - the §5.5.9 verdict table's `Classification` column for that row reads `majority-disagree → C-<N>` (1:1 ID match — orphan on either side is a contract violation per `prompts/profiles/implementation-planning.md` self-review step 6).
+   - the item's `planItems[].clarificationId` set to that `C-<N>` (1:1 link). `validators/validate-run.py` `_validate_plan_body_clarification_matching` recomputes each item's class and fails when a majority-disagree item's `clarificationId` is missing, dangling, or points at a non-`approval` row.
 8. The top-of-report `- [ ] Approved` marker line is rendered if and only if the Gate result is `passed` or `passed-with-dissent`. `validators/validate-run.py` `validate_phase_boundary` enforces this correspondence; manually adding the marker line when the gate did not pass is a contract violation.
 
 ### `plan-body-verification-<task-type>-<seq>.json` schema

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

@@ -218,7 +218,7 @@ These phases are governed by [team-contract](./team-contract.md). It is the cano
 Claude Code **v2.1.178 removed the `TeamCreate` / `TeamDelete` tools and the `Agent(...)` `team_name` parameter**. With `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1` (seeded by `okstra install` into the user's `settings.json`), every session already owns **one implicit team** from the moment it starts — there is no creation step to perform and no `team_name` to pass on dispatch. Workers spawned with `Agent(name: ...)` auto-join that implicit team. Do NOT search for, probe, or call `TeamCreate`: its absence is the expected state on every current Claude Code, NOT an "Agent Teams unavailable" signal, and is never a reason to degrade the run. There is no `select:TeamCreate` probe and no doubly-empty-select branch anymore — those keyed off a tool that no longer exists.
 
 1. Record team-state before any dispatch:
-   - `teamName` — the verbatim name from the launch prompt's gate block (`okstra-<task-key>`; implementation stage runs append `-s<N>`, single-stage final-verification appends `-fv-s<N>`). Audit/display label only — the implicit team's on-disk directory is `session-<leadSessionId-prefix>`, which run-end teardown and reconcile resolve from `lead.sessionId`, NEVER from `teamName`.
+   - `teamName` — the verbatim name from the launch prompt's gate block (`okstra-<task-key>`; implementation stage runs append `-s<N>`, single-stage final-verification appends `-fv-s<N>`). Audit/display label only — the implicit team's on-disk directory is `session-<leadSessionId-prefix>`, but run-end teardown resolves it from the CURRENT live session (see `_common-contract.md` "Run-end teammate teardown"), NOT from the phase-3 `lead.sessionId` snapshot recorded here, which drifts across resume / compaction; it is never resolved from `teamName`.
    - `teamCreate: { attempted: false, status: "implicit" }` — the audit marker that this run rides the session's implicit team (no explicit creation tool exists). A concurrent-run launch prompt instead pre-records `status: "skipped", reason: "concurrent-run"`; honor whichever the gate specifies.
 2. Verify `team-state.lead.sessionId` is populated. The `okstra.sh` exec path fills it automatically (`generate_claude_session_id` → `claude --session-id ...`). The render-only / in-session takeover path (`okstra-run` skill) auto-detects via `resolve_inproc_lead_session_id`, which is best-effort and may return empty if `~/.claude/projects/<encoded-cwd>/` is unreadable or has no jsonl yet. If `lead.sessionId` is empty at this point, write the running session's id into team-state before proceeding — Phase 7 token-usage collection depends on it and will fail with `lead jsonl not found (sessionId=)` otherwise.
 3. Decide split-pane capability, record it, then emit the phase-3 checkpoint and proceed to Phase 4. Split-pane teammates require a tmux session — this is a host capability, NOT an okstra success/failure gate, and is the only thing the removed "TeamCreate" probe should ever have been deciding:

package/runtime/prompts/lead/report-writer.md

@@ -34,7 +34,7 @@ Agent(
 )
 ```
 
-The `model:` parameter is **derived from the Report writer worker's `modelExecutionValue`** in `task-manifest.json`, mapped to an Agent family token (`opus` / `sonnet` / `haiku`) per [team-contract](./team-contract.md) "Model Assignment Rules" #3–#4. Do NOT hardcode it — the report-writer-worker definition is `model: inherit`, so without this explicit parameter the worker silently runs on the lead's model instead of its assignment. The same `modelExecutionValue` feeds the prompt header in item 6 below, so the spawn model and the recorded `**Model:**` header always agree.
+The `model:` parameter is **derived from the Report writer worker's `modelExecutionValue`** in `task-manifest.json`, mapped to an Agent family token (`opus` / `sonnet` / `haiku`) per [team-contract](./team-contract.md) "Model Assignment Rules" #3–#4. Do NOT hardcode it — the report-writer-worker definition is `model: inherit`, so without this explicit parameter the worker silently runs on the lead's model instead of its assignment. The same `modelExecutionValue` feeds the prompt header in item 7 below, so the spawn model and the recorded `**Model:**` header always agree.
 
 The prompt MUST include, in this order at the top:
 
@@ -43,18 +43,22 @@ The prompt MUST include, in this order at the top:
 3. `**Result Path:** runs/<task-type>/reports/final-report-<task-type>-<seq>.data.json` — canonical JSON SSOT. The renderer produces the sibling `.md` automatically.
 4. `**Worker Result Path:** runs/<task-type>/worker-results/report-writer-worker-<task-type>-<seq>.md` — mandatory validator-checked worker-results audit file
 5. `Assigned worker prompt history path: <absolute-path>`
-6. `**Model:** Report writer worker, <modelExecutionValue>` (resolved per Phase 5.5 anchor-header rules)
-7. The full `[Required reading]` clause (see [team-contract](./team-contract.md)) — for Phase 6 it adds two **per-task-type, instruction-set-local** read-only files, both scoped to this run's task-type by `okstra-ctl` at prep time:
+6. The three BLOCKING dispatch anchor headers the lead MUST inject (per [team-contract](./team-contract.md) headers #5 / #7 / #8 — the worker cannot synthesize the two error paths and must not dead-end when they are absent):
+   - `**Worker Preamble Path:** <absolute-path>` — the canonical Required Reading + Error Reporting SSOT at `~/.okstra/templates/worker-prompt-preamble.md`; the worker Reads it end-to-end before producing output.
+   - `**Errors log path:** <absolute-path>` — run-level errors JSONL (`logs/errors-<task-type>-<seq>.jsonl`).
+   - `**Errors sidecar path:** <absolute-path>` — this worker's per-run sidecar JSON (`worker-results/report-writer-worker-errors-<task-type>-<seq>.json`).
+7. `**Model:** Report writer worker, <modelExecutionValue>` (resolved per Phase 5.5 anchor-header rules)
+8. The full `[Required reading]` clause (see [team-contract](./team-contract.md)) — for Phase 6 it adds two **per-task-type, instruction-set-local** read-only files, both scoped to this run's task-type by `okstra-ctl` at prep time:
    - `<instruction-set>/final-report-schema.json` — a task-type excerpt of the data.json schema (the other task-types' deliverable blocks and their unreachable `$defs` are stripped; ~38% of the full schema is `$defs` alone). This is your authoring contract for the data.json shape. Do **NOT** pull the full `schemas/final-report-v1.0.schema.json` — it carries all task-types and its `schemas/...` path is not part of the task bundle. (Validation still runs against the full schema post-hoc via the renderer, so the excerpt never relaxes the contract.)
    - `<instruction-set>/final-report-template.md` — the **phase-stripped** template (every other task-type's §5.x deliverable block removed by `render.py`'s `_strip_phase_blocks`, leaving only your run's §5.x). Do **NOT** also pull the full `templates/reports/final-report.template.md` source (it re-adds ~330 lines of other phases' deliverables and is not in the task bundle).
-8. A one-line MCP pointer instead of the verbatim block — `**MCP servers:** follow the task brief's "## Available MCP Servers" section (already in your Required reading).` The brief is already in the report-writer's Required reading (item 7), so the verbatim block is redundant.
-9. The convergence classifications (Full/Partial/Contested/Worker-Unique), the round history data (`roundHistory[]`), the `round2SkippedReason` value, and pointers to all worker result files under `worker-results/`. The report-writer worker populates `crossVerification.roundHistory` in the data.json so Section 6 can show which rounds executed, queue sizes, and why Round 2 was (or was not) skipped. The renderer prints the full per-round table only when more than one round ran; single-round or zero-round histories are auto-collapsed to a one-line summary.
-10. `**Report Language:** <en|ko>` — must be either `en` or `ko`; `auto`
+9. A one-line MCP pointer instead of the verbatim block — `**MCP servers:** follow the task brief's "## Available MCP Servers" section (already in your Required reading).` The brief is already in the report-writer's Required reading (item 8), so the verbatim block is redundant.
+10. The convergence classifications (Full/Partial/Contested/Worker-Unique), the round history data (`roundHistory[]`), the `round2SkippedReason` value, and pointers to all worker result files under `worker-results/`. The report-writer worker populates `crossVerification.roundHistory` in the data.json so Section 6 can show which rounds executed, queue sizes, and why Round 2 was (or was not) skipped. The renderer prints the full per-round table only when more than one round ran; single-round or zero-round histories are auto-collapsed to a one-line summary.
+11. `**Report Language:** <en|ko>` — must be either `en` or `ko`; `auto`
     has been resolved by the lead from project.json / global config
     before the dispatch is constructed. The worker copies this verbatim
     into `data.json.meta.reportLanguage`.
-11. For implementation-planning runs: a literal block listing the 8 required English section headings the validator scans for (`Option Candidates`, `Trade-off`, `Recommended Option`, `Stepwise Execution Order`, `Dependency`, `Validation Checklist`, `Rollback`, `User Approval Request`). The writer must use these exact substrings as section headings (Korean translation in parentheses is allowed).
-12. An explicit instruction: `You are the author of TWO files: (a) the final-report data.json at <Result Path>, (b) the worker-results audit file at <Worker Result Path>. After writing the data.json, invoke "okstra render-final-report <Result Path>" via Bash so the markdown sibling is rendered before you return. Do not return the report inline. The validator fails the run when (a)'s schema validation fails, when the rendered markdown is absent, or when (b) is missing.`
+12. For implementation-planning runs: a literal block listing the 8 required English section headings the validator scans for (`Option Candidates`, `Trade-off`, `Recommended Option`, `Stepwise Execution Order`, `Dependency`, `Validation Checklist`, `Rollback`, `User Approval Request`). The writer must use these exact substrings as section headings (Korean translation in parentheses is allowed).
+13. An explicit instruction: `You are the author of TWO files: (a) the final-report data.json at <Result Path>, (b) the worker-results audit file at <Worker Result Path>. After writing the data.json, invoke "okstra render-final-report <Result Path>" via Bash so the markdown sibling is rendered before you return. Do not return the report inline. The validator fails the run when (a)'s schema validation fails, when the rendered markdown is absent, or when (b) is missing.`
 
 **Completion detection after dispatch (BLOCKING).** The `Agent(name: ..., run_in_background: true)` call returns `Spawned successfully` immediately; that ack is NOT completion. After dispatching the report-writer (async), Lead MUST detect its completion via the self-scheduled polling protocol in [team-contract](./team-contract.md) "Worker-completion detection (self-scheduled polling)", polling for the appearance of the data.json (Result Path) and the worker-results file (Worker Result Path) — do NOT restate the algorithm here. Report-writer is a single worker, so the pending set has one entry; the SSOT protocol handles that naturally. Lead MUST NOT treat the `Spawned successfully` ack as completion and MUST NOT end its turn with a prose "waiting for the report" statement; that path stalls the run until the user manually nudges it.
 
@@ -273,7 +277,9 @@ Section numbering follows `templates/reports/final-report.template.md` exactly
 - `approach` — 그래서 어떤 작업이 필요한가 (택한 방향).
 - `justification` — 왜 이게 합리적 선택인가 (대안 대비, 근거).
 
-Every field MUST anchor its claim with at least one evidence reference — a `path:line`, a report ID (`C-001` / `F-013` / `§5.4`), or another cited source already present in this report. When the evidence is genuinely insufficient, say so explicitly (`근거 불충분 — <이유>`) instead of inventing one. `validators/validate-run.py` → `_validate_rationale_evidence` fails any field carrying neither a citation nor an insufficiency marker, so an ungrounded or fabricated rationale is rejected at validation time. Do NOT restate the Verdict Card or the §5.4 trade-off matrix verbatim — this section is the *why*, in connected prose, that those tables compress.
+Every field MUST anchor its claim with at least one evidence reference — a `path:line`, an **in-report** ID (`C-001` / `E-006` / `§5.4`), or another cited source already present in this report. When the evidence is genuinely insufficient, say so explicitly (`근거 불충분 — <이유>`) instead of inventing one. `validators/validate-run.py` → `_validate_rationale_evidence` fails any field carrying neither a citation nor an insufficiency marker, so an ungrounded or fabricated rationale is rejected at validation time.
+
+**Reader-facing prose MUST NOT cite a bare brief/worker-internal ID that this report never surfaces** — `RC-*` (reporter confirmations, defined in the brief), `RF-*` / `F-*` (findings, defined in worker-results) have no anchor in the final report, so a reader hits an opaque token with nothing to click. Either expand it inline (`the confirmed version target 1.27.47→1.27.48`) or, for an audit trail, namespace it (`claude:F-005`). **Enforced:** `_validate_no_opaque_id_references` fails a bare `RC-*` / `RF-*` / non-namespaced `F-*` appearing in `verdictCard` / `finalVerdict` / `rationale` / `clarificationItems[].statement`. (The renderer anchors + links in-report IDs of any digit width, so a surfaced `RC-4`-style id does resolve.) Do NOT restate the Verdict Card or the §5.4 trade-off matrix verbatim — this section is the *why*, in connected prose, that those tables compress.
 
 0. **Clarification Response Carried In** — render this `## 0.` heading ONLY when `{{CLARIFICATION_RESPONSE_RELATIVE_PATH}}` is non-empty. Walk every `C-*` row of the prior report's `## 1. Clarification Items` table, reconcile against new evidence, and record the outcome (`resolved` / `obsolete`) with citation before drafting the verdict. When no carry-in path was provided, OMIT the `## 0.` heading entirely — the validator fails an empty Section 0 stub.
 1. **Cross Verification Results** — 4 categories (Full / Partial / Contested / Worker-Unique) when convergence is enabled, per `convergence`. Prepend the Round History sub-table (columns: `Round | inputQueueSize | resolvedCount | carriedForwardCount | dispatches | skippedWorkers`) plus a `round2SkippedReason: <value>` note, pulled verbatim from `convergence-<task-type>-<seq>.json`. Empty contested list renders as `- 합의 미달 항목 없음.`. Convergence-disabled runs use the legacy Consensus/Differences format and omit the round table.

package/runtime/prompts/profiles/_common-contract.md

@@ -55,15 +55,16 @@ profile document.
   - This step is mandatory for every phase (`requirements-discovery`, `error-analysis`, `implementation-planning`, `implementation`, `final-verification`, `release-handoff`). Whether there is anything to ask about is decided by the `--list` output, NOT by the lead's reading of `lead-pane.id`: an empty list → skip the question (above); the lead MUST NOT fabricate a synthetic pane list.
 - Run-end teammate teardown (shared — MUST run AFTER the pane disposition question and BEFORE `PROGRESS: complete`):
   - CC v2.1.178 removed `TeamCreate` / `TeamDelete`: this run rode the session's **implicit team** (Phase 3 recorded `teamCreate.status: "implicit"` plus the `teamName` audit label). There is no tool to delete a team — the implicit team ends when the session ends. What teardown CAN do is gracefully dismiss the worker teammates the lead spawned, so they stop showing as live members in the FleetView roster.
-  - **Whether to run this step is decided by on-disk fact.** The harness names the team directory `session-<leadSessionId-prefix>` (the `teamName` label never becomes a directory name). Resolve existence from disk: find the `~/.claude/teams/session-*/config.json` whose `leadSessionId` equals team-state `lead.sessionId`.
-    - **Matching on-disk config found, with members beyond the lead** → teammates exist; run the dismissal sequence below.
-    - **No matching on-disk config, or split-pane was off** → nothing to dismiss → silent-skip.
+  - **Whether to run this step is decided by on-disk fact, resolved at teardown time by the CURRENT live session — NOT from `team-state.lead.sessionId`.** The harness names the team directory `session-<leadSessionId-prefix>` (the `teamName` label never becomes a directory name), but `team-state.lead.sessionId` is only a phase-3 snapshot: Claude Code re-issues the session id across resume / compaction mid-run, so the live roster usually sits under a DIFFERENT `session-*` dir than the snapshot names. Resolving from the snapshot is what made split-pane teardown silently miss its own live teammates. The resolver in step 1 below keys off the live session (falling back to the snapshot dir only when the live one is absent) and prints the members to dismiss.
+    - **Resolver printed one or more `dismissible-member: <name>` lines** → teammates exist; run the dismissal sequence below.
+    - **Resolver printed `no live roster for this session`, or split-pane was off** → nothing to dismiss → silent-skip.
   - The pane disposition prompt above is the only user prompt for this cleanup decision. Do NOT ask a second teammate-only question.
   - On `아니오` / `n` / `keep` → dismiss nothing. Tell the user the teammates remain visible in FleetView/Teams until the session ends, and can be removed earlier from the Teams UI.
   - On `예` / `y` / `close` → emit `PROGRESS: phase-7-teardown dismissing teammates`, then run the sequence below. Token-usage collection MUST already be complete — it reads `~/.claude/projects/` jsonls, which dismissal never touches, but the read MUST precede teardown.
-    1. Run `$HOME/.okstra/bin/okstra-team-reconcile.sh "<resolved-config-path>"` — the on-disk `~/.claude/teams/session-<…>/config.json` resolved in the existence check above — exactly once. It flips dead-pane stale-active members to inactive, and no-ops when tmux is unavailable or nothing is stale. Do NOT loop it.
-    2. Send each confirmed-complete member a structured `SendMessage(to: <name>, message: { type: "shutdown_request" })` — the `message` MUST be the object literal shown, NEVER a JSON string stuffed into a text field. NEVER target the lead's own session, and never use `TaskStop` (teammates are not background tasks — `TaskStop` 404s on a member address).
+    1. Run `$HOME/.okstra/bin/okstra-team-reconcile.sh --project-root "<PROJECT_ROOT>" --fallback-team "session-<lead.sessionId-prefix>"` exactly once. It resolves the live session's `~/.claude/teams/session-<live>/config.json` (falling back to the snapshot `session-<lead.sessionId-prefix>` dir only if the live one is absent), flips dead-pane stale-active members to inactive (no-op when tmux is unavailable or nothing is stale), and prints one `dismissible-member: <name>` line per non-lead member. Do NOT loop it, and do NOT hand-resolve a config path from `team-state.lead.sessionId`.
+    2. Send each printed `dismissible-member: <name>` **whose completion is confirmed** (its Result Path exists) a structured `SendMessage(to: <name>, message: { type: "shutdown_request" })` — the `message` MUST be the object literal shown, NEVER a JSON string stuffed into a text field. NEVER target the lead's own session, and never use `TaskStop` (teammates are not background tasks — `TaskStop` 404s on a member address).
   - Claude Code exposes no tool to delete the team or surgically remove a roster entry, so a dismissed teammate may still show as an idle pill until the session ends. Do not pretend the team was deleted. If the user wants the roster gone entirely, surface the manual action: `Teams/FleetView 에서 team <teamName> 삭제`, and if tmux panes were kept earlier also show `$HOME/.okstra/bin/okstra-trace-cleanup.sh --run-dir "<RUN_DIR>"`.
+  - **Enforcement / safety net.** This teardown fires after the Phase 7 validator's window, so `validate_session_conformance.py` cannot check it (it is not a required checkpoint). The net is the `SessionEnd` hook `$HOME/.okstra/bin/okstra-team-reconcile.sh --session-end` (seeded into `settings.template.json`): when the Claude session ends it reconciles that session's roster regardless of whether this step ran, so a dead-pane member never lingers as a live pill past session end.
   - Report the outcome in one short line (e.g. `worker teammate 정리 완료`, or `stale 멤버 1명 reconcile 후 정리`) and proceed to the final `PROGRESS: complete ...` line.
 - Brief handoff contract (shared — applies whenever the run consumes a task brief produced by `okstra-brief`):
   - the brief is a **pre-discovery artifact**: it converts a domain-reporter's words (non-expert *or* developer) into expert-consumable form so this and later phases can run with zero fill-in questions to the operator. The brief is **not** authoritative on solution decisions; it is authoritative on the reporter's intent.

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

@@ -41,7 +41,7 @@
   - The YAML frontmatter `approved: true|false` field is the only authorised approval gate. report-writer always emits `approved: false`. The user clears it either by (a) editing the frontmatter line to `approved: true` directly, or (b) invoking the next phase with `--approve` so the CLI flips the frontmatter on the user's behalf. `okstra_ctl.run._validate_approved_plan` reads this field and refuses entry until it is `true`.
 - Cross-verification mode:
   - Phase 5.5 finding convergence runs in **adversarial mode** for this phase (`convergence.adversarial=true`). Verifiers actively try to refute each worker finding (requirement gap / risk / option) by re-inspecting its cited evidence; the burden of proof sits on the claim. See `prompts/lead/convergence.md` §"Adversarial Verification Mode".
-  - §5.5.9 plan-body verification runs with an **adversarial posture** (`prompts/lead/convergence.md` §"Adversarial plan-body posture"): verifiers open and confirm every cited path / command and put the burden of proof on the plan. The gate threshold is unchanged — a *majority* `DISAGREE` (`majority-disagree`) is still required to block approval; a single dissent does not.
+  - §5.5.9 plan-body verification runs with an **adversarial posture** (`prompts/lead/convergence.md` §"Adversarial plan-body posture"): verifiers open and confirm every cited path / command and put the burden of proof on the plan. The gate threshold is majority-based for kinds `b`/`c`/`e`, but a single `DISAGREE` blocks on its own for the concrete, safety-critical kinds `a` (path/symbol mismatch) / `d` (rollback order) — and `f` on `P-Req-*` items. A majority also needs ≥2 participating votes, so a lone dissent whose peer returned a non-result does not block on a majority-gated kind (see `convergence.md` §"Adversarial plan-body posture").
 {{INCLUDE:_coverage-critic.md}}
 - Non-goals:
   - code-level micro-optimization unless it changes the implementation approach
@@ -78,11 +78,11 @@
       Validator S10d rejects a missing/empty line in any of the three categories (skipped only when a `TDD exemption:` line is present). The `RED:` step below must encode these cases, not a single assertion.
   - **Per-stage subsections** (`## 5.5.<i> Stage <i>: <title>` for each `i`), each containing the four required subsections:
     - `### Carry-In` — for `depends-on (none)`: task-brief only. Otherwise: each depended-on stage's static exit contract + runtime sidecar path `runs/<impl-key>/carry/stage-<i>.json` placeholder.
-    - `### Stepwise Execution Order` — bite-sized table with `step | action | files | command | expected`. **Effective row count ≤ 8** (excluding header / divider / blank). Each step is one cohesive, self-contained change (시간 하한 없음; 함께 바뀌는 여러 파일을 포함할 수 있다); for code steps include actual code or diff sketch. **TDD ordering is MUST, not a preference:** the **first** effective step's `action` cell MUST start with the literal `RED:` and describe the failing test(s) that capture this stage's `Acceptance` **and the three declared `Test case (success|boundary|failure)` lines** (`expected` = FAIL) — the RED step encodes the case set, not a single happy-path assertion; at least one later `action` cell MUST start with the literal `GREEN:` and describe the minimal implementation that makes it pass (`expected` = PASS); an optional refactor step starts with `REFACTOR:`. **Exemption:** doc-only / config-only / pure-rename stages with no observable runtime behaviour may omit RED/GREEN by declaring one line `TDD exemption: <reason>` in the stage section (mirrors the executor's per-step exemption in `_implementation-executor.md`). Validator S10c enforces RED-first + GREEN, or the exemption line.
+    - `### Stepwise Execution Order` — bite-sized table with `step | action | files | command | expected`. **Effective row count ≤ 8** (excluding header / divider / blank). Each step is one cohesive, self-contained change (시간 하한 없음; 함께 바뀌는 여러 파일을 포함할 수 있다); for code steps include actual code or diff sketch. **TDD ordering is MUST, not a preference:** the **first** effective step's `action` cell MUST start with the literal `RED:` and describe the failing test(s) that capture this stage's `Acceptance` **and the three declared `Test case (success|boundary|failure)` lines** (`expected` = FAIL) — the RED step encodes the case set, not a single happy-path assertion; at least one later `action` cell MUST start with the literal `GREEN:` and describe the minimal implementation that makes it pass (`expected` = PASS); an optional refactor step starts with `REFACTOR:`. **Exemption:** doc-only / config-only / pure-rename stages with no observable runtime behaviour may omit RED/GREEN by declaring one line `TDD exemption: <reason>` in the stage section (mirrors the executor's per-step exemption in `_implementation-executor.md`). Validator S10c enforces RED-first + GREEN **and** that the `RED:` step's `expected` reads FAIL / the `GREEN:` step's reads PASS; S10e rejects a `TDD exemption:` whose reason is not one of doc-only / config-only / pure-rename (both in `validators/validate-implementation-plan-stages.py`).
     - **Per-stage conformance declaration (mandatory one line, in the stage section — same placement freedom as `TDD exemption:`):** the stage MUST carry exactly one of:
       - `Conformance tests: stage-<N> — <task_root>/qa/scripts/stage-<N>.<ext> (requires=[db|io|http|external,...])` — a Tier3 verification script that proves this stage's upstream requirements (brief / requirements-discovery / error-analysis / improvement-discovery → this stage's `Acceptance`) hold against **real** DB rows, real endpoints, or the real external API — NOT mocks. When you emit this line you MUST also (a) write the script to `<task_root>/qa/scripts/stage-<N>.<ext>` and (b) add a matching entry to `<task_root>/qa/conformance-manifest.json` with fields `stageKey` (= `<task-id>-stage-<N>`), `script`, `runCommand`, `requirementIds`, `requires` (subset of `{db, io, http, external}`), `passContract`, `exemption: null`, `waiver: null`. The script's standard interface: a `main` that exits `0`=PASS / non-zero=FAIL, and whose stdout ends with `QA-RESULT: PASS|FAIL` followed by one `REQ <id>: PASS|FAIL: <근거>` line per requirement. When the verification body is a test spec, author it with the project's own test framework (devDependency) invoked via a discovery override at `<task_root>/qa/scripts/` (jest: `--config <project config> --roots <task_root>/qa/scripts`) — never hand-roll `describe`/`expect` and never widen the project's own test config; for TypeScript specs also write `<task_root>/qa/scripts/tsconfig.json` extending the project tsconfig with the runner's `types` entry so editors resolve the file.
       - `Conformance exemption: <reason>` — only for stages that touch no db/io/http/external surface, or where unit tests fully cover the increment. (If the eventual `implementation` diff actually touches one of those surfaces, `validate-run.py`'s diff-surface cross-check is BLOCKING — an exemption cannot hide a real db/io/http/external change.)
-      The manifest lives at the **task level** (`<task_root>/qa/`, path token `TASK_QA_PATH`) and is shared across planning → implementation → final-verification. Layout split: executable scripts (conformance + any real-IO test) live under `<task_root>/qa/scripts/`; data sidecars (`conformance-manifest.json`, `result-*.json`) stay at the `qa/` root. This declaration is enforced at three layers: `validators/validate-implementation-plan-stages.py` check **S11** forces every stage to carry one of the two lines; the manifest JSON structure — including each entry's `script` living under `qa/scripts/` — is enforced by `validate_conformance_manifest` (called from both the run path and validate-run); and the result gate (each script's `QA-RESULT`) is enforced by the verifier Tier3 + validate-run.
+      The manifest lives at the **task level** (`<task_root>/qa/`, path token `TASK_QA_PATH`) and is shared across planning → implementation → final-verification. Layout split: executable scripts (conformance + any real-IO test) live under `<task_root>/qa/scripts/`; data sidecars (`conformance-manifest.json`, `result-*.json`) stay at the `qa/` root. This declaration is enforced at four layers: `validators/validate-implementation-plan-stages.py` check **S11** forces every stage to carry one of the two lines; at the planning boundary `validators/validate-run.py` `_validate_planning_conformance_declared` fails when a stage that declared `Conformance tests:` has no matching `-stage-<N>` entry in the shared manifest (a declaration that was never materialized); the manifest JSON structure — including each entry's `script` living under `qa/scripts/` — is enforced by `validate_conformance_manifest` (called from both the run path and validate-run); and the result gate (each script's `QA-RESULT`) is enforced by the verifier Tier3 + validate-run.
     - `### Stage Exit Contract` — predicted added/modified files, newly exposed identifiers/types/endpoints, downstream-usable resources.
     - `### Stage Validation` — pre / mid / post exact commands or observable outcomes for this stage only.
   - **Vertical-slice-first partition rule (1st-class):** the grouping anchor is a **thin end-to-end vertical slice** — one stage delivers a single user-observable increment, crossing whatever layers are needed (data → service → API → UI) to make that one increment work. File/module proximity is demoted to the **intra-slice grouping rule**: within a slice, keep steps touching the same file/directory/module together so the diff, PR, and rollback unit stay cohesive. **Horizontal layer-splitting is forbidden** — never carve "the DB layer" into one stage and "the service layer" into the next; that produces stages that ship no standalone user value. A stage is split ONLY when (a) a real `depends-on` data/contract dependency exists, (b) effective steps would exceed 8, or (c) it is a distinct vertical slice (a different user-value increment). Maximising the number of parallel stages is NOT a reason to split — parallelism is an emergent property of independent stages, never a partitioning goal.
@@ -101,13 +101,13 @@
   - **recommendedNextSteps 정책:** cross-project 선행/후속의 substance 는 `crossProjectDependencies` 에 두고, `§3 Recommended Next Steps` 에는 그 섹션(`§5.4 Cross-Project Dependencies`)을 가리키는 포인터만 둔다 — 이중 기록 금지.
   - validation checklist (pre / mid / post) — each item is an exact command or observable outcome
   - rollback strategy — exact revert path (commits, flags, migrations) and the signal that triggers rollback
-  - **Requirement Coverage (mandatory, §5.5.8):** one row per concrete requirement from the task brief / packet. Assign stable IDs `R-001`, `R-002`, ... in source order. Columns: `ID | Source | Requirement | Covered by option / stage / step | Status`. `Source` cites the brief heading or file/line where the requirement came from. `Covered by` must name the specific Option Candidate and Stage/Step that satisfies it, not just "recommended option". `Status` is one of `covered`, `gap`, or `blocked C-NNN`. If any row is `gap` or `blocked C-NNN`, the Plan Body Verification gate MUST NOT be `passed` / `passed-with-dissent`; add a matching `Blocks=approval` row for the blocker and keep `approved: false`.
+  - **Requirement Coverage (mandatory, §5.5.8):** one row per concrete requirement from the task brief / packet. Assign stable IDs `R-001`, `R-002`, ... in source order. Columns: `ID | Source | Requirement | Covered by option / stage / step | Status`. `Source` cites the brief heading or file/line where the requirement came from. `Covered by` must name the specific Option Candidate and Stage/Step that satisfies it, not just "recommended option". **Enforced:** `validators/validate-run.py` `_validate_requirement_coverage_covered_by` fails a `covered` row whose `coveredBy` is bare "recommended option", names no Option/Stage/Step anchor, or cites a Stage number absent from the Stage Map (whether the cited step *actually satisfies* the requirement remains a worker `DISAGREE(f)` judgment). `Status` is one of `covered`, `gap`, or `blocked C-NNN`. If any row is `gap` or `blocked C-NNN`, the Plan Body Verification gate MUST NOT be `passed` / `passed-with-dissent`; add a matching `Blocks=approval` row for the blocker and keep `approved: false`.
   - **Review-rule compliance plan:** when a project-local review rule pack is found, each Option Candidate MUST include the design implication of those rules in its File Structure / interfaces / blast-radius notes. For any helper or data transform used by more than one changed service, the plan must either place it in a shared module or explicitly justify why duplication is intentional. For any test step, the plan must state the observable behavior being asserted, not the internal collaborator call being pinned. For any exported/public method added or renamed, the step must carry the intended noun/side-effect semantics so implementation names can be reviewed before code is written.
   - the YAML frontmatter MUST include the line `approved: false` (report-writer always emits the unflipped value). The user authorises the next `implementation` run by flipping it to `approved: true` (manual edit or `--approve` CLI). Do NOT recreate any `User Approval Request` body block — the validator fails reports that contain one (see `validators/validate-run.py` deprecated patterns).
   - the YAML frontmatter MUST include the line `implementation-option:` directly under `approved:` (report-writer always emits it with an **empty value**). The user selects which Option Candidate the next `implementation` run executes by filling this line with that option's name (manual edit or `--implementation-option <name>` CLI). When left empty, the `implementation` run falls back to the `Recommended Option`.
   - **the frontmatter `approved: false` line is rendered unconditionally; if the plan-body verification gate (§5.5.9) returns `blocked-by-disagreement` or `aborted-non-result`, the writer MUST keep `approved: false` and the validator refuses any report that ships with `approved: true` under such a gate result.**
   - every ambiguity flagged during pre-planning that the user must resolve before approval registered as a `Blocks=approval` row in the `## 1. Clarification Items` table (do NOT create a separate `Open Questions` block under the implementation plan body — the unified table is the single home)
-  - **§5.5.9 Plan Body Verification (BLOCKING).** After report-writer finishes the draft, the lead MUST run a worker peer-review round on the consolidated plan body (Option Candidates / Trade-off Matrix / Recommended Option / Stage Map and per-stage sections / Dependency / Validation Checklist / Rollback / Requirement Coverage) and populate `### 5.5.9 Plan Body Verification` in the final report. The round protocol, plan-item ID scheme (`P-Opt-*` / `P-Step-*` / `P-Dep-*` / `P-Val-*` / `P-Rb-*`), verdict semantics, gate-result classification, and dissent log format are defined in `prompts/lead/convergence.md` "Plan-body verification mode". The four gate-result values are `passed`, `passed-with-dissent`, `blocked-by-disagreement`, `aborted-non-result`. When the gate would have been `blocked-by-disagreement` or `aborted-non-result`, the lead MUST NOT silently flip it to one of the passing values to "unblock" the run — that is a contract violation. When `convergence.adversarial=true` (the default for this phase), this round uses the adversarial posture — verifiers confirm cited paths/commands and the burden of proof is on the plan — but the gate threshold stays `majority-disagree` (see that skill's §"Adversarial plan-body posture").
+  - **§5.5.9 Plan Body Verification (BLOCKING).** After report-writer finishes the draft, the lead MUST run a worker peer-review round on the consolidated plan body (Option Candidates / Trade-off Matrix / Recommended Option / Stage Map and per-stage sections / Dependency / Validation Checklist / Rollback / Requirement Coverage) and populate `### 5.5.9 Plan Body Verification` in the final report. The round protocol, plan-item ID scheme (`P-Opt-*` / `P-Step-*` / `P-Dep-*` / `P-Val-*` / `P-Rb-*`), verdict semantics, gate-result classification, and dissent log format are defined in `prompts/lead/convergence.md` "Plan-body verification mode". The four gate-result values are `passed`, `passed-with-dissent`, `blocked-by-disagreement`, `aborted-non-result`. When the gate would have been `blocked-by-disagreement` or `aborted-non-result`, the lead MUST NOT silently flip it to one of the passing values to "unblock" the run — that is a contract violation. **Enforced:** `validators/validate-run.py` `_validate_plan_body_gate_recompute` re-derives the gate from `planItems[].verdicts` and fails when the declared `gateResult` claims a healthier outcome than the recorded votes support; `_validate_plan_item_extraction_completeness` fails when any plan-body deliverable category is under-extracted into `planItems`, so a dropped item can no longer dodge the gate. When `convergence.adversarial=true` (the default for this phase), this round uses the adversarial posture — verifiers confirm cited paths/commands and the burden of proof is on the plan — but the gate threshold stays `majority-disagree` (see that skill's §"Adversarial plan-body posture").
   - **Decision-record evaluation (sole owner)**: this phase is the **single owner** of decision-record evaluation in the okstra lifecycle. The brief never evaluates or drafts decision records — it only forwards `adr-candidate:*` signals. Every `adr-candidate:*` entry inherited from the brief's `Open Questions` is a mandatory evaluation target. In addition, evaluate every decision the recommended option introduces against the three criteria:
     1. **Hard to reverse** — would changing the decision later cost meaningfully more than deciding now?
     2. **Surprising without context** — would a future reader, seeing only the code, wonder "why was it built this way?"?
@@ -127,7 +127,7 @@
   4. **Ambiguity check** — any requirement that could be read two ways must be made explicit or moved to the `## 1. Clarification Items` table as a `Blocks=approval` row.
   5. **Scope check** — if the recommended plan now spans multiple independent subsystems, recommend splitting into separate planning runs rather than shipping an oversized plan.
   6. **Review-rule preflight check** — if a project review rule pack exists, map each relevant rule to the recommended option. Reject the draft if it knowingly creates a violation that the later PR reviewer would flag, unless the plan records a specific rationale and follow-up. In particular, scan for repeated helper stacks across planned files, tests that assert delegation to the same calculator/helper they exercise, public names that hide side effects, domain rules placed in repositories/adapters, and APIs made dead by this change.
-  7. **Plan-body verification reconciliation (BLOCKING for implementation-planning).** Inspect the `### 5.5.9 Plan Body Verification` verdict table. For every plan-item row classified as `majority-disagree → C-<N>`, the corresponding `C-<N>` row MUST exist in `## 1. Clarification Items` with `Kind` chosen per the standard policy and `Blocks=approval`. Do NOT create a parallel `Open Questions` block under the implementation plan body — the unified table is the single home. Conversely, the `Classification` column's `C-<N>` reference and the `## 1. Clarification Items` `ID` column MUST match 1:1; an orphan on either side is a contract violation. For `partial-consensus` and `worker-unique` plan-items, the dissenting opinion lives in §5.5.9 `Dissent log` and is NOT promoted to §5.
+  7. **Plan-body verification reconciliation (BLOCKING for implementation-planning).** For every §5.5.9 `planItems[]` entry whose verdicts make it `majority-disagree`, set that item's `clarificationId` to a `C-<N>` row that MUST exist in `## 1. Clarification Items` with `Kind` chosen per the standard policy and `Blocks=approval`. Do NOT create a parallel `Open Questions` block under the implementation plan body — the unified table is the single home. **Enforced:** `validators/validate-run.py` `_validate_plan_body_clarification_matching` recomputes each item's class and fails when a majority-disagree item has no `clarificationId`, or its `clarificationId` is dangling / points at a non-`approval` row. For `partial-consensus` and `dissent-isolated` plan-items, the dissenting opinion lives in §5.5.9 `Dissent log` and is NOT promoted to §5.
   8. **Stage Map self-check** — for every stage, count the effective rows of its `Stepwise Execution Order` table by hand; reject the draft if any stage exceeds 8. Confirm each stage declares a non-empty `Slice value:` and `Acceptance:` line, the three `Test case (success|boundary|failure):` lines (or carries a `TDD exemption:` line), and that its first step `action` starts with `RED:` with a later `GREEN:` — this is what validator S10 enforces, including S10d on the test-case lines. Read each stage's three test-case lines as a reviewer: reject any that restates the happy path in all three slots, leaves `boundary` blank, or writes `N/A` where a real edge input exists. Walk the `depends-on` graph and confirm it is a DAG (no cycle, no self-reference). For each `depends-on` link, confirm it encodes a real data/contract dependency — do NOT add links to serialise unrelated work, and do NOT split a stage merely to create more parallel stages. **Parallel-safety:** for every pair of `depends-on (none)` stages, confirm their `Stage Exit Contract` predicted file sets are disjoint; if they share a file, merge them or add a `depends-on` link (validator S9 rejects overlap). **Project-boundary:** confirm no stage mixes edits from two projects (different repo/`PROJECT_ROOT` or different top-level deployable module); if any stage does, split it per project. For multi-project plans, confirm each stage's `title` carries its `[<project>]` tag and the `Cross-project parallelism:` line under the table records the parallel-vs-sequenced determination (with the forcing dependency) for every project pair; for cross-repo work, confirm it is split into separate per-repo runs (required — one run structurally cannot touch another repo) rather than crammed into one task's stages.
   9. **Cross-project dependency check** — 타 repo / 다른 top-level 배포 모듈 / published 패키지에 대한 의존을 빠뜨리지 않았는지 확인한다. `dependencyMigrationRisk` 에 `kind: cross-project` 행이 있으면 매칭되는 `direction: upstream-precondition` `XP-NNN` 행이 `crossProjectDependencies` 에 있고, 그 `requiredWork` 가 추상 표현("상대 작업 완료")이 아니라 상대가 실제로 만들어야 할 구체 작업인지 reviewer 로서 다시 읽는다(validator S 가 존재만 보므로 구체성은 self-review 가 책임짐). cross-repo 작업을 한 task 의 stage 로 욱여넣지 않고 별도 run + XP 행으로 분리했는지, cross-project substance 가 `§3 Recommended Next Steps` 에 중복되지 않고 `§5.4 Cross-Project Dependencies` 에만 있는지 확인한다.
   10. **Decision-draft materialization check** — `decisionDrafts` 가 비어있지 않으면, 매칭 materialization step(`.okstra/decisions/<NNNN>-<slug>.md` 생성)이 어느 stage 의 stepwise 에 존재하는지, draft 개수와 materialization step 이 1:1 로 대응하는지 reviewer 로서 확인한다. validator 는 step 의 *존재*만 보므로 `<NNNN>-<slug>` 정확성·개수 대응은 self-review 가 책임진다.

package/runtime/python/okstra_ctl/render_final_report.py

@@ -136,10 +136,12 @@ def _yaml_inline_list(values: list[str]) -> str:
 # reference must not silently jump to the wrong row.
 _HEADING_RE = re.compile(r"^(#{1,6})[ \t]+(.*?)[ \t]*$")
 _FENCE_RE = re.compile(r"^[ \t]*(?:```|~~~)")
-_FIRST_CELL_ID_RE = re.compile(r"^[ \t]*\*{0,2}([A-Z]{1,4}-\d{3,})\b")
+_FIRST_CELL_ID_RE = re.compile(r"^[ \t]*\*{0,2}([A-Z]{1,4}-\d{1,})\b")
 # A reference token: an ID not glued to a word char / `-` on either side and
 # not prefixed by `:` (which would make it a `<worker>:<item-id>` source ref).
-_REF_ID_RE = re.compile(r"(?<![:\w-])[A-Z]{1,4}-\d{3,}(?![\w-])")
+# `\d{1,}` (not `{3,}`): short IDs like `RC-4` are valid — the old 3-digit floor
+# silently dropped them, so they could never anchor or link.
+_REF_ID_RE = re.compile(r"(?<![:\w-])[A-Z]{1,4}-\d{1,}(?![\w-])")
 
 
 def _slugify(text: str) -> str:

package/runtime/python/okstra_ctl/team_reconcile.py

@@ -16,6 +16,13 @@ CC v2.1.178 removed ``TeamDelete``: the implicit team ends with the session and
 run-end teardown only dismisses teammates via ``shutdown_request``. Reconcile
 keeps the roster honest so a dismissed-but-dead member does not linger as a
 live pill — see _common-contract.md "Run-end teammate teardown".
+
+Roster resolution (``--project-root``) exists because ``team-state.lead.sessionId``
+is a phase-3 snapshot: Claude Code re-issues the session id across resume /
+compaction mid-run, so the live on-disk roster often sits under a DIFFERENT
+``session-*`` dir than the snapshot names. Resolving by the CURRENT live session
+(the newest jsonl under the encoded-cwd projects dir) is what makes split-pane
+teardown find the teammates it must dismiss.
 """
 from __future__ import annotations
 
@@ -26,6 +33,8 @@ import sys
 import tempfile
 from pathlib import Path
 
+from okstra_ctl.session import resolve_inproc_lead_session_id
+
 
 def live_pane_ids() -> tuple[bool, set[str]]:
     """Return ``(tmux_available, live_pane_ids)``.
@@ -66,6 +75,44 @@ def reconcile_members(config: dict, live_panes: set[str]) -> list[str]:
     return flipped
 
 
+def dismissible_members(config: dict) -> list[str]:
+    """Names of every non-lead member — the set the lead may ``shutdown_request``.
+
+    The lead further filters by confirmed-complete (result path present) before
+    dismissing; this just tells it which teammates the resolved roster holds.
+    """
+    lead = config.get("leadAgentId")
+    names: list[str] = []
+    for member in config.get("members", []):
+        if member.get("agentId") == lead:
+            continue
+        names.append(member.get("name", member.get("agentId", "?")))
+    return names
+
+
+def _team_config_for_session(session_id: str) -> Path:
+    """``~/.claude/teams/session-<prefix>/config.json`` for a session id.
+
+    The harness names the team dir with the session id's first segment (the
+    8-hex stem before the first dash), never the ``teamName`` label.
+    """
+    prefix = session_id.split("-", 1)[0]
+    return Path.home() / ".claude" / "teams" / f"session-{prefix}" / "config.json"
+
+
+def _live_team_config(project_root: Path) -> Path | None:
+    """Resolve the CURRENT live session's team config, or None when absent.
+
+    Robust to the mid-run session-id drift that strands the phase-3
+    ``lead.sessionId`` snapshot: keys off the live session, not the snapshot.
+    """
+    sid = resolve_inproc_lead_session_id(project_root)
+    if not sid:
+        return None
+    cand = _team_config_for_session(sid)
+    return cand if cand.is_file() else None
+
+
 def _config_path(team_arg: str) -> Path:
     """Resolve a team name, a team dir, or a config.json path to the config file."""
     p = Path(team_arg)
@@ -92,43 +139,126 @@ def _atomic_write(path: Path, text: str) -> None:
         raise
 
 
-def main(argv: list[str]) -> int:
-    dry_run = False
-    rest: list[str] = []
-    for arg in argv:
-        if arg in ("--list", "--dry-run"):
-            dry_run = True
-        else:
-            rest.append(arg)
-    if len(rest) != 1:
-        print("usage: okstra-team-reconcile.sh [--list] <team-name|team-dir|config.json>",
-              file=sys.stderr)
-        return 2
-
-    cfg_path = _config_path(rest[0])
-    if not cfg_path.is_file():
-        print(f"team-reconcile: no team config at {cfg_path}", file=sys.stderr)
-        return 1
+def _reconcile_config(cfg_path: Path, dry_run: bool, print_members: bool) -> int:
+    """Read, reconcile, and (unless dry-run) write back one config.json.
 
+    When ``print_members`` is set, also emit one ``dismissible-member: <name>``
+    line per non-lead member so the lead knows whom to ``shutdown_request``.
+    """
     try:
         config = json.loads(cfg_path.read_text())
     except (OSError, json.JSONDecodeError) as exc:
         print(f"team-reconcile: cannot read team config at {cfg_path}: {exc}",
               file=sys.stderr)
         return 1
+
     available, live = live_pane_ids()
     if not available:
         print("team-reconcile: tmux unavailable — skipped (no flip)")
+    else:
+        flipped = reconcile_members(config, live)
+        if flipped and dry_run:
+            print("team-reconcile (dry-run): would deactivate " + ", ".join(flipped))
+        elif flipped:
+            _atomic_write(cfg_path, json.dumps(config, indent=2, ensure_ascii=False) + "\n")
+            print(f"team-reconcile: deactivated {len(flipped)} stale member(s): "
+                  + ", ".join(flipped))
+        else:
+            print("team-reconcile: no stale-active members")
+
+    if print_members:
+        for name in dismissible_members(config):
+            print(f"dismissible-member: {name}")
+    return 0
+
+
+def _session_id_from_stdin() -> str:
+    """Extract ``session_id`` from a SessionEnd hook's JSON payload on stdin.
+
+    Returns "" when stdin is a terminal (manual invocation), empty, or not the
+    expected JSON — the caller then no-ops. The hook must never block or fail a
+    session teardown.
+    """
+    if sys.stdin.isatty():
+        return ""
+    try:
+        raw = sys.stdin.read()
+    except OSError:
+        return ""
+    if not raw.strip():
+        return ""
+    try:
+        data = json.loads(raw)
+    except json.JSONDecodeError:
+        return ""
+    sid = data.get("session_id") or data.get("sessionId") or ""
+    return sid if isinstance(sid, str) else ""
+
+
+def _run_resolve_and_reconcile(project_root: str, fallback_team: str, dry_run: bool) -> int:
+    """``--project-root`` mode: resolve the live roster, reconcile, list members."""
+    cfg = _live_team_config(Path(project_root))
+    if cfg is None and fallback_team:
+        fb = _config_path(fallback_team)
+        cfg = fb if fb.is_file() else None
+    if cfg is None:
+        print("team-reconcile: no live roster for this session — nothing to dismiss")
         return 0
+    print(f"team-reconcile: roster resolved at {cfg}")
+    return _reconcile_config(cfg, dry_run, print_members=True)
+
 
-    flipped = reconcile_members(config, live)
-    if not flipped:
-        print("team-reconcile: no stale-active members")
+def _run_session_end(dry_run: bool) -> int:
+    """``--session-end`` mode: reconcile the ending session's roster from the
+    SessionEnd hook payload. Safety net so a lead that skipped run-end teardown
+    still leaves no dead-pane member lingering as a live pill."""
+    sid = _session_id_from_stdin()
+    if not sid:
         return 0
-    if dry_run:
-        print("team-reconcile (dry-run): would deactivate " + ", ".join(flipped))
+    cfg = _team_config_for_session(sid)
+    if not cfg.is_file():
         return 0
+    return _reconcile_config(cfg, dry_run, print_members=False)
 
-    _atomic_write(cfg_path, json.dumps(config, indent=2, ensure_ascii=False) + "\n")
-    print(f"team-reconcile: deactivated {len(flipped)} stale member(s): " + ", ".join(flipped))
-    return 0
+
+def _parse_argv(argv: list[str]) -> tuple[bool, str, str, bool, list[str]]:
+    dry_run = False
+    project_root = ""
+    fallback_team = ""
+    session_end = False
+    rest: list[str] = []
+    it = iter(argv)
+    for arg in it:
+        if arg in ("--list", "--dry-run"):
+            dry_run = True
+        elif arg == "--project-root":
+            project_root = next(it, "")
+        elif arg == "--fallback-team":
+            fallback_team = next(it, "")
+        elif arg == "--session-end":
+            session_end = True
+        else:
+            rest.append(arg)
+    return dry_run, project_root, fallback_team, session_end, rest
+
+
+def main(argv: list[str]) -> int:
+    dry_run, project_root, fallback_team, session_end, rest = _parse_argv(argv)
+
+    if session_end:
+        return _run_session_end(dry_run)
+    if project_root:
+        return _run_resolve_and_reconcile(project_root, fallback_team, dry_run)
+
+    if len(rest) != 1:
+        print("usage: okstra-team-reconcile.sh [--list] "
+              "(<team-name|team-dir|config.json> | --project-root <dir> "
+              "[--fallback-team <label>] | --session-end)",
+              file=sys.stderr)
+        return 2
+
+    cfg_path = _config_path(rest[0])
+    if not cfg_path.is_file():
+        print(f"team-reconcile: no team config at {cfg_path}", file=sys.stderr)
+        return 1
+    return _reconcile_config(cfg_path, dry_run, print_members=False)

package/runtime/schemas/final-report-v1.0.schema.json

@@ -1480,6 +1480,12 @@
               "id": { "type": "string", "minLength": 1 },
               "subject": { "type": "string", "minLength": 1 },
               "sourceSection": { "type": "string" },
+              "clarificationId": {
+                "anyOf": [
+                  { "type": "null" },
+                  { "type": "string", "pattern": "^C-\\d{3,}$" }
+                ]
+              },
               "verdicts": {
                 "type": "array",
                 "items": {

package/runtime/templates/reports/final-report.template.md

@@ -341,7 +341,7 @@ implementation-option: {{ frontmatter.implementationOption | yaml_scalar }}
 {{ t("implementationPlanning.planBodyBreakageLegend") }}
 
 {% for item in implementationPlanning.planBodyVerification.planItems %}
-**{{ item.id }} — {{ item.subject }}**{% if item.sourceSection %} ({{ t("implementationPlanning.planBodySourceLabel") }} {{ item.sourceSection }}){% endif %}
+**{{ item.id }} — {{ item.subject }}**{% if item.sourceSection %} ({{ t("implementationPlanning.planBodySourceLabel") }} {{ item.sourceSection }}){% endif %}{% if item.clarificationId %} — {{ t("implementationPlanning.planBodyBlockerLabel") }} {{ item.clarificationId }}{% endif %}
 
 
 | Worker | Verdict | Breakage kind | Note |

package/runtime/templates/reports/i18n/en.json

@@ -95,6 +95,7 @@
     "planBodyVerdictLegend": "Verdict — **AGREE**: executable as written and internally consistent with other items · **SUPPLEMENT**: item is sound but a dependency / edge case / precondition is missing · **DISAGREE**: has a defect (see Breakage kind) · **verification-error**: the worker produced no result.",
     "planBodyBreakageLegend": "Breakage kind — a: cited file path/symbol mismatches another step or option · b: command is not executable or is ambiguous · c: validation signal is not observable · d: rollback violates commit/dependency order · e: contradicts the trade-off matrix · f: requirement-coverage row does not map to an option/stage/step that actually satisfies the requirement. (`--` = not applicable)",
     "planBodySourceLabel": "source §",
+    "planBodyBlockerLabel": "blocks approval →",
     "optionInterfacesLabel": "Affected interfaces / public contracts / downstream consumers",
     "optionBlastRadiusLabel": "Blast radius estimate",
     "recommendedTableHeaderLabel": "Item",

package/runtime/templates/reports/i18n/ko.json

@@ -95,6 +95,7 @@
     "planBodyVerdictLegend": "판정(Verdict) — **AGREE**: 적힌 대로 실행 가능하고 다른 항목과 내부적으로 일관됨 · **SUPPLEMENT**: 항목 자체는 타당하나 의존성·엣지케이스·전제조건이 누락됨 · **DISAGREE**: 결함이 있음(결함 유형 참조) · **verification-error**: 워커 검증이 결과를 내지 못함.",
     "planBodyBreakageLegend": "결함 유형(Breakage kind) — a: 인용한 파일 경로/심볼이 다른 스텝·옵션과 불일치 · b: 명령이 실행 불가하거나 모호함 · c: 검증 신호가 관측 불가 · d: 롤백이 커밋/의존성 순서를 위반 · e: 트레이드오프 매트릭스와 모순 · f: 요구사항 커버리지 행이 요구사항을 실제로 충족하는 옵션/스테이지/스텝에 매핑되지 않음. (`--` = 해당 없음)",
     "planBodySourceLabel": "출처 §",
+    "planBodyBlockerLabel": "승인 차단 →",
     "optionInterfacesLabel": "영향 인터페이스 / 공개 계약 / 다운스트림 소비자",
     "optionBlastRadiusLabel": "폭발 반경 추정",
     "recommendedTableHeaderLabel": "항목",

package/runtime/templates/reports/settings.template.json

@@ -47,6 +47,10 @@
           {
             "type": "command",
             "command": "$HOME/.okstra/bin/okstra-trace-cleanup.sh --reap"
+          },
+          {
+            "type": "command",
+            "command": "$HOME/.okstra/bin/okstra-team-reconcile.sh --session-end"
           }
         ]
       }

package/runtime/validators/validate-brief.py

@@ -35,6 +35,8 @@ Checks performed per brief file:
     (`scripts/okstra_ctl/improvement_lenses.py` SSOT).
 12. When present, `Related Task Graph` is a markdown table with the canonical
     columns and relation/direction values from the okstra-brief contract.
+13. The requirement/objective section `## Desired Outcome` (required in every
+    brief variant) exists and its body is not blank. `_(none)_` stays valid.
 
 Exit code 0 on PASS, 1 on FAIL.
 """
@@ -391,6 +393,39 @@ def check_related_task_graph(text: str, errors: list[str]) -> None:
             )
 
 
+REQUIREMENT_SECTION = "Desired Outcome"
+
+
+def has_section_heading(text: str, heading: str) -> bool:
+    """True when a `## <heading>` line exists (distinct from an empty body)."""
+    pattern = re.compile(r"^##\s+" + re.escape(heading) + r"\s*$", re.MULTILINE)
+    return pattern.search(text) is not None
+
+
+def check_requirement_section(text: str, errors: list[str]) -> None:
+    """The requirement/objective section must exist and carry a non-blank body.
+
+    `## Desired Outcome` is the "shape of success" required by every brief
+    variant (okstra-brief SKILL.md Step 5 §"Required sections by variant").
+    Without this check a brief that drops the heading — or wipes its body —
+    still passes, letting implementation-planning report 100% Requirement
+    Coverage against an empty objective. `_(none)_` stays valid: it is the
+    contract's explicit placeholder for a deliberately-empty gap (SKILL.md
+    Step 4 stop conditions), not a missing requirement.
+    """
+    if not has_section_heading(text, REQUIREMENT_SECTION):
+        errors.append(
+            f"required section '## {REQUIREMENT_SECTION}' is missing "
+            "(every brief variant must state the shape of success)"
+        )
+        return
+    if not section_body(text, REQUIREMENT_SECTION).strip():
+        errors.append(
+            f"required section '## {REQUIREMENT_SECTION}' has an empty body "
+            "(use _(none)_ only for a deliberately-empty gap)"
+        )
+
+
 def check_reporter_confirmations(
     rc_status: str | None, reporter_rows: list[str], errors: list[str]
 ) -> None:
@@ -452,6 +487,8 @@ def validate_brief(path: Path, briefs_root: Path) -> list[str]:
 
     check_related_task_graph(text, errors)
 
+    check_requirement_section(text, errors)
+
     # 2. brief-id matches filename stem
     stem = path.stem
     if fm.get("brief-id") and fm["brief-id"] != stem:

package/runtime/validators/validate-implementation-plan-stages.py

@@ -185,7 +185,10 @@ def _check_each_stage_section(text: str, stages: List[StageMeta]) -> List[Valida
 _LABEL_PREFIX = r"^\s*(?:[-*]\s+)?(?:\*\*)?"
 SLICE_VALUE = re.compile(_LABEL_PREFIX + r"Slice value\s*:\s*(?:\*\*)?\s*(.+?)\s*$", re.M)
 ACCEPTANCE = re.compile(_LABEL_PREFIX + r"Acceptance\s*:\s*(?:\*\*)?\s*(.+?)\s*$", re.M)
-TDD_EXEMPTION = re.compile(_LABEL_PREFIX + r"TDD exemption\s*:\s*(?:\*\*)?\s*\S", re.M)
+TDD_EXEMPTION = re.compile(_LABEL_PREFIX + r"TDD exemption\s*:\s*(?:\*\*)?\s*(.+?)\s*$", re.M)
+# Profile implementation-planning.md:81 limits the exemption to these three
+# categories; any other reason (e.g. "refactor") must not waive RED/GREEN.
+TDD_EXEMPTION_ALLOWED = ("doc-only", "config-only", "pure-rename")
 TEST_CASE_CATEGORIES = ("success", "boundary", "failure")
 TEST_CASE = {
     cat: re.compile(
@@ -197,17 +200,32 @@ CONFORMANCE_TESTS = re.compile(_LABEL_PREFIX + r"Conformance tests\s*:\s*(?:\*\*
 CONFORMANCE_EXEMPTION = re.compile(_LABEL_PREFIX + r"Conformance exemption\s*:\s*(?:\*\*)?\s*\S", re.M)
 
 
+def _exemption_reason_allowed(section: str) -> bool:
+    """True when a `TDD exemption:` line is present AND its reason names an
+    allowed category (doc-only / config-only / pure-rename, case-insensitive).
+    A present-but-unlisted reason returns False so S10e can reject it."""
+    m = TDD_EXEMPTION.search(section)
+    if not m:
+        return False
+    reason = m.group(1).lower()
+    return any(cat in reason for cat in TDD_EXEMPTION_ALLOWED)
+
+
 def _check_slice_tdd(text: str, stages: List[StageMeta]) -> List[ValidationError]:
     """S10: each stage declares a vertical slice and follows RED→GREEN ordering.
 
     S10a — `Slice value:` line with a non-empty value.
     S10b — `Acceptance:` line with a non-empty value.
-    S10c — first effective Stepwise step's action starts with `RED:` AND some
-           action starts with `GREEN:`, OR a `TDD exemption:` line is present.
+    S10c — first effective Stepwise step's action starts with `RED:` (its
+           `expected` cell reading FAIL) AND some action starts with `GREEN:`
+           (its `expected` cell reading PASS), OR a valid `TDD exemption:` line.
     S10d — stage declares all three `Test case (success|boundary|failure):`
-           lines with non-empty values, OR a `TDD exemption:` line is present.
+           lines with non-empty values, OR a valid `TDD exemption:` line.
            Forces the plan to address the happy path, edge/boundary inputs, and
            failure/negative inputs instead of a single acceptance assertion.
+    S10e — a present `TDD exemption:` line's reason must name an allowed
+           category (doc-only / config-only / pure-rename); an arbitrary reason
+           must not waive RED/GREEN.
     """
     errs: List[ValidationError] = []
     for s in stages:
@@ -223,6 +241,11 @@ def _check_slice_tdd(text: str, stages: List[StageMeta]) -> List[ValidationError
                 "S10b: 'Acceptance:' line missing or empty"))
 
         if TDD_EXEMPTION.search(section):
+            if not _exemption_reason_allowed(section):
+                errs.append(ValidationError("S10", s.stage_number,
+                    "S10e: 'TDD exemption:' reason must be one of "
+                    "doc-only / config-only / pure-rename — an arbitrary reason "
+                    "cannot waive RED/GREEN"))
             continue
 
         missing_cases = [
@@ -234,14 +257,34 @@ def _check_slice_tdd(text: str, stages: List[StageMeta]) -> List[ValidationError
                 "line(s) — declare a non-empty success, boundary, and failure "
                 "case each, or add a 'TDD exemption:' line"))
 
-        rows = _effective_step_rows(section)
-        actions = [r[1] for r in rows if len(r) > 1]
-        first_is_red = bool(actions) and actions[0].startswith("RED:")
-        has_green = any(a.startswith("GREEN:") for a in actions)
-        if not (first_is_red and has_green):
-            errs.append(ValidationError("S10", s.stage_number,
-                "S10c: first step action must start with 'RED:' and some "
-                "step action with 'GREEN:', or add a 'TDD exemption:' line"))
+        errs.extend(_check_red_green_steps(section, s.stage_number))
+    return errs
+
+
+def _check_red_green_steps(section: str, stage_number: int) -> List[ValidationError]:
+    """S10c: RED-first + later GREEN, with each step's `expected` cell matching
+    its prefix (RED → FAIL, GREEN → PASS). Only certain violations fire."""
+    rows = _effective_step_rows(section)
+    steps = [(r[1], r[4]) for r in rows if len(r) > 4]
+    actions = [a for a, _ in steps]
+    first_is_red = bool(actions) and actions[0].startswith("RED:")
+    has_green = any(a.startswith("GREEN:") for a in actions)
+    errs: List[ValidationError] = []
+    if not (first_is_red and has_green):
+        errs.append(ValidationError("S10", stage_number,
+            "S10c: first step action must start with 'RED:' and some "
+            "step action with 'GREEN:', or add a 'TDD exemption:' line"))
+        return errs
+    for action, expected in steps:
+        exp = expected.upper()
+        if action.startswith("RED:") and "FAIL" not in exp:
+            errs.append(ValidationError("S10", stage_number,
+                "S10c: 'RED:' step's expected cell must read FAIL, got "
+                f"'{expected}'"))
+        elif action.startswith("GREEN:") and "PASS" not in exp:
+            errs.append(ValidationError("S10", stage_number,
+                "S10c: 'GREEN:' step's expected cell must read PASS, got "
+                f"'{expected}'"))
     return errs
 
 

package/runtime/validators/validate-run.py

@@ -861,6 +861,57 @@ def _task_root_from_run_dir(run_dir: Path) -> Path:
     return run_dir.parent.parent
 
 
+def _validate_planning_conformance_declared(report_path: Path, failures: list[str]) -> None:
+    """H4-c — at planning time, every stage that DECLARES `Conformance tests:`
+    must already carry a matching entry in the shared task-level
+    `qa/conformance-manifest.json`. The profile mandates writing the script +
+    manifest entry as part of emitting that line
+    (implementation-planning.md:83/85); without this check a declaration that
+    was never materialized only surfaces much later at the `implementation`
+    entry gate. Matches by stageKey suffix (`-stage-<N>`) like
+    `_scope_manifest_entries`; skips stages that took a `Conformance exemption:`.
+    """
+    data_path = report_path.with_suffix(".data.json")
+    if not data_path.is_file():
+        return
+    try:
+        data = json.loads(data_path.read_text(encoding="utf-8"))
+    except (OSError, json.JSONDecodeError):
+        return
+    ip = data.get("implementationPlanning")
+    if not isinstance(ip, dict):
+        return
+    declaring_stages = [
+        s.get("stage")
+        for s in (ip.get("stages") or [])
+        if isinstance(s, dict) and str(s.get("conformanceTests") or "").strip()
+    ]
+    if not declaring_stages:
+        return
+    task_root = _task_root_from_run_dir(report_path.parent.parent)
+    manifest_path = task_root / "qa" / "conformance-manifest.json"
+    entries = []
+    if manifest_path.is_file():
+        try:
+            entries = json.loads(manifest_path.read_text()).get("entries") or []
+        except (OSError, json.JSONDecodeError):
+            entries = []
+    for stage_number in declaring_stages:
+        suffix = f"-stage-{stage_number}"
+        has_entry = any(
+            isinstance(e, dict) and str(e.get("stageKey") or "").endswith(suffix)
+            for e in entries
+        )
+        if not has_entry:
+            failures.append(
+                f"final-report data.json: stage {stage_number} declares "
+                "`Conformance tests:` but no matching entry exists in "
+                f"{manifest_path} (stageKey ending `{suffix}`). Emitting the "
+                "declaration MUST also write the manifest entry + script "
+                "(implementation-planning.md §Conformance)."
+            )
+
+
 def _validate_conformance(report_path: Path, failures: list[str],
                           surface_patterns: object = None) -> None:
     """Tier 3 conformance 게이트(implementation / final-verification).
@@ -1476,6 +1527,7 @@ def validate_final_report_data(report_path: Path, failures: list[str]) -> None:
         failures.append(f"final-report data.json: {err}")
 
     _validate_rationale_evidence(data, failures)
+    _validate_no_opaque_id_references(data, failures)
 
     task_type = (data.get("header") or {}).get("taskType")
     if task_type == "final-verification":
@@ -1483,10 +1535,17 @@ def validate_final_report_data(report_path: Path, failures: list[str]) -> None:
     elif task_type == "implementation-planning":
         _validate_implementation_planning_cross_project(data, failures)
         _validate_implementation_planning_decision_drafts(data, failures)
+        _validate_plan_body_gate_recompute(data, failures)
+        _validate_plan_item_extraction_completeness(data, failures)
+        _validate_plan_item_subject_substance(data, failures)
+        _validate_plan_body_clarification_matching(data, failures)
+        _validate_requirement_coverage_covered_by(data, failures)
 
 
-# path:line (foo.service.ts:268), report ID (C-001 / F-013 / G-crit-002 / RC-1),
-# or a section reference (§5.4) — any one satisfies "this claim is anchored".
+# path:line (foo.service.ts:268), an in-report ID (C-001 / E-006 / P-004), a
+# namespaced audit ref (claude:F-005), or a §section reference (§5.4) — any one
+# satisfies "this claim is anchored". A bare brief/worker ID (RC-*/RF-*/F-*) is
+# handled separately by `_validate_no_opaque_id_references`.
 _EVIDENCE_TOKEN = re.compile(
     r"[\w./-]+\.\w+:\d+|\b[A-Z]{1,3}(?:-[a-z]+)?-\d+\b|§\s*\d")
 # Explicit "I don't know" escapes — anti-fabrication's other valid answer.
@@ -1517,12 +1576,61 @@ def _validate_rationale_evidence(data: dict, failures: list[str]) -> None:
             continue
         failures.append(
             f"final-report data.json: rationale.{field} cites no evidence "
-            f"(expected a path:line, a report ID like C-001/F-013, or a §"
+            f"(expected a path:line, an in-report ID like C-001, or a §"
             f"section reference) and gives no explicit insufficiency marker "
             f"(e.g. '근거 불충분'). Anchor the claim or state what is unknown."
         )
 
 
+# Brief/worker-internal ID families that are NOT surfaced (anchored) in the
+# final report: `RC-` reporter confirmations live in the brief, `F-`/`RF-`
+# findings live in worker-results. A reader-facing sentence citing a bare one
+# of these has no in-report target to resolve — the reader is stuck. Namespaced
+# audit citations (`claude:F-005`) are exempt via the `:` negative lookbehind.
+_OPAQUE_ID_RE = re.compile(r"(?<![:\w-])(?:RC|RF|F)-\d+(?![\w-])")
+
+
+def _reader_facing_narrative(data: dict) -> list[tuple[str, str]]:
+    """(label, text) for every reader-facing narrative string in the report —
+    the fields a human reads to act, where an unresolvable ID is most harmful."""
+    out: list[tuple[str, str]] = []
+    for section in ("verdictCard", "finalVerdict"):
+        block = data.get(section)
+        if isinstance(block, dict):
+            for field in ("finalConclusion", "nextStep"):
+                value = block.get(field)
+                if isinstance(value, str):
+                    out.append((f"{section}.{field}", value))
+    rationale = data.get("rationale")
+    if isinstance(rationale, dict):
+        for field in _RATIONALE_FIELDS:
+            value = rationale.get(field)
+            if isinstance(value, str):
+                out.append((f"rationale.{field}", value))
+    for row in data.get("clarificationItems") or []:
+        if isinstance(row, dict) and isinstance(row.get("statement"), str):
+            out.append((f"clarificationItems[{row.get('id') or '?'}].statement", row["statement"]))
+    return out
+
+
+def _validate_no_opaque_id_references(data: dict, failures: list[str]) -> None:
+    """Reader-facing prose must not cite a bare brief/worker-internal ID
+    (`RC-*`, `RF-*`, non-namespaced `F-*`) that the report never surfaces — the
+    reader has nothing to click and no definition to find. Expand it inline
+    (`the confirmed version target 1.27.47→1.27.48`) or namespace an audit
+    citation (`claude:F-005`)."""
+    for label, text in _reader_facing_narrative(data):
+        offenders = sorted({m.group(0) for m in _OPAQUE_ID_RE.finditer(text)})
+        if offenders:
+            failures.append(
+                f"final-report data.json: {label} cites brief/worker-internal "
+                f"ID(s) {', '.join(offenders)} that this report never surfaces "
+                "(no anchor to resolve them to). Expand them to plain language "
+                "on the reference, or namespace an audit citation like "
+                "`claude:F-005` — a reader cannot resolve a bare RC-/RF-/F- token."
+            )
+
+
 def _validate_implementation_planning_cross_project(data: dict, failures: list[str]) -> None:
     """타 프로젝트 의존을 DM 행(`kind == 'cross-project'`)으로 선언했다면
     `crossProjectDependencies` 에 `direction == 'upstream-precondition'` 행이
@@ -1584,6 +1692,302 @@ def _validate_implementation_planning_decision_drafts(data: dict, failures: list
         )
 
 
+# Plan-body gate outcomes ranked by how favorable each is to approval.
+# A higher rank claims a healthier verification result. The recompute check
+# below fails only when the *declared* gate outranks what the recorded
+# per-worker verdicts support — i.e. the lead claimed a better outcome than
+# the votes justify. A lead writing a conservatively *worse* gate is allowed,
+# so genuine edge cases in this recompute never manufacture false failures.
+_PLAN_GATE_RANK = {
+    "aborted-non-result": 0,
+    "blocked-by-disagreement": 0,
+    "passed-with-dissent": 1,
+    "passed": 2,
+}
+
+# Breakage kinds where a single DISAGREE blocks the gate on its own (no majority
+# needed), because the defect is concrete, safety-critical, and adversarially
+# verifiable: `a` = cited path/symbol mismatch, `d` = rollback violates
+# commit/dependency order. `b`/`c`/`e` still need a majority — `b` in particular
+# is prone to planning-vs-implementation environment false positives.
+_SINGLE_VOTE_BLOCKING_KINDS = {"a", "d"}
+
+
+def _classify_plan_item_gate(item: dict) -> str:
+    """Recompute one plan item's gate class from its per-worker verdicts,
+    per `prompts/lead/convergence.md` "Round protocol". Returns one of
+    ``majority-disagree`` / ``has-dissent`` / ``full-consensus`` /
+    ``all-non-result``. Collapses ``partial-consensus`` and
+    ``dissent-isolated`` into ``has-dissent`` because they resolve to the
+    same gate value; only the majority-disagree boundary changes the gate.
+    """
+    tokens = [
+        (
+            str(v.get("verdict") or "").strip().upper(),
+            str(v.get("breakageKind") or "").strip().lower(),
+        )
+        for v in (item.get("verdicts") or [])
+        if isinstance(v, dict)
+    ]
+    non_error = [(vd, bk) for (vd, bk) in tokens if vd and vd != "VERIFICATION-ERROR"]
+    if not non_error:
+        return "all-non-result"
+    disagree = [(vd, bk) for (vd, bk) in non_error if vd == "DISAGREE"]
+    agree = [(vd, bk) for (vd, bk) in non_error if vd in ("AGREE", "SUPPLEMENT")]
+    disagree_kinds = {bk for (_vd, bk) in disagree if bk}
+    if not disagree:
+        return "full-consensus"
+    # Single-vote-blocking kinds: one confirmed DISAGREE on a concrete,
+    # safety-critical, adversarially-verifiable defect is enough to block, even
+    # in a two-worker roster — a lone correct dissent must not be outvoted here.
+    # `a`/`d` for any item; `f` only for P-Req items (requirement coverage).
+    is_req = str(item.get("id") or "").upper().startswith("P-REQ")
+    if disagree_kinds & _SINGLE_VOTE_BLOCKING_KINDS or (is_req and "f" in disagree_kinds):
+        return "majority-disagree"
+    # Otherwise a genuine majority is required — and a majority needs at least
+    # two participating votes, so a lone surviving DISAGREE (its peer returned a
+    # non-result) does NOT block. That fixes the paradox where a worker failure
+    # made the gate stricter than a healthy roster would.
+    if len(non_error) >= 2 and len(disagree) > len(agree):
+        return "majority-disagree"
+    return "has-dissent"
+
+
+def _recompute_plan_body_gate(pbv: dict) -> str | None:
+    """Recompute the whole §5.5.9 gate value from ``planItems[].verdicts``.
+    Returns a value in ``PLAN_VERIFY_GATE_VALUES`` or ``None`` when there are
+    no plan items to judge (disabled / empty round)."""
+    classes = [
+        _classify_plan_item_gate(it)
+        for it in (pbv.get("planItems") or [])
+        if isinstance(it, dict)
+    ]
+    if not classes:
+        return None
+    if all(c == "all-non-result" for c in classes):
+        return "aborted-non-result"
+    if any(c == "majority-disagree" for c in classes):
+        return "blocked-by-disagreement"
+    if any(c == "has-dissent" for c in classes):
+        return "passed-with-dissent"
+    return "passed"
+
+
+def _validate_plan_body_gate_recompute(data: dict, failures: list[str]) -> None:
+    """H1 — the declared `Gate result` must not claim a healthier outcome than
+    the recorded per-worker verdicts support. Closes the forgery hole where a
+    lead writes `gateResult: passed` while workers actually voted DISAGREE:
+    the verdicts live in `planItems[].verdicts`, so the gate is recomputable
+    and no longer depends on the lead's honesty alone.
+    """
+    ip = data.get("implementationPlanning")
+    if not isinstance(ip, dict):
+        return
+    pbv = ip.get("planBodyVerification")
+    if not isinstance(pbv, dict):
+        return
+    declared = str(pbv.get("gateResult") or "").strip().lower()
+    recomputed = _recompute_plan_body_gate(pbv)
+    if recomputed is None or declared not in _PLAN_GATE_RANK:
+        return
+    if _PLAN_GATE_RANK[declared] > _PLAN_GATE_RANK[recomputed]:
+        failures.append(
+            "final-report data.json: implementationPlanning.planBodyVerification "
+            f"`gateResult` is `{declared}` but the recorded planItems[].verdicts "
+            f"only support `{recomputed}` (a majority DISAGREE, a DISAGREE(f) on "
+            "a P-Req item, or all-non-result dispatches were recorded). The gate "
+            "value must honestly aggregate the worker votes — do not upgrade it "
+            "to unblock the run (convergence.md Round protocol)."
+        )
+
+
+# Each plan-body deliverable array and the P-* verdict-item prefix it must be
+# extracted into for §5.5.9 cross-verification (convergence.md Plan-item
+# extraction). A weak item dropped from planItems escapes the gate entirely.
+_PLAN_ITEM_SOURCES = (
+    ("optionCandidates", "P-Opt", "Option Candidates (§4.5.1)"),
+    ("stepwiseExecution", "P-Step", "Stepwise Execution Order (§4.5.4)"),
+    ("dependencyMigrationRisk", "P-Dep", "Dependency / Migration Risk (§4.5.5)"),
+    ("validationChecklist", "P-Val", "Validation Checklist (§4.5.6)"),
+    ("rollbackStrategy", "P-Rb", "Rollback Strategy (§4.5.7)"),
+    ("requirementCoverage", "P-Req", "Requirement Coverage (§4.5.8)"),
+)
+
+
+def _validate_plan_item_extraction_completeness(data: dict, failures: list[str]) -> None:
+    """H2 — when a verification round ran, every plan-body deliverable item must
+    appear as a matching `P-*` verdict item. Closes the omission hole where the
+    lead silently drops a weak item (e.g. an out-of-order rollback) from
+    planItems so no worker ever verifies it, yet the gate still reads passed.
+    Requires only that no category is *under-extracted*; over-extraction is fine.
+    """
+    ip = data.get("implementationPlanning")
+    if not isinstance(ip, dict):
+        return
+    pbv = ip.get("planBodyVerification")
+    if not isinstance(pbv, dict):
+        return
+    round_count = pbv.get("roundCount")
+    if not isinstance(round_count, int) or round_count < 1:
+        return
+    extracted_ids = [
+        str(it.get("id") or "").upper()
+        for it in (pbv.get("planItems") or [])
+        if isinstance(it, dict)
+    ]
+    for field, prefix, label in _PLAN_ITEM_SOURCES:
+        source_count = len([r for r in (ip.get(field) or []) if isinstance(r, dict)])
+        if source_count == 0:
+            continue
+        extracted = len(
+            [i for i in extracted_ids if i.startswith(prefix.upper() + "-")]
+        )
+        if extracted < source_count:
+            failures.append(
+                f"final-report data.json: {label} has {source_count} item(s) but "
+                f"planBodyVerification.planItems carries only {extracted} "
+                f"`{prefix}-*` verdict item(s). Every plan-body item MUST be "
+                "extracted for cross-verification — a dropped item escapes the "
+                "gate (convergence.md Plan-item extraction)."
+            )
+
+
+# A `subject` this short or shaped like a bare `P-Opt-1` id is a placeholder,
+# not the plain-language "what this item is" label §5.5.9 renders as a heading.
+_MIN_SUBJECT_LEN = 3
+_BARE_PLAN_ITEM_ID_RE = re.compile(r"^P-(?:Opt|Step|Dep|Val|Rb|Req)-\d+$", re.IGNORECASE)
+
+
+def _validate_plan_item_subject_substance(data: dict, failures: list[str]) -> None:
+    """H2 follow-up — `planItems[].subject` must be a real label, not a
+    placeholder. The schema only enforces non-empty, so `"x"` or a copied
+    `P-Opt-1` id would otherwise slip through and defeat the whole point of the
+    subject (letting a reader see *what* each AGREE/DISAGREE is about).
+    """
+    ip = data.get("implementationPlanning")
+    if not isinstance(ip, dict):
+        return
+    pbv = ip.get("planBodyVerification")
+    if not isinstance(pbv, dict):
+        return
+    for item in pbv.get("planItems") or []:
+        if not isinstance(item, dict):
+            continue
+        item_id = str(item.get("id") or "").strip()
+        subject = str(item.get("subject") or "").strip()
+        if (
+            len(subject) < _MIN_SUBJECT_LEN
+            or subject == item_id
+            or _BARE_PLAN_ITEM_ID_RE.match(subject)
+        ):
+            failures.append(
+                f"final-report data.json: plan item `{item_id or '<unknown>'}` has a "
+                f"placeholder subject `{subject}`. Give a plain-language label of "
+                "what the item is (e.g. 'Option A: upload v2 를 신규 모듈로 분리') so "
+                "the §5.5.9 reader knows what each verdict is about "
+                "(convergence.md Plan-item extraction)."
+            )
+
+
+def _validate_plan_body_clarification_matching(data: dict, failures: list[str]) -> None:
+    """H5 — every plan item that the recorded verdicts make `majority-disagree`
+    must point (via `clarificationId`) at an existing `blocks: approval`
+    clarification row. Closes the hole where a majority-disagree item blocks the
+    gate but no §1 Clarification row is raised, so the user never sees why
+    approval is withheld (convergence.md self-review step 7).
+    """
+    ip = data.get("implementationPlanning")
+    if not isinstance(ip, dict):
+        return
+    pbv = ip.get("planBodyVerification")
+    if not isinstance(pbv, dict):
+        return
+    round_count = pbv.get("roundCount")
+    if not isinstance(round_count, int) or round_count < 1:
+        return
+    clar_rows = [r for r in (data.get("clarificationItems") or []) if isinstance(r, dict)]
+    all_ids = {r.get("id") for r in clar_rows if r.get("id")}
+    approval_ids = {r.get("id") for r in clar_rows if r.get("blocks") == "approval" and r.get("id")}
+    for item in pbv.get("planItems") or []:
+        if not isinstance(item, dict):
+            continue
+        if _classify_plan_item_gate(item) != "majority-disagree":
+            continue
+        item_id = item.get("id") or "<unknown>"
+        cid = item.get("clarificationId")
+        if not cid:
+            failures.append(
+                f"final-report data.json: plan item `{item_id}` is majority-disagree "
+                "but carries no `clarificationId`. A blocking disagreement MUST "
+                "surface as a `## 1. Clarification Items` row (blocks=approval) so "
+                "the user sees the blocker (convergence.md self-review step 7)."
+            )
+        elif cid not in approval_ids:
+            reason = (
+                "references a non-existent §1 row"
+                if cid not in all_ids
+                else "references a §1 row whose `blocks` is not `approval`"
+            )
+            failures.append(
+                f"final-report data.json: plan item `{item_id}` (majority-disagree) "
+                f"has clarificationId `{cid}` which {reason}. Every majority-disagree "
+                "item MUST map 1:1 to a `blocks: approval` Clarification row."
+            )
+
+
+_COVERED_BY_ANCHOR_RE = re.compile(r"option|stage|step", re.IGNORECASE)
+_COVERED_BY_STAGE_REF_RE = re.compile(r"stage\s*(\d+)", re.IGNORECASE)
+_COVERED_BY_VAGUE = {"recommended option", "the recommended option", "recommended"}
+
+
+def _validate_requirement_coverage_covered_by(data: dict, failures: list[str]) -> None:
+    """H3 (partial) — a `covered` requirement row's `coveredBy` must name a
+    concrete plan element that actually exists, not the spec-forbidden bare
+    "recommended option" nor a phantom stage. Whether the cited step truly
+    *satisfies* the requirement stays a worker DISAGREE(f) judgment; this closes
+    the coarser hole where `coveredBy` points at nothing real.
+    """
+    ip = data.get("implementationPlanning")
+    if not isinstance(ip, dict):
+        return
+    rows = [r for r in (ip.get("requirementCoverage") or []) if isinstance(r, dict)]
+    if not rows:
+        return
+    stage_numbers = {
+        s.get("stage") for s in (ip.get("stages") or []) if isinstance(s, dict)
+    }
+    for row in rows:
+        if row.get("status") != "covered":
+            continue
+        rid = row.get("id") or "<row>"
+        covered = str(row.get("coveredBy") or "").strip()
+        if covered.lower() in _COVERED_BY_VAGUE:
+            failures.append(
+                f"final-report data.json: requirementCoverage `{rid}` is `covered` "
+                f"but coveredBy is just `{covered}`. Name the specific Option "
+                "Candidate and Stage/Step that satisfies it, not 'recommended "
+                "option' (profile Requirement Coverage)."
+            )
+            continue
+        if not _COVERED_BY_ANCHOR_RE.search(covered):
+            failures.append(
+                f"final-report data.json: requirementCoverage `{rid}` coveredBy "
+                f"`{covered}` names no Option / Stage / Step. A `covered` row must "
+                "cite the concrete plan element that satisfies the requirement."
+            )
+            continue
+        phantom = [
+            n for m in _COVERED_BY_STAGE_REF_RE.finditer(covered)
+            if stage_numbers and (n := int(m.group(1))) not in stage_numbers
+        ]
+        if phantom:
+            failures.append(
+                f"final-report data.json: requirementCoverage `{rid}` coveredBy "
+                f"cites Stage {phantom[0]} which does not exist in the Stage Map. "
+                "A coverage row must point at a real stage."
+            )
+
+
 def _validate_final_verification_consistency(data: dict, failures: list[str]) -> None:
     """Enforce verdict ↔ blocker/condition/routing consistency on the
     final-verification data.json (SSOT). The schema guarantees field SHAPE;
@@ -2424,6 +2828,8 @@ def main() -> int:
             except (OSError, json.JSONDecodeError):
                 _sp = None
         _validate_conformance(report_path, failures, surface_patterns=_sp)
+    if task_type == "implementation-planning":
+        _validate_planning_conformance_declared(report_path, failures)
     if task_type == "improvement-discovery":
         brief_relative = str(task_manifest.get("taskBriefPath") or "").strip()
         brief_path = (