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
This commit is contained in:
51
openspec/changes/domain3-multi-agent/proposal.md
Normal file
51
openspec/changes/domain3-multi-agent/proposal.md
Normal file
@@ -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
|
||||
Reference in New Issue
Block a user