wiggum-cli 0.17.2 → 0.17.3

package/dist/templates/prompts/PROMPT_e2e.md.tmpl

@@ -28,8 +28,14 @@ Check the bridge is running:
 ```bash
 curl -s http://localhost:3999/health || (cd {{projectRoot}} && npm run e2e:bridge &)
 sleep 3
+curl -s http://localhost:3999/health
 ```
 
+If bridge health still fails (for example `listen EPERM` / socket permission errors), do not keep retrying commands in this run:
+- Mark each unchecked `- [ ] E2E:` scenario as `- [ ] E2E: ... - FAILED: bridge unavailable in sandbox`
+- Add the concrete error text under each failed scenario
+- Continue to Step 4 and record a clear blocked summary
+
 ### Step 2: Parse E2E Test Scenarios
 Read E2E test scenarios from @.ralph/specs/$FEATURE-implementation-plan.md.
 Each scenario is marked with `- [ ] E2E:` prefix and follows this format:
@@ -88,32 +94,27 @@ CONTENT=$(agent-browser eval "document.getElementById('terminal-mirror').textCon
 # Verify CONTENT contains expected strings
 ```
 
-6. **Reset between scenarios:**
+6. **Reset between scenarios (without ending the browser session):**
 ```bash
-agent-browser close
+# Re-open the next scenario URL directly in the same session.
+agent-browser open "http://localhost:3999?cmd=<next-command>&cwd=<next-path>"
 ```
 
 ### TUI Interaction Cheatsheet
 
 | Action | Command |
 |--------|---------|
-| Open TUI | `agent-browser open "http://localhost:3999?cmd=init&cwd=/path"` |
+| Open TUI | `agent-browser open "http://localhost:3999?cmd=<cmd>&cwd=<path>"` |
 | Read screen | `agent-browser eval "document.getElementById('terminal-mirror').textContent"` |
-| Take snapshot | `agent-browser snapshot -i` |
-| Click element | `agent-browser click @ref` |
-| Type text | `agent-browser type @ref "text"` |
-| Press Enter | `agent-browser key Enter` |
-| Arrow down | `agent-browser key ArrowDown` |
-| Escape | `agent-browser key Escape` |
-| Screenshot | `agent-browser screenshot e2e-failure.png` |
-| Wait for text | `agent-browser wait --text "expected" --timeout 10000` |
+| Type/key press | `agent-browser type @ref "text"` / `agent-browser key Enter` |
 | Close session | `agent-browser close` |
 
 ### Key Rules
 - Always wait for expected text before asserting (TUI renders async via React)
 - Use `agent-browser eval` with `terminal-mirror` for reliable text reading
 - Take screenshots on failures for debugging
-- Each scenario navigates to a fresh URL (clean state)
+- Keep one browser session across all scenarios; do not call `agent-browser close` until all scenarios are done
+- Each scenario should navigate to a fresh URL (clean state)
 - Wait 500ms after key presses before reading (Ink re-render delay)
 
 ### Step 4: Report Results
@@ -158,14 +159,10 @@ When all scenarios are executed:
    ```
 5. If all passed: signal ready for PR phase
 6. If any failed: failures documented, loop will retry after fix iteration
+7. Close browser once at the end: `agent-browser close`
 
 ## Learning Capture
-If E2E testing revealed issues worth remembering, append to @.ralph/LEARNINGS.md:
-- Flaky test patterns -> Add under "## Anti-Patterns" > "E2E Pitfalls"
-- TUI timing issues -> Add under "## Anti-Patterns"
-- Useful agent-browser techniques -> Add under "## Tool Usage"
-
-Format: `- [YYYY-MM-DD] [$FEATURE] Brief description`
+If useful E2E patterns found, append to @.ralph/LEARNINGS.md
 {{else}}
 ## Task
 Execute automated E2E tests for the completed feature using Playwright MCP tools.
@@ -282,56 +279,6 @@ Update @.ralph/specs/$FEATURE-implementation-plan.md for each scenario:
   - Fix needed: [suggested action]
 ```
 
-## Playwright MCP Tool Reference
-
-| Tool | Purpose | Key Parameters |
-|------|---------|----------------|
-| `browser_navigate` | Go to URL | `url` |
-| `browser_snapshot` | Get page state (use for assertions) | - |
-| `browser_click` | Click element | `element`, `ref` |
-| `browser_type` | Type into element | `element`, `ref`, `text`, `submit` |
-| `browser_fill_form` | Fill multiple fields | `fields[]` with name, type, ref, value |
-| `browser_select_option` | Select dropdown | `element`, `ref`, `values[]` |
-| `browser_wait_for` | Wait for text/time | `text`, `textGone`, `time` |
-| `browser_take_screenshot` | Capture visual state | `filename` (optional) |
-| `browser_console_messages` | Get JS console output | `level` (error/warning/info) |
-| `browser_press_key` | Press keyboard key | `key` (e.g., "Enter", "Tab") |
-| `browser_close` | Close browser/reset state | - |
-
-## Assertion Patterns
-
-### Text Verification
-```
-1. browser_snapshot -> get page content
-2. Check snapshot output for expected text strings
-3. If text not found, scenario fails
-```
-
-### Element State
-```
-1. browser_snapshot -> accessibility tree shows element states
-2. Check for: enabled/disabled, checked/unchecked, visible
-```
-
-### URL Verification
-```
-1. After navigation/action, snapshot shows current URL
-2. Verify URL contains expected path/params
-```
-
-{{#if hasSupabase}}### Database State
-```
-1. mcp__plugin_supabase_supabase__execute_sql with SELECT query
-2. Verify row count, column values match expectations
-```
-{{/if}}
-
-## Browser State Management
-
-- Use `browser_close` between unrelated scenarios to reset localStorage/cookies
-- Keep browser open for scenarios that test state persistence (e.g., duplicate submission)
-- Fresh browser state = clean localStorage, no prior submissions tracked
-
 ## Error Recovery
 
 If a scenario fails:
@@ -358,21 +305,6 @@ When all scenarios are executed:
 5. If all passed: signal ready for PR phase
 6. If any failed: failures documented, loop will retry after fix iteration
 
-## Troubleshooting
-
-### UI Changes Not Visible
-If code changes don't appear in the browser:
-1. Stop the dev server
-2. Clear cache: `rm -rf {{appDir}}/.next`
-3. Restart: `cd {{appDir}} && {{devCommand}}`
-4. Wait for full rebuild before testing
-
-### Stale Data
-- Clear browser storage: Use `browser_close` between scenarios
-{{#if hasSupabase}}- Check Supabase for stale test data from previous runs
-- Delete test data: `DELETE FROM table WHERE data->>'_test' = 'true'`
-{{/if}}
-
 ## Rules
 - Always get a fresh `browser_snapshot` after actions before making assertions
 - Use `browser_wait_for` when waiting for async operations (form submission, API calls)
@@ -382,10 +314,5 @@ If code changes don't appear in the browser:
 - Document failures clearly so fix iteration knows what to address
 
 ## Learning Capture
-If E2E testing revealed issues worth remembering, append to @.ralph/LEARNINGS.md:
-- Flaky test patterns -> Add under "## Anti-Patterns" > "E2E Pitfalls"
-- Useful Playwright techniques -> Add under "## Tool Usage"
-- Timing issues or race conditions -> Add under "## Anti-Patterns"
-
-Format: `- [YYYY-MM-DD] [$FEATURE] Brief description`
+If useful E2E patterns found, append to @.ralph/LEARNINGS.md
 {{/if}}

package/dist/templates/prompts/PROMPT_e2e_fix.md.tmpl

@@ -0,0 +1,55 @@
+## Context
+If @.ralph/guides/AGENTS.md exists, study it for commands and patterns.
+Study @.ralph/specs/$FEATURE-implementation-plan.md for E2E failure details.
+Study @.ralph/specs/$FEATURE.md for behavioral constraints and acceptance criteria.
+{{#if frameworkVariant}}For detailed architecture, see @{{appDir}}/.claude/CLAUDE.md{{/if}}
+
+## Learnings
+Read @.ralph/LEARNINGS.md — pay attention to the "E2E Pitfalls" section to avoid repeating known issues.
+
+## Task
+Fix all E2E test scenarios marked `- [ ] E2E: ... - FAILED` in @.ralph/specs/$FEATURE-implementation-plan.md.
+
+1. Read the implementation plan and identify every line matching `- [ ] E2E: ... - FAILED`.
+2. For each failure, read the `Error:` and `Fix needed:` fields to understand what went wrong.
+3. Cross-reference @.ralph/specs/$FEATURE.md to ensure fixes respect behavioral constraints.
+4. Apply the minimal code change needed to make the failing scenario pass.
+5. Do NOT touch passing scenarios or non-E2E implementation code unless required by the fix.
+
+{{#if isTui}}
+### TUI E2E Fix Notes
+- Fixes typically involve Ink component state, key handling, or terminal output formatting.
+- Verify fix with the agent-browser bridge: `curl -s http://localhost:3999/health` to confirm it is running.
+- After fixing, re-run the failed scenario manually via agent-browser to confirm it passes before updating the plan.
+- If bridge/agent-browser cannot start due sandbox socket restrictions (e.g. `listen EPERM`, daemon socket startup failure), treat scenarios as blocked infrastructure:
+  - Keep each affected scenario as `- [ ] E2E: ... - FAILED: bridge unavailable in sandbox`
+  - Record exact error output
+  - Do not loop on repeated identical retries in this run
+{{else}}
+### Web E2E Fix Notes
+- Fixes typically involve DOM structure, async timing, or data state issues.
+- Verify fix with the dev server running at http://localhost:3000.
+- After fixing, re-run the failed scenario via Playwright MCP to confirm it passes before updating the plan.
+{{/if}}
+
+## Validation
+After applying fixes, run ONLY the E2E validation command:
+```bash
+cd {{appDir}} && {{testCommand}}
+```
+
+Unit tests and build are already passing — do not re-run lint, typecheck, or build unless the fix touches non-E2E source files.
+
+## Completion
+When fixes are applied and validation passes:
+1. Update @.ralph/specs/$FEATURE-implementation-plan.md — for each fixed scenario, change `- [ ] E2E: ... - FAILED` to `- [x] E2E: ... - PASSED`.
+2. `git -C {{appDir}} add -A`
+3. `git -C {{appDir}} commit -m "fix($FEATURE): resolve failing E2E scenarios"`
+4. `git -C {{appDir}} push origin feat/$FEATURE`
+
+## Learning Capture
+If this fix iteration revealed E2E-specific patterns worth remembering, append to @.ralph/LEARNINGS.md:
+- Flaky test patterns or timing issues -> Add under "## Anti-Patterns (What to Avoid)" > "E2E Pitfalls"
+- Useful debugging techniques -> Add under "## Tool Usage"
+
+Format: `- [YYYY-MM-DD] [$FEATURE] Brief description`

package/dist/templates/prompts/PROMPT_feature.md.tmpl

@@ -14,106 +14,20 @@ Study @.ralph/specs/$FEATURE.md for feature specification.
 3. Create @.ralph/specs/$FEATURE-implementation-plan.md with tasks
 
 ## Implementation Plan Format
-```markdown
-# $FEATURE Implementation Plan
-
-**Spec:** .ralph/specs/$FEATURE.md
-**Branch:** feat/$FEATURE
-**Status:** Planning | In Progress | PR Review | Completed
-
-## Tasks
-
-### Phase 1: Setup
-- [ ] Task 1 - [complexity: S/M/L]
-- [ ] Task 2
-
-### Phase 2: Core Implementation
-- [ ] Task 3
-- [ ] Task 4
-
-### Phase 3: Tests (Unit/Integration)
-- [ ] Write tests for [component]
-- [ ] Write tests for [feature]
-
-### Phase 4: Polish & Design
-- [ ] Run design checklist from @.ralph/guides/FRONTEND.md (if UI changes)
-- [ ] Verify responsive design (mobile/tablet/desktop)
-- [ ] Add loading/empty/error states
-- [ ] Verify hover/focus states on interactive elements
-{{#if styling}}- [ ] For charts: use ChartContainer pattern with tooltips + legends{{/if}}
-- [ ] Task N (additional polish)
-
-### Phase 5: E2E Testing
-{{#if isTui}}
-TUI E2E tests executed via xterm.js bridge + agent-browser.
-Fixture projects in `e2e/fixtures/`. Bridge at `http://localhost:3999`.
-
-- [ ] E2E: [Scenario name] - [brief description]
-  - **Command:** [wiggum command, e.g., init, new auth-flow]
-  - **CWD:** [working directory, e.g., e2e/fixtures/bare-project]
-  - **Steps:**
-    1. [Action] -> [expected terminal output]
-    2. [Action] -> [expected terminal output]
-  - **Verify:** [text that should appear in terminal]
-
-Example TUI E2E scenario:
-- [ ] E2E: Init in bare project - happy path
-  - **Command:** init
-  - **CWD:** e2e/fixtures/bare-project
-  - **Steps:**
-    1. Open bridge with init command -> Welcome screen renders
-    2. Arrow down to select option -> Option highlighted
-    3. Press Enter -> Next screen appears
-  - **Verify:** "initialized" text visible in terminal
-{{else}}
-Browser-based tests executed via Playwright MCP tools.
-
-- [ ] E2E: [Scenario name] - [brief description]
-  - **URL:** [starting URL, use {placeholders} for dynamic IDs]
-  - **Preconditions:** [setup requirements, e.g., "Survey must be published"]
-  - **Steps:**
-    1. [Action] -> [expected result]
-    2. [Action] -> [expected result]
-  - **Verify:** [final assertion text to check]
-  - **Database check:** [optional SQL query to verify data]
-
-Example E2E scenario:
-- [ ] E2E: Submit survey response - happy path
-  - **URL:** /survey/{surveyId}?utm_source=e2e_test
-  - **Preconditions:** Published survey with required questions
-  - **Steps:**
-    1. Navigate to survey URL -> Form displays with all questions
-    2. Fill required text field -> No validation error
-    3. Select rating 4 -> Button shows selected state
-    4. Click "Submit Survey" -> Loading state appears
-    5. Wait for "Thank You!" -> Success card displays
-  - **Verify:** "successfully submitted" text visible
-  - **Database check:** SELECT * FROM survey_responses WHERE survey_id = '{surveyId}'
-{{/if}}
-
-## Done
-- [x] Completed task - [commit hash]
-- [x] E2E: Scenario name - PASSED
-```
+Create `@.ralph/specs/$FEATURE-implementation-plan.md` with:
+- **Header:** feature name, spec path (`$FEATURE.md`), branch (`feat/$FEATURE`), status
+- **Phases:** Setup | Core Implementation | Tests (Unit/Integration) | Polish & Design | E2E Testing
+- **Tasks:** `- [ ] Task description [S/M/L]` — every task MUST use `- [ ]` checkbox syntax
+- **E2E tasks:** `- [ ] E2E: Scenario name` with required fields:
+{{#if isTui}}  - Command, CWD, Steps (action → expected terminal output), Verify text{{else}}  - URL, Preconditions, Steps (action → expected result), Verify text, optional Database check{{/if}}
+- **Done section:** `- [x] Completed task - [commit hash]`
 
 ## CRITICAL CONSTRAINT — PLANNING ONLY
-**You are in the PLANNING phase. Your ONLY job is to produce an implementation plan.**
-- Do NOT write any source code, test code, or configuration files
-- Do NOT create, modify, or touch any files outside `.ralph/specs/`
-- Do NOT run build, test, or lint commands
-- Do NOT make git commits
-- If you feel the urge to "just implement a small piece", STOP — that is a phase violation
-- The implementation phase runs AFTER this session ends, in a separate session
-- Violation of this constraint wastes tokens and breaks the harness automation
+Planning only. Do NOT write code, tests, configs, or run builds/commits.
+The implementation phase runs in a separate session after planning ends.
+Violation wastes tokens and breaks harness automation.
 
 ## Rules
-- You MUST use `- [ ]` checkbox syntax for every task in the plan
-- Do NOT use heading-based task formats (e.g., `#### Task 1:`) for individual tasks
-- The harness parses `- [ ]` lines to track progress — other formats will break automation
-- Use `### Phase N:` headings only for phase grouping, not for individual tasks
-- One task = one commit-sized unit of work (but tasks can be grouped into phases for batch implementation)
+- MUST use `- [ ]` checkbox syntax for every task — harness parses this for progress tracking
+- Use `### Phase N:` headings for phases; one task = one commit-sized unit of work
 - Every implementation task needs a corresponding test task
-- Use Supabase MCP to check existing schema
-- Use PostHog MCP to check existing analytics setup
-- For UI-heavy features (new pages, dashboards, analytics, marketing pages), reference @.ralph/guides/FRONTEND.md
-- Consider `/frontend-design` skill for features needing distinctive aesthetics

package/dist/templates/prompts/PROMPT_review_auto.md.tmpl

@@ -11,6 +11,34 @@ Capture any review feedback patterns for future iterations.
 All implementation and E2E tasks are complete. Create PR and request review.
 Complete ALL steps in a single pass — do not end the session between steps.
 
+### Step 0: Verify Spec Requirements
+Before creating the PR, verify the implementation meets the spec requirements and update spec files.
+
+1. Read @.ralph/specs/$FEATURE.md and for each requirement under "## Requirements":
+   - Check if it was implemented (review implementation plan tasks)
+   - Mark as `[x]` if complete, leave as `[ ]` if not implemented (add a note explaining why)
+
+2. For each item under "## Acceptance Criteria":
+   - Verify against implementation and test results
+   - Mark as `[x]` if verified, leave as `[ ]` with a note if not met
+
+3. Update spec status:
+   - Change `**Status:** Planned` (or `Draft`) to `**Status:** Completed` if all requirements met, or `**Status:** Partial` if some are missing
+   - Update `**Last Updated:**` to today's date
+
+4. Update @.ralph/specs/README.md Active Specs table:
+   - Update ONLY the row for $FEATURE (do NOT remove or modify other rows)
+   - Change status and update Last Updated date
+
+5. If any requirements were not fully met, add an "## Implementation Notes" section documenting gaps and reasons.
+
+6. Commit spec updates:
+   ```bash
+   git -C {{appDir}} add ../.ralph/specs/
+   git -C {{appDir}} commit -m "docs($FEATURE): verify spec requirements"
+   git -C {{appDir}} push origin feat/$FEATURE
+   ```
+
 ### Step 1: Verify Ready State
 1. Check all tasks are complete in implementation plan (no `- [ ]` items)
 2. Verify tests pass: `cd {{appDir}} && {{testCommand}}`
@@ -62,63 +90,37 @@ cd {{appDir}} && gh pr create --base main --head feat/$FEATURE \
 
 Closes #[Read the source issue number from the spec file metadata or context section]
 
-Generated with Claude Code
+Generated with Wiggum Loop
 EOF
 )"
 ```
 
-### Step 4: Request Claude Code Review
-
-Run automated code review using Claude Code CLI:
-
-```bash
-# Check if Claude Code CLI is installed
-if ! command -v claude &> /dev/null; then
-    echo "WARNING: Claude Code CLI not installed. Manual review needed."
-    cd {{appDir}} && gh pr comment --body "Manual review requested - Claude Code CLI not available. Install: https://docs.anthropic.com/en/docs/claude-code/overview"
-else
-    echo "Running Claude Code review..."
-
-    cd {{appDir}} && claude -p "You are reviewing a PR for the $FEATURE feature.
-
-Review the git diff against main and check:
-- Code quality and patterns consistency
-- Test coverage adequacy
-- Potential bugs or edge cases
-- Security concerns (injection, XSS, etc.)
-- Performance implications
-- Error handling completeness
-
-Run: git diff main
-
-Then:
-1. Post your complete review as a comment on the PR using:
-   gh pr comment --body '<your review in markdown>'
-   Format the comment with: a summary, specific issues with file:line refs (if any), and the verdict.
-2. Print your final verdict as the LAST line of stdout. Print exactly one of:
-   VERDICT: APPROVED
-   VERDICT: NOT APPROVED
-   This line is parsed by the automation — do not omit it."
-fi
-```
-
-After the review completes, check its output:
-- If it contains "VERDICT: APPROVED", echo that line so the automation detects it:
-  ```bash
-  echo "VERDICT: APPROVED"
-  ```
-- If issues were found, echo:
-  ```bash
-  echo "VERDICT: NOT APPROVED"
-  ```
+### Step 4: Run Automated Review
+
+Use the current review CLI session (`$REVIEW_CLI`) to perform a full review:
+
+1. Review `git diff main` for:
+   - Code quality and consistency
+   - Test coverage and missing tests
+   - Potential bugs and edge cases
+   - Security risks (injection, auth, data exposure)
+   - Performance and error handling
+2. Post review feedback to the PR with `gh pr comment --body ...`
+3. Print your final verdict as the **LAST** line of stdout, exactly one of:
+   - `VERDICT: APPROVED`
+   - `VERDICT: NOT APPROVED`
+4. Before printing `VERDICT: APPROVED`, wait for CI to complete and pass:
+   - Run `cd {{appDir}} && gh pr checks feat/$FEATURE --watch --interval 10`
+   - If checks are pending, keep waiting
+   - If any check fails, output `VERDICT: NOT APPROVED` and list failing checks
 
 **Handle review feedback:**
-- If Claude outputs "VERDICT: APPROVED" -> Done. The PR is ready for manual merge by the user.
-- If Claude lists issues:
+- If verdict is `VERDICT: APPROVED` -> Done. The PR is ready for manual merge by the user.
+- If verdict is `VERDICT: NOT APPROVED`:
   1. Address each issue with code fixes
   2. Commit: `git -C {{appDir}} add -A && git -C {{appDir}} commit -m "fix($FEATURE): address review feedback"`
   3. Push: `git -C {{appDir}} push origin feat/$FEATURE`
-  4. Re-run the Claude review command above
+  4. Re-run this review step
 - Max 3 review iterations before requiring manual intervention
 
 ### Step 5: Final Summary
@@ -133,6 +135,7 @@ no implementation found" so the harness can trigger a new implementation iterati
 
 ## Rules
 - **NEVER approve if any tests are failing.** Output "VERDICT: NOT APPROVED — test failures" if any tests fail.
+- **NEVER approve while CI checks are pending/failing.** Wait until checks complete and pass.
 - Do NOT merge the PR — auto mode only reviews, the user merges
 - Do NOT implement missing features — only review and fix minor issues
 - Address ALL review comments before marking as approved
@@ -143,7 +146,7 @@ no implementation found" so the harness can trigger a new implementation iterati
 - **gh: command not found** -> Install GitHub CLI: `brew install gh`
 - **gh auth error** -> Run: `gh auth login`
 - **PR already exists** -> Use: `gh pr view` to see status
-- **Claude Code CLI not installed** -> Install: `npm install -g @anthropic-ai/claude-code`
+- **Review CLI missing** -> Install the configured `$REVIEW_CLI` binary and retry
 
 ## Learning Capture
 If the review revealed patterns worth remembering, append to @.ralph/LEARNINGS.md:

package/dist/templates/prompts/PROMPT_review_manual.md.tmpl

@@ -11,6 +11,34 @@ Capture any review feedback patterns for future iterations.
 All implementation and E2E tasks are complete. Create PR for manual review.
 Complete ALL steps in a single pass — do not end the session between steps.
 
+### Step 0: Verify Spec Requirements
+Before creating the PR, verify the implementation meets the spec requirements and update spec files.
+
+1. Read @.ralph/specs/$FEATURE.md and for each requirement under "## Requirements":
+   - Check if it was implemented (review implementation plan tasks)
+   - Mark as `[x]` if complete, leave as `[ ]` if not implemented (add a note explaining why)
+
+2. For each item under "## Acceptance Criteria":
+   - Verify against implementation and test results
+   - Mark as `[x]` if verified, leave as `[ ]` with a note if not met
+
+3. Update spec status:
+   - Change `**Status:** Planned` (or `Draft`) to `**Status:** Completed` if all requirements met, or `**Status:** Partial` if some are missing
+   - Update `**Last Updated:**` to today's date
+
+4. Update @.ralph/specs/README.md Active Specs table:
+   - Update ONLY the row for $FEATURE (do NOT remove or modify other rows)
+   - Change status and update Last Updated date
+
+5. If any requirements were not fully met, add an "## Implementation Notes" section documenting gaps and reasons.
+
+6. Commit spec updates:
+   ```bash
+   git -C {{appDir}} add ../.ralph/specs/
+   git -C {{appDir}} commit -m "docs($FEATURE): verify spec requirements"
+   git -C {{appDir}} push origin feat/$FEATURE
+   ```
+
 ### Step 1: Verify Ready State
 1. Check all tasks are complete in implementation plan (no `- [ ]` items)
 2. Verify tests pass: `cd {{appDir}} && {{testCommand}}`
@@ -62,7 +90,7 @@ cd {{appDir}} && gh pr create --base main --head feat/$FEATURE \
 
 Closes #[Read the source issue number from the spec file metadata or context section]
 
-Generated with Claude Code
+Generated with Wiggum Loop
 EOF
 )"
 ```
@@ -78,7 +106,7 @@ The feature branch has been prepared and pushed. A pull request has been created
 2. Address any review comments
 3. Merge when approved
 
-Note: Spec status updates are handled in the Spec Verification phase before PR creation.
+Note: Spec status updates are handled in Step 0 above, before PR creation.
 
 ## Rules
 - Manual review mode stops after PR creation