okstra 0.49.0 → 0.50.0

package/runtime/prompts/profiles/requirements-discovery.md

@@ -39,14 +39,14 @@
   - When the brief's `Desired Outcome`, classification, or routing target depends on a chain of decisions, walk that chain one branch at a time. Each branch is one `Clarification Items` row, not a free-form interview.
   - For every clarification row, put the single best answer and one-line rationale in `Expected form` as `Recommended: ...`. Put other options and one-sentence consequences in the same cell as `Alternatives: ...`.
   - **Codebase-first rule**: if a branch can be resolved by `Read` / `Grep` / file inspection, resolve it that way and record `Evidence checked: <path:line>` in the `Statement` cell. Do NOT escalate to the user.
-  - Budget: the unified `## 5. Clarification Items` table caps at the smaller of (a) one row per unresolved decision branch, (b) 8 rows total. Beyond the cap, fold remaining ambiguity into the routing recommendation's risk notes.
+  - Budget: the unified `## 1. Clarification Items` table caps at the smaller of (a) one row per unresolved decision branch, (b) 8 rows total. Beyond the cap, fold remaining ambiguity into the routing recommendation's risk notes.
 - Expected output emphasis:
   - evidence-backed routing decision
   - uncertainty boundaries and missing inputs
   - next recommended phase and safe resume guidance
   - canonical-term resolution for every `terminology:*` brief item, written as a one-line `<term> = <definition>` line in a new `Domain Alignment` subsection of the final report; alongside each, propose whether `<PROJECT_ROOT>/.okstra/glossary.md` should be updated (proposal only — actual writes happen via `okstra-brief` Step 4.5 on a subsequent run)
 - Clarification request policy (phase-specific addenda — shared policy is in `_common-contract.md`):
-  - if any blocking input is missing at the time of writing the final report, populate `## 5. Clarification Items` in `final-report-template.md` (a single unified table; `Blocks=next-phase` for items the next run cannot start without)
+  - if any blocking input is missing at the time of writing the final report, populate `## 1. Clarification Items` in `final-report-template.md` (a single unified table; `Blocks=next-phase` for items the next run cannot start without)
   - prefer concrete questions whose answers map directly to a routing decision (`bugfix` vs `feature`, `error-analysis` vs `implementation-planning`, etc.). State each option in plain language with one sentence describing what choosing it would mean for the next phase.
   - every clarification row carries a recommended answer + one-line rationale inside the `Expected form` cell; rows that lack a recommendation are rejected as half-formed.
   - **Codebase-first ambiguity resolution (defect rule)**: any ambiguity that can be answered by `Read` / `Grep` / file inspection MUST be resolved that way and recorded with file:line evidence. Writing a clarification row for something the codebase already answers is a defect of this phase.

package/runtime/python/okstra_ctl/clarification_items.py

@@ -1,6 +1,6 @@
-"""Parse the ``## 5. Clarification Items`` table from a final-report markdown.
+"""Parse the ``## 1. Clarification Items`` table from a final-report markdown.
 
-The unified §5 table (introduced when §4.5.9 / §5.1 / §5.2 collapsed into a
+The unified §1 table (introduced when §4.5.9 / §5.1 / §5.2 collapsed into a
 single section) is the canonical home for every clarification an
 implementation-planning run owes the user — decisions, file attachments,
 single data points. Each row carries a ``Blocks`` column whose value picks
@@ -12,7 +12,7 @@ This module exposes one read function for that gate so both
 ``_validate_approved_plan`` (pre-implementation run-prep) and any later
 validator can share the same parsing logic.
 
-Legacy compatibility: reports written before the §5 unification used
+Legacy compatibility: reports written before the §1 unification used
 ``4.5.9 Open Questions`` + ``5.1 Additional Materials`` + ``5.2 Questions
 for the User`` and lacked a ``Blocks`` column. Those reports cannot be
 gate-checked by Blocks; the parser returns ``None`` to signal "schema
@@ -26,13 +26,13 @@ from pathlib import Path
 from typing import Optional
 
 
-SECTION_HEADING_PATTERN = re.compile(r"^##\s+5\.\s+Clarification Items\s*$", re.MULTILINE)
-NEXT_TOP_LEVEL_HEADING_PATTERN = re.compile(r"^##\s+(?!5\.)", re.MULTILINE)
+SECTION_HEADING_PATTERN = re.compile(r"^##\s+1\.\s+Clarification Items\s*$", re.MULTILINE)
+NEXT_TOP_LEVEL_HEADING_PATTERN = re.compile(r"^##\s+(?!1\.)", re.MULTILINE)
 
 
 @dataclass(frozen=True)
 class ClarificationItem:
-    """One row of the §5 table.
+    """One row of the §1 table.
 
     ``raw_*`` fields preserve the exact cell text (after backtick stripping)
     for diagnostics; canonical lowercased versions live in ``blocks`` /
@@ -77,9 +77,9 @@ def _is_separator_row(line: str) -> bool:
     return True
 
 
-def _section_5_slice(report_text: str) -> Optional[str]:
-    """Return the substring spanning the §5 section (heading exclusive of the
-    next ``##`` heading), or None if §5 is absent."""
+def _section_1_slice(report_text: str) -> Optional[str]:
+    """Return the substring spanning the §1 section (heading exclusive of the
+    next ``##`` heading), or None if §1 is absent."""
     start_match = SECTION_HEADING_PATTERN.search(report_text)
     if not start_match:
         return None
@@ -89,7 +89,7 @@ def _section_5_slice(report_text: str) -> Optional[str]:
 
 
 def parse_clarification_items(report_text: str) -> Optional[list[ClarificationItem]]:
-    """Return the list of §5 rows. ``None`` means "no unified §5 table
+    """Return the list of §1 rows. ``None`` means "no unified §1 table
     detected" (legacy report or missing section) — caller must NOT treat
     that as "table is empty".
 
@@ -97,7 +97,7 @@ def parse_clarification_items(report_text: str) -> Optional[list[ClarificationIt
     just the ``- 추가 정보 요청 없음.`` placeholder); that IS a confident
     "no approval-blocking items".
     """
-    section = _section_5_slice(report_text)
+    section = _section_1_slice(report_text)
     if section is None:
         return None
 

package/runtime/python/okstra_ctl/render.py

@@ -75,7 +75,7 @@ def _strip_phase_blocks(text: str, current_phase: str) -> str:
     entirely. When *current_phase* is empty or not one of the four
     block-targetable phases (e.g. `requirements-discovery`,
     `error-analysis`), every block is dropped — correct because none of
-    the `## 4.5` / `4.6` / `4.7` / `4.8` deliverable sections apply
+    the `## 5.5` / `5.6` / `5.7` / `5.8` deliverable sections apply
     there.
 
     Observed (fontsninja-classifier-v2 RD run): the raw final-report

package/runtime/python/okstra_ctl/render_final_report.py

@@ -9,7 +9,7 @@ the canonical user-facing markdown.
 
 Why this exists: prior to v0.32, report-writer-worker wrote the markdown
 directly. Free-form authoring led to silent contract violations — missing
-columns in the Execution Status table, omitted §7 phase-continuation
+columns in the Execution Status table, omitted §4 phase-continuation
 rows, invented ``## Index`` sections. Routing everything through one
 template + schema cuts those failure modes to zero.
 

package/runtime/python/okstra_ctl/report_views.py

@@ -3,9 +3,9 @@
 Single product, single source of truth:
 
 * ``render_html(src_md, *, run_meta)`` — deterministic self-contained
-  HTML renderer for human readers. Sections §5/§6/§7 user-actionable
-  rows (those reachable from §5 ``C-*`` IDs) get embedded ``<form>``
-  controls. §4.6 / §4.7 / §4.8 deliverable sub-sections are explicitly
+  HTML renderer for human readers. Sections §1/§3/§4 user-actionable
+  rows (those reachable from §1 ``C-*`` IDs) get embedded ``<form>``
+  controls. §5.6 / §5.7 / §5.8 deliverable sub-sections are explicitly
   excluded from form attachment — they are read-only deliverables.
 
 User responses are NEVER merged back into the original report. The HTML
@@ -57,7 +57,7 @@ def _strip_leading_frontmatter(text: str) -> str:
 
 from .clarification_items import (
     _is_separator_row,
-    _section_5_slice,
+    _section_1_slice,
     _split_pipe_row,
     parse_clarification_items,
 )
@@ -79,7 +79,7 @@ _LINK_PATTERN = re.compile(r"\[([^\]]+)\]\(([^)]+)\)")
 
 # Sections whose Response-ID-bearing rows must NOT get form attachment
 # (read-only deliverables — see plan §1.4).
-_NO_FORM_SECTION_PREFIXES = ("## 4.6", "### 4.6", "## 4.7", "### 4.7", "## 4.8", "### 4.8")
+_NO_FORM_SECTION_PREFIXES = ("## 5.6", "### 5.6", "## 5.7", "### 5.7", "## 5.8", "### 5.8")
 
 
 @dataclass(frozen=True)
@@ -161,7 +161,7 @@ def _markdown_to_html(
     headings: list[tuple[int, str, str]] = []
     i = 0
     n = len(lines)
-    current_section_path: list[str] = []  # ['## 5. ...', '### 5.1 ...'] etc.
+    current_section_path: list[str] = []  # ['## 1. ...', '### 1.1 ...'] etc.
 
     while i < n:
         line = lines[i]
@@ -394,7 +394,7 @@ class _GroupedSpec:
     value`` metadata cell led by ``headline_col``; the long columns
     (``wide_cols``) each keep their own min-width column.
 
-    ``kind == "clarification"`` additionally re-attaches the §5 form
+    ``kind == "clarification"`` additionally re-attaches the §1 form
     widget to the ``user_input_col`` cell and the ``data-*`` row attrs."""
     headline_col: int
     group_cols: tuple[int, ...]
@@ -410,7 +410,7 @@ class _GroupedSpec:
 def _grouped_table_spec(
     header_cells: list[str], section_path: list[str]
 ) -> Optional[_GroupedSpec]:
-    """Only §5 Clarification Items is grouped in the HTML view (it keeps the
+    """Only §1 Clarification Items is grouped in the HTML view (it keeps the
     interactive form and stays flat in the .md). All other narrative tables are
     already rendered compactly by the template, so no grouping is applied here."""
     norm = [h.strip() for h in header_cells]
@@ -420,7 +420,7 @@ def _grouped_table_spec(
         group = tuple(c for c in range(len(norm)) if c != headline and c not in wide_set)
         return _GroupedSpec(headline_col=headline, group_cols=group, wide_cols=wide, **kw)
 
-    # §5 Clarification Items — keep the interactive form, and widen the three
+    # §1 Clarification Items — keep the interactive form, and widen the three
     # long-prose columns (Expected form is prose too, not a code column).
     if (
         any("Clarification Items" in h for h in section_path)
@@ -474,7 +474,7 @@ def _grouped_meta_cell(
 def _grouped_clarification_row(
     row: list[str], spec: _GroupedSpec
 ) -> tuple[str, str]:
-    """Return ``(tr_attrs, wide_cells_html)`` for one §5 row, re-attaching
+    """Return ``(tr_attrs, wide_cells_html)`` for one §1 row, re-attaching
     the form widget + ``data-*`` attrs to ``C-\\d+`` rows exactly as the
     non-grouped path does."""
     rid = row[spec.id_col] if 0 <= spec.id_col < len(row) else ""
@@ -822,7 +822,7 @@ def serialize_user_response(
 # --------------------------------------------------------------------------- #
 
 def report_has_clarification_items(src_md: str) -> bool:
-    """True when the final-report MD has at least one §5 ``C-*``
+    """True when the final-report MD has at least one §1``C-*``
     clarification row. This is the single predicate that gates HTML-view
     generation: the self-contained html's only value over the markdown is
     the embedded ``<form>`` widgets for those rows, so a clarification-free
@@ -844,7 +844,7 @@ def render_html_view(
 ) -> Path | None:
     """Write ``<stem>.html`` next to ``src_md_path`` and return its path,
     or return ``None`` when generation is skipped because the report has
-    no §5 clarification rows (see ``report_has_clarification_items``).
+    no §1 clarification rows (see ``report_has_clarification_items``).
     Idempotent — overwrites an existing html sibling, and removes a stale
     one when a previously-clarification-bearing report no longer has rows."""
     src_text = src_md_path.read_text(encoding="utf-8")

package/runtime/python/okstra_ctl/run.py

@@ -175,14 +175,14 @@ def _validate_approved_plan(path: str) -> None:
             f"approved plan is not yet approved (frontmatter `approved: {m.group(1)}`): {path}\n"
             "  open the report and change the frontmatter line to `approved: true`, "
             "or re-run okstra with `--approve` to flip it from the CLI.\n"
-            "  resolve any `Blocks=approval` rows in `## 5. Clarification Items` first."
+            "  resolve any `Blocks=approval` rows in `## 1. Clarification Items` first."
         )
-    # frontmatter approved == true 상태. §5 Clarification Items 의
+    # frontmatter approved == true 상태. §1 Clarification Items 의
     # Blocks=approval 행이 아직 open/answered 면 승인을 무효화한다.
     blockers = unresolved_approval_blockers(body)
     if blockers:
         lines = [
-            f"approved plan frontmatter has `approved: true` but §5 has {len(blockers)} "
+            f"approved plan frontmatter has `approved: true` but §1 has {len(blockers)} "
             f"unresolved `Blocks=approval` row(s); resolve them or mark them obsolete first:",
         ]
         for b in blockers:

package/runtime/python/okstra_ctl/wizard.py

@@ -205,6 +205,28 @@ S_CONFIRM = "confirm"
 S_EDIT_TARGET = "edit_target"
 S_DONE = "done"
 
+# ---- 멀티탭 배치 프롬프트 그룹 (방출 계층 전용) ----
+# 그룹 id 는 S_* 가 아니므로 prompts JSON SOT / step-id 동기화 검사 대상이 아니다.
+GROUP_MODELS = "models"
+GROUP_OPTIONS = "options"
+GROUP_MAX_TABS = 4  # AskUserQuestion 의 질문(탭) 수 한도
+
+# 멤버는 모두 서로 의존이 없는 단일선택 픽 step 이어야 한다.
+# *_TEXT 후속 / workers_override / pr_template_scope 는 의존성 때문에 개별 유지.
+PROMPT_GROUPS: dict[str, tuple[str, ...]] = {
+    GROUP_MODELS: (S_LEAD_MODEL, S_EXECUTOR_MODEL, S_CLAUDE_MODEL,
+                   S_CODEX_MODEL, S_GEMINI_MODEL, S_REPORT_WRITER_MODEL),
+    GROUP_OPTIONS: (S_DIRECTIVE_PICK, S_RELATED_TASKS_PICK,
+                    S_CLARIFICATION_PICK, S_PR_TEMPLATE_PICK),
+}
+GROUP_LABELS: dict[str, str] = {
+    GROUP_MODELS: "모델 선택 (탭별로 선택)",
+    GROUP_OPTIONS: "추가 옵션 (탭별로 선택)",
+}
+_STEP_TO_GROUP: dict[str, str] = {
+    sid: gid for gid, ids in PROMPT_GROUPS.items() for sid in ids
+}
+
 
 # ---- Data types ----------------------------------------------------------
 
@@ -305,9 +327,11 @@ class Prompt:
     help: str = ""
     echo_template: str = ""  # e.g. "task-group: {value}"
     multi: bool = False  # only meaningful when kind == "pick"
+    # only meaningful when kind == "pick_group": one entry per AskUserQuestion tab
+    questions: list["Prompt"] = field(default_factory=list)
 
     def to_json(self) -> dict[str, Any]:
-        return {
+        out = {
             "step": self.step,
             "kind": self.kind,
             "label": self.label,
@@ -316,6 +340,14 @@ class Prompt:
             "echoTemplate": self.echo_template,
             "multi": self.multi,
         }
+        if self.kind == "pick_group":
+            out["questions"] = [
+                {"step": q.step, "label": q.label,
+                 "options": [asdict(o) for o in q.options],
+                 "multi": q.multi}
+                for q in self.questions
+            ]
+        return out
 
 
 class WizardError(Exception):
@@ -373,12 +405,12 @@ def _validate_approved_plan(path_str: str, project_root: Path) -> Path:
             "  edit the report and change the line to `approved: true`, or re-run "
             "okstra with `--approve` to flip it from the CLI."
         )
-    # frontmatter approved == true 라도 §5 의 Blocks=approval 행이 미해결이면
+    # frontmatter approved == true 라도 §1 의 Blocks=approval 행이 미해결이면
     # 승인이 무효 — prepare_task_bundle 의 _validate_approved_plan 과 동일 규약.
     blockers = unresolved_approval_blockers(body)
     if blockers:
         lines = [
-            f"approved plan frontmatter has `approved: true` but §5 has {len(blockers)} "
+            f"approved plan frontmatter has `approved: true` but §1 has {len(blockers)} "
             f"unresolved `Blocks=approval` row(s); resolve them or mark them obsolete first:",
         ]
         for b in blockers:
@@ -2218,6 +2250,30 @@ def init_state(
     )
 
 
+def _build_group_prompt(state: WizardState, group_id: str) -> Prompt:
+    """그룹의 적용가능·미답변 픽 멤버를 최대 GROUP_MAX_TABS 개 모은다.
+
+    멤버가 1개뿐이면 멀티탭 UI가 불필요하므로 그 멤버의 평범한 픽을 반환한다.
+    호출부(next_prompt)는 적용 가능한 멤버가 최소 1개일 때만 진입하므로 빈 그룹은
+    도달 불가다.
+    """
+    members: list[Prompt] = []
+    for sid in PROMPT_GROUPS[group_id]:
+        if sid in state.answered:
+            continue
+        step = STEP_BY_ID[sid]
+        if not step.applies(state):
+            continue
+        members.append(step.build(state))
+        if len(members) >= GROUP_MAX_TABS:
+            break
+    assert members, f"group {group_id!r} reached with no applicable members"
+    if len(members) == 1:
+        return members[0]
+    return Prompt(step=group_id, kind="pick_group",
+                  label=GROUP_LABELS[group_id], questions=members)
+
+
 def next_prompt(state: WizardState) -> Prompt:
     if state.confirmed:
         return Prompt(step=S_DONE, kind="done")
@@ -2225,10 +2281,39 @@ def next_prompt(state: WizardState) -> Prompt:
         if step.id in state.answered:
             continue
         if step.applies(state):
+            group_id = _STEP_TO_GROUP.get(step.id)
+            if group_id is not None:
+                return _build_group_prompt(state, group_id)
             return step.build(state)
     return Prompt(step=S_DONE, kind="done")
 
 
+def _submit_group(state: WizardState, prompt: Prompt, value: str) -> dict[str, Any]:
+    """pick_group 답(JSON 객체)을 각 멤버 submit() 으로 라우팅한다.
+
+    멤버 submit 이 WizardError 를 던지면 그대로 전파되어 같은 그룹을 재-프롬프트한다.
+    answered 마킹은 모든 멤버 submit 이 통과한 뒤에만 일괄 수행한다(answered 단위의
+    전부-아니면-전무). 개별 멤버가 변경한 state 필드는 롤백하지 않지만, 재-프롬프트 시
+    같은 그룹이 다시 나와 사용자 입력으로 덮어쓰므로 무해하다.
+    """
+    try:
+        answers = json.loads(value or "{}")
+    except json.JSONDecodeError as exc:
+        raise WizardError(f"pick_group answer must be a JSON object: {exc}")
+    if not isinstance(answers, dict):
+        raise WizardError("pick_group answer must be a JSON object")
+    echoes: list[str] = []
+    for q in prompt.questions:
+        echo = STEP_BY_ID[q.step].submit(state, str(answers.get(q.step, "") or ""))
+        if echo:
+            echoes.append(echo)
+    for q in prompt.questions:
+        if q.step not in state.answered:
+            state.answered.append(q.step)
+    nxt = next_prompt(state)
+    return {"echo": "; ".join(echoes), "next": nxt.to_json()}
+
+
 def submit(state: WizardState, value: str) -> dict[str, Any]:
     """Validate the answer for the *currently active* step and advance.
 
@@ -2238,6 +2323,8 @@ def submit(state: WizardState, value: str) -> dict[str, Any]:
     prompt = next_prompt(state)
     if prompt.kind == "done":
         return {"echo": "", "next": prompt.to_json()}
+    if prompt.kind == "pick_group":
+        return _submit_group(state, prompt, value)
     step = STEP_BY_ID[prompt.step]
     echo = step.submit(state, value or "")
     if prompt.step not in state.answered:

package/runtime/python/okstra_ctl/workflow.py

@@ -87,7 +87,7 @@ PHASE_RULES: dict[str, dict[str, str]] = {
             "  - trade-off matrix across options (complexity, risk, reversibility, test cost, rollout cost) and recommended option with rationale tied to isolation / single-responsibility / YAGNI principles\n"
             "  - bite-sized stepwise execution order for the recommended option (each step ~2-5 min, exact file paths and commands, TDD ordering when applicable, no placeholders)\n"
             "  - dependency / migration risk assessment, validation checklist (pre / mid / post with exact commands), rollback strategy with revert path and trigger signal\n"
-            "  - every unresolved ambiguity registered as a `Blocks=approval` row in the `## 5. Clarification Items` table (do NOT create a separate `Open Questions` block under `4.5.x` — the unified table is the single home)\n"
+            "  - every unresolved ambiguity registered as a `Blocks=approval` row in the `## 1. Clarification Items` table (do NOT create a separate `Open Questions` block under `5.5.x` — the unified table is the single home)\n"
             "  - YAML frontmatter line `approved: false` awaiting human flip to `true`\n"
             "  - self-review confirmation (spec coverage, placeholder scan, internal consistency, ambiguity, scope)"
         ),

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

@@ -760,7 +760,7 @@ If the list is non-empty, run **one** `AskUserQuestion`:
   1. `Yes — collect now (Recommended)` — proceed to 6.5c.
   2. `No — leave for the downstream phase` — set
      `reporter-confirmations: skipped`. The phase will promote each
-     pending row into its own `## 5. Clarification Items` as
+     pending row into its own `## 1. Clarification Items` as
      `Blocks=next-phase` (`Blocks=approval` only in
      `implementation-planning`); see each phase profile's "Brief
      consumption" addendum.

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

@@ -77,7 +77,7 @@ Read the worker result files generated in Phase 4/5 and extract individual findi
    - For bullet/numbered findings, parse `[TICKETID: <id>]` from the item title.
    - Items with multiple tickets (e.g. `TICKET-123, TICKET-456`) expand to a set of ticket keys.
    - Items tagged `unknown` keep the literal `unknown` as their ticket key.
-2. For each finding, record the summary, evidence (file path, line number, basis), the worker who identified it, **the worker-internal item ID assigned by that worker** (e.g. `F-001`, `1.1`, `F-3` — see `prompts/profiles/_common-contract.md` "Cross-worker traceability" SSOT), and the parsed ticket set. The item ID is persisted on the finding record as `findings[].discoveredBy.<worker>.itemId` and on each cross-worker confirmation as `findings[].sourceItems[]` (one entry per contributing `<worker>:<item-id>` pair). The final-report's `## 1.1 Consensus` / `## 1.2 Differences` / `## 3.1 Primary Evidence` tables read this list verbatim into their `Source items` columns — without this, the synthesised `C-NNN` row has no traceable link back to the original worker wording.
+2. For each finding, record the summary, evidence (file path, line number, basis), the worker who identified it, **the worker-internal item ID assigned by that worker** (e.g. `F-001`, `1.1`, `F-3` — see `prompts/profiles/_common-contract.md` "Cross-worker traceability" SSOT), and the parsed ticket set. The item ID is persisted on the finding record as `findings[].discoveredBy.<worker>.itemId` and on each cross-worker confirmation as `findings[].sourceItems[]` (one entry per contributing `<worker>:<item-id>` pair). The final-report's `## 6.1 Consensus` / `## 6.2 Differences` / `## 2.1 Primary Evidence` tables read this list verbatim into their `Source items` columns — without this, the synthesised `C-NNN` row has no traceable link back to the original worker wording.
 3. Claude Lead groups findings based on semantic similarity AND ticket-set equality:
   - Same semantics + same ticket set across 2+ workers → immediately reach `full consensus`.
   - Same semantics but disjoint ticket sets → keep as separate groups (do NOT over-merge across tickets).
@@ -561,12 +561,12 @@ existing Acceptance Blocker. If you find none, say so explicitly.
 ### Verification — confirm-or-downgrade (BLOCKING)
 
 Each candidate blocker is verified by the Phase 4 analysers (excluding the critic). Do NOT use the adversarial finding classifier's "uncertain → reject" rule here.
-- **Confirmed** (an analyser reproduces it or cites supporting evidence) → promote to a `## 4 Acceptance Blockers` row (keep severity + recommended follow-up phase).
+- **Confirmed** (an analyser reproduces it or cites supporting evidence) → promote to a `## 5.8 Acceptance Blockers` row (keep severity + recommended follow-up phase).
 - **Not confirmed** (cannot reproduce, or evidence is weak) → **downgrade to a Residual Risk row — never drop it.** Record the escalation trigger so the user can re-judge a high-severity-but-unconfirmed candidate.
 
 ### Verdict impact
 
-Promoted blockers enter `## 4 Acceptance Blockers`; since `accepted` requires zero blockers, the verdict moves to `conditional-accept` / `blocked` automatically. The existing verdict↔blocker consistency validator (`validators/validate-run.py` `_validate_final_verification_consistency`) enforces this unchanged — no new enum or validator.
+Promoted blockers enter `## 5.8 Acceptance Blockers`; since `accepted` requires zero blockers, the verdict moves to `conditional-accept` / `blocked` automatically. The existing verdict↔blocker consistency validator (`validators/validate-run.py` `_validate_final_verification_consistency`) enforces this unchanged — no new enum or validator.
 
 ### State
 
@@ -630,7 +630,7 @@ Default values are emitted into the manifest by `scripts/okstra_ctl/render.py` (
 
 ### Plan-item extraction (Round 0 equivalent)
 
-From the report-writer's draft of `## 4.5 Implementation Plan Deliverables`, lead extracts plan items with the following prefixes (see also `templates/reports/final-report.template.md` §4.5.9):
+From the report-writer's draft of `## 5.5 Implementation Plan Deliverables`, lead extracts plan items with the following prefixes (see also `templates/reports/final-report.template.md` §5.5.9):
 
 | Prefix | Source sub-section | One row per |
 |--------|--------------------|-------------|
@@ -689,13 +689,13 @@ Plan-body verification stays **lightweight** even under this posture — the `ve
    - all dispatches non-result → `aborted-non-result`
    - any `partial-consensus` / `dissent-isolated` present, no `majority-disagree` → `passed-with-dissent`
    - all items `full-consensus` → `passed`
-6. Lead writes `runs/<task-type>/state/plan-body-verification-<task-type>-<seq>.json` (schema below) and populates `### 4.5.9 Plan Body Verification` in the final report (template at `templates/reports/final-report.template.md`). The §4.5.9 body uses a single `#### Verdict details` table (`Plan item / Worker / Verdict / Breakage kind / Note` — one row per plan-item × worker pair). The older wide `| Plan item | <worker1> | <worker2> | … | Classification |` matrix and the former narrow `#### Verdict summary` card are both removed — the matrix scaled horizontally with the worker count, and the summary only restated per-item classifications already derivable from the details table. The validator's `Plan Body Verification` + `Gate result:` substring checks gate this section.
-7. For every `majority-disagree` item, lead adds a row to `## 5. Clarification Items` with:
+6. Lead writes `runs/<task-type>/state/plan-body-verification-<task-type>-<seq>.json` (schema below) and populates `### 5.5.9 Plan Body Verification` in the final report (template at `templates/reports/final-report.template.md`). The §5.5.9 body uses a single `#### Verdict details` table (`Plan item / Worker / Verdict / Breakage kind / Note` — one row per plan-item × worker pair). The older wide `| Plan item | <worker1> | <worker2> | … | Classification |` matrix and the former narrow `#### Verdict summary` card are both removed — the matrix scaled horizontally with the worker count, and the summary only restated per-item classifications already derivable from the details table. The validator's `Plan Body Verification` + `Gate result:` substring checks gate this section.
+7. For every `majority-disagree` item, lead adds a row to `## 1. Clarification Items` with:
    - new `C-<N>` ID (numbering continues from any existing rows)
    - `Statement` summarising the disagreement and the worker breakage `<kind>`
    - `Kind` chosen per the standard policy (usually `decision` for option-level conflicts, `data-point` for path/symbol mismatches)
    - `Blocks=approval`
-   - the §4.5.9 verdict table's `Classification` column for that row reads `majority-disagree → C-<N>` (1:1 ID match — orphan on either side is a contract violation per `prompts/profiles/implementation-planning.md` self-review step 6).
+   - the §5.5.9 verdict table's `Classification` column for that row reads `majority-disagree → C-<N>` (1:1 ID match — orphan on either side is a contract violation per `prompts/profiles/implementation-planning.md` self-review step 6).
 8. The top-of-report `- [ ] Approved` marker line is rendered if and only if the Gate result is `passed` or `passed-with-dissent`. `validators/validate-run.py` `validate_phase_boundary` enforces this correspondence; manually adding the marker line when the gate did not pass is a contract violation.
 
 ### `plan-body-verification-<task-type>-<seq>.json` schema
@@ -802,4 +802,4 @@ Mirrors finding convergence (§"Worker failure handling in reverify"). Concretel
 
 - A dispatch that returns terminal non-result MUST NOT be aggregated as `DISAGREE`.
 - If at least one dispatch was issued AND **all** plan-body dispatches return non-result, the Gate result is `aborted-non-result`. Record one `contract-violation` event per non-result dispatch.
-- When the gate is `aborted-non-result`, report-writer MUST keep the frontmatter `approved: false` (publishing `approved: true` under this gate result is a validator failure). A single row is added to `## 5. Clarification Items` with `Statement="plan-body verification could not run — all workers returned non-result"`, `Kind=decision`, `Blocks=approval`, allowing the user to either retry the phase or override by manually flipping the frontmatter to `approved: true` (or running `--approve` on the resume command).
+- When the gate is `aborted-non-result`, report-writer MUST keep the frontmatter `approved: false` (publishing `approved: true` under this gate result is a validator failure). A single row is added to `## 1. Clarification Items` with `Statement="plan-body verification could not run — all workers returned non-result"`, `Kind=decision`, `Blocks=approval`, allowing the user to either retry the phase or override by manually flipping the frontmatter to `approved: true` (or running `--approve` on the resume command).

package/runtime/skills/okstra-report-writer/SKILL.md

@@ -48,9 +48,9 @@ The prompt MUST include, in this order at the top:
 6. `**Model:** Report writer worker, <modelExecutionValue>` (resolved per Phase 5.5 anchor-header rules)
 7. The full `[Required reading]` clause (see [okstra-team-contract](../okstra-team-contract/SKILL.md)) — for Phase 6 it adds two **per-task-type, instruction-set-local** read-only files, both scoped to this run's task-type by `okstra-ctl` at prep time:
    - `<instruction-set>/final-report-schema.json` — a task-type excerpt of the data.json schema (the other task-types' deliverable blocks and their unreachable `$defs` are stripped; ~38% of the full schema is `$defs` alone). This is your authoring contract for the data.json shape. Do **NOT** pull the full `schemas/final-report-v1.0.schema.json` — it carries all task-types and its `schemas/...` path is not part of the task bundle. (Validation still runs against the full schema post-hoc via the renderer, so the excerpt never relaxes the contract.)
-   - `<instruction-set>/final-report-template.md` — the **phase-stripped** template (every other task-type's §4.x deliverable block removed by `render.py`'s `_strip_phase_blocks`, leaving only your run's §4.x). Do **NOT** also pull the full `templates/reports/final-report.template.md` source (it re-adds ~330 lines of other phases' deliverables and is not in the task bundle).
+   - `<instruction-set>/final-report-template.md` — the **phase-stripped** template (every other task-type's §5.x deliverable block removed by `render.py`'s `_strip_phase_blocks`, leaving only your run's §5.x). Do **NOT** also pull the full `templates/reports/final-report.template.md` source (it re-adds ~330 lines of other phases' deliverables and is not in the task bundle).
 8. A one-line MCP pointer instead of the verbatim block — `**MCP servers:** follow the task brief's "## Available MCP Servers" section (already in your Required reading).` The brief is already in the report-writer's Required reading (item 7), so the verbatim block is redundant.
-9. The convergence classifications (Full/Partial/Contested/Worker-Unique), the round history data (`roundHistory[]`), the `round2SkippedReason` value, and pointers to all worker result files under `worker-results/`. The report-writer worker populates `crossVerification.roundHistory` in the data.json so Section 1 can show which rounds executed, queue sizes, and why Round 2 was (or was not) skipped. The renderer prints the full per-round table only when more than one round ran; single-round or zero-round histories are auto-collapsed to a one-line summary.
+9. The convergence classifications (Full/Partial/Contested/Worker-Unique), the round history data (`roundHistory[]`), the `round2SkippedReason` value, and pointers to all worker result files under `worker-results/`. The report-writer worker populates `crossVerification.roundHistory` in the data.json so Section 6 can show which rounds executed, queue sizes, and why Round 2 was (or was not) skipped. The renderer prints the full per-round table only when more than one round ran; single-round or zero-round histories are auto-collapsed to a one-line summary.
 10. `**Report Language:** <en|ko>` — must be either `en` or `ko`; `auto`
     has been resolved by the lead from project.json / global config
     before the dispatch is constructed. The worker copies this verbatim
@@ -78,9 +78,9 @@ Speculative reasons such as "session resume constraint", "team object no longer
 
 ## Phase 6 → Phase 7 execution sequence (BLOCKING order)
 
-The four steps below MUST execute in this exact order. Reordering them is the recurring root cause of reports shipping with `--` token cells (Phase 7 not run yet), Section 6 missing follow-up entries, or Section 7 rows never spawning.
+The four steps below MUST execute in this exact order. Reordering them is the recurring root cause of reports shipping with `--` token cells (Phase 7 not run yet), Section 3 missing follow-up entries, or Section 4 rows never spawning.
 
-1. **Phase 6 — Report writer worker drafts the final-report data.json** at `runs/<task-type>/reports/final-report-<task-type>-<seq>.data.json`, then invokes `scripts/okstra-render-final-report.py` to produce the sibling markdown. Token Usage cells in the data.json are `null` at this point (renderer emits `--` for nulls); Section 6 lists prioritized actions but does NOT yet include auto-spawned follow-ups (they don't exist yet).
+1. **Phase 6 — Report writer worker drafts the final-report data.json** at `runs/<task-type>/reports/final-report-<task-type>-<seq>.data.json`, then invokes `scripts/okstra-render-final-report.py` to produce the sibling markdown. Token Usage cells in the data.json are `null` at this point (renderer emits `--` for nulls); Section 3 lists prioritized actions but does NOT yet include auto-spawned follow-ups (they don't exist yet).
 2. **Phase 7 step 1 — Token-usage collector with `--substitute-data`** (BLOCKING). One invocation aggregates `leadUsage` / `workers[].usage` / `usageSummary` into team-state AND populates `tokenUsage` + `executionStatus[].totalTokens` etc. in the data.json AND re-invokes the renderer so the sibling markdown carries the real numbers. Skipping the flag ships a markdown full of `--` cells.
 
    ```bash
@@ -103,7 +103,7 @@ The four steps below MUST execute in this exact order. Reordering them is the re
    - When the report has **no** `C-*` clarification rows, the html carries no interactive forms (it would only duplicate the MD), so the renderer prints `html: skipped (...)` and writes nothing. This is the expected state for clarification-free runs — `validators/validate-report-views.py` treats "no C-* rows + no html" as a pass, not a missing artifact.
 
    Must run AFTER step 1 (so token placeholders are substituted in any rendered html) and BEFORE step 2 (so the html artifact, when generated, exists for the validator step that checks it).
-4. **Phase 7 step 2 — Follow-up task spawner** (BLOCKING when Section 7 is non-empty). Turns the report's `## 7. Follow-up Tasks (후속 작업)` rows into `tasks/<task-group>/<new-task-id>/` stubs.
+4. **Phase 7 step 2 — Follow-up task spawner** (BLOCKING when Section 4 is non-empty). Turns the report's `## 4. Follow-up Tasks (후속 작업)` rows into `tasks/<task-group>/<new-task-id>/` stubs.
 
    ```bash
    python3 scripts/okstra-spawn-followups.py \
@@ -115,11 +115,11 @@ The four steps below MUST execute in this exact order. Reordering them is the re
 
    Behaviour contract:
    - Idempotent: rows whose target dir exists are reported as `existing` and skipped. Reruns of the same parent task are safe.
-   - Rows with `autoSpawn != "yes"` are reported as `skipped` and never written; surface them in Section 6 if manual action is still needed.
+   - Rows with `autoSpawn != "yes"` are reported as `skipped` and never written; surface them in Section 3 if manual action is still needed.
    - Rows whose `origin` is `phase-continuation` are reported as `skipped (no new task dir)` and never spawn — they advance the same task-key via `/okstra-run` instead.
    - An invalid `origin`, `suggestedTaskType`, missing `title`, missing `reason`, or missing `newTaskId` exits `1`. (Schema validation in Phase 6 catches most of these before the spawner runs.)
    - **Canonical spawn rule (single source of truth):** the spawner runs when `task-type` ∈ {`implementation`, `final-verification`, `release-handoff`}, OR when `followUpTasks` is non-empty for any other task-type. For the listed task-types `followUpTasks` must be present (schema enforces the phase-continuation row for non-terminal task-types); an empty array is permitted only for `release-handoff`. Missing arrays are no-ops (exit `0`). All other references to this rule (including the Persistence Checklist) defer to this statement.
-5. **Phase 7 step 3 — Update Section 6** after the spawner. The report-writer MUST append one row per newly spawned task-key with its entry command:
+5. **Phase 7 step 3 — Update Section 3** after the spawner. The report-writer MUST append one row per newly spawned task-key with its entry command:
 
    ```
    - Follow-up: `<task-group>/<new-task-id>` — Claude Code 세션 안 `/okstra-run task-key=<task-group>/<new-task-id> task-type=<suggested>` / 별도 터미널 `scripts/okstra.sh --task-key <task-group>/<new-task-id> --task-type <suggested>`
@@ -215,16 +215,16 @@ When the run's `task-type` is `implementation-planning`, the final report MUST c
 | 5 | `Dependency` | `### Dependency / Migration Risk (의존성·마이그레이션 위험)` |
 | 6 | `Validation Checklist` | `### Validation Checklist (검증 체크리스트)` |
 | 7 | `Rollback` | `### Rollback Strategy (롤백 전략)` |
-| 8 | `User Approval Request` | Satisfied by the top-of-report `## User Approval Request (사용자 승인 게이트)` block. Do NOT recreate a `### 4.5.8 User Approval Request` body stub — the validator now fails reports that contain one. |
-| 9 | `Plan Body Verification` + `Gate result:` | `### Plan Body Verification (계획 본문 검증)` containing a `Gate result:` line — copy `templates/reports/final-report.template.md §4.5.9` verbatim. Validator checks both substrings. |
+| 8 | `User Approval Request` | Satisfied by the top-of-report `## User Approval Request (사용자 승인 게이트)` block. Do NOT recreate a `### 5.5.8 User Approval Request` body stub — the validator now fails reports that contain one. |
+| 9 | `Plan Body Verification` + `Gate result:` | `### Plan Body Verification (계획 본문 검증)` containing a `Gate result:` line — copy `templates/reports/final-report.template.md §5.5.9` verbatim. Validator checks both substrings. |
 
 The Korean translation in parentheses is optional but the English keyword is mandatory. The body of each section is written in the Report Language per the writing rules below. For non-`implementation-planning` runs, omit this entire block — these headings are NOT validator-checked for other task-types.
 
-The final-report template `templates/reports/final-report.template.md` Section 4.5 already encodes this contract — copy that block verbatim and fill in.
+The final-report template `templates/reports/final-report.template.md` Section 5.5 already encodes this contract — copy that block verbatim and fill in.
 
 ### Final-verification verdict token contract (BLOCKING)
 
-When the run's `task-type` is `final-verification`, the report's `## 2. Final Verdict` table MUST contain a `Verdict Token` row whose value is **exactly one of** the literal strings below. The `release-handoff` profile reads this row as its entry gate; any other value blocks the next phase.
+When the run's `task-type` is `final-verification`, the report's `## 7. Final Verdict` table MUST contain a `Verdict Token` row whose value is **exactly one of** the literal strings below. The `release-handoff` profile reads this row as its entry gate; any other value blocks the next phase.
 
 | # | Required substring | Meaning |
 |---|--------------------|---------|
@@ -234,15 +234,15 @@ When the run's `task-type` is `final-verification`, the report's `## 2. Final Ve
 
 For every other task-type, set the `Verdict Token` cell to `not-applicable`. Do NOT omit the row — the template renders it for all task-types and downstream tooling expects the field to exist.
 
-The final-report template `templates/reports/final-report.template.md` Section 2 already encodes this contract — copy that block verbatim and fill in.
+The final-report template `templates/reports/final-report.template.md` Section 7 already encodes this contract — copy that block verbatim and fill in.
 
 ### Release-handoff section contract (release-handoff runs only)
 
-When the run's `task-type` is `release-handoff`, the final report MUST include Section `## 4.6 Release Handoff Deliverables` with all eight sub-sections (`4.6.1` Source Verification Report, `4.6.2` Feature Branch & Working-Tree State, `4.6.3` User Selections, `4.6.4` Executed Commands, `4.6.5` Commit List, `4.6.6` Merge Conflict Probe, `4.6.7` Pull Request Outcome, `4.6.8` Routing Recommendation). Every entry is dictated by the lead's recorded git/gh command log and the user's verbatim answers to the H1/H2/H3 menu prompts. H1 choices are `local only`, `push + PR`, or `skip`; release-handoff records existing implementation commits and MUST NOT create new commits. If the user picked `skip` (H1) or `cancel` (H3), keep 4.6.3 populated but leave 4.6.4–4.6.6 explicitly empty per the template's empty-state lines.
+When the run's `task-type` is `release-handoff`, the final report MUST include Section `## 5.6 Release Handoff Deliverables` with all eight sub-sections (`5.6.1` Source Verification Report, `5.6.2` Feature Branch & Working-Tree State, `5.6.3` User Selections, `5.6.4` Executed Commands, `5.6.5` Commit List, `5.6.6` Merge Conflict Probe, `5.6.7` Pull Request Outcome, `5.6.8` Routing Recommendation). Every entry is dictated by the lead's recorded git/gh command log and the user's verbatim answers to the H1/H2/H3 menu prompts. H1 choices are `local only`, `push + PR`, or `skip`; release-handoff records existing implementation commits and MUST NOT create new commits. If the user picked `skip` (H1) or `cancel` (H3), keep 5.6.3 populated but leave 5.6.4–5.6.6 explicitly empty per the template's empty-state lines.
 
 **Single-lead authorship (release-handoff only):** release-handoff has no worker roster (no `Report writer worker`, no `Claude worker` drafter). The Claude lead authors the final-report file directly — there is no `Report writer worker` dispatch to perform in Phase 6, no resume-safe dispatch concern, and no mandatory worker-results file for a report-writer role. The rest of this skill's dispatch / resume / fallback machinery applies ONLY when `Report writer worker` is in the roster (i.e. every task-type other than `release-handoff`).
 
-The final-report template `templates/reports/final-report.template.md` Section 4.6 already encodes this contract — copy that block verbatim and fill in. For non-`release-handoff` runs, omit Section 4.6 entirely.
+The final-report template `templates/reports/final-report.template.md` Section 5.6 already encodes this contract — copy that block verbatim and fill in. For non-`release-handoff` runs, omit Section 5.6 entirely.
 
 ### Mandatory worker-results file (BLOCKING)
 
@@ -260,16 +260,16 @@ Skipping this file because "the real report is in `reports/`" is wrong. Both fil
 
 ### Main Body Section
 
-Section numbering follows `templates/reports/final-report.template.md` exactly — that file is the documentation SSOT for section names and ordering. For full body structure at authoring time, consult your run's **phase-stripped** `final-report-template.md` (the instruction-set copy of the same template, with other task-types' §4.x deliverable blocks removed); the "copy that block verbatim" references below mean the §-block as it appears in that stripped copy, not a re-read of the full source.
+Section numbering follows `templates/reports/final-report.template.md` exactly — that file is the documentation SSOT for section names and ordering. For full body structure at authoring time, consult your run's **phase-stripped** `final-report-template.md` (the instruction-set copy of the same template, with other task-types' §5.x deliverable blocks removed); the "copy that block verbatim" references below mean the §-block as it appears in that stripped copy, not a re-read of the full source.
 
-**Verdict Card (top-of-report, mandatory).** Render `## Verdict Card` between the report header and the (conditional) Approval block. Its `Verdict Token` / `Direction` / `Next Step` cells MUST byte-match the corresponding cells in `## 2. Final Verdict` and the first item of `## 6.`. Divergence is `contract-violated`.
+**Verdict Card (top-of-report, mandatory).** Render `## Verdict Card` between the report header and the (conditional) Approval block. Its `Verdict Token` / `Direction` / `Next Step` cells MUST byte-match the corresponding cells in `## 7. Final Verdict` and the first item of `## 6.`. Divergence is `contract-violated`.
 
-0. **Clarification Response Carried In** — render this `## 0.` heading ONLY when `{{CLARIFICATION_RESPONSE_RELATIVE_PATH}}` is non-empty. Walk every `C-*` row of the prior report's `## 5. Clarification Items` table, reconcile against new evidence, and record the outcome (`resolved` / `obsolete`) with citation before drafting the verdict. When no carry-in path was provided, OMIT the `## 0.` heading entirely — the validator fails an empty Section 0 stub.
+0. **Clarification Response Carried In** — render this `## 0.` heading ONLY when `{{CLARIFICATION_RESPONSE_RELATIVE_PATH}}` is non-empty. Walk every `C-*` row of the prior report's `## 1. Clarification Items` table, reconcile against new evidence, and record the outcome (`resolved` / `obsolete`) with citation before drafting the verdict. When no carry-in path was provided, OMIT the `## 0.` heading entirely — the validator fails an empty Section 0 stub.
 1. **Cross Verification Results** — 4 categories (Full / Partial / Contested / Worker-Unique) when convergence is enabled, per `okstra-convergence`. Prepend the Round History sub-table (columns: `Round | inputQueueSize | resolvedCount | carriedForwardCount | dispatches | skippedWorkers`) plus a `round2SkippedReason: <value>` note, pulled verbatim from `convergence-<task-type>-<seq>.json`. Empty contested list renders as `- 합의 미달 항목 없음.`. Convergence-disabled runs use the legacy Consensus/Differences format and omit the round table.
 2. **Final Verdict** — `Direction` ∈ `continue-investigation` / `begin-implementation` / `approve` / `reject` / `hold`. **Verdict Token** is `not-applicable` for every task-type except `final-verification` — see "Final-verification verdict token contract" below for that case.
 3. **Evidence and Detailed Analysis** — primary evidence rows (file path, line, snippet); secondary evidence / alternate interpretations. If `reference-expectations.md` lists explicit expected values, record match/gap per row.
-4. **Missing Information and Risks** — uncertain / "I don't know" items. `implementation-planning` adds §4.5 (see heading contract below); `release-handoff` adds §4.6.
-5. **Clarification Items** — single unified `C-*` table; column schema, ID convention, and rerun behaviour are owned by `_common-contract.md §Clarification request policy` (8-column SSOT). The deprecated `4.5.9 Open Questions` / `5.1 추가 자료 요청` / `5.2 사용자 확인 질문` sub-sections are removed; the validator fails reports that reintroduce them.
+4. **Missing Information and Risks** — uncertain / "I don't know" items. `implementation-planning` adds §5.5 (see heading contract below); `release-handoff` adds §5.6.
+5. **Clarification Items** — single unified `C-*` table; column schema, ID convention, and rerun behaviour are owned by `_common-contract.md §Clarification request policy` (8-column SSOT). The deprecated `5.5.9 Open Questions` / `1.1 추가 자료 요청` / `1.2 사용자 확인 질문` sub-sections are removed; the validator fails reports that reintroduce them.
 6. **Recommended Next Steps** — prioritized actions. After Phase 7's follow-up spawner runs, append a row per newly created task-key (see "Phase 6 → Phase 7 execution sequence" above).
 7. **Follow-up Tasks** — auto-spawn-eligible table. Each row drives `okstra-spawn-followups.py`; see template §7 for the row schema.
 
@@ -281,8 +281,8 @@ Section numbering follows `templates/reports/final-report.template.md` exactly
   empty-states, token summary, column headers, release-handoff labels)
   are i18n-rendered by `okstra-render-final-report.py` from
   `templates/reports/i18n/<lang>.json`; do not translate those — focus
-  on the prose you author (Section 1 categories, Section 3 evidence
-  narratives, Section 4 risks, Section 6 recommendations, etc.).
+  on the prose you author (Section 6 categories, Section 2 evidence
+  narratives, Section 5 risks, Section 3 recommendations, etc.).
   Code identifiers, file paths, model names, status tokens, and the
   validator-checked English substrings (`Option Candidates`,
   `Verdict Token`, `accepted`/`conditional-accept`/`blocked`, etc.)
@@ -296,7 +296,7 @@ Section numbering follows `templates/reports/final-report.template.md` exactly
 - Write the actual analysis text instead of a meta-description
 - Do not make unfounded assertions
 - Include findings from all four categories. Do not omit "contested" or "worker-unique" findings
-- Include the convergence round history sub-table (Section 1) so the reader can audit which rounds executed and what `round2SkippedReason` indicates (e.g. `"not-skipped"` when Round 2 ran, or one of the three skip reasons). Pull values verbatim from `convergence-<task-type>-<seq>.json`; do NOT recompute.
+- Include the convergence round history sub-table (Section 6) so the reader can audit which rounds executed and what `round2SkippedReason` indicates (e.g. `"not-skipped"` when Round 2 ran, or one of the three skip reasons). Pull values verbatim from `convergence-<task-type>-<seq>.json`; do NOT recompute.
 - For each finding, include a brief summary of votes per worker across executed rounds. `verification-error` votes are listed as such — never as `DISAGREE`.
 - The report writer worker does not participate in the re-verification vote. It is responsible only for drafting the final report
 

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

@@ -42,6 +42,7 @@ The wizard tells you *which UI to use* via `kind` (and the optional `multi` flag
 
 - `kind: "pick"` + `multi: false` (default) → render `AskUserQuestion` with `label`, `options[].label`, and `multiSelect: false`. Use the chosen `options[].value` (single string) as the answer.
 - `kind: "pick"` + `multi: true` → render `AskUserQuestion` with `label`, `options[].label`, and `multiSelect: true`. Join the chosen `options[].value` entries with `,` into a single CSV string and submit that as `--answer "csv,values"`. If the user selects nothing, still submit `--answer ""` — the wizard will reply `ok: false` and re-prompt the same step (do not skip the call).
+- `kind: "pick_group"` → render a SINGLE `AskUserQuestion` whose questions array maps 1:1 to the wizard's `questions[]`. For each entry use `questions[].label`, `questions[].options[].label`, and `multiSelect: questions[].multi`. Collect the user's chosen `options[].value` per tab, build a JSON object keyed by each `questions[].step`, and submit it as a single literal `--answer '{"lead_model":"opus","claude_model":"default",...}'`. A tab the user leaves at its default still gets its `"default"`/`""` value in the JSON. Never split a `pick_group` into multiple `AskUserQuestion` calls — the wizard already capped it at 4 tabs and emits any remainder as the next prompt.
 - `kind: "text"` → write `label` as a plain text message and consume the user's NEXT message as the answer.
 - `kind: "done"` → input collection finished; move to Step 5.
 
@@ -96,6 +97,7 @@ Repeat until `next.kind == "done"`:
 1. **Render** the prompt according to `kind` (and `multi` for pick):
    - `pick` + `multi: false` → `AskUserQuestion` with `multiSelect: false`, `label`, and `options`. The user's chosen option's `value` is the answer string.
    - `pick` + `multi: true` → `AskUserQuestion` with `multiSelect: true`, `label`, and `options`. Join the selected `value`s with `,` into a single literal CSV string (e.g. `"claude,codex,gemini"`) and submit it as a single `--answer "claude,codex,gemini"`. Empty selection submits `--answer ""` and the wizard re-prompts.
+   - `pick_group` → one `AskUserQuestion` with one question per `questions[]` entry (tab). Map each tab's selected `value` back by `questions[].step`, assemble a JSON object, and submit it as a single literal `--answer '<json>'`.
    - `text` → plain text message containing `label`. Consume the user's next reply verbatim as the answer string (empty reply = empty string).
 2. **Submit** the answer — call `okstra wizard step` with the literal state-file path from Step 2 and the literal user answer (no shell variables, no `$(...)`):
    ```bash