pi-crew 0.7.1 → 0.7.2

package/CHANGELOG.md

@@ -1,5 +1,17 @@
 # Changelog
 
+## [0.7.2] — Fix: Knowledge Injection into Workers + HITL for All Workflows (2026-06-15)
+
+### Bug Fixes
+
+- **Knowledge injection into crew workers (O4)** — crew workers are spawned with `--no-extensions` and only load `prompt-runtime.ts`; they do **not** load the pi-crew extension. So the `before_agent_start` hook in `knowledge-injection.ts` never fired for workers — `.crew/knowledge.md` was invisible to every crew worker. **Fix**: inject `buildKnowledgeFragment(task.cwd)` directly into `renderTaskPrompt()` in `prompt-builder.ts` (where all worker context is assembled). The main session still gets knowledge via the hook; workers now get it via the prompt path.
+
+  **Live-verified**: all 3 workers (explorer, executor, verifier) in a fast-fix run confirmed seeing the knowledge section verbatim (`"Use TABS for indentation"`, `"Tests run via npm test"`).
+
+- **Plan-level HITL for all workflows (T1.2)** — the post-batch approval re-check in the team-runner main loop only checked `hasPendingMutatingAdaptiveTask(tasks)` (adaptive/implementation workflows only). The boundary detector `hasPendingMutatingTaskAtBoundary(tasks)` was added to the initial build but **not** to the loop's re-check. So for non-adaptive workflows (`default`, `fast-fix`), the approval gate never fired after read-only tasks completed. **Fix**: add `hasPendingMutatingTaskAtBoundary(tasks)` to the loop's post-batch re-check (line 835), matching the initial-build logic.
+
+  **Verified** via 6 new unit tests + full flow trace. When `runtime.requirePlanApproval: true`, the run now blocks at the plan→execute boundary (`status: blocked`, "Plan approval required") until approved via `team api op=approve-plan`.
+
 ## [0.7.1] — Fix: Auto-Continue After Compaction (2026-06-15)
 
 ### Bug Fix

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pi-crew",
-  "version": "0.7.1",
+  "version": "0.7.2",
   "description": "Pi extension for coordinated AI teams, workflows, worktrees, and async task orchestration",
   "author": "baphuongna",
   "license": "MIT",

package/src/errors.ts

@@ -1,6 +1,24 @@
+// pi-crew structured error module — taxonomy mapping E001–E006.
 /**
- * Error code taxonomy for pi-crew.
- * Maps to semantic categories matching fallow's E001-E004 pattern.
+ * @fileoverview Error types and structured error handling for pi-crew.
+ *
+ * This module defines pi-crew's error taxonomy, mapping to semantic categories
+ * matching fallow's E001-E004 pattern. It exports three main constructs:
+ *
+ * - {@link ErrorCode} — a `const` object and string-literal union type alias
+ *   enumerating machine-readable error codes (E001–E006). Implemented as a
+ *   `const` object rather than a TypeScript `enum` so that Node's
+ *   `--experimental-strip-types` can load this module (enum syntax is not
+ *   supported in strip-only mode).
+ *
+ * - {@link CrewError} — a structured `Error` subclass that carries an
+ *   {@link ErrorCode}, an optional human-readable `help` hint, and an optional
+ *   `context` string. Its `toString()` renders the display format:
+ *   `error[E001]: Failed to read manifest.json: not found`.
+ *
+ * - {@link errors} — a factory object exposing convenience constructors
+ *   (e.g. `errors.fileRead`, `errors.taskNotFound`) that build `CrewError`
+ *   instances with sensible defaults and pre-attached context.
  */
 // Implemented as const object + type alias (not `enum`) so that Node's
 // `--experimental-strip-types` can load this module. TypeScript `enum`

package/src/runtime/task-runner/prompt-builder.ts

@@ -5,6 +5,7 @@ import { buildMemoryBlock } from "../agent-memory.ts";
 import { permissionForRole } from "../role-permission.ts";
 import { renderTaskPacket, HANDOFF_TEMPLATE } from "../task-packet.ts";
 import { buildWorkspaceTree } from "../workspace-tree.ts";
+import { buildKnowledgeFragment } from "../../extension/knowledge-injection.ts";
 
 /**
  * When loadMode is "lean", emit a tool guidance block that tells the worker
@@ -114,6 +115,11 @@ export async function renderTaskPrompt(manifest: TeamRunManifest, step: Workflow
 		treeBlock,
 		"",
 		toolGuidanceBlock(agent),
+		"",
+		// O4: project knowledge (.crew/knowledge.md) — workers don't load the
+		// pi-crew extension (spawned with --no-extensions), so before_agent_start
+		// never fires for them. Inject here so every worker sees project knowledge.
+		buildKnowledgeFragment(task.cwd),
 	].filter(Boolean).join("\n");
 
 	// Dynamic suffix: goal, step, skills, task packet, dependency context, memory — changes per task

package/src/runtime/team-runner.ts

@@ -394,7 +394,7 @@ function hasPendingMutatingAdaptiveTask(tasks: TeamTaskState[]): boolean {
  * Fires when there are pending mutating tasks whose prerequisites (read-only
  * tasks) have completed — i.e. the plan→execute boundary.
  */
-function hasPendingMutatingTaskAtBoundary(tasks: TeamTaskState[]): boolean {
+export function hasPendingMutatingTaskAtBoundary(tasks: TeamTaskState[]): boolean {
 	const hasCompletedReadOnly = tasks.some((t) => t.status === "completed" && !isMutatingTask(t));
 	const hasPendingMutating = tasks.some((t) => t.status === "queued" && isMutatingTask(t));
 	return hasCompletedReadOnly && hasPendingMutating;
@@ -832,7 +832,7 @@ tasks = mergeResult.resultTasks;
 		if (injectedAfterBatch.injected) {
 			manifest = requiresPlanApproval(workflow, input.runtimeConfig) ? ensurePlanApprovalRequested(manifest, tasks) : manifest;
 			queueIndex = buildTaskGraphIndex(tasks);
-		} else if (requiresPlanApproval(workflow, input.runtimeConfig) && hasPendingMutatingAdaptiveTask(tasks)) {
+		} else if (requiresPlanApproval(workflow, input.runtimeConfig) && (hasPendingMutatingAdaptiveTask(tasks) || hasPendingMutatingTaskAtBoundary(tasks))) {
 			manifest = ensurePlanApprovalRequested(manifest, tasks);
 		}
 		if (manifest.planApproval?.status === "cancelled") {