@sulhadin/orchestrator 3.1.5 → 4.0.0-beta

package/README.md

@@ -4,7 +4,7 @@ AI team orchestration for [Claude Code](https://docs.anthropic.com/en/docs/claud
 
 ## What is Orchestra?
 
-Orchestra turns a single Claude Code session into a coordinated development team. A Product Manager plans features, a Conductor orchestrates them — delegating each phase to a sub-agent with the right role (backend, frontend, architect). Sub-agents own implementation and verification; conductor owns commits. Each role has strict boundaries, every commit passes verification, and the system learns from past milestones.
+Orchestra turns a single Claude Code session into a coordinated development team. A Product Manager plans features, a Lead assembles the right team — deriving sub-agent identity dynamically from phase content and delegating each phase. Sub-agents own implementation and verification; lead owns commits. Each role has strict boundaries, every commit passes verification, and the system learns from past milestones.
 
 No infrastructure. No API keys. Just markdown files and Claude Code.
 
@@ -31,15 +31,14 @@ Both options use the same commands: `/orchestra:pm`, `/orchestra:start`, etc.
 ## How It Works
 
 ```
-Terminal 1 (PM):                    Terminal 2 (Conductor):
+Terminal 1 (PM):                    Terminal 2 (Lead):
   /orchestra pm                       /orchestra start
   │                                   │
   ├─ Discuss features                 ├─ Scan milestones
-  ├─ Create milestones                ├─ Delegate to architect → RFC
-  ├─ Groom phases                     ├─ Delegate to backend → code + tests
-  │                                   ├─ Delegate to frontend → UI
-  │  (plan M2 while M1 runs)          ├─ Call reviewer → code review
-  │                                   ├─ Push → milestone done
+  ├─ Create milestones                ├─ Design phase → RFC
+  ├─ Groom phases                     ├─ Delegate to sub-agents → code + tests
+  │                                   ├─ Call reviewer → code review
+  │  (plan M2 while M1 runs)          ├─ Push → milestone done
   │                                   └─ Stop (inline) or next milestone (agent)
 ```
 
@@ -56,10 +55,10 @@ PM challenges scope, creates M1-user-auth with 3 phases
 ```
 /orchestra start
 📋 Starting M1-user-auth
-🏗️ architect → RFC ready → user approves
-⚙️ backend → phase-1: DB schema → committed
-⚙️ backend → phase-2: API endpoints → committed
-🎨 frontend → phase-3: Login UI → committed
+🏗️ design → RFC ready → user approves
+⚙️ phase-1: DB schema → committed
+⚙️ phase-2: API endpoints → committed
+⚙️ phase-3: Login UI → committed
 🔍 reviewer → approved
 ✅ M1-user-auth done. Pushed to origin.
 ```
@@ -85,10 +84,6 @@ PM challenges scope, creates M1-user-auth with 3 phases
 | Command | Role |
 |---------|------|
 | `/orchestra pm` | Product Manager — plan and orchestrate |
-| `/orchestra backend` | Backend Engineer — code + tests |
-| `/orchestra frontend` | Frontend Engineer — UI + design |
-| `/orchestra architect` | Architect — technical design |
-| `/orchestra adaptive` | Adaptive expert — any domain (iOS, DevOps, ML...) |
 | `/orchestra orchestrator` | System maintenance |
 
 ## Architecture
@@ -96,7 +91,7 @@ PM challenges scope, creates M1-user-auth with 3 phases
 ```
 .claude/                                ← Claude Code integration
 ├── agents/
-│   ├── conductor.md                    ← Autonomous milestone executor
+│   ├── lead.md                         ← Autonomous milestone executor
 │   └── reviewer.md                     ← Independent code review
 ├── skills/*.orchestra.md               ← 14 domain checklists
 ├── rules/*.orchestra.md                ← Discipline rules (auto-loaded)
@@ -104,9 +99,8 @@ PM challenges scope, creates M1-user-auth with 3 phases
 
 .orchestra/                             ← Project data + config
 ├── config.yml                          ← Pipeline settings (customize per stack)
-├── roles/                              ← Role identities
+├── roles/                              ← Role identities (orchestrator, product-manager)
 ├── blueprints/                         ← Project templates
-├── knowledge.md                        ← Project knowledge log
 └── milestones/                         ← Your work
 ```
 
@@ -122,12 +116,10 @@ PM challenges scope, creates M1-user-auth with 3 phases
 
 **Verification gate** — Tests + lint must pass before every commit. Commands come from config. Fails 3 times → phase marked failed, escalated to user.
 
-**14 built-in skills** — Domain checklists for auth, CRUD, deployment, accessibility, React, testing, debugging, and more. PM assigns to phases, conductor loads them automatically.
+**14 built-in skills** — Domain checklists for auth, CRUD, deployment, accessibility, React, testing, debugging, and more. PM assigns to phases, lead loads them automatically.
 
 **Blueprints** — Start from templates instead of scratch. `saas-starter` creates 5 milestones instantly. `blueprint add` saves your work as a reusable template.
 
-**Learning system** — `knowledge.md` accumulates decisions and lessons. 5-line retrospective after each milestone. PM reads before grooming new work. System gets smarter over time.
-
 **Role boundaries** — Enforced via `.claude/rules/`. PM cannot write code. Engineers cannot modify system files. Orchestrator cannot write features. Boundaries checked by file path, not by words.
 
 **Milestone isolation** — `inline` mode stops after each milestone (user compacts manually). `agent` mode spawns each milestone in its own sub-agent — context freed automatically, enabling 20+ milestones in a single `--auto` session.
@@ -150,7 +142,6 @@ Smart merge on upgrade:
 | Blueprints (template) | Updated |
 | Blueprints (your custom) | Preserved |
 | milestones/ | Untouched |
-| knowledge.md | Preserved |
 | config.yml | Smart merged (user values preserved, new keys added) |
 
 ## Documentation
@@ -159,7 +150,7 @@ Full docs at [docs/](https://github.com/sulhadin/orchestrator/blob/main/docs/REA
 
 - [Getting Started](https://github.com/sulhadin/orchestrator/blob/main/docs/getting-started.md) — installation, first milestone, two-terminal model
 - [Commands](https://github.com/sulhadin/orchestrator/blob/main/docs/commands.md) — all commands with examples
-- [Roles](https://github.com/sulhadin/orchestrator/blob/main/docs/roles.md) — 6 roles + adaptive, responsibilities, boundaries
+- [Roles](https://github.com/sulhadin/orchestrator/blob/main/docs/roles.md) — roles, responsibilities, boundaries
 - [Features](https://github.com/sulhadin/orchestrator/blob/main/docs/features.md) — config, verification, skills, blueprints, and more
 - [Blueprints](https://github.com/sulhadin/orchestrator/blob/main/docs/blueprints.md) — project templates, customization
 - [Skills](https://github.com/sulhadin/orchestrator/blob/main/docs/skills.md) — domain checklists, creating new skills

package/bin/build-template.js

@@ -42,7 +42,6 @@ const SYSTEM_PATHS = [
   { src: ".orchestra/roles", dest: ".orchestra/roles" },
   { src: ".orchestra/blueprints", dest: ".orchestra/blueprints" },
   { src: ".orchestra/config.yml", dest: ".orchestra/config.yml" },
-  { src: ".orchestra/knowledge.md", dest: ".orchestra/knowledge.md" },
   { src: ".orchestra/README.md", dest: ".orchestra/README.md" },
   { src: "CLAUDE.md", dest: "CLAUDE.md" }
 ];

package/bin/index.js

@@ -355,21 +355,6 @@ function run() {
       }
     }
 
-    // knowledge.md
-    const knowledgePath = path.join(orchestraDest, "knowledge.md");
-    const knowledgeBackup = path.join(targetDir, ".orchestra-backup-knowledge.md");
-    let hasKnowledge = false;
-    if (fs.existsSync(knowledgePath)) {
-      const content = fs.readFileSync(knowledgePath, "utf-8");
-      const marker = "<!-- New entries go here";
-      const idx = content.indexOf(marker);
-      if (idx !== -1 && content.slice(idx + marker.length).trim().length > 10) {
-        fs.copyFileSync(knowledgePath, knowledgeBackup);
-        hasKnowledge = true;
-        console.log("  [~] Backed up knowledge.md");
-      }
-    }
-
     // config.yml (user may have customized)
     const configPath = path.join(orchestraDest, "config.yml");
     const configBackup = path.join(targetDir, ".orchestra-backup-config.yml");
@@ -392,7 +377,7 @@ function run() {
         // Only remove orchestra files, keep user's custom agents/commands
         const files = fs.readdirSync(dirPath);
         for (const file of files) {
-          if (file === "conductor.md" || file === "reviewer.md" || file === "orchestra") {
+          if (file === "conductor.md" || file === "lead.md" || file === "reviewer.md" || file === "orchestra") {
             const fullPath = path.join(dirPath, file);
             if (fs.statSync(fullPath).isDirectory()) {
               rmDirRecursive(fullPath);
@@ -441,13 +426,6 @@ function run() {
       rmDirRecursive(backupPath);
     }
 
-    // Restore knowledge.md
-    if (hasKnowledge && fs.existsSync(knowledgeBackup)) {
-      fs.copyFileSync(knowledgeBackup, path.join(orchestraDest, "knowledge.md"));
-      fs.unlinkSync(knowledgeBackup);
-      console.log("  [+] Restored knowledge.md");
-    }
-
     // Merge config.yml: new template keys added, user values preserved
     if (hasConfig && fs.existsSync(configBackup)) {
       const userConfig = fs.readFileSync(configBackup, "utf-8");

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sulhadin/orchestrator",
-  "version": "3.1.5",
+  "version": "4.0.0-beta",
   "description": "AI Team Orchestration System — multi-role coordination for Claude Code",
   "bin": "bin/index.js",
   "scripts": {

package/template/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "orchestra",
   "description": "AI Team Orchestration — multi-role coordination with milestones, phases, and quality gates for Claude Code",
-  "version": "3.1.5",
+  "version": "4.0.0-beta",
   "author": {
     "name": "Sulhadin Öney"
   },

package/template/.orchestra/README.md

@@ -1,21 +1,20 @@
 # Orchestra — AI Team Orchestration
 
 A milestone-based orchestration system for coordinating AI agent sessions
-working on the same codebase. Two terminals: PM plans, conductor executes.
+working on the same codebase. Two terminals: PM plans, lead executes.
 
 ## How It Works
 
 ```
-Terminal 1 (PM):                    Terminal 2 (Conductor):
+Terminal 1 (PM):                    Terminal 2 (Lead):
   /orchestra pm                      /orchestra start
   │                                  │
   ├─ Discuss features with user      ├─ Scan milestones
-  ├─ Create milestones               ├─ 🏗️ delegate to architect → RFC
+  ├─ Create milestones               ├─ 🏗️ design phase → RFC
   ├─ Groom phases                    ├─ 🚦 User approves RFC
-  ├─ Always available                ├─ ⚙️ delegate to backend → phase by phase
-  │                                  ├─ 🎨 delegate to frontend → phase by phase
-  │  (can plan M2 while M1 runs)     ├─ 🔍 reviewer → review commits
-  │                                  ├─ git push → milestone done
+  ├─ Always available                ├─ ⚙️ delegate to sub-agent → phase by phase
+  │                                  ├─ 🔍 reviewer → review commits
+  │  (can plan M2 while M1 runs)     ├─ git push → milestone done
   │                                  └─ Stop (inline) or next milestone (agent)
 ```
 
@@ -26,21 +25,16 @@ Terminal 1 (PM):                    Terminal 2 (Conductor):
 ├── README.md              # This file
 ├── roles/                 # Role identities (one file per role)
 │   ├── product-manager.md
-│   ├── architect.md
-│   ├── backend-engineer.md
-│   ├── frontend-engineer.md
-│   ├── adaptive.md
 │   └── orchestrator.md
 ├── config.yml             # Pipeline settings, thresholds, verification commands
 ├── blueprints/            # Project/component milestone templates
-├── knowledge.md           # Append-only project knowledge log
 ├── milestones/            # Feature work (one dir per feature)
 │   └── M1-feature-name/
 │       ├── prd.md         # Product requirements (PM writes)
 │       ├── milestone.md   # Summary, acceptance criteria, status
 │       ├── grooming.md    # Discussion, scope, decisions
-│       ├── rfc.md         # Technical design (architect fills)
-│       ├── context.md     # Running log (conductor maintains for resume)
+│       ├── rfc.md         # Technical design (lead fills during design phase)
+│       ├── context.md     # Running log (lead maintains for resume)
 │       └── phases/        # Sequential units of work
 │           ├── phase-1.md
 │           └── ...
@@ -51,12 +45,12 @@ Terminal 1 (PM):                    Terminal 2 (Conductor):
 ### Terminal 1: `/orchestra pm` (Planning)
 
 PM is always available for discussion. Creates milestones, never writes code.
-You can plan new milestones while the conductor is executing another one.
+You can plan new milestones while the lead is executing another one.
 
 ### Terminal 2: `/orchestra start` (Execution)
 
-Conductor reads milestones, delegates each phase to a sub-agent with the right role.
-Sub-agents implement + verify; conductor commits. After milestone completion, behavior
+Lead reads milestones, derives the right team member identity from phase content, and delegates each phase to a sub-agent.
+Sub-agents implement + verify; lead commits. After milestone completion, behavior
 depends on `milestone_isolation` config: stops (inline) or continues to next (agent).
 Maintains `context.md` for resume capability.
 
@@ -76,14 +70,12 @@ PM discusses feature with user
   → PM plans scope, phases, acceptance criteria
   → [USER APPROVAL GATE: Milestone creation]
   → PM creates milestone (status: planning)
-  → Conductor activates architect: writes RFC + validates grooming
+  → Lead runs design phase: writes RFC + validates grooming
   → [USER APPROVAL GATE: RFC + grooming validation → Implementation]
-  → Conductor executes backend phases (sequential, each → commit)
-  → Conductor executes frontend phases (sequential, each → commit)
-  → Conductor calls reviewer agent (reviews unpushed commits)
+  → Lead delegates phases to sub-agents (sequential, each → commit)
+  → Lead calls reviewer agent (reviews unpushed commits)
   → FIX cycle if changes-requested (re-review if fix >= 30 lines)
-  → Conductor pushes, PM verifies acceptance criteria, closes milestone
-  → Conductor appends 5-line retrospective to knowledge.md
+  → Lead pushes, PM verifies acceptance criteria, closes milestone
 
 Hotfix (production bugs):
   /orchestra hotfix {description}
@@ -93,8 +85,8 @@ Hotfix (production bugs):
 
 ### Milestone Lock
 
-Conductor claims a milestone by writing `Locked-By: {timestamp}` to milestone.md before execution.
-Other conductors skip locked milestones. Lock expires after config.yml `thresholds.milestone_lock_timeout` minutes (default 120).
+Lead claims a milestone by writing `Locked-By: {timestamp}` to milestone.md before execution.
+Other leads skip locked milestones. Lock expires after config.yml `thresholds.milestone_lock_timeout` minutes (default 120).
 
 ### Pipeline Modes (Complexity)
 
@@ -105,18 +97,18 @@ PM sets `Complexity` on milestone (pipeline) and `complexity` on each phase (mod
 | `trivial` | Haiku | Phases → Commit → Push | Version bumps, env vars, config changes |
 | `quick` | Sonnet | Phases → Commit → Push (skip review) | Single-file fixes, simple CRUD |
 | `standard` | Sonnet | Phases → Review → Push | Typical features, clear requirements |
-| `complex` | Opus | Architect → Phases → Review → Push | New subsystems, unfamiliar territory |
+| `complex` | Opus | Design → Phases → Review → Push | New subsystems, unfamiliar territory |
 
 Defaults: config.yml `pipeline.default_pipeline` and `pipeline.default_complexity`.
 
 ### Milestone Isolation
 
-Config `pipeline.milestone_isolation` controls how the conductor handles multiple milestones:
+Config `pipeline.milestone_isolation` controls how the lead handles multiple milestones:
 
 | Mode | Behavior | Best for |
 |------|----------|----------|
-| `inline` (default) | Conductor runs milestone directly, **stops** after completion. User runs `/compact` then `/orchestra start` for next milestone. | Manual sessions, PC-based work |
-| `agent` | Conductor spawns a sub-agent per milestone. Context freed automatically after each. Loops to next milestone. | `--auto` overnight batch runs |
+| `inline` (default) | Lead runs milestone directly, **stops** after completion. User runs `/compact` then `/orchestra start` for next milestone. | Manual sessions, PC-based work |
+| `agent` | Lead spawns a sub-agent per milestone. Context freed automatically after each. Loops to next milestone. | `--auto` overnight batch runs |
 
 ```
 Inline mode:                          Agent mode:
@@ -129,7 +121,7 @@ Inline mode:                          Agent mode:
 
 In agent mode, the delegation is two-tier:
 ```
-Conductor (lean dispatcher)
+Lead (lean dispatcher)
   └── Milestone Agent (fresh context)
         └── Phase Agent (unchanged)
 ```
@@ -148,7 +140,7 @@ Conductor (lean dispatcher)
 | Status | Meaning |
 |--------|---------|
 | `pending` | Not yet started |
-| `in-progress` | Conductor is executing |
+| `in-progress` | Lead is executing |
 | `done` | Completed and committed |
 | `failed` | Execution failed — needs retry or manual intervention |
 
@@ -158,18 +150,17 @@ Conductor (lean dispatcher)
 
 Phases always execute in this order:
 
-1. **Architect** (RFC) — if technical design is needed
-2. **Backend phases** — always before frontend
-3. **Frontend phases** — after backend is done
-4. **Reviewer** — reviews all unpushed commits
+1. **Design** (RFC) — if technical design is needed
+2. **Implementation phases** — lead derives sub-agent identity from phase scope
+3. **Reviewer** — reviews all unpushed commits
 
-Within each domain (backend/frontend), phases run in order: phase-1 → phase-2 → phase-3.
+Phases run in order: phase-1 → phase-2 → phase-3.
 
 **Parallel execution:** If PM sets `depends_on` in phase frontmatter, independent phases
 can run in parallel via subagent worktree isolation. No `depends_on` = sequential (default).
 
 **Verification Gate:** Sub-agents run typecheck + tests + lint (from config.yml) before reporting.
-Conductor NEVER commits unless verification passes.
+Lead NEVER commits unless verification passes.
 
 ---
 
@@ -212,14 +203,14 @@ Rules:
 
 The user must approve before these transitions:
 - **Milestone creation** — PM discusses and plans, but must get user approval before creating the milestone directory and files
-- **RFC → Implementation** — user reviews architect's RFC (if `rfc_approval` is not `skip`)
+- **RFC → Implementation** — user reviews design RFC (if `rfc_approval` is not `skip`)
 
 Push is automatic after review passes. All other transitions are automatic.
 
 ### Rejection Handling
 
 If the user says **no** at any gate:
-- **RFC rejected** → Architect revises based on feedback, re-submits (max config `pipeline.max_rfc_rounds`)
+- **RFC rejected** → Lead revises based on feedback, re-submits (max config `pipeline.max_rfc_rounds`)
 - **Milestone rejected** → PM revises in PM terminal
 
 Rejections are normal. The system does not stall — it loops back with feedback.
@@ -228,13 +219,13 @@ Rejections are normal. The system does not stall — it loops back with feedback
 
 ## Review Flow (Git-Native)
 
-Reviewer is a separate agent called by the conductor. Review is based on **unpushed commits**.
+Reviewer is a separate agent called by the lead. Review is based on **unpushed commits**.
 
 ```
-Conductor calls reviewer agent
+Lead calls reviewer agent
   → Reviewer runs: git log origin/{branch}..HEAD
   → Reviewer runs: git diff origin/{branch}...HEAD
-  → Reviewer applies full checklist (backend or frontend mode)
+  → Reviewer applies full checklist
   → Returns: approved / approved-with-comments / changes-requested
 ```
 
@@ -242,7 +233,7 @@ Conductor calls reviewer agent
 
 **If approved-with-comments** → push immediately. Comments are logged in context.md.
 
-**If changes-requested** → Conductor continues the phase's sub-agent via SendMessage with
+**If changes-requested** → Lead continues the phase's sub-agent via SendMessage with
 reviewer findings. Re-review triggered if fix >= config `re_review_lines` threshold.
 
 ---
@@ -260,7 +251,7 @@ No role may create, edit, delete, or modify these files:
 - `.orchestra/roles/*.md`
 - `.orchestra/config.yml`
 - `.orchestra/blueprints/`
-- `.claude/agents/conductor.md`, `.claude/agents/reviewer.md`
+- `.claude/agents/lead.md`, `.claude/agents/reviewer.md`
 - `.claude/rules/*.orchestra.md`
 - `.claude/skills/*/SKILL.md`
 - `.claude/commands/orchestra/`
@@ -278,9 +269,7 @@ No role may create, edit, delete, or modify these files:
 |---------------|-----------------|
 | Orchestrator | Write feature code, RFCs, design specs, review code, create milestones |
 | Product Manager | Write code, fix bugs, run tests, create design specs, modify system files |
-| Architect | Write feature code, implement endpoints, fix bugs, write tests |
-| Backend Engineer | Write RFCs, design UI, review your own code, make product decisions |
-| Frontend Engineer | Modify backend code, write RFCs, review your own code |
+| Sub-agents | Write outside phase `## Scope`, modify system files, review your own code |
 
 ## File Ownership Rules
 
@@ -288,38 +277,35 @@ Each role has exclusive write access to specific directories:
 
 | Role | Owns (can write) | Reads |
 |------|-------------------|-------|
-| orchestrator | `.orchestra/roles/*`, `.orchestra/config.yml`, `.orchestra/README.md`, `.orchestra/blueprints/`, `CLAUDE.md`, `.claude/agents/`, `.claude/skills/*/SKILL.md`, `.claude/rules/*.orchestra.md`, `.claude/commands/orchestra/`, `.orchestra/knowledge.md`, `docs/` | Everything |
+| orchestrator | `.orchestra/roles/*`, `.orchestra/config.yml`, `.orchestra/README.md`, `.orchestra/blueprints/`, `CLAUDE.md`, `.claude/agents/`, `.claude/skills/*/SKILL.md`, `.claude/rules/*.orchestra.md`, `.claude/commands/orchestra/`, `docs/` | Everything |
 | product-manager | `.orchestra/milestones/*` (prd.md, milestone.md, grooming.md, phases) | Everything |
-| architect | `.orchestra/milestones/*/rfc.md`, `.orchestra/milestones/*/architecture.md`, `.orchestra/milestones/*/adrs/*`, project configs | Everything |
-| backend-engineer | Defined by PM in phase scope (typically `src/`, `tests/`, `migrations/`) | `.orchestra/milestones/*/phases/*` |
-| frontend-engineer | Defined by PM in phase scope (typically `frontend/`, `app/`) | `.orchestra/milestones/*/phases/*` |
-| adaptive | Defined by `scope:` field in phase file — dynamic per phase | `.orchestra/milestones/*/phases/*` |
-| conductor (all roles) | `.orchestra/milestones/*/context.md`, `.orchestra/knowledge.md` (append only) | Everything in active milestone |
+| sub-agents | Only what phase `## Scope` defines — dynamic per phase | `.orchestra/milestones/*/phases/*` |
+| lead | `.orchestra/milestones/*/context.md` | Everything in active milestone |
 
 ---
 
-## PM ↔ Conductor Communication
+## PM ↔ Lead Communication
 
-PM and conductor run in **separate terminals**. They communicate through milestone files:
+PM and lead run in **separate terminals**. They communicate through milestone files:
 
 - **PM writes:** prd.md, grooming.md, milestone.md, phase files
-- **Conductor reads:** milestone files → executes phases → updates results + context.md
-- **No direct messaging** between PM and conductor — file system is the interface
+- **Lead reads:** milestone files → executes phases → updates results + context.md
+- **No direct messaging** between PM and lead — file system is the interface
 
 ### Context Persistence
 
-Conductor maintains `context.md` in each milestone directory with a fixed structure:
+Lead maintains `context.md` in each milestone directory with a fixed structure:
 - `## Status` — milestone id, start date, pipeline type
 - `## Phases` — per-phase status, commit hash, files changed, errors
 - `## Codebase Map` — scout-generated file map (survives milestone clear)
 - `## Decisions` — key choices from each phase that affect later phases
 - `## Metrics` — phase duration and verification retries (used by `/orchestra status`)
 
-This enables resume after terminal close/reopen. On restart, conductor reads context.md and skips completed phases.
+This enables resume after terminal close/reopen. On restart, lead reads context.md and skips completed phases.
 
-### Approval Gates (Conductor Terminal)
+### Approval Gates (Lead Terminal)
 
-Conductor asks the user directly (not PM) at this point:
+Lead asks the user directly (not PM) at this point:
 1. **RFC ready** — "Approve RFC to start implementation?" (if `rfc_approval` is not `skip`)
 
 Push is automatic after review passes — no approval needed.
@@ -334,7 +320,7 @@ Push is automatic after review passes — no approval needed.
 sequenceDiagram
     actor U as User
     participant PM as Terminal 1: PM
-    participant C as Terminal 2: Conductor
+    participant C as Terminal 2: Lead
 
     U->>PM: "I want user auth"
     PM->>PM: Discuss, plan, create milestone
@@ -342,16 +328,12 @@ sequenceDiagram
     U->>C: /orchestra start
     C->>C: Read milestone files
 
-    C->>C: architect → write RFC
+    C->>C: design phase → write RFC
     C->>U: Approve RFC?
     U->>C: Yes
 
-    loop Each backend phase
-        C->>C: backend → phase-N → commit
-    end
-
-    loop Each frontend phase
-        C->>C: frontend → phase-N → commit
+    loop Each phase
+        C->>C: sub-agent → phase-N → commit
     end
 
     C->>C: reviewer agent → review commits
@@ -371,11 +353,11 @@ sequenceDiagram
     Note over PM: PM is free the entire time<br/>Can plan M2 while M1 executes
 ```
 
-### 2. Conductor Execution Loop (Inline Mode)
+### 2. Lead Execution Loop (Inline Mode)
 
 ```mermaid
 sequenceDiagram
-    participant C as Conductor
+    participant C as Lead
 
     C->>C: Scan milestones/
     Note over C: M1: in-progress<br/>M2: planning<br/>M3: done
@@ -389,11 +371,11 @@ sequenceDiagram
     Note over C: STOP. "Run /compact or /clear then /orchestra start"
 ```
 
-### 3. Conductor Execution Loop (Agent Mode)
+### 3. Lead Execution Loop (Agent Mode)
 
 ```mermaid
 sequenceDiagram
-    participant C as Conductor
+    participant C as Lead
     participant MA as Milestone Agent
 
     C->>C: Scan milestones/

package/template/.orchestra/blueprints/README.md

@@ -9,7 +9,7 @@ set of milestones pre-groomed with phases, skills, and acceptance criteria.
 1. PM activates: `/orchestra blueprint saas-starter`
 2. PM reviews the generated milestones — customize as needed
 3. PM approves → milestones are created in `.orchestra/milestones/`
-4. Conductor executes with `/orchestra start`
+4. Lead executes with `/orchestra start`
 
 ## How to Customize
 
@@ -35,9 +35,9 @@ What this blueprint is for, what it produces.
 ### M1 — {title}
 - Complexity: {quick/standard/full}
 - Phases:
-  1. (backend) {description} [skills: {skill-list}]
-  2. (backend) {description}
-  3. (frontend) {description}
+  1. {description} [skills: {skill-list}]
+  2. {description}
+  3. {description}
 - Acceptance Criteria:
   - [ ] {criterion}
 
@@ -66,9 +66,9 @@ Use this whenever you need a new entity in your API.
 ### M{N} — {RESOURCE_NAME} CRUD
 - Complexity: standard
 - Phases:
-  1. (backend) DB schema + migration for {RESOURCE_NAME} [skills: crud-api]
-  2. (backend) CRUD endpoints + validation + tests [skills: crud-api]
-  3. (frontend) {RESOURCE_NAME} list + detail + form UI
+  1. DB schema + migration for {RESOURCE_NAME} [skills: crud-api]
+  2. CRUD endpoints + validation + tests [skills: crud-api]
+  3. {RESOURCE_NAME} list + detail + form UI
 - Acceptance Criteria:
   - [ ] All CRUD operations work
   - [ ] Input validation on all mutations

package/template/.orchestra/blueprints/api-only.md

@@ -9,8 +9,8 @@ and deployment pipeline. Ideal for microservices or API-first projects.
 ### M1 — Project Setup + Database
 - Complexity: standard
 - Phases:
-  1. (backend) Project skeleton — framework, configs, linting, structure
-  2. (backend) Database setup — ORM, connection, base migration [skills: deployment]
+  1. (impl) Project skeleton — framework, configs, linting, structure
+  2. (impl) Database setup — ORM, connection, base migration [skills: deployment]
 - Acceptance Criteria:
   - [ ] Project builds and runs locally
   - [ ] Database connection works
@@ -19,8 +19,8 @@ and deployment pipeline. Ideal for microservices or API-first projects.
 ### M2 — Authentication
 - Complexity: standard
 - Phases:
-  1. (backend) User model + auth endpoints [skills: auth-setup]
-  2. (backend) Auth middleware + API key support [skills: auth-setup]
+  1. (impl) User model + auth endpoints [skills: auth-setup]
+  2. (impl) Auth middleware + API key support [skills: auth-setup]
 - Acceptance Criteria:
   - [ ] Login, signup, token refresh work
   - [ ] Protected endpoints reject unauthenticated requests
@@ -29,8 +29,8 @@ and deployment pipeline. Ideal for microservices or API-first projects.
 ### M3 — Core API
 - Complexity: standard
 - Phases:
-  1. (backend) Core resource endpoints + validation [skills: crud-api]
-  2. (backend) Pagination, filtering, error handling [skills: crud-api]
+  1. (impl) Core resource endpoints + validation [skills: crud-api]
+  2. (impl) Pagination, filtering, error handling [skills: crud-api]
 - Acceptance Criteria:
   - [ ] All CRUD operations work
   - [ ] Consistent error format
@@ -39,7 +39,7 @@ and deployment pipeline. Ideal for microservices or API-first projects.
 ### M4 — CI/CD + Deploy
 - Complexity: quick
 - Phases:
-  1. (backend) Dockerfile + CI pipeline + health check [skills: deployment]
+  1. (impl) Dockerfile + CI pipeline + health check [skills: deployment]
 - Acceptance Criteria:
   - [ ] Docker build works
   - [ ] CI pipeline passes

package/template/.orchestra/blueprints/component-crud-resource.md

@@ -13,9 +13,9 @@ validation, frontend UI, and tests. Use whenever you need a new entity.
 ### M{N} — {RESOURCE_NAME} CRUD
 - Complexity: standard
 - Phases:
-  1. (backend) DB schema + migration for {RESOURCE_NAME} table [skills: crud-api]
-  2. (backend) {RESOURCE_NAME} CRUD endpoints + validation + tests [skills: crud-api]
-  3. (frontend) {RESOURCE_NAME} list view + detail view + create/edit form
+  1. (impl) DB schema + migration for {RESOURCE_NAME} table [skills: crud-api]
+  2. (impl) {RESOURCE_NAME} CRUD endpoints + validation + tests [skills: crud-api]
+  3. (impl) {RESOURCE_NAME} list view + detail view + create/edit form
 - Acceptance Criteria:
   - [ ] Create, read, update, delete operations work
   - [ ] Input validation on create and update