prizmkit 1.1.100 → 1.1.102

package/bundled/dev-pipeline-windows/templates/sections/phase-commit.md

@@ -1,75 +0,0 @@
-### Architecture Sync & Commit (SINGLE COMMIT)
-
-**a.** Run `/prizmkit-retrospective` — maintains `.prizmkit/prizm-docs/` (architecture index):
-1. **Structural sync**: Use `git diff --cached --name-status` to locate changed modules, update KEY_FILES/INTERFACES/DEPENDENCIES/file counts in affected `.prizmkit/prizm-docs/` files
-2. **Architecture knowledge** (feature sessions only): Extract TRAPS/RULES/DECISIONS from completed work into `.prizmkit/prizm-docs/`
-3. **L2 coverage check**: For any module/sub-module with source files created or significantly modified in this session but no L2 `.prizm` doc — evaluate whether L2 is warranted and create if so. The current session has the best context for accurate KEY_FILES, TRAPS, and DECISIONS.
-4. Stage doc changes: `git add .prizmkit/prizm-docs/`
-⚠️ Do NOT commit here. Only stage.
-
-**b.** Stage all feature code explicitly (NEVER use `git add -A` or `git add .`):
-```powershell
-git add <specific-files-created-or-modified>
-git add .prizmkit/prizm-docs/
-```
-
-**c.** Run `/prizmkit-committer` → THE ONLY commit for this feature:
-`feat({{FEATURE_ID}}): {{FEATURE_TITLE}}`
-This single commit includes: feature code + tests + .prizmkit/prizm-docs/ updates. Do NOT push.
-- MANDATORY: commit must be done via `/prizmkit-committer` skill. Do NOT run manual `git add`/`git commit` as a substitute.
-- Do NOT run `update-feature-status.py` here — the pipeline runner handles feature-list.json updates automatically after session exit.
-
-**d.** Final verification:
-```powershell
-git status --short
-```
-Working tree MUST be clean after this step. If any feature-related files remain, stage them into the SAME commit via `git add <file>; if ($LASTEXITCODE -eq 0) { git commit --amend --no-edit }`, do NOT create a separate commit.
-
-**e.** Write completion summary for downstream dependency context:
-
-Write `.prizmkit/specs/{{FEATURE_SLUG}}/completion-summary.json` with the key changes from this session. This file is NOT committed to git — the pipeline runner reads it to propagate context to dependent features.
-
-```json
-{
-  "completion_notes": [
-    "<each item: one key change, API, model, or integration point that downstream features may need>",
-    "Example: Added User model (id, email, password_hash, display_name) in prisma/schema.prisma",
-    "Example: POST /api/auth/register and POST /api/auth/login endpoints in src/api/auth.ts",
-    "Example: Auth middleware in src/middleware/auth.ts — validates JWT on protected routes"
-  ]
-}
-```
-
-Rules for writing completion notes:
-- Focus on **what downstream features need to know**: new APIs, models, exported functions, key file paths
-- Each note should be self-contained and concise (one line, under 120 characters preferred)
-- Include 3-8 notes covering the most important changes
-- Do NOT include test files, config changes, or internal implementation details unless they affect other features
-- If this feature has no downstream dependents, still write the summary (it serves as documentation)
-
-
-**Checkpoint update**: After `/prizmkit-retrospective` completes, run the update script to set step `prizmkit-retrospective` to `"completed"`:
-```powershell
-Invoke-PrizmPython {{PIPELINE_DIR}}\scripts\update-checkpoint.py `
-  --checkpoint-path {{CHECKPOINT_PATH}} `
-  --step prizmkit-retrospective `
-  --status completed
-```
-After `/prizmkit-committer` completes, set step `prizmkit-committer` to `"completed"`:
-```powershell
-Invoke-PrizmPython {{PIPELINE_DIR}}\scripts\update-checkpoint.py `
-  --checkpoint-path {{CHECKPOINT_PATH}} `
-  --step prizmkit-committer `
-  --status completed
-```
-
-### TERMINAL STOP — Commit Completed
-
-After all of the following are true, the session is **TERMINAL**:
-
-- `/prizmkit-committer` has completed
-- `git status --short` is clean (except ignored/local-only pipeline artifacts)
-- `.prizmkit/specs/{{FEATURE_SLUG}}/completion-summary.json` is written
-- the `prizmkit-committer` checkpoint is marked `completed`
-
-At that point, stop immediately. Do **not** process delayed teammate/reviewer findings, do **not** edit files, do **not** amend the commit, and do **not** start any new tool calls. Any findings that arrive after S09 is completed are follow-up work for a later session, not part of this feature commit.

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

@@ -1,23 +0,0 @@
-   - **Section 3 — Key TRAPS & RULES**: extract only relevant TRAPS/RULES from prizm-docs. Do NOT copy full L0/L1/L2 content — the orchestrator already loaded them.
-   - **Section 4 — File Manifest**: For each file relevant to this feature, list: file path, why it's needed (modify/reference/test), key interface signatures (function names + params + return types). Do NOT include full file content — agents read files on-demand. Format:
-     ### Files to Modify
-     | File | Why Needed | Key Interfaces |
-     |------|-----------|----------------|
-     | `<source-dir>/config.js` | Add runtime config layer | `config` (Zod object), `configSchema` |
-
-     ### Files for Reference
-     | File | Why Needed | Key Interfaces |
-     |------|-----------|----------------|
-     | `<source-dir>/security/permission-guard.js` | Permission check integration | `checkCommandPermission(userId, cmd)` |
-
-     ### Known TRAPS (from .prizmkit/prizm-docs/)
-     - <trap entries extracted from L1/L2 docs>
-
-
-**Checkpoint update**: Run the update script to set step `context-snapshot` to `"completed"`:
-```powershell
-Invoke-PrizmPython {{PIPELINE_DIR}}\scripts\update-checkpoint.py `
-  --checkpoint-path {{CHECKPOINT_PATH}} `
-  --step context-snapshot `
-  --status completed
-```

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

@@ -1,14 +0,0 @@
-### Build Context Snapshot
-
-```powershell
-if (Test-Path .prizmkit\specs\{{FEATURE_SLUG}}\context-snapshot.md) { "EXISTS" } else { "MISSING" }
-```
-
-If MISSING — build it now:
-1. Read `.prizmkit/prizm-docs/root.prizm` and relevant L1/L2 prizm docs
-2. Read source files listed in the feature's scope (use prizm-docs KEY_FILES for guidance)
-3. Write `.prizmkit/specs/{{FEATURE_SLUG}}/context-snapshot.md`:
-   - **Section 1 — Feature Brief**: 2-3 line feature description from Task Contract
-   - **Section 2 — Verification Gates**: gate checklist from Task Contract
-   - **Section 3 — Key TRAPS & RULES**: extract only relevant TRAPS/RULES from prizm-docs that apply to files in this scope. Do NOT copy full L0/L1/L2 content.
-   - **Section 4 — File Manifest**: file path, why needed, key interfaces. Format: Files to Modify | Files for Reference tables.

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

@@ -1,19 +0,0 @@
-   - **Section 3 — Key TRAPS & RULES**: extract only relevant TRAPS/RULES from prizm-docs that apply to files in this scope. Do NOT copy full L0/L1/L2 content.
-   - **Section 4 — File Manifest**: For each relevant file, list path, why needed, key interface signatures. Use table format:
-
-     ### Files to Modify
-     | File | Why Needed | Key Interfaces |
-     |------|-----------|----------------|
-
-     ### Files for Reference
-     | File | Why Needed | Key Interfaces |
-     |------|-----------|----------------|
-
-
-**Checkpoint update**: Run the update script to set step `context-snapshot` to `"completed"`:
-```powershell
-Invoke-PrizmPython {{PIPELINE_DIR}}\scripts\update-checkpoint.py `
-  --checkpoint-path {{CHECKPOINT_PATH}} `
-  --step context-snapshot `
-  --status completed
-```

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

@@ -1,63 +0,0 @@
-### Plan Challenge — Critic Agent(s)
-
-**Guard**: Verify critic agent file exists before spawning:
-```powershell
-if (Test-Path -LiteralPath "{{CRITIC_SUBAGENT_PATH}}") { "CRITIC:READY" } else { "CRITIC:MISSING" }
-```
-If CRITIC:MISSING — skip this phase entirely and proceed. Log: "Critic agent not installed — skipping Plan Challenge."
-
-**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**:
-| Parameter | Value |
-|-----------|-------|
-| subagent_type | prizm-dev-team-critic |
-| mode | plan |
-| run_in_background | false |
-
-**Prompt**:
-> {{AGENT_PROMPT_CRITIC_PLAN_CHALLENGE}}
-
-**If {{CRITIC_COUNT}} = 3 → Multi-Critic Voting** (skip Single Critic above):
-
-Spawn 3 Critic agents in PARALLEL (issue all 3 Agent tool calls in the SAME message turn). Do NOT wait for one before spawning the next. Each with mode="plan", run_in_background=false:
-
-Critic-A prompt (append to base prompt above):
-> "**Focus Lens: Architecture & Scalability.** Prioritize: architectural pattern fit, scalability implications, over-engineering risks, component boundary design.
-> Write `.prizmkit/specs/{{FEATURE_SLUG}}/challenge-report-A.md`."
-
-Critic-B prompt (append to base prompt above):
-> "**Focus Lens: Data Model & Edge Cases.** Prioritize: data model design fit, entity relationships, edge cases in business logic, missing boundary conditions.
-> Write `.prizmkit/specs/{{FEATURE_SLUG}}/challenge-report-B.md`."
-
-Critic-C prompt (append to base prompt above):
-> "**Focus Lens: Security & Performance.** Prioritize: security attack surface, authentication/authorization gaps, performance bottlenecks, resource leaks.
-> Write `.prizmkit/specs/{{FEATURE_SLUG}}/challenge-report-C.md`."
-
-After all critics return, read all 3 reports:
-- Challenge raised by **2/3 or more** critics → **must respond** (adjust plan or justify why not)
-- Challenge raised by **1/3 only** → logged in context-snapshot but not blocking
-- Max 1 plan revision round.
-
-**CP-2.5**: Plan challenges reviewed and resolved.
-
-
-**Checkpoint update**: Run the update script to set step `critic-plan-review` to `"completed"`:
-```powershell
-Invoke-PrizmPython {{PIPELINE_DIR}}\scripts\update-checkpoint.py `
-  --checkpoint-path {{CHECKPOINT_PATH}} `
-  --step critic-plan-review `
-  --status completed
-```

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

@@ -1,42 +0,0 @@
-### Plan Challenge — Critic Agent
-
-**Guard**: Verify critic agent file exists before spawning:
-```powershell
-if (Test-Path -LiteralPath "{{CRITIC_SUBAGENT_PATH}}") { "CRITIC:READY" } else { "CRITIC:MISSING" }
-```
-If CRITIC:MISSING — skip this phase entirely and proceed. Log: "Critic agent not installed — skipping Plan Challenge."
-
-**Spawn Agent**:
-| Parameter | Value |
-|-----------|-------|
-| subagent_type | prizm-dev-team-critic |
-| mode | plan |
-| run_in_background | false |
-
-**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.
-
-**CP-2.5**: Plan challenges reviewed and resolved.
-
-
-**Checkpoint update**: Run the update script to set step `critic-plan-review` to `"completed"`:
-```powershell
-Invoke-PrizmPython {{PIPELINE_DIR}}\scripts\update-checkpoint.py `
-  --checkpoint-path {{CHECKPOINT_PATH}} `
-  --step critic-plan-review `
-  --status completed
-```

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

@@ -1,44 +0,0 @@
-### Implement — Dev Subagent
-
-**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 |
-|-----------|-------|
-| subagent_type | prizm-dev-team-dev |
-| run_in_background | false |
-| isolation | Leave empty — Dev works directly in the repo, no worktree |
-
-**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. 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:
-```powershell
-$contextSnapshot = '.prizmkit\specs\{{FEATURE_SLUG}}\context-snapshot.md'
-if ((Test-Path $contextSnapshot) -and (Select-String -Path $contextSnapshot -Pattern '## Implementation Log' -Quiet)) { "GATE:PASS" } else { "GATE:MISSING" }
-```
-If GATE:MISSING — send message to Dev (re-spawn if needed): "Write the '## Implementation Log' section to context-snapshot.md before I can proceed to review. Include: files changed/created, key decisions, deviations from plan, notable discoveries."
-
-
-**Checkpoint update**: Run the update script to set step `prizmkit-implement` to `"completed"`:
-```powershell
-Invoke-PrizmPython {{PIPELINE_DIR}}\scripts\update-checkpoint.py `
-  --checkpoint-path {{CHECKPOINT_PATH}} `
-  --step prizmkit-implement `
-  --status completed
-```

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

@@ -1,59 +0,0 @@
-### Implement — Dev Agent
-
-**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
-if (Test-Path -LiteralPath ".prizmkit/specs/{{FEATURE_SLUG}}/plan.md") {
-  (Select-String -Path ".prizmkit/specs/{{FEATURE_SLUG}}/plan.md" -Pattern '^- \[ \]' -ErrorAction SilentlyContinue).Count
-} else {
-  0
-}
-```
-- If result is `0` (all tasks already `[x]`) → **SKIP this phase**, go directly to Review. Do NOT spawn Dev.
-- If result is non-zero → spawn Dev agent below.
-
-**Spawn Agent**:
-| Parameter | Value |
-|-----------|-------|
-| 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:
-```powershell
-if (Select-String -Path ".prizmkit/specs/{{FEATURE_SLUG}}/context-snapshot.md" -Pattern "## Implementation Log" -Quiet -ErrorAction SilentlyContinue) { "GATE:PASS" } else { "GATE:MISSING" }
-```
-If GATE:MISSING — send message to Dev (re-spawn if needed): "Write the '## Implementation Log' section to context-snapshot.md before I can proceed to review. Include: files changed/created, key decisions, deviations from plan, notable discoveries."
-
-Wait for Dev to return. **If Dev times out before all tasks are `[x]`**:
-1. Check progress: `(Select-String -Path ".prizmkit/specs/{{FEATURE_SLUG}}/plan.md" -Pattern '^- \[ \]' -ErrorAction SilentlyContinue).Count`
-2. If any tasks remain: re-spawn Dev with this recovery prompt:
-   > {{AGENT_PROMPT_DEV_RESUME}}
-3. Max 2 recovery retries. After 2 failures, orchestrator implements remaining tasks directly.
-
-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"`:
-```powershell
-Invoke-PrizmPython {{PIPELINE_DIR}}\scripts\update-checkpoint.py `
-  --checkpoint-path {{CHECKPOINT_PATH}} `
-  --step prizmkit-implement `
-  --status completed
-```

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

@@ -1,39 +0,0 @@
-### Implement + Test
-
-**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:
-
-You know this project's tech stack. Identify ALL test commands that apply (e.g., `go test ./...`, `npm test`, `cargo test`, `pytest`, `make test`, etc.). Record them as `TEST_CMDS`. Then record baseline:
-```powershell
-# Run each test command, capture output
-& { {{TEST_CMD}} } 2>&1 | Tee-Object (Join-Path $env:TEMP "test-baseline.txt") | Select-Object -Last 20
-```
-
-**3b.** Run `/prizmkit-implement` — this handles the full implementation cycle:
-- Reads plan.md Tasks section from `.prizmkit/specs/{{FEATURE_SLUG}}/`
-- Reads context from `context-snapshot.md` (Prizm docs, TRAPS, file manifest)
-- Implements task-by-task with TDD, marking each `[x]` immediately
-- Creates/updates L2 `.prizm` docs when creating new modules or significantly modifying existing ones — AI selectively decides the modules that warrant L2 based on complexity and importance
-- Runs tests using `TEST_CMD` after each task
-- Writes '## Implementation Log' to `context-snapshot.md`
-
-**3c.** After implement completes, verify:
-1. All tasks in plan.md are `[x]`
-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**: 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"`:
-```powershell
-Invoke-PrizmPython {{PIPELINE_DIR}}\scripts\update-checkpoint.py `
-  --checkpoint-path {{CHECKPOINT_PATH}} `
-  --step prizmkit-implement `
-  --status completed
-```

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

@@ -1,27 +0,0 @@
-### Plan & Tasks
-
-```powershell
-Test-Path -LiteralPath ".prizmkit/specs/{{FEATURE_SLUG}}/plan.md"
-```
-
-If missing, run `/prizmkit-plan` with `artifact_dir=.prizmkit/specs/{{FEATURE_SLUG}}/` to generate `plan.md`:
-- The plan.md should include: architecture — components, interfaces, data flow, files to create/modify, testing approach, and a Tasks section with `[ ]` checkboxes ordered by dependency.
-- Resolve any `[NEEDS CLARIFICATION]` markers using the feature description — do NOT pause for interactive input.
-
-**Database Design Gate** (if feature involves data persistence — new tables, schema changes, new entities):
-Before proceeding past CP-1, verify:
-1. Plan.md Data Model section references existing schema/model files (scan for `*.prisma`, `*.sql`, `migrations/`, `models/`, `*.entity.*` files; read them if not already in context-snapshot)
-2. All new tables/fields follow existing naming conventions, ID strategy, timestamp patterns, and constraint style
-3. No `[NEEDS CLARIFICATION]` remains in Data Model section — resolve by reading existing code and making a conservative choice that matches existing patterns. Document the resolution in plan.md.
-4. If a DB design decision genuinely cannot be resolved from existing code alone, document the assumption made and flag it in the Implementation Log for user review.
-
-**CP-1**: plan.md exists with Tasks section.
-
-
-**Checkpoint update**: Run the update script to set step `prizmkit-plan` to `"completed"`:
-```powershell
-Invoke-PrizmPython {{PIPELINE_DIR}}\scripts\update-checkpoint.py `
-  --checkpoint-path {{CHECKPOINT_PATH}} `
-  --step prizmkit-plan `
-  --status completed
-```

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

@@ -1,27 +0,0 @@
-### Plan & Tasks
-
-```powershell
-Get-ChildItem -LiteralPath ".prizmkit/specs/{{FEATURE_SLUG}}/" -ErrorAction SilentlyContinue
-```
-
-If plan.md missing, run `/prizmkit-plan` with `artifact_dir=.prizmkit/specs/{{FEATURE_SLUG}}/`:
-- 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.
-
-**Database Design Gate** (if feature involves data persistence — new tables, schema changes, new entities):
-Before proceeding past CP-1:
-1. Scan for existing schema files (`*.prisma`, `*.sql`, `migrations/`, `models/`, `*.entity.*`) and read them
-2. Ensure new tables/fields follow existing naming conventions and constraint patterns
-3. Resolve all uncertain DB design decisions before writing Tasks — document choices in plan.md
-
-**CP-1**: plan.md exists with Tasks section.
-
-
-**Checkpoint update**: Run the update script to set step `prizmkit-plan` to `"completed"`:
-```powershell
-Invoke-PrizmPython {{PIPELINE_DIR}}\scripts\update-checkpoint.py `
-  --checkpoint-path {{CHECKPOINT_PATH}} `
-  --step prizmkit-plan `
-  --status completed
-```

package/bundled/dev-pipeline-windows/templates/sections/phase-prizmkit-test.md

@@ -1,39 +0,0 @@
-### Scoped Feature Test Gate — PrizmKit Test
-
-**Goal**: Generate and verify tests for this feature's changed scope before code review without embedding the full gate implementation in this prompt.
-
-Create a start marker immediately before invoking the skill so the gate can reject stale reports from older sessions:
-
-```powershell
-Invoke-PrizmPython {{PIPELINE_DIR}}\scripts\prizmkit-test-gate.py start `
-  --feature-slug "{{FEATURE_SLUG}}"
-```
-
-Run `/prizmkit-test` with the feature artifact directory:
-
-```text
-/prizmkit-test scope=this-change artifact_dir=.prizmkit/specs/{{FEATURE_SLUG}}/
-```
-
-Rules:
-- This gate is feature-pipeline only. Do NOT use `.prizmkit/bugfix/` or `.prizmkit/refactor/` artifact directories here.
-- Generate or update tests only for this feature's changed files, changed public interfaces, and acceptance criteria.
-- Record unrelated historical coverage gaps under `Out of Scope Gaps`; do not generate tests for them and do not fail this feature because of them.
-- If generated tests fail because implementation is wrong, fix implementation within this feature scope and rerun the affected tests.
-- If failures are baseline or unrelated to this feature, document them in the report and continue only when no in-scope failure remains unexplained.
-
-**Gate Check — Test Report**:
-After `/prizmkit-test` returns, run the gate script to locate the newest current-run report, validate scope/freshness/boundary coverage, write `test-report-path.txt`, and mark the `prizmkit-test` checkpoint completed only on `GATE:PASS`:
-
-```powershell
-Invoke-PrizmPython {{PIPELINE_DIR}}\scripts\prizmkit-test-gate.py check `
-  --feature-slug "{{FEATURE_SLUG}}" `
-  --artifact-dir ".prizmkit/specs/{{FEATURE_SLUG}}/" `
-  --checkpoint-path "{{CHECKPOINT_PATH}}"
-```
-
-Gate outcomes:
-- `GATE:PASS` → append the report path and a 3-5 bullet summary to `context-snapshot.md` under `## PrizmKit Test Gate`, then proceed to the next checkpoint step. The gate script already wrote `test-report-path.txt` and marked `prizmkit-test` completed.
-- `GATE:FAIL` with `NEEDS_FIXES` → read the report's `In-Scope Failures`, fix the feature implementation or generated tests within this feature scope, rerun `/prizmkit-test`, and repeat the gate check. Do not proceed to code review while the verdict is not `PASS`.
-- `GATE:FAIL` with `BLOCKED`, wrong mode, wrong artifact dir, unreadable report, stale scope, boundary failure, validator failure, or checkpoint update failure → write `.prizmkit/specs/{{FEATURE_SLUG}}/failure-log.md` with the scoped test failure and stop for recovery.
-- `GATE:MISSING` → perform one bounded status check: inspect `/prizmkit-test` output and `.prizmkit/test/` for a report directory. If no current-run report exists, write `failure-log.md` and stop for recovery.

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

@@ -1,35 +0,0 @@
-### Review — Code Review
-
-Precondition: the `prizmkit-test` checkpoint is completed and `.prizmkit/specs/{{FEATURE_SLUG}}/test-report-path.txt` points to the scoped test report.
-
-Before invoking review, read `.prizmkit/specs/{{FEATURE_SLUG}}/test-report-path.txt`, read the referenced `/prizmkit-test` report, and confirm the summary in `context-snapshot.md` under `## PrizmKit Test Gate` matches it. The code-review skill must receive this context through `artifact_dir=.prizmkit/specs/{{FEATURE_SLUG}}/` and the Reviewer must assess generated/updated test quality, `In-Scope Failures`, `Baseline Failures`, `Out of Scope Gaps`, boundary coverage if present, and the scoped report verdict.
-
-Run `/prizmkit-code-review` with `artifact_dir=.prizmkit/specs/{{FEATURE_SLUG}}/`.
-
-The skill runs an internal review-fix loop (Reviewer Agent → filter → Dev Agent fix, max 3 rounds) and writes `review-report.md` to the artifact directory.
-
-**Gate Check — Review Report**:
-After `/prizmkit-code-review` returns, verify the review report:
-```powershell
-if (Select-String -Path ".prizmkit/specs/{{FEATURE_SLUG}}/review-report.md" -Pattern "## Verdict" -Quiet -ErrorAction SilentlyContinue) { "GATE:PASS" } else { "GATE:MISSING" }
-```
-If GATE:MISSING:
-- Do not re-run `/prizmkit-code-review` in an unbounded report-repair loop.
-- Perform one bounded status check; retry 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
-- `NEEDS_FIXES` → the skill exhausted its max rounds; log the remaining findings and proceed (do not retry externally)
-
-**CP-3**: Review complete, report written.
-
-
-**Checkpoint update**: Run the update script to set step `prizmkit-code-review` to `"completed"`:
-```powershell
-Invoke-PrizmPython {{PIPELINE_DIR}}\scripts\update-checkpoint.py `
-  --checkpoint-path {{CHECKPOINT_PATH}} `
-  --step prizmkit-code-review `
-  --status completed
-```

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

@@ -1,35 +0,0 @@
-### Review — Code Review
-
-Precondition: the `prizmkit-test` checkpoint is completed and `.prizmkit/specs/{{FEATURE_SLUG}}/test-report-path.txt` points to the scoped test report.
-
-Before invoking review, read `.prizmkit/specs/{{FEATURE_SLUG}}/test-report-path.txt`, read the referenced `/prizmkit-test` report, and confirm the summary in `context-snapshot.md` under `## PrizmKit Test Gate` matches it. The code-review skill must receive this context through `artifact_dir=.prizmkit/specs/{{FEATURE_SLUG}}/` and the Reviewer must assess generated/updated test quality, `In-Scope Failures`, `Baseline Failures`, `Out of Scope Gaps`, boundary coverage if present, and the scoped report verdict.
-
-Run `/prizmkit-code-review` with `artifact_dir=.prizmkit/specs/{{FEATURE_SLUG}}/`.
-
-The skill runs an internal review-fix loop (Reviewer Agent → filter → Dev Agent fix, max 3 rounds) and writes `review-report.md` to the artifact directory.
-
-**Gate Check — Review Report**:
-After `/prizmkit-code-review` returns, verify the review report:
-```powershell
-if (Select-String -Path ".prizmkit/specs/{{FEATURE_SLUG}}/review-report.md" -Pattern "## Verdict" -Quiet -ErrorAction SilentlyContinue) { "GATE:PASS" } else { "GATE:MISSING" }
-```
-If GATE:MISSING:
-- Do not re-run `/prizmkit-code-review` in an unbounded report-repair loop.
-- Perform one bounded status check; retry 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
-- `NEEDS_FIXES` → the skill exhausted its max rounds; log the remaining findings and proceed (do not retry externally)
-
-**CP-3**: Review complete, report written.
-
-
-**Checkpoint update**: Run the update script to set step `prizmkit-code-review` to `"completed"`:
-```powershell
-Invoke-PrizmPython {{PIPELINE_DIR}}\scripts\update-checkpoint.py `
-  --checkpoint-path {{CHECKPOINT_PATH}} `
-  --step prizmkit-code-review `
-  --status completed
-```

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

@@ -1,73 +0,0 @@
-### Specify + Plan (Full Workflow)
-
-Check existing artifacts first:
-```powershell
-if (Test-Path .prizmkit\specs\{{FEATURE_SLUG}}) { Get-ChildItem .prizmkit\specs\{{FEATURE_SLUG}} | Select-Object -ExpandProperty Name } else { "MISSING" }
-```
-
-- Both (spec.md, plan.md) exist → **SKIP to CP-1**
-- `context-snapshot.md` exists → use it directly, skip context snapshot building
-- Some missing → generate only missing files
-
-**Step A — Build Context Snapshot** (skip if `context-snapshot.md` already exists):
-
-1. Read `.prizmkit/prizm-docs/root.prizm` and relevant L1/L2 prizm docs
-2. Detect source code directories: read KEY_FILES and STRUCTURE sections from `root.prizm` to identify where source code lives (e.g. `src/`, `app/`, `lib/`, `cmd/`, `packages/`, or project root). If `root.prizm` is missing, scan the project tree:
-   ```powershell
-   Get-ChildItem -Path . -File -Recurse -Depth 2 -Include *.js,*.ts,*.py,*.go,*.java,*.rb,*.rs -ErrorAction SilentlyContinue |
-     Where-Object { $_.FullName -notmatch '\\(node_modules|\.git|dist|build|vendor)(\\|$)' } |
-     Select-Object -First 30 -ExpandProperty FullName
-   ```
-   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 (copy from Task Contract above, 2-3 lines only)
-   - **Section 2 — Verification Gates**: copy the gate checklist from the Task Contract above
-   - **Section 3 — Key TRAPS & RULES**: extract TRAPS and RULES entries from loaded prizm-docs that apply to files in this feature's scope. Do NOT copy full L0/L1/L2 content — only the specific TRAPS/RULES lines relevant to the files listed in Section 4.
-   - **Section 4 — File Manifest**: For each file relevant to this feature, list path, why needed (modify/reference/test), key interface signatures. Do NOT include full file content. Format:
-     ### Files to Modify
-     | File | Why Needed | Key Interfaces |
-     |------|-----------|----------------|
-     | `<source-dir>/config.js` | Add runtime config layer | `config` (Zod object), `configSchema` |
-
-     ### Files for Reference
-     | File | Why Needed | Key Interfaces |
-     |------|-----------|----------------|
-     | `<source-dir>/security/permission-guard.js` | Permission check integration | `checkCommandPermission(userId, cmd)` |
-
-     ### Known TRAPS (from .prizmkit/prizm-docs/)
-     - <trap entries extracted from L1/L2 docs>
-5. Confirm with PowerShell: `if (Test-Path .prizmkit\specs\{{FEATURE_SLUG}}\context-snapshot.md) { "EXISTS" } else { "MISSING" }`
-
-**After Step A**: Use context-snapshot.md Section 4 File Manifest to guide targeted file reads. Do NOT scan directories or read unrelated files.
-
-**Step B — Planning Artifacts** (generate only missing files):
-
-```powershell
-@('.prizmkit\specs\{{FEATURE_SLUG}}\spec.md', '.prizmkit\specs\{{FEATURE_SLUG}}\plan.md') | ForEach-Object {
-  if (Test-Path $_) { $_ }
-}
-```
-
-- spec.md missing: Run `/prizmkit-plan` → generate spec.md. Resolve any `[NEEDS CLARIFICATION]` markers using the task description — do NOT pause for interactive input.
-- plan.md missing: Run `/prizmkit-plan` → generate plan.md (change approach, components, interface design, data model, testing strategy, risk assessment, and Tasks section with `[ ]` checkboxes)
-
-> All files go under `.prizmkit/specs/{{FEATURE_SLUG}}/`. Confirm each with `Test-Path` after writing.
-
-**Database Design Gate** (if feature involves data persistence — new tables, schema changes, new entities):
-Before proceeding past CP-1, verify:
-1. Plan.md Data Model section references existing schema/model files (scan for `*.prisma`, `*.sql`, `migrations/`, `models/`, `*.entity.*` files; read them if not already in context-snapshot)
-2. All new tables/fields follow existing naming conventions, ID strategy, timestamp patterns, and constraint style
-3. No `[NEEDS CLARIFICATION]` remains in Data Model section — resolve by reading existing code and making a conservative choice that matches existing patterns. Document the resolution in plan.md.
-4. If a DB design decision genuinely cannot be resolved from existing code alone, document the assumption made and flag it in the Implementation Log for user review.
-
-**CP-1**: Both spec.md and plan.md exist.
-
-
-**Checkpoint update**: Run the update script to set step `context-snapshot-and-plan` to `"completed"`:
-```powershell
-Invoke-PrizmPython {{PIPELINE_DIR}}\scripts\update-checkpoint.py `
-  --checkpoint-path {{CHECKPOINT_PATH}} `
-  --step context-snapshot-and-plan `
-  --status completed
-```