pi-messenger 0.8.0 → 0.8.1

package/CHANGELOG.md

@@ -1,5 +1,15 @@
 # Changelog
 
+## [0.8.1] - 2026-01-30
+
+### Changed
+- **Parallelism-aware planning** - Planner prompt now includes a dedicated Parallel Execution section teaching DAG thinking, independent work streams, critical path minimization, and real data flow dependencies. Plans should produce wider dependency graphs with more concurrent waves instead of linear chains.
+- **Parallelism-aware review** - Both the automated planning loop reviewer and the manual plan review (`action: "review"`) now evaluate plans for unnecessary sequential dependencies and critical path length.
+- PRD truncation applied consistently to both explicit `prd` parameter and auto-discovered PRD files (100KB limit).
+
+### Fixed
+- Stale README agent list referenced removed "analysts" instead of the actual 5 agents.
+
 ## [0.8.0] - 2026-01-30
 
 ### Added

package/README.md

@@ -225,6 +225,26 @@ The `plan` action runs a multi-pass planning loop: the planner drafts tasks, a r
 
 **No special format required** -- just put your docs in the project. The planner finds and reads markdown files, READMEs, and code comments.
 
+### How Work Execution Works
+
+Crew doesn't run tasks sequentially. Tasks form a dependency graph, and the work handler executes them in **waves** based on what's ready:
+
+```
+Wave 1:  task-1 (no deps)  ─┐
+         task-3 (no deps)  ─┤── run in parallel
+                             │
+Wave 2:  task-2 (→ task-1) ─┤── task-1 done, task-2 unblocked
+         task-4 (→ task-3) ─┘── task-3 done, task-4 unblocked
+
+Wave 3:  task-5 (→ task-2, task-4) ── both deps done
+```
+
+A task is **ready** when its status is pending and all its dependencies are completed. Each wave picks all ready tasks (up to `concurrency.workers`), spawns parallel workers, waits for them to finish, then checks what's newly unblocked. Independent tasks — those that don't depend on each other — run concurrently in the same wave.
+
+The planner structures tasks to maximize this parallelism. Foundation work (types, config, schemas) has no dependencies so it starts immediately. Features that don't touch each other get separate dependency chains so they can run in parallel. Tasks that need shared work done first (tests, integration, docs) depend on the tasks that produce it.
+
+A single `work` call runs one wave. Autonomous mode (`autonomous: true`) runs waves back-to-back until everything is done or blocked.
+
 ### Autonomous Mode
 
 Run tasks continuously until completion:
@@ -310,7 +330,7 @@ pi_messenger({ action: "crew.install" })
 ```
 
 **What gets installed:**
-- **5 agents** in `~/.pi/agent/agents/` (planner, analysts, worker, reviewer)
+- **5 agents** in `~/.pi/agent/agents/` (planner, worker, reviewer, interview-generator, plan-sync)
 - **1 skill** in `~/.pi/agent/skills/` (pi-messenger-crew quick reference)
 
 To remove:

package/crew/agents/crew-planner.md

@@ -64,13 +64,22 @@ Synthesize everything you've found. Identify:
 Create a task breakdown following the exact output format below. Guidelines:
 
 - **4-8 tasks** typically (scale with complexity)
-- First tasks should have **no dependencies** to enable parallel start
 - Each task should be **completable in one work session**
 - Group related work but keep tasks focused
 - End with testing and documentation tasks
 - Include specific files to create/modify when known
 - Include acceptance criteria in task descriptions
 
+### Parallel Execution
+
+Tasks execute in waves — all tasks whose dependencies are met run concurrently. Structure your breakdown to maximize parallelism:
+
+- **Think in dependency graphs, not sequences.** Tasks form a DAG, not a numbered list. Two tasks that don't touch the same files or types should be independent.
+- **Identify independent work streams.** Backend and frontend, types and implementation, different modules — these often have separate chains that can run in parallel. A server task and a CSS task don't depend on each other.
+- **Minimize the critical path.** The longest dependency chain determines total execution time. If a 10-task plan has a single chain of 10, it's sequential. If it has two chains of 5, it's twice as fast.
+- **Dependencies should reflect real data flow.** Task B depends on Task A only if B imports types, calls functions, or reads files that A creates. Conceptual ordering ("settings before server") isn't a dependency unless the server literally imports from the settings module.
+- **Front-load foundation tasks with no dependencies** so multiple streams can start from wave 1.
+
 ## Output Format
 
 Your final output MUST include both formats:

package/crew/handlers/plan.ts

@@ -16,7 +16,6 @@ import { discoverCrewAgents } from "../utils/discover.js";
 import { loadCrewConfig } from "../utils/config.js";
 import { parseVerdict, type ParsedReview } from "../utils/verdict.js";
 import * as store from "../store.js";
-import { getCrewDir } from "../store.js";
 
 const PRD_PATTERNS = [
   "PRD.md", "prd.md",
@@ -139,6 +138,9 @@ export async function execute(
       });
     }
     prdContent = fs.readFileSync(fullPath, "utf-8");
+    if (prdContent.length > MAX_PRD_SIZE) {
+      prdContent = prdContent.slice(0, MAX_PRD_SIZE) + "\n\n[Content truncated]";
+    }
   } else {
     const discovered = discoverPRD(cwd);
     if (!discovered) {
@@ -161,7 +163,7 @@ export async function execute(
     });
   }
 
-  const config = loadCrewConfig(getCrewDir(cwd));
+  const config = loadCrewConfig(store.getCrewDir(cwd));
   const maxPasses = Math.max(1, config.planning.maxPasses);
   const hasReviewer = availableAgents.some(a => a.name === "crew-reviewer");
 
@@ -386,7 +388,8 @@ Evaluate this plan against the PRD:
 2. Task granularity — is each task completable in one work session?
 3. Dependencies — correct and complete dependency chain?
 4. Gaps — missing tasks, edge cases, security concerns?
-5. Execution order — optimal for parallel start?
+5. Parallelism — are there unnecessary sequential dependencies? Tasks that don't share files or types should be independent. Flag any chain that could be split into concurrent streams.
+6. Critical path — what's the longest dependency chain? Could it be shortened by restructuring?
 
 Output your verdict as SHIP, NEEDS_WORK, or MAJOR_RETHINK with detailed feedback.`;
 }

package/crew/handlers/review.ts

@@ -216,7 +216,8 @@ Review this plan for:
 2. Task granularity - Are tasks appropriately sized?
 3. Dependencies - Are dependencies correct and complete?
 4. Gaps - Are there missing tasks or edge cases?
-5. Order - Is the execution order optimal?
+5. Parallelism - Are there unnecessary sequential dependencies? Tasks that don't share files or types should be independent.
+6. Critical path - What's the longest dependency chain? Could it be shortened?
 
 Output your verdict as SHIP (plan is solid), NEEDS_WORK (minor adjustments), or MAJOR_RETHINK (fundamental issues).`;
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pi-messenger",
-  "version": "0.8.0",
+  "version": "0.8.1",
   "description": "Inter-agent messaging and file reservation system for pi coding agent",
   "type": "module",
   "pi": {