@sjawhar/pi-legion-envoy 5.24.4 → 5.24.6

package/dist/envoy.js

@@ -32805,8 +32805,14 @@ function renderAdvice(tool, key, advice, opts) {
   const openAsks = advice.your_open_asks;
   const writesSinceHuman = advice.session_writes_since_human;
   const lines = [];
+  const unparsed = advice.unparsed_openers;
+  if (unparsed !== undefined && unparsed.count > 0 && (tool === "dispatch_issue" || tool === "dispatch_artifact")) {
+    const quoted = unparsed.examples.map((example) => JSON.stringify(example)).join(", ");
+    const subject2 = unparsed.count === 1 ? "1 typed-block opening in this document is text, not a block" : `${unparsed.count} typed-block openings in this document are text, not blocks`;
+    lines.push(`${subject2}: ${quoted}. An opening like \`:::ask{\u2026}\` makes a block only as a line of its own, so as text it asks nobody. Mentioning the syntax on purpose? Put it in code. See the \`dispatch\` skill, "Decision blocks".`);
+  }
   if (advice.decision_blocks === 0 && opts.isPrimarySpec === true && (tool === "dispatch_issue" || tool === "dispatch_artifact")) {
-    lines.push('No decision blocks in this spec \u2014 nothing here reaches a human\'s inbox. Want human feedback? See the `dispatch` skill, "Decision blocks".');
+    lines.push('This spec holds no ask blocks, so nothing here reaches a human\'s inbox. Want human feedback? See the `dispatch` skill, "Decision blocks".');
   }
   if (hasIssueAdvice && writesSinceHuman !== undefined && writesSinceHuman >= 3 && (tool === "dispatch_message" || tool === "dispatch_ask" || tool === "dispatch_comment" && opts.isAskReply !== true)) {
     const middle = writesSinceHuman >= 6 ? "Stop posting here until a human replies." : "Progress ledger or scratchpad? If so, stop.";

package/dist/legion.js

@@ -31744,8 +31744,14 @@ function renderAdvice(tool, key, advice, opts) {
   const openAsks = advice.your_open_asks;
   const writesSinceHuman = advice.session_writes_since_human;
   const lines = [];
+  const unparsed = advice.unparsed_openers;
+  if (unparsed !== undefined && unparsed.count > 0 && (tool === "dispatch_issue" || tool === "dispatch_artifact")) {
+    const quoted = unparsed.examples.map((example) => JSON.stringify(example)).join(", ");
+    const subject2 = unparsed.count === 1 ? "1 typed-block opening in this document is text, not a block" : `${unparsed.count} typed-block openings in this document are text, not blocks`;
+    lines.push(`${subject2}: ${quoted}. An opening like \`:::ask{\u2026}\` makes a block only as a line of its own, so as text it asks nobody. Mentioning the syntax on purpose? Put it in code. See the \`dispatch\` skill, "Decision blocks".`);
+  }
   if (advice.decision_blocks === 0 && opts.isPrimarySpec === true && (tool === "dispatch_issue" || tool === "dispatch_artifact")) {
-    lines.push('No decision blocks in this spec \u2014 nothing here reaches a human\'s inbox. Want human feedback? See the `dispatch` skill, "Decision blocks".');
+    lines.push('This spec holds no ask blocks, so nothing here reaches a human\'s inbox. Want human feedback? See the `dispatch` skill, "Decision blocks".');
   }
   if (hasIssueAdvice && writesSinceHuman !== undefined && writesSinceHuman >= 3 && (tool === "dispatch_message" || tool === "dispatch_ask" || tool === "dispatch_comment" && opts.isAskReply !== true)) {
     const middle = writesSinceHuman >= 6 ? "Stop posting here until a human replies." : "Progress ledger or scratchpad? If so, stop.";
@@ -33531,7 +33537,7 @@ import { logger } from "@oh-my-pi/pi-utils";
 // package.json
 var package_default = {
   name: "@sjawhar/pi-legion-envoy",
-  version: "5.24.4",
+  version: "5.24.6",
   type: "module",
   omp: {
     extensions: [

package/dist/skills/dispatch/SKILL.md

@@ -49,10 +49,8 @@ discussion it came from — never as a compressed standalone ask.
 
 ## Writing for the human
 
-Sami, 2026-09-12, on what Legion had been producing: "It's completely incomprehensible. It's just
-compressed jargon nonsense. I have no idea what the fuck it's saying." Every spec, ask, comment,
-message, and PR body is read by a person who has not read the code, does not share this session's
-vocabulary, and is often on a phone. Write for that person.
+Every spec, ask, comment, message, and PR body is read by a person who has not read the code, does
+not share this session's vocabulary, and is often on a phone. Write for that person.
 
 - Plain English, full sentences, one idea per sentence. Never repo shorthand or nouns you coined:
   not "fix 8c", "READY-target", "PR B", "spec@v3", "the pair", "the packet" — say what the thing is.
@@ -73,8 +71,8 @@ vocabulary, and is often on a phone. Write for that person.
   shapes the sentence under it.
 - Before posting, test it: could Sami, reading only this text on his phone, know what he is being
   told or asked? If not, rewrite it. Length is not the problem; density is.
-- When an ask or message communicates a judgment, lead with that judgment in one sentence and put the mechanism underneath it. Do not make the reader ask a second time whether the result is a win. This shapes communication only when a judgment exists; it does not pre-decide an open question or remove its genuine options. Inferred from the AGENTC-186 12-hour-cap incident (platform PO, 2026-09-17).
-- When a Dispatch message states a root cause, include the reproducing command or test in that same message. Without it, label the diagnosis a hypothesis; a diagnosis still in progress may say so plainly. This boundary applies to causal claims, not to reporting that an investigation has started. Inferred from the astro lane's 2026-09-16 retro (platform PO, 2026-09-17).
+- When an ask or message communicates a judgment, lead with that judgment in one sentence and put the mechanism underneath it. Do not make the reader ask a second time whether the result is a win. This shapes communication only when a judgment exists; it does not pre-decide an open question or remove its genuine options.
+- When a Dispatch message states a root cause, include the reproducing command or test in that same message. Without it, label the diagnosis a hypothesis; a diagnosis still in progress may say so plainly. This boundary applies to causal claims, not to reporting that an investigation has started.
 
 ## Writing a spec
 
@@ -110,15 +108,18 @@ A spec has two readers: the human who decides reads the **Summary** and **New si
 ## Decision blocks
 
 A decision a human must make is an `:::ask` block where the decision arises in the spec: inside
-the section whose content it is about, never gathered into a list at the top or bottom. Sami,
-LEGION-204 comment, 2026-09-20 14:47Z, verbatim: "Adding a bunch of decision blocks at the top is
-terrible!! Decisions should be in context in the spec".
+the section whose content it is about, never gathered into a list at the top or bottom.
 
 The block is what reaches the human's Inbox. A question phrased as prose in the spec reaches
 nobody. A spec with no ask blocks is fine only when the issue genuinely needs no human decision.
-When `dispatch_issue` or `dispatch_artifact` answers `No decision blocks in this spec …`, read it
-as a question, not an error: either no decision is needed and you say nothing, or you forgot to
-make the decision a block and must fix the spec.
+When `dispatch_issue` or `dispatch_artifact` answers `This spec holds no ask blocks …`, read it as a
+question: either no decision is needed and you say nothing, or you forgot to make it a block. When
+it answers `… typed-block openings in this document are text, not blocks`, the quoted openings are
+blocks stored as prose (inside a line, or a paste with something before every line): fix the markdown
+and upload again; a mention on purpose belongs in code. Neither answer sees a spec wrapped whole in a
+code fence (take the fence off), a malformed opening inside a line (`::ask{`, `:::ask {`: an ask opens
+only as `:::ask{…}` on a line of its own), or any `dispatch_doc_edit`: after an edit that writes an
+ask, `dispatch_doc_read` the section and check it renders as `:::ask{#<id> …}` on its own line.
 
 **Wrong:** a **Decisions needed** list at the top of the spec with three bullets.
 **Right:** put each decision in the design section it belongs to as an `:::ask{#slug}` block, with
@@ -127,14 +128,8 @@ make the decision a block and must fix the spec.
 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`.
+out of Design move the same way, and the emptied section is deleted. An ask block has two ids that
+differ; [Editing a document](skill://dispatch/references/document-edits.md) says which.
 
 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.
@@ -185,8 +180,7 @@ When a symptom and its cause sit on different issues, the work accrues to the ca
 the symptom's issue carries a pointer to it. Before posting a measurement or finding, search
 Dispatch for the failing identity's or component's name, and post on the issue whose title names
 the fix, not the one naming the symptom. A symptom issue gathering messages with no human response
-is the tell. (The production freeze was iterated on AGENTC-546, the failing gate, while its cause
-and answer sat on AGENTC-1010.)
+is the tell.
 
 ## Claim the issue before you work it
 
@@ -216,11 +210,7 @@ field, and choosing your next issue are in [Working an issue](skill://dispatch/r
 
 ### Before you ask
 
-Sami, 2026-09-16, verbatim, rejecting two asks the same night: "All of these \"decisions\" are
-completely disconnected from any discussion of design or trade-offs. This is not a very useful way
-of having this discussion" (on a report-table shape), and "What's a fenced PutObject or phantom
-eval_id? What's an R4 model header? What exactly is the question or uncertainty here?" (on a
-production import). Every `dispatch_ask` passes four gates first:
+Every `dispatch_ask` passes four gates first:
 
 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)). Technical
@@ -228,19 +218,18 @@ production import). Every `dispatch_ask` passes four gates first:
    internals are your lane's to decide and record in the spec. Two things still go to the
    platform PO over Envoy: a contract between two lanes, and a halt condition (a change to IAM,
    deletion or exposure of production data, anything that reaches a customer). The PO takes those
-   to Sami as a Dispatch ask; you do not open one yourself, even as a permission ask under gate 2
-   (Sami, 2026-09-25, AGENTC-34 §12).
+   to Sami as a Dispatch ask; you do not open one yourself, even as a permission ask under gate 2.
 2. **Is there genuine uncertainty, and have you measured what you can?** If there is none, 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 sentence, with options that name its outcomes (below).
    Measure before you write: how many are affected, whether anything reaches the path, what the
    current state already is. The measurement decides whether a human is needed at all, and when
-   one is, it turns a research request he cannot answer into a decision he can — an ask whose
-   lead was "accept this or build a workaround", with nobody knowing whether anyone was affected,
-   was unanswerable until a measurement showed the usage could not be observed at all; the same
-   ask, carrying that and the size of the affected population, was answered at once, and another
-   lost an option outright when the measurement showed it could not repair most of the affected.
+   one is, it turns a research request he cannot answer into a decision he can. Put the
+   measurement and the size of the affected population in the ask. When the measurement shows one
+   fix cannot repair most of that population and another fix can, drop the first, rather than
+   offering it cut down to the part it reaches. An option not to act, such as a permission ask's
+   Hold, is not a fix, and it stays.
    Report what the measurement could **not** establish, with its own control: "I found no
    evidence" and "there is no evidence to find" read alike and mean opposite things, and a
    control that shares the query's blind spot proves neither. Before you say you are waiting on
@@ -302,13 +291,8 @@ passage with `anchor`. Follow up on an ask or comment with `dispatch_comment`; c
 with a `dispatch://` reference (see [References](#references)). Never write "see above", "the
 message above", or "as attached".
 
-**Pointing at another message is a defect, not a shortcut.** Sami, 2026-09-17, verbatim, on an
-ask that read "the settings listed in my comment just above" after a long procedure had been posted
-as a comment: "you just dump information into messages and then add a new ask that references a
-previous message in prose with no link or no context whatsoever and uses compressed shorthand
-jargon." The ask view does not show the issue's comments, so that ask was unanswerable; "Cloud
-Identity licence check / 2SV override / 1-day grace" was shorthand he had never used. The rules
-that follow from it:
+**Pointing at another message is a defect, not a shortcut:** the ask view does not show the
+issue's comments. The rules:
 
 - An ask that names another message in prose — "my comment above", "the procedure I posted",
   "see the earlier message" — is retracted by the PO as failing the gates. Put the content IN the
@@ -332,7 +316,7 @@ they must read to decide belongs in the spec in the first place — see [Artifac
 
 Before saying you are waiting for human input, call `dispatch_open_asks`. With no arguments it lists this session's active asks across open issues and project documents, including whether the human or agent owes the next reply. With `dispatch_open_asks({ project })` it lists every open ask in that project — on its issues and on its documents, whoever authored them — which is how you audit what a whole project is waiting on rather than just your own asks.
 
-**Unsettled product shape needs a decision before implementation.** When a page, navigation entry, table key, customer-scoping rule, or persisted sidecar would set product shape that Sami has not already settled, send a one-line ask before the first implementation commit. A lane's schema decision or a platform-PO contract ruling does not settle product shape. This does not turn a user-specified decision or routine implementation into an approval request; it is inferred from AGENTC-186's 2026-09-16 retro (platform PO, 2026-09-17). A control or behaviour the human asked for in words is settled by those words, together with every choice inside it that his words do not make (where it sits, its defaults, its options): build it without an ask, as gate 4 of [Before you ask](#before-you-ask) says. This rule covers only product shape outside what he asked for, and its ask comes before the commit that sets that shape.
+**Unsettled product shape needs a decision before implementation.** When a page, navigation entry, table key, customer-scoping rule, or persisted sidecar would set product shape that Sami has not already settled, send a one-line ask before the first implementation commit. A lane's schema decision or a platform-PO contract ruling does not settle product shape. This does not turn a user-specified decision or routine implementation into an approval request. A control or behaviour the human asked for in words is settled by those words, together with every choice inside it that his words do not make (where it sits, its defaults, its options): build it without an ask, as gate 4 of [Before you ask](#before-you-ask) says. This rule covers only product shape outside what he asked for, and its ask comes before the commit that sets that shape.
 
 **Anything you are blocked on a human for is an open ask.** An agent waits on a human only through
 an open ask. An approval, a credential or grant to renew, a setting only they can change, a review
@@ -371,10 +355,6 @@ other way — Sami said it live, a later comment settled it, or the question bec
 design moved — resolve it yourself with `dispatch_resolve_ask` in the same turn you learn that.
 Never leave it for the human to clear.
 
-Sami, AGENTC-27 `rules-derivation-2026-09-17.md` row R04, verbatim: "I think this was answered
-live. If not, please reask." The same pattern left him closing asks as `Dismissed`, `Settled`, and
-`Resolved I think`: noise the human had to clear.
-
 Every later write on the issue answers `You still have an open ask on …` and names it. Treat that
 as the checklist: if it is still needed, leave it; if it was answered elsewhere, resolve it with
 the resolving fact as the reason. Before posting a new ask, inspect your open ones. If the new ask
@@ -441,9 +421,7 @@ Uploading one (`dispatch_artifact`, its slugs, versions and Markdown rules) is i
 
 ## Structure over stream
 
-Dispatch is a structured workspace, never a message stream (Sami, 2026-09-13, verbatim: "strange
-to me that agents keep trying to use dispatch as a giant stream of messages instead of
-high-signal, structured conversation"). The structure IS the product:
+Dispatch is a structured workspace, never a message stream. The structure IS the product:
 
 - **One issue per piece of work.** A new deliverable — an email to send, a document to review, a
   decision with its own lifecycle — gets its own issue with the content as the issue's document

package/dist/skills/dispatch/references/document-edits.md

@@ -182,3 +182,9 @@ deletion cannot undo a removal.
 `retype` turns the paragraph or typed block with `block` into the named typed `type` in place. It keeps the
 block id, keeps a typed block's body, and uses `attributes` for client-owned typed attributes. Use it when
 an existing paragraph is the question that should become a decision.
+
+An ask block has two ids: the block id, shown as `:::ask{#<id> …}` in the rendered document and
+taken bare by `move`/`delete` in `block` (the `block:<id>` 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`.

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

@@ -11,7 +11,12 @@ The server declares typed document blocks at `GET /api/v1/schema/blocks`. Write
 container-directive form `:::name{#block-id key="value"}` on its own line, ordinary block children,
 and a closing line of as many colons at the same nesting. A typed block directly inside another needs the outer
 one's fence a colon longer (`::::callout{…}` around a `:::callout{…}`), and so does one whose code holds a `:::` line;
-Dispatch writes its fences that way. An unclosed typed block at document level is rejected. For
+Dispatch writes its fences that way. An unclosed typed block at document level is rejected. An
+opening line that continues a paragraph instead of standing on its own (indented four or more
+columns under the paragraph's text) is refused, naming the line's number and text - `INVALID_OP` on an edit's `markdown` or `with`, `INVALID_MARKDOWN` on any other write - since it
+would be stored as the paragraph's text; start the block on its own line. An opening written inside
+a line is stored as text, and `dispatch_issue` and `dispatch_artifact` quote it back as a
+typed-block opening that is text, not a block. For
 a new typed block, omit `#block-id`; Dispatch mints it. When editing an existing typed block, retain
 its id and every rendered attribute. Never copy an existing block's id into new markdown: an id
 names one block, so an insert, upload or suggestion whose markdown names an id the document holds

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

@@ -9,15 +9,14 @@ project's architecture model, or list or audit a project's backlog.
 When you finish an issue, or are told to work on the next thing, take the top ready issue of the
 whole backlog, across every project: status `todo`, highest priority first, then board rank. There
 are no areas: a standing role, a product owner and a lane each take the top issue like everyone
-else (Sami, 2026-09-27, dispatch://AGENTC-34/ask/01ed2956-73cc-48d2-8ed4-7a86c6d439b1). `todo`
+else (dispatch://AGENTC-34/ask/01ed2956-73cc-48d2-8ed4-7a86c6d439b1). `todo`
 means ready: specced, unblocked, and waiting on neither a deploy nor a decision. An issue that
 waits on one belongs in `backlog`, with what it waits on said on the issue.
 
 Hold at most three issues in flight (`in_progress`, `testing`, `needs_review` or `retro`), of any
-kind (Sami, 2026-09-27, answering dispatch://AGENTC-34/ask/1aeb8f2e-0950-4eaa-aaac-24286c9dd3ca;
-the question proposed two, and his answer set three). The limit is per agent and has nothing to do
-with the week's priorities (Sami, 2026-09-28, reply a7647eb0 on
-dispatch://AGENTC-393/ask/b773d9f6): the priorities decide only what you pull next. Past three:
+kind (dispatch://AGENTC-34/ask/1aeb8f2e-0950-4eaa-aaac-24286c9dd3ca). The limit is per agent and
+has nothing to do with the week's priorities (dispatch://AGENTC-393/comment/a7647eb0): the
+priorities decide only what you pull next. Past three:
 push any unfinished work, say where in one comment on the issue, move it to `backlog` and clear
 its route. Each issue counts on its own; a child does not ride under its parent's slot.
 In-flight issues with no owner at all go
@@ -38,9 +37,7 @@ reordering the board yourself.
 
 ## Claim the issue before you work it
 
-Two sessions once spent a night implementing the same issue, because nothing on it said who was
-on it (Sami, 2026-09-24, verbatim: "It seems like we need a better way of tracking what's already
-in progress"). So before you start implementing an issue, claim it:
+Before you start implementing an issue, claim it:
 
 ```ts
 dispatch_claim({ issue: "LEGION-234" })                  // I am implementing this
@@ -76,8 +73,7 @@ you find work nobody is on.
 
 **Claiming and moving the status are two separate actions, and you do both.** A claim says which
 session is on the work; the status says where the work has got to, and humans use it to track
-that too (Sami, 2026-09-24, verbatim: "Keep them separate — Separate because humans might be
-using them to keep track of work"). So when you start: `dispatch_claim({ issue })` **and**
+that too. So when you start: `dispatch_claim({ issue })` **and**
 `dispatch_issue_update({ issue, status: "in_progress" })`.
 
 ## Issue status is yours to move
@@ -87,9 +83,8 @@ the daemon writes it), the session doing the work moves it, the way a person mov
 `in_progress` when implementation starts, `testing` when the change is being proven on a
 production-like surface, `needs_review` when its pull request is open and waiting on the merge
 queue, `done` when the change has been driven in production (a merge is not `done`). Move child
-issues you own as well as the root. An issue left at `triage` while work is underway is a defect:
-Sami, 2026-09-15, on the roadmap he could not read — "I'm not even sure what their development
-status is." Waiting for the deploy lane is not a status and is never announced.
+issues you own as well as the root. An issue left at `triage` while work is underway is a defect.
+Waiting for the deploy lane is not a status and is never announced.
 
 ```ts
 // PATCH /api/v1/issues/{key} — status, title, labels, priority, external_links (merged by URL), route, parent
@@ -122,10 +117,9 @@ when work has started.
 ## Priority is yours to set
 
 Priority is the coarse bucket a backlog is read by: `0` is P0, the highest, through `3`, P3, the
-lowest, and `null` clears it. Sami ruled on 2026-09-24, answering "may agents set issue priority
-(P0–P3), or only propose it for you?" on `dispatch://LEGION/artifact/issue-status-conventions-md`:
-**"Agents may set"**. So set it — on creation, and on a grooming pass over issues that have none —
-and say what you set and why; he overrides anything he disagrees with from the dashboard. A closed
+lowest, and `null` clears it. Agents set it (`dispatch://LEGION/artifact/issue-status-conventions-md`)
+— on creation, and on a grooming pass over issues that have none — and say what you set and why;
+Sami overrides anything he disagrees with from the dashboard. A closed
 issue takes only `rank`, `components`, and a reopening `status` (any status but `done`);
 everything else, `priority` included, waits for the reopen (`409 ISSUE_CLOSED`). So reopen it
 first, then set the priority — the two cannot go in one call. `rank` itself is not a tool field:
@@ -165,26 +159,21 @@ dispatch_issues({ project, priority: [0, 1], limit: 250 })
 Every unclaimed row in `triage`, `icebox`, `backlog` or `todo` is a decision: someone takes it and
 builds it, or it closes. A row in `in_progress`, `testing`, `needs_review` or `retro`, or one that
 carries a claim, is work under way ([Issue status is yours to move](#issue-status-is-yours-to-move))
-and is not re-staffed. A todo with a finished spec reads as queued work that nobody is doing
-(LEGION-173 sat in todo for two weeks with a complete spec; AGENTC-1010's v4 plan sat in backlog
-with nobody building it).
+and is not re-staffed. A todo with a finished spec reads as queued work that nobody is doing.
 
 A close that says the defect cannot happen cites the code that makes it impossible. An issue
 closed because a rewrite forecloses it names the file and line in the rewrite that does so; a
 close that cannot name one is not foreclosed, it is unread. The cheapest way for a rewrite to reach
-parity is to port the code, defect included: LEGION-211's bare `git worktree prune`, filed against
-the TypeScript daemon, had been ported into the Go coordinator and was live in production.
+parity is to port the code, defect included.
 
 The audit finds four shapes:
 
 - **Unstaffed work.** A plan or measurement exists, and no one is building it.
 - **Unrecorded delivery.** An issue not yet in `testing` or `done`, claimed or not, has a merged PR
-  naming it. Check the change live, then move the issue (AGENTC-1033 sat at `triage` after its fix,
-  agent-c #20367, merged).
+  naming it. Check the change live, then move the issue.
 - **Unrecorded practice.** Someone does the issue's work by hand, more than once, while the issue
-  sits in backlog (OPS-132, done by hand on every migration merge). It leaves no plan and no PR to
-  find; the tell is your own messages. Doing something by hand more than once means an issue is
-  wearing the wrong status.
+  sits in backlog. It leaves no plan and no PR to find; the tell is your own messages. Doing
+  something by hand more than once means an issue is wearing the wrong status.
 - **Unreachable route.** An open issue whose route names a role nobody holds, or a session that is
   not running, reaches nobody, whatever its priority, and the priority filter above never finds
   it. List it on its own:
@@ -192,16 +181,14 @@ The audit finds four shapes:
   dispatch_issues({ project, route_status: "no_holder", limit: 250 })
   ```
   Each row reads `route role:sre (nobody holds it right now)` or `route session:<id> (that session
-  is not running right now)`. That is one read of the listener, and one read is a restart gap as
-  often as a vacancy: an agent box that restarts or resumes keeps the session id, but the session
-  is absent from the listener for minutes, and its role with it. On 2026-09-27, 58 of 63 session
-  routes one read showed as unreachable pointed at a single session that was moving between boxes.
+  is not running right now)`. That is one read of the listener, and one read cannot tell a
+  restart gap from a vacancy: an agent box that restarts or resumes keeps the session id, but the
+  session is absent from the listener for minutes, and its role with it.
   So a route is unowned only when it is `no_holder` on two reads at least ten minutes apart: list
   again after ten minutes and act on the issues both lists name. Confirm with the second
   `dispatch_issues` read, not `envoy_role_get`: a role lookup releases the claim of a holder whose
   session is absent from the registry as it answers. Then staff the role, re-route the
-  issue to a live holder, or clear the route and assign it (AGENTC-1065, a P2 production listener
-  503, sat routed to an unheld `role:sre` with no assignee). `route_status: "unknown"` means the
+  issue to a live holder, or clear the route and assign it. `route_status: "unknown"` means the
   listener did not answer, so a route could not be judged; a `no_holder` filter refuses rather
   than answer an empty list then.
 

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

@@ -77,8 +77,15 @@ passed — never as a fresh identity.
 
 Deployment instructions, when present, are the operator's standing rules for this repository —
 required checks, deploy/smoke commands, code-owner expectations, standing roles you may consult,
-the merge credential. They override this skill's defaults where they conflict; they never
-override a Sami ruling quoted here.
+the merge credential. They override this skill's defaults where they conflict, except four rules
+they never override: no deferrals (*PR body, review, and the merge gate*, below); bringing the base
+into the branch only on a real conflict or a retarget
+(`skill://legion-worker/references/conflicts-and-rewrites.md#reintegrating-the-base`); the
+implementer's own proof on a production-like surface at the head that merges, an applied simplify
+head included (`skill://legion-worker/references/pr-body.md#what-a-proof-is`,
+`skill://legion-worker/references/pr-body.md#the-rules-every-phases-evidence-follows`); and the
+implementer's production check after the merge
+(`skill://legion-worker/references/merge-gate.md#after-the-human-merge`).
 
 ## Asking another role
 
@@ -145,8 +152,7 @@ new work.
 
 **Shared operation safety:** Every Legion issue workspace is a `jj workspace` of one shared
 clone, so they all share one operation log: `jj undo`, `jj abandon`, and
-`jj op restore|revert|abandon|undo` rewrite it for every tree at once (on 2026-09-12 one
-worker's `jj undo` rewrote nine of another tree's commits). The extension refuses them in every
+`jj op restore|revert|abandon|undo` rewrite it for every tree at once. The extension refuses them in every
 phase-worker pane before they run — a `bash` command in any position of a pipeline or `&&`
 chain, with or without `-R`, judged on the whole argument list; `eval` code; and a `hub`
 process start — from your own tool calls and from any `task` subagent you spawn (it runs in
@@ -196,7 +202,7 @@ committer at all, and the one rewrite still open to you (*Rewriting pushed commi
 reference) resets the committer only of commits on your own chain that descend from the commit
 you named, after its guard cleared. Another role's commit
 carrying you as committer, which you did not rewrite that way, is evidence that something
-rewrote commits it should not have — the observable symptom of LEGION-118. Stop and send the
+rewrote commits it should not have. Stop and send the
 architect that log; do not accept it as a side effect. A wrong identity on your own commit, the
 other App or none, is a pane-environment problem to report to the architect, not something to
 pin (`docs/solutions/legion/shared-main-repo-hazards-for-concurrent-issue-workspaces.md`,
@@ -220,7 +226,7 @@ subcommand's `comment`, `create`, `edit`, `close`, `reopen`, `delete`, `pin`, `u
 GET (an explicit `-X`, or the POST that `-f`/`-F`/`--input` imply; pull-request conversation
 comments live on that path too, so edit them with `gh pr comment`) — printing
 `Legion issues live on Dispatch; use dispatch_message or dispatch_comment on <your LEGION_ISSUE>`:
-Legion never reads or writes a GitHub issue (LEGION-78). `pr comment`, `pr review`,
+Legion never reads or writes a GitHub issue. `pr comment`, `pr review`,
 `api …/pulls/…`, `api graphql`, and issue reads are unaffected. The credential reaches `legion`
 through the file `$LEGION_GRANT_FILE` names, written by the extension before each of your bash
 commands, each `github` tool call, and each `read`/`grep` of a `pr://` or `issue://` URL (and by
@@ -294,7 +300,7 @@ line), the full definition of a proof, what the tester verifies, and the simplif
   thread's opener (or, on a bot's thread, from the Legion reviewer) closes one. The implementer
   runs `legion threads resolve` before every push that answers a review, and the merger before
   READY: `skill://legion-worker/references/review-threads.md`.
-- **No deferrals.** Sami, 2026-09-11, verbatim: "My rule is no deferrals." A finding that changes
+- **No deferrals.** A finding that changes
   behaviour, hides an error, or breaks a gate is fixed in this pull request; naming, duplication,
   or wording cleanup is batched into the one `Fast-follow:` line instead of iterating per push.
 - **A red CI job** that failed on its own is re-run with
@@ -329,7 +335,9 @@ with. With `--data` omitted, `legion handoff write` reads the JSON object from s
 
 `handoff_write` validates the payload against the phase's schema before writing: an
 implement handoff without a well-formed `proof`, or a test handoff that reports no failure and
-carries no `proof` of its own, exits 1 naming the field and writes nothing.
+carries no `proof` of its own, exits 1 naming the field and writes nothing. Each `proof` entry, in
+either phase, is an object of six non-empty strings: `criterion` (the acceptance line it proves),
+`surface`, `command`, `observed`, `headSha` (the commit it ran at) and `negativeControl`.
 
 Then verify the durable artifact exists:
 

package/dist/skills/legion-worker/references/conflicts-and-rewrites.md

@@ -8,8 +8,7 @@ Every path it cites is in sjawhar/legion.
 ## Reintegrating the base
 
 - **Reintegrate the base only on a real conflict, except after a base retarget — and with a
-  merge, never `jj rebase`.** Sami, 2026-09-11, verbatim:
-  "Please don't do unnecessary rebases (i.e. unless there are merge conflicts). The CI queue is too long and slow."
+  merge, never `jj rebase`.**
   The implementer merges the base into the issue branch only when GitHub reports it `CONFLICTING`, the controller asks
   because of a conflict, or after the pull request is retargeted to a new base. Otherwise, never reintegrate the base to
   pick up `main` or refresh CI (a single failed CI job is re-run on its own: *A red CI job* in
@@ -24,8 +23,7 @@ Every path it cites is in sjawhar/legion.
   jj always rebases every descendant of any commit it rewrites — a revset naming the root of your
   own chain and rewriting it in place also rewrites whatever another tree has stacked on that root,
   whichever selector chose it (`-s`, `-b`, and `-r` all rewrite descendants; `-r` only re-parents
-  them to fill the hole, which is worse). This is what happened in LEGION-118: one issue's own
-  conflict step moved a second issue's twelve commits and its bookmark onto a conflicted copy.
+  them to fill the hole, which is worse).
   Resolve the conflict with a forward merge instead of a rewrite — merge the branch's own
   bookmark with the destination in one new commit, so nothing existing is rewritten and nothing
   built on your prior commits, in this tree or another, ever moves:
@@ -91,7 +89,8 @@ and the new head; the merger never computes a fingerprint — it uses the `--sum
 ## Rewriting pushed commits
 
 **Rewriting pushed commits** — a `jj squash --into` a commit already on GitHub, or any other
-rewrite of a commit you already pushed — is the LEGION-118 hazard in a second shape: jj rebases
+rewrite of a commit you already pushed — is the hazard *Reintegrating the base* describes, in a
+second shape: jj rebases
 every descendant of any commit it rewrites, and in the one shared repository a descendant can be
 another tree's branch stacked on your pushed commit, which then moves, with its bookmark, onto a
 rewritten copy. So look for a descendant outside your own chain first, and record the pushed tip
@@ -115,9 +114,7 @@ cd -- "$LEGION_WORKSPACE" && \
 `descendants(<commit>) ~ ::@` is everything built on the commit you are about to rewrite that is
 not on your own chain. Non-empty means the rewrite would move work that is not yours: do not
 rewrite it. Put the change in a new commit on top instead, and report the listed commits to the
-architect. On a two-workspace rig of this shape a `jj squash --into` a pushed commit reported
-`Rebased 13 descendant commits` and moved a second issue's twelve commits and its bookmark; the
-check above listed those thirteen and refused before anything moved.
+architect.
 
 Then rewrite, resolve, and push with the one push procedure (*Every role pushes its own commits*
 in `skill://legion-worker`). It lets the remote branch sit on the

package/dist/skills/legion-worker/references/merge-gate.md

@@ -82,15 +82,13 @@ completion leaves the issue in reviewing until you finish.
 
 ## After the human merge
 
-- **After a human merges, the implementer verifies in production.** Sami, 2026-09-13,
-  verbatim: "the agent that developed it should be responsible for testing in production."
+- **After a human merges, the implementer verifies in production.**
   The architect sends the implementer back once the merge lands; the implementer watches the
   deploy slot that carries the merge to `production-apply` (or the equivalent publish step),
   drives the changed path in production through the user's own access path, and records the
   observation on the PR and the issue before the architect signs off. A staging pass is not
-  this: on 2026-09-12 a slot's entire staging gate passed at 00:02Z and its production-apply
-  failed at 00:12Z on a resource staging never runs. If the slot fails on the change, the
-  implementer owns the fix and the next slot.
+  this, since a staging gate does not run every resource production does. If the slot fails on
+  the change, the implementer owns the fix and the next slot.
   The record has three places: the PR body's `Production:` line, one pull-request comment
   carrying the Legion footer, and a `dispatch_message` on the issue — the reviewer and merger
   read GitHub, the architect reads the issue. When the deploy that carries the merge has not

package/dist/skills/legion-worker/references/pr-body.md

@@ -51,17 +51,10 @@ a deliberately broken input and the refusal or failure observed. The surface is
 repository, a real browser, a devN stack, staging, or a local stack with real migrations, one that
 has the resource the change touches — and each `E2E` line carries a **link** to that run,
 screenshot, or e2e; human review does not replace user-facing verification, and a green unit suite
-is not it. A unit or integration test is a regression lock, never proof of a criterion. Sami,
-2026-09-13, verbatim: "They need to test everything in a production-like
-environment before merging, and it is the agent that develops the feature that is responsible
-for doing that. If there's anything blocking that, we need to fix it: if it's infrastructure, we
-need to fix it; if it's tooling, we need to develop it; if it's skills, we need to fix the skills
-... it should not require deploying to production to realize your feature doesn't work."
-Evidence for the rule: in the week of 2026-09-08 three surfaces merged green and were wrong on
-inspection (the Astrolabe IPI stack, Dispatch on ECS, the candidate flow), and on 2026-09-12 six
-deploy slots died on code first executed after merge, including a production-only ECS bootstrap
-the whole staging gate never ran. The implementer's proof and the tester's proof below are both
-this proof.
+is not it. A unit or integration test is a regression lock, never proof of a criterion. The agent
+that develops the change proves it this way before the merge, and whatever blocks that proof is
+fixed, not skipped (*When no surface reaches the changed path*, below). The implementer's proof
+and the tester's proof below are both this proof.
 
 ## The rules every phase's evidence follows
 
@@ -98,8 +91,8 @@ this proof.
   diff gets none.** It is scoped to the pull request's own diff, at the head where the last review
   round closed: nothing applied leaves that head final; applied → the applied head is the final
   head: CI runs on it, the pair runs once on it, and the E2E proof re-runs on it for the surface
-  the simplify diff touched (Sami, 2026-09-13: test on the real surface before merging, no
-  shortcuts — a refactor that "preserves behaviour" is a claim until it is executed). That cost is
+  the simplify diff touched, since a refactor that "preserves behaviour" is a claim until it is
+  executed. That cost is
   why 0-applied is the expected outcome and a pass that applies is spent sparingly. At the applied
   head the implementer re-cites the `CI` line and re-runs its own proof into `E2E (implementer)`,
   and the tester re-runs its proof for the touched surface into `E2E (tester)`, before the
@@ -116,10 +109,8 @@ No surface reaches the changed path is a report to the architect, never a reason
 Say which surface is missing and what it would have to do — a rig that can spawn the role, a
 sandbox that holds the resource, a credential, a command that does not exist yet — and send it to
 the architect with `envoy_publish` to its role topic. The architect creates a child issue in this
-tree to build it (infrastructure, tooling, or a skill) and resumes you once it lands. Sami,
-2026-09-13, verbatim: "If there's anything blocking that, we need to fix it: if it's
-infrastructure, we need to fix it; if it's tooling, we need to develop it; if it's skills, we need
-to fix the skills." A code path whose first execution would be after the merge — a deploy
+tree to build it (infrastructure, tooling, or a skill) and resumes you once it lands. A code path
+whose first execution would be after the merge — a deploy
 workflow's inline step, a post-merge helper, a production-only resource — is untested until you
 have executed it somewhere production-like; completing with a unit-test-only handoff is the
 failure this rule exists to stop.

package/package.json

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