okstra 0.174.0 → 0.176.0

package/runtime/python/okstra_ctl/workflow.py

@@ -1,8 +1,11 @@
 """Phase / workflow state computation.
 
-bash `compute_workflow_render_context` + `default_next_phase_for_task_type` 의
-python 구현. (task-type, current task/run status, render-only flag) 만 받아서
-WORKFLOW_* 필드 dict 를 돌려준다.
+bash `compute_workflow_render_context` 의 python 구현. (task-type, current
+task/run status, render-only flag) 만 받아서 WORKFLOW_* 필드 dict 를 돌려준다.
+
+다음 phase 는 이 모듈이 계산하지 않는다. 포인터의 shape·승격·투영은
+`okstra_ctl.next_phase` 하나가 소유하고, 값은 리포트가 저작한 라우팅에서
+투영된다.
 
 task-type 별 PHASE_ALLOWED_OUTPUTS 본문 매핑은 모듈 상수(`PHASE_RULES`)로 보유하고,
 PHASE_FORBIDDEN_ACTIONS 는 `prompts/profiles/forbidden-actions.json` SSOT 에서 로드한다.
@@ -12,8 +15,6 @@ from __future__ import annotations
 import json
 from pathlib import Path
 
-from okstra_ctl.analysis_inputs import ANALYSIS_TASK_TYPES
-
 PHASE_SEQUENCE = [
     "requirements-discovery",
     "error-analysis",
@@ -33,22 +34,6 @@ ERROR_ANALYSIS_ROUTING_DIRECTIONS = {
     "implementation-option-selection": "begin-option-selection",
 }
 
-DEFAULT_NEXT_PHASE = {
-    "requirements-discovery": "implementation-option-selection",
-    "improvement-discovery": "pending-routing-decision",
-    **{task_type: "pending-routing-decision" for task_type in ANALYSIS_TASK_TYPES},
-    "error-analysis": "implementation-option-selection",
-    "implementation-option-selection": "implementation-planning",
-    "implementation-planning": "implementation",
-    "implementation": "final-verification",
-    # final-verification 의 다음 단계는 verdict 에 따라 갈리므로 정적 매핑은
-    # `pending-release-handoff` 로 둔다 (accepted 일 때만 release-handoff 로
-    # 진입; 그 외에는 error-analysis / implementation-option-selection /
-    # implementation-planning 으로 리라우팅).
-    "final-verification": "pending-release-handoff",
-    "release-handoff": "done-or-follow-up",
-}
-
 # Phase 별 allowed outputs. bash heredoc 원문 그대로 옮긴 값 — 들여쓰기와 백틱은
 # prompt template 에 그대로 박혀 lead 가 읽는다. forbidden actions 는 이 dict 가
 # 아니라 prompts/profiles/forbidden-actions.json (load_phase_forbidden) 이 SSOT.
@@ -56,7 +41,7 @@ PHASE_RULES: dict[str, dict[str, str]] = {
     "requirements-discovery": {
         "allowed": (
             "  - work-category classification (bugfix / feature / refactor / ops / improvement)\n"
-            "  - routing decision toward the next safe lifecycle phase\n"
+            "  - routing decision as the `routing` object `{nextTaskType, readyWhen, rationale}`: `nextTaskType` is `error-analysis` or `implementation-option-selection` and nothing else — this phase never hands off directly to planning or implementation. Prose alone does not route the task — Phase 7 projects `workflow.nextRecommendedPhase` from `nextTaskType`\n"
             "  - missing-input list and clarification requests\n"
             "  - approval / confirmation checkpoints recorded for the next phase\n"
             "  - one endStateCoverage row per brief end-state id (this phase authors no goal of its own)"
@@ -132,14 +117,14 @@ PHASE_RULES: dict[str, dict[str, str]] = {
             "  - TDD evidence for TDD-applicable steps: failing-test output before implementation commit and passing-test output after, with framing SHAs\n"
             "  - per-verifier sections for every verifier in the resolved roster, with an independent verdict (PASS / CONCERNS / FAIL) and cited diff snippets; dissent is preserved by the Okstra lead\n"
             "  - rollback verification (advisory, never blocks — record the revert path for a human; `result` is ok / not-applicable / advisory — human-run)\n"
-            "  - routing recommendation for `final-verification` (ready / needs new error-analysis or planning loop)"
+            "  - routing recommendation as the `routingRecommendation` object `{target, rationale}`: `target` is one of `final-verification`, `error-analysis`, `implementation-planning`, `implementation`, and `rationale` is why that one and nothing else. Prose alone does not route the task — Phase 7 projects `workflow.nextRecommendedPhase` from `target`"
         ),
     },
     "final-verification": {
         "allowed": (
             "  - acceptance verdict with requirement coverage assessment\n"
             "  - residual risk and regression notes\n"
-            "  - recommended follow-up routing (`error-analysis` / `implementation-option-selection` / `implementation-planning` / `release-handoff`) for any defects detected"
+            "  - routing recommendation as the `routingRecommendation` object `{target, rationale}`: `target` is one of `release-handoff`, `release-handoff(stage-group)`, `error-analysis`, `implementation-option-selection`, `implementation-planning`, `implementation`, `done`, and `rationale` ties that choice to the verdict and the blocker list. Both `release-handoff` forms require the `accepted` verdict; plain `release-handoff` additionally requires `whole-task` verification scope. Prose alone does not route the task — Phase 7 projects `workflow.nextRecommendedPhase` from `target`"
         ),
     },
     "release-handoff": {
@@ -187,10 +172,6 @@ def load_phase_forbidden(workspace_root: Path) -> dict[str, str]:
     return {phase: render_forbidden(items) for phase, items in data.items()}
 
 
-def default_next_phase_for(task_type: str) -> str:
-    return DEFAULT_NEXT_PHASE.get(task_type, "unknown")
-
-
 def compute_workflow_state(
     *,
     task_type: str,
@@ -221,8 +202,6 @@ def compute_workflow_state(
         else:
             phase_state = "not-started"
 
-    routing_status = "pending" if task_type == "requirements-discovery" else "not-applicable"
-
     if render_only:
         checkpoint_label = "instruction-set-prepared"
     elif current_run_status == "in-progress":
@@ -239,10 +218,17 @@ def compute_workflow_state(
         "WORKFLOW_WORK_CATEGORY": resolved_work_category,
         "WORKFLOW_CURRENT_PHASE": task_type,
         "WORKFLOW_CURRENT_PHASE_STATE": phase_state,
-        "WORKFLOW_NEXT_RECOMMENDED_PHASE": default_next_phase_for(task_type),
+        # 값이 아니라 자리표시자다. 실제 포인터는 리포트 라우팅에서 투영돼
+        # 매니페스트의 `workflow.nextRecommendedPhase` 구조체로 저장된다.
+        # 이 ctx 값은 그 구조체로 대체되지 않는다 — 남은 소비자는
+        # `render.py` 의 `_active_workflow` 하나이고, 그것은 이 빈 문자열을
+        # 승격해 phase 없는 pending 포인터를 active-run-context 에 적는다.
+        # `prompts/launch.template.md` 는 더 이상 이 토큰을 쓰지 않는다.
+        # 다음 phase 이름을 문장에 끼워 넣던 두 줄이, 이름 없이 읽히는 문장으로
+        # 바뀌었기 때문이다.
+        "WORKFLOW_NEXT_RECOMMENDED_PHASE": "",
         "WORKFLOW_LAST_COMPLETED_PHASE": last_completed,
         "WORKFLOW_AWAITING_APPROVAL": "false",
-        "WORKFLOW_ROUTING_STATUS": routing_status,
         "WORKFLOW_LAST_SAFE_CHECKPOINT_LABEL": checkpoint_label,
         "PHASE_ALLOWED_OUTPUTS": rules["allowed"],
         "PHASE_FORBIDDEN_ACTIONS": forbidden_by_phase.get(

package/runtime/python/okstra_ctl/worktree.py

@@ -4,9 +4,9 @@ Every okstra task — regardless of task-type/phase — runs inside an
 isolated git worktree rooted at
 `~/.okstra/worktrees/<project_id>/<task_group>/<task_id>/`. The same
 worktree is reused across all phases of one task-key (requirements-
-discovery → error-analysis → implementation-planning → implementation),
-so phase N picks up exactly the working-tree state phase N-1 left
-behind.
+discovery → error-analysis → implementation-option-selection →
+implementation-planning → implementation), so phase N picks up exactly
+the working-tree state phase N-1 left behind.
 
 A global registry (`worktree_registry.py`) maps task-keys to the
 on-disk path + branch and serialises reservations, so two concurrent

package/runtime/python/okstra_ctl/worktree_registry.py

@@ -8,10 +8,11 @@ processes cannot race to reserve the same path or branch.
 
 Why a global registry:
   - A single task-key spans multiple phases (requirements-discovery →
-    error-analysis → implementation-planning → implementation). All
-    phases must land in the **same** worktree on the **same** branch.
-    Re-entry from any phase must look up the existing entry instead of
-    creating a duplicate.
+    error-analysis → implementation-option-selection →
+    implementation-planning → implementation). All phases must land in
+    the **same** worktree on the **same** branch. Re-entry from any
+    phase must look up the existing entry instead of creating a
+    duplicate.
   - Two different task-keys must never collide on the same branch name.
     A global branch index makes that detectable cheaply.
   - Cleanup of stale entries (worktree dir removed manually) needs a