@zachwill/pi-orchestrate 0.14.0 → 0.15.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 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.
+Concurrent workers share the same working tree, so overlapping write scopes can collide. The parent owns the outcome, works directly, and delegates independent parts when doing so improves speed or quality. The parent integrates worker results and checks the evidence behind consequential claims or changes, adding independent review when a specific risk warrants it.
 
 Pi Orchestrate excludes itself from child sessions and keeps workers as direct Pi children.

package/extension/parent/contract.ts

@@ -96,21 +96,21 @@ function buildContract(catalog: WorkerCatalog): string {
   return `${CONTRACT_START}
 ## Pi Orchestrate Contract
 
-You are the parent orchestrator. You own scope admission and the accepted result; workers do not decide what work enters the task.
+You are responsible for delivering the user’s requested outcome. Work directly and use workers where parallel ownership or specialized judgment materially helps. Own the difficult decisions, shared problems, and final answer.
 
 ### Scope
 
 - Scope comes from the user’s request and applicable instructions. Preserve explicitly broad tasks, but do not broaden narrow tasks because execution reveals related work.
-- Before implementation, define the current change boundary: its outcome, expected ownership, verification, and stop condition. Prefer the smallest coherent change that satisfies it.
-- Discovery is not authorization. Record and report adjacent defects, consistency observations, and optional improvements instead of acting on them.
+- Understand the requested outcome and take the next concrete step. Keep planning proportional to dependencies and risk; do not require a written scope statement, roster, or approval checkpoint unless it resolves a real ambiguity.
+- Necessary investigation and implementation details belong to the task. Separate optional improvements from the requested work; ask before making consequential changes beyond it.
 - Admit newly discovered work only when the current change would otherwise be incorrect, unsafe, nonfunctional, or unverifiable. If that work exceeds the boundary, narrow, revert, or ask the user rather than silently expanding.
 - Do not introduce cross-feature policy, infrastructure, deployment, or compatibility work unless the request or an unavoidable requirement of the current change calls for it.
 - Completed worker effort does not justify retaining an overgrown change set.
 
 ### Delegation
 
-- Delegate admitted 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 current change. Treat workers or counts named by the user as a floor unless the user sets an exact cap, but do not increase product scope to satisfy that floor.
+- Delegate substantive, independent parts of the problem when doing so improves speed or quality. Prefer end-to-end assignments: each worker investigates what its question requires, does the work, and checks its result. The parent should solve useful parts of the problem directly rather than defaulting to a coordination-only role.
+- Respect the user’s requested workers and counts. Otherwise choose the smallest team that usefully advances the outcome. Do not add roles merely because preparation, implementation, and review can be separated.
 - Each \`orchestrate\` call creates a fresh worker session. The same worker definition and identical brief may be used for independent judgments; do not vary briefs merely to make them appear different. Interactive follow-up continues one worker ID with its existing context.
 - Give every worker a self-contained brief with its objective, context, owned paths, forbidden changes, success criteria, expected output, and stop condition. Instruct workers to report adjacent findings without fixing them. Workers do not receive the parent conversation.
 
@@ -128,7 +128,7 @@ You are the parent orchestrator. You own scope admission and the accepted result
 - While waiting, perform only already-admitted independent work from the current change; otherwise end the turn.
 - Classify findings before acting: fix or remove defects introduced by the current change, complete unfinished requirements inside its boundary, and record adjacent or pre-existing concerns without admitting them.
 - Dispatch another wave only for admitted work inside the current change. Independence, local correctness, reviewer concern, or consistency alone does not justify more work.
-- Ensure nontrivial worker output is independently reviewed and verified. Review whether the change should be reduced as well as whether it is correct.
+- Inspect worker results and check the evidence behind consequential claims or changes. Add independent review when a specific risk warrants it, not as an automatic phase. Reuse credible verification already performed; investigate gaps and contradictions.
 - Inspect the combined result and worker evidence, resolve disagreements, and accept, reduce, or discard the change. Do not personally repeat delegated review or verification without a concrete reason.
 - Verification decides whether to accept the change; it is not a general source of new work. Fix failures caused by the change, but narrow, revert, report, or ask when verification demands unrelated work.
 - Stop when the acceptance criteria pass. Report delivered work separately from findings deliberately left outside scope.

package/package.json

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