prizmkit 1.1.140 → 1.1.142

package/bundled/dev-pipeline/templates/sections/bugfix-phase-commit-report.md

@@ -1,6 +1,6 @@
 ### Phase 4: Commit & Learn
 
-This phase follows successful automated, manual, or hybrid verification and runs only after the authoritative test gate permits commit.
+This phase follows successful automated, manual, or hybrid verification and runs only after a valid `TEST_PASS` report/result pair permits commit.
 
 **Bug Fix Documentation Policy**:
 - Default: run `/prizmkit-retrospective` with structural sync only.

package/bundled/dev-pipeline/templates/sections/bugfix-phase-diagnose-plan.md

@@ -2,7 +2,7 @@
 
 **Goal**: prove or strongly establish the root cause before editing code.
 
-1. Read `.prizmkit/prizm-docs/root.prizm`, then only the relevant L1/L2 docs for affected modules.
+1. Read `.prizmkit/prizm-docs/root.prizm`, then only the relevant module indexes and detail docs for affected modules.
 2. Trace from the error source to the likely root cause:
    - classify error type;
    - inspect relevant TRAPS/RULES;

package/bundled/dev-pipeline/templates/sections/bugfix-phase-manual-verification.md

@@ -2,7 +2,7 @@
 
 `verification_type` is `{{VERIFICATION_TYPE}}`.
 
-L4 is always headless and must complete manual/hybrid verification automatically. Do not ask for a user, wait for UAT, or stop as `partial`.
+The pipeline session is always headless and must complete manual/hybrid verification automatically. Do not ask for a user, wait for UAT, or stop as `partial`.
 
 1. Select the available non-interactive verification path: browser tooling, CLI/API checks, fixtures, project test commands, or another deterministic local check.
 2. Cover the reported behavior and acceptance criteria; for browser-visible behavior, capture both the original reproduction and post-fix result when the configured tooling is available.

package/bundled/dev-pipeline/templates/sections/bugfix-phase-review.md

@@ -16,4 +16,4 @@ Missing required evidence, an unsafe repair, a failed verification, or failure t
 - `REVIEW_NEEDS_FIXES` → route through bounded implementation/review/test repair; do not commit.
 - `REVIEW_INCOMPLETE` or `REVIEW_INVALID` → inspect progress once, write `failure-log.md`, and stop. Do not accept old or incidental verdict text and do not synthesize a passing result outside the skill.
 
-**Checkpoint update**: Set step `prizmkit-code-review` to `completed` with `stage_result=REVIEW_PASS` only for an accepted valid Final Result.
+**Checkpoint update**: Set step `prizmkit-code-review` to `completed` with `stage_result=REVIEW_PASS` only for an accepted valid Final Result. Set it to `failed` with `stage_result=REVIEW_NEEDS_FIXES` when the review returns known unresolved findings.

package/bundled/dev-pipeline/templates/sections/bugfix-phase-test.md

@@ -1,21 +1,24 @@
 ### Bugfix Test Gate — PrizmKit Test
 
-After Main-Agent code review returns a valid `PASS`, run the mandatory post-review test stage against the same Bugfix artifact root. Implementation and review completion alone can never classify the task complete.
+After Main-Agent Code Review returns `PASS`, run the mandatory test stage against the same Bugfix artifact root:
 
 ```text
 /prizmkit-test scope=this-change artifact_dir=.prizmkit/bugfix/{{BUG_ID}}/
 ```
 
-Read the current structured evidence package under `.prizmkit/test/evidence/<evidence-id>/`: `manifest.json`, `verdict.json`, and `validation.json`. A derived Markdown report is not completion authority. Confirm scope, hashes, final verdict, and validator result before accepting `TEST_PASS`.
+Consume the sibling terminal artifacts:
 
-Gate outcomes and authoritative routing:
+- `.prizmkit/bugfix/{{BUG_ID}}/test-report.md`
+- `.prizmkit/bugfix/{{BUG_ID}}/test-result.json`
 
-- `TEST_PASS`: update the checkpoint handoff and continue to retrospective.
-- `TEST_FAIL` with `repair_scope=test-infrastructure`: return to `/prizmkit-implement`, then return directly to this test gate; do not make speculative production edits.
-- `TEST_FAIL` with `repair_scope=production|runtime|schema|dependency|public-interface`: return to implementation, obtain a fresh code-review result, then return to this test gate.
-- `TEST_FAIL` with an unknown or missing `repair_scope`: record `WORKFLOW_BLOCKED` and leave a safe checkpoint at the test stage; do not guess a production edit.
-- `TEST_BLOCKED`: preserve all evidence and artifacts, perform only bounded automatic environment recovery, then terminate as `WORKFLOW_BLOCKED` with `blocked_reason=test_blocked`. Never edit production speculatively and never ask the user.
+They must agree on the testing result and unresolved items. Do not require an evidence package, manifest, hashes, attestation, or test-internal checkpoint.
 
-The `repair_round` counter is shared with review failures and may not exceed three outer rounds. At the limit, leave a truthful blocked terminal result. Internal code-review convergence has its separate ten-round limit.
+Gate outcomes:
 
-**Checkpoint update**: Only a validated structured `TEST_PASS` may complete `prizmkit-test` with `stage_result=TEST_PASS` plus `manifest`, `verdict`, and `validation` evidence paths, then proceed to retrospective.
+- `TEST_PASS`: mark the test checkpoint step completed and continue to retrospective.
+- `TEST_NEEDS_FIXES`: preserve the report/result and stop truthfully. A high-risk production repair reports `review_required=true` and `review_scope=delta`; the caller owns any review-and-retest route.
+- `TEST_BLOCKED`: preserve the report/result and blocker, then record terminal `WORKFLOW_BLOCKED`. Do not reinterpret the result as a runtime crash or make speculative production edits.
+
+The skill itself diagnoses and repairs valid execution failures for at most three rounds before returning. The caller must not recreate that repair loop or maintain test-internal state.
+
+**Checkpoint update**: Only `TEST_PASS` plus `test-report.md` and `test-result.json` completes `prizmkit-test` and allows retrospective.

package/bundled/dev-pipeline/templates/sections/bugfix-reminders.md

@@ -1,6 +1,6 @@
 ## Reminders
 
-- Use L1 skills: `/prizmkit-plan`, `/prizmkit-implement`, `/prizmkit-code-review`, `/prizmkit-retrospective`, `/prizmkit-committer`.
+- Use the atomic skills: `/prizmkit-plan`, `/prizmkit-implement`, `/prizmkit-code-review`, `/prizmkit-retrospective`, `/prizmkit-committer`.
 - All bugfix skills use `artifact_dir=.prizmkit/bugfix/{{BUG_ID}}/`.
 - The first plan task must prove the bug with a reproduction test when feasible.
 - Commit with `fix(<scope>):`, not `feat:`.

package/bundled/dev-pipeline/templates/sections/checkpoint-system.md

@@ -1,6 +1,6 @@
 ## Workflow Checkpoint System
 
-A checkpoint file tracks this task family's L4 execution. It is not the L1 workflow-state record.
+A checkpoint file tracks this task family's pipeline execution. It is not a skill result or a replacement for skill-owned reports.
 
 **Path**: `{{CHECKPOINT_PATH}}`
 
@@ -13,20 +13,29 @@ Use this helper to update checkpoint status. Do not hand-edit `workflow-checkpoi
   --checkpoint-path {{CHECKPOINT_PATH}} \
   --step <step-id-or-skill-name> \
   --status <in_progress|completed|failed|skipped> \
+  --stage-result <optional-domain-result> \
   --note "<optional note>"
 ```
 
 - Use the step `skill` value such as `prizmkit-implement`, or the step id such as `S04`.
+- Omit `--stage-result` for stages without a domain result.
+- Complete `prizmkit-plan` with `--status completed --stage-result PLAN_READY`.
+- Complete `prizmkit-implement` with `--status completed --stage-result IMPLEMENTED`.
+- Complete `prizmkit-code-review` only with `--status completed --stage-result REVIEW_PASS`.
+- Complete `prizmkit-test` only after validating the sibling report/result pair, with `--status completed --stage-result TEST_PASS`.
+- Complete `prizmkit-retrospective` with `--status completed --stage-result RETRO_COMPLETE`.
+- Record commit authorization wait with `--status in_progress --stage-result COMMIT_PENDING`; after the local commit, use `--status completed --stage-result COMMITTED`.
+- For `TEST_NEEDS_FIXES` or `TEST_BLOCKED`, use `--status failed --stage-result <result>` and preserve its report/result and blocker; never mark the test step completed.
 - Omit `--note` when there is no useful failure or handoff note.
 
 ### Rules
 
-1. Before each skill, read the checkpoint and verify the previous step is `completed` or `skipped`. A pending or in-progress predecessor must be completed first.
-2. Starting a skill marks its step `in_progress`; completion marks it `completed`; failures mark it `failed` and write `failure-log.md`.
-3. L4 checkpoint metadata must preserve `current_stage`, `next_stage`, `stage_result`, `repair_scope`, `repair_round`, `authoritative_evidence_paths`, `blocked_reason`, and `terminal_status`.
-4. `authoritative_evidence_paths` may point only to validated structured `manifest.json`, `verdict.json`, and `validation.json`; a Markdown report is never completion authority.
-5. Preserve all evidence and session artifacts on recovery. Never replace the task family's L1 workflow state with this L4 checkpoint or merge their schemas.
-6. The outer repair round is shared across review/test failures and stops at three. The internal Code Review loop has its separate ten-round limit.
-7. `TEST_BLOCKED`, an unknown result, an unsafe repair scope, or an exhausted third repair round records terminal `WORKFLOW_BLOCKED` with a deterministic `blocked_reason`; never speculate on production edits.
-8. `WORKFLOW_COMPLETED` is valid only when the expected family stage sequence is complete, Code Review records `REVIEW_PASS`, and the test stage records `TEST_PASS` with all three authoritative evidence records.
+1. Before each skill, verify its predecessor is `completed` or `skipped`.
+2. Starting a skill marks its step `in_progress`; a valid success marks it `completed`; a non-pass records its truthful `stage_result` and leaves later stages incomplete.
+3. Pipeline metadata owns only `current_stage`, `next_stage`, `stage_result`, `repair_scope`, `repair_round`, `blocked_reason`, and `terminal_status`; lifecycle `status` belongs to each checkpoint step.
+4. Skills own their reports and terminal results. The pipeline must not duplicate a skill's internal state machine or require evidence manifests, hashes, or attestations.
+5. Preserve all reports and session artifacts on recovery. Never replace skill artifacts with the pipeline checkpoint or merge their schemas.
+6. `TEST_NEEDS_FIXES` is a known testing-domain non-pass. `TEST_BLOCKED` records terminal `WORKFLOW_BLOCKED` with a deterministic reason. Neither is an AI CLI crash.
+7. Any cross-stage continuation or retry policy belongs to the pipeline and must remain separate from the test skill's internal review and repair budgets.
+8. `WORKFLOW_COMPLETED` is valid only when the expected family sequence is complete, Code Review records `REVIEW_PASS`, the test stage records `TEST_PASS`, and every declared artifact exists.
 9. On session exit, leave the checkpoint at the truthful stage. Do not mark future steps completed.

package/bundled/dev-pipeline/templates/sections/headless-commit-authorization.md

@@ -2,7 +2,7 @@
 
 This pipeline session is non-interactive. Do not ask questions, wait for user input, or request commit confirmation.
 
-The pipeline launch has already authorized local commits for this task. Invoke `/prizmkit-committer` with the L4-managed execution context:
+The pipeline launch has already authorized local commits for this task. Invoke `/prizmkit-committer` with the pipeline-managed execution context:
 
 ```json
 {

package/bundled/dev-pipeline/templates/sections/phase-commit-full.md

@@ -15,7 +15,7 @@ git log --oneline
 **b.** Run `/prizmkit-retrospective` (**before commit**, maintains `.prizmkit/prizm-docs/` architecture index):
 1. **Structural sync**: update KEY_FILES/INTERFACES/DEPENDENCIES/file counts for changed modules
 2. **Architecture knowledge**: extract TRAPS, RULES, DECISIONS from completed work into `.prizmkit/prizm-docs/`
-3. **L2 coverage check**: For any module/sub-module with source files created or significantly modified in this session but no L2 `.prizm` doc — evaluate whether L2 is warranted and create if so. The current session has the best context for accurate KEY_FILES, TRAPS, and DECISIONS.
+3. **Detail-doc coverage check**: For any module/sub-module with source files created or significantly modified in this session but no detail `.prizm` doc — evaluate whether one is warranted and create it when needed. The current session has the best context for accurate KEY_FILES, TRAPS, and DECISIONS.
 4. Stage doc changes: `git add .prizmkit/prizm-docs/`
 ⚠️ Do NOT commit here. Only stage.
 

package/bundled/dev-pipeline/templates/sections/phase-commit.md

@@ -3,7 +3,7 @@
 **a.** Run `/prizmkit-retrospective` — maintains `.prizmkit/prizm-docs/` (architecture index):
 1. **Structural sync**: Use `git diff --cached --name-status` to locate changed modules, update KEY_FILES/INTERFACES/DEPENDENCIES/file counts in affected `.prizmkit/prizm-docs/` files
 2. **Architecture knowledge** (feature sessions only): Extract TRAPS/RULES/DECISIONS from completed work into `.prizmkit/prizm-docs/`
-3. **L2 coverage check**: For any module/sub-module with source files created or significantly modified in this session but no L2 `.prizm` doc — evaluate whether L2 is warranted and create if so. The current session has the best context for accurate KEY_FILES, TRAPS, and DECISIONS.
+3. **Detail-doc coverage check**: For any module/sub-module with source files created or significantly modified in this session but no detail `.prizm` doc — evaluate whether one is warranted and create it when needed. The current session has the best context for accurate KEY_FILES, TRAPS, and DECISIONS.
 4. Stage doc changes: `git add .prizmkit/prizm-docs/`
 ⚠️ Do NOT commit here. Only stage.
 

package/bundled/dev-pipeline/templates/sections/phase-context-snapshot-agent-suffix.md

@@ -1,4 +1,4 @@
-   - **Section 3 — Key TRAPS & RULES**: extract only relevant TRAPS/RULES from prizm-docs. Do NOT copy full L0/L1/L2 content — the orchestrator already loaded them.
+   - **Section 3 — Key TRAPS & RULES**: extract only relevant TRAPS/RULES from the loaded Prizm docs. Do NOT copy complete documentation files — the orchestrator already loaded them.
    - **Section 4 — File Manifest**: For each file, list: path, why needed, and a **key-content summary** so you do NOT need to re-read the file. Format depends on file type:
      - **Code files** (JS/TS/Python/Go): function signatures. Example: `config` (Zod object), `loadConfig(path)→Config`.
      - **Shell scripts** (`.sh`): command-line args, key behavior branches, sourced libs, critical line ranges. Example: `args: --feature-id; sources lib/common.sh; lines 120-180 worktree logic`.
@@ -19,6 +19,6 @@
      | `package.json` | Test cmd+deps | scripts:{test:vitest}, deps:{vitest} |
 
      ### Known TRAPS (from .prizmkit/prizm-docs/)
-     - <trap entries extracted from L1/L2 docs>
+     - <trap entries extracted from the loaded Prizm docs>
 
 

package/bundled/dev-pipeline/templates/sections/phase-context-snapshot-base.md

@@ -5,7 +5,7 @@
 ```
 
 If MISSING — build it now:
-1. Read `.prizmkit/prizm-docs/root.prizm` and relevant L1/L2 prizm docs
+1. Read `.prizmkit/prizm-docs/root.prizm` and the relevant module indexes and detail docs
 2. Read source files listed in the feature's scope (use prizm-docs KEY_FILES for guidance)
 3. Write `.prizmkit/specs/{{FEATURE_SLUG}}/context-snapshot.md`:
    - **Section 1 — Feature Brief**: 2-3 line feature description from Task Contract

package/bundled/dev-pipeline/templates/sections/phase-context-snapshot-lite-suffix.md

@@ -1,4 +1,4 @@
-   - **Section 3 — Key TRAPS & RULES**: extract only relevant TRAPS/RULES from prizm-docs that apply to files in this scope. Do NOT copy full L0/L1/L2 content.
+   - **Section 3 — Key TRAPS & RULES**: extract only relevant TRAPS/RULES from the loaded Prizm docs that apply to files in this scope. Do NOT copy complete documentation files.
    - **Section 4 — File Manifest**: For each relevant file, list path, why needed, key interface signatures. Use table format:
 
      ### Files to Modify

package/bundled/dev-pipeline/templates/sections/phase-implement-lite.md

@@ -11,7 +11,7 @@
 - If implementation is delegated to a subagent, the subagent must read `plan.md` and `context-snapshot.md` before editing
 - Uses context from `context-snapshot.md` (Prizm docs, TRAPS, file manifest) for targeted source reads; avoid re-reading source files already summarized there unless they changed after the snapshot
 - Implements task-by-task, marking each `[x]` immediately
-- Creates/updates L2 `.prizm` docs when creating new modules or significantly modifying existing ones — AI selectively decides which modules warrant L2 based on complexity and importance
+- Creates/updates detail `.prizm` docs when creating new modules or significantly modifying existing ones — AI selectively decides which modules warrant detail documentation based on complexity and importance
 - Does not run the scoped/full test gate; testing happens after code review in the PrizmKit Test phase
 - Writes '## Implementation Log' to `context-snapshot.md`
 

package/bundled/dev-pipeline/templates/sections/phase-prizmkit-test.md

@@ -1,42 +1,30 @@
 ### Scoped Feature Test Gate — PrizmKit Test
 
-**Goal**: After Code Review completes, generate and verify tests for this Feature's changed scope through `/prizmkit-test`. Review is a hard precondition for accepting any full test result.
+**Goal**: After Code Review completes, use `/prizmkit-test` to analyze the complete affected business module and Regression Ring, add project-native tests, repair valid failures within the skill's bounded loop, and produce the terminal report/result pair.
 
-Create a current-run marker immediately before invoking the skill:
-
-```bash
-{{RUNTIME_HELPER_CMD}} artifact ensure-dir .prizmkit/specs/{{FEATURE_SLUG}}
-{{RUNTIME_HELPER_CMD}} artifact touch .prizmkit/specs/{{FEATURE_SLUG}}/.prizmkit-test-started
-```
-
-Run `/prizmkit-test` with the Feature artifact directory. This gate is Feature-only: never substitute `.prizmkit/bugfix/` or `.prizmkit/refactor/` artifact roots.
+Run the skill with the current Feature artifact directory:
 
 ```text
 /prizmkit-test scope=this-change artifact_dir=.prizmkit/specs/{{FEATURE_SLUG}}/
 ```
 
-## Authoritative Evidence Gate
+## Testing Result Gate
 
-The report is a derived view only. Its historical Boundary Matrix and Boundary Completion Gate are useful context but never completion authority. A valid derived view may state `Boundary-missing: 0`, `Happy-path-only: 0`, `Completion gate passed: yes`, and `Validator result: passed`, but those Markdown fields cannot establish success. Locate the evidence package through `.prizmkit/specs/{{FEATURE_SLUG}}/test-report-path.txt`, then consume and validate these structured records:
+Consume these sibling terminal artifacts:
 
-- `.prizmkit/test/evidence/<evidence-id>/manifest.json`
-- `.prizmkit/test/evidence/<evidence-id>/verdict.json`
-- `.prizmkit/test/evidence/<evidence-id>/validation.json`
+- `.prizmkit/specs/{{FEATURE_SLUG}}/test-report.md`
+- `.prizmkit/specs/{{FEATURE_SLUG}}/test-result.json`
 
-Before accepting `TEST_PASS`, verify all three records are present, JSON is complete and non-duplicated, the evidence ID and scope match this Feature, every manifest-listed file hash matches, `final_verdict` and `verdict.verdict` agree, `validation.result=passed`, `validation.verdict` agrees, validator/payload hashes are present, the compatibility boundary rejects the legacy report interface, and current inventoried target hashes still match. Never accept a Markdown-only report or a Markdown `PASS` as completion evidence.
+The JSON is the minimal terminal result projection and the report contains semantic coverage, native execution, Main-Agent review, optional independent Test Reviewer, and repair details. They must agree. Do not require an evidence package, manifest, hashes, attestation, package lifecycle, or test-internal checkpoint.
 
-## Repair Routing
+## Caller Routing
 
-Preserve the same artifact directory and update the L1 workflow state plus this L4 checkpoint with `current_stage`, `next_stage`, `stage_result`, `repair_scope`, `repair_round`, authoritative evidence paths, `blocked_reason`, and `terminal_status`. L1 workflow state and `workflow-checkpoint.json` are separate contracts; never substitute one for the other.
+The caller checkpoint records only the returned testing result and caller-owned routing state. It must not ask the skill to manage sessions or checkpoints.
 
-- `REVIEW_NEEDS_FIXES` → `prizmkit-implement` → `prizmkit-code-review` → `prizmkit-test`.
-- `TEST_FAIL` with `repair_scope=test-infrastructure` → `prizmkit-implement` → `prizmkit-test`; do not make speculative production edits.
-- `TEST_FAIL` with `repair_scope=production|runtime|schema|dependency|public-interface` → `prizmkit-implement` → `prizmkit-code-review` → `prizmkit-test`.
-- `TEST_FAIL` with unknown or unsafe scope → do not guess a production edit; record `WORKFLOW_BLOCKED` and a safe resume entry.
-- `TEST_BLOCKED` → preserve all evidence and artifacts, perform only bounded environment recovery, then finish terminal `WORKFLOW_BLOCKED` with `blocked_reason=test_blocked`; never edit production speculatively. When a finalized blocked package exists, pass its validated `manifest`, `verdict`, and `validation` paths to the checkpoint; do not leave these paths null.
-- The builder's evidence-protocol recovery budget is separate from the outer `repair_round`: after bounded preflight/package attempts, stop creating evidence versions and return `TEST_BLOCKED`.
-- The outer `repair_round` is shared across review/test failures and may not exceed three. The Code Review internal loop limit remains separate and is at most ten completed rounds.
+- `TEST_PASS` → mark `prizmkit-test` completed and continue to retrospective.
+- `TEST_NEEDS_FIXES` → stop the current caller path truthfully. If `review_required=true` and `review_scope=delta`, a caller may route the repaired delta through Code Review before invoking test again. Any continuation policy is caller-owned, not part of the test skill.
+- `TEST_BLOCKED` → preserve the report, result, and blocker; record terminal `WORKFLOW_BLOCKED`. Do not reinterpret it as an AI CLI crash or perform speculative production edits.
 
-A missing, stale, incomplete, mismatched, tampered, or wrong-scope package is not `TEST_PASS`: preserve the evidence, write `failure-log.md`, and leave the checkpoint resumable or blocked according to headless policy.
+A test execution failure inside the skill is not automatically terminal: `/prizmkit-test` owns up to three direct diagnosis-and-repair rounds. The caller handles only the terminal result returned after that loop.
 
-**CP-4**: Only a validated structured `TEST_PASS` may complete `prizmkit-test` with `stage_result=TEST_PASS` plus `manifest`, `verdict`, and `validation` evidence paths, then proceed to retrospective. `TEST_FAIL` and `TEST_BLOCKED` remain in the repair/recovery state machine.
+**CP-4**: `TEST_PASS` plus the required `test-report.md` and `test-result.json` completes the test step. `TEST_NEEDS_FIXES` and `TEST_BLOCKED` are truthful non-pass testing results and cannot complete later stages.

package/bundled/dev-pipeline/templates/sections/phase-review-full.md

@@ -4,8 +4,8 @@ Review the completed implementation before the full Feature test gate runs. A re
 
 Use `artifact_dir=.prizmkit/specs/{{FEATURE_SLUG}}/` so `/prizmkit-code-review` can read the spec, plan, context snapshot, implementation log, and current diff. Follow the skill's current review contract for review execution, repairs, verification, evidence, and handoff. Do not invoke another review skill or add a second review path outside that contract.
 
-- `REVIEW_PASS` → update checkpoint metadata with `stage=code-review`, `status=REVIEW_PASS`, `stage_result=REVIEW_PASS`, `next_stage=prizmkit-test`, and `resume_from=prizmkit-test`; then run the full test gate.
-- `REVIEW_NEEDS_FIXES` → preserve findings, increment the shared outer `repair_round`, route `prizmkit-implement` → `prizmkit-code-review` → `prizmkit-test`, and do not accept any test result from before the repaired review.
+- `REVIEW_PASS` → update checkpoint metadata with `stage=code-review`, `status=completed`, `stage_result=REVIEW_PASS`, `next_stage=prizmkit-test`, and `resume_from=prizmkit-test`; then run the full test gate.
+- `REVIEW_NEEDS_FIXES` → update the review step with `status=failed` and `stage_result=REVIEW_NEEDS_FIXES`, preserve findings, increment the shared outer `repair_round`, route `prizmkit-implement` → `prizmkit-code-review` → `prizmkit-test`, and do not accept any test result from before the repaired review.
 - If the outer repair round is already three, record `WORKFLOW_BLOCKED`; do not start another repair route.
 
 Missing required evidence, unsafe repair, failed verification, or failure to converge under the review contract produces `REVIEW_NEEDS_FIXES`.

package/bundled/dev-pipeline/templates/sections/phase-specify-plan-full.md

@@ -20,7 +20,7 @@ If `EXISTING_CODE` is non-empty: your spec/plan/tasks must reflect this existing
 
 **Step A — Build Context Snapshot** (skip if `context-snapshot.md` already exists):
 
-1. Read `.prizmkit/prizm-docs/root.prizm` and relevant L1/L2 prizm docs
+1. Read `.prizmkit/prizm-docs/root.prizm` and the relevant module indexes and detail docs
 2. Detect source code directories from KEY_FILES and STRUCTURE sections in `root.prizm`; if root docs are unavailable, use the helper to list likely source files:
    ```bash
    {{RUNTIME_HELPER_CMD}} artifact source-files . --json
@@ -30,7 +30,7 @@ If `EXISTING_CODE` is non-empty: your spec/plan/tasks must reflect this existing
 4. Write `.prizmkit/specs/{{FEATURE_SLUG}}/context-snapshot.md`:
    - **Section 1 — Feature Brief**: feature description (copy from Task Contract above, 2-3 lines only)
    - **Section 2 — Verification Gates**: copy the gate checklist from the Task Contract above
-   - **Section 3 — Key TRAPS & RULES**: extract TRAPS and RULES entries from loaded prizm-docs that apply to files in this feature's scope. Do NOT copy full L0/L1/L2 content — only the specific TRAPS/RULES lines relevant to the files listed in Section 4.
+   - **Section 3 — Key TRAPS & RULES**: extract TRAPS and RULES entries from the loaded Prizm docs that apply to files in this feature's scope. Do NOT copy complete documentation files — include only the specific TRAPS/RULES lines relevant to the files listed in Section 4.
    - **Section 4 — File Manifest**: For each file relevant to this feature, list path, why needed (modify/reference/test), key interface signatures. Do NOT include full file content. Format:
      ### Files to Modify
      | File | Why Needed | Key Interfaces |
@@ -43,7 +43,7 @@ If `EXISTING_CODE` is non-empty: your spec/plan/tasks must reflect this existing
      | `<source-dir>/security/permission-guard.js` | Permission check integration | `checkCommandPermission(userId, cmd)` |
 
      ### Known TRAPS (from .prizmkit/prizm-docs/)
-     - <trap entries extracted from L1/L2 docs>
+     - <trap entries extracted from the loaded Prizm docs>
 5. Confirm: `{{RUNTIME_HELPER_CMD}} artifact exists .prizmkit/specs/{{FEATURE_SLUG}}/context-snapshot.md`
 
 **After Step A**: Use context-snapshot.md Section 4 File Manifest to guide targeted file reads. Do NOT scan directories or read unrelated files.

package/bundled/dev-pipeline/templates/sections/refactor-phase-review.md

@@ -16,4 +16,4 @@ Missing required evidence, an unsafe repair, a failed verification, or failure t
 
 Verify directly that the review checks behavior preservation, public API compatibility, imports, tests, and rollback assumptions.
 
-**Checkpoint update**: Set step `prizmkit-code-review` to `completed` with `stage_result=REVIEW_PASS` only for an accepted valid Final Result. Do not complete the checkpoint for incomplete or invalid reports.
+**Checkpoint update**: Set step `prizmkit-code-review` to `completed` with `stage_result=REVIEW_PASS` only for an accepted valid Final Result. Set it to `failed` with `stage_result=REVIEW_NEEDS_FIXES` when the review returns known unresolved findings. Do not complete the checkpoint for incomplete or invalid reports.

package/bundled/dev-pipeline/templates/sections/refactor-phase-test.md

@@ -1,21 +1,24 @@
 ### Refactor Test Gate — PrizmKit Test
 
-After Main-Agent code review returns a valid `PASS`, run the mandatory post-review test stage against the same Refactor artifact root. Behavior-preservation checks collected during planning and implementation remain supporting evidence; they never replace this authoritative evidence gate.
+After Main-Agent Code Review returns `PASS`, run the mandatory test stage against the same Refactor artifact root. Existing behavior-preservation context is input to testing; the final current-state native executions remain required.
 
 ```text
 /prizmkit-test scope=this-change artifact_dir=.prizmkit/refactor/{{REFACTOR_ID}}/
 ```
 
-Read the current structured evidence package under `.prizmkit/test/evidence/<evidence-id>/`: `manifest.json`, `verdict.json`, and `validation.json`. A derived Markdown report is not completion authority. Confirm scope, hashes, final verdict, and validator result before accepting `TEST_PASS`.
+Consume the sibling terminal artifacts:
 
-Gate outcomes and authoritative routing:
+- `.prizmkit/refactor/{{REFACTOR_ID}}/test-report.md`
+- `.prizmkit/refactor/{{REFACTOR_ID}}/test-result.json`
 
-- `TEST_PASS`: verify behavior-preservation evidence remains recorded, update the checkpoint handoff, and continue to retrospective.
-- `TEST_FAIL` with `repair_scope=test-infrastructure`: return to `/prizmkit-implement`, preserve the behavior baseline, then return directly to this test gate; do not make speculative production edits.
-- `TEST_FAIL` with `repair_scope=production|runtime|schema|dependency|public-interface`: return to implementation, obtain a fresh code-review result, then return to this test gate.
-- `TEST_FAIL` with an unknown or missing `repair_scope`: record `WORKFLOW_BLOCKED` and leave a safe checkpoint at the test stage; do not guess a production edit.
-- `TEST_BLOCKED`: preserve all evidence and artifacts, perform only bounded automatic environment recovery, then terminate as `WORKFLOW_BLOCKED` with `blocked_reason=test_blocked`. Never edit production speculatively and never ask the user.
+They must agree on the testing result and unresolved items. Do not require an evidence package, manifest, hashes, attestation, or test-internal checkpoint.
 
-The `repair_round` counter is shared with review failures and may not exceed three outer rounds. At the limit, leave a truthful blocked terminal result. Internal code-review convergence has its separate ten-round limit.
+Gate outcomes:
 
-**Checkpoint update**: Only a validated structured `TEST_PASS` may complete `prizmkit-test` with `stage_result=TEST_PASS` plus `manifest`, `verdict`, and `validation` evidence paths, then proceed to retrospective.
+- `TEST_PASS`: verify required behavior-preservation coverage is included, mark the test step completed, and continue to retrospective.
+- `TEST_NEEDS_FIXES`: preserve the report/result and stop truthfully. A high-risk production repair reports `review_required=true` and `review_scope=delta`; the caller owns any review-and-retest route.
+- `TEST_BLOCKED`: preserve the report/result and blocker, then record terminal `WORKFLOW_BLOCKED`. Do not reinterpret the result as a runtime crash or make speculative production edits.
+
+The skill itself diagnoses and repairs valid execution failures for at most three rounds before returning. The caller must not recreate that repair loop or maintain test-internal state.
+
+**Checkpoint update**: Only `TEST_PASS` plus `test-report.md` and `test-result.json` completes `prizmkit-test` and allows retrospective.

package/bundled/dev-pipeline/templates/sections/refactor-reminders.md

@@ -1,6 +1,6 @@
 ## Reminders
 
-- Use L1 skills: `/prizmkit-plan`, `/prizmkit-implement`, `/prizmkit-code-review`, `/prizmkit-retrospective`, `/prizmkit-committer`.
+- Use the atomic skills: `/prizmkit-plan`, `/prizmkit-implement`, `/prizmkit-code-review`, `/prizmkit-retrospective`, `/prizmkit-committer`.
 - All refactor skills use `artifact_dir=.prizmkit/refactor/{{REFACTOR_ID}}/`.
 - Behavior preservation is the first priority.
 - Follow the active skills and runtime contracts; they determine execution topology, review ownership, and delegation boundaries

package/bundled/dev-pipeline/templates/session-status-schema.json

@@ -15,7 +15,7 @@
     },
     "status": {
       "type": "string",
-      "enum": ["success", "partial", "failed", "commit_missing", "docs_missing", "merge_conflict", "context_overflow"]
+      "enum": ["success", "partial", "failed", "crashed", "timed_out", "infra_error", "commit_missing", "docs_missing", "merge_conflict", "context_overflow", "stalled_context_continuation", "workflow_blocked", "workflow_skipped"]
     },
     "completed_phases": {
       "type": "array",