jettypod 4.1.5 → 4.1.6

package/lib/worktree-manager.js

@@ -100,9 +100,34 @@ async function createWorktree(workItem, options = {}) {
     });
 
     // Step 2: Create git worktree
-    // Always branch from 'main' to avoid nested worktrees
+    // Branch from the default branch (main, master, etc.) to avoid nested worktrees
     try {
-      execSync(`git worktree add -b "${branchName}" "${worktreePath}" main`, {
+      // Detect the default branch name
+      let defaultBranch;
+      try {
+        // Try to get the default branch from git config
+        defaultBranch = execSync('git symbolic-ref refs/remotes/origin/HEAD', {
+          cwd: gitRoot,
+          encoding: 'utf8',
+          stdio: ['pipe', 'pipe', 'pipe']
+        }).trim().replace('refs/remotes/origin/', '');
+      } catch {
+        // Fallback: check which common branch names exist
+        try {
+          execSync('git rev-parse --verify main', { cwd: gitRoot, stdio: 'pipe' });
+          defaultBranch = 'main';
+        } catch {
+          try {
+            execSync('git rev-parse --verify master', { cwd: gitRoot, stdio: 'pipe' });
+            defaultBranch = 'master';
+          } catch {
+            // Last resort: use HEAD
+            defaultBranch = 'HEAD';
+          }
+        }
+      }
+
+      execSync(`git worktree add -b "${branchName}" "${worktreePath}" ${defaultBranch}`, {
         cwd: gitRoot,
         stdio: 'pipe'
       });

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "jettypod",
-  "version": "4.1.5",
+  "version": "4.1.6",
   "description": "AI-powered development workflow manager with TDD, BDD, and automatic test generation",
   "main": "jettypod.js",
   "bin": {

package/skills-templates/feature-planning/SKILL.md

@@ -113,7 +113,7 @@ After user tests (or skips prototyping):
 Which approach works best?
 ```
 
-User picks winner. Record it.
+User picks winner. Note their choice - you'll record it formally in Step 8 when transitioning to implementation.
 
 ### Step 6: Generate BDD Scenarios AND Step Definitions
 
@@ -239,74 +239,20 @@ console.log(''); // Extra line before continuing
 1. Confirm success with checkmarks
 2. Proceed immediately to Step 6.75
 
-### Step 6.75: Scaffold Unit Test Files
+### Step 6.75: Note About Unit Tests
 
-**CRITICAL:** After BDD validation passes, scaffold empty unit test files for expected implementation files.
+**Unit tests will be created during speed mode implementation**, not during feature planning.
 
-**Execute:**
+The speed-mode skill guides Claude to:
+1. Implement the feature code
+2. Create corresponding unit tests for the happy path
+3. Ensure tests pass before completing the chore
 
-```javascript
-const { scaffoldUnitTestFile } = require('../../lib/unit-test-generator');
-const path = require('path');
-
-console.log('📝 Scaffolding unit test files...\n');
-
-// Infer implementation files from chore breadcrumbs
-// Parse "Files to create/modify" from each proposed chore
-const implementationFiles = [];
-
-// For each chore you're about to propose, extract file paths
-// Example: if chore says "Files to create/modify: src/login.js, src/auth.js"
-// Then implementationFiles = ['src/login.js', 'src/auth.js']
-
-for (const chore of proposedChores) {
-  const filesMatch = chore.description.match(/Files to create\/modify:\s*([^\n]+)/);
-  if (filesMatch) {
-    const files = filesMatch[1].split(',').map(f => f.trim());
-    implementationFiles.push(...files);
-  }
-}
-
-// Remove duplicates
-const uniqueFiles = [...new Set(implementationFiles)];
-
-// Scaffold test files
-const scaffoldedTests = [];
-for (const filePath of uniqueFiles) {
-  if (filePath.endsWith('.js') && !filePath.includes('test')) {
-    try {
-      const testFile = scaffoldUnitTestFile(filePath);
-      scaffoldedTests.push(testFile);
-      console.log(`  ✅ ${testFile}`);
-    } catch (err) {
-      console.log(`  ⚠️  Could not scaffold ${filePath}: ${err.message}`);
-    }
-  }
-}
-
-if (scaffoldedTests.length > 0) {
-  console.log(`\n📦 Scaffolded ${scaffoldedTests.length} unit test files`);
-  console.log('These files have empty TODO placeholders - speed mode will fill them.\n');
-} else {
-  console.log('No new test files to scaffold\n');
-}
-```
-
-**Why scaffold now:**
-- Creates test file structure before implementation
-- Reminds developers tests are required
-- Speed mode can update these TODO placeholders after GREEN
-- Prevents "I'll add tests later" (they never do)
-
-**What gets scaffolded:**
-- Empty `test/[path]/[file].test.js` files
-- Basic `describe()` blocks
-- TODO placeholders for actual tests
-- Won't overwrite existing test files
+This keeps feature planning focused on BDD scenarios (what users experience) while speed mode handles unit tests (implementation details).
 
 ### Step 7: Propose Speed Mode Chores
 
-**CRITICAL:** After BDD validation passes, analyze the codebase and propose technical implementation chores with rich breadcrumbs for speed mode execution.
+**CRITICAL:** After BDD validation passes, analyze the codebase and propose technical implementation chores. **DO NOT CREATE CHORES YET** - the feature must transition to implementation mode first (Step 8).
 
 **Your analysis should consider:**
 - The BDD scenarios (especially the happy path)
@@ -315,7 +261,6 @@ if (scaffoldedTests.length > 0) {
 - Tech stack and framework conventions
 - Which scenario steps each chore addresses
 - Similar code patterns to follow
-- Specific step definitions that should pass
 
 **Say to the user:**
 
@@ -324,7 +269,7 @@ Now let me analyze the codebase and propose implementation chores for speed mode
 
 [Analyze codebase, read relevant files, check patterns]
 
-Based on the scenario and codebase, here are the chores I recommend for speed mode:
+Based on the scenario and my understanding of the codebase, here are the chores I recommend for speed mode:
 
 **Chore 1: [Technical task title]**
 - Why: [What this accomplishes toward the scenario]
@@ -335,7 +280,7 @@ Based on the scenario and codebase, here are the chores I recommend for speed mo
   • Patterns to follow: [reference existing similar code]
   • Key functions/components needed: [list]
 - Verification:
-  • Step definitions that should pass: [specific steps from .steps.js]
+  • [Which step definitions should pass]
 
 **Chore 2: [Technical task title]**
 - Why: [What this accomplishes]
@@ -346,7 +291,7 @@ Based on the scenario and codebase, here are the chores I recommend for speed mo
   • Patterns to follow: [references]
   • Key functions/components needed: [list]
 - Verification:
-  • Step definitions that should pass: [steps]
+  • [Which steps should pass]
 
 [etc.]
 
@@ -355,107 +300,7 @@ These chores will make the happy path scenario pass.
 Sound good? Any adjustments?
 ```
 
-**Wait for user confirmation/adjustments.**
-
-**Then create the chores with rich descriptions:**
-
-```javascript
-// Import breadcrumb generators
-const { parseStepDefinitions } = require('../../lib/step-definition-parser');
-const { findSimilarPatterns } = require('../../lib/pattern-finder');
-const { generateVerificationCommands } = require('../../lib/verification-command-generator');
-const { create } = require('./features/work-tracking');
-const path = require('path');
-
-// Parse step definitions for verification breadcrumbs
-const stepDefsPath = path.join(process.cwd(), 'features/step_definitions', `${featureSlug}.steps.js`);
-const stepMap = parseStepDefinitions(stepDefsPath);
-
-// For each confirmed chore:
-for (const chore of confirmedChores) {
-  // Find similar patterns for implementation guidance
-  const patterns = findSimilarPatterns(chore.keywords || []);
-
-  // Build pattern references
-  const patternRefs = patterns.length > 0
-    ? patterns.map(p => `${p.file} (${p.description})`).join('\n  • ')
-    : 'No similar patterns found - create new implementation';
-
-  // Build step definition references with file:line
-  const stepRefs = chore.steps
-    .map(stepText => {
-      const stepInfo = stepMap.get(stepText);
-      if (stepInfo) {
-        return `${path.basename(stepInfo.file)}:${stepInfo.lineNumber} - "${stepText}"`;
-      }
-      return `"${stepText}" (not yet implemented)`;
-    })
-    .join('\n  • ');
-
-  // Generate verification command for the chore's scenario
-  const verification = generateVerificationCommands(
-    `features/${featureSlug}.feature`,
-    chore.scenarioLine
-  );
-
-  const description = `${chore.technicalDescription}
-
-Scenario steps addressed:
-${chore.scenarioSteps.map(s => `• ${s}`).join('\n')}
-
-Implementation guidance:
-• Files to create/modify: ${chore.files.join(', ')}
-• Patterns to follow:
-  • ${patternRefs}
-• Key functions/components needed: ${chore.components.join(', ')}
-
-Verification:
-• Step definitions that should pass:
-  • ${stepRefs}
-• Test command: ${verification.command}
-• Scenario: ${verification.scenarioName}`;
-
-  await create('chore', chore.title, description, featureId, 'speed', false);
-}
-```
-
-**Example chore description (with breadcrumb generators):**
-
-```
-Build login form component with email/password fields
-
-Scenario steps addressed:
-• Given I am on the login page
-• When I enter valid credentials and submit
-
-Implementation guidance:
-• Files to create/modify: src/components/LoginForm.jsx
-• Patterns to follow:
-  • src/components/SignupForm.jsx (Functions: handleSubmit, validateEmail)
-  • lib/validation.js (Functions: validateEmailFormat, validatePassword)
-• Key functions/components needed: EmailInput, PasswordInput, SubmitButton
-
-Verification:
-• Step definitions that should pass:
-  • login.steps.js:15 - "I am on the login page"
-  • login.steps.js:23 - "I enter valid credentials and submit"
-• Test command: npm run test:bdd -- features/login.feature:8
-• Scenario: User successfully logs in with valid credentials
-```
-
-**Report:**
-```
-✅ Created X chores for speed mode
-
-Each chore includes automated breadcrumbs from:
-• Step definition parser - Exact file:line references for verification
-• Pattern finder - Similar code patterns to follow
-• Verification command generator - Ready-to-run test commands
-• Scenario steps addressed
-• Implementation guidance with file paths
-
-Ready to start implementation: jettypod work start [first-chore-id]
-```
+**Wait for user confirmation/adjustments, then proceed to Step 8.**
 
 ### Step 8: Transition to Implementation
 
@@ -482,8 +327,8 @@ Does this rationale capture why you chose this approach? (You can edit it if nee
 
 **CRITICAL: After user confirms, use Bash tool to EXECUTE the work implement command:**
 
-```javascript
-// Use Bash tool to execute:
+```bash
+# Use Bash tool to execute:
 node jettypod.js work implement [feature-id] \
   --winner="[approach-name or prototypes/winner-file]" \
   --rationale="[user's confirmed/edited rationale]"
@@ -491,10 +336,39 @@ node jettypod.js work implement [feature-id] \
 
 **DO NOT display this as example text. EXECUTE IT using the Bash tool.**
 
-After execution succeeds, verify the feature transitioned to implementation phase and display:
+#### Step 8C: Create the Chores
+
+**CRITICAL: NOW create the chores.** The feature has transitioned to implementation mode, so chore creation will succeed.
+
+For each chore that the user confirmed in Step 7, use the Bash tool to create it:
+
+```bash
+# Use Bash tool to execute for each chore:
+node jettypod.js work create chore "[Chore title]" "[Chore description with all the implementation guidance]" --parent=[feature-id]
+```
+
+**Build the description from your Step 7 proposal:**
+```
+[Technical description]
+
+Scenario steps addressed:
+• [Step 1]
+• [Step 2]
+
+Implementation guidance:
+• Files to create/modify: [paths]
+• Patterns to follow: [references]
+• Key functions/components needed: [list]
+
+Verification:
+• [Which step definitions should pass]
+```
+
+After creating all chores, display:
 
 ```
 ✅ Feature transitioned to implementation phase
+✅ Created X chores for speed mode
 
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 🎯 Feature Discovery Complete!
@@ -508,7 +382,7 @@ After execution succeeds, verify the feature transitioned to implementation phas
 Ready to start implementation?
 ```
 
-#### Step 8C: Transition to Speed Mode
+#### Step 8D: Transition to Speed Mode
 
 **WAIT for user confirmation.**
 
@@ -516,8 +390,8 @@ When user confirms they want to proceed with implementation (responds with "yes"
 
 **IMMEDIATELY invoke the speed-mode skill using the Skill tool:**
 
-```javascript
-Skill("speed-mode")
+```
+Use the Skill tool with skill: "speed-mode"
 ```
 
 **The speed-mode skill will then:**
@@ -610,7 +484,7 @@ Scenario: Prevent unauthorized access
 
 **User picks:** Option 1 (Simple inline form)
 
-**Scenarios generated:**
+**Scenarios generated (happy path only for speed mode):**
 ```gherkin
 Feature: Email/Password Login
 
@@ -620,11 +494,8 @@ Scenario: Successful login
   Then I am redirected to the dashboard
   And I have an active JWT token
 
-Scenario: Invalid credentials
-  Given I am on the login page
-  When I enter invalid credentials
-  Then I see an error message
-  And I remain on the login page
+# SPEED MODE: Only happy path above
+# STABLE MODE: Will add error handling scenarios like "Invalid credentials"
 ```
 
 **Rationale confirmation:**

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

@@ -33,7 +33,7 @@ When this skill is activated, you are helping implement a speed mode chore to ma
 - **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
-- **Pragmatic** - localStorage for data, simple implementations
+- **Use real infrastructure** - use the actual database/storage from your tech stack, not mocks
 - **Autonomous execution** - Claude Code writes code, user confirms approach
 
 **User Profile:** May not know how to code - Claude Code does the implementation autonomously.
@@ -52,7 +52,7 @@ When this skill is activated, you are helping implement a speed mode chore to ma
 **Where Claude Code executes autonomously:**
 - Step 1: Scenario analysis
 - Step 2: Codebase analysis
-- Step 3 Phase 2: RED→GREEN iteration loop
+- Step 3 Phase 2: RED→GREEN→REFACTOR loop
 - Step 4 Phases 3-4: Create chores and elevate
 
 ---
@@ -569,13 +569,33 @@ Modified src/dashboard.js
 - **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
-- **localStorage/memory for data** - no full database setup
+- **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)
 
-**Step 3: Final Verification and Completion**
+**Step 3: REFACTOR**
 
-After GREEN is achieved, run full feature file once to verify no regressions:
+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
+
+**Keep it fast** - 5 minutes max. Major refactoring happens in stable mode.
+
+**Re-run tests after refactoring** to ensure nothing broke:
+
+```javascript
+const result = await runBddScenarioWithTimeout(feature.scenario_file, scenarioLine);
+if (result.exitCode !== 0) {
+  console.log('⚠️  Refactoring broke tests - revert and try again');
+}
+```
+
+**Step 4: Final Verification and Completion**
+
+After GREEN + REFACTOR, run full feature file once to verify no regressions:
 
 ```javascript
 // After iteration loop succeeds (GREEN achieved)
@@ -630,8 +650,32 @@ if (filesModified.length > 0) {
   console.log();
 }
 
-// Note: Unit tests should be added during stable mode implementation
-// Speed mode focuses on proving the happy path works
+// --- Create unit tests for new functions ---
+// For each new function implemented, create a unit test file with happy path coverage
+
+// Unit test template for new functions:
+// test/[filename].test.js or __tests__/[filename].test.js
+/*
+const { functionName } = require('../src/path/to/module');
+
+describe('functionName', () => {
+  it('should handle valid input successfully', () => {
+    // Arrange
+    const input = validTestData;
+
+    // Act
+    const result = functionName(input);
+
+    // Assert
+    expect(result).toEqual(expectedOutput);
+  });
+});
+*/
+
+// Speed mode unit tests focus on:
+// - Happy path with valid input
+// - One successful operation per function
+// - Basic return value verification
 
 console.log(`Next step: Elevate to stable mode using 'jettypod work set-mode <feature-id> stable'\n`);
 ```