prizmkit 1.1.69 → 1.1.70

package/bundled/dev-pipeline-windows/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-windows/templates/sections/phase-browser-verification-auto.md

@@ -1,8 +1,9 @@
 ### Browser Verification — MANDATORY
 
-You MUST execute this phase. Use native PowerShell commands for setup, server lifecycle, and cleanup.
+You MUST attempt this phase. Mark it as skipped only when no usable browser tool can be found, installed, or started. Use native PowerShell commands for setup, server lifecycle, and cleanup.
+
+**Step 0 — Tool Selection (BLOCKING — decide before any browser action)**:
 
-**Tool readiness**:
 ```powershell
 $playwright = Get-Command playwright-cli -ErrorAction SilentlyContinue
 $opencli = Get-Command opencli -ErrorAction SilentlyContinue
@@ -10,16 +11,25 @@ if ($playwright) { playwright-cli --version } else { "PLAYWRIGHT_CLI:NOT_INSTALL
 if ($opencli) { opencli --version } else { "OPENCLI:NOT_INSTALLED" }
 ```
 
-If neither browser tool is available, install playwright-cli as the default:
+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:
+   ```powershell
+   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.
+
+Use `opencli` instead of `playwright-cli` only when the scenario requires an existing Chrome login/session or third-party integration cookies.
+
+Record your choice:
 ```powershell
-npm install -g @playwright/cli@latest
-playwright-cli --version
+$BROWSER_TOOL = "playwright-cli"   # or "opencli" or "skipped"
+"Selected browser tool: $BROWSER_TOOL"
 ```
 
-**Choose the tool**:
-- Use `playwright-cli` for isolated local dev-server verification.
-- Use `opencli` when the scenario needs an existing Chrome login/session.
-- If opencli is selected, verify connectivity with `opencli doctor` before browser actions.
+If `$BROWSER_TOOL -eq "skipped"`, do NOT start a dev server and do NOT run browser commands. Go directly to result reporting and the checkpoint update.
 
 **Dev server setup**:
 ```powershell
@@ -56,6 +66,8 @@ Use the selected browser tool to inspect current page state, perform actions, an
 - `playwright-cli open http://localhost:$DEV_PORT`, `playwright-cli snapshot`, `playwright-cli screenshot`, `playwright-cli close`
 - `opencli browser open http://localhost:$DEV_PORT`, `opencli browser state`, `opencli browser screenshot`, `opencli browser close`
 
+Base concrete actions on the Task Contract's Verification Gates.
+
 **Cleanup**:
 ```powershell
 if ($DEV_SERVER_PID) { Stop-Process -Id $DEV_SERVER_PID -Force -ErrorAction SilentlyContinue }
@@ -64,7 +76,7 @@ Get-NetTCPConnection -LocalPort ([int]$DEV_PORT) -ErrorAction SilentlyContinue |
   ForEach-Object { Stop-Process -Id $_ -Force -ErrorAction SilentlyContinue }
 ```
 
-Append results to `context-snapshot.md` with tool, URL, commands used, screenshot path, PASS/FAIL reason, and cleanup status.
+Append results to `context-snapshot.md` with tool, URL, commands used, screenshot path, PASS/FAIL/SKIPPED reason, and cleanup status.
 
 **Checkpoint update**:
 ```powershell

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

@@ -15,7 +15,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:
      ```powershell
 	     Get-ChildItem -Path . -Directory -Recurse -Depth 2 -ErrorAction SilentlyContinue |

package/bundled/dev-pipeline-windows/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-windows/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:
 ```powershell
@@ -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-windows/templates/sections/phase-implement-lite.md

@@ -1,20 +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`:
-```powershell
-# Example for Go
-if (-not (Select-String -Path .gitignore -Pattern '^/binary-name$' -Quiet -ErrorAction SilentlyContinue)) {
-  Add-Content -Path .gitignore -Value '/binary-name'
-}
-```
-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:
 
@@ -36,11 +25,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-windows/templates/sections/phase-plan-lite.md

@@ -5,7 +5,7 @@ Get-ChildItem .prizmkit/specs/{{FEATURE_SLUG}}/ -ErrorAction SilentlyContinue
 ```
 
 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-windows/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-Object (Join-Path $env:TEMP "review-test-out.txt") | Select-Object -Last 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-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.70",
   "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.70",
   "description": "Create a new PrizmKit-powered project with clean initialization — no framework dev files, just what you need.",
   "type": "module",
   "bin": {