okstra 0.158.1 → 0.160.0

package/runtime/python/okstra_ctl/worker_liveness.py

@@ -54,6 +54,14 @@ DEFAULT_LAUNCH_GRACE_SECONDS = 60
 DEFAULT_POLL_INTERVAL_SECONDS = 20.0
 DEFAULT_WAIT_TIMEOUT_SECONDS = 2400.0
 
+# A budget breach is one observation, and "slow" and "dead" are only
+# distinguishable across two. On a breach the probe re-reads the sidecar this
+# far into the future — a fraction of the stage's own budget, so a stage with a
+# longer budget also gets a longer confirmation. Measured false positives this
+# absorbs (dev-10400): `analysis` 386s against a 360s budget,
+# `data-json-write-start` 1602s against 1260s.
+DEFAULT_STALL_CONFIRM_RATIO = 0.5
+
 
 def _utc_now() -> datetime:
     return datetime.now(timezone.utc)
@@ -183,13 +191,58 @@ class ProbeTarget:
     result_path: Path | None = None
 
 
-def probe_one(target: ProbeTarget, *, now: datetime, max_idle: float,
-              launch_grace: float) -> dict:
-    if target.liveness_mode == LIVENESS_AUDIT_HEARTBEAT:
-        return probe_heartbeat(
-            target.artifact, target.dispatched_at, now, max_idle, launch_grace
-        )
-    return probe_launch(target.artifact, target.dispatched_at, now, launch_grace)
+def _confirm_window(probe: dict, stall_confirm: float | None) -> float:
+    """Seconds to wait before a budget breach becomes a verdict.
+
+    Only a breach carries ``budgetSeconds``. The other stalled shapes — a
+    sidecar with no heartbeat at all, a newest beat that predates this dispatch
+    — are not "the worker is mid-tool-call", so waiting tells us nothing new
+    about them.
+    """
+    if "budgetSeconds" not in probe:
+        return 0.0
+    if stall_confirm is not None:
+        return max(0.0, float(stall_confirm))
+    return probe["budgetSeconds"] * DEFAULT_STALL_CONFIRM_RATIO
+
+
+def probe_one(
+    target: ProbeTarget,
+    *,
+    now: datetime,
+    max_idle: float,
+    launch_grace: float,
+    stall_confirm: float | None = None,
+    sleep: Callable[[float], None] = time.sleep,
+    clock: Callable[[], datetime] = _utc_now,
+) -> dict:
+    """One worker's verdict, with a budget breach confirmed before it stands.
+
+    The wait this costs is bounded by the confirmation window; what the probe
+    exists to avoid is paying ``DEFAULT_WAIT_TIMEOUT_SECONDS`` for a worker that
+    died early, and that is still never paid.
+    """
+    if target.liveness_mode != LIVENESS_AUDIT_HEARTBEAT:
+        return probe_launch(target.artifact, target.dispatched_at, now, launch_grace)
+    probe = probe_heartbeat(
+        target.artifact, target.dispatched_at, now, max_idle, launch_grace
+    )
+    if probe["state"] != "stalled":
+        return probe
+    window = _confirm_window(probe, stall_confirm)
+    if window <= 0:
+        return probe
+    sleep(window)
+    confirmed = probe_heartbeat(
+        target.artifact, target.dispatched_at, clock(), max_idle, launch_grace
+    )
+    if confirmed.get("lastHeartbeat") == probe.get("lastHeartbeat"):
+        return confirmed
+    # The question the window asks is whether the heartbeat moved, not whether
+    # the re-read is healthy on its own terms. A beat opening a stage with a
+    # smaller budget than the window we just slept reads as stale the instant it
+    # lands, which would call a worker dead for proving it is alive.
+    return {**confirmed, "state": "live", "reason": ""}
 
 
 def probe_all(
@@ -198,9 +251,15 @@ def probe_all(
     now: datetime,
     max_idle: float,
     launch_grace: float,
+    stall_confirm: float | None = None,
+    sleep: Callable[[float], None] = time.sleep,
+    clock: Callable[[], datetime] = _utc_now,
 ) -> dict:
     probes = [
-        probe_one(t, now=now, max_idle=max_idle, launch_grace=launch_grace)
+        probe_one(
+            t, now=now, max_idle=max_idle, launch_grace=launch_grace,
+            stall_confirm=stall_confirm, sleep=sleep, clock=clock,
+        )
         for t in targets
     ]
     unhealthy = [p for p in probes if p["state"] in ("stalled", "did-not-launch")]
@@ -221,6 +280,7 @@ def wait_for_results(
     launch_grace: float,
     interval: float,
     timeout: float,
+    stall_confirm: float | None = None,
     clock: Callable[[], datetime] = _utc_now,
     sleep: Callable[[float], None] = time.sleep,
 ) -> dict:
@@ -239,7 +299,8 @@ def wait_for_results(
     while True:
         now = clock()
         result = probe_all(
-            targets, now=now, max_idle=max_idle, launch_grace=launch_grace
+            targets, now=now, max_idle=max_idle, launch_grace=launch_grace,
+            stall_confirm=stall_confirm, sleep=sleep, clock=clock,
         )
         pending = [
             str(t.result_path) for t in targets if not result_ready(t)
@@ -367,6 +428,15 @@ def main(argv: list[str] | None = None) -> int:
                         help="--wait poll interval in seconds")
     parser.add_argument("--timeout", type=float, default=DEFAULT_WAIT_TIMEOUT_SECONDS,
                         help="--wait deadline in seconds")
+    parser.add_argument(
+        "--stall-confirm", type=float, default=None,
+        help=(
+            "seconds to re-check a heartbeat budget breach before calling it "
+            "stalled (default: half that stage's budget; 0 disables). A slow "
+            "worker appends its next heartbeat inside this window; a dead one "
+            "does not."
+        ),
+    )
     args = parser.parse_args(argv)
 
     if len(args.team_state) != len(args.worker):
@@ -388,6 +458,7 @@ def main(argv: list[str] | None = None) -> int:
             now=_utc_now(),
             max_idle=args.max_idle,
             launch_grace=args.launch_grace,
+            stall_confirm=args.stall_confirm,
         )
         print(json.dumps(result, ensure_ascii=False, indent=2))
         # Non-zero on an unhealthy worker so a poll loop can branch on the exit
@@ -410,6 +481,7 @@ def main(argv: list[str] | None = None) -> int:
         launch_grace=args.launch_grace,
         interval=args.interval,
         timeout=args.timeout,
+        stall_confirm=args.stall_confirm,
     )
     print(json.dumps(result, ensure_ascii=False, indent=2))
     return {"completed": 0, "unhealthy": 1}.get(result["outcome"], 2)

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

@@ -2959,6 +2959,20 @@
       "required": ["roundCount", "gateResult", "planItems", "dissentLog"],
       "additionalProperties": false,
       "properties": {
+        "uniformVerifiers": {
+          "type": "array",
+          "description": "Verifiers whose every vote this round was one verdict. Advisory: a unanimous round is legitimate, but the gate reads as a three-way cross-check unless this sits beside it.",
+          "items": {
+            "type": "object",
+            "additionalProperties": false,
+            "required": ["worker", "verdict", "itemCount"],
+            "properties": {
+              "worker": { "type": "string", "minLength": 1 },
+              "verdict": { "type": "string", "minLength": 1 },
+              "itemCount": { "type": "integer", "minimum": 1 }
+            }
+          }
+        },
         "roundCount": { "type": "integer", "minimum": 0 },
         "gateResult": {
           "enum": [

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

@@ -1637,7 +1637,11 @@
                 "items": { "type": "string" }
               },
               "confidence": { "enum": ["low", "medium", "high"] },
-              "disproveWith": { "type": "string", "minLength": 1 }
+              "disproveWith": { "type": "string", "minLength": 1 },
+              "downstreamOf": {
+                "type": "array",
+                "items": { "type": "string", "pattern": "^EA-\\d{3,}$" }
+              }
             }
           }
         },
@@ -1699,6 +1703,28 @@
       "enum": ["open", "answered", "resolved", "obsolete"]
     },
 
+    "ClarificationScopeToken": {
+      "enum": ["in-repo", "cross-repo", "new-schema", "deferrable"]
+    },
+
+    "ClarificationOption": {
+      "type": "object",
+      "required": ["role", "answer", "rationale", "scopeImpact", "addedWork", "directionChange"],
+      "additionalProperties": false,
+      "properties": {
+        "role": { "enum": ["recommended", "alternative"] },
+        "answer": { "type": "string", "minLength": 1 },
+        "rationale": { "type": "string", "minLength": 1 },
+        "scopeImpact": {
+          "type": "array",
+          "minItems": 1,
+          "items": { "$ref": "#/$defs/ClarificationScopeToken" }
+        },
+        "addedWork": { "type": "string", "minLength": 1 },
+        "directionChange": { "type": "string", "minLength": 1 }
+      }
+    },
+
     "WorkerStatus": {
       "enum": ["completed", "error", "timeout", "not-run", "synthesis-only"]
     },
@@ -3736,6 +3762,20 @@
       "required": ["roundCount", "gateResult", "planItems", "dissentLog"],
       "additionalProperties": false,
       "properties": {
+        "uniformVerifiers": {
+          "type": "array",
+          "description": "Verifiers whose every vote this round was one verdict. Advisory: a unanimous round is legitimate, but the gate reads as a three-way cross-check unless this sits beside it.",
+          "items": {
+            "type": "object",
+            "additionalProperties": false,
+            "required": ["worker", "verdict", "itemCount"],
+            "properties": {
+              "worker": { "type": "string", "minLength": 1 },
+              "verdict": { "type": "string", "minLength": 1 },
+              "itemCount": { "type": "integer", "minimum": 1 }
+            }
+          }
+        },
         "roundCount": { "type": "integer", "minimum": 0 },
         "gateResult": {
           "enum": [
@@ -4074,6 +4114,15 @@
       "type": "object",
       "required": ["id", "ticketId", "kind", "statement", "expectedForm", "blocks", "status"],
       "additionalProperties": false,
+      "allOf": [
+        {
+          "if": {
+            "properties": { "kind": { "const": "decision" } },
+            "required": ["kind"]
+          },
+          "then": { "required": ["options"] }
+        }
+      ],
       "properties": {
         "id": { "type": "string", "pattern": "^C-\\d{3,}$" },
         "ticketId": { "$ref": "#/$defs/TicketId" },
@@ -4082,7 +4131,12 @@
         "expectedForm": { "type": "string", "minLength": 1 },
         "blocks": { "$ref": "#/$defs/ClarificationBlocks" },
         "status": { "$ref": "#/$defs/ClarificationStatus" },
-        "userInput": { "type": "string" }
+        "userInput": { "type": "string" },
+        "options": {
+          "type": "array",
+          "minItems": 2,
+          "items": { "$ref": "#/$defs/ClarificationOption" }
+        }
       }
     },
 

package/runtime/skills/okstra-inspect/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: okstra-inspect
 description: >-
-  Use this for everything that happens AFTER a single okstra task has already run — inspecting it or light bookkeeping on it, never launching new work. The tell is usually a named task id (PROD-1623, dev-9184), often dropped without the word "okstra." Reach for it when the user wants one task's: status, current/next phase, blockers, or approval gate; its final report — where it is or whether it passed (verdict / pass); its elapsed time or context/read cost; its run history, re-run, or resume; to mark it done / in-progress / blocked / todo; or a failed run's error logs gathered into a report (error report). Also bundles cross-project okstra errors into an anonymized feedback zip (error feedback). Use it even for a bare "mark it done" or "where's the report." NOT for starting a run (okstra-run), rollups/schedules (okstra-rollup / okstra-schedule-gen), a brief (okstra-brief-gen), setup (okstra-setup), or cross-project management (okstra-manager).
+  Use this for everything that happens AFTER a single okstra task has already run — inspecting it or light bookkeeping on it, never launching new work. The tell is usually a named task id (PROD-1623, dev-9184), often dropped without the word "okstra." Reach for it when the user wants one task's: status, current/next phase, blockers, or approval gate; its final report — where it is or whether it passed (verdict / pass); its elapsed time or context/read cost; its run history, re-run, or resume; to mark it done / in-progress / blocked / todo; or a failed run's error logs gathered into a report (error report). Also turns cross-project okstra errors into an anonymized zip (error feedback) or GitHub issues (file okstra issues), and audits run health across tasks (run audit). NOT for starting a run (okstra-run), rollups/schedules (okstra-rollup / okstra-schedule-gen), a brief (okstra-brief-gen), setup (okstra-setup), or cross-project management (okstra-manager).
 ---
 
 # OKSTRA Inspect
@@ -18,6 +18,8 @@ Single read-side entry point for okstra runtime inspection plus the one status m
 | `cost` | `facets/cost.md` | Estimate file/read context cost for a task bundle. |
 | `errors` | `facets/errors.md` | Aggregate okstra-run error logs for a task into a timestamped markdown report; print a summary. |
 | `error-zip` | `facets/error-zip.md` | Collect cross-project okstra error logs into an anonymized zip (report + raw) and summarize clusters. |
+| `error-issue` | `facets/error-issue.md` | Turn cross-project okstra anomalies into GitHub issue candidates; file the approved ones after explicit user approval. |
+| `run-audit` | `facets/run-audit.md` | Check every run's artifacts against progress invariants; report what went wrong without an error ever being logged. |
 | `recap` | `facets/recap.md` | Summarize a task's run-to-run phase transitions, then answer free-form questions over its `.okstra` artifacts. Appends each summary/Q&A to `recap/recap-log.jsonl`, and writes agent-authored notes to `notes/` for feeding into later runs. |
 
 ## Step 0: Preflight (shared)

package/runtime/skills/okstra-inspect/facets/error-issue.md

@@ -0,0 +1,77 @@
+# okstra-inspect facet — error-issue
+
+Loaded lazily by the dispatch table in `SKILL.md` (core). Shared rules — Step 0 preflight, the standard task-key resolution rule (0/1/N), the no-task fallback, and Output Rules — live in the core file and still apply here.
+
+## error-issue
+
+Trigger phrases: "okstra error-issue", "issue candidates", "file okstra issues", "report okstra defects".
+
+Turn okstra run anomalies into GitHub issue candidates, then file the approved ones. Read-only over every target's `.okstra/`. Apart from the plan file you edit between the two commands, the only write is the GitHub issue — and that only after the user approves.
+
+**Never run `submit` without an explicit user approval in this session.** `plan` is free to run unattended; `submit` is not.
+
+### error-issue.1 — Build the plan
+
+```bash
+okstra error-issue plan --out ~/.okstra/error-issue-plan.json
+```
+
+Parse the stdout JSON: `candidateCount`, `belowGate`, `notOkstraDefect`, `conflicted`, `unreachableRuns`.
+
+`candidateCount` includes candidates whose action is already `skip`, so it is not the number of issues that will be filed. Report the filed count from the create/comment rows of the board below.
+
+### error-issue.2 — Review each candidate's classification
+
+Read the plan file. For each candidate, verify the recorded `classification` against its `signals` list. The classification was computed by `issue_signals.classify`; your job is to confirm it reads correctly against the raw evidence, not to invent a new one.
+
+If a candidate's signals do not support its classification, drop it from the plan file rather than arguing with it in prose. If deciding requires reading the raw `stderrExcerpt`, add an evidence entry and quote the line — an evidence entry always carries all three of `signal`, `value`, `source`, so write `{"signal": "<the signal it backs>", "value": "<the quoted line>", "source": "message excerpt"}`. `submit` rejects an entry missing any of the three; a two-key entry is not a lighter form of evidence, it is an unreadable one.
+
+### error-issue.3 — Present the approval board (Korean)
+
+First state the destination on its own line — `plan.json` 의 `repo` 값을 그대로 읽어 `등록 대상: <repo>` 로 적는다. 이 값은 `~/.okstra/error-issue.json` 이 덮어쓸 수 있으므로 okstra 레포라고 단정하지 않는다. CLI 가 `repo` 없는 plan 을 거부하는 이유가 바로 이것 — 목적지는 승인 화면에 반드시 있어야 할 값이다.
+
+Then show two tables, never merged into one.
+
+**등록 예정** — candidates whose action is `create` or `comment`. `title` 열은 실제로 올라갈 제목 그대로 싣는다. 그것이 없으면 "승인 화면에서 본 것과 올라가는 것이 같다"가 성립하지 않는다:
+
+| # | action | title | fingerprint | errorType / phase | 발생 | 지지 신호(`evidence`) | 기존 이슈 |
+|---|---|---|---|---|---:|---|---|
+
+**보류** — candidates whose action is already `skip`. They are NOT filed; they are shown so the human sees what was set aside. `skip` has two distinct origins and the row must say which:
+
+- **반대 신호** — `conflictingSignals` is non-empty. `classify` called it an okstra defect while another signal pointed elsewhere.
+- **이미 보고됨** — `conflictingSignals` is empty and `existingIssue` is set. An open issue already covers the last occurrence, so there is nothing new to say.
+
+| # | fingerprint | errorType / phase | 발생 | 보류 사유 | 지지 신호 | 반대 신호 / 기존 이슈 |
+|---|---|---|---:|---|---|---|
+
+**본문** — then, for every `등록 예정` row, print that candidate's `body` **whole and verbatim** in a fenced block, one block per row, labelled with the same `#`. Never elide a section. The table summarizes; the body is what actually gets posted, and "승인 화면에서 본 것과 올라가는 것이 같다" is this facet's whole claim — a title plus a signal list does not carry it.
+
+Bodies are bounded by construction: every line is derived (counts, signal values, invariant names) except the one representative message, which shares its source with the `title` in the same row. The raw error records are deliberately NOT in the body — their free text carries the reporting project's ticket ids and source filenames, and no shape rule can separate those from okstra's own vocabulary. They stay in the candidate's `records` in `plan.json` and in the `okstra error-zip` archive. If you need to vet them, read `plan.json` locally; do not paste them into the body.
+
+Then ask via `AskUserQuestion` (options: 전부 등록 / 일부만 선택 / 등록 안 함). Deselected candidates are removed from the plan file before submit.
+
+A held candidate is promoted only when the user explicitly says so, and the action you set depends on `existingIssue`:
+
+- `existingIssue` is null → set `action` to `create`.
+- `existingIssue` is set → set `action` to `comment`. **Never `create` over an existing issue** — that files a duplicate carrying the same `okstra-fingerprint` marker, and from then on `find_existing_issue` matches whichever of the two the list returns first, so every later run reports against an arbitrary one.
+
+Say which you set and why.
+
+Surface `unreachableRuns > 0` — no silent omission.
+
+### error-issue.4 — Submit
+
+Only after an explicit approval:
+
+```bash
+okstra error-issue submit --plan ~/.okstra/error-issue-plan.json
+```
+
+Report `created` / `commented` / `skipped` / `rejected` / `failed`. If `rejected > 0`, print each rejection's `reasons` verbatim — a rejection means the outbound text or the evidence failed the final gate, and it is never something to work around.
+
+If `failed > 0`, print each failure's `error` and **do not re-run `submit` on the same plan file**. A failure is a candidate that crashed or whose `gh` call errored; the candidates before it were already filed, and their `action` in the plan file still says `create`. Re-run `error-issue plan` instead — the fingerprint lookup turns the already-filed ones into `comment`/`skip`, which is the only thing that keeps a retry from filing duplicates.
+
+### error-issue.5 — Next step
+
+End with: "이 이슈를 실제로 고치려면 `/okstra-brief-gen` 에 이슈 URL 을 주고, okstra 레포에서 `okstra-run --task-type error-analysis` 로 진행하세요."

package/runtime/skills/okstra-inspect/facets/run-audit.md

@@ -0,0 +1,34 @@
+# okstra-inspect facet — run-audit
+
+Loaded lazily by the dispatch table in `SKILL.md` (core). Shared rules — Step 0 preflight, the standard task-key resolution rule (0/1/N), the no-task fallback, and Output Rules — live in the core file and still apply here.
+
+## run-audit
+
+Trigger phrases: "okstra run-audit", "run audit", "진행 점검", "태스크들 제대로 가고 있나", "silent failures".
+
+Check every run's artifacts against progress invariants. This catches what the error log cannot: a run that never logged a failure but still ended wrong. Read-only.
+
+### run-audit.1 — Run the audit
+
+```bash
+okstra run-audit
+```
+
+### run-audit.2 — Report (Korean)
+
+Group the `violations` array by `invariant` and report one section each:
+
+| invariant | 위반 태스크 수 | 프로젝트 수 |
+|---|---:|---|
+
+Under each, list the affected `taskKey` values with their `detail` and `source`. Always cite `source` — the reader must be able to open the file the verdict came from.
+
+### run-audit.3 — Split the two outcomes
+
+State plainly which violations are this task's own state versus a repeated okstra defect:
+
+- an invariant broken in **one** task → that task's own state; tell the user what to do about that task
+- an invariant broken across **two or more** tasks → an okstra defect; point at `/okstra-inspect error-issue` to file it
+- `approval-not-forgotten` is the exception and never routes to `error-issue` no matter how far it spreads. It means a human has not approved yet, not that okstra did something wrong — `error_issue.NEVER_AN_ISSUE` drops it, so pointing the user at `error-issue` for it promises a filing that will never happen. Report it as a to-do list of tasks awaiting the user's approval instead.
+
+Never file an issue from this facet. Filing is `error-issue`'s job and it has its own approval gate.

package/runtime/skills/okstra-run/SKILL.md

@@ -174,7 +174,9 @@ When `next.kind == "done"`, fetch the public wizard outcome:
 okstra wizard outcome --state-file /var/folders/.../okstra-wizard.AbCd.json
 ```
 
-Output: `{ok: true, outcome: {renderArgs: {...}, persistActions: [...], confirmationText: "..."}}`.
+Output: `{ok: true, outcome: {renderArgs: {...}, orchestration: {chainStages: "..."}, persistActions: [...], confirmationText: "..."}}`.
+
+`renderArgs` holds only flags `okstra render-bundle` accepts, which is what makes the pass-everything rule below safe. `orchestration` holds signals this skill acts on itself — never pass its entries to `render-bundle`.
 
 Run every `outcome.persistActions[]` entry BEFORE `render-bundle`. The only supported action is:
 
@@ -216,6 +218,19 @@ The python function underneath is mutex-protected (`~/.okstra/.locks/<task-key>.
 
 You can delete the literal state-file path after this point — its job is done. Invoke `rm` with the literal path (e.g. `rm /var/folders/.../okstra-wizard.AbCd.json`), not a shell variable.
 
+<!-- BEGIN FRAGMENT: host-orchestration-implementation -->
+## Host orchestration rules — implementation
+
+These are the rules the **host orchestrator** follows around an `implementation`
+run: when to offer a conformance waiver, what a concurrent-run marker means, how
+to recover a stale stage SHA, and what the chaining queue does when the next
+stage is not ready. They are not lead phase rules — the lead's rules live in
+`prompts/profiles/`.
+
+This file is the single source. Two surfaces are generated from it: the
+`okstra-run` skill body (marker block, synced by `tools/sync-skill-fragments.mjs`)
+and each run's `instruction-set/host-orchestration-rules.md`. Edit here.
+
 ### Step 5.1 (implementation only): blocking local conformance waiver offer
 
 `render-bundle` accepts an optional `--qa-waiver "<stageKey>:<reason>"` flag (implementation only). It records a **user-acknowledged** waiver into the task-level conformance manifest entry (`entry.waiver`), letting the run proceed when an `io`-only Tier 3 conformance script genuinely cannot run. The waiver records the user's reason **verbatim**.
@@ -256,6 +271,13 @@ If `render-bundle` fails with a `PrepareError` containing `Recorded stage SHAs n
 
 If the anchor (`implementation_base_commit`) is reported unresolvable, run the same command's `--reset-anchor <ref>` after user confirmation. Correcting a confirm item without the picker is forbidden — the runtime also rejects a confirm correction without `--use-ref`.
 
+### Next stage not yet ready — normal termination (not an exception gate)
+Because of the dependency closure, the chain queue **may include a stage that another implementation run has occupied as started/reserved.** That stage's `render-bundle` is rejected with `--stage N already in progress or reserved by another run` (StageTargetError). This is **not** an exception gate needing human judgment but a "next stage not yet ready" situation. On this rejection, **terminate the chain normally** and report the remaining queue to the user (e.g. `remaining queue: stage 4, 5 — resume with okstra-run after occupancy is released`). This is a different branch from the exception gate below (data corruption·concurrent-occupancy conflict confirmation).
+
+### Exception gate during chaining
+If `render-bundle` raises Step 5's concurrent-run conflict detection (concurrent-run branch) or git stale-SHA reconciliation (git-reconcile branch), **stop the chain at that stage** and present the gate to the user exactly as Step 5 prescribes. Once the user resolves the gate, resume the chain in place (continue with the remaining queue). Data corruption·concurrent-occupancy conflicts are confirmed by a human — this is the safety boundary of unattended chaining. (Unlike the "not ready" rejection above, these two branches do not discard the queue; they wait for user resolution.)
+<!-- END FRAGMENT: host-orchestration-implementation -->
+
 ## Step 6: Take over as Okstra lead
 
 Read `<INSTRUCTION_SET_PATH>/lead-execution-prompt.md` verbatim and take over as `Okstra lead` in the current host-native session. The prompt selects exactly one runtime adapter and points to compact intake artifacts first (`active-run-context`, `analysis-profile.md`, and `analysis-packet.md`); full source files such as `analysis-material.md`, `reference-expectations.md`, and `final-report-template.md` are lazy/fallback inputs. Follow the rendered prompt order, do not preempt it.
@@ -265,11 +287,11 @@ Then proceed through the phases exactly as the lead prompt directs (Phase 1 cont
 Inform the user with one short line:
 > Took over as Okstra lead (`<host-runtime>`) for `<taskKey>` (`<task-type>`). Run dir: `<RUN_DIR_RELATIVE_PATH>`. Beginning Phase 1 (context loading).
 
-## Step 7: implementation unattended chaining (chain-stages)
+## Step 7: implementation unattended chaining (orchestration.chainStages)
 
-When `task-type == implementation` and Step 5 render-args' `chain-stages` CSV has 2+ elements, the current session acts as the orchestrator and runs the stages in dependency order as an unattended chain (a single element behaves like the existing single run, so skip this section — the end of Step 6 is the end of the run).
+When `task-type == implementation` and Step 5 outcome's `orchestration.chainStages` CSV has 2+ elements, the current session acts as the orchestrator and runs the stages in dependency order as an unattended chain (a single element behaves like the existing single run, so skip this section — the end of Step 6 is the end of the run).
 
-Queue = the topologically-sorted stage list from splitting `chain-stages` on `,` (the order Task 5 emitted by topologically sorting the dependency closure). For each stage `N` in the queue, in order:
+Queue = the topologically-sorted stage list from splitting `orchestration.chainStages` on `,` (the order Task 5 emitted by topologically sorting the dependency closure). For each stage `N` in the queue, in order:
 
 1. Call Step 5's `render-bundle` with the same arguments but `--stage N` (the base commit is auto-computed by prepare from the predecessor's done `head_commit`, so do not pass it by hand). Step 5's blocking local conformance waiver offer·concurrent-run detection·git-reconcile gates apply identically to each stage's `render-bundle`.
 2. As in Step 6, become the host-native Okstra lead and run that stage's Phase 1–7 inline. Phase 6's lead post-stage persistence appends that stage's `status:"done"` row to `runs/<plan-task-key>/consumers.jsonl` (per the implementation profile directive).
@@ -278,11 +300,7 @@ Queue = the topologically-sorted stage list from splitting `chain-stages` on `,`
 
 Once the whole queue is consumed, end the chain and report completion to the user.
 
-### Next stage not yet ready — normal termination (not an exception gate)
-Because of the dependency closure, the chain queue **may include a stage that another implementation run has occupied as started/reserved.** That stage's `render-bundle` is rejected with `--stage N already in progress or reserved by another run` (StageTargetError). This is **not** an exception gate needing human judgment but a "next stage not yet ready" situation. On this rejection, **terminate the chain normally** and report the remaining queue to the user (e.g. `remaining queue: stage 4, 5 — resume with okstra-run after occupancy is released`). This is a different branch from the exception gate below (data corruption·concurrent-occupancy conflict confirmation).
-
-### Exception gate during chaining
-If `render-bundle` raises Step 5's concurrent-run conflict detection (concurrent-run branch) or git stale-SHA reconciliation (git-reconcile branch), **stop the chain at that stage** and present the gate to the user exactly as Step 5 prescribes. Once the user resolves the gate, resume the chain in place (continue with the remaining queue). Data corruption·concurrent-occupancy conflicts are confirmed by a human — this is the safety boundary of unattended chaining. (Unlike the "not ready" rejection above, these two branches do not discard the queue; they wait for user resolution.)
+The two branches that end or pause the queue — "Next stage not yet ready" and "Exception gate during chaining" — are in the host orchestration rules block above.
 
 ## Persisting the PR template scope (release-handoff)
 
@@ -308,4 +326,4 @@ Do not read the wizard state file directly. `okstra wizard outcome` exposes any
 
 - Echo each captured answer (`result.echo`) on one short line so the user sees what was registered.
 - Never invent identity; if a `text` prompt returns an empty answer where the wizard rejects it, the user must retry.
-- After Step 6, begin the lead workflow without re-summarizing the skill itself. For a single run, the end of Step 6 is the end of the run — but in an unattended chain where `chain-stages` has 2+ elements, repeat Step 6 per stage until Step 7's queue is empty (or it stops at a "not ready" / exception gate), then finish.
+- After Step 6, begin the lead workflow without re-summarizing the skill itself. For a single run, the end of Step 6 is the end of the run — but in an unattended chain where `orchestration.chainStages` has 2+ elements, repeat Step 6 per stage until Step 7's queue is empty (or it stops at a "not ready" / exception gate), then finish.

package/runtime/skills/okstra-user-response/SKILL.md

@@ -1,21 +1,21 @@
 ---
 name: okstra-user-response
 description: >-
-  Use this to answer an okstra task's open clarification questions in-session, without hand-editing any file. The tell is a request to respond to an okstra run's clarification items or its approval gate — "answer okstra", "I'll answer the questions", "clarification response", "user response", "approve and move on". This skill lists tasks whose latest report still has open clarification blockers, then walks the open C-ids one at a time — each rewritten as a self-contained question with background, three concrete answers (recommendation first) plus "Enter directly" — echoes the collected answers back for an explicit "confirmed" acknowledgement, optionally records approval, and writes the `user-responses/` sidecar via `okstra user-response write`. NOT for starting a run (okstra-run), inspecting a finished task (okstra-inspect), or generating a brief (okstra-brief-gen). The skill never picks an answer — it builds the option board and transcribes what the user decides.
+  Use this to answer an okstra task's open clarification questions in-session, without hand-editing any file. The tell is a request to respond to an okstra run's clarification items or its approval gate — "answer okstra", "I'll answer the questions", "clarification response", "user response", "approve and move on". This skill lists tasks whose latest report still has open clarification blockers, then walks the open C-ids one at a time — each rewritten as a self-contained question with background, its options with their impact plus "Enter directly" — echoes the collected answers back for an explicit "confirmed" acknowledgement, optionally records approval, and writes the `user-responses/` sidecar via `okstra user-response write`. NOT for starting a run (okstra-run), inspecting a finished task (okstra-inspect), or generating a brief (okstra-brief-gen). The skill never picks an answer — it builds the option board and transcribes what the user decides.
 ---
 
 # OKSTRA User Response
 
 Single entry point for answering the clarification questions an okstra run left behind (the open `C-*` rows under the final report's `## 1. Clarification Items`) **in-session**, and recording those answers as a `runs/<type>/user-responses/` sidecar. The next `/okstra-run` auto-attaches this sidecar via `--clarification-response`.
 
-**Core principle — the skill never picks an answer for the user.** It builds the option board — background, a self-contained question, three concrete answers, `Enter directly` — and the user alone picks from it; every `value` is what the user chose or typed. It never calls `write` until the user has explicitly confirmed.
+**Core principle — the skill never picks an answer for the user.** It builds the option board — background, a self-contained question, the report's options with their impact, `Enter directly` — and the user alone picks from it; every `value` is what the user chose or typed. It never calls `write` until the user has explicitly confirmed.
 
 **Second principle — one question at a time.** Never batch two clarification items into one question, and never dump the whole open list at the user. Ask item 1, transcribe the answer, then ask item 2.
 
 | Sub-command | What it does |
 |---|---|
 | `list` | List tasks that still have approval-open clarification, newest report first. |
-| `show` | Expand one report's open `C-*` rows (statement + recommended + alternatives + contextRefs). |
+| `show` | Expand one report's open `C-*` rows (statement + options + contextRefs). |
 | `write` | Record the collected answers (+ optional approval) as a `user-responses/` sidecar. |
 
 ## Step 0: Preflight (shared)
@@ -71,7 +71,11 @@ Carry the chosen entry's `reportPath` and `taskKey` forward.
 okstra user-response show --report <reportPath>
 ```
 
-Returns `{reportPath, rows: [{id, kind, blocks, status, statement, recommended, alternatives, contextRefs, resolvedRefs}]}`. `resolvedRefs` is `[{ref, definition}]` — the CLI has already looked up what each internal token (`RB-002`, `FU-001`, `§4.7`, …) means in the report body; `definition` is `null` only when the report text alone could not resolve it (e.g. a `path:line` pointer).
+Returns `{reportPath, rows: [{id, kind, blocks, status, statement, expectedForm, options, contextRefs, resolvedRefs}]}`.
+
+Each entry of `options[]` is `{role, answer, rationale, scopeImpact, addedWork, directionChange}`. `role` is `recommended` for exactly one entry and `alternative` for the rest; `scopeImpact` is a token list drawn from `in-repo` / `cross-repo` / `new-schema` / `deferrable`; `addedWork` and `directionChange` are one sentence each. A schema-v1 report has nowhere to record impact, so those three arrive empty — the CLI reconstructs only the answers from the report's `Expected form` cell.
+
+`resolvedRefs` is `[{ref, definition}]` — the CLI has already looked up what each internal token (`RB-002`, `FU-001`, `§4.7`, …) means in the report body; `definition` is `null` only when the report text alone could not resolve it (e.g. a `path:line` pointer).
 
 This call is a **data fetch, not a presentation step**. Do not print `rows` at the user, and do not paste a raw `statement` as a question — a `statement` like `Rewrite RB-002 rollback (see §4.7)` is meaningless on its own, which is the whole reason this skill exists. Announce only the count and the plan:
 
@@ -103,23 +107,19 @@ Close the background with the raw source on one line, so the mapping back to the
 
 > Source: `C-014` — "<raw statement>"
 
-### 3b. The picker — three answers plus `Enter directly`
+### 3b. The picker — the report's options plus `Enter directly`
 
-One `AskUserQuestion` (single-select), with exactly four options in this order:
+One `AskUserQuestion` (single-select). Fill the slots from `options[]` in array order — the `role: recommended` entry first with its label suffixed `(Recommended)`, then the `alternative` entries — and always close with `Enter directly` as the last option. Never mark anything but the `recommended` entry as recommended.
 
-1. **The recommendation** — the answer from `recommended` restated in plain language, label suffixed `(Recommended)`; its description carries the rationale (the part of the `recommended` cell after `—`).
-2. **Alternative** — `alternatives[0]`.
-3. **Alternative** — `alternatives[1]`.
-4. **`Enter directly`** — always last, always present.
+Each `label` is that option's `answer`, kept to the answer itself (1–5 words). Each `description` carries the rationale followed by the three impact axes, in this fixed order:
 
-Slots 2–3 fill from `alternatives[]` first. When `alternatives[]` is short, fill each remaining slot with the first of these that applies:
+> `<rationale>` — Scope: `<scopeImpact, comma-joined>` · Added work: `<addedWork>` · Direction: `<directionChange>`
 
-- **a concrete candidate the report itself names** — another option row, an approach §2 rejected, a value already in use elsewhere. Its description must open with `Not an okstra proposal — from <where>` and cite that source.
-- **`Reframe this question`** — the item is held rather than answered, and the next run re-asks it.
+The three axes answer three different questions: how far the choice reaches, what new work it creates, and what it overturns. Never fold them into one phrase — whichever is easiest to write ends up standing in for the other two, and the user weighs a scope change as though it were free. That is the failure this board exists to prevent.
 
-That last entry is what guarantees the picker always reaches three answers plus `Enter directly`. Never pad a slot with an option no source supports, and never mark anything but `recommended` as recommended.
+When an axis is empty — a schema-v1 report has nowhere to record impact — write `not stated in the report` for that axis. Do not infer it, and do not read the code to reconstruct it. A guessed side effect is worse than a stated gap, because the user cannot tell the two apart.
 
-Keep each `label` to the answer itself (1–5 words); the description carries the consequence.
+When `options[]` carries more than three entries, keep the recommended one plus the two alternatives whose `scopeImpact` differs most from it, and say in the background text how many you left out. When it carries exactly two, the picker has three options in total — do not pad it with an invented third.
 
 ### 3c. Transcribe the decision, then move on
 
@@ -127,13 +127,13 @@ Record one entry — `{id, kind, value, rationale?, disposition}`, `kind` copied
 
 | The user picks | `value` | `disposition` |
 |---|---|---|
-| Option 1–3 | that option's full answer text, not its short label | `answer` |
+| One of the `options[]` entries | that option's `answer` text, not its short label | `answer` |
 | `Enter directly` → their own answer | the user's utterance verbatim (rationale into `rationale`) | `answer` |
-| `Reframe this question`, or free text asking for it to be re-asked | what the user wants re-asked, verbatim (empty → the raw statement) | `reframe` |
+| Free text asking for the item to be re-asked | what the user wants re-asked, verbatim (empty → the raw statement) | `reframe` |
 
 A reframe is not an answer, so it does not satisfy the approval gate.
 
-If the user replies with a question instead of an answer ("what does this mean?"), record nothing: **Read** the `§`/`path:line` from `contextRefs[]`, explain it in plain language, and re-ask the same item with the same four options. Explain only — **do not resolve it for them**; the decision goes back to the user.
+If the user replies with a question instead of an answer ("what does this mean?"), record nothing: **Read** the `§`/`path:line` from `contextRefs[]`, explain it in plain language, and re-ask the same item with the same options. Explain only — **do not resolve it for them**; the decision goes back to the user.
 
 Echo one line per finished item (`[2/5] C-014 → answer: 60s`), then ask the next one. Do not summarize the whole set until Step 4.
 

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

@@ -406,6 +406,10 @@ Carried-forward plan items retain their prior verdicts verbatim; each such item
 {% endif %}
 {% if implementationPlanning.planBodyVerification.gateBlockedBy %}- **Blocked by**: {% for cause in implementationPlanning.planBodyVerification.gateBlockedBy %}`{{ cause }}`{% if not loop.last %}, {% endif %}{% endfor %}
 {% endif %}
+{% if implementationPlanning.planBodyVerification.uniformVerifiers %}- **{{ t("implementationPlanning.planBodyUniformVerifierLabel") }}**: {% for u in implementationPlanning.planBodyVerification.uniformVerifiers %}`{{ u.worker }}` → `{{ u.verdict }}` ({{ u.itemCount }}){% if not loop.last %}, {% endif %}{% endfor %}
+
+> {{ t("implementationPlanning.planBodyUniformVerifierLegend") }}
+{% endif %}
 > {{ t("implementationPlanning.planBodyGateLegend") }}
 >
 > {{ t("implementationPlanning.planBodyBlockedByLegend") }}

package/runtime/templates/reports/html/assets/base.css

@@ -38,6 +38,7 @@ svg { max-width: 100%; min-width: 520px; height: auto; }
 svg .edge { stroke: GrayText; stroke-width: 2; }
 svg .edge-arrow-head { fill: GrayText; }
 svg .node rect { fill: color-mix(in srgb, Highlight 14%, Canvas); stroke: Highlight; }
+svg .node-leading rect { fill: color-mix(in srgb, Highlight 32%, Canvas); stroke-width: 2; }
 svg .node text { fill: CanvasText; font-size: 13px; }
 table { width: 100%; border-collapse: collapse; margin-top: 1rem; font-size: .9rem; }
 /* Korean takes a line break between any two syllables, so an auto-layout
@@ -79,7 +80,19 @@ th, td { text-align: left; vertical-align: top; border-bottom: 1px solid color-m
 .ledger-source { font-size: .9rem; color: GrayText; }
 .ledger-source > span:first-child::after { content: ":"; }
 .status { display: inline-block; white-space: nowrap; border-radius: 999px; padding: .1rem .5rem; background: color-mix(in srgb, GrayText 15%, Canvas); }
-.status-gap, .status-risk { background: color-mix(in srgb, #d94b4b 18%, Canvas); }
+.status-gap, .status-risk, .status-error, .status-timeout { background: color-mix(in srgb, #d94b4b 18%, Canvas); }
+/* Figures are read by comparing them down the column, which only works when
+   the digits line up: tabular-nums stops a 1 from being narrower than a 7, and
+   the right edge is the one they share. */
+.run-usage-lede { max-width: 78ch; }
+.figure { text-align: right; font-variant-numeric: tabular-nums; white-space: nowrap; }
+/* Four nowrap number columns need almost none of the width, and the default
+   even split spent it on them while the agent names wrapped mid-word. */
+[data-report-section="run-usage"] .row-key { width: 45%; }
+.cli-extra { display: block; color: GrayText; font-size: .85em; }
+tfoot th { font-weight: 600; }
+tfoot tr:first-child > * { border-top: 2px solid color-mix(in srgb, CanvasText 30%, transparent); }
+tfoot .grand-total > * { font-weight: 700; }
 .human-report-footer { width: min(1120px, calc(100% - 2rem)); margin: 0 auto 2rem; display: flex; flex-wrap: wrap; gap: .6rem; }
 .human-report-footer pre { flex-basis: 100%; white-space: pre-wrap; max-height: 14em; overflow: auto; }
 fieldset, label { display: block; margin: .7rem 0; }