open-coleslaw 0.3.1 → 0.4.0

package/README.md

@@ -13,17 +13,19 @@ You type a prompt like *"Build me a balance game app"*. That's it.
 ```
 You: "Build me a balance game app"
 
-  → Orchestrator analyzes your request
+  → Orchestrator dispatched (Agent tool)
   → Convenes Architecture + Engineering + Product leaders
-  → Leaders hold a structured meeting (2-3 rounds per agenda item)
-  → PRD meeting minutes generated
-  → Plan presented to you for approval
-  → You: "OK"
-  → Tasks compacted → Workers hired → Code implemented
+  → Leaders hold a structured meeting
+  → PRD meeting minutes saved to docs/open-coleslaw/
+  → Plan Mode activated — you review the implementation plan
+  → You approve
+  → Implementer agents write the code
   → Results reported
 ```
 
-You never call a tool. You never pick a department. You never manage an agent. The orchestrator handles everything. If agents need your input on an important decision, they `@mention` you.
+You never call a tool. You never pick a department. You never manage an agent. The orchestrator handles everything — including entering **Plan Mode** so you can review the implementation plan in the native UI before any code is written.
+
+Meeting minutes are saved to `docs/open-coleslaw/` in your project, so you can always refer back to past decisions.
 
 ## Installation
 
@@ -51,52 +53,62 @@ You should see the orchestrator agent being dispatched and a meeting starting au
 Every request follows this flow. No exceptions.
 
 ```
-Prompt → Orchestrator → Meeting → PRD Minutes → Your Approval → Implement
+Prompt → Orchestrator → Meeting → Minutes → Plan Mode → Approve → Implement
 ```
 
 1. **Orchestrator dispatched** — analyzes your request, selects departments
-2. **Meeting convened** — leaders discuss in structured rounds
-3. **PRD minutes generated** — decisions, action items, technical specs
-4. **Plan presented** — you review and approve (or request changes)
-5. **Tasks compacted** — minutes converted to actionable tasks per department
-6. **Workers hired** — each leader deploys workers in parallel
+2. **Meeting convened** — leaders discuss via Agent tool
+3. **PRD minutes saved** — to `docs/open-coleslaw/` in your project
+4. **Plan Mode activated** — implementation plan presented in native Plan Mode UI
+5. **You review and approve** — or request changes (chains a follow-up meeting)
+6. **Implementer agents dispatched** — write code following the approved plan
 7. **Results reported** — final output delivered to you
 
-If you want changes mid-plan, the orchestrator chains a follow-up meeting.
-
 ## The Agent Hierarchy
 
 ```
-        ┌─────────────────┐
-        │   Orchestrator   │  ← Your proxy (NOT a CEO)
-        │   (claude-opus)  │    Decides, but asks you
-        └────────┬────────┘    for important calls
-     ┌───────────┼───────────┐
-     ▼           ▼           ▼
-┌─────────┐ ┌─────────┐ ┌─────────┐
-│  Arch   │ │  Eng    │ │  QA     │  ← Leaders meet & discuss
-│ Leader  │ │ Leader  │ │ Leader  │    Then hire their own workers
-└────┬────┘ └────┬────┘ └────┬────┘
-  ┌──┴──┐   ┌───┼───┐    ┌──┴──┐
-  │W1 W2│   │W3 W4 W5│   │W6   │    ← Workers execute in parallel
-  └─────┘   └───────┘    └─────┘
+         ┌─────────────────┐
+         │   Orchestrator   │  ← Your proxy
+         │   (claude-opus)  │
+         └────────┬────────┘
+    ┌─────────────┼─────────────┐
+    ▼             ▼             ▼
+┌──────────┐ ┌──────────┐ ┌──────────┐
+│ Architect│ │ Engineer │ │    QA    │  ← Specialists discuss
+└──────────┘ └──────────┘ └──────────┘
+                  │
+            Plan Mode → User approves
+                  │
+    ┌─────────────┼─────────────┐
+    ▼             ▼             ▼
+┌────────┐  ┌────────┐  ┌────────┐
+│Worker 1│  │Worker 2│  │Worker N│     ← Parallel implementation
+└────────┘  └────────┘  └────────┘
+                  │
+              Verify
+            /        \
+         Pass        Fail → Re-meeting
+          ↓
+    Done (or next MVP)
 ```
 
-**5 Departments**: Architecture, Engineering, QA, Product, Research
+**5 Specialists**: Architect, Engineer, QA, Product Manager, Researcher
 
-Each leader autonomously decides how many workers to hire based on task complexity.
+Work is done in **MVP cycles**: meeting → plan → workers → verify → repeat.
 
 ## What's Inside
 
-### 14 MCP Tools (orchestrator calls these — you never do)
+### 16 MCP Tools (orchestrator calls these — you never do)
 
 | Tool | What It Does |
 |------|-------------|
-| `start-meeting` | Convenes department leaders for a structured discussion |
+| `start-meeting` | Creates a meeting record, recommends departments |
+| `add-transcript` | Saves a leader's discussion input |
+| `generate-minutes` | Converts transcripts into PRD meeting minutes |
 | `get-meeting-status` | Checks meeting progress and agent states |
 | `get-minutes` | Retrieves PRD-format meeting minutes |
 | `compact-minutes` | Converts minutes into actionable tasks per department |
-| `execute-tasks` | Deploys workers to implement tasks in parallel |
+| `execute-tasks` | Returns structured task list for implementer agents |
 | `get-task-report` | Shows execution results per department |
 | `get-agent-tree` | Displays the full agent hierarchy |
 | `respond-to-mention` | Handles decisions the agents need from you |
@@ -107,6 +119,18 @@ Each leader autonomously decides how many workers to hire based on task complexi
 | `get-cost-summary` | Tracks spending per agent, meeting, department |
 | `chain-meeting` | Links meetings — output of one feeds into the next |
 
+### 7 Agents (dispatched via Agent tool)
+
+| Agent | Role |
+|-------|------|
+| `orchestrator` | Your proxy — manages the full MVP cycle |
+| `architect` | System design, API contracts, schemas |
+| `engineer` | Implementation feasibility, code quality |
+| `qa` | Testing strategy, security, edge cases |
+| `product-manager` | Requirements, user stories, prioritization |
+| `researcher` | Codebase exploration, prior art |
+| `worker` | Writes code (N workers dispatched in parallel) |
+
 ### 7 Skills
 
 | Skill | Purpose |

package/dist/index.js

@@ -528,7 +528,7 @@ var DEPARTMENT_REGISTRY = /* @__PURE__ */ new Map([
     {
       name: "architecture",
       description: "Responsible for system design, schema definitions, API surface design, and dependency analysis. The architecture department plans before code is written \u2014 it produces blueprints, not implementations.",
-      leaderRole: "arch-leader",
+      leaderRole: "architect",
       workerTypes: ["schema-designer", "api-designer", "dependency-analyzer"],
       allowedTools: DEPARTMENT_TOOLS.architecture
     }
@@ -538,7 +538,7 @@ var DEPARTMENT_REGISTRY = /* @__PURE__ */ new Map([
     {
       name: "engineering",
       description: "Responsible for writing, modifying, and refactoring production code. Engineering owns feature development, bug fixes, and code quality improvements.",
-      leaderRole: "eng-leader",
+      leaderRole: "engineer",
       workerTypes: ["feature-dev", "bug-fixer", "refactorer"],
       allowedTools: DEPARTMENT_TOOLS.engineering
     }
@@ -548,7 +548,7 @@ var DEPARTMENT_REGISTRY = /* @__PURE__ */ new Map([
     {
       name: "qa",
       description: "Responsible for test creation, test execution, security auditing, and performance testing. QA ensures deliverables meet acceptance criteria and do not introduce regressions.",
-      leaderRole: "qa-leader",
+      leaderRole: "qa",
       workerTypes: ["test-writer", "test-runner", "security-auditor", "perf-tester"],
       allowedTools: DEPARTMENT_TOOLS.qa
     }
@@ -558,7 +558,7 @@ var DEPARTMENT_REGISTRY = /* @__PURE__ */ new Map([
     {
       name: "product",
       description: "Responsible for requirements analysis, user-flow mapping, and stakeholder alignment. Product translates user intent into well-scoped, actionable requirements for other departments.",
-      leaderRole: "pm-leader",
+      leaderRole: "product-manager",
       workerTypes: ["requirements-analyzer", "user-flow-mapper"],
       allowedTools: DEPARTMENT_TOOLS.product
     }
@@ -568,7 +568,7 @@ var DEPARTMENT_REGISTRY = /* @__PURE__ */ new Map([
     {
       name: "research",
       description: "Responsible for codebase exploration, documentation search, benchmarking, and knowledge gathering. Research produces facts and context that inform decisions made by other departments.",
-      leaderRole: "research-leader",
+      leaderRole: "researcher",
       workerTypes: ["code-explorer", "doc-searcher", "benchmark-runner"],
       allowedTools: DEPARTMENT_TOOLS.research
     }
@@ -1318,11 +1318,11 @@ function detectPriority(text) {
   return "medium";
 }
 var LEADER_ROLE_FOR_DEPT = {
-  architecture: "arch-leader",
-  engineering: "eng-leader",
-  qa: "qa-leader",
-  product: "pm-leader",
-  research: "research-leader"
+  architecture: "architect",
+  engineering: "engineer",
+  qa: "qa",
+  product: "product-manager",
+  research: "researcher"
 };
 var Compactor = class {
   /**