@zachwill/pi-orchestrate 0.4.0 → 0.4.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -65,11 +65,12 @@ Workers, runs, and queued delivery survive extension reloads and session switche
65
65
 
66
66
  Pi Orchestrate injects the authoritative orchestration contract and trusted catalog into the parent system prompt. The parent remains responsible for the task end to end:
67
67
 
68
- 1. Keep trivial or tightly coupled work in the parent session.
69
- 2. Give every worker a complete brief: objective, scope and paths, forbidden actions, context, constraints, success criteria, checks, and expected output.
68
+ 1. Keep trivial or tightly coupled work in the parent. Divide broad work into bounded, independent scopes and dispatch all currently independent scopes in parallel.
69
+ 2. Give every worker a thorough, self-contained brief with the objective, paths and scope, context, success criteria, and expected output. State forbidden actions explicitly.
70
70
  3. Dispatch independent scopes together, then yield after asynchronous acceptance.
71
- 4. Review evidence and changes, resolve conflicts, integrate deliberately, and verify the result.
72
- 5. Produce the final answer from the parent session.
71
+ 4. As results expose new independent work, dispatch another parallel wave and continue until the whole task is complete.
72
+ 5. Review evidence and changes, resolve conflicts, integrate deliberately, and verify the result.
73
+ 6. Produce the final answer from the parent session.
73
74
 
74
75
  Workers provide bounded evidence or changes. They do not replace parent judgment.
75
76
 
@@ -29,14 +29,14 @@ function buildContract(catalog: WorkerCatalog): string {
29
29
 
30
30
  You are the parent orchestrator and own the task end to end.
31
31
 
32
- - Keep trivial or tightly coupled work in the parent. Use as many useful workers as independent scopes justify.
32
+ - Keep trivial or tightly coupled work in the parent. Divide broad work into bounded, independent scopes and dispatch all currently independent scopes in parallel.
33
33
  - Delegate each independent scope with its own \`orchestrate\` call using \`{ worker, title, instructions }\`. Emit sibling \`orchestrate\` calls in one assistant message so Pi executes them concurrently.
34
- - Give every worker a full brief: objective; paths/scope; forbidden actions; context; constraints; observable success; checks; expected output.
34
+ - Give every worker a thorough, self-contained brief with the objective, paths and scope, context, success criteria, and expected output. State forbidden actions explicitly.
35
35
  - Input, catalog, and model preflight is atomic per call before that worker starts. Sibling calls are admitted independently, so one rejected call does not prevent valid siblings from starting.
36
36
  - A sole \`orchestrate\` call or a pure group of sibling \`orchestrate\` calls runs asynchronously. Pi accepts a pure group concurrently, yields the parent turn, delivers each result as it settles, and starts synthesis only after the whole group settles. Mixing \`orchestrate\` with another tool makes it inline and blocking. \`worker_send\` is asynchronous only as the sole tool call in its assistant message.
37
37
  - Exact worker instructions remain visible in the tool call and can be expanded; titles are labels, not substitutes for complete messages.
38
38
  - After an accepted async run, yield the parent turn. Worker responses arrive individually as each worker settles, and the final response starts parent synthesis. Do not duplicate delegated work, poll \`orchestration_status\`, or use it as a normal completion mechanism.
39
- - The active-work widget shows only workers currently starting, running, or stopping. Inline worker responses appear progressively in live tool output.
39
+ - As results expose new independent work, dispatch another parallel wave. Continue until the whole task is complete.
40
40
  - The parent synthesizes worker results, reviews their evidence and changes, resolves conflicts, integrates the final result, and runs the relevant verification before declaring completion.
41
41
  - Prefer one-shot workers. Use \`worker_send\` for follow-up work on a ready reusable worker, \`worker_close\` when that ready worker is finished, and \`worker_abort\` only when active work must stop.
42
42
  - The public tools are \`orchestrate\`, \`orchestration_status\`, \`worker_send\`, \`worker_abort\`, and \`worker_close\`.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@zachwill/pi-orchestrate",
3
- "version": "0.4.0",
3
+ "version": "0.4.1",
4
4
  "type": "module",
5
5
  "description": "Concurrent worker orchestration for Pi",
6
6
  "files": ["extension/", "examples/", "README.md", "LICENSE"],