@sjawhar/pi-envoy 10.6.0 → 10.6.2

package/dist/dispatch.js

@@ -19251,9 +19251,17 @@ async function runDispatchCli(argv, rawEnv, io) {
 
 // ../envoy-client/bin/dispatch.ts
 var readText = (path2) => readFileSync4(path2 === "-" ? 0 : path2, "utf-8");
-process.exit(await runDispatchCli(Bun.argv.slice(2), process.env, {
-  stdout: (text) => process.stdout.write(text),
-  stderr: (text) => process.stderr.write(text),
+var pending = [];
+var writeTo = (stream) => (text) => {
+  const { promise: promise2, resolve: resolve2 } = Promise.withResolvers();
+  stream.write(text, () => resolve2());
+  pending.push(promise2);
+};
+var code = await runDispatchCli(Bun.argv.slice(2), process.env, {
+  stdout: writeTo(process.stdout),
+  stderr: writeTo(process.stderr),
   readText,
   cwd: process.cwd()
-}));
+});
+await Promise.all(pending);
+process.exit(code);

package/dist/skills/dispatch-brainstorming/SKILL.md

@@ -18,9 +18,10 @@ follows is a document on the same issue. This skill replaces superpowers' `brain
 - There is no approval after each section, only the one at the end.
 - A small change gets a short spec, never a design in chat: its size shortens the spec and changes
   nothing about where the conversation happens.
-- No spec or plan file goes in the repository (`docs/superpowers/specs/`,
-  `docs/superpowers/plans/`, `docs/plans/`): the spec is the issue's primary document and the plan
-  is its `plan.md` document.
+- The spec is the issue's primary document and the plan is its `plan.md` document, in place of
+  superpowers' spec and plan files (`docs/superpowers/specs/`, `docs/superpowers/plans/`). A copy
+  also goes in the repository only when the person, the issue, its spec or the repository asks for
+  one.
 
 The brainstorming stages still shape what you ask: clarifying questions, then two or three
 approaches with a recommendation, then the design section by section. A question that depends on
@@ -28,8 +29,8 @@ no open answer goes out at once, whatever its stage.
 
 Read `skill://dispatch` before the first version: its "Writing a spec", "Decision blocks",
 "Writing for the human" and "Approval of a spec" sections define the spec's shape, each block's
-shape, and when approval is requested. A Legion phase worker never writes the spec; it sends a
-decision to its architect (`skill://legion-worker`).
+shape, and when approval is requested. A Legion phase worker never writes the issue's spec
+document; it sends a decision to its architect (`skill://legion-worker`).
 
 ## Where the spec lives
 
@@ -98,7 +99,7 @@ reactions, and so do corrections to it. Neither your model nor theirs is the sta
 
 Once the spec is approved — or, when the issue needed no spec at all (a bug fix with no design
 decision), once you have enough to plan from — the implementation plan is the issue's `plan.md`
-document, never its spec and never a repository file:
+document, never its spec:
 
 ```bash
 dispatch artifact --issue <KEY> --name plan.md --content-file - <<'EOF'
@@ -108,7 +109,9 @@ EOF
 
 Uploading `plan.md` again writes its next version. `writing-plans`'s content rules still apply in
 full — file structure, task right-sizing, bite-sized steps, no placeholders, the header, and its
-self-review — only where the plan lives changes: the issue's `plan.md`, never a repository file.
+self-review — only where the plan lives changes: the issue's `plan.md`, in place of a plan file.
+A copy in the repository, or spec code there, goes in only when the person, the issue, its spec or
+the repository asks for it.
 Technical choices inside the approved design are made in the plan and need no question. A plan
 never changes a decision the human made in the spec: a change to one goes back to the spec as a
 decision block, with the evidence for it.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sjawhar/pi-envoy",
-  "version": "10.6.0",
+  "version": "10.6.2",
   "license": "Apache-2.0",
   "type": "module",
   "omp": {