@sjawhar/opencode-legion-envoy 5.0.1 → 5.0.2

package/dist/src/server.js

@@ -14316,7 +14316,7 @@ var dispatchToolSpecs = [
   },
   {
     name: "dispatch_issues",
-    example: { project: "AGENTC", limit: 250, offset: 250 },
+    example: { project: "PROJ", limit: 250, offset: 250 },
     description: "List a project's issues for a roadmap or backlog pass: every issue in one project, each carrying " + "its status, priority, parent, labels, open-ask count, and route with whether it reaches anyone, " + "so you can see backlog shape without opening every issue. Optionally filter by status, parent, " + "label, priority, route status, or how recently it changed; priority takes one or more of 0-3 " + "(P0-P3) and null for an issue with no priority, so an owner's P0/P1 audit is priority [0, 1]. " + 'route_status "no_holder" lists every open issue whose route names a role nobody holds or a ' + "session that is not running at the moment of the read, whatever its priority. A restarting " + "session is absent for minutes, so an issue is unowned only when a read ten minutes later agrees. " + "Do not use it to search by keyword or phrase; dispatch_search remains the keyword surface. " + "Dispatch pages the list: limit sets the page size (default " + `${DEFAULT_ISSUE_PAGE_LIMIT}, max ${MAX_ISSUE_PAGE_LIMIT}) and offset selects where it starts ` + "(default 0), and the answer names how many issues match, so repeat with the next offset to " + "walk every matching issue. A walk is exact only while the list does not change: an issue " + "that enters or leaves what the filters match, or whose status or rank changes, between two " + "pages shifts rows across a page boundary, so one issue can come back twice and another never.",
     arguments: (z2) => ({
       project: z2.string().describe("Project key to list issues from."),

package/package.json

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

package/skills/dispatch/references/brainstorming.md

@@ -43,10 +43,10 @@ do corrections to it. Neither your model nor theirs is the starting truth.
 
 ## A worked example
 
-`dispatch://AGENTC-1563/artifact/spec` is the secrets broker's identity model. Its first version
+Take the spec for the secrets broker's identity model. Its first version
 held the problem, the human's words, what exists today, and the one question that was ready then;
 it also called itself "a conversation", which the human struck as commentary. Each later version
 folds the answers in with the human's words and date and adds the questions they open. Its first
-approval request, on `dispatch://AGENTC-1563/artifact/spec@v35`, named four inferences the human
+approval request, on the spec's version 35, named four inferences the human
 had never discussed; the human rejected it, and each of the four was then either put to the human
 as its own decision block or taken out of the spec.

package/skills/dispatch/references/issues.md

@@ -9,14 +9,13 @@ 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 (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.
+else (Sami's ruling). `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 (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:
+kind (Sami's ruling). The limit is per agent and has nothing to do with the week's priorities
+(Sami, correcting a reading that tied the two together): 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
@@ -28,9 +27,9 @@ writes on the root of a tree Legion is running is set back and the tree's archit
 it; only a person in the dashboard, or `legion status`, stops that tree. On an issue under one, a
 status that takes it out of the flow parks that issue and stops its workers.
 
-One agent keeps the backlog's order against those priorities, with Sami
-(dispatch://AGENTC-34/ask/f6780f9e-8b96-49eb-9be7-7c7f2036d5cc). Setting an issue's priority
-stays yours ([Priority is yours to set](#priority-is-yours-to-set)); reordering the board does not.
+One agent keeps the backlog's order against those priorities, with Sami, as he ruled. Setting an
+issue's priority stays yours ([Priority is yours to set](#priority-is-yours-to-set)); reordering
+the board does not.
 When the top of the backlog looks wrong, or a priority's next step is not yet a ready issue,
 publish it to `notifications.role.backlog-order`, which the order keeper holds, instead of
 reordering the board yourself.
@@ -88,11 +87,11 @@ 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
-dispatch_issue_update({ issue: "AGENTC-175", status: "testing" })
-dispatch_issue_update({ issue: "AGENTC-175", status: "done", reason: "Shipped in owner/repo#7; verified on the production dashboard." })
-dispatch_issue_update({ issue: "AGENTC-175", priority: 1 }) // 0–3; see Priority is yours to set
-dispatch_issue_update({ issue: "AGENTC-175", external_links: ["https://github.com/owner/repo/pull/7"] })
-dispatch_issue_update({ issue: "AGENTC-175", parent: "AGENTC-170" }) // same-project key; "" clears the parent
+dispatch_issue_update({ issue: "PROJ-175", status: "testing" })
+dispatch_issue_update({ issue: "PROJ-175", status: "done", reason: "Shipped in owner/repo#7; verified on the production dashboard." })
+dispatch_issue_update({ issue: "PROJ-175", priority: 1 }) // 0–3; see Priority is yours to set
+dispatch_issue_update({ issue: "PROJ-175", external_links: ["https://github.com/owner/repo/pull/7"] })
+dispatch_issue_update({ issue: "PROJ-175", parent: "PROJ-170" }) // same-project key; "" clears the parent
 ```
 
 Closing takes a `reason`, and the tool refuses `status: "done"` without one: it posts the reason on

package/skills/legion-controller/SKILL.md

@@ -197,7 +197,7 @@ dispatch_issues({ project: "<PROJECT>", status: "todo", priority: [0], limit: 25
 
 When the first line ends `(showing 1-250 of N)`, the next page is `offset: 250`, then `500`. Read
 pages only as far as you need: stop listing once the free slots are filled. `<PROJECT>` is the
-Dispatch project key, the prefix of this deployment's issue keys (`AGENTC-12` → `AGENTC`), which is
+Dispatch project key, the prefix of this deployment's issue keys (`PROJ-12` → `PROJ`), which is
 also `daemon.project` in `legion state --json`: the project key exactly as `legion.yaml` writes it.
 A row that shows `claimed by …` and does not end its claim with `· not running` (the route, when
 the row shows one, comes after the claim) is claimed, as the table below says: skip it without