jettypod 4.4.90 → 4.4.92

package/apps/dashboard/components/PlaceholderCard.tsx

@@ -23,6 +23,7 @@ export function PlaceholderCard({ height, minHeight = DEFAULT_MIN_HEIGHT }: Plac
         borderRadius: 8,
         border: '2px dashed rgba(100, 116, 139, 0.4)',
         backgroundColor: 'rgba(100, 116, 139, 0.1)',
+        marginTop: 8,
         marginBottom: 8,
       }}
     />

package/jettypod.js

@@ -245,16 +245,32 @@ Status: ${currentWork.status}
 <jettypod_essentials>
 JettyPod: Structured workflow system with skills that guide complex workflows.
 
-## ⚠️ CRITICAL: All Work Requires a Work Item
-**Claude CANNOT write code directly to main branch.**
-- All work requires: \`work create\` → \`work start\` → skill workflow → \`work merge\`
-- If user asks to implement something without a work item, create one first and invoke the matching skill
-- Pre-commit hooks block direct commits to main
+## ⚠️ CRITICAL: All Work Starts with request-routing
+
+**WHY:** request-routing creates a safe workspace (worktree) where your changes can actually be committed. Without it, you'll edit files on main, then discover the pre-commit hook blocks you—leaving uncommitted changes that can't be saved.
+
+**FIRST RESPONSE RULE:** If user describes ANY code change, your FIRST action must be invoking request-routing. Not after reading files. Not after understanding the problem. FIRST.
+
+**Trigger phrases → invoke request-routing immediately:**
+- "we should...", "let's...", "can you..." (implementation requests)
+- "fix", "broken", "not working", "bug" (bug reports)
+- "add", "build", "create", "implement" (feature requests)
+- "refactor", "migrate", "upgrade" (technical work)
+- "I noticed...", "I'm thinking..." (when followed by desired change)
+
+**⚠️ ANTI-PATTERN: Do NOT edit files before invoking request-routing.**
+Wrong: See problem → edit files → realize you're on main → ask about workflow
+Wrong: Read files → understand problem → try to fix → get blocked → create work item
+Right: User describes work → invoke request-routing → skill creates worktree → then edit
 
 ## ⚠️ CRITICAL: Skills are MANDATORY for workflows
 Skills auto-activate and MUST complete their full workflow:
-- epic-planning: Guides architectural decisions
-- feature-planning: Guides UX discovery + BDD scenarios
+- **request-routing**: ⚡ ENTRY POINT - routes ALL work requests to correct skill
+- epic-planning: Guides architectural decisions (invoked by request-routing)
+- feature-planning: Guides UX discovery + BDD scenarios (invoked by request-routing)
+- chore-planning: Guides technical work planning (invoked by request-routing)
+- bug-planning: Guides bug investigation (invoked by request-routing)
+- simple-improvement: Direct implementation for obvious changes (invoked by request-routing)
 - speed-mode: Implements happy path, THEN auto-invokes stable-mode
 - stable-mode: Adds error handling to speed implementation
 - external-transition: Guides launch preparation

package/lib/work-commands/index.js

@@ -1367,14 +1367,17 @@ async function mergeWork(options = {}) {
   try {
     // Get feature branch - either passed explicitly, from worktree DB, or from current CWD
     let currentBranch;
+    // Track worktree path for uncommitted changes check
+    let worktreePath = null;
+
     if (featureBranch) {
       // Branch passed from caller (e.g., status transition with worktree)
       currentBranch = featureBranch;
     } else if (workItemId) {
-      // Explicit work item ID - look up branch from worktrees table
+      // Explicit work item ID - look up branch AND worktree_path from worktrees table
       const worktreeRecord = await new Promise((resolve, reject) => {
         db.get(
-          `SELECT branch_name FROM worktrees WHERE work_item_id = ? AND status = 'active'`,
+          `SELECT branch_name, worktree_path FROM worktrees WHERE work_item_id = ? AND status = 'active'`,
           [workItemId],
           (err, row) => {
             if (err) return reject(err);
@@ -1389,6 +1392,7 @@ async function mergeWork(options = {}) {
         ));
       }
       currentBranch = worktreeRecord.branch_name;
+      worktreePath = worktreeRecord.worktree_path;
     } else {
       // Detect from current branch in CWD
       try {
@@ -1408,6 +1412,61 @@ async function mergeWork(options = {}) {
       if (currentBranch === 'main' || currentBranch === 'master') {
         return Promise.reject(new Error('Already on main branch. Cannot merge from main to main.'));
       }
+
+      // If we were running from inside a worktree, capture that path
+      if (cwd.includes('.jettypod-work')) {
+        worktreePath = cwd;
+      }
+    }
+
+    // CRITICAL SAFETY CHECK: Verify worktree has no uncommitted changes
+    // This prevents silent data loss when user forgets to commit their work
+    if (worktreePath) {
+      const fs = require('fs');
+      if (fs.existsSync(worktreePath)) {
+        try {
+          const worktreeStatus = execSync('git status --porcelain', {
+            cwd: worktreePath,
+            encoding: 'utf8',
+            stdio: 'pipe'
+          }).trim();
+
+          if (worktreeStatus) {
+            const lines = worktreeStatus.split('\n');
+            const staged = lines.filter(line => /^[MADRC]/.test(line));
+            const unstaged = lines.filter(line => /^.[MD]/.test(line));
+            const untracked = lines.filter(line => /^\?\?/.test(line));
+
+            // Block on any changes (staged, unstaged, or untracked)
+            if (staged.length > 0 || unstaged.length > 0 || untracked.length > 0) {
+              let errorDetails = `\n❌ UNCOMMITTED CHANGES IN WORKTREE - MERGE BLOCKED\n\n`;
+              errorDetails += `Worktree: ${worktreePath}\n`;
+
+              if (staged.length > 0) {
+                errorDetails += `\nStaged files (${staged.length}):\n${staged.map(l => '  ' + l).join('\n')}`;
+              }
+              if (unstaged.length > 0) {
+                errorDetails += `\n\nUnstaged changes (${unstaged.length}):\n${unstaged.map(l => '  ' + l).join('\n')}`;
+              }
+              if (untracked.length > 0) {
+                errorDetails += `\n\nUntracked files (${untracked.length}):\n${untracked.map(l => '  ' + l).join('\n')}`;
+              }
+
+              errorDetails += `\n\n⚠️  YOUR WORK WILL BE LOST if you merge without committing!\n\n`;
+              errorDetails += `To save your work, run:\n`;
+              errorDetails += `  cd "${worktreePath}"\n`;
+              errorDetails += `  git add -A && git commit -m "your message"\n\n`;
+              errorDetails += `Then retry:\n`;
+              errorDetails += `  jettypod work merge ${currentWork.id}`;
+
+              return Promise.reject(new Error(errorDetails));
+            }
+          }
+        } catch (statusErr) {
+          // If we can't check status, warn but continue (worktree may be corrupted)
+          console.warn(`⚠️  Warning: Could not check worktree status: ${statusErr.message}`);
+        }
+      }
     }
 
     // Check for uncommitted changes

package/package.json

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

package/skills-templates/request-routing/SKILL.md

@@ -42,7 +42,9 @@ From the user's request, identify work type and complexity signals:
 | "quick", "small", "just", "simple", "tweak" | Lower complexity |
 | "feature", "workflow", "experience", "redesign" | Higher complexity |
 | References specific file/function | Lower complexity |
-| Describes user-facing behavior change | Higher complexity |
+| Has edge cases to consider (validation, failures, states) | Higher complexity |
+| Could fail in interesting ways | Higher complexity |
+| Needs error handling design | Higher complexity |
 
 ### Step 2: Gather Context (Silent - No Questions)
 
@@ -86,13 +88,19 @@ Does this need UX exploration?
      ├─► Yes → feature-planning
      │
      ▼
+Are there edge cases to consider?
+(Validation? Error states? Things that could fail? Multiple outcomes?)
+     ├─► Yes → feature-planning
+     │         (The speed→stable split helps: make it work, then handle edge cases)
+     │
+     ▼
 Is this substantial technical work?
 (Refactoring, infrastructure, migrations, multi-file changes)
      ├─► Yes → chore-planning
      │
      ▼
-Is this a simple, obvious change?
-(Copy, styling, config, minor behavior tweak, one clear approach)
+Is this truly atomic?
+(No edge cases. Happy path IS the complete implementation.)
      └─► Yes → simple-improvement
 ```
 
@@ -102,9 +110,9 @@ Is this a simple, obvious change?
 |-------|-------------|-------------|
 | **bug-planning** | Something is broken/not working as expected | Investigation → fix |
 | **epic-planning** | Large initiative spanning multiple features | Break down → plan features |
-| **feature-planning** | New user-facing behavior with UX decisions to make | UX exploration → BDD → speed → stable → production |
+| **feature-planning** | New behavior needing UX exploration OR has edge cases worth sequencing | UX exploration → BDD → speed → stable → production |
 | **chore-planning** | Substantial technical work, clear implementation | speed → stable → production |
-| **simple-improvement** | Obvious change, no UX decisions, small scope | Direct implementation |
+| **simple-improvement** | Atomic change where happy path IS the complete implementation | Direct implementation |
 
 ## Routing Examples
 
@@ -125,6 +133,14 @@ Is this a simple, obvious change?
 
 *(Multiple valid UX approaches exist)*
 
+**→ feature-planning (small but has edge cases)**
+- "Add form validation to the signup form"
+- "Add retry logic when the API fails"
+- "Add confirmation before deleting items"
+- "Add input validation for the settings"
+
+*(Looks small, but has edge cases: what errors? what states? what feedback? Speed→stable split helps.)*
+
 **→ chore-planning**
 - "Refactor the auth module to use the new pattern"
 - "Migrate from Moment.js to date-fns"
@@ -140,7 +156,7 @@ Is this a simple, obvious change?
 - "Change the header color to blue"
 - "Add a tooltip to the settings icon"
 
-*(One obvious implementation, no UX exploration needed, just do it)*
+*(Truly atomic: no edge cases, no error states to design, happy path IS the complete implementation)*
 
 ## Stating Your Routing Decision
 
@@ -156,12 +172,18 @@ This is a larger initiative with multiple features. Let's break it down.
 ```
 Then invoke epic-planning skill.
 
-**Feature:**
+**Feature (UX exploration):**
 ```
 This adds new user-facing behavior with some design choices to explore. Let me suggest a few approaches.
 ```
 Then invoke feature-planning skill.
 
+**Feature (edge cases):**
+```
+This has edge cases worth handling separately - let's make it work first, then handle the error states.
+```
+Then invoke feature-planning skill.
+
 **Chore:**
 ```
 This is technical work with a clear implementation path. Let me help you plan it out.
@@ -179,10 +201,10 @@ Then invoke simple-improvement skill.
 **If genuinely ambiguous (rare - should be <20% of cases):**
 ```
 I could approach "[brief description]" as:
-- A **simple improvement** - just implement the obvious solution
-- A **feature** - explore a few UX approaches first
+- A **simple improvement** - implement it directly (no edge cases to worry about)
+- A **feature** - sequence it (make it work first, then handle edge cases)
 
-Which feels right?
+Are there edge cases worth handling separately, or is this truly atomic?
 ```
 
 Only ask when you truly cannot decide based on signals and context.