prizmkit 1.1.69 → 1.1.70

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

@@ -19,7 +19,7 @@ ls .prizmkit/specs/{{FEATURE_SLUG}}/ 2>/dev/null
    Identify the top-level source directories from the results.
 3. Scan the detected source directories for files related to this feature; read each one
 4. Write `.prizmkit/specs/{{FEATURE_SLUG}}/context-snapshot.md`:
-   - **Section 1 — Task Brief**: task description + acceptance criteria (copy from above)
+   - **Section 1 — Task Contract**: Objective, scope rule, non-scope rule, and Verification Gates from the Task Contract above
    - **Section 2 — Project Structure**: run the following to get a visual directory tree, then paste output:
      ```bash
      find . -maxdepth 2 -type d -not -path '*/node_modules/*' -not -path '*/.git/*' -not -path '*/dist/*' -not -path '*/build/*' -not -path '*/__pycache__/*' -not -path '*/vendor/*' | sed -e 's;[^/]*/;|____;g;s;____|; |;g'

package/bundled/dev-pipeline/templates/sections/task-contract.md

@@ -0,0 +1,34 @@
+## Task Contract
+
+This section defines the only work that belongs to this session.
+
+### Objective
+
+Implement {{FEATURE_ID}}: "{{FEATURE_TITLE}}".
+
+{{FEATURE_DESCRIPTION}}
+
+### Scope Rule
+
+Current scope is limited to the intersection of:
+
+1. The Objective above
+2. The Verification Gates below
+3. Dependencies required to complete those gates
+
+Raw user context, project brief, and completed dependency notes are authoritative context, but they do not expand scope by themselves.
+
+### Non-Scope Rule
+
+Do NOT implement unrelated backlog items, already completed features, or adjacent modules unless they are required by the Objective or a Verification Gate.
+
+### Verification Gates
+
+These gates are generated from `feature.acceptance_criteria` and are the only acceptance requirements for this session.
+
+{{AC_CHECKLIST}}
+
+Gate rule:
+- `[x]` means verified with implementation or test evidence.
+- Any remaining `[ ]` means the feature is incomplete.
+- If a gate is blocked, document the reason in `failure-log.md`; blocked is not success.

package/bundled/dev-pipeline/templates/sections/test-failure-recovery-agent.md

@@ -1,67 +1,48 @@
 ## Test Failure Recovery Protocol
 
-When tests fail during implementation (Phase 3 / Phase 4), use **convergence-based recovery** — keep fixing as long as progress is being made.
+Use this protocol whenever implementation or review tests fail. Its purpose is to distinguish tolerated pre-existing failures from blockers introduced by this session.
 
-### Recovery Loop
-
-1. **Run tests and record results**:
-   - Count total failures and note which tests failed
-   - Compare against baseline (BASELINE_FAILURES) — exclude pre-existing failures
-
-2. **Check termination conditions** (evaluate BEFORE each fix attempt):
-   - **All tests pass** → Done. Exit recovery loop.
-   - **Plateau detected** — same failure count AND same failing tests for 3 consecutive rounds → AI cannot resolve these failures. Document and exit.
-   - **Still making progress** — failure count decreased compared to previous round → Continue fixing.
-   - **First round** — no history yet → Proceed to fix.
-
-3. **Fix and iterate**:
-   - Analyze remaining failures: root cause (code bug vs. test brittleness vs. environment issue)
-   - Categorize:
-     - **Pre-existing baseline failure**: Expected, do NOT fix
-     - **New regression**: Fix the code
-     - **Brittle test**: Fix the test or environment setup
-   - Apply fix, re-run `($TEST_CMD)`, go back to step 1
+### Failure Classes
 
-### Convergence Tracking
+| Class | Meaning | Required Action | May Continue? |
+|-------|---------|-----------------|---------------|
+| Baseline failure | Existed before this session | Document in Implementation Log or review notes | Yes |
+| New regression | Introduced by this session | Fix before reporting success | No |
+| Brittle test | Test expectation/setup is wrong for the intended behavior | Fix the test or environment setup, then rerun | Only after fixed or documented as blocked |
+| Environment/tooling failure | External tool, network, install, or local environment prevents verification | Document in `failure-log.md` with impact on gates | Only if no Verification Gate is blocked |
 
-Track failures each round. Example: 5→3→3→3→3 = plateau at round 3, stop at round 5 (3/3).
+### Recovery Loop
 
-**Key rule**: If failures decrease (even by 1), the plateau counter resets to 0.
+1. Run tests and record: failing test names, failure count, and class for each failure.
+2. Compare with `BASELINE_FAILURES`; never blame baseline failures on this feature.
+3. Fix new regressions and brittle tests while progress is being made.
+4. Stop after a plateau: same failure count and same failing tests for 3 consecutive rounds.
+5. If failures decrease, reset the plateau counter.
 
-### Escalation — Dev + Reviewer Workflow
+### Success Rule
 
-When the recovery loop exits with remaining failures:
-- Dev appends failure details to Implementation Log
-- Reviewer agent runs full test suite in Phase 5
-- If Reviewer confirms NEW regressions (not in baseline): mark verdict as `NEEDS_FIXES`
-- If Reviewer confirms only baseline failures remain: proceed with `PASS_WITH_WARNINGS`
+Proceed to review only when:
 
-### Context-Aware Test Re-run (Performance Optimization)
+1. all new regressions are fixed;
+2. baseline failures are documented;
+3. every Verification Gate is verified.
 
-**Skip redundant re-runs**:
-- If Implementation Log section in context-snapshot.md already confirms "all tests passing"
-- → Skip Phase 5 test suite re-run (Reviewer will verify baseline log instead)
-- This avoids rebuilding/re-running tests when already verified
+Blocked gates are not success. If any gate cannot be verified, follow the Blocked Rule.
 
-**When to re-run**:
-- If Implementation Log is missing or incomplete
-- If any new code was added after the last test run
-- If Reviewer suspects brittleness or environment drift
+### Blocked Rule
 
-### Failure Capture Rules
+If a remaining failure prevents any Verification Gate from being verified, the feature is incomplete. Write `failure-log.md` and do not report success.
 
-If tests remain broken after recovery:
+### Failure Capture Format
 
-```
+```markdown
 ## Test Failures Encountered
 
 - **Test**: [test name/path]
   - Root Cause: [explanation]
-  - Category: [pre-existing baseline | new regression | brittle test | environment]
+  - Category: [baseline failure | new regression | brittle test | environment/tooling]
   - Rounds Attempted: [N rounds, plateau at round M]
-  - Status: [still failing | requires next session | known limitation]
+  - Status: [fixed | still failing | blocked]
 
-- **Impact on Feature**: [can AC be verified despite failure | blocks AC verification]
+- **Impact on Verification Gates**: [verified | not affected | blocked + reason]
 ```
-
-**Rule**: If any AC cannot be verified due to test failure, the feature is incomplete. Document in failure-log.md for next session.

package/bundled/dev-pipeline/templates/sections/test-failure-recovery-lite.md

@@ -1,58 +1,48 @@
 ## Test Failure Recovery Protocol
 
-When tests fail during implementation, use **convergence-based recovery** — keep fixing as long as progress is being made.
+Use this protocol whenever implementation tests fail. Its purpose is to distinguish tolerated pre-existing failures from blockers introduced by this session.
 
-### Recovery Loop
-
-1. **Run tests and record results**:
-   - Count total failures and note which tests failed
-   - Compare against baseline (BASELINE_FAILURES) — exclude pre-existing failures
-
-2. **Check termination conditions** (evaluate BEFORE each fix attempt):
-   - **All tests pass** → Done. Exit recovery loop.
-   - **Plateau detected** — same failure count AND same failing tests for 3 consecutive rounds → AI cannot resolve these failures. Document and exit.
-   - **Still making progress** — failure count decreased compared to previous round → Continue fixing.
-   - **First round** — no history yet → Proceed to fix.
+### Failure Classes
 
-3. **Fix and iterate**:
-   - Analyze remaining failures: root cause (code bug vs. test brittleness vs. environment issue)
-   - Categorize:
-     - **Pre-existing baseline failure**: Expected, do NOT fix
-     - **New regression**: Fix the code
-     - **Brittle test**: Fix the test or environment setup
-   - Apply fix, re-run `($TEST_CMD)`, go back to step 1
+| Class | Meaning | Required Action | May Continue? |
+|-------|---------|-----------------|---------------|
+| Baseline failure | Existed before this session | Document in Implementation Log | Yes |
+| New regression | Introduced by this session | Fix before reporting success | No |
+| Brittle test | Test expectation/setup is wrong for the intended behavior | Fix the test or environment setup, then rerun | Only after fixed or documented as blocked |
+| Environment/tooling failure | External tool, network, install, or local environment prevents verification | Document in `failure-log.md` with impact on gates | Only if no Verification Gate is blocked |
 
-### Convergence Tracking
+### Recovery Loop
 
-Track failures each round. Example: 5→3→3→3→3 = plateau at round 3, stop at round 5 (3/3).
+1. Run tests and record: failing test names, failure count, and class for each failure.
+2. Compare with `BASELINE_FAILURES`; never blame baseline failures on this feature.
+3. Fix new regressions and brittle tests while progress is being made.
+4. Stop after a plateau: same failure count and same failing tests for 3 consecutive rounds.
+5. If failures decrease, reset the plateau counter.
 
-**Key rule**: If failures decrease (even by 1), the plateau counter resets to 0.
+### Success Rule
 
-### Escalation — Single Agent
+Proceed only when:
 
-When the recovery loop exits with remaining failures:
-- Document all remaining failures in Implementation Log with root cause analysis
-- Record PARTIAL status with known failure list
-- **Do NOT block commit** — unresolved test failures are deferred to next session
+1. all new regressions are fixed;
+2. baseline failures are documented;
+3. every Verification Gate is verified.
 
-### Context-Aware Optimization
+Blocked gates are not success. If any gate cannot be verified, follow the Blocked Rule.
 
-**Skip redundant re-runs**: If Implementation Log already confirms "all tests passing", skip full suite re-run.
+### Blocked Rule
 
-### Failure Capture Rules
+If a remaining failure prevents any Verification Gate from being verified, the feature is incomplete. Write `failure-log.md` and do not report success.
 
-If tests remain broken after recovery:
+### Failure Capture Format
 
-```
+```markdown
 ## Test Failures Encountered
 
 - **Test**: [test name/path]
   - Root Cause: [explanation]
-  - Category: [pre-existing baseline | new regression | brittle test | environment]
+  - Category: [baseline failure | new regression | brittle test | environment/tooling]
   - Rounds Attempted: [N rounds, plateau at round M]
-  - Status: [still failing | requires next session | known limitation]
+  - Status: [fixed | still failing | blocked]
 
-- **Impact on Feature**: [can AC be verified despite failure | blocks AC verification]
+- **Impact on Verification Gates**: [verified | not affected | blocked + reason]
 ```
-
-**Rule**: If any AC cannot be verified due to test failure, the feature is incomplete. Document in failure-log.md for next session.

package/bundled/dev-pipeline/tests/test_generate_bootstrap_prompt.py

@@ -6,6 +6,7 @@ from generate_bootstrap_prompt import (
     compute_feature_slug,
     find_feature,
     format_acceptance_criteria,
+    format_ac_checklist,
     format_global_context,
     get_completed_dependencies,
     determine_pipeline_mode,
@@ -73,6 +74,18 @@ class TestFormatAcceptanceCriteria:
         assert "- Password reset works" in result
 
 
+class TestFormatAcChecklist:
+    def test_empty_does_not_create_unchecked_gate(self):
+        result = format_ac_checklist([])
+        assert result == "- (no Verification Gates specified)"
+        assert "[ ]" not in result
+
+    def test_items_are_unchecked_verification_gates(self):
+        result = format_ac_checklist(["Users can log in", "Password reset works"])
+        assert "- [ ] Users can log in" in result
+        assert "- [ ] Password reset works" in result
+
+
 # ---------------------------------------------------------------------------
 # format_global_context
 # ---------------------------------------------------------------------------

package/bundled/dev-pipeline-windows/scripts/generate-bootstrap-prompt.py

@@ -286,7 +286,7 @@ def extract_baseline_failures(test_commands, project_root):
 def format_ac_checklist(acceptance_criteria):
     """Format acceptance criteria as a markdown checkbox list."""
     if not acceptance_criteria:
-        return "- [ ] (no acceptance criteria specified)"
+        return "- (no Verification Gates specified)"
     lines = []
     for item in acceptance_criteria:
         lines.append("- [ ] {}".format(item))
@@ -323,10 +323,10 @@ def format_user_context(user_context):
     if not items:
         return ""
     lines = [
-        "### User-Provided Context (HIGHEST PRIORITY)",
-        "",
-        "> The following materials were provided by the user. "
-        "They take precedence over AI inference.",
+        "> These materials were provided by the user and are authoritative "
+        "when they clarify or constrain this feature. They do not expand "
+        "the current scope by themselves; use the Task Contract to decide "
+        "what belongs to this session.",
         "",
     ]
     for item in items:
@@ -970,6 +970,10 @@ def assemble_sections(pipeline_mode, sections_dir, init_done, is_resume,
     mission += "\n\n" + tier_desc
     sections.append(("mission", mission))
 
+    # --- Task Contract: single source of current scope and gates ---
+    sections.append(("task-contract",
+                      load_section(sections_dir, "task-contract.md")))
+
     # --- Feature Context (XML-wrapped, optimization 3) ---
     sections.append(("feature-context",
                       load_section(sections_dir, "feature-context.md")))
@@ -1079,13 +1083,8 @@ def assemble_sections(pipeline_mode, sections_dir, init_done, is_resume,
                           load_section(sections_dir,
                                        "test-failure-recovery-agent.md")))
 
-    # --- AC Verification Checklist (all tiers) ---
-    ac_checklist_path = os.path.join(sections_dir, "ac-verification-checklist.md")
-    if os.path.isfile(ac_checklist_path):
-        sections.append(("ac-verification-checklist",
-                          load_section(sections_dir,
-                                       "ac-verification-checklist.md")))
-
+    # Verification Gates are included in Task Contract. Keep AC in one place so
+    # background context and implementation prompts cannot redefine scope.
     # --- Review (only for agent tiers) ---
     if pipeline_mode == "full":
         sections.append(("phase-review",

package/bundled/dev-pipeline-windows/templates/agent-prompts/dev-implement.md

@@ -1,30 +1,44 @@
 "Read {{DEV_SUBAGENT_PATH}}. Implement feature {{FEATURE_ID}} (slug: {{FEATURE_SLUG}}).
-**IMPORTANT**: Read `.prizmkit/specs/{{FEATURE_SLUG}}/context-snapshot.md` FIRST — Section 3 has Prizm Context (TRAPS/RULES), Section 4 has File Manifest with paths and interfaces.
-⚠️ DO NOT re-read source files already listed in Section 4 File Manifest unless you need implementation detail beyond the interface summary.
-1. Read `.prizmkit/specs/{{FEATURE_SLUG}}/context-snapshot.md` for full context.
-2. Run `/prizmkit-implement` to execute the tasks in plan.md. Run tests with: `{{TEST_CMD}}`. Known baseline failures (pre-existing, not your fault): `{{BASELINE_FAILURES}}`.
-3. If plan.md has more than 5 tasks: run `/compact` after completing every 3 tasks to manage context budget. If `/compact` is unavailable, continue without it.
-4. After implement completes, verify the '## Implementation Log' section was written to context-snapshot.md.
 
-## Acceptance Criteria Verification
+## Required Inputs
 
-Update the AC Verification Checklist in context-snapshot.md by marking each item [x] as you verify it:
-- As you complete each task, verify the corresponding acceptance criteria
-- Check the AC Checklist at the end of implementation
-- All [ ] must become [x] — if any AC remains unverified, the feature is incomplete
-- Document any AC that cannot be verified due to test failures
+1. Read `.prizmkit/specs/{{FEATURE_SLUG}}/context-snapshot.md` first.
+2. Use Section 4 File Manifest for targeted reads.
+3. Do not expand scope beyond the Task Contract and Verification Gates.
+4. Do not re-read source files already listed in Section 4 unless implementation details are missing from the manifest.
 
-## Test Failure Recovery (Convergence-Based)
+## Work
 
-If tests fail, use convergence recovery — keep fixing while progress is being made:
+Run `/prizmkit-implement` to execute `plan.md`.
 
-1. **Run tests, record results**: count failures, exclude baseline failures
-2. **Check termination**: All pass → done | Plateau (same failures 3 rounds) → stop | Failures decreased → continue
-3. **Fix and iterate**: analyze, apply fix, re-run `{{TEST_CMD}}`, go back to step 1
+Test command:
+`{{TEST_CMD}}`
 
-**Key rule**: If failures decrease (even by 1), plateau counter resets.
-**Do NOT block completion** if unable to resolve — only NEW REGRESSIONS (not in baseline) require fixing.
-**If any AC cannot be verified** due to test failure: the feature is incomplete, add to failure notes.
+Known baseline failures:
+`{{BASELINE_FAILURES}}`
 
-4. Do NOT execute any git commands (no git add/commit/reset/push).
-Do NOT exit until all tasks are [x], the '## Implementation Log' section is written, and AC Verification Checklist is 100% complete in context-snapshot.md."
+If plan.md has more than 5 tasks, run `/compact` after completing every 3 tasks to manage context budget. If `/compact` is unavailable, continue without it.
+
+## Required Outputs
+
+Before returning, append `## Implementation Log` to `context-snapshot.md` with:
+- files changed/created
+- key decisions
+- deviations from plan
+- test results
+- Verification Gate status
+- unresolved blockers, if any
+
+## Protocol References
+
+- Follow the global Context Budget Rules.
+- Carry forward the Dev-isolated subset: skip scaffold/generated files listed in `context-snapshot.md`; verify dependency versions before install/build commands that resolve dependencies; after build/compile commands, ensure outputs are ignored and never commit generated artifacts.
+- If tests fail, follow this Test Failure Recovery subset: classify failures as baseline, new regression, brittle test, or environment/tooling; fix new regressions and brittle tests while progress is being made; document baseline failures; write `failure-log.md` for blockers.
+- Do not run git commands; staging and commit are handled by the orchestrator.
+
+Do not return success unless:
+1. implementation tasks are complete;
+2. `## Implementation Log` exists;
+3. every Verification Gate is verified.
+
+If any Verification Gate is blocked, write `failure-log.md` and return a blocked/incomplete result instead of success."

package/bundled/dev-pipeline-windows/templates/agent-prompts/reviewer-review.md

@@ -1,5 +1,5 @@
 "Read {{REVIEWER_SUBAGENT_PATH}}. For feature {{FEATURE_ID}} (slug: {{FEATURE_SLUG}}):
-1. Read `.prizmkit/specs/{{FEATURE_SLUG}}/spec.md` (if it exists) for goals and acceptance criteria; if spec.md does not exist, read `.prizmkit/specs/{{FEATURE_SLUG}}/context-snapshot.md` Section 1 instead
+1. Read `.prizmkit/specs/{{FEATURE_SLUG}}/spec.md` (if it exists) for goals and Verification Gates; if spec.md does not exist, read `.prizmkit/specs/{{FEATURE_SLUG}}/context-snapshot.md` Section 1 Task Contract instead
 2. Read `.prizmkit/specs/{{FEATURE_SLUG}}/plan.md` for architecture decisions and completed tasks
 3. Run /prizmkit-code-review with artifact_dir=.prizmkit/specs/{{FEATURE_SLUG}}/. The skill will run its internal review-fix loop (Reviewer → filter → Dev fix, max 3 rounds) and write review-report.md.
 4. Run the full test suite using `{{TEST_CMD}}`. When running tests: `({{TEST_CMD}}) 2>&1 | Tee-Object (Join-Path $env:TEMP "review-test-out.txt") | Select-Object -Last 20`, then Select-String (Join-Path $env:TEMP "review-test-out.txt") for details — do NOT re-run the suite multiple times.

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

@@ -84,12 +84,12 @@ New-Item -ItemType Directory -Force -Path .prizmkit/bugfix/{{BUG_ID}} | Out-Null
 
 {{IF_BROWSER_INTERACTION}}
 
-#### Browser Verification Setup
+#### Browser Verification Protocol
 
-The bug may be reproducible via the UI using browser tools:
+The bug may be reproducible via the UI. Use this single browser protocol for planning, implementation, review, and final reporting:
 
 {{IF_BROWSER_TOOL_AUTO}}
-- **Browser Tool**: Will be auto-selected based on error type and dev server configuration
+- **Browser Tool**: Auto-select at runtime based on error type and dev server configuration
 {{END_IF_BROWSER_TOOL_AUTO}}
 
 {{IF_BROWSER_TOOL_PLAYWRIGHT}}
@@ -103,10 +103,7 @@ The bug may be reproducible via the UI using browser tools:
 **Browser Verification Goals**:
 {{BROWSER_VERIFY_STEPS}}
 
-If the bug is related to UI/frontend, you may use these tools to:
-1. Reproduce the bug in a running dev server
-2. Verify the fix after implementation
-3. Smoke-test related UI flows for regression
+Use this protocol only when the bug is UI/frontend-reproducible. Evidence must cover: original bug reproduction, post-fix behavior, related UI regression smoke tests, tool used, and any manual verification steps.
 
 {{END_IF_BROWSER_INTERACTION}}
 
@@ -141,7 +138,7 @@ Run `/prizmkit-plan` with `artifact_dir=.prizmkit/bugfix/{{BUG_ID}}/`:
 - Resolve any `[NEEDS CLARIFICATION]` markers autonomously — do NOT pause
 
 {{IF_BROWSER_INTERACTION}}
-- **Browser Verification**: If the bug is UI-reproducible, plan.md should include browser-based reproduction as an optional verification step
+- **Browser Verification**: If the bug is UI-reproducible, plan.md should reference the Browser Verification Protocol above instead of redefining browser steps.
 {{END_IF_BROWSER_INTERACTION}}
 
 **DECISION GATE — Fast Path Check**:
@@ -171,11 +168,7 @@ Run `/prizmkit-implement` with `artifact_dir=.prizmkit/bugfix/{{BUG_ID}}/`:
 
 {{IF_BROWSER_INTERACTION}}
 
-**Browser Verification During Implementation**:
-- After each code fix, you may optionally use browser tools to verify the behavior
-- Reproduce the original bug steps and confirm they no longer occur
-- Test related UI flows to ensure no regression
-- Document any manual verification steps in the implementation notes
+**Browser Verification During Implementation**: If the bug is UI-reproducible, apply the Browser Verification Protocol above and document evidence in the implementation notes.
 
 {{END_IF_BROWSER_INTERACTION}}
 
@@ -196,20 +189,30 @@ After implement completes, verify:
 If `FAST_PATH=true` (≤ 2 tasks, obvious root cause), skip this phase entirely.
 
 Run `/prizmkit-code-review` with `artifact_dir=.prizmkit/bugfix/{{BUG_ID}}/`:
-- The skill runs an internal review-fix loop (Reviewer → filter → Dev fix, max 3 rounds) and writes review-report.md
-- If PASS: proceed
-- If NEEDS_FIXES: the skill exhausted its max rounds; log remaining findings and proceed
+- The skill runs an internal review-fix loop (Reviewer → filter → Dev fix, max 3 rounds) and writes `review-report.md`
+- `review-report.md` must contain `## Verdict`
+
+**Gate Check — Review Report**:
+After `/prizmkit-code-review` returns, verify the review report:
+```powershell
+if (Select-String -Path .prizmkit/bugfix/{{BUG_ID}}/review-report.md -Pattern "## Verdict" -Quiet) { "GATE:PASS" } else { "GATE:MISSING" }
+```
+If GATE:MISSING:
+- Do not re-run `/prizmkit-code-review` in an unbounded report-repair loop.
+- Perform one bounded status check; retry `/prizmkit-code-review` at most once only if the missing report appears caused by a transient team/config/lock error.
+- If the report is still missing after that single check/retry, write `failure-log.md` with the spawn/skill error and last observable state, then either perform a safe inline fallback review (spec/plan/diff/tests → write `review-report.md` with `## Verdict`) or stop with a clear recovery failure.
+
+Read `review-report.md` and check the Verdict:
+- `PASS` → proceed
+- `NEEDS_FIXES` → the skill exhausted its max rounds; log remaining findings and proceed
 
 {{IF_BROWSER_INTERACTION}}
 
-**Code Review — Browser Verification Check**:
-- Verify that browser-based reproduction steps (if applicable) are clearly documented
-- Confirm that the fix maintains the expected UI behavior for all affected flows
-- Validate that any manual verification steps have been completed successfully
+**Code Review — Browser Verification Check**: Confirm that UI-reproducible bug evidence follows the Browser Verification Protocol above.
 
 {{END_IF_BROWSER_INTERACTION}}
 
-**CP-3**: Code review complete, all tests green.
+**CP-3**: Code review complete, `review-report.md` written, and all tests green.
 
 **Checkpoint update**: Set step `prizmkit-code-review` to `"completed"`.
 

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

@@ -16,7 +16,7 @@ You are the **refactor session orchestrator**. Execute Refactor {{REFACTOR_ID}}:
 
 **NON-INTERACTIVE MODE**: You are running in headless non-interactive mode. There is NO human on the other end. NEVER ask for user confirmation, NEVER wait for user input, NEVER use interactive prompts (e.g. "Would you like me to…"). If a skill has an interactive step (e.g. offer remediation, ask for approval), skip it and proceed autonomously. Make decisions based on the data available and move forward.
 
-**MANDATORY TEAM REQUIREMENT**: You MUST use the `prizm-dev-team` agents (Dev + Reviewer). This is NON-NEGOTIABLE. All implementation and review work MUST be performed by the appropriate team agents (Dev, Reviewer). You are the orchestrator — handle coordination, planning, and commit phases directly.
+**NORMAL-PATH TEAM REQUIREMENT**: Use the `prizm-dev-team` agents (Dev + Reviewer) for implementation and review. You are the orchestrator — handle coordination, planning, and commit phases directly. If a required agent cannot be spawned after the bounded retry policy below, follow the documented recovery exception instead of looping forever.
 
 **REFACTOR DOCUMENTATION POLICY**:
 - **DEFAULT**: Run `/prizmkit-retrospective` with full sync (Job 1 + Job 2), because refactoring changes code structure and interfaces.
@@ -83,7 +83,8 @@ You are the **refactor session orchestrator**. Execute Refactor {{REFACTOR_ID}}:
 **Agent spawn failure policy (all Agent tool calls)**:
 - If spawning Dev or Reviewer fails with team/config/lock errors, retry at most once.
 - If the second attempt fails, do not keep spawning variants and do not enter artifact polling for Implementation Log, review-report, or refactor-report markers.
-- Use the documented inline/recovery fallback for that phase: complete remaining refactor work directly in the orchestrator when safe, write the required report yourself where possible, or write `failure-log.md` with the spawn error and last observable state before stopping for recovery.
+- Recovery exception: complete remaining refactor work directly in the orchestrator only when the action is safe and bounded; otherwise write `failure-log.md` with the spawn error and last observable state before stopping for recovery.
+- Any recovery exception must be recorded in the required report or session status so downstream runs know the normal team path was unavailable.
 - Apply the same cap to any re-spawn for report repair or resume prompts; do not burn multiple minutes on identical team/config/lock failures.
 
 ## Workflow Checkpoint System
@@ -131,32 +132,26 @@ Resolve any `[NEEDS CLARIFICATION]` markers using the refactor description — d
 
 {{IF_BROWSER_INTERACTION}}
 
-#### Browser Verification Strategy
+#### Browser Behavior Preservation Protocol
 
-The refactor may affect UI behavior. Browser verification can validate:
-- **UI Render**: UI components render identically after refactoring
-- **User Interactions**: Navigation, form submissions, and workflows function as before
-- **Feature Coverage**: Refactored features work end-to-end in real browser environment
+The refactor may affect UI behavior. Use this single browser protocol for planning, implementation, review, and final reporting:
 
 {{IF_BROWSER_TOOL_AUTO}}
-Browser tool will be auto-selected at runtime based on dev server and feature complexity.
+- **Browser Tool**: Auto-select at runtime based on dev server and feature complexity.
 {{END_IF_BROWSER_TOOL_AUTO}}
 
 {{IF_BROWSER_TOOL_PLAYWRIGHT}}
-**Tool: playwright-cli** — Local isolated browser instance for dev server verification
+- **Browser Tool**: playwright-cli — local isolated browser instance for dev server verification.
 {{END_IF_BROWSER_TOOL_PLAYWRIGHT}}
 
 {{IF_BROWSER_TOOL_OPENCLI}}
-**Tool: opencli** — Chrome session with existing login for testing OAuth/third-party integrations
+- **Browser Tool**: opencli — Chrome session with existing login for OAuth/third-party integrations.
 {{END_IF_BROWSER_TOOL_OPENCLI}}
 
 **Verification Goals**:
 {{BROWSER_VERIFY_STEPS}}
 
-Include browser verification approach in plan.md:
-- Which UI flows should be smoke-tested after refactoring?
-- Any specific user journeys affected by the structural changes?
-- Should verification be part of review phase or implementation phase?
+Evidence must cover affected UI render, primary user interactions, behavior-sensitive workflows, tool used, and whether verification belongs in implementation, review, or both.
 
 {{END_IF_BROWSER_INTERACTION}}
 
@@ -170,7 +165,7 @@ Include browser verification approach in plan.md:
 **Goal**: Execute all tasks from plan.md while preserving existing behavior.
 
 - Spawn Dev agent (Agent tool, subagent_type="prizm-dev-team-dev", run_in_background=false)
-  Spawn failure cap: for team/config/lock errors, retry at most once for this Dev spawn. If the second attempt fails, do not poll for `## Implementation Log`; write `failure-log.md` and either complete remaining refactor work directly in the orchestrator or stop for recovery.
+  Apply the all-agent spawn failure policy above for this Dev spawn: for team/config/lock errors, retry at most once; if the second attempt fails, do not poll for `## Implementation Log`; use the bounded recovery exception.
   Prompt: "Read {{DEV_SUBAGENT_PATH}}. For refactor {{REFACTOR_ID}} ('{{REFACTOR_TITLE}}'):
   1. Read `.prizmkit/refactor/{{REFACTOR_ID}}/spec.md` and `.prizmkit/refactor/{{REFACTOR_ID}}/plan.md`
   2. Read `.prizmkit/prizm-docs/` for affected modules (TRAPS, RULES, PATTERNS)
@@ -185,11 +180,7 @@ Include browser verification approach in plan.md:
 
 {{IF_BROWSER_INTERACTION}}
 
-  6. **Browser Smoke Tests** (after every major refactor task):
-     - Use browser tools to verify UI still renders correctly
-     - Test the primary user flows affected by the refactoring
-     - Confirm no visual or interactive regressions
-     - Document any manual browser verification steps in implementation notes
+  6. Apply the Browser Behavior Preservation Protocol above after major refactor tasks and document evidence in implementation notes.
 
 {{END_IF_BROWSER_INTERACTION}}
 
@@ -208,7 +199,7 @@ Include browser verification approach in plan.md:
 **Goal**: Verify refactoring quality and behavior preservation.
 
 - Spawn Reviewer agent (Agent tool, subagent_type="prizm-dev-team-reviewer", run_in_background=false)
-  Spawn failure cap: for team/config/lock errors, retry at most once for this Reviewer spawn. If the second attempt fails, do not poll for `review-report.md`; write `failure-log.md` with the spawn error and last observable state before stopping or performing an inline fallback.
+  Apply the all-agent spawn failure policy above for this Reviewer spawn.
   Prompt: "Read {{REVIEWER_SUBAGENT_PATH}}. For refactor {{REFACTOR_ID}}:
   1. Read `.prizmkit/refactor/{{REFACTOR_ID}}/spec.md` for goals and behavior preservation contracts
   2. Read `.prizmkit/refactor/{{REFACTOR_ID}}/plan.md` for architecture decisions and completed tasks
@@ -217,11 +208,7 @@ Include browser verification approach in plan.md:
 
 {{IF_BROWSER_INTERACTION}}
 
-  5. **Browser Verification Review**:
-     - Verify that critical user workflows still function end-to-end in browser
-     - Confirm UI renders consistently after structural changes
-     - Validate any behavior-sensitive components behave identically
-     - Document browser verification findings in review-report.md
+  5. Verify the Browser Behavior Preservation Protocol evidence and document findings in `review-report.md`.
 
 {{END_IF_BROWSER_INTERACTION}}
 

package/bundled/dev-pipeline-windows/templates/sections/ac-verification-checklist.md

@@ -1,13 +1,7 @@
-## Acceptance Criteria Verification Checklist
+## Verification Gates Compatibility Note
 
-This checklist is auto-generated from feature.acceptance_criteria. The Dev agent must verify each criterion and mark as complete:
+This section file is retained for compatibility with older bootstrap templates.
 
-{{AC_CHECKLIST}}
-
-**Verification Gates**:
-1. All [x] items confirmed by Dev agent during implementation
-2. Reviewer agent verifies checklist is 100% complete before clearing PASS verdict
-3. Any unmet AC ([ ] remaining) marks feature as incomplete
-
----
+Current section assembly renders Verification Gates only inside `task-contract.md` so the feature scope and acceptance requirements have a single source of truth.
 
+Do not add this section separately unless you intentionally want to duplicate the gates outside the Task Contract.

package/bundled/dev-pipeline-windows/templates/sections/context-budget-rules.md

@@ -31,3 +31,4 @@ You are running in **headless non-interactive mode** with a FINITE context windo
      (c) Use no version constraint (e.g., `"express": "*"`)
    - **This is a BLOCKING gate**: do NOT run `npm install` / `pip install` / `cargo build` / `go mod tidy` until ALL versions in the manifest have been verified or use open constraints
    - Batch version lookups: query multiple packages in parallel to save time (e.g., run multiple `npm view` commands concurrently)
+10. **Build artifact hygiene** — After any build/compile command (`go build`, `npm run build`, `tsc`, etc.), ensure the output binary, build directory, generated bundle, or cache directory is ignored by git before the commit phase. Never commit compiled binaries, build output, or generated artifacts.