okstra 0.214.1 → 0.216.0

package/runtime/prompts/lead/okstra-lead-contract.md

@@ -58,9 +58,43 @@ Every `okstra` command the lead documents cite, grouped by phase, each spelled w
 | `okstra incremental-scope --prev-data <path>` | Decide re-verify vs carry-forward stages on a clarification re-run | launch prompt "Incremental re-verification" |
 | `okstra incremental-carry --prev-data <path> --prev-seq <seq> --cur-narrative <path>` | Merge carried-forward plan-item verdicts after `plan-items seed` | launch prompt "Incremental re-verification" |
 | `okstra stage-map <task-key>` | Read the prior Stage Map and done stages before re-planning | host orchestration rules (implementation-planning) |
-| `okstra stage-close <task-key> --stage <N> --from-commit <sha>` | Close a stage whose work already landed outside okstra | host orchestration rules (implementation-planning) |
+| `okstra stage-close <task-key> --stage <N> --from-commit <sha> [--supersede-failed <reason>]` | Close a stage whose work already landed outside okstra, or a `failed` stage whose failure no longer applies |
+| `okstra stage-reopen <task-key> --stage <N> --reason <why> [--evidence <report>]` | Reopen a `done` stage for a fix run, e.g. after a `blocked` final-verification of that stage | host orchestration rules (implementation-planning) |
 | `okstra git-reconcile --plan-run-root <dir> --project-id <id> --task-group <group> --task-id <id> --work-category <category>` | Detect (`--check --text`) or record (`--apply --stage <N> --use-ref <ref>`) stage SHAs made stale by git history outside okstra | host orchestration rules (implementation) |
 
+### discussion — the discussion record
+
+| Command | Use when | Procedure |
+|---|---|---|
+| `okstra discussion confirm-subject <task-key> --subject <what> --question <to-settle> --run-manifest <path>` | The user confirmed the subject and the question to settle | discussion `profile.md` "Facilitator" |
+| `okstra discussion ask <task-key> --author <leader-or-worker-id> --text <question> --run-manifest <path>` | Register a question for the user before putting it to the user | discussion `profile.md` "Facilitator" |
+| `okstra discussion address <task-key> --to <worker-id> --text <question> --run-manifest <path>` | The user asked one participant directly | discussion `profile.md` "Facilitator" |
+| `okstra discussion answer <task-key> --question <Q-NNNN> --author <user-or-worker-id> --text <answer> --run-manifest <path>` | Record the addressee's answer; resending it returns the stored record | discussion `profile.md` "Facilitator" |
+| `okstra discussion decide <task-key> --text <decision> --run-manifest <path>` | Record a user decision; add `--question <Q-NNNN>` when it settles a question | discussion `profile.md` "Facilitator" |
+| `okstra discussion add-material <task-key> --kind <evidence-or-alternative> --author <user-leader-or-worker-id> --text <what> --run-manifest <path>` | New evidence or a new alternative arrived; it becomes an input reference of the next research cycle | discussion `profile.md` "Facilitator" |
+| `okstra discussion draft <task-key>` | Read the record every participant gets as its next input | discussion `profile.md` "Facilitator" |
+| `okstra discussion status <task-key>` | On entry and on resume: the phase, the one question to put to the user next, unrecovered failures and remaining disagreements | discussion `profile.md` "Facilitator" |
+| `okstra discussion cycle-open <task-key> --run-manifest <path>` | Before dispatching research: `dispatch` names the research instruction for every analyser; any other action says why nothing is dispatched | discussion `profile.md` "Research cycle" |
+| `okstra discussion settle <task-key> --run-manifest <path>` | After the research batch settled: record each analyser's result and each failure left after the dispatcher's retry loop | discussion `profile.md` "Research cycle" |
+| `okstra discussion recover <task-key> --failure <X-NNNN> --choice <retry-replace-or-reduce> --run-manifest <path>` | Record the user's choice for one failure; never choose for the user | discussion `profile.md` "Failures" |
+| `okstra discussion cycle-close <task-key> --run-manifest <path>` | After `okstra convergence finalize`: import the claims with their authors and verdicts and end the verification cycle | discussion `profile.md` "Research cycle" |
+| `okstra discussion question-prompt <task-key> --question <Q-NNNN> --run-manifest <path>` | The user addressed one participant: write that question's instruction and materialize batch | discussion `profile.md` "Direct questions" |
+| `okstra discussion collect-answer <task-key> --question <Q-NNNN> --run-manifest <path>` | After the direct-question dispatch settled: record the whole result as the answer, or the failure | discussion `profile.md` "Direct questions" |
+| `okstra discussion add-requirement <task-key> --text <requirement> --author <user-leader-or-worker-id> --run-manifest <path>` | A requirement of the current draft is settled; add `--applies-to <follow-up-label>` when only one follow-up needs it | discussion `profile.md` "Completion" |
+| `okstra discussion add-scope <task-key> --kind <in-scope-or-excluded> --text <what> --author <user-leader-or-worker-id> --run-manifest <path>` | An in-scope or excluded item of the current draft is settled; record an explicit `none` when nothing is excluded | discussion `profile.md` "Completion" |
+| `okstra discussion withdraw <task-key> --item <N-NNNN-or-B-NNNN> --reason <why> --run-manifest <path>` | The user drops a requirement or scope item from the current draft, including one carried from the reopened revision; to replace an item, withdraw it and add the new one | discussion `profile.md` "Completion" |
+| `okstra discussion confirm-completion <task-key> --draft-version <sha256-digest> --direction <direction> --risk <accepted-risks> --run-manifest <path>` | The user saw the draft at that version, chose the direction and confirmed the remaining disagreements and risks: publish the immutable revision | discussion `profile.md` "Completion" |
+| `okstra discussion reopen <task-key> --revision <revision-id> --reason <why> --run-manifest <path>` | The user wants to change a completed discussion: open a new draft on top of the latest revision | discussion `profile.md` "Completion" |
+| `okstra discussion revisions <task-key>` | List the published revisions with their content digests | discussion `profile.md` "Completion" |
+| `okstra discussion revision-show <task-key> --revision <revision-id>` | Print one published revision byte-for-byte | discussion `profile.md` "Completion" |
+| `okstra discussion record <task-key>` | The user wants the whole discussion record, every research result in full | discussion `profile.md` "Completion" |
+| `okstra discussion memory-sync <task-key>` | `status` lists a revision under `memoryRegistration` that the Memory Book does not hold yet: retry its registration with the same source key; after a secret refusal, add `--revision <revision-id> --summary-file <path>` only with the summary the user edited | discussion `profile.md` "Completion" |
+| `okstra discussion follow-up-brief <task-key> --revision <revision-id> --follow-up <label> --target-task <follow-up-task-key> --end-state <N-NNNN>=<EB-PB-or-EO>` | After a revision is published, the user asks for one follow-up task's brief; repeat `--end-state` per requirement and add `:<how to observe it>` when the revision gives no observation method; add `--target-project-root <dir>` for a follow-up in another project | discussion `profile.md` "Follow-ups" |
+| `okstra discussion links <task-key>` | Show the linked follow-ups and which of them need the user's impact review | discussion `profile.md` "Follow-ups" |
+| `okstra discussion impact <task-key> --from <revision-id> --to <revision-id>` | Show what changed between two revisions; add `--follow-up <label>` for one follow-up | discussion `profile.md` "Follow-ups" |
+| `okstra discussion apply <task-key> --revision <latest-revision-id> --target-task <follow-up-task-key> --choice <adopt-or-keep>` | Record the user's choice for one follow-up; never choose for the user | discussion `profile.md` "Follow-ups" |
+| `okstra discussion complete-amendment <task-key> --revision <revision-id> --target-task <follow-up-task-key>` | `links` shows a follow-up `amendment-pending` whose `next` names this command: the user approved the amended plan, so move the follow-up's brief to the revision; a refusal names what is still missing | discussion `profile.md` "Follow-ups" |
+
 ### Any phase — progress, activity, errors, approval
 
 | Command | Use when | Procedure |
@@ -108,10 +142,11 @@ Every `okstra` command the lead documents cite, grouped by phase, each spelled w
 | `okstra convergence seed --groups <path> --work-state <path> --final-state <path> --migration-dir <dir>` | Create, resume, or recover the working state | `convergence` "Round 0" |
 | `okstra convergence plan-round --work-state <path> --plan <path>` | Write the next round's dispatch plan | `convergence` "Round 1-N" |
 | `okstra convergence reverify-prompt --run-manifest <path> --plan <path> --worker <worker>` | Print one worker's reverify instructions; never compose them by hand | `convergence` "Re-verification Dispatch" |
-| `okstra convergence collect-results --plan <path> --mode <mode> --run-manifest <path> --output <path>` | Read one round's responses into the apply-round input | `convergence` "Round 1-N" |
+| `okstra convergence collect-results --plan <path> --result <worker>=<path> --run-manifest <path> --output <path>` | Read one round's responses into the apply-round input | `convergence` "Round 1-N" |
 | `okstra convergence apply-round --work-state <path> --plan <path> --results <path>` | Apply a round's results | `convergence` "Round 1-N" |
-| `okstra convergence critic-prompt --run-manifest <path>` | Print the coverage-critic instructions; dispatch concurrently with the first reverify round | `convergence` "Coverage critic pass" |
-| `okstra convergence critic-verify-prompt --run-manifest <path> --gaps <path> --worker <worker>` | Print one analyser's gap-verification instructions | `convergence` "Gap verification" |
+| `okstra convergence critic-prompt --run-manifest <path>` | Print the critic instructions (acceptance on `final-verification`, coverage elsewhere); dispatch concurrently with the first reverify round | `convergence` "Coverage critic pass" |
+| `okstra convergence critic-verify-prompt --run-manifest <path> --gaps <path> --worker <worker>` | Print one analyser's gap-verification or acceptance-candidate instructions | `convergence` "Gap verification", "Acceptance critic pass" |
+| `okstra convergence collect-acceptance-votes --run-manifest <path> --candidates <path> --result <worker>=<path> --output <path>` | Derive confirmed/downgraded per acceptance candidate from the analysers' responses | `convergence` "Acceptance critic pass" |
 | `okstra convergence apply-critic-gaps --work-state <path> --results <path>` | Apply the gap-verification batch once, before `finalize` | `convergence` "Coverage critic pass" |
 | `okstra convergence apply-acceptance-critic --work-state <path> --results <path>` | Record the final-verification acceptance-critic accounting | `convergence` "Acceptance critic pass" |
 | `okstra convergence finalize --work-state <path> --output <path>` | Write the public final state after every round and critic batch is applied | `convergence` "Round 1-N" |
@@ -196,6 +231,7 @@ A single okstra run executes **exactly one** lifecycle phase. The phase is given
 | `final-verification` | acceptance verdict, residual risk, regression notes; read-only execution of existing test/validation commands, run-artifact writes (qa result sidecars, `okstra handoff record-verified` on acceptance), and qaEnv-replica-only conformance runs are permitted | source code edits, refactors, scope expansion, mutations of the project or shared environments |
 | `release-handoff` | user-selected packaging only: PR creation / push of the implementation branch, handoff summary (lead-only phase) | local commits, history-rewriting pushes, direct pushes to a base branch, release-publishing commands, source edits, worker dispatch of any kind |
 | `improvement-discovery` *(sidetrack — outside `PHASE_SEQUENCE`)* | lens-scoped improvement candidates (`## 5.9` report), per-candidate next-phase recommendation | code edits, planning or root-cause work, candidates outside the lens allowlist or beyond the cap, starting any lifecycle phase inside this run |
+| `discussion` *(sidetrack — outside `PHASE_SEQUENCE`)* | the lead facilitates: researched evidence, assumptions and alternatives, user questions one at a time, recorded user decisions, remaining disagreements and risks; completion only on the user's confirmation | code edits, detailed implementation plans, state-mutating commands, treating agent consensus or a convergence stop as completion, starting a follow-up task or any lifecycle phase inside this run |
 
 Phase-transition checklist (lead, end of run):
 
@@ -407,7 +443,7 @@ examples and critic-specific procedures; the conditional reading table in the
 output identifies when those sections are needed:
 
 ```sh
-awk '/^### Lightweight Re-verification Prompt$/ {skip=1} /^## Convergence State Artifact$/ {skip=0} /^## Coverage critic pass$/ {skip=1} /^## Output$/ {skip=0} !skip {print}' '<convergence-contract-path>'
+awk '/^### Adversarial Re-verification Prompt$/ {skip=1} /^## Convergence State Artifact$/ {skip=0} /^## Coverage critic pass$/ {skip=1} /^## Output$/ {skip=0} !skip {print}' '<convergence-contract-path>'
 ```
 
 `tests/contract/test_contract_examples_execute.py::test_convergence_common_read_keeps_protocol`
@@ -530,11 +566,10 @@ The deterministic dispatcher records this through its selected adapter — Lead
 Convergence is enabled by default. Configure via task-manifest.json:
 
 - `convergence.enabled`: true/false (default: true)
-- `convergence.maxRounds`: 1–3 — **phase-aware default**: `1` for `requirements-discovery`, `2` for all other task types
-- `convergence.verificationMode`: `"lightweight"` | `"full-reanalysis"` (default: `"lightweight"`; the adversarial phases below force `"full-reanalysis"`)
-- `convergence.adversarial`: true/false — **phase-aware default**: `true` for `requirements-discovery` / `error-analysis` / `implementation-option-selection` / `implementation-planning` / `project-analysis` / `feature-analysis` / `change-impact-analysis`, `false` otherwise. When `true`, Phase 5.5 runs in adversarial mode (verifiers refute findings; burden of proof on the claim). See [convergence](./convergence.md) "Adversarial Verification Mode".
+- `convergence.maxRounds`: 1–3 — default `2`
+- `convergence.adversarial` is always `true` and `convergence.verificationMode` always `"full-reanalysis"`: every phase runs Phase 5.5 in adversarial mode (verifiers refute findings; burden of proof on the claim). See [convergence](./convergence.md) "Adversarial Verification Mode".
 
-When `task-manifest.json` does not set `convergence.maxRounds`, lead MUST resolve the effective value via the phase-aware default above before entering Phase 5.5 and put it in the grouped input at `config.effectiveMaxRounds`.
+When `task-manifest.json` does not set `convergence.maxRounds`, lead MUST resolve the effective value via the default above before entering Phase 5.5 and put it in the grouped input at `config.effectiveMaxRounds`.
 
 The lead judges semantic similarity, ticket-set equality, and evidence. After writing the grouped input, it drives `okstra convergence seed → plan-round → apply-round → finalize → validate` and MUST NOT calculate queue membership, classification, history arithmetic, skip reasons, final state, or counts itself. `ConvergenceEngine` owns all of those deterministic transitions.
 
@@ -643,14 +678,12 @@ The run-level error log lives at `<runDir>/logs/errors-<task-type>-<seq>.jsonl`.
 | Ignoring task bundle model assignments | Task bundle overrides are canonical |
 | Inserting per-worker emphasis sentences ("you focus on X") into dispatch prompts | Send byte-identical dispatch prompts per [team-contract](./team-contract.md) "Dispatch-prompt invariant" — specialization lives in Section 7 of the worker output, not the prompt body |
 | Omitting contested or worker-unique findings | All categories must appear in the report |
-| Running full re-analysis when lightweight suffices | Default lightweight; full only when manifest opts in |
 | Using `/tmp/*prompt*.txt` for worker prompt persistence | Persist the exact worker prompt to the assigned run-level `prompts/` path |
 | Lead writes `final-report-<suffix>.md` itself when `Report writer worker` is in the roster | Dispatch the Report writer worker per [report-writer](./report-writer.md) "Phase 6 dispatch template" |
 | Skipping Report writer worker dispatch citing "session resume constraint" or "team is gone" | No such constraint exists — see [report-writer](./report-writer.md) "Resume-safe dispatch" |
 | Selecting a generic worker assignment for Report writer worker | Use the rostered `report-writer-worker` assignment; the selected adapter owns its native field mapping |
 | Including `final-report-template.md` in analysis worker `[Required reading]` | Template belongs only in the report-writer prompt — see [team-contract](./team-contract.md) audience-scoped enumeration |
-| Injecting `[Required reading]` into lightweight reverify prompts | Lightweight reverify forbids re-reading source materials — see [convergence](./convergence.md) "Reverify prompt: required-reading suppression" |
-| Letting `convergence.maxRounds` default to 2 for `requirements-discovery` | Resolve effective default to `1` for discovery and put it in the grouped input |
+| Injecting `[Required reading]` into reverify prompts | A reverify reads only the cited evidence — see [convergence](./convergence.md) "Reverify prompt: required-reading suppression" |
 | Issuing serial Read calls in Phase 1 | The intake files are independent — issue all Read calls in a single message (parallel) |
 | Running `agent-prompt materialize`, `jobs`, or a jobs-file dispatcher once per `runner=cli-wrapper` worker of a batch | One `okstra agent-prompt materialize --project-root <dir> --run-manifest <path> --batch <file> --jobs-out <jobs-file>` call per batch, chained with the dispatcher the execution surface selects (`okstra team dispatch` on `cmux-pane`, `okstra worker-dispatch` otherwise) and `--jobs-file <jobs-file>`. Native-session rows still dispatch one host call per row — see [convergence](./convergence.md) "Invocation materialization gate" |
 | Flagging an adapter-shortened dispatch prompt as "incomplete" because it omits host-loaded material | The Worker Preamble pointer and core inputs remain mandatory; the selected adapter may omit duplicate host-loaded definitions |

package/runtime/prompts/profiles/_common-contract.md

@@ -9,7 +9,7 @@ profile document.
 - Worker interaction model (shared — read before inferring behaviour from the roster):
   - the run's selected roster is a **roster**, not a behaviour contract. Each role's interaction mode changes across operating phases of the same run.
   - **Phase 4 / 5 (independent analysis)**: every analyser in the resolved provider assignment roster produces findings independently and has no access to another worker's output. `report-writer` does not analyse.
-  - **Phase 5.5 (convergence — peer review by workers)**: workers peer-review each other's findings across up to `effectiveMaxRounds` rounds; the lead mediates but does not vote. See `prompts/lead/convergence.md` for the round protocol (replay of findings, `AGREE` / `DISAGREE` / `SUPPLEMENT` verdicts), queue invariants, and final classification (`full-consensus` / `partial-consensus` / `contested` / `worker-unique` / `unverified`). For `requirements-discovery`, `error-analysis`, `implementation-option-selection`, `implementation-planning`, `project-analysis`, `feature-analysis`, and `change-impact-analysis` this phase runs in **adversarial mode** (`convergence.adversarial=true`): verifiers try to refute each finding against its cited evidence and the burden of proof sits on the claim — see that skill's §"Adversarial Verification Mode".
+  - **Phase 5.5 (convergence — peer review by workers)**: workers peer-review each other's findings across up to `effectiveMaxRounds` rounds; the lead mediates but does not vote. See `prompts/lead/convergence.md` for the round protocol (replay of findings, `SURVIVES` / `SURVIVES-WITH-CAVEAT` / `REFUTED` / `UNVERIFIABLE` verdicts), queue invariants, and final classification (`full-consensus` / `partial-consensus` / `contested` / `worker-unique` / `unverified`). Every phase runs it in **adversarial mode** (`convergence.adversarial=true`): verifiers try to refute each finding against its cited evidence and the burden of proof sits on the claim — see that skill's §"Adversarial Verification Mode".
   - Do NOT conclude "no peer review happens" from the roster alone — every profile that lists ≥2 analyser workers runs convergence by default (`convergence.enabled=true` in `task-manifest.json`).
   - For a new `implementation-planning` run, the plan-body sequence is initial verification → one planner self-fix → targeted re-verification → user gate. The initial verification is round 1, the targeted re-verification is round 2, and a second automatic self-fix is a contract violation. A user-directed correction does not consume the automatic self-fix limit, and a verification failure after that correction does not restart the automatic loop.
   - **provider-unavailable fallback (tolerance).** A worker dispatch can fail to produce a result for two distinct reasons, and both take the same recovery path. (1) **Pane budget:** the dispatch is rejected because a teammate pane could not be created — this is the harness running out of room for its own teammate panes, not okstra placing a worker. The wording is the host's, so match the condition rather than a fixed string. (2) **Sandbox CLI-start failure:** an external CLI worker wrapper exits non-zero within seconds with empty stdout and its live-log shows `operation not permitted`. In either case the lead spends the one shared retry budget through the assignment's recorded runner. If the provider is still unavailable, record that terminal status and continue only under the convergence quorum rules; never replace it silently with a fixed provider or count a substitute as the original provider's vote. Completed external-CLI workers hold no pane of their own. A pane the harness opened for its own teammate carries no id okstra recorded, so no okstra command closes it — the host and the user own that surface. (This is a prompt instruction, not a code-enforced gate.)

package/runtime/prompts/wizard/prompts.ko.json

@@ -96,7 +96,7 @@
       }
     },
     "task_type_text": {
-      "label": "Task type? (입력 가능: requirements-discovery, improvement-discovery, project-analysis, feature-analysis, change-impact-analysis, error-analysis, implementation-option-selection, implementation-planning, implementation, final-verification, release-handoff)",
+      "label": "Task type? (입력 가능: requirements-discovery, improvement-discovery, project-analysis, feature-analysis, change-impact-analysis, error-analysis, implementation-option-selection, implementation-planning, implementation, final-verification, release-handoff, discussion)",
       "echo_template": "task-type: {value}"
     },
     "selected_direction_pick": {
@@ -223,6 +223,19 @@
         "abort": "brief-carry: 중단"
       }
     },
+    "discussion_start_pick": {
+      "label": "무엇에 대한 토론을 시작할까요? discussion 은 brief 대신 이 시작 입력을 받고, 진행자가 토론 대상과 해결할 질문을 먼저 확인합니다.",
+      "echo_template": "discussion-start: {value}",
+      "options": {
+        "__continue__": "이 task 의 토론 이어가기 — {task_key} (마지막 결정·대기 질문 복원)",
+        "__brief__": "이 brief 를 시작 입력으로 — {brief}",
+        "__free_input__": "티켓·프로젝트 링크 또는 짧은 설명 직접 입력"
+      }
+    },
+    "discussion_start": {
+      "label": "토론 시작 입력: 티켓·프로젝트 링크(URL 또는 프로젝트 안 파일 경로)나 토론할 내용을 짧게 입력하세요.",
+      "echo_template": "discussion-start: {value}"
+    },
     "base_ref_pick": {
       "label": "이 task 의 base branch?",
       "echo_template": "base-ref: {value}",

package/runtime/python/okstra_ctl/adapters/providers/antigravity/adapter.py

@@ -33,6 +33,10 @@ ANTIGRAVITY = {
         "gemini-3.1-pro", "Gemini 3.1 Pro", "gemini-3.1-pro",
         aliases=("gemini 3.1 pro",),
     ),
+    "gemini-4-argon": ModelSpec(
+        "gemini-4-argon", "Gemini 4 Argon", "gemini-4-argon",
+        aliases=("gemini 4 argon",),
+    ),
     "gemini-3.8-flash": ModelSpec(
         "gemini-3.8-flash", "Gemini 3.8 Flash", "gemini-3.8-flash",
         aliases=("gemini 3.8 flash",),

package/runtime/python/okstra_ctl/adapters/providers/claude/adapter.py

@@ -44,7 +44,7 @@ CLAUDE = {
     # opus 채널이 지금 서빙하는 점-릴리스. 엔트리가 없으면 served-model 게이트가
     # 관측값을 카탈로그에서 못 찾아 dispatch 가 exit 78 로 실패한다 — 실측
     # 2026-09-23, 두 프로젝트에서 `claude-opus-5-5` 로 같은 실패(dev-10860
-    # stage-3·4·5). haiku-4-5-20251001 과 같은 이유의 엔트리다.
+    # stage-3·4·5).
     "opus-5-5": ModelSpec(
         "opus-5-5", "opus-5-5", "claude-opus-5-5", aliases=("claude-opus-5-5",),
         channel_family="opus", selectable=False,
@@ -66,16 +66,9 @@ CLAUDE = {
     "haiku": ModelSpec(
         "haiku", "haiku", "haiku", version_kind="channel", channel_family="haiku"
     ),
-    # picker 에서는 감춘다(사유는 fable-5 와 동일).
-    "haiku-4-5": ModelSpec(
-        "haiku-4-5", "haiku-4-5", "claude-haiku-4-5", aliases=("claude-haiku-4-5",),
-        channel_family="haiku", selectable=False,
-    ),
-    # 구버전이 아니라 haiku 채널이 실제로 서빙하는 날짜-고정 id 다. 이 엔트리가
-    # 없으면 served-model 게이트가 관측값을 카탈로그에서 못 찾아 dispatch 가
-    # "served model is not in the catalog" 로 실패한다(dispatch_core.py).
-    "haiku-4-5-20251001": ModelSpec(
-        "haiku-4-5-20251001", "haiku-4-5", "claude-haiku-4-5-20251001",
+    # haiku 채널이 서빙하는 점-릴리스(opus-5-5 와 같은 이유).
+    "haiku-5-5": ModelSpec(
+        "haiku-5-5", "haiku-5-5", "claude-haiku-5-5", aliases=("claude-haiku-5-5",),
         channel_family="haiku", selectable=False,
     ),
 }

package/runtime/python/okstra_ctl/agent/invocation.py

@@ -29,6 +29,7 @@ AgentAudience = Literal[
     "discovery-worker",
     "diagnosis-worker",
     "technical-verification-worker",
+    "discussion-worker",
     "planning-worker",
     "direction-selection-worker",
     "implementation-executor",

package/runtime/python/okstra_ctl/agent/prompt_cli/dynamic_verifier.py

@@ -28,7 +28,7 @@ from ...convergence_store import (
 from ...worker_prompt_policy import (
     CRITIC_VERIFY_DISPATCH_KIND,
     PLAN_VERIFY_DISPATCH_KIND_PREFIX,
-    is_plan_critic_verification,
+    is_critic_verification,
     verification_dispatch_round,
 )
 from .inputs import AgentPromptCliError
@@ -82,7 +82,7 @@ def _dynamic_verifier_source(
         and manifest.get("executionIdentityVersion") == 2
     )
     is_reverify = (
-        (args.assignment_ref.startswith("reverify/") or is_plan_critic_verification(
+        (args.assignment_ref.startswith("reverify/") or is_critic_verification(
             task_type=str(manifest.get("taskType", "")),
             assignment_ref=args.assignment_ref, dispatch_kind=args.dispatch_kind,
         ))

package/runtime/python/okstra_ctl/agent/prompt_cli/materialize.py

@@ -40,7 +40,7 @@ from ...worker_prompt_contract import (
 )
 from ...worker_prompt_policy import (
     critic_assignment_ref,
-    is_plan_critic_verification,
+    is_critic_verification,
     is_verification_dispatch_kind,
 )
 from ...paths import okstra_home
@@ -278,15 +278,15 @@ def _materialize_run(
         if (
             args.assignment_ref == "reverify/critic-worker"
             and critic_ref in assignments
-            and is_plan_critic_verification(
+            and is_critic_verification(
                 task_type=str(manifest.get("taskType", "")),
                 assignment_ref=critic_ref, dispatch_kind=args.dispatch_kind,
             )
         ):
             recovery = (
-                f"; for the rostered plan critic, use --assignment-ref {critic_ref} "
+                f"; for the rostered critic, use --assignment-ref {critic_ref} "
                 "with --worker-id critic-worker and --audience reverification-worker. "
-                "Keep the plan-verify-r<N> dispatch kind and, on v2 runs, the selected "
+                f"Keep the {args.dispatch_kind} dispatch kind and, on v2 runs, the selected "
                 "critic's --source-role-execution-ref. This is a reference correction; "
                 "the existing critic assignment does not need to be added or changed"
             )

package/runtime/python/okstra_ctl/agent/prompt_cli/run_identity.py

@@ -10,7 +10,7 @@ from typing import Any, Mapping
 
 from ...worker_prompt_policy import (
     CRITIC_DUTY_BY_ASSIGNMENT_SEGMENT,
-    is_plan_critic_verification,
+    is_critic_verification,
     resolve_prompt_plan_for_manifest,
 )
 from .inputs import AgentPromptCliError
@@ -36,7 +36,7 @@ def _validate_run_identity(
     elif assignment_ref.startswith("critic/"):
         scope = assignment_ref.split("/", 1)[1]
         expected = CRITIC_DUTY_BY_ASSIGNMENT_SEGMENT.get(scope, "")
-        if is_plan_critic_verification(
+        if is_critic_verification(
             task_type=str(manifest.get("taskType", "")),
             assignment_ref=assignment_ref, dispatch_kind=dispatch_kind,
         ):

package/runtime/python/okstra_ctl/analysis_packet.py

@@ -84,6 +84,9 @@ WORKER_PROFILE_SECTIONS_BY_TASK_TYPE = {
         # while the aggregate still looks complete.
         "Worker diversity rule",
     ),
+    "discussion": (
+        "Worker research procedure",
+    ),
 }
 CLARIFICATION_SECTIONS = (
     "Clarification Items",

package/runtime/python/okstra_ctl/consumers.py

@@ -139,7 +139,8 @@ def append_consumer(plan_run_root: Path, *, impl_task_key: str, stage: int,
     with consumers_mutex(plan_run_root):
         if not _equivalent_row_exists(plan_run_root, impl_task_key, stage,
                                       status, force_reappend,
-                                      fields.get("head_commit")):
+                                      fields.get("head_commit"),
+                                      fields.get("source")):
             record: Dict[str, Any] = {
                 "impl_task_key": impl_task_key,
                 "stage": stage,
@@ -157,7 +158,7 @@ def append_consumer(plan_run_root: Path, *, impl_task_key: str, stage: int,
 
 def _equivalent_row_exists(plan_run_root: Path, impl_task_key: str, stage: int,
                            status: str, force_reappend: bool,
-                           head_commit: Any) -> bool:
+                           head_commit: Any, source: Any = None) -> bool:
     rows = read_consumers(plan_run_root)
     # 같은 tuple 이 이미 있어도, 그 뒤에 다른 lifecycle row 가 왔다면 이 append 는
     # stage 의 현재 위치를 옮기는 새 사실이다 — fix run 의 started 재기록이 그 경우다.
@@ -167,6 +168,11 @@ def _equivalent_row_exists(plan_run_root: Path, impl_task_key: str, stage: int,
         if (row.get("impl_task_key") == impl_task_key
                 and row.get("stage") == stage
                 and row.get("status") == status):
+            # backfill 행은 리드가 쓸 행의 대역이라 `report_path`·`completed_at` 이
+            # 없다. 리드의 행이 그 뒤에 붙어야 최신 done 행이 보고서를 가리킨다.
+            if (row.get("source") == "carry-backfill"
+                    and source != "carry-backfill"):
+                continue
             if not force_reappend:
                 return True
             if row.get("head_commit") == head_commit: