jettypod 4.1.2 → 4.1.4

package/features/production-mode-skill.feature

@@ -1,121 +0,0 @@
-Feature: 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
-
-Scenario: Fresh from stable mode - Quick validation (Scenario A)
-  Given a feature just completed stable mode within 1 day
-  And production scenarios already exist in the feature file
-  And production chores already exist for the feature
-  And production standards file exists
-  When I start the production-mode skill for this feature
-  Then 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
-
-Scenario: Gap in time - Re-validation (Scenario B)
-  Given a feature completed stable mode over 7 days ago
-  And production scenarios exist in the feature file
-  And production chores exist for the feature
-  And production standards file exists
-  When I start the production-mode skill for this feature
-  Then 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
-
-Scenario: Post external-transition - Generate from standards (Scenario C)
-  Given a feature in stable mode with no production scenarios
-  And no production chores exist for the feature
-  And production standards file exists from external-transition
-  When I start the production-mode skill for this feature
-  Then 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
-
-# STABLE MODE SCENARIOS - Error Handling and Edge Cases
-
-Scenario: Missing production standards file
-  Given a feature in stable mode
-  And the production standards file does not exist at .jettypod/production-standards.json
-  When I start the production-mode skill for this feature
-  Then it fails with error "Production standards file not found"
-  And it suggests running external-transition first
-
-Scenario: Corrupted production standards file
-  Given a feature in stable mode
-  And the production standards file exists but contains malformed JSON
-  When I start the production-mode skill for this feature
-  Then it fails with error "Failed to parse production standards"
-  And it shows the JSON parsing error details
-
-Scenario: Invalid production standards format
-  Given a feature in stable mode
-  And the production standards file exists with valid JSON
-  But the standards array is missing required fields
-  When I start the production-mode skill for this feature
-  Then it fails with error "Invalid standards format"
-  And it specifies which required fields are missing
-
-Scenario: Missing scenario file for feature
-  Given a feature in stable mode
-  And the feature has no scenario_file set in database
-  When I start the production-mode skill for this feature
-  Then it fails with error "Feature has no scenario file"
-  And it suggests the feature may not be properly initialized
-
-Scenario: Scenario file does not exist on disk
-  Given a feature in stable mode
-  And the feature has scenario_file set in database
-  But the file does not exist at that path
-  When I start the production-mode skill for this feature
-  Then it fails with error "Scenario file not found"
-  And it shows the expected file path
-
-Scenario: Feature not found in database
-  Given an invalid feature ID
-  When I start the production-mode skill with that feature ID
-  Then it fails with error "Feature not found"
-
-Scenario: Feature has no completed_at timestamp
-  Given a feature marked as done in stable mode
-  But the completed_at field is null
-  When the context detector checks time since stable completion
-  Then it treats this as Scenario C (no production content yet)
-
-Scenario: File permission error reading standards
-  Given a feature in stable mode
-  And the production standards file exists
-  But the file is not readable due to permissions
-  When I start the production-mode skill for this feature
-  Then it fails with error indicating permission denied
-  And it shows the file path with permission issues
-
-Scenario: File permission error writing scenarios
-  Given a feature in Scenario C (generating scenarios)
-  And production standards are loaded successfully
-  But the scenario file is not writable due to permissions
-  When attempting to append scenarios to the file
-  Then it fails with error indicating write permission denied
-
-Scenario: Empty standards array
-  Given a feature in stable mode
-  And the production standards file exists with empty standards array
-  When I start the production-mode skill for this feature
-  Then it completes successfully
-  And reports 0 standards to implement
-
-Scenario: Database connection error
-  Given the database file is locked or corrupted
-  When I start the production-mode skill
-  Then it fails with database error
-  And it suggests checking database integrity
-
-# PRODUCTION MODE: Will add scale/security scenarios

package/features/refactor-mode/steps.js

@@ -1,217 +0,0 @@
-const { Given, When, Then } = require('@cucumber/cucumber');
-const assert = require('assert');
-
-// State for scenarios
-let auditResults = null;
-let selectedCategory = null;
-let detailedBreakdown = null;
-let createdEpic = null;
-let createdChores = [];
-
-Given('I have existing work items in the system', function () {
-  // For integration test - work items exist in test DB
-  this.existingWorkItems = true;
-});
-
-Given("I'm in a project with technical debt", function () {
-  // Mock project with technical debt
-  this.projectHasDebt = true;
-});
-
-Given('I see the audit menu', function () {
-  // Previous step set auditResults
-  assert(auditResults, 'Audit results should be available');
-});
-
-Given('I see the detailed breakdown for {string}', function (category) {
-  // Previous step set detailedBreakdown
-  assert(detailedBreakdown, 'Detailed breakdown should be available');
-  assert.strictEqual(detailedBreakdown.category, category);
-});
-
-Given('I see recommendations for Storage Pattern', function () {
-  // Recommendations were shown in previous step
-  this.hasRecommendations = true;
-});
-
-When('I enter refactor mode and audit the codebase', function () {
-  // Simulate entering refactor mode with audit
-  auditResults = {
-    codeSmells: { count: 5, summary: 'Long functions, duplicated code' },
-    featureSpecific: { count: 3, summary: 'features/auth/ has patterns' },
-    architectural: { count: 15, summary: 'Storage patterns duplicated' },
-    performance: { count: 4, summary: 'Unnecessary re-renders' }
-  };
-});
-
-When('I enter refactor mode', function () {
-  // Simulate entering refactor mode
-  auditResults = {
-    codeSmells: { count: 5, summary: 'Long functions' },
-    featureSpecific: { count: 3, summary: 'features/auth/' },
-    architectural: { count: 15, summary: 'Storage patterns' },
-    performance: { count: 4, summary: 'Re-renders' }
-  };
-});
-
-When('I select {string} category', function (category) {
-  selectedCategory = category;
-});
-
-When('I pick {string} category', function (category) {
-  selectedCategory = category;
-  // Generate detailed breakdown
-  detailedBreakdown = {
-    category,
-    items: [
-      {
-        name: 'Storage Pattern',
-        count: 15,
-        type: '🟠 Cross-Cutting',
-        impact: 'High - affects all features',
-        time: '2 hours',
-        files: ['auth.js', 'expenses.js', '+13 more'],
-        example: 'localStorage.getItem() duplicated'
-      }
-    ]
-  };
-});
-
-When('I approve creating chores for storage pattern', function () {
-  // User approved - create chores
-  createdEpic = {
-    id: 999,
-    title: 'Refactor: Architectural patterns',
-    type: 'epic'
-  };
-
-  createdChores = [
-    {
-      id: 1000,
-      title: 'Create shared storage util',
-      epicId: 999,
-      type: 'chore'
-    },
-    {
-      id: 1001,
-      title: 'Migrate auth to storage util',
-      epicId: 999,
-      type: 'chore'
-    }
-  ];
-});
-
-When('Claude analyzes impact vs time', function () {
-  // Claude analyzes and generates recommendations
-  this.recommendations = {
-    quickWin: 'Storage Pattern (quick win, high impact)',
-    warning: 'State Management (needs Discovery Mode first)'
-  };
-});
-
-When('I say {string}', function (userInput) {
-  if (userInput === 'create chores') {
-    // User approved - create chores
-    createdEpic = {
-      id: 999,
-      title: 'Refactor: Architectural patterns',
-      type: 'epic'
-    };
-
-    createdChores = [
-      {
-        id: 1000,
-        title: 'Create shared storage util',
-        epicId: 999,
-        type: 'chore'
-      },
-      {
-        id: 1001,
-        title: 'Migrate auth to storage util',
-        epicId: 999,
-        type: 'chore'
-      }
-    ];
-  }
-});
-
-Then('Claude audits the codebase', function () {
-  assert(auditResults, 'Audit should have run');
-});
-
-Then('I see categorized menu with counts:', function (dataTable) {
-  const expectedCategories = dataTable.hashes();
-
-  // Verify we have results for each category
-  assert(auditResults.codeSmells, 'Should have code smells results');
-  assert(auditResults.featureSpecific, 'Should have feature-specific results');
-  assert(auditResults.architectural, 'Should have architectural results');
-  assert(auditResults.performance, 'Should have performance results');
-
-  // Verify counts are present
-  assert(auditResults.codeSmells.count > 0, 'Code smells count should be > 0');
-  assert(auditResults.architectural.count > 0, 'Architectural count should be > 0');
-});
-
-Then('I see detailed items with:', function (dataTable) {
-  const expectedFields = dataTable.hashes();
-
-  assert(detailedBreakdown, 'Should have detailed breakdown');
-  assert(detailedBreakdown.items.length > 0, 'Should have at least one item');
-
-  const item = detailedBreakdown.items[0];
-  assert(item.type, 'Item should have type');
-  assert(item.impact, 'Item should have impact');
-  assert(item.time, 'Item should have time estimate');
-  assert(item.files, 'Item should have files list');
-  assert(item.example, 'Item should have example');
-});
-
-Then('I see recommendation: {string}', function (recommendation) {
-  assert(this.recommendations, 'Should have recommendations');
-  assert(this.recommendations.quickWin.includes('Storage Pattern'), 'Should recommend Storage Pattern');
-  assert(this.recommendations.quickWin.includes('quick win'), 'Should mention quick win');
-});
-
-Then('I see warning: {string}', function (warning) {
-  assert(this.recommendations, 'Should have recommendations');
-  assert(this.recommendations.warning.includes('State Management'), 'Should warn about State Management');
-  assert(this.recommendations.warning.includes('Discovery Mode'), 'Should mention Discovery Mode');
-});
-
-Then('epic {string} is created', function (epicTitle) {
-  assert(createdEpic, 'Epic should be created');
-  assert.strictEqual(createdEpic.title, epicTitle);
-  assert.strictEqual(createdEpic.type, 'epic');
-});
-
-Then('chore {string} is created', function (choreTitle) {
-  const chore = createdChores.find(c => c.title === choreTitle);
-  assert(chore, `Chore "${choreTitle}" should be created`);
-  assert.strictEqual(chore.type, 'chore');
-});
-
-Then('refactor chores are created under an epic', function () {
-  assert(createdEpic, 'Epic should be created');
-  assert(createdChores.length > 0, 'Chores should be created');
-
-  // Verify chores are linked to epic
-  createdChores.forEach(chore => {
-    assert.strictEqual(chore.epicId, createdEpic.id, 'Chore should be linked to epic');
-  });
-});
-
-Then('the epic is linked to the refactor mode work item', function () {
-  // Epic is created as part of refactor mode workflow
-  assert(createdEpic, 'Epic should exist');
-  assert(this.existingWorkItems, 'Work items should exist');
-});
-
-Then('all chores are linked to the epic', function () {
-  assert(createdEpic, 'Epic should be created');
-  assert(createdChores.length > 0, 'Chores should be created');
-
-  createdChores.forEach(chore => {
-    assert.strictEqual(chore.epicId, createdEpic.id, 'All chores should be linked to epic');
-  });
-});

package/features/refactor-mode.feature

@@ -1,49 +0,0 @@
-Feature: Refactor Mode
-  As a developer
-  I want an interactive audit menu for refactoring
-  So that I can systematically clean up technical debt
-
-  # INTEGRATION TEST - Must work with existing work tracking
-  Scenario: Refactor mode integrates with work tracking
-    Given I have existing work items in the system
-    When I enter refactor mode and audit the codebase
-    And I select "Architectural" category
-    And I approve creating chores for storage pattern
-    Then refactor chores are created under an epic
-    And the epic is linked to the refactor mode work item
-
-  Scenario: User enters refactor mode and sees audit menu
-    Given I'm in a project with technical debt
-    When I enter refactor mode
-    Then Claude audits the codebase
-    And I see categorized menu with counts:
-      | Category            | Example                    |
-      | Code Smells         | Long functions (5 found)   |
-      | Feature-Specific    | features/auth/ (3 files)   |
-      | Architectural       | Storage patterns (15 uses) |
-      | Performance         | Re-renders (4 components)  |
-
-  Scenario: User picks category and sees detailed breakdown
-    Given I see the audit menu
-    When I pick "Architectural" category
-    Then I see detailed items with:
-      | Field   | Example                              |
-      | Type    | 🟠 Cross-Cutting                     |
-      | Impact  | High - affects all features          |
-      | Time    | 2 hours                              |
-      | Files   | auth.js, expenses.js, +13 more       |
-      | Example | localStorage.getItem() duplicated    |
-
-  Scenario: Claude recommends quick wins
-    Given I see the detailed breakdown for "Architectural"
-    When Claude analyzes impact vs time
-    Then I see recommendation: "Start with Storage Pattern (quick win, high impact)"
-    And I see warning: "Skip State Management (needs Discovery Mode first)"
-
-  Scenario: User approves and chores are created
-    Given I see recommendations for Storage Pattern
-    When I say "create chores"
-    Then 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

package/features/simplify-external-transition.feature

@@ -1,166 +0,0 @@
-Feature: 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
-
-Scenario: User transitions project to external state
-  Given I have a JettyPod project in internal state
-  And I have some features in stable mode with production chores already created
-  When I run "jettypod project external"
-  Then 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
-
-# SPEED MODE: Only happy path above
-# STABLE MODE: Error handling, edge cases, validation scenarios below
-
-Scenario: Project already in external state
-  Given I have a JettyPod project in external state
-  When I run "jettypod project external"
-  Then I should see a message "Project already in external state"
-  And no duplicate infrastructure items should be created
-  And the command should exit successfully
-
-Scenario: Infrastructure epic already exists
-  Given I have a JettyPod project in internal state
-  And an "Infrastructure Readiness" epic already exists
-  When I run "jettypod project external"
-  Then 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
-
-Scenario: Database connection fails during transition
-  Given I have a JettyPod project in internal state
-  And the database connection will fail
-  When I run "jettypod project external"
-  Then 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
-
-Scenario: Work item creation fails mid-transition
-  Given I have a JettyPod project in internal state
-  And work item creation will fail after creating the epic
-  When I run "jettypod project external"
-  Then 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
-
-Scenario: Invalid checklist data structure
-  Given I have a JettyPod project in internal state
-  And the infrastructure checklist has invalid data
-  When I run "jettypod project external"
-  Then I should see a validation error message
-  And the project_state should remain "internal"
-  And no infrastructure items should be created
-
-Scenario: Infrastructure chores generated from production standards
-  Given I have a JettyPod project in internal state
-  And I have production standards with infrastructure-scoped standards
-  And the standards include "database_backups" in infrastructure scope
-  And the standards include "monitoring_setup" in infrastructure scope
-  When I run "jettypod project external"
-  Then 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
-
-Scenario: Different presets create different infrastructure chores
-  Given I have a JettyPod project in internal state
-  And production standards are set to "startup-mvp" preset
-  When I run "jettypod project external"
-  Then infrastructure chores should match startup-mvp standards
-  And I should see fewer infrastructure chores than enterprise preset
-
-  When I change production standards to "enterprise" preset
-  And I run "jettypod project external" on a new project
-  Then 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
-
-Scenario: Scope field correctly filters infrastructure vs feature standards
-  Given I have a JettyPod project in internal state
-  And production standards include 5 infrastructure-scoped standards
-  And production standards include 8 feature-scoped standards
-  When I run "jettypod project external"
-  Then 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
-
-Scenario: Infrastructure chore created per standard (not grouped by domain)
-  Given I have a JettyPod project in internal state
-  And production standards include 3 security infrastructure standards
-  And production standards include 2 monitoring infrastructure standards
-  When I run "jettypod project external"
-  Then 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
-
-Scenario: Missing production standards file during transition
-  Given I have a JettyPod project in internal state
-  And no production standards file exists
-  When I run "jettypod project external"
-  Then 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
-
-Scenario: Infrastructure chores include pattern guidance from standards
-  Given I have a JettyPod project in internal state
-  And production standards include a standard with pattern guidance
-  And the standard has pattern "Use pg_dump with --clean flag"
-  When I run "jettypod project external"
-  Then 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
-
-# PRODUCTION MODE: Security, scale, and compliance scenarios
-
-Scenario: Audit logging for external transition
-  Given I have a JettyPod project in internal state
-  When I run "jettypod project external"
-  Then 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
-
-Scenario: Performance with large projects (1000+ work items)
-  Given I have a JettyPod project with 1000 work items
-  And the project is in internal state
-  When I run "jettypod project external"
-  Then the transition should complete in under 5 seconds
-  And memory usage should remain under 100MB
-  And all infrastructure items should be created successfully
-
-Scenario: Concurrent transition attempts are prevented
-  Given I have a JettyPod project in internal state
-  When I start "jettypod project external" in one process
-  And I attempt "jettypod project external" in another process
-  Then the second attempt should be blocked
-  And I should see "Transition already in progress"
-  And only one infrastructure epic should be created
-
-Scenario: State transition is recorded for compliance
-  Given I have a JettyPod project in internal state
-  When I run "jettypod project external"
-  Then 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
-
-Scenario: Infrastructure creation is idempotent
-  Given I have a JettyPod project in external state
-  And an "Infrastructure Readiness" epic exists
-  When I run "jettypod project external" again
-  Then no duplicate infrastructure items should be created
-  And the existing epic ID should be preserved
-  And I should see "Infrastructure already configured"