docs: boocode-lift-analysis, openspec change docs, codesight cache, deps

- Add boocode-lift-analysis.md: comprehensive 30-repo lift matrix across 25 domains
- Add openspec/ change docs: domain2-code-intelligence, domain3-multi-agent, impeccable-wave, streaming-codeblocks
- Update .gitignore: .impeccable/, .omo/, bun.lock, DESIGN.md, PRODUCT.md
- Update dependencies in package.json + pnpm-lock.yaml
- Update .codesight/ analysis cache

openspec/changes/domain3-multi-agent/.openspec.yaml

@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-06-08

openspec/changes/domain3-multi-agent/proposal.md

@@ -0,0 +1,51 @@
+# Domain 3 — Multi-Agent Orchestration
+
+**Status:** Proposed
+**Depends on:** v2.7.17-orchestrator, v2.8.13-model-resolution-matcher, v2.8.17-boulder-state
+
+## Why
+
+BooCode's conductor runs sequential analysis flows on local Qwen with a static wave scheduler. Each step is a linear dependency chain. This works for simple analysis flows but misses 8 concrete improvements identified in the lift analysis (boocode-lift-analysis.md Domain 3).
+
+DO_WHILE loops, SWITCH branching, FORK_JOIN parallel execution, a formal task state machine, declarative DAGs, parallel batch execution, and a structured phased lifecycle would make the conductor a true multi-agent workflow engine.
+
+## What Changes
+
+### Phase 1: Flow state machine + branching (high confidence)
+
+1. Task state machine — Add formal states: SCHEDULED → IN_PROGRESS → COMPLETED/FAILED/TIMED_OUT with retriable flag. Currently steps just have running/completed/failed/cancelled.
+
+2. DO_WHILE loop step — Re-runs a sub-step until a condition is met. while(condition) guard on step definition.
+
+3. SWITCH branch step — cases: [{ when: condition, steps: [...] }]. First matching case executes.
+
+4. FORK_JOIN step — Fans out to N parallel sub-steps and synchronizes at a Join point. All branches must complete before the flow advances.
+
+### Phase 2: Declarative DAGs (medium confidence)
+
+5. JSON DAG format — Optional JSON-based flow definition alongside existing TypeScript Step[] arrays. LLM-friendly, versioned, loadable from disk.
+
+### Phase 3: Batch execution + lifecycle (lower confidence)
+
+6. Parallel batch execution — Independent tasks within a flow run concurrently. Uses existing dispatcher's task queue — launch multiple tasks at once.
+
+7. Structured phased lifecycle — ticket → research → plan → execute → commit → review as a template flow definition.
+
+## Non-Goals
+- No replacement of existing flow engine — additive changes only
+- No Paseo daemon integration (handled by omo-paseo-bridge)
+- No inter-agent messaging (Domain 4)
+
+## Capabilities
+
+### New Capabilities
+- DO_WHILE step type — repeat sub-steps until condition met
+- SWITCH step type — conditional branching by case
+- FORK_JOIN step type — parallel fan-out with Join sync
+- Retriable task flag — auto-retry failed steps up to N times
+- JSON DAG format — portable flow definitions
+- Phased lifecycle template — ticket-to-review reference flow
+
+### Modified Capabilities
+- Step kind: gains 'do_while', 'switch', 'fork_join'
+- Flow runner: wave scheduler handles branching + parallel branches

openspec/changes/domain3-multi-agent/tasks.md

@@ -0,0 +1,57 @@
+# Tasks — Domain 3: Multi-Agent Orchestration
+
+## Phase 1 (4 tasks)
+
+### 1. Task state machine
+Add formal states to Step:
+- Read ./apps/coder/src/services/flow-runner.ts and ./apps/coder/src/services/flow-runner-decisions.ts
+- Extend Step.type to add TIMED_OUT state
+- Add retriable flag: retry_count, max_retries to Step
+- Wire into flow-runner's advance/delegate path
+- On failure with retriable=true: re-queue instead of failing
+**Verification**: tsc --noEmit passes
+
+### 2. DO_WHILE loop step
+- Add 'do_while' to StepKind
+- Step definition: { kind: 'do_while', condition: (ctx) => boolean, steps: Step[] }
+- Flow runner executes steps, re-evaluates condition, loops or advances
+- Guard against infinite loops (max 100 iterations default)
+**Verification**: tsc --noEmit passes
+
+### 3. SWITCH branch step
+- Add 'switch' to StepKind
+- Step definition: { kind: 'switch', cases: [{ when: (ctx) => boolean, steps: Step[] }] }
+- Flow runner evaluates cases in order, executes first matching case's steps
+- Default/else case support
+**Verification**: tsc --noEmit passes
+
+### 4. FORK_JOIN step
+- Add 'fork_join' to StepKind
+- Step definition: { kind: 'fork_join', branches: Step[][], joinStrategy: 'all' | 'any' }
+- Flow runner dispatches all branches in parallel via existing task queue
+- On completion, gathers results and passes to join handler
+**Verification**: tsc --noEmit passes
+
+## Phase 2 (1 task)
+
+### 5. JSON DAG format
+- Define JSON schema for flow DAG: nodes, edges, conditions
+- Create DAG loader that produces Step[] from JSON
+- Add validation for cycles, unreachable nodes, missing deps
+- Parallel to existing TypeScript Step[] arrays — not a replacement
+**Verification**: tsc --noEmit passes. Load a sample JSON DAG and verify it produces correct Step[].
+
+## Phase 3 (2 tasks)
+
+### 6. Parallel batch execution
+- Modify flow runner to dispatch independent steps concurrently
+- Use Promise.all for independent steps in the same wave
+- Respect dependency ordering
+**Verification**: tsc --noEmit passes. Two independent steps with different durations finish concurrently.
+
+### 7. Phased lifecycle template
+- Create conductor/flows/lifecycle.ts with 6-phase template:
+  ticket → research → plan → execute → commit → review
+- Each phase is a step with agent dispatch + output validation
+- Users can fork and customize
+**Verification**: tsc --noEmit passes. Flow definition renders correct Step[].