@sjawhar/pi-legion-envoy 5.16.4 → 5.16.5

package/dist/legion.js

@@ -39253,7 +39253,7 @@ import { logger } from "@oh-my-pi/pi-utils";
 // package.json
 var package_default = {
   name: "@sjawhar/pi-legion-envoy",
-  version: "5.16.4",
+  version: "5.16.5",
   type: "module",
   omp: {
     extensions: [

package/dist/skills/dispatch/SKILL.md

@@ -154,7 +154,7 @@ exactly one owner to every owner-scoped tool: `issue` for an issue, or `project`
 that GitHub issue or pull request. Only `dispatch_issue` with `external` creates a native issue; if no issue is linked, call
 `dispatch_issue({ external: "owner/repo#n", project: "<project>", title: "<title>" })` before addressing it.
 
-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) and `assignee`: the lowercase GitHub login of the human who answers the issue's asks, or `null` when nobody holds it. `dispatch_read` of an issue prints it as `Assignee: <login>` or `Assignee: unassigned`.
+Issue reads include `rank`, the server-owned ordering key used by project boards; reorder through `PATCH /api/v1/issues/{key}` with `{"rank": {"before": "<key>", "after": "<key>"}}`, either neighbor optional and both in the issue's project. A bearer caller also names its own session in that body, `"actor": {"kind": "session", "id": "<your session id>"}`, or the server refuses with `ACTOR_KIND`. They also include nullable coarse priority (`P0` highest through `P3` lowest) and `assignee`: the lowercase GitHub login of the human who answers the issue's asks, or `null` when nobody holds it. `dispatch_read` of an issue prints it as `Assignee: <login>` or `Assignee: unassigned`.
 
 ### Who answers an ask
 
@@ -172,6 +172,36 @@ dispatch_issue({ project, title, parent?, external?, spec?, force?, labels?: str
 `details` `{ issue }`; creating an issue does not subscribe you to it (see [Following](#following)). 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).
 
+## Choosing what to work on
+
+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`
+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:
+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
+back to `backlog` as well: no claim or route held by a live session, no Dispatch activity in the
+last day, and no pull request moving on GitHub (an owner working there leaves no Dispatch trace).
+The order keeper sweeps those. Never write the status of an issue that carries the `legion`
+label, or of any issue under one: the Legion daemon writes those statuses, and moving one of its
+admitted roots out of its flow parks the tree 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.
+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.
+
 ## Claim the issue before you work it
 
 Two sessions once spent a night implementing the same issue, because nothing on it said who was
@@ -300,7 +330,7 @@ This is not search: it matches no text. Use `dispatch_search` for a keyword or p
 
 ### The owner audit
 
-As the owner of a surface, list your area's P0 and P1 issues and staff or close each one nobody
+As the owner of a surface, list the project's P0 and P1 issues and staff or close each one nobody
 has started:
 ```ts
 dispatch_issues({ project, priority: [0, 1], limit: 250 })

package/package.json

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