jettypod 4.1.2 → 4.1.4

package/SYSTEM-BEHAVIOR.md

@@ -1,2199 +0,0 @@
-# JettyPod System Behaviors
-
-*Auto-generated from test scenarios on 2025-11-12*
-
-## Summary
-
-- **19** features
-- **116** test scenarios
-- **619** test steps
-
-## Table of Contents
-
-- [Auto-Generate Production Chores at End of Stable Mode](#auto-generate-production-chores-at-end-of-stable-mode) (0 scenarios)
-- [Backlog Command](#backlog-command) (3 scenarios)
-- [Backlog Filtering for Production Items](#backlog-filtering-for-production-items) (0 scenarios)
-- [Fix Text Wrapping in Terminal Output](#fix-text-wrapping-in-terminal-output) (4 scenarios)
-- [Git Hook Integration](#git-hook-integration) (4 scenarios)
-- [Git Hooks Integration](#git-hooks-integration) (1 scenarios)
-- [JettyPod update command](#jettypod-update-command) (5 scenarios)
-- [Mode Change Prompts](#mode-change-prompts) (1 scenarios)
-- [Multiple Claude Code instances coordination](#multiple-claude-code-instances-coordination) (14 scenarios)
-- [Production Mode Skill](#production-mode-skill) (14 scenarios)
-- [Refactor Mode](#refactor-mode) (5 scenarios)
-- [Simplify External Transition Command](#simplify-external-transition-command) (17 scenarios)
-- [Terminal Logo Display](#terminal-logo-display) (4 scenarios)
-- [Bug Workflow Display](#bug-workflow-display) (2 scenarios)
-- [Work Commands - Stable Mode](#work-commands-stable-mode) (10 scenarios)
-- [Work Item Commands](#work-item-commands) (1 scenarios)
-- [Mode defaults to discovery on work item creation](#mode-defaults-to-discovery-on-work-item-creation) (14 scenarios)
-- [Work set-mode updates CLAUDE.md if item is current](#work-set-mode-updates-claude-md-if-item-is-current) (6 scenarios)
-- [Work start sets CLAUDE.md mode from work item](#work-start-sets-claude-md-mode-from-work-item) (11 scenarios)
-
----
-
-## What JettyPod Does
-
-This documentation is derived from actual passing tests. It describes the verified behaviors of the system.
-
-### Auto-Generate Production Chores at End of Stable Mode
-
-*Related features: Auto-Generate Production Chores at End of Stable Mode*
-
-**Verified behaviors:**
-
----
-
-### Backlog Command
-
-*Related features: Backlog Command*
-
-**Verified behaviors:**
-
-- **User views active backlog items**
-  When I have work items in various statuses, I run "jettypod backlog" → I see only active work items (backlog, todo, in_progress) and I see the items in a tree hierarchy and completed items are hidden
-
-- **User views all work items including completed**
-  When I have work items in various statuses, I run "jettypod backlog all" → I see all work items regardless of status and I see the items in a tree hierarchy
-
-- **User views only completed items**
-  When I have work items in various statuses, I run "jettypod backlog completed" → I see only completed work items (done, cancelled) and I see the items in a tree hierarchy
-
----
-
-### Backlog Filtering for Production Items
-
-*Related features: Backlog Filtering for Production Items*
-
-**Verified behaviors:**
-
----
-
-### Fix Text Wrapping in Terminal Output
-
-*Related features: Fix Text Wrapping in Terminal Output*
-
-**Verified behaviors:**
-
-- **Long titles wrap at word boundaries within terminal width**
-  When I have a feature with a title longer than the terminal width, I run jettypod backlog with current terminal width → the title wraps at word boundaries and continuation lines align with the content indentation and no words are split mid-character
-
-- **Long descriptions wrap cleanly in expanded view**
-  When I have a feature with a long description, I run jettypod backlog --expand=1 with current terminal width → the description wraps at word boundaries and continuation lines have proper "Description: " prefix indentation and the text fits within terminal width
-
-- **Tree structure preserved with wrapped text**
-  When I have nested items with long titles, I run jettypod backlog --expand=all with current terminal width → tree connectors (├──, └──) display correctly and wrapped continuation lines align under the item content and tree structure remains visually clear
-
-- **Terminal width changes are respected**
-  When the terminal width is 120 columns, I have items with titles that wrap at 120 columns, the terminal is resized to 80 columns and I run jettypod backlog with current terminal width → text wraps to fit 80 columns and alignment adjusts to the new width
-
----
-
-### Git Hook Integration
-
-*Related features: Git Hook Integration*
-
-**Verified behaviors:**
-
-- **First commit updates status to in_progress**
-  When I have a work item with status "todo", the work item is set as current work, I make my first commit → the work item status should be "in_progress"
-
-- **Merge to main updates status to done**
-  When I have a work item with status "in_progress", the work item is set as current work, I am on a feature branch, I merge to main → the work item status should be "done"
-
-- **No current work item - hooks do nothing**
-  When no work item is set as current, I make a commit → no errors occur
-
-- **Integration - hooks work with existing work commands**
-  When I have initialized jettypod with git, I create a work item via work commands, I start work on the item, I commit changes → the work item status updates automatically and the current work file still exists
-
----
-
-### Git Hooks Integration
-
-*Related features: Git Hooks Integration*
-
-**Verified behaviors:**
-
-- **Integration - post-commit hook updates status**
-  When I initialize a git repo with jettypod, I create and start work on a todo item, I make a commit → the hook updates status to in_progress
-
----
-
-### JettyPod update command
-
-*Related features: JettyPod update command*
-
-**Verified behaviors:**
-
-- **User runs jettypod update when new version is available**
-  When jettypod version 3.0.0 is installed, npm registry has version 3.1.0 available, I run update command "jettypod update" → jettypod checks npm registry for latest version and jettypod shows "New version available: 3.1.0 (current: 3.0.0)" and jettypod downloads and installs version 3.1.0 and skills are refreshed in current project and jettypod shows "✅ JettyPod updated to 3.1.0"
-
-- **User runs jettypod update when already on latest version**
-  When jettypod version 3.1.0 is installed, npm registry has version 3.1.0 available, I run update command "jettypod update" → jettypod checks npm registry for latest version and jettypod shows "Already on latest version: 3.1.0" and skills are refreshed in current project
-
-- **User runs jettypod update without internet connection**
-  When jettypod is installed, there is no internet connection, I run update command "jettypod update" → jettypod shows "Cannot check for updates: network error" and skills are still refreshed in current project using existing jettypod
-
-- **Command rename - jettypod without init creates new project**
-  When I am in a directory without .claude/, I run update command "jettypod" → jettypod initializes the project and .claude/ directory is created and CLAUDE.md is created and skills are installed
-
-- **Backwards compatibility - jettypod init still works**
-  When I am in a directory without .claude/, I run update command "jettypod init" → jettypod initializes the project and .claude/ directory is created and CLAUDE.md is created and skills are installed
-
----
-
-### Mode Change Prompts
-
-*Related features: Mode Change Prompts*
-
-**Verified behaviors:**
-
-- **Integration - mode change with work item present**
-  When I have jettypod with a work item in progress, I check current work exists → the work item has a status
-
----
-
-### Multiple Claude Code instances coordination
-
-*Related features: Multiple Claude Code instances coordination*
-
-**Verified behaviors:**
-
-- **Single Claude instance pushes to main without queue**
-  When I am a Claude Code instance with completed work, I have committed my changes locally, the push queue is empty, main branch has no new commits, I attempt to push to main → I push directly to main and I do not create a queue entry
-
-- **First Claude instance creates queue entry when main is ahead**
-  When I am a Claude Code instance with completed work, I have committed my changes locally, the push queue is empty, main branch has 2 new commits since my work started, I attempt to push to main → I create a queue entry at position 1 and I see "Added to push queue (position 1)" and I rebase my commits on top of main and I push to main and I remove my queue entry
-
-- **Second Claude waits for first to complete**
-  When Claude instance A is at position 1 in the push queue, I am a Claude Code instance with completed work, I have committed my changes locally, I attempt to push to main → I create a queue entry at position 2 and I see "Added to push queue (position 2, waiting for 1 commit ahead)" and I do not push yet and I wait for position 1 to complete
-
-- **Queue processes sequentially when first completes**
-  When Claude instance A is at position 1 and is pushing, I am at position 2 in the queue, Claude instance A completes their push → I move to position 1 and I rebase my commits on top of the updated main and I push to main and I remove my queue entry
-
-- **Queue file corrupted or contains invalid JSON**
-  When the push queue file exists but contains invalid JSON, I attempt to push to main → I should see an error message about corrupted queue file and the system should initialize a new empty queue and I should be able to push successfully
-
-- **Queue file cannot be written due to permissions**
-  When the .jettypod directory has no write permissions, I attempt to push to main → I should see an error about insufficient permissions and the system should provide guidance to fix permissions and the push should not proceed
-
-- **Git rebase fails with conflicts**
-  When I am at position 1 in the queue, my changes conflict with changes on main, I attempt to rebase on main → I should see a clear error about rebase conflicts and I should receive guidance on how to resolve conflicts and my queue entry should remain until conflicts are resolved
-
-- **Git fetch fails due to network issues**
-  When I am checking if main has moved ahead, git fetch fails due to network connectivity → I should see an error about network failure and the system should suggest retry or check connectivity and the push should not proceed
-
-- **Git push fails after successful rebase**
-  When I have successfully rebased on main, git push fails due to remote rejection → I should see a clear error message and my queue entry should remain for retry and the system should not corrupt the queue state
-
-- **Invalid queue entry with missing fields**
-  When the queue contains an entry with missing instanceId, the queue processor attempts to process entries → invalid entries should be removed from queue and valid entries should continue processing and a warning should be logged about invalid entries
-
-- **Stale queue entry from crashed instance**
-  When a queue entry has been waiting for over 1 hour, the instance that created it is no longer running, queue cleanup runs → the stale entry should be removed and subsequent entries should advance in position and a notification should be logged
-
-- **Multiple instances try to write queue simultaneously**
-  When two Claude instances both try to add queue entries at same time, concurrent queue writes occur → both entries should be successfully added and no queue corruption should occur and positions should be correctly assigned
-
-- **Empty commit SHA provided to queue**
-  When I attempt to add a queue entry with empty commit SHA, validation runs → I should see an error about invalid commit SHA and no queue entry should be created and guidance should be provided
-
-- **Queue position monitoring with removed entries**
-  When I am at position 3 in the queue, entry at position 1 is removed (not completed normally) → I should move to position 2 and I should be notified of position change and queue integrity should be maintained
-
----
-
-### Production Mode Skill
-
-*Related features: Production Mode Skill*
-
-**Verified behaviors:**
-
-- **Fresh from stable mode - Quick validation (Scenario A)**
-  When a feature just completed stable mode within 1 day, production scenarios already exist in the feature file, production chores already exist for the feature, production standards file exists, I start the production-mode skill for this feature → it detects Scenario A (hot context) and it validates existing scenarios against current standards and it identifies no gaps and it proceeds to implement existing production chores
-
-- **Gap in time - Re-validation (Scenario B)**
-  When a feature completed stable mode over 7 days ago, production scenarios exist in the feature file, production chores exist for the feature, production standards file exists, I start the production-mode skill for this feature → it detects Scenario B (cold context) and it re-validates existing scenarios against current standards and it checks if project state changed since stable mode and it identifies any gaps in standards coverage and it updates scenarios if needed
-
-- **Post external-transition - Generate from standards (Scenario C)**
-  When a feature in stable mode with no production scenarios, no production chores exist for the feature, production standards file exists from external-transition, I start the production-mode skill for this feature → it detects Scenario C (post-transition) and it reads production standards from file and it generates production scenarios from activated standards and it appends scenarios to the feature file and it proposes production chores based on standards and it creates chores after user confirmation
-
-- **Missing production standards file**
-  When a feature in stable mode, the production standards file does not exist at .jettypod/production-standards.json, I start the production-mode skill for this feature → it fails with error "Production standards file not found" and it suggests running external-transition first
-
-- **Corrupted production standards file**
-  When a feature in stable mode, the production standards file exists but contains malformed JSON, I start the production-mode skill for this feature → it fails with error "Failed to parse production standards" and it shows the JSON parsing error details
-
-- **Invalid production standards format**
-  When a feature in stable mode, the production standards file exists with valid JSON, I start the production-mode skill for this feature → it fails with error "Invalid standards format" and it specifies which required fields are missing
-
-- **Missing scenario file for feature**
-  When a feature in stable mode, the feature has no scenario_file set in database, I start the production-mode skill for this feature → it fails with error "Feature has no scenario file" and it suggests the feature may not be properly initialized
-
-- **Scenario file does not exist on disk**
-  When a feature in stable mode, the feature has scenario_file set in database, I start the production-mode skill for this feature → it fails with error "Scenario file not found" and it shows the expected file path
-
-- **Feature not found in database**
-  When an invalid feature ID, I start the production-mode skill with that feature ID → it fails with error "Feature not found"
-
-- **Feature has no completed_at timestamp**
-  When a feature marked as done in stable mode, the context detector checks time since stable completion → it treats this as Scenario C (no production content yet)
-
-- **File permission error reading standards**
-  When a feature in stable mode, the production standards file exists, I start the production-mode skill for this feature → it fails with error indicating permission denied and it shows the file path with permission issues
-
-- **File permission error writing scenarios**
-  When a feature in Scenario C (generating scenarios), production standards are loaded successfully, attempting to append scenarios to the file → it fails with error indicating write permission denied
-
-- **Empty standards array**
-  When a feature in stable mode, the production standards file exists with empty standards array, I start the production-mode skill for this feature → it completes successfully and reports 0 standards to implement
-
-- **Database connection error**
-  When the database file is locked or corrupted, I start the production-mode skill → it fails with database error and it suggests checking database integrity
-
----
-
-### Refactor Mode
-
-*Related features: Refactor Mode*
-
-**Verified behaviors:**
-
-- **Refactor mode integrates with work tracking**
-  When I have existing work items in the system, I enter refactor mode and audit the codebase and I select "Architectural" category and I approve creating chores for storage pattern → refactor chores are created under an epic and the epic is linked to the refactor mode work item
-
-- **User enters refactor mode and sees audit menu**
-  When I'm in a project with technical debt, I enter refactor mode → Claude audits the codebase and I see categorized menu with counts:
-
-- **User picks category and sees detailed breakdown**
-  When I see the audit menu, I pick "Architectural" category → I see detailed items with:
-
-- **Claude recommends quick wins**
-  When I see the detailed breakdown for "Architectural", Claude analyzes impact vs time → I see recommendation: "Start with Storage Pattern (quick win, high impact)" and I see warning: "Skip State Management (needs Discovery Mode first)"
-
-- **User approves and chores are created**
-  When I see recommendations for Storage Pattern, I say "create chores" → epic "Refactor: Architectural patterns" is created and chore "Create shared storage util" is created and chore "Migrate auth to storage util" is created and all chores are linked to the epic
-
----
-
-### Simplify External Transition Command
-
-*Related features: Simplify External Transition Command*
-
-**Verified behaviors:**
-
-- **User transitions project to external state**
-  When I have a JettyPod project in internal state, I have some features in stable mode with production chores already created, I run "jettypod project external" → the project_state should be updated to "external" and an "Infrastructure Readiness" epic should be created and 4 infrastructure features should be created under the epic and 15 infrastructure chores should be created across the features and production mode work items should now be visible in the backlog and no duplicate production chores should be created for existing features
-
-- **Project already in external state**
-  When I have a JettyPod project in external state, I run "jettypod project external" → I should see a message "Project already in external state" and no duplicate infrastructure items should be created and the command should exit successfully
-
-- **Infrastructure epic already exists**
-  When I have a JettyPod project in internal state, an "Infrastructure Readiness" epic already exists, I run "jettypod project external" → the project_state should be updated to "external" and no duplicate "Infrastructure Readiness" epic should be created and existing infrastructure items should be preserved and I should see a message about existing infrastructure
-
-- **Database connection fails during transition**
-  When I have a JettyPod project in internal state, the database connection will fail, I run "jettypod project external" → I should see a clear error message about database failure and the project_state should remain "internal" and no partial infrastructure items should be created
-
-- **Work item creation fails mid-transition**
-  When I have a JettyPod project in internal state, work item creation will fail after creating the epic, I run "jettypod project external" → I should see an error message about failed creation and the project_state should remain "internal" and any partial work items should be cleaned up
-
-- **Invalid checklist data structure**
-  When I have a JettyPod project in internal state, the infrastructure checklist has invalid data, I run "jettypod project external" → I should see a validation error message and the project_state should remain "internal" and no infrastructure items should be created
-
-- **Infrastructure chores generated from production standards**
-  When I have a JettyPod project in internal state, I have production standards with infrastructure-scoped standards, the standards include "database_backups" in infrastructure scope, the standards include "monitoring_setup" in infrastructure scope, I run "jettypod project external" → infrastructure chores should be created from standards and each infrastructure standard should create one chore and chore descriptions should include acceptance criteria from standards and chore descriptions should include reasoning from standards and no static checklist should be used
-
-- **Different presets create different infrastructure chores**
-  When I have a JettyPod project in internal state, production standards are set to "startup-mvp" preset, I run "jettypod project external" and I change production standards to "enterprise" preset → infrastructure chores should match startup-mvp standards and I should see fewer infrastructure chores than enterprise preset and I run "jettypod project external" on a new project and infrastructure chores should match enterprise standards and I should see more infrastructure chores than startup-mvp preset and additional chores should include multi-region setup and additional chores should include advanced monitoring
-
-- **Scope field correctly filters infrastructure vs feature standards**
-  When I have a JettyPod project in internal state, production standards include 5 infrastructure-scoped standards, production standards include 8 feature-scoped standards, I run "jettypod project external" → exactly 5 infrastructure chores should be created and no feature-scoped standards should create infrastructure chores and feature-scoped standards should be reserved for feature production chores
-
-- **Infrastructure chore created per standard (not grouped by domain)**
-  When I have a JettyPod project in internal state, production standards include 3 security infrastructure standards, production standards include 2 monitoring infrastructure standards, I run "jettypod project external" → 5 separate infrastructure chores should be created and each chore should reference exactly one standard and chores should not be grouped by domain and each chore title should describe the specific standard
-
-- **Missing production standards file during transition**
-  When I have a JettyPod project in internal state, no production standards file exists, I run "jettypod project external" → I should see an error "Production standards file not found" and I should be prompted to run external transition interactively and the project_state should remain "internal" and no infrastructure items should be created
-
-- **Infrastructure chores include pattern guidance from standards**
-  When I have a JettyPod project in internal state, production standards include a standard with pattern guidance, the standard has pattern "Use pg_dump with --clean flag", I run "jettypod project external" → the created chore should include the pattern in description and the pattern should be labeled "Pattern:" in the description and developers should have clear implementation guidance
-
-- **Audit logging for external transition**
-  When I have a JettyPod project in internal state, I run "jettypod project external" → an audit log entry should be created and the log should include timestamp, user, and project details and the log should record the state change from "internal" to "external" and the log should include the infrastructure epic ID created
-
-- **Performance with large projects (1000+ work items)**
-  When I have a JettyPod project with 1000 work items, the project is in internal state, I run "jettypod project external" → the transition should complete in under 5 seconds and memory usage should remain under 100MB and all infrastructure items should be created successfully
-
-- **Concurrent transition attempts are prevented**
-  When I have a JettyPod project in internal state, I start "jettypod project external" in one process and I attempt "jettypod project external" in another process → the second attempt should be blocked and I should see "Transition already in progress" and only one infrastructure epic should be created
-
-- **State transition is recorded for compliance**
-  When I have a JettyPod project in internal state, I run "jettypod project external" → a state transition record should be created and the record should include "from: internal, to: external" and the record should include a timestamp and the record should be immutable
-
-- **Infrastructure creation is idempotent**
-  When I have a JettyPod project in external state, an "Infrastructure Readiness" epic exists, I run "jettypod project external" again → no duplicate infrastructure items should be created and the existing epic ID should be preserved and I should see "Infrastructure already configured"
-
----
-
-### Terminal Logo Display
-
-*Related features: Terminal Logo Display*
-
-**Verified behaviors:**
-
-- **jettypod init displays unicode gradient logo**
-  When a new empty directory, I run jettypod init → the output contains the unicode gradient logo and the logo includes "DEV" and "POD" text and the logo uses ANSI color codes
-
-- **Logo module exports showLogo function**
-  When the logo module exists, I import it → it exports a "showLogo" function
-
-- **Logo output is properly formatted**
-  I call the showLogo function → it outputs 6 lines of logo art and it includes the version subtitle
-
-- **jettypod init integrates with existing features**
-  When a new empty directory, I run jettypod init → I see the unicode logo and the .jettypod directory is created and CLAUDE.md is created and git hooks are installed
-
----
-
-### Bug Workflow Display
-
-*Related features: Bug Workflow Display*
-
-**Verified behaviors:**
-
-- **Starting work on a bug displays workflow guidance**
-  When jettypod is initialized, I create a bug "Install script fails", I start work on the bug → the output contains "BUG FIXING WORKFLOW" and the output contains "1. REPRODUCE" and the output contains "2. INVESTIGATE" and the output contains "3. ISOLATE" and the output contains "4. FIX" and the output contains "5. VERIFY" and the output contains "6. COMMIT"
-
-- **Starting work on a feature does not display bug workflow**
-  When jettypod is initialized, I create a feature "Add new feature", I start work on the feature → the output does not contain "BUG FIXING WORKFLOW"
-
----
-
-### Work
-
-*Related features: Work Commands - Stable Mode*
-
-**Verified behaviors:**
-
-- **Start work with invalid ID**
-  When jettypod is initialized, I try to start work with ID "invalid" → I get an error "Invalid work item ID"
-
-- **Start work with negative ID**
-  When jettypod is initialized, I try to start work with ID "-1" → I get an error "Invalid work item ID"
-
-- **Start work when not initialized**
-  When jettypod is not initialized, I try to start work with ID "1" → I get an error "JettyPod not initialized"
-
-- **Start work on non-existent item**
-  When jettypod is initialized, I try to start work with ID "999" → I get an error "Work item #999 not found"
-
-- **Stop work with invalid status**
-  When I have current work, I try to stop work with status "invalid" → I get an error "Invalid status"
-
-- **Stop work when no current work**
-  When jettypod is initialized, no work is active, I try to stop work → operation succeeds with no changes
-
-- **Get current work with corrupted file**
-  When jettypod is initialized, current work file is corrupted, I get current work → it returns null
-
-- **Start work without git repo**
-  When jettypod is initialized without git, I have a work item, I start work on the item → it succeeds without creating branch
-
-- **Multiple start work calls**
-  When I have a work item, I start work on it, I start work on a different item → the first item stops being current and the second item becomes current
-
-- **Start work preserves existing status**
-  When I have a work item with status "in_progress", I start work on it → the status remains "in_progress"
-
----
-
-### Work Item
-
-*Related features: Work Item Commands*
-
-**Verified behaviors:**
-
-- **Integration - work commands with existing work tracking**
-  When I have initialized jettypod, I create an epic with id 1, I create a feature with id 2 under epic 1, I start work on item 2 → the current work file exists and the current work contains item 2 and item 2 status is in_progress or backlog
-
----
-
-### Mode defaults to discovery on work item creation
-
-*Related features: Mode defaults to discovery on work item creation*
-
-**Verified behaviors:**
-
-- **Create epic without mode**
-  When jettypod is initialized, I create an epic "Test Epic" without mode → the work item is created successfully and the work item has NULL mode
-
-- **Create epic with mode (optional)**
-  When jettypod is initialized, I create an epic "Test Epic" with mode "stable" → the work item is created successfully and the work item has mode "stable"
-
-- **Create feature with explicit mode**
-  When jettypod is initialized, I create a feature "Test Feature" with mode "speed" → the work item is created successfully and the work item has mode "speed"
-
-- **Create feature without mode defaults to discovery**
-  When jettypod is initialized, I create a feature "Test Feature" without mode → the work item is created successfully and the work item has mode "discovery"
-
-- **Create feature with invalid mode**
-  When jettypod is initialized, I try to create a feature "Test Feature" with mode "invalid" → I get an error "Invalid mode" and no work item is created
-
-- **Create bug with mode fails**
-  When jettypod is initialized, I try to create a bug "Test Bug" with mode "stable" → I get an error "Bugs cannot have modes" and no work item is created
-
-- **Create bug without mode succeeds with NULL**
-  When jettypod is initialized, I create a bug "Test Bug" without mode → the work item is created successfully and the work item has no mode
-
-- **Create chore with mode fails**
-  When jettypod is initialized, I try to create a chore "Test Chore" with mode "production" → I get an error "Chores do not have modes" and no work item is created
-
-- **Create chore without mode succeeds with NULL**
-  When jettypod is initialized, jettypod is initialized, I create a chore "Test Chore" without mode and I create a feature "Test Feature" with mode "<mode>" → the work item is created successfully and the work item has NULL mode and the work item is created successfully and the work item has mode "<mode>"
-
-- **Epic with children in different modes**
-  When jettypod is initialized, I create an epic "Test Epic" without mode, I create a feature "Speed Feature" with mode "speed" and parent epic, I create a bug "Test Bug" with parent epic, I create a chore "Test Chore" without mode and parent epic, I view the backlog → I see the epic without mode indicator and I see the feature with mode "speed" and I see the bug without mode indicator and I see the chore without mode indicator
-
-- **Create multiple items with same title but different modes**
-  When jettypod is initialized, I create a feature "Duplicate" with mode "speed" and I create a feature "Duplicate" with mode "stable" → both work items are created successfully and they have different modes
-
-- **Mode is case-sensitive**
-  When jettypod is initialized, I try to create a feature "Test" with mode "Speed" → I get an error "Invalid mode"
-
-- **Mode with whitespace is invalid**
-  When jettypod is initialized, I try to create a feature "Test" with mode " speed " → I get an error "Invalid mode"
-
-- **Empty string mode is treated as NULL**
-  When jettypod is initialized, I try to create a feature "Test" with mode "" → I get an error "Invalid mode"
-
----
-
-### Work set-mode updates CLAUDE.md if item is current
-
-*Related features: Work set-mode updates CLAUDE.md if item is current*
-
-**Verified behaviors:**
-
-- **Set mode on current work item updates CLAUDE.md**
-  When I create a feature "Test Feature" with mode "speed", I start work on the feature, CLAUDE.md mode is set to "speed", I set mode for current item to "stable" → the work item has mode "stable" and CLAUDE.md mode is set to "stable"
-
-- **Set mode on non-current item does not update CLAUDE.md**
-  When I create a feature "Item 1" with mode "speed", I create a feature "Item 2" with mode "discovery", I start work on the feature "Item 1", CLAUDE.md mode is set to "speed", I set mode for item "Item 2" to "stable" → item "Item 2" has mode "stable"
-
-- **Set invalid mode shows error**
-  When I create a feature "Test Feature" with mode "speed", I try to set mode to "invalid" → I get error "Invalid mode" and the work item still has mode "speed"
-
-- **Set mode is case-sensitive**
-  When I create a feature "Test Feature" with mode "speed", I create a feature "Test Feature" with mode "speed", I try to set mode to "Speed" and I set mode for current item to "<new_mode>" → I get error "Invalid mode" and I start work on the feature and the work item has mode "<new_mode>" and CLAUDE.md mode is set to "<new_mode>"
-
-- **Mode change persists across work start/stop**
-  When I create a feature "Test Feature" with mode "speed", I start work on the feature, I set mode for current item to "production" and I stop work and I start work on the feature → CLAUDE.md mode is set to "production"
-
-- **Change mode multiple times**
-  When I create a feature "Test Feature" with mode "speed", I start work on the feature, I set mode for current item to "discovery" and I set mode for current item to "stable" and I set mode for current item to "production" → the work item has mode "production" and CLAUDE.md mode is set to "production"
-
----
-
-### Work start sets CLAUDE.md mode from work item
-
-*Related features: Work start sets CLAUDE.md mode from work item*
-
-**Verified behaviors:**
-
-- **Start work on feature in speed mode**
-  When I create a feature "Speed Feature" with mode "speed", I start work on the feature → CLAUDE.md mode is set to "speed"
-
-- **Start work on bug in stable mode**
-  When I create a bug "Stable Bug" with mode "stable", I start work on the bug → CLAUDE.md mode is set to "stable"
-
-- **Start work on chore inherits parent feature mode**
-  When I create a feature "Discovery Feature" with mode "discovery", I create a chore "Child Chore" without mode and parent feature, I start work on the chore → CLAUDE.md mode is set to "discovery"
-
-- **Start work on feature in production mode**
-  When I create a feature "Production Feature" with mode "production", I start work on the feature → CLAUDE.md mode is set to "production"
-
-- **Switch from speed mode item to stable mode item**
-  When I create a feature "Speed Feature" with mode "speed", I create a bug "Stable Bug" with mode "stable", I start work on the feature, CLAUDE.md mode is set to "speed", I stop work and I start work on the bug → CLAUDE.md mode is set to "stable"
-
-- **Start work updates mode even if item already in progress**
-  When I create a feature "Test Feature" with mode "discovery", the feature status is "in_progress", CLAUDE.md has mode "speed", I start work on the feature → CLAUDE.md mode is set to "discovery"
-
-- **Start work on epic (NULL mode)**
-  When I create an epic "Test Epic" without mode, I start work on the epic → CLAUDE.md has no mode line and the current work section exists
-
-- **Start work on feature with default discovery mode**
-  When I create a feature "Default Feature" without mode, the work item has mode "discovery", I start work on the feature → CLAUDE.md mode is set to "discovery"
-
-- **Start work on child features use their own mode, not parent's**
-  When I create an epic "Test Epic" without mode, I create a feature "Speed Feature" with mode "speed" and parent epic, I create a feature "Stable Feature" with mode "stable" and parent epic, I start work on the speed feature and I stop work → CLAUDE.md mode is set to "speed" and I start work on the stable feature and CLAUDE.md mode is set to "stable"
-
-- **Work item mode persists in database after start**
-  When I create a feature "Test Feature" with mode "stable", I start work on the feature and I stop work → the work item still has mode "stable"
-
-- **Starting work multiple times preserves mode**
-  When I create a feature "Test Feature" with mode "production", I start work on the feature and I stop work and I start work on the feature → CLAUDE.md mode is set to "production" and the work item still has mode "production"
-
----
-
-## Detailed Feature Specifications
-
-### Auto-Generate Production Chores at End of Stable Mode
-
-When stable mode completes all scenarios for a feature, the skill analyzes the implementation with hot context and generates specific, actionable production chores. Chore visibility depends on project state (external vs internal). Epic: Production Mode Approach: Preview-and-Confirm (Transparent)
-
----
-
-### Backlog Command
-
-Enhanced command to view work items with built-in filters Approach: Enhanced backlog with filters (backlog, backlog all, backlog completed)
-
-#### User views active backlog items
-
-**Context:**
-- I have work items in various statuses
-
-**Action:**
-- I run "jettypod backlog"
-
-**Expected outcome:**
-- I see only active work items (backlog, todo, in_progress)
-- I see the items in a tree hierarchy
-- completed items are hidden
-
-#### User views all work items including completed
-
-**Context:**
-- I have work items in various statuses
-
-**Action:**
-- I run "jettypod backlog all"
-
-**Expected outcome:**
-- I see all work items regardless of status
-- I see the items in a tree hierarchy
-
-#### User views only completed items
-
-**Context:**
-- I have work items in various statuses
-
-**Action:**
-- I run "jettypod backlog completed"
-
-**Expected outcome:**
-- I see only completed work items (done, cancelled)
-- I see the items in a tree hierarchy
-
----
-
-### Backlog Filtering for Production Items
-
-Hide production mode features and their chores from the BACKLOG section when project_state is 'internal'. Show them with --all flag. Epic: Production Mode Approach: Tree-aware filtering with smart pruning
-
----
-
-### Fix Text Wrapping in Terminal Output
-
-Terminal-aware word wrapping that respects terminal width and aligns continuation lines with tree structure indentation Approach: Terminal-Aware Word-Wrap with Alignment @text-wrapping
-
-#### Long titles wrap at word boundaries within terminal width
-
-**Context:**
-- I have a feature with a title longer than the terminal width
-
-**Action:**
-- I run jettypod backlog with current terminal width
-
-**Expected outcome:**
-- the title wraps at word boundaries
-- continuation lines align with the content indentation
-- no words are split mid-character
-
-#### Long descriptions wrap cleanly in expanded view
-
-**Context:**
-- I have a feature with a long description
-
-**Action:**
-- I run jettypod backlog --expand=1 with current terminal width
-
-**Expected outcome:**
-- the description wraps at word boundaries
-- continuation lines have proper "Description: " prefix indentation
-- the text fits within terminal width
-
-#### Tree structure preserved with wrapped text
-
-**Context:**
-- I have nested items with long titles
-
-**Action:**
-- I run jettypod backlog --expand=all with current terminal width
-
-**Expected outcome:**
-- tree connectors (├──, └──) display correctly
-- wrapped continuation lines align under the item content
-- tree structure remains visually clear
-
-#### Terminal width changes are respected
-
-**Context:**
-- the terminal width is 120 columns
-- I have items with titles that wrap at 120 columns
-
-**Action:**
-- the terminal is resized to 80 columns
-- I run jettypod backlog with current terminal width
-
-**Expected outcome:**
-- text wraps to fit 80 columns
-- alignment adjusts to the new width
-
----
-
-### Git Hook Integration
-
-As a developer I want work item status to update automatically on git operations So that I don't have to manually track progress
-
-#### First commit updates status to in_progress
-
-**Context:**
-- I have a work item with status "todo"
-- the work item is set as current work
-
-**Action:**
-- I make my first commit
-
-**Expected outcome:**
-- the work item status should be "in_progress"
-
-#### Merge to main updates status to done
-
-**Context:**
-- I have a work item with status "in_progress"
-- the work item is set as current work
-- I am on a feature branch
-
-**Action:**
-- I merge to main
-
-**Expected outcome:**
-- the work item status should be "done"
-
-#### No current work item - hooks do nothing
-
-**Context:**
-- no work item is set as current
-
-**Action:**
-- I make a commit
-
-**Expected outcome:**
-- no errors occur
-
-#### Integration - hooks work with existing work commands
-
-**Context:**
-- I have initialized jettypod with git
-- I create a work item via work commands
-- I start work on the item
-
-**Action:**
-- I commit changes
-
-**Expected outcome:**
-- the work item status updates automatically
-- the current work file still exists
-
----
-
-### Git Hooks Integration
-
-As a developer I want work item status to auto-update on commits So I don't manually track progress
-
-#### Integration - post-commit hook updates status
-
-**Context:**
-- I initialize a git repo with jettypod
-- I create and start work on a todo item
-
-**Action:**
-- I make a commit
-
-**Expected outcome:**
-- the hook updates status to in_progress
-
----
-
-### JettyPod update command
-
-Self-updating jettypod and skills refresh with a single command Epic: JettyPod and Skills Auto-Update Approach: Full self-update - Check npm, update jettypod, refresh skills
-
-#### User runs jettypod update when new version is available
-
-**Context:**
-- jettypod version 3.0.0 is installed
-- npm registry has version 3.1.0 available
-
-**Action:**
-- I run update command "jettypod update"
-
-**Expected outcome:**
-- jettypod checks npm registry for latest version
-- jettypod shows "New version available: 3.1.0 (current: 3.0.0)"
-- jettypod downloads and installs version 3.1.0
-- skills are refreshed in current project
-- jettypod shows "✅ JettyPod updated to 3.1.0"
-
-#### User runs jettypod update when already on latest version
-
-**Context:**
-- jettypod version 3.1.0 is installed
-- npm registry has version 3.1.0 available
-
-**Action:**
-- I run update command "jettypod update"
-
-**Expected outcome:**
-- jettypod checks npm registry for latest version
-- jettypod shows "Already on latest version: 3.1.0"
-- skills are refreshed in current project
-
-#### User runs jettypod update without internet connection
-
-**Context:**
-- jettypod is installed
-- there is no internet connection
-
-**Action:**
-- I run update command "jettypod update"
-
-**Expected outcome:**
-- jettypod shows "Cannot check for updates: network error"
-- skills are still refreshed in current project using existing jettypod
-
-#### Command rename - jettypod without init creates new project
-
-**Context:**
-- I am in a directory without .claude/
-
-**Action:**
-- I run update command "jettypod"
-
-**Expected outcome:**
-- jettypod initializes the project
-- .claude/ directory is created
-- CLAUDE.md is created
-- skills are installed
-
-#### Backwards compatibility - jettypod init still works
-
-**Context:**
-- I am in a directory without .claude/
-
-**Action:**
-- I run update command "jettypod init"
-
-**Expected outcome:**
-- jettypod initializes the project
-- .claude/ directory is created
-- CLAUDE.md is created
-- skills are installed
-
----
-
-### Mode Change Prompts
-
-As a developer I want to update work status when switching modes So my work state stays current
-
-#### Integration - mode change with work item present
-
-**Context:**
-- I have jettypod with a work item in progress
-
-**Action:**
-- I check current work exists
-
-**Expected outcome:**
-- the work item has a status
-
----
-
-### Multiple Claude Code instances coordination
-
-Commit queue system ensures safe, ordered pushes to main when multiple Claude Code instances work in the same directory simultaneously Approach: Commit Queue System
-
-#### Single Claude instance pushes to main without queue
-
-**Context:**
-- I am a Claude Code instance with completed work
-- I have committed my changes locally
-- the push queue is empty
-- main branch has no new commits
-
-**Action:**
-- I attempt to push to main
-
-**Expected outcome:**
-- I push directly to main
-- I do not create a queue entry
-
-#### First Claude instance creates queue entry when main is ahead
-
-**Context:**
-- I am a Claude Code instance with completed work
-- I have committed my changes locally
-- the push queue is empty
-- main branch has 2 new commits since my work started
-
-**Action:**
-- I attempt to push to main
-
-**Expected outcome:**
-- I create a queue entry at position 1
-- I see "Added to push queue (position 1)"
-- I rebase my commits on top of main
-- I push to main
-- I remove my queue entry
-
-#### Second Claude waits for first to complete
-
-**Context:**
-- Claude instance A is at position 1 in the push queue
-- I am a Claude Code instance with completed work
-- I have committed my changes locally
-
-**Action:**
-- I attempt to push to main
-
-**Expected outcome:**
-- I create a queue entry at position 2
-- I see "Added to push queue (position 2, waiting for 1 commit ahead)"
-- I do not push yet
-- I wait for position 1 to complete
-
-#### Queue processes sequentially when first completes
-
-**Context:**
-- Claude instance A is at position 1 and is pushing
-- I am at position 2 in the queue
-
-**Action:**
-- Claude instance A completes their push
-
-**Expected outcome:**
-- I move to position 1
-- I rebase my commits on top of the updated main
-- I push to main
-- I remove my queue entry
-
-#### Queue file corrupted or contains invalid JSON
-
-**Context:**
-- the push queue file exists but contains invalid JSON
-
-**Action:**
-- I attempt to push to main
-
-**Expected outcome:**
-- I should see an error message about corrupted queue file
-- the system should initialize a new empty queue
-- I should be able to push successfully
-
-#### Queue file cannot be written due to permissions
-
-**Context:**
-- the .jettypod directory has no write permissions
-
-**Action:**
-- I attempt to push to main
-
-**Expected outcome:**
-- I should see an error about insufficient permissions
-- the system should provide guidance to fix permissions
-- the push should not proceed
-
-#### Git rebase fails with conflicts
-
-**Context:**
-- I am at position 1 in the queue
-- my changes conflict with changes on main
-
-**Action:**
-- I attempt to rebase on main
-
-**Expected outcome:**
-- I should see a clear error about rebase conflicts
-- I should receive guidance on how to resolve conflicts
-- my queue entry should remain until conflicts are resolved
-
-#### Git fetch fails due to network issues
-
-**Context:**
-- I am checking if main has moved ahead
-
-**Action:**
-- git fetch fails due to network connectivity
-
-**Expected outcome:**
-- I should see an error about network failure
-- the system should suggest retry or check connectivity
-- the push should not proceed
-
-#### Git push fails after successful rebase
-
-**Context:**
-- I have successfully rebased on main
-
-**Action:**
-- git push fails due to remote rejection
-
-**Expected outcome:**
-- I should see a clear error message
-- my queue entry should remain for retry
-- the system should not corrupt the queue state
-
-#### Invalid queue entry with missing fields
-
-**Context:**
-- the queue contains an entry with missing instanceId
-
-**Action:**
-- the queue processor attempts to process entries
-
-**Expected outcome:**
-- invalid entries should be removed from queue
-- valid entries should continue processing
-- a warning should be logged about invalid entries
-
-#### Stale queue entry from crashed instance
-
-**Context:**
-- a queue entry has been waiting for over 1 hour
-- the instance that created it is no longer running
-
-**Action:**
-- queue cleanup runs
-
-**Expected outcome:**
-- the stale entry should be removed
-- subsequent entries should advance in position
-- a notification should be logged
-
-#### Multiple instances try to write queue simultaneously
-
-**Context:**
-- two Claude instances both try to add queue entries at same time
-
-**Action:**
-- concurrent queue writes occur
-
-**Expected outcome:**
-- both entries should be successfully added
-- no queue corruption should occur
-- positions should be correctly assigned
-
-#### Empty commit SHA provided to queue
-
-**Context:**
-- I attempt to add a queue entry with empty commit SHA
-
-**Action:**
-- validation runs
-
-**Expected outcome:**
-- I should see an error about invalid commit SHA
-- no queue entry should be created
-- guidance should be provided
-
-#### Queue position monitoring with removed entries
-
-**Context:**
-- I am at position 3 in the queue
-
-**Action:**
-- entry at position 1 is removed (not completed normally)
-
-**Expected outcome:**
-- I should move to position 2
-- I should be notified of position change
-- queue integrity should be maintained
-
----
-
-### Production Mode Skill
-
-Context-aware skill that guides implementation of production mode chores with smart detection of three starting contexts (hot, cold, post-transition) Epic: #609 Production Mode Approach: Context-Aware Production Mode with Scenario A/B/C detection
-
-#### Fresh from stable mode - Quick validation (Scenario A)
-
-**Context:**
-- a feature just completed stable mode within 1 day
-- production scenarios already exist in the feature file
-- production chores already exist for the feature
-- production standards file exists
-
-**Action:**
-- I start the production-mode skill for this feature
-
-**Expected outcome:**
-- it detects Scenario A (hot context)
-- it validates existing scenarios against current standards
-- it identifies no gaps
-- it proceeds to implement existing production chores
-
-#### Gap in time - Re-validation (Scenario B)
-
-**Context:**
-- a feature completed stable mode over 7 days ago
-- production scenarios exist in the feature file
-- production chores exist for the feature
-- production standards file exists
-
-**Action:**
-- I start the production-mode skill for this feature
-
-**Expected outcome:**
-- it detects Scenario B (cold context)
-- it re-validates existing scenarios against current standards
-- it checks if project state changed since stable mode
-- it identifies any gaps in standards coverage
-- it updates scenarios if needed
-
-#### Post external-transition - Generate from standards (Scenario C)
-
-**Context:**
-- a feature in stable mode with no production scenarios
-- no production chores exist for the feature
-- production standards file exists from external-transition
-
-**Action:**
-- I start the production-mode skill for this feature
-
-**Expected outcome:**
-- it detects Scenario C (post-transition)
-- it reads production standards from file
-- it generates production scenarios from activated standards
-- it appends scenarios to the feature file
-- it proposes production chores based on standards
-- it creates chores after user confirmation
-
-#### Missing production standards file
-
-**Context:**
-- a feature in stable mode
-- the production standards file does not exist at .jettypod/production-standards.json
-
-**Action:**
-- I start the production-mode skill for this feature
-
-**Expected outcome:**
-- it fails with error "Production standards file not found"
-- it suggests running external-transition first
-
-#### Corrupted production standards file
-
-**Context:**
-- a feature in stable mode
-- the production standards file exists but contains malformed JSON
-
-**Action:**
-- I start the production-mode skill for this feature
-
-**Expected outcome:**
-- it fails with error "Failed to parse production standards"
-- it shows the JSON parsing error details
-
-#### Invalid production standards format
-
-**Context:**
-- a feature in stable mode
-- the production standards file exists with valid JSON
-
-**Action:**
-- I start the production-mode skill for this feature
-
-**Expected outcome:**
-- it fails with error "Invalid standards format"
-- it specifies which required fields are missing
-
-#### Missing scenario file for feature
-
-**Context:**
-- a feature in stable mode
-- the feature has no scenario_file set in database
-
-**Action:**
-- I start the production-mode skill for this feature
-
-**Expected outcome:**
-- it fails with error "Feature has no scenario file"
-- it suggests the feature may not be properly initialized
-
-#### Scenario file does not exist on disk
-
-**Context:**
-- a feature in stable mode
-- the feature has scenario_file set in database
-
-**Action:**
-- I start the production-mode skill for this feature
-
-**Expected outcome:**
-- it fails with error "Scenario file not found"
-- it shows the expected file path
-
-#### Feature not found in database
-
-**Context:**
-- an invalid feature ID
-
-**Action:**
-- I start the production-mode skill with that feature ID
-
-**Expected outcome:**
-- it fails with error "Feature not found"
-
-#### Feature has no completed_at timestamp
-
-**Context:**
-- a feature marked as done in stable mode
-
-**Action:**
-- the context detector checks time since stable completion
-
-**Expected outcome:**
-- it treats this as Scenario C (no production content yet)
-
-#### File permission error reading standards
-
-**Context:**
-- a feature in stable mode
-- the production standards file exists
-
-**Action:**
-- I start the production-mode skill for this feature
-
-**Expected outcome:**
-- it fails with error indicating permission denied
-- it shows the file path with permission issues
-
-#### File permission error writing scenarios
-
-**Context:**
-- a feature in Scenario C (generating scenarios)
-- production standards are loaded successfully
-
-**Action:**
-- attempting to append scenarios to the file
-
-**Expected outcome:**
-- it fails with error indicating write permission denied
-
-#### Empty standards array
-
-**Context:**
-- a feature in stable mode
-- the production standards file exists with empty standards array
-
-**Action:**
-- I start the production-mode skill for this feature
-
-**Expected outcome:**
-- it completes successfully
-- reports 0 standards to implement
-
-#### Database connection error
-
-**Context:**
-- the database file is locked or corrupted
-
-**Action:**
-- I start the production-mode skill
-
-**Expected outcome:**
-- it fails with database error
-- it suggests checking database integrity
-
----
-
-### Refactor Mode
-
-As a developer I want an interactive audit menu for refactoring So that I can systematically clean up technical debt
-
-#### Refactor mode integrates with work tracking
-
-**Context:**
-- I have existing work items in the system
-
-**Action:**
-- I enter refactor mode and audit the codebase
-- I select "Architectural" category
-- I approve creating chores for storage pattern
-
-**Expected outcome:**
-- refactor chores are created under an epic
-- the epic is linked to the refactor mode work item
-
-#### User enters refactor mode and sees audit menu
-
-**Context:**
-- I'm in a project with technical debt
-
-**Action:**
-- I enter refactor mode
-
-**Expected outcome:**
-- Claude audits the codebase
-- I see categorized menu with counts:
-
-#### User picks category and sees detailed breakdown
-
-**Context:**
-- I see the audit menu
-
-**Action:**
-- I pick "Architectural" category
-
-**Expected outcome:**
-- I see detailed items with:
-
-#### Claude recommends quick wins
-
-**Context:**
-- I see the detailed breakdown for "Architectural"
-
-**Action:**
-- Claude analyzes impact vs time
-
-**Expected outcome:**
-- I see recommendation: "Start with Storage Pattern (quick win, high impact)"
-- I see warning: "Skip State Management (needs Discovery Mode first)"
-
-#### User approves and chores are created
-
-**Context:**
-- I see recommendations for Storage Pattern
-
-**Action:**
-- I say "create chores"
-
-**Expected outcome:**
-- epic "Refactor: Architectural patterns" is created
-- chore "Create shared storage util" is created
-- chore "Migrate auth to storage util" is created
-- all chores are linked to the epic
-
----
-
-### Simplify External Transition Command
-
-Remove batch production chore generation from 'jettypod project external'. Just update project_state flag and create infrastructure readiness work items. Production items become visible automatically through backlog filtering. Epic: Production Mode Approach: Skill-based external transition with infrastructure epic creation
-
-#### User transitions project to external state
-
-**Context:**
-- I have a JettyPod project in internal state
-- I have some features in stable mode with production chores already created
-
-**Action:**
-- I run "jettypod project external"
-
-**Expected outcome:**
-- the project_state should be updated to "external"
-- an "Infrastructure Readiness" epic should be created
-- 4 infrastructure features should be created under the epic
-- 15 infrastructure chores should be created across the features
-- production mode work items should now be visible in the backlog
-- no duplicate production chores should be created for existing features
-
-#### Project already in external state
-
-**Context:**
-- I have a JettyPod project in external state
-
-**Action:**
-- I run "jettypod project external"
-
-**Expected outcome:**
-- I should see a message "Project already in external state"
-- no duplicate infrastructure items should be created
-- the command should exit successfully
-
-#### Infrastructure epic already exists
-
-**Context:**
-- I have a JettyPod project in internal state
-- an "Infrastructure Readiness" epic already exists
-
-**Action:**
-- I run "jettypod project external"
-
-**Expected outcome:**
-- the project_state should be updated to "external"
-- no duplicate "Infrastructure Readiness" epic should be created
-- existing infrastructure items should be preserved
-- I should see a message about existing infrastructure
-
-#### Database connection fails during transition
-
-**Context:**
-- I have a JettyPod project in internal state
-- the database connection will fail
-
-**Action:**
-- I run "jettypod project external"
-
-**Expected outcome:**
-- I should see a clear error message about database failure
-- the project_state should remain "internal"
-- no partial infrastructure items should be created
-
-#### Work item creation fails mid-transition
-
-**Context:**
-- I have a JettyPod project in internal state
-- work item creation will fail after creating the epic
-
-**Action:**
-- I run "jettypod project external"
-
-**Expected outcome:**
-- I should see an error message about failed creation
-- the project_state should remain "internal"
-- any partial work items should be cleaned up
-
-#### Invalid checklist data structure
-
-**Context:**
-- I have a JettyPod project in internal state
-- the infrastructure checklist has invalid data
-
-**Action:**
-- I run "jettypod project external"
-
-**Expected outcome:**
-- I should see a validation error message
-- the project_state should remain "internal"
-- no infrastructure items should be created
-
-#### Infrastructure chores generated from production standards
-
-**Context:**
-- I have a JettyPod project in internal state
-- I have production standards with infrastructure-scoped standards
-- the standards include "database_backups" in infrastructure scope
-- the standards include "monitoring_setup" in infrastructure scope
-
-**Action:**
-- I run "jettypod project external"
-
-**Expected outcome:**
-- infrastructure chores should be created from standards
-- each infrastructure standard should create one chore
-- chore descriptions should include acceptance criteria from standards
-- chore descriptions should include reasoning from standards
-- no static checklist should be used
-
-#### Different presets create different infrastructure chores
-
-**Context:**
-- I have a JettyPod project in internal state
-- production standards are set to "startup-mvp" preset
-
-**Action:**
-- I run "jettypod project external"
-- I change production standards to "enterprise" preset
-
-**Expected outcome:**
-- infrastructure chores should match startup-mvp standards
-- I should see fewer infrastructure chores than enterprise preset
-- I run "jettypod project external" on a new project
-- infrastructure chores should match enterprise standards
-- I should see more infrastructure chores than startup-mvp preset
-- additional chores should include multi-region setup
-- additional chores should include advanced monitoring
-
-#### Scope field correctly filters infrastructure vs feature standards
-
-**Context:**
-- I have a JettyPod project in internal state
-- production standards include 5 infrastructure-scoped standards
-- production standards include 8 feature-scoped standards
-
-**Action:**
-- I run "jettypod project external"
-
-**Expected outcome:**
-- exactly 5 infrastructure chores should be created
-- no feature-scoped standards should create infrastructure chores
-- feature-scoped standards should be reserved for feature production chores
-
-#### Infrastructure chore created per standard (not grouped by domain)
-
-**Context:**
-- I have a JettyPod project in internal state
-- production standards include 3 security infrastructure standards
-- production standards include 2 monitoring infrastructure standards
-
-**Action:**
-- I run "jettypod project external"
-
-**Expected outcome:**
-- 5 separate infrastructure chores should be created
-- each chore should reference exactly one standard
-- chores should not be grouped by domain
-- each chore title should describe the specific standard
-
-#### Missing production standards file during transition
-
-**Context:**
-- I have a JettyPod project in internal state
-- no production standards file exists
-
-**Action:**
-- I run "jettypod project external"
-
-**Expected outcome:**
-- I should see an error "Production standards file not found"
-- I should be prompted to run external transition interactively
-- the project_state should remain "internal"
-- no infrastructure items should be created
-
-#### Infrastructure chores include pattern guidance from standards
-
-**Context:**
-- I have a JettyPod project in internal state
-- production standards include a standard with pattern guidance
-- the standard has pattern "Use pg_dump with --clean flag"
-
-**Action:**
-- I run "jettypod project external"
-
-**Expected outcome:**
-- the created chore should include the pattern in description
-- the pattern should be labeled "Pattern:" in the description
-- developers should have clear implementation guidance
-
-#### Audit logging for external transition
-
-**Context:**
-- I have a JettyPod project in internal state
-
-**Action:**
-- I run "jettypod project external"
-
-**Expected outcome:**
-- an audit log entry should be created
-- the log should include timestamp, user, and project details
-- the log should record the state change from "internal" to "external"
-- the log should include the infrastructure epic ID created
-
-#### Performance with large projects (1000+ work items)
-
-**Context:**
-- I have a JettyPod project with 1000 work items
-- the project is in internal state
-
-**Action:**
-- I run "jettypod project external"
-
-**Expected outcome:**
-- the transition should complete in under 5 seconds
-- memory usage should remain under 100MB
-- all infrastructure items should be created successfully
-
-#### Concurrent transition attempts are prevented
-
-**Context:**
-- I have a JettyPod project in internal state
-
-**Action:**
-- I start "jettypod project external" in one process
-- I attempt "jettypod project external" in another process
-
-**Expected outcome:**
-- the second attempt should be blocked
-- I should see "Transition already in progress"
-- only one infrastructure epic should be created
-
-#### State transition is recorded for compliance
-
-**Context:**
-- I have a JettyPod project in internal state
-
-**Action:**
-- I run "jettypod project external"
-
-**Expected outcome:**
-- a state transition record should be created
-- the record should include "from: internal, to: external"
-- the record should include a timestamp
-- the record should be immutable
-
-#### Infrastructure creation is idempotent
-
-**Context:**
-- I have a JettyPod project in external state
-- an "Infrastructure Readiness" epic exists
-
-**Action:**
-- I run "jettypod project external" again
-
-**Expected outcome:**
-- no duplicate infrastructure items should be created
-- the existing epic ID should be preserved
-- I should see "Infrastructure already configured"
-
----
-
-### Terminal Logo Display
-
-As a JettyPod user I want to see a welcoming logo when I run jettypod init So that the tool feels approachable and modern
-
-#### jettypod init displays unicode gradient logo
-
-**Context:**
-- a new empty directory
-
-**Action:**
-- I run jettypod init
-
-**Expected outcome:**
-- the output contains the unicode gradient logo
-- the logo includes "DEV" and "POD" text
-- the logo uses ANSI color codes
-
-#### Logo module exports showLogo function
-
-**Context:**
-- the logo module exists
-
-**Action:**
-- I import it
-
-**Expected outcome:**
-- it exports a "showLogo" function
-
-#### Logo output is properly formatted
-
-**Action:**
-- I call the showLogo function
-
-**Expected outcome:**
-- it outputs 6 lines of logo art
-- it includes the version subtitle
-
-#### jettypod init integrates with existing features
-
-**Context:**
-- a new empty directory
-
-**Action:**
-- I run jettypod init
-
-**Expected outcome:**
-- I see the unicode logo
-- the .jettypod directory is created
-- CLAUDE.md is created
-- git hooks are installed
-
----
-
-### Bug Workflow Display
-
-As a developer I want to see bug-specific workflow guidance when starting a bug So that I have systematic steps to follow for fixing bugs
-
-#### Starting work on a bug displays workflow guidance
-
-**Context:**
-- jettypod is initialized
-- I create a bug "Install script fails"
-
-**Action:**
-- I start work on the bug
-
-**Expected outcome:**
-- the output contains "BUG FIXING WORKFLOW"
-- the output contains "1. REPRODUCE"
-- the output contains "2. INVESTIGATE"
-- the output contains "3. ISOLATE"
-- the output contains "4. FIX"
-- the output contains "5. VERIFY"
-- the output contains "6. COMMIT"
-
-#### Starting work on a feature does not display bug workflow
-
-**Context:**
-- jettypod is initialized
-- I create a feature "Add new feature"
-
-**Action:**
-- I start work on the feature
-
-**Expected outcome:**
-- the output does not contain "BUG FIXING WORKFLOW"
-
----
-
-### Work Commands - Stable Mode
-
-Edge cases and error handling for work commands
-
-#### Start work with invalid ID
-
-**Context:**
-- jettypod is initialized
-
-**Action:**
-- I try to start work with ID "invalid"
-
-**Expected outcome:**
-- I get an error "Invalid work item ID"
-
-#### Start work with negative ID
-
-**Context:**
-- jettypod is initialized
-
-**Action:**
-- I try to start work with ID "-1"
-
-**Expected outcome:**
-- I get an error "Invalid work item ID"
-
-#### Start work when not initialized
-
-**Context:**
-- jettypod is not initialized
-
-**Action:**
-- I try to start work with ID "1"
-
-**Expected outcome:**
-- I get an error "JettyPod not initialized"
-
-#### Start work on non-existent item
-
-**Context:**
-- jettypod is initialized
-
-**Action:**
-- I try to start work with ID "999"
-
-**Expected outcome:**
-- I get an error "Work item #999 not found"
-
-#### Stop work with invalid status
-
-**Context:**
-- I have current work
-
-**Action:**
-- I try to stop work with status "invalid"
-
-**Expected outcome:**
-- I get an error "Invalid status"
-
-#### Stop work when no current work
-
-**Context:**
-- jettypod is initialized
-- no work is active
-
-**Action:**
-- I try to stop work
-
-**Expected outcome:**
-- operation succeeds with no changes
-
-#### Get current work with corrupted file
-
-**Context:**
-- jettypod is initialized
-- current work file is corrupted
-
-**Action:**
-- I get current work
-
-**Expected outcome:**
-- it returns null
-
-#### Start work without git repo
-
-**Context:**
-- jettypod is initialized without git
-- I have a work item
-
-**Action:**
-- I start work on the item
-
-**Expected outcome:**
-- it succeeds without creating branch
-
-#### Multiple start work calls
-
-**Context:**
-- I have a work item
-- I start work on it
-
-**Action:**
-- I start work on a different item
-
-**Expected outcome:**
-- the first item stops being current
-- the second item becomes current
-
-#### Start work preserves existing status
-
-**Context:**
-- I have a work item with status "in_progress"
-
-**Action:**
-- I start work on it
-
-**Expected outcome:**
-- the status remains "in_progress"
-
----
-
-### Work Item Commands
-
-As a developer I want to start and stop work on items So that my current work is tracked automatically
-
-#### Integration - work commands with existing work tracking
-
-**Context:**
-- I have initialized jettypod
-- I create an epic with id 1
-- I create a feature with id 2 under epic 1
-
-**Action:**
-- I start work on item 2
-
-**Expected outcome:**
-- the current work file exists
-- the current work contains item 2
-- item 2 status is in_progress or backlog
-
----
-
-### Mode defaults to discovery on work item creation
-
-As a developer I want new work items to default to discovery mode So I can start exploring without specifying mode every time
-
-#### Create epic without mode
-
-**Context:**
-- jettypod is initialized
-
-**Action:**
-- I create an epic "Test Epic" without mode
-
-**Expected outcome:**
-- the work item is created successfully
-- the work item has NULL mode
-
-#### Create epic with mode (optional)
-
-**Context:**
-- jettypod is initialized
-
-**Action:**
-- I create an epic "Test Epic" with mode "stable"
-
-**Expected outcome:**
-- the work item is created successfully
-- the work item has mode "stable"
-
-#### Create feature with explicit mode
-
-**Context:**
-- jettypod is initialized
-
-**Action:**
-- I create a feature "Test Feature" with mode "speed"
-
-**Expected outcome:**
-- the work item is created successfully
-- the work item has mode "speed"
-
-#### Create feature without mode defaults to discovery
-
-**Context:**
-- jettypod is initialized
-
-**Action:**
-- I create a feature "Test Feature" without mode
-
-**Expected outcome:**
-- the work item is created successfully
-- the work item has mode "discovery"
-
-#### Create feature with invalid mode
-
-**Context:**
-- jettypod is initialized
-
-**Action:**
-- I try to create a feature "Test Feature" with mode "invalid"
-
-**Expected outcome:**
-- I get an error "Invalid mode"
-- no work item is created
-
-#### Create bug with mode fails
-
-**Context:**
-- jettypod is initialized
-
-**Action:**
-- I try to create a bug "Test Bug" with mode "stable"
-
-**Expected outcome:**
-- I get an error "Bugs cannot have modes"
-- no work item is created
-
-#### Create bug without mode succeeds with NULL
-
-**Context:**
-- jettypod is initialized
-
-**Action:**
-- I create a bug "Test Bug" without mode
-
-**Expected outcome:**
-- the work item is created successfully
-- the work item has no mode
-
-#### Create chore with mode fails
-
-**Context:**
-- jettypod is initialized
-
-**Action:**
-- I try to create a chore "Test Chore" with mode "production"
-
-**Expected outcome:**
-- I get an error "Chores do not have modes"
-- no work item is created
-
-#### Create chore without mode succeeds with NULL
-
-**Context:**
-- jettypod is initialized
-- jettypod is initialized
-
-**Action:**
-- I create a chore "Test Chore" without mode
-- I create a feature "Test Feature" with mode "<mode>"
-
-**Expected outcome:**
-- the work item is created successfully
-- the work item has NULL mode
-- the work item is created successfully
-- the work item has mode "<mode>"
-
-#### Epic with children in different modes
-
-**Context:**
-- jettypod is initialized
-- I create an epic "Test Epic" without mode
-- I create a feature "Speed Feature" with mode "speed" and parent epic
-- I create a bug "Test Bug" with parent epic
-- I create a chore "Test Chore" without mode and parent epic
-
-**Action:**
-- I view the backlog
-
-**Expected outcome:**
-- I see the epic without mode indicator
-- I see the feature with mode "speed"
-- I see the bug without mode indicator
-- I see the chore without mode indicator
-
-#### Create multiple items with same title but different modes
-
-**Context:**
-- jettypod is initialized
-
-**Action:**
-- I create a feature "Duplicate" with mode "speed"
-- I create a feature "Duplicate" with mode "stable"
-
-**Expected outcome:**
-- both work items are created successfully
-- they have different modes
-
-#### Mode is case-sensitive
-
-**Context:**
-- jettypod is initialized
-
-**Action:**
-- I try to create a feature "Test" with mode "Speed"
-
-**Expected outcome:**
-- I get an error "Invalid mode"
-
-#### Mode with whitespace is invalid
-
-**Context:**
-- jettypod is initialized
-
-**Action:**
-- I try to create a feature "Test" with mode " speed "
-
-**Expected outcome:**
-- I get an error "Invalid mode"
-
-#### Empty string mode is treated as NULL
-
-**Context:**
-- jettypod is initialized
-
-**Action:**
-- I try to create a feature "Test" with mode ""
-
-**Expected outcome:**
-- I get an error "Invalid mode"
-
----
-
-### Work set-mode updates CLAUDE.md if item is current
-
-As a developer I want to change a work item's mode with jettypod work set-mode So I can adjust my approach without recreating the work item Given jettypod is initialized And CLAUDE.md exists
-
-#### Set mode on current work item updates CLAUDE.md
-
-**Context:**
-- I create a feature "Test Feature" with mode "speed"
-- I start work on the feature
-- CLAUDE.md mode is set to "speed"
-
-**Action:**
-- I set mode for current item to "stable"
-
-**Expected outcome:**
-- the work item has mode "stable"
-- CLAUDE.md mode is set to "stable"
-
-#### Set mode on non-current item does not update CLAUDE.md
-
-**Context:**
-- I create a feature "Item 1" with mode "speed"
-- I create a feature "Item 2" with mode "discovery"
-- I start work on the feature "Item 1"
-- CLAUDE.md mode is set to "speed"
-
-**Action:**
-- I set mode for item "Item 2" to "stable"
-
-**Expected outcome:**
-- item "Item 2" has mode "stable"
-
-#### Set invalid mode shows error
-
-**Context:**
-- I create a feature "Test Feature" with mode "speed"
-
-**Action:**
-- I try to set mode to "invalid"
-
-**Expected outcome:**
-- I get error "Invalid mode"
-- the work item still has mode "speed"
-
-#### Set mode is case-sensitive
-
-**Context:**
-- I create a feature "Test Feature" with mode "speed"
-- I create a feature "Test Feature" with mode "speed"
-
-**Action:**
-- I try to set mode to "Speed"
-- I set mode for current item to "<new_mode>"
-
-**Expected outcome:**
-- I get error "Invalid mode"
-- I start work on the feature
-- the work item has mode "<new_mode>"
-- CLAUDE.md mode is set to "<new_mode>"
-
-#### Mode change persists across work start/stop
-
-**Context:**
-- I create a feature "Test Feature" with mode "speed"
-- I start work on the feature
-
-**Action:**
-- I set mode for current item to "production"
-- I stop work
-- I start work on the feature
-
-**Expected outcome:**
-- CLAUDE.md mode is set to "production"
-
-#### Change mode multiple times
-
-**Context:**
-- I create a feature "Test Feature" with mode "speed"
-- I start work on the feature
-
-**Action:**
-- I set mode for current item to "discovery"
-- I set mode for current item to "stable"
-- I set mode for current item to "production"
-
-**Expected outcome:**
-- the work item has mode "production"
-- CLAUDE.md mode is set to "production"
-
----
-
-### Work start sets CLAUDE.md mode from work item
-
-As a developer I want jettypod work start to set the CLAUDE.md mode from the work item's mode So I automatically work in the correct mode for each work item Given jettypod is initialized And CLAUDE.md exists
-
-#### Start work on feature in speed mode
-
-**Context:**
-- I create a feature "Speed Feature" with mode "speed"
-
-**Action:**
-- I start work on the feature
-
-**Expected outcome:**
-- CLAUDE.md mode is set to "speed"
-
-#### Start work on bug in stable mode
-
-**Context:**
-- I create a bug "Stable Bug" with mode "stable"
-
-**Action:**
-- I start work on the bug
-
-**Expected outcome:**
-- CLAUDE.md mode is set to "stable"
-
-#### Start work on chore inherits parent feature mode
-
-**Context:**
-- I create a feature "Discovery Feature" with mode "discovery"
-- I create a chore "Child Chore" without mode and parent feature
-
-**Action:**
-- I start work on the chore
-
-**Expected outcome:**
-- CLAUDE.md mode is set to "discovery"
-
-#### Start work on feature in production mode
-
-**Context:**
-- I create a feature "Production Feature" with mode "production"
-
-**Action:**
-- I start work on the feature
-
-**Expected outcome:**
-- CLAUDE.md mode is set to "production"
-
-#### Switch from speed mode item to stable mode item
-
-**Context:**
-- I create a feature "Speed Feature" with mode "speed"
-- I create a bug "Stable Bug" with mode "stable"
-- I start work on the feature
-- CLAUDE.md mode is set to "speed"
-
-**Action:**
-- I stop work
-- I start work on the bug
-
-**Expected outcome:**
-- CLAUDE.md mode is set to "stable"
-
-#### Start work updates mode even if item already in progress
-
-**Context:**
-- I create a feature "Test Feature" with mode "discovery"
-- the feature status is "in_progress"
-- CLAUDE.md has mode "speed"
-
-**Action:**
-- I start work on the feature
-
-**Expected outcome:**
-- CLAUDE.md mode is set to "discovery"
-
-#### Start work on epic (NULL mode)
-
-**Context:**
-- I create an epic "Test Epic" without mode
-
-**Action:**
-- I start work on the epic
-
-**Expected outcome:**
-- CLAUDE.md has no mode line
-- the current work section exists
-
-#### Start work on feature with default discovery mode
-
-**Context:**
-- I create a feature "Default Feature" without mode
-- the work item has mode "discovery"
-
-**Action:**
-- I start work on the feature
-
-**Expected outcome:**
-- CLAUDE.md mode is set to "discovery"
-
-#### Start work on child features use their own mode, not parent's
-
-**Context:**
-- I create an epic "Test Epic" without mode
-- I create a feature "Speed Feature" with mode "speed" and parent epic
-- I create a feature "Stable Feature" with mode "stable" and parent epic
-
-**Action:**
-- I start work on the speed feature
-- I stop work
-
-**Expected outcome:**
-- CLAUDE.md mode is set to "speed"
-- I start work on the stable feature
-- CLAUDE.md mode is set to "stable"
-
-#### Work item mode persists in database after start
-
-**Context:**
-- I create a feature "Test Feature" with mode "stable"
-
-**Action:**
-- I start work on the feature
-- I stop work
-
-**Expected outcome:**
-- the work item still has mode "stable"
-
-#### Starting work multiple times preserves mode
-
-**Context:**
-- I create a feature "Test Feature" with mode "production"
-
-**Action:**
-- I start work on the feature
-- I stop work
-- I start work on the feature
-
-**Expected outcome:**
-- CLAUDE.md mode is set to "production"
-- the work item still has mode "production"
-
----
-