@sjawhar/pi-legion-envoy 1.56.2 → 1.56.3

package/dist/envoy.js

@@ -29945,7 +29945,6 @@ function componentsArgument(z) {
 }
 var SPEC_SECTIONS = [
   "Summary",
-  "Decisions needed",
   "New since we talked",
   "Acceptance",
   "Requirements",

package/dist/legion.js

@@ -16145,7 +16145,7 @@ import { logger } from "@oh-my-pi/pi-utils";
 // package.json
 var package_default = {
   name: "@sjawhar/pi-legion-envoy",
-  version: "1.56.2",
+  version: "1.56.3",
   type: "module",
   omp: {
     extensions: [
@@ -29264,7 +29264,6 @@ function componentsArgument(z) {
 }
 var SPEC_SECTIONS = [
   "Summary",
-  "Decisions needed",
   "New since we talked",
   "Acceptance",
   "Requirements",

package/dist/skills/dispatch/SKILL.md

@@ -117,6 +117,18 @@ make the decision a block and must fix the spec.
 **Right:** put each decision in the design section it belongs to as an `:::ask{#slug}` block, with
 2–4 options, a recommendation, and surrounding prose that explains the trade-off.
 
+A spec that already has the pile is repaired with `move`, not rewritten: `dispatch_doc_edit` with
+`{ op: "move", block: "<block-uuid>", after: "<the sentence that states the options>" }` relocates
+the block and keeps its ask, its answer and its followers; the context paragraphs that were lifted
+out of Design move the same way, and the emptied section is deleted (the same repair, made on
+AGENTC-397 after Sami's 2026-09-20 request: "move the decisions items to be in context of their
+discussion in the spec, not just all piled up at the start with no context"). An ask block has two
+ids: the block id, shown as `:::ask{#<uuid> …}` in the rendered document and taken bare by
+`move`/`delete` in `block` (the `block:<uuid>` form is only for `before`/`after` anchors), and the
+ask id, which `dispatch_open_asks`, the dashboard's `?ask=` link, `dispatch_read` and
+`dispatch_comment({ reply_to_ask })` use. They differ; `dispatch://KEY/ask/<block-id>` answers
+`not found`.
+
 See [Typed blocks](#typed-blocks) for the syntax and [Before you ask](#before-you-ask) under
 [Asking](#asking) to decide whether the question is a real decision at all.
 
@@ -212,9 +224,10 @@ of having this discussion" (on a report-table shape), and "What's a fenced PutOb
 eval_id? What's an R4 model header? What exactly is the question or uncertainty here?" (on a
 production import). Every `dispatch_ask` passes three gates first:
 
-1. **Does it need his authority, taste, or risk appetite?** The same bar as a spec's Decisions
-   needed ([Writing a spec](#writing-a-spec)). Schema shapes, table layouts, field names, migration
-   internals, and contracts between lanes do not: they go to the platform PO over Envoy, who rules.
+1. **Does it need his authority, taste, or risk appetite?** This is the bar for a decision
+   written as an `:::ask` block in context ([Decision blocks](#decision-blocks)). Schema shapes,
+   table layouts, field names, migration internals, and contracts between lanes do not: they go to
+   the platform PO over Envoy, who rules.
 2. **Is there genuine uncertainty?** If not, it is a plan you execute. The one legitimate ask
    without uncertainty is permission for an action only a human can authorise — a production
    write, an external send, a console action — and then the question is that action in one
@@ -344,6 +357,11 @@ At least one field besides `ask` is required. Use this only while the same decis
 log and invalidates any answer draft against the prior `edited_at` revision, so the human sees the new wording and explicitly reconfirms.
 An answered or resolved ask cannot be edited. If the decision is moot or superseded, retract the old ask and open a new one.
 
+An ask that lives as an `ask` block in a document takes its question and options from the document, so edit those with
+`dispatch_doc_edit` (`replace` on the block's text, or `delete`/`insert` on its option items), never with `dispatch_edit_ask`: the
+next document save reasserts the block's text over whatever `dispatch_edit_ask` wrote, and that reversal is logged as an edit by
+the document's saver. `dispatch_edit_ask` is for asks opened with `dispatch_ask` that have no block.
+
 An ask stays open until a human answers, unless its question no longer needs that answer. Retract a moot or superseded question, or
 self-resolve one after finding the answer:
 ```ts

package/dist/skills/legion-architect/SKILL.md

@@ -86,11 +86,11 @@ handoffs; do not narrate them into the spec or a `dispatch_message`. A blocker o
 clear is a `dispatch_ask`.
 
 The issue's primary document **is** the root specification. Extend it in place — a new version
-that keeps the human's own text and adds Summary, Decisions needed, New since we talked, the
-adoption/decomposition and waves, acceptance criteria, and the integration test — never a second
-"spec" artifact beside it (`dispatch_artifact` with the primary document's name replaces the
-human's document; do not do that). Both readers described in
-[Writing for the human](../dispatch/SKILL.md#writing-for-the-human) must be able to follow it.
+that keeps the human's own text and adds Summary, New since we talked, the adoption/decomposition
+and waves, acceptance criteria, and the integration test — never a second "spec" artifact beside
+it (`dispatch_artifact` with the primary document's name replaces the human's document; do not do
+that). Both readers described in [Writing for the human](../dispatch/SKILL.md#writing-for-the-human)
+must be able to follow it.
 The design gate runs only when the "Design gate policy" line at the end of your system prompt
 says `gates.design: root-issues`. When it says `gates.design: off`, write the spec and continue
 to section 2 with no approval step at all: do not request approval, do not register a gate, and

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sjawhar/pi-legion-envoy",
-  "version": "1.56.2",
+  "version": "1.56.3",
   "type": "module",
   "omp": {
     "extensions": [