@sjawhar/opencode-legion-envoy 1.14.0 → 1.15.0

package/dist/src/server.js

@@ -13567,6 +13567,7 @@ var IssueEventPayloadSchema = object({
   title: string2().optional(),
   labels: array(string2()).optional(),
   status: string2().optional(),
+  priority: number2().int().min(0).max(3).nullable().optional(),
   rank: string2().optional(),
   route: string2().nullish()
 });
@@ -13663,7 +13664,9 @@ var ChildStatusEventPayloadSchema = object({
 var SubscriptionRemovedEventPayloadSchema = object({
   session_id: string2().optional(),
   by: object({ kind: string2(), id: string2().optional() }).passthrough().optional(),
-  topics: array(string2()).optional()
+  topics: array(string2()).optional(),
+  pending: boolean2().optional(),
+  request_event_id: number2().int().positive().optional()
 });
 // ../contracts/src/dispatch-snippet.ts
 var HTML_ENTITIES = [
@@ -13760,7 +13763,8 @@ var dispatchToolSpecs = [
       external: z.string().describe("Optional external issue reference.").optional(),
       force: z.boolean().describe("Create even though POSSIBLE_DUPLICATE listed similar issues; pass it only after reading them.").optional(),
       spec: z.string().describe(`Optional initial primary-document markdown. ${SPEC_WRITING_GUIDANCE}`).optional(),
-      labels: z.array(z.string({ min: 1, max: 40 }), { max: 20 }).describe("Optional initial labels, at most 20 labels of up to 40 characters.").optional()
+      labels: z.array(z.string({ min: 1, max: 40 }), { max: 20 }).describe("Optional initial labels, at most 20 labels of up to 40 characters.").optional(),
+      priority: z.number({ int: true, min: 0, max: 3 }).describe("Optional coarse priority: P0 is highest and P3 is lowest.").optional()
     })
   },
   {
@@ -14616,6 +14620,11 @@ function asErrorShape(value) {
 function isJson(response) {
   return response.headers.get("content-type")?.includes("application/json") ?? false;
 }
+var DISPATCH_TOOL_DEADLINE_MS = 60000;
+function requestSignal(signal) {
+  const deadline = AbortSignal.timeout(DISPATCH_TOOL_DEADLINE_MS);
+  return signal === undefined ? deadline : AbortSignal.any([signal, deadline]);
+}
 
 class DispatchClient {
   token;
@@ -14623,10 +14632,12 @@ class DispatchClient {
   #baseUrl;
   #resolvedIssues = new Map;
   #creatingIssues = new Map;
-  constructor(baseUrl, token, fetchImpl = fetch) {
+  #signal;
+  constructor(baseUrl, token, fetchImpl = fetch, signal) {
     this.token = token;
     this.fetchImpl = fetchImpl;
     this.#baseUrl = baseUrl.replace(/\/+$/, "");
+    this.#signal = requestSignal(signal);
   }
   async issue(input) {
     return this.#json("POST", ["api", "v1", "issues"], input);
@@ -14838,6 +14849,7 @@ class DispatchClient {
     const response = await this.fetchImpl(this.#url(path, query), {
       method,
       headers,
+      signal: this.#signal,
       ...body === undefined ? {} : { body: JSON.stringify(body) }
     });
     return this.#response(response);
@@ -14846,7 +14858,8 @@ class DispatchClient {
     const response = await this.fetchImpl(this.#url(path), {
       method,
       headers: { Accept: "application/json", Authorization: `Bearer ${this.token}` },
-      body
+      body,
+      signal: this.#signal
     });
     return this.#response(response);
   }
@@ -15197,10 +15210,13 @@ function issueSummary(issue, events, references) {
   const asks = issue.open_asks;
   const spec = issue.artifacts?.find((artifact) => artifact.primary);
   const specApproval = spec === undefined ? undefined : approvalLine(spec);
+  if (issue.priority === undefined)
+    throw new Error("Dispatch issue is missing priority");
   return [
     `Title: ${issue.title}`,
     `Key: ${issue.key}`,
     `Status: ${issue.status}`,
+    ...issue.priority === null ? [] : [`Priority: P${issue.priority}`],
     `Labels: ${issue.labels.length === 0 ? "none" : issue.labels.join(", ")}`,
     `Route: ${issue.route ?? "none"}`,
     ...specApproval === undefined ? [] : [`Spec ${specApproval.replace(/^Approval/, "approval")}`],
@@ -15311,7 +15327,7 @@ async function executeDispatchTool(input) {
   const ownerArguments = await resolveOwnerArguments(input.tool, input.args, input.cwd, env, exec);
   const args = toolSchema(input.tool).parse(ownerArguments.args);
   const actor = toolActor(await resolveOrigin(env, exec, input.cwd), input);
-  const client = new DispatchClient(configUrl, configToken, input.fetchImpl);
+  const client = new DispatchClient(configUrl, configToken, input.fetchImpl, input.signal);
   const owner = ownerArguments.owner?.kind === "issue" ? {
     kind: "issue",
     issue: await ensureIssue(client, ownerArguments.owner.issue, actor)
@@ -15334,6 +15350,7 @@ async function executeDispatchTool(input) {
       const external = optionalString(args, "external");
       const force = optionalBoolean(args, "force");
       const spec = optionalString(args, "spec");
+      const priority = optionalNumber(args, "priority");
       const labels = args.labels;
       try {
         const created = await client.issue({
@@ -15343,6 +15360,7 @@ async function executeDispatchTool(input) {
           ...external === undefined ? {} : { external },
           ...force === undefined ? {} : { force },
           ...spec === undefined ? {} : { spec },
+          ...priority === undefined ? {} : { priority },
           ...Array.isArray(labels) ? { labels } : {},
           actor
         });
@@ -15894,7 +15912,7 @@ class EnvoyApiError extends Error {
 function createEnvoyClient(config) {
   const baseUrl = normalizeEnvoyUrl(config.baseUrl);
   const timeoutMs = config.timeoutMs ?? DEFAULT_TIMEOUT_MS;
-  const apiToken = process.env["ENVOY_TOKEN"];
+  const { ENVOY_TOKEN: apiToken } = process.env;
   const request = async (path, init) => {
     const url = `${baseUrl}${path}`;
     for (let attempt = 0;attempt < 2; attempt += 1) {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sjawhar/opencode-legion-envoy",
-  "version": "1.14.0",
+  "version": "1.15.0",
   "type": "module",
   "main": "dist/src/server.js",
   "exports": {

package/skills/dispatch/SKILL.md

@@ -78,13 +78,13 @@ exactly one owner to every owner-scoped tool: `issue` for an issue, or `project`
 [References](#references) for the resulting ref shape). On first use, an external issue reference creates its native issue in the
 project configured for that repository in Dispatch Settings, then falls back to `DISPATCH_DEFAULT_PROJECT`.
 
-Issue reads include `rank`, the server-owned ordering key used by project boards; reorder through `PATCH /api/v1/issues/{key}` with neighboring issue keys rather than writing a priority value.
+Issue reads include `rank`, the server-owned ordering key used by project boards; reorder through `PATCH /api/v1/issues/{key}` with neighboring issue keys. They also include nullable coarse priority (`P0` highest through `P3` lowest).
 
 Architects create newly tracked child work with:
 ```ts
-dispatch_issue({ project, title, parent?, external?, spec?, force?, labels?: string[] })
+dispatch_issue({ project, title, parent?, external?, spec?, force?, labels?: string[], priority?: 0 | 1 | 2 | 3 })
 ```
-`labels` are optional initial labels: Dispatch trims them, preserves their case, and removes case-insensitive duplicates. It returns
+`labels` are optional initial labels: Dispatch trims them, preserves their case, and removes case-insensitive duplicates. Set `priority` on creation only when the human's intent makes the bucket clear; otherwise priority remains the human's decision. It returns
 `details` `{ issue, topic }`. Use `dispatch_issue` only to create an issue; never use it to park a question. When `spec` is supplied,
 follow [Writing a spec](#writing-a-spec).
 
@@ -165,7 +165,8 @@ dispatch_edit_ask({
 })
 ```
 At least one field besides `ask` is required. Use this only while the same decision remains open: it keeps the prior text in the event
-log. An answered or resolved ask cannot be edited. If the decision is moot or superseded, retract the old ask and open a new one.
+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 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:

package/skills/legion-architect/SKILL.md

@@ -34,6 +34,13 @@ separate coordinator to finish necessary work.
   create and continue to own. Re-file a genuinely independent child through the
   controller rather than treating it as an abandoned dependency.
 
+## Deployment instructions
+
+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.
+
 ## 1. Decompose or adopt
 
 Inspect the root issue, acceptance criteria, existing children, and current handoffs.
@@ -127,10 +134,12 @@ legion({
 
 The daemon spawns that sub-architect as its own process with the child's context already
 in its environment; a resume of an existing role continues the same process instead of
-starting a fresh one. Keep the returned session identifiers, because retro and adjustment
-use those live sessions. Park while children are in flight. On each child closure,
-re-scope open work, close obsolete work with a reason, and release the next wave only
-when it now makes sense. There is no inter-child dependency mechanism to encode.
+starting a fresh one. Keep the returned session identifiers; retro and adjustment resume
+those same sessions through `spawn_worker` (a finished worker is retired after
+`worker_idle_retire_seconds` and comes back from its session file). Park while children are
+in flight. On each child closure, re-scope open work, close obsolete work with a reason, and
+release the next wave only when it now makes sense. There is no inter-child dependency
+mechanism to encode.
 
 ## 3. Children complete
 
@@ -160,18 +169,24 @@ review and the merge-gate sequence.
 
 ## 5. Retro
 
-Retro is mandatory for every issue that passed review, before merge. Message the
-implementer's live session (idle since it completed its phase; the daemon never tears
-it down) with `envoy_publish` to its role token, naming the skill:
+Retro is mandatory for every issue that passed review, before merge. Send the implementer
+back in through the daemon — `spawn_worker` on the implementer carrying the retro task. This
+resumes the same agent whether its pane is still live or the daemon has already retired it
+idle (a finished worker is retired after `worker_idle_retire_seconds`, default 600 s, and
+resumed from its session file on its next assignment). Never `envoy_publish` to a finished
+worker's role topic for this: a retired role has no live holder and the publish is rejected
+with 404.
 
 ```text
-envoy_publish({
-  topic: "notifications.role.<implementer's encoded token>",
-  message: "Run the legion-retro skill now. Capture durable learnings and post the issue comment; do not create a .legion handoff file."
+legion({
+  op: "spawn_worker",
+  issue: "LEGION-40",
+  role: "implementer",
+  task: "Run the legion-retro skill now. Capture durable learnings and post the issue comment; do not create a .legion handoff file."
 })
 ```
 
-Wait for the messaged implementer to report its durable retro result. Retro output is
+Wait for the implementer to report its durable retro result. Retro output is
 `docs/solutions/` plus an issue comment; it must not create a `.legion` file or change
 the reviewer-approved head after cleanup.
 
@@ -189,7 +204,8 @@ Preserve this order exactly:
    head. The deletion must land before that approval, which is head-pinned. An implementer
    completion always writes the issue's status as `testing`; this one is not a test round,
    so on its `phase-complete` wake call `legion({ op: "set_status", issue, status: "retro" })`
-   before messaging the reviewer to approve;
+   before `spawn_worker` on the reviewer to approve that head (a finished reviewer may already
+   be retired; `spawn_worker` resumes it);
 3. retro completes without dirtying the branch beyond `docs/solutions/`;
 4. the merger verifies the current head is the reviewer-approved head plus only the retro
    commits and publishes `READY #<n> at <sha>` to `notifications.role.pr-queue`; it never

package/skills/legion-controller/SKILL.md

@@ -33,6 +33,13 @@ listener restart.
 This handshake lets the daemon redeliver held controller work. It does not turn the controller
 into a state holder: daemon state and the Dispatch project remain authoritative.
 
+## Deployment instructions
+
+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.
+
 ## Turn discipline
 
 - **Direct user message always first.** If this turn includes a direct user message, answer

package/skills/legion-oracle/SKILL.md

@@ -36,11 +36,12 @@ digraph oracle_decision {
 
 ## Research Strategy
 
-If the deployment instructions name a librarian role, ask it first (publish to its
-`notifications.role.<name>` topic with `expects_reply: required`). Then run steps 1-2 (parallel
-OK), and 3-4 if needed, with tools a Legion pane actually has: `read`, `grep`, `web_search`, and
-`task(agent="scout")` (fast read-only codebase search) or `task(agent="oracle")` (deeper
-read-only analysis when the answer needs judgment across many files). Do not name any other agent.
+If the deployment instructions name a librarian (or oracle) role, publish your question to
+`notifications.role.<name>` with `expects_reply: required` and wait for the reply before
+researching yourself. Then run steps 1-2 (parallel OK), and 3-4 if needed, with tools a Legion
+pane actually has: `read`, `grep`, `web_search`, and `task(agent="scout")` (fast read-only
+codebase search) or `task(agent="oracle")` (deeper read-only analysis when the answer needs
+judgment across many files). Do not name any other agent.
 
 | Step | Tool | Query |
 |------|------|-------|

package/skills/legion-retro/SKILL.md

@@ -21,6 +21,10 @@ retrospective's durable output.
    Retro writes **no `.legion` file**, so it never re-dirties the cleaned handoff tree.
 4. The merger verifies the approved head, publishes `READY`, and pushes nothing; the merge queue
    merges under the repository's own rules.
+5. After the merge lands, the implementer — not the reviewer, the merger, or the queue — verifies
+   the change in production and records it on the PR and the issue (Sami, 2026-09-13, verbatim:
+   "the agent that developed it should be responsible for testing in production"). The
+   architect's sign-off waits for that record.
 
 Do not start retro before step 2, skip it because the change seems mechanical, or publish `READY`
 before step 3. The design gate is not a substitute for review and retro.
@@ -28,6 +32,10 @@ before step 3. The design gate is not a substitute for review and retro.
 ## Two perspectives
 
 1. Re-read the issue, its acceptance criteria, the PR, test evidence, and review evidence.
+   Confirm the PR's `E2E` line links a pre-merge proof on a production-like surface (a devN
+   stack, staging, or a local stack with real migrations). If it links only a unit suite or
+   nothing, the retro's first durable learning is that gap, and the issue goes back to the
+   tester before `READY`.
    Do not rebase or create a new branch; work on the existing issue branch.
 2. Spawn one fresh-eyes subagent. Give it the issue and PR, ask it to inspect the diff and
    return concrete reusable learnings, and require it to return analysis rather than edit files.

package/skills/legion-worker/SKILL.md

@@ -55,13 +55,22 @@ round, a question) can deliver a new prompt to this same session. Treat it as a
 continuation — re-read the current issue and your own prior handoff, since time has
 passed — never as a fresh identity.
 
+## Deployment instructions
+
+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.
+
 ## Asking another role
 
 Reach any live role on this issue the same way you reach the architect: `envoy_publish` to
 `notifications.role.` followed by that role's encoded token. Use it when you need context an
 earlier phase has that its handoff doesn't cover — ask the planner why a constraint was
 scoped that way, ask the implementer what a commit actually did. A role that finished its
-phase is still alive and idle in its pane; it answers.
+phase stays idle in its pane for the daemon's idle-retire window and answers; once retired (no
+live holder, a publish is rejected 404), read its committed handoff or ask the architect to
+`spawn_worker` it.
 
 ## Workspace and handoff precedence
 
@@ -240,7 +249,23 @@ Negative control: <deliberately broken input> → <refusal or failure observed>.
 - The tester fills in the `E2E` section: the real surface a user reaches the criterion
   through, the exact command or run id, what was observed, the head SHA, and one negative
   control — a deliberately broken input and the refusal or failure it produced. A unit or
-  integration test is a regression lock, never proof of a criterion. Environment or
+  integration test is a regression lock, never proof of a criterion. The surface is
+  **production-like** — a devN stack, staging, or a local stack with real migrations, one that
+  has the resource the change touches — and the `E2E` line carries a **link** to that run,
+  screenshot, or e2e; the merge queue does not approve a user-facing change without it, and a
+  green unit suite is not it. 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." A code path whose first execution is after merge — a
+  deploy workflow's inline step, a post-merge helper, a production-only resource — is untested
+  until the implementer has executed it against a devN stack; if no surface can reach it, the
+  tester names that missing surface as the blocker instead of passing the phase. 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. Environment or
   secret-scrub evidence (e.g. "`LEGION_*`/`DISPATCH_*`/`ENVOY_*` unset") is recorded once, in
   `.legion/test.json`, and only when the issue's acceptance criteria call for it — never
   re-pasted into the PR body each round.
@@ -264,6 +289,15 @@ Negative control: <deliberately broken input> → <refusal or failure observed>.
   `READY #<n> at <sha>` plus the PR body's gate facts to the merge queue's role
   (`notifications.role.pr-queue`) with `envoy_publish`. The merger never merges; the queue
   merges under its own authority.
+- **After the queue merges, the implementer verifies in production.** Sami, 2026-09-13,
+  verbatim: "the agent that developed it should be responsible for testing 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.
 
 ## Completion gate: handoff write, verification, and persistence
 
@@ -316,7 +350,9 @@ record of this issue's active phase. Do not add pipeline labels, run a controlle
 invent a different completion protocol — this is the whole contract.
 
 **Stay in this session afterward.** Your process does not exit when your phase completes;
-it goes idle in its pane. Other roles on this issue may reach you through Envoy with
+it goes idle in its pane, and after `worker_idle_retire_seconds` (default 600 s) idle with no
+active phase the daemon retires it — your next assignment resumes this same session from its
+session file, so it is still you. Other roles on this issue may reach you through Envoy with
 questions about the work you did — answer them, reading `$LEGION_WORKSPACE` and your own
 committed handoff as needed, without mutating anything (see Workspace and handoff
 precedence above). You will also be the one resumed, with a new prompt in this same