okstra 0.125.1 → 0.125.3

package/docs/project-structure-overview.md

@@ -317,7 +317,6 @@ Token/cost accounting:
 | `templates/reports/final-report.template.md` | Jinja2 final-report Markdown template |
 | `templates/reports/report.css`, `report.js` | Inline assets for self-contained HTML report view |
 | `templates/reports/*.template.md` | Inputs, schedule, user-response, settings templates |
-| `templates/prd/brief.template.md` | Brief template |
 | `templates/project-docs/task-index.template.md` | Project task index template |
 
 ### 4.8 `schemas/`

package/package.json

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

package/runtime/BUILD.json

@@ -1,5 +1,5 @@
 {
-  "package": "0.125.1",
-  "builtAt": "2026-07-20T08:47:14.936Z",
+  "package": "0.125.3",
+  "builtAt": "2026-07-20T11:02:05.650Z",
   "repoRoot": "/home/runner/work/okstra/okstra"
 }

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

@@ -148,7 +148,7 @@ This wrapper does NOT invoke MCP tools directly. MCP availability inside the Ant
 
 Before invoking the Antigravity CLI, you MUST:
 
-1. Extract the absolute path from the lead's `**Worker Preamble Path:**` anchor header and verify the CLI run will Read that file end-to-end (canonical SSOT for the Required Reading + Error Reporting + Output sections contract). The lead's prompt body — which you persist verbatim and feed into Antigravity via stdin — already contains this anchor; do not strip it.
+1. Extract the absolute path from the lead's `**Worker Preamble Path:**` anchor header and verify the CLI run will Read that file end-to-end (canonical SSOT for the Required Reading + Error Reporting + Output sections contract). The lead's prompt body — which you persist verbatim and feed into Antigravity via stdin — already contains this anchor; do not strip it. **Exception — reverify dispatches**: a Phase 5.5 re-verification prompt (its `**Prompt History Path:**` carries a `-reverify-r<N>-` segment) deliberately omits this anchor, because lightweight mode judges the supplied findings without re-reading source materials. Proceed without it; do NOT return a sentinel and do NOT synthesize the preamble path. The `**Errors log path:**` / `**Errors sidecar path:**` gate under "Error reporting" still applies to reverify prompts.
 2. Verify the lead's prompt body lists the per-run primary input files under `## Inputs` (normally `analysis-packet.md` for analysis workers). The source files named inside that packet are fallback/evidence paths to open when needed. Analysis workers do NOT read `final-report-template.md` — that file is for the report writer only.
 
 The CLI writes a Reading Confirmation block to the **audit sidecar** at `runs/<task-type>/worker-results/antigravity-worker-audit-<task-type>-<seq>.md`. The sidecar's body begins with `# Antigravity Worker Audit — <task-key>` followed by one short line per input file confirming end-to-end reading. Section-0 placement follows the worker preamble §"Reading rules" (canonical). If any file was skipped, record a `tool-failure` in the errors sidecar instead of fabricating Findings.

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

@@ -148,7 +148,7 @@ This wrapper does NOT invoke MCP tools directly. MCP availability inside the Cod
 
 Before invoking the Codex CLI, you MUST:
 
-1. Extract the absolute path from the lead's `**Worker Preamble Path:**` anchor header and verify the CLI run will Read that file end-to-end (canonical SSOT for the Required Reading + Error Reporting + Output sections contract). The lead's prompt body — which you persist verbatim and feed into Codex via stdin — already contains this anchor; do not strip it.
+1. Extract the absolute path from the lead's `**Worker Preamble Path:**` anchor header and verify the CLI run will Read that file end-to-end (canonical SSOT for the Required Reading + Error Reporting + Output sections contract). The lead's prompt body — which you persist verbatim and feed into Codex via stdin — already contains this anchor; do not strip it. **Exception — reverify dispatches**: a Phase 5.5 re-verification prompt (its `**Prompt History Path:**` carries a `-reverify-r<N>-` segment) deliberately omits this anchor, because lightweight mode judges the supplied findings without re-reading source materials. Proceed without it; do NOT return a sentinel and do NOT synthesize the preamble path. The `**Errors log path:**` / `**Errors sidecar path:**` gate under "Error reporting" still applies to reverify prompts.
 2. Verify the lead's prompt body lists the per-run primary input files under `## Inputs` (normally `analysis-packet.md` for analysis workers). The source files named inside that packet are fallback/evidence paths to open when needed. Analysis workers do NOT read `final-report-template.md` — that file is for the report writer only.
 
 The CLI writes a Reading Confirmation block to the **audit sidecar** at `runs/<task-type>/worker-results/codex-worker-audit-<task-type>-<seq>.md`. The sidecar's body begins with `# Codex Worker Audit — <task-key>` followed by one short line per input file confirming end-to-end reading. Section-0 placement follows the worker preamble §"Reading rules" (canonical). If any file was skipped, record a `tool-failure` in the errors sidecar instead of fabricating Findings.

package/runtime/bin/okstra-incremental-carry.py

@@ -0,0 +1,10 @@
+#!/usr/bin/env python3
+"""Thin CLI wrapper — installed to ~/.okstra/bin/. Delegates to okstra_ctl."""
+import sys
+from pathlib import Path
+
+sys.path.insert(0, str(Path(__file__).resolve().parent))
+from okstra_ctl.incremental_carry import main  # noqa: E402
+
+if __name__ == "__main__":
+    raise SystemExit(main(sys.argv[1:]))

package/runtime/bin/okstra-incremental-scope.py

@@ -0,0 +1,10 @@
+#!/usr/bin/env python3
+"""Thin CLI wrapper — installed to ~/.okstra/bin/. Delegates to okstra_ctl."""
+import sys
+from pathlib import Path
+
+sys.path.insert(0, str(Path(__file__).resolve().parent))
+from okstra_ctl.incremental_scope import main  # noqa: E402
+
+if __name__ == "__main__":
+    raise SystemExit(main(sys.argv[1:]))

package/runtime/prompts/lead/convergence.md

@@ -251,7 +251,7 @@ Call `await_workers(handles)` through the same adapter and apply the shared term
 
 ### Required reverify-prompt anchor headers (BLOCKING)
 
-Every reverify prompt MUST start with the same 5 anchor headers used in the initial Phase 4 dispatch — in this exact order, before any other content:
+Every reverify prompt MUST start with these 7 anchor headers — in this exact order, before any other content:
 
 ```
 **Project Root:** <absolute-path>
@@ -259,8 +259,16 @@ Every reverify prompt MUST start with the same 5 anchor headers used in the init
 **Result Path:** runs/<task-type>/worker-results/<role-slug>-reverify-r<N>-<task-type>-<seq>.md
 Assigned worker prompt history path: <Project Root>/<Prompt History Path>
 **Model:** <role>, <modelExecutionValue>
+**Errors log path:** <absolute-path>
+**Errors sidecar path:** <absolute-path>
 ```
 
+The two errors paths carry the same absolute values the lead forwarded in the initial Phase 4 dispatch for that role (source: the launch prompt's `## Run Logs (error-log wiring)` section). Omitting either one makes a CLI-wrapper worker return `<WORKER>_ERRORS_PATH_MISSING` before it invokes its CLI — the path-delivery contract in [team-contract](./team-contract.md) "Error reporting" is not relaxed for reverify, because a reverify dispatch can fail the same way an initial dispatch can.
+
+Relative to the Phase 4 anchor set rendered by `okstra_ctl.worker_prompt_headers.worker_prompt_headers()`, a reverify prompt adds `**Model:**` and drops two anchors whose targets lightweight mode never reads: `**Worker Preamble Path:**` and `**Coding preflight pack:**`.
+
+The rationale for both drops is §"Reverify prompt: required-reading suppression" below.
+
 `<modelExecutionValue>` MUST be resolved from one of these canonical sources, in priority order:
 
 1. `task-manifest.json` → `resultContract.requiredWorkerRoles[].modelExecutionValue` for the receiving role

package/runtime/prompts/lead/plan-body-verification.md

@@ -42,6 +42,7 @@ Plan-body verification is configured under `convergence.planBodyVerification` in
 |---------|---------|-------------|
 | `enabled` | `true` | If `false`, the round is skipped and the top-of-report Approval marker is rendered unconditionally (legacy behaviour). |
 | `maxRounds` | `1` | Upper bound. Plan-body verification is consistency / completeness checking, not fact checking — additional rounds rarely help. Range 1–3. |
+| `selfFixMaxRounds` | `3` | Upper bound on the report-writer self-fix loop (§"Round protocol" step 7). Range 1–5. The loop also stops early on no-progress, so this is a ceiling, not a target. |
 | `gating` | `true` | If `true` (default), `majority-disagree` blocks the Approval marker. If `false`, the round is advisory-only and the marker always renders. |
 
 Default values are emitted into the manifest by `scripts/okstra_ctl/render.py` (`_build_convergence_block`). The ctx knob `OKSTRA_PLAN_VERIFICATION=false` flips `planBodyVerification.enabled` to false.
@@ -126,27 +127,33 @@ Plan-body verification stays **lightweight** even under this posture — the `ve
    - `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` — 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**.
+   - `needs-reverify` — a single-vote-blocking kind fired but the item has **fewer than 2 participating non-error votes**, i.e. the lone dissent was never cross-verified because its peer returned `verification-error`. A single-vote-blocking kind means "one *confirmed* DISAGREE is enough"; an unconfirmed one is not. This does **not** block the Approval marker — blocking on it would make a worker failure produce a stricter gate than a healthy roster, the same paradox the ≥2-vote majority rule already rules out. The item is re-dispatched in the next round (step 7); if it survives the round budget it is promoted per step 8 with a Statement that says verification never completed. **Enforced:** `validators/validate-run.py` `_classify_plan_item_gate` returns `needs-reverify` for this shape and `_recompute_plan_body_gate` folds it into `passed-with-dissent`.
    - `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`
+   - any `partial-consensus` / `dissent-isolated` / `needs-reverify` 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`, 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. **Self-fix round (at most once, targeting planner-fixable defects).** After aggregation, if at least one `majority-disagree` item has a majority of its `DISAGREE` verdicts at `fixability == planner-fixable`, lead attempts one self-fix **before** promoting it to the user:
+7. **Self-fix loop (up to `selfFixMaxRounds`, targeting planner-fixable defects).** After aggregation, while at least one `majority-disagree` item has a majority of its `DISAGREE` verdicts at `fixability == planner-fixable`, lead runs self-fix rounds **before** promoting anything to the user:
    - lead instructs report-writer to rewrite only those planner-fixable items for correction (NOT a full draft regeneration — patch only the plan section each `P-*` points to; procedure in [report-writer](./report-writer.md) §"Self-fix rewrite").
    - missing or weak `P-Prep-*` contracts are repaired by adding kind-specific inline detail or an AI-prepared PREP item with a concrete proposal. Facts that require user or external authority remain `blocked` and keep their request material; never invent those facts during self-fix.
-   - lead re-runs plan-body verification once (focused on the corrected items + adjacent items the rewrite touched). After re-verification, overwrite `planItems[].verdicts` with the new verdicts.
+   - lead re-runs plan-body verification (focused on the corrected items + adjacent items the rewrite touched, plus any `needs-reverify` items whose peer failed to vote last round). After re-verification, overwrite `planItems[].verdicts` with the new verdicts.
    - for an item whose `majority-disagree` was resolved by self-fix, record `self-fixed in round <N>: <what was fixed>` in `planItems[].selfFixNote`. A resolved item does not create a clarification.
-   - this round runs **at most once** (infinite-loop cap). If a self-fix round was attempted, record `planBodyVerification.selfFixRoundApplied = true`.
+   - **Loop termination.** Record the round count in `planBodyVerification.selfFixRoundsApplied` and why the loop stopped in `planBodyVerification.selfFixStopReason`:
+     - `all-resolved` — no planner-fixable `majority-disagree` item remains. Exit.
+     - `no-progress` — the round resolved **zero** planner-fixable items relative to the previous round. Exit even with budget left: the same rewrite would repeat. Newly *introduced* defects count against progress, so a rewrite that trades one defect for another stops the loop rather than churning.
+     - `max-rounds-reached` — `selfFixRoundsApplied == selfFixMaxRounds`. Exit.
+     - `not-attempted` — the loop never ran because no item qualified.
+     The `no-progress` and `max-rounds-reached` exits are what make the loop terminate; `selfFixMaxRounds` alone is the backstop.
    - a `majority-disagree` item with a majority of `needs-user-input` is NOT a self-fix target — it goes straight to the next step's clarification promotion.
-8. For every `majority-disagree` item **that remains after the self-fix round** (items not resolved by self-fix, or with a `needs-user-input` majority from the start), lead adds a row to `## 1. Clarification Items` with:
+8. For every `majority-disagree` item **that remains after the self-fix loop** (items not resolved by self-fix, or with a `needs-user-input` majority from the start), 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 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.
-   - a `planner-fixable` item that survives the self-fix round is still promoted, but its `Statement` MUST state "planner self-fix attempted but unresolved" (the cap prevents repeating the rewrite). `validators/validate-run.py` `_validate_self_fix_before_clarification` fails when `selfFixRoundApplied != true` yet a planner-fixable majority item is promoted.
+   - a `planner-fixable` item that survives the self-fix loop is still promoted, but its `Statement` MUST state "planner self-fix attempted but unresolved" and name the stop reason. `validators/validate-run.py` `_validate_self_fix_before_clarification` fails when a planner-fixable majority item is promoted while the budget is not exhausted — it requires `selfFixRoundsApplied >= 1` **and** `selfFixStopReason` in `{no-progress, max-rounds-reached}`, so neither `all-resolved` nor `not-attempted` can excuse a promotion.
 9. 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
@@ -160,7 +167,8 @@ Plan-body verification stays **lightweight** even under this posture — the `ve
   "gating": true,
   "verificationMode": "lightweight",
   "gateResult": "passed | passed-with-dissent | blocked-by-disagreement | aborted-non-result",
-  "selfFixRoundApplied": false,
+  "selfFixRoundsApplied": 0,
+  "selfFixStopReason": "not-attempted | all-resolved | no-progress | max-rounds-reached",
   "planItems": [
     {
       "id": "P-Opt-1",
@@ -193,7 +201,7 @@ Plan-body verification stays **lightweight** even under this posture — the `ve
 
 `planItems[].votes.<worker>` is the verbatim verdict token emitted by the worker — `AGREE | DISAGREE(<a|b|c|d|e|f>) | SUPPLEMENT` — or `verification-error` for terminal non-result dispatches. The `DISAGREE` token retains its `<kind>` suffix so the breakage class is recoverable from the state file alone.
 
-`planBodyVerification.selfFixRoundApplied` (bool, default false): whether a self-fix round was attempted at least once. `planItems[].verdicts[].fixability` is each `DISAGREE`'s `planner-fixable | needs-user-input` judgement, recorded in the final data.json (`§5.5.9`).
+`planBodyVerification.selfFixRoundsApplied` (int, default 0): how many self-fix rounds actually ran. `planBodyVerification.selfFixStopReason` (enum, default `not-attempted`): why the loop exited — see §"Round protocol" step 7. `planItems[].verdicts[].fixability` is each `DISAGREE`'s `planner-fixable | needs-user-input` judgement, recorded in the final data.json (`§5.5.9`).
 
 ## Plan-body reverify prompt
 

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

@@ -235,7 +235,9 @@ When lead instructs a self-fix round (passing the target `P-*` list + the reason
 - requirement-coverage mapping error → remap to a real option/stage/step or XP row.
 - missing/weak design-prep contract → fix with kind-specific inline detail or an AI-prepared PREP item carrying a concrete `aiProposal`. Do NOT invent facts requiring user/external authority — keep them `blocked` + request material.
 
-After correcting, leave `self-fixed in round <N>: <what was fixed>` in that `planItems[].selfFixNote` and mark `planBodyVerification.selfFixRoundApplied = true`. `needs-user-input` items are NEVER a correction target — they are promoted to clarification as-is.
+After correcting, leave `self-fixed in round <N>: <what was fixed>` in that `planItems[].selfFixNote` and set `planBodyVerification.selfFixRoundsApplied` to the number of rounds run so far. `needs-user-input` items are NEVER a correction target — they are promoted to clarification as-is.
+
+Lead may instruct several rounds (bounded by `selfFixMaxRounds`, see [plan-body-verification](./plan-body-verification.md) §"Round protocol" step 7). Each round targets only the items still broken, so a round that fixes nothing new ends the loop — correcting an item by breaking a sibling counts as no progress, not progress.
 
 ### Final-verification verdict token contract (BLOCKING)
 

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

@@ -114,6 +114,7 @@
   - **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
+  - **Requirement admissibility (scope boundary):** a brief line becomes a Requirement Coverage row only when **a stage can satisfy it by changing files in this repository** — source, tests, config, or deployment *manifest files*. A line whose satisfaction needs a person's approval, a ticket status change, or an action against live infrastructure (applying a manifest, a cutover, creating a dashboard or alert, validating in staging/production) is NOT a requirement for this phase: it belongs to the brief's `## External Gates`, and this plan neither creates a stage for it nor cites it in coverage. Briefs generated by `okstra-brief-gen` pre-split these into `## Acceptance Criteria` (admissible) and `## External Gates` (not); when reading an older brief that carries a raw Definition-of-Done checklist, apply the same test line by line. The boundary is the *action*, not the topic — "add the flag to `values-prod.yaml`" is admissible, "apply that manifest to prod" is not. Planning an operational stage this phase cannot execute (see the run-scope rule above forbidding deployments) produces steps whose commands never resolve, which the §5.5.9 gate then correctly blocks — the plan must not create that deadlock in the first place.
   - **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).

package/runtime/python/okstra_ctl/incremental_carry.py

@@ -299,6 +299,21 @@ def _parse_stage_csv(value: str | None, *, option: str) -> set[int] | None:
         raise CarryError(f"{option} contains an invalid stage number") from exc
 
 
+def _load_data(path: str, *, option: str) -> dict:
+    """Read one data.json as a CarryError-reporting operation. Unreadable or
+    malformed input means the carry cannot happen, which is what CarryError
+    already communicates — without this the caller gets a traceback instead of
+    the documented `carry refused:` refusal it knows how to fall back from.
+    """
+    try:
+        data = json.loads(Path(path).read_text(encoding="utf-8"))
+    except (OSError, ValueError) as exc:
+        raise CarryError(f"{option} could not be read: {exc}") from exc
+    if not isinstance(data, dict):
+        raise CarryError(f"{option} must contain a JSON object")
+    return data
+
+
 def main(argv: list[str]) -> int:
     ap = argparse.ArgumentParser(prog="okstra incremental-carry")
     ap.add_argument("--prev-data", required=True, help="prior run final-report data.json")
@@ -309,9 +324,9 @@ def main(argv: list[str]) -> int:
     ap.add_argument("--out", required=True, help="path to write the merged data.json")
     args = ap.parse_args(argv)
 
-    prev = json.loads(Path(args.prev_data).read_text(encoding="utf-8"))
-    cur = json.loads(Path(args.cur_data).read_text(encoding="utf-8"))
     try:
+        prev = _load_data(args.prev_data, option="--prev-data")
+        cur = _load_data(args.cur_data, option="--cur-data")
         merged = merge_carried_forward(
             prev,
             cur,
@@ -325,9 +340,13 @@ def main(argv: list[str]) -> int:
         print(f"carry refused: {exc}", file=sys.stderr)
         return 1
 
-    Path(args.out).write_text(
-        json.dumps(merged, ensure_ascii=False, indent=2) + "\n", encoding="utf-8"
-    )
+    try:
+        Path(args.out).write_text(
+            json.dumps(merged, ensure_ascii=False, indent=2) + "\n", encoding="utf-8"
+        )
+    except OSError as exc:
+        print(f"carry refused: --out could not be written: {exc}", file=sys.stderr)
+        return 1
     carried = sum(
         1
         for item in merged.get("implementationPlanning", {})

package/runtime/python/okstra_ctl/incremental_scope.py

@@ -109,9 +109,9 @@ def main(argv: list[str]) -> int:
     ap.add_argument("--prep-items", default="", help="comma-separated changed PREP item IDs")
     args = ap.parse_args(argv)
 
-    data = json.loads(Path(args.prev_data).read_text(encoding="utf-8"))
-    stages = parse_stage_graph(data)
     try:
+        data = json.loads(Path(args.prev_data).read_text(encoding="utf-8"))
+        stages = parse_stage_graph(data)
         impacted = {int(t.strip()) for t in args.impacted.split(",") if t.strip()}
         prep_ids = {t.strip() for t in args.prep_items.split(",") if t.strip()}
         impacted.update(design_prep_impacted_stages(data, prep_ids))
@@ -123,7 +123,12 @@ def main(argv: list[str]) -> int:
             stages=stages, impacted_stages=impacted,
             prev_base_sha=args.prev_base_sha, cur_base_sha=args.cur_base_sha,
         )
-    except ValueError as exc:
+    # Every bad input degrades to a full re-verification rather than raising:
+    # `full` is always the safe answer, and the caller reads the decision off
+    # stdout, so a traceback would leave it with no decision at all. OSError
+    # covers an unreadable --prev-data, KeyError/TypeError a stageMap row that
+    # is missing `stage` or is not a mapping.
+    except (OSError, ValueError, KeyError, TypeError) as exc:
         decision = IncrementalDecision(
             "full", [], [], f"invalid incremental-scope input: {exc}",
         )

package/runtime/python/okstra_ctl/render.py

@@ -156,7 +156,6 @@ _FM_TAGS_CATALOG: dict[str, list[str]] = {
     "quick-input": ["quick", "input"],
     "final-report": ["final-report"],
     "schedule": ["schedule"],
-    "prd-brief": ["prd", "brief"],
 }
 
 
@@ -185,8 +184,6 @@ def _doc_type_from_template_path(template_path: str) -> str:
         stem = name[: -len(".template.md")]
     else:
         stem = Path(name).stem
-    if stem == "brief" and "prd" in Path(template_path).parts:
-        return "prd-brief"
     return stem
 
 
@@ -1160,6 +1157,8 @@ def _build_convergence_block(ctx: dict) -> dict:
       False otherwise
     - `planBodyVerification` is implementation-planning specific; the key is
       always emitted (dead-letter on other phases) so the schema stays stable.
+      Its `selfFixMaxRounds` default 3 bounds the report-writer self-fix loop
+      that runs before a planner-fixable defect is promoted to the user.
 
     ctx knobs honoured:
     - `OKSTRA_PLAN_VERIFICATION`: "true" | "false" | "" (empty → default True).
@@ -1199,6 +1198,7 @@ def _build_convergence_block(ctx: dict) -> dict:
         "planBodyVerification": {
             "enabled": plan_verify_enabled,
             "maxRounds": 1,
+            "selfFixMaxRounds": 3,
             "gating": True,
         },
     }

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

@@ -1844,7 +1844,15 @@
             "aborted-non-result"
           ]
         },
-        "selfFixRoundApplied": { "type": "boolean" },
+        "selfFixRoundsApplied": { "type": "integer", "minimum": 0 },
+        "selfFixStopReason": {
+          "enum": [
+            "not-attempted",
+            "all-resolved",
+            "no-progress",
+            "max-rounds-reached"
+          ]
+        },
         "planItems": {
           "type": "array",
           "items": {

package/runtime/skills/okstra-brief-gen/SKILL.md

@@ -564,6 +564,39 @@ stop conditions (codebase-scan-specific additions):
 
 When both of the above conditions hold, sharpening may end even if budget remains.
 
+### Splitting a source checklist (Definition of Done / acceptance list)
+
+Issue-tracker templates almost always ship one checklist that mixes work an
+agent does with work a person does — a Linear "Definition of Done" typically
+carries `tests written and passing` next to `reviewed by ≥1 dev`,
+`validated in staging by <name>`, and `ticket moved to Done`. Copied across
+whole, every one of those lines reads to a downstream phase as a requirement,
+because a markdown checkbox carries no owner.
+
+Split every such checklist across the two sections using one test:
+
+> **Can an okstra phase satisfy this by changing files in this repository?**
+
+- **Yes → `## Acceptance Criteria`.** Source, tests, config, and deployment
+  *manifest files* all count — editing `values-prod.yaml` is a file change.
+- **No → `## External Gates`.** A person's approval or sign-off, manual QA,
+  validation performed in staging/production, creating a dashboard or alert,
+  running a deployment, and ticket status transitions. Record who or what owns
+  it (`Brice`, `release manager`, `CI`), so the reader can act on it outside
+  okstra.
+
+The distinction is the *action*, not the topic: "add the RSS flag to
+`values-prod.yaml`" is a criterion; "apply that manifest to prod" and "confirm
+the new-app count on the Metabase dashboard with Brice" are gates.
+
+Never drop a gate to make the brief tidier — an omitted release step is worse
+than a correctly-parked one. Never promote a gate into Acceptance Criteria to
+look thorough either: an okstra phase cannot satisfy it, so it can only surface
+later as an unmeetable requirement that blocks the run.
+
+If a line is genuinely ambiguous, put it in `## Open Questions` and let
+`requirements-discovery` resolve the owner.
+
 ### Augmentation labels (REQUIRED — no unlabelled augmentation)
 
 Every augmentation — both inline `> augmented: …` blockquotes and
@@ -611,6 +644,10 @@ Required sections:
 - **Problem / Symptom** — current state. For bugs: repro + observed/expected;
   for greenfield: gap between current and desired.
 - **Desired Outcome** — success shape, not a solution prescription.
+- **Acceptance Criteria** — must-pass points an okstra phase can satisfy by
+  changing repository files. See "Splitting a source checklist" below.
+- **External Gates** — must-pass points owned by a person or by live
+  infrastructure. Recorded for the reader; never a requirement for any phase.
 - **Constraints** — deadlines, compatibility, technical/operational limits.
 - **Related Artifacts** — files, URLs, issues, prior task-keys.
 - **Related Task Graph** — structured task-to-task edges when the work was
@@ -709,6 +746,8 @@ The installed template `~/.okstra/templates/reports/brief.template.md` is the by
 | `## Problem / Symptom` | Required | Not required — omit | Required |
 | `## Context` | Required | Required | Required |
 | `## Desired Outcome` | Required | Required | Required |
+| `## Acceptance Criteria` | Required — `_(none)_` or one bullet per repo-satisfiable must-pass point | Required — `_(none)_` or bullets | Required — `_(none)_` or bullets |
+| `## External Gates` | Required — `_(none)_` or one bullet per person/infra-owned gate | Required — `_(none)_` or bullets | Required — `_(none)_` or bullets |
 | `## Constraints` | Required | Required | Required |
 | `## Related Artifacts` | Required | Required | Required |
 | `## Related Task Graph` | Required — `_(none)_` or canonical table | Required — `_(none)_` or canonical table | Required — `_(none)_` or canonical table |

package/runtime/templates/reports/brief.template.md

@@ -73,6 +73,35 @@ between current and desired.>
 
 <!-- Do NOT prescribe a solution — that belongs to implementation-planning. -->
 
+## Acceptance Criteria
+
+<One bullet per must-pass point that okstra phases can satisfy by changing
+files in this repository. Use _(none)_ if none.>
+
+<!-- Admissibility test — a criterion belongs here only if it is satisfied by
+changing repository files (source, tests, config, deployment manifests).
+Anything that needs a person's approval, a ticket status change, or an action
+against live infrastructure goes to `## External Gates` instead. Downstream
+phases treat this section as the requirement set: `implementation-planning`
+builds one Requirement Coverage row per bullet, `final-verification` gates
+acceptance on it. -->
+
+- <criterion satisfied by a repository file change>
+
+## External Gates
+
+<Must-pass points owned by a person or by live infrastructure — peer review
+sign-off, manual QA by a named person, staging/production validation,
+dashboard or alert setup, ticket status transitions. Use _(none)_ if none.>
+
+<!-- These are recorded so the reader knows the full release picture, and are
+NOT requirements for any okstra phase: no phase plans a stage for them, no
+phase gates on them, and they never become acceptance blockers. Ticket
+templates routinely mix these with real criteria — split them here rather
+than downstream. -->
+
+- <gate>: <who or what owns it>
+
 ## Constraints
 
 <Deadlines, compatibility, technical/operational limits. Use _(none)_ if

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

@@ -262,10 +262,10 @@ Carried-forward plan items retain their prior verdicts verbatim; each such item
 
 ### Validation Checklist{% if t("sectionAside.validationChecklist") != "Validation Checklist" %} ({{ t("sectionAside.validationChecklist") }}){% endif %}
 
-| ID | Phase | Ticket ID | Check | Command / Observation | Expected outcome |
-|----|-------|-----------|-------|------------------------|-------------------|
+| {{ t("columns.recordMeta") }} | Check | Command / Observation | Expected outcome |
+|--------|-------|------------------------|-------------------|
 {% for row in implementationPlanning.validationChecklist -%}
-| {{ row.id | mdcell }} | {{ row.phase | mdcell }} | `{{ row.ticketId | mdcell }}` | {{ row.check | mdcell }} | `{{ row.commandOrObservation | mdcell }}` | {{ row.expectedOutcome | mdcell }} |
+| **{{ row.id | mdcell }}**<br>Ticket: `{{ row.ticketId | mdcell }}`<br>Phase: {{ row.phase | mdcell }} | {{ row.check | mdcell }} | `{{ row.commandOrObservation | mdcell }}` | {{ row.expectedOutcome | mdcell }} |
 {% endfor %}
 
 ### Rollback Strategy{% if t("sectionAside.rollbackStrategy") != "Rollback Strategy" %} ({{ t("sectionAside.rollbackStrategy") }}){% endif %}

package/runtime/validators/validate-brief.py

@@ -426,6 +426,39 @@ def check_requirement_section(text: str, errors: list[str]) -> None:
         )
 
 
+# Splitting the source checklist across these two sections is what keeps a
+# person-owned gate ("validated in staging by <name>") out of the requirement
+# set. Both must exist even when empty, because a missing heading is
+# indistinguishable from "the reporter listed no gates" — and the silent
+# version of that mistake is what puts an unmeetable requirement into
+# Requirement Coverage.
+SCOPE_SPLIT_SECTIONS = ("Acceptance Criteria", "External Gates")
+
+
+def check_scope_split_sections(text: str, errors: list[str]) -> None:
+    """Both halves of the requirement/gate split must exist with a body.
+
+    `## Acceptance Criteria` holds must-pass points an okstra phase can satisfy
+    by changing repository files; `## External Gates` holds the ones a person or
+    live infrastructure owns (okstra-brief-gen SKILL.md §"Splitting a source
+    checklist"). `_(none)_` stays valid — it is the contract's explicit
+    placeholder for a deliberately-empty section.
+    """
+    for heading in SCOPE_SPLIT_SECTIONS:
+        if not has_section_heading(text, heading):
+            errors.append(
+                f"required section '## {heading}' is missing (a brief must split "
+                "must-pass points into repo-satisfiable criteria and "
+                "person/infrastructure-owned gates)"
+            )
+            continue
+        if not section_body(text, heading).strip():
+            errors.append(
+                f"required section '## {heading}' has an empty body "
+                "(use _(none)_ only for a deliberately-empty section)"
+            )
+
+
 def check_reporter_confirmations(
     rc_status: str | None, reporter_rows: list[str], errors: list[str]
 ) -> None:
@@ -488,6 +521,7 @@ def validate_brief(path: Path, briefs_root: Path) -> list[str]:
     check_related_task_graph(text, errors)
 
     check_requirement_section(text, errors)
+    check_scope_split_sections(text, errors)
 
     # 2. brief-id matches filename stem
     stem = path.stem

package/runtime/validators/validate-run.py

@@ -1800,8 +1800,8 @@ _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/plan-body-verification.md` "Round protocol". Returns one of
-    ``majority-disagree`` / ``has-dissent`` / ``full-consensus`` /
-    ``all-non-result``. Collapses ``partial-consensus`` and
+    ``majority-disagree`` / ``needs-reverify`` / ``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.
     """
@@ -1827,6 +1827,13 @@ def _classify_plan_item_gate(item: dict) -> str:
     # `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):
+        # "One confirmed DISAGREE" presupposes the item was actually
+        # cross-verified. When the peer returned a non-result nothing confirmed
+        # the dissent, so blocking here would reproduce the same
+        # worker-failure-makes-the-gate-stricter paradox the majority branch
+        # below guards against. Route it to a re-verify round instead.
+        if len(non_error) < 2:
+            return "needs-reverify"
         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
@@ -1852,7 +1859,7 @@ def _recompute_plan_body_gate(pbv: dict) -> str | None:
         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):
+    if any(c in ("has-dissent", "needs-reverify") for c in classes):
         return "passed-with-dissent"
     return "passed"
 
@@ -2402,8 +2409,14 @@ def _validate_plan_body_clarification_matching(data: dict, failures: list[str])
             )
 
 
+# Stop reasons that justify promoting a still-broken planner-fixable item to the
+# user: the self-fix budget ran out, or a round produced no net resolution so
+# further rounds would repeat themselves.
+_SELF_FIX_EXHAUSTED_REASONS = frozenset({"max-rounds-reached", "no-progress"})
+
+
 def _validate_self_fix_before_clarification(data: dict, failures: list[str]) -> None:
-    """A planner-fixable defect MUST pass through a self-fix round before it is
+    """A planner-fixable defect MUST exhaust the self-fix budget before it is
     promoted to a `## 1. Clarification Items` row. Closes the hole where the
     lead dumps a fixable plan defect (abbreviated path, prose command,
     placeholder, coverage remap) onto the user instead of having report-writer
@@ -2418,7 +2431,14 @@ def _validate_self_fix_before_clarification(data: dict, failures: list[str]) ->
     round_count = pbv.get("roundCount")
     if not isinstance(round_count, int) or round_count < 1:
         return
-    if pbv.get("selfFixRoundApplied") is True:
+    rounds_applied = pbv.get("selfFixRoundsApplied")
+    stop_reason = pbv.get("selfFixStopReason")
+    budget_exhausted = (
+        isinstance(rounds_applied, int)
+        and rounds_applied >= 1
+        and stop_reason in _SELF_FIX_EXHAUSTED_REASONS
+    )
+    if budget_exhausted:
         return
     for item in pbv.get("planItems") or []:
         if not isinstance(item, dict):
@@ -2431,12 +2451,16 @@ def _validate_self_fix_before_clarification(data: dict, failures: list[str]) ->
         ]
         fixable = [v for v in disagrees if v.get("fixability") == "planner-fixable"]
         if disagrees and len(fixable) * 2 > len(disagrees):
+            allowed = " / ".join(sorted(_SELF_FIX_EXHAUSTED_REASONS))
             failures.append(
                 "final-report data.json: plan item "
                 f"`{item.get('id') or '<unknown>'}` is majority-disagree with a "
-                "planner-fixable majority but `selfFixRoundApplied` is not true. A "
-                "planner-fixable defect MUST be corrected by a report-writer self-fix "
-                "round before it becomes a clarification row "
+                f"planner-fixable majority but the self-fix budget is not "
+                f"exhausted (`selfFixRoundsApplied`={rounds_applied!r}, "
+                f"`selfFixStopReason`={stop_reason!r}; need >=1 rounds and a stop "
+                f"reason of {allowed}). A planner-fixable defect MUST be corrected "
+                "by report-writer self-fix rounds until the budget runs out or a "
+                "round makes no progress, before it becomes a clarification row "
                 "(plan-body-verification.md Self-fix round)."
             )
 

package/runtime/templates/prd/brief.template.md

@@ -1,286 +0,0 @@
----
-title: OKSTRA PRD Brief - {{TASK_KEY}}
-id: {{FM_ID}}
-tags: {{FM_TAGS}}
-status: new
-aliases: {{FM_ALIASES}}
-date: {{TASK_DATE}}
-task-id: "{{TASK_ID}}"
-task-group: "{{TASK_GROUP}}"
-project-id: "{{PROJECT_ID}}"
-taskType: "{{FM_TASK_TYPE}}"
----
-
-# OKSTRA Task Brief
-
-<!--
-This brief is the single source-of-truth document that lets an okstra worker (Claude/Codex/Antigravity) analyze the task without any prior knowledge of the codebase or domain.
-
-Principles:
-1. Workers cannot reach external links → embed every piece of primary evidence inline (fenced code block).
-2. Workers don't know domain terms → predefine the key terms in the Domain Glossary.
-3. Keep operator-facing information (okstra.sh commands, working directory) out of the brief — put it in a separate runbook.
-4. The sections you must fill differ by Task Type → complete that task's conditional block.
-5. Mark empty sections explicitly with `_N/A — <reason>_`. Silence is a source of worker confusion.
--->
-
-## Identity
-
-| Field | Value |
-|-------|-------|
-| Brief Title | `<task-group>-<TASK-ID>-<short-slug>` |
-| Project ID | `<project-id>` |
-| Task Group | `<task-group>` |
-| Task ID | `<TASK-ID>` |
-| Task Type | `requirements-discovery` \| `error-analysis` \| `implementation-planning` \| `final-verification` |
-| Issue / Ticket | `<TASK-ID> · <title in original language> (English: <translation if non-English>)` |
-| Requested Outcome | <one sentence. The key deliverable this run must produce> |
-
----
-
-## Request Summary
-
-- **What is being requested or changed?**
-  <one paragraph, or 3-5 bullets>
-- **Why now?**
-  <business/technical trigger. Deadline, incident, dependent task, etc.>
-- **New / Continuation / Reopened?**
-  <One of the three + prior run identifier (if any)>
-- **What decision should this run produce?**
-  <the 1-3 key decisions this run must answer. Vagueness distracts the worker>
-
----
-
-## Inline Evidence
-
-<!--
-Workers cannot reach external URLs / Notion / Linear / Slack. Embed all primary evidence inline here.
--->
-
-### Symptom / Sample Payload
-
-```
-<observed symptom, sample response payload, UI screenshot caption, etc. — as text>
-```
-
-### Logs / Stack Trace (if applicable)
-
-```
-<log excerpt. Mask sensitive information>
-```
-
-### Relevant Code Excerpts
-
-```typescript
-// path: src/domains/upload/dto/upload-job.view.ts:23-45
-<code excerpt — the worker should grasp the essentials without reading the whole file>
-```
-
-### External Doc Excerpts (Notion/Linear/Confluence excerpts)
-
-> <quote from the source. The link is secondary; the quote is the substance>
-> -- Source: <doc title + section>
-
----
-
-## Domain Glossary
-
-<!--
-Codex/Antigravity don't know this codebase. Define 5-15 key terms, one sentence each.
-If a worker guesses at an undefined term, analysis quality drops immediately.
--->
-
-| Term | Definition |
-|------|-----------|
-| `<domain term 1>` | <1-2 sentence definition> |
-| `<domain term 2>` | <1-2 sentence definition> |
-| `<code identifier 1>` | <role + location + relationship to other entities> |
-
----
-
-## Current Context
-
-- **Current behavior or state**:
-  <how the system behaves today>
-- **Desired behavior or outcome**:
-  <how it should behave>
-- **Existing related implementation**:
-  - `<file-path>:<line-range>` — <one-line role>
-- **Related code paths** (for reference — put direct excerpts in Inline Evidence):
-  - `<path>`
-  - `<path>`
-
----
-
-## Out of Scope
-
-<!--
-An explicit exclusion list. Central to preventing worker scope-creep.
--->
-
-Things this run will **not** address:
-
-- <out-of-scope item 1 + reason for exclusion>
-- <out-of-scope item 2 + reason for exclusion>
-- <item to be handled in a separate ticket/run — specify the ticket ID>
-
----
-
-## Task-Type Focus
-
-<!--
-Of the two blocks below, fill only the one matching the current task-type and delete the rest.
--->
-
-### If `requirements-discovery`
-
-- **Why might this be a bugfix?**
-  <evidence, or "weak signal — none observed">
-- **Why might this be a feature/improvement?**
-  <evidence>
-- **Why might this be a refactor/ops?**
-  <evidence>
-- **Classification blockers** — what is preventing a confident classification?
-  <the evidence gap, specifically>
-
-### If `error-analysis`
-
-- **Symptom** — what does the user/system observe?
-- **Reproduction Steps** — 1-2-3 format. State the environment/preconditions.
-  ```
-  1. <env: staging | local | prod>
-  2. <action>
-  3. <action>
-  4. Expected: <…> / Actual: <…>
-  ```
-- **Frequency** — always / intermittent / only under specific conditions / one-off?
-- **Blast Radius** — scope of affected users/requests/data
-- **Suspected Cause(s)** — hypotheses so far. Each with confidence (High/Med/Low) and rationale.
-- **What has been ruled out** — false leads already verified (so the worker doesn't retread them)
-
----
-
-## Constraints and Risks
-
-- **Business constraints**: <e.g. PII, SLA — do not list external approval/authorization items (assume the user holds all permissions)>
-- **Technical constraints**: <e.g. backward-compat, existing client, schema>
-- **Delivery constraints**: <deadline, dependent deployment, rollout gate — but do not list waiting on external approval or permission checks as schedule factors>
-- **Approval / review checkpoints**: _N/A — assume the user holds all permission and approval authority (okstra default rule). Describe specifically only when a genuine external blocker exists._
-- **Known assumptions**: <explicit assumptions — items for the worker to verify>
-- **Open uncertainties**: <things to confirm — answering them unlocks a decision. Exclude external permission/approval items>
-
----
-
-## Configuration / Deployment Context
-
-<!--
-Fill this section *only when applicable*. DTO changes, pure logic edits, docs work, etc. are usually _N/A_.
-When irrelevant, replace the entire section with this single line:
-
-  _N/A — this task does not touch config or deployment._
--->
-
-- **Config files in scope**: `<path>` — <which keys are relevant>
-- **Current observed values**: <key=value, cite the source>
-- **Expected values / invariants**: <what must not change + what must change>
-- **Deployment manifests in scope**: `<helm chart / k8s manifest / terraform path>`
-- **Rollout invariants**: <e.g. zero-downtime, version skew window>
-
----
-
-## External Resource Hints (for Lead pre-fetch)
-
-<!--
-A list of external resources the okstra Lead must embed inline into the worker prompt.
-Workers don't access MCP/external tools directly, so the Lead snapshots them ahead of time and embeds them in the prompt.
--->
-
-| Resource | Type | Why needed |
-|----------|------|-----------|
-| `<table-name>` | MySQL schema | <which analysis needs schema verification> |
-| `<library@version>` | Library docs (`mcp__test-context7`) | <to confirm API signatures> |
-| `<aws-doc-keyword>` | AWS knowledge base | <for design verification> |
-| `/Volumes/.../app/<sibling-project>/<path>` | Cross-project file | <reference impl> |
-
-If it's clear there are no resources, mark this section `_N/A_`.
-
----
-
-## Related Tasks
-
-<!--
-You must specify a relation label: blocker | blocked-by | sibling | follow-up | duplicate | shares-codepath
--->
-
-| Task | Relation | Note |
-|------|----------|------|
-| `DEV-XXXX` | `sibling` | same epic, same codebase, possible concurrent changes |
-| `DEV-YYYY` | `blocker` | this task can start only after DEV-YYYY completes |
-
----
-
-## Definition of Done (for this run)
-
-<!--
-Requested Outcome is the big picture. Here you write "the verifiable conditions this run's output must satisfy."
--->
-
-This run's final report must satisfy all of the following:
-
-- [ ] <explicit answer to decision item 1, or "undecidable + reason">
-- [ ] <explicit answer to decision item 2>
-- [ ] <list of remaining blocking questions>
-- [ ] <recommended next phase + reasoning>
-
----
-
-## Questions for Workers
-
-<!--
-Specify priority as P0 (must answer) / P1 (answer if possible) / P2 (bonus).
--->
-
-1. **[P0]** <key question 1>
-2. **[P0]** <key question 2>
-3. **[P1]** <secondary question>
-4. **[P2]** <exploratory question>
-
----
-
-## Expected Outputs
-
-| Category | Expected content |
-|----------|-----------------|
-| Root cause / plan options / blockers | <ranked list of options or candidates> |
-| Missing information | <what additional discovery is required> |
-| Risks | <ordered by severity> |
-| Recommended next actions | <phase routing + concrete next step> |
-
----
-
-## Notes for Lead (synthesis emphasis)
-
-<!--
-Worker selection (which model to use) is decided automatically from recommendedWorkers in task-manifest.json, so don't write it here.
-This section covers *synthesis emphasis* only.
--->
-
-- **Synthesis priority**: <e.g. safety vs speed, public/private boundary accuracy, backward compat>
-- **Where worker disagreement matters most**: <the point where consensus matters most>
-- **Where reduced confidence is acceptable**: <exploratory areas — a hypothesis alone is enough>
-
----
-
-## Brief Hygiene Checklist
-
-Self-check after writing:
-
-- [ ] Every external link has an inline excerpt embedded
-- [ ] The Domain Glossary has every term a codebase-blind worker needs to know
-- [ ] Out of Scope is written explicitly
-- [ ] Only the relevant block of Task-Type Focus remains (the other block is deleted)
-- [ ] If error-analysis, Reproduction Steps are filled in
-- [ ] Definition of Done is a verifiable checklist
-- [ ] The Configuration / Deployment section has content only when applicable, and is closed with `_N/A_` when irrelevant
-- [ ] The ticket title is identifiable in Korean/English/original language
-- [ ] Related Tasks have relation labels specified