@sjawhar/opencode-legion-envoy 1.14.1 → 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()
 });
@@ -13762,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()
     })
   },
   {
@@ -15208,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")}`],
@@ -15345,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({
@@ -15354,6 +15360,7 @@ async function executeDispatchTool(input) {
           ...external === undefined ? {} : { external },
           ...force === undefined ? {} : { force },
           ...spec === undefined ? {} : { spec },
+          ...priority === undefined ? {} : { priority },
           ...Array.isArray(labels) ? { labels } : {},
           actor
         });

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sjawhar/opencode-legion-envoy",
-  "version": "1.14.1",
+  "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).
 

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.

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,6 +55,13 @@ 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
@@ -242,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.
@@ -266,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