prizmkit 1.1.68 → 1.1.70

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

@@ -84,12 +84,12 @@ mkdir -p .prizmkit/bugfix/{{BUG_ID}}
 
 {{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:
+```bash
+grep -q "## Verdict" .prizmkit/bugfix/{{BUG_ID}}/review-report.md && echo "GATE:PASS" || echo "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/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.
@@ -80,6 +80,13 @@ You are the **refactor session orchestrator**. Execute Refactor {{REFACTOR_ID}}:
 
 **YOU are the orchestrator. Execute each phase by spawning the appropriate team agent with run_in_background=false.**
 
+**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.
+- 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
 
 A checkpoint file tracks your progress through this workflow:
@@ -125,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}}
 
@@ -164,6 +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)
+  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)
@@ -178,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}}
 
@@ -201,6 +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)
+  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
@@ -209,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}}
 
@@ -221,7 +216,20 @@ Include browser verification approach in plan.md:
   7. Report: verdict (PASS/NEEDS_FIXES), number of rounds, findings fixed/rejected
   "
 - **Wait for Reviewer to return**
-- Read `review-report.md` — if PASS proceed, if NEEDS_FIXES log remaining findings and proceed.
+- **Gate Check — Review Report**:
+  After Reviewer returns, verify the review report contains a verdict:
+  ```bash
+  grep -q "## Verdict" .prizmkit/refactor/{{REFACTOR_ID}}/review-report.md && echo "GATE:PASS" || echo "GATE:MISSING"
+  ```
+  If GATE:MISSING:
+  - Do not enter an unbounded report-repair loop and do not repeatedly re-spawn Reviewer.
+  - Perform one bounded status check; retry at most once: inspect the Reviewer output, `review-report.md` path, and any internal Reviewer/Dev spawn messages from `/prizmkit-code-review`.
+  - If the missing report is caused by team/config/lock errors from the Reviewer or internal Reviewer/Dev agent spawn, retry the Reviewer agent at most once only if it appears transient.
+  - If the report is still missing after that single check/retry, write `.prizmkit/refactor/{{REFACTOR_ID}}/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 to next phase
+- `NEEDS_FIXES` → log remaining findings and proceed (do not retry externally)
 - **CP-RF-3**: Code review complete, tests pass, behavior preserved
 - **Checkpoint update**: set step `prizmkit-code-review` to `"completed"` in `{{CHECKPOINT_PATH}}`
 

package/bundled/dev-pipeline/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/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.

package/bundled/dev-pipeline/templates/sections/feature-context.md

@@ -1,25 +1,30 @@
 <feature-context>
-### Feature Description
+## Source Semantics
 
-{{FEATURE_DESCRIPTION}}
+Use this material according to the following priority:
 
-{{USER_CONTEXT}}
+1. **Task Contract** — defines current scope and Verification Gates.
+2. **User Raw Context** — authoritative constraints, but not automatic scope expansion.
+3. **Completed Dependencies** — existing behavior and interfaces; do not re-implement them.
+4. **Project Brief** — product background and architecture alignment.
+5. **App Global Context** — stack, runtime, and testing conventions.
+6. **Project Conventions** — repository-specific rules.
 
-### Acceptance Criteria
+### User Raw Context
 
-{{ACCEPTANCE_CRITERIA}}
+{{USER_CONTEXT}}
 
-### Project Brief
+### Completed Dependencies
 
-> Product ideas checklist from planning. Lines marked [x] are already implemented. When your feature touches any [ ] item, ensure alignment. After implementation, mark relevant items [x] and append the key file/directory paths.
+> Use this section to understand available interfaces and avoid duplicating completed work.
 
-{{PROJECT_BRIEF}}
+{{COMPLETED_DEPENDENCIES}}
 
-### Dependencies (Already Completed)
+### Project Brief
 
-> Below are features that this feature depends on, along with their key implementation notes. Use this context to understand what has already been built and what interfaces/APIs/models are available.
+> Use this section for alignment only. Do not treat unrelated backlog items as current feature scope.
 
-{{COMPLETED_DEPENDENCIES}}
+{{PROJECT_BRIEF}}
 
 ### App Global Context
 

package/bundled/dev-pipeline/templates/sections/phase-browser-verification-auto.md

@@ -1,46 +1,37 @@
 ### Browser Verification — MANDATORY
 
-You MUST execute this phase. Do NOT skip it. Do NOT mark it as completed without actually running browser verification.
+You MUST attempt this phase. Mark it as skipped only when no usable browser tool can be found, installed, or started.
 
 **Step 0 — Tool Selection (BLOCKING — decide before any browser action)**:
 
 0a. Check which browser tools are available:
 ```bash
 echo "=== playwright-cli ==="
-which playwright-cli 2>/dev/null && playwright-cli --version 2>/dev/null || echo "NOT_INSTALLED"
+which playwright-cli 2>/dev/null && playwright-cli --version 2>/dev/null || echo "PLAYWRIGHT_CLI:NOT_INSTALLED"
 echo "=== opencli ==="
-which opencli 2>/dev/null && opencli --version 2>/dev/null || echo "NOT_INSTALLED"
+which opencli 2>/dev/null && opencli --version 2>/dev/null || echo "OPENCLI:NOT_INSTALLED"
 ```
 
-0b. If opencli is installed, verify Browser Bridge connectivity:
-```bash
-opencli doctor 2>/dev/null || echo "OPENCLI_BRIDGE_FAILED"
-```
-
-0c. **Choose your tool** based on availability and scenario:
-
-| Condition | Use this tool |
-|-----------|--------------|
-| Only playwright-cli installed | `playwright-cli` |
-| Only opencli installed (and doctor passes) | `opencli` |
-| Both installed — verifying local dev server, forms, components | `playwright-cli` (isolated, deterministic) |
-| Both installed — feature needs real login state (OAuth/SSO) | `opencli` (reuses Chrome sessions) |
-| Both installed — verifying third-party integration pages | `opencli` (has logged-in cookies) |
-| Both installed — headless CI environment | `playwright-cli` (no Chrome dependency) |
-| Neither installed | Skip — log `## Browser Verification: SKIPPED — no browser tool available` |
+0b. Use this single decision tree:
+1. If `playwright-cli` is available, use it by default for local dev-server verification.
+2. Else if `opencli` is available, run `opencli doctor`; use `opencli` only if doctor passes.
+3. Else install `playwright-cli` as the default:
+   ```bash
+   npm install -g @playwright/cli@latest
+   playwright-cli --version
+   ```
+4. If no browser tool is usable after these steps, append `## Browser Verification: SKIPPED — no usable browser tool` to `context-snapshot.md`, then continue to reporting/checkpoint.
 
-If neither tool is available, install playwright-cli as the default:
-```bash
-npm install -g @playwright/cli@latest
-playwright-cli --version
-```
+Use `opencli` instead of `playwright-cli` only when the scenario requires an existing Chrome login/session or third-party integration cookies.
 
 Record your choice:
 ```bash
-BROWSER_TOOL="playwright-cli"   # or "opencli"
+BROWSER_TOOL="playwright-cli"   # or "opencli" or "skipped"
 echo "Selected browser tool: $BROWSER_TOOL"
 ```
 
+If `BROWSER_TOOL="skipped"`, do NOT start a dev server and do NOT run browser commands. Go directly to Step 4 Reporting and the checkpoint update.
+
 ---
 
 **If you chose `playwright-cli`**, follow this workflow:
@@ -74,7 +65,7 @@ If `SKILL_MISSING`: run `playwright-cli install --skills`. If current platform i
 Use `playwright-cli snapshot` to discover element refs, then verify these goals:
    {{BROWSER_VERIFY_STEPS}}
 
-Construct your verification workflow based on: (1) the playwright-cli skill documentation, (2) the `--help` output, (3) the current task's acceptance criteria. Take a final screenshot: `playwright-cli screenshot`.
+Construct your verification workflow based on: (1) the playwright-cli skill documentation, (2) the `--help` output, (3) the current task's Verification Gates. Take a final screenshot: `playwright-cli screenshot`.
 
 **Step 3 — Cleanup (playwright-cli)**:
 1. `playwright-cli close`

package/bundled/dev-pipeline/templates/sections/phase-browser-verification-opencli.md

@@ -94,7 +94,7 @@ opencli browser click 12 && opencli browser wait time 1 && opencli browser state
 
 **IMPORTANT**: Always run `opencli browser state` after page-changing actions (open, click on links, scroll) to get fresh element indices. Never guess indices.
 
-Construct your verification workflow based on: (1) the `opencli browser --help` output, (2) the current task's acceptance criteria. Decide the concrete actions yourself. Take a final screenshot if needed: `opencli browser screenshot`.
+Construct your verification workflow based on: (1) the `opencli browser --help` output, (2) the current task's Verification Gates. Decide the concrete actions yourself. Take a final screenshot if needed: `opencli browser screenshot`.
 
 **Step 3 — Cleanup (REQUIRED — you started it, you stop it)**:
 

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

@@ -113,7 +113,7 @@ Use `playwright-cli snapshot` on the running app to discover actual element refs
 Construct your verification workflow based on:
 1. The playwright-cli skill documentation (read in Step 0d)
 2. The `playwright-cli --help` output (captured in Step 0b)
-3. The current task's acceptance criteria and implemented features
+3. The current task's Verification Gates and implemented features
 
 Decide the concrete playwright-cli actions (click, fill, snapshot, screenshot, etc.) yourself based on the snapshot output and your knowledge of the implemented code. The goals above describe WHAT to verify — you determine HOW using playwright-cli commands.
 

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

@@ -13,7 +13,7 @@ If MISSING — build it now:
    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 — Feature Brief**: feature 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/phase-critic-plan-full.md

@@ -8,6 +8,16 @@ If CRITIC:MISSING — skip this phase entirely and proceed. Log: "Critic agent n
 
 **Choose ONE path based on `{{CRITIC_COUNT}}`:**
 
+**Agent spawn failure policy**:
+- If spawning Critic fails with team/config/lock errors, retry at most once.
+- If the second attempt fails, do not keep spawning variants. Either create the required team once (when team tooling is available) or perform the plan challenge inline and write the required challenge report yourself.
+- Record the fallback in the report; do not burn multiple minutes on repeated identical spawn failures.
+
+**No silent report polling**:
+- Do NOT run a long no-output loop waiting for `challenge-report*.md`.
+- If you need to wait for a report file, use a short bounded check (≤120s) that prints elapsed time and reports present on every iteration.
+- If reports are still missing after the bounded check, request one status update; if still missing, perform the missing challenge lens inline and continue.
+
 **If {{CRITIC_COUNT}} = 1 → Single Critic** (skip to CP-2.5 after this):
 
 **Spawn Agent**:

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

@@ -16,6 +16,16 @@ If CRITIC:MISSING — skip this phase entirely and proceed. Log: "Critic agent n
 **Prompt**:
 > {{AGENT_PROMPT_CRITIC_PLAN_CHALLENGE}}
 
+**Agent spawn failure policy**:
+- If spawning Critic fails with team/config/lock errors, retry at most once.
+- If the second attempt fails, do not keep spawning variants. Either create the required team once (when team tooling is available) or perform the plan challenge inline and write `challenge-report.md` yourself.
+- Record the fallback in the report; do not burn multiple minutes on repeated identical spawn failures.
+
+**No silent report polling**:
+- Do NOT run a long no-output loop waiting for `challenge-report.md`.
+- If you need to wait for the report file, use a short bounded check (≤120s) that prints elapsed time and whether the report exists on every iteration.
+- If the report is still missing after the bounded check, request one status update; if still missing, perform the challenge inline and continue.
+
 Wait for Critic to return.
 - Read challenge-report.md. For items marked CRITICAL/HIGH: decide whether to adjust plan.md or document why the plan stands.
 - Max 1 plan revision round.

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

@@ -1,13 +1,6 @@
 ### Implement — Dev Subagent
 
-**Build artifacts rule** (passed to Dev): After any build/compile command (`go build`, `npm run build`, `tsc`, etc.), ensure the output binary or build directory is in `.gitignore`. Never commit compiled binaries, build output, or generated artifacts.
-
-**Dependency version gate (BLOCKING — pass to Dev agent)**: Before running ANY package install command (`npm install`, `pip install`, `cargo build`, `go mod tidy`, `bundle install`, etc.):
-1. Every version number in the dependency manifest MUST be verified against the real registry (see Context Budget Rules §9)
-2. If a scaffold tool generated a `package.json` / `requirements.txt` / etc., verify the versions it wrote too — scaffold tools can emit outdated versions
-3. Do NOT proceed with install until all versions are confirmed real. Violation = wasted timeout cycles that can crash the session
-
-**Scaffold file rule (pass to Dev agent)**: After running any init/scaffold command, record generated files in context-snapshot.md under `### Scaffold Files (do not re-read)`. Never re-read these files — their content is standard boilerplate (see Context Budget Rules §8). When spawning subagents, explicitly list scaffold files so they skip reading them.
+**Protocol handoff to Dev**: The Dev prompt already carries the required subset of Context Budget Rules, the Test Failure Recovery Protocol, and Task Contract / Verification Gate constraints. Do not duplicate those rules here; verify Dev output against the gates below.
 
 **Spawn Agent**:
 | Parameter | Value |
@@ -15,10 +8,22 @@
 | subagent_type | prizm-dev-team-dev |
 | run_in_background | false |
 
+**Agent spawn failure policy**:
+- If spawning Dev fails with team/config/lock errors, retry at most once.
+- If the second attempt fails, do not enter Implementation Log polling or repeated recovery spawn loops.
+- Use the documented inline/recovery fallback: write `failure-log.md` with the spawn error and last observable state, then either complete remaining tasks directly in the orchestrator or stop with a clear failure for recovery.
+- Apply the same cap to Dev re-spawns for Implementation Log repair or resume prompts; do not burn multiple minutes on identical team/config/lock failures.
+
 **Prompt**:
 > {{AGENT_PROMPT_DEV_IMPLEMENT}}
 
-Wait for Dev to return. All tasks must be `[x]`, tests pass.
+Wait for Dev to return. Implementation may proceed only when tasks are complete and the Test Failure Recovery Protocol's Success Rule is satisfied.
+
+**No silent artifact polling**:
+- Do NOT run a long no-output loop that only waits for `## Implementation Log` or any other file marker.
+- If you must wait for Dev after spawning or sending a status request, use short bounded checks (≤120s) that print a heartbeat line each iteration with: elapsed time, remaining unchecked task count, whether `## Implementation Log` exists, and whether `git diff --stat` changed.
+- If Dev has no transcript/file/diff progress for one bounded check, send one status request. If there is still no progress on the next bounded check, stop waiting, write `failure-log.md` with the last observable state, and follow Subagent Timeout Recovery.
+- Prefer the Agent tool's completion notification or Dev's `COMPLETION_SIGNAL`; file presence alone is not a liveness signal.
 
 **Gate Check — Implementation Log**:
 After Dev agent returns, verify the Implementation Log was written:

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

@@ -1,13 +1,6 @@
 ### Implement — Dev Agent
 
-**Build artifacts rule** (passed to Dev): After any build/compile command (`go build`, `npm run build`, `tsc`, etc.), ensure the output binary or build directory is in `.gitignore`. Never commit compiled binaries, build output, or generated artifacts.
-
-**Dependency version gate (BLOCKING — pass to Dev agent)**: Before running ANY package install command (`npm install`, `pip install`, `cargo build`, `go mod tidy`, `bundle install`, etc.):
-1. Every version number in the dependency manifest MUST be verified against the real registry (see Context Budget Rules §9)
-2. If a scaffold tool generated a `package.json` / `requirements.txt` / etc., verify the versions it wrote too — scaffold tools can emit outdated versions
-3. Do NOT proceed with install until all versions are confirmed real. Violation = wasted timeout cycles that can crash the session
-
-**Scaffold file rule (pass to Dev agent)**: After running any init/scaffold command, record generated files in context-snapshot.md under `### Scaffold Files (do not re-read)`. Never re-read these files — their content is standard boilerplate (see Context Budget Rules §8). When spawning subagents, explicitly list scaffold files so they skip reading them.
+**Protocol handoff to Dev**: The Dev prompt already carries the required subset of Context Budget Rules, the Test Failure Recovery Protocol, and Task Contract / Verification Gate constraints. Do not duplicate those rules here; verify Dev output against the gates below.
 
 Before spawning Dev, check plan.md Tasks section:
 ```bash
@@ -22,9 +15,21 @@ grep -c '^\- \[ \]' .prizmkit/specs/{{FEATURE_SLUG}}/plan.md 2>/dev/null || true
 | subagent_type | prizm-dev-team-dev |
 | run_in_background | false |
 
+**Agent spawn failure policy**:
+- If spawning Dev fails with team/config/lock errors, retry at most once.
+- If the second attempt fails, do not enter Implementation Log polling or repeated recovery spawn loops.
+- Use the documented inline/recovery fallback: write `failure-log.md` with the spawn error and last observable state, then either complete remaining tasks directly in the orchestrator or stop with a clear failure for recovery.
+- Apply the same cap to Dev re-spawns for Implementation Log repair or resume prompts; do not burn multiple minutes on identical team/config/lock failures.
+
 **Prompt**:
 > {{AGENT_PROMPT_DEV_IMPLEMENT}}
 
+**No silent artifact polling**:
+- Do NOT run a long no-output loop that only waits for `## Implementation Log` or any other file marker.
+- If you must wait for Dev after spawning or sending a status request, use short bounded checks (≤120s) that print a heartbeat line each iteration with: elapsed time, remaining unchecked task count, whether `## Implementation Log` exists, and whether `git diff --stat` changed.
+- If Dev has no transcript/file/diff progress for one bounded check, send one status request. If there is still no progress on the next bounded check, stop waiting, write `failure-log.md` with the last observable state, and follow Subagent Timeout Recovery.
+- Prefer the Agent tool's completion notification or Dev's `COMPLETION_SIGNAL`; file presence alone is not a liveness signal.
+
 **Gate Check — Implementation Log**:
 After Dev agent returns, verify the Implementation Log was written:
 ```bash
@@ -38,7 +43,7 @@ Wait for Dev to return. **If Dev times out before all tasks are `[x]`**:
    > {{AGENT_PROMPT_DEV_RESUME}}
 3. Max 2 recovery retries. After 2 failures, orchestrator implements remaining tasks directly.
 
-All tasks `[x]`, tests pass.
+Implementation phase is complete only when all tasks are `[x]` and the Test Failure Recovery Protocol's Success Rule is satisfied.
 
 
 **Checkpoint update**: Run the update script to set step `prizmkit-implement` to `"completed"`:

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

@@ -1,18 +1,9 @@
 ### Implement + Test
 
-**Build artifacts**: After any build/compile command (`go build`, `npm run build`, `tsc`, etc.), ensure the output binary or build directory is in `.gitignore`:
-```bash
-# Example for Go
-grep -q '^/binary-name$' .gitignore || echo '/binary-name' >> .gitignore
-```
-Never commit compiled binaries, build output, or generated artifacts.
-
-**Dependency version gate (BLOCKING)**: Before running ANY package install command (`npm install`, `pip install`, `cargo build`, `go mod tidy`, `bundle install`, etc.):
-1. Every version number in your dependency manifest MUST be verified against the real registry (see Context Budget Rules §9)
-2. If you used a scaffold tool that generated a `package.json` / `requirements.txt` / etc., verify the versions it wrote too — scaffold tools can emit outdated versions
-3. Do NOT proceed with install until all versions are confirmed real. Violation = wasted timeout cycles
-
-**Scaffold file rule**: After running any init/scaffold command, record generated files in context-snapshot.md under `### Scaffold Files (do not re-read)`. Never re-read these files — their content is standard boilerplate (see Context Budget Rules §8).
+**Protocol references**:
+- Follow Context Budget Rules §8 for scaffold/generated files.
+- Follow Context Budget Rules §9 before package install/build commands that resolve dependencies.
+- Follow Context Budget Rules §10 after build/compile commands.
 
 **3a.** Detect test commands and record baseline:
 
@@ -32,11 +23,11 @@ You know this project's tech stack. Identify ALL test commands that apply (e.g.,
 
 **3c.** After implement completes, verify:
 1. All tasks in plan.md are `[x]`
-2. Run the full test suite to ensure nothing is broken
-3. Verify each acceptance criterion from Section 1 of context-snapshot.md is met — check mentally, do NOT re-read files you already wrote
-4. If any criterion is not met, fix it now using the convergence-based recovery loop (see Test Failure Recovery Protocol)
+2. Run the full test suite to ensure no new regressions remain
+3. Verify each Verification Gate from the Task Contract — check mentally, do NOT re-read files you already wrote
+4. If any gate is unmet or blocked, follow the Test Failure Recovery Protocol
 
-**CP-2**: All acceptance criteria met, all tests pass.
+**CP-2**: Implementation may proceed only when all tasks are `[x]` and the Test Failure Recovery Protocol's Success Rule is satisfied. Blocked gates must be documented in `failure-log.md` and are not success.
 
 
 **Checkpoint update**: Run the update script to set step `prizmkit-implement` to `"completed"`:

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

@@ -5,7 +5,7 @@ ls .prizmkit/specs/{{FEATURE_SLUG}}/ 2>/dev/null
 ```
 
 If plan.md missing, run `/prizmkit-plan` with `artifact_dir=.prizmkit/specs/{{FEATURE_SLUG}}/`:
-- Pass the feature description and acceptance criteria from the Feature Context section above as input
+- Pass the Objective and Verification Gates from the Task Contract as input
 - The plan.md should include: key components, data flow, files to create/modify, and a Tasks section with `[ ]` checkboxes (each task = one implementable unit). Keep under 80 lines.
 - Resolve any `[NEEDS CLARIFICATION]` markers using the feature description — do NOT pause for interactive input.
 

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

@@ -9,7 +9,11 @@ After `/prizmkit-code-review` returns, verify the review report:
 ```bash
 grep -q "## Verdict" .prizmkit/specs/{{FEATURE_SLUG}}/review-report.md && echo "GATE:PASS" || echo "GATE:MISSING"
 ```
-If GATE:MISSING — re-run `/prizmkit-code-review`.
+If GATE:MISSING:
+- Do not re-run `/prizmkit-code-review` in an unbounded report-repair loop.
+- Perform one bounded status check; retry at most once: inspect the skill output, `review-report.md` path, and any Reviewer/Dev spawn messages.
+- If the missing report is caused by team/config/lock errors from the internal Reviewer/Dev agent spawn, retry `/prizmkit-code-review` at most once only if it appears transient.
+- 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 to next phase

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

@@ -9,7 +9,11 @@ After `/prizmkit-code-review` returns, verify the review report:
 ```bash
 grep -q "## Verdict" .prizmkit/specs/{{FEATURE_SLUG}}/review-report.md && echo "GATE:PASS" || echo "GATE:MISSING"
 ```
-If GATE:MISSING — re-run `/prizmkit-code-review`.
+If GATE:MISSING:
+- Do not re-run `/prizmkit-code-review` in an unbounded report-repair loop.
+- Perform one bounded status check; retry at most once: inspect the skill output, `review-report.md` path, and any Reviewer/Dev spawn messages.
+- If the missing report is caused by team/config/lock errors from the internal Reviewer/Dev agent spawn, retry `/prizmkit-code-review` at most once only if it appears transient.
+- 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 to next phase
@@ -17,7 +21,7 @@ Read `review-report.md` and check the Verdict:
 
 Run the full test suite: `({{TEST_CMD}}) 2>&1 | tee /tmp/review-test-out.txt | tail -20`
 
-**CP-3**: Review complete, tests pass, report written.
+**CP-3**: Review complete, report written, and the Test Failure Recovery Protocol's Success Rule is satisfied.
 
 
 **Checkpoint update**: Run the update script to set step `prizmkit-code-review` to `"completed"`:

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'