@sjawhar/pi-envoy 9.0.0 → 9.1.0

package/dist/dispatch.js

@@ -17300,10 +17300,7 @@ async function refuseOpenDecisionBlocks(client, tool, resolved) {
   const asks = new Map(documentAsks.map((ask) => [ask.block_id, ask]));
   const lines = version2.markdown.split(`
 `);
-  const stillOpen = (named, state) => {
-    const next = state === "answered" ? "fold the answer into the text" : "write the decision into the text";
-    return `${named}, ${state} but still open in version ${latest}: ${next} with dispatch doc-edit, which writes a version that carries it`;
-  };
+  const stillOpen = (named, state) => state === "answered" ? `${named}, answered but still open in version ${latest}: it settles into a version on its own in about two seconds; wait, then request again` : `${named}, ${state} but still open in version ${latest}: write the decision into the text with dispatch doc-edit, which writes a version that carries it`;
   const open = blocks.flatMap((block) => {
     const ask = asks.get(block.id);
     const openers = lines.filter((line) => line.includes(`ask{#${block.id} `) || line.includes(`ask{#${block.id}}`));
@@ -17332,7 +17329,7 @@ async function refuseOpenDecisionBlocks(client, tool, resolved) {
   throw new Error([
     `dispatch ${commandName(tool)} was not called: ${artifact.name} (version ${latest}) has ${count}. Answering one writes a new version, which would move this request to that version and leave it waiting on you.`,
     ...open.map((line) => `- ${line}`),
-    "Do not request approval over an open block, even when a human asked for it. Tell the human which block is open and ask them to answer it or to waive it. Once it is answered, fold the answer into the text with dispatch doc-edit. If they waive it, close the block with dispatch resolve-ask (--kind resolved, their words as the --reason) and write their decision into the text with dispatch doc-edit. Then request approval again once the human has agreed to every point in the new version: the call opens the request, or hands an open one back to the human."
+    "Do not request approval over an open block, even when a human asked for it. Tell the human which block is open and ask them to answer it or to waive it. Once it is answered, it settles into a version on its own in about two seconds; wait, then request again. Edit the document only where the answer changes design text outside the block, never to restate it. If they waive it, close the block with dispatch resolve-ask (--kind resolved, their words as the --reason) and write their decision into the text with dispatch doc-edit. Then request approval again once the human has agreed to every point in the new version: the call opens the request, or hands an open one back to the human."
   ].join(`
 `));
 }

package/dist/skills/dispatch/SKILL.md

@@ -82,20 +82,23 @@ a new version that keeps the human's own text, never a second "spec" artifact be
 
 - **Each open question is a decision block**, shaped and placed as [Decision blocks](#decision-blocks)
   says. Because it is an ask, it reaches the human's Inbox, and the answer lands next to its context.
-- **A settled point records the person's own words and the date**, quoted, so no reader mistakes
-  it for your inference; an answer that is only a chosen option is recorded in the form
-  `<name> chose "Commit author" on the question below (<date>)`, naming them from `dispatch whoami`
-  or the conversation, or "the person" when the token names no owner — never a name you were not
-  given. A point you inferred says so, with the reasoning — a security concern, a restriction, or
-  a cost nobody measured is exactly this, not a settled constraint; during a live brainstorming
-  conversation, `skill://dispatch-brainstorming` is stricter and keeps an inference out of the spec
-  until the human has agreed to it. One carried in from another document keeps its provenance: an
-  agent's inference there is marked one here, or stays out until the human raises it.
+- **An answered decision block is itself the record of the decision.** It already renders the
+  person's chosen option and their own words, with who answered it and when; never add text
+  restating it. A point you inferred says so, with the reasoning — a security concern, a
+  restriction, or a cost nobody measured is exactly this, not a settled constraint; during a live
+  brainstorming conversation, `skill://dispatch-brainstorming` is stricter and keeps an inference
+  out of the spec until the human has agreed to it. One carried in from another document keeps its
+  provenance: an agent's inference there is marked one here, or stays out until the human raises
+  it.
+- **A decision that arrives another way carries no rendered record.** A comment that answers a
+  question, a conversation, or a waiver is written into the text in the person's own words and the
+  date, quoted, naming them from `dispatch whoami` or the conversation, or "the person" when the
+  token names no owner — never a name you were not given.
 - **Sections follow the topic.** No heading is required and none has a fixed place; name each
   section for what it discusses.
-- **A changed point is rewritten, not appended to.** When an answer or a new fact changes the
-  design, rewrite the text it changes and fold the answered decision into it; the document's
-  versions keep the history.
+- **A changed point is rewritten, not appended to.** When an answer or a new fact changes design
+  text outside its decision block, rewrite that text; the block stays where it is as the record of
+  the answer. The document's versions keep the history.
 - **No placeholders.** No TBD, TODO, or hedging ("might", "could consider"): an open item is a
   decision block, a technical decision your lane makes where the work happens, outside the spec,
   or, for a contract between two lanes, a question you settle with the other lane over Envoy (see
@@ -367,7 +370,7 @@ version, the way a pull-request review approves a commit, and any later version
 approval stale. A later version also moves an open request to that version and leaves it waiting
 on you until you request again, which hands the same request back to the human. Answering a
 decision block writes a new version, so request approval only when all three hold: every decision
-block is settled, which means answered and folded into the text, or waived as the next paragraph
+block is settled, which means answered or waived as the next paragraph
 says; the human has agreed to every point in the spec; and the current version has not been
 approved. A Legion root spec under an armed design gate always goes to approval once all three
 hold (`skill://legion-architect`).

package/dist/skills/dispatch/references/documents.md

@@ -209,9 +209,10 @@ The command opens an approval ask with the options `Approve` and `Request change
 "Approve spec.md (version N)?" followed by the summary, where N is the document's latest version. It
 is refused, with nothing sent, while that version holds a decision block open, and the refusal
 names each block and its ask. An answer or a `dispatch resolve-ask` closes the ask at once but
-reaches a version only when the document settles, about two seconds later, or with your next
-`dispatch doc-edit`: fold the answer into the text (or, for a waiver, write the human's decision
-in) before you request. A block written in the last few seconds counts as open before Dispatch has
+reaches a version only when the document settles, about two seconds later. An answered block
+already carries its own record, so wait for that version rather than editing just to force one; a
+waiver carries none, so write the human's decision into the text with your next `dispatch doc-edit`
+before you request. A block written in the last few seconds counts as open before Dispatch has
 opened its ask. A document holds one open request. A new version moves it to that version, keeping
 its thread and summary, and leaves it waiting on you, as a human's reply in its thread does; a move
 your own edit made sends you no event, and `dispatch read` and `dispatch doc-read` show it as

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

@@ -72,17 +72,18 @@ are ones you checked.
    revise or hand back, reply with `--reply-to-ask <ask id> --turn agent` instead: a `--reply-to`
    reply takes the default turn, which hands the request back to the human unchanged, and a call
    with a corrected `--summary` is refused while it waits on them.
-3. **Each next version folds the answers in and adds what they open.** Keep each answered
-   decision block where it is, fold its answer into the surrounding text in the human's words with
-   the date, recording the person as `skill://dispatch`'s "Writing a spec" says for a settled
-   point. Then add the next sections, each with its question. Every question that is ready goes out
+3. **Each next version keeps answers in place and adds what they open.** An answered decision
+   block already carries its own record, as `skill://dispatch`'s "Writing a spec" says; leave it
+   where it is. Where an answer changes design text elsewhere in the spec, rewrite that text. Then
+   add the next sections, each with its question. Every question that is ready goes out
    at once, each as a decision block at the end of the section that sets it up; a question waits
    only when it depends on an answer still open.
-4. **A comment that answers a question settles it** as surely as the block does. Fold it into the
-   text at once, and close the block with `dispatch resolve-ask` if the human has not.
+4. **A comment that answers a question settles it** as surely as the block does. It carries no
+   rendered record, so write it into the text at once, recording the person as `skill://dispatch`'s
+   "Writing a spec" says, and close the block with `dispatch resolve-ask` if the human has not.
 5. **Request approval at the end, not after each section.** Once nothing in the spec is new to the
    human, request it exactly when "Approval of a spec" in `skill://dispatch` says: every decision
-   block settled and folded in, the human has agreed to every point in the spec, and the current
+   block settled, the human has agreed to every point in the spec, and the current
    version is not yet approved (or waived, as that section's next paragraph covers). The request
    carries nothing new, as that section also says.
 

package/package.json

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