prizmkit 1.1.69 → 1.1.72

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

@@ -21,7 +21,7 @@ Get-ChildItem .prizmkit/specs/{{FEATURE_SLUG}}/ -ErrorAction SilentlyContinue
    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:
      ```powershell
 	     Get-ChildItem -Path . -Directory -Recurse -Depth 2 -ErrorAction SilentlyContinue |

package/bundled/dev-pipeline-windows/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-windows/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 the failed tests
-   - 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-windows/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 the failed tests
-   - 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/skills/_metadata.json

@@ -1,5 +1,5 @@
 {
-  "version": "1.1.69",
+  "version": "1.1.72",
   "skills": {
     "prizm-kit": {
       "description": "Full-lifecycle dev toolkit. Covers spec-driven development, Prizm context docs, code quality, debugging, deployment, and knowledge management.",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "prizmkit",
-  "version": "1.1.69",
+  "version": "1.1.72",
   "description": "Create a new PrizmKit-powered project with clean initialization — no framework dev files, just what you need.",
   "type": "module",
   "bin": {