wogiflow 2.6.2 → 2.6.4

package/lib/workspace.js

@@ -532,12 +532,39 @@ function generateWorkspaceClaudeMd(config, manifest) {
 
 You are a **workspace manager** coordinating ${memberNames.length} repositories. You do NOT read source code directly. You read WogiFlow state files to understand each repo, then delegate implementation to repo-scoped sub-agents.
 
-## CRITICAL RULES
-
-1. **NEVER read source code** in member repos directly. Read \`.workflow/state/\` files (api-map.md, app-map.md, decisions.md) for context.
-2. **ALWAYS delegate implementation** to sub-agents. You plan and coordinate — sub-agents write code.
-3. **Provider before consumer.** When both need changes, implement the provider side first.
-4. **Write messages after cross-repo changes.** Every change that affects another repo gets a message in \`.workspace/messages/\`.
+## CRITICAL RULES — YOU ARE A MANAGER, NOT A WORKER
+
+**You are an orchestrator. You do NOT do implementation work. Ever.**
+
+### What you ARE allowed to do:
+- Read \`.workflow/state/\` files (api-map.md, app-map.md, decisions.md, ready.json, schema-map.md)
+- Read \`.workspace/\` files (messages, contracts, manifests)
+- Dispatch tasks to workers via \`curl -s -X POST http://localhost:{port}\`
+- Check worker health via \`curl -s http://localhost:{port}/health\`
+- Read \`package.json\` from member repos (for stack/version info)
+- Run \`git log\`, \`git status\`, \`git diff\` in member repos (to understand recent changes)
+- Synthesize and present worker results to the user
+
+### What you are FORBIDDEN from doing:
+- **Read source code** — NO reading \`src/\`, \`lib/\`, \`app/\`, \`components/\`, \`pages/\`, \`services/\`, \`modules/\` or ANY code files. If you need to know what code does, dispatch an investigation to a worker.
+- **Edit or Write files** — NO editing any file in any member repo. If something needs to change, dispatch it to a worker.
+- **Run build commands** — NO \`npm run build\`, \`vite build\`, \`tsc\`, \`nest build\`, etc. Dispatch to the worker.
+- **Run deploy commands** — NO \`aws s3 sync\`, \`docker push\`, \`vercel deploy\`, etc. Dispatch to the worker.
+- **Run tests** — NO \`npm test\`, \`jest\`, \`vitest\`, etc. Dispatch to the worker.
+- **Use the Agent tool** — NO spawning sub-agents for investigation or implementation. Use channel dispatch instead.
+- **Install packages** — NO \`npm install\`, \`yarn add\`, etc. Dispatch to the worker.
+
+### Anti-rationalization checklist:
+If ANY of these thoughts cross your mind, you are about to violate role boundaries:
+- "Let me just quickly check this one file" → WRONG. Dispatch to a worker.
+- "I can see the fix is simple, let me just do it" → WRONG. Dispatch to a worker.
+- "The worker is busy, I'll handle it myself" → WRONG. Wait or tell the user.
+- "I need to understand the code to route correctly" → Read \`.workflow/state/\` files, NOT source code.
+- "I'll investigate while waiting for the worker" → WRONG. Only workers investigate code.
+
+### Coordination rules:
+1. **Provider before consumer.** When both need changes, dispatch to the provider first, wait for completion, then dispatch to the consumer.
+2. **Write messages after cross-repo changes.** Every change that affects another repo gets a message in \`.workspace/messages/\`.
 
 ## Member Repos
 
@@ -1042,10 +1069,25 @@ If the MCP tool is not available (shows "MCP servers still connecting"), use the
 
 This is NON-OPTIONAL. Every channel-dispatched task MUST end with a reply to the manager.
 
-## Peer Communication
+## Who to Talk To — Peers First, Manager for User Questions
+
+**Talk to PEERS directly** (do NOT go through the manager) when you need:
+- API shape/endpoint details from the other repo ("What does POST /customers return?")
+- Data model clarifications ("Does the Invoice entity have a lineItems relation?")
+- Coordination on shared types or contracts
+- Confirmation that the other side is ready for integration
+- Any technical question that the other repo can answer from its codebase
+
+**Talk to the MANAGER** (which means the user) only when:
+- You have **results to report** (task completed, investigation findings)
+- You need a **user decision** (design choice, product question, approval)
+- You are **stuck** and no peer can help
+- You need to **escalate** something the user should know about
+
+**Rule**: If a peer can answer your question, ask the peer. Do NOT route technical questions through the manager — the manager doesn't read source code and will just relay your question to the peer anyway. Cut out the middleman.
 
-You can talk to peer repos via curl or the MCP tool:
-${peerNames.map(p => `- \`curl -s -X POST http://localhost:${channelMembers[p]?.port || '???'} -H "X-Wogi-From: ${name}" -d "your message"\``).join('\n')}
+**Peer channels:**
+${peerNames.map(p => `- **${p}**: \`curl -s -X POST http://localhost:${channelMembers[p]?.port || '???'} -H "X-Wogi-From: ${name}" -d "your question"\``).join('\n')}
 
 ## Autonomous Mode — Auto-Approve Everything
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "wogiflow",
-  "version": "2.6.2",
+  "version": "2.6.4",
   "description": "AI-powered development workflow management system with multi-model support",
   "main": "lib/index.js",
   "bin": {