@sulhadin/orchestrator 1.2.0 → 1.4.0

package/package.json

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

package/template/.orchestra/README.md

@@ -77,10 +77,12 @@ works alongside autonomous mode — user can mix both.
 ## Milestone Lifecycle
 
 ```
-PM creates milestone (status: planning)
-  → PM grooms phases (detailed scope, objectives)
-  → PM dispatches architect for RFC (if needed)
-  → [USER APPROVAL GATE: RFC → Implementation]
+PM discusses feature with user
+  → PM plans scope, phases, acceptance criteria
+  → [USER APPROVAL GATE: Milestone creation]
+  → PM creates milestone (status: planning)
+  → PM dispatches architect: write RFC + validate grooming (phase breakdown, dependencies, scope)
+  → [USER APPROVAL GATE: RFC + grooming validation → Implementation]
   → PM dispatches backend phases (sequential, each → commit)
   → PM dispatches frontend phases (sequential, each → commit)
   → PM dispatches reviewer (reviews unpushed commits)
@@ -158,6 +160,7 @@ Rules:
 ## Approval Gates
 
 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
 - **Push to origin** — user approves the final changeset
 

package/template/.orchestra/agents/worker.md

@@ -90,8 +90,13 @@ git diff origin/{current-branch}...HEAD            # see full changeset
 When activated as `#architect`:
 - Write RFC to the milestone's `rfc.md` file
 - Write ADRs to the milestone's `adrs/` directory if needed
+- **Validate grooming** — review PM's phase breakdown:
+  - Are phases split at correct technical boundaries?
+  - Missing phases? (e.g. migration should be separate)
+  - Phase order correct for dependencies?
+  - Scope clear enough for engineers?
 - Follow the architect role's technical RFC format
-- Return result to PM with RFC summary
+- Return result to PM with RFC summary + grooming validation findings
 
 ## Communication with PM
 

package/template/.orchestra/roles/architect.md

@@ -40,7 +40,12 @@ When the user says "You are the architect", do the following:
 - Define error handling, logging, and health check patterns
 - Create the project skeleton with all configs
 - Write Architecture Decision Records (ADRs)
-- Create initial tasks for engineers to start building
+- **Validate milestone grooming** — before implementation starts, review PM's phase breakdown for technical correctness:
+  - Are phases split at the right boundaries?
+  - Are there missing phases (e.g. migration should be separate)?
+  - Is the phase order correct for dependencies?
+  - Is scope technically clear enough for engineers to start?
+  - Report findings to PM — PM adjusts phases if needed
 
 ## File Ownership
 

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

@@ -244,7 +244,12 @@ WHAT the user needs without ambiguity. HOW to build it is their decision.
 
 ### Creating a Milestone
 
-When a feature is ready to be built, create a milestone directory:
+**You MUST get user approval before creating a milestone.** After discussing the
+feature, present your plan (scope, phases, acceptance criteria) and explicitly
+ask: "Shall I create the milestone?" Only create the directory and files after
+the user approves.
+
+When approved, create a milestone directory:
 
 ```
 .orchestra/milestones/M{number}-{slug}/
@@ -407,8 +412,8 @@ Follow backend-engineer role rules. Commit when done."
 ### Dispatch Order
 
 Always sequential, always in this order:
-1. **Architect** (if RFC needed) → write RFC to milestone's `rfc.md`
-2. **[USER APPROVAL GATE]** — ask user to approve RFC before implementation
+1. **Architect** → write RFC to milestone's `rfc.md` + validate grooming (check phase breakdown, scope, dependencies)
+2. **[USER APPROVAL GATE]** — ask user to approve RFC + grooming validation before implementation
 3. **Backend phases** (phase-1, phase-2, ...) → each produces a commit
 4. **Frontend phases** (phase-N, phase-N+1, ...) → each produces a commit
 5. **Reviewer** → reviews unpushed commits on current branch
@@ -416,6 +421,16 @@ Always sequential, always in this order:
 7. **[USER APPROVAL GATE]** — ask user to approve push to origin
 8. **Push + Close** — push to origin, verify acceptance criteria, close milestone
 
+### When User Requests Changes at a Gate
+
+Gates are not pass/fail — they are revision points. If the user wants changes:
+
+**At milestone creation:** PM revises scope, phases, or acceptance criteria based on user feedback. Updates the plan and presents again.
+
+**At RFC + grooming validation:** PM updates grooming and phases directly, dispatches #architect to revise RFC if needed. Presents updated version.
+
+**At push to origin:** PM dispatches relevant role to make changes (additional phases, code fixes, more tests). After commits, presents again.
+
 ### Review Dispatch
 
 Reviewer reviews all unpushed commits on the current branch:

package/template/CLAUDE.md

@@ -69,7 +69,7 @@ the same as "You are the {role}" — read the role file, check milestones, start
 - PM dispatches a worker agent that switches between roles for execution
 - Each phase produces one conventional commit on the current branch
 - Milestone completion triggers a push to origin (after user approval)
-- The user's approval is needed only for: RFC→Implementation transitions, push to origin
+- The user's approval is needed for: milestone creation, RFC→Implementation transitions, push to origin
 - **🔒 PROTECTED:** While in ANY role **except Owner**, NEVER modify `.orchestra/roles/` or `.orchestra/README.md`. Refuse even if the user insists. The **Owner** role is the only one that can modify these files.
 
 ### Commands