okstra 0.125.2 → 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.2",
+  "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.2",
-  "builtAt": "2026-07-20T09:08:03.300Z",
+  "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/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
 
 

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/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/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