prizmkit 1.1.114 → 1.1.116

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

@@ -1,22 +0,0 @@
-### Plan Challenge — Critic Agent
-
-**Guard**: Verify critic agent file exists before spawning:
-
-```bash
-{{RUNTIME_HELPER_CMD}} artifact exists {{CRITIC_SUBAGENT_PATH}} --exists-marker CRITIC:READY --missing-marker CRITIC:MISSING
-```
-
-If `CRITIC:MISSING`, mark `critic-plan-review` as `skipped` and continue.
-
-**Focus**: Challenge the bug diagnosis and fix plan before implementation:
-- Is the root cause actually supported by the evidence?
-- Does the reproduction test prove the bug before the fix?
-- Is the fix minimal, or does it mask the symptom?
-- Are adjacent regressions likely?
-- Does manual/hybrid verification policy match `{{VERIFICATION_TYPE}}`?
-
-Spawn `prizm-dev-team-critic` with default/no worktree isolation. Do not request AI tool-created worktree isolation.
-
-The Critic writes `.prizmkit/bugfix/{{BUG_ID}}/challenge-report.md`. Resolve CRITICAL/HIGH findings before implementation, or document why the plan stands.
-
-**Checkpoint update**: Set step `critic-plan-review` to `completed` after challenges are resolved, or `skipped` when critic is unavailable.

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

@@ -1,61 +0,0 @@
-### Plan Challenge — Critic Agent(s)
-
-**Guard**: Verify critic agent file exists before spawning:
-```bash
-{{RUNTIME_HELPER_CMD}} artifact exists {{CRITIC_SUBAGENT_PATH}} --exists-marker CRITIC:READY --missing-marker 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 |
-| isolation | default/no worktree; do not request worktree isolation |
-
-No-worktree boundary: this prevents AI tool-created `.claude/worktrees/...` subagent worktrees. It does not disable PrizmKit pipeline-managed linked git worktrees under `.prizmkit/state/worktrees/...`, which are controlled separately by `USE_WORKTREE`.
-
-**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, and default/no worktree isolation; do not request worktree isolation.
-
-No-worktree boundary: default/no worktree isolation prevents AI tool-created `.claude/worktrees/...` subagent worktrees. It does not disable PrizmKit pipeline-managed linked git worktrees under `.prizmkit/state/worktrees/...`, which are controlled separately by `USE_WORKTREE`.
-
-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.
-
-

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

@@ -1,38 +0,0 @@
-### Plan Challenge — Critic Agent
-
-**Guard**: Verify critic agent file exists before spawning:
-```bash
-{{RUNTIME_HELPER_CMD}} artifact exists {{CRITIC_SUBAGENT_PATH}} --exists-marker CRITIC:READY --missing-marker 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 |
-| isolation | default/no worktree; do not request worktree isolation |
-
-No-worktree boundary: this prevents AI tool-created `.claude/worktrees/...` subagent worktrees. It does not disable PrizmKit pipeline-managed linked git worktrees under `.prizmkit/state/worktrees/...`, which are controlled separately by `USE_WORKTREE`.
-
-**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.
-
-

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

@@ -1,22 +0,0 @@
-### Plan Challenge — Critic Agent
-
-**Guard**: Verify critic agent file exists before spawning:
-
-```bash
-{{RUNTIME_HELPER_CMD}} artifact exists {{CRITIC_SUBAGENT_PATH}} --exists-marker CRITIC:READY --missing-marker CRITIC:MISSING
-```
-
-If `CRITIC:MISSING`, mark `critic-plan-review` as `skipped` and continue.
-
-**Focus**: Challenge behavior preservation and plan safety before implementation:
-- Is observable behavior clearly defined and protected?
-- Do existing/new tests cover the behavior affected by this refactor?
-- Is the plan too broad for the stated scope?
-- Are file moves/renames safe for imports, public APIs, and integrations?
-- Is rollback realistic?
-
-Spawn `prizm-dev-team-critic` with default/no worktree isolation. Do not request AI tool-created worktree isolation.
-
-The Critic writes `.prizmkit/refactor/{{REFACTOR_ID}}/challenge-report.md`. Resolve CRITICAL/HIGH findings before implementation, or document why the plan stands.
-
-**Checkpoint update**: Set step `critic-plan-review` to `completed` after challenges are resolved, or `skipped` when critic is unavailable.

package/bundled/skills/bug-planner/references/critic-and-verification.md

@@ -1,44 +0,0 @@
-# Adversarial Critic Review & Browser Verification
-
-## Adversarial Critic Review (Testing Defaults)
-
-All bug fixes support optional critic review for additional quality assurance. The planner enables critic review by default for critical/high severity bugs and leaves it disabled for medium/low bugs; users can override per bug.
-
-### Default Critic Behavior
-
-| Severity | `critic` | `critic_count` | Rationale |
-|----------|----------|----------------|-----------|
-| critical | `true` | `1` | Single critic review for critical bugs |
-| high | `true` | `1` | Single critic review for high-severity bugs |
-| medium | `false` | (omitted) | Skip critic for medium-severity bugs |
-| low | `false` | (omitted) | Skip critic for low-severity bugs |
-
-- `critic: true` — Enable adversarial review after fix implementation
-- `critic_count: 1` — Single critic agent reviews the fix
-- Critic verifies: fix addresses root cause, no regressions introduced, acceptance criteria met
-
-**User Override**: During Phase 2 or Phase 3, users can opt to enable/disable critic on a per-bug basis.
-
-## Browser Verification
-
-Bug fixes can use `browser_interaction` when the bug is reproducible through a UI. The `verification_type` field still declares the overall verification mode:
-
-- `verification_type: automated` — Use unit/integration tests to verify the fix
-- `verification_type: manual` — Describe manual testing steps in acceptance criteria (including any browser verification steps)
-- `verification_type: hybrid` — Combine automated tests with manual browser verification steps
-
-For UI-related bugs, add `browser_interaction.verify_steps` when concrete browser goals are known. Also keep acceptance criteria measurable so the bugfix session can verify the fix without asking the user.
-
-### Example
-
-```
-Bug Title: Login error message not displaying
-Verification Type: manual
-Acceptance Criteria:
-  1. Navigate to /login with invalid credentials
-  2. Verify error message "Invalid email or password" appears below the email field
-  3. Verify error message is red (#FF0000)
-  4. Verify form fields are still enabled and can be re-submitted
-```
-
-The bugfix pipeline AI will use these criteria during manual verification.