@sulhadin/orchestrator 3.1.4 → 4.0.0-beta

package/template/.orchestra/blueprints/saas-starter.md

@@ -9,9 +9,9 @@ API layer, dashboard UI, and deployment. Produces a working, deployed MVP.
 ### M1 — Project Setup + Database
 - Complexity: full
 - Phases:
-  1. (architect) Tech stack RFC — runtime, framework, DB, ORM, auth strategy
-  2. (backend) Project skeleton — monorepo/single, configs, linting, base structure
-  3. (backend) Database setup — ORM config, connection, base migration [skills: deployment]
+  1. (design) Tech stack RFC — runtime, framework, DB, ORM, auth strategy
+  2. (impl) Project skeleton — monorepo/single, configs, linting, base structure
+  3. (impl) Database setup — ORM config, connection, base migration [skills: deployment]
 - Acceptance Criteria:
   - [ ] Project builds and runs locally
   - [ ] Database connection works
@@ -21,11 +21,11 @@ API layer, dashboard UI, and deployment. Produces a working, deployed MVP.
 ### M2 — Authentication
 - Complexity: full
 - Phases:
-  1. (architect) Auth RFC — strategy, token flow, session management
-  2. (backend) User model + migration + auth endpoints [skills: auth-setup, crud-api]
-  3. (backend) Auth middleware + protected route pattern [skills: auth-setup]
-  4. (frontend) Login + signup pages + auth state management
-  5. (frontend) Protected route wrapper + logout flow
+  1. (design) Auth RFC — strategy, token flow, session management
+  2. (impl) User model + migration + auth endpoints [skills: auth-setup, crud-api]
+  3. (impl) Auth middleware + protected route pattern [skills: auth-setup]
+  4. (impl) Login + signup pages + auth state management
+  5. (impl) Protected route wrapper + logout flow
 - Acceptance Criteria:
   - [ ] User can sign up, log in, log out
   - [ ] Protected routes reject unauthenticated users
@@ -36,10 +36,10 @@ API layer, dashboard UI, and deployment. Produces a working, deployed MVP.
 ### M3 — Core API + Dashboard
 - Complexity: standard
 - Phases:
-  1. (backend) Core resource CRUD endpoints + validation [skills: crud-api]
-  2. (backend) Pagination, filtering, sorting on list endpoints [skills: crud-api]
-  3. (frontend) Dashboard layout — sidebar, header, responsive shell
-  4. (frontend) Core resource list + detail + create/edit forms
+  1. (impl) Core resource CRUD endpoints + validation [skills: crud-api]
+  2. (impl) Pagination, filtering, sorting on list endpoints [skills: crud-api]
+  3. (impl) Dashboard layout — sidebar, header, responsive shell
+  4. (impl) Core resource list + detail + create/edit forms
 - Acceptance Criteria:
   - [ ] CRUD operations work end-to-end
   - [ ] Dashboard is responsive (mobile + desktop)
@@ -49,9 +49,9 @@ API layer, dashboard UI, and deployment. Produces a working, deployed MVP.
 ### M4 — CI/CD + Deployment
 - Complexity: standard
 - Phases:
-  1. (backend) Dockerfile + docker-compose for local dev [skills: deployment]
-  2. (backend) CI pipeline — lint, type check, test, build [skills: deployment]
-  3. (backend) Health check endpoint + graceful shutdown [skills: deployment]
+  1. (impl) Dockerfile + docker-compose for local dev [skills: deployment]
+  2. (impl) CI pipeline — lint, type check, test, build [skills: deployment]
+  3. (impl) Health check endpoint + graceful shutdown [skills: deployment]
 - Acceptance Criteria:
   - [ ] `docker-compose up` starts full local environment
   - [ ] CI pipeline runs on every push
@@ -61,8 +61,8 @@ API layer, dashboard UI, and deployment. Produces a working, deployed MVP.
 ### M5 — Polish + Launch Readiness
 - Complexity: quick
 - Phases:
-  1. (frontend) Error boundaries, 404 page, loading skeletons
-  2. (backend) Rate limiting, request logging, error formatting
+  1. (impl) Error boundaries, 404 page, loading skeletons
+  2. (impl) Rate limiting, request logging, error formatting
 - Acceptance Criteria:
   - [ ] No unhandled errors in UI
   - [ ] API returns consistent error format

package/template/.orchestra/config.yml

@@ -23,7 +23,7 @@ pipeline:
   parallel: disabled
 
   # Milestone isolation mode: inline | agent
-  # inline: conductor runs milestones directly, stops after each. User compacts manually. (default)
+  # inline: lead runs milestones directly, stops after each. User compacts manually. (default)
   # agent: each milestone runs in its own sub-agent. Context freed automatically. Best for --auto.
   milestone_isolation: inline
 

package/template/.orchestra/roles/orchestrator.md

@@ -19,12 +19,11 @@ You are NOT above the system — you ARE the system.
 | Create/edit/delete role files | `.orchestra/roles/*.md` |
 | Edit config | `.orchestra/config.yml` |
 | Edit CLAUDE.md | `CLAUDE.md` |
-| Edit conductor/reviewer agents | `.claude/agents/conductor.md`, `.claude/agents/reviewer.md` |
+| Edit lead/reviewer agents | `.claude/agents/lead.md`, `.claude/agents/reviewer.md` |
 | Create/edit rules | `.claude/rules/*.orchestra.md` |
 | Create/edit skills | `.claude/skills/*/SKILL.md` |
 | Create/edit blueprints | `.orchestra/blueprints/*.md` |
 | Create/edit commands | `.claude/commands/orchestra/*.md` |
-| Edit knowledge log | `.orchestra/knowledge.md` |
 | Maintain documentation | `docs/*.md` |
 
 ## Cannot Do
@@ -41,7 +40,7 @@ When evolving the Orchestra system, follow this 6-phase process:
 3. **Challenge** — present, invite pushback, genuinely rethink, reach consensus
 4. **Plan** — exact files, line numbers, insertion order. ALWAYS preview first.
 5. **Implement** — task list, bottom-up, verify each change
-6. **Capture** — knowledge.md, docs/, cross-file consistency check
+6. **Capture** — docs/, cross-file consistency check
 
 **Phase 4 is NOT optional.** Always preview before implementing.
 

package/template/.orchestra/roles/product-manager.md

@@ -20,13 +20,7 @@ Cannot write: feature code, RFCs, architecture docs, review findings, system fil
 
 1. Read `.orchestra/config.yml` for pipeline settings
 2. Check `.orchestra/milestones/` for active milestones
-3. Check `.orchestra/knowledge.md` Active Knowledge for recent lessons
-4. Greet: "PM ready. What's on your mind?" + milestone status summary
-
-## Knowledge: Where to Save What You Learn
-
-- **knowledge.md** → project-level lessons (other roles read this)
-- **Auto memory** → personal behavior adjustments (only you read this)
+3. Greet: "PM ready. What's on your mind?" + milestone status summary
 
 ## Milestone Creation
 
@@ -45,7 +39,7 @@ Cannot write: feature code, RFCs, architecture docs, review findings, system fil
 ### Milestone Review Loop
 
 After creating milestone files, launch a milestone-reviewer sub-agent before
-marking the milestone as ready. This catches planning errors before conductor executes.
+marking the milestone as ready. This catches planning errors before lead executes.
 
 **Flow:** PM creates → reviewer sub-agent → PM fixes → reviewer again → max `pipeline.max_milestone_review_rounds`
 
@@ -57,15 +51,18 @@ in {milestone_path}/: prd.md, milestone.md, grooming.md, and all files in phases
 (rfc.md and context.md don't exist yet — don't flag them as missing.)
 
 ## Checklist
-1. Every phase has `role:` set?
-2. Every phase has `complexity:` set?
-3. Every phase has `skills:` appropriate for the role and task?
-4. Every phase has `scope:` defining which files/dirs to touch?
-5. Acceptance criteria are testable? (not vague like "works well" — specific like "returns 200")
-6. `milestone.md` has `Complexity:` set?
-7. Phase order and `depends_on` are correct? (frontend depends on backend, etc.)
-8. No overlapping scope between phases? (two phases writing same files)
-9. PRD explains WHY, not just WHAT?
+1. Every phase has `complexity:` set?
+2. Every phase has `skills:` appropriate for the task?
+3. Every phase has `## Scope` defining specific files/dirs to touch?
+4. Acceptance criteria are testable? (not vague like "works well" — specific like "returns 200")
+5. `milestone.md` has `Complexity:` set?
+6. Phase order and `depends_on` are correct?
+7. No overlapping scope between phases? (two phases writing same files)
+8. PRD explains WHY, not just WHAT?
+9. Every non-trivial phase has `## Context` explaining what the project is?
+10. Every non-trivial phase has `## Technical Decisions` with NO unresolved "X OR Y" choices?
+11. Standard+ phases have `## References` for technologies that may have changed since training cutoff?
+12. Standard+ phases have `## Constraints` with at least 2 negative scenarios?
 
 ## Return Format
 verdict: approved | changes-requested
@@ -99,19 +96,46 @@ summary: {2-3 sentences}
 
 ```markdown
 ---
-role: backend-engineer | frontend-engineer | architect | adaptive                                                                                                                                             
-status: pending | in-progress | done | failed                                                                                                                                                               
-order: 1                                                                                                                                                                                                      
-complexity: standard          # trivial | quick | standard | complex — conductor uses this for model selection                                                                                                          
-skills: []                    # list .claude/skills/, assign relevant ones by name
+status: pending
+order: 1
+complexity: standard          # trivial | quick | standard | complex
+skills: []                    # .claude/skills/ names
 depends_on: []
 ---
 
 ## Objective
+What this phase must accomplish. One paragraph, specific.
+
+## Context
+What is this project? Why does it exist? What does the user do with it?
+This grounds the implementer so they understand the bigger picture.
+Can reference prd.md for detail. (Optional for trivial complexity.)
+
+## Technical Decisions
+All technical choices resolved. NO "X or Y" — every decision is final.
+Include versions for all named technologies.
+(Optional for trivial complexity.)
+
 ## Scope
+Files and directories this phase touches. Be specific:
+- src/services/auth.ts (new)
+- src/routes/login.ts (modify)
+- tests/auth.test.ts (new)
+
+## References
+Links to official docs for anything where training data may be stale.
+(Optional, recommended for standard+.)
+
 ## Acceptance Criteria
+Testable criteria. Each must be verifiable by running a command or checking output.
+- [ ] `POST /api/login` with valid credentials returns 200 with JWT
+
+## Constraints
+Negative scenarios, boundary conditions, and hard limits. (Optional for trivial/quick.)
+- [ ] Max 5 login attempts per minute per IP
+
 ## Result
-(filled by conductor)
+(filled by lead after execution)
 ```
 
 ### Complexity Levels
@@ -121,7 +145,7 @@ depends_on: []
 | `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 (default) |
-| `complex` | Opus | Architect → Phases → Review → Push | New subsystems, unfamiliar territory |
+| `complex` | Opus | Design → Phases → Review → Push | New subsystems, unfamiliar territory |
 
 ### Blueprint Command
 
@@ -130,7 +154,6 @@ depends_on: []
 
 ### Grooming
 
-Before grooming, check `.orchestra/knowledge.md` (Active + Archive) for relevant patterns.
 
 ### Status Command
 

package/template/CLAUDE.md

@@ -16,14 +16,10 @@ Call `ask_user_questions` with:
 - options:
   1. Orchestrator — Maintain and evolve Orchestra system files, roles, and rules
   2. Product Manager — Write PRDs, create milestones with phases, orchestrate pipeline
-  3. Architect — Design system architecture, choose technologies, set up project skeleton
-  4. Backend Engineer — Implement features, write code + tests, build APIs
-  5. Frontend Engineer — Design + build user interfaces, write frontend tests
-  6. Adaptive — Adaptive expert role (iOS, DevOps, ML, etc.) — domain defined per phase
-  7. Discussion — Just brainstorm, no role needed
+  3. Discussion — Just brainstorm, no role needed
 
 If user skips or starts giving instructions directly — work with them normally.
-Sub-agents spawned by conductor skip role selection — they already have a role assigned in their prompt.
+Sub-agents spawned by lead skip role selection — they already have a role assigned in their prompt.
 Do NOT greet. Do NOT explain. The role selection IS your greeting.
 
 **AFTER ROLE SELECTED:**
@@ -33,15 +29,15 @@ Do NOT greet. Do NOT explain. The role selection IS your greeting.
 3. Check `.orchestra/milestones/` for active work
 4. If work exists → announce and start. If not → report and wait.
 
-Role IDs: orchestrator, product-manager, architect, backend-engineer, frontend-engineer, adaptive
+Role IDs: orchestrator, product-manager
 
 **ROLE ACTIVATION:** Only via `/orchestra {role}` commands. Never switch on free text.
 
-**`/orchestra start`** → read `.claude/agents/conductor.md`, run in **separate terminal** from PM.
+**`/orchestra start`** → read `.claude/agents/lead.md`, run in **separate terminal** from PM.
 
 ### Rules
 
-- Two-terminal model: PM plans in one terminal, conductor executes in another
+- Two-terminal model: PM plans in one terminal, lead executes in another
 - Each role writes only to its ownership scope (defined in role file)
 - Rules (`.claude/rules/*.orchestra.md`) auto-loaded. Skills loaded per phase.
 - **PROTECTED:** Non-Orchestrator roles NEVER modify `.orchestra/roles/`, `.orchestra/config.yml`, `.orchestra/README.md`, `.orchestra/blueprints/`, `.claude/agents/`, `.claude/rules/*.orchestra.md`, `.claude/skills/*/SKILL.md`, `.claude/commands/orchestra/`, `CLAUDE.md`, or `docs/`.