prizmkit 1.1.130 → 1.1.131

package/bundled/skills/prizmkit-workflow/references/workflow-state-protocol.md

@@ -0,0 +1,181 @@
+# PrizmKit Workflow State Protocol
+
+`workflow-state.json` is lifecycle runtime metadata for one formal requirement. It preserves stage handoff, repair routing, orchestrator ownership, and resume information without replacing authoritative artifacts or any host-owned execution checkpoint.
+
+## Location and Identity
+
+```text
+.prizmkit/state/workflows/<requirement-slug>.json
+```
+
+The state file is created only when a lifecycle runs. The active `artifact_dir` is the generic requirement artifact root and must be preserved exactly across every stage:
+
+```text
+.prizmkit/specs/<requirement-slug>/
+.prizmkit/bugfix/<bug-id>/
+.prizmkit/refactor/<refactor-id>/
+```
+
+Never select a different most-recent plan when resuming or handing off. Any execution checkpoint maintained by an external host remains separate from this lifecycle state. Never merge, substitute, or infer one schema from the other. The target project controls whether generated `.prizmkit/` files are committed, ignored, or shared.
+
+## Authority
+
+The state file is an index, not the authority for stage completion:
+
+| Information | Authority |
+|---|---|
+| Requirement goals and acceptance criteria | `{artifact_dir}/spec.md` |
+| Implementation tasks and completion | `{artifact_dir}/plan.md` plus current workspace |
+| Review findings and verdict | `{artifact_dir}/review-report.md` final result |
+| Test execution, verdict, and repair scope | Validated evidence package and authoritative `verdict.json` |
+| Test report presentation | `{artifact_dir}/test-report.md` as a derived view only |
+| Retrospective completion and result | `{artifact_dir}/retrospective-result.json` |
+| Durable architecture knowledge | `.prizmkit/prizm-docs/` |
+| Local commit | Git history and confirmed or authorized commit identity |
+| Current stage, orchestrator, and resume entry | Workflow state |
+| External orchestration progress | The external host's own checkpoint, never this state |
+
+Every consumer compares workflow state with authoritative artifacts and the current workspace. Missing or stale state is reconstructed from those sources and is never accepted as success by itself.
+
+## Schema
+
+```json
+{
+  "schema_version": 1,
+  "artifact_dir": ".prizmkit/specs/example",
+  "orchestrator": "prizmkit-workflow",
+  "stage": "test",
+  "status": "TEST_PASS",
+  "stage_result": "TEST_PASS",
+  "completed_stages": ["plan", "implement", "code-review", "test"],
+  "repair_scope": null,
+  "repair_round": 0,
+  "next_stage": "retrospective",
+  "resume_from": "prizmkit-retrospective"
+}
+```
+
+### Fields
+
+| Field | Meaning |
+|---|---|
+| `schema_version` | State schema version. Current value is `1`. |
+| `artifact_dir` | The single generic requirement artifact root reused by every stage. |
+| `orchestrator` | `prizmkit-workflow`, another semantic coordinator identifier, or `null` for direct stage use. |
+| `stage` | The stage that most recently wrote state. |
+| `status` | Lifecycle progression status, distinct from the domain `stage_result`. |
+| `stage_result` | Domain result such as `PASS`, `NEEDS_FIXES`, `TEST_*`, `DOCS_UPDATED`, or `NO_DOC_CHANGE`. |
+| `completed_stages` | Ordered stages completed for this requirement. |
+| `repair_scope` | `null`, `test-infrastructure`, `production`, `runtime`, `schema`, `dependency`, `public-interface`, or `unknown`. |
+| `repair_round` | Outer cross-stage repair round, from `0` through `3`. |
+| `next_stage` | Next semantic stage, or `null` after commit. |
+| `resume_from` | Exact atomic skill that can resume, or `null` after commit. |
+
+## Lifecycle and Verdict Mappings
+
+The mandatory formal lifecycle is:
+
+```text
+PLAN_READY
+  → IMPLEMENTED
+  → REVIEW_PASS
+  → TEST_PASS
+  → RETRO_COMPLETE
+  → COMMIT_PENDING
+  → COMMITTED
+```
+
+No formal stage is silently optional. Domain evidence maps as follows:
+
+```text
+review-report final PASS        → status=REVIEW_PASS, stage_result=PASS
+review-report final NEEDS_FIXES → status=REVIEW_NEEDS_FIXES, stage_result=NEEDS_FIXES
+validated verdict TEST_PASS     → status=TEST_PASS, stage_result=TEST_PASS
+validated verdict TEST_FAIL     → status=TEST_FAIL, stage_result=TEST_FAIL
+validated verdict TEST_BLOCKED  → status=TEST_BLOCKED, stage_result=TEST_BLOCKED
+retrospective result DOCS_UPDATED  → status=RETRO_COMPLETE, stage_result=DOCS_UPDATED
+retrospective result NO_DOC_CHANGE → status=RETRO_COMPLETE, stage_result=NO_DOC_CHANGE
+```
+
+`RETRO_COMPLETE` is the stable completion status. `DOCS_UPDATED` and `NO_DOC_CHANGE` are mutually exclusive retrospective results, not substitute statuses. A derived Markdown test report never establishes a `TEST_*` status without validated authoritative evidence.
+
+## Repair Routing
+
+```text
+REVIEW_NEEDS_FIXES
+  → implement
+  → code-review
+  → test
+
+TEST_FAIL with repair_scope=test-infrastructure
+  → implement
+  → test
+
+TEST_FAIL with repair_scope=production|runtime|schema|dependency|public-interface
+  → implement
+  → code-review
+  → test
+
+TEST_FAIL with repair_scope=unknown
+  → conservative production route only when safe
+  → otherwise WORKFLOW_BLOCKED
+
+TEST_BLOCKED
+  → never make speculative production edits
+  → interactive execution stops with a prizmkit-test resume entry
+  → a trusted headless host may perform bounded environment recovery, then records WORKFLOW_BLOCKED if unresolved
+
+RETRO_BLOCKED
+  → WORKFLOW_BLOCKED
+WORKFLOW_BLOCKED
+  → resume only after the recorded blocker is resolved
+```
+
+The outer workflow permits at most three automatic repair rounds. These are cross-stage rounds (`repair_round` `0` through `3`). The code-review internal loop permits at most ten completed review rounds and is separate; review-internal repairs do not increment the outer counter.
+
+## Orchestrator Ownership and Handoff
+
+1. An atomic stage performs only its own stage, writes the truthful terminal result and `next_stage`, and returns control.
+2. When `orchestrator` is non-null, only that orchestrator invokes the next skill. The atomic stage must not auto-invoke it again.
+3. Direct stage use may report one deterministic next invocation but does not claim the next stage ran.
+4. Every handoff preserves the same `artifact_dir`.
+5. External automation invokes atomic stages directly and does not invoke `prizmkit-workflow` as a nested coordinator.
+6. Workflow state never replaces or absorbs an external host's checkpoint.
+
+## Commit Authorization
+
+Interactive execution:
+
+```text
+committer previews intended files and message
+→ waits for explicit confirmation from the current user
+→ creates the local commit
+```
+
+Trusted headless execution:
+
+```text
+a trusted host explicitly authorizes the current local task commit
+→ host injects mode=<host-defined-headless-mode>, owner=<trusted-host-identifier>,
+  local_commit_authorized=true, push_authorized=false
+→ committer verifies gates and commits automatically
+→ no question, wait, or push is permitted
+```
+
+A self-declared or otherwise untrusted headless context does not authorize a commit. Push is never implied by either mode.
+
+## Recovery
+
+When state is missing, stale, or inconsistent:
+
+1. Read `spec.md` and `plan.md` from `artifact_dir` only when they are not already available in current context.
+2. Inspect task markers and the current workspace.
+3. Read the latest review report and final result when needed to establish review authority.
+4. Validate authoritative test evidence and `repair_scope`.
+5. Validate `retrospective-result.json` when retrospective is claimed complete.
+6. Verify the commit when commit is claimed complete.
+7. When an external host is active, let that host validate its own checkpoint independently; never merge the schemas.
+8. Reconstruct the latest safe predecessor and report the reconstruction.
+9. Continue only from the first incomplete or invalid stage.
+
+Stale state never bypasses review, testing, retrospective, commit authorization, or external host checkpoint enforcement.

package/bundled/skills/recovery-workflow/SKILL.md

@@ -1,284 +1,105 @@
 ---
 name: "recovery-workflow"
-description: "Recover and resume interrupted PrizmKit workflow or pipeline sessions. Auto-detects feature-workflow, bug-fix-workflow, refactor-workflow, plan lists, pipeline state, git branches, diffs, spec/plan artifacts, review artifacts, and session summaries; then offers recovery script, manual command, interactive resume, clean retry, or start-fresh options. Use when an AI CLI session timed out, crashed, hit token limits, left partial work, or the user says recover, resume, continue where I left off, pick up where it left off, or salvage partial work."
+description: "Return the exact PrizmKit CLI command that continues an interrupted feature, bugfix, or refactor task on its recorded task branch. Use when a pipeline process or AI session stopped unexpectedly and the user asks to recover, resume, continue, pick up, or salvage that task. This skill detects active task checkout records and reports commands; it does not reconstruct lifecycle phases or run recovery prompts."
 ---
 
 # Recovery Workflow
 
-Recover interrupted workflow or pipeline work. This skill is intentionally different from the ordinary feature/bug/refactor workflows: the success criterion is high-quality continuation of interrupted work, not structural consistency with other workflows.
+Find an interrupted pipeline task's durable checkout record and return the existing runtime command that continues that task on its recorded branch. The runtime already owns branch reuse, checkpoint interpretation, session continuation, and task execution; this skill must not reproduce those mechanisms.
 
-## When to Use
+## Boundary
 
-Use this skill when the user says:
-- Recover, resume, continue where I left off, or pick up where it left off.
-- Session interrupted, timed out, crashed, or hit token limits.
-- A pipeline/AI session left partial work and the user wants to salvage or complete it.
-- The user does not know whether the interrupted work was feature, bug fix, or refactor work.
+This workflow:
+- Detects active feature, bugfix, and refactor task checkout records.
+- Confirms that each recorded task branch still exists.
+- Returns the exact item-specific `cli.py ... run <TASK_ID>` command.
+- Shows the branch, task family, task ID, and checkout record that justify the command.
 
-Do not use this skill when:
-- The user only wants normal pipeline status/logs/stop/retry for a healthy pipeline -> use the matching launcher.
-- The user explicitly wants a clean retry of one pipeline item -> use the matching launcher reset guidance.
-- The user wants to discard all interrupted work and start fresh -> route to the original workflow after confirmation.
+This workflow does not:
+- Infer implementation, review, test, retrospective, or commit phases.
+- Inspect historical artifact directories to guess interrupted work.
+- Generate a recovery bootstrap prompt or launch a separate recovery AI session.
+- Reset state, delete branches, discard work, or execute the continuation command automatically.
+- Treat completed checkout records, old session logs, plan lists, or stale checkpoint files as active interruptions.
 
-## Recovery Approach Policy
+## Detection
 
-Always present the user with recovery choices after detection. Do not silently choose between script recovery and interactive recovery.
-
-Recommended default:
-- Use `python3 ./.prizmkit/dev-pipeline/cli.py recovery run` when the interrupted work appears to be a pipeline or AI-session continuation problem and the user wants autonomous completion.
-
-Interactive recovery remains valid when:
-- The user wants control in the current conversation.
-- The recovery script is unavailable or fails.
-- The interrupted work is a small current-workspace Fast Path task.
-- The user wants to inspect before launching another AI session.
-
-Clean retry is different from recovery:
-- Use clean retry when the user wants to discard the failed item attempt and rerun from scratch.
-- Use recovery when partial work, context, or decisions should be preserved.
-
-## Detection Signals
-
-Inspect multiple signals. Do not depend on a single artifact.
-
-| Signal | Meaning |
-|---|---|
-| Current branch | `fix/*`, `feat/*`, `refactor/*`, or task-specific branch names can indicate workflow family |
-| Git diff / staged / untracked files | Shows partial implementation or planning work |
-| `spec.md` / `plan.md` | Current-session Fast Path planning artifacts |
-| `.prizmkit/plans/feature-list.json` | Feature pipeline planning artifact |
-| `.prizmkit/plans/bug-fix-list.json` | Bugfix pipeline planning artifact |
-| `.prizmkit/plans/refactor-list.json` | Refactor pipeline planning artifact |
-| `.prizmkit/state/features/` | Feature pipeline state |
-| `.prizmkit/state/bugfix/` | Bugfix pipeline state |
-| `.prizmkit/state/refactor/` | Refactor pipeline state |
-| `session-summary.md` / `context-snapshot.md` | Previous-session context handoff |
-| Review artifacts | Evidence that implementation reached review |
-| `.prizmkit/bugfix/<BUG_ID>/fix-plan.md` / `fix-report.md` | Optional bug recovery signals when present, not required contract |
-
-Run the detection script for the first pass:
+Run the bundled detector from the target project root:
 
 ```bash
-python3 ${SKILL_DIR}/scripts/detect-recovery-state.py
-```
-
-For the signature matching and phase inference tables, read `${SKILL_DIR}/references/detection.md`.
-
-## Recovery Flow
-
-### Phase 0: Auto-detect
-
-1. Run the detection script.
-2. If the script fails, fall back to manual checks: branch, git status, list files, pipeline state directories, and obvious session artifacts.
-3. Identify primary workflow family: bug-fix, feature, refactor, or unknown.
-4. Identify whether the work is current-workspace Fast Path, planned pipeline work, active pipeline work, failed pipeline item, or ambiguous.
-
-Checkpoint: recovery target and likely phase are known, or no workflow is detected.
-
-### Phase 1: Diagnose workspace health
-
-Before recommending recovery, inspect and summarize:
-
-- Current branch.
-- Whether the working tree has uncommitted changes.
-- Whether code/test files changed.
-- Which plan lists exist.
-- Which pipeline state directories exist.
-- Failed, in-progress, pending, and completed items when status commands are available.
-- Residual task branches that may correspond to failed/interrupted work.
-- Detected artifacts such as `spec.md`, `plan.md`, review reports, session summaries, or optional bugfix reports.
-
-Use concise markdown, not box-drawing banners:
-
-```markdown
-## Workspace Diagnosis
-
-- Branch: fix/B-001-login-crash
-- Working tree: 3 uncommitted files
-- Code changes: 2 source files, 1 test file
-- Plan lists: bug-fix-list.json found
-- Pipeline state: bugfix has 1 failed item
-- Session artifacts: plan.md found, review report not found
-
-## Detected Recovery Target
-
-- Workflow: bug-fix-workflow
-- Likely phase: Review
-- Reason: fix branch + code changes + no review artifact
-- Remaining work: review -> verification -> commit -> merge decision
+python3 ${SKILL_DIR}/scripts/detect-recovery-state.py --project-root .
 ```
 
-If code changes exist, run or suggest the project test command when it is safe and reasonably detectable. Report failures without hiding them.
-
-### Phase 2: Select recovery target
-
-If multiple failed or interrupted targets exist, use `AskUserQuestion` to choose the first target.
-
-For up to three targets, list each target explicitly plus an all-sequential option. If there are more than three targets, group choices to avoid an overloaded question:
+The detector reads only active checkout records:
 
 ```text
-Question: Multiple interrupted targets found. Which should we recover first?
-Header: Target
-Options:
-- Highest-priority failed item — recover the most urgent failed item first
-- Choose from summary — show full target list before selecting
-- Recover all sequentially — recover each failed/interrupted item in priority order
-- Stop here — do not recover now
+.prizmkit/state/features/<F-NNN>/checkout.json
+.prizmkit/state/bugfix/<B-NNN>/checkout.json
+.prizmkit/state/refactor/<R-NNN>/checkout.json
 ```
 
-### Phase 3: Select recovery approach
+A candidate is resumable only when:
+- `state` is `active`;
+- `task_id` matches its task family;
+- `active_dev_branch` is present; and
+- the recorded local branch still exists.
 
-Use `AskUserQuestion` for the approach. Do not proceed without an explicit selection.
+The runtime uses the same checkout record when the returned command starts, so it continues on the recorded branch rather than creating a new branch.
 
-```text
-Question: Interrupted work was detected. How would you like to recover?
-Header: Recovery
-Options:
-- Run recovery script (Recommended) — execute python3 ./.prizmkit/dev-pipeline/cli.py recovery run to generate a bootstrap prompt and complete remaining phases in a dedicated AI session
-- Resume interactively — continue from the inferred phase in this conversation
-- Clean retry — discard the failed item attempt and rerun it from scratch through the matching launcher reset flow
-- Start fresh — abandon interrupted work and restart the original workflow
-```
+## Selection
 
-If the user wants to inspect first, offer:
+### One candidate
 
-```bash
-python3 ./.prizmkit/dev-pipeline/cli.py recovery detect
-python3 ./.prizmkit/dev-pipeline/cli.py recovery run --dry-run
-```
+Return that candidate immediately. Do not add another confirmation round because this skill only reports a command and does not execute it.
 
-### Phase 4: Execute the selected approach
+### Multiple candidates
 
-**Run recovery script**:
+Use `AskUserQuestion` to ask which task to continue. Label each option with:
 
-```bash
-python3 ./.prizmkit/dev-pipeline/cli.py recovery run
+```text
+<TASK_ID> — <family> — <branch>
 ```
 
-After launch, stop this skill and report how the user can monitor the recovery session.
+After selection, return only the selected task's continuation block.
 
-**Resume interactively**:
+### No candidate
 
-1. Read the target workflow SKILL.md.
-2. Read available context artifacts in this order:
-   - `context-snapshot.md` when present.
-   - `session-summary.md` when present.
-   - `spec.md`, `plan.md`, review reports, relevant diffs, and list entries.
-3. Read relevant `.prizmkit/prizm-docs/` according to the project progressive-loading protocol.
-4. Continue from the inferred phase using the target workflow's rules.
-5. Preserve existing work where safe; do not restart from scratch unless the user chooses that.
+Report that no active interrupted pipeline task branch was found. Do not fall back to branch-name, plan-list, diff, or artifact guesses. Suggest the matching scenario workflow for fresh work, or the matching pipeline launcher when the user already has a validated plan list and only needs a runtime command.
 
-**Clean retry**:
+## Continuation Commands
 
-Route to the matching launcher reset flow:
+Return the detector-provided command verbatim. The canonical forms are:
 
 ```bash
-python3 ./.prizmkit/dev-pipeline/cli.py reset feature <FEATURE_ID> --clean --run .prizmkit/plans/feature-list.json
-python3 ./.prizmkit/dev-pipeline/cli.py reset bugfix <BUG_ID> --clean --run .prizmkit/plans/bug-fix-list.json
-python3 ./.prizmkit/dev-pipeline/cli.py reset refactor <REFACTOR_ID> --clean --run .prizmkit/plans/refactor-list.json
+python3 ./.prizmkit/dev-pipeline/cli.py feature run F-001
+python3 ./.prizmkit/dev-pipeline/cli.py bugfix run B-001
+python3 ./.prizmkit/dev-pipeline/cli.py refactor run R-001
 ```
 
-Ask before running a clean retry because it intentionally discards that item's prior session state.
-
-**Start fresh**:
-
-Suggest the original workflow:
-- `feature-workflow`
-- `bug-fix-workflow`
-- `refactor-workflow`
-
-Stop after the user confirms restart.
-
-## Per-Workflow Recovery Notes
-
-### Bug-fix recovery
-
-Bug-fix recovery should not assume `fix-plan.md` or `fix-report.md` exists. Use them when present, but also infer from:
-
-- `fix/*` branch.
-- Code/test diff.
-- `spec.md` / `plan.md`.
-- Review artifacts.
-- Commits ahead of the original branch.
-- User-provided bug ID or matching bug-fix-list entry.
-
-Typical inference:
-
-| Detected state | Resume from |
-|---|---|
-| Fix branch, no implementation artifacts | Diagnosis / triage |
-| `spec.md` or `plan.md`, no code changes | Fix implementation |
-| Code/test changes, no review artifact | Review |
-| Review artifact or optional `fix-report.md` | User verification |
-| Fix commit exists on branch | Merge decision |
+Do not prepend `git checkout`. The runtime resolves the durable checkout identity and continues the task on its recorded branch or linked worktree.
 
-### Feature recovery
+Do not replace continuation with any reset command. Reset and clean-reset are separate destructive operations owned by the matching pipeline launcher.
 
-Feature recovery is usually list/pipeline driven:
-
-| Detected state | Resume from |
-|---|---|
-| No feature list and no Fast Path artifacts | Route selection or feature clarification |
-| Valid feature list, no pipeline state | `feature-pipeline-launcher` launch |
-| Feature list plus pipeline state | `feature-pipeline-launcher` status/retry or recovery script |
-| Current-workspace Fast Path artifacts | Continue `/prizmkit-implement`, review, retrospective, or commit based on state |
-
-### Refactor recovery
-
-Refactor recovery mirrors feature recovery but must preserve behavior checks:
-
-| Detected state | Resume from |
-|---|---|
-| No refactor list and no Fast Path artifacts | Route selection or refactor clarification |
-| Valid refactor list, no pipeline state | `refactor-pipeline-launcher` launch |
-| Refactor list plus pipeline state | `refactor-pipeline-launcher` status/retry or recovery script |
-| Current-workspace Fast Path artifacts | Continue implementation, behavior checks, review, retrospective, or commit based on state |
-
-## Runtime Status Reference
+## Output
 
-Recovery may inspect pipeline state before choosing recovery, interactive resume, or clean retry. Use the canonical Python runtime forms:
+Use this exact structure:
 
-```bash
-python3 ./.prizmkit/dev-pipeline/cli.py recovery run
-python3 ./.prizmkit/dev-pipeline/cli.py recovery detect
-python3 ./.prizmkit/dev-pipeline/cli.py feature status .prizmkit/plans/feature-list.json
-python3 ./.prizmkit/dev-pipeline/cli.py bugfix status .prizmkit/plans/bug-fix-list.json
-python3 ./.prizmkit/dev-pipeline/cli.py refactor status .prizmkit/plans/refactor-list.json
-python3 ./.prizmkit/dev-pipeline/cli.py reset feature <F-XXX> --clean --run .prizmkit/plans/feature-list.json
-python3 ./.prizmkit/dev-pipeline/cli.py reset bugfix <B-XXX> --clean --run .prizmkit/plans/bug-fix-list.json
+```text
+INTERRUPTED_TASK_FOUND
+family: <feature | bugfix | refactor>
+task_id: <F-NNN | B-NNN | R-NNN>
+branch: <recorded active_dev_branch>
+checkout: <project-relative checkout.json path>
+command:
+python3 ./.prizmkit/dev-pipeline/cli.py <family> run <TASK_ID>
+
+execution: not performed
 ```
 
-Use the matching launcher for healthy status/logs/retry flows. Use clean retry only after explicit user confirmation because it discards the selected item session state.
-
-## Error Handling
-
-| Scenario | Action |
-|---|---|
-| No workflow signature matches | Report no interrupted workflow detected and suggest original workflow skills |
-| Multiple workflows match | Present the evidence and ask which target to recover first |
-| Branch and artifacts disagree | Trust git diff/status as ground truth, but report the discrepancy |
-| Detection script fails | Fall back to manual detection checks |
-| Tests fail during diagnosis | Report failures and ask whether to continue recovery, fix tests, or stop |
-| Recovery script unavailable | Offer interactive recovery or clean retry |
-| Clean retry requested with uncommitted changes | Warn that retry may discard item session state; ask for explicit confirmation |
-
-## Relationship to Other Skills
-
-| Skill or command | Relationship |
-|---|---|
-| `feature-workflow` | Recovery target for interrupted feature workflows |
-| `bug-fix-workflow` | Recovery target for interrupted bug-fix workflows |
-| `refactor-workflow` | Recovery target for interrupted refactor workflows |
-| `feature-pipeline-launcher` | Status/logs/retry for healthy or resumable feature pipelines |
-| `bugfix-pipeline-launcher` | Status/logs/retry for healthy or resumable bugfix pipelines |
-| `refactor-pipeline-launcher` | Status/logs/retry for healthy or resumable refactor pipelines |
-| `/prizmkit-code-review` | Used when interactive recovery resumes at review |
-| `/prizmkit-committer` | Used when interactive recovery resumes at commit |
-| `python3 ./.prizmkit/dev-pipeline/cli.py recovery run` | Dedicated script recovery counterpart |
-
-## Output
+When no candidate exists:
 
-- Recovery diagnosis summary.
-- User-selected recovery target and approach.
-- Either launched recovery script, interactive continuation, clean retry command, or start-fresh handoff.
-- Final recovery summary when interactive recovery completes.
+```text
+NO_INTERRUPTED_TASK_FOUND
+reason: no active checkout record with an existing task branch
+execution: not performed
+```

package/bundled/skills/recovery-workflow/evals/evals.json

@@ -1,53 +1,37 @@
 {
   "skill_name": "recovery-workflow",
-  "notes": "These test cases require workspace state setup. Recovery now treats fix-plan.md and fix-report.md as optional signals; branch, diff, spec.md, plan.md, review artifacts, and pipeline state are also valid recovery signals.",
+  "notes": "Recovery reports item-specific continuation commands from active durable checkout records. It does not reconstruct lifecycle phases or launch a separate recovery session.",
   "evals": [
     {
       "id": 1,
-      "name": "bugfix-mid-fix-with-plan",
-      "prompt": "My session broke, help me recover",
-      "expected_output": "Should auto-detect bug-fix-workflow from fix/B-001-* branch. Should detect fix-plan.md + code changes as optional plan signal plus implementation diff -> infer Review. Should display recovery report with workflow type, phase, artifacts, and code stats. Should ask recovery approach before invoking /prizmkit-code-review or recovery script.",
-      "setup_description": "Create fix/B-001-login-crash branch, optional .prizmkit/bugfix/B-001/fix-plan.md, modify 3 source files + 1 test file. No fix-report.md, no commits ahead of main.",
+      "name": "single-feature-interruption",
+      "prompt": "My feature pipeline process stopped. Give me the command to continue it.",
+      "expected_output": "Detect one active feature checkout record with an existing branch and return python3 ./.prizmkit/dev-pipeline/cli.py feature run F-001 without executing it.",
+      "setup_description": "Create .prizmkit/state/features/F-001/checkout.json with state active and an existing dev/F-001-* local branch.",
       "files": []
     },
     {
       "id": 2,
-      "name": "bugfix-diff-no-fix-plan",
-      "prompt": "Continue the previous bug fix",
-      "expected_output": "Should auto-detect bug-fix-workflow from fix/B-002-* branch even without fix-plan.md. Code/test changes should infer Review. Should not require .prizmkit/bugfix/B-002/fix-plan.md to exist.",
-      "setup_description": "Create fix/B-002-null-pointer branch and modify 2 source files + 1 test file. No .prizmkit/bugfix/B-002 directory, no fix-plan.md, no fix-report.md.",
+      "name": "single-bugfix-interruption",
+      "prompt": "Resume the interrupted bugfix task.",
+      "expected_output": "Detect the active bugfix checkout and return python3 ./.prizmkit/dev-pipeline/cli.py bugfix run B-001 without reconstructing phases or executing the command.",
+      "setup_description": "Create .prizmkit/state/bugfix/B-001/checkout.json with state active and an existing bugfix/B-001-* local branch.",
       "files": []
     },
     {
       "id": 3,
-      "name": "bugfix-plan-only",
-      "prompt": "Continue the previous work",
-      "expected_output": "Should auto-detect bug-fix-workflow from fix/B-003-* branch. Should detect spec.md or plan.md but no code changes -> infer Fix. Should read the plan artifact and resume implementation only after user chooses interactive recovery.",
-      "setup_description": "Create fix/B-003-null-pointer branch with spec.md and plan.md. No code changes.",
+      "name": "multiple-interrupted-tasks",
+      "prompt": "Continue whichever pipeline task was interrupted.",
+      "expected_output": "Detect multiple active checkout records and ask the user to select by task ID, family, and branch before returning one command.",
+      "setup_description": "Create active feature and refactor checkout records whose local branches both exist.",
       "files": []
     },
     {
       "id": 4,
-      "name": "feature-list-exists",
-      "prompt": "resume",
-      "expected_output": "Should auto-detect feature-workflow from .prizmkit/plans/feature-list.json. Should detect list exists but no pipeline state -> infer Launch. Should ask recovery approach; launcher handoff is valid after user selection.",
-      "setup_description": "On main branch, create .prizmkit/plans/feature-list.json with 3 features. No .prizmkit/state/features/ directory.",
-      "files": []
-    },
-    {
-      "id": 5,
-      "name": "refactor-monitoring",
-      "prompt": "pick up where it left off",
-      "expected_output": "Should auto-detect refactor-workflow from .prizmkit/plans/refactor-list.json + pipeline state. Should infer Monitor / Recover Pipeline. Should ask whether to run recovery script, resume interactively, clean retry, or start fresh.",
-      "setup_description": "On main branch, create .prizmkit/plans/refactor-list.json with 2 items. Create .prizmkit/state/refactor/ with status files showing 1 completed, 1 in-progress.",
-      "files": []
-    },
-    {
-      "id": 6,
-      "name": "no-workflow-detected",
-      "prompt": "recover",
-      "expected_output": "Should detect no workflow signatures in workspace. Should display guidance suggesting /feature-workflow, /bug-fix-workflow, or /refactor-workflow. Should NOT attempt recovery actions.",
-      "setup_description": "Clean workspace on main branch. No .prizmkit/plans/*.json files, no pipeline state, no fix/* or feat/* or refactor/* branch, no spec.md or plan.md.",
+      "name": "historical-state-only",
+      "prompt": "Recover the previous pipeline task.",
+      "expected_output": "Return NO_INTERRUPTED_TASK_FOUND because completed checkout records, plan lists, session logs, and old checkpoints are not active interruptions.",
+      "setup_description": "Create only completed checkout records plus historical sessions and checkpoints.",
       "files": []
     }
   ]