prizmkit 1.1.69 → 1.1.70

package/bundled/VERSION.json

@@ -1,5 +1,5 @@
 {
-  "frameworkVersion": "1.1.69",
-  "bundledAt": "2026-06-09T23:54:02.566Z",
-  "bundledFrom": "7453dba"
+  "frameworkVersion": "1.1.70",
+  "bundledAt": "2026-06-10T03:59:21.944Z",
+  "bundledFrom": "e948b58"
 }

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

@@ -248,7 +248,7 @@ def extract_baseline_failures(test_cmd, 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))
@@ -285,10 +285,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:
@@ -932,6 +932,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")))
@@ -1041,13 +1045,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/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/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 /tmp/review-test-out.txt | tail -20`, then grep `/tmp/review-test-out.txt` for details — do NOT re-run the suite multiple times.

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.
@@ -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/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-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 |
@@ -24,7 +17,7 @@
 **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.

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
@@ -50,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-full.md

@@ -21,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"`: