jettypod 4.1.1 → 4.1.3

package/.devpod/current-work.json

@@ -0,0 +1,10 @@
+{
+  "id": 2,
+  "title": "Second Item",
+  "type": "feature",
+  "status": "in_progress",
+  "parent_id": null,
+  "parent_title": null,
+  "epic_id": null,
+  "epic_title": null
+}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "jettypod",
-  "version": "4.1.1",
+  "version": "4.1.3",
   "description": "Simplified development mode manager",
   "main": "jettypod.js",
   "bin": {
@@ -11,7 +11,8 @@
     "test:bdd": "NODE_ENV=test cucumber-js",
     "test:unit": "NODE_ENV=test jest",
     "test:unit:watch": "NODE_ENV=test jest --watch",
-    "test:cleanup": "node -e \"const fs = require('fs'); const path = require('path'); const testDb = path.join(process.cwd(), '.jettypod', 'test-work.db'); if (fs.existsSync(testDb)) { fs.unlinkSync(testDb); console.log('✅ Cleaned up test database'); }\""
+    "test:cleanup": "node -e \"const fs = require('fs'); const path = require('path'); const testDb = path.join(process.cwd(), '.jettypod', 'test-work.db'); if (fs.existsSync(testDb)) { fs.unlinkSync(testDb); console.log('✅ Cleaned up test database'); }\"",
+    "prepublishOnly": "echo '🔄 Syncing skills to templates...' && cp -r .claude/skills/* skills-templates/ && echo '✅ Skills synced'"
   },
   "devDependencies": {
     "@cucumber/cucumber": "^10.0.1",

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

@@ -580,12 +580,12 @@ Implementation complete:
 • All scenarios: ✅ Passing
 ```
 
-### Step 4: Check for Stable Mode Completion and Auto-Elevate
+### Step 4: Check for Production Mode (When All Stable Chores Complete)
 
-**CRITICAL: After completing a stable mode chore, check if ALL stable chores are done. If yes, trigger production chore generation or elevate to production mode.**
+**CRITICAL: This step ONLY happens when ALL stable chores for the feature are complete. Otherwise skip to marking chore as done.**
 
+**Check completion status and project state:**
 ```javascript
-// Check if all stable chores for this feature are done
 const { getDb } = require('../../lib/database');
 const { getCurrentWork } = require('../../lib/current-work');
 
@@ -598,56 +598,82 @@ db.get(`
   FROM work_items
   WHERE parent_id = ?
     AND type = 'chore'
-    AND mode = 'stable'
-    AND status != 'done'
-`, [featureId], async (err, result) => {
-  if (err) {
-    console.error('Error checking stable chores:', err.message);
-    db.close();
-    return;
-  }
-
+    AND status NOT IN ('done', 'cancelled')
+`, [featureId], (err, result) => {
   if (result.incomplete_count === 0) {
-    // All stable chores done!
-    console.log('\n✅ ALL STABLE MODE CHORES COMPLETE!');
-    console.log('Checking project state for production chore generation...\n');
-
-    // NOTE: The production chore generation logic is now handled by
-    // features/work-commands/index.js in the stopWork() function
-    // when a stable mode chore is marked as done.
-    //
-    // This will trigger automatically - no action needed here.
-    // The system will:
-    // 1. Analyze implementation files
-    // 2. Propose production chores
-    // 3. Ask for confirmation
-    // 4. Create production chores
-    // 5. Elevate feature to production mode
+    // All stable chores done - check project state
+    db.get('SELECT project_state FROM project_config WHERE id = 1', (err, config) => {
+      const projectState = config?.project_state || 'internal';
+
+      if (projectState === 'internal') {
+        // Internal project - stable mode is complete
+        console.log('Internal project - no production mode needed');
+      } else {
+        // External project - invoke production-mode skill
+        console.log('External project - auto-generating production chores from standards');
+      }
+    });
   } else {
+    // More chores remain - just mark this one done
     console.log(`\n📋 ${result.incomplete_count} stable mode chores remaining`);
   }
-
   db.close();
 });
 ```
 
-**Display based on completion status:**
+**If all stable chores are done AND project is INTERNAL:**
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+✅ FEATURE COMPLETE!
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+What we accomplished:
+✅ All BDD scenarios passing (happy path + error handling + edge cases)
+✅ Comprehensive error handling and validation
+✅ Feature stable and ready to use
+
+This is an internal project - no production hardening needed.
+
+If you later transition to external state, production chores will be
+automatically generated from production standards.
+```
+
+**If all stable chores are done AND project is EXTERNAL:**
+
+Use the Skill tool to invoke the production-mode skill:
 
-**If all stable chores done:**
+```javascript
+// Use Skill tool to invoke: production-mode
+// The production-mode skill will:
+// 1. Detect feature context (Scenario A/B/C)
+// 2. Generate production scenarios from standards
+// 3. Append scenarios to feature file
+// 4. Create production chores
+```
+
+Display to user:
 
 ```
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-🎯 Stable Mode Complete!
+✅ ALL STABLE MODE CHORES COMPLETE!
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
 What we accomplished:
 ✅ All BDD scenarios passing (happy path + error handling + edge cases)
-✅ Comprehensive error handling
-✅ Input validation
-✅ All stable mode chores complete
+✅ Comprehensive error handling and validation
+✅ Feature stable and ready for production hardening
+
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+🚀 AUTO-GENERATING PRODUCTION CHORES
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+This project is external - invoking production-mode skill to:
+  • Detect feature context (authentication/data/general)
+  • Generate production scenarios from standards
+  • Create production chores with proper scope
 
-The system will now analyze the implementation and propose production chores.
-This happens automatically via the work tracking system.
+[Invoke production-mode skill - it handles the rest autonomously]
 ```
 
 **If stable chores remain:**

package/test-tmp/{external-transition-1762982858258 → external-transition-1762983159050}/.claude/skills/stable-mode/SKILL.md

@@ -580,12 +580,12 @@ Implementation complete:
 • All scenarios: ✅ Passing
 ```
 
-### Step 4: Check for Stable Mode Completion and Auto-Elevate
+### Step 4: Check for Production Mode (When All Stable Chores Complete)
 
-**CRITICAL: After completing a stable mode chore, check if ALL stable chores are done. If yes, trigger production chore generation or elevate to production mode.**
+**CRITICAL: This step ONLY happens when ALL stable chores for the feature are complete. Otherwise skip to marking chore as done.**
 
+**Check completion status and project state:**
 ```javascript
-// Check if all stable chores for this feature are done
 const { getDb } = require('../../lib/database');
 const { getCurrentWork } = require('../../lib/current-work');
 
@@ -598,56 +598,82 @@ db.get(`
   FROM work_items
   WHERE parent_id = ?
     AND type = 'chore'
-    AND mode = 'stable'
-    AND status != 'done'
-`, [featureId], async (err, result) => {
-  if (err) {
-    console.error('Error checking stable chores:', err.message);
-    db.close();
-    return;
-  }
-
+    AND status NOT IN ('done', 'cancelled')
+`, [featureId], (err, result) => {
   if (result.incomplete_count === 0) {
-    // All stable chores done!
-    console.log('\n✅ ALL STABLE MODE CHORES COMPLETE!');
-    console.log('Checking project state for production chore generation...\n');
-
-    // NOTE: The production chore generation logic is now handled by
-    // features/work-commands/index.js in the stopWork() function
-    // when a stable mode chore is marked as done.
-    //
-    // This will trigger automatically - no action needed here.
-    // The system will:
-    // 1. Analyze implementation files
-    // 2. Propose production chores
-    // 3. Ask for confirmation
-    // 4. Create production chores
-    // 5. Elevate feature to production mode
+    // All stable chores done - check project state
+    db.get('SELECT project_state FROM project_config WHERE id = 1', (err, config) => {
+      const projectState = config?.project_state || 'internal';
+
+      if (projectState === 'internal') {
+        // Internal project - stable mode is complete
+        console.log('Internal project - no production mode needed');
+      } else {
+        // External project - invoke production-mode skill
+        console.log('External project - auto-generating production chores from standards');
+      }
+    });
   } else {
+    // More chores remain - just mark this one done
     console.log(`\n📋 ${result.incomplete_count} stable mode chores remaining`);
   }
-
   db.close();
 });
 ```
 
-**Display based on completion status:**
+**If all stable chores are done AND project is INTERNAL:**
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+✅ FEATURE COMPLETE!
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+What we accomplished:
+✅ All BDD scenarios passing (happy path + error handling + edge cases)
+✅ Comprehensive error handling and validation
+✅ Feature stable and ready to use
+
+This is an internal project - no production hardening needed.
+
+If you later transition to external state, production chores will be
+automatically generated from production standards.
+```
+
+**If all stable chores are done AND project is EXTERNAL:**
+
+Use the Skill tool to invoke the production-mode skill:
 
-**If all stable chores done:**
+```javascript
+// Use Skill tool to invoke: production-mode
+// The production-mode skill will:
+// 1. Detect feature context (Scenario A/B/C)
+// 2. Generate production scenarios from standards
+// 3. Append scenarios to feature file
+// 4. Create production chores
+```
+
+Display to user:
 
 ```
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-🎯 Stable Mode Complete!
+✅ ALL STABLE MODE CHORES COMPLETE!
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
 What we accomplished:
 ✅ All BDD scenarios passing (happy path + error handling + edge cases)
-✅ Comprehensive error handling
-✅ Input validation
-✅ All stable mode chores complete
+✅ Comprehensive error handling and validation
+✅ Feature stable and ready for production hardening
+
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+🚀 AUTO-GENERATING PRODUCTION CHORES
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+This project is external - invoking production-mode skill to:
+  • Detect feature context (authentication/data/general)
+  • Generate production scenarios from standards
+  • Create production chores with proper scope
 
-The system will now analyze the implementation and propose production chores.
-This happens automatically via the work tracking system.
+[Invoke production-mode skill - it handles the rest autonomously]
 ```
 
 **If stable chores remain:**

package/test-tmp/external-transition-1762983159304/.claude/settings.json

@@ -0,0 +1,24 @@
+{
+  "hooks": {
+    "PreToolUse": [
+      {
+        "matcher": "Edit",
+        "hooks": [
+          {
+            "type": "command",
+            "command": ".jettypod/hooks/protect-claude-md.js"
+          }
+        ]
+      },
+      {
+        "matcher": "Write",
+        "hooks": [
+          {
+            "type": "command",
+            "command": ".jettypod/hooks/protect-claude-md.js"
+          }
+        ]
+      }
+    ]
+  }
+}

package/test-tmp/external-transition-1762983159304/.claude/skills/epic-planning/SKILL.md

@@ -0,0 +1,297 @@
+---
+name: epic-planning
+description: Guide epic planning with feature brainstorming and optional architectural decision prototyping. Use when user asks to plan an epic, mentions planning features for an epic, says "help me plan epic", or when they just created an epic and want to break it down into features.
+---
+
+# Epic Planning Skill
+
+Guides Claude through comprehensive epic planning including feature identification and architectural decisions.
+
+## Instructions
+
+When this skill is activated, you are helping plan an epic. Follow this structured approach:
+
+### Step 1: Understand the Epic
+
+You'll receive context about the epic being planned. Review:
+- Epic title and description
+- Project context
+- Any parent context
+
+### Step 2: Check Existing Features and Decisions
+
+**CRITICAL:** Before suggesting features or approaches, check what already exists:
+
+**Check for existing features:**
+```bash
+node jettypod.js backlog | grep -A 20 "Epic Name"
+```
+
+If features already exist, acknowledge them and skip to Step 4 (Architectural Decision).
+
+**Check for existing decisions:**
+```bash
+node -e "const { showDecisionsForEpic } = require('./features/decisions/index.js'); showDecisionsForEpic(epicId)"
+```
+
+If decisions exist, present them to the user:
+
+```
+🎯 **Existing Architectural Decisions for This Epic:**
+
+[For each decision:]
+- **[Aspect]:** [Decision]
+  *Rationale:* [Why this was chosen]
+  *Decided:* [Date]
+
+These decisions were made previously. Before we continue:
+1. Do these decisions still apply?
+2. Should we revisit any of them?
+3. Are there additional aspects we need to decide?
+```
+
+Only proceed with suggesting new architectural options if:
+- No decisions exist yet, OR
+- User confirms decisions need to be revisited, OR
+- User identifies new aspects to decide
+
+### Step 3: Brainstorm Features (Skip if Features Already Exist)
+
+Based on the epic's purpose, suggest features that belong in this epic:
+
+```
+I'll help you plan the features for this epic.
+
+Based on [epic name], here are the features I recommend:
+
+**Feature 1: [Name]** - [Brief description of what users can do]
+**Feature 2: [Name]** - [Brief description]
+**Feature 3: [Name]** - [Brief description]
+...
+
+**Questions:**
+- [Any clarifying questions about scope]
+- [Missing features to consider]
+
+What features should we include? What am I missing?
+```
+
+### Step 4: Architectural Decision (Optional)
+
+After features are defined, ask if this epic needs a shared technical approach:
+
+```
+**Architectural question:** Does this epic need a shared technical decision?
+
+For example:
+- Which library/framework for this capability?
+- What data structure or protocol?
+- What architectural pattern?
+
+Examples where architectural decisions matter:
+- Real-time features: WebSockets vs SSE vs polling?
+- Auth system: Which auth library and token strategy?
+- Data sync: Optimistic vs pessimistic locking?
+
+Should we explore different architectural approaches?
+```
+
+### Step 5A: If Architectural Decision Needed
+
+If the epic needs architectural decision, suggest exactly 3 approaches:
+
+```
+Here are 3 different architectural approaches for [epic name]:
+
+**Option 1: [Simple/Conservative approach name]**
+- **Pros**: ✅ [2-3 advantages - proven, reliable, fast to implement]
+- **Cons**: ❌ [2-3 trade-offs - limitations, constraints]
+- **Technical Impact**: [How this affects the features in this epic]
+
+**Option 2: [Balanced approach name]**
+- **Pros**: ✅ [2-3 advantages - good balance]
+- **Cons**: ❌ [2-3 trade-offs]
+- **Technical Impact**: [How this affects the features in this epic]
+
+**Option 3: [Advanced/Modern approach name]**
+- **Pros**: ✅ [2-3 advantages - powerful, flexible]
+- **Cons**: ❌ [2-3 trade-offs - complexity, learning curve]
+- **Technical Impact**: [How this affects the features in this epic]
+
+**Additional approaches considered but not recommended:**
+- *[Alternative 1]*: [Brief] - Not selected because [reason]
+- *[Alternative 2]*: [Brief] - Not selected because [reason]
+
+Would you like me to create working prototypes of these architectural approaches?
+```
+
+### Step 5B: If Prototyping Needed
+
+If user wants to prototype approaches:
+
+1. Build 2-3 prototype approaches in `/prototypes/epic-[id]-[approach-name]/`
+2. Each prototype should demonstrate the architectural difference
+3. **Add prototype header**:
+   ```
+   // Prototype: Epic [epic-id] - [approach name]
+   // Created: [date]
+   // Purpose: Demonstrate [architectural aspect]
+   // Decision: [to be filled after testing]
+   ```
+4. After user tests, help them choose the winner
+5. Document the decision and rationale
+
+### Step 5C: If Approach Already Known
+
+If user already knows the approach or skips prototyping:
+
+```
+Which architectural approach works best for this epic?
+```
+
+Then record their decision.
+
+### Step 6: Create Features and Complete Discovery
+
+Once features are defined and architectural decision is made (if needed):
+
+**CRITICAL: You must EXECUTE commands using the Bash tool. Do NOT just display them as text.**
+
+#### Step 6A: Create Features
+
+Use the Bash tool to create each feature:
+
+```javascript
+// For each feature, use Bash tool to execute:
+node jettypod.js work create feature "[Feature 1]" "[Description]" --parent=[epic-id]
+node jettypod.js work create feature "[Feature 2]" "[Description]" --parent=[epic-id]
+// etc.
+```
+
+Display to user as you create each one:
+```
+Creating features...
+✅ Created Feature #123: [Feature 1]
+✅ Created Feature #456: [Feature 2]
+```
+
+#### Step 6B: Record Architectural Decision (if applicable)
+
+If an architectural decision was made, propose the rationale to the user:
+
+```
+I'm going to record this architectural decision:
+
+Aspect: Architecture
+Decision: [architectural approach chosen]
+Rationale: [why this approach was selected]
+
+Does this rationale capture why you chose this approach? (You can edit it if needed)
+```
+
+**WAIT for user to confirm or provide edited rationale.**
+
+**CRITICAL: After user confirms, use Bash tool to EXECUTE the epic-implement command:**
+
+```javascript
+// Use Bash tool to execute:
+node jettypod.js work epic-implement [epic-id] \
+  --aspect="Architecture" \
+  --decision="[architectural approach chosen]" \
+  --rationale="[user's confirmed/edited rationale]"
+```
+
+**DO NOT display this as example text. EXECUTE IT using the Bash tool.**
+
+After execution succeeds, verify the decision was recorded and display:
+
+```
+✅ Architectural decision recorded
+
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+🎯 Epic Planning Complete!
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+Features created: [count]
+Architectural decision: Recorded
+
+**Next step:** Plan your first feature
+Run: jettypod work discover [feature-id]
+Or talk to Claude Code: "Let's do feature discovery for #[feature-id]"
+```
+
+## Key Principles
+
+1. **Feature brainstorming is always required** - Don't skip this even if architectural decision is clear
+2. **Architectural decision is optional** - Not all epics need one (e.g., "Q1 Goals" is just grouping)
+3. **Always suggest exactly 3 options** when architectural decision needed - Simple/Conservative, Balanced, Advanced
+4. **Be specific about features** - Each feature should be user-facing capability
+5. **Use the Approach Suggestion template** - Pros, Cons, Technical Impact format
+6. **Suggest next step** - Always end with clear guidance on what to do next
+7. **Use jettypod commands** - Create features using jettypod CLI, record decisions with epic-implement
+
+## Example: Epic with Architectural Decision
+
+Epic: "Real-time Collaboration"
+
+**Features brainstormed:**
+- Live cursor tracking
+- Concurrent editing with conflict resolution
+- Presence indicators
+- Real-time chat
+
+**Architectural approaches suggested:**
+
+**Option 1: Long Polling (REST)**
+- **Pros**: ✅ Simple, works with all proxies, uses existing HTTP infrastructure
+- **Cons**: ❌ Higher latency (1-2s), more server load, inefficient for high-frequency updates
+- **Technical Impact**: Each feature polls independently, easy to implement per feature
+
+**Option 2: Server-Sent Events (SSE)**
+- **Pros**: ✅ Lightweight, auto-reconnection, efficient one-way streaming
+- **Cons**: ❌ One-direction only (server→client), limited browser connections (6 per domain)
+- **Technical Impact**: Good for cursor/presence, requires separate POST for edits
+
+**Option 3: WebSockets (Socket.io)**
+- **Pros**: ✅ Bidirectional, low latency (<100ms), perfect for real-time, fallback support
+- **Cons**: ❌ More complex infrastructure, requires sticky sessions, WebSocket proxies needed
+- **Technical Impact**: All features use unified connection, best UX but infrastructure complexity
+
+**Additional approaches considered:**
+- *WebRTC Data Channels*: Peer-to-peer, low latency - Not selected due to NAT/firewall traversal complexity
+- *GraphQL Subscriptions*: Good for selective updates - Not selected as overkill for this use case
+
+**User choice:** Option 3 (WebSockets with Socket.io)
+
+**Rationale confirmation:**
+Claude proposes: "Bidirectional real-time updates needed for collaboration, Socket.io provides fallbacks and auto-reconnection"
+User confirms: "Yes, that's right"
+
+**Command run:**
+```bash
+jettypod work epic-implement 5 \
+  --aspect="Architecture" \
+  --decision="WebSockets with Socket.io" \
+  --rationale="Bidirectional real-time updates needed for collaboration, Socket.io provides fallbacks and auto-reconnection"
+```
+
+## Example: Epic without Architectural Decision
+
+Epic: "User Management"
+
+**Features brainstormed:**
+- User registration
+- Profile editing
+- Password reset
+- Account deletion
+
+**Architectural decision:** None needed - these are independent features using existing auth system
+
+## Validation
+
+Before completing epic discovery, ensure:
+- [ ] At least 2-3 features identified
+- [ ] Features are user-facing capabilities (not technical tasks)
+- [ ] Architectural decision documented if needed
+- [ ] Features created in database
+- [ ] User knows next step .jettypod work discover [feature-id])