jettypod 4.4.95 → 4.4.97

package/lib/git-hooks/post-merge

@@ -57,7 +57,7 @@ const currentWork = JSON.parse(fs.readFileSync(currentWorkPath, 'utf-8'));
 // Update to done using shared updateStatus (includes epic auto-close logic)
 (async () => {
   try {
-    const { updateStatus } = require('__JETTYPOD_ROOT__/features/work-tracking');
+    const { updateStatus } = require('__JETTYPOD_ROOT__/lib/work-tracking');
     await updateStatus(currentWork.id, 'done');
 
     // Clear current work pointer since work is done

package/package.json

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

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

@@ -67,6 +67,14 @@ Your shell's working directory was likely inside a worktree that was deleted. Th
 
 **Your task:** Acknowledge the context passed from chore-planning.
 
+**🚫 FORBIDDEN: Writing Files at This Step**
+```
+❌ Write tool to any path
+❌ Edit tool to any path
+❌ Any file creation or modification
+```
+**This is a CONTEXT step.** File writes happen in Step 5.
+
 You will receive:
 - `choreContext.chore` - Chore ID, title, description
 - `choreContext.classification` - Type and confidence
@@ -149,10 +157,34 @@ Resolve the issue before continuing.
 
 **Move to Step 3 only if worktree was created successfully.**
 
+**🔒 WORKTREE PATH LOCK**
+
+After worktree validation passes, capture and lock the path:
+- `WORKTREE_PATH` - the absolute path from the query result
+
+**Display:**
+
+```
+🔒 WORKTREE LOCK ACTIVE
+Path: ${WORKTREE_PATH}
+
+All file writes will use this path.
+```
+
+**From this point forward, ALL file operations MUST use paths starting with `${WORKTREE_PATH}/`**
+
 ### Step 3: Establish Test Baseline
 
 **Your task:** Run tests to establish baseline before making changes.
 
+**🚫 FORBIDDEN: Writing Files at This Step**
+```
+❌ Write tool to any path
+❌ Edit tool to any path
+❌ Any file creation or modification
+```
+**This is a TESTING step.** File writes happen in Step 5.
+
 **Test handling varies by type:**
 
 **For REFACTOR:**
@@ -205,6 +237,14 @@ jettypod workflow checkpoint <chore-id> --step=3
 
 **Your task:** Display warnings and constraints based on chore type.
 
+**🚫 FORBIDDEN: Writing Files at This Step**
+```
+❌ Write tool to any path
+❌ Edit tool to any path
+❌ Any file creation or modification
+```
+**This is a GUIDANCE step.** File writes happen in Step 5.
+
 **Load guidance from taxonomy:**
 
 ```javascript
@@ -258,6 +298,10 @@ const guidance = getGuidance('[chore-type]');
 
 ### Step 5: Execute with Iteration
 
+**🔒 WORKTREE PATH REQUIRED:** All file writes MUST use the `WORKTREE_PATH` captured in Step 2.
+
+**✅ NOW you may write files** - worktree is locked, guidance is displayed.
+
 **Your task:** Make changes and iterate until tests pass. Max 5 iterations.
 
 ```

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

@@ -17,19 +17,20 @@ When this skill is activated, you are helping discover the best approach for a f
 
 | Command | Used For | When | Phase |
 |---------|----------|------|-------|
-| `work implement <feature-id>` | Transition feature to implementation phase | After chores created (Step 8C) | Feature Planning |
-| `work tests start <feature-id>` | Create worktree for test authoring | After transition (Step 8D) | Feature Planning |
-| `work tests merge` → `cd` → `work cleanup` | Merge tests to main, then cleanup worktree | After tests validated (Step 8D) | Feature Planning |
-| `work start <chore-id>` | Start implementing a specific chore | After tests merged (Step 8E) | Speed Mode |
+| `work tests start <feature-id>` | Create worktree for test authoring | After Integration Contract (Step 7) | Feature Planning |
+| `work tests merge` → `cd` → `work cleanup` | Merge tests to main, then cleanup worktree | After chores created (Step 12) | Feature Planning |
+| `work implement <feature-id>` | Transition feature to implementation phase | After chores created (Step 11) | Feature Planning |
+| `work start <chore-id>` | Start implementing a specific chore | After tests merged (Step 13) | Speed Mode |
 
 **CRITICAL:** All commands are run by **Claude**, not the user. The distinction is:
+- `work tests start` = Creates isolated worktree for BDD test authoring (Step 7)
 - `work implement` = Ends feature planning, transitions to implementation phase
-- `work tests start/merge` = Write and land BDD tests in isolated worktree
+- `work tests merge` = Land BDD tests on main
 - `work start` = Creates worktree/branch for chore implementation
 
-**🛑 STOP GATE:** DO NOT run `work start` until Step 8E. Tests must be merged to main first.
+**🛑 STOP GATE:** DO NOT run `work start` until Step 13. Tests must be merged to main first.
 
-**🛑 HANDOFF REQUIREMENT:** After `work start`, you MUST invoke speed-mode using the Skill tool. See Step 8E.
+**🛑 HANDOFF REQUIREMENT:** After `work start`, you MUST invoke speed-mode using the Skill tool. See Step 13.
 
 ---
 
@@ -228,7 +229,7 @@ Which approach works best?
 
 **WAIT for user response.**
 
-User picks winner. Note their choice - you'll record it formally in Step 8 when transitioning to implementation.
+User picks winner. Note their choice - you'll record it formally in Step 11 when transitioning to implementation.
 
 **🔄 WORKFLOW CHECKPOINT: Winner chosen**
 
@@ -238,12 +239,10 @@ jettypod workflow checkpoint <feature-id> --step=5
 
 **Proceed to Step 6.**
 
-### Step 6: Define Integration Contract AND Generate BDD Scenarios
+### Step 6: Define Integration Contract
 
 **CRITICAL:** Before writing scenarios, you MUST define how users reach this feature. Features that pass tests but aren't integrated into the product are useless.
 
-#### Step 6A: Define Integration Contract
-
 **Ask yourself and document:**
 
 1. **Entry Point** - How does a user reach this feature?
@@ -279,17 +278,77 @@ Example:
 
 **WAIT for user to confirm or adjust the integration contract.**
 
-#### Step 6B: Propose BDD Scenarios (DO NOT WRITE YET)
+**Proceed to Step 7.**
+
+### Step 7: Create Test Worktree
+
+**CRITICAL:** Create the isolated worktree BEFORE proposing scenarios. This ensures:
+1. A safe workspace exists before any file discussion
+2. Claude has `WORKTREE_PATH` before being tempted to write files
+3. Writing to main is impossible because we're in worktree context
+
+**🚫 FORBIDDEN: Manual Git Worktree Commands**
+```
+❌ git worktree add ...
+❌ git checkout -b tests/...
+❌ git branch tests/...
+```
+**ALWAYS use jettypod commands** - they handle branch naming, path conventions, database tracking, and cleanup. Manual git commands will create orphaned worktrees that break the merge workflow.
+
+**Run:**
+
+```bash
+jettypod work tests start ${FEATURE_ID}
+```
+
+This creates:
+- Worktree at `.jettypod-work/tests-<id>-<slug>/`
+- Branch `tests/feature-<id>-<slug>`
+
+**🛑 STOP AND CHECK:** Verify worktree was created successfully. If you see an error, investigate before continuing.
+
+**Capture from output:**
+- `WORKTREE_PATH` - the absolute path to the worktree (e.g., `/path/to/.jettypod-work/tests-42-email-login`)
+
+Example output:
+```
+✅ Created test worktree: /path/to/.jettypod-work/tests-42-email-login
+Branch: tests/feature-42-email-login
+
+Write your BDD files to:
+  <worktree>/features/email-login.feature
+  <worktree>/features/step_definitions/email-login.steps.js
+```
+
+**Display:**
 
-**🚫 FORBIDDEN: Writing Files at This Step**
 ```
-❌ Write tool to features/*.feature
-❌ Write tool to features/step_definitions/*.js
-❌ Any file creation on main branch
+📁 Test worktree created: ${WORKTREE_PATH}
+Branch: tests/feature-${FEATURE_ID}-${FEATURE_SLUG}
+
+🔒 WORKTREE LOCK ACTIVE: All BDD file writes will use this path.
 ```
-**Files are written in Step 8D** inside an isolated worktree. At this step, you are ONLY displaying proposed scenarios to the user for confirmation. The worktree doesn't exist yet.
 
-**CRITICAL:** Do NOT write files yet. Display the proposed scenarios for user confirmation. Files will be written in Step 8D inside an isolated worktree.
+**🔒 WORKTREE PATH LOCK**
+
+From this point forward, ALL file operations for BDD tests MUST use paths starting with:
+```
+${WORKTREE_PATH}/features/
+```
+
+**Store `WORKTREE_PATH`** - you'll need it for Step 9.
+
+**Proceed to Step 8.**
+
+### Step 8: Propose BDD Scenarios
+
+**🚫 FORBIDDEN: Writing Files at This Step**
+```
+❌ Write tool to ${WORKTREE_PATH}/features/*.feature
+❌ Write tool to ${WORKTREE_PATH}/features/step_definitions/*.js
+❌ Any file creation (even in worktree)
+```
+**Files are written in Step 9** after user confirms the scenarios. At this step, you are ONLY displaying proposed scenarios to the user for confirmation.
 
 **Feature slug:** Derive `FEATURE_SLUG` from the feature title:
 - Lowercase
@@ -302,8 +361,8 @@ Based on chosen approach, **display** the proposed scenarios to the user:
 ```
 📋 Proposed BDD Scenarios
 
-**Feature file:** features/[feature-slug].feature
-**Step definitions:** features/step_definitions/[feature-slug].steps.js
+**Feature file:** ${WORKTREE_PATH}/features/[feature-slug].feature
+**Step definitions:** ${WORKTREE_PATH}/features/step_definitions/[feature-slug].steps.js
 ```
 
 Then show the full Gherkin content:
@@ -316,8 +375,8 @@ Feature: [Feature Name]
   Approach: [Chosen approach name]
 
   # Integration Contract:
-  # Entry Point: [from Step 6A]
-  # Caller Code: [from Step 6A]
+  # Entry Point: [from Step 6]
+  # Caller Code: [from Step 6]
 
 # INTEGRATION SCENARIO (REQUIRED - proves feature is reachable)
 Scenario: User can reach [feature] from [entry point]
@@ -354,7 +413,7 @@ Does this capture the feature correctly? Any scenarios to add/change?
 ```
 
 **Scenario content requirements:**
-- **FIRST scenario MUST be the Integration Scenario** from Step 6A (proves reachability)
+- **FIRST scenario MUST be the Integration Scenario** from Step 6 (proves reachability)
 - **Include all "make it work" scenarios**:
   - All success paths - required functionality AND optional features
   - Multiple valid workflows if the feature supports them
@@ -365,17 +424,17 @@ Does this capture the feature correctly? Any scenarios to add/change?
 
 **WAIT for user confirmation.**
 
-- If user confirms → Proceed to Step 7
+- If user confirms → Proceed to Step 9
 - If user requests changes → Revise scenarios and display again
-- **Store the confirmed scenarios in memory** - you'll write them in Step 8D
+- **Store the confirmed scenarios in memory** - you'll write them in Step 9
 
 **🔄 WORKFLOW CHECKPOINT: BDD scenarios confirmed**
 
 ```bash
-jettypod workflow checkpoint <feature-id> --step=6
+jettypod workflow checkpoint <feature-id> --step=8
 ```
 
-**Proceed to Step 7.**
+**Proceed to Step 9.**
 
 **Template for speed mode (make it work):**
 
@@ -387,8 +446,8 @@ Feature: [Feature Name]
   Approach: [Chosen approach name]
 
   # Integration Contract:
-  # Entry Point: [from Step 6A]
-  # Caller Code: [from Step 6A]
+  # Entry Point: [from Step 6]
+  # Caller Code: [from Step 6]
 
 # INTEGRATION SCENARIO (REQUIRED - proves feature is reachable)
 Scenario: User can reach [feature] from [entry point]
@@ -500,13 +559,94 @@ Scenario: Prevent unauthorized access
 
 </details>
 
-### Step 7: Propose Speed Mode Chores
+### Step 9: Write and Validate BDD Files
 
-**CRITICAL:** After user confirms the BDD scenarios, analyze the codebase and propose technical implementation chores. **DO NOT CREATE CHORES YET** - the feature must transition to implementation mode first (Step 8).
+**NOW you may write files** - the worktree exists (from Step 7) and scenarios are confirmed (from Step 8).
+
+**🔒 WORKTREE PATH REQUIRED:** All file writes MUST use the `WORKTREE_PATH` captured in Step 7.
+
+Using the scenarios confirmed in Step 8, write the files using **absolute paths to the worktree**:
+
+**A. Write scenario file** using Write tool:
+```
+${WORKTREE_PATH}/features/${FEATURE_SLUG}.feature
+```
+
+**B. Write step definitions file** using Write tool:
+```
+${WORKTREE_PATH}/features/step_definitions/${FEATURE_SLUG}.steps.js
+```
+
+**Step definition requirements:**
+1. Implement all Given/When/Then steps from the scenarios
+2. Follow existing patterns - check other `.steps.js` files for conventions
+3. Include test environment setup/cleanup
+4. All Given steps (setup state)
+5. All When steps (execute actions)
+6. All Then steps (verify outcomes)
+
+**Validate BDD infrastructure:**
+
+Run cucumber dry-run **from within the worktree**:
+
+```bash
+cd ${WORKTREE_PATH} && npx cucumber-js --dry-run features/${FEATURE_SLUG}.feature
+```
+
+**What the output means:**
+
+✅ **Success** - No errors, all steps have definitions:
+```
+0 scenarios
+0 steps
+```
+(Dry-run doesn't execute, so 0 is correct)
+
+❌ **Undefined steps** - Missing step definitions:
+```
+Undefined. Implement with the following snippet:
+  Given('I am on the login page', function () {
+    ...
+  });
+```
+→ Add the missing step definition to your `.steps.js` file
+
+❌ **Syntax error** - Invalid Gherkin:
+```
+Parse error in features/foo.feature
+```
+→ Fix the feature file syntax
+
+❌ **Duplicate steps** - Multiple definitions match:
+```
+Multiple step definitions match
+```
+→ Remove or rename one of the duplicate step definitions
+
+**If validation fails:**
+1. Read the error message carefully
+2. Fix the step definitions or scenario file **in the worktree**
+3. Re-run the dry-run command
+4. **Loop until validation passes** - do NOT proceed until green
+
+**If validation succeeds:**
+Display: "✅ BDD infrastructure validated - all steps have definitions"
+
+**Update database with scenario file path:**
+
+```bash
+sqlite3 .jettypod/work.db "UPDATE work_items SET scenario_file = 'features/${FEATURE_SLUG}.feature' WHERE id = ${FEATURE_ID}"
+```
+
+**Proceed to Step 10.**
+
+### Step 10: Propose Speed Mode Chores
+
+**CRITICAL:** After BDD files are written and validated, analyze the codebase and propose technical implementation chores. **DO NOT CREATE CHORES YET** - the feature must transition to implementation mode first (Step 11).
 
 **Your analysis should consider:**
 - The BDD scenarios (integration + all success paths)
-- The Integration Contract from Step 6A
+- The Integration Contract from Step 6
 - Existing codebase structure and patterns
 - Epic's architectural decisions (if any)
 - Tech stack and framework conventions
@@ -516,7 +656,7 @@ Scenario: Prevent unauthorized access
 **REQUIRED: At least one chore MUST be an Integration Chore** that:
 - Wires the feature into the existing app
 - Makes the Integration Scenario pass
-- Modifies the caller code identified in Step 6A
+- Modifies the caller code identified in Step 6
 
 **Say to the user:**
 
@@ -530,7 +670,7 @@ Based on the scenario and my understanding of the codebase, here are the chores
 **Chore 1: [Integration chore - wire feature into app]** ⚡ INTEGRATION
 - Why: Makes the feature reachable from [entry point]
 - Integration Contract:
-  • Entry point: [from Step 6A]
+  • Entry point: [from Step 6]
   • Caller code to modify: [specific file/function]
 - Scenario steps addressed:
   • [Integration scenario Given/When/Then steps]
@@ -560,17 +700,17 @@ Sound good? Any adjustments?
 
 **WAIT for user response.**
 
-- If user confirms → Proceed to Step 8
+- If user confirms → Proceed to Step 11
 - If user requests changes → Revise chore proposals, then WAIT again
 - If user adds/removes chores → Update your list accordingly
 
-### Step 8: Transition to Implementation
+### Step 11: Rationale, Create Chores, and Transition
 
-Complete the discovery phase by transitioning the feature from discovery to implementation.
+Complete the discovery phase by recording the decision, creating chores, and transitioning the feature from discovery to implementation.
 
-**CRITICAL: You must EXECUTE the transition command using the Bash tool. Do NOT just display it as text.**
+**CRITICAL: You must EXECUTE commands using the Bash tool. Do NOT just display them as text.**
 
-#### Step 8A: Propose Rationale
+#### Sub-step A: Confirm Rationale
 
 Display to user:
 
@@ -585,11 +725,11 @@ Does this rationale capture why you chose this approach? (You can edit it if nee
 
 **WAIT for user to confirm or provide edited rationale.**
 
-#### Step 8B: Create the Chores
+#### Sub-step B: Create the Chores
 
 **CRITICAL: Create chores BEFORE running `work implement`.** The system validates that chores exist before allowing the transition.
 
-For each chore that the user confirmed in Step 7, use the Bash tool to create it:
+For each chore that the user confirmed in Step 10, use the Bash tool to create it:
 
 ```bash
 jettypod work create chore "[Chore title]" "[Chore description]" --parent=${FEATURE_ID}
@@ -600,24 +740,24 @@ Replace `${FEATURE_ID}` with actual ID. Example:
 jettypod work create chore "Set up auth routes" "Create login/logout endpoints..." --parent=42
 ```
 
-**CRITICAL: Copy the EXACT proposal from Step 7 into each chore description.** Do not paraphrase or summarize - the implementation guidance must be preserved verbatim:
+**CRITICAL: Copy the EXACT proposal from Step 10 into each chore description.** Do not paraphrase or summarize - the implementation guidance must be preserved verbatim:
 
 ```
-[Technical description from Step 7]
+[Technical description from Step 10]
 
 Scenario steps addressed:
-• [EXACT steps from Step 7]
+• [EXACT steps from Step 10]
 
 Implementation guidance:
-• Files to create/modify: [EXACT paths from Step 7]
-• Patterns to follow: [EXACT references from Step 7]
-• Key functions/components needed: [EXACT list from Step 7]
+• Files to create/modify: [EXACT paths from Step 10]
+• Patterns to follow: [EXACT references from Step 10]
+• Key functions/components needed: [EXACT list from Step 10]
 
 Verification:
-• [EXACT step definitions from Step 7]
+• [EXACT step definitions from Step 10]
 ```
 
-#### Step 8C: Execute Transition
+#### Sub-step C: Execute Transition
 
 **After ALL chores are created, use Bash tool to EXECUTE the work implement command:**
 
@@ -636,8 +776,8 @@ jettypod work implement 42 --winner="Simple inline form" --rationale="Fastest UX
 
 **If the command fails**, check the error message:
 - "Feature not found" → Verify the feature ID
-- "No chores exist" → You skipped Step 8B - go back and create chores first
-- "Already in implementation" → Feature was already transitioned, proceed to Step 8D
+- "No chores exist" → You skipped Sub-step B - go back and create chores first
+- "Already in implementation" → Feature was already transitioned, proceed to Step 12
 
 After successful transition, display:
 
@@ -645,134 +785,20 @@ After successful transition, display:
 ✅ Feature transitioned to implementation phase
 ✅ Created X chores for speed mode
 
-Now I'll write the BDD tests in an isolated worktree...
+Now I'll merge the BDD tests to main...
 ```
 
 **🔄 WORKFLOW CHECKPOINT: Implementation transition complete**
 
 ```bash
-jettypod workflow checkpoint <feature-id> --step=8
-```
-
-**Proceed to Step 8D.**
-
-#### Step 8D: Write Tests in Isolated Worktree
-
-**CRITICAL:** Tests are written in an isolated worktree, not directly on main. This ensures agent failures don't leave uncommitted garbage on main.
-
-**🚫 FORBIDDEN: Manual Git Worktree Commands**
-```
-❌ git worktree add ...
-❌ git checkout -b tests/...
-❌ git branch tests/...
-```
-**ALWAYS use jettypod commands** - they handle branch naming, path conventions, database tracking, and cleanup. Manual git commands will create orphaned worktrees that break the merge workflow.
-
-**Sub-step 1: Create test worktree**
-
-```bash
-jettypod work tests start ${FEATURE_ID}
-```
-
-This creates:
-- Worktree at `.jettypod-work/tests-<id>-<slug>/`
-- Branch `tests/feature-<id>-<slug>`
-
-**Capture the worktree path from output** - you'll need it for file operations.
-
-Example output:
-```
-✅ Created test worktree: /path/to/.jettypod-work/tests-42-email-login
-Branch: tests/feature-42-email-login
-
-Write your BDD files to:
-  <worktree>/features/email-login.feature
-  <worktree>/features/step_definitions/email-login.steps.js
-
-When done, merge then cleanup:
-  jettypod work tests merge 42
-  cd /path/to/main/repo
-  jettypod work cleanup 42
-```
-
-**🛑 STOP AND CHECK:** Verify worktree was created successfully. If you see an error, investigate before continuing.
-
-**Sub-step 2: Write BDD files in the worktree**
-
-Using the scenarios you confirmed in Step 6B, write the files using **absolute paths to the worktree**:
-
-**A. Write scenario file** using Write tool:
-```
-<worktree_path>/features/${FEATURE_SLUG}.feature
-```
-
-**B. Write step definitions file** using Write tool:
-```
-<worktree_path>/features/step_definitions/${FEATURE_SLUG}.steps.js
-```
-
-**Step definition requirements:**
-1. Implement all Given/When/Then steps from the scenarios
-2. Follow existing patterns - check other `.steps.js` files for conventions
-3. Include test environment setup/cleanup
-4. All Given steps (setup state)
-5. All When steps (execute actions)
-6. All Then steps (verify outcomes)
-
-**Sub-step 3: Validate BDD infrastructure**
-
-Run cucumber dry-run **from within the worktree**:
-
-```bash
-cd <worktree_path> && npx cucumber-js --dry-run features/${FEATURE_SLUG}.feature
+jettypod workflow checkpoint <feature-id> --step=11
 ```
 
-**What the output means:**
-
-✅ **Success** - No errors, all steps have definitions:
-```
-0 scenarios
-0 steps
-```
-(Dry-run doesn't execute, so 0 is correct)
+**Proceed to Step 12.**
 
-❌ **Undefined steps** - Missing step definitions:
-```
-Undefined. Implement with the following snippet:
-  Given('I am on the login page', function () {
-    ...
-  });
-```
-→ Add the missing step definition to your `.steps.js` file
-
-❌ **Syntax error** - Invalid Gherkin:
-```
-Parse error in features/foo.feature
-```
-→ Fix the feature file syntax
-
-❌ **Duplicate steps** - Multiple definitions match:
-```
-Multiple step definitions match
-```
-→ Remove or rename one of the duplicate step definitions
-
-**If validation fails:**
-1. Read the error message carefully
-2. Fix the step definitions or scenario file **in the worktree**
-3. Re-run the dry-run command
-4. **Loop until validation passes** - do NOT proceed until green
-
-**If validation succeeds:**
-Display: "✅ BDD infrastructure validated - all steps have definitions"
-
-**Sub-step 4: Update database with scenario file path**
-
-```bash
-sqlite3 .jettypod/work.db "UPDATE work_items SET scenario_file = 'features/${FEATURE_SLUG}.feature' WHERE id = ${FEATURE_ID}"
-```
+### Step 12: Merge Tests to Main
 
-**Sub-step 5: Merge tests to main**
+The BDD files were written in Step 9. Now merge them to main.
 
 **Merge and cleanup (3 steps):**
 
@@ -799,7 +825,7 @@ This will:
 - Mark worktree as merged (cleanup is separate)
 
 **🛑 STOP AND CHECK:** Verify merge succeeded:
-- ✅ "Tests merged to main" → Proceed to Step 8E
+- ✅ "Tests merged to main" → Proceed to Step 13
 - ❌ Error → Investigate, worktree still exists for debugging
 
 **After successful merge, display:**
@@ -832,9 +858,9 @@ 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.**
+**Proceed to Step 13.**
 
-#### Step 8E: Start First Chore
+### Step 13: Start First Chore
 
 **Feature planning is now complete.** The feature has been transitioned to implementation phase, tests are on main, and chores are ready.
 
@@ -957,15 +983,15 @@ Before completing feature planning, ensure:
 - [ ] Exactly 3 approaches suggested
 - [ ] Winner chosen (with prototypes or without)
 - [ ] **Integration Contract defined** (entry point, caller code, integration scenario)
+- [ ] **Test worktree created** with `work tests start` (Step 7)
 - [ ] **Integration Scenario is FIRST scenario** in proposed scenarios
-- [ ] BDD scenarios **proposed and confirmed** by user (Step 6B)
+- [ ] BDD scenarios **proposed and confirmed** by user (Step 8)
+- [ ] **BDD files written** in worktree using `WORKTREE_PATH` (Step 9)
+- [ ] **BDD infrastructure validated** with dry-run (Step 9)
 - [ ] **At least one Integration Chore proposed** (wires feature into app)
-- [ ] Speed mode chores proposed and confirmed (Step 7)
-- [ ] Chores created in database (Step 8B)
-- [ ] Feature transitioned to implementation with `work implement` (Step 8C)
-- [ ] **Test worktree created** with `work tests start` (Step 8D)
-- [ ] **BDD files written** in worktree (Step 8D)
-- [ ] **BDD infrastructure validated** with dry-run (Step 8D)
-- [ ] **Tests merged to main** with `work tests merge` → `cd` → `work cleanup` (Step 8D)
-- [ ] First chore started with `work start [chore-id]` (Step 8E)
-- [ ] **Speed-mode skill invoked using Skill tool** (Step 8E)
+- [ ] Speed mode chores proposed and confirmed (Step 10)
+- [ ] Chores created in database (Step 11)
+- [ ] Feature transitioned to implementation with `work implement` (Step 11)
+- [ ] **Tests merged to main** with `work tests merge` → `cd` → `work cleanup` (Step 12)
+- [ ] First chore started with `work start [chore-id]` (Step 13)
+- [ ] **Speed-mode skill invoked using Skill tool** (Step 13)

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

@@ -30,12 +30,72 @@ When this skill is activated, you are helping implement a production mode chore
 
 ---
 
+## 🛑 PRE-FLIGHT VALIDATION (REQUIRED)
+
+**Before proceeding with ANY implementation, you MUST validate the worktree exists.**
+
+Run this query FIRST:
+
+```bash
+sqlite3 .jettypod/work.db "SELECT wi.id, wi.title, wi.status, wt.worktree_path, wt.branch_name FROM work_items wi LEFT JOIN worktrees wt ON wi.id = wt.work_item_id WHERE wi.status = 'in_progress' AND wi.type = 'chore'"
+```
+
+**Check the result:**
+
+| worktree_path | What it means | Action |
+|---------------|---------------|--------|
+| **Has a path** (e.g., `/path/to/.jettypod-work/...`) | ✅ Worktree exists, ready to proceed | Continue to Step 0 |
+| **NULL or empty** | ❌ `work start` was not called | **STOP - run `jettypod work start [chore-id]` first** |
+| **No rows returned** | ❌ No chore is in progress | **STOP - verify the chore exists and run `work start`** |
+
+**🛑 STOP GATE:** If `worktree_path` is NULL or no rows returned, you MUST run `jettypod work start [chore-id]` before continuing. DO NOT proceed without a valid worktree.
+
+**🚫 FORBIDDEN: Manual Git Worktree Commands**
+```
+❌ git worktree add ...
+❌ git checkout -b feature/...
+❌ git branch feature/...
+```
+**ALWAYS use `jettypod work start`** - it handles branch naming, path conventions, database tracking, and cleanup. Manual git commands will create orphaned worktrees that break the merge workflow.
+
+---
+
+## 🔒 WORKTREE PATH LOCK
+
+**After pre-flight validation passes, capture and lock the worktree path:**
+
+From the pre-flight query output, extract and store:
+- `WORKTREE_PATH` - the absolute path to the worktree
+
+**Display:**
+
+```
+🔒 WORKTREE LOCK ACTIVE
+Path: ${WORKTREE_PATH}
+
+All file writes will use this path.
+```
+
+**From this point forward, ALL file operations MUST use paths starting with `${WORKTREE_PATH}/`**
+
+This lock prevents accidental writes to the main repository.
+
+---
+
 ## Implementation Steps
 
 ### Step 0: Detect Production Context (CRITICAL FIRST STEP)
 
 **MUST RUN FIRST:** Detect which scenario applies to this feature.
 
+**🚫 FORBIDDEN: Writing Files at This Step**
+```
+❌ Write tool to any path
+❌ Edit tool to any path
+❌ Any file creation or modification
+```
+**This is a DETECTION step.** File writes happen in Step 3.
+
 **To detect context, check these conditions:**
 
 ```bash
@@ -89,6 +149,14 @@ This validates that `stable_mode_complete` gate is passed and creates an executi
 
 **For all scenarios:** Read production standards file.
 
+**🚫 FORBIDDEN: Writing Files at This Step**
+```
+❌ Write tool to any path
+❌ Edit tool to any path
+❌ Any file creation or modification
+```
+**This is a READ step.** File writes happen in Step 3.
+
 ```bash
 # Check if production standards file exists
 ls .jettypod/production-standards.json
@@ -111,6 +179,14 @@ jettypod workflow checkpoint <feature-id> --step=1
 
 **For Scenario A only:** Quick validation of existing scenarios.
 
+**🚫 FORBIDDEN: Writing Files at This Step**
+```
+❌ Write tool to any path
+❌ Edit tool to any path
+❌ Any file creation or modification
+```
+**This is a VALIDATION step.** File writes happen in Step 3.
+
 ```javascript
 const { validateScenarios } = require('../../lib/production-scenario-validator');
 const { getDb } = require('../../lib/database');
@@ -168,6 +244,14 @@ try {
 
 **For Scenario B only:** Re-validate with current standards.
 
+**🚫 FORBIDDEN: Writing Files at This Step**
+```
+❌ Write tool to any path
+❌ Edit tool to any path
+❌ Any file creation or modification
+```
+**This is a VALIDATION step.** File writes happen in Step 3.
+
 ```javascript
 const { validateScenarios } = require('../../lib/production-scenario-validator');
 const config = require('../../lib/config');
@@ -223,6 +307,14 @@ try {
 
 **For Scenario C only:** Generate production scenarios from standards.
 
+**🚫 FORBIDDEN: Writing Files at This Step**
+```
+❌ Write tool to any path
+❌ Edit tool to any path
+❌ Any file creation or modification
+```
+**This is a GENERATION step (via jettypod commands, not direct file writes).** File writes happen in Step 3.
+
 ```bash
 # Get feature details
 sqlite3 .jettypod/work.db "SELECT id, title, scenario_file FROM work_items WHERE id = <feature-id>"
@@ -247,6 +339,10 @@ jettypod workflow checkpoint <feature-id> --step=2
 
 ### Step 3: Implement Production Chore
 
+**🔒 WORKTREE PATH REQUIRED:** All file writes MUST use the `WORKTREE_PATH` captured after pre-flight validation.
+
+**✅ NOW you may write files** - worktree is locked, context is detected.
+
 **For all scenarios:** Implement the current production chore with test-driven iteration.
 
 **Get current work and identify target scenario:**

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

@@ -102,6 +102,28 @@ sqlite3 .jettypod/work.db "SELECT wi.id, wi.title, wi.status, wt.worktree_path,
 
 ---
 
+## 🔒 WORKTREE PATH LOCK
+
+**After pre-flight validation passes, capture and lock the worktree path:**
+
+From the pre-flight query output, extract and store:
+- `WORKTREE_PATH` - the absolute path to the worktree (e.g., `/path/to/.jettypod-work/4-add-nav-link`)
+
+**Display:**
+```
+🔒 WORKTREE LOCK ACTIVE
+Path: ${WORKTREE_PATH}
+
+All file writes will use this path.
+```
+
+**From this point forward, ALL file operations MUST use paths starting with:**
+```
+${WORKTREE_PATH}/
+```
+
+---
+
 ### Overview
 
 **Speed Mode Goal:** Make it work - implement ALL functionality (integration + required + optional features) to make success scenarios pass, assuming everything works correctly.
@@ -269,6 +291,14 @@ Analyzing BDD scenarios to determine implementation approach...
 
 ### Step 1: Check for Breadcrumbs and Analyze Scenario
 
+**🚫 FORBIDDEN: Writing Files at This Step**
+```
+❌ Write tool to any path
+❌ Edit tool to any path
+❌ Any file creation or modification
+```
+**This is an ANALYSIS step.** File writes happen in Step 5.
+
 **CRITICAL:** Claude Code executes this autonomously - no user permission needed.
 
 **Your task:**
@@ -340,6 +370,14 @@ Now analyzing codebase to propose implementation...
 
 ### Step 2: Autonomous Codebase Analysis
 
+**🚫 FORBIDDEN: Writing Files at This Step**
+```
+❌ Write tool to any path
+❌ Edit tool to any path
+❌ Any file creation or modification
+```
+**This is an ANALYSIS step.** File writes happen in Step 5.
+
 **CRITICAL:** Claude Code executes this autonomously - no user permission needed.
 
 **Your task:**
@@ -416,6 +454,14 @@ jettypod workflow checkpoint <feature-id> --step=2
 
 ### Step 3: Decide if Confirmation Needed
 
+**🚫 FORBIDDEN: Writing Files at This Step**
+```
+❌ Write tool to any path
+❌ Edit tool to any path
+❌ Any file creation or modification
+```
+**This is a DECISION step.** File writes happen in Step 5.
+
 **Evaluate if you need user confirmation before implementing:**
 
 **Skip confirmation (proceed directly to Step 4) if:**
@@ -432,6 +478,14 @@ jettypod workflow checkpoint <feature-id> --step=2
 
 ### Step 3A: Propose Implementation Approach (Conditional)
 
+**🚫 FORBIDDEN: Writing Files at This Step**
+```
+❌ Write tool to any path
+❌ Edit tool to any path
+❌ Any file creation or modification
+```
+**This is a PROPOSAL step.** File writes happen in Step 5.
+
 **⚡ ASYNC BOUNDARY - Only execute this if confirmation needed**
 
 **Present your analysis and proposal to the user:**
@@ -514,6 +568,10 @@ jettypod workflow checkpoint <feature-id> --step=4
 
 ### Step 5: RED→GREEN→REFACTOR Loop
 
+**🔒 WORKTREE PATH REQUIRED:** All file writes MUST use the `WORKTREE_PATH` captured after pre-flight validation.
+
+**✅ NOW you may write files** - worktree is locked, approach is confirmed.
+
 **Execute autonomously** - iterate until tests pass (max 10 iterations).
 
 **Each iteration (True TDD):**

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

@@ -109,6 +109,28 @@ sqlite3 .jettypod/work.db "SELECT wi.id, wi.title, wi.status, wt.worktree_path,
 
 ---
 
+## 🔒 WORKTREE PATH LOCK
+
+**After pre-flight validation passes, capture and lock the worktree path:**
+
+From the pre-flight query output, extract and store:
+- `WORKTREE_PATH` - the absolute path to the worktree
+
+**Display:**
+
+```
+🔒 WORKTREE LOCK ACTIVE
+Path: ${WORKTREE_PATH}
+
+All file writes will use this path.
+```
+
+**From this point forward, ALL file operations MUST use paths starting with `${WORKTREE_PATH}/`**
+
+This lock prevents accidental writes to the main repository.
+
+---
+
 ### Overview
 
 **Stable Mode Goal:** Transform speed mode's "make it work" implementation into robust, reliable code with comprehensive error handling and validation.
@@ -271,6 +293,14 @@ Analyzing stable mode BDD scenarios to determine what error handling and validat
 
 **CRITICAL:** Claude Code executes this autonomously - no user permission needed.
 
+**🚫 FORBIDDEN: Writing Files at This Step**
+```
+❌ Write tool to any path
+❌ Edit tool to any path
+❌ Any file creation or modification
+```
+**This is an ANALYSIS step.** File writes happen in Step 5.
+
 **Your task:**
 1. Get current work item and parent feature's scenario file
 2. Read the full scenario file (should have success scenarios + stable mode error/edge case scenarios)
@@ -328,6 +358,14 @@ Now reviewing speed mode implementation...
 
 **CRITICAL:** Claude Code executes this autonomously - no user permission needed.
 
+**🚫 FORBIDDEN: Writing Files at This Step**
+```
+❌ Write tool to any path
+❌ Edit tool to any path
+❌ Any file creation or modification
+```
+**This is an ANALYSIS step.** File writes happen in Step 5.
+
 **Your task:**
 1. Find files created/modified in speed mode
 2. Read the existing implementation
@@ -380,6 +418,14 @@ jettypod workflow checkpoint <feature-id> --step=2
 
 ### Step 3: Decide if Confirmation Needed
 
+**🚫 FORBIDDEN: Writing Files at This Step**
+```
+❌ Write tool to any path
+❌ Edit tool to any path
+❌ Any file creation or modification
+```
+**This is a DECISION step.** File writes happen in Step 5.
+
 **Evaluate if you need user confirmation before implementing:**
 
 **Skip confirmation (proceed directly to Step 4) if:**
@@ -398,6 +444,14 @@ jettypod workflow checkpoint <feature-id> --step=2
 
 **⚡ ASYNC BOUNDARY - Only execute this if confirmation needed**
 
+**🚫 FORBIDDEN: Writing Files at This Step**
+```
+❌ Write tool to any path
+❌ Edit tool to any path
+❌ Any file creation or modification
+```
+**This is a PROPOSAL step.** File writes happen in Step 5.
+
 **Present your analysis and proposal to the user:**
 
 ```
@@ -496,6 +550,10 @@ jettypod workflow checkpoint <feature-id> --step=4
 
 ### Step 5: RED→GREEN→REFACTOR Loop
 
+**🔒 WORKTREE PATH REQUIRED:** All file writes MUST use the `WORKTREE_PATH` captured after pre-flight validation.
+
+**✅ NOW you may write files** - worktree is locked, approach is confirmed.
+
 **Execute autonomously** - iterate until tests pass (max 10 iterations).
 
 **Each iteration (True TDD):**