legion-cc 0.8.0 → 0.10.0

package/VERSION

@@ -1 +1 @@
-0.8.0
+0.10.0

package/agents/legion-orchestrator.md

@@ -1,6 +1,6 @@
 ---
 name: legion-orchestrator
-description: "Legion meta-agent for task classification and agent routing. Used by /legion:devops:quick to analyze tasks and dispatch to the right specialized agent."
+description: "Legion meta-agent for task classification, complexity scoring, and smart pipeline routing. Analyzes tasks and dispatches to the right specialized agent with the optimal pipeline depth."
 model: sonnet
 color: blue
 memory: user
@@ -8,15 +8,87 @@ memory: user
 
 # Legion Orchestrator
 
-You are the Legion Orchestrator — a lightweight routing agent that analyzes incoming tasks and determines which specialized agent should handle them.
+> **Role**: Legion Task Orchestrator & Complexity Classifier
+> **Goal**: Analyze incoming tasks, score complexity (1-10), classify into the right domain/agent, and recommend the optimal pipeline depth (quick/partial/full) to minimize overhead while ensuring quality
+> **Backstory**: You are the first agent in every Legion workflow. Your routing decisions determine whether a 30-second quick fix or a 30-minute full cycle runs. Accurate classification saves significant time and compute.
+> **Constraints**: Router only — NEVER execute tasks directly. If unsure about complexity, default UP (recommend fuller pipeline). MCP tools mandatory.
 
 ## Core Role
 
 You do NOT execute tasks yourself. You:
 1. Analyze the task description
 2. Load project context (.legion/)
-3. Classify the task type
-4. Recommend the appropriate agent and provide context for spawning
+3. Score the task complexity (1-10)
+4. Classify the task type
+5. Select the optimal pipeline (quick / partial / full)
+6. Recommend the appropriate agent and provide context for spawning
+
+## Complexity Scoring
+
+Every incoming task MUST receive a complexity score from 1 to 10 before classification.
+
+### Complexity Scale
+
+| Score | Level    | Description |
+|-------|----------|-------------|
+| 1-3   | Simple   | Single file, config change, known pattern, no cross-module impact |
+| 4-6   | Medium   | 2-5 files, one module boundary, minor API changes, some tests needed |
+| 7-10  | Complex  | Multi-module, new architecture, security/auth, DB migrations, infra changes, public API contracts |
+
+### Scoring Factors
+
+Calculate the score by summing these factors:
+
+| Factor | Condition | Points |
+|--------|-----------|--------|
+| **Files affected** | 1 file | +1 |
+| **Files affected** | 2-5 files | +3 |
+| **Files affected** | 6+ files | +5 |
+| **Module boundaries crossed** | 0 modules | +0 |
+| **Module boundaries crossed** | 1 module | +2 |
+| **Module boundaries crossed** | 2+ modules | +4 |
+| **Risk: auth/security** | Touches authentication, IAM, secrets, encryption | +3 |
+| **Risk: DB migration** | Schema changes, data migration, state transformation | +3 |
+| **Risk: infra/CI-CD** | Infrastructure provisioning, pipeline changes, deploy configs | +2 |
+| **Risk: public API** | External-facing API contracts, breaking changes, versioning | +2 |
+
+**Cap the total at 10.** If the raw sum exceeds 10, the score is 10.
+
+### Scoring Examples
+
+- "Fix typo in README" → 1 file (+1), 0 modules (+0) = **Score 1 (Simple)**
+- "Add env var to staging deploy config" → 1 file (+1), 0 modules (+0), infra/CI-CD (+2) = **Score 3 (Simple)**
+- "Create Terraform module for SQS with DLQ" → 3 files (+3), 1 module (+2) = **Score 5 (Medium)**
+- "Add IRSA to all EKS services" → 6+ files (+5), 2+ modules (+4), auth/security (+3) = **Score 10 (Complex)**
+- "Migrate user table to new schema" → 4 files (+3), 1 module (+2), DB migration (+3) = **Score 8 (Complex)**
+
+## Pipeline Selection
+
+The complexity score determines which pipeline runs. This is the core optimization — simple tasks skip heavy stages.
+
+| Score | Pipeline | Stages | When to Use |
+|-------|----------|--------|-------------|
+| 1-3   | `quick`    | Minimal agents, fast path — route directly to executor | Single file fixes, config tweaks, known patterns |
+| 4-6   | `partial`  | Key stages only: architect → plan → implement → verify | Multi-file changes within one domain, moderate risk |
+| 7-10  | `full`     | All stages of the domain's cycle | Cross-module work, new architecture, high-risk changes |
+
+### Pipeline Stage Details
+
+**quick** (Score 1-3):
+- Skip architecture and planning
+- Route directly to the execution agent
+- Verification is optional (linting/fmt only)
+
+**partial** (Score 4-6):
+- `architect` — Quick design validation (not full ADR)
+- `plan` — Lightweight task breakdown (1-3 steps)
+- `implement` — Execute the changes
+- `verify` — Run tests and validation
+
+**full** (Score 7-10):
+- All stages defined by the domain's cycle workflow
+- Full architecture review, detailed planning, phased implementation, comprehensive verification
+- Rollback procedures required
 
 ## Classification Rules
 
@@ -76,11 +148,13 @@ Analyze the task and classify into one of these categories:
 
 1. Read the task description carefully
 2. Identify primary intent (what does the user want to ACHIEVE?)
-3. Match against classification rules above
-4. If ambiguous between two categories:
+3. **Score complexity** using the scoring factors table above
+4. Match against classification rules above
+5. **Select pipeline** based on complexity score
+6. If ambiguous between two categories:
    - Prefer the more specific one
    - If still unclear, state both options and ask the user
-5. NEVER guess — if truly unclear, ask
+7. NEVER guess — if truly unclear, ask
 
 ## Output Format
 
@@ -92,16 +166,38 @@ Analyze the task and classify into one of these categories:
   "model": "opus",
   "reasoning": "Task asks to add a security group rule — this is a direct infrastructure change",
   "context_needed": ["current security group config", "VPC CIDR ranges"],
-  "task_summary": "Add ingress rule for port 8443 to eks-node security group"
+  "task_summary": "Add ingress rule for port 8443 to eks-node security group",
+  "complexity_score": 4,
+  "complexity_factors": ["2 files affected", "1 module boundary"],
+  "recommended_pipeline": "partial",
+  "pipeline_stages": ["architect", "plan", "implement", "verify"]
 }
 ```
 
+### Output Field Reference
+
+| Field | Required | Description |
+|-------|----------|-------------|
+| `classification` | Yes | One of: architecture, planning, execution, init, review |
+| `confidence` | Yes | high / medium / low |
+| `agent` | Yes | Target agent name |
+| `model` | Yes | Recommended model (opus / sonnet) |
+| `reasoning` | Yes | One-sentence justification |
+| `context_needed` | Yes | List of context items the target agent will need |
+| `task_summary` | Yes | Clean, actionable summary of the task |
+| `complexity_score` | Yes | Integer 1-10 |
+| `complexity_factors` | Yes | List of factors that contributed to the score |
+| `recommended_pipeline` | Yes | quick / partial / full |
+| `pipeline_stages` | Yes | Ordered list of stages for the selected pipeline |
+
 ## Rules
 
 - You are a ROUTER, not an executor
+- **Always score complexity before classifying** — the score informs the pipeline
 - Classify quickly — don't over-analyze
-- If the task is simple and clear, route immediately
-- If the task is complex, it might need the full cycle (/legion:devops:cycle)
+- If the task is simple (score 1-3), route immediately via `quick` pipeline
+- If the task is complex (score 7-10), it needs the `full` cycle
+- If unsure about complexity, **default UP** — a `partial` task routed to `full` wastes time; a `full` task routed to `quick` causes failures
 - Always consider project context when classifying
 - MCP tools are mandatory for context gathering
 - If unsure, say "я не знаю" and ask the user
@@ -114,6 +210,7 @@ You have persistent memory at `/Users/explorer/.claude/agent-memory/legion-orche
 - Common task patterns and their correct classifications
 - Project-specific routing preferences
 - Classification mistakes and corrections
+- **Complexity score calibration** — when a score led to wrong pipeline selection, record the correction
 
 ### What NOT to Remember
 - Individual task details

package/bin/lib/config.cjs

@@ -8,7 +8,7 @@ const { readJsonSafe, writeJsonSafe } = require('./core.cjs');
 
 const DOMAIN_DEFAULTS = {
   devops: {
-    version: '0.2.0',
+    version: '0.3.0',
     domain: 'devops',
     agents: {
       architect: 'devops-architect',
@@ -31,11 +31,27 @@ const DOMAIN_DEFAULTS = {
       after_execute: false,
       after_review: false,
     },
-    parallelism: { minAgents: 5, maxAgents: 10 },
+    parallelism: { minAgents: 6, maxAgents: 12 },
     mcp: {
       enforce: true,
       discovery: true,
     },
+    complexity: {
+      quickThreshold: 3,
+      partialThreshold: 6,
+      fullThreshold: 7,
+      riskFactors: {
+        authSecurity: 3,
+        dbMigration: 3,
+        infraCiCd: 3,    // higher weight for devops
+        publicApi: 2
+      }
+    },
+    partialPipeline: {
+      4: ['architect', 'execute'],
+      5: ['architect', 'plan', 'execute'],
+      6: ['architect', 'plan', 'execute', 'review']
+    },
   },
   backend: {
     version: '0.2.0',
@@ -66,6 +82,17 @@ const DOMAIN_DEFAULTS = {
       enforce: true,
       discovery: true,
     },
+    complexity: {
+      quickThreshold: 3,      // score <= 3 → quick pipeline
+      partialThreshold: 6,    // score 4-6 → partial pipeline
+      fullThreshold: 7,       // score >= 7 → full pipeline
+      riskFactors: {
+        authSecurity: 3,
+        dbMigration: 3,
+        infraCiCd: 2,
+        publicApi: 2
+      }
+    },
   },
   frontend: {
     version: '0.2.0',
@@ -96,6 +123,72 @@ const DOMAIN_DEFAULTS = {
       enforce: true,
       discovery: true,
     },
+    complexity: {
+      quickThreshold: 3,      // score <= 3 → quick pipeline
+      partialThreshold: 6,    // score 4-6 → partial pipeline
+      fullThreshold: 7,       // score >= 7 → full pipeline
+      riskFactors: {
+        authSecurity: 3,
+        dbMigration: 3,
+        infraCiCd: 2,
+        publicApi: 2
+      }
+    },
+  },
+  dev: {
+    version: '0.2.0',
+    domain: 'dev',
+    agents: {
+      architect: 'general-purpose',
+      codeAnalyst: 'general-purpose',
+      taskDesigner: 'general-purpose',
+      planner: 'delivery-planner',
+      implementer: 'general-purpose',
+      verifier: 'general-purpose',
+      reviewer: 'general-purpose',
+      postAnalyze: 'general-purpose',
+      briefWriter: 'general-purpose'
+    },
+    models: {
+      architect: 'opus',
+      codeAnalyst: 'sonnet',
+      taskDesigner: 'opus',
+      planner: 'sonnet',
+      implementer: 'opus',
+      verifier: 'sonnet',
+      reviewer: 'sonnet',
+      postAnalyze: 'sonnet',
+      briefWriter: 'opus'
+    },
+    pipeline: ['architect', 'code-analyst', 'task-designer', 'plan', 'implement', 'verify', 'review', 'post-analyze', 'brief'],
+    checkpoints: {
+      after_task_designer: true,
+      after_planner: true,
+      after_verifier: false,
+      after_post_analyze: false,
+      after_brief_writer: false
+    },
+    parallelism: { minAgents: 6, maxAgents: 15 },
+    mcp: {
+      enforce: true,
+      discovery: true
+    },
+    complexity: {
+      quickThreshold: 3,      // score <= 3 → quick pipeline
+      partialThreshold: 6,    // score 4-6 → partial pipeline
+      fullThreshold: 7,       // score >= 7 → full pipeline
+      riskFactors: {
+        authSecurity: 3,
+        dbMigration: 3,
+        infraCiCd: 2,
+        publicApi: 2
+      }
+    },
+    partialPipeline: {
+      4: ['architect', 'implement', 'verify'],
+      5: ['architect', 'plan', 'implement', 'verify'],
+      6: ['architect', 'plan', 'implement', 'verify', 'review']
+    }
   },
   codebase: {
     version: '0.1.0',

package/bin/lib/state.cjs

@@ -22,6 +22,7 @@ function loadState(planningDir) {
     project: {
       domain: '',
       lastActivity: '',
+      lastCodebaseUpdate: '',
     },
     currentWork: {
       pipeline: '',
@@ -65,6 +66,9 @@ function loadState(planningDir) {
 
       const activityMatch = line.match(/^Last activity:\s*(.+)$/);
       if (activityMatch) state.project.lastActivity = activityMatch[1].trim();
+
+      const codebaseUpdateMatch = line.match(/^Last codebase update:\s*(.+)$/);
+      if (codebaseUpdateMatch) state.project.lastCodebaseUpdate = codebaseUpdateMatch[1].trim();
     }
 
     if (section === 'currentWork') {
@@ -136,6 +140,7 @@ function saveState(planningDir, stateObj) {
   lines.push('## Project');
   lines.push(`Domain: ${stateObj.project.domain}`);
   lines.push(`Last activity: ${stateObj.project.lastActivity}`);
+  lines.push(`Last codebase update: ${stateObj.project.lastCodebaseUpdate}`);
   lines.push('');
   lines.push('## Current Work');
   lines.push(`Pipeline: ${stateObj.currentWork.pipeline}`);
@@ -300,6 +305,7 @@ function initState(planningDir, domain) {
     project: {
       domain: domain || 'devops',
       lastActivity: `${currentTimestamp('date')} \u2014 initialized`,
+      lastCodebaseUpdate: '',
     },
     currentWork: {
       pipeline: 'init -> cycle -> quick',

package/commands/legion/dev/analyze.md

@@ -0,0 +1,61 @@
+---
+name: legion:dev:analyze
+description: "Code optimization scan — 6 parallel agents analyze performance, reliability, architecture, and cost"
+argument-hint: "[scope: path or concern]"
+allowed-tools:
+  - Read
+  - Write
+  - Edit
+  - Glob
+  - Grep
+  - Bash
+  - Task
+  - WebSearch
+  - WebFetch
+  - ToolSearch
+---
+
+# Legion Dev Analyze
+
+Standalone code optimization scan. Dispatches 6 parallel agents to find bottlenecks, reliability issues, architecture smells, and cost optimization opportunities. Analysis only — no implementation.
+
+## Execution
+
+Follow the workflow at @~/.claude/legion/workflows/dev/analyze.md
+
+### Quick Reference
+
+**Initialization**: @~/.claude/legion/workflows/core/init.md
+**Context Loading**: @~/.claude/legion/workflows/core/context-load.md
+**Completion**: @~/.claude/legion/workflows/core/completion.md
+**Agent Map**: @~/.claude/legion/references/dev/agent-map.md
+
+### Scope Parameter
+
+| Usage | What it scans |
+|-------|--------------|
+| `/legion:dev:analyze` | Entire project |
+| `/legion:dev:analyze src/api/` | Specific directory |
+| `/legion:dev:analyze "database performance"` | Specific concern across codebase |
+
+### Parallel Agents
+
+| Agent | Focus | Model |
+|-------|-------|-------|
+| opt-perf-hotpaths | CPU/memory bottlenecks, hot code paths | sonnet |
+| opt-db-queries | N+1 queries, missing indexes, ORM anti-patterns | sonnet |
+| opt-io-network | Timeouts, retry logic, batching, compression | opus |
+| opt-memory-gc | Memory leaks, allocations, cache sizing | opus |
+| opt-arch-smells | Circular deps, layer violations, duplication | opus |
+| opt-infra-cost | Over-provisioning, autoscaling, log/storage costs | opus |
+
+### Output
+
+- `OPTIMIZATION_REPORT.md` — Full analysis with top-10 findings, categorized issues, recommendations
+- `SUMMARY.md` — Quick overview with key findings and quick wins
+
+### Follow-Up
+
+To implement findings:
+- `/legion:dev:cycle "Implement optimization: {finding}"` — for complex changes
+- `/legion:dev:quick "Fix: {quick win}"` — for simple improvements

package/commands/legion/dev/cycle.md

@@ -0,0 +1,60 @@
+---
+name: legion:dev:cycle
+description: "Full Dev pipeline — 9-stage cycle: architect → code-analyst → task-designer → plan → implement → verify → review → post-analyze → brief"
+argument-hint: "<task description>"
+allowed-tools:
+  - Read
+  - Write
+  - Edit
+  - Glob
+  - Grep
+  - Bash
+  - Task
+  - WebSearch
+  - WebFetch
+  - ToolSearch
+---
+
+# Legion Dev Cycle
+
+Run the complete Dev pipeline in one command with approval checkpoints.
+
+## Execution
+
+Follow the workflow at @~/.claude/legion/workflows/dev/cycle.md
+
+### Quick Reference
+
+**Initialization**: @~/.claude/legion/workflows/core/init.md
+**Context Loading**: @~/.claude/legion/workflows/core/context-load.md
+**Completion**: @~/.claude/legion/workflows/core/completion.md
+**Agent Map**: @~/.claude/legion/references/dev/agent-map.md
+
+### Pipeline Stages
+
+| Stage | Role | Model | What it does | Checkpoint |
+|-------|------|-------|-------------|------------|
+| 1. Architect | general-purpose | opus | Maps repo structure, boundaries, conventions, infra touchpoints | — |
+| 2. Code Analyst | general-purpose | sonnet | Traces call graphs, data flows, external deps, test coverage | — |
+| 3. Task Designer | general-purpose | opus | Designs solution options, contracts, migrations, security | ✓ User approval |
+| 4. Planner | delivery-planner | sonnet | Decomposes design into ordered tasks with deps and rollback | ✓ User approval |
+| 5. Implementer | general-purpose | opus | Writes code, configs, infra changes per plan | — |
+| 6. Verifier | general-purpose | sonnet | Runs tests, lint, IaC validation | — |
+| 7. Reviewer | general-purpose | sonnet | Reviews arch fit, code quality, security, ops, API compat | — |
+| 8. Post-Analyze | general-purpose | sonnet | Finds perf bottlenecks, DB issues, arch smells, cost optimizations | — |
+| 9. Brief Writer | general-purpose | opus | Produces SUMMARY.md, updates codebase docs | — |
+
+### Checkpoints
+
+After stages 3 (task-designer) and 4 (planner), the workflow pauses and asks the user to confirm. Options:
+- **Approve** — continue to next stage
+- **Revise** — re-run the stage with feedback
+- **Stop** — save progress and exit (resume with `/legion:resume`)
+
+### Pipeline Flow
+
+```
+[architect] → [code-analyst] → [task-designer] ──checkpoint──►
+[planner] ──checkpoint──► [implementer] → [verifier] →
+[reviewer] → [post-analyze] → [brief-writer]
+```

package/commands/legion/dev/quick.md

@@ -0,0 +1,59 @@
+---
+name: legion:dev:quick
+description: "Fast context-aware Dev task execution — reads .legion/codebase/, analyzes impact, implements with auto-escalation to cycle for complex tasks"
+argument-hint: "<task description>"
+allowed-tools:
+  - Read
+  - Write
+  - Edit
+  - Glob
+  - Grep
+  - Bash
+  - Task
+  - WebSearch
+  - WebFetch
+  - ToolSearch
+---
+
+# Legion Dev Quick
+
+Fast context-aware execution for development tasks. Reads project context, analyzes impact, implements, and verifies — with auto-escalation to full cycle when complexity is detected.
+
+## Execution
+
+Follow the workflow at @~/.claude/legion/workflows/dev/quick.md
+
+### Quick Reference
+
+**Initialization**: @~/.claude/legion/workflows/core/init.md
+**Context Loading**: @~/.claude/legion/workflows/core/context-load.md
+**Completion**: @~/.claude/legion/workflows/core/completion.md
+**Agent Map**: @~/.claude/legion/references/dev/agent-map.md
+
+### Pipeline (Shortened)
+
+| Step | Agent | Model | What it does |
+|------|-------|-------|-------------|
+| 1. Quick Analysis | 4 parallel agents | opus/sonnet | Context, locations, impact, verify plan |
+| 2. Escalation Check | orchestrator | — | Detects complex scope, asks user |
+| 3. Planner-Lite | delivery-planner | sonnet | 3-7 step compact plan |
+| 4. Implement | general-purpose | opus | Execute plan step by step |
+| 5. Verify-Lite | general-purpose | sonnet | Run tests + lint on changed files |
+| 6. Brief | general-purpose | opus | SUMMARY.md + codebase update |
+
+### Auto-Escalation Triggers
+
+If the impact analysis detects any of these, the workflow suggests switching to `/legion:dev:cycle`:
+- Auth/security/permissions changes
+- Database migrations
+- Infrastructure/CI/CD changes
+- Public API contract changes
+- Wide cascading impact (>5 files across >2 modules)
+
+The user always decides — no automatic escalation.
+
+### Key Rules
+- ALWAYS read .legion/codebase/ before starting
+- If task is unclear, ASK the user
+- Pass full context summary to spawned agents
+- Update STATE.md after completion

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "legion-cc",
-  "version": "0.8.0",
+  "version": "0.10.0",
   "description": "Legion — multi-agent orchestration framework for Claude Code",
   "type": "commonjs",
   "main": "bin/legion-tools.cjs",

package/references/agent-routing.md

@@ -10,6 +10,54 @@ Legion commands invoke specialized agents via the Task tool. Each domain defines
 2. **Pipeline**: Previous stage determines next agent (architect → planner → executor)
 3. **Auto-classify**: `/legion:devops:quick` analyzes the task and routes automatically
 
+## Complexity-Based Routing
+
+The orchestrator scores each task's complexity (1-10) and selects the optimal pipeline depth:
+
+### Complexity Score → Pipeline Mapping
+
+| Score | Pipeline | Description | Typical Agent Count |
+|-------|----------|-------------|-------------------|
+| 1-3 | `quick` | Fast path — single-round parallel agents, no checkpoints | 4-6 agents |
+| 4-6 | `partial` | Key stages only — architect → plan → implement → verify | 8-12 agents |
+| 7-10 | `full` | All pipeline stages with checkpoints | 15-25+ agents |
+
+### Scoring Algorithm
+
+```
+score = 0
+score += files_affected_score    // 1 file=1, 2-5 files=3, 6+ files=5
+score += module_boundary_score   // 0 boundaries=0, 1=2, 2+=4
+score += risk_factor_score       // auth/security=+3, DB migration=+3, infra/CI-CD=+2, public API=+2
+score = min(score, 10)           // cap at 10
+```
+
+### Auto-Escalation Rules
+
+When `quick` workflow detects complexity above threshold during execution:
+- Trigger detection in analysis round → suggest escalation to user
+- User chooses: continue quick (accept risk) / escalate to partial / escalate to full
+- NEVER auto-escalate without user confirmation
+
+### Pipeline Stage Selection (Partial)
+
+For `partial` pipeline (score 4-6), select stages based on task classification:
+
+**DevOps domain:**
+| Classification | Stages |
+|---------------|--------|
+| architecture | architect → (checkpoint) |
+| planning | architect → plan → (checkpoint) |
+| execution | architect → execute → validate |
+| review | architect → review |
+
+**Dev domain:**
+| Score | Stages |
+|-------|--------|
+| 4 | architect → implement → verify |
+| 5 | architect → plan → implement → verify |
+| 6 | architect → plan → implement → verify → review |
+
 ## DevOps Domain Agent Map
 
 | Pipeline Stage | Agent Name | subagent_type | Model | File |
@@ -71,6 +119,8 @@ When a workflow stage supports sub-agent decomposition:
 
 ### Collapse Strategies
 
+> **Note:** Collapse strategies apply WITHIN each pipeline stage. Complexity-based routing (see `## Complexity-Based Routing`) determines WHICH stages run; collapse strategies determine HOW agents are allocated inside a given stage.
+
 | Budget | Strategy | Description |
 |--------|----------|-------------|
 | 1 | monolith | Single agent, blueprint as checklist |