jettypod 4.3.0 → 4.4.1

package/skills-templates/speed-mode/SKILL.md

@@ -22,28 +22,15 @@ Guides Claude Code through speed mode implementation with autonomous analysis an
 
 ## Instructions
 
-When this skill is activated, you are helping implement a speed mode chore to make all success scenarios pass. Follow this structured approach:
-
-## 🔑 Critical Context
-
-**You are working in an isolated git worktree:**
-- `work start [chore-id]` created a dedicated worktree for this chore
-- All file operations must use **absolute paths** from the worktree (not relative paths)
-- The worktree has its own branch - changes are isolated from main
-- BDD tests and unit tests run in the worktree context
-
-**Worktree path is available in Step 0 output** - use it for all file operations.
-
----
+When this skill is activated, you are helping implement a speed mode chore to make the happy path scenario pass. Follow this structured approach:
 
 ### Overview
 
-**Speed Mode Goal:** Make it work - implement ALL functionality (required + optional features) to make success scenarios pass, assuming everything works correctly.
+**Speed Mode Goal:** Implement ALL scoped functionality to make the happy path BDD scenario pass, assuming everything works correctly.
 
 **Key Principles:**
-- **Implement ALL features/functions** defined in scenarios - both required and optional functionality
-- **All success paths** - every workflow that should work when inputs are valid
-- **Assume success** - assume inputs are valid, files upload successfully, types are correct
+- **Implement ALL features/functions** defined in the scenario - do not skip functionality
+- **Assume happy path** - assume inputs are valid, files upload successfully, types are correct
 - **No error handling** - no validation, no edge case handling, no error messages (that's for stable mode)
 - **Fast iteration** - single file when possible, inline code over abstraction
 - **Use real infrastructure** - use the actual database/storage from your tech stack, not mocks
@@ -53,136 +40,20 @@ When this skill is activated, you are helping implement a speed mode chore to ma
 
 ---
 
-## 🧪 Unit Testing in Speed Mode - True TDD
-
-**Unit tests are written DURING the RED→GREEN loop, not after.**
-
-**The TDD workflow (each iteration):**
-1. **Identify next failing BDD step** - Which scenario step needs to pass next?
-2. **Write unit test for the function** - Test the specific function/logic needed
-3. **Watch unit test fail (RED)** - Confirm test catches the missing implementation
-4. **Write minimal code** - Just enough to make the unit test pass
-5. **Run unit test (GREEN)** - Verify the function works in isolation
-6. **Run BDD scenarios** - Check if this makes any BDD steps pass
-7. **Next iteration** - Repeat for next failing step
-
-**What to unit test:**
-- New functions you're creating (not framework/library code)
-- Core logic and business rules
-- Success scenarios only (no error cases - that's stable mode)
-
-**Where to put unit tests:**
-- Follow project conventions: `test/`, `__tests__/`, or `*.test.js` alongside code
-- Check existing test files for patterns
-
-**Example of TDD iteration:**
-```javascript
-// Iteration 1: BDD step "Given a user exists" is failing
-
-// 1. Write unit test first (RED)
-test('createUser creates user with valid data', () => {
-  const user = createUser('John', 'john@example.com');
-  expect(user.name).toBe('John');
-  expect(user.email).toBe('john@example.com');
-});
-// Run: FAILS - createUser doesn't exist
-
-// 2. Write minimal implementation (GREEN)
-function createUser(name, email) {
-  return { name, email };
-}
-// Run unit test: PASSES
-// Run BDD: "Given a user exists" now passes
-
-// Iteration 2: Next failing BDD step...
-```
-
-**Unit test scope in speed mode:**
-```javascript
-// ✅ Speed mode unit tests (success paths)
-test('createUser creates user with valid data', () => {
-  const user = createUser('John', 'john@example.com');
-  expect(user.name).toBe('John');
-  expect(user.email).toBe('john@example.com');
-});
-
-// ❌ NOT in speed mode (stable mode adds these)
-test('createUser throws error for invalid email', () => {
-  expect(() => createUser('John', 'invalid')).toThrow();
-});
-```
-
-<details>
-<summary><strong>📋 Speed Mode Constraints (click to expand)</strong></summary>
-
-**What to implement:**
-- ALL scoped functionality - required features AND optional features from all success scenarios
-- Multiple valid workflows if the feature supports them
-- Success variations (different outcomes that are all correct)
-
-**What NOT to implement:**
-- ❌ Error handling (try/catch, validation, edge cases)
-- ❌ Input validation (null checks, type checks, range validation)
-- ❌ Error messages for failures
-- ❌ Edge case handling (empty arrays, boundary values, race conditions)
-
-**Code organization:**
-- Single file when possible - keep it simple
-- Inline code over separate modules initially
-- Use real infrastructure (actual database/storage from your tech stack, not mocks)
-- Focus: Make. All. Features. Work. (all success paths)
-
-</details>
-
----
-
-### Step 0: Initialize Speed Mode Context
-
-**You are now in speed mode,** implementing a chore to make success scenarios pass.
-
-**Get the current work context:**
-
-```bash
-sqlite3 .jettypod/work.db "SELECT wi.id, wi.title, wi.parent_id, parent.title as parent_title, parent.scenario_file, wt.worktree_path, wt.branch_name FROM work_items wi LEFT JOIN work_items parent ON wi.parent_id = parent.id LEFT JOIN worktrees wt ON wi.id = wt.work_item_id WHERE wi.status = 'in_progress' AND wi.type = 'chore'"
-```
-
-**Display to user:**
-
-```
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-🚀 SPEED MODE: Implementing Chore #[id]
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-Chore: [title]
-Feature: #[parent-id] [parent-title]
-Worktree: [worktree_path]
-Branch: [branch_name]
-
-Analyzing BDD scenarios to determine implementation approach...
-```
-
-**Then proceed to Step 1.**
-
----
-
 ## Quick Reference: Async Boundaries
 
 **Where Claude Code MUST wait for user confirmation:**
 
-| Phase | Location | Why | Condition |
-|-------|----------|-----|-----------|
-| Step 3A | Before implementing (conditional) | User confirms implementation approach | Only if approach is ambiguous or multiple valid paths |
-| Step 6 Phase 2 | Before creating stable chores | User confirms proposed stable mode chores | Always |
+| Phase | Location | Why |
+|-------|----------|-----|
+| Step 3 Phase 1 | Before implementing | User confirms implementation approach |
+| Step 4 Phase 2 | Before creating chores | User confirms proposed stable mode chores |
 
 **Where Claude Code executes autonomously:**
-- Step 0: Initialize context
-- Step 1: Scenario analysis and breadcrumb check
+- Step 1: Scenario analysis
 - Step 2: Codebase analysis
-- Step 3: Decision to skip/ask for confirmation
-- Step 4: Establish RED baseline
-- Step 5: RED→GREEN→REFACTOR loop (true TDD)
-- Step 6 Phase 1: Generate stable mode scenarios/steps
-- Step 6 Phases 3-5: Create chores and invoke stable-mode skill
+- Step 3 Phase 2: RED→GREEN→REFACTOR loop
+- Step 4 Phases 3-4: Create chores and elevate
 
 ---
 
@@ -190,7 +61,7 @@ Analyzing BDD scenarios to determine implementation approach...
 
 **DO NOT mark features as complete after speed mode implementation.**
 
-Speed mode is ONLY a checkpoint to prove functionality works. Features are INCOMPLETE without stable mode chores that add:
+Speed mode is ONLY a checkpoint to prove the happy path works. Features are INCOMPLETE without stable mode chores that add:
 - Error handling and validation
 - Edge case coverage
 - Comprehensive testing
@@ -198,7 +69,7 @@ Speed mode is ONLY a checkpoint to prove functionality works. Features are INCOM
 
 **Required workflow after speed mode implementation:**
 
-1. ✅ **Complete ALL speed mode chores** - Implement all success scenarios (required + optional features)
+1. ✅ **Complete ALL speed mode chores** - Implement happy path functionality
 2. ✅ **Elevate to stable mode** - Use `node jettypod.js work set-mode <feature-id> stable` to auto-generate stable mode chores
 3. ✅ **Implement stable mode chores** - Add error handling and edge cases
 4. ❌ **NEVER mark feature complete in speed mode** - This bypasses critical quality gates
@@ -210,12 +81,17 @@ The validation will require you to:
 - This will automatically analyze the implementation and generate appropriate stable mode chores
 - Or explicitly skip (not recommended): `node jettypod.js work set-mode <feature-id> stable --force`
 
-**Remember:** Speed mode makes it work (all success scenarios). Stable mode makes it robust (handles failures).
+**Remember:** Speed mode proves it works on the happy path. Stable mode makes it production-ready.
 
 ---
 
 ## Implementation Steps
 
+<!-- ═══════════════════════════════════════════════════════════════════════════
+     PHASE 1: AUTONOMOUS ANALYSIS
+     No user input required - Claude Code executes independently
+     ═══════════════════════════════════════════════════════════════════════════ -->
+
 ### Step 1: Check for Breadcrumbs and Analyze Scenario
 
 **CRITICAL:** Claude Code executes this autonomously - no user permission needed.
@@ -230,8 +106,15 @@ The validation will require you to:
 **To get current work and check for breadcrumbs:**
 
 ```bash
-# Get current work item with description and parent feature's scenario_file
-sqlite3 .jettypod/work.db "SELECT wi.id, wi.title, wi.description, wi.parent_id, parent.title as parent_title, parent.scenario_file FROM work_items wi LEFT JOIN work_items parent ON wi.parent_id = parent.id WHERE wi.status = 'in_progress' AND wi.type = 'chore'"
+# Get current work item with description
+jettypod work current
+
+# Get parent feature details including scenario_file
+jettypod work show <parent-feature-id>
+
+# Or query database directly
+sqlite3 .jettypod/work.db "SELECT id, title, description, parent_id FROM work_items WHERE status = 'in_progress' AND type = 'chore'"
+sqlite3 .jettypod/work.db "SELECT id, title, scenario_file FROM work_items WHERE id = <parent-feature-id>"
 ```
 
 **Check for breadcrumbs** by examining the chore's description for:
@@ -244,8 +127,8 @@ If all three sections exist, use them. Otherwise, fall back to autonomous analys
 **Then read the scenario file** using the Read tool on the path returned by `scenario_file`.
 
 **Parse Gherkin:**
-- Extract all `Scenario:` blocks (all success paths - required + optional features)
-- Parse Given/When/Then/And steps for each scenario
+- Extract first `Scenario:` block (happy path)
+- Parse Given/When/Then/And steps
 - Identify:
   - Initial state setup (Given)
   - User actions (When)
@@ -358,62 +241,65 @@ Integration Points:
 Now proposing implementation approach...
 ```
 
-### Step 3: Decide if Confirmation Needed
-
-**Evaluate if you need user confirmation before implementing:**
+**Move to Step 3 automatically.**
 
-**Skip confirmation (proceed directly to Step 4) if:**
-- Breadcrumbs are comprehensive (files, patterns, functions all specified)
-- Implementation approach is clear and unambiguous
-- Only one reasonable way to implement the scenario
-- Epic architectural decisions are clear and constraining
+<!-- ═══════════════════════════════════════════════════════════════════════════
+     PHASE 2: USER CONFIRMATION REQUIRED
+     ⚡ ASYNC BOUNDARY - Must wait for user response before proceeding
+     ═══════════════════════════════════════════════════════════════════════════ -->
 
-**Ask for confirmation (Step 3A) if:**
-- Multiple valid implementation approaches exist
-- Breadcrumbs are vague or missing key details
-- Architectural choice impacts other features
-- You're uncertain about the right approach
+### Step 3: Propose and Execute Implementation
 
-### Step 3A: Propose Implementation Approach (Conditional)
+**Two phases: Propose (get user confirmation) → Execute (autonomous)**
 
-**⚡ ASYNC BOUNDARY - Only execute this if confirmation needed**
+#### Phase 1: Propose Implementation Approach
 
-**Present your analysis and proposal to the user:**
+**Present your analysis and proposal:**
 
 ```
 💡 Implementation Proposal
 
-I see multiple ways to approach this. Here's what I'm thinking:
+Based on scenario analysis and codebase patterns, here's how I'll make the scenario pass:
 
-**Option I'm recommending:**
-• Files to create/modify: [specific paths]
-• Key approach: [what makes this the right choice]
-• Why: [rationale - why this over alternatives]
+**Files to create/modify:**
+1. [file path] - [what it will do]
+2. [file path] - [what it will do]
 
-**Alternative considered:**
-• [Brief description] - not choosing because [reason]
+**Key implementation points:**
+• [Point 1]: [specific approach]
+• [Point 2]: [specific approach]
+• [Point 3]: [specific approach]
 
-Sound good, or would you prefer a different approach?
+**Why this approach:**
+[Brief explanation of how this satisfies the scenario while following codebase patterns]
+
+Sound good? I'll implement this autonomously once you confirm.
 ```
 
-**⚡ WAIT for user confirmation or adjustments.**
+**WAIT for user confirmation or adjustments.**
 
-If user adjusts: revise proposal and confirm again before proceeding.
+If user adjusts: revise proposal and confirm again.
 
-**If you skipped this step:** Proceed directly to Step 4.
+<!-- ═══════════════════════════════════════════════════════════════════════════
+     PHASE 3: AUTONOMOUS EXECUTION
+     User has confirmed - Claude Code executes RED→GREEN loop independently
+     ═══════════════════════════════════════════════════════════════════════════ -->
 
----
+#### Phase 2: Autonomous Execution
 
-### Step 4: Establish RED Baseline
+**CRITICAL:** After user confirms, Claude Code executes autonomously - no permission needed for individual code changes.
 
-**CRITICAL:** After user confirms, execute autonomously - no permission needed for code changes.
+**Step 1: Establish RED Baseline**
 
 Before writing any implementation code, run tests to establish the RED state:
 
 ```bash
 # Get current work and parent feature's scenario file
-sqlite3 .jettypod/work.db "SELECT wi.id, wi.parent_id, parent.scenario_file FROM work_items wi LEFT JOIN work_items parent ON wi.parent_id = parent.id WHERE wi.status = 'in_progress'"
-# This gives you the chore ID, parent feature ID, and path to the .feature file
+jettypod work current
+# Note the parent_id from output
+
+sqlite3 .jettypod/work.db "SELECT scenario_file FROM work_items WHERE id = <parent-feature-id>"
+# This gives you the path to the .feature file
 
 # Run BDD tests to establish RED baseline
 npx cucumber-js <scenario-file-path> --format progress
@@ -448,360 +334,441 @@ First error:
 Now implementing...
 ```
 
----
+**Step 2: RED→GREEN Iteration Loop**
 
-### Step 5: RED→GREEN→REFACTOR Loop
+Iterate until all tests pass or MAX_ITERATIONS reached:
 
-**Execute autonomously** - iterate until tests pass (max 10 iterations).
+<!-- ┌─────────────────────────────────────────────────────────────────────────┐
+     │ 🔄 ITERATION LOOP: RED→GREEN                                           │
+     │                                                                         │
+     │ Progress Tracking:                                                      │
+     │ • Display: "Iteration X/10" at start of each cycle                     │
+     │ • Track: steps passing vs total, newly passing steps                   │
+     │ • Goal: All steps pass (exit code 0)                                   │
+     │                                                                         │
+     │ Return Points:                                                          │
+     │ • CHECKPOINT_ITERATION: Resume at specific iteration number            │
+     │ • CHECKPOINT_PROGRESS: Resume with known passing step count            │
+     │ • If session interrupted, can resume from last known iteration         │
+     └─────────────────────────────────────────────────────────────────────────┘ -->
 
-**Each iteration (True TDD):**
+```javascript
+// --- Imports and setup ---
+const { runBddScenarioWithTimeout, parseTestProgress, findNewlyPassingSteps, extractErrors, MAX_ITERATIONS } = require('./.claude/skills/speed-mode/test-runner');
+
+let previousResult = global.redBaseline; // From Step 1
+let iteration = 0;
+
+// --- Main iteration loop ---
+// 📊 PROGRESS: Iteration {iteration}/{MAX_ITERATIONS} | Steps: {passed}/{total}
+while (iteration < MAX_ITERATIONS) {
+  iteration++;
+  console.log(`\n━━━ Iteration ${iteration}/${MAX_ITERATIONS} ━━━`);
+
+  // --- Make code changes ---
+  console.log(`\n✍️  Making code changes...`);
+  // [Claude Code writes implementation code here using Write/Edit tools]
+
+  // --- Run tests ---
+  console.log(`\n🧪 Running tests...`);
+  const result = await runBddScenarioWithTimeout(feature.scenario_file, happyPathLine);
+
+  // --- Handle timeout ---
+  if (result.timedOut) {
+    console.log(`⚠️  Test execution timed out - tests may be hanging`);
+    console.log(`Stopping iteration loop`);
+    break;
+  }
 
-1. **Identify next failing BDD step** - Which scenario step to tackle?
-2. **Write unit test** - Test the function/logic needed for that step (watch it fail - RED)
-3. **Write minimal implementation** - Just enough code to pass the unit test
-4. **Run unit test** - Verify it passes (GREEN)
-5. **Run BDD scenarios** - Check if BDD step now passes
-6. **Display progress** - Show what's passing, what's next
-7. **Continue or exit** - If all BDD scenarios pass → REFACTOR. Otherwise, repeat.
+  // --- Parse results and track progress ---
+  const currentResult = parseTestProgress(result.stdout + result.stderr);
+  const errors = extractErrors(result.stdout + result.stderr);
+  const newlyPassing = findNewlyPassingSteps(previousResult, currentResult);
 
-**Show progress each iteration:**
-```
-━━━ Iteration 3/10 ━━━
-📝 Unit test: test/dashboard.test.js - sortActivityByDate()
-   RED: Test fails - function doesn't exist yet
-✍️  Implementation: src/dashboard.js - added sortActivityByDate()
-   GREEN: Unit test passes
-🧪 Running BDD scenarios...
-📊 Progress: 7/8 BDD steps passing
-✅ Newly passing: And activity should be sorted by date
-🔧 Next failure: And activity should be filterable
-    BDD step: When I filter by category "work"
-```
+  // --- Display progress ---
+  console.log(`\n📊 Progress: ${currentResult.passed}/${currentResult.total} steps passing`);
 
-**When GREEN achieved:**
-```
-🎉 GREEN: All success scenarios passing!
-```
+  if (newlyPassing.length > 0) {
+    console.log(`\n✅ Newly passing:`);
+    newlyPassing.forEach(step => console.log(`  • ${step}`));
+  }
 
-**Then REFACTOR (quick pass, 5 min max):**
-- Extract duplicated code
-- Rename unclear variables  
-- Simplify complex expressions
-- Remove dead code
+  // --- Check for GREEN state ---
+  if (currentResult.exitCode === 0 || currentResult.passed === currentResult.total) {
+    console.log(`\n🎉 GREEN: All tests passing!`);
+    break;
+  }
 
-**Re-run tests after refactor** to ensure nothing broke.
+  // --- Display next failure ---
+  if (errors.errors.length > 0) {
+    const nextError = errors.errors[0];
+    console.log(`\n🔧 Next failure to address:`);
+    console.log(`  Step: ${nextError.step}`);
+    console.log(`  Error: ${nextError.message}`);
+    if (nextError.stack) {
+      console.log(`  Stack: ${nextError.stack.split('\n')[0]}`);
+    }
+  } else if (currentResult.failedSteps.length > 0) {
+    console.log(`\n🔧 Still failing:`);
+    currentResult.failedSteps.slice(0, 3).forEach(step => console.log(`  • ${step}`));
+    if (currentResult.failedSteps.length > 3) {
+      console.log(`  ... and ${currentResult.failedSteps.length - 3} more`);
+    }
+  }
 
-<details>
-<summary><strong>📋 TDD Loop Guidelines (click to expand)</strong></summary>
+  previousResult = currentResult;
+}
 
-**Iteration strategy:**
-- Start with first failing step
-- Make minimal change to pass that step
-- Run tests immediately
-- Move to next failure
+// --- Handle max iterations reached ---
+if (iteration >= MAX_ITERATIONS) {
+  console.log(`\n⚠️  Maximum iterations (${MAX_ITERATIONS}) reached without achieving GREEN`);
+  console.log(`Final progress: ${previousResult.passed}/${previousResult.total} steps passing`);
+  console.log(`\nConsider:`);
+  console.log(`  • Breaking down the chore into smaller pieces`);
+  console.log(`  • Reviewing the implementation approach`);
+  console.log(`  • Checking for incorrect assumptions`);
+}
+```
 
-**If stuck after 5 iterations:**
-- Review approach - is there a simpler path?
-- Check assumptions - are you solving the right problem?
-- Break down the change - can you make smaller steps?
+**Display example:**
+```
+━━━ Iteration 1/10 ━━━
 
-**Max 10 iterations:**
-- If you hit max without GREEN, stop
-- Display final progress and suggest next steps
-- Consider breaking chore into smaller pieces
+✍️  Making code changes...
+Created src/login.js
+Modified src/app.js
 
-</details>
+🧪 Running tests...
 
----
+📊 Progress: 2/8 steps passing
 
-**CRITICAL: Check if ALL speed mode chores are complete. Stable mode transition happens ONLY after all speed chores are done.**
+✅ Newly passing:
+  • Given a user is logged in
+  • When they click the dashboard button
 
-<!-- ┌─────────────────────────────────────────────────────────────────────────┐
-     │ 🔍 COMPLETION CHECK: Speed Chores                                      │
-     │                                                                         │
-     │ Progress Tracking:                                                      │
-     │ • Query: Count incomplete speed chores for feature                     │
-     │ • Display: "X speed mode chores remaining" or "All complete"           │
-     │ • Action: Generate stable scenarios/steps/chores if all complete       │
-     │                                                                         │
-     │ Return Point:                                                           │
-     │ • CHECKPOINT_CHORE_COUNT: Known incomplete count from last check       │
-     │ • If session interrupted, re-query to get current count                │
-     └─────────────────────────────────────────────────────────────────────────┘ -->
+🔧 Next failure to address:
+  Step: Then they should see their dashboard
+  Error: Cannot read property 'innerText' of null
+  Stack: at Dashboard.render (src/dashboard.js:12:15)
 
-**Check for incomplete speed chores:**
+━━━ Iteration 2/10 ━━━
 
-```bash
-# Get current work to find parent feature ID
-sqlite3 .jettypod/work.db "SELECT wi.parent_id FROM work_items wi WHERE wi.status = 'in_progress'"
+✍️  Making code changes...
+Created src/dashboard.js
+Modified src/app.js
 
-# Get list of remaining speed chores (excluding current chore)
-sqlite3 .jettypod/work.db "SELECT id, title FROM work_items WHERE parent_id = <feature-id> AND type = 'chore' AND mode = 'speed' AND status != 'done' AND id != <current-chore-id> ORDER BY created_at LIMIT 1"
-```
+🧪 Running tests...
 
-**If speed chores remain, display and start next chore:**
+📊 Progress: 5/8 steps passing
 
-```
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-🎯 Speed Mode Chore Complete
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+✅ Newly passing:
+  • Then they should see their dashboard
+  • And the dashboard should show their username
+  • And the dashboard should show their recent activity
 
-✅ Success scenarios pass for this chore
+🔧 Next failure to address:
+  Step: And the activity should be sorted by date
+  Error: Expected ['Post 2', 'Post 1'] but got ['Post 1', 'Post 2']
 
-More speed mode chores remain. Starting next chore:
-#[next-chore-id]: [next-chore-title]
-```
+━━━ Iteration 3/10 ━━━
 
-**Then immediately merge current chore and start next:**
+✍️  Making code changes...
+Modified src/dashboard.js
 
-```bash
-# Commit changes in the worktree
-git add . && git commit -m "feat: [brief description of what was implemented]"
+🧪 Running tests...
 
-# Merge current chore - this automatically marks it as done
-jettypod work merge
+📊 Progress: 8/8 steps passing
 
-# Start next speed chore
-jettypod work start [next-chore-id]
-```
+✅ Newly passing:
+  • And the activity should be sorted by date
 
-**CRITICAL: Use ONLY `jettypod work merge` to complete chores.**
-- ❌ DO NOT use `jettypod work status <id> done`
-- ❌ DO NOT use `jettypod work complete <id>`
-- ❌ DO NOT use `jettypod work set-mode <id> done`
-- ✅ ONLY use `jettypod work merge`
+🎉 GREEN: All tests passing!
+```
 
-The merge command handles everything: pushes branch, merges to main, marks chore done, cleans up worktree.
+**Speed mode constraints:**
+- **Implement ALL scoped functionality** - if the scenario requires file upload, implement it (just assume it works)
+- **Single file when possible** - keep it simple
+- **NO error handling** - no try/catch, no validation, no edge cases
+- **Assume everything works** - valid inputs, successful operations, correct types
+- **Use real infrastructure** - actual database/storage from your tech stack
+- **Inline code over separate modules** - keep it simple
+- **Focus: Make. All. Features. Work.** (on the happy path)
 
-The speed-mode skill will automatically re-invoke for the next chore.
+**Step 3: REFACTOR**
 
-**If all speed chores are done (count = 0), continue to Step 6 below.**
+After GREEN is achieved, do a quick refactor pass:
 
----
+1. **Extract duplicated code** - DRY up any copy-pasted logic
+2. **Rename unclear variables** - make intent obvious
+3. **Simplify complex expressions** - break into readable steps
+4. **Remove dead code** - delete unused variables/functions
 
-### Step 6: Transition to Stable Mode (After All Speed Chores Complete)
+**Keep it fast** - 5 minutes max. Major refactoring happens in stable mode.
 
-**⚡ ASYNC BOUNDARY - Must wait for user to confirm proposed scenarios/chores**
+**Re-run tests after refactoring** to ensure nothing broke:
 
-**CRITICAL:** This step ONLY runs after ALL speed chores are complete. This is the transition from speed mode to stable mode.
+```javascript
+const result = await runBddScenarioWithTimeout(feature.scenario_file, scenarioLine);
+if (result.exitCode !== 0) {
+  console.log('⚠️  Refactoring broke tests - revert and try again');
+}
+```
 
-**Workflow: Merge last chore → Generate scenarios → Generate step definitions → Propose chores → Commit BDD files → Create chores → Set mode to stable → Invoke stable-mode skill**
+**Step 4: Final Verification and Completion**
 
-#### Phase 1: Merge Final Speed Chore
+After GREEN + REFACTOR, run full feature file once to verify no regressions:
 
-**Complete the current (final) speed chore:**
+```javascript
+// After iteration loop succeeds (GREEN achieved)
+if (currentResult.exitCode === 0 || currentResult.passed === currentResult.total) {
+  console.log(`\n🎉 GREEN: Happy path scenario passing!`);
+  console.log(`\n🔍 Running full verification (all scenarios)...`);
+
+  // Run entire feature file once for regression detection
+  // Uses the already imported runBddScenarioWithTimeout with no line number to run all scenarios
+  const fullResult = await runBddScenarioWithTimeout(feature.scenario_file);
+
+  if (fullResult.timedOut) {
+    console.log(`⚠️  Full verification timed out`);
+  } else if (fullResult.exitCode !== 0) {
+    const fullProgress = parseTestProgress(fullResult.stdout + fullResult.stderr);
+    console.log(`⚠️  Full verification found regressions: ${fullProgress.total - fullProgress.passed} scenarios failing`);
+    console.log(`This is expected in speed mode - stable mode will address additional scenarios.`);
+  } else {
+    console.log(`✅ Full verification passed - all scenarios passing!`);
+  }
+}
+```
 
-```bash
-# Commit changes in the worktree
-git add . && git commit -m "feat: [brief description of what was implemented]"
+Display comprehensive results:
 
-# Merge to main with lock held for transition phase
-# This prevents race conditions when multiple instances generate BDD files simultaneously
-jettypod work merge --with-transition
-```
+**On SUCCESS (GREEN achieved):**
 
-<details>
-<summary>💡 Why --with-transition? (click to expand)</summary>
+```javascript
+// Track what files were created/modified during implementation
+const filesCreated = [/* list of created files */];
+const filesModified = [/* list of modified files */];
 
-The `--with-transition` flag holds the merge lock through the entire BDD generation phase (Phases 2-6).
+console.log(`\n━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━`);
+console.log(`✅ SPEED MODE COMPLETE - GREEN STATE ACHIEVED`);
+console.log(`━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━\n`);
 
-**Without this flag:**
-- Instance A merges → generates BDD → appends to step_definitions/auth.steps.js
-- Instance B merges → generates BDD → appends to step_definitions/auth.steps.js (CONFLICT!)
-- Second write can overwrite first write, losing step definitions
+console.log(`🎉 Happy path scenario: ALL TESTS PASSING\n`);
 
-**With this flag:**
-- Instance A acquires lock → merges → generates BDD → commits → releases lock
-- Instance B waits → acquires lock → merges → generates BDD → commits → releases lock
-- No conflicts, all step definitions preserved
+console.log(`Implementation Summary:`);
+console.log(`  Iterations: ${iteration}/${MAX_ITERATIONS}`);
+console.log(`  Test steps: ${currentResult.passed}/${currentResult.total} passing\n`);
 
-You'll release the lock in Phase 6 after committing BDD files.
-</details>
+if (filesCreated.length > 0) {
+  console.log(`Files created:`);
+  filesCreated.forEach(file => console.log(`  ✅ ${file}`));
+  console.log();
+}
 
-**CRITICAL: Use ONLY `jettypod work merge` to complete chores.**
-- ❌ DO NOT use `jettypod work status <id> done`
-- ❌ DO NOT use `jettypod work complete <id>`
-- ❌ DO NOT use `jettypod work set-mode <id> done`
-- ✅ ONLY use `jettypod work merge`
+if (filesModified.length > 0) {
+  console.log(`Files modified:`);
+  filesModified.forEach(file => console.log(`  ✏️  ${file}`));
+  console.log();
+}
 
-After merge, you are now on main branch. Ready to generate stable mode scenarios.
+// --- Create unit tests for new functions ---
+// For each new function implemented, create a unit test file with happy path coverage
 
-#### Phase 2: Generate Stable Mode BDD Scenarios
+// Unit test template for new functions:
+// test/[filename].test.js or __tests__/[filename].test.js
+/*
+const { functionName } = require('../src/path/to/module');
 
-**Your task:** Create BDD scenarios for error handling, edge cases, and validation.
+describe('functionName', () => {
+  it('should handle valid input successfully', () => {
+    // Arrange
+    const input = validTestData;
 
-**Read the feature's existing scenario file:**
+    // Act
+    const result = functionName(input);
 
-```bash
-# Find the feature's scenario file
-sqlite3 .jettypod/work.db "SELECT id, title FROM work_items WHERE id = <feature-id>"
-# Look for: features/bdd/<epic-slug>/<feature-slug>.feature
-```
+    // Assert
+    expect(result).toEqual(expectedOutput);
+  });
+});
+*/
 
-**Analysis checklist for new scenarios:**
+// Speed mode unit tests focus on:
+// - Happy path with valid input
+// - One successful operation per function
+// - Basic return value verification
 
-1. **Error scenarios** - What can go wrong?
-   - Invalid user input (wrong types, out of range, malformed data)
-   - Missing required parameters
-   - System errors (file not found, network errors, database errors)
-   - Permission/authorization failures
+console.log(`Next step: Elevate to stable mode using 'jettypod work set-mode <feature-id> stable'\n`);
+```
 
-2. **Edge case scenarios** - Boundary conditions
-   - Empty inputs (empty strings, empty arrays, null values)
-   - Maximum values (large numbers, long strings, many items)
-   - Minimum values (zero, negative numbers)
-   - Special characters and Unicode
+**Display:**
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+✅ GREEN STATE ACHIEVED - Now Creating Stable Chores
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
-3. **State consistency scenarios** - Data integrity
-   - Concurrent operations (race conditions)
-   - Partial failures (transaction rollbacks)
-   - State transitions (invalid state changes)
+🎉 Happy path scenario: ALL TESTS PASSING
 
-**Generate stable scenarios and append to feature file:**
+Implementation Summary:
+  Iterations: 3/10
+  Test steps: 8/8 passing
 
-```gherkin
-Scenario: Handle missing required parameter
-  Given the system is initialized
-  When I call the function with missing "name" parameter
-  Then it should throw a validation error
-  And the error message should be "Parameter 'name' is required"
+Files created:
+  ✅ src/login.js
+  ✅ src/dashboard.js
 
-Scenario: Handle empty input
-  Given the system is initialized
-  When I provide an empty string as input
-  Then it should return an appropriate error
-  And the error code should be "INVALID_INPUT"
+Files modified:
+  ✏️  src/app.js
+  ✏️  src/index.html
 
-Scenario: Handle maximum boundary value
-  Given the system is initialized
-  When I provide the maximum allowed value
-  Then it should process successfully
-  And return the expected result
+⚠️  Speed mode is NOT complete until stable chores exist.
+Proceeding to Step 4 to create stable mode chores...
 ```
 
-**Append scenarios to the feature file** (don't overwrite existing speed scenarios):
+**On FAILURE (max iterations or timeout):**
 
-```bash
-# Append to existing .feature file
-cat >> features/bdd/<epic-slug>/<feature-slug>.feature << 'EOF'
+```javascript
+// --- Display failure header ---
+console.log(`\n━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━`);
+console.log(`⚠️  SPEED MODE INCOMPLETE - STILL IN RED STATE`);
+console.log(`━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━\n`);
+
+// --- Handle timeout case ---
+if (result.timedOut) {
+  console.log(`❌ Test execution timed out`);
+  console.log(`\nPossible causes:`);
+  console.log(`  • Infinite loop in implementation code`);
+  console.log(`  • Test is waiting for async operation that never completes`);
+  console.log(`  • Step definition has blocking code`);
+} else {
+  // --- Handle max iterations case ---
+  console.log(`❌ Maximum iterations (${MAX_ITERATIONS}) reached\n`);
+  console.log(`Final Progress: ${previousResult.passed}/${previousResult.total} steps passing\n`);
+
+  // --- Display failing steps ---
+  if (previousResult.failedSteps.length > 0) {
+    console.log(`Still failing:`);
+    previousResult.failedSteps.forEach(step => console.log(`  ✖ ${step}`));
+    console.log();
+  }
 
-# Stable Mode Scenarios - Error Handling and Edge Cases
+  // --- Display remaining errors ---
+  const errors = extractErrors(result.stdout + result.stderr);
+  if (errors.errors.length > 0) {
+    console.log(`Remaining errors:`);
+    errors.errors.slice(0, 3).forEach(err => {
+      console.log(`  Step: ${err.step}`);
+      console.log(`  Error: ${err.message}\n`);
+    });
+  }
+}
 
-Scenario: [Title]
-  Given [context]
-  When [action]
-  Then [expected behavior]
+// --- Display next steps ---
+console.log(`\nWhat to do:`);
+console.log(`  • Review implementation approach - is it the right strategy?`);
+console.log(`  • Check for incorrect assumptions about existing code`);
+console.log(`  • Consider breaking this chore into smaller pieces`);
+console.log(`  • Verify step definitions match what implementation provides`);
+console.log(`\nDO NOT proceed to generate stable mode chores until GREEN is achieved.`);
+```
 
-Scenario: [Title]
-  Given [context]
-  When [action]
-  Then [expected behavior]
-EOF
+**Display (on failure):**
 ```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+⚠️  SPEED MODE INCOMPLETE - STILL IN RED STATE
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
-#### Phase 3: Generate Stable Mode Step Definitions
+❌ Maximum iterations (10) reached
 
-**Your task:** Create step definition files for the new stable scenarios.
+Final Progress: 5/8 steps passing
 
-**Identify new step definitions needed:**
+Still failing:
+  ✖ Then they should see their dashboard
+  ✖ And the dashboard should show their username
+  ✖ And the dashboard should show their recent activity
 
-1. Read the stable scenarios you just created
-2. Extract unique Given/When/Then steps
-3. Check if step definitions already exist in `features/bdd/<epic-slug>/steps/`
-4. Create new step definition files for missing steps
+Remaining errors:
+  Step: Then they should see their dashboard
+  Error: Cannot read property 'innerText' of null
 
-**Generate step definition files:**
+  Step: And the dashboard should show their username
+  Error: Expected 'John Doe' but got undefined
 
-```javascript
-// features/bdd/<epic-slug>/steps/<feature-slug>-stable.steps.js
-
-const { Given, When, Then } = require('@cucumber/cucumber');
-const { expect } = require('chai');
-
-// Error handling steps
-When('I call the function with missing {string} parameter', async function(paramName) {
-  try {
-    // Implementation that calls function without parameter
-    this.error = null;
-  } catch (err) {
-    this.error = err;
-  }
-});
+What to do:
+  • Review implementation approach - is it the right strategy?
+  • Check for incorrect assumptions about existing code
+  • Consider breaking this chore into smaller pieces
+  • Verify step definitions match what implementation provides
 
-Then('it should throw a validation error', function() {
-  expect(this.error).to.exist;
-  expect(this.error.name).to.equal('ValidationError');
-});
+DO NOT proceed to generate stable mode chores until GREEN is achieved.
+```
 
-Then('the error message should be {string}', function(expectedMessage) {
-  expect(this.error.message).to.equal(expectedMessage);
-});
+**Move to Step 4 IMMEDIATELY if GREEN achieved.**
 
-// Edge case steps
-When('I provide an empty string as input', async function() {
-  this.result = await this.functionUnderTest('');
-});
+**CRITICAL: GREEN is NOT completion - it's just a checkpoint. Speed mode is INCOMPLETE until stable mode chores are created. You MUST continue to Step 4.**
 
-When('I provide the maximum allowed value', async function() {
-  this.result = await this.functionUnderTest(Number.MAX_SAFE_INTEGER);
-});
-```
+<!-- ═══════════════════════════════════════════════════════════════════════════
+     PHASE 4: STABLE CHORE GENERATION
+     ⚡ ASYNC BOUNDARY - Must wait for user to confirm proposed chores
+     ═══════════════════════════════════════════════════════════════════════════ -->
 
-**Create step definition files:**
+### Step 4: Generate Stable Mode Chores (REQUIRED - Do Not Skip)
 
-```bash
-# Create the step definition file
-touch features/bdd/<epic-slug>/steps/<feature-slug>-stable.steps.js
-# Write the step definitions to the file
-```
+**CRITICAL:** This step is MANDATORY. Speed mode is NOT complete until stable mode chores exist. Without them, users cannot resume work on this feature.
+
+**Two phases: Analyze and propose → Get confirmation → Create autonomously**
 
-#### Phase 4: Analyze Implementation and Propose Stable Mode Chores
+#### Phase 1: Analyze Implementation
 
-**Your task:** Based on the stable scenarios and step definitions, identify what needs to be implemented.
+**Your task:** Review what was built and identify what's needed for stable mode.
 
 **Analysis checklist:**
 
 1. **Error handling gaps**
-   - What validation needs to be added?
-   - What error types need to be thrown?
-   - What error messages need to be user-friendly?
-
-2. **Edge case handling**
-   - What boundary checks are needed?
-   - What null/undefined checks are missing?
-   - What type validation is needed?
-
-3. **Code that needs refactoring**
-   - What needs better structure for error handling?
+   - What user errors are possible?
+   - What system errors could occur?
+   - What validation is missing?
+
+2. **Edge cases**
+   - Boundary conditions (empty inputs, max values, etc.)
+   - Race conditions
+   - State consistency issues
+
+3. **Non-happy-path scenarios**
+   - Read the full scenario file (not just happy path)
+   - Identify scenarios 2+ (error handling, edge cases)
+   - Check what additional behavior is needed
+
+4. **Code quality needs**
+   - What needs better structure/organization?
+   - What needs proper error messages?
    - What needs logging/debugging support?
-   - What needs better separation of concerns?
+
+#### Phase 2: Propose Stable Mode Chores
 
 **Present your analysis:**
 
 ```
 📋 Stable Mode Chores Proposal
 
-I've generated [N] stable mode scenarios covering error handling and edge cases.
-I've created step definitions for these scenarios.
-
-Here are the chores needed to make these scenarios pass:
+I've analyzed the implementation. Here are the chores needed for stable mode:
 
 **Chore 1: [Title]**
 - Why: [What gap this fills]
 - Scope: [What specifically needs to be done]
-- Scenarios: [Which BDD scenarios this addresses]
+- Scenario: [Which BDD scenario this addresses, if applicable]
 
 **Chore 2: [Title]**
 - Why: [What gap this fills]
 - Scope: [What specifically needs to be done]
-- Scenarios: [Which BDD scenarios this addresses]
+- Scenario: [Which BDD scenario this addresses, if applicable]
 
 **Chore 3: [Title]**
 - Why: [What gap this fills]
 - Scope: [What specifically needs to be done]
-- Scenarios: [Which BDD scenarios this addresses]
+- Scenario: [Which BDD scenario this addresses, if applicable]
 
-These chores will make all stable mode scenarios pass with proper error handling and edge case coverage.
+These chores will make all BDD scenarios pass with proper error handling and edge case coverage.
 
 Sound good? I'll create these chores once you confirm.
 ```
@@ -810,7 +777,12 @@ Sound good? I'll create these chores once you confirm.
 
 If user adjusts: revise chores and confirm again.
 
-#### Phase 5: Create Chores Autonomously
+<!-- ═══════════════════════════════════════════════════════════════════════════
+     PHASE 5: AUTONOMOUS COMPLETION
+     User has confirmed chores - create them and finalize
+     ═══════════════════════════════════════════════════════════════════════════ -->
+
+#### Phase 3: Create Chores Autonomously
 
 **CRITICAL:** After user confirms, create chores programmatically - no additional permission needed.
 
@@ -818,7 +790,7 @@ If user adjusts: revise chores and confirm again.
 
 ```javascript
 const { create } = require('./features/work-tracking');
-const { getCurrentWork } = require('./lib/current-work');
+const { getCurrentWork } = require('../../lib/current-work');
 
 (async () => {
   const currentWork = await getCurrentWork();
@@ -840,47 +812,46 @@ Chores created:
 • #[ID]: [Title]
 ```
 
-#### Phase 6: Commit Stable Mode Scenarios and Steps to Main
+#### Phase 4: Auto-Elevate to Stable Mode (If All Speed Chores Done)
 
-**CRITICAL: Commit the BDD files to main BEFORE starting stable chores.**
+**CRITICAL: Check if ALL speed mode chores are complete. If yes, auto-elevate to stable mode.**
 
-```bash
-# You're currently on main after merging the last speed chore
-# Commit the stable mode scenarios and step definitions
-git add features/
-git commit -m "test: Add stable mode BDD scenarios and step definitions
-
-Added error handling and edge case scenarios for stable mode implementation.
+<!-- ┌─────────────────────────────────────────────────────────────────────────┐
+     │ 🔍 COMPLETION CHECK: Speed Chores                                      │
+     │                                                                         │
+     │ Progress Tracking:                                                      │
+     │ • Query: Count incomplete speed chores for feature                     │
+     │ • Display: "X speed mode chores remaining" or "All complete"           │
+     │ • Action: Auto-elevate if all complete                                 │
+     │                                                                         │
+     │ Return Point:                                                           │
+     │ • CHECKPOINT_CHORE_COUNT: Known incomplete count from last check       │
+     │ • If session interrupted, re-query to get current count                │
+     └─────────────────────────────────────────────────────────────────────────┘ -->
 
-- [N] new stable mode scenarios
-- Step definitions for validation, error handling, and edge cases"
+**Check for incomplete speed chores:**
 
-# Push to remote
-git push
+```bash
+# Get current work to find parent feature ID
+jettypod work current
 
-# Release the merge lock (held since Phase 1)
-jettypod work merge --release-lock
+# Count incomplete speed chores for the feature
+sqlite3 .jettypod/work.db "SELECT COUNT(*) FROM work_items WHERE parent_id = <feature-id> AND type = 'chore' AND mode = 'speed' AND status != 'done'"
 ```
 
-This ensures stable mode BDD files are in main and will be present in stable chore worktrees.
-
-The merge lock is now released - other instances can proceed with their transitions.
-
-#### Phase 7: Set Feature Mode to Stable
-
-**Set the feature mode:**
+**If all speed chores are done (count = 0), EXECUTE elevation:**
 
 ```bash
 jettypod work set-mode <feature-id> stable
 ```
 
-#### Phase 8: Invoke Stable Mode Skill
+**DO NOT display this as example text. EXECUTE IT using the Bash tool.**
 
-**CRITICAL: Immediately transition to stable-mode skill to start implementing stable chores.**
+After execution, display:
 
 ```
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-🎯 Speed Mode Complete! Transitioning to Stable Mode
+🎯 Speed Mode Complete! Feature Elevated to Stable Mode
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
 ⚠️  CRITICAL: Speed mode is ONLY a checkpoint to prove functionality works.
@@ -888,35 +859,56 @@ The feature is INCOMPLETE without stable mode - error handling, validation,
 edge cases, and comprehensive testing are ALL required.
 
 What we accomplished:
+✅ Happy path scenario passes
 ✅ All speed mode chores complete
-✅ Generated [N] stable mode BDD scenarios
-✅ Created step definitions for stable scenarios
-✅ Created [N] stable mode chores
-✅ Feature mode set to stable
+✅ Feature elevated to stable mode
+✅ Stable mode chores created and ready
 
-🚀 NEVER leave a feature in speed mode.
+🚀 NEVER leave a feature in speed mode - it's not production-ready.
 Stable mode adds:
   • Comprehensive error handling and user-friendly error messages
   • Input validation (null checks, type checks, range validation)
   • Edge case handling (empty arrays, boundary values, race conditions)
   • State consistency and data integrity
-  • All BDD scenarios passing (success scenarios + error/edge cases)
+  • All BDD scenarios passing (happy path + error/edge cases)
+
+**Next step:** IMMEDIATELY start the first stable mode chore
+  jettypod work start [first-stable-chore-id]
+```
+
+**If speed chores remain, display:**
 
-**Next step:** I'm now invoking the stable-mode skill to start implementing the first stable chore.
 ```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+🎯 Speed Mode Chore Done - Stable Chores Created
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+What we accomplished:
+✅ Happy path scenario passes for this chore
+✅ Stable mode chores created for when speed mode finishes
 
-**Invoke the stable-mode skill:**
+Remaining speed mode chores: [count]
 
-Use the Skill tool to automatically transition to stable mode implementation:
+⚠️  Speed mode is NOT complete yet - [count] chores remain.
+You can take a break here - stable mode chores exist and work can resume.
 
+**Next step:** Continue with next speed mode chore
+  jettypod work start [next-speed-chore-id]
 ```
-Skill tool with skill="stable-mode"
+
+**Mark current chore as done:**
+
+Use Bash tool to commit and push:
+```bash
+git add . && git commit -m "feat: [brief description of what was implemented]" && git push
+```
+
+Then use the merge command to merge to main (which auto-marks chore as done via post-merge hook):
+```bash
+jettypod work merge
 ```
 
-The stable-mode skill will:
-1. Start the first stable chore automatically
-2. Guide implementation to make stable scenarios pass
-3. Continue with remaining stable chores
+The post-merge hook will automatically mark the chore as done when merged to main.
 
-**End speed-mode skill.**
+**End skill.**