edsger 0.50.0 → 0.52.0

package/dist/skills/phase/pr-splitting/SKILL.md

@@ -1,24 +1,24 @@
 ---
-description: Split feature implementation into multiple smaller, reviewable pull requests
+description: Split issue implementation into multiple smaller, reviewable pull requests
 kind: phase
 user-invocable: false
 variables:
   - BASE_BRANCH
-  - FEATURE_ID
+  - ISSUE_ID
 ---
 
-You are an expert software architect specialized in splitting feature implementations into multiple smaller, reviewable pull requests.
+You are an expert software architect specialized in splitting issue implementations into multiple smaller, reviewable pull requests.
 
-Your task is to analyze the actual code changes on the `dev/$FEATURE_ID` branch compared to `main` and create a plan to split them into multiple logical PRs.
+Your task is to analyze the actual code changes on the `dev/$ISSUE_ID` branch compared to `main` and create a plan to split them into multiple logical PRs.
 
 ## Your Environment
 
 You have full access to the repository. You can:
 
-- Run `git diff main...dev/$FEATURE_ID` to see all changes
-- Run `git diff main...dev/$FEATURE_ID -- <path>` to see changes for specific files
+- Run `git diff main...dev/$ISSUE_ID` to see all changes
+- Run `git diff main...dev/$ISSUE_ID -- <path>` to see changes for specific files
 - Read any file in the repository to understand context
-- Run `git log main...dev/$FEATURE_ID --oneline` to see commit history
+- Run `git log main...dev/$ISSUE_ID --oneline` to see commit history
 
 ## Key Principles
 
@@ -27,14 +27,14 @@ You have full access to the repository. You can:
 3. **Dependency Order**: PRs should be ordered so each one builds on the previous (database first, then API, then UI)
 4. **Independent Testability**: Each PR should not break the build when merged independently in order
 5. **Clear Boundaries**: Each PR should have clear scope — one concern per PR
-6. **Module-Based Splitting**: Split by module/domain, not just by layer. If a feature touches auth, payments, and notifications — those are separate PRs even if they're all "backend"
+6. **Module-Based Splitting**: Split by module/domain, not just by layer. If a issue touches auth, payments, and notifications — those are separate PRs even if they're all "backend"
 
 ## PR Branch Naming Convention
 
 Branch names MUST follow this pattern:
 
-- `pr/$FEATURE_ID/1-{short-description}`
-- `pr/$FEATURE_ID/2-{short-description}`
+- `pr/$ISSUE_ID/1-{short-description}`
+- `pr/$ISSUE_ID/2-{short-description}`
 - etc.
 
 ## PR Dependencies (Stacked PRs)
@@ -48,7 +48,7 @@ PRs are created as **stacked branches** — each dependent PR's branch is create
 Use `depends_on_branch_name` to specify which PR must be merged before this one:
 
 - First PR: `"depends_on_branch_name": null` (merges directly to main)
-- Subsequent PRs: `"depends_on_branch_name": "pr/$FEATURE_ID/1-database"` (depends on previous PR)
+- Subsequent PRs: `"depends_on_branch_name": "pr/$ISSUE_ID/1-database"` (depends on previous PR)
 
 **Important**: If file A imports from file B, and both are changed files, file B must be in the same PR as file A or in an earlier PR in the dependency chain. This ensures each PR compiles correctly.
 
@@ -57,9 +57,9 @@ Use `depends_on_branch_name` to specify which PR must be merged before this one:
 - **Database migrations and schema**: First PR
 - **Types and interfaces**: Can go with the PR that introduces them, or in a foundational PR
 - **Backend services and API routes**: Middle PRs, split by module/domain
-- **Frontend components**: Later PRs that depend on backend, split by feature area
+- **Frontend components**: Later PRs that depend on backend, split by issue area
 - **Tests**: Include with the code they test
-- **Configuration files**: Group with the feature they configure
+- **Configuration files**: Group with the issue they configure
 
 ## Handling Existing PRs During Re-sync
 
@@ -72,7 +72,7 @@ When existing PRs are provided, respect their status:
 ## Important Notes
 
 - Every changed file must be assigned to exactly one PR
-- If the feature is small enough, a single PR is fine
+- If the issue is small enough, a single PR is fine
 - Consider the reviewer's perspective: each PR should tell a coherent story
 - Database migrations should be in the earliest PR possible
 - Analyze the ACTUAL diff, not just file names — understand what the changes do

package/dist/skills/phase/smoke-test/SKILL.md

@@ -75,6 +75,6 @@ Rules:
 ## Common pitfalls
 
 - **Over-testing internal plumbing**: if the diff is an internal rename with no user-visible effect, skip it.
-- **Duplicating existing feature coverage**: you are testing the delta, not the whole product. The regular feature-level test cases already cover baseline behavior.
+- **Duplicating existing issue coverage**: you are testing the delta, not the whole product. The regular issue-level test cases already cover baseline behavior.
 - **Vague "verify X works" cases**: give explicit inputs and observable outputs. A tester should not have to think about what "works" means.
 - **All-critical lists**: if everything is critical, nothing is. Reserve critical for cases whose failure justifies holding the release.

package/dist/skills/phase/technical-design/SKILL.md

@@ -1,5 +1,5 @@
 ---
-description: Create comprehensive technical design documents based on feature requirements and codebase analysis
+description: Create comprehensive technical design documents based on issue requirements and codebase analysis
 kind: phase
 user-invocable: false
 variables:
@@ -7,9 +7,9 @@ variables:
   - MCP_TOKEN
 ---
 
-You are a senior software architect and technical lead specializing in creating comprehensive technical design documents. Your task is to analyze a feature and generate detailed technical design documentation.
+You are a senior software architect and technical lead specializing in creating comprehensive technical design documents. Your task is to analyze a issue and generate detailed technical design documentation.
 
-**Your Role**: Create detailed architectural design documents based on feature requirements, user stories, and test cases.
+**Your Role**: Create detailed architectural design documents based on issue requirements, user stories, and test cases.
 
 CRITICAL: You are NOT a software engineer who writes code. You are a technical architect who creates design documents, architectural diagrams in text form, and technical specifications. Your role is PURELY design-focused.
 
@@ -28,7 +28,7 @@ CRITICAL: You are NOT a software engineer who writes code. You are a technical a
    - Look for database schema files, migration files, and configuration
    - Examine documentation files (README.md, CLAUDE.md)
 
-2. **Context Analysis**: All feature information, user stories, test cases, and existing technical design are provided in the prompt
+2. **Context Analysis**: All issue information, user stories, test cases, and existing technical design are provided in the prompt
 
 3. **Design Creation**: Generate comprehensive technical design documentation that includes:
    - Architecture overview and system integration
@@ -39,7 +39,7 @@ CRITICAL: You are NOT a software engineer who writes code. You are a technical a
 
 **Important Guidelines**:
 
-- All feature information is provided in the prompt - do NOT attempt to fetch additional context
+- All issue information is provided in the prompt - do NOT attempt to fetch additional context
 - Focus on creating comprehensive technical specifications
 - Consider integration with existing systems and architecture
 - Address scalability, maintainability, and performance

package/dist/skills/phase/test-cases-analysis/SKILL.md

@@ -1,10 +1,10 @@
 ---
-description: Analyze a feature and its user stories to generate comprehensive test cases
+description: Analyze a issue and its user stories to generate comprehensive test cases
 kind: phase
 user-invocable: false
 ---
 
-You are an expert QA Engineer and Test Architect specializing in comprehensive test case design. Your task is to analyze a feature and its user stories to generate thorough, high-quality test cases.
+You are an expert QA Engineer and Test Architect specializing in comprehensive test case design. Your task is to analyze a issue and its user stories to generate thorough, high-quality test cases.
 
 **Your Role**: You are a senior QA professional who designs test strategies at top tech companies. You create test cases that ensure complete coverage and catch issues before they reach production.
 
@@ -31,7 +31,7 @@ Every test case you create MUST follow these quality standards:
    - **Security**: Authentication, authorization, data protection
    - **Performance**: Load handling, response times, resource usage
    - **Accessibility**: Screen reader support, keyboard navigation
-   - **Integration**: Interactions with other features and systems
+   - **Integration**: Interactions with other issues and systems
 
 **Analysis Process**:
 
@@ -43,7 +43,7 @@ Every test case you create MUST follow these quality standards:
 
 **Important Guidelines**:
 
-- All feature information, user stories, and existing test cases are provided in the prompt
+- All issue information, user stories, and existing test cases are provided in the prompt
 - Do NOT attempt to read source code files or run any commands
 - Do NOT use tools like Bash, Read, Glob, Write, TodoWrite, or any other tools
 - Focus exclusively on creating high-quality test cases

package/dist/skills/phase/user-stories-analysis/SKILL.md

@@ -1,21 +1,21 @@
 ---
-description: Analyze a feature and generate comprehensive, professional user stories
+description: Analyze a issue and generate comprehensive, professional user stories
 kind: phase
 user-invocable: false
 ---
 
-You are a **Senior Product Manager** specializing in writing professional, detailed user stories. Your task is to analyze a feature and generate comprehensive, high-quality user stories.
+You are a **Senior Product Manager** specializing in writing professional, detailed user stories. Your task is to analyze a issue and generate comprehensive, high-quality user stories.
 
 **Your Role**: You are an expert product manager conducting rigorous business analysis. You think like a PM who has shipped products at top tech companies. You write user stories that engineers love because they are clear, specific, and leave no ambiguity.
 
-CRITICAL: You are NOT a software engineer. You should NEVER write code, build projects, or modify files. Your role is PURELY analytical - focus on understanding the feature requirements and creating professional user stories.
+CRITICAL: You are NOT a software engineer. You should NEVER write code, build projects, or modify files. Your role is PURELY analytical - focus on understanding the issue requirements and creating professional user stories.
 
 **Professional User Story Format**:
 Every user story you create MUST follow this professional format:
 
-1. **Sequential ID**: A unique identifier with a prefix derived from the feature name (e.g., "PR-001" for "Potential Risk" feature, "CL-001" for "Conversation Lens" feature). Use a 2-3 letter abbreviation of the feature name.
+1. **Sequential ID**: A unique identifier with a prefix derived from the issue name (e.g., "PR-001" for "Potential Risk" issue, "CL-001" for "Conversation Lens" issue). Use a 2-3 letter abbreviation of the issue name.
 
-2. **Shortname**: A concise 2-5 word name that captures the essence of the story (e.g., "Risk Tab Access", "Beta Feature Awareness").
+2. **Shortname**: A concise 2-5 word name that captures the essence of the story (e.g., "Risk Tab Access", "Beta Issue Awareness").
 
 3. **Category/Group**: Stories should be logically grouped by functional area (e.g., "Core Interface & Navigation", "Data Display & Visualization", "Configuration & Settings").
 
@@ -24,7 +24,7 @@ Every user story you create MUST follow this professional format:
    - Be SPECIFIC about the goal (not vague desires - concrete actions)
    - Be SPECIFIC about the benefit (measurable or observable outcomes)
 
-5. **Description**: A detailed paragraph (2-4 sentences) that provides context and explains the story in depth. This should describe what the feature does, how it integrates with existing functionality, and why it matters.
+5. **Description**: A detailed paragraph (2-4 sentences) that provides context and explains the story in depth. This should describe what the issue does, how it integrates with existing functionality, and why it matters.
 
 6. **Requirements**: A bulleted list of 4-8 specific, testable implementation requirements. Each requirement should be:
    - Concrete and unambiguous
@@ -44,13 +44,13 @@ Every user story MUST follow the INVEST criteria:
 
 **Analysis Process**:
 
-1. **Understand the Feature**: Deeply analyze the feature description, product context, and any images/screenshots
-2. **Identify User Personas**: Determine all relevant user types/roles who interact with this feature
+1. **Understand the Issue**: Deeply analyze the issue description, product context, and any images/screenshots
+2. **Identify User Personas**: Determine all relevant user types/roles who interact with this issue
 3. **Map User Journeys**: Think through complete user workflows and interactions
 4. **Identify Functional Areas**: Group related functionality into categories
 5. **Review Existing Stories**: Check for duplicates and gaps in existing user stories
 6. **Create Stories**: Write professional stories following the format above
-7. **Validate Coverage**: Ensure all aspects of the feature are covered
+7. **Validate Coverage**: Ensure all aspects of the issue are covered
 
 **Business Analysis Focus**:
 
@@ -60,11 +60,11 @@ Every user story MUST follow the INVEST criteria:
 - Configuration, settings, and customization options
 - Error handling and edge cases from a user perspective
 - Accessibility and usability considerations
-- Integration with existing features and workflows
+- Integration with existing issues and workflows
 
 **Important Guidelines**:
 
-- All feature information, product context, and existing user stories are provided in the prompt
+- All issue information, product context, and existing user stories are provided in the prompt
 - Do NOT attempt to read source code files or run any commands
 - Do NOT use tools like Bash, Read, Glob, Write, TodoWrite, or any other tools
 - Focus exclusively on creating high-quality, professional user stories
@@ -75,7 +75,7 @@ Every user story MUST follow the INVEST criteria:
 You can delete existing draft user stories that are:
 
 - **Duplicates**: Already covered by other stories
-- **No longer relevant**: Feature requirements changed
+- **No longer relevant**: Issue requirements changed
 - **Low quality**: Don't meet professional standards
 - **Addressed by feedback**: Explicitly requested for deletion
 
@@ -113,6 +113,6 @@ CRITICAL: Checklists are not optional suggestions - they are mandatory quality g
 - Requirements should be specific, testable, and user-focused
 - Description should provide enough context for any team member to understand
 - Stories should cover different user personas comprehensively
-- Aim for 8-20 stories per feature depending on complexity
+- Aim for 8-20 stories per issue depending on complexity
 
 Focus on systematic analysis based on the provided context information.

package/dist/system/session-manager.d.ts

@@ -14,8 +14,8 @@ export interface CliSession {
     status: SessionStatus;
     startedAt: string;
     lastHeartbeat: string;
-    currentFeatureId?: string;
-    currentFeatureName?: string;
+    currentIssueId?: string;
+    currentIssueName?: string;
 }
 /**
  * Register this CLI session with the server.
@@ -28,7 +28,7 @@ export declare function registerSession(options?: {
 /**
  * Send a heartbeat to keep the session alive and check for commands
  */
-export declare function sendHeartbeat(currentFeatureId?: string, currentFeatureName?: string): Promise<SessionStatus>;
+export declare function sendHeartbeat(currentIssueId?: string, currentIssueName?: string): Promise<SessionStatus>;
 /**
  * Start periodic heartbeats
  */

package/dist/system/session-manager.js

@@ -57,7 +57,7 @@ export async function registerSession(options) {
 /**
  * Send a heartbeat to keep the session alive and check for commands
  */
-export async function sendHeartbeat(currentFeatureId, currentFeatureName) {
+export async function sendHeartbeat(currentIssueId, currentIssueName) {
     if (!currentSessionId) {
         return 'running';
     }
@@ -66,8 +66,8 @@ export async function sendHeartbeat(currentFeatureId, currentFeatureName) {
             session_id: currentSessionId,
             version: getVersion(),
             status: _sessionStatus,
-            current_feature_id: currentFeatureId,
-            current_feature_name: currentFeatureName,
+            current_issue_id: currentIssueId,
+            current_issue_name: currentIssueName,
         }));
         // Server may respond with a new status (e.g., 'paused' or 'stopped')
         if (result.status && result.status !== _sessionStatus) {

package/dist/system/sleep-notification.js

@@ -50,7 +50,7 @@ export function startSleepMonitor() {
                     if (assertions.includes('PreventUserIdleSystemSleep') &&
                         assertions.includes('PreventUserIdleSystemSleep             0')) {
                         logWarning('System sleep prevention assertion is not active');
-                        showNotification('Edsger CLI', 'Sleep prevention may have stopped. Edsger is still processing features.');
+                        showNotification('Edsger CLI', 'Sleep prevention may have stopped. Edsger is still processing issues.');
                     }
                 }
                 catch {
@@ -74,7 +74,7 @@ export function startSleepMonitor() {
                 sleepMonitorProcess.stdout?.on('data', (data) => {
                     const output = data.toString();
                     if (output.includes('boolean true')) {
-                        showNotification('Edsger CLI', 'Edsger is processing features. Are you sure you want to sleep?');
+                        showNotification('Edsger CLI', 'Edsger is processing issues. Are you sure you want to sleep?');
                     }
                 });
                 sleepMonitorProcess.on('error', () => {

package/dist/system/sleep-prevention.js

@@ -43,7 +43,7 @@ export function startSleepPrevention() {
                 sleepPreventionProcess = spawn('systemd-inhibit', [
                     '--what=idle:sleep',
                     '--who=edsger',
-                    '--why=Processing features',
+                    '--why=Processing issues',
                     '--mode=block',
                     'sleep',
                     'infinity',

package/dist/types/index.d.ts

@@ -7,13 +7,13 @@ export interface EdsgerConfig {
         timeout?: number;
     };
     workflow: {
-        /** Max concurrent feature workers (hard cap: 10). Default: 3 */
+        /** Max concurrent issue workers (hard cap: 10). Default: 3 */
         maxConcurrency: number;
-        /** Interval in ms between polling for new features. Default: 30000 */
+        /** Interval in ms between polling for new issues. Default: 30000 */
         pollInterval: number;
-        /** Max retry attempts for a failed feature. Default: 3 */
+        /** Max retry attempts for a failed issue. Default: 3 */
         maxRetries: number;
-        /** Cooldown in ms before retrying a failed feature. Default: 300000 (5 min) */
+        /** Cooldown in ms before retrying a failed issue. Default: 300000 (5 min) */
         retryCooldown: number;
         /** Max time in ms a worker can run before being killed. Default: 1800000 (30 min) */
         workerTimeout: number;
@@ -87,10 +87,10 @@ export interface VerificationResult {
     summary: string;
     overall_suggestions?: string[];
 }
-export interface FeatureAnalysisResult {
-    featureId: string;
+export interface IssueAnalysisResult {
+    issueId: string;
     productInfo: unknown;
-    featureInfo: unknown;
+    issueInfo: unknown;
     existingUserStories: UserStory[];
     existingTestCases: TestCase[];
     createdUserStories: UserStory[];
@@ -107,8 +107,8 @@ export interface FeatureAnalysisResult {
         deletion_reasons?: Record<string, string>;
     };
 }
-export interface FeatureData {
-    feature: {
+export interface IssueData {
+    issue: {
         id: string;
         name: string;
         description: string;
@@ -122,7 +122,7 @@ export interface FeatureData {
         name: string;
         description: string;
         status: string;
-        features: unknown[];
+        issues: unknown[];
         metadata: {
             created_at: string;
             updated_at: string;
@@ -155,15 +155,15 @@ export interface DisplayTestCase {
     name: string;
     is_critical?: boolean;
 }
-export interface FeatureAnalysisDisplayResult {
-    featureId: string;
+export interface IssueAnalysisDisplayResult {
+    issueId: string;
     status: string;
     summary?: string;
     createdUserStories?: DisplayUserStory[];
     createdTestCases?: DisplayTestCase[];
 }
-export type FeatureStatus = 'backlog' | 'ready_for_ai' | 'assigned_to_ai' | 'feature_analysis' | 'feature_analysis_verification' | 'user_stories_analysis' | 'user_stories_analysis_verification' | 'test_cases_analysis' | 'test_cases_analysis_verification' | 'technical_design' | 'technical_design_verification' | 'branch_planning' | 'branch_planning_verification' | 'code_implementation' | 'code_implementation_verification' | 'pr_splitting' | 'pr_splitting_verification' | 'pr_execution' | 'code_refine' | 'code_refine_verification' | 'bug_fixing' | 'code_review' | 'functional_testing' | 'ready_for_review' | 'shipped' | 'testing_in_progress' | 'testing_passed' | 'testing_failed' | 'archived';
-export type ChatChannelType = 'feature' | 'product' | 'general';
+export type IssueStatus = 'backlog' | 'ready_for_ai' | 'assigned_to_ai' | 'issue_analysis' | 'issue_analysis_verification' | 'user_stories_analysis' | 'user_stories_analysis_verification' | 'test_cases_analysis' | 'test_cases_analysis_verification' | 'technical_design' | 'technical_design_verification' | 'branch_planning' | 'branch_planning_verification' | 'code_implementation' | 'code_implementation_verification' | 'pr_splitting' | 'pr_splitting_verification' | 'pr_execution' | 'code_refine' | 'code_refine_verification' | 'bug_fixing' | 'code_review' | 'functional_testing' | 'ready_for_review' | 'shipped' | 'testing_in_progress' | 'testing_passed' | 'testing_failed' | 'archived';
+export type ChatChannelType = 'issue' | 'product' | 'general';
 export type ChatMode = 'group' | 'direct' | 'ai_assistant';
 export type ChatSenderType = 'human' | 'ai' | 'system';
 export type ChatMessageType = 'text' | 'action_request' | 'action_result' | 'question' | 'answer' | 'options';
@@ -212,8 +212,8 @@ export interface ChatWorkerInitMessage {
     verbose?: boolean;
 }
 export interface ChatWorkerPhaseEvent {
-    type: 'event:phase_completed' | 'event:phase_failed' | 'event:feature_done' | 'event:feature_started';
-    featureId: string;
+    type: 'event:phase_completed' | 'event:phase_failed' | 'event:issue_done' | 'event:issue_started';
+    issueId: string;
     phase?: string;
     summary?: string;
     phaseOutput?: unknown;
@@ -221,15 +221,15 @@ export interface ChatWorkerPhaseEvent {
     repoPath?: string;
 }
 export interface ChatWorkerCommand {
-    type: 'command:pause_feature' | 'command:resume_feature';
-    featureId: string;
+    type: 'command:pause_issue' | 'command:resume_issue';
+    issueId: string;
 }
 export interface ChatWorkerQuery {
-    type: 'query:active_features';
+    type: 'query:active_issues';
 }
 export interface ChatWorkerReply {
-    type: 'reply:active_features';
-    features: {
+    type: 'reply:active_issues';
+    issues: {
         id: string;
         name: string;
         phase: string;

package/dist/types/{features.d.ts → issues.d.ts}

@@ -1,5 +1,5 @@
-import { type FeatureWorkflow } from './pipeline.js';
-export interface FeatureInfo {
+import { type IssueWorkflow } from './pipeline.js';
+export interface IssueInfo {
     id: string;
     name: string;
     description?: string;
@@ -7,7 +7,7 @@ export interface FeatureInfo {
     status: string;
     product_id: string;
     execution_mode?: string;
-    workflow?: FeatureWorkflow | null;
+    workflow?: IssueWorkflow | null;
     autonomous_hours?: number;
     created_at?: string;
     updated_at?: string;

package/dist/types/pipeline.d.ts

@@ -3,20 +3,20 @@
  */
 import { type ChecklistPhaseContext } from '../services/checklist.js';
 import { type EdsgerConfig } from './index.js';
-export type ExecutionMode = 'full_pipeline' | 'only_feature_analysis' | 'only_user_stories_analysis' | 'only_test_cases_analysis' | 'only_technical_design' | 'only_branch_planning' | 'only_code_implementation' | 'only_pr_splitting' | 'only_pr_execution' | 'only_functional_testing' | 'only_code_refine' | 'only_code_review' | 'from_feature_analysis' | 'from_user_stories_analysis' | 'from_test_cases_analysis' | 'from_technical_design' | 'from_branch_planning' | 'from_code_implementation' | 'from_pr_splitting' | 'from_pr_execution' | 'from_functional_testing' | 'from_code_review' | 'custom' | 'autonomous';
+export type ExecutionMode = 'full_pipeline' | 'only_issue_analysis' | 'only_user_stories_analysis' | 'only_test_cases_analysis' | 'only_technical_design' | 'only_branch_planning' | 'only_code_implementation' | 'only_pr_splitting' | 'only_pr_execution' | 'only_functional_testing' | 'only_code_refine' | 'only_code_review' | 'from_issue_analysis' | 'from_user_stories_analysis' | 'from_test_cases_analysis' | 'from_technical_design' | 'from_branch_planning' | 'from_code_implementation' | 'from_pr_splitting' | 'from_pr_execution' | 'from_functional_testing' | 'from_code_review' | 'custom' | 'autonomous';
 export type WorkflowPhaseStatus = 'pending' | 'completed';
 export interface WorkflowPhase {
     phase: string;
     status: WorkflowPhaseStatus;
     executed_at?: string;
 }
-export type FeatureWorkflow = WorkflowPhase[];
+export type IssueWorkflow = WorkflowPhase[];
 export interface PipelinePhaseOptions {
-    readonly featureId: string;
+    readonly issueId: string;
     readonly verbose?: boolean;
 }
 export interface PipelineResult {
-    readonly featureId: string;
+    readonly issueId: string;
     readonly phase: string;
     readonly status: 'success' | 'error' | 'blocked';
     readonly message: string;

package/dist/updater/auto-updater.d.ts

@@ -1,11 +1,11 @@
 /**
  * Auto Updater - Checks for and applies CLI updates automatically
  *
- * Features:
+ * Issues:
  * - Checks npm registry for latest version
  * - Compares with current version
  * - Updates the package globally
- * - New feature workers automatically use the updated code (fork-based architecture)
+ * - New issue workers automatically use the updated code (fork-based architecture)
  */
 /**
  * Get the latest published version from npm registry

package/dist/updater/auto-updater.js

@@ -1,11 +1,11 @@
 /**
  * Auto Updater - Checks for and applies CLI updates automatically
  *
- * Features:
+ * Issues:
  * - Checks npm registry for latest version
  * - Compares with current version
  * - Updates the package globally
- * - New feature workers automatically use the updated code (fork-based architecture)
+ * - New issue workers automatically use the updated code (fork-based architecture)
  */
 import { execSync } from 'child_process';
 import { getVersion, resetVersionCache } from '../constants.js';
@@ -100,7 +100,7 @@ export function checkAndUpdate() {
             logInfo(`Update available: v${currentVersion} -> v${latestVersion}`);
             const success = performUpdate();
             if (success) {
-                logSuccess('Update applied. New feature workers will use the updated version automatically.');
+                logSuccess('Update applied. New issue workers will use the updated version automatically.');
             }
         }
         else {

package/dist/utils/conflict-resolver.d.ts

@@ -9,7 +9,7 @@ export interface ConflictResolverConfig {
     model?: string;
     verbose?: boolean;
     maxTurns?: number;
-    featureBranch?: string;
+    issueBranch?: string;
     baseBranch?: string;
     /**
      * Original base branch before squash merge.

package/dist/utils/conflict-resolver.js

@@ -80,11 +80,11 @@ IMPORTANT:
 /**
  * Create the initial prompt describing the rebase task
  */
-function createRebaseTaskPrompt(featureBranch, baseBranch, conflictFiles, originalBaseBranch) {
+function createRebaseTaskPrompt(issueBranch, baseBranch, conflictFiles, originalBaseBranch) {
     let context = `A git rebase operation is in progress and has encountered conflicts.
 
 ## Current Situation
-- Feature branch: ${featureBranch}
+- Issue branch: ${issueBranch}
 - Rebasing onto: ${baseBranch}`;
     if (originalBaseBranch) {
         context += `
@@ -117,17 +117,17 @@ Start by running "git status" to see the current state.`;
  */
 // eslint-disable-next-line complexity -- orchestration function with conflict detection, agent resolution, and cleanup
 export async function resolveConflictsWithAgent(config = {}) {
-    const { model = 'sonnet', verbose, maxTurns = 100, featureBranch, baseBranch, originalBaseBranch, baseBranchCompleted, } = config;
+    const { model = 'sonnet', verbose, maxTurns = 100, issueBranch, baseBranch, originalBaseBranch, baseBranchCompleted, } = config;
     const _resolvedFiles = [];
     if (verbose) {
         logInfo(`\n🔧 Starting automatic conflict resolution with Claude agent...`);
     }
     // Get initial conflict information
-    const currentBranch = featureBranch || getCurrentBranch();
+    const currentBranch = issueBranch || getCurrentBranch();
     const targetBranch = baseBranch || 'main';
     const initialConflictFiles = getConflictFiles();
     if (verbose) {
-        logInfo(`   Feature branch: ${currentBranch}`);
+        logInfo(`   Issue branch: ${currentBranch}`);
         logInfo(`   Rebasing onto: ${targetBranch}`);
         if (originalBaseBranch) {
             logInfo(`   Original base (--onto): ${originalBaseBranch}`);

package/dist/utils/formatters.d.ts

@@ -1,8 +1,8 @@
 import { type CodeImplementationContext } from '../phases/code-implementation/context.js';
-import { type FeatureAnalysisContext } from '../phases/feature-analysis/context.js';
 import { type FunctionalTestingContext } from '../phases/functional-testing/context-fetcher.js';
+import { type IssueAnalysisContext } from '../phases/issue-analysis/context.js';
 import { type TechnicalDesignContext } from '../phases/technical-design/context.js';
-import type { TestCase, UserStory } from '../types/features.js';
+import type { TestCase, UserStory } from '../types/issues.js';
 import { type DownloadedImage } from './image-downloader.js';
 /**
  * Format user stories for display in prompts
@@ -20,9 +20,9 @@ export declare function formatTechnicalDesignContext(context: TechnicalDesignCon
     downloadedImages: DownloadedImage[];
 }>;
 /**
- * Format feature analysis context for Claude Code prompts
+ * Format issue analysis context for Claude Code prompts
  */
-export declare function formatFeatureAnalysisContext(context: FeatureAnalysisContext): Promise<{
+export declare function formatIssueAnalysisContext(context: IssueAnalysisContext): Promise<{
     content: string;
     downloadedImages: DownloadedImage[];
 }>;