prizmkit 1.1.100 → 1.1.102

package/bundled/dev-pipeline-windows/templates/refactor-list-schema.json

@@ -1,270 +0,0 @@
-{
-  "$schema": "http://json-schema.org/draft-07/schema#",
-  "title": "Dev-Pipeline Refactor List",
-  "description": "Schema for .prizmkit/plans/refactor-list.json — standardized input for the Refactor Pipeline",
-  "type": "object",
-  "required": [
-    "$schema",
-    "project_name",
-    "refactors"
-  ],
-  "properties": {
-    "$schema": {
-      "type": "string",
-      "const": "dev-pipeline-refactor-list-v1"
-    },
-    "project_name": {
-      "type": "string",
-      "minLength": 1
-    },
-    "project_description": {
-      "type": "string"
-    },
-    "created_at": {
-      "type": "string",
-      "format": "date-time"
-    },
-    "created_by": {
-      "type": "string"
-    },
-    "refactors": {
-      "type": "array",
-      "minItems": 1,
-      "items": {
-        "type": "object",
-        "required": [
-          "id",
-          "title",
-          "description",
-          "scope",
-          "type",
-          "priority",
-          "complexity",
-          "behavior_preservation",
-          "acceptance_criteria",
-          "dependencies",
-          "status"
-        ],
-        "properties": {
-          "id": {
-            "type": "string",
-            "pattern": "^R-\\d{3}$",
-            "description": "Refactor ID, format R-001, R-002..."
-          },
-          "title": {
-            "type": "string",
-            "minLength": 1,
-            "description": "Refactor title — brief description of the change"
-          },
-          "description": {
-            "type": "string",
-            "minLength": 1,
-            "description": "Detailed description: what is being refactored and why"
-          },
-          "scope": {
-            "type": "object",
-            "description": "Files and modules affected by this refactor",
-            "properties": {
-              "files": {
-                "type": "array",
-                "items": {
-                  "type": "string"
-                },
-                "description": "File paths affected by this refactor"
-              },
-              "modules": {
-                "type": "array",
-                "items": {
-                  "type": "string"
-                },
-                "description": "Module names affected by this refactor"
-              }
-            }
-          },
-          "type": {
-            "type": "string",
-            "enum": [
-              "extract",
-              "rename",
-              "restructure",
-              "simplify",
-              "decouple",
-              "migrate"
-            ],
-            "description": "extract=extract-function/module; rename=rename-symbols; restructure=move/reorganize; simplify=reduce-complexity; decouple=remove-dependencies; migrate=tech-migration"
-          },
-          "priority": {
-            "type": "string",
-            "enum": [
-              "critical",
-              "high",
-              "medium",
-              "low"
-            ],
-            "description": "Refactor priority. Pipeline processes critical before high before medium before low; within same level, array order determines sequence."
-          },
-          "complexity": {
-            "type": "string",
-            "enum": [
-              "low",
-              "medium",
-              "high"
-            ],
-            "description": "Estimated complexity of the refactor"
-          },
-          "behavior_preservation": {
-            "type": "object",
-            "required": [
-              "strategy"
-            ],
-            "description": "Strategy for ensuring no behavior changes",
-            "properties": {
-              "strategy": {
-                "type": "string",
-                "enum": [
-                  "test-gate",
-                  "snapshot",
-                  "manual"
-                ],
-                "description": "test-gate=existing-tests-must-pass; snapshot=before/after-snapshot-comparison; manual=human-verification"
-              },
-              "existing_tests": {
-                "type": "boolean",
-                "description": "Whether existing tests cover the refactored code"
-              },
-              "new_tests_needed": {
-                "type": "array",
-                "items": {
-                  "type": "string"
-                },
-                "description": "New tests that should be written before refactoring"
-              }
-            }
-          },
-          "acceptance_criteria": {
-            "type": "array",
-            "minItems": 1,
-            "items": {
-              "type": "string"
-            },
-            "description": "Conditions that must be met for the refactor to be considered complete"
-          },
-          "dependencies": {
-            "type": "array",
-            "items": {
-              "type": "string",
-              "pattern": "^R-\\d{3}$"
-            },
-            "description": "IDs of refactors that must be completed before this one"
-          },
-          "status": {
-            "type": "string",
-            "enum": [
-              "pending",
-              "in_progress",
-              "completed",
-              "failed",
-              "skipped",
-              "auto_skipped"
-            ],
-            "description": "Refactor status. Subset of feature status enum."
-          },
-          "model": {
-            "type": "string",
-            "description": "AI model ID for this refactor. Overrides $MODEL env var."
-          },
-          "estimated_lines": {
-            "type": "integer",
-            "description": "Estimated number of lines affected by this refactor"
-          },
-          "completion_notes": {
-            "type": "array",
-            "items": {
-              "type": "string"
-            },
-            "description": "AI-generated summary of key changes from this refactor session. Used to provide rich dependency context to downstream refactors. Each item is a concise statement about what was refactored (e.g. modules extracted, files restructured, interfaces changed)."
-          },
-          "user_context": {
-            "type": "array",
-            "items": { "type": "string" },
-            "description": "User-provided supplementary materials, preserved verbatim. Each entry is either inline content/rules (stored as-is) or a file reference (e.g. 'src/auth/login.ts:42-78', 'src/utils/ — focus on validation logic')."
-          },
-          "critic": {
-            "type": "boolean",
-            "description": "Enable adversarial plan challenge before implementation. Default: true for critical/high priority refactors, false for others.",
-            "default": false
-          },
-          "critic_count": {
-            "type": "integer",
-            "description": "Number of parallel critic agents. 1 = single critic, 3 = multi-critic voting. Default: 3 for critical, 1 for high, omit for others.",
-            "enum": [
-              1,
-              3
-            ]
-          },
-          "browser_interaction": {
-            "type": "object",
-            "description": "Browser verification config for refactors affecting UI behavior. Supports playwright-cli and opencli. AI auto-detects dev server command, URL, and port from project config at runtime.",
-            "properties": {
-              "tool": {
-                "type": "string",
-                "enum": ["playwright-cli", "opencli", "auto"],
-                "default": "auto",
-                "description": "Browser tool to use. 'auto' (default) = AI chooses at runtime. 'playwright-cli' = local dev server verification in isolated browser. 'opencli' = reuses Chrome logged-in session, ideal for verifying refactors involving third-party integrations or OAuth flows."
-              },
-              "verify_steps": {
-                "type": "array",
-                "description": "Verification goals describing WHAT to verify after refactoring (e.g., 'Navigation still works', 'Form submission succeeds', 'UI renders identically'). AI decides concrete browser tool actions at runtime. If omitted, AI explores the app and verifies no visual or behavioral regressions.",
-                "items": {
-                  "type": "string"
-                }
-              }
-            }
-          }
-        }
-      }
-    },
-    "global_context": {
-      "type": "object",
-      "description": "Global context for all refactors in this batch",
-      "properties": {
-        "tech_stack": {
-          "type": "string"
-        },
-        "language": {
-          "type": "string"
-        },
-        "runtime": {
-          "type": "string"
-        },
-        "frontend_framework": {
-          "type": "string"
-        },
-        "frontend_styling": {
-          "type": "string"
-        },
-        "backend_framework": {
-          "type": "string"
-        },
-        "database": {
-          "type": "string"
-        },
-        "orm": {
-          "type": "string"
-        },
-        "testing_strategy": {
-          "type": "string"
-        },
-        "bundler": {
-          "type": "string"
-        },
-        "project_type": {
-          "type": "string"
-        },
-        "ci_pipeline": {
-          "type": "string"
-        }
-      }
-    }
-  }
-}

package/bundled/dev-pipeline-windows/templates/sections/ac-verification-checklist.md

@@ -1,7 +0,0 @@
-## Verification Gates Compatibility Note
-
-This section file is retained for compatibility with older bootstrap templates.
-
-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-windows/templates/sections/checkpoint-system.md

@@ -1,91 +0,0 @@
-## Workflow Checkpoint System
-
-A checkpoint file tracks your progress through this workflow:
-
-**Path**: `{{CHECKPOINT_PATH}}`
-
-### Rules
-
-1. **Before each skill**: Read `workflow-checkpoint.json`, verify the previous step has `status: "completed"` or `status: "skipped"`. If it is still `"pending"` or `"in_progress"`, you MUST complete it first before moving on.
-
-2. **Starting a skill**: Use the update script to set the current step to `status: "in_progress"`.
-
-3. **After each skill completes**: Use the update script to set the current step to `status: "completed"`.
-
-4. **On failure**: Use the update script to set the step to `status: "failed"` and continue to the next step if possible, or halt and write failure-log.md.
-
-5. **On session exit**: The checkpoint file reflects your actual progress. Do NOT manually set future steps to "completed".
-
-### Checkpoint Update Pattern
-
-**IMPORTANT: NEVER hand-write or edit `workflow-checkpoint.json` directly. Always use the update script.**
-
-Define this helper once in the active PowerShell session before running PrizmKit Python scripts:
-
-```powershell
-function Invoke-PrizmPython {
-  param([Parameter(ValueFromRemainingArguments = $true)][string[]]$Arguments)
-  $python = Get-Command python -ErrorAction SilentlyContinue
-  if ($python) {
-    & $python.Source -c 'import sys; raise SystemExit(0 if sys.version_info[0] == 3 else 1)' *> $null
-    if ($LASTEXITCODE -eq 0) {
-      & $python.Source @Arguments
-      return
-    }
-  }
-  $py = Get-Command py -ErrorAction SilentlyContinue
-  if ($py) {
-    & $py.Source -3 -c 'import sys; raise SystemExit(0 if sys.version_info[0] == 3 else 1)' *> $null
-    if ($LASTEXITCODE -eq 0) {
-      & $py.Source -3 @Arguments
-      return
-    }
-  }
-  throw "Python 3 is required. Install Python and ensure python or py is in PATH."
-}
-```
-
-After completing each skill, run:
-
-```powershell
-Invoke-PrizmPython {{PIPELINE_DIR}}\scripts\update-checkpoint.py `
-  --checkpoint-path {{CHECKPOINT_PATH}} `
-  --step <SKILL_NAME> `
-  --status completed
-```
-
-For example, after completing `prizmkit-implement`:
-```powershell
-Invoke-PrizmPython {{PIPELINE_DIR}}\scripts\update-checkpoint.py `
-  --checkpoint-path {{CHECKPOINT_PATH}} `
-  --step prizmkit-implement `
-  --status completed
-```
-
-Before starting the next skill:
-```powershell
-Invoke-PrizmPython {{PIPELINE_DIR}}\scripts\update-checkpoint.py `
-  --checkpoint-path {{CHECKPOINT_PATH}} `
-  --step <NEXT_SKILL_NAME> `
-  --status in_progress
-```
-
-On failure:
-```powershell
-Invoke-PrizmPython {{PIPELINE_DIR}}\scripts\update-checkpoint.py `
-  --checkpoint-path {{CHECKPOINT_PATH}} `
-  --step <SKILL_NAME> `
-  --status failed `
-  --note "brief failure reason"
-```
-
-The script outputs JSON: `{"ok": true, ...}` on success, `{"ok": false, "error": "..."}` on failure.
-
-### Resume Behavior
-
-**Checkpoint is the primary source of truth for resume.** On retry sessions:
-
-1. Read `workflow-checkpoint.json` — steps already `"completed"` or `"skipped"` are skipped
-2. Start from the first `"pending"` or `"in_progress"` step
-3. If `failure-log.md` exists, read it for diagnostic context (the previous session failure reason, what approach to try differently) — but do NOT use it to determine the step to resume from
-4. If `workflow-checkpoint.json` is missing or corrupted, fall back to `failure-log.md` + the resume phase as the legacy mechanism

package/bundled/dev-pipeline-windows/templates/sections/context-budget-rules.md

@@ -1,34 +0,0 @@
-## Context Budget Rules (CRITICAL — read before any phase)
-
-You are running in **headless non-interactive mode** with a FINITE context window. Exceeding it will crash the session and lose all work. Follow these rules strictly:
-
-0. **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.
-
-1. **context-snapshot.md is your single source of truth** — After it is built, ALWAYS read context-snapshot.md instead of re-reading individual source files
-2. **Never re-read your own writes** — After you create/modify a file, do NOT read it back to verify. Trust your write was correct.
-3. **Stay focused** — Do NOT explore code unrelated to this feature. No curiosity-driven reads.
-4. **One task at a time** — Complete and test one task before starting the next.
-5. **Minimize tool output** — Never load full command output into context. First capture to a temp file (`& { <command> } 2>&1 | Tee-Object (Join-Path $env:TEMP "out.txt") | Select-Object -Last 20`), then scan the first/last lines to identify relevant fields, and use targeted filtering (`Select-String`, regex matching, PowerShell object filtering) to extract only the information needed for the current task. Only read the filtered result — never the raw full output.
-6. **No intermediate commits** — Do NOT run `git add`/`git commit` during implementation phases. All changes are committed once at the end via `/prizmkit-committer`.
-7. **Capture test output once** — When running test suites, always use `& { {{TEST_CMD}} } 2>&1 | Tee-Object (Join-Path $env:TEMP "test-out.txt") | Select-Object -Last 20`. Then Select-String `(Join-Path $env:TEMP "test-out.txt")` for details. Never re-run the suite just to apply a different filter.
-8. **Scaffold / generated file awareness (CRITICAL)** — When you run a scaffolding tool or package manager init command (`npm init`, `npx create-*`, `vite create`, `cargo init`, `go mod init`, `rails new`, `django-admin startproject`, `npx shadcn-ui init`, etc.), the output files are **generated boilerplate**. You MUST:
-   - Identify and mentally tag all files created by the tool as "scaffold files"
-   - Record the list of scaffold-generated files in context-snapshot.md under a `### Scaffold Files (do not re-read)` section
-   - **NEVER re-read scaffold files** after initial creation. Their content is standard boilerplate — you already know what they contain from the tool that generated them
-   - If you need to modify a scaffold file, make the edit directly without reading it first (you know the standard template content)
-   - This applies equally to `node_modules/`, `package-lock.json`, generated config files (`tsconfig.json`, `vite.config.ts`, `tailwind.config.js`, `.eslintrc`, etc.) produced by init commands
-   - When passing context to subagents, explicitly tell them Get-Command files are scaffold-generated so they skip reading them too
-9. **Package version verification (HARD CONSTRAINT — BLOCKING)** — Before writing ANY dependency version in `package.json`, `requirements.txt`, `Cargo.toml`, `go.mod`, `Gemfile`, `pyproject.toml`, or any other dependency manifest:
-   - You MUST verify the real version exists by querying the package registry first:
-     - npm/Node.js: `npm view <package> dist-tags.latest 2>$null`
-     - Python/pip: `pip index versions <package> 2>$null | Select-Object -First 1`
-     - Go: `go list -m -versions <module>@latest 2>$null`
-     - Rust: `cargo search <crate> --limit 1 2>$null`
-   - **NEVER guess or hallucinate version numbers**. If you cannot verify a version, use `"latest"` or `"*"` as a placeholder, or omit the version constraint entirely and let the package manager resolve it
-   - If the registry query fails (network issue, package not found), you MUST either:
-     (a) Use a known-safe version you have high confidence in, OR
-     (b) Skip that dependency and document it as a manual step, OR
-     (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-windows/templates/sections/critical-paths-agent.md

@@ -1,10 +0,0 @@
-## Critical Paths
-
-| Resource | Path |
-|----------|------|
-| Feature Artifacts Dir | `.prizmkit/specs/{{FEATURE_SLUG}}/` |
-| Context Snapshot | `.prizmkit/specs/{{FEATURE_SLUG}}/context-snapshot.md` |
-| Dev Agent Def | {{DEV_SUBAGENT_PATH}} |
-| Reviewer Agent Def | {{REVIEWER_SUBAGENT_PATH}} |
-| Critic Agent Def (if enabled) | {{CRITIC_SUBAGENT_PATH}} |
-| Project Root | {{PROJECT_ROOT}} |

package/bundled/dev-pipeline-windows/templates/sections/critical-paths-full.md

@@ -1,12 +0,0 @@
-## Critical Paths
-
-| Resource | Path |
-|----------|------|
-| Feature Artifacts Dir | `.prizmkit/specs/{{FEATURE_SLUG}}/` |
-| Context Snapshot | `.prizmkit/specs/{{FEATURE_SLUG}}/context-snapshot.md` |
-| Team Config | `{{TEAM_CONFIG_PATH}}` |
-| Dev Agent Def | {{DEV_SUBAGENT_PATH}} |
-| Reviewer Agent Def | {{REVIEWER_SUBAGENT_PATH}} |
-| Critic Agent Def | {{CRITIC_SUBAGENT_PATH}} |
-| Project Root | {{PROJECT_ROOT}} |
-| Feature List Path | {{FEATURE_LIST_PATH}} |

package/bundled/dev-pipeline-windows/templates/sections/critical-paths-lite.md

@@ -1,7 +0,0 @@
-## Critical Paths
-
-| Resource | Path |
-|----------|------|
-| Feature Artifacts Dir | `.prizmkit/specs/{{FEATURE_SLUG}}/` |
-| Context Snapshot | `.prizmkit/specs/{{FEATURE_SLUG}}/context-snapshot.md` |
-| Project Root | {{PROJECT_ROOT}} |

package/bundled/dev-pipeline-windows/templates/sections/directory-convention-agent.md

@@ -1,8 +0,0 @@
-## PrizmKit Directory Convention
-
-```
-.prizmkit/specs/{{FEATURE_SLUG}}/context-snapshot.md  ← orchestrator writes Sections 1-4; Dev appends Implementation Log; Reviewer appends Review Notes
-.prizmkit/specs/{{FEATURE_SLUG}}/plan.md              ← includes Tasks section
-```
-
-**`context-snapshot.md`** is the shared knowledge base. Orchestrator writes Sections 1-4; Dev appends Implementation Log; Reviewer appends Review Notes. Append-only after initial creation.

package/bundled/dev-pipeline-windows/templates/sections/directory-convention-full.md

@@ -1,9 +0,0 @@
-## PrizmKit Directory Convention
-
-```
-.prizmkit/specs/{{FEATURE_SLUG}}/context-snapshot.md  ← orchestrator writes Sections 1-4; Dev appends Implementation Log; Reviewer appends Review Notes
-.prizmkit/specs/{{FEATURE_SLUG}}/spec.md
-.prizmkit/specs/{{FEATURE_SLUG}}/plan.md              ← includes Tasks section
-```
-
-**`context-snapshot.md`** is the shared knowledge base. Orchestrator writes Sections 1-4; Dev appends Implementation Log; Reviewer appends Review Notes. This eliminates redundant I/O across all agents.

package/bundled/dev-pipeline-windows/templates/sections/directory-convention-lite.md

@@ -1,6 +0,0 @@
-## PrizmKit Directory Convention
-
-```
-.prizmkit/specs/{{FEATURE_SLUG}}/context-snapshot.md
-.prizmkit/specs/{{FEATURE_SLUG}}/plan.md              ← includes Tasks section
-```

package/bundled/dev-pipeline-windows/templates/sections/failure-capture.md

@@ -1,21 +0,0 @@
-## Failure Capture Protocol
-
-If you encounter an unrecoverable error, context overflow, or are about to exit without completing all phases:
-
-1. Write `.prizmkit/specs/{{FEATURE_SLUG}}/failure-log.md` BEFORE exiting:
-   ```
-   FAILURE_TYPE: timeout | test_failure | review_rejected | context_overflow | unknown
-   PHASE: <Get-Command phase failed>
-   ROOT_CAUSE: <1-2 sentence explanation>
-   ATTEMPTED: <approaches already tried>
-   SUGGESTION: <what the next session should try differently>
-   DISCOVERED_TRAPS:
-   - [CRITICAL|HIGH|LOW] <gotcha discovered during this failed session> | FIX: <approach>
-   ```
-
-2. This file is intentionally lightweight — write it BEFORE context runs out.
-
-**Lifecycle**: failure-log.md is a temporary cross-session artifact. Do NOT commit it to git. After a successful session (all phases complete + commit done), delete it:
-```powershell
-Remove-Item -Force -ErrorAction SilentlyContinue .prizmkit/specs/{{FEATURE_SLUG}}/failure-log.md
-```

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

@@ -1,21 +0,0 @@
-<feature-context>
-## Source Semantics
-
-Use this material according to the following priority:
-
-1. **Task Contract** — defines current scope and Verification Gates.
-2. **Completed Dependencies** — existing interfaces; do not re-implement.
-3. **App Global Context** — stack, runtime, testing conventions.
-
-### Completed Dependencies
-
-{{COMPLETED_DEPENDENCIES}}
-
-### App Global Context
-
-{{GLOBAL_CONTEXT}}
-
-### Project Conventions
-
-> Read {{PLATFORM_CONVENTIONS}} for project-level coding standards and architecture decisions.
-</feature-context>

package/bundled/dev-pipeline-windows/templates/sections/log-size-awareness.md

@@ -1,41 +0,0 @@
-## Session Log Budget Awareness (CHECKPOINT GUIDANCE)
-
-Your session log grows with every tool call and agent interaction. Use this
-section as passive checkpoint guidance only; do not spawn a background helper for
-log-size checks.
-
-### Checkpoint Before Large Work Batches
-
-- `MAX_LOG_SIZE` controls whether this advisory section is included. It is not a
-  runtime recovery mechanism.
-- Before major phases or large task batches, update durable artifacts that a
-  continuation session can trust: plan/task checkboxes, context snapshots,
-  implementation or review notes, workflow checkpoints, session status, and test
-  reports where applicable.
-- Keep command output small. Capture large outputs to temporary files and read
-  only filtered summaries needed for the current decision.
-- Prefer already-built context snapshots and manifests over broad source-file
-  re-reads.
-
-### Headless Recovery Source of Truth
-
-- Headless recovery must rely on durable checkpoints and artifacts, not an
-  interactive slash command.
-- If context overflow still occurs, the runner detects the overflow and starts a
-  fresh continuation session from checkpoint files and durable artifacts.
-- Durable checkpoint files and artifacts are the source of truth for what was
-  completed, what remains, and the tests or review gates already run.
-
-### Interactive Claude Code Note
-
-- `/compact` may help when a human is manually operating an interactive Claude
-  Code session.
-- `/compact` is optional interactive convenience only. It must not be required
-  for headless recovery and must not be delegated to a background helper.
-
-### Log Growth Reduction Tips
-
-- Reuse context-snapshot.md instead of re-reading files already summarized there.
-- Filter command output before loading it into context.
-- Keep agent prompts focused and avoid unnecessary transcript expansion.
-- Checkpoint often so automatic continuation can resume from durable state.