@sjawhar/opencode-legion-envoy 5.0.0 → 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.0",
+  "version": "5.0.2",
   "type": "module",
   "main": "dist/src/server.js",
   "exports": {

package/skills/AGENTS.md

@@ -21,6 +21,6 @@ event intake, process lifecycle, credentials, and role delivery.
 The owning skill above is where each contract is defined; a role prompt that needs a contract from its own seat points there or restates only its own step. This file lists and does not restate.
 A Legion prompt (a skill here, a role prompt, or an agent definition in `packages/pi-envoy/agents/`) names a task agent only as `task(agent="<name>")` and a skill it tells the model to load only as `skill://<name>`. Those are the two forms the Go daemon's boot gate and `legion probe-image` resolve through Oh My Pi, refusing by name one it cannot find; a dispatch or a load written any other way goes unchecked. An agent or skill Legion's prompts name is shipped here or in `packages/pi-envoy/agents/`, unless Oh My Pi bundles it.
 A skill file an agent loads stays under 51,200 bytes, Oh My Pi's spill threshold (a longer one arrives with its middle cut out), and a skill's detail lives in `references/` files linked as `skill://<name>/references/<file>.md`, never by relative path, which a read by path cuts at 300 lines. `packages/pi-envoy/src/skills-guard.test.ts` fails on a file at the threshold, on any `SKILL.md` body of 500 lines or more, on a skill whose frontmatter `name` is not its directory's name, on a `dispatch-first` over its budget, on a `skill://<name>/<path>` link that names a missing file or a missing `#heading`, and on a `legion-worker` reference nothing links.
-The text a worker boots with (its role prompt) lives in `packages/pi-envoy/roles/` and is
-composed per role in `packages/daemon/src/daemon/processes.ts`; `packages/pi-envoy/roles/roles.test.ts`
-holds the structural rules for those parts.
+The text a worker boots with (its role prompt) lives in `packages/daemon/internal/prompts/roles/`,
+embedded in the `legion` binary and composed per role by `packages/daemon/internal/prompts/prompts.go`;
+`packages/daemon/internal/prompts/roles_test.go` holds the structural rules for those parts.

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

package/skills/legion-worker/SKILL.md

@@ -317,7 +317,7 @@ line), the full definition of a proof, what the tester verifies, and the simplif
 ## Completion gate: handoff write, verification, and persistence
 
 The merger writes no handoff and pushes nothing, so this gate does not apply to it
-(`packages/pi-envoy/roles/merger.md`).
+(`packages/daemon/internal/prompts/roles/merger.md`).
 
 Write the phase-specific handoff: call the `legion` tool with `op: "handoff_write"`, `phase: "<p>"`,
 and `data`: a JSON object of the phase-specific fields only. It runs `legion handoff write` in

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

@@ -73,12 +73,12 @@ completion leaves the issue in reviewing until you finish.
   in READY (an empty output is quoted as `no file changes above the approved head`); then the same
   with `'~docs/solutions'` appended, which must print nothing. *The READY packet*: the merger
   always posts `READY #<n> at <current sha> (approved at <approved sha>) for <KEY> (<pr url>)`
-  (the shape `packages/pi-envoy/roles/merger.md` defines), then the PR body's `Outcome:` line and
-  its `Not proven / risk:` value — every bullet under that label joined with `; ` on the one
-  READY line, or `none` — quoted from the `## For the reviewer` block at that same head (or one
-  line saying the body carries no brief — the packet still publishes), then the `--summary`
-  output and the PR body's gate facts, as a `dispatch_message` on the issue. When the `Legion
-  addressing` line names a merge queue, it also publishes the same packet there with
+  (the shape `packages/daemon/internal/prompts/roles/merger.md` defines), then the PR body's
+  `Outcome:` line and its `Not proven / risk:` value — every bullet under that label joined with
+  `; ` on the one READY line, or `none` — quoted from the `## For the reviewer` block at that same
+  head (or one line saying the body carries no brief — the packet still publishes), then the
+  `--summary` output and the PR body's gate facts, as a `dispatch_message` on the issue. When the
+  `Legion addressing` line names a merge queue, it also publishes the same packet there with
   `envoy_publish`; a 404 means the Dispatch message remains the durable notice and the merger
   stays idle. The READY packet names both the implementer's and tester's `E2E` lines; a missing
   one is reported to the architect instead of published. Legion never merges.