@iloom/cli 0.13.0-beta.0 → 0.13.1

package/dist/prompts/init-prompt.txt

@@ -300,16 +300,20 @@ The following JSON Schema defines valid iloom settings:
                         "enum": [
                           "sonnet",
                           "opus",
-                          "haiku"
+                          "haiku",
+                          "sonnet[1m]",
+                          "opus[1m]"
                         ],
-                        "description": "Claude model shorthand: sonnet, opus, or haiku"
+                        "description": "Claude model shorthand: sonnet, opus, haiku, sonnet[1m], or opus[1m]"
                       },
                       "swarmModel": {
                         "type": "string",
                         "enum": [
                           "sonnet",
                           "opus",
-                          "haiku"
+                          "haiku",
+                          "sonnet[1m]",
+                          "opus[1m]"
                         ],
                         "description": "Model to use for this agent in swarm mode. Overrides the base model when running inside swarm workers."
                       },
@@ -359,7 +363,9 @@ The following JSON Schema defines valid iloom settings:
               "enum": [
                 "sonnet",
                 "opus",
-                "haiku"
+                "haiku",
+                "sonnet[1m]",
+                "opus[1m]"
               ],
               "default": "opus",
               "description": "Claude model shorthand for spin orchestrator"
@@ -369,7 +375,9 @@ The following JSON Schema defines valid iloom settings:
               "enum": [
                 "sonnet",
                 "opus",
-                "haiku"
+                "haiku",
+                "sonnet[1m]",
+                "opus[1m]"
               ],
               "description": "Model for the spin orchestrator when running in swarm mode. Overrides spin.model for swarm workflows."
             },
@@ -390,7 +398,9 @@ The following JSON Schema defines valid iloom settings:
               "enum": [
                 "sonnet",
                 "opus",
-                "haiku"
+                "haiku",
+                "sonnet[1m]",
+                "opus[1m]"
               ],
               "default": "opus",
               "description": "Claude model shorthand for plan command"
@@ -433,7 +443,9 @@ The following JSON Schema defines valid iloom settings:
               "enum": [
                 "sonnet",
                 "opus",
-                "haiku"
+                "haiku",
+                "sonnet[1m]",
+                "opus[1m]"
               ],
               "default": "sonnet",
               "description": "Claude model shorthand for session summary generation"
@@ -454,6 +466,15 @@ The following JSON Schema defines valid iloom settings:
                   "maximum": 65535,
                   "description": "Base port for web workspace port calculations (default: 3000)"
                 },
+                "protocol": {
+                  "type": "string",
+                  "enum": [
+                    "http",
+                    "https"
+                  ],
+                  "default": "http",
+                  "description": "Protocol for dev server URLs (http or https)"
+                },
                 "devServer": {
                   "type": "string",
                   "enum": [
@@ -481,6 +502,13 @@ The following JSON Schema defines valid iloom settings:
                   },
                   "description": "Build arguments to pass to docker build (e.g., {\"NODE_ENV\": \"development\"})"
                 },
+                "dockerBuildSecrets": {
+                  "type": "object",
+                  "additionalProperties": {
+                    "type": "string"
+                  },
+                  "description": "Secret files to mount during docker build via --secret (e.g., {\"npmrc\": \"~/.npmrc\"}). Keys are secret IDs, values are source file paths."
+                },
                 "dockerRunArgs": {
                   "type": "array",
                   "items": {
@@ -579,30 +607,6 @@ The following JSON Schema defines valid iloom settings:
               ],
               "additionalProperties": false,
               "description": "Neon database configuration. Requires Neon CLI installed and authenticated for database branching."
-            },
-            "supabase": {
-              "type": "object",
-              "properties": {
-                "projectRef": {
-                  "type": "string",
-                  "minLength": 1,
-                  "description": "Supabase project reference ID (e.g., \"abcdefghijklmnop\")"
-                },
-                "parentBranch": {
-                  "type": "string",
-                  "minLength": 1,
-                  "description": "Reserved for future use. Supabase currently always branches from the default branch."
-                },
-                "withData": {
-                  "type": "boolean",
-                  "description": "Whether to include data when creating a new branch (defaults to true)"
-                }
-              },
-              "required": [
-                "projectRef"
-              ],
-              "additionalProperties": false,
-              "description": "Supabase database configuration. Requires Supabase CLI installed and authenticated for database branching."
             }
           },
           "additionalProperties": false,
@@ -1385,7 +1389,7 @@ Swarms are iloom's most powerful feature. Give them an epic and they'll decompos
 
 You can tune how swarms balance thinking depth versus speed:
 
-  🧠 Maximum Quality — Agents take more time to reason deeply, produce thorough analysis, and write more carefully considered code. Best when correctness matters most. Uses Opus for all agents, which is significantly more expensive.
+  🧠 Maximum Quality — Agents take more time to reason deeply, produce thorough analysis, and write more carefully considered code. Best when correctness matters most. Uses Opus[1m] for the orchestrator and Opus for all other agents, which is significantly more expensive.
   ⚖️  Balanced (recommended) — Strong reasoning at a practical pace. The sweet spot for most work.
   ⚡ Fast & Cheap — Agents move quickly through issues with lighter analysis. Great for rapid prototyping or if you're on a budget.
 ```
@@ -1889,8 +1893,8 @@ When configuring agents, use these model identifiers:
 
    | Mode | Focus | Models used | Best for |
    |------|-------|-------------|----------|
-   | **Maximum Quality** | Deepest reasoning, best analysis | Opus everywhere (except complexity evaluator stays Haiku) | Complex epics, critical features |
-   | **Balanced** (default) | Opus for analysis, Sonnet for everything else | Opus: analyzer, analyze-and-plan. Sonnet: orchestrator, worker, planner, implementer, enhancer, code-reviewer. Haiku: complexity evaluator | Most tasks |
+   | **Maximum Quality** | Deepest reasoning, best analysis | Opus[1m] orchestrator; Opus everywhere else (complexity evaluator stays Haiku) | Complex epics, critical features |
+   | **Balanced** (default) | Strong reasoning at a practical pace | Opus[1m]: orchestrator. Opus: worker, analyzer, analyze-and-plan. Sonnet: planner, implementer, enhancer, code-reviewer. Haiku: complexity evaluator | Most tasks |
    | **Fast & Cheap** | Quick iterations, lowest cost | Haiku everywhere | Simple tasks, rapid prototyping |
 
    Note: The complexity evaluator always stays on Haiku regardless of mode, since it performs a simple classification task that does not benefit from a larger model.
@@ -1899,8 +1903,8 @@ When configuring agents, use these model identifiers:
 
    When the user selects a mode, **merge** the model values into their existing settings. Only set the `swarmModel` (or `model` for the worker) field on each agent — do not overwrite or remove other agent settings.
 
-   - **Maximum Quality:** Set `spin.swarmModel` to `"opus"`. Set `agents.iloom-swarm-worker.model` to `"opus"`. Set `swarmModel` to `"opus"` on all phase agents (`iloom-issue-analyzer`, `iloom-issue-planner`, `iloom-issue-implementer`, `iloom-issue-enhancer`, `iloom-issue-analyze-and-plan`, `iloom-code-reviewer`). Keep `iloom-issue-complexity-evaluator.swarmModel` as `"haiku"`.
-   - **Balanced (default):** Set `spin.swarmModel` to `"sonnet"`. Set `agents.iloom-swarm-worker.model` to `"sonnet"`. Set `swarmModel` to `"opus"` on analysis agents (`iloom-issue-analyzer`, `iloom-issue-analyze-and-plan`). Set `swarmModel` to `"sonnet"` on all other phase agents (`iloom-issue-planner`, `iloom-issue-implementer`, `iloom-issue-enhancer`, `iloom-code-reviewer`). Keep `iloom-issue-complexity-evaluator.swarmModel` as `"haiku"`.
+   - **Maximum Quality:** Set `spin.swarmModel` to `"opus[1m]"`. Set `agents.iloom-swarm-worker.model` to `"opus"`. Set `swarmModel` to `"opus"` on all phase agents (`iloom-issue-analyzer`, `iloom-issue-planner`, `iloom-issue-implementer`, `iloom-issue-enhancer`, `iloom-issue-analyze-and-plan`, `iloom-code-reviewer`). Keep `iloom-issue-complexity-evaluator.swarmModel` as `"haiku"`.
+   - **Balanced (default):** No settings changes needed — the defaults already apply Opus[1m] for the orchestrator, Opus for workers and analysis agents, Sonnet for other phase agents, and Haiku for the complexity evaluator. Only set explicit values if the user wants to be explicit about the configuration.
    - **Fast & Cheap:** Set `spin.swarmModel` to `"haiku"`. Set `agents.iloom-swarm-worker.model` to `"haiku"`. Set `swarmModel` to `"haiku"` on all phase agents and `iloom-issue-complexity-evaluator`.
 
    **Important notes:**

package/dist/prompts/issue-prompt.txt

@@ -226,7 +226,7 @@ The `il` command can also be used as a shorter alias.
 ### Loom Isolation Features
 Each loom provides:
 - Dedicated Git worktree (no branch conflicts)
-- Unique database branch via database branching integration
+- Unique database branch via Neon integration
 - Color-coded terminal/VS Code for visual context switching
 - Deterministic port assignment (3000 + issue number)
 
@@ -1082,6 +1082,9 @@ If workflow plan determined SKIP_PLANNING AND complexity is COMPLEX:
 
 **Execute for both SIMPLE and COMPLEX workflows**
 
+**PREREQUISITE CHECK — Do not skip this:**
+Before executing implementation, verify that a plan comment exists on the issue (either from STEP 2-SIMPLE or STEP 3). If no plan comment exists and the workflow scan determined NEEDS_PLANNING, you MUST stop and run the appropriate analyze-and-plan or planning skill before proceeding. Do not implement without a documented plan.
+
 Only execute if workflow plan determined NEEDS_IMPLEMENTATION:
 
 1. **Extract plan location from previous agent:**

package/dist/prompts/plan-prompt.txt

@@ -14,7 +14,7 @@ Look for available Gemini MCP tools (typically named with "gemini" in the tool n
 - Brainstorming and creative exploration
 - Targeted queries and analysis
 
-**Workflow**: Use these tools during Phase 1 (Understanding) and Phase 2 (Design Exploration) to gather multiple perspectives. Synthesize Gemini's responses into your plan.
+**Workflow**: Use these tools during Phase 1 (Understanding) and Phase 2 (Design Exploration) to gather multiple perspectives. Delegate deep research to the `iloom-issue-analyzer` agent (see Phase 1) and use Gemini for supplementary brainstorming. Synthesize findings into your plan.
 
 **Fallback**: If Gemini MCP tools are unavailable (error responses), continue using your own capabilities for planning.
 {{/if}}
@@ -26,7 +26,7 @@ You have access to Codex AI through MCP tools for code-aware planning.
 Look for available Codex MCP tools (typically named with "codex" in the tool name) for:
 - Code-focused analysis and implementation suggestions
 
-**Workflow**: Use this tool during Phase 2 (Design Exploration) and Phase 3 (Issue Decomposition) to get code-specific insights.
+**Workflow**: Use this tool during Phase 2 (Design Exploration) and Phase 3 (Issue Decomposition) for code-specific insights. Delegate deep research to the `iloom-issue-analyzer` agent (see Phase 1) and use Codex for supplementary code analysis.
 
 **Fallback**: If Codex MCP tool is unavailable (error response), continue using your own capabilities for planning.
 {{/if}}
@@ -35,9 +35,9 @@ Look for available Codex MCP tools (typically named with "codex" in the tool nam
 ### Default Planning (Claude)
 
 You are the primary planner for this session. Use your capabilities to:
-- Gather context by exploring the codebase with Read, Glob, Grep tools
-- Use Task subagents for comprehensive research when needed
-- Synthesize information into a coherent implementation plan
+- Delegate deep research to the `iloom-issue-analyzer` agent (see Phase 1 Research Phase) for thorough problem space, codebase, and third-party dependency understanding
+- Use Task subagents for supplementary research tasks, keeping the main conversation focused on planning decisions
+- Synthesize findings into a coherent implementation plan
 {{/unless}}{{/unless}}
 
 {{#if HAS_REVIEWER}}
@@ -148,13 +148,41 @@ Each issue you help create should represent a single, focused unit of work that:
 - Ask clarifying questions when requirements are ambiguous
 - Present trade-offs clearly when multiple approaches exist
 
+**No Spikes or Investigation Issues**
+All technical uncertainty must be resolved during the research phase (Phase 1), before decomposition begins. Never create "spike", "investigation", "proof of concept", or "exploration" child issues. If the research phase reveals a question that can't be answered without writing code (e.g., "can this library handle our use case?"), flag it to the user as a blocker — they decide whether to investigate before planning continues or to proceed optimistically. The swarm executes — it does not research.
+
 ---
 
 ## Planning Process
 
 ### Phase 1: Understanding (Brainstorming)
 
-Start by understanding the problem space. Ask clarifying questions ONE AT A TIME to prevent cognitive overload.
+Before asking questions, conduct structured research to build a thorough understanding. Research informs better questions and prevents decomposition errors later.
+
+#### Research Phase
+
+**Delegate research to the `iloom-issue-analyzer` agent** to build thorough understanding before decomposing work.
+
+Launch the analyzer as a Task subagent in foreground mode (wait for completion since you need the results before proceeding):
+
+```
+Task(
+  subagent_type: "iloom-issue-analyzer",
+  prompt: "Analyze [issue description/context]. Focus on: problem space understanding, third-party dependencies, codebase entry points and patterns, cross-cutting concerns, and edge cases. Do NOT create issue comments - just return your findings."
+)
+```
+
+The analyzer agent has a comprehensive research framework covering:
+- Problem space and domain understanding
+- Third-party dependency research (Context7, WebSearch, ToolSearch)
+- Systematic codebase exploration (entry points, dependency mapping, pattern recognition)
+- Cross-cutting concern analysis
+
+Wait for the analyzer to complete, then use its findings to inform sharper clarifying questions and better decomposition decisions.
+
+---
+
+After research is complete, ask clarifying questions. Your research findings should inform sharper, more specific questions. **Ask up to 4 independent questions at once** — only hold back questions whose answers depend on a prior question's response.
 
 **Using the AskUserQuestion Tool:**
 When asking clarifying questions, use the AskUserQuestion tool to present options to the user. This provides a better UX with structured choices:
@@ -163,23 +191,17 @@ When asking clarifying questions, use the AskUserQuestion tool to present option
 - Include a clear question header
 - The user can always provide custom input if options don't fit
 
-Example tool usage:
+Example tool usage (batching independent questions):
 ```
 AskUserQuestion(
-  question: "What authentication approach should we use?",
-  options: ["OAuth 2.0 (Recommended)", "JWT tokens", "Session-based", "Other"]
+  question: "A few questions to clarify scope:\n\n1. What authentication approach should we use?\n2. Are there hard constraints (time, dependencies, compatibility)?\n3. Should this support multiple database providers or just one?",
+  options: ["Answer inline", "Let me think — ask again later"]
 )
 ```
 
 **Question Patterns:**
 - Use the AskUserQuestion tool with multiple-choice options when feasible (easier to answer)
 - Focus on: purpose, constraints, success criteria, existing context
-- Acknowledge each answer before moving to the next question
-
-**Example Questions:**
-- "What problem does this feature solve for users?"
-- "Are there existing patterns in the codebase we should follow?"
-- "What are the hard constraints (time, dependencies, compatibility)?"
 
 ### Phase 2: Design Exploration
 
@@ -283,6 +305,8 @@ Each child issue should include ONLY these sections:
    - `substantive: <file-path> — <what it should contain or export>` — the file has expected content, exports, or structure
    - `wired: <file-path> — <how it should be integrated>` — the code is properly connected to the rest of the system (e.g., registered in a router, imported by a parent module, called from an entry point)
 
+   For replacement or migration work, the `substantive` check type means "equivalent to the original in observable terms" — not just "file has expected content or exports." Specify what observable behavior or output the file must reproduce from the original.
+
    Example:
    ```
    ## Must-Haves
@@ -292,10 +316,33 @@ Each child issue should include ONLY these sections:
    ```
 {{/if}}
 
+**Acceptance Criteria Quality Rules:**
+
+- **Observable over structural**: Criteria must describe what a user or developer can observe by using the app or running a command — not what exists in code. "A user can log in and make an authenticated API call that returns data" not "Auth module is configured with Cognito credentials." If you can't verify the criterion without reading source code, rewrite it.
+- **Replacement work requires comparison criteria**: When an issue replaces or rewrites existing functionality, at least one acceptance criterion must define equivalence to the original in observable terms — visual appearance, feature set, and behavior. Specify which dimensions must match. "Has a login form" is not a replacement criterion; "Login page renders with the same layout, branding, interactive features, and error states as the existing page" is.
+- **Integration points need cross-boundary criteria**: When work involves two systems communicating (shared auth, data passing between frameworks, synchronized state), at least one criterion must verify behavior across the boundary — not just that each side is configured. Pattern: "Action in system A produces expected result in system B."
+- **Criteria must specify the verification context**: State the conditions under which the criterion is verified. If the work must function within a specific environment (inside an existing app's layout, behind a specific auth flow, on a single dev server), the criterion must say so. "Works" is ambiguous; "works when run via the project's standard dev command on a single port" is not.
+- **Include constraint criteria for shared systems**: When work modifies or integrates with a shared system, at least one criterion must verify that existing behavior is preserved. "All existing pages/features continue to function unchanged" catches regressions that purely additive criteria miss.
+
 Do NOT add "Implementation Details", "Technical Approach", or similar sections — these violate the rule above.
 
 ---
 
+## Issue Tracker
+
+The configured issue tracker for this project is **{{ISSUE_TRACKER}}**.
+
+**All issue operations** (creating issues, fetching issue details, managing dependencies, posting comments) **MUST use the `mcp__issue_management__*` MCP tools** listed below. These tools abstract across tracker backends (GitHub, Linear, Jira) and handle authentication, format conversion, and API differences automatically.
+
+{{#unless IS_GITHUB_TRACKER}}
+**Do NOT use `gh` CLI for issue or project management** (e.g., `gh issue`, `gh search`, `gh project`, `gh api` for issues) — the configured tracker is {{ISSUE_TRACKER}}, not GitHub. The `gh` CLI only works with GitHub issues and will fail or return irrelevant results. Use the MCP tools above instead.
+{{#if IS_GITHUB_VCS}}
+`gh` is still available for GitHub VCS operations: `gh pr`, `gh repo`.
+{{/if}}
+{{/unless}}
+
+---
+
 ## Issue Creation
 
 At the end of the planning session, you have MCP tools to create issues:
@@ -330,8 +377,10 @@ Before presenting the plan to the user, audit it against these questions:
 1. **For each blocking dependency:** "Can I replace this with a shared contract so both issues run in parallel?" If yes, rewrite the issues with an explicit contract and remove the dependency.
 2. **DAG shape check:** Is the graph wide and shallow, or narrow and linear? If your longest chain is more than 2 deep, re-examine whether intermediate dependencies are truly hard blockers.
 3. **Contract completeness:** Does every issue that produces or consumes a shared API specify the exact contract (function signatures, types, module exports) in its description?
+4. **Acceptance criteria observability:** For each acceptance criterion, ask: can this be verified by using the app or running a command, without reading source code? If not, rewrite it.
 {{#if WAVE_VERIFICATION}}
-4. **Wave verification tasks:** Does every wave boundary have a verification child issue? Count your waves — if you have N waves, you need N verification issues (one after each wave, including a final one). If any wave boundary is missing a verification issue, add one now. This is mandatory, not optional.
+5. **Wave verification tasks:** Does every wave boundary have a verification child issue? Count your waves — if you have N waves, you need N verification issues (one after each wave, including a final one). If any wave boundary is missing a verification issue, add one now. This is mandatory, not optional.
+6. **Integration must-haves for producer/consumer pairs:** For each wave with parallel issues, check: does any issue produce a class/service that a sibling issue's factory or provider is expected to consume? If yes, the wave's verification issue must have a `substantive:` must-have verifying the consumer injects/passes a real instance (not null). Missing these means nobody checks the wiring after merge.
 {{/if}}
 
 {{#if WAVE_VERIFICATION}}
@@ -370,12 +419,44 @@ Verify integration (depends on A, B, C)
 ```
 
 Skip verification tasks only when the DAG is trivially small (2 or fewer child issues).
+
+**Integration-Point Must-Haves for Producer/Consumer Pairs:**
+
+When parallel issues in the same wave have producer/consumer relationships, the verification issue for that wave MUST include integration must-haves that verify the consumer actually uses the producer's output — not just that both pieces exist independently.
+
+**How to detect producer/consumer pairs:** Scan parallel issues within each wave for these signals:
+- One issue's "Shared Contracts (Produces)" matches another issue's "Shared Contracts (Consumes)"
+- A factory or provider class in issue B constructs or injects instances of a class created in issue A
+- Constructor parameters or method signatures in one issue are typed as classes/interfaces from a sibling issue
+- DI container registrations in one issue provide services consumed in another
+
+**What to generate:** For each detected pair, add a `substantive:` must-have to the wave's verification issue. The must-have should verify that the consumer passes or injects a real instance of the producer's class — not a null placeholder. The check must be statically verifiable (grep for null in constructor calls, verify the factory imports and instantiates the real class, check that DI binds to the concrete implementation).
+
+**Format:**
+```
+## Must-Haves
+- substantive: <consumer-file-path> — <ConsumerClass> passes a real <ProducerClass> instance (not null) to <target> in <methods-or-call-sites>
+```
+
+**Example:** If wave 2 has:
+- Issue A: Creates `LayoutCanvasView` class
+- Issue B: Creates `LayoutPlayerItemFactory` that constructs `LayoutPlayerItem`
+
+Then the wave 2 verification issue gets:
+```
+## Must-Haves
+- substantive: src/factories/LayoutPlayerItemFactory.ts — LayoutPlayerItemFactory injects CanvasViewFactoryService and passes a real LayoutCanvasView (not null) to LayoutPlayerItem in both createFromEditorItem and createFromDraftItem
+```
+
+Place integration must-haves on the wave's verification issue, NOT on the individual child issues — the integration only exists after both are merged.
 {{/if}}
 
+{{#unless AUTONOMOUS_MODE}}
 **Before Creating Issues:**
 1. Summarize the proposed issues and their relationships
 2. Ask for explicit confirmation: "Ready to create these issues?"
 3. Create issues only after user approval
+{{/unless}}
 
 {{#if EXISTING_ISSUE_MODE}}
 **Issue Decomposition Mode:**

package/dist/prompts/regular-prompt.txt

@@ -133,7 +133,7 @@ The `il` command can also be used as a shorter alias.
 ### Loom Isolation Features
 Each loom provides:
 - Dedicated Git worktree (no branch conflicts)
-- Unique database branch via database branching integration
+- Unique database branch via Neon integration
 - Color-coded terminal/VS Code for visual context switching
 - Deterministic port assignment (3000 + issue number)
 

package/dist/prompts/swarm-orchestrator-prompt.txt

@@ -199,7 +199,16 @@ If both fail, mark the child as `failed` with the error and skip spawning.
 
 **Do NOT use `il start` to create worktrees. Worktrees are created by this orchestrator via `git worktree add`.**
 
-#### Step 2.2b: Spawn the Child Agent
+#### Step 2.2b: Capture Pre-Wave Commit and Spawn the Child Agent
+
+**Before spawning this wave**, capture the current epic branch HEAD so the wave verifier can diff only the changes introduced by this wave:
+
+```bash
+cd "{{EPIC_WORKTREE_PATH}}"
+PRE_WAVE_COMMIT=$(git rev-parse HEAD)
+```
+
+Save `PRE_WAVE_COMMIT` — you will pass it to any verification agents spawned for this wave.
 
 **Spawn all unblocked issues in parallel** by making multiple `Task` tool calls in a single message.
 
@@ -242,6 +251,8 @@ The prompt for each verification agent should be exactly:
 ```
 Issue: #<child-number>
 Worktree: <child-worktree-path>
+Epic Worktree: {{EPIC_WORKTREE_PATH}}
+Pre-wave commit: <PRE_WAVE_COMMIT>
 
 IMPORTANT: Your working directory is <child-worktree-path>. Run `cd <child-worktree-path>` as your FIRST action before doing ANY work.
 ```
@@ -397,7 +408,9 @@ If the `il cleanup` command fails, log the error but continue with the orchestra
 After a child completes:
 1. Remove the completed child's issue number from all other children's `blockedBy` lists
 2. Check if any previously blocked children are now unblocked (empty `blockedBy` list)
-3. If newly unblocked children exist: spawn agents for them (same pattern as Phase 2, Step 2.2)
+3. If newly unblocked children exist:
+   - Capture a fresh `PRE_WAVE_COMMIT` before spawning (same as Step 2.2b)
+   - Spawn agents for them (same pattern as Phase 2, Step 2.2)
 
 {{#if DRAFT_PR_MODE}}
 {{#if AUTO_COMMIT_PUSH}}
@@ -468,23 +481,19 @@ git log --oneline -5
 
 #### Step 5.2.5a: Run Code Review
 
-**Delegate this to a subagent.** Spawn a Task subagent to invoke the code reviewer:
+**Delegate this to a subagent.** Spawn a Task subagent using the code reviewer agent directly:
 
-- `subagent_type`: `"general-purpose"`
+- `subagent_type`: `"iloom-swarm-code-reviewer"`
 - Prompt:
 
 ```
 Run a full code review of the integrated epic branch.
 
-## Instructions
-
-You are in the epic worktree at `{{EPIC_WORKTREE_PATH}}`. All child agents' work has been merged into this branch.
+You are in the epic worktree at `{{EPIC_WORKTREE_PATH}}`. All child agents' work has been merged into this branch. Individual file changes have already been reviewed per-wave. Focus on cross-wave integration concerns: duplicate implementations across child issues, inconsistent patterns where children touched the same areas, conflicts introduced by combining waves.
 
-1. Execute: @agent-iloom-code-reviewer with prompt "Run code review."
-2. Wait for the review to complete.
-3. Report back with the full review results, including all findings with their confidence scores, file locations, and recommendations.
-   - If no issues found, report "No issues found."
-   - If issues found, include the full structured report (Critical issues 95-100, Warnings 80-94).
+Report the full review results, including all findings with their confidence scores, file locations, and recommendations.
+- If no issues found, report "No issues found."
+- If issues found, include the full structured report (Critical issues 95-100, Warnings 80-94).
 ```
 
 **Handle the subagent result:**
@@ -639,3 +648,7 @@ Mark todo #9, #10, #11, and #12 as completed.
 Mark todo #9, #10, and #11 as completed.
 {{/if}}
 {{/if}}
+
+### Step 5.5: Mark Epic as Complete
+
+Call `mcp__recap__set_loom_state` with `{ "state": "done" }` (omit `worktreePath` — this targets the epic loom itself). This lets the iloom hook detect swarm completion and show appropriate agent guidance for follow-up questions.

package/dist/{rebase-MAMWPA2L.js → rebase-MLIN572O.js}

@@ -2,24 +2,24 @@
 import {
   BuildRunner,
   MergeManager
-} from "./chunk-Q7VXHJP6.js";
+} from "./chunk-EHAITKLS.js";
 import {
   installDependencies
-} from "./chunk-VIQOQ463.js";
+} from "./chunk-OLJ54WGW.js";
 import {
   GitWorktreeManager
-} from "./chunk-4VQXMEEP.js";
+} from "./chunk-PPQ5LV7U.js";
 import "./chunk-772N5WCA.js";
 import "./chunk-K3QGG4O2.js";
 import "./chunk-DDHWZNGL.js";
 import {
   getWorktreeRoot,
   isValidGitRepo
-} from "./chunk-QNPJXO53.js";
+} from "./chunk-KGOBNC5A.js";
 import {
   SettingsManager
-} from "./chunk-WGUGB54H.js";
-import "./chunk-4JZEQBWV.js";
+} from "./chunk-F5NKWLMQ.js";
+import "./chunk-XIVLGWUX.js";
 import "./chunk-FTYWGQFM.js";
 import {
   logger
@@ -148,4 +148,4 @@ export {
   RebaseCommand,
   WorktreeValidationError
 };
-//# sourceMappingURL=rebase-MAMWPA2L.js.map
+//# sourceMappingURL=rebase-MLIN572O.js.map

package/dist/{recap-IDBO3KM5.js → recap-CKGKFDJL.js}

@@ -4,16 +4,16 @@ import {
 } from "./chunk-NXMDEL3F.js";
 import {
   findArchivedRecap
-} from "./chunk-3XEXT35Z.js";
+} from "./chunk-E5OM25WK.js";
 import {
   IdentifierParser
-} from "./chunk-SN4S5CWL.js";
+} from "./chunk-GQDVH6FA.js";
 import {
   GitWorktreeManager
-} from "./chunk-4VQXMEEP.js";
-import "./chunk-QNPJXO53.js";
-import "./chunk-WGUGB54H.js";
-import "./chunk-4JZEQBWV.js";
+} from "./chunk-PPQ5LV7U.js";
+import "./chunk-KGOBNC5A.js";
+import "./chunk-F5NKWLMQ.js";
+import "./chunk-XIVLGWUX.js";
 import "./chunk-FTYWGQFM.js";
 import "./chunk-VRPPI6GU.js";
 
@@ -135,4 +135,4 @@ var RecapCommand = class {
 export {
   RecapCommand
 };
-//# sourceMappingURL=recap-IDBO3KM5.js.map
+//# sourceMappingURL=recap-CKGKFDJL.js.map

package/dist/{run-RGZHCQ6M.js → run-CUNRQNZS.js}

@@ -1,21 +1,22 @@
 #!/usr/bin/env node
 import {
-  DevServerManager
-} from "./chunk-QQULYI2S.js";
+  DevServerManager,
+  buildDevServerUrl
+} from "./chunk-P5MNWBLH.js";
 import {
   DockerManager
-} from "./chunk-AYLC633W.js";
-import "./chunk-H3T3EPF3.js";
+} from "./chunk-7TN5VW4I.js";
+import "./chunk-LNY2Y32V.js";
 import {
   getWorkspacePort
-} from "./chunk-ZUIFO7B4.js";
+} from "./chunk-ERMEYFT6.js";
 import {
   IdentifierParser
-} from "./chunk-SN4S5CWL.js";
-import "./chunk-VIQOQ463.js";
+} from "./chunk-GQDVH6FA.js";
+import "./chunk-OLJ54WGW.js";
 import {
   GitWorktreeManager
-} from "./chunk-4VQXMEEP.js";
+} from "./chunk-PPQ5LV7U.js";
 import {
   openBrowser
 } from "./chunk-WEBMMJKL.js";
@@ -28,11 +29,11 @@ import {
 import "./chunk-K3QGG4O2.js";
 import {
   extractIssueNumber
-} from "./chunk-QNPJXO53.js";
+} from "./chunk-KGOBNC5A.js";
 import {
   SettingsManager
-} from "./chunk-WGUGB54H.js";
-import "./chunk-4JZEQBWV.js";
+} from "./chunk-F5NKWLMQ.js";
+import "./chunk-XIVLGWUX.js";
 import "./chunk-FTYWGQFM.js";
 import {
   logger
@@ -214,14 +215,16 @@ Make sure the project is built (run 'il start' first)`
    * Auto-starts dev server if not already running
    */
   async openWebBrowser(worktree) {
-    var _a, _b, _c;
+    var _a, _b, _c, _d, _e;
     const cliOverrides = extractSettingsOverrides();
     const settings = await this.settingsManager.loadSettings(void 0, cliOverrides);
+    const isMainWorktree = await this.gitWorktreeManager.isMainWorktree(worktree, this.settingsManager);
     const port = await getWorkspacePort({
       worktreePath: worktree.path,
       worktreeBranch: worktree.branch,
       basePort: (_b = (_a = settings.capabilities) == null ? void 0 : _a.web) == null ? void 0 : _b.basePort,
-      checkEnvFile: true
+      checkEnvFile: true,
+      isMainWorktree
     });
     const issueNumber = extractIssueNumber(worktree.branch);
     const dockerIdentifier = (issueNumber == null ? void 0 : issueNumber.toString()) ?? worktree.branch;
@@ -244,7 +247,8 @@ Make sure the project is built (run 'il start' first)`
         `Dev server failed to start on port ${port}. Opening browser anyway...`
       );
     }
-    const url = `http://localhost:${port}`;
+    const protocol = ((_e = (_d = settings.capabilities) == null ? void 0 : _d.web) == null ? void 0 : _e.protocol) ?? "http";
+    const url = buildDevServerUrl(port, protocol);
     logger.info(`Opening browser: ${url}`);
     await openBrowser(url);
     logger.success("Browser opened");
@@ -253,4 +257,4 @@ Make sure the project is built (run 'il start' first)`
 export {
   RunCommand
 };
-//# sourceMappingURL=run-RGZHCQ6M.js.map
+//# sourceMappingURL=run-CUNRQNZS.js.map