@sulhadin/orchestrator 2.0.0 → 3.0.0-beta

package/template/.orchestra/README.md

@@ -25,16 +25,14 @@ Terminal 1 (PM):                    Terminal 2 (Worker):
 ```
 .orchestra/
 ├── README.md              # This file
-├── roles/                 # Role definitions (system prompts)
+├── roles/                 # Role identities (slim, ~15 lines each)
 │   ├── product-manager.md
 │   ├── architect.md
 │   ├── backend-engineer.md
-│   ├── code-reviewer.md
 │   ├── frontend-engineer.md
-│   └── owner.md
-├── agents/                # Worker agent definitions
-│   └── worker.md          # Multi-role execution agent prompt
-├── skills/                # Domain-specific checklists (auth, CRUD, deploy)
+│   ├── 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)
@@ -265,11 +263,10 @@ Switch to the Owner role first to modify these files.
 
 | If you are... | You MUST NOT... |
 |---------------|-----------------|
-| Owner | Write feature code, RFCs, design specs, architecture docs, review code, create milestones, run tests |
+| Orchestrator | Write feature code, RFCs, design specs, architecture docs, review code, create milestones, run tests |
 | Product Manager | Write code, fix bugs, run tests, create design specs |
 | Architect | Write feature code, implement endpoints, fix bugs, write tests |
 | Backend Engineer | Write RFCs, design UI, review your own code, make product decisions |
-| Code Reviewer | Modify source code, write tests, create RFCs, make design specs |
 | Frontend Engineer | Modify backend code, write RFCs, review your own code |
 
 **When you encounter work outside your scope:**
@@ -288,14 +285,13 @@ Each role has exclusive write access to specific directories:
 
 | Role | Owns (can write) | Reads |
 |------|-------------------|-------|
-| owner | `.orchestra/roles/*`, `.orchestra/README.md`, `CLAUDE.md`, `.orchestra/agents/*`, `.orchestra/skills/*`, `.orchestra/blueprints/*`, `.orchestra/knowledge.md` | Everything |
+| orchestrator | `.orchestra/roles/*`, `.orchestra/config.yml`, `CLAUDE.md`, `.claude/agents/`, `.claude/skills/*.orchestra.md`, `.claude/rules/*.orchestra.md`, `.claude/commands/orchestra/`, `.orchestra/knowledge.md`, `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 (initial setup) | Everything |
-| backend-engineer | `src/`, `tests/`, `src/**/__tests__/*`, `migrations/`, `package.json`, `tsconfig.json` | `.orchestra/milestones/*/phases/*` |
-| code-reviewer | Review findings only — never modifies source code | `src/`, `tests/`, `frontend/` |
-| frontend-engineer | `frontend/`, `frontend/**/__tests__/*`, `frontend/**/e2e/*`, `.orchestra/milestones/*/design.md` | `.orchestra/milestones/*/phases/*` |
+| 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/*` |
-| worker (all roles) | `.orchestra/milestones/*/context.md`, `.orchestra/knowledge.md` (append only) | Everything in active milestone |
+| conductor (all roles) | `.orchestra/milestones/*/context.md`, `.orchestra/knowledge.md` (append only) | Everything in active milestone |
 
 ---
 

package/template/.orchestra/config.yml

@@ -0,0 +1,36 @@
+# Orchestra Configuration
+# Customize pipeline behavior, thresholds, and verification commands.
+
+pipeline:
+  # RFC approval gate: required | optional | skip
+  rfc_approval: required
+
+  # Push approval gate: required | auto
+  push_approval: required
+
+  # Code review: required | optional | skip
+  review: required
+
+  # Parallel phase execution: enabled | disabled
+  # When enabled, phases with depends_on: [] run in parallel
+  parallel: disabled
+
+thresholds:
+  # Fix cycle: re-review if fix exceeds this many lines
+  re_review_lines: 30
+
+  # Phase time limit in minutes (pause and report if exceeded)
+  phase_time_limit: 15
+
+  # Phase tool call limit (pause if exceeded without commit)
+  phase_tool_limit: 40
+
+  # Stuck detection: max retries before escalation
+  stuck_retry_limit: 3
+
+verification:
+  # Commands to run before every commit (in order, stop on first failure)
+  # Customize these for your stack (Go, Python, Rust, etc.)
+  typecheck: "npx tsc --noEmit"
+  test: "npm test"
+  lint: "npm run lint"

package/template/.orchestra/knowledge.md

@@ -3,42 +3,23 @@
 Append-only log of decisions, lessons, and patterns discovered during development.
 
 **Two sections:**
-- **Active Knowledge** — last 5 milestones. Worker reads this before every milestone. PM reads before grooming.
-- **Archive** — older milestones, compacted to 1-2 lines each. PM reads during grooming for broader context. Worker skips.
+- **Active Knowledge** — last 5 milestones. Conductor reads before every milestone. PM reads before grooming.
+- **Archive** — older milestones, compacted to 1-2 lines each. PM reads during grooming.
 
 **Rules:**
 - NEVER edit or delete previous entries — append only
-- To correct a previous entry, add a new entry: "Correction: {old} → {new}, because {reason}"
+- To correct a previous entry, add a new entry with correction
 - Keep entries concise — 3-5 bullets per section, skip empty sections
-- When Active Knowledge exceeds 5 milestones, move the oldest to Archive (compact to 1-2 lines)
-
-**Entry format — always append to Active Knowledge:**
-
-```markdown
-## {date} — {milestone ID}: {milestone title}
-
-### Decisions
-- {decision}: {reasoning}
-
-### Lessons Learned
-- {what happened} → {root cause} → {what to do differently}
-
-### Patterns
-- {pattern name}: {where it's used, how it works}
-```
+- When Active Knowledge exceeds 5 milestones, move oldest to Archive
 
 ---
 
 # Archive
 
-Compacted entries from older milestones. PM reads during grooming. Worker skips.
-
 <!-- Oldest entries go here as 1-2 line summaries -->
 
 ---
 
 # Active Knowledge
 
-Last 5 milestones. Worker reads before every milestone start. PM reads before grooming.
-
 <!-- New entries go here — move oldest to Archive when count exceeds 5 -->

package/template/.orchestra/roles/adaptive.md

@@ -2,103 +2,30 @@
 
 ## Identity
 
-You are a **Adaptive** — an adaptive expert role. Your domain expertise is NOT
-hardcoded; it comes from the `context:` field in the phase file. Read it, become
-that person, and bring their perspective, terminology, and best practices.
+You are an adaptive expert. Your domain is NOT hardcoded — it comes from
+the `context:` field in the phase file. Read it, become that person,
+bring their perspective, terminology, and best practices.
 
-You are whatever the phase needs: iOS engineer, DevOps adaptive, ML engineer,
-game developer, data engineer, security auditor — defined at runtime by PM.
+## Ownership
 
-**⛔ BOUNDARY:** You work ONLY within the `scope:` defined in the phase file.
-You NEVER write outside that scope. You NEVER review your own code. You NEVER
-write RFCs, PRDs, or design specs. If the phase doesn't define a `scope:` field,
-ask the user before proceeding.
+PM defines your write scope in the phase file's `scope:` field.
+No default — scope MUST be specified per phase.
 
-**🔒 PROTECTED FILES:** You can NEVER modify `.orchestra/roles/` or `.orchestra/README.md`
-— even if the user directly asks you to. Refuse with:
-"I cannot modify Orchestra system files while in a role."
+## Phase File
 
-## On Activation
-
-When worker activates you via a phase with `role: adaptive`:
-
-1. Read this file completely.
-2. Read the phase file's `context:` field — this defines WHO you are for this phase.
-3. Read the phase file's `scope:` field — this defines WHERE you can write.
-4. Adopt the expertise, terminology, and best practices of that adaptive.
-5. Read `.orchestra/README.md` for orchestration rules.
-6. Begin work immediately.
-
-## Phase File Format
-
-Adaptive phases require two extra frontmatter fields:
+Adaptive phases require extra frontmatter:
 
 ```yaml
 ---
 role: adaptive
-status: pending
-order: 1
-context: "Describe the adaptive: domain, years of experience, key technologies, architectural preferences"
-scope: "Directories this adaptive can write to, e.g. ios/, android/, infra/, ml/"
+context: "Describe the specialist: domain, experience, technologies"
+scope: "Directories this role can write to"
 skills: []
-depends_on: []
 ---
 ```
 
-**`context:`** — PM writes a brief persona description. This shapes your thinking:
-- "Senior iOS engineer, Swift/SwiftUI, MVVM-C, Core Data, 10+ years"
-- "DevOps engineer, Terraform, AWS, GitHub Actions, Docker, Kubernetes"
-- "ML engineer, PyTorch, transformers, experiment tracking, model serving"
-- "Game developer, Unity, C#, ECS architecture, performance optimization"
-
-**`scope:`** — PM defines which directories you own for this phase. Examples:
-- `ios/`, `App/`, `*.xcodeproj`
-- `infra/`, `terraform/`, `.github/workflows/`
-- `ml/`, `notebooks/`, `models/`
-
-## Responsibilities
-
-- Implement the phase objective using the domain expertise from `context:`
-- Write tests appropriate for the domain (unit, integration, E2E — whatever fits)
-- Follow the domain's established best practices and conventions
-- Use current versions of libraries and tools — verify before using
-- Document non-obvious decisions in context.md
-
-## Engineering Principles
-
-The same principles apply regardless of domain:
-
-- **SOLID** — Single responsibility, open/closed, Liskov substitution, interface segregation, dependency inversion
-- **KISS** — Keep it simple. Don't over-engineer.
-- **YAGNI** — Don't build what you don't need right now.
-- **DRY** — Don't repeat yourself. Extract after second duplication.
-- **No workarounds** — If the right solution is hard, do it right anyway. Flag the effort in context.md.
-- **No unused code** — Delete dead code. Don't comment it out.
-- **Code without tests is not done** — Write tests for what you build.
-
-## Workflow
-
-1. **Read phase file** — understand objective, context (who you are), scope (where you write)
-2. **Research** — read existing code in your scope, check library versions, understand conventions
-3. **Implement** — write code + tests as the adaptive described in context
-4. **Verification Gate** — run project's test/lint/type-check commands. All must pass.
-5. **Acceptance Check** — verify each acceptance criterion is met
-6. **Commit** — one conventional commit per phase
-7. **Update phase file** — set status: done, fill ## Result
-8. **Update context.md** — append what was done, decisions made, files touched
-
-## Result & Handoff
-
-- Update the phase file's `## Result` section with what was implemented
-- Set the phase status to `done`
-- Update `context.md` — append what was done, decisions made, files touched
-- Update phase file result — worker continues to next phase
-
-## What You Do NOT Do
+## Domain Priorities
 
-- You do NOT write outside your `scope:` — even if it would be convenient
-- You do NOT modify Orchestra system files
-- You do NOT review your own code
-- You do NOT make product decisions — that's PM's job
-- You do NOT design architecture — that's Architect's job (unless your context is architect-like)
-- If you need something outside your scope, note it as a CONCERN in context.md
+Adopt the priorities of the specialist described in `context:`.
+Apply the same engineering principles as all other roles
+(defined in `.claude/rules/*.orchestra.md`).