prizmkit 1.1.100 → 1.1.102

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

@@ -1,40 +1,53 @@
-### Implement — Dev Subagent
+### Implement — Orchestrator Direct (no 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.
+**Rationale**: Development is deterministic plan execution — the orchestrator already built full context in Phase 1. Spawning a Dev subagent forces it to rebuild context (re-reading files the orchestrator already read), wastes context, and risks worktree double-edit. The orchestrator implements directly.
 
-**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.
+Before starting, check plan.md Tasks:
+```bash
+grep -c '^\- \[ \]' .prizmkit/specs/{{FEATURE_SLUG}}/plan.md 2>/dev/null || true
+```
+- If result is `0` (all tasks already `[x]`) → **SKIP to Review**.
+- If non-zero → implement directly below.
 
-**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.
+**Build artifacts rule**: After any build/compile command, ensure output is in `.gitignore`. Never commit binaries/build output.
 
-**Gate Check — Implementation Log**:
-After Dev agent returns, verify the Implementation Log was written:
+**3a.** Detect test commands and record baseline:
 ```bash
-grep -q "## Implementation Log" .prizmkit/specs/{{FEATURE_SLUG}}/context-snapshot.md && echo "GATE:PASS" || echo "GATE:MISSING"
+($TEST_CMD) 2>&1 | tee /tmp/test-baseline.txt | tail -20
 ```
-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."
 
+**3b.** Run `/prizmkit-implement` directly — you (the orchestrator) execute the full cycle:
+- Read plan.md Tasks from `.prizmkit/specs/{{FEATURE_SLUG}}/`
+- Use context-snapshot.md Section 4 File Manifest for targeted reads — do NOT re-read files already summarized there
+- Implements task-by-task, marking each `[x]` immediately
+- Creates/updates L2 `.prizm` docs when creating new modules
+- Defers scoped/full test execution until after the code-review loop completes
+- If plan.md has >5 tasks: update checkpoints after every 3 tasks
+
+**3c. Focused checks only (no test gate here)**:
+- During implementation, do not run mandatory periodic or full-suite tests.
+- If a tiny targeted check is needed to understand a local failure, run only the smallest relevant command and capture output to `/tmp/test-out.txt`.
+- The scoped feature test gate runs after code review; do not declare implementation success based on an early full-suite run.
+
+**3d. Verification Gate Self-Check (BLOCKING — before declaring implement done)**:
+For each Verification Gate from the Task Contract, write one evidence line to Implementation Log:
+```
+### Gate Evidence
+- [x] G1: <gate text> — Evidence: <test name / file:line / fixture path>
+- [ ] G3: <gate text> — BLOCKED: <reason>  ← no evidence = BLOCKED, not success
+```
+
+**3e.** Append `## Implementation Log` (with Gate Evidence) to `context-snapshot.md`:
+- files changed/created
+- key decisions
+- deviations from plan
+- test results
+- Gate Evidence section
+- unresolved blockers
+
+**CP-2**: All tasks `[x]`, Implementation Log written with Gate Evidence, and blocked gates documented in `failure-log.md`. Test execution is deferred until after code review.
 
-**Checkpoint update**: Run the update script to set step `prizmkit-implement` to `"completed"`:
+**Checkpoint update**:
 ```bash
 python3 $PIPELINE_DIR/scripts/update-checkpoint.py \
   --checkpoint-path {{CHECKPOINT_PATH}} \

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

@@ -1,52 +1,54 @@
-### Implement — Dev Agent
+### Implement — Orchestrator Direct (no 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.
+**Rationale**: Development is deterministic plan execution — the orchestrator already built full context in Phase 1-2. Spawning a Dev subagent forces it to rebuild context (re-reading files the orchestrator already read), wastes context, and risks worktree double-edit. The orchestrator implements directly.
 
-Before spawning Dev, check plan.md Tasks section:
+Before starting, check plan.md Tasks:
 ```bash
 grep -c '^\- \[ \]' .prizmkit/specs/{{FEATURE_SLUG}}/plan.md 2>/dev/null || true
 ```
-- 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:
+- If result is `0` (all tasks already `[x]`) → **SKIP to Review**.
+- If non-zero → implement directly below.
+
+**Build artifacts rule**: After any build/compile command, ensure output is in `.gitignore`. Never commit binaries/build output.
+
+**3a.** Detect test commands and record baseline:
 ```bash
-grep -q "## Implementation Log" .prizmkit/specs/{{FEATURE_SLUG}}/context-snapshot.md && echo "GATE:PASS" || echo "GATE:MISSING"
+($TEST_CMD) 2>&1 | tee /tmp/test-baseline.txt | tail -20
+```
+Save pre-existing failing tests as `BASELINE_FAILURES`.
+
+**3b.** Run `/prizmkit-implement` directly — you (the orchestrator) execute the full cycle:
+- Read plan.md Tasks from `.prizmkit/specs/{{FEATURE_SLUG}}/`
+- Use context-snapshot.md Section 4 File Manifest for targeted reads — do NOT re-read files already summarized there
+- Implements task-by-task, marking each `[x]` immediately
+- Creates/updates L2 `.prizm` docs when creating new modules
+- Defers scoped/full test execution until after the code-review loop completes
+- If plan.md has >5 tasks: update checkpoints after every 3 tasks
+
+**3c. Focused checks only (no test gate here)**:
+- During implementation, do not run mandatory periodic or full-suite tests.
+- If a tiny targeted check is needed to understand a local failure, run only the smallest relevant command and capture output to `/tmp/test-out.txt`.
+- The scoped feature test gate runs after code review; do not declare implementation success based on an early full-suite run.
+
+**3d. Verification Gate Self-Check (BLOCKING — before declaring implement done)**:
+For each Verification Gate from the Task Contract, write one evidence line to Implementation Log:
+```
+### Gate Evidence
+- [x] G1: <gate text> — Evidence: <test name / file:line / fixture path>
+- [ ] G3: <gate text> — BLOCKED: <reason>  ← no evidence = BLOCKED, not success
 ```
-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: `grep -c '^\- \[ \]' .prizmkit/specs/{{FEATURE_SLUG}}/plan.md`
-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.
+**3e.** Append `## Implementation Log` (with Gate Evidence) to `context-snapshot.md`:
+- files changed/created
+- key decisions
+- deviations from plan
+- test results
+- Gate Evidence section
+- unresolved blockers
 
+**CP-2**: All tasks `[x]`, Implementation Log written with Gate Evidence, and blocked gates documented in `failure-log.md`. Test execution is deferred until after code review.
 
-**Checkpoint update**: Run the update script to set step `prizmkit-implement` to `"completed"`:
+**Checkpoint update**:
 ```bash
 python3 $PIPELINE_DIR/scripts/update-checkpoint.py \
   --checkpoint-path {{CHECKPOINT_PATH}} \

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

@@ -1,33 +1,24 @@
-### Implement + Test
+### Implement
 
 **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:
-```bash
-# Run each test command, capture output
-($TEST_CMD) 2>&1 | tee /tmp/test-baseline.txt | tail -20
-```
-
-**3b.** Run `/prizmkit-implement` — this handles the full implementation cycle:
+**3a.** Run `/prizmkit-implement` — this handles the 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
+- Implements task-by-task, marking each `[x]` immediately
 - Creates/updates L2 `.prizm` docs when creating new modules or significantly modifying existing ones — AI selectively decides which modules warrant L2 based on complexity and importance
-- Runs tests using `TEST_CMD` after each task
+- Does not run the scoped/full test gate; testing happens after code review in the PrizmKit Test phase
 - Writes '## Implementation Log' to `context-snapshot.md`
 
-**3c.** After implement completes, verify:
+**3b.** 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
+2. Verify each Verification Gate from the Task Contract using code/file evidence already in context — do NOT re-read files you already wrote
+3. If any gate is unmet or blocked, write `failure-log.md` and stop for recovery
 
-**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.
+**CP-2**: Implementation may proceed only when all tasks are `[x]` and blocked gates are documented in `failure-log.md`. Test execution is deferred until after code review.
 
 
 **Checkpoint update**: Run the update script to set step `prizmkit-implement` to `"completed"`:

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

@@ -1,6 +1,6 @@
 ### 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.
+**Goal**: After code review completes, generate and verify tests for this feature's changed scope 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:
 
@@ -34,6 +34,6 @@ python3 "$PIPELINE_DIR/scripts/prizmkit-test-gate.py" check \
 
 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 `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 retrospective/commit 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/templates/sections/phase-review-agent.md

@@ -1,8 +1,6 @@
 ### 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.
+Review the completed implementation before the scoped feature test gate runs. Use `artifact_dir=.prizmkit/specs/{{FEATURE_SLUG}}/` so the code-review skill can read spec, plan, context snapshot, implementation log, and current diff artifacts. Do not require or read a prior `/prizmkit-test` report here; test generation and test-fix looping happen in the next phase.
 
 Run `/prizmkit-code-review` with `artifact_dir=.prizmkit/specs/{{FEATURE_SLUG}}/`.
 

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

@@ -1,8 +1,6 @@
 ### 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.
+Review the completed implementation before the scoped feature test gate runs. Use `artifact_dir=.prizmkit/specs/{{FEATURE_SLUG}}/` so the code-review skill can read spec, plan, context snapshot, implementation log, and current diff artifacts. Do not require or read a prior `/prizmkit-test` report here; test generation and test-fix looping happen in the next phase.
 
 Run `/prizmkit-code-review` with `artifact_dir=.prizmkit/specs/{{FEATURE_SLUG}}/`.
 

package/bundled/dev-pipeline/templates/sections/phase0-test-baseline.md

@@ -1,15 +1,10 @@
-### Phase 0: Record Test Baseline & Detect Test Commands
+### Phase 0: Detect Test Commands
 
 **Step 1 — Detect test commands**: 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`.
 
-**Step 2 — Record pre-existing failure baseline**:
-```bash
-# Run each test command, capture output
-($TEST_CMD) 2>&1 | tee /tmp/test-baseline.txt | tail -20
-```
-Save the list of **pre-existing failing tests** (if any) as `BASELINE_FAILURES`. These are known failures that existed before this session — Dev must NOT be blamed for them, but must list them in COMPLETION_SIGNAL.
+**Step 2 — Do not run tests yet**: This phase only records the commands that will be used by the post-review PrizmKit Test gate. Do not run baseline, periodic, or full-suite tests here; test execution happens after code review.
 
-> **Test Output Rule**: Always capture test output to a temp file (`tee /tmp/test-out.txt`). Then grep the file instead of re-running the suite.
+> **Test Output Rule**: When the post-review gate runs, capture test output to a temp file (`tee /tmp/test-out.txt`). Then grep the file instead of re-running the suite.
 
 
 **Checkpoint update**: Run the update script to set step `test-baseline` to `"completed"`:

package/bundled/dev-pipeline/templates/sections/test-failure-recovery-agent.md

@@ -1,6 +1,6 @@
 ## Test Failure Recovery Protocol
 
-Use this protocol whenever implementation or review tests fail. Its purpose is to distinguish tolerated pre-existing failures from blockers introduced by this session.
+Use this protocol whenever the post-review PrizmKit Test gate fails. Its purpose is to distinguish tolerated pre-existing failures from blockers introduced by this session.
 
 ### Failure Classes
 
@@ -19,9 +19,13 @@ Use this protocol whenever implementation or review tests fail. Its purpose is t
 4. Stop after a plateau: same failure count and same failing tests for 3 consecutive rounds.
 5. If failures decrease, reset the plateau counter.
 
+### Hard Round Cap (BLOCKING)
+
+After **6 total test-fix rounds**, STOP trial-and-error. Write failure-log listing all hypotheses tried. Switch to: read full relevant source section ONCE (via `grep -n`+`sed -n`, never full Read), understand control flow, rewrite failing block in one shot. Do NOT exceed 7 total rounds.
+
 ### Success Rule
 
-Proceed to review only when:
+Proceed to retrospective/commit only when:
 
 1. all new regressions are fixed;
 2. baseline failures are documented;

package/bundled/dev-pipeline/templates/sections/test-failure-recovery-lite.md

@@ -1,6 +1,6 @@
 ## Test Failure Recovery Protocol
 
-Use this protocol whenever implementation tests fail. Its purpose is to distinguish tolerated pre-existing failures from blockers introduced by this session.
+Use this protocol whenever the post-review PrizmKit Test gate fails. Its purpose is to distinguish tolerated pre-existing failures from blockers introduced by this session.
 
 ### Failure Classes
 
@@ -19,6 +19,10 @@ Use this protocol whenever implementation tests fail. Its purpose is to distingu
 4. Stop after a plateau: same failure count and same failing tests for 3 consecutive rounds.
 5. If failures decrease, reset the plateau counter.
 
+### Hard Round Cap (BLOCKING)
+
+After **6 total test-fix rounds**, STOP trial-and-error. Write failure-log listing all hypotheses tried. Switch to: read full relevant source section ONCE (via `grep -n`+`sed -n`, never full Read), understand control flow, rewrite failing block in one shot. Do NOT exceed 7 total rounds.
+
 ### Success Rule
 
 Proceed only when: