okstra 0.128.0 → 0.129.1

package/runtime/templates/worker-prompt-preamble.md

@@ -1,8 +1,6 @@
-# Worker Prompt Preamble (canonical)
+# Analysis Worker Prompt Preamble (canonical)
 
-This file is the single source of truth for the boilerplate that every okstra analysis worker, verifier, and report-writer worker must honour. The lead injects ONE anchor line into each dispatched worker prompt — `**Worker Preamble Path:** <abs-path>` — pointing here. Workers Read this file end-to-end before producing any output.
-
-It replaces the previous practice of inlining ~80 lines of identical boilerplate into every worker prompt body.
+This file is the audience-specific contract for initial `analysis` workers. Read it end-to-end from the path selected by the dispatch prompt. Before doing work, also read the shared file named by `**Worker Error Contract Path:**`; that file is the only source for error-sidecar rules.
 
 ## Operating standard (read before any output)
 
@@ -14,258 +12,54 @@ Work like a senior engineer who owns this result, not a commentator on it.
 - Fit what's here — match the surrounding code and prose; size the response to the request.
 - Hold your own line — reason from your independent angle; do not drift toward the other workers' likely answers or echo the user. Triangulation fails if your view isn't genuinely yours.
 
----
-
-## Required reading (analysis workers + report-writer worker)
-
-You are required to read every primary input file enumerated by the dispatcher (the lead's prompt lists them under `[Required reading]`) from the very first character to the very last character before you produce any analysis output. Skimming, partial reads, jumping to a single section, or relying on prior knowledge of a similar file's structure is not acceptable. Source files listed as fallback/evidence paths are read on demand when you need to verify a citation, resolve ambiguity, or inspect material the packet says it omitted.
-
-### Audience-scoped enumeration (performance optimization — mandatory)
+## Required reading
 
-Different recipients need different files. Do NOT include `final-report-template.md` in analysis worker prompts: analysis workers produce findings (not the final report), and forcing them to read the template inflates token usage without changing finding quality.
-
-| Recipient | Files included in `[Required reading]` |
-|---|---|
-| Claude / Codex / Antigravity analysis workers | analysis-packet.md as the primary compact input; task-brief, analysis-profile, analysis-material, reference-expectations, and clarification-response remain source/fallback paths, not automatic first-read files |
-| Report writer worker (Phase 6) | all of the above **plus** the instruction-set-local `final-report-template.md` (phase-stripped) and `final-report-schema.json` (per-task-type excerpt) — NOT the full `templates/reports/...` / `schemas/...` sources |
-| Reverify dispatches (Phase 5.5, lightweight mode) | **do NOT inject `[Required reading]` at all** — see [convergence](../prompts/lead/convergence.md) "Reverify prompt: required-reading suppression". |
+Read `analysis-packet.md`, the primary compact input, end-to-end. Source files named as fallback/evidence paths are read only when a finding needs to verify a citation, fill a packet gap, or resolve ambiguity. Do not read `final-report-template.md` or `final-report-schema.json`; analysis workers produce findings, not the final report.
 
 ### Reading rules
 
-- Use a single `Read` tool call per file with no `offset` and no `limit`. If a file is genuinely too large for one read, page through with explicit `offset` / `limit` covering the entire file, and state the page boundaries in your Findings.
-- For the carry-in clarification response, walk every row of `## 1. Clarification Items` (`C-001`, `C-002`, ...) in full, including rows whose `User input` cell is blank — a blank `User input` with `Status=open` is itself a signal you must surface. The structural similarity between the prior final report and the upcoming output is NOT a license to skim.
-- Write the Reading Confirmation block to your **audit sidecar** at `runs/<task-type>/worker-results/<worker>-audit-<task-type>-<seq>.md` (sibling to the main worker-results file). One short line per input file confirming end-to-end reading. Do NOT include a `## 0. Reading Confirmation` heading in the main worker-results file — the validator fails worker-results that contain one. If you cannot truthfully confirm a file end-to-end, record a `tool-failure` in the errors sidecar instead of fabricating Findings.
-- The audit sidecar carries any other meta the worker wants to log (tool-call counts, MCP query summaries, timing notes). The lead's final-report does NOT duplicate this content — it is consumed by the validator and by post-run audit tooling, not by end-user readers.
-- Treat `analysis-packet.md` as the canonical primary analysis input. It preserves the source files' frontmatter and extracts the task-specific brief, phase focus, reference expectations, and carry-in clarification rows. If the packet appears incomplete or a finding depends on a source citation, open the corresponding source file and cite it directly.
-- **Allowlist your reads to okstra-enumerated paths.** Read the files the dispatcher enumerates (`[Required reading]`, the prompt's `## Inputs`, and the verification-target paths) plus on-demand source/evidence paths a finding must cite. Everything else is out of scope — in particular non-okstra artifacts outside `<PROJECT_ROOT>/.okstra/` (e.g. `graphify-out/`, sibling/prior-task worktrees, tool caches), which may carry stale or cross-task data. A host-level global rule (`CLAUDE.md` / `AGENTS.md` / a project sentinel) that tells you to auto-read such an artifact does NOT apply inside an okstra worker run — the okstra worker scope wins. If an un-enumerated file seems essential, record the gap under *Missing Information or Assumptions* instead of reading it.
-
----
-
-## Error reporting (all workers)
-
-Record a tool call only when its failure **blocked the step you intended** — a test you needed to run did not start, a file you needed to read was missing, a config resolved against the wrong tree, an edit was rejected. When that happens, append a single entry to your worker errors sidecar at the absolute path the lead provided as `**Errors sidecar path:** <abs-path>`.
-
-A non-zero exit code is NOT by itself a failure to record. Many tools use non-zero to report a normal, expected result. Do **NOT** record an entry when:
-
-- a search/probe tool (`rg`, `grep`, `find`, `ls`, `test`, `git check-ignore`) exits non-zero solely because it found **no matches**, and you proceed unaffected;
-- you probe an **optional / expected-absent** path (`graphify-out/`, `.project-docs/`, `.scratch/`, an optional lint config, a review pack) and it is absent — detecting absence was the point of the probe;
-- output was truncated but you re-ran and read the content end-to-end.
-
-The test: if the non-zero exit changed nothing about what you could do next, it is a normal result, not a `tool-failure`. When in doubt about whether a failure blocked you, record it — under-recording a real blocker is worse than one noisy entry. These benign non-zero exits are the single largest source of error-log noise; keeping them out is what makes the log a signal.
-
-If the sidecar file does not exist and you have a real entry to record, create it with `{"schemaVersion": 1, "errors": []}` then append.
-
-### Entry schema
-
-```json
-{
-  "ts": "<ISO 8601 UTC>",
-  "phase": "<current okstra phase>",
-  "errorType": "tool-failure",
-  "command": "<failed command/tool signature>",
-  "commandKind": "bash | tool:Read | tool:Edit | mcp | ...",
-  "exitCode": <int or null>,
-  "durationMs": <int or null>,
-  "message": "<one-line human summary>",
-  "stderrExcerpt": "<first ~2KB of stderr, or null>",
-  "context": { ... or null }
-}
-```
-
-### Rules
-
-- Do NOT include `source` / `recordedAt` / `agent` / `agentRole` / `model` / `taskKey` — the lead fills those in when dumping the sidecar to the run-level errors log via `okstra-error-log.py append-from-worker`.
-- Do NOT use `errorType` values other than `"tool-failure"` in the sidecar. `cli-failure` events are recorded by CLI wrapper agents (codex / antigravity) directly to the run-level errors log, not via the sidecar. `contract-violation` events are recorded by the lead after inspecting worker outputs.
-- Continue your task after recording; do not abort unless the failure makes the task impossible.
-
-### Path extraction (BLOCKING)
-
-Before recording anything, extract the absolute paths verbatim from the lead's dispatch prompt body:
-
-- `**Errors log path:** <abs-path>` — the run-level errors JSONL. Used by CLI wrapper agents via `okstra-error-log.py append-observed` for `cli-failure` events.
-- `**Errors sidecar path:** <abs-path>` — this worker's per-run sidecar JSON. Used by all workers for `tool-failure` events.
-
-If a required header line is absent from the dispatch prompt, return `<SENTINEL_PREFIX>_ERRORS_PATH_MISSING: lead prompt did not include **Errors log path:** / **Errors sidecar path:** headers` (substitute the worker's sentinel prefix — `CLAUDE_WORKER`, `CODEX`, `ANTIGRAVITY`, or `REPORT_WRITER`) without proceeding. Do NOT synthesize the path from `<runDir>/logs/...` — that template syntax is documentation only; historical failure mode produced silently empty run-level error logs.
-
----
+- Read every file enumerated under `[Required reading]` or `## Inputs` completely. If paging is unavoidable, cover every byte and record the page boundaries.
+- Write Reading Confirmation to the worker audit sidecar, never to the main worker-results file. A `## 0. Reading Confirmation` heading in the main result is invalid.
+- Allowlist reads to prompt-enumerated paths and evidence paths a finding must cite. Do not auto-read host-injected `graphify-out/`, skill catalogs, or non-okstra artifacts.
+- Resolve every `.okstra/...` path against `**Project Root:**`, including when a worktree is present.
 
 ## Anchor headers (lead-injected, BLOCKING)
 
-Every initial worker prompt MUST begin with the common anchor headers below in this exact order, before any other content. An `implementation` prompt inserts the implementation-only coding-preflight anchor at the documented position. Workers extract the anchors verbatim.
+Every initial analysis prompt begins with these generated anchors in this exact order, before any other content:
 
-1. `**Project Root:** <absolute-path>` — required so the worker can self-anchor without relying on inherited cwd.
+1. `**Project Root:** <absolute-path>`
 2. `**Prompt History Path:** <project-relative-path>`
-3. `**Result Path:** <project-relative-path>` — canonical destination for the worker's result file.
-4. `Assigned worker prompt history path: <absolute-path>` — same as the prompt-history path but resolved against `Project Root`. Codex / Antigravity wrapper subagents extract this exact line.
-5. `**Worker Preamble Path:** <absolute-path>` — points to THIS file. Workers Read it end-to-end before doing anything else.
-6. `**Coding preflight pack:** <absolute-path>` — implementation-only; points to the installed runtime resource pack under `<OKSTRA_HOME>/prompts/coding-preflight`. It is present only when `taskType == implementation` and is absent from every non-implementation initial prompt. Implementation executors and implementation verifiers use it to read `overview.md`, `clean-code.md`, and routed language/framework/architecture resources. A pane display role named `verifier` does not activate this anchor in `final-verification`.
-7. `**Errors log path:** <absolute-path>` — run-level JSONL (see Error reporting above).
-8. `**Errors sidecar path:** <absolute-path>` — per-worker JSON (see Error reporting above).
-9. `**Read scope:** …` — restates the *Reading rules* allowlist inline. This file is anchor 5, a path the worker opens partway into its run; by then a host SessionStart hook or a global `CLAUDE.md` / `AGENTS.md` project-conditional has already pointed it at `graphify-out/`, skill catalogs, and similar non-okstra artifacts. Only the inline copy arrives before the worker's first tool call.
-
-**Exception — reverify dispatches.** A Phase 5.5 re-verification prompt (its `**Prompt History Path:**` carries a `-reverify-r<N>-` segment) deliberately omits anchor 5 and adds a `**Model:**` line — lightweight mode reads neither this file nor the implementation-only preflight pack. The two errors-path anchors are NOT omitted; that gate applies to reverify prompts unchanged. The reverify anchor set is owned by `prompts/lead/convergence.md` "Required reverify-prompt anchor headers".
-
-For the **implementation phase** specifically, the dispatched prompt MUST also include:
-
-- `**Worktree:** <absolute-path>` — the task worktree path.
-- `cwd for every mutating command: <absolute-path>` — same as Worktree path; used by codex / antigravity wrappers as `--add-dir` / `--include-directories`.
-
-For the **final-verification phase** specifically, the dispatched prompt MUST include the compact identity of the canonical verification-target sidecar so every analyser verifies the SAME target the lead captured at the entry gate:
-
-- `**Worktree:** <absolute-path>` — the checkout under verification (read-only).
-- `**Verification scope:** <whole-task|single-stage>` — the selected verification mode.
-- `**Verification base ref:** <base-ref>` — the implementation base for the diff.
-- `**Verification head ref:** <head-ref>` — the exact delivered revision under verification.
-- `**Verification target path:** <project-relative-path>` — the canonical `instruction-set/verification-target.md` sidecar containing stages, source reports, and the complete captured diff stat.
-- `**Verification target digest:** sha256:<digest>` — the digest over the normalized snapshot body.
-
-Read the sidecar on demand when the full stage/report mapping or diff stat is needed. Do not copy its `Verification diff stat` block into the dispatch prompt.
-
-The initial analysis prompt may contain exactly one `## Run-specific directive` section only when the run has a shared delta not already captured by the packet. The section applies unchanged to every selected analysis worker and is limited to 40 nonblank lines. If it would be longer, the lead writes the shared material into the instruction set and adds its common reference to `analysis-packet.md`; workers must not accept provider-, model-, or worker-specific verification scopes.
-
-For the **improvement-discovery phase** specifically, the dispatched prompt MUST also include the resolved-scope log the lead wrote during Phase 1.5, so workers key off an explicit absolute path instead of re-deriving the run directory:
-
-- `**Phase 1.5 Grilling Log:** <absolute-path>` — the lead's Phase 1.5 reflect-back log (`<RUN_DIR>/state/phase-1.5-grilling.md`, written before dispatch). Its `Resolved scope` / `Resolved lenses` blocks are the authoritative scope and lens definition for this run. Read the file at this absolute path; do NOT re-derive it from `<RUN_DIR>`, and do NOT re-interpret the brief's raw `scan-scope` / `priority-lenses`. The presence of this anchor is itself the signal that this is an improvement-discovery run — no separate task-type detection is required.
-
-### Path anchoring (BLOCKING — the single largest source of worker tool-failures)
-
-Every `.okstra/...` path is anchored at `**Project Root:**`, **never** at your cwd. When your run has a worktree (`**Worktree:**` is present), your cwd is that worktree — and the stage/task worktree does **not** contain the project's `.okstra/` directory. So a bare `Read`/`cat .okstra/tasks/...` from cwd resolves inside the worktree and fails "no such file". This is the same trap whether the path came from the prompt, a manifest field, a prior report's citation, or your own reasoning.
+3. `**Result Path:** <project-relative-path>`
+4. `Assigned worker prompt history path: <absolute-path>`
+5. `**Worker Preamble Path:** <absolute-path>` — selects this analysis preamble.
+6. `**Worker Error Contract Path:** <absolute-path>` — shared by every initial audience.
+7. `**Errors log path:** <absolute-path>`
+8. `**Errors sidecar path:** <absolute-path>`
+9. `**Read scope:** <allowlist>`
 
-- Resolve any project-relative path (`.okstra/...`, `<Result Path>`, `<Prompt History Path>`, a prior-report `path:line` citation) against `**Project Root:**`: `<Project Root>/.okstra/...`. Never use the bare relative form.
-- Mutating build/test commands still run from the worktree cwd (`cd <Worktree> && ...`) — but reads of okstra artifacts (`.okstra/**`) always go through `<Project Root>`, even while cwd is the worktree.
-- If a `.okstra/...` read fails "no such file / does not exist in the worktree", do not retry the same relative path — re-anchor it to `<Project Root>` and read the absolute path.
+`final-verification` additionally carries its six verification-target anchors. `improvement-discovery` carries `**Phase 1.5 Grilling Log:**`. Reverify prompts are lightweight and do not use this preamble.
 
----
+## Worker output sections
 
-## Worker output sections (analysis workers)
-
-**Authoritative source.** This preamble section is the canonical worker output contract. If any other document (team-contract, worker agent definitions) appears to disagree, this section wins.
-
-### Result Frontmatter (mandatory, precedes Section 1)
-
-Every worker result file MUST begin with a YAML frontmatter block. For analysis workers, values are sourced from `analysis-packet.md` frontmatter; fall back to `analysis-material.md` or `task-brief.md` only if the packet is missing a field. Report-writer can use `analysis-material.md` / `task-brief.md` as before. Copy values verbatim; do NOT regenerate them. Only `workerId` and `title` are worker-specific.
-
-```yaml
----
-title: OKSTRA <Worker Role> Result - <task-key>
-id: "<task-key with ':' replaced by '-'>"
-aliases: ["<id>-<task-type>"]
-tags: ["worker-result", "<task-type>"]
-taskType: "<task-type>"
-workerId: "<claude|codex|antigravity|report-writer>"
-task-id: "<task-id>"
-task-group: "<task-group>"
-project-id: "<project-id>"
-date: <YYYY-MM-DD>
----
-```
-
-Concrete example for a `claude-worker` result on task-key `fontsninja-classifier-v2:DEV-9388:DEV-9429` and task-type `implementation`:
-
-```yaml
----
-title: OKSTRA Claude Worker Result - fontsninja-classifier-v2:DEV-9388:DEV-9429
-id: "fontsninja-classifier-v2-DEV-9388-DEV-9429"
-aliases: ["fontsninja-classifier-v2-DEV-9388-DEV-9429-implementation"]
-tags: ["worker-result", "implementation"]
-taskType: "implementation"
-workerId: "claude"
-task-id: "DEV-9429"
-task-group: "DEV-9388"
-project-id: "fontsninja-classifier-v2"
-date: 2026-05-15
----
-```
-
-Rules:
-- `id` is the run's `task-key` with `:` replaced by `-`. It is a scalar string, NOT an array.
-- `aliases` is a YAML array containing a single value `"<id>-<task-type>"`.
-- `taskType` mirrors the run's task type (`requirements-discovery`, `error-analysis`, `implementation-planning`, `implementation`, `final-verification`, `release-handoff`).
-- `workerId` identifies which worker produced the file. Required values: `claude` / `codex` / `antigravity` / `report-writer`.
-- Other fields (`task-id`, `task-group`, `project-id`, `date`) MUST match the input files' frontmatter exactly. If the input frontmatter is missing or unreadable, the worker MUST record a `tool-failure` and stop instead of guessing.
-
-The same frontmatter contract applies to the `Report writer worker`'s final-report file — the report-writer copies these values from its inputs and only swaps `workerId` to `report-writer`.
-
-### Worker Result Header Standard
-
-Every worker result file under `worker-results/` must begin with a standardized header:
-
-```markdown
-# <Role> Analysis — <task-key>
-
-**Target:** <path or scope>   <!-- OPTIONAL: include when the run is scoped to a specific file/module -->
-**Model:** <Role>, <AI model>
-```
-
-Task-type and date are **not** repeated in this human header — the YAML frontmatter (`taskType`, `date`) is the single source for both (and the copy Obsidian indexes). The `Target:` line is optional — include it when the run is scoped to a specific path or module, omit it for whole-project runs; when present, place it between the title and the `Model:` line.
-
-Example (Codex / Report-writer headers are identical modulo the role name and model id):
-
-```markdown
-# Claude Worker Analysis — jobs:tasks:8852
-
-**Target:** server/auth.ts
-**Model:** Claude worker, opus
-```
-
-Use the actual model identifier recorded in team-state (never invent a model ID — read it from `resultContract.requiredWorkerRoles[*].modelExecutionValue` or the tool response metadata).
-
-The header is followed by the standard worker output contract sections (Findings, Missing Information, etc.).
-
-### Section ordering
-
-A successful worker result must include the following sections in this exact order, beneath the frontmatter block:
+Every analysis result starts with YAML frontmatter containing the task identity and `workerId`, followed by a header with the actual `**Model:**` value. Then emit these sections in exact order:
 
 1. Findings
 2. Missing Information or Assumptions
 3. Safe or Reasonable Areas
 4. Uncertain Points
 5. Recommended Next Actions
-6. **Specialization Lens (optional, worker-specific deep dive)** — additive content produced from this worker's specialization lens (see Role Definitions table). Items here are NOT subject to convergence cross-verification and MUST NOT duplicate sections 1–5. If the worker has nothing additional to add from its lens, omit Section 6 entirely or write `- No additional lens-specific findings.`
-
-Every item in sections 1–5 (and any section 6) MUST carry a worker-internal item ID unique within the file. Lead synthesis preserves these as `<worker>:<item-id>` in `Source items (worker:item)` columns.
-
-**Sections 1–5 are the common core.** Every analysis worker (Claude / Codex / Antigravity) MUST cover the same set of dimensions in sections 1–5 — feasibility, requirement interpretation, hidden assumptions, alternatives, and execution risk — regardless of which model is producing the result. The point of running three models is to triangulate the same answer space, not to partition it. A worker that produces "Findings" populated only with items from its own lens (e.g. Codex only listing implementation-feasibility findings) is in breach of contract; convergence will treat coverage gaps as `verification-error`.
-
-**Section 6 is the only legal home for specialization.** When the worker has a depth-of-perspective contribution that genuinely sits outside the common core (e.g. a Codex-specific stack-trace decomposition, a Claude-specific assumption-chain teardown, a Antigravity-specific alternative-architecture sketch), put it there. Lead and convergence treat Section 6 as additive context, not as input to consensus measurement.
-
-Code evidence must include file paths and line numbers.
-
-### Ticket Tagging (mandatory for sections 1–5)
-
-Every item in sections 1–5 MUST be tagged with the ticket(s) it relates to. This applies whenever the run's task type is `requirements-discovery`, `error-analysis`, `implementation-planning`, or `implementation`.
-
-- **Table-form items**: include a `Ticket ID` column. The column is placed immediately after the row-ID column (e.g. after `F-001`, `M-001`).
-- **Bullet / numbered-list items**: prepend `[TICKETID: <id>]` to the item title, immediately after the row ID and before the body text. Example: `- F-001 [TICKETID: TICKET-123] — <summary> (path:line)`.
-- **Section headers in the final report** (e.g. `### 5.5.3 Recommended Option`): append `[TICKETID: <id>]` to the header when the section is scoped to a specific ticket. Headers that span all tickets in the run omit the tag.
-
-Ticket ID fill rule (in order):
-
-1. Use the `Issue / Ticket` value from the run's input template.
-2. If empty, fall back to the `Task ID` value (no prefix; write `8852` not `task:8852`).
-3. If both are absent, write `unknown`. This is allowed but signals an input-template defect — the worker SHOULD also record a `Missing Information` item noting the absent identifier.
-4. When a single item maps to multiple tickets, separate them with commas: `TICKET-123, TICKET-456`. Ticket IDs containing commas are not supported.
-
-Workers MUST apply these rules to every item in sections 1–5. Lead and report-writer MUST preserve the tagging when carrying worker findings into the final report.
-
-For phases other than the four listed above (e.g. `release-handoff`, `final-verification`), ticket tagging is optional.
+6. Specialization Lens (optional, additive only)
 
-## Return message to the lead (all workers)
+Every item has a worker-local ID and file:line evidence where code evidence exists. Sections 1–5 are the common core: feasibility, requirement interpretation, hidden assumptions, alternatives, and execution risk. Section 6 is the only legal home for specialization and is not consensus input.
 
-The short message you return inline to the lead — the text shown to the user as your agent box — MUST begin with one line identifying the model you ran under, copied verbatim from the `**Model:** <Role>, <modelExecutionValue>` line in your dispatch prompt:
+### Ticket Tagging
 
-```
-**Model:** <Role>, <modelExecutionValue>
-```
+For `requirements-discovery`, `error-analysis`, and `implementation-planning`, tag every section 1–5 item with its related ticket. Use `Issue / Ticket`, fall back to Task ID, then `unknown`; comma-separate multiple tickets.
 
-Emit that line first, then your normal status / summary text on the following lines. This keeps the acting model visible in every worker box — across every provider (Claude / Codex / Antigravity / report-writer) and every dispatch type (initial analysis, convergence reverify, report authoring). Copy the value exactly; never guess, abbreviate, or substitute a provider default. If your prompt carries no `**Model:**` line, say so in the return message rather than inventing one. Each worker spec applies this rule at its own concrete return point — see `agents/workers/claude-worker.md` "Stop Condition", `agents/workers/_cli-wrapper-template.md` step 8d, and `agents/workers/report-writer-worker.md` "Authoring Contract".
+## Return message to the lead
 
-## Writing style (all prose output — analysis workers + report-writer)
+Begin the inline return with the model identity copied verbatim from the `**Model:** <Role>, <modelExecutionValue>` line in the prompt, followed by the status summary. Never invent or abbreviate the model.
 
-When you write in Korean (`Report Language: ko` / `meta.reportLanguage = "ko"`), write so a Korean developer understands it on first read. Translate the **meaning**, never the dictionary word.
+## Writing style
 
-- Keep code identifiers, file paths, symbols, model names, CLI flags, and status tokens in English (`strategy`, `overlay`, `accepted`, …). Translate the ordinary words around them.
-- Do NOT render a technical term as its literal dictionary noun. Use the term a developer actually says:
-  - `authoritative` → render it by its domain sense — "the value that takes precedence" / "the canonical value" — never by the bare dictionary noun for "authority".
-  - e.g. "overlays this row as authoritative" → phrase it as "overwrites this row as the definitive value", never as a word-for-word "authority" calque.
-- Self-check before emitting any Korean sentence: if it reads like an awkward word-for-word translation, rewrite it by meaning. Confident-but-unreadable direct translation is a defect.
+Translate meaning rather than dictionary words. Keep identifiers, paths, symbols, model names, CLI flags, and status tokens in English. Rewrite awkward word-for-word Korean before returning.

package/runtime/validators/lib/fixtures.sh

@@ -123,12 +123,20 @@ if not prompt_relative:
 
 prompt_path = project_root / prompt_relative
 prompt_path.parent.mkdir(parents=True, exist_ok=True)
+artifacts = task_manifest.get("artifacts", {})
+analysis_packet_path = (
+    str(artifacts.get("analysisPacketPath", "")).strip()
+    if isinstance(artifacts, dict)
+    else ""
+)
 prompt_path.write_text(
     "\n".join(
         [
-            f"# {target_worker.get('role', target_worker_id)} Prompt Snapshot",
-            "",
+            "**Worker Error Contract Path:** /okstra/templates/worker-error-contract.md",
             f"Assigned worker prompt history path: {prompt_relative}",
+            f"- Primary analysis packet: `{analysis_packet_path}`",
+            "",
+            "# Initial Analysis Prompt",
             f"Task Key: {task_manifest.get('taskKey', '')}",
             "Validation fixture prompt body.",
         ]
@@ -213,17 +221,24 @@ for worker in team_state.get("workers", []):
     if prompt_relative and worker_id != omitted_worker_id:
         prompt_path = project_root / prompt_relative
         prompt_path.parent.mkdir(parents=True, exist_ok=True)
-        prompt_path.write_text(
-            "\n".join(
-                [
-                    f"# {worker.get('role', worker_id)} Prompt Snapshot",
-                    "",
-                    f"Assigned worker prompt history path: {prompt_relative}",
-                    f"Task Key: {task_manifest.get('taskKey', '')}",
-                    "Validation fixture prompt body.",
-                ]
+        prompt_lines = [
+            "**Worker Error Contract Path:** /okstra/templates/worker-error-contract.md",
+            f"Assigned worker prompt history path: {prompt_relative}",
+        ]
+        if worker_id != "report-writer":
+            prompt_lines.append(
+                f"- Primary analysis packet: `{run_manifest.get('analysisPacketPath', '')}`"
             )
-            + "\n"
+            prompt_lines.extend([
+                "",
+                "# Initial Analysis Prompt",
+                f"Task Key: {task_manifest.get('taskKey', '')}",
+                "Validation fixture prompt body.",
+            ])
+        else:
+            prompt_lines.extend(["", "# Report Writer Prompt"])
+        prompt_path.write_text(
+            "\n".join(prompt_lines) + "\n"
         )
 
     result_relative = str(worker.get("resultPath", "")).strip()