prizmkit 1.1.139 → 1.1.141

package/bundled/dev-pipeline/templates/bugfix-bootstrap-prompt.md

@@ -104,7 +104,7 @@ Use this protocol only when the bug is UI/frontend-reproducible. Evidence must c
 
 **Step 1 — Diagnose the bug**:
 
-1. Read `.prizmkit/prizm-docs/root.prizm` and relevant L1/L2 docs for affected modules
+1. Read `.prizmkit/prizm-docs/root.prizm` and the relevant module indexes and detail docs for affected modules
 2. Trace the bug:
    - Classify error type (Runtime / Network / Auth / Data / Logic / Config / External)
    - Check `.prizmkit/prizm-docs/` TRAPS sections for matching known issues
@@ -203,18 +203,18 @@ Handle `REVIEW_PASS` and `REVIEW_NEEDS_FIXES` according to task policy. `REVIEW_
 
 ### Phase 4: Post-Review Test Gate — PrizmKit Test
 
-After a valid code-review PASS, run the mandatory authoritative test gate against the same artifact root:
+After a valid code-review PASS, run the mandatory test gate against the same artifact root:
 
 ```text
 /prizmkit-test scope=this-change artifact_dir=.prizmkit/bugfix/{{BUG_ID}}/
 ```
 
-Read the current structured `manifest.json`, `verdict.json`, and `validation.json`; Markdown alone is never completion authority. `TEST_FAIL` with `test-infrastructure` returns through implementation directly to test. Production/runtime/schema/dependency/public-interface fixes return through implementation, fresh review, and test. Unknown scope is blocked. `TEST_BLOCKED` permits bounded automatic environment recovery at the test stage or terminal `WORKFLOW_BLOCKED`, never speculative production edits. The shared outer repair cap is three.
+Read the sibling `test-report.md` and `test-result.json`; they must agree. `TEST_PASS` proceeds to retrospective and commit. `TEST_NEEDS_FIXES` preserves the known correction or delta-review requirement and stops truthfully. `TEST_BLOCKED` preserves its blocker and records `WORKFLOW_BLOCKED`. Do not require a manifest/attestation package, reinterpret the testing result as a runtime crash, or recreate the skill's internal loops.
 
-Only validated `TEST_PASS` may proceed to commit.
+Only `TEST_PASS` may proceed to commit.
 
 {{IF_VERIFICATION_MANUAL_OR_HYBRID}}
-**MANUAL/HYBRID AUTOMATION**: This L4 session is always headless. Execute manual/hybrid verification with available deterministic browser, CLI/API, fixture, or test tooling. Document the method and evidence, then continue through `/prizmkit-retrospective` and `/prizmkit-committer`; never ask for UAT, wait for a user, or stop as `partial`.
+**MANUAL/HYBRID AUTOMATION**: This pipeline session is always headless. Execute manual/hybrid verification with available deterministic browser, CLI/API, fixture, or test tooling. Document the method and verification basis, then continue through `/prizmkit-retrospective` and `/prizmkit-committer`; never ask for UAT, wait for a user, or stop as `partial`.
 - Do not write `verifying` to the external bug-list status field; fine-grained verification is session/checkpoint metadata, while the external list status remains one of `pending`, `in_progress`, `completed`, `failed`, `skipped`, or `needs_info`.
 {{END_IF_VERIFICATION_MANUAL_OR_HYBRID}}
 
@@ -224,7 +224,7 @@ Only validated `TEST_PASS` may proceed to commit.
 
 ### Headless Commit Authorization
 
-This pipeline launch authorizes one local task commit only after review and authoritative test evidence pass. Never ask a question, wait for input, or request confirmation. Invoke `/prizmkit-committer` with `mode=l4-headless`, `owner=prizmkit-l4`, and `local_commit_authorized=true`. The runtime controls any optional remote publication after the local commit; do not make a publication decision in this session.
+This pipeline launch authorizes one local task commit only after Code Review and a consistent `TEST_PASS` report/result pair. Never ask a question, wait for input, or request confirmation. Invoke `/prizmkit-committer` with `mode=l4-headless`, `owner=prizmkit-l4`, and `local_commit_authorized=true`. The runtime controls any optional remote publication after the local commit; do not make a publication decision in this session.
 
 **Bug Fix Documentation Policy**:
 - **DEFAULT**: Run `/prizmkit-retrospective` with structural sync only (Job 1). Skip knowledge injection.

package/bundled/dev-pipeline/templates/refactor-bootstrap-prompt.md

@@ -159,15 +159,15 @@ Handle `REVIEW_PASS` and `REVIEW_NEEDS_FIXES` according to behavior-preservation
 
 ### Phase 5: Post-Review Test Gate — PrizmKit Test
 
-After a valid code-review PASS, run the mandatory authoritative test gate against the same artifact root:
+After a valid code-review PASS, run the mandatory test gate against the same artifact root:
 
 ```text
 /prizmkit-test scope=this-change artifact_dir=.prizmkit/refactor/{{REFACTOR_ID}}/
 ```
 
-Behavior-preservation checks remain supporting evidence and never replace current structured `manifest.json`, `verdict.json`, and `validation.json`. `TEST_FAIL` with `test-infrastructure` returns through implementation directly to test. Production/runtime/schema/dependency/public-interface fixes return through implementation, fresh review, and test. Unknown scope is blocked. `TEST_BLOCKED` permits bounded automatic environment recovery at the test stage or terminal `WORKFLOW_BLOCKED`, never speculative production edits. The shared outer repair cap is three.
+Behavior-preservation context remains supporting input. Read the sibling `test-report.md` and `test-result.json`; they must agree. `TEST_PASS` proceeds to browser verification or retrospective. `TEST_NEEDS_FIXES` preserves the known correction or delta-review requirement and stops truthfully. `TEST_BLOCKED` preserves its blocker and records `WORKFLOW_BLOCKED`. Do not require a manifest/attestation package, reinterpret the testing result as a runtime crash, or recreate the skill's internal loops.
 
-Only validated `TEST_PASS` may proceed to browser verification or commit.
+Only `TEST_PASS` may proceed to browser verification or commit.
 
 ---
 
@@ -187,7 +187,7 @@ Record tool choice, URL, steps, screenshot path if available, result, and cleanu
 
 ### Headless Commit Authorization
 
-This pipeline launch authorizes one local task commit only after review, authoritative test evidence, and required behavior-preservation gates pass. Never ask a question, wait for input, or request confirmation. Invoke `/prizmkit-committer` with `mode=l4-headless`, `owner=prizmkit-l4`, and `local_commit_authorized=true`. The runtime controls any optional remote publication after the local commit; do not make a publication decision in this session.
+This pipeline launch authorizes one local task commit only after Code Review, a consistent `TEST_PASS` report/result pair, and required behavior-preservation gates pass. Never ask a question, wait for input, or request confirmation. Invoke `/prizmkit-committer` with `mode=l4-headless`, `owner=prizmkit-l4`, and `local_commit_authorized=true`. The runtime controls any optional remote publication after the local commit; do not make a publication decision in this session.
 
 Run `/prizmkit-retrospective` using the current working tree and staged changes as input context. Do not rely only on `git diff --cached`.
 
@@ -266,7 +266,7 @@ Before exiting, write `{{SESSION_STATUS_PATH}}`:
 
 ## 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`.
 - Follow the active skills and runtime contracts; they determine execution topology, review ownership, and delegation boundaries
 - On execution-unit timeout, preserve the active checkout and artifacts and follow the owning contract's recovery or downgrade path
 - Behavior preservation is the first priority.

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-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,25 @@ 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-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`.
+- 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`.
+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-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-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