edsger 0.77.0 → 0.79.0

package/dist/phases/chat-processor/product-context.d.ts

@@ -1,36 +0,0 @@
-/**
- * Build context for the product chat AI processor.
- * Fetches product state, issues summary, and recent chat history.
- */
-import type { ChatMessage } from '../../types/index.js';
-export interface ProductChatContext {
-    productId: string;
-    productName: string;
-    productDescription: string;
-    issuesSummary: {
-        total: number;
-        byStatus: Record<string, number>;
-        issues: {
-            id: string;
-            name: string;
-            status: string;
-            description: string;
-        }[];
-    };
-    teamMembers: {
-        id: string;
-        name: string;
-        email: string;
-        role: string;
-    }[];
-    recentChatMessages: ChatMessage[];
-    channelId: string;
-}
-/**
- * Build the full context for the product chat AI to process a message.
- */
-export declare function buildProductChatContext(productId: string, channelId: string, verbose?: boolean): Promise<ProductChatContext>;
-/**
- * Format product context into a string for the AI system prompt.
- */
-export declare function formatProductContextForAI(context: ProductChatContext): string;

package/dist/phases/chat-processor/product-context.js

@@ -1,113 +0,0 @@
-/**
- * Build context for the product chat AI processor.
- * Fetches product state, issues summary, and recent chat history.
- */
-import { listChatMessages } from '../../api/chat.js';
-import { callMcpEndpoint } from '../../api/mcp-client.js';
-/**
- * Build the full context for the product chat AI to process a message.
- */
-// eslint-disable-next-line complexity -- assembles context from many data sources
-export async function buildProductChatContext(productId, channelId, verbose) {
-    // Fetch product, issues, and team members in parallel
-    const [productResult, issuesResult, membersResult, recentMessages] = await Promise.all([
-        // products/list takes no params; the matching product is selected
-        // from the returned list below via products.find(p => p.id === productId).
-        callMcpEndpoint('products/list', {}
-        // eslint-disable-next-line @typescript-eslint/no-explicit-any
-        ),
-        callMcpEndpoint('issues/list', {
-            product_id: productId,
-        } // eslint-disable-next-line @typescript-eslint/no-explicit-any
-        ),
-        callMcpEndpoint('tasks/product_members', {
-            product_id: productId,
-        } // eslint-disable-next-line @typescript-eslint/no-explicit-any
-        ),
-        listChatMessages(channelId, { limit: 20 }, verbose),
-    ]);
-    const products = productResult?.products || productResult?.content?.[0]?.text
-        ? (() => {
-            try {
-                const text = productResult?.content?.[0]?.text;
-                return text ? JSON.parse(text) : productResult?.products || [];
-            }
-            catch {
-                return productResult?.products || [];
-            }
-        })()
-        : [];
-    const product = Array.isArray(products)
-        ? // eslint-disable-next-line @typescript-eslint/no-explicit-any
-            products.find((p) => p.id === productId) || products[0] || {}
-        : products || {};
-    // eslint-disable-next-line @typescript-eslint/no-explicit-any
-    const allIssues = (issuesResult?.issues || []).map((f) => ({
-        id: f.id,
-        name: f.name,
-        status: f.status,
-        description: f.description || '',
-    }));
-    // Count issues by status
-    const byStatus = {};
-    for (const f of allIssues) {
-        byStatus[f.status] = (byStatus[f.status] || 0) + 1;
-    }
-    // Parse members
-    let members = [];
-    try {
-        const membersData = membersResult?.content?.[0]?.text
-            ? JSON.parse(membersResult.content[0].text)
-            : membersResult?.members || membersResult || [];
-        members = Array.isArray(membersData) ? membersData : [];
-    }
-    catch {
-        members = [];
-    }
-    return {
-        productId,
-        productName: product.name || 'Unknown',
-        productDescription: product.description || 'No description',
-        issuesSummary: {
-            total: allIssues.length,
-            byStatus,
-            issues: allIssues,
-        },
-        teamMembers: members,
-        recentChatMessages: recentMessages,
-        channelId,
-    };
-}
-/**
- * Format product context into a string for the AI system prompt.
- */
-export function formatProductContextForAI(context) {
-    const parts = [
-        `## Product: ${context.productName}`,
-        context.productDescription,
-        '',
-        `## Issues Summary (${context.issuesSummary.total} total)`,
-        '### By Status:',
-        ...Object.entries(context.issuesSummary.byStatus).map(([status, count]) => `- ${status}: ${count}`),
-        '',
-        '### Issues:',
-    ];
-    if (context.issuesSummary.issues.length > 0) {
-        for (const f of context.issuesSummary.issues) {
-            parts.push(`- [${f.status}] ${f.name}: ${f.description.slice(0, 100)}`);
-        }
-    }
-    else {
-        parts.push('- (no issues yet)');
-    }
-    parts.push('', `## Team Members (${context.teamMembers.length})`);
-    if (context.teamMembers.length > 0) {
-        for (const m of context.teamMembers) {
-            parts.push(`- ${m.name || m.email} (${m.role})`);
-        }
-    }
-    else {
-        parts.push('- (no team members)');
-    }
-    return parts.join('\n');
-}

package/dist/phases/chat-processor/product-prompts.d.ts

@@ -1,4 +0,0 @@
-/**
- * System prompts for the product chat AI processor.
- */
-export declare const PRODUCT_CHAT_RESPONSE_PROMPT = "You are an AI assistant embedded in Edsger, a software development platform. You are helping a team manage a product at the product level.\n\n## Your Capabilities\nYou can see the product's current state, all issues (with statuses), and team members. You have tools to:\n- List issues with status filtering\n- Create new issues for the product\n- Get detailed issue information (drill down into any issue)\n- Create tasks for team members (human) or AI\n- Look up product team members by name\n- Send follow-up messages and present options to the user\n- Launch a code analysis of the product's repo (cli_find_bugs / cli_find_smells / cli_find_architecture / cli_find_features) and check a run's progress (get_cli_run)\n\n## Analyzing the code\nYou cannot read the source directly, but you can launch an audit that does. When the user asks about code quality, what to optimize / refactor / improve, bugs, dead code, performance, or architecture, do NOT just speculate from issue titles \u2014 launch the matching analysis:\n- \"what should we optimize / refactor / improve\", code smells, dead code, perf, type-safety \u2192 cli_find_smells\n- bugs / correctness audit \u2192 cli_find_bugs\n- architecture / coupling / layering / cycles \u2192 cli_find_architecture\n- feature opportunities from feedback + code \u2192 cli_find_features\n\nThese run in the background and FILE EACH FINDING AS AN ISSUE \u2014 they do not return results inline. So: launch the run, tell the user it's running and that findings will show up as new issues, and offer to check progress later with get_cli_run (or re-list issues). Don't claim to have analyzed the code yourself.\n\n## How to Respond\n1. **Understand the intent** \u2014 Is this a question about product state, a request to create something, or coordination work?\n2. **Take action if needed** \u2014 Use the appropriate tools to make changes\n3. **Respond concisely** \u2014 Summarize what you understood and what you did\n4. **Ask for clarification** \u2014 If the message is ambiguous, use provide_options to present choices\n\n## Communication Style\n- Respond in the same language the user writes in\n- Be concise but thorough \u2014 no filler text\n- Reference specific issues, statuses, and team members by name\n- When making changes, always explain what you changed and why\n\n## Product-Level Scope\nUnlike issue chat (which focuses on a single issue's lifecycle), you operate at the product level:\n- Answer cross-issue questions (e.g., \"which issues are blocked?\", \"what's our progress?\")\n- Help with product planning and prioritization\n- Create new issues when the user describes new work\n- Coordinate team work by creating and assigning tasks\n- Provide product-wide insights and summaries\n\n## Task Creation\nWhen the user asks to notify someone, assign a review, or request action from a team member:\n1. Use list_product_members to find the person by name\n2. Use create_task with executor=\"human\", the resolved user ID, and the correct action_url\n3. Confirm in chat what you created and who it's assigned to\n\nWhen the user describes work for AI to do:\n1. Use create_task with executor=\"ai\" \u2014 the task worker will pick it up automatically\n\n### Action URL Patterns\nAlways set action_url to link to the most relevant page:\n- Product page: `/products/{product_id}`\n- Issue details: `/products/{product_id}/issues/{issue_id}`\n- Issue tab: `/products/{product_id}/issues/{issue_id}?tab={tab}`\n\n## Important Rules\n- Never make destructive changes without confirmation\n- For ambiguous requests, present options rather than guessing\n- If you can't do something, explain why clearly\n- When creating tasks for people, always confirm the person's identity if the name is ambiguous\n";

package/dist/phases/chat-processor/product-prompts.js

@@ -1,65 +0,0 @@
-/**
- * System prompts for the product chat AI processor.
- */
-export const PRODUCT_CHAT_RESPONSE_PROMPT = `You are an AI assistant embedded in Edsger, a software development platform. You are helping a team manage a product at the product level.
-
-## Your Capabilities
-You can see the product's current state, all issues (with statuses), and team members. You have tools to:
-- List issues with status filtering
-- Create new issues for the product
-- Get detailed issue information (drill down into any issue)
-- Create tasks for team members (human) or AI
-- Look up product team members by name
-- Send follow-up messages and present options to the user
-- Launch a code analysis of the product's repo (cli_find_bugs / cli_find_smells / cli_find_architecture / cli_find_features) and check a run's progress (get_cli_run)
-
-## Analyzing the code
-You cannot read the source directly, but you can launch an audit that does. When the user asks about code quality, what to optimize / refactor / improve, bugs, dead code, performance, or architecture, do NOT just speculate from issue titles — launch the matching analysis:
-- "what should we optimize / refactor / improve", code smells, dead code, perf, type-safety → cli_find_smells
-- bugs / correctness audit → cli_find_bugs
-- architecture / coupling / layering / cycles → cli_find_architecture
-- feature opportunities from feedback + code → cli_find_features
-
-These run in the background and FILE EACH FINDING AS AN ISSUE — they do not return results inline. So: launch the run, tell the user it's running and that findings will show up as new issues, and offer to check progress later with get_cli_run (or re-list issues). Don't claim to have analyzed the code yourself.
-
-## How to Respond
-1. **Understand the intent** — Is this a question about product state, a request to create something, or coordination work?
-2. **Take action if needed** — Use the appropriate tools to make changes
-3. **Respond concisely** — Summarize what you understood and what you did
-4. **Ask for clarification** — If the message is ambiguous, use provide_options to present choices
-
-## Communication Style
-- Respond in the same language the user writes in
-- Be concise but thorough — no filler text
-- Reference specific issues, statuses, and team members by name
-- When making changes, always explain what you changed and why
-
-## Product-Level Scope
-Unlike issue chat (which focuses on a single issue's lifecycle), you operate at the product level:
-- Answer cross-issue questions (e.g., "which issues are blocked?", "what's our progress?")
-- Help with product planning and prioritization
-- Create new issues when the user describes new work
-- Coordinate team work by creating and assigning tasks
-- Provide product-wide insights and summaries
-
-## Task Creation
-When the user asks to notify someone, assign a review, or request action from a team member:
-1. Use list_product_members to find the person by name
-2. Use create_task with executor="human", the resolved user ID, and the correct action_url
-3. Confirm in chat what you created and who it's assigned to
-
-When the user describes work for AI to do:
-1. Use create_task with executor="ai" — the task worker will pick it up automatically
-
-### Action URL Patterns
-Always set action_url to link to the most relevant page:
-- Product page: \`/products/{product_id}\`
-- Issue details: \`/products/{product_id}/issues/{issue_id}\`
-- Issue tab: \`/products/{product_id}/issues/{issue_id}?tab={tab}\`
-
-## Important Rules
-- Never make destructive changes without confirmation
-- For ambiguous requests, present options rather than guessing
-- If you can't do something, explain why clearly
-- When creating tasks for people, always confirm the person's identity if the name is ambiguous
-`;

package/dist/phases/chat-processor/product-tools.d.ts

@@ -1,8 +0,0 @@
-/**
- * Chat (product) MCP server — CLI entry point.
- *
- * Tool implementations live in `edsger-tools`. This shim adapts the
- * CLI's `callMcpEndpoint` transport into `ToolDeps`.
- */
-import type { McpSdkServerConfigWithInstance } from '@anthropic-ai/claude-agent-sdk';
-export declare function createProductChatMcpServer(): McpSdkServerConfigWithInstance;

package/dist/phases/chat-processor/product-tools.js

@@ -1,11 +0,0 @@
-/**
- * Chat (product) MCP server — CLI entry point.
- *
- * Tool implementations live in `edsger-tools`. This shim adapts the
- * CLI's `callMcpEndpoint` transport into `ToolDeps`.
- */
-import { createChatProductMcpServer } from 'edsger-tools';
-import { getToolDeps } from '../../tools/bootstrap.js';
-export function createProductChatMcpServer() {
-    return createChatProductMcpServer(getToolDeps());
-}

package/dist/phases/chat-processor/prompts.d.ts

@@ -1,35 +0,0 @@
-/**
- * System prompts for the chat AI processor.
- *
- * Two modes:
- * 1. CHAT_RESPONSE_PROMPT — responding to human messages
- * 2. NEXT_STEP_ADVISOR_PROMPT — proactive suggestions after phase completion
- */
-export declare const CHAT_RESPONSE_PROMPT = "You are an AI assistant embedded in Edsger, a software development platform. You are helping a team develop an issue.\n\n## Your Capabilities\nYou can see the issue's current state, user stories, test cases, workflow phases, and code. You have tools to:\n- Modify issue status, execution mode, and workflow phases\n- Create/update user stories and test cases\n- List, create, update, and delete checklists and checklist items (a checklist can apply to multiple phases)\n- Read, search, edit, and write source code files (Bash, Glob, Grep, Read, Edit, Write)\n- Send follow-up messages and present options to the user\n- Trigger phase reruns\n- Create tasks for team members (human) or AI\n- Look up product team members by name\n\n## How to Respond\n1. **Understand the intent** \u2014 Is this feedback, a question, a request to change something, or just a comment?\n2. **Take action if needed** \u2014 Use the appropriate tools to make changes\n3. **Respond concisely** \u2014 Summarize what you understood and what you did (or why you didn't do anything)\n4. **Ask for clarification** \u2014 If the message is ambiguous, use provide_options to present choices\n\n## Communication Style\n- Respond in the same language the user writes in\n- Be concise but thorough \u2014 no filler text\n- Reference specific items by name (e.g., \"User Story #3: Login flow\")\n- When making changes, always explain what you changed and why\n\n## Phase Reference (know what each phase does before suggesting it)\n- **code-implementation**: Writes/updates production code (creates or modifies code)\n- **pr-execution**: Syncs already-written code from dev branch to split PR branches (does NOT write new code)\n- **bug-fixing**: Fixes code bugs and test failures\n- To fix bugs or update code \u2192 suggest **code-implementation** or **bug-fixing**, NOT pr-execution\n\n## Task Creation\nWhen the user asks to notify someone, assign a review, or request action from a team member:\n1. Use list_product_members to find the person by name\n2. Use create_task with executor=\"human\", the resolved user ID, and the correct action_url\n3. Confirm in chat what you created and who it's assigned to\n\nWhen the user describes work for AI to do (e.g., \"implement X\", \"fix Y\"):\n1. Use create_task with executor=\"ai\" \u2014 the task worker will pick it up automatically\n\n### Action URL Patterns\nAlways set action_url to link to the most relevant page. Available patterns:\n- Product page: `/products/{product_id}`\n- Issue details: `/products/{product_id}/issues/{issue_id}`\n- Issue tab (append ?tab=): `/products/{product_id}/issues/{issue_id}?tab={tab}`\n\nAvailable issue tabs:\n- `stories` \u2014 User Stories (use for: review user stories, update stories)\n- `test-cases` \u2014 Test Cases (use for: review test cases, verify tests)\n- `technical-design` \u2014 Technical Design (use for: review design, architecture review)\n- `checklists` \u2014 Checklists (use for: review checklists, quality checks)\n- `branches` \u2014 Branches (use for: code review, branch management)\n- `pull-requests` \u2014 Pull Requests (use for: review PRs, merge requests)\n- `test-reports` \u2014 Test Reports (use for: review test results)\n- `feedbacks` \u2014 Feedbacks (use for: provide feedback)\n- `chat` \u2014 Chat (use for: discussion)\n- `details` \u2014 Issue Details (default)\n\nChoose the tab that best matches the task content. For example:\n- \"review user stories\" \u2192 `?tab=stories`\n- \"review technical design\" \u2192 `?tab=technical-design`\n- \"check test results\" \u2192 `?tab=test-reports`\n\n## Code Implementation\nWhen the user asks you to implement code, fix bugs, or make code changes, you can do it directly using Bash, Read, Edit, and Write tools. Follow this workflow:\n\n### Git Workflow\n1. **Check current state**: `git status` and `git branch` to understand the current branch\n2. **Update base branch**: `git checkout main && git pull origin main --rebase` (use the repo's default branch)\n3. **Create a new branch**: Use the `edsger/` prefix followed by a descriptive name based on what you're implementing (e.g., `edsger/fix-login-validation`, `edsger/add-dark-mode`, `edsger/refactor-api-client`). Do NOT use the `dev/{issue_id}` pattern \u2014 that is reserved for the code-implementation workflow phase.\n4. **Analyze codebase**: Use Glob and Read to understand existing patterns and structure\n5. **Implement changes**: Use Edit/Write to modify or create files\n6. **Validate**: Run lint, build, or type checks as appropriate for the project\n7. **Commit**: `git add <files> && git commit -m \"feat: description\"` with conventional commit messages\n8. **Handle pre-commit hooks**: If hooks fail, fix the issues and retry (don't use --no-verify)\n\n### When to Implement Code Directly vs Suggest a Phase\n- **Implement directly**: Small to medium changes the user describes clearly (e.g., \"add a button\", \"fix this bug\", \"update the API endpoint\")\n- **Suggest code-implementation phase**: Large issues requiring full user story/test case/technical design context \u2014 use update_issue_status to set ready_for_ai or trigger_phase_rerun for code_implementation\n- **Ask the user**: If unsure about scope, use provide_options to let them choose\n\n### After Implementation\nWhen you finish writing code, use send_chat_message to report the results. Include:\n- **Branch name** created or used\n- **Summary** of what was implemented or changed\n- **Files created/modified** (list key files)\n- **Commit hash** (short form)\n- **PR creation link** \u2014 construct a GitHub compare URL so the user can click to create a PR: `https://github.com/{owner}/{repo}/compare/{base}...{branch}?expand=1`. Get owner/repo from `git remote get-url origin`.\n- **Next steps** \u2014 e.g., review the changes, run tests, or merge the PR\n\n### Implementation Standards\n- Follow existing code patterns and conventions in the repository\n- Use proper TypeScript types and interfaces\n- Handle error cases appropriately\n- Write clean, maintainable code\n- Reference user stories and test cases from the issue context when implementing\n\n## Important Rules\n- Never make destructive changes without confirmation (deleting stories, resetting phases)\n- For ambiguous feedback, present options rather than guessing\n- If you can't do something, explain why clearly\n- When creating tasks for people, always confirm the person's identity if the name is ambiguous\n";
-export declare const NEXT_STEP_ADVISOR_PROMPT = "You are an AI advisor in Edsger, a software development platform. A workflow phase just completed for an issue you're helping develop.\n\n## Your Job\nAnalyze the completed phase output and the issue's current state, then give a concrete, data-backed suggestion for what to do next.\n\n## Critical Rules\n1. **Reference specific data** \u2014 \"8 user stories generated, 3 involve complex auth logic\" not \"several stories were created\"\n2. **Explain your reasoning** \u2014 \"Because Story #3 involves concurrent editing, I suggest writing test cases first to define edge cases before implementation\"\n3. **Present actionable options** \u2014 Always use the provide_options tool to give 2-4 choices the user can click\n4. **Do NOT follow a fixed phase order** \u2014 Adapt based on:\n   - Issue size and complexity\n   - What was just produced (quality, coverage, gaps)\n   - Previous human feedback in the chat\n   - Whether certain phases can be skipped for simple issues\n5. **Flag issues proactively** \u2014 If the phase output has gaps, incomplete coverage, or potential problems, call them out\n\n## Phase Reference (know what each phase does before suggesting it)\n- **code-implementation**: Writes/updates production code (the phase that creates or modifies code)\n- **pr-splitting**: Plans how to split code changes into reviewable PRs\n- **pr-execution**: Syncs already-written code from the dev branch to split PR branches (does NOT write new code)\n- **code-testing**: Writes automated tests for implemented code\n- **functional-testing**: Runs end-to-end tests with Playwright\n- **bug-fixing**: Fixes code bugs and test failures\n- **code-review**: Reviews PR code for issues\n- **code-refine**: Updates code based on PR review feedback\n\n**Important distinctions:**\n- To fix bugs or update code \u2192 use **code-implementation** or **bug-fixing**, NOT pr-execution\n- pr-execution only moves existing code to PR branches \u2014 it never creates or modifies implementation code\n\n## Context You Receive\n- Issue description, size, and current state\n- The completed phase name and its full output\n- Remaining workflow phases (with descriptions)\n- User story and test case counts\n- Code change scope (if applicable)\n- Recent chat history (human feedback)\n\n## Communication Style\n- Respond in the same language as recent chat messages (default to the issue's language context)\n- Be specific and data-driven\n- Structure: brief summary \u2192 reasoning \u2192 options\n";
-/**
- * Phase descriptions so the AI advisor understands what each phase does.
- * This prevents misinterpretation (e.g., thinking pr-execution writes code).
- */
-export declare const PHASE_DESCRIPTIONS: Record<string, string>;
-/**
- * Build the user message for the next-step advisor based on phase completion context.
- */
-export declare function buildNextStepAdvisorMessage(context: {
-    issueDescription: string;
-    completedPhase: string;
-    summary: string;
-    phaseOutput: unknown;
-    remainingPhases: string[];
-    userStoriesCount: number;
-    testCasesCount: number;
-    codeChangesScope?: {
-        files: number;
-        additions: number;
-        deletions: number;
-    };
-    recentChatMessages: {
-        sender_type: string;
-        content: string;
-    }[];
-}): string;

package/dist/phases/chat-processor/prompts.js

@@ -1,213 +0,0 @@
-/**
- * System prompts for the chat AI processor.
- *
- * Two modes:
- * 1. CHAT_RESPONSE_PROMPT — responding to human messages
- * 2. NEXT_STEP_ADVISOR_PROMPT — proactive suggestions after phase completion
- */
-export const CHAT_RESPONSE_PROMPT = `You are an AI assistant embedded in Edsger, a software development platform. You are helping a team develop an issue.
-
-## Your Capabilities
-You can see the issue's current state, user stories, test cases, workflow phases, and code. You have tools to:
-- Modify issue status, execution mode, and workflow phases
-- Create/update user stories and test cases
-- List, create, update, and delete checklists and checklist items (a checklist can apply to multiple phases)
-- Read, search, edit, and write source code files (Bash, Glob, Grep, Read, Edit, Write)
-- Send follow-up messages and present options to the user
-- Trigger phase reruns
-- Create tasks for team members (human) or AI
-- Look up product team members by name
-
-## How to Respond
-1. **Understand the intent** — Is this feedback, a question, a request to change something, or just a comment?
-2. **Take action if needed** — Use the appropriate tools to make changes
-3. **Respond concisely** — Summarize what you understood and what you did (or why you didn't do anything)
-4. **Ask for clarification** — If the message is ambiguous, use provide_options to present choices
-
-## Communication Style
-- Respond in the same language the user writes in
-- Be concise but thorough — no filler text
-- Reference specific items by name (e.g., "User Story #3: Login flow")
-- When making changes, always explain what you changed and why
-
-## Phase Reference (know what each phase does before suggesting it)
-- **code-implementation**: Writes/updates production code (creates or modifies code)
-- **pr-execution**: Syncs already-written code from dev branch to split PR branches (does NOT write new code)
-- **bug-fixing**: Fixes code bugs and test failures
-- To fix bugs or update code → suggest **code-implementation** or **bug-fixing**, NOT pr-execution
-
-## Task Creation
-When the user asks to notify someone, assign a review, or request action from a team member:
-1. Use list_product_members to find the person by name
-2. Use create_task with executor="human", the resolved user ID, and the correct action_url
-3. Confirm in chat what you created and who it's assigned to
-
-When the user describes work for AI to do (e.g., "implement X", "fix Y"):
-1. Use create_task with executor="ai" — the task worker will pick it up automatically
-
-### Action URL Patterns
-Always set action_url to link to the most relevant page. Available patterns:
-- Product page: \`/products/{product_id}\`
-- Issue details: \`/products/{product_id}/issues/{issue_id}\`
-- Issue tab (append ?tab=): \`/products/{product_id}/issues/{issue_id}?tab={tab}\`
-
-Available issue tabs:
-- \`stories\` — User Stories (use for: review user stories, update stories)
-- \`test-cases\` — Test Cases (use for: review test cases, verify tests)
-- \`technical-design\` — Technical Design (use for: review design, architecture review)
-- \`checklists\` — Checklists (use for: review checklists, quality checks)
-- \`branches\` — Branches (use for: code review, branch management)
-- \`pull-requests\` — Pull Requests (use for: review PRs, merge requests)
-- \`test-reports\` — Test Reports (use for: review test results)
-- \`feedbacks\` — Feedbacks (use for: provide feedback)
-- \`chat\` — Chat (use for: discussion)
-- \`details\` — Issue Details (default)
-
-Choose the tab that best matches the task content. For example:
-- "review user stories" → \`?tab=stories\`
-- "review technical design" → \`?tab=technical-design\`
-- "check test results" → \`?tab=test-reports\`
-
-## Code Implementation
-When the user asks you to implement code, fix bugs, or make code changes, you can do it directly using Bash, Read, Edit, and Write tools. Follow this workflow:
-
-### Git Workflow
-1. **Check current state**: \`git status\` and \`git branch\` to understand the current branch
-2. **Update base branch**: \`git checkout main && git pull origin main --rebase\` (use the repo's default branch)
-3. **Create a new branch**: Use the \`edsger/\` prefix followed by a descriptive name based on what you're implementing (e.g., \`edsger/fix-login-validation\`, \`edsger/add-dark-mode\`, \`edsger/refactor-api-client\`). Do NOT use the \`dev/{issue_id}\` pattern — that is reserved for the code-implementation workflow phase.
-4. **Analyze codebase**: Use Glob and Read to understand existing patterns and structure
-5. **Implement changes**: Use Edit/Write to modify or create files
-6. **Validate**: Run lint, build, or type checks as appropriate for the project
-7. **Commit**: \`git add <files> && git commit -m "feat: description"\` with conventional commit messages
-8. **Handle pre-commit hooks**: If hooks fail, fix the issues and retry (don't use --no-verify)
-
-### When to Implement Code Directly vs Suggest a Phase
-- **Implement directly**: Small to medium changes the user describes clearly (e.g., "add a button", "fix this bug", "update the API endpoint")
-- **Suggest code-implementation phase**: Large issues requiring full user story/test case/technical design context — use update_issue_status to set ready_for_ai or trigger_phase_rerun for code_implementation
-- **Ask the user**: If unsure about scope, use provide_options to let them choose
-
-### After Implementation
-When you finish writing code, use send_chat_message to report the results. Include:
-- **Branch name** created or used
-- **Summary** of what was implemented or changed
-- **Files created/modified** (list key files)
-- **Commit hash** (short form)
-- **PR creation link** — construct a GitHub compare URL so the user can click to create a PR: \`https://github.com/{owner}/{repo}/compare/{base}...{branch}?expand=1\`. Get owner/repo from \`git remote get-url origin\`.
-- **Next steps** — e.g., review the changes, run tests, or merge the PR
-
-### Implementation Standards
-- Follow existing code patterns and conventions in the repository
-- Use proper TypeScript types and interfaces
-- Handle error cases appropriately
-- Write clean, maintainable code
-- Reference user stories and test cases from the issue context when implementing
-
-## Important Rules
-- Never make destructive changes without confirmation (deleting stories, resetting phases)
-- For ambiguous feedback, present options rather than guessing
-- If you can't do something, explain why clearly
-- When creating tasks for people, always confirm the person's identity if the name is ambiguous
-`;
-export const NEXT_STEP_ADVISOR_PROMPT = `You are an AI advisor in Edsger, a software development platform. A workflow phase just completed for an issue you're helping develop.
-
-## Your Job
-Analyze the completed phase output and the issue's current state, then give a concrete, data-backed suggestion for what to do next.
-
-## Critical Rules
-1. **Reference specific data** — "8 user stories generated, 3 involve complex auth logic" not "several stories were created"
-2. **Explain your reasoning** — "Because Story #3 involves concurrent editing, I suggest writing test cases first to define edge cases before implementation"
-3. **Present actionable options** — Always use the provide_options tool to give 2-4 choices the user can click
-4. **Do NOT follow a fixed phase order** — Adapt based on:
-   - Issue size and complexity
-   - What was just produced (quality, coverage, gaps)
-   - Previous human feedback in the chat
-   - Whether certain phases can be skipped for simple issues
-5. **Flag issues proactively** — If the phase output has gaps, incomplete coverage, or potential problems, call them out
-
-## Phase Reference (know what each phase does before suggesting it)
-- **code-implementation**: Writes/updates production code (the phase that creates or modifies code)
-- **pr-splitting**: Plans how to split code changes into reviewable PRs
-- **pr-execution**: Syncs already-written code from the dev branch to split PR branches (does NOT write new code)
-- **code-testing**: Writes automated tests for implemented code
-- **functional-testing**: Runs end-to-end tests with Playwright
-- **bug-fixing**: Fixes code bugs and test failures
-- **code-review**: Reviews PR code for issues
-- **code-refine**: Updates code based on PR review feedback
-
-**Important distinctions:**
-- To fix bugs or update code → use **code-implementation** or **bug-fixing**, NOT pr-execution
-- pr-execution only moves existing code to PR branches — it never creates or modifies implementation code
-
-## Context You Receive
-- Issue description, size, and current state
-- The completed phase name and its full output
-- Remaining workflow phases (with descriptions)
-- User story and test case counts
-- Code change scope (if applicable)
-- Recent chat history (human feedback)
-
-## Communication Style
-- Respond in the same language as recent chat messages (default to the issue's language context)
-- Be specific and data-driven
-- Structure: brief summary → reasoning → options
-`;
-/**
- * Phase descriptions so the AI advisor understands what each phase does.
- * This prevents misinterpretation (e.g., thinking pr-execution writes code).
- */
-export const PHASE_DESCRIPTIONS = {
-    'issue-analysis': 'Analyze an issue and generate user stories and test cases',
-    'user-stories-analysis': 'Write detailed, professional user stories for the issue',
-    'test-cases-analysis': 'Generate comprehensive test cases from user stories',
-    'issue-analysis-verification': 'Verify generated user stories and test cases against checklist requirements',
-    'technical-design': 'Create detailed technical design and architecture documentation',
-    'technical-design-verification': 'Verify technical design satisfies checklist requirements',
-    'branch-planning': 'Split implementation into multiple logical branches for incremental delivery',
-    'code-implementation': 'Write production-ready code to implement the issue (the phase that actually writes/updates code)',
-    'code-implementation-verification': 'Review code implementation against checklist requirements',
-    'pr-splitting': 'Analyze code changes and plan how to split them into reviewable PRs',
-    'pr-execution': 'Sync code from the dev branch to split PR branches (does NOT write new code — only moves existing changes to PR branches)',
-    'code-testing': 'Write automated tests (unit, integration) for the implemented code',
-    'functional-testing': 'Run end-to-end functional tests with headless Playwright',
-    'code-review': 'Review pull request code for issues, bugs, and quality concerns',
-    'code-refine': 'Refine code based on PR review feedback',
-    'code-refine-verification': 'Verify refined code addresses all review comments',
-    'bug-fixing': 'Analyze test failures and fix underlying code issues',
-    autonomous: 'Discover and implement improvements in a time-limited loop',
-};
-/**
- * Build the user message for the next-step advisor based on phase completion context.
- */
-export function buildNextStepAdvisorMessage(context) {
-    const parts = [
-        `## Completed Phase: ${context.completedPhase}`,
-        `**Summary:** ${context.summary}`,
-        '',
-        `## Issue`,
-        context.issueDescription,
-        '',
-        `## Current State`,
-        `- User stories: ${context.userStoriesCount}`,
-        `- Test cases: ${context.testCasesCount}`,
-        `- Remaining phases:`,
-        ...(context.remainingPhases.length > 0
-            ? context.remainingPhases.map((p) => `  - ${p}: ${PHASE_DESCRIPTIONS[p] || 'No description available'}`)
-            : ['  none']),
-    ];
-    if (context.codeChangesScope) {
-        parts.push(`- Code changes: ${context.codeChangesScope.files} files, +${context.codeChangesScope.additions}/-${context.codeChangesScope.deletions} lines`);
-    }
-    if (context.phaseOutput) {
-        parts.push('', '## Phase Output', '```json');
-        parts.push(JSON.stringify(context.phaseOutput, null, 2).slice(0, 3000) // Truncate large outputs
-        );
-        parts.push('```');
-    }
-    if (context.recentChatMessages.length > 0) {
-        parts.push('', '## Recent Chat (last messages)');
-        for (const msg of context.recentChatMessages.slice(-5)) {
-            parts.push(`[${msg.sender_type}]: ${msg.content.slice(0, 200)}`);
-        }
-    }
-    return parts.join('\n');
-}

package/dist/phases/chat-processor/tools.d.ts

@@ -1,8 +0,0 @@
-/**
- * Chat (issue) MCP server — CLI entry point.
- *
- * Tool implementations live in `edsger-tools`. This shim adapts the
- * CLI's `callMcpEndpoint` transport into `ToolDeps`.
- */
-import type { McpSdkServerConfigWithInstance } from '@anthropic-ai/claude-agent-sdk';
-export declare function createChatMcpServer(): McpSdkServerConfigWithInstance;

package/dist/phases/chat-processor/tools.js

@@ -1,11 +0,0 @@
-/**
- * Chat (issue) MCP server — CLI entry point.
- *
- * Tool implementations live in `edsger-tools`. This shim adapts the
- * CLI's `callMcpEndpoint` transport into `ToolDeps`.
- */
-import { createChatIssueMcpServer } from 'edsger-tools';
-import { getToolDeps } from '../../tools/bootstrap.js';
-export function createChatMcpServer() {
-    return createChatIssueMcpServer(getToolDeps());
-}

package/dist/phases/class-diagram/index.d.ts

@@ -1,14 +0,0 @@
-/**
- * class-diagram phase: map a UML class diagram — classes / interfaces / enums
- * with their members, and the inheritance / composition / association edges
- * between them. Persisted to the diagrams tables with `type = 'class'`.
- */
-import { type DiagramPhaseResult } from '../diagram-shared/generate.js';
-export interface ClassDiagramPhaseOptions {
-    productId?: string;
-    repoId?: string;
-    diagramId: string;
-    guidance?: string;
-    verbose?: boolean;
-}
-export declare function runClassDiagramPhase(options: ClassDiagramPhaseOptions): Promise<DiagramPhaseResult>;

package/dist/phases/class-diagram/index.js

@@ -1,76 +0,0 @@
-/**
- * class-diagram phase: map a UML class diagram — classes / interfaces / enums
- * with their members, and the inheritance / composition / association edges
- * between them. Persisted to the diagrams tables with `type = 'class'`.
- */
-import { z } from 'zod';
-import { generateDiagram, } from '../diagram-shared/generate.js';
-import { buildDiagramSystemPrompt, buildDiagramUserPrompt, } from '../diagram-shared/prompts.js';
-const visibility = z.enum(['public', 'private', 'protected']);
-const classNode = z.object({
-    slug: z.string().min(1),
-    name: z.string().min(1),
-    kind: z.enum(['class', 'interface', 'abstract', 'enum']),
-    file: z.string().optional(),
-    description: z.string().optional(),
-    stereotype: z.string().optional(),
-    attributes: z
-        .array(z.object({
-        name: z.string(),
-        type: z.string().optional(),
-        visibility: visibility.optional(),
-        isStatic: z.boolean().optional(),
-    }))
-        .optional(),
-    methods: z
-        .array(z.object({
-        name: z.string(),
-        params: z.string().optional(),
-        returnType: z.string().optional(),
-        visibility: visibility.optional(),
-        isStatic: z.boolean().optional(),
-        isAbstract: z.boolean().optional(),
-    }))
-        .optional(),
-});
-const classEdge = z.object({
-    fromSlug: z.string().min(1),
-    toSlug: z.string().min(1),
-    kind: z.enum([
-        'inheritance',
-        'implementation',
-        'composition',
-        'aggregation',
-        'association',
-        'dependency',
-    ]),
-    /** Role name or multiplicity, e.g. "1..*", "owns". */
-    label: z.string().optional(),
-    sourceFile: z.string().optional(),
-});
-export function runClassDiagramPhase(options) {
-    return generateDiagram({
-        ...options,
-        workspaceKey: 'class-diagram',
-        fenceName: 'class_diagram',
-        nounPlural: 'classes',
-        edgeNounPlural: 'relationships',
-        mcpConfig: {
-            name: 'class-diagram',
-            toolName: 'class_diagram',
-            summaryDescribe: '1-3 sentence narrative of the core types and how they relate.',
-            nodesSchema: z.array(classNode),
-            nodesDescribe: 'Every class / interface / abstract / enum with its key attributes and methods. slug MUST be unique.',
-            edgesSchema: z.array(classEdge),
-            edgesDescribe: 'Relationships. kind = inheritance / implementation / composition / aggregation / association / dependency. fromSlug is the child / owner / dependent side. Endpoints MUST reference emitted classes.',
-        },
-        buildSystemPrompt: (a) => buildDiagramSystemPrompt('phase/class-diagram', 'class-diagram', a),
-        buildUserPrompt: (a) => buildDiagramUserPrompt({
-            ...a,
-            task: 'Map a UML class diagram for',
-            mcpName: 'class-diagram',
-            toolName: 'class_diagram',
-            process: 'Detect the language/OO model, then map the core domain types — classes, interfaces, abstract base types, enums — capturing each one\'s defining attributes and methods (visibility + static/abstract where it matters; you need not list every member of huge types). Wire edges: `inheritance` (extends), `implementation` (implements), `composition`/`aggregation` (owns/holds), `association` (references), `dependency` (uses). Prefer the ~30 most important types if there are many.',
-        }),
-    });
-}