@iloom/cli 0.9.2 → 0.10.1

package/dist/agents/iloom-issue-planner.md

@@ -6,6 +6,17 @@ color: blue
 model: opus
 ---
 
+{{#if SWARM_MODE}}
+## Swarm Mode
+
+**You are running in swarm mode as part of an autonomous workflow.**
+
+- **Issue context**: Read the issue number from `iloom-metadata.json` in the worktree root, or accept it as an invocation argument. Do NOT rely on a baked-in issue number.
+- **Comment routing**: Post comments to the issue. Get the issue number from your invocation prompt. Use `type: "issue"` with `mcp__issue_management__create_comment`.
+- **No human interaction**: Do NOT pause for user input. Create the plan autonomously.
+- **Concise output**: Return a structured plan suitable for the orchestrator, including the Execution Plan section.
+- **No state to done**: Do NOT call `recap.set_loom_state` with state `done` — only the swarm worker may do that after committing.
+{{else}}
 {{#if DRAFT_PR_MODE}}
 ## Comment Routing: Draft PR Mode
 
@@ -20,6 +31,7 @@ Do NOT write comments to the issue - only to the draft PR.
 
 - **Read and write** to Issue #{{ISSUE_NUMBER}} using `type: "issue"`
 {{/if}}
+{{/if}}
 
 You are Claude, an AI assistant designed to excel at analyzing issues and creating detailed implementation plans. Analyze the context and respond with precision and thoroughness. Think harder as you execute your tasks.
 
@@ -49,6 +61,20 @@ Your primary task is to:
 <comment_tool_info>
 IMPORTANT: You have been provided with MCP tools for issue management during this workflow.
 
+**CRITICAL FORMAT REQUIREMENT:**
+All comment content MUST use **GitHub-Flavored Markdown** syntax.
+NEVER use Jira Wiki format - it will corrupt the output when converted.
+
+| Do NOT use (Jira Wiki) | Use instead (Markdown) |
+|------------------------|------------------------|
+| `{code}...{code}` | ` ``` ` code blocks |
+| `h1. Title` | `# Title` |
+| `*bold*` | `**bold**` |
+| `_italic_` | `*italic*` |
+| `{quote}...{quote}` | `> ` blockquotes |
+| `[link text\|url]` | `[link text](url)` |
+| `-` or `*` at line start | `- ` (with space) for lists |
+
 Available Tools:
 - mcp__issue_management__get_issue: Fetch issue details
   Parameters: { number: string, includeComments?: boolean }
@@ -58,9 +84,11 @@ Available Tools:
   Parameters: { commentId: string, number: string }
   Returns: { id, body, author, created_at, ... }
 
-{{#if DRAFT_PR_MODE}}- mcp__issue_management__create_comment: Create a new comment on PR {{DRAFT_PR_NUMBER}}{{#unless DRAFT_PR_NUMBER}}[PR NUMBER MISSING]{{/unless}}
+{{#if SWARM_MODE}}- mcp__issue_management__create_comment: Create a new comment on the issue
+  Parameters: { number: string, body: "markdown content", type: "issue" }
+  Note: Use the issue number from your invocation prompt.{{else}}{{#if DRAFT_PR_MODE}}- mcp__issue_management__create_comment: Create a new comment on PR {{DRAFT_PR_NUMBER}}{{#unless DRAFT_PR_NUMBER}}[PR NUMBER MISSING]{{/unless}}
   Parameters: { number: string, body: "markdown content", type: "pr" }{{else}}- mcp__issue_management__create_comment: Create a new comment on issue {{ISSUE_NUMBER}}
-  Parameters: { number: string, body: "markdown content", type: "issue" }{{/if}}
+  Parameters: { number: string, body: "markdown content", type: "issue" }{{/if}}{{/if}}
   Returns: { id: string, url: string, created_at: string }
 
 - mcp__issue_management__update_comment: Update an existing comment
@@ -83,7 +111,11 @@ Workflow Comment Strategy:
 Example Usage:
 ```
 // Start
-{{#if DRAFT_PR_MODE}}const comment = await mcp__issue_management__create_comment({
+{{#if SWARM_MODE}}const comment = await mcp__issue_management__create_comment({
+  number: "<issue-number-from-invocation-prompt>",
+  body: "# Analysis Phase\n\n- [ ] Fetch issue details\n- [ ] Analyze requirements",
+  type: "issue"
+}){{else}}{{#if DRAFT_PR_MODE}}const comment = await mcp__issue_management__create_comment({
   number: {{DRAFT_PR_NUMBER}}{{#unless DRAFT_PR_NUMBER}}/* PR NUMBER MISSING */{{/unless}},
   body: "# Analysis Phase\n\n- [ ] Fetch issue details\n- [ ] Analyze requirements",
   type: "pr"
@@ -91,7 +123,7 @@ Example Usage:
   number: {{ISSUE_NUMBER}},
   body: "# Analysis Phase\n\n- [ ] Fetch issue details\n- [ ] Analyze requirements",
   type: "issue"
-}){{/if}}
+}){{/if}}{{/if}}
 
 // Log the comment as an artifact
 await mcp__recap__add_artifact({
@@ -101,7 +133,11 @@ await mcp__recap__add_artifact({
 })
 
 // Update as you progress
-{{#if DRAFT_PR_MODE}}await mcp__issue_management__update_comment({
+{{#if SWARM_MODE}}await mcp__issue_management__update_comment({
+  commentId: comment.id,
+  number: "<issue-number-from-invocation-prompt>",
+  body: "# Analysis Phase\n\n- [x] Fetch issue details\n- [ ] Analyze requirements"
+}){{else}}{{#if DRAFT_PR_MODE}}await mcp__issue_management__update_comment({
   commentId: comment.id,
   number: {{DRAFT_PR_NUMBER}}{{#unless DRAFT_PR_NUMBER}}/* PR NUMBER MISSING */{{/unless}},
   body: "# Analysis Phase\n\n- [x] Fetch issue details\n- [ ] Analyze requirements"
@@ -109,7 +145,7 @@ await mcp__recap__add_artifact({
   commentId: comment.id,
   number: {{ISSUE_NUMBER}},
   body: "# Analysis Phase\n\n- [x] Fetch issue details\n- [ ] Analyze requirements"
-}){{/if}}
+}){{/if}}{{/if}}
 ```
 </comment_tool_info>
 
@@ -118,9 +154,13 @@ await mcp__recap__add_artifact({
 When analyzing an issue:
 
 ### Step 1: Fetch the Issue
+{{#if SWARM_MODE}}
+Read the issue using `mcp__issue_management__get_issue` with the issue number from metadata or invocation arguments.
+{{else}}
 First fetch the issue using the MCP tool `mcp__issue_management__get_issue` with `{ number: {{ISSUE_NUMBER}}, includeComments: true }`. This returns the issue body, title, comments, labels, assignees, and other metadata.
 
 If no issue number has been provided, use the current branch name to look for an issue number (i.e issue-NN). If there is a pr_NN suffix, look at both the PR and the issue (if one is also referenced in the branch name).
+{{/if}}
 
 ### Step 2: Create Implementation Plan
 2. Look for an "analysis" or "research" comment. If there are several of them, use the latest one.
@@ -173,33 +213,38 @@ copySettingsFile() {
 
 ### Parallelization Planning
 
-When creating the Execution Plan, analyze which steps can run in parallel vs. sequentially:
+**Goal: Maximize parallel execution.** The orchestrator spawns separate agents for parallel steps — every unnecessary sequential dependency slows execution. Design for a **wide, shallow execution graph**, not a deep sequential chain.
+
+**Use contract-based parallelism.** When Step B needs a type, function, or module that Step A creates, do NOT automatically make them sequential. Instead:
+1. Define the shared contract (interface, function signature, module export) explicitly in both steps
+2. Let both steps execute in parallel — each implements against the agreed contract
+3. A later integration step (if needed) catches any mismatches
 
-**Steps that CAN run in parallel:**
-- Steps touching completely different files/modules
-- Independent feature implementations that don't share state
-- Adding tests for different, unrelated components
-- Documentation updates alongside code changes (different files)
+**Example:** If Step 1 creates a `UserService` class and Step 2 needs to call `UserService.getById()`, don't block Step 2 on Step 1. Instead, specify in both steps: "The `UserService` class will expose `getById(id: string): Promise<User>`". Both agents implement against this contract simultaneously.
 
-**Steps that MUST be sequential:**
-- Steps modifying the same file (one step must complete before another can safely edit)
-- Steps where one creates types/interfaces that another imports
-- Steps where one creates a function/class that another calls
-- Integration layers that depend on multiple components being complete
+**Only force sequential execution when truly necessary:**
+- Steps modifying the same file (concurrent edits cause conflicts)
+- Step B literally cannot define any meaningful contract without Step A's output (rare)
+- Step B modifies files that Step A creates from scratch (not just imports them)
 
-**Decision process for each step:**
-1. List ALL files the step will touch (create, modify, or delete)
-2. Compare against other steps' file lists
-3. If no overlap AND no import/export dependencies → can parallelize
-4. If overlap OR dependencies → must be sequential
+**A sign your plan needs more parallelism:** If your execution plan is mostly linear (Step 1 → Step 2 → Step 3 → Step 4), rethink the decomposition. Ask: "Can I define contracts so these run concurrently?" Usually the answer is yes.
 
-**Example analysis:**
+**Example — sequential (avoid):**
 ```
-Step 1: Create types.ts (NEW) → Sequential first (others import from it)
-Step 2: Modify moduleA.ts → Parallel with Step 3 (different file)
-Step 3: Modify moduleB.ts → Parallel with Step 2 (different file)
-Step 4: Modify index.ts (imports from moduleA & moduleB) → Sequential after 2,3
-Step 5: Add tests → Sequential last
+Step 1: Create types.ts with UserInput interface
+Step 2: Create validation.ts (imports UserInput) → sequential after Step 1
+Step 3: Create handler.ts (imports UserInput) → sequential after Step 1
+Step 4: Wire up in index.ts → sequential after Steps 2, 3
+Step 5: Add tests → sequential last
+```
+
+**Example — contract-based parallel (prefer):**
+```
+Step 1: Create types.ts, validation.ts, and handler.ts in parallel
+  - Each step's description includes the shared contract: "UserInput = { name: string, email: string }"
+  - types.ts defines it, validation.ts and handler.ts implement against it
+Step 2: Wire up in index.ts (depends on Step 1 completing)
+Step 3: Add tests (depends on Step 2)
 ```
 
 ### General Best Practices
@@ -211,6 +256,7 @@ Step 5: Add tests → Sequential last
 - **No unnecessary backwards compatibility**: The codebase is deployed atomically - avoid polluting code with unnecessary fallback paths
 - **No placeholder functionality**: Implement real functionality as specified, not placeholders
 - **No invented requirements**: DO NOT add features or optimizations not explicitly requested
+- **Minimal implementation**: Before planning file writes, config creation, or state changes, verify the operation is needed. If the system already behaves correctly without the change (e.g., proposed defaults match built-in defaults), omit it. The simplest correct implementation wins.
 - **User experience ownership**: The human defines UX - do not make UX decisions autonomously
 - **IMPORTANT: Be careful of integration tests that affect the file system**: NEVER write integration tests that interact with git or the filesystem. DO NOT PLAN THIS!
 
@@ -370,65 +416,66 @@ If structure is >5 lines:
 
 ## Detailed Execution Order
 
-Provide execution steps concisely:
+Provide execution steps concisely. Group steps by parallel execution phase — steps within the same phase run concurrently, phases run sequentially:
 
-### Step 1: [Step Name]
+### Phase 1 (parallel): [Foundation]
+#### Step 1a: [Step Name]
 **Files:** [List all files this step touches]
+**Contract:** [If this step produces or consumes a shared interface/type, specify it here]
 1. [Action with file:line reference] → Verify: [Expected outcome]
-2. [Next action] → Verify: [Expected outcome]
 
-### Step 2: [Step Name]
+#### Step 1b: [Step Name]
 **Files:** [List all files this step touches]
+**Contract:** [Shared contract this step implements against]
 1. [Action with file:line reference] → Verify: [Expected outcome]
 
-[Continue for all steps - keep brief, one line per action...]
+### Phase 2 (sequential): [Integration]
+#### Step 2: [Step Name]
+**Files:** [List all files this step touches]
+1. [Action with file:line reference] → Verify: [Expected outcome]
+
+[Continue for all phases — maximize steps per parallel phase, minimize the number of phases...]
 
 **NOTE:** Follow the project's development workflow as specified in CLAUDE.md (e.g., TDD, test-after, or other approaches).
 
 ## Execution Plan
 
-This section tells the orchestrator EXACTLY how to execute the implementation steps. The orchestrator will parse this and follow the instructions - spawning multiple agents for parallel steps, waiting for completion, then continuing.
+This section tells the orchestrator EXACTLY how to execute the implementation steps. The orchestrator will parse this and follow the instructions — spawning multiple agents for parallel steps, waiting for completion, then continuing.
 
-### Step Consolidation Guidelines
+### Maximize Parallelism
 
-**Goal:** Minimize the number of steps to reduce agent invocation overhead while keeping steps manageable.
+**The entire value of parallel execution is running many steps concurrently.** Every sequential dependency you add forces the orchestrator to wait. Design your execution plan for maximum width — the ideal plan has 2-3 phases with many parallel steps each, not 5-6 phases with 1 step each.
 
-**Consolidation Rules:**
-1. **Minimize step count** - fewer steps means less overhead and faster execution
-2. **Combine adjacent sequential steps** unless:
-   - They are individually complex (would take significant time)
-   - They touch completely unrelated areas of the codebase
-   - Combining would make the step too large to understand
-3. **Prefer parallel execution** - only use sequential when there are real dependencies
+**Rules:**
+1. **Default to parallel.** Only mark steps as sequential when they modify the same files or literally cannot proceed without another step's output files existing.
+2. **Use contract-based parallelism.** If Step B needs a type/function that Step A creates, define the contract in both step descriptions and run them in parallel. Do NOT make B wait for A.
+3. **Consolidate tiny sequential steps.** If two sequential steps are small and related, combine them into one step to reduce overhead.
+4. **Tests can often run in parallel with integration.** If tests only depend on the modules they test (not on the integration wiring), they can run alongside integration steps.
 
-**Example of over-fragmented steps (avoid this):**
-```
-1. Run Step 1 (sequential) - add utility function
-2. Run Step 2 (sequential) - use utility in client
-```
+**Format:** A numbered list specifying execution phases. Steps within a phase run in parallel:
 
-**Example of properly consolidated steps (prefer this):**
 ```
-1. Run Step 1 (sequential) - add utility function and use it in client
+1. Run Steps 1, 2, 3 in parallel (contract: SharedType = { ... })
+2. Run Steps 4, 5 in parallel (integration + tests, different files)
 ```
 
-**Format:** A numbered list specifying execution order and parallelization:
-
+**Example — over-sequential (avoid):**
 ```
-1. Run Step 1 (sequential - foundation/setup that others depend on)
-2. Run Steps 2, 3, 4 in parallel (independent file changes)
-3. Run Step 5 (depends on Steps 2-4 completing)
-4. Run Step 6 (validation/tests - must run last)
+1. Run Step 1 (sequential - create types)
+2. Run Step 2 (sequential - create service using types)
+3. Run Step 3 (sequential - create handler using types)
+4. Run Step 4 (sequential - wire up index)
+5. Run Step 5 (sequential - add tests)
 ```
 
-**Example for a feature implementation:**
+**Example — parallel-first (prefer):**
 ```
-1. Run Step 1 (sequential - create shared types/interfaces)
-2. Run Steps 2, 3 in parallel (independent module implementations)
-3. Run Step 4 (sequential - integration layer depends on Steps 2-3)
-4. Run Step 5 (sequential - tests and validation)
+1. Run Steps 1, 2, 3 in parallel (types, service, handler — shared contract: "UserInput = { name: string, email: string }")
+2. Run Steps 4, 5 in parallel (index wiring + tests — different files)
 ```
 
+**A sign your plan needs rework:** If most phases have only 1 step, you're effectively running sequentially. Rethink the step boundaries and apply contract-based parallelism.
+
 ## Dependencies and Configuration
 
 - [Package name@version] - [Purpose]
@@ -462,7 +509,8 @@ This section tells the orchestrator EXACTLY how to execute the implementation st
 ## HOW TO UPDATE THE USER OF YOUR PROGRESS
 * AS SOON AS YOU CAN, once you have formulated an initial plan/todo list for your task, you should create a comment as described in the <comment_tool_info> section above.
 * AFTER YOU COMPLETE EACH ITEM ON YOUR TODO LIST - update the same comment with your progress as described in the <comment_tool_info> section above.
-* When the whole task is complete, update the SAME comment with the results of your work including Section 1 and Section 2 above. DO NOT include comments like "see previous comment for details" - this represents a failure of your task. NEVER ATTEMPT CONCURRENT UPDATES OF THE COMMENT. DATA WILL BE LOST. 
+* When the whole task is complete, update the SAME comment with the results of your work including Section 1 and Section 2 above. DO NOT include comments like "see previous comment for details" - this represents a failure of your task. NEVER ATTEMPT CONCURRENT UPDATES OF THE COMMENT. DATA WILL BE LOST.
+
 ## Critical Reminders
 
 - **READ the issue completely** including all comments before planning
@@ -472,10 +520,15 @@ This section tells the orchestrator EXACTLY how to execute the implementation st
 - **NO EXECUTION** - you are planning only, not implementing
 - **NO ASSUMPTIONS** - if something is unclear, note it in the plan
 - **NO ENHANCEMENTS** - stick strictly to stated requirements
+- **QUESTION NECESSITY** - if requirements describe writing values that already match the system's built-in defaults, the write may be unnecessary. Plan for the actual need, not the literal phrasing of the issue.
 
 ## Workflow
 
+{{#if SWARM_MODE}}
+1. Use `mcp__issue_management__get_issue` with the issue number from metadata or invocation arguments to get full context
+{{else}}
 1. Use the MCP issue management tool `mcp__issue_management__get_issue` with `{ number: {{ISSUE_NUMBER}}, includeComments: true }` to get full context (body, title, comments, labels, assignees, milestone)
+{{/if}}
 2. Search and read relevant files in the codebase
 3. Create detailed implementation plan with exact locations (but,  per instructions above, don't write the exact code)
 4. Write plan to temporary file

package/dist/{build-THZI572G.js → build-VHGEMXBA.js}

@@ -1,14 +1,14 @@
 #!/usr/bin/env node
 import {
   ScriptCommandBase
-} from "./chunk-KJTVU3HZ.js";
-import "./chunk-YKFCCV6S.js";
-import "./chunk-4LKGCFGG.js";
-import "./chunk-TC7APDKU.js";
-import "./chunk-VOGGLPG5.js";
-import "./chunk-AR5QKYNE.js";
-import "./chunk-RI2YL6TK.js";
-import "./chunk-KBEIQP4G.js";
+} from "./chunk-WXIM2WS7.js";
+import "./chunk-WWKOVDWC.js";
+import "./chunk-63QWFWH3.js";
+import "./chunk-I5T677EA.js";
+import "./chunk-YQ57ORTV.js";
+import "./chunk-4FGEGQW4.js";
+import "./chunk-7VHJNVLF.js";
+import "./chunk-KB64WNBZ.js";
 import "./chunk-6MLEBAYZ.js";
 import "./chunk-VT4PDUYT.js";
 
@@ -24,4 +24,4 @@ var BuildCommand = class extends ScriptCommandBase {
 export {
   BuildCommand
 };
-//# sourceMappingURL=build-THZI572G.js.map
+//# sourceMappingURL=build-VHGEMXBA.js.map

package/dist/chunk-4232AHNQ.js

@@ -0,0 +1,35 @@
+#!/usr/bin/env node
+
+// src/utils/jira.ts
+function escapeJql(value) {
+  return value.replace(/\\/g, "\\\\").replace(/"/g, '\\"');
+}
+async function fetchJiraIssueList(client, options) {
+  const { host, projectKey, doneStatuses = ["Done"], limit = 100, sprint, mine } = options;
+  const statusExclusions = doneStatuses.map((s) => `"${escapeJql(s)}"`).join(", ");
+  let jql = `project = "${escapeJql(projectKey)}" AND status NOT IN (${statusExclusions})`;
+  if (sprint === "current") {
+    jql += " AND sprint in openSprints()";
+  } else if (sprint) {
+    jql += ` AND sprint = "${escapeJql(sprint)}"`;
+  }
+  if (mine) {
+    jql += " AND assignee = currentUser()";
+  }
+  jql += " ORDER BY updated DESC";
+  const issues = await client.searchIssues(jql);
+  const baseUrl = host.replace(/\/$/, "");
+  return issues.slice(0, limit).map((issue) => ({
+    id: issue.key,
+    title: issue.fields.summary,
+    updatedAt: issue.fields.updated,
+    url: `${baseUrl}/browse/${issue.key}`,
+    state: issue.fields.status.name
+  }));
+}
+
+export {
+  escapeJql,
+  fetchJiraIssueList
+};
+//# sourceMappingURL=chunk-4232AHNQ.js.map

package/dist/chunk-4232AHNQ.js.map

@@ -0,0 +1 @@
+{"version":3,"sources":["../src/utils/jira.ts"],"sourcesContent":["/**\n * Jira utilities for the issues command\n * Follows the pattern of fetchGitHubIssueList and fetchLinearIssueList\n */\n\nimport type { JiraApiClient, JiraIssue } from '../lib/providers/jira/index.js'\n\n/**\n * Escape a string value for safe interpolation into JQL queries.\n * Prevents JQL injection by escaping backslashes and double quotes.\n */\nexport function escapeJql(value: string): string {\n  return value.replace(/\\\\/g, '\\\\\\\\').replace(/\"/g, '\\\\\"')\n}\n\nexport interface JiraIssueListItem {\n  id: string        // issue key e.g. \"PROJ-123\"\n  title: string     // fields.summary\n  updatedAt: string // fields.updated (ISO string)\n  url: string       // {host}/browse/{key}\n  state: string     // fields.status.name\n}\n\n/**\n * Fetch a list of Jira issues for a project, excluding done statuses\n * @param client - Configured JiraApiClient instance\n * @param options - Fetch options\n * @returns Array of issues sorted by updated date\n */\nexport async function fetchJiraIssueList(\n  client: JiraApiClient,\n  options: {\n    host: string\n    projectKey: string\n    doneStatuses?: string[]\n    limit?: number\n    sprint?: string | undefined\n    mine?: boolean | undefined\n  },\n): Promise<JiraIssueListItem[]> {\n  const { host, projectKey, doneStatuses = ['Done'], limit = 100, sprint, mine } = options\n\n  // Build JQL with status exclusion\n  const statusExclusions = doneStatuses.map((s) => `\"${escapeJql(s)}\"`).join(', ')\n  let jql = `project = \"${escapeJql(projectKey)}\" AND status NOT IN (${statusExclusions})`\n\n  // Add sprint filter\n  if (sprint === 'current') {\n    jql += ' AND sprint in openSprints()'\n  } else if (sprint) {\n    jql += ` AND sprint = \"${escapeJql(sprint)}\"`\n  }\n\n  // Add assignee filter\n  if (mine) {\n    jql += ' AND assignee = currentUser()'\n  }\n\n  jql += ' ORDER BY updated DESC'\n\n  const issues: JiraIssue[] = await client.searchIssues(jql)\n\n  const baseUrl = host.replace(/\\/$/, '')\n\n  return issues.slice(0, limit).map((issue) => ({\n    id: issue.key,\n    title: issue.fields.summary,\n    updatedAt: issue.fields.updated,\n    url: `${baseUrl}/browse/${issue.key}`,\n    state: issue.fields.status.name,\n  }))\n}\n"],"mappings":";;;AAWO,SAAS,UAAU,OAAuB;AAC/C,SAAO,MAAM,QAAQ,OAAO,MAAM,EAAE,QAAQ,MAAM,KAAK;AACzD;AAgBA,eAAsB,mBACpB,QACA,SAQ8B;AAC9B,QAAM,EAAE,MAAM,YAAY,eAAe,CAAC,MAAM,GAAG,QAAQ,KAAK,QAAQ,KAAK,IAAI;AAGjF,QAAM,mBAAmB,aAAa,IAAI,CAAC,MAAM,IAAI,UAAU,CAAC,CAAC,GAAG,EAAE,KAAK,IAAI;AAC/E,MAAI,MAAM,cAAc,UAAU,UAAU,CAAC,wBAAwB,gBAAgB;AAGrF,MAAI,WAAW,WAAW;AACxB,WAAO;AAAA,EACT,WAAW,QAAQ;AACjB,WAAO,kBAAkB,UAAU,MAAM,CAAC;AAAA,EAC5C;AAGA,MAAI,MAAM;AACR,WAAO;AAAA,EACT;AAEA,SAAO;AAEP,QAAM,SAAsB,MAAM,OAAO,aAAa,GAAG;AAEzD,QAAM,UAAU,KAAK,QAAQ,OAAO,EAAE;AAEtC,SAAO,OAAO,MAAM,GAAG,KAAK,EAAE,IAAI,CAAC,WAAW;AAAA,IAC5C,IAAI,MAAM;AAAA,IACV,OAAO,MAAM,OAAO;AAAA,IACpB,WAAW,MAAM,OAAO;AAAA,IACxB,KAAK,GAAG,OAAO,WAAW,MAAM,GAAG;AAAA,IACnC,OAAO,MAAM,OAAO,OAAO;AAAA,EAC7B,EAAE;AACJ;","names":[]}

package/dist/chunk-4E7LCFUG.js

@@ -0,0 +1,24 @@
+#!/usr/bin/env node
+
+// src/utils/text.ts
+function capitalizeFirstLetter(str) {
+  if (!str || str.length === 0) {
+    return str;
+  }
+  if (str.startsWith(" ")) {
+    return str.slice(1);
+  }
+  const firstChar = str.charAt(0);
+  const upperChar = firstChar.toUpperCase();
+  if (upperChar !== firstChar.toLowerCase() || new RegExp("\\p{L}", "u").test(firstChar)) {
+    if (upperChar !== firstChar) {
+      return upperChar + str.slice(1);
+    }
+  }
+  return str;
+}
+
+export {
+  capitalizeFirstLetter
+};
+//# sourceMappingURL=chunk-4E7LCFUG.js.map

package/dist/chunk-4E7LCFUG.js.map

@@ -0,0 +1 @@
+{"version":3,"sources":["../src/utils/text.ts"],"sourcesContent":["/**\n * Capitalizes the first letter of a string.\n *\n * Override behavior: If the string starts with a space, it signals the user\n * wants to opt-out of auto-capitalization. In this case, the leading space\n * is stripped and the first letter is NOT capitalized.\n *\n * @param str - The string to process\n * @returns The processed string with first letter capitalized (or original if override)\n */\nexport function capitalizeFirstLetter(str: string): string {\n\t// Handle empty or whitespace-only strings\n\tif (!str || str.length === 0) {\n\t\treturn str\n\t}\n\n\t// Check for space-prefix override: strip leading space and return as-is\n\tif (str.startsWith(' ')) {\n\t\treturn str.slice(1)\n\t}\n\n\t// Find the first character that could be capitalized (a letter)\n\tconst firstChar = str.charAt(0)\n\n\t// If first character is a letter (including unicode), capitalize it\n\t// Check if toUpperCase() produces a different result (indicates it's a letter with case)\n\tconst upperChar = firstChar.toUpperCase()\n\tif (upperChar !== firstChar.toLowerCase() || /\\p{L}/u.test(firstChar)) {\n\t\t// Only capitalize if it actually changes (avoids issues with non-cased scripts)\n\t\tif (upperChar !== firstChar) {\n\t\t\treturn upperChar + str.slice(1)\n\t\t}\n\t}\n\n\t// Non-letter first character or no case transformation available: return unchanged\n\treturn str\n}\n"],"mappings":";;;AAUO,SAAS,sBAAsB,KAAqB;AAE1D,MAAI,CAAC,OAAO,IAAI,WAAW,GAAG;AAC7B,WAAO;AAAA,EACR;AAGA,MAAI,IAAI,WAAW,GAAG,GAAG;AACxB,WAAO,IAAI,MAAM,CAAC;AAAA,EACnB;AAGA,QAAM,YAAY,IAAI,OAAO,CAAC;AAI9B,QAAM,YAAY,UAAU,YAAY;AACxC,MAAI,cAAc,UAAU,YAAY,KAAK,WAAC,UAAM,GAAC,EAAC,KAAK,SAAS,GAAG;AAEtE,QAAI,cAAc,WAAW;AAC5B,aAAO,YAAY,IAAI,MAAM,CAAC;AAAA,IAC/B;AAAA,EACD;AAGA,SAAO;AACR;","names":[]}

package/dist/{chunk-AR5QKYNE.js → chunk-4FGEGQW4.js}

@@ -1,10 +1,10 @@
 #!/usr/bin/env node
 import {
   SettingsManager
-} from "./chunk-RI2YL6TK.js";
+} from "./chunk-7VHJNVLF.js";
 import {
   MetadataManager
-} from "./chunk-KBEIQP4G.js";
+} from "./chunk-KB64WNBZ.js";
 import {
   logger
 } from "./chunk-VT4PDUYT.js";
@@ -375,7 +375,7 @@ async function getDefaultBranch(path2 = process.cwd()) {
 }
 async function findAllBranchesForIssue(issueNumber, path2 = process.cwd(), settingsManager) {
   if (!settingsManager) {
-    const { SettingsManager: SM } = await import("./SettingsManager-AW3JTJHD.js");
+    const { SettingsManager: SM } = await import("./SettingsManager-FNKCOZMQ.js");
     settingsManager = new SM();
   }
   const protectedBranches = await settingsManager.getProtectedBranches(path2);
@@ -738,4 +738,4 @@ export {
   removePlaceholderCommitFromHead,
   removePlaceholderCommitFromHistory
 };
-//# sourceMappingURL=chunk-AR5QKYNE.js.map
+//# sourceMappingURL=chunk-4FGEGQW4.js.map

package/dist/{chunk-R4YWBGY6.js → chunk-5FJWO4IT.js}

@@ -2,31 +2,32 @@
 import {
   detectPackageManager,
   runScript
-} from "./chunk-4LKGCFGG.js";
+} from "./chunk-WWKOVDWC.js";
 import {
   ProjectCapabilityDetector
-} from "./chunk-TL72BGP6.js";
+} from "./chunk-MORRVYPT.js";
 import {
   getPackageConfig,
   hasScript
-} from "./chunk-VOGGLPG5.js";
+} from "./chunk-YQ57ORTV.js";
 import {
+  detectClaudeCli,
+  launchClaude
+} from "./chunk-UR5DGNUO.js";
+import {
+  GitCommandError,
   executeGitCommand,
   fetchOrigin,
   findMainWorktreePathWithSettings,
   findWorktreeForBranch,
   getMergeTargetBranch
-} from "./chunk-AR5QKYNE.js";
+} from "./chunk-4FGEGQW4.js";
 import {
   SettingsManager
-} from "./chunk-RI2YL6TK.js";
+} from "./chunk-7VHJNVLF.js";
 import {
   MetadataManager
-} from "./chunk-KBEIQP4G.js";
-import {
-  detectClaudeCli,
-  launchClaude
-} from "./chunk-FO5GGFOV.js";
+} from "./chunk-KB64WNBZ.js";
 import {
   getLogger
 } from "./chunk-6MLEBAYZ.js";
@@ -59,7 +60,8 @@ var MergeManager = class {
    */
   async rebaseOnMain(worktreePath, options = {}) {
     var _a;
-    const { dryRun = false, force = false } = options;
+    const { dryRun = false, force = false, jsonStream = false } = options;
+    await this.abortInProgressRebase(worktreePath);
     const mainBranch = await this.getMainBranch(worktreePath);
     const metadata = await this.metadataManager.readMetadata(worktreePath);
     const isChildLoom = !!(metadata == null ? void 0 : metadata.parentLoom);
@@ -117,7 +119,7 @@ Ensure the branch exists locally.`
       if (wipCommitHash) {
         await this.restoreWipCommit(worktreePath, wipCommitHash);
       }
-      return;
+      return { conflictsDetected: false, claudeLaunched: false, conflictsResolved: false };
     }
     const commitsOutput = await executeGitCommand(["log", "--oneline", `${targetBranch}..HEAD`], {
       cwd: worktreePath
@@ -138,7 +140,7 @@ Ensure the branch exists locally.`
       if (commitLines.length > 0) {
         getLogger().info(`[DRY RUN] This would rebase ${commitLines.length} commit(s)`);
       }
-      return;
+      return { conflictsDetected: false, claudeLaunched: false, conflictsResolved: false };
     }
     try {
       await executeGitCommand(["-c", "core.hooksPath=/dev/null", "rebase", targetBranch], { cwd: worktreePath });
@@ -146,20 +148,22 @@ Ensure the branch exists locally.`
       if (wipCommitHash) {
         await this.restoreWipCommit(worktreePath, wipCommitHash);
       }
+      return { conflictsDetected: false, claudeLaunched: false, conflictsResolved: false };
     } catch (error) {
       const conflictedFiles = await this.detectConflictedFiles(worktreePath);
       if (conflictedFiles.length > 0) {
         getLogger().info("Merge conflicts detected, attempting Claude-assisted resolution...");
         const resolved = await this.attemptClaudeConflictResolution(
           worktreePath,
-          conflictedFiles
+          conflictedFiles,
+          { jsonStream }
         );
         if (resolved) {
           getLogger().success("Conflicts resolved with Claude assistance, rebase completed");
           if (wipCommitHash) {
             await this.restoreWipCommit(worktreePath, wipCommitHash);
           }
-          return;
+          return { conflictsDetected: true, claudeLaunched: true, conflictsResolved: true };
         }
         const conflictError = this.formatConflictError(conflictedFiles);
         throw new Error(conflictError);
@@ -338,7 +342,7 @@ To recover:
    * @returns true if conflicts resolved, false otherwise
    * @private
    */
-  async attemptClaudeConflictResolution(worktreePath, conflictedFiles) {
+  async attemptClaudeConflictResolution(worktreePath, conflictedFiles, options = {}) {
     const isClaudeAvailable = await detectClaudeCli();
     if (!isClaudeAvailable) {
       getLogger().debug("Claude CLI not available, skipping conflict resolution");
@@ -352,14 +356,18 @@ To recover:
       "Bash(git diff:*)",
       "Bash(git log:*)",
       "Bash(git add:*)",
-      "Bash(git rebase:*)"
+      "Bash(git rebase:*)",
+      "Bash(GIT_EDITOR=true git rebase:*)"
     ];
     try {
       await launchClaude(prompt, {
         appendSystemPrompt: systemPrompt,
         addDir: worktreePath,
-        headless: false,
-        // Interactive - runs in current terminal with stdio: inherit
+        headless: options.jsonStream ? true : false,
+        ...options.jsonStream && {
+          permissionMode: "bypassPermissions",
+          passthroughStdout: true
+        },
         allowedTools: rebaseAllowedTools,
         noSessionPersistence: true
         // Utility operation - no session persistence needed
@@ -396,8 +404,12 @@ To recover:
   async isRebaseInProgress(worktreePath) {
     const fs = await import("fs/promises");
     const path = await import("path");
-    const rebaseMergePath = path.join(worktreePath, ".git", "rebase-merge");
-    const rebaseApplyPath = path.join(worktreePath, ".git", "rebase-apply");
+    const gitDir = (await executeGitCommand(
+      ["rev-parse", "--absolute-git-dir"],
+      { cwd: worktreePath }
+    )).trim();
+    const rebaseMergePath = path.join(gitDir, "rebase-merge");
+    const rebaseApplyPath = path.join(gitDir, "rebase-apply");
     try {
       await fs.access(rebaseMergePath);
       return true;
@@ -410,6 +422,39 @@ To recover:
     }
     return false;
   }
+  /**
+   * Abort an in-progress rebase if one is detected
+   * This handles cases where a previous rebase was interrupted (e.g., terminal closed,
+   * Claude session ended, user manually stopped) and the worktree is left in a dirty state.
+   * Since we're about to start a new rebase, the stale rebase state is irrelevant and safe to abort.
+   *
+   * @param worktreePath - Path to the worktree
+   * @private
+   */
+  async abortInProgressRebase(worktreePath) {
+    const rebaseInProgress = await this.isRebaseInProgress(worktreePath);
+    if (!rebaseInProgress) {
+      return;
+    }
+    getLogger().warn("A rebase is already in progress. Aborting the stale rebase before proceeding...");
+    try {
+      await executeGitCommand(["rebase", "--abort"], { cwd: worktreePath });
+      getLogger().info("Stale rebase aborted successfully.");
+    } catch (error) {
+      const errorMsg = error instanceof Error ? error.message : String(error);
+      if (errorMsg.includes("No rebase in progress")) {
+        getLogger().info("Rebase was already resolved by another process.");
+        return;
+      }
+      if (error instanceof GitCommandError) {
+        throw new Error(
+          `Failed to abort in-progress rebase: ${error.message}
+Manual recovery: run "git rebase --abort" in the worktree directory.`
+        );
+      }
+      throw error;
+    }
+  }
 };
 
 // src/lib/BuildRunner.ts
@@ -494,4 +539,4 @@ export {
   MergeManager,
   BuildRunner
 };
-//# sourceMappingURL=chunk-R4YWBGY6.js.map
+//# sourceMappingURL=chunk-5FJWO4IT.js.map