okstra 0.124.0 → 0.125.1

package/docs/architecture/storage-model.md

@@ -231,6 +231,8 @@ Main contents:
 This document is only a quick summary and is not the source of truth.
 Always use `task-manifest.json` when checking canonical metadata.
 
+The rendered `task-index.md` is an English-literal artifact. The headings, field labels, and `## Notes` footnote of the template (`templates/project-docs/task-index.template.md`) ship as English literals regardless of the `reportLanguage` setting, matching the okstra-schedule-gen schedule contract. The docs-publication pipeline's Hangul check (`npm run docs:validate`) enforces this contract.
+
 ## Run manifest contract
 
 Each execution records the current run contract in the resolved `<run-dir>/manifests/run-manifest-<task-type>-<seq>.json`. The non-stage or stage-qualified rule above determines `<run-dir>`.

package/docs/architecture.md

@@ -225,6 +225,10 @@ implementation-planning Phase 6
 
 Resolution is stage-scoped: only items whose `stageRefs` include the selected stage participate, so an unsafe open decision blocks that stage rather than unrelated ready stages. `no-design-inputs` resolves to `proceed`. Plans created before the `implementation-design-prep-v1` report contract also proceed with a `legacy-unassessed` warning and are not rewritten.
 
+### Fix-run incremental reverification
+
+When an implementation run is prepared on a stage whose latest final-report data.json carries one or more verifier `FAIL` verdicts, prep derives a fix-run carry (`okstra_ctl.stage_fix_carry`) — previous report path, previous run HEAD, failed verifiers, carried blocking findings, routing recommendation — and injects it into the rendered analysis profile as a "Fix-Run Carry" block via the `{{FIX_RUN_CONTEXT}}` token. Verifiers then keep the full validation-command re-run but narrow the static design/test-quality sweep to `git diff <prev-head>..HEAD` plus a mandatory re-check of each carried finding, and the report writer authors the new data.json incrementally by copying the previous one and updating only the changed blocks (`prompts/profiles/_implementation-verifier.md` § Fix-run incremental scope, `prompts/lead/report-writer.md` § Fix-run incremental authoring). A first run on a stage, or a rerun after a PASS, renders the token empty and behaves as before.
+
 ### Clarification & decision-capture discipline
 
 okstra runs a single cross-phase discipline for turning open questions into resolved decisions and durable memory. It is not one module — it is enforced at three sites that share one vocabulary, deliberately split across an interactive layer and a headless layer:
@@ -294,7 +298,7 @@ The standard `okstra` workflow applies the following team contract consistently
 - The main Claude is always the `Claude lead` and operates in synthesis-only mode.
 - The default required worker roles are `Claude worker`, `Codex worker`, and `Report writer worker`. `Antigravity worker` is optional and is included as required only when explicitly named by `--workers` or the profile's `- Workers:` section.
 - `Report writer worker` focuses on report structure and evidence organization, but `Claude lead` remains the final synthesis owner.
-- The default model contract is computed from central defaults. Fallbacks are `Claude lead`=`opus`, `Claude worker`=`opus`, `Codex worker`=`gpt-5.6-sol`, and `Antigravity worker`=`auto` (when opted in). Without a separate override, `Report writer worker` follows the `Claude lead` model (therefore `opus` by default).
+- The default model contract is computed from central defaults. Fallbacks are `Claude lead`=`opus`, `Claude worker`=`opus`, `Codex worker`=`gpt-5.6-sol`, `Report writer worker`=`sonnet`, and `Antigravity worker`=`auto` (when opted in). `Report writer worker` no longer inherits the `Claude lead` model — it resolves from its own catalog `ROLE_DEFAULTS` entry because it does not vote in convergence; `--report-writer-model opus` or `OKSTRA_DEFAULT_REPORT_WRITER_MODEL` restores the previous behavior.
 - Because `Antigravity worker` is optional, it is attempted only in runs where it is explicitly included.
 - Before the final judgment, each required role in the current run's worker roster must have either a result or an explicit terminal status (`completed`, `timeout`, `error`, `not-run`).
 - Every attempted worker (`completed`, `timeout`, `error`) must have an assigned worker prompt history file under the current run's `prompts/` directory.
@@ -782,7 +786,7 @@ Each validator blocks the phase with a `contract-violated` exit code when a cont
 - The run directory is organized into typed subdirectories such as `manifests/`, `state/`, `prompts/`, `reports/`, `status/`, `sessions/`, and `worker-results/`; prompt snapshots are prepared under `prompts/` first.
 - Claude creates workers and collects results.
 - The standard workflow uses a `Claude lead` with default workers `Claude worker`, `Codex worker`, and `Report writer worker`; `Antigravity worker` is optional and included only when explicitly requested.
-- Worker models can be overridden with `--lead-model`, `--claude-model`, `--codex-model`, `--antigravity-model`, and `--report-writer-model`; defaults are centrally managed through `OKSTRA_DEFAULT_*` environment variables. Fallback defaults are `Claude lead`/`Report writer worker`=`opus`, `Claude worker`=`opus`, `Codex worker`=`gpt-5.6-sol`, and `Antigravity worker`=`auto`.
+- Worker models can be overridden with `--lead-model`, `--claude-model`, `--codex-model`, `--antigravity-model`, and `--report-writer-model`; defaults are centrally managed through `OKSTRA_DEFAULT_*` environment variables. Fallback defaults are `Claude lead`=`opus`, `Claude worker`=`opus`, `Codex worker`=`gpt-5.6-sol`, `Report writer worker`=`sonnet`, and `Antigravity worker`=`auto`.
 - For `--task-type implementation`, select the provider that takes the Executor role with `--executor <claude|codex|antigravity>` (or `OKSTRA_DEFAULT_EXECUTOR`, fallback `claude`). Only the Executor may mutate project files. The other two providers and the Executor's own provider are each dispatched as verifiers in separate CLI sessions (session isolation preserves the self-review safeguard). The Executor's model reuses the selected provider's worker-model flag (`--claude-model` / `--codex-model` / `--antigravity-model`). Provider / displayName / workerAgent / model are recorded in the run-manifest `teamContract.executor` block.
 - Worktree cwd injection by Executor: Codex / Antigravity executors pin cwd to the worktree at the CLI layer through wrappers (`okstra-codex-exec.sh -C` / `okstra-antigravity-exec.sh --include-directories`). Because the Bash tool has no per-call cwd argument, the Claude executor prefixes cwd-sensitive toolchain invocations (`cargo`/`npm`/`pnpm`/`bun`/`pytest`/`make`/`go`) with `cd {{EXECUTOR_WORKTREE_PATH}} && <cmd>` in the same Bash invocation. Wrapping in `bash -lc`/`bash -c` is prohibited because it hides the leading `cd` token and defeats permission auto-allow. Prefer working-directory flags such as `git -C` or `cargo --manifest-path` when available. See the *Executor Worktree* block in `prompts/profiles/implementation.md` and the Executor exception in `agents/workers/claude-worker.md` for details.
 - The project-level current-task convenience pointer is `.okstra/discovery/latest-task.json`.

package/docs/cli.md

@@ -369,7 +369,7 @@ When omitted, it uses the central default `OKSTRA_DEFAULT_ANTIGRAVITY_MODEL`, fa
 ### `--report-writer-model`
 
 Selects the model used by the `Report writer worker`.
-When omitted, it uses the central default `OKSTRA_DEFAULT_REPORT_WRITER_MODEL`, falling back to the lead default.
+When omitted, it uses the central default `OKSTRA_DEFAULT_REPORT_WRITER_MODEL`, falling back to `sonnet`. The report writer does not vote in convergence, so its default sits below the lead tier to cut report-generation wall-clock; pass `--report-writer-model opus` to restore the previous behavior.
 
 The central-default environment variables are:
 
@@ -383,7 +383,7 @@ The central-default environment variables are:
 Fallback defaults are:
 
 - `Claude lead`: `opus`
-- `Report writer worker`: `opus`
+- `Report writer worker`: `sonnet`
 - `Claude worker`: `opus`
 - `Codex worker`: `gpt-5.6-sol`
 - `Antigravity worker`: `auto`

package/docs/for-ai/skills/okstra-inspect.md

@@ -3,6 +3,7 @@
 ## Source
 
 - Skill source: [`skills/okstra-inspect/SKILL.md`](../../../skills/okstra-inspect/SKILL.md)
+- Facet bodies: `skills/okstra-inspect/facets/<sub-command>.md` — the skill is a thin core (preflight + dispatch + shared rules); each sub-command's full procedure is a lazily loaded facet file, guarded by `tests/contract/test_okstra_inspect_facets.py`
 - CLI registry: [`src/cli-registry.mjs`](../../../src/cli-registry.mjs)
 - context-cost CLI: `src/commands/inspect/context-cost.mjs`
 - time-report CLI: `src/commands/inspect/time-report.mjs`

package/docs/for-ai/skills/okstra-pr-gen.md

@@ -27,12 +27,12 @@ A 3-option picker via `AskUserQuestion`:
 
 1. `Generate PR` — generate a PR body from a branch diff
 2. `Register template` — save a new PR body template
-3. `Enter manually` — always last (okstra picker convention)
+3. `Enter directly` — always last (okstra picker convention)
 
 ## Mode A — Generate PR
 
 1. Pick a template: `okstra pr template list --json`. If empty, use the bundled default. Carry the chosen name as `<template>` (`default` for the bundled one).
-2. Pick the base branch: `okstra pr branches --json`. 3-option from the top `recommended` entries plus `Enter manually`. Carry the choice as `<base>`.
+2. Pick the base branch: `okstra pr branches --json`. 3-option from the top `recommended` entries plus `Enter directly`. Carry the choice as `<base>`.
 3. Generation bundle: `okstra pr gen --base <base> --template <template> --json` → `{base, currentBranch, templateName, template, commits, diffStat}`. Then **read the real diff honestly** (SSOT): `git diff <base>...HEAD` (large diffs section by section). Fill the placeholders from the diff and commits, describing **only actual changes**. Mark a checklist box `[x]` only when the diff supports it (tests touched → tests box, docs touched → docs box). If `commits`/`diffStat` are empty, say there is nothing to describe and stop. **Never append AI trailers/footers.**
 4. Output and offer to create the PR: print the filled PR body as a single fenced markdown block. Ask whether to open a PR. **Only on an explicit yes**: write the body to a temp file and run `gh pr create --base <base> --title "<title>" --body-file <path>`. If `gh` is missing or unauthenticated (`gh auth status` fails), leave the text in chat and give manual-creation guidance. **No push/PR creation without the user's confirmation.**
 

package/docs/performance-improvement-plan-v2.md

@@ -105,7 +105,7 @@ The four default worker definitions are under `agents/workers/`.
 | B4 | Multiple renders/writes run serially during prepare | Low–medium | `scripts/okstra_ctl/run.py` render block | Lower priority |
 | B5 | The token usage collector scans session JSONL linearly | Low–medium | `scripts/okstra_token_usage/` | **Resolved** — P6 incremental cache implemented |
 | B6 | Simple work uses the same full workflow | Medium | task-type lifecycle / requirements routing | Fast-track design needed — largest remaining lever |
-| B7 | The report writer's final-report/data.json **output volume itself** is large (90–140 KB) | High | Measurements in §4.1 item 3 — 8–19 minutes of generation per run | Slim the report contract or select a report-writer model — **user decision required** |
+| B7 | The report writer's final-report/data.json **output volume itself** is large (90–140 KB) | High | Measurements in §4.1 item 3 — 8–19 minutes of generation per run | **Resolved** — default report-writer model lowered to `sonnet` (catalog `ROLE_DEFAULTS`) and a prose-budget dedup contract landed on the narrative blocks (`tests/contract/test_report_prose_budget.py`); fix runs additionally author reports incrementally (see the fix-run incremental reverification section in `docs/architecture.md`) |
 
 Established assumptions:
 
@@ -363,7 +363,7 @@ The current plan correctly makes P1 the top priority, but the earlier phrases "7
 
 **2026-06-11 update** — Measurements in §4.1 confirm that P0/P1/P6, critic parallelization, and phaseTimeline instrumentation are complete, while B3 (report-writer input compression) was rejected. Only two priorities remain, and both require a user decision first:
 
-1. **B7 — reduce report-writer output-side cost**: slim the report contract (reduce the template/schema and change validator contracts) or lower the default report-writer model. Estimated saving: 5–12 minutes per run.
+1. **B7 — reduce report-writer output-side cost**: **done** — the default report-writer model is now `sonnet`, and the prose-budget contract deduplicates the narrative blocks. Remaining follow-up if further reduction is needed: evidence pointer-ization (option B of the slimming decision).
 2. **B6/P3 — fast-track routing**: shorten the lifecycle for simple work. Requires an approval-gate policy decision.
 
 ### Implementation Plan Links

package/docs/project-structure-overview.md

@@ -54,13 +54,14 @@ okstra/
 │   ├── okstra_vendor/               vendored Jinja2 / MarkupSafe + graphify / networkx (okstra-graphify skill)
 │   ├── lib/okstra/                  Bash helpers for okstra.sh
 │   └── lib/okstra-ctl/              Bash control-center subcommands
-├── skills/                          Claude Code skills (11)
+├── skills/                          Claude Code skills (13); `_fragments/` holds shared marker blocks
 ├── agents/                          lead SKILL.md + worker agent specs
 ├── prompts/                         launch template, phase profiles, wizard prompt JSON
 ├── schemas/                         JSON schema for final-report data.json
 ├── templates/                       report, setup, PR, project-doc templates/assets
 ├── validators/                      run / brief / schedule / view validators
 ├── tools/build.mjs                  source → runtime sync
+├── tools/sync-skill-fragments.mjs   expand shared fragment blocks into skills/*/SKILL.md
 ├── tools/docs_publication/          public-manual publication pipeline (build-time only; not shipped)
 ├── config/docs-publication.json     publication inventory: every tracked Markdown path + classification
 ├── runtime/                         generated install payload; do not edit directly
@@ -220,6 +221,7 @@ Important modules:
 | `run.py` | `prepare_task_bundle()` single authority and CLI parser |
 | `implementation_stage.py` | `implementation` single-stage run orchestration — read the Stage Lifecycle Snapshot → pick an available Stage Map entry → provision an isolated stage worktree → publish the selected stage as run context (extracted from `run.py`) |
 | `stage_targets.py` | Stage readiness/verification policy SSOT — from the Stage Lifecycle Snapshot (`consumers.jsonl` ledger + carry sidecar backfill + active registry reservation) it decides which stage is runnable, which commit it branches from, and what final-verification checks. `order_stage_closure` topologically sorts (Kahn) the dependency closure of the wizard's multi-selected stage set to produce the unattended `chain-stages` chaining order |
+| `stage_fix_carry.py` | fix-run carry derivation for a re-run on an `implementation` stage whose latest final-report data.json carries verifier `FAIL` verdicts — collects the previous report path, previous run HEAD, failed verifiers, carried blocking findings, and a routing recommendation, which `run.py` renders into the analysis profile through the `{{FIX_RUN_CONTEXT}}` token. A first run, or a re-run after `PASS`, yields no carry and renders the token empty |
 | `stage_reconcile.py` | best-effort git reconciliation shared by the stage prepare flow (delegates to `git_reconcile.auto_reconcile`; advisory — failures are only reported to stderr, the dependency gate stays authoritative) |
 | `design_surfaces.py` | deterministic detection of an `implementation-planning` stage's design surface — matches the stage's file-path tokens/suffixes/patterns and action wording via `SurfaceRule` to derive which design input the stage needs among domain contract, DB/table schema, external interface, transaction/consistency, transformation mapping, lifecycle, rollout/observability, and manual user test, plus its evidence (`TriggerEvidence`). An unmappable structure raises `DesignSurfaceError` |
 | `design_prep.py` | fingerprint / materialize / resolve backend for design-preparation requests (CLI: `okstra design-prep <list\|show\|write>`) — computes an assessment fingerprint from the approved planning snapshot's `ASSESSMENT_FIELDS`, idempotently writes an Okstra-owned request under `design-prep-requests/`, and resolves the highest-revision append-only user response under `design-prep-inputs/` whose fingerprint matches as the effective response. Keeps the three authorities (report snapshot / Okstra request / user input) separate and never modifies the report or existing revisions. Sidecar I/O is protected by a directory-fd anchor + flock |
@@ -342,14 +344,16 @@ Optional (v1.0 backward-compatible) top-level keys:
 
 ### 4.10 `skills/`
 
-13 user-facing skills (the only skills `okstra install` copies). The list SSOT is `USER_SKILL_NAMES` in `src/lib/skill-catalog.mjs`; the Claude plugin manifest and the installer both derive from it:
+13 user-facing skills (the only skills `okstra install` copies). The list SSOT is `USER_SKILL_NAMES` in `src/lib/skill-catalog.mjs`; the Claude plugin manifest and the installer both derive from it.
+
+Boilerplate shared by several skills (bash invocation rule, outdated-CLI preflight, python bootstrap note) is kept canonical in `skills/_fragments/*.md` and expanded in place inside each `SKILL.md` between `<!-- BEGIN FRAGMENT: <name> -->` / `<!-- END FRAGMENT: <name> -->` markers by `tools/sync-skill-fragments.mjs` (`--check` fails on drift). Sources stay fully expanded, so `runtime/` and installed copies remain self-contained; the guards are `tests-js/skill-fragments.test.mjs` and `tests/contract/test_prompt_fragment_ownership.py`.
 
 | Skill | User-invocable | Role |
 |---|---:|---|
 | `okstra-brief-gen` | yes | Produce task brief from ticket/doc/link/conversation |
 | `okstra-run` | yes | Start/resume okstra task in current Claude Code session |
 | `okstra-memory` | yes | Store/search/archive global conversation memory under `~/.okstra/memory-book` |
-| `okstra-inspect` | yes | Unified read-side — sub-commands `status` (lifecycle + workStatus), `history` (past runs / re-run / resume), `report` (find final-report), `time` (elapsed-time breakdown), `logs` (wrapper log inventory + cleanup), `cost` (task bundle context/read cost) |
+| `okstra-inspect` | yes | Unified read-side — sub-commands `status` (lifecycle + workStatus), `history` (past runs / re-run / resume), `report` (find final-report), `time` (elapsed-time breakdown), `logs` (wrapper log inventory + cleanup), `cost` (task bundle context/read cost), `errors` (error-log aggregation), `error-zip` (anonymized cross-project error bundle), `recap` (cross-run phase recap). `SKILL.md` is a thin core (preflight + dispatch table + shared rules) and each sub-command body lives in `skills/okstra-inspect/facets/<sub-command>.md`, lazily read only after dispatch resolves; the 1:1 match between dispatch rows and facet files is enforced by `tests/contract/test_okstra_inspect_facets.py` |
 | `okstra-rollup` | yes | Cross-task roll-up — aggregate runs/time/errors across a task-group (or whole project) and synthesize a digest from the report files |
 | `okstra-usage` | yes | Read-only project usage snapshot — aggregate recent run coverage, tokens, known cost, CPU, and wall-clock time by task type (default: 30 days) |
 | `okstra-schedule-gen` | yes | Generate task-group schedule |

package/package.json

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

package/runtime/BUILD.json

@@ -1,5 +1,5 @@
 {
-  "package": "0.124.0",
-  "builtAt": "2026-07-19T03:50:18.974Z",
+  "package": "0.125.1",
+  "builtAt": "2026-07-20T08:47:14.936Z",
   "repoRoot": "/home/runner/work/okstra/okstra"
 }

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

@@ -93,7 +93,7 @@ options:
   --codex-model        Model for Codex worker. Default: OKSTRA_DEFAULT_CODEX_MODEL or gpt-5.6-sol
   --antigravity-model       Model for Antigravity worker. Default: OKSTRA_DEFAULT_ANTIGRAVITY_MODEL or gemini-3.1-pro
   --report-writer-model
-                      Model for report writer worker. Default: OKSTRA_DEFAULT_REPORT_WRITER_MODEL or lead model default
+                      Model for report writer worker. Default: OKSTRA_DEFAULT_REPORT_WRITER_MODEL or sonnet
   --lead-runtime      Lead runtime adapter. Default: claude-code.
                       codex is currently render-only and records Codex adapter
                       metadata in prepared artifacts without dispatching workers.

package/runtime/bin/okstra-antigravity-exec.sh

@@ -254,6 +254,16 @@ mkfifo "$stdout_fifo"
 tee -a "$log_path" < "$stdout_fifo" &
 stdout_tee_pid=$!
 
+# Disable git's fsmonitor for every git command agy runs in this process tree —
+# the main worktree's fsmonitor daemon leaks its IPC socket into task worktrees,
+# so git status/commit here intermittently fail with `fsmonitor_ipc__send_query`
+# errors. GIT_CONFIG_* scopes the override to this process tree without touching
+# the user's repo config. See `okstra-codex-exec.sh` for the full rationale.
+_gc_idx="${GIT_CONFIG_COUNT:-0}"
+export "GIT_CONFIG_KEY_${_gc_idx}=core.fsmonitor"
+export "GIT_CONFIG_VALUE_${_gc_idx}=false"
+export GIT_CONFIG_COUNT="$(( _gc_idx + 1 ))"
+
 agy --print "$(cat "$prompt_path")" --model "$model" "${add_dir_args[@]}" \
   --print-timeout "$PRINT_TIMEOUT" --dangerously-skip-permissions \
   2>> "$log_path" \

package/runtime/bin/okstra-codex-exec.sh

@@ -328,6 +328,18 @@ mkfifo "$stdout_fifo"
 tee -a "$log_path" < "$stdout_fifo" &
 stdout_tee_pid=$!
 
+# Disable git's fsmonitor for every git command codex runs in this process
+# tree. The main worktree's fsmonitor daemon leaks its IPC socket into task
+# worktrees, so git status/commit here intermittently fail with
+# `fsmonitor_ipc__send_query` errors (workers otherwise recover by hand with
+# `git -c core.fsmonitor=false`). Injecting it via GIT_CONFIG_* scopes the
+# override to this process tree without touching the user's repo config, and
+# appends after any GIT_CONFIG_* the caller already set.
+_gc_idx="${GIT_CONFIG_COUNT:-0}"
+export "GIT_CONFIG_KEY_${_gc_idx}=core.fsmonitor"
+export "GIT_CONFIG_VALUE_${_gc_idx}=false"
+export GIT_CONFIG_COUNT="$(( _gc_idx + 1 ))"
+
 codex exec -C "$project_root" ${extra_args[@]+"${extra_args[@]}"} --model "$model" --sandbox workspace-write -c approval_policy=never - \
   < "$prompt_path" \
   2>> "$log_path" \

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

@@ -124,7 +124,7 @@ The table below documents those prep-time seed values **for reference only** —
 | Role | Seed model | Worker assignment | Source definition |
 |------|-----------|---------------|-------------------|
 | Lead role | opus | -- | runtime-specific role label; orchestration + convergence supervision + final-report review/approval |
-| Report writer worker | opus | report-writer-worker | `agents/workers/report-writer-worker.md` |
+| Report writer worker | sonnet | report-writer-worker | `agents/workers/report-writer-worker.md` |
 | Claude worker | opus | claude-worker | `agents/workers/claude-worker.md` |
 | Codex worker | gpt-5.6-sol | codex-worker | generated from `agents/workers/_cli-wrapper-template.md` + `codex-worker.params.json` |
 | Antigravity worker | auto | antigravity-worker | generated from `agents/workers/_cli-wrapper-template.md` + `antigravity-worker.params.json` |

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

@@ -53,6 +53,9 @@ The prompt MUST include, in this order at the top:
     into `data.json.meta.reportLanguage`.
 12. For implementation-planning runs: a literal block listing the 10 required English section headings (`Option Candidates`, `Trade-off`, `Recommended Option`, `Stepwise Execution Order`, `Dependency`, `Validation Checklist`, `Rollback`, `User Approval Request`, `Plan Body Verification`, `Implementation Design Preparation`). The writer uses these exact substrings as section headings (Korean translation in parentheses is allowed), and the `Plan Body Verification` section carries its required `Gate result:` line.
 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>" through the available execution interface 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.`
+14. The prose budget (dedup contract): `verdictCard.finalConclusion` is the conclusion SSOT — at most 3 sentences. `rationale.*` fields stay within 2 sentences each and reference the verdict card / row IDs instead of restating their prose; `readerSummary` fields are one line each; `summary` stays at 3-5 rows unless the run covers multiple tickets. The schema field descriptions carry the same budgets (`tests/contract/test_report_prose_budget.py` guards both surfaces). Generation time scales with output volume, so exceeding the budget is a cost bug, not extra diligence.
+
+**Fix-run incremental authoring (applies when the run's profile carries a "Fix-Run Carry" block).** Do not author the data.json from scratch. Start by copying the previous run's data.json (the `Previous report` path in the Fix-Run Carry block) to this run's Result Path, then update ONLY the blocks the fix run changed: `meta`/`header` (run seq, dates), `executionStatus`, `implementation.verifierResults`, `implementation.validationEvidence`, `implementation.commitList` / `diffSummary`, `crossVerification`, `verdictCard`, `finalVerdict`, and any `evidence` rows the fix touched. Deliverable prose for unchanged sections is carried forward verbatim — do not re-generate it. Then invoke the renderer exactly as in a full run. The schema validation and renderer contract are unchanged, so an incrementally-authored data.json passes the same post-hoc gates. The lead's dispatch prompt MUST include the previous data.json path when the carry block is present.
 
 **Completion detection after dispatch (BLOCKING).** A dispatch acknowledgement is NOT completion — detect completion via the SSOT protocol in [team-contract](./team-contract.md) "Worker-completion detection", with a one-entry pending set covering the data.json (Result Path) and the worker-results file (Worker Result Path). Do NOT end the turn with a prose "waiting for the report" statement.
 
@@ -104,7 +107,7 @@ The four Phase 7 steps below MUST execute in this exact order. Reordering them i
    - When the report has **no** `C-*` clarification rows and is **not** a Plan Approval widget target, the html carries no interactive forms (it would only duplicate the MD), so the renderer prints `html: skipped (...)` and writes nothing. This is the expected state for such runs — `validators/validate-report-views.py` treats "no C-* rows + no approval target + no html" as a pass, not a missing artifact.
 
    This step runs after usage collection so token placeholders are substituted in any rendered html and before routing persistence so the html artifact, when generated, exists for the validator step that checks it.
-3. **Complete routing and follow-up persistence.** Run the follow-up task spawner when Section 4 is non-empty. It turns the report's `## 4. Follow-up Tasks (Follow-up Tasks)` rows into `tasks/<task-group>/<new-task-id>/` stubs.
+3. **Complete routing and follow-up persistence.** Run the follow-up task spawner when Section 4 is non-empty. It turns the report's `## 4. Follow-up Tasks` rows into `tasks/<task-group>/<new-task-id>/` stubs.
 
    ```bash
    okstra spawn-followups \
@@ -194,9 +197,9 @@ Token Summary Generation Rules:
   CLI `--report-language` flag is given.
 - All values come from `usageSummary` (populated by `scripts/okstra-token-usage.py` at the start of Phase 7). Do not estimate or invent.
 - **Lead** row: `usageSummary.leadTotalTokens` / `usageSummary.leadBillableEquivalentTokens` / `usageSummary.estimatedCostUsd.lead`.
-- **Worker subtotal** (ko: `Worker subtotal`) row: `usageSummary.workerTotalTokens` / `usageSummary.workerBillableEquivalentTokens` / `usageSummary.estimatedCostUsd.claudeWorkers`.
-- **Grand total** (ko: `Grand total`) row: `usageSummary.grandTotalTokens` / `usageSummary.grandBillableEquivalentTokens` / sum of `lead + claudeWorkers`.
-- **Codex/Antigravity CLI add-on** (ko: `Codex/Antigravity CLI add-on cost`) row: `usageSummary.estimatedCostUsd.cliWorkers`. If 0, still show the row so the reader sees that no CLI work was billed under those providers (or that CLI fallback occurred).
+- **Worker subtotal** row: `usageSummary.workerTotalTokens` / `usageSummary.workerBillableEquivalentTokens` / `usageSummary.estimatedCostUsd.claudeWorkers`.
+- **Grand total** row: `usageSummary.grandTotalTokens` / `usageSummary.grandBillableEquivalentTokens` / sum of `lead + claudeWorkers`.
+- **Codex/Antigravity CLI add-on** row: `usageSummary.estimatedCostUsd.cliWorkers`. If 0, still show the row so the reader sees that no CLI work was billed under those providers (or that CLI fallback occurred).
 - Format tokens with comma separators (e.g., `32,500`); format USD with two decimals (e.g., `$1.43`).
 - If `lead` or any `worker.usage` records unavailable evidence, show `--` for that row and append a one-line note (`reason: <note>`).
 - If pricing for a model is unknown, the script omits `estimatedCostUsd` for that block — show `N/A` in that column and add a note like `pricing missing for model <model>`.
@@ -207,16 +210,16 @@ When the run's `task-type` is `implementation-planning`, the final report MUST c
 
 | # | Required substring | Recommended heading form |
 |---|--------------------|--------------------------|
-| 1 | `Option Candidates` | `### Option Candidates (Option Candidates)` |
-| 2 | `Trade-off` | `### Trade-off Matrix (Trade-off Matrix)` |
-| 3 | `Recommended Option` | `### Recommended Option (Recommended Option)` |
-| 4 | `Stepwise Execution Order` | `### Stepwise Execution Order (Stepwise Execution Order)` |
-| 5 | `Dependency` | `### Dependency / Migration Risk (Dependency / Migration Risk)` |
-| 6 | `Validation Checklist` | `### Validation Checklist (Validation Checklist)` |
-| 7 | `Rollback` | `### Rollback Strategy (Rollback Strategy)` |
+| 1 | `Option Candidates` | `### Option Candidates (Korean gloss)` |
+| 2 | `Trade-off` | `### Trade-off Matrix (Korean gloss)` |
+| 3 | `Recommended Option` | `### Recommended Option (Korean gloss)` |
+| 4 | `Stepwise Execution Order` | `### Stepwise Execution Order (Korean gloss)` |
+| 5 | `Dependency` | `### Dependency / Migration Risk (Korean gloss)` |
+| 6 | `Validation Checklist` | `### Validation Checklist (Korean gloss)` |
+| 7 | `Rollback` | `### Rollback Strategy (Korean gloss)` |
 | 8 | `User Approval Request` | Satisfied by the top-of-report `## User Approval Request (User Approval Gate)` block. Do NOT recreate a `### 5.5.8 User Approval Request` body stub — the validator now fails reports that contain one. |
-| 9 | `Plan Body Verification` + `Gate result:` | `### Plan Body Verification (Plan Body Verification)` containing a `Gate result:` line — copy `templates/reports/final-report.template.md §5.5.9` verbatim. Validator checks both substrings. |
-| 10 | `Implementation Design Preparation` | `### Implementation Design Preparation (Implementation Design Preparation)` — rendered from `implementationPlanning.designPreparation` by `templates/reports/final-report.template.md §5.5.10`. |
+| 9 | `Plan Body Verification` + `Gate result:` | `### Plan Body Verification (Korean gloss)` containing a `Gate result:` line — copy `templates/reports/final-report.template.md §5.5.9` verbatim. Validator checks both substrings. |
+| 10 | `Implementation Design Preparation` | `### Implementation Design Preparation (Korean gloss)` — rendered from `implementationPlanning.designPreparation` by `templates/reports/final-report.template.md §5.5.10`. |
 
 The Korean translation in parentheses is optional but the English keyword is mandatory. The body of each section is written in the Report Language per the writing rules below. For non-`implementation-planning` runs, omit this entire block — these headings are NOT validator-checked for other task-types.
 

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

@@ -102,6 +102,32 @@ Re-running commands proves the diff *builds and passes*; it does NOT prove the d
 - **Advisory findings (recorded as recommendations; verdict MAY still PASS):** function >50 effective lines, a single body mixing read+write stages, weak readability, a missing-but-non-critical outcome assertion, newly orphaned private/public code that is safe to remove but not on a critical path, or weak-but-not-misleading names. These land in the verifier result as `should-fix` / `nit` recommendations, not as a `FAIL`.
 - **Output.** Every finding — blocking or advisory — is a structured item in the verifier's worker result (`path:line`, rule, severity, suggested fix) so it carries into Phase 5.5 convergence and the final report. A blocking hit sets the verifier verdict to `FAIL` with the rule cited, using the same verdict machinery as the Discrepancy rule above. `Claude lead` MUST NOT silently downgrade a cited blocking finding to advisory during synthesis; an override requires a concrete cited reason, exactly as for the Discrepancy rule.
 
+### Fix-run incremental scope (applies when the profile carries a "Fix-Run Carry" block)
+
+A fix run re-verifies a stage whose previous run already passed a full static
+sweep and failed only on cited blocking findings. Re-sweeping the whole stage
+diff re-buys wall-clock without new information, so the static scope narrows —
+the command re-run does not:
+
+- **Command re-run stays full.** Every Tier 1/2/3 command from the plan's
+  validation set runs end-to-end exactly as in a first run. QA-RESULT gating
+  (`validate-run.py` Tier 3) is unchanged.
+- **Static design & test-quality sweep narrows to the fix diff.** Enumerate
+  `git diff <prev-head>..HEAD` (the `Previous run HEAD` line of the Fix-Run
+  Carry block) instead of the whole stage diff, and re-check each carried
+  blocking finding against the current tree. The blocking/advisory taxonomy
+  above applies unchanged to that narrowed file set.
+- **Carried findings drive the verdict.** Every carried blocking finding MUST
+  be re-checked and cited in the verifier result as `resolved` (with the fix
+  commit) or `still-failing` (verdict `FAIL`). A new blocking defect inside
+  the fix diff also forces `FAIL`. Files untouched since `<prev-head>` are
+  out of static-sweep scope — they already passed the previous full sweep.
+
+Enforcement: the carried-finding re-check lands in the verifier result file
+(Phase 5.5 convergence consumes it); a fix-run verifier result that cites no
+carried findings is a contract violation the lead records via
+`okstra error-log append-observed --error-type contract-violation`.
+
 ### DB / IO / SQL change — real-execution gate (mock-only acceptance forbidden)
 
 A mocked unit test cannot observe the SQL a query builder actually emits — `count({ col: 'FontFamily.fontFamily' })` passes a mocked suite yet throws `Unknown column` on a real database. For this class of change a green mock-only suite is therefore NOT evidence; only a run against a real (or faithful-replica) datastore is. This gate is the verifier's enforcement of that rule.

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

@@ -104,13 +104,13 @@
     - **Different repos** — a single okstra task **cannot** span repos: every stage worktree is a `git worktree add` in one repo's main checkout (one `<project-id>`), the run-index / manifests / registry are keyed to that one project, and the edit allowlist only covers that project's tree plus `~/.okstra/worktrees/**`. This is a structural limit, not a style preference. Therefore cross-repo work MUST be split into **a separate okstra run per repo** — never modelled as stages of one task. State, in the Stage Map `Cross-project parallelism:` line, whether those per-repo runs can proceed in parallel. To avoid re-deriving shared analysis, the second repo's run should consume the first run's relevant plan/decision artifacts as brief Source Material (see the cross-project dependency rows below).
     - **Parallel-feasibility check (mandatory for every multi-project plan):** disjoint files (S9 below) is necessary but NOT sufficient for parallelism — a cross-project API/contract/schema/deploy-order dependency forces sequencing even when no file overlaps. For each pair of projects, explicitly determine and record (in the `Cross-project parallelism:` line) whether they are independent (run in parallel) or sequenced (and the exact dependency that forces the order).
   - **Parallel-safety invariant (BLOCKING):** any two stages that are both `depends-on (none)` MUST predict disjoint file sets in their `Stage Exit Contract`. Two parallel `implementation` runs would otherwise edit the same file concurrently. Work touching a shared file must either go in one stage or be ordered with `depends-on`. Enforced by `validators/validate-implementation-plan-stages.py` check S9.
-  - **Cross-project dependency rows (`crossProjectDependencies` array — replaces the old `## Cross-Repo Carry` appendix):** a dependency on another project (a different repo / a different top-level independently-deployable module / a published package) is recorded not as the freeform `## Cross-Repo Carry` appendix but as an **`XP-NNN` row of the structured field `crossProjectDependencies`**. Put one XP row per project dependency and fill in whichever `direction` applies (rendered as `### Cross-Project Dependencies` §5.4; a single-project plan uses an empty array). The row fields replace the old three subsections with — `requiredWork` (the concrete work the other side must build) / `verificationSignal` (the signal this run will observe) / `linkedWork` (the stage·step of this plan that is blocked until the signal is met) / `howToStart` (the exact handoff in the other repo).
-    - `direction: upstream-precondition` — this run **waits on the other side's prerequisite work (precondition required)**: `requiredWork` = the concrete work the other side must implement first, `verificationSignal` = the signal this run must observe before proceeding (PR merged / endpoint live / version published), `linkedWork` = the stage·step of this plan that is blocked until the signal is met, `howToStart` = in the other repo, `okstra-brief-gen` (**cite this report's absolute path as Source Material** — the only permitted cross-`<PROJECT_ROOT>` read) → `okstra-run`.
-    - `direction: downstream-carry` — this run **produces what the other side will consume (the existing carry)**: `requiredWork` = the self-contained B-portion the other side will implement next (from the other side's perspective, a new `R-NNN`·proposed stages·affected files), `verificationSignal` = the (this-run-delivered) signal the other side confirms before proceeding, `linkedWork` = the stage·step of this plan that delivers that signal, `howToStart` is the same as upstream. Do not hand over this run's already-`done` stages as if they were the other side's stages — include only the portion the other side still has to build.
+  - **Cross-project dependency rows (`crossProjectDependencies` array — replaces the old `## Cross-Repo Carry` appendix):** a dependency on another project (a different repo / a different top-level independently-deployable module / a published package) is recorded not as the freeform `## Cross-Repo Carry` appendix but as an **`XP-NNN` row of the structured field `crossProjectDependencies`**. Put one XP row per project dependency and fill in whichever `direction` applies (rendered as `### Cross-Project Dependencies` §5.4; a single-project plan uses an empty array). The row fields replace the old three subsections with — `requiredWork` (the concrete work the other side must build) / `verificationSignal` (the signal this run will observe) / `linkedWork` (the stage/step of this plan that is blocked until the signal is met) / `howToStart` (the exact handoff in the other repo).
+    - `direction: upstream-precondition` — this run **waits on the other side's prerequisite work (precondition required)**: `requiredWork` = the concrete work the other side must implement first, `verificationSignal` = the signal this run must observe before proceeding (PR merged / endpoint live / version published), `linkedWork` = the stage/step of this plan that is blocked until the signal is met, `howToStart` = in the other repo, `okstra-brief-gen` (**cite this report's absolute path as Source Material** — the only permitted cross-`<PROJECT_ROOT>` read) → `okstra-run`.
+    - `direction: downstream-carry` — this run **produces what the other side will consume (the existing carry)**: `requiredWork` = the self-contained B-portion the other side will implement next (from the other side's perspective, a new `R-NNN`, proposed stages, and affected files), `verificationSignal` = the (this-run-delivered) signal the other side confirms before proceeding, `linkedWork` = the stage/step of this plan that delivers that signal, `howToStart` is the same as upstream. Do not hand over this run's already-`done` stages as if they were the other side's stages — include only the portion the other side still has to build.
     - **A cross-repo dependency cannot be expressed with `depends-on`:** that gate only resolves commits inside a single repo's git graph (`scripts/okstra_ctl/run.py` `_resolve_stage_base_commit`), so it cannot point at a commit in another repo. Cross-repo work is split into a separate okstra run + XP row rather than a stage (the Different-repos rule). The other run is structurally independent, so it does not automatically recognise this run's completed stages as `done` (nor should it — that is this repo's work); the XP row is only a narrative input that seeds the other side's planning. This run does not write to the other repo's tree or its `.okstra/` (it emits only this report's XP rows). The old "Recognition caveat" wording has been moved into a render note (i18n `crossProjectRecognitionNote`) and is emitted automatically in the `### Cross-Project Dependencies` section.
   - **Stage exit contract is the carry surface:** keep it as narrow as possible. Wider surface = more downstream coupling.
   - dependency / migration risk assessment (ordering constraints, data backfills, feature-flag prerequisites, repo-internal sequencing)
-  - **Cross-Project Dependencies (conditionally required):** when the plan depends on work in another project / repo / published package, add (a) a `kind: cross-project` DM row to `dependencyMigrationRisk`, and (b) a matching `XP-NNN` row to `crossProjectDependencies`. An upstream-precondition row must have concrete `requiredWork`·`verificationSignal`·`howToStart` — `validators/validate-run.py` enforces that a DM `cross-project` ⇒ at least one `direction: upstream-precondition` XP row, and the schema enforces non-empty row fields. A cross-project dependency is recorded as this structured precondition, not as a soft Recommended Next Step. A single-project plan uses an empty array.
+  - **Cross-Project Dependencies (conditionally required):** when the plan depends on work in another project / repo / published package, add (a) a `kind: cross-project` DM row to `dependencyMigrationRisk`, and (b) a matching `XP-NNN` row to `crossProjectDependencies`. An upstream-precondition row must have concrete `requiredWork` / `verificationSignal` / `howToStart` — `validators/validate-run.py` enforces that a DM `cross-project` ⇒ at least one `direction: upstream-precondition` XP row, and the schema enforces non-empty row fields. A cross-project dependency is recorded as this structured precondition, not as a soft Recommended Next Step. A single-project plan uses an empty array.
   - **recommendedNextSteps policy:** keep the substance of cross-project preconditions/carries in `crossProjectDependencies`, and put in `§3 Recommended Next Steps` only a pointer to that section (`§5.4 Cross-Project Dependencies`) — no double recording.
   - 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

package/runtime/prompts/profiles/implementation.md

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

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

@@ -63,5 +63,4 @@
   - full implementation design unless it is required to decide the next phase
   - **source code edits, plan authoring, builds, or deployments** — this run only classifies the work and routes it; deeper analysis and planning belong to subsequent phases
   - **writes outside `<PROJECT_ROOT>/.okstra/`** — this phase only uses okstra's artifact root. Glossary additions land in `<PROJECT_ROOT>/.okstra/glossary.md` (via `okstra-brief-gen` Step 4.5); decision drafts land in `<PROJECT_ROOT>/.okstra/decisions/` (via `implementation-planning`).
-  - work-unit decomposition (fan-out) is in-scope for this phase — but each unit's *solution design*·source
-    edits·plan authoring remain non-goals and are handled by downstream phases
+  - work-unit decomposition (fan-out) is in-scope for this phase — but each unit's *solution design*, source edits, and plan authoring remain non-goals and are handled by downstream phases

package/runtime/python/okstra_ctl/models.py

@@ -61,10 +61,12 @@ CODEX = {
 PROVIDER_MAPPINGS = {"claude": CLAUDE, "antigravity": ANTIGRAVITY, "codex": CODEX}
 
 # ROLE-keyed (not provider): 1:1 with run.py recommended_role_models. "lead" uses
-# the claude provider; "report-writer" is role-only (None → caller uses lead's).
+# the claude provider; "report-writer" resolves via the claude provider too.
+# report-writer defaults below the lead tier on purpose: it does not vote in
+# convergence, and its wall-clock is dominated by sheer report generation.
 ROLE_DEFAULTS = {
     "lead": "opus", "claude": "opus", "codex": "gpt-5.6-sol",
-    "antigravity": "gemini-3.1-pro", "report-writer": None,
+    "antigravity": "gemini-3.1-pro", "report-writer": "sonnet",
 }
 
 

package/runtime/python/okstra_ctl/run.py

@@ -30,6 +30,7 @@ from okstra_project import project_json_path, upsert_project_json
 from okstra_project.state import slugify
 from . import fix_cycles
 from .analysis_packet import build_analysis_packet
+from .stage_fix_carry import derive_stage_fix_carry
 from .clarification_items import (
     attached_user_responses_section,
     clarification_response_with_sidecars,
@@ -1346,7 +1347,7 @@ def recommended_role_models() -> dict[str, str]:
         "claude": _default("OKSTRA_DEFAULT_CLAUDE_MODEL", default_model("claude")),
         "codex": _default("OKSTRA_DEFAULT_CODEX_MODEL", default_model("codex")),
         "antigravity": _default("OKSTRA_DEFAULT_ANTIGRAVITY_MODEL", default_model("antigravity")),
-        "report-writer": _default("OKSTRA_DEFAULT_REPORT_WRITER_MODEL", lead_default),
+        "report-writer": _default("OKSTRA_DEFAULT_REPORT_WRITER_MODEL", default_model("report-writer")),
     }
 
 
@@ -1600,7 +1601,7 @@ def _write_instruction_set_sources(
     instruction_set.mkdir(parents=True, exist_ok=True)
     profile_rendered = profile_content
     if inp.task_type == "implementation":
-        profile_rendered += "\n\n{{DESIGN_PREP_CONTEXT}}"
+        profile_rendered += "\n\n{{DESIGN_PREP_CONTEXT}}\n\n{{FIX_RUN_CONTEXT}}"
     profile_tokens = (
         "EXECUTOR_PROVIDER",
         "EXECUTOR_DISPLAY_NAME",
@@ -1613,6 +1614,7 @@ def _write_instruction_set_sources(
         "EXECUTOR_WORKTREE_STATUS",
         "EXECUTOR_WORKTREE_NOTE",
         "DESIGN_PREP_CONTEXT",
+        "FIX_RUN_CONTEXT",
         "PHASE_FORBIDDEN_ACTIONS",
     )
     for key in profile_tokens:
@@ -2038,6 +2040,10 @@ def prepare_task_bundle(inp: PrepareInputs) -> PrepareOutputs:
         _publish_stage_run_claim(
             inp, ctx, ctx_stage_map, stage_run_claim,
         )
+        carry = derive_stage_fix_carry(
+            Path(ctx["RUN_DIR"]), ctx.get("EXECUTOR_WORKTREE_PATH", ""),
+        )
+        ctx["FIX_RUN_CONTEXT"] = carry.as_prompt_markdown() if carry else ""
 
     if inp.render_only:
         # render-only entry path (e.g. okstra-run skill, in-session takeover):

package/runtime/python/okstra_ctl/stage_fix_carry.py

@@ -0,0 +1,112 @@
+"""Derive the fix-run carry for an implementation stage whose previous run
+ended with one or more verifier FAIL verdicts.
+
+Pure read-side: scans the stage run directory's final-report data.json files
+(the JSON SSOT written by the report writer) and the stage worktree HEAD.
+Returns None when the upcoming run is not a fix run, so callers can treat
+"no carry" and "first run on this stage" identically.
+"""
+from __future__ import annotations
+
+import json
+import re
+import subprocess
+from dataclasses import dataclass
+from pathlib import Path
+
+_REPORT_RE = re.compile(r"final-report-implementation-(\d+)\.data\.json$")
+
+
+@dataclass(frozen=True)
+class StageFixCarry:
+    prev_report_path: str
+    prev_report_seq: str
+    prev_head_commit: str
+    failed_verifiers: list[str]
+    blocking_findings: list[str]
+    routing_recommendation: str
+
+    def as_prompt_markdown(self) -> str:
+        lines = [
+            "## Fix-Run Carry (this run fixes a prior FAIL)",
+            "",
+            f"- Previous report (data.json SSOT): `{self.prev_report_path}`",
+            f"- Previous run HEAD (fix-diff base): `{self.prev_head_commit}`",
+            f"- Failed verifiers: {', '.join(self.failed_verifiers)}",
+            "- Carried blocking findings:",
+        ]
+        lines.extend(f"  - {finding}" for finding in self.blocking_findings)
+        if self.routing_recommendation:
+            lines.append(
+                f"- Previous routing recommendation: {self.routing_recommendation}"
+            )
+        lines.extend([
+            "",
+            "Scope rules for this fix run live in the implementation sidecars "
+            "(`_implementation-verifier.md` § Fix-run incremental scope, "
+            "`report-writer.md` § Fix-run incremental authoring).",
+            "Lead duties: transcribe this block verbatim into every CLI "
+            "executor/verifier prompt (CLI processes cannot read this file), "
+            "and pass the previous data.json path above to the report-writer "
+            "dispatch so it authors incrementally.",
+        ])
+        return "\n".join(lines)
+
+
+def derive_stage_fix_carry(
+    stage_run_dir: Path, worktree_path: str,
+) -> StageFixCarry | None:
+    report = _latest_report(Path(stage_run_dir))
+    if report is None:
+        return None
+    try:
+        data = json.loads(report.read_text(encoding="utf-8"))
+    except (OSError, json.JSONDecodeError):
+        return None
+    impl = data.get("implementation")
+    if not isinstance(impl, dict):
+        return None
+    failed = [
+        row for row in impl.get("verifierResults") or []
+        if isinstance(row, dict) and row.get("verdict") == "FAIL"
+    ]
+    if not failed:
+        return None
+    head = _git_head(worktree_path)
+    if not head:
+        return None
+    return StageFixCarry(
+        prev_report_path=str(report),
+        prev_report_seq=_REPORT_RE.search(report.name).group(1),
+        prev_head_commit=head,
+        failed_verifiers=[str(row.get("verifier", "")) for row in failed],
+        blocking_findings=[
+            str(row.get("discrepancy") or row.get("verifier") or "")
+            for row in failed
+        ],
+        routing_recommendation=str(impl.get("routingRecommendation") or ""),
+    )
+
+
+def _latest_report(stage_run_dir: Path) -> Path | None:
+    reports_dir = stage_run_dir / "reports"
+    if not reports_dir.is_dir():
+        return None
+    candidates = sorted(
+        (p for p in reports_dir.iterdir() if _REPORT_RE.search(p.name)),
+        key=lambda p: _REPORT_RE.search(p.name).group(1),
+    )
+    return candidates[-1] if candidates else None
+
+
+def _git_head(worktree_path: str) -> str:
+    if not worktree_path:
+        return ""
+    try:
+        out = subprocess.run(
+            ["git", "-C", worktree_path, "rev-parse", "HEAD"],
+            capture_output=True, text=True, check=False,
+        )
+    except OSError:
+        return ""
+    return out.stdout.strip() if out.returncode == 0 else ""

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

@@ -146,7 +146,7 @@
       ],
       "additionalProperties": false,
       "properties": {
-        "finalConclusion": { "type": "string", "minLength": 1 },
+        "finalConclusion": { "type": "string", "minLength": 1, "description": "Conclusion SSOT for the whole report: at most 3 sentences. Other prose blocks reference this instead of restating it." },
         "verdictToken": { "$ref": "#/$defs/VerdictToken" },
         "direction": { "$ref": "#/$defs/Direction" },
         "approvalRequired": { "type": "boolean" },
@@ -176,14 +176,14 @@
 
     "rationale": {
       "type": "object",
-      "description": "## 작업 배경과 근거 — reviewer-facing narrative answering the four questions in order. Each field is prose (not a table) and MUST carry at least one evidence reference (path:line, a report ID such as C-001/F-013/§5.4, or another cited source) OR an explicit insufficiency marker (e.g. '근거 불충분'). validate-run.py fails a field with neither. Required for every task-type.",
+      "description": "## 작업 배경과 근거 — reviewer-facing narrative answering the four questions in order. Each field is prose (not a table) and MUST carry at least one evidence reference (path:line, a report ID such as C-001/F-013/§5.4, or another cited source) OR an explicit insufficiency marker (e.g. '근거 불충분'). validate-run.py fails a field with neither. Required for every task-type. Prose budget: at most 2 sentences per field; reference verdictCard.finalConclusion and row IDs instead of restating them.",
       "required": ["motivation", "problem", "approach", "justification"],
       "additionalProperties": false,
       "properties": {
-        "motivation": { "type": "string", "minLength": 1, "description": "왜 이 작업을 하는가 — 목표·맥락." },
-        "problem": { "type": "string", "minLength": 1, "description": "왜 이게 문제인가 — 현재 상태의 결함을 증거로." },
-        "approach": { "type": "string", "minLength": 1, "description": "그래서 어떤 작업이 필요한가 — 택한 방향." },
-        "justification": { "type": "string", "minLength": 1, "description": "왜 이게 합리적 선택인가 — 대안 대비 근거." }
+        "motivation": { "type": "string", "minLength": 1, "description": "왜 이 작업을 하는가 — 목표·맥락. ≤2 sentences." },
+        "problem": { "type": "string", "minLength": 1, "description": "왜 이게 문제인가 — 현재 상태의 결함을 증거로. ≤2 sentences." },
+        "approach": { "type": "string", "minLength": 1, "description": "그래서 어떤 작업이 필요한가 — 택한 방향. ≤2 sentences." },
+        "justification": { "type": "string", "minLength": 1, "description": "왜 이게 합리적 선택인가 — 대안 대비 근거. ≤2 sentences." }
       }
     },