okstra 0.207.0 → 0.208.0

package/runtime/python/okstra_ctl/phases/implementation_option_selection/profile.md

@@ -1,14 +1,6 @@
 # Implementation Option Selection Profile
 
 - Purpose: compare feasible implementation directions before planning, preserving a read-only record of the evidence and trade-offs that selects the direction to plan
-- Required workers:
-  - claude
-  - codex
-  - antigravity
-  - report-writer
-- Optional workers (opt-in via `--workers`):
-  - grok
-  - kimi
 {{INCLUDE:_common-contract.md}}
 - Brief consumption:
   - Apply the shared reporter-confirmation precondition exactly as written. Unresolved `intent-check:` and `conversion-block:` rows use `Blocks=next-phase`.
@@ -18,6 +10,11 @@
   - In `candidate-comparison` mode only, submit at most three candidates. A candidate must be feasible from inspected evidence, not from an assumed future change.
   - In `preselected-validation` mode, receive one preselected direction from the lead and validate its evidence, counterevidence, criterion scores, and requirement mappings, and state the same feasibility verdict with its rationale and counterevidence. The worker must not generate new candidates.
   - Do not produce detailed file lists, stage maps, execution commands, or a plan approval request.
+- Census aspects:
+  - requirement mapping: Which candidate or preselected direction satisfies this requirement, and how?
+  - requirement support: Which inspected evidence supports that mapping?
+  - requirement counter-evidence: What is the strongest evidence against that mapping?
+  - task feasibility: Is each candidate feasible, not feasible, or uncertain on inspected evidence?
 - Pre-selection context exploration:
   - In `candidate-comparison` mode, inspect the code paths, interfaces, tests, and constraints needed to distinguish candidates before assigning scores.
   - In `preselected-validation` mode, inspect the code paths, interfaces, tests, and constraints needed to validate the one preselected direction.

package/runtime/python/okstra_ctl/phases/implementation_option_selection/spec.md

@@ -8,7 +8,7 @@ This directory owns candidate evaluation, vote completion, comparison projection
 |---|---|---|
 | IOS-1 | Candidate scores, coverage, votes and ranking are recomputed | `scripts/okstra_ctl/phases/implementation_option_selection/validation.py::validate_implementation_option_selection` |
 | IOS-2 | Blocked facts retain their user decision or technical evidence channel | `scripts/okstra_ctl/phases/implementation_option_selection/validation.py::validate_blocked_answer_channel` |
-| IOS-3 | Comparison requires at least three independent analysers | `scripts/okstra_ctl/phases/implementation_option_selection/entry.py::validate_analyser_roster` |
+| IOS-3 | A valid candidate needs two `feasible` votes, or the single vote when the user selected one designer | `scripts/okstra_ctl/phases/implementation_option_selection/validation.py::required_feasible_votes`; `scripts/okstra_ctl/phases/implementation_option_selection/tests/test_implementation_options.py::test_a_single_designer_vote_validates_its_candidate` |
 | IOS-4 | Candidate fingerprints deduplicate equivalent mechanisms | `scripts/okstra_ctl/phases/implementation_option_selection/tests/test_implementation_options.py::test_duplicate_candidates_share_a_fingerprint` |
 
 Report schemas remain in `schemas/final-report-v2.0.schema.json` and `schemas/final-report-v3.0.schema.json`, under `implementationOptionSelection`. Next-phase decisions belong to `prompts/lead/phase-routing.md`.
@@ -36,11 +36,11 @@ Direction confirmation and detailed plan approval are independent user decisions
 | `candidate-comparison` | Requirement ledger, cause evidence, code evidence, independently proposed raw candidates | At most three ranked valid directions and a separate user selection |
 | `preselected-validation` | A direction already fixed by upstream evidence or an explicit user instruction | One normalized and validated direction, or `blocked`; no alternative is generated |
 
-The normal analyser roster contains at least three analyser workers plus the report writer. Each analyser may propose at most three raw candidates. All analysers reassess the merged candidate set before ranking.
+The user selects one to five designers (`profile.json`, three recommended) plus the report writer. Each designer may propose at most three raw candidates. All analysers reassess the merged candidate set before ranking.
 
 ## 3. Prepare gates
 
-Prepare rejects the phase when the brief has no stable `EB-NNN`, `PB-NNN`, or `EO-NNN` requirement IDs. External Gates are not part of that denominator. Prepare also rejects a roster with fewer than three analysers.
+Prepare rejects the phase when the brief has no stable `EB-NNN`, `PB-NNN`, or `EO-NNN` requirement IDs. External Gates are not part of that denominator.
 
 The phase reuses the task-key worktree and may inspect the code and prior task artifacts. It does not obtain a writable implementation-stage worktree.
 

package/runtime/python/okstra_ctl/phases/implementation_option_selection/validation.py

@@ -224,6 +224,15 @@ def _validate_option_scores(
     return values_valid and weighted_score_valid
 
 
+def required_feasible_votes(participating_analysers: Sequence[str]) -> int:
+    """유효한 후보에 필요한 `feasible` 표 수.
+
+    사용자가 설계자를 한 명만 고르면 두 번째 표는 오지 않는다. 그때는 그 한 표가
+    전부이고, 교차 모델 검증이 없었다는 사실은 run 의 advisory 와 리포트가 알린다.
+    """
+    return min(MIN_FEASIBLE_VOTES, max(1, len(set(participating_analysers))))
+
+
 def _validate_option_feasibility(
     option: Mapping[str, object],
     participating_analysers: Sequence[str],
@@ -246,8 +255,9 @@ def _validate_option_feasibility(
         isinstance(vote, Mapping) and vote.get("verdict") == "feasible"
         for vote in votes
     )
-    if require_valid and feasible < MIN_FEASIBLE_VOTES:
-        errors.append(f"{option_id} must have at least two feasible votes")
+    required = required_feasible_votes(participating_analysers)
+    if require_valid and feasible < required:
+        errors.append(f"{option_id} must have at least {required} feasible vote(s)")
     if require_valid and option.get("safetyBlockers"):
         errors.append(f"{option_id} safetyBlockers must be empty")
     if require_valid and option.get("unresolvedFeasibilityFacts"):
@@ -260,7 +270,7 @@ def _validate_option_feasibility(
         )
     return (
         all_participated
-        and feasible >= MIN_FEASIBLE_VOTES
+        and feasible >= required
         and not option.get("safetyBlockers")
         and not option.get("unresolvedFeasibilityFacts")
         and not copied
@@ -394,7 +404,7 @@ def vote_gaps(
     여기서 세는 것은 **표만 모자란** 후보다. `safetyBlockers` 나
     `unresolvedFeasibilityFacts` 가 있거나 베낀 표가 있으면 표를 더 받아도
     유효해지지 않으므로 제외한다. 남은 표를 다 받아도 `feasible` 이
-    `MIN_FEASIBLE_VOTES` 에 못 미치는 후보도 제외한다 — 부쳐 봐야 결과가
+    `required_feasible_votes` 에 못 미치는 후보도 제외한다 — 부쳐 봐야 결과가
     같다.
     """
     roster = list(dict.fromkeys(str(name) for name in participating_analysers))
@@ -422,7 +432,7 @@ def vote_gaps(
             isinstance(vote, Mapping) and vote.get("verdict") == "feasible"
             for vote in votes
         )
-        if feasible + len(missing) < MIN_FEASIBLE_VOTES:
+        if feasible + len(missing) < required_feasible_votes(roster):
             continue
         gaps.append(
             VoteGap(

package/runtime/python/okstra_ctl/phases/implementation_planning/authoring.py

@@ -1377,7 +1377,8 @@ def _seed(args: argparse.Namespace) -> dict[str, Any]:
 
     Idempotent by id. An existing row keeps everything it carries — verdicts
     already applied, `carriedForwardFromSeq`, `selfFixNote` — because a re-seed
-    between rounds must not erase the round before it.
+    between rounds must not erase the round before it. `contentHash` and
+    `stageScope` are re-derived from the current plan.
 
     `--prior-state` extends that to the previous *run*: a newly seeded item
     whose text the previous run already judged inherits its verdicts instead of
@@ -1415,10 +1416,17 @@ def _seed(args: argparse.Namespace) -> dict[str, Any]:
     ]
     carried = _carry_prior_run_verdicts(args, added, hashes)
     recorded.extend(added)
+    scopes = {item["id"]: item.get("stageScope") for item in extracted}
     for row in recorded:
         item_id = row.get("id") if isinstance(row, Mapping) else None
         if isinstance(item_id, str) and item_id in hashes:
             row["contentHash"] = hashes[item_id]
+            # 큐는 추출값으로, 게이트는 이 행으로 범위를 정한다. 행의 범위가 낡으면
+            # 재검증 큐에서 빠진 항목이 게이트를 계속 막는다(2026-10-04 dev-11118 P-Val-5).
+            if scopes[item_id]:
+                row["stageScope"] = scopes[item_id]
+            else:
+                row.pop("stageScope", None)
     if args.state is not None:
         audit_rows = data.get("planItems")
         if not isinstance(audit_rows, list):

package/runtime/python/okstra_ctl/phases/implementation_planning/boundary.json

@@ -5,7 +5,7 @@
     "file writes outside the run`s artifact directories (`reports/`, `prompts/`, `state/`, `manifests/`, `worker-results/`, `status/`, `sessions/`), including task-root QA scripts, manifest, and tsconfig (planning declares conformance commands and required dependencies; implementation writes these files); in particular, do not write to `docs/superpowers/specs/` or `docs/superpowers/plans/`",
     "executing builds, migrations, deployments, or any state-mutating command",
     "starting `implementation` inside this run (must be a separate run authorised by an approved deliverable from this phase), even if the user says \"다음 단계 진행해\"",
-    "dispatching parallel sub-agents beyond the required worker roster (okstra owns worker fan-out)",
+    "dispatching parallel sub-agents beyond the run's selected roster (okstra owns worker fan-out)",
     "leaving placeholders such as TBD / TODO / \"handle edge cases\" / \"similar to Option N\" in the report",
     "delegating the self-review pass — the Okstra lead must run it"
   ]

package/runtime/python/okstra_ctl/phases/implementation_planning/instructions/plan-body-verification.md

@@ -55,7 +55,9 @@ Plan-body verification is configured under `convergence.planBodyVerification` in
 
 Default values are emitted into the manifest by `scripts/okstra_ctl/render.py` (`_build_convergence_block`). The ctx knob `OKSTRA_PLAN_VERIFICATION=false` flips `planBodyVerification.enabled` to false. `gating=false` is not that opt-out: extraction and one round still run.
 
-The shared Majority definition and the auto-disable rule (fewer than 2 analyser workers → advisory `gating=false` path) are owned by `prompts/lead/convergence.md` §"Convergence Algorithm" / §"Configuration" and apply here unchanged.
+The shared Majority definition is owned by `prompts/lead/convergence.md` §"Convergence Algorithm" / §"Configuration" and applies here unchanged.
+
+**A one-analyser roster.** When the user selected one planner, no second vote can arrive, so that planner's vote is the panel: a non-error `DISAGREE` settles its item on that vote instead of returning `needs-reverify`, and the round closes on the gate it scored. The run carries a `no cross-model check` advisory. **Enforced:** `scripts/okstra_ctl/phases/implementation_planning/plan_body.py` `_classify_plan_item_gate` lowers its quorum to one when `planBodyVerification.participatingAnalysers.rostered` is 1.
 
 ## Plan-item extraction (Round 0 equivalent)
 
@@ -456,7 +458,7 @@ For contract 3.0, `prepare` checks the selected-direction draft with the same se
 
    The environment exception in §"Planning-time environment gap" covers **running build and test commands only** — whether a referenced path exists, whether a command is declared in `package.json`, and whether the plan is internally consistent are all checkable without it, and a blanket "capability constraints prevent workspace resolution" is not a valid answer to any of them.
 
-   **How the corrective round is recorded.** The first prompt was dispatched, so it is immutable — `--replace-undispatched` refuses it, correctly. Materialize the correction under a NEW `--invocation-id` and a new prompt path. Before linking its result, retire the first attempt's link: `okstra agent-prompt reject-result --project-root <dir> --run-manifest <path> --dispatch-id <first dispatch id> --superseded-by <corrective dispatch id> --reason "<what was wrong with the returned result>"`. Without that step the corrective `link-result` fails with `agent result is already linked to another dispatch`, which is how a worker that ran for twenty minutes and wrote a good result ends up unrecordable. Nothing is deleted: the rejected link stays in `agentResultLinks` carrying `supersededBy` and `rejectionReason`, so the ledger shows both attempts and why the second exists.
+   **How the corrective round is recorded.** The first prompt was dispatched, so it is immutable — `--replace-undispatched` refuses it, correctly. Materialize the correction under a NEW `--invocation-id` and a new prompt path. Before linking its result, retire the first attempt's link: `okstra agent-prompt reject-result --project-root <dir> --run-manifest <path> --dispatch-id <first dispatch id> --superseded-by <corrective dispatch id> --reason "<what was wrong with the returned result>"`. Without that step the corrective `link-result` fails with `agent result is already linked to another dispatch`, which is how a worker that ran for twenty minutes and wrote a good result ends up unrecordable. Run it only when the first attempt has a link: a team dispatch links a result only when its attempt settles `completed`, so an attempt that ended in `error` has none, and `reject-result` then fails with `expected exactly one agent result link … found 0` — skip the step in that case. Nothing is deleted: the rejected link stays in `agentResultLinks` carrying `supersededBy` and `rejectionReason`, so the ledger shows both attempts and why the second exists.
 
    Then run `okstra plan-items complete-round --state <plan-body-verification.json> --run-manifest <current-run-manifest.json> --round <N>`. Python appends one immutable round history entry, records each verified item's votes, derives the current projection from the actual assigned roster, and stamps `completedAt` after the preceding verification command succeeds. The file accumulates across rounds; it is never truncated to the latest one. Report assembly later projects the completed nested `planBodyVerification` into the final record.
 7. **Self-fix loop (one rewrite, targeting planner-fixable defects).** After the initial verification, lead may run one report-writer rewrite when a `majority-disagree` item has a majority of `DISAGREE` verdicts at `fixability == planner-fixable`. Re-verify changed items once, preserving verdicts on unchanged content. Then stop automatic self-fix regardless of outcome and follow step 8. The fixed order is initial verification → one planner self-fix → targeted re-verification → lead decision or immediate user confirmation. A second automatic self-fix is rejected by `plan_items_cli._record_self_fixes`; `_validate_self_fix_grouping` and session activity validation detect multiple recorded rewrites. No rewrite is needed when no item qualifies.

package/runtime/python/okstra_ctl/phases/implementation_planning/plan_body.py

@@ -207,7 +207,13 @@ def _critic_gate_class(item: dict) -> str | None:
     return "has-dissent" if dissent else "full-consensus"
 
 
-def _classify_plan_item_gate(item: dict) -> str:
+def _rostered_analysers(pbv: dict) -> int | None:
+    declared = pbv.get("participatingAnalysers")
+    rostered = declared.get("rostered") if isinstance(declared, dict) else None
+    return rostered if isinstance(rostered, int) else None
+
+
+def _classify_plan_item_gate(item: dict, *, rostered_analysers: int | None = None) -> str:
     """Recompute one plan item's gate class from its per-worker verdicts,
     per `prompts/lead/plan-body-verification.md` "Round protocol". Returns one of
     ``majority-disagree`` / ``needs-reverify`` / ``has-dissent`` /
@@ -216,7 +222,8 @@ def _classify_plan_item_gate(item: dict) -> str:
     ``majority-disagree`` so the user gate sees it. ``has-dissent`` remains
     advisory-only, rollback items, and a single-vote kind that lost its
     reproduction. An analyser 1-1 is ``needs-reverify`` until ``critic-worker``
-    settles it.
+    settles it. With a one-analyser roster the single vote is the panel: no
+    peer can ever vote, so waiting for one would stall the round.
     """
     corrected = _critic_gate_class(item)
     if corrected is not None:
@@ -253,6 +260,7 @@ def _classify_plan_item_gate(item: dict) -> str:
     if not blocking_disagree:
         return "has-dissent"
     blocking_kinds = {bk for (_vd, bk) in blocking_disagree if bk}
+    quorum = 1 if rostered_analysers == 1 else 2
     # Single-vote-blocking kinds: one confirmed DISAGREE on a concrete,
     # safety-critical, adversarially-verifiable defect is enough to block, even
     # in a two-worker roster — a lone correct dissent must not be outvoted here.
@@ -270,19 +278,19 @@ def _classify_plan_item_gate(item: dict) -> str:
         # the dissent, so blocking here would reproduce the same
         # worker-failure-makes-the-gate-stricter paradox the majority branch
         # below guards against. Route it to a re-verify round instead.
-        if len(non_error) < 2:
+        if len(non_error) < quorum:
             return "needs-reverify"
         return "majority-disagree"
     # Otherwise a genuine majority is required — and a majority needs at least
     # two participating votes, so a lone surviving DISAGREE (its peer returned a
     # non-result) does NOT block. That fixes the paradox where a worker failure
     # made the gate stricter than a healthy roster would.
-    if len(non_error) >= 2 and len(blocking_disagree) > len(agree):
+    if len(non_error) >= quorum and len(blocking_disagree) > len(agree):
         return "majority-disagree"
     if len(blocking_disagree) == len(agree) and len(non_error) >= 2:
         return "needs-reverify"
     if (
-        len(non_error) >= 2
+        len(non_error) >= quorum
         and blocking_disagree
         and (not (blocking_kinds & single_vote_kinds) or _is_variation_point_item(item))
     ):
@@ -486,7 +494,9 @@ def _resolved_noncritical_dissent_ids(data: dict) -> set[str]:
 
 def _plan_item_decision_authority(item: dict, pbv: dict) -> str | None:
     """자동 수정 이후의 설계 판단만 리드가 결정하며 사실·사용자 권한은 남긴다."""
-    classification = _classify_plan_item_gate(item)
+    classification = _classify_plan_item_gate(
+        item, rostered_analysers=_rostered_analysers(pbv)
+    )
     votes = [row for row in item.get("verdicts", []) if isinstance(row, dict)]
     non_result = any(
         row.get("verdict") not in {"AGREE", "SUPPLEMENT", "DISAGREE"} for row in votes
@@ -537,7 +547,9 @@ def _is_dissent_downgraded(
 ) -> bool:
     """유효한 리드 결정 또는 사용자 진행 처분은 반대 표를 보존하며 차단을 해소한다."""
     return _lead_decision_applies(item, pbv) or (
-        _classify_plan_item_gate(item) == "majority-disagree"
+        _classify_plan_item_gate(
+            item, rostered_analysers=_rostered_analysers(pbv)
+        ) == "majority-disagree"
         and str(item.get("id") or "") in accepted_item_ids
     )
 
@@ -582,7 +594,9 @@ def _set_aside_reason(item: dict, pbv: dict, accepted_item_ids: set[str]) -> str
     raw = (
         "has-dissent"
         if _is_dissent_downgraded(item, pbv, accepted_item_ids)
-        else _classify_plan_item_gate(item)
+        else _classify_plan_item_gate(
+            item, rostered_analysers=_rostered_analysers(pbv)
+        )
     )
     if raw != "majority-disagree":
         return None
@@ -619,7 +633,9 @@ def _plan_item_gate_class(
     classification = (
         "has-dissent"
         if _is_dissent_downgraded(item, pbv, accepted_item_ids)
-        else _classify_plan_item_gate(item)
+        else _classify_plan_item_gate(
+            item, rostered_analysers=_rostered_analysers(pbv)
+        )
     )
     if classification != "majority-disagree":
         return classification

package/runtime/python/okstra_ctl/phases/implementation_planning/profile.json

@@ -6,7 +6,7 @@
       "mode": "static",
       "roleId": "planner",
       "dutyId": "planning-worker",
-      "min": 2,
+      "min": 1,
       "recommended": 2,
       "max": 5
     },

package/runtime/python/okstra_ctl/phases/implementation_planning/profile.md

@@ -7,14 +7,6 @@ Validation commands are executable inputs: preserve their newlines, quotes, and
 Plan for the actual worktree layout before approval. Shared documentation directories can be links to the main checkout. Choose a build command compatible with those links (for example, an installed Next.js version may provide `next build --webpack`); verify the available option rather than assuming it. Do not plan for a verifier to move links or repair its environment. Compare negative-case assertions with the brief and the script body: a requirement to cache existing assets does not establish that missing assets should be cached. Record any changed expectation in a new plan revision; preserve the earlier approved plan.
 
 - Purpose: turn an upstream-selected direction into an executable plan; legacy reruns may retain candidate comparison
-- Required workers:
-  - claude
-  - codex
-  - report-writer
-- Optional workers (opt-in via `--workers`):
-  - antigravity — when added to the roster it joins the analyser set; omitted by default
-  - grok — optional adversarial analyser/critic through the Grok CLI wrapper
-  - kimi — optional long-context analyser/critic through the Kimi CLI wrapper
 {{INCLUDE:_common-contract.md}}
 {{INCLUDE:_stage-discipline.md}}
 - Brief consumption (phase-specific addendum — shared rules live in `_common-contract.md` under "Brief handoff contract"):
@@ -32,6 +24,11 @@ Plan for the actual worktree layout before approval. Shared documentation direct
     4. If current evidence requires changing the selected direction, emit `direction-invalidated` and stop planning.
   - identify requirement gaps and affected interfaces with file:line evidence, resolving codebase-answerable ambiguity before returning findings
   - surface migration, deployment, cross-project, and approval risks without drafting final-report headings or schema rows
+- Census aspects:
+  - requirement plan-linkage: Which planned files and stages realize this requirement?
+  - requirement interface-impact: Which interfaces does realizing this requirement change, and who calls them?
+  - requirement validation: Which validation step proves this requirement once the plan is executed?
+  - task migration-deploy-approval-risk: Which migration, deployment, cross-project, or approval risk does the plan carry?
 - Legacy candidate-comparison-only responsibilities:
   - **Legacy candidate-comparison procedure** — only a legacy rerun without `selected-direction.json` compares feasible Option Candidates, preserves their trade-offs and Recommended Option, then produces stages, validation, rollback, and requirement coverage. This is the only branch that generates candidates, assigns candidate scores, recommends a direction, or awaits a user candidate choice.
   - **Spec-settled short-circuit** — when the brief already carries a decision-complete design the reporter has confirmed, do not re-litigate it. Preserve that design as the Recommended Option and its already-weighed alternatives as the remaining Option Candidates.
@@ -95,7 +92,7 @@ Plan for the actual worktree layout before approval. Shared documentation direct
   - **source code edits of any kind** — this run produces a plan document only; Edit/Write on project source files is forbidden until the plan is approved and a separate `implementation` run starts
   - executing builds, migrations, deployments, or any command that mutates project state outside the run's own artifact directories (`reports/`, `prompts/`, `state/`, `manifests/`, `worker-results/`, `status/`, `sessions/`)
   - this run stays in `implementation-planning` regardless of user phrasing — the shared anti-escalation rule applies
-  - dispatching parallel sub-agents beyond the required worker roster — okstra owns worker fan-out
+  - dispatching parallel sub-agents beyond the run's selected roster — okstra owns worker fan-out
   - writing artifacts anywhere except `<PROJECT_ROOT>/.okstra/` — the run's `reports/` directory is the canonical location for this phase
 - Clarification request policy (phase-specific addenda — shared policy is in `_common-contract.md`):
 {{INCLUDE:_clarification-recommendation.md}}
@@ -293,7 +290,7 @@ For a new `implementation-planning` run, the fixed order is initial verification
    ```
 
    An `AGREE` response records the considered counterexample and exclusion reason in its note; unverified external material is `verification-error`, not `DISAGREE`.
-2. Dispatch a single plan-body reverify round to every analyser worker in the roster (`claude`, `codex`, and `antigravity` when opted in). `Report writer worker` is NOT a participant in this round.
+2. Dispatch a single plan-body reverify round to every analyser worker in the run's roster. `Report writer worker` is NOT a participant in this round.
 3. Record each verifier Markdown result through `okstra plan-items apply-verdicts --state <plan-body-verification.json> --result <worker-id>=<result.md> --round <N>`. Python validates every submitted `P-*` identifier against the current convergence state and overwrites only that round's verdicts. Then resolve the gate result to one of `passed` / `passed-with-dissent` / `blocked-by-disagreement` / `aborted-non-result`.
 4. After `okstra plan-verify` succeeds, run `okstra plan-items complete-round --state <plan-body-verification.json> --run-manifest <current-run-manifest.json> --round <N>`. Python reads the current worker assignments, atomically appends the convergence-owned history, and updates its nested final projection. This state is the only plan-verification input report assembly reads.
 5. Record every *in-scope execution* `majority-disagree` decision through `okstra approval-decision`; record its plan and clarification links only on activities. Do not promote `observed` / `deferred` / `record` items, and do not append `clarificationItems[]` directly.

package/runtime/python/okstra_ctl/phases/improvement_discovery/profile.json

@@ -6,7 +6,7 @@
       "mode": "static",
       "roleId": "analyser",
       "dutyId": "discovery-worker",
-      "min": 3,
+      "min": 1,
       "recommended": 3,
       "max": 5
     },

package/runtime/python/okstra_ctl/phases/improvement_discovery/profile.md

@@ -1,15 +1,6 @@
 # Improvement Discovery Profile
 
 - Purpose: scan a codebase scope through a fixed lens whitelist and surface ranked improvement candidates with multi-worker consensus classification
-- Required workers:
-  - claude
-  - codex
-  - antigravity
-  - report-writer
-- Optional workers (opt-in via `--workers`):
-  - grok — optional adversarial analyser/critic through the Grok CLI wrapper
-  - kimi — optional long-context analyser/critic through the Kimi CLI wrapper
-- Roster guidance: the required block plus these opt-in providers form the full allowlist. As everywhere, `--workers` may narrow within it (`okstra_ctl.workers.validate_workers_against_profile` enforces the allowlist only, minimum 1), but narrowing this phase is strongly discouraged: cross-worker lens diversity is its load-bearing value, and a reduced roster produces candidates no second worker ever challenged.
 {{INCLUDE:_common-contract.md}}
 - Brief consumption (phase-specific addendum — shared rules live in `_common-contract.md` under "Brief handoff contract"):
   - this phase REQUIRES a codebase-scan brief whose frontmatter contains `scope: codebase`. A brief without that marker is rejected before worker dispatch.
@@ -29,18 +20,20 @@
   - for every candidate, record lens, scope, severity, effort, recommended next phase, evidence, and a worker-local source item ID
   - identify overlap with other findings or linked tasks as duplicate, broader/narrower, conflicting, blocked-by, or follow-up instead of silently merging it
 - Worker diversity rule:
-  - every analyser inspects every resolved priority lens. The Phase 1.5 grilling log assigns only the first pass: enumerate selected analyser worker instances in `requiredWorkerRoles` order and rotate them over resolved priority lenses in log order. Provider/model names never determine the position.
+  - every analyser inspects every resolved priority lens. The Phase 1.5 grilling log assigns only the first pass: enumerate selected analyser worker instances in `workerRoles` order and rotate them over resolved priority lenses in log order. Provider/model names never determine the position.
   - each worker, before broadening to the remaining lenses, must do one of: (a) produce at least one candidate from its primary pass, or (b) record a no-candidate rationale citing the highest-signal path:line evidence it inspected.
   - two workers' candidates are the same candidate only when they cite the same underlying design/code problem and the same remediation direction. Shared evidence paths alone are not enough to merge; keep distinct failure modes distinct.
   - when a candidate from one worker overlaps another worker's evidence, convergence must classify the relationship as one of: duplicate, broader/narrower, or conflicting. Do not collapse contested candidates just to meet the candidate cap.
   - when a candidate overlaps a brief `Related Task Graph` edge, convergence must classify whether the candidate is a duplicate of, blocked by, or follow-up to the linked task. Do not assign a new task-key without carrying the linked task reference into Recommended Next Steps.
+- Census aspects:
+  - lens lens-review: Which improvement candidate, or which no-candidate rationale with path:line evidence, does this lens yield inside the scan scope?
 - Phase 1.5 — Lead reflect-back grilling (runs after Phase 1 context loading and before Phase 4 worker dispatch):
   - Lead inspects scan-scope paths via `ls` / `Grep` / `Read` to map modules, entry points, dependencies, and approximate LOC, and reviews recent git history to note which scan-scope files change most.
   - Lead emits a single reflect-back message covering: (a) understood scope per path (one-line summary), (b) understood meaning of each priority lens in this scope, (c) understood out-of-scope rationale, (d) ordered list of N open questions.
   - For each open question Lead asks ONE `AskUserQuestion` with a `(Recommended)` answer drawn from a codebase-first inspection. Budget: at most 12 questions in this phase.
   - Stop conditions (OR): all questions resolved / budget exhausted / user signals proceed.
   - Lead persists the round at `<RUN_DIR>/state/phase-1.5-grilling.md` with one section per question (question / recommended / user answer) and a closing `Resolved scope` / `Resolved lenses` block. Worker prompts use this resolved block as the authoritative scope and lens definition.
-  - The same log includes `## Primary Pass Assignments` with a `Worker ID | Primary lens` table. It contains every selected analyser exactly once in `requiredWorkerRoles` order; the lead derives it from the resolved roster and lenses rather than provider catalog order.
+  - The same log includes `## Primary Pass Assignments` with a `Worker ID | Primary lens` table. It contains every selected analyser exactly once in `workerRoles` order; the lead derives it from the resolved roster and lenses rather than provider catalog order.
   - After writing the log and before Phase 4 dispatch, the lead injects its **absolute path** into every analyser prompt as the `**Phase 1.5 Grilling Log:** <absolute-path>` anchor header (see `okstra_ctl.worker_prompt_headers.worker_prompt_headers()`). This is the improvement-discovery counterpart to the `**Worktree:**` / `**Verification …:**` anchors that implementation / final-verification inject: workers read the log from this explicit path rather than re-deriving `<RUN_DIR>`. The path is byte-identical across all analysers, so it does not break the dispatch-prompt invariant.
 - Decision-tree walk (bounded):
   - When candidates branch on a structural question (e.g. "is module X meant to own this responsibility?"), resolve via `Read` / `Grep` first. Only escalate to the user inside the Phase 1.5 budget.

package/runtime/python/okstra_ctl/phases/project_analysis/profile.json

@@ -6,7 +6,7 @@
       "mode": "static",
       "roleId": "analyser",
       "dutyId": "analysis-worker",
-      "min": 2,
+      "min": 1,
       "recommended": 3,
       "max": 5
     },

package/runtime/python/okstra_ctl/phases/project_analysis/profile.md

@@ -1,14 +1,6 @@
 # Project Analysis Profile
 
 - Purpose: map a bounded project area so later work can navigate components, dependencies, entry points, repositories, and external integrations without changing the source
-- Required workers:
-  - claude
-  - codex
-  - report-writer
-- Optional workers (opt-in via `--workers`):
-  - antigravity
-  - grok — optional adversarial analyser/critic through the Grok CLI wrapper
-  - kimi — optional long-context analyser/critic through the Kimi CLI wrapper
 {{INCLUDE:_common-contract.md}}
 - Phase 1.5 questions:
   - Which repositories, directories, and external systems are inside the scan scope?

package/runtime/python/okstra_ctl/phases/release_handoff/profile.md

@@ -5,7 +5,7 @@
   shipped and in what order their PRs must be merged — the branch names do not say.
 - Purpose: take a release-ready single-stage final-verification verdict for each already-committed implementation stage and turn it into a delivered push and/or pull request, with explicit user selection at every mutating step. **One stage is one PR.** The PR head is that stage's stack branch (`<prefix>-<task-id>-s<N>`); nothing is squashed, rebased, or collected into a bundle branch.
 - **Execution model: single-lead, no worker dispatch.** This phase is a thin orchestrator over `git` / `gh`; it does NOT dispatch teammates, does NOT dispatch analysis or drafter sub-agents, and does NOT run convergence. The host-native Okstra lead performs every step inline (drafting PR text, asking the user, running git / gh, writing the final report) — see "Lead-only contract" below.
-- Worker roster: none — this profile intentionally has no `- Required workers:` block; the run is executed entirely by the Okstra lead.
+- Worker roster: none — `profile.json` declares no roles; the run is executed entirely by the Okstra lead.
 - Lead-only contract (replaces the shared team contract for this phase):
   - The host-native Okstra lead is the sole agent for this run. No worker dispatch, no teammates, no parallel sub-agents, no convergence loop. Do NOT run `okstra convergence` in any form: prepare already wrote this run's convergence state as "not run — fewer than two analysers", which is the record report assembly reads. **Enforced:** `okstra_ctl.render._initialize_lead_only_convergence` writes it when the run has no analysers, and leaves an existing state alone.
   - The lead drafts each stage's PR title and PR body **inline** by reading the run brief, that stage's cited final-verification report, `git log --oneline <stage base>..<stage head>`, and `git diff <stage base>..<stage head> --stat`. No drafter worker is dispatched.

package/runtime/python/okstra_ctl/phases/release_handoff/spec.md

@@ -79,7 +79,7 @@ sequenceDiagram
     P-->>W: lead prompt for current session
 ```
 
-The profile has no `Required workers:` block, and `run.py` also empties the worker override for `release-handoff`. So not going through the general TeamCreate / convergence / report-writer flow of `prompts/lead/okstra-lead-contract.md` is the intended behavior.
+`profile.json` declares no roles, so prepare resolves an empty roster for `release-handoff`. So not going through the general TeamCreate / convergence / report-writer flow of `prompts/lead/okstra-lead-contract.md` is the intended behavior.
 
 ## 4. entry gate
 

package/runtime/python/okstra_ctl/phases/requirements_discovery/profile.json

@@ -6,7 +6,7 @@
       "mode": "static",
       "roleId": "analyser",
       "dutyId": "discovery-worker",
-      "min": 2,
+      "min": 1,
       "recommended": 3,
       "max": 5
     },

package/runtime/python/okstra_ctl/phases/requirements_discovery/profile.md

@@ -1,14 +1,6 @@
 # Requirements Discovery Profile
 
 - Purpose: classify the work request, identify missing requirement evidence, and route the task to the safest next lifecycle phase before implementation starts
-- Required workers:
-  - claude
-  - codex
-  - report-writer
-- Optional workers (opt-in via `--workers`):
-  - antigravity — when added to the roster it joins the analyser set; omitted by default
-  - grok — optional adversarial analyser/critic through the Grok CLI wrapper
-  - kimi — optional long-context analyser/critic through the Kimi CLI wrapper
 {{INCLUDE:_common-contract.md}}
 - Brief consumption (phase-specific addendum — shared rules live in `_common-contract.md` under "Brief handoff contract"):
   - Apply the shared reporter-confirmation precondition exactly as written. In this phase, unresolved `intent-check:` / `conversion-block:` rows use `Blocks=next-phase`.
@@ -22,6 +14,16 @@
   - identify independently startable decomposition candidates without publishing or rendering fan-out artifacts; preserve every directed dependency from `Related Task Graph`
   - resolve codebase-answerable ambiguity by inspection and record file:line evidence; return only human-owned decisions as clarification candidates with the evidence already checked
   - state the reporter's rejection criteria, missing routing inputs, and the evidence boundary behind each recommendation
+- Census aspects:
+  - requirement interpretation: What does this requirement ask for, read against the brief and the code it touches?
+  - requirement scope-boundary: Where does this requirement stop, and which nearby behaviour does it leave out?
+  - requirement dependency: What must exist or happen first for this requirement, in code or in a related task?
+  - requirement verification-method: How would a later phase observe that this requirement is met?
+  - requirement human-decision: Does this requirement need a decision only a person can make? Name it, or cite the code that settles it.
+  - task classification: Which work category (bugfix, feature, improvement, refactor, ops) does the evidence support?
+  - task rejection-criteria: Which delivered outcome would the reporter reject?
+  - task missing-materials: Which missing material blocks reliable routing?
+  - task terminology: Which fuzzy or overloaded terms need one canonical form, and what decides it?
 - Primary focus areas:
   - classify the work as bugfix, feature, improvement, refactor, or ops
   - capture the reporter's **rejection criteria** — the delivered outcome that would make this work wrong or unacceptable — as a routing input. Consume it from the brief's `Desired Outcome` / `Out of Scope` / `Source Material` when present; when it is absent AND it would change the classification (e.g. bugfix vs feature) or the next-phase choice, raise it as one `decision` clarification row with `Evidence checked: none — reporter intent`. Never infer it — this is a reporter-intent signal, the mirror of improvement-discovery's `Anti-goals`

package/runtime/python/okstra_ctl/phases/requirements_discovery/spec.md

@@ -64,10 +64,10 @@ sequenceDiagram
     participant Git as worktree registry
     participant FS as task artifacts
 
-    W->>P: task-type=requirements-discovery, brief, base-ref, workers
-    P->>Prof: profile exists, Required workers parsed
+    W->>P: task-type=requirements-discovery, brief, base-ref, role selection
+    P->>Prof: profile.json role requirements loaded
     P->>P: verify installation, upsert project.json
-    P->>P: resolve workers from profile + override
+    P->>P: resolve role assignments from selection + model defaults
     P->>Git: create or reuse task worktree
     P->>P: expand _common-contract include
     P->>FS: write instruction-set and manifests

package/runtime/python/okstra_ctl/phases/technical_verification/profile.json

@@ -6,7 +6,7 @@
       "mode": "static",
       "roleId": "analyser",
       "dutyId": "technical-verification-worker",
-      "min": 2,
+      "min": 1,
       "recommended": 2,
       "max": 5
     },

package/runtime/python/okstra_ctl/phases/technical_verification/profile.md

@@ -1,10 +1,6 @@
 # Technical Verification Profile
 
 - Purpose: collect experimental evidence for unresolved technical facts before a new implementation comparison.
-- Required workers:
-  - claude
-  - codex
-  - report-writer
 {{INCLUDE:_common-contract.md}}
 
 ## Input and experiment procedure

package/runtime/python/okstra_ctl/plan_items.py

@@ -701,7 +701,7 @@ def critic_is_rostered(run_manifest: Mapping[str, Any]) -> bool:
     """이 run 이 critic 슬롯을 실제로 배정했는가.
 
     정본은 `invocationAssignments` 다 — run 이 해소한 critic 을 적는 곳이고
-    (`okstra_ctl.render._optional_worker_roles`), `critic/*` 항목이 없으면
+    (`okstra_ctl.render._critic_role_rows`), `critic/*` 항목이 없으면
     critic 이 없다. `workerAssignments` 로는 판정할 수 없다: critic 은 분석
     워커 로스터에서 제외되므로(`okstra_ctl.run._analysis_worker_rows`)
     rostered 여부와 무관하게 그 배열에 나타나지 않는다.