jettypod 4.4.51 → 4.4.53

package/apps/dashboard/components/KanbanBoard.tsx

@@ -17,6 +17,15 @@ const modeLabels: Record<string, { label: string; color: string }> = {
   production: { label: 'prod', color: 'bg-purple-100 text-purple-800 dark:bg-purple-900/50 dark:text-purple-300' },
 };
 
+function getModeLabel(item: WorkItem): string {
+  if (!item.mode) return '';
+  const base = modeLabels[item.mode]?.label || item.mode;
+  if (item.current_step && item.total_steps) {
+    return `${base} ${item.current_step}/${item.total_steps}`;
+  }
+  return base;
+}
+
 interface KanbanCardProps {
   item: WorkItem;
   epicTitle?: string | null;
@@ -40,7 +49,7 @@ function KanbanCard({ item, epicTitle, showEpic = false }: KanbanCardProps) {
               <span className="text-xs text-zinc-400 font-mono">#{item.id}</span>
               {item.mode && modeLabels[item.mode] && (
                 <span className={`text-xs px-1.5 py-0.5 rounded ${modeLabels[item.mode].color}`}>
-                  {modeLabels[item.mode].label}
+                  {getModeLabel(item)}
                 </span>
               )}
             </div>
@@ -78,7 +87,7 @@ function KanbanCard({ item, epicTitle, showEpic = false }: KanbanCardProps) {
                     <span className="text-zinc-400 font-mono">#{chore.id}</span>
                     {chore.mode && modeLabels[chore.mode] && (
                       <span className={`px-1 py-0.5 rounded text-[10px] ${modeLabels[chore.mode].color}`}>
-                        {modeLabels[chore.mode].label}
+                        {getModeLabel(chore)}
                       </span>
                     )}
                     <span className="text-zinc-700 dark:text-zinc-300 truncate">

package/apps/dashboard/lib/db.ts

@@ -21,6 +21,8 @@ export interface WorkItem {
   created_at: string;
   children?: WorkItem[];
   chores?: WorkItem[];
+  current_step?: number | null;
+  total_steps?: number | null;
 }
 
 export interface Decision {
@@ -207,9 +209,11 @@ export function getKanbanData(doneLimit: number = 50): KanbanData {
     // Get all chores that belong to features (for chore expansion)
     const featureChores = db.prepare(`
       SELECT c.id, c.type, c.title, c.description, c.status, c.parent_id, c.epic_id,
-             c.branch_name, c.mode, c.phase, c.completed_at, c.created_at
+             c.branch_name, c.mode, c.phase, c.completed_at, c.created_at,
+             wc.current_step, wc.total_steps
       FROM work_items c
       INNER JOIN work_items f ON c.parent_id = f.id
+      LEFT JOIN workflow_checkpoints wc ON wc.work_item_id = c.id
       WHERE c.type = 'chore' AND f.type = 'feature'
       ORDER BY c.id
     `).all() as WorkItem[];
@@ -231,9 +235,11 @@ export function getKanbanData(doneLimit: number = 50): KanbanData {
     const allItems = db.prepare(`
       SELECT w.id, w.type, w.title, w.description, w.status, w.parent_id, w.epic_id,
              w.branch_name, w.mode, w.phase, w.completed_at, w.created_at,
-             p.type as parent_type
+             p.type as parent_type,
+             wc.current_step, wc.total_steps
       FROM work_items w
       LEFT JOIN work_items p ON w.parent_id = p.id
+      LEFT JOIN workflow_checkpoints wc ON wc.work_item_id = w.id
       WHERE w.type IN ('feature', 'chore', 'bug')
         AND (w.parent_id IS NULL OR p.type = 'epic')
       ORDER BY w.id

package/docs/command-whitelist-feature-planning.md

@@ -0,0 +1,120 @@
+# Command Whitelist Matrix: Feature Planning
+
+This document defines what commands/actions are allowed at each step of the feature-planning skill. Hooks should enforce these rules and redirect the agent when violations occur.
+
+## Matrix
+
+| Step | Description | Allowed Commands | Blocked Commands | Redirect Message |
+|------|-------------|------------------|------------------|------------------|
+| **1** | Get feature context | `work show`, `workflow start`, `backlog` | Any file writes, `work create`, `work start`, `work implement` | "You're in Step 1 - get context first with `work show <id>`" |
+| **2** | Check epic decisions | `decisions --epic=X` | File writes, `work create`, `work start` | "Check for epic decisions before suggesting approaches" |
+| **3** | Suggest 3 UX approaches | Read-only (Read, Glob, Grep) | File writes, `work create`, `work start` | "Wait for user to pick an approach - no changes yet" |
+| **4** | Optional prototyping | Write to `prototypes/` only | Writes to `features/`, `src/`, `work create`, `work start` | "Prototypes go in prototypes/ - no production code yet" |
+| **5** | Choose winner | `workflow checkpoint` | File writes, `work create`, `work start` | "Wait for user to confirm winner" |
+| **6A** | Define integration contract | Read-only | File writes | "Define how users reach the feature first" |
+| **6B** | Propose BDD scenarios | Read-only, `workflow checkpoint` | **Write to `features/`**, `work create`, `work start` | "**BDD files are written in Step 8D in a worktree, not now**" |
+| **7** | Propose chores | Read-only (analyze codebase) | `work create`, `work start`, file writes | "Propose chores to user first - don't create yet" |
+| **8B** | Create chores | `work create chore` | `work start`, writes to `features/` | "Create all chores before transitioning" |
+| **8C** | Execute transition | `work implement`, `workflow checkpoint` | `work start` | "Transition the feature before starting chores" |
+| **8D** | Write tests in worktree | `work tests start`, `work tests merge`, Write to **worktree path only**, `cucumber-js --dry-run` | Write to main repo paths, `work start` | "Write tests in the worktree, not main repo" |
+| **8E** | Start first chore | `work start`, `workflow complete` | - | "Start the chore, then invoke speed-mode" |
+
+## Key Enforcement Points
+
+### 0. Allowlist-First Enforcement
+
+**Principle:** Each step defines what IS allowed, not what's blocked. Anything not explicitly allowed is rejected.
+
+This is simpler to reason about, safer by default, and guides the agent toward correct behavior rather than away from incorrect behavior.
+
+**Enforcement logic:**
+1. Check if command/action is in the step's allowlist → allow
+2. Check if it matches a global bypass pattern (see below) → block with specific message
+3. Otherwise → block with generic "not allowed at this step" + list what IS allowed
+
+### 1. Common Bypass Patterns (Global Blocks)
+
+Agents sometimes try shortcuts that bypass CLI commands entirely. Catch the common ones:
+
+- **Direct SQL:** `sqlite3` commands, raw SQL (`INSERT`, `UPDATE`, `DELETE`) in bash
+- **Inline Node execution:** `node -e` with database operations
+
+**Redirect Message:** "Use CLI commands to modify work items, not direct SQL. Run `jettypod help` to see available commands."
+
+We don't need to catch every possible bypass - these cover ~95% of cases. The redirect message does the real work.
+
+### 2. Step 6B is the Critical Trap
+
+The agent often tries to write `.feature` files in Step 6B after proposing scenarios. This must be blocked.
+
+**Rule:** Block all writes to `features/**` until Step 8D, and only then to the worktree path.
+
+### 3. Worktree Path Validation
+
+In Step 8D, writes are only allowed to the active worktree path (`.jettypod-work/tests-*`), not anywhere in the main repo.
+
+**Rule:** If a write targets a path that doesn't start with the active worktree path, block it.
+
+### 4. Order Enforcement
+
+The following commands have strict ordering:
+1. `work create chore` - Only in Step 8B (after user confirms chores)
+2. `work implement` - Only in Step 8C (after chores created)
+3. `work tests start` - Only in Step 8D (after implement)
+4. `work tests merge` - Only in Step 8D (after tests written)
+5. `work start` - Only in Step 8E (after tests merged)
+
+**Rule:** Each command should validate the previous step completed.
+
+## Context Required for Enforcement
+
+Hooks need access to:
+- **Current skill:** `feature-planning`
+- **Current step:** 1-8E (from workflow checkpoint)
+- **Feature ID:** The work item being planned
+- **Worktree path:** For Step 8D validation (from `worktrees` table)
+
+## Example Hook Logic
+
+```javascript
+// Pseudocode for pre-command hook
+function validateCommand(command, context) {
+  const { skill, step, featureId, worktreePath } = context;
+
+  if (skill !== 'feature-planning') return { allowed: true };
+
+  // Step 6B: Block writes to features/
+  if (step === '6B' && command.type === 'write' && command.path.includes('features/')) {
+    return {
+      allowed: false,
+      message: "BDD files are written in Step 8D in a worktree, not now. You're proposing scenarios - wait for user confirmation."
+    };
+  }
+
+  // Step 8D: Only allow writes to worktree
+  if (step === '8D' && command.type === 'write') {
+    if (!command.path.startsWith(worktreePath)) {
+      return {
+        allowed: false,
+        message: `Write tests in the worktree (${worktreePath}), not the main repo.`
+      };
+    }
+  }
+
+  // Block work start until Step 8E
+  if (command.name === 'work start' && step !== '8E') {
+    return {
+      allowed: false,
+      message: `Cannot start chores yet. Complete steps through 8D first (tests must be merged to main).`
+    };
+  }
+
+  return { allowed: true };
+}
+```
+
+## Open Questions
+
+1. **Step granularity:** Should we track sub-steps like 8B, 8C, 8D, 8E separately, or group them as "Step 8"?
+2. **Read operations:** Should we restrict what files can be read at certain steps, or only writes?
+3. **Skill transitions:** How do we handle the handoff to speed-mode at Step 8E?

package/jettypod.js

@@ -257,11 +257,6 @@ Skills auto-activate and MUST complete their full workflow:
 ❌ DO NOT manually create chores when a skill should generate them
 ✅ ALWAYS let skills complete autonomously before taking manual actions
 
-## 🔄 Session Start: Check for Interrupted Workflows
-On session start, run: \`jettypod workflow resume\`
-If an interrupted workflow is found, ASK the user if they want to resume it.
-Do not assume - the user may want to start fresh or work on something else.
-
 ## Basic Commands (for non-workflow operations)
 jettypod work create epic "<title>"
 jettypod work create feature "<title>" --parent=<id>

package/package.json

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

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

@@ -45,6 +45,22 @@ When this skill is activated, you are executing a standalone chore. The chore-pl
 
 ---
 
+## 🚨 SHELL CWD RECOVERY
+
+**If ALL bash commands start failing with "Error: Exit code 1" and no output:**
+
+Your shell's working directory was likely inside a worktree that was deleted. The CWD no longer exists.
+
+**Recovery steps:**
+1. Get the main repo path from your session context (look for the project path in earlier messages)
+2. Run: `cd <main-repo-path>`
+3. Verify: `pwd && ls .jettypod`
+4. Resume your work
+
+**Why this happens:** When a worktree is merged, it gets deleted. If your shell was inside that worktree directory, all subsequent commands fail because the CWD doesn't exist.
+
+---
+
 ## Implementation Steps
 
 ### Step 1: Receive and Display Context
@@ -72,6 +88,16 @@ Implementation Plan:
 • Affected tests: [list from context]
 ```
 
+**🔄 WORKFLOW INTEGRATION: Start workflow tracking**
+
+After receiving context, register this skill execution:
+
+```bash
+jettypod workflow start chore-mode <chore-id>
+```
+
+This validates that `chore_planning_complete` gate is passed (if applicable) and creates an execution record for session resume.
+
 **Move to Step 2 automatically.**
 
 ### Step 2: Create Worktree
@@ -167,6 +193,12 @@ Baseline Result:
 
 **CRITICAL:** If baseline tests fail, STOP. Fix existing failures before proceeding with chore work.
 
+**🔄 WORKFLOW CHECKPOINT: Test baseline established**
+
+```bash
+jettypod workflow checkpoint <chore-id> --step=3
+```
+
 **Move to Step 4 automatically.**
 
 ### Step 4: Display Type-Specific Guidance
@@ -260,6 +292,12 @@ const guidance = getGuidance('[chore-type]');
 - ✅ All tests pass → Move to Step 6
 - ❌ Max iterations reached → Display failure, ask user for guidance
 
+**🔄 WORKFLOW CHECKPOINT: Execution complete** (when all tests pass)
+
+```bash
+jettypod workflow checkpoint <chore-id> --step=5
+```
+
 **On max iterations:**
 
 ```
@@ -333,12 +371,20 @@ Go back to Step 5 to fix issues.
 git add .
 git commit -m "chore: [brief description]"
 git push
+```
+
+**🚨 CRITICAL: Shell CWD Corruption Prevention**
+
+The merge will delete the worktree. Chain commands to ensure shell is in main repo BEFORE deletion.
 
-# Switch to main repo before merging (merge cannot run from inside worktree)
-cd $(git rev-parse --show-toplevel)/..
+```bash
+# CRITICAL: cd to main repo AND merge in SAME command
+cd $(git rev-parse --show-toplevel)/.. && jettypod work merge [chore-id]
+```
 
-# Merge to main (auto-marks chore done)
-jettypod work merge [chore-id]
+```bash
+# MANDATORY: Verify shell is in main repo
+pwd && ls .jettypod
 ```
 
 **Display:**
@@ -361,6 +407,14 @@ Verification:
 Merged to main. Chore #[id] marked done.
 ```
 
+**🔄 WORKFLOW INTEGRATION: Complete workflow**
+
+```bash
+jettypod workflow complete chore-mode <chore-id>
+```
+
+This marks the `chore_mode_complete` gate as passed. The standalone chore is now complete.
+
 **End skill.**
 
 ---

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

@@ -31,6 +31,16 @@ Display:
 Analyzing chore type...
 ```
 
+**🔄 WORKFLOW INTEGRATION: Start workflow tracking**
+
+After understanding the chore context, register this skill execution:
+
+```bash
+jettypod workflow start chore-planning <chore-id>
+```
+
+This creates an execution record for session resume.
+
 ### Step 2: Classify Chore Type
 
 Classify the chore by matching keywords in the title and description against these patterns:
@@ -267,6 +277,16 @@ The chore-mode skill will:
 3. Run verification steps
 4. Merge when complete
 
+**🔄 WORKFLOW INTEGRATION: Complete workflow**
+
+Before invoking chore-mode:
+
+```bash
+jettypod workflow complete chore-planning <chore-id>
+```
+
+This marks the `chore_planning_complete` gate as passed, enabling chore-mode to start.
+
 **End chore-planning skill after invoking chore-mode.**
 
 ## Key Principles

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

@@ -24,7 +24,19 @@ Run this command to get epic context:
 jettypod work status ${EPIC_ID}
 ```
 
-Capture the title, description, and any existing context. Proceed to Step 2.
+Capture the title, description, and any existing context.
+
+**🔄 WORKFLOW INTEGRATION: Start workflow tracking**
+
+After getting the epic context, register this skill execution:
+
+```bash
+jettypod workflow start epic-planning <epic-id>
+```
+
+This creates an execution record for session resume.
+
+Proceed to Step 2.
 
 ---
 
@@ -57,7 +69,19 @@ Then synthesize into an epic title + description and create:
 jettypod work create epic "${EPIC_TITLE}" "${EPIC_DESCRIPTION}"
 ```
 
-Capture the new epic ID from output. Proceed to Step 3 (skip Step 2 since nothing exists yet).
+Capture the new epic ID from output.
+
+**🔄 WORKFLOW INTEGRATION: Start workflow tracking**
+
+After creating the epic, register this skill execution:
+
+```bash
+jettypod workflow start epic-planning <epic-id>
+```
+
+This creates an execution record for session resume.
+
+Proceed to Step 3 (skip Step 2 since nothing exists yet).
 
 ### Step 2: Check Existing State
 
@@ -388,6 +412,14 @@ Chores:
 Or run: jettypod backlog to see all items.
 ```
 
+**🔄 WORKFLOW INTEGRATION: Complete workflow**
+
+```bash
+jettypod workflow complete epic-planning <epic-id>
+```
+
+This marks the `epic_planning_complete` gate as passed. Features created under this epic can now begin their own planning.
+
 **Do NOT invoke any skill. End epic-planning skill.**
 
 ## Key Principles

package/skills-templates/external-transition/SKILL.md

@@ -83,6 +83,16 @@ Ready to proceed? (yes/no)
 
 Wait for the user to respond with "yes" or similar affirmative response.
 
+**🔄 WORKFLOW INTEGRATION: Start workflow tracking**
+
+After receiving initial confirmation, register this skill execution:
+
+```bash
+jettypod workflow start external-transition
+```
+
+This creates an execution record for session resume (note: external-transition is project-level, not tied to a specific work item).
+
 If they say "no" or express hesitation, ask what concerns they have or what they need to clarify.
 
 ### Step 3: Production Standards Selection
@@ -320,6 +330,12 @@ Then confirm to user:
 These standards will guide all production mode work going forward.
 ```
 
+**🔄 WORKFLOW CHECKPOINT: Standards saved**
+
+```bash
+jettypod workflow checkpoint --step=7
+```
+
 ### Step 8: Final Confirmation for Transition
 
 Now confirm the actual state transition:
@@ -362,6 +378,14 @@ Your project is now in external state.
 **Want to start on infrastructure work now?**
 ```
 
+**🔄 WORKFLOW INTEGRATION: Complete workflow**
+
+```bash
+jettypod workflow complete external-transition
+```
+
+This marks the `external_transition_complete` gate as passed. The project is now in external state with production standards configured.
+
 ### Step 11: Guide Next Actions
 
 If the user wants to start infrastructure work:

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

@@ -53,6 +53,16 @@ This returns: title, description, parent epic (if any), mode, phase, and any exi
 
 **If the feature is not found**, ask the user to verify the ID or run `jettypod backlog` to find it.
 
+**🔄 WORKFLOW INTEGRATION: Start workflow tracking**
+
+After getting the feature context, register this skill execution:
+
+```bash
+jettypod workflow start feature-planning <feature-id>
+```
+
+This creates an execution record for session resume.
+
 **Proceed to Step 2** (or Step 3 if this is a standalone feature with no parent epic).
 
 ### Step 2: Check Epic Architectural Decisions
@@ -184,6 +194,12 @@ Which approach works best?
 
 User picks winner. Note their choice - you'll record it formally in Step 8 when transitioning to implementation.
 
+**🔄 WORKFLOW CHECKPOINT: Winner chosen**
+
+```bash
+jettypod workflow checkpoint <feature-id> --step=5
+```
+
 **Proceed to Step 6.**
 
 ### Step 6: Define Integration Contract AND Generate BDD Scenarios
@@ -317,6 +333,12 @@ Does this capture the feature correctly? Any scenarios to add/change?
 - If user requests changes → Revise scenarios and display again
 - **Store the confirmed scenarios in memory** - you'll write them in Step 8D
 
+**🔄 WORKFLOW CHECKPOINT: BDD scenarios confirmed**
+
+```bash
+jettypod workflow checkpoint <feature-id> --step=6
+```
+
 **Proceed to Step 7.**
 
 **Template for speed mode (make it work):**
@@ -590,6 +612,12 @@ After successful transition, display:
 Now I'll write the BDD tests in an isolated worktree...
 ```
 
+**🔄 WORKFLOW CHECKPOINT: Implementation transition complete**
+
+```bash
+jettypod workflow checkpoint <feature-id> --step=8
+```
+
 **Proceed to Step 8D.**
 
 #### Step 8D: Write Tests in Isolated Worktree
@@ -743,6 +771,14 @@ This will:
 Start this one? [yes / pick different / done for now]
 ```
 
+**🔄 WORKFLOW INTEGRATION: Complete workflow**
+
+```bash
+jettypod workflow complete feature-planning <feature-id>
+```
+
+This marks the `feature_planning_complete` gate as passed, enabling speed-mode to start.
+
 **Proceed to Step 8E.**
 
 #### Step 8E: Start First Chore

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

@@ -54,6 +54,16 @@ sqlite3 .jettypod/work.db "SELECT completed_at FROM work_items WHERE parent_id =
 
 Based on these checks, determine which scenario applies.
 
+**🔄 WORKFLOW INTEGRATION: Start workflow tracking**
+
+After detecting context, register this skill execution:
+
+```bash
+jettypod workflow start production-mode <feature-id>
+```
+
+This validates that `stable_mode_complete` gate is passed and creates an execution record for session resume.
+
 **Three Scenarios:**
 
 **Scenario A: Fresh from Stable (Hot Context)**
@@ -89,6 +99,12 @@ cat .jettypod/production-standards.json
 
 If the file doesn't exist, run external-transition first to generate production standards.
 
+**🔄 WORKFLOW CHECKPOINT: Standards read**
+
+```bash
+jettypod workflow checkpoint <feature-id> --step=1
+```
+
 ---
 
 ### Step 2A: Validate Scenarios (Scenario A - Hot Context)
@@ -221,6 +237,12 @@ This will:
 3. Append scenarios to the feature file
 4. Create production chores
 
+**🔄 WORKFLOW CHECKPOINT: Scenarios validated/generated** (after any Step 2 variant)
+
+```bash
+jettypod workflow checkpoint <feature-id> --step=2
+```
+
 ---
 
 ### Step 3: Implement Production Chore
@@ -243,6 +265,12 @@ Parse the chore description to find which scenario it addresses (look for "Scena
    npx cucumber-js <scenario-file> --name "<scenario-name>" --format progress
    ```
 
+   **🔄 WORKFLOW CHECKPOINT: RED baseline established**
+
+   ```bash
+   jettypod workflow checkpoint <feature-id> --step=3
+   ```
+
 2. **Iterate until scenario passes (max 10 iterations):**
    - Implement production hardening using Edit/Write tools
    - Run the target scenario to check progress
@@ -307,3 +335,13 @@ Once all production chores complete:
 1. Feature is production-ready
 2. Can be deployed to external environment
 3. Meets all standards for scale, security, compliance
+
+**🔄 WORKFLOW INTEGRATION: Complete workflow**
+
+When all production chores are complete:
+
+```bash
+jettypod workflow complete production-mode <feature-id>
+```
+
+This marks the `production_mode_complete` gate as passed. The feature is now production-ready.

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

@@ -48,6 +48,27 @@ When this skill is activated, you are helping implement a speed mode chore to ma
 
 ---
 
+## 🚨 SHELL CWD RECOVERY
+
+**If ALL bash commands start failing with "Error: Exit code 1" and no output:**
+
+Your shell's working directory was likely inside a worktree that was deleted. The CWD no longer exists.
+
+**Recovery steps:**
+1. Get the main repo path from your session context (look for the project path in earlier messages)
+2. Run: `cd <main-repo-path>`
+3. Verify: `pwd && ls .jettypod`
+4. Resume your work
+
+**Example:**
+```bash
+cd /Users/erikspangenberg/personal-assistant && pwd
+```
+
+**Why this happens:** When a worktree is merged, it gets deleted. If your shell was inside that worktree directory, all subsequent commands fail because the CWD doesn't exist.
+
+---
+
 ## 🛑 PRE-FLIGHT VALIDATION (REQUIRED)
 
 **Before proceeding with ANY implementation, you MUST validate the worktree exists.**
@@ -217,6 +238,16 @@ test('createUser throws error for invalid email', () => {
 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'"
 ```
 
+**🔄 WORKFLOW INTEGRATION: Start workflow tracking**
+
+After getting the work context, register this skill execution:
+
+```bash
+jettypod workflow start speed-mode <feature-id>
+```
+
+This validates that `feature_planning_complete` gate is passed and creates an execution record for session resume.
+
 **Display to user:**
 
 ```
@@ -377,6 +408,12 @@ Integration Points:
 Now proposing implementation approach...
 ```
 
+**🔄 WORKFLOW CHECKPOINT: Codebase analysis complete**
+
+```bash
+jettypod workflow checkpoint <feature-id> --step=2
+```
+
 ### Step 3: Decide if Confirmation Needed
 
 **Evaluate if you need user confirmation before implementing:**
@@ -467,6 +504,12 @@ First error:
 Now implementing...
 ```
 
+**🔄 WORKFLOW CHECKPOINT: RED baseline established**
+
+```bash
+jettypod workflow checkpoint <feature-id> --step=4
+```
+
 ---
 
 ### Step 5: RED→GREEN→REFACTOR Loop
@@ -502,6 +545,12 @@ Now implementing...
 🎉 GREEN: All success scenarios passing!
 ```
 
+**🔄 WORKFLOW CHECKPOINT: GREEN achieved**
+
+```bash
+jettypod workflow checkpoint <feature-id> --step=5
+```
+
 **Then REFACTOR (quick pass, 5 min max):**
 - Extract duplicated code
 - Rename unclear variables
@@ -564,16 +613,23 @@ More speed mode chores remain. Starting next chore:
 
 **Merge and start next:**
 
+**🚨 CRITICAL: Shell CWD Corruption Prevention**
+
+The merge will delete the worktree. Chain commands to ensure shell is in main repo BEFORE deletion.
+
 ```bash
 # Commit changes in the worktree
 git add . && git commit -m "feat: [brief description of what was implemented]"
+```
 
-# Return to main repo and merge (cannot merge from inside worktree)
-cd $(git rev-parse --show-toplevel)/..  # Exit worktree to main repo
-jettypod work merge [current-chore-id]
+```bash
+# CRITICAL: cd to main repo AND merge in SAME command
+cd $(git rev-parse --show-toplevel)/.. && jettypod work merge [current-chore-id]
+```
 
-# Start next speed chore
-jettypod work start [next-chore-id]
+```bash
+# Verify shell is valid, then start next chore
+pwd && jettypod work start [next-chore-id]
 ```
 
 The speed-mode skill will automatically re-invoke for the next chore.
@@ -612,15 +668,28 @@ npx cucumber-js <scenario-file-path> --name "User can reach" --format progress
 
 #### Step 7B: Merge Final Speed Chore
 
+**🚨 CRITICAL: Shell CWD Corruption Prevention**
+
+The merge will delete the worktree. Chain commands to ensure shell is in main repo BEFORE deletion.
+
 ```bash
 # Commit changes in the worktree
 git add . && git commit -m "feat: [brief description of what was implemented]"
+```
 
-# Return to main repo and merge (cannot merge from inside worktree)
-cd $(git rev-parse --show-toplevel)/..  # Exit worktree to main repo
-jettypod work merge [current-chore-id] --with-transition
+```bash
+# CRITICAL: cd to main repo AND merge in SAME command
+# Using $(git rev-parse --show-toplevel)/.. exits worktree to main repo
+cd $(git rev-parse --show-toplevel)/.. && jettypod work merge [current-chore-id] --with-transition
 ```
 
+```bash
+# MANDATORY: Verify shell is in main repo (run immediately after merge)
+pwd && ls .jettypod
+```
+
+**If you see "No such file or directory" errors:** Your shell CWD was corrupted. Get the main repo path from your session context and run `cd <main-repo-path>`.
+
 After merge, you are on main branch. Ready to generate stable mode scenarios.
 
 #### Step 7C: Generate and Propose Stable Mode Chores
@@ -680,19 +749,35 @@ Scenario: [Edge case title]
 
 **6. Commit and merge the test worktree:**
 
+**🚨 CRITICAL: Shell CWD Corruption Prevention**
+
+The merge will delete the test worktree. If your shell is inside that worktree, ALL subsequent commands will fail. You MUST:
+1. Chain the cd and merge in a SINGLE bash command
+2. Verify your shell is in main repo AFTER merge
+
 ```bash
-# Commit in the test worktree
-cd <worktree-path>
-git add features/
-git commit -m "test: Add stable mode BDD scenarios and step definitions
+# First: Commit in the test worktree (separate command is OK here)
+cd <worktree-path> && 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.
 - [N] new stable mode scenarios
 - Step definitions for validation and error handling"
+```
+
+```bash
+# CRITICAL: cd to main repo AND merge in SAME command
+# This ensures shell is in main repo BEFORE worktree deletion
+cd <main-repo-path> && jettypod work tests merge <feature-id>
+```
+
+```bash
+# MANDATORY: Verify shell is in main repo (run this immediately after merge)
+pwd && ls .jettypod
+```
 
-# Return to main repo and merge
+**If you see "No such file or directory" errors:** Your shell CWD was corrupted. Run:
+```bash
 cd <main-repo-path>
-jettypod work tests merge <feature-id>
 ```
 
 **7. Present proposal to user:**
@@ -745,6 +830,14 @@ Repeat for each confirmed chore. **Do NOT use `--mode` flag** - chores inherit m
 jettypod work merge --release-lock
 ```
 
+**🔄 WORKFLOW COMPLETE: Speed mode finished**
+
+Mark speed mode as complete (this passes the `speed_mode_complete` gate, enabling stable-mode):
+
+```bash
+jettypod workflow complete speed-mode <feature-id>
+```
+
 #### Step 7E: Start First Stable Chore and Invoke Stable Mode Skill
 
 **🛑 CRITICAL HANDOFF - You MUST start the first chore BEFORE invoking stable-mode.**

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

@@ -52,6 +52,22 @@ When this skill is activated, you are helping implement a stable mode chore to a
 
 ---
 
+## 🚨 SHELL CWD RECOVERY
+
+**If ALL bash commands start failing with "Error: Exit code 1" and no output:**
+
+Your shell's working directory was likely inside a worktree that was deleted. The CWD no longer exists.
+
+**Recovery steps:**
+1. Get the main repo path from your session context (look for the project path in earlier messages)
+2. Run: `cd <main-repo-path>`
+3. Verify: `pwd && ls .jettypod`
+4. Resume your work
+
+**Why this happens:** When a worktree is merged, it gets deleted. If your shell was inside that worktree directory, all subsequent commands fail because the CWD doesn't exist.
+
+---
+
 ## 🛑 PRE-FLIGHT VALIDATION (REQUIRED)
 
 **Before proceeding with ANY implementation, you MUST validate the worktree exists.**
@@ -222,6 +238,16 @@ test('getUserById returns null for non-existent user', () => {
 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'"
 ```
 
+**🔄 WORKFLOW INTEGRATION: Start workflow tracking**
+
+After getting the work context, register this skill execution:
+
+```bash
+jettypod workflow start stable-mode <feature-id>
+```
+
+This validates that `speed_mode_complete` gate is passed and creates an execution record for session resume.
+
 **Display to user:**
 
 ```
@@ -346,6 +372,12 @@ To pass the target scenario, I need to:
 Now proposing comprehensive implementation...
 ```
 
+**🔄 WORKFLOW CHECKPOINT: Code analysis complete**
+
+```bash
+jettypod workflow checkpoint <feature-id> --step=2
+```
+
 ### Step 3: Decide if Confirmation Needed
 
 **Evaluate if you need user confirmation before implementing:**
@@ -431,6 +463,12 @@ First error:
 Now implementing...
 ```
 
+**🔄 WORKFLOW CHECKPOINT: RED baseline established**
+
+```bash
+jettypod workflow checkpoint <feature-id> --step=4
+```
+
 ---
 
 ### Step 5: RED→GREEN→REFACTOR Loop
@@ -466,6 +504,12 @@ Now implementing...
 🎉 GREEN: All stable mode scenarios passing!
 ```
 
+**🔄 WORKFLOW CHECKPOINT: GREEN achieved**
+
+```bash
+jettypod workflow checkpoint <feature-id> --step=5
+```
+
 **Then REFACTOR (quick pass, 5 min max):**
 - Extract duplicated validation logic
 - Rename unclear error variables
@@ -528,16 +572,23 @@ More stable mode chores remain. Starting next chore:
 
 **Merge and start next:**
 
+**🚨 CRITICAL: Shell CWD Corruption Prevention**
+
+The merge will delete the worktree. Chain commands to ensure shell is in main repo BEFORE deletion.
+
 ```bash
 # Commit changes in the worktree
 git add . && git commit -m "feat: [brief description of error handling added]"
+```
 
-# Return to main repo and merge (cannot merge from inside worktree)
-cd $(git rev-parse --show-toplevel)/..  # Exit worktree to main repo
-jettypod work merge [current-chore-id]
+```bash
+# CRITICAL: cd to main repo AND merge in SAME command
+cd $(git rev-parse --show-toplevel)/.. && jettypod work merge [current-chore-id]
+```
 
-# Start next stable chore
-jettypod work start [next-chore-id]
+```bash
+# Verify shell is valid, then start next chore
+pwd && jettypod work start [next-chore-id]
 ```
 
 The stable-mode skill will automatically re-invoke for the next chore.
@@ -556,10 +607,20 @@ If the query returns no remaining chores, proceed to Step 7.
 
 **First, merge the final stable chore:**
 
+**🚨 CRITICAL: Shell CWD Corruption Prevention**
+
 ```bash
 git add . && git commit -m "feat: [brief description of error handling added]"
-cd $(git rev-parse --show-toplevel)/..  # Exit worktree to main repo
-jettypod work merge [current-chore-id]
+```
+
+```bash
+# CRITICAL: cd to main repo AND merge in SAME command
+cd $(git rev-parse --show-toplevel)/.. && jettypod work merge [current-chore-id]
+```
+
+```bash
+# MANDATORY: Verify shell is in main repo
+pwd && ls .jettypod
 ```
 
 **Then check project state:**
@@ -603,6 +664,14 @@ Note: If you later transition to external (accepting real users),
 run the external-transition skill to generate production chores.
 ```
 
+**🔄 WORKFLOW INTEGRATION: Complete workflow (internal project)**
+
+```bash
+jettypod workflow complete stable-mode <feature-id>
+```
+
+This marks the `stable_mode_complete` gate as passed. For internal projects, this is the final workflow step.
+
 **End skill.** Feature is DONE.
 
 ---
@@ -637,6 +706,14 @@ What we accomplished:
 🚀 Now invoking production-mode skill...
 ```
 
+**🔄 WORKFLOW INTEGRATION: Complete workflow (external project)**
+
+```bash
+jettypod workflow complete stable-mode <feature-id>
+```
+
+This marks the `stable_mode_complete` gate as passed, enabling production-mode to start.
+
 **Invoke production-mode:**
 
 ```