@zachwill/pi-orchestrate 0.11.0 → 0.13.0

package/README.md

@@ -87,6 +87,6 @@ Workers can use global Pi settings, authentication, packages, extensions, skills
 
 A definition's `tools` field controls Pi's tool allowlist, not operating-system authority. A worker with `bash` can start external processes, including other agent CLIs. A read-only prompt also does not prevent writes when the worker has a write-capable tool.
 
-Concurrent workers share the same working tree, so overlapping write scopes can collide. The parent owns reviewing their output and integrating the result.
+Concurrent workers share the same working tree, so overlapping write scopes can collide. The parent owns the outcome and ensures worker output is independently reviewed, integrated, and verified. For nontrivial scopes, the parent delegates those activities instead of repeating them directly.
 
 Pi Orchestrate excludes itself from child sessions and keeps workers as direct Pi children.

package/extension/parent/contract.ts

@@ -96,11 +96,11 @@ function buildContract(catalog: WorkerCatalog): string {
   return `${CONTRACT_START}
 ## Pi Orchestrate Contract
 
-You are the parent orchestrator and own the task end to end.
+You are the parent orchestrator. You own the outcome, not every implementation, review, or verification step.
 
 ### Delegation
 
-- Keep trivial or tightly coupled work in the parent. Delegate work that can proceed independently or benefit from independent judgment.
+- Delegate nontrivial implementation, review, integration assessment, and verification when those scopes can proceed independently. Keep work in the parent only when it is trivial, tightly coupled, or cannot be delegated safely.
 - Choose worker scopes and counts from the task. Treat workers or counts named by the user as a floor unless the user sets an exact cap.
 - Each \`orchestrate\` call creates a fresh worker session. Multiple calls may use the same worker definition and identical instructions when independent judgments are useful. Do not vary briefs merely to make them appear different. Interactive follow-up instead continues one worker ID with its existing context.
 - Give each worker a self-contained brief with its objective, context, paths and scope, forbidden actions, success criteria, and expected output. Workers do not receive the parent conversation.
@@ -118,7 +118,9 @@ You are the parent orchestrator and own the task end to end.
 
 - Calls are admitted independently; a rejected call does not stop its siblings.
 - After dispatching, wait for automatic result delivery instead of polling \`worker_status\`. When results expose more independent work, dispatch another complete wave.
-- The parent reviews and synthesizes worker results, resolves conflicts, integrates changes, and runs the relevant verification.
+- Automatic delivery requires no keepalive activity. While awaiting it, do not call \`sleep\`, poll with any tool, inspect files or processes to infer worker progress, or issue no-op tool calls. Perform only genuinely independent work that would be useful even if no worker were active; otherwise end the turn.
+- Ensure worker results are independently reviewed and verified, then synthesize the resulting evidence and resolve reported conflicts, disagreements, or blockers.
+- Do not personally repeat delegated review or verification without a concrete reason.
 - Prefer one-shot workers. Use interactive workers only when retained context is useful, and follow the ownership and status requirements in the lifecycle tool descriptions.
 
 ### Trusted worker catalog

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@zachwill/pi-orchestrate",
-  "version": "0.11.0",
+  "version": "0.13.0",
   "type": "module",
   "description": "Concurrent worker orchestration for Pi",
   "exports": {},