okstra 0.62.0 → 0.63.0

package/package.json

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

package/runtime/BUILD.json

@@ -1,5 +1,5 @@
 {
-  "package": "0.62.0",
-  "builtAt": "2026-06-09T08:14:49.499Z",
+  "package": "0.63.0",
+  "builtAt": "2026-06-09T09:05:23.698Z",
   "repoRoot": "/home/runner/work/okstra/okstra"
 }

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

@@ -90,8 +90,12 @@ You are an in-process Claude subagent — Lead's `Agent()` call blocks until you
 
 After your `Write` to the assigned worker-results file (path provided by Lead as `**Result Path:**` — the canonical anchor header defined in `okstra-team-contract` "Worker Prompt Composition" — or derived under `runs/<task-type>/worker-results/claude-worker-<task-type>-<seq>.md`) succeeds:
 
-1. Return your final assistant message **immediately**, in this format:
-   `Worker results written to <abs path>. Sections 1–5 complete. Findings: <n>.`
+1. Return your final assistant message **immediately**. Begin every return with your model identity, copied verbatim from the `**Model:** Claude worker, <modelExecutionValue>` line in your dispatch prompt (per Worker Preamble → "Return message to the lead"), then the status line — for an analysis dispatch:
+   ```
+   **Model:** Claude worker, <modelExecutionValue>
+   Worker results written to <abs path>. Sections 1–5 complete. Findings: <n>.
+   ```
+   The `**Model:**` line precedes whatever you return — analysis status above, or a convergence reverify verdict summary.
 2. Do NOT perform additional `Read`, `Grep`, `Glob`, MCP, or self-review tool calls after the file is written.
 3. Do NOT rewrite the worker-results file with `Write` more than once. If a correction is genuinely required, perform a single `Edit` and then return immediately.
 4. The only exception is recording a `tool-failure` in the errors sidecar when a post-Write failure is itself the failure being reported — return immediately after that single sidecar append.

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

@@ -106,7 +106,11 @@ The wrapper exists because Claude Code's Bash permission matcher rejects simple-
       2. Record a `cli-failure` event directly to the run-level error log via the exact `okstra-error-log.py append-observed` template in §"Error reporting" — substitute `--exit-code 0`, `--duration-ms <observed-ms>`, `--message "okstra-codex-exec.sh exited 0 but no result file at <abs-path>"`, and `--stderr-excerpt-file <temp-tail-path>`.
       3. Return `CODEX_RESULT_MISSING: codex exited 0 but result file absent at <abs-path>` instead of the raw stdout. The lead is responsible for deciding redispatch per `okstra-team-contract` "Lead Redispatch Policy on Result-Missing".
 
-   d. **Normal return.** Otherwise (`exit_code == 0` AND result file exists), concatenate the wrapper's accumulated stdout from `BashOutput` and return it as-is without modification.
+   d. **Normal return.** Otherwise (`exit_code == 0` AND result file exists), return the wrapper's accumulated stdout from `BashOutput`, prefixed by exactly one model-identity line copied verbatim from the `**Model:** Codex worker, <execution-value>` line in the lead prompt (per Worker Preamble → "Return message to the lead"):
+      ```
+      **Model:** Codex worker, <assigned-model-execution-value>
+      ```
+      Emit that line first, then the stdout unmodified. The model line is the ONLY addition permitted — do not otherwise summarize or alter the CLI output. This applies to convergence reverify dispatches too.
 
 9. When `Task Type` is `improvement-discovery`, the lead's Phase 1.5 reflect-back log at `<RUN_DIR>/state/phase-1.5-grilling.md` is the authoritative scope and lens definition. Read its `Resolved scope` and `Resolved lenses` blocks and do NOT re-interpret the brief's raw `scan-scope` / `priority-lenses` fields. Findings that violate the resolved lens whitelist or scope are rejected by `validators/validate-improvement-report.py`.
 
@@ -228,7 +232,7 @@ pre-flight terminal status, not a runtime CLI error.
 
 - Ignore stderr warnings from MCP integration.
 - Return error messages as-is on failure.
-- Do not summarize or modify Codex results.
+- Do not summarize or modify Codex results beyond prepending the single `**Model:**` line on a normal return (step 8d).
 - Sections 1–5 of the worker output are the common core shared with the Claude and Gemini workers — the dispatched prompt asks identical questions for all three roles, and the Codex CLI must answer all of them, not only implementation-feasibility findings. Your specialization (implementation realism, code-path implications, edge cases, technical trade-offs) belongs only in optional Section 6 as additive depth. A Codex result whose Findings section is populated solely with implementation-feasibility items is in breach of contract; see `skills/okstra-team-contract/SKILL.md` "Worker Output Contract".
 
 ## Stage evidence emission (BLOCKING, implementation task only)

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

@@ -106,7 +106,11 @@ The wrapper exists because Claude Code's Bash permission matcher rejects simple-
       2. Record a `cli-failure` event directly to the run-level error log via the exact `okstra-error-log.py append-observed` template in §"Error reporting" — substitute `--exit-code 0`, `--duration-ms <observed-ms>`, `--message "okstra-gemini-exec.sh exited 0 but no result file at <abs-path>"`, and `--stderr-excerpt-file <temp-tail-path>`.
       3. Return `GEMINI_RESULT_MISSING: gemini exited 0 but result file absent at <abs-path>` instead of the raw stdout. The lead is responsible for deciding redispatch per `okstra-team-contract` "Lead Redispatch Policy on Result-Missing".
 
-   d. **Normal return.** Otherwise (`exit_code == 0` AND result file exists), concatenate the wrapper's accumulated stdout from `BashOutput` and return it as-is without modification.
+   d. **Normal return.** Otherwise (`exit_code == 0` AND result file exists), return the wrapper's accumulated stdout from `BashOutput`, prefixed by exactly one model-identity line copied verbatim from the `**Model:** Gemini worker, <execution-value>` line in the lead prompt (per Worker Preamble → "Return message to the lead"):
+      ```
+      **Model:** Gemini worker, <assigned-model-execution-value>
+      ```
+      Emit that line first, then the stdout unmodified. The model line is the ONLY addition permitted — do not otherwise summarize or alter the CLI output. This applies to convergence reverify dispatches too.
 
 9. When `Task Type` is `improvement-discovery`, the lead's Phase 1.5 reflect-back log at `<RUN_DIR>/state/phase-1.5-grilling.md` is the authoritative scope and lens definition. Read its `Resolved scope` and `Resolved lenses` blocks and do NOT re-interpret the brief's raw `scan-scope` / `priority-lenses` fields. Findings that violate the resolved lens whitelist or scope are rejected by `validators/validate-improvement-report.py`.
 
@@ -228,7 +232,7 @@ pre-flight terminal status, not a runtime CLI error.
 
 - Always specify the assigned `-m` value for the current run.
 - Return error messages as-is on failure.
-- Do not summarize or modify Gemini results.
+- Do not summarize or modify Gemini results beyond prepending the single `**Model:**` line on a normal return (step 8d).
 - Sections 1–5 of the worker output are the common core shared with the Claude and Codex workers — the dispatched prompt asks identical questions for all three roles, and the Gemini CLI must answer all of them, not only requirement-interpretation findings. Your specialization (requirement interpretation, consistency, safety, documentation quality, alternative viewpoints) belongs only in optional Section 6 as additive depth. A Gemini result whose Findings section is populated solely with requirement-interpretation items is in breach of contract; see `skills/okstra-team-contract/SKILL.md` "Worker Output Contract".
 
 ## Stage evidence emission (BLOCKING, implementation task only)

package/runtime/agents/workers/report-writer-worker.md

@@ -103,7 +103,12 @@ Rules (the schema enforces most of these — they are listed here so you know *w
 - For `implementation-planning`, populate `implementationPlanning.requirementCoverage` with one row per concrete requirement from the brief / packet, using IDs `R-001`, `R-002`, ... in source order. `coveredBy` MUST name the specific Option Candidate plus Stage/Step that satisfies the requirement. Use `status: "covered"` only when the report's plan actually covers it; otherwise use `gap` or `blocked C-NNN` and ensure the corresponding `Clarification Items` row blocks approval. Do not collapse this into `ticketCoverage`; ticket coverage is not requirement coverage.
 - When the `Task Type` is `improvement-discovery`, populate `## 5.9 Improvement Candidates` with the 10-column schema enforced by `validators/validate-improvement-report.py`. Source the row IDs (`I-NNN`), lens whitelist, and Source workers patterns from `scripts/okstra_ctl/improvement_lenses.py` — do NOT introduce new lens names or worker prefixes. `improvement-discovery` is NOT in the data.json schema enum, so author its markdown directly (not via `okstra-render-final-report.py`). Immediately after writing the markdown, run (`Bash`): `python3 scripts/okstra-inject-report-index.py <markdown path> --report-language <en|ko>`. That adds the top-of-report Index plus `I-NNN` / `C-NNN` scroll anchors; the run validator fails the report when the Index anchor is absent.
 
-Write the data.json with your `Write` tool against the absolute `Result Path`. Then invoke the renderer (`Bash`): `python3 scripts/okstra-render-final-report.py <data.json path>`. Confirm both files exist and respond with a short status line: `data.json written to <abs path>; markdown rendered to <abs path>. Sections populated: <count>.`
+Write the data.json with your `Write` tool against the absolute `Result Path`. Then invoke the renderer (`Bash`): `python3 scripts/okstra-render-final-report.py <data.json path>`. Confirm both files exist and respond with a short status line prefixed by your model identity, copied verbatim from the `**Model:** Report writer worker, <modelExecutionValue>` line in your dispatch prompt (per Worker Preamble → "Return message to the lead"):
+
+```
+**Model:** Report writer worker, <modelExecutionValue>
+data.json written to <abs path>; markdown rendered to <abs path>. Sections populated: <count>.
+```
 
 <!-- Worker Result File contract lives above, right after the Authority
      section. The legacy "after Authoring Contract" placement was kept

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

@@ -235,18 +235,15 @@ implementation-option: {{ frontmatter.implementationOption | yaml_scalar }}
 {% for stage in implementationPlanning.stages %}
 ## 5.5.{{ stage.stage }} Stage {{ stage.stage }}: {{ stage.title }}
 
-Slice value: {{ stage.sliceValue }}
-
-Acceptance: {{ stage.acceptance }}
-
+- **Slice value:** {{ stage.sliceValue }}
+- **Acceptance:** {{ stage.acceptance }}
 {% if stage.conformanceTests %}
-Conformance tests: stage-{{ stage.stage }} — {{ stage.conformanceTests }}
+- **Conformance tests:** stage-{{ stage.stage }} — {{ stage.conformanceTests }}
 {% else %}
-Conformance exemption: {{ stage.conformanceExemption }}
+- **Conformance exemption:** {{ stage.conformanceExemption }}
 {% endif %}
 {% if stage.tddExemption %}
-
-TDD exemption: {{ stage.tddExemption }}
+- **TDD exemption:** {{ stage.tddExemption }}
 {% endif %}
 
 ### Carry-In

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

@@ -68,7 +68,7 @@
     "columnRelatedIds": "Related item IDs"
   },
   "finalVerdict": {
-    "intro": "Final conclusion and recommended direction. `Direction` values: `continue-investigation / begin-implementation / approve / reject / hold`. When `task-type` is `final-verification`, `Verdict Token` is one of `accepted / conditional-accept / blocked` and serves as the `release-handoff` entry gate. For all other task-types: `not-applicable`."
+    "intro": "This run's final conclusion and next action. **`Direction`** is the recommended next action — one of `continue-investigation`, `begin-implementation`, `approve`, `reject`, or `hold` — and is present for every task-type. **`Verdict Token`** is meaningful only for the `final-verification` task-type, where it is one of `accepted`, `conditional-accept`, or `blocked` and serves as the `release-handoff` entry gate. For every other task-type, `Verdict Token` is always `not-applicable`."
   },
   "evidence": {
     "sourceItemsColumnNote": "The `Source items` column is described in §6.1."

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

@@ -68,7 +68,7 @@
     "columnRelatedIds": "관련 항목 IDs"
   },
   "finalVerdict": {
-    "intro": "최종 결론과 권장 방향입니다. `Direction` 값: `continue-investigation / begin-implementation / approve / reject / hold`. `task-type` 이 `final-verification` 일 때 `Verdict Token` 은 `accepted / conditional-accept / blocked` 중 하나이며 `release-handoff` 진입 게이트로 쓰입니다. 그 외 task-type 에서는 `not-applicable`."
+    "intro": "이 run 의 최종 결론과 다음 행동입니다. **`Direction`** 은 권장 다음 행동으로 `continue-investigation`(조사 계속) · `begin-implementation`(구현 시작) · `approve`(승인) · `reject`(반려) · `hold`(보류) 중 하나이며, 모든 task-type 에 존재합니다. **`Verdict Token`** 은 `final-verification` task-type 에서만 의미를 가집니다 — `accepted` · `conditional-accept` · `blocked` 중 하나로 `release-handoff` 진입 게이트로 쓰입니다. 그 외 task-type 에서 `Verdict Token` 은 항상 `not-applicable`(해당 없음) 입니다."
   },
   "evidence": {
     "sourceItemsColumnNote": "`Source items` 열 설명은 §6.1 과 동일합니다."

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

@@ -114,6 +114,16 @@ For task types `requirements-discovery`, `error-analysis`, `implementation-plann
 
 See `skills/okstra-team-contract/SKILL.md` "Worker Output Contract" for the full frontmatter schema and section ordering rules. This preamble is consistent with that contract; the team-contract document is authoritative if the two ever diverge.
 
+## Return message to the lead (all workers)
+
+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:
+
+```
+**Model:** <Role>, <modelExecutionValue>
+```
+
+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 / Gemini / 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".
+
 ## Writing style (all prose output — analysis workers + report-writer)
 
 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.

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

@@ -162,11 +162,16 @@ def _check_each_stage_section(text: str, stages: List[StageMeta]) -> List[Valida
     return errs
 
 
-SLICE_VALUE = re.compile(r"^\s*Slice value\s*:\s*(.+?)\s*$", re.M)
-ACCEPTANCE = re.compile(r"^\s*Acceptance\s*:\s*(.+?)\s*$", re.M)
-TDD_EXEMPTION = re.compile(r"^\s*TDD exemption\s*:\s*\S", re.M)
-CONFORMANCE_TESTS = re.compile(r"^\s*Conformance tests\s*:\s*\S", re.M)
-CONFORMANCE_EXEMPTION = re.compile(r"^\s*Conformance exemption\s*:\s*\S", re.M)
+# Each label line may be plain (`Slice value: …`) or rendered as a bold-label
+# bullet (`- **Slice value:** …`). The optional `(?:[-*]\s+)?` bullet marker and
+# the two optional `\*\*` groups accept both forms; the bold wraps the colon, so
+# the closing `**` sits AFTER the colon.
+_LABEL_PREFIX = r"^\s*(?:[-*]\s+)?(?:\*\*)?"
+SLICE_VALUE = re.compile(_LABEL_PREFIX + r"Slice value\s*:\s*(?:\*\*)?\s*(.+?)\s*$", re.M)
+ACCEPTANCE = re.compile(_LABEL_PREFIX + r"Acceptance\s*:\s*(?:\*\*)?\s*(.+?)\s*$", re.M)
+TDD_EXEMPTION = re.compile(_LABEL_PREFIX + r"TDD exemption\s*:\s*(?:\*\*)?\s*\S", re.M)
+CONFORMANCE_TESTS = re.compile(_LABEL_PREFIX + r"Conformance tests\s*:\s*(?:\*\*)?\s*\S", re.M)
+CONFORMANCE_EXEMPTION = re.compile(_LABEL_PREFIX + r"Conformance exemption\s*:\s*(?:\*\*)?\s*\S", re.M)
 
 
 def _check_slice_tdd(text: str, stages: List[StageMeta]) -> List[ValidationError]: