prizmkit 1.1.140 → 1.1.142

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

@@ -1,6 +1,6 @@
 # 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.
+`workflow-state.json` is lifecycle metadata for one formal requirement. It preserves stage handoff, orchestrator ownership, and resume information without replacing skill-owned artifacts or any host-owned execution checkpoint.
 
 ## Location and Identity
 
@@ -8,7 +8,7 @@
 .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:
+The active `artifact_dir` is preserved exactly across every stage:
 
 ```text
 .prizmkit/specs/<requirement-slug>/
@@ -16,7 +16,7 @@ The state file is created only when a lifecycle runs. The active `artifact_dir`
 .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.
+Never select another recent plan when resuming. Any external execution checkpoint remains separate from this state. Never merge, substitute, or infer one schema from the other.
 
 ## Authority
 
@@ -26,16 +26,16 @@ The state file is an index, not the authority for stage completion:
 |---|---|
 | 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` |
+| Review findings and result | `{artifact_dir}/review-report.md` |
+| Test semantics and native execution | `{artifact_dir}/test-report.md` |
+| Terminal testing result | `{artifact_dir}/test-result.json` |
+| Retrospective completion | `{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 |
+| External orchestration progress | External host checkpoint |
 
-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.
+Every consumer compares workflow state with the skill-owned artifacts and current workspace. Missing or stale state is reconstructed from those sources and is never accepted as success by itself.
 
 ## Schema
 
@@ -45,7 +45,7 @@ Every consumer compares workflow state with authoritative artifacts and the curr
   "artifact_dir": ".prizmkit/specs/example",
   "orchestrator": "prizmkit-workflow",
   "stage": "test",
-  "status": "TEST_PASS",
+  "status": "completed",
   "stage_result": "TEST_PASS",
   "completed_stages": ["plan", "implement", "code-review", "test"],
   "repair_scope": null,
@@ -59,88 +59,83 @@ Every consumer compares workflow state with authoritative artifacts and the curr
 
 | 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`. |
+| `schema_version` | State schema version. |
+| `artifact_dir` | Generic requirement artifact root reused by every stage. |
+| `orchestrator` | Semantic coordinator identifier, or null for direct stage use. |
+| `stage` | Stage that most recently wrote state. |
+| `status` | Lifecycle status: `pending`, `in_progress`, `completed`, `failed`, or `skipped`. |
+| `stage_result` | Domain result for the current stage, such as `PLAN_READY`, `IMPLEMENTED`, `REVIEW_PASS`, `REVIEW_NEEDS_FIXES`, `TEST_*`, `RETRO_COMPLETE`, or `COMMITTED`. |
 | `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. |
+| `repair_scope` | Optional caller-owned routing scope. The test skill reports high-risk repairs through `test-result.json` instead of scheduling another stage. |
+| `repair_round` | Optional outer cross-stage repair round, from 0 through 3. It is not a test-internal repair counter. |
+| `next_stage` | Next semantic stage, or null when stopped. |
+| `resume_from` | Exact atomic skill that can resume, or null when none is selected. |
 
-## Lifecycle and Verdict Mappings
+`status` and `stage_result` are deliberately separate. Lifecycle status values must never be replaced with domain result values.
 
-The mandatory formal lifecycle is:
+## Lifecycle and Result Mappings
 
 ```text
 PLAN_READY
-  → IMPLEMENTED
-  → REVIEW_PASS
-  → TEST_PASS
-  → RETRO_COMPLETE
-  → COMMIT_PENDING
-  → COMMITTED
+→ IMPLEMENTED
+→ REVIEW_PASS
+→ TEST_PASS
+→ RETRO_COMPLETE
+→ COMMIT_PENDING
+→ COMMITTED
 ```
 
-No formal stage is silently optional. Domain evidence maps as follows:
+No formal stage is silently optional. Domain artifacts map to workflow state 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
+plan PLAN_READY                  → status=completed,  stage_result=PLAN_READY
+plan PLAN_BLOCKED                → status=failed,     stage_result=PLAN_BLOCKED
+implementation IMPLEMENTED       → status=completed,  stage_result=IMPLEMENTED
+implementation repair/block      → status=failed,     stage_result=IMPLEMENT_REPAIR or IMPLEMENT_BLOCKED
+review-report PASS               → status=completed,  stage_result=REVIEW_PASS
+review-report NEEDS_FIXES        → status=failed,     stage_result=REVIEW_NEEDS_FIXES
+test-result TEST_PASS            → status=completed,  stage_result=TEST_PASS
+test-result TEST_NEEDS_FIXES     → status=failed,     stage_result=TEST_NEEDS_FIXES
+test-result TEST_BLOCKED         → status=failed,     stage_result=TEST_BLOCKED
+retrospective DOCS_UPDATED       → status=completed,  stage_result=RETRO_COMPLETE
+retrospective NO_DOC_CHANGE      → status=completed,  stage_result=RETRO_COMPLETE
+retrospective blocked            → status=failed,     stage_result=RETRO_BLOCKED
+commit authorization pending     → status=in_progress, stage_result=COMMIT_PENDING
+local commit confirmed           → status=completed,  stage_result=COMMITTED
+commit blocked                   → status=failed,     stage_result=COMMIT_BLOCKED
 ```
 
-`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.
+`DOCS_UPDATED` and `NO_DOC_CHANGE` remain retrospective artifact `result` values. The workflow `stage_result` is the retrospective stage result `RETRO_COMPLETE`.
 
-## Repair Routing
+`TEST_PASS` requires both `test-report.md` and a consistent `test-result.json`. No manifest, attestation, evidence package, or test-internal checkpoint is part of this contract.
 
-```text
-REVIEW_NEEDS_FIXES
-  → implement
-  → code-review
-  → test
-
-TEST_FAIL with repair_scope=test-infrastructure
-  → implement
-  → test
+## Non-Pass Results and Routing Boundary
 
-TEST_FAIL with repair_scope=production|runtime|schema|dependency|public-interface
-  → implement
-  → code-review
-  → test
+`prizmkit-test` performs its own bounded failure repair and review loops before returning. The test skill never invokes another lifecycle stage.
 
-TEST_FAIL with repair_scope=unknown
-  → conservative production route only when safe
-  → otherwise WORKFLOW_BLOCKED
+```text
+TEST_NEEDS_FIXES
+→ known correction or required delta review remains
+→ caller decides whether and how to arrange another stage
 
 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
+→ truth, input, safe environment, or reliable execution prevents a verdict
+→ never make speculative production edits
+→ caller or external host owns recovery policy
 ```
 
-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.
+A test result is not an AI CLI session classification. `TEST_NEEDS_FIXES` and `TEST_BLOCKED` must not be rewritten as crash or infrastructure failure merely because they stop lifecycle progression.
+
+Any outer repair or continuation policy is independently owned by the caller and cannot alter the test report. The Main-Agent test review limit of ten rounds, independent Test Reviewer limit of five responses, and execution-failure repair limit of three rounds are internal to one test invocation and do not update outer counters.
 
 ## 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.
+1. An atomic stage performs only its own stage, writes its truthful result and artifact paths, and returns control.
+2. When `orchestrator` is non-null, only that orchestrator invokes the next skill.
+3. Direct stage use may report a possible next invocation but does not claim it 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.
+5. External automation invokes atomic stages directly and does not nest the composite workflow.
+6. Workflow state never replaces or absorbs an external host checkpoint.
 
 ## Commit Authorization
 
@@ -148,34 +143,32 @@ Interactive execution:
 
 ```text
 committer previews intended files and message
-→ waits for explicit confirmation from the current user
+→ waits for explicit current-user confirmation
 → 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
+trusted host explicitly authorizes the current local task commit
 → committer verifies gates and commits automatically
-→ no question or wait is permitted
+→ remote publication remains separate
 ```
 
-A self-declared or otherwise untrusted headless context does not authorize a commit. Remote publication remains a separate host-runtime decision.
+A self-declared or untrusted headless context does not authorize a commit.
 
 ## 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`.
+1. Reuse current context, then read `spec.md` and `plan.md` only when needed.
+2. Inspect task markers and current workspace.
+3. Read the current review report when needed to establish review authority.
+4. Validate that `test-report.md` and terminal `test-result.json` exist, agree, and reflect the claimed result.
 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.
+7. Let an active external host validate its own checkpoint independently.
 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.
+Stale state never bypasses review, testing, retrospective, commit authorization, or external checkpoint enforcement.

package/bundled/skills/prizmkit-retrospective/SKILL.md

@@ -40,7 +40,7 @@ prizmkit-plan
 ## When NOT to Use
 
 - The requirement has not passed code review and testing.
-- `TEST_FAIL` or `TEST_BLOCKED` remains unresolved.
+- `TEST_NEEDS_FIXES` or `TEST_BLOCKED` remains unresolved.
 - The request is a direct edit outside the formal requirement lifecycle, unless the user explicitly asks for documentation maintenance.
 - First-time docs initialization or out-of-band docs repair; use `/prizmkit-prizm-docs` instead.
 
@@ -49,7 +49,7 @@ prizmkit-plan
 1. Reuse the caller's `artifact_dir`; do not select another requirement.
 2. Confirm the latest review result is `PASS`.
 3. Confirm the latest testing result is `TEST_PASS`.
-4. Read the final source diff with `.prizmkit/` excluded, then use `spec.md`, `plan.md`, the final `review-report.md`, and final test evidence only as supporting context for the non-`.prizmkit/` changes.
+4. Read the final source diff with `.prizmkit/` excluded, then use `spec.md`, `plan.md`, the final `review-report.md`, `test-report.md`, and `test-result.json` only as supporting context for the non-`.prizmkit/` changes.
 5. If the workflow state is missing or stale, reconstruct it from those authoritative artifacts and report the reconstruction.
 
 `.prizmkit/` is always excluded from retrospective project-change input scope. Do not treat any file under `.prizmkit/`—including plans, artifacts, state, evidence, or existing Prizm docs—as a changed project file from which structural or durable knowledge is inferred. Required lifecycle state/evidence writes and targeted `.prizmkit/prizm-docs/` updates remain outputs; documentation changes must be justified only by observed non-`.prizmkit/` project changes.
@@ -102,7 +102,8 @@ Write `{artifact_dir}/retrospective-result.json` for every formal requirement:
 
 ```json
 {
-  "status": "RETRO_COMPLETE",
+  "status": "completed",
+  "stage_result": "RETRO_COMPLETE",
   "result": "DOCS_UPDATED",
   "reason": "Durable module interfaces and traps changed",
   "review_verdict": "PASS",
@@ -110,7 +111,7 @@ Write `{artifact_dir}/retrospective-result.json` for every formal requirement:
 }
 ```
 
-`status=RETRO_COMPLETE` is the stable completion status. `result` must be exactly `DOCS_UPDATED` or `NO_DOC_CHANGE`; do not use either result as a substitute for completion status. Use `result=NO_DOC_CHANGE` with a concrete reason when no documentation update is warranted. This artifact is the retrospective gate evidence consumed by the committer and external automation; workflow state alone does not prove completion.
+`status=completed` is the stable lifecycle status. `stage_result=RETRO_COMPLETE` marks successful retrospective completion; `result` must be exactly `DOCS_UPDATED` or `NO_DOC_CHANGE`. Use `result=NO_DOC_CHANGE` with a concrete reason when no documentation update is warranted. This artifact is the retrospective gate evidence consumed by the committer and external automation; workflow state alone does not prove completion.
 
 ## Workflow State and Handoff
 
@@ -121,14 +122,15 @@ On successful completion, update `.prizmkit/state/workflows/<requirement-slug>.j
 ```json
 {
   "stage": "retrospective",
-  "status": "RETRO_COMPLETE",
+  "status": "completed",
+  "stage_result": "RETRO_COMPLETE",
   "completed_stages": ["plan", "implement", "code-review", "test", "retrospective"],
   "next_stage": "committer",
   "resume_from": "prizmkit-committer"
 }
 ```
 
-Use `status=RETRO_COMPLETE` for both successful outcomes, with `result=DOCS_UPDATED` when durable docs changed or `result=NO_DOC_CHANGE` when the stage completed without a docs update. Both result values permit the commit stage.
+Use `status=completed` and `stage_result=RETRO_COMPLETE` for both successful outcomes, with `result=DOCS_UPDATED` when durable docs changed or `result=NO_DOC_CHANGE` when the stage completed without a docs update. Both result values permit the commit stage.
 
 If documentation validation or synchronization cannot safely complete, return `RETRO_BLOCKED`, do not commit, and provide the exact recovery entry.
 

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

@@ -1,6 +1,6 @@
 # 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.
+`workflow-state.json` is lifecycle metadata for one formal requirement. It preserves stage handoff, orchestrator ownership, and resume information without replacing skill-owned artifacts or any host-owned execution checkpoint.
 
 ## Location and Identity
 
@@ -8,7 +8,7 @@
 .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:
+The active `artifact_dir` is preserved exactly across every stage:
 
 ```text
 .prizmkit/specs/<requirement-slug>/
@@ -16,7 +16,7 @@ The state file is created only when a lifecycle runs. The active `artifact_dir`
 .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.
+Never select another recent plan when resuming. Any external execution checkpoint remains separate from this state. Never merge, substitute, or infer one schema from the other.
 
 ## Authority
 
@@ -26,16 +26,16 @@ The state file is an index, not the authority for stage completion:
 |---|---|
 | 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` |
+| Review findings and result | `{artifact_dir}/review-report.md` |
+| Test semantics and native execution | `{artifact_dir}/test-report.md` |
+| Terminal testing result | `{artifact_dir}/test-result.json` |
+| Retrospective completion | `{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 |
+| External orchestration progress | External host checkpoint |
 
-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.
+Every consumer compares workflow state with the skill-owned artifacts and current workspace. Missing or stale state is reconstructed from those sources and is never accepted as success by itself.
 
 ## Schema
 
@@ -45,7 +45,7 @@ Every consumer compares workflow state with authoritative artifacts and the curr
   "artifact_dir": ".prizmkit/specs/example",
   "orchestrator": "prizmkit-workflow",
   "stage": "test",
-  "status": "TEST_PASS",
+  "status": "completed",
   "stage_result": "TEST_PASS",
   "completed_stages": ["plan", "implement", "code-review", "test"],
   "repair_scope": null,
@@ -59,88 +59,83 @@ Every consumer compares workflow state with authoritative artifacts and the curr
 
 | 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`. |
+| `schema_version` | State schema version. |
+| `artifact_dir` | Generic requirement artifact root reused by every stage. |
+| `orchestrator` | Semantic coordinator identifier, or null for direct stage use. |
+| `stage` | Stage that most recently wrote state. |
+| `status` | Lifecycle status: `pending`, `in_progress`, `completed`, `failed`, or `skipped`. |
+| `stage_result` | Domain result for the current stage, such as `PLAN_READY`, `IMPLEMENTED`, `REVIEW_PASS`, `REVIEW_NEEDS_FIXES`, `TEST_*`, `RETRO_COMPLETE`, or `COMMITTED`. |
 | `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. |
+| `repair_scope` | Optional caller-owned routing scope. The test skill reports high-risk repairs through `test-result.json` instead of scheduling another stage. |
+| `repair_round` | Optional outer cross-stage repair round, from 0 through 3. It is not a test-internal repair counter. |
+| `next_stage` | Next semantic stage, or null when stopped. |
+| `resume_from` | Exact atomic skill that can resume, or null when none is selected. |
 
-## Lifecycle and Verdict Mappings
+`status` and `stage_result` are deliberately separate. Lifecycle status values must never be replaced with domain result values.
 
-The mandatory formal lifecycle is:
+## Lifecycle and Result Mappings
 
 ```text
 PLAN_READY
-  → IMPLEMENTED
-  → REVIEW_PASS
-  → TEST_PASS
-  → RETRO_COMPLETE
-  → COMMIT_PENDING
-  → COMMITTED
+→ IMPLEMENTED
+→ REVIEW_PASS
+→ TEST_PASS
+→ RETRO_COMPLETE
+→ COMMIT_PENDING
+→ COMMITTED
 ```
 
-No formal stage is silently optional. Domain evidence maps as follows:
+No formal stage is silently optional. Domain artifacts map to workflow state 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
+plan PLAN_READY                  → status=completed,  stage_result=PLAN_READY
+plan PLAN_BLOCKED                → status=failed,     stage_result=PLAN_BLOCKED
+implementation IMPLEMENTED       → status=completed,  stage_result=IMPLEMENTED
+implementation repair/block      → status=failed,     stage_result=IMPLEMENT_REPAIR or IMPLEMENT_BLOCKED
+review-report PASS               → status=completed,  stage_result=REVIEW_PASS
+review-report NEEDS_FIXES        → status=failed,     stage_result=REVIEW_NEEDS_FIXES
+test-result TEST_PASS            → status=completed,  stage_result=TEST_PASS
+test-result TEST_NEEDS_FIXES     → status=failed,     stage_result=TEST_NEEDS_FIXES
+test-result TEST_BLOCKED         → status=failed,     stage_result=TEST_BLOCKED
+retrospective DOCS_UPDATED       → status=completed,  stage_result=RETRO_COMPLETE
+retrospective NO_DOC_CHANGE      → status=completed,  stage_result=RETRO_COMPLETE
+retrospective blocked            → status=failed,     stage_result=RETRO_BLOCKED
+commit authorization pending     → status=in_progress, stage_result=COMMIT_PENDING
+local commit confirmed           → status=completed,  stage_result=COMMITTED
+commit blocked                   → status=failed,     stage_result=COMMIT_BLOCKED
 ```
 
-`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.
+`DOCS_UPDATED` and `NO_DOC_CHANGE` remain retrospective artifact `result` values. The workflow `stage_result` is the retrospective stage result `RETRO_COMPLETE`.
 
-## Repair Routing
+`TEST_PASS` requires both `test-report.md` and a consistent `test-result.json`. No manifest, attestation, evidence package, or test-internal checkpoint is part of this contract.
 
-```text
-REVIEW_NEEDS_FIXES
-  → implement
-  → code-review
-  → test
-
-TEST_FAIL with repair_scope=test-infrastructure
-  → implement
-  → test
+## Non-Pass Results and Routing Boundary
 
-TEST_FAIL with repair_scope=production|runtime|schema|dependency|public-interface
-  → implement
-  → code-review
-  → test
+`prizmkit-test` performs its own bounded failure repair and review loops before returning. The test skill never invokes another lifecycle stage.
 
-TEST_FAIL with repair_scope=unknown
-  → conservative production route only when safe
-  → otherwise WORKFLOW_BLOCKED
+```text
+TEST_NEEDS_FIXES
+→ known correction or required delta review remains
+→ caller decides whether and how to arrange another stage
 
 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
+→ truth, input, safe environment, or reliable execution prevents a verdict
+→ never make speculative production edits
+→ caller or external host owns recovery policy
 ```
 
-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.
+A test result is not an AI CLI session classification. `TEST_NEEDS_FIXES` and `TEST_BLOCKED` must not be rewritten as crash or infrastructure failure merely because they stop lifecycle progression.
+
+Any outer repair or continuation policy is independently owned by the caller and cannot alter the test report. The Main-Agent test review limit of ten rounds, independent Test Reviewer limit of five responses, and execution-failure repair limit of three rounds are internal to one test invocation and do not update outer counters.
 
 ## 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.
+1. An atomic stage performs only its own stage, writes its truthful result and artifact paths, and returns control.
+2. When `orchestrator` is non-null, only that orchestrator invokes the next skill.
+3. Direct stage use may report a possible next invocation but does not claim it 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.
+5. External automation invokes atomic stages directly and does not nest the composite workflow.
+6. Workflow state never replaces or absorbs an external host checkpoint.
 
 ## Commit Authorization
 
@@ -148,34 +143,32 @@ Interactive execution:
 
 ```text
 committer previews intended files and message
-→ waits for explicit confirmation from the current user
+→ waits for explicit current-user confirmation
 → 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
+trusted host explicitly authorizes the current local task commit
 → committer verifies gates and commits automatically
-→ no question or wait is permitted
+→ remote publication remains separate
 ```
 
-A self-declared or otherwise untrusted headless context does not authorize a commit. Remote publication remains a separate host-runtime decision.
+A self-declared or untrusted headless context does not authorize a commit.
 
 ## 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`.
+1. Reuse current context, then read `spec.md` and `plan.md` only when needed.
+2. Inspect task markers and current workspace.
+3. Read the current review report when needed to establish review authority.
+4. Validate that `test-report.md` and terminal `test-result.json` exist, agree, and reflect the claimed result.
 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.
+7. Let an active external host validate its own checkpoint independently.
 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.
+Stale state never bypasses review, testing, retrospective, commit authorization, or external checkpoint enforcement.