@sjawhar/opencode-legion-envoy 1.21.1 → 1.23.0

package/dist/src/server.js

@@ -14194,6 +14194,19 @@ var stateRole = strictObject({
   launchFailures: number2().int().nonnegative().optional(),
   locator: stateLocator.optional()
 });
+var stateQueuedWorkerIdentity = {
+  roleToken: nonEmptyString,
+  issue: nonEmptyString,
+  role: nonEmptyString
+};
+var stateQueuedWorker = union([
+  strictObject(stateQueuedWorkerIdentity),
+  strictObject({
+    ...stateQueuedWorkerIdentity,
+    kind: _enum2(["assignment", "catchup"]),
+    queuedAt: nonEmptyString
+  })
+]);
 var LegionDaemonApi = {
   State: {
     response: strictObject({
@@ -14210,7 +14223,8 @@ var LegionDaemonApi = {
       controllerLocator: stateLocator.optional(),
       roles: record(string2(), stateRole),
       controllerPendingNotices: number2().int().nonnegative(),
-      pendingStatusWrites: array(nonEmptyString)
+      pendingStatusWrites: array(nonEmptyString),
+      workerAdmission: strictObject({ queue: array(stateQueuedWorker) })
     })
   },
   ControllerReady: {
@@ -14297,7 +14311,8 @@ var LegionDaemonApi = {
     request: architectCapability.extend({
       issue: nonEmptyString,
       role: legionRole,
-      task: nonEmptyString
+      task: nonEmptyString,
+      requestId: uuid2()
     }),
     response: object({
       status: _enum2(["spawned", "resumed", "queued"]),
@@ -16031,10 +16046,16 @@ class EnvoyApiError extends Error {
     this.expected = parsed?.expected;
   }
 }
+function resolveEnvoyToken(env) {
+  const { ENVOY_TOKEN_FILE: file, ENVOY_TOKEN: plain } = env;
+  if (file !== undefined && file !== "")
+    return readSecretFile("ENVOY_TOKEN_FILE", file);
+  return plain || undefined;
+}
 function createEnvoyClient(config) {
   const baseUrl = normalizeEnvoyUrl(config.baseUrl);
   const timeoutMs = config.timeoutMs ?? DEFAULT_TIMEOUT_MS;
-  const { ENVOY_TOKEN: apiToken } = process.env;
+  const apiToken = resolveEnvoyToken(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.21.1",
+  "version": "1.23.0",
   "type": "module",
   "main": "dist/src/server.js",
   "exports": {

package/skills/legion-architect/SKILL.md

@@ -301,7 +301,7 @@ active phase worker.
 | `design-approved` | Payload `{type:"design-approved"}`. A human approved the root spec document at its current version; the gate is open. Proceed to section 2. |
 | `design-changes-requested` | Payload `{type:"design-changes-requested", version, reason, author?}`. A human asked for changes to the root spec at `version`, for `reason`. Revise the spec, call `dispatch_request_approval` again, and stay parked; the gate is closed. |
 | `phase-complete` | Payload `{type:"phase-complete", issue, role, summary}`. May arrive live or via `catchup-overseer`'s `phaseCompletions`. Read the committed handoff for that phase, then spawn the next phase's owner, or `spawn_worker` on the same role again to resume it with corrections if the handoff shows unresolved gaps. A `reviewer` completion whose GitHub review is `CHANGES_REQUESTED` (the daemon returns the issue's Dispatch status to `in_progress` for this, on the reviewer's completion and again when you spawn the corrective implementer unless the daemon already knows the issue is `in_progress`) means `spawn_worker` the **implementer** again with the review findings — thread URLs and blocking items — as its task, then route back through tester and reviewer in order; never `spawn_worker` the reviewer directly off this wake and never proceed to retro on this verdict. A reviewer completion with an `APPROVED` review proceeds to retro (step 5). A `reviewer` completion after a conflict-forced rebase whose review body names an unchanged fingerprint is a confirmation, not a round: if retro already completed, `spawn_worker` the merger; otherwise resume the step you were on. An `implementer` completion that follows the merge is its production report: read the record on the pull request and the issue, then run step 7 — the issue is already at `retro`, the daemon writes no status for this completion, and you set `done` yourself. A `tester` completion whose handoff carries `implementerProof.verdict: "rejected"`, or a failure naming the production-like proof, goes back to the **implementer** with that finding — never forward to the reviewer, and never by supplying the proof from another role. A worker that reports no surface reaches the changed path gets a child issue in this tree (infrastructure, tooling, or a skill) and a resume once it lands; that report is never a reason to advance the phase. |
-| `worker-queued` | Payload `{type:"worker-queued", issue, role}`. This role's task is queued for promotion — either the deployment's worker cap is full, or the live worker acknowledged the task without starting a turn and the daemon is retrying it (counted; the worker is replaced after three such failures, still with the same task). Do not respawn or retry — wait for `worker-started`. |
+| `worker-queued` | Payload `{type:"worker-queued", issue, role}`. This role's task is queued for promotion — either the deployment's worker cap is full, or the live worker acknowledged the task without starting a turn and the daemon is retrying it (counted; the worker is replaced after three such failures, still with the same task). Do not respawn or retry — wait for `worker-started`. `legion state` shows the queue (`workerAdmission.queue`: role token, issue, role, kind, and the time the task was first queued — never the task text); read it before re-sending. A `spawn_worker` identical to the queued task changes nothing and is not announced again. Different text replaces the queued task silently in the same FIFO slot and retains its original queue time. A `spawn_worker` that fails with "got no response in 3 attempts" was already retried by the plugin under one request id and may still have reached the daemon: read the queue and the role's claim in `legion state` before sending it again. |
 | `worker-started` | Payload `{type:"worker-started", issue, role}`. A previously queued role has been promoted and is now running. Treat it exactly as a normal spawn: resume tracking that role's live session. |
 | `pr-ready` | Verify the live PR head, green status, and review state. Continue the review/retro/merger order only for that current head. |
 | `pr-review` | Payload `{type:"pr-review", state, author, body}`. Delivered to whichever role is currently active for the issue, falling back to you when no worker phase is active. Follows the same verdict rule as a reviewer's `phase-complete`: `state: "changes_requested"` sends the implementer back in with the review findings, then tester, then reviewer — never the reviewer again and never retro; that `spawn_worker` returns the issue to `in_progress` on its own (the daemon writes it for a corrective implementer whenever the PR's latest recorded review is changes requested, a human's after approval included), so you set nothing by hand; `state: "approved"` proceeds toward retro (step 5) once the step 6 integration/merge-gate conditions are met. `state: "approved"` on a rebased head whose body names an unchanged fingerprint is that confirmation: proceed to retro if it has not run, otherwise to the merger — never to a second retro or test round. |

package/skills/legion-controller/SKILL.md

@@ -62,7 +62,8 @@ override a Sami ruling quoted here.
 | New issue created in the Dispatch project (`issue.created`, status `triage`; resync heals misses) | issue key + triage context (incl. pre-existing children) | Triage: `legion({ op: "set_status", issue, status: "todo" })` to admit, or set `backlog`/`icebox` to park |
 | Backlog eligibility | slot freed / priority change | Reconsider parked items and move the eligible root to `todo` |
 | Architect escalation (controller-actionable only: re-file a child as a root issue, capacity, cross-tree conflicts) | request + context | Judge and act; issue-scoped human Q&A goes through `dispatch_ask` from the owning architect, not here |
-| Resync report | artifact-driven anomaly list (zero-owner trees, untriaged-open, launch-failed) | Verify against fresh state, then heal |
+| Resync report | artifact-driven anomaly list (zero-owner trees, untriaged-open, launch-failed, admission-drift) | Verify against fresh state, then heal |
+| Resync report: `admission-drift` entry | issue key + whether the daemon added it to, or removed it from, its admission list (the detail says which) | No action: the daemon already repaired it in the same run. An issue that reappears in consecutive reports is a live leak — file a LEGION issue on Dispatch with both reports pasted as evidence (never a GitHub issue) |
 | `child-status` | child key + status transition | Not controller-actionable by default; if the daemon could not route it to the parent's architect role, verify the transition and forward it with `envoy_publish` |
 | Mention | Slack/GitHub PR @mention text | Answer, or route to the owning issue's architect role |
 | Closed-tree activity (comment, review, CI on a closed tree) | issue, root, event summary | Read the artifact; if work should resume, `legion({ op: "set_status", issue: root, status: "todo" })`; otherwise no action — the event is not held or redelivered |
@@ -124,7 +125,10 @@ Treat a resync report as an anomaly list, not an instruction. For every zero-own
 untriaged-open, or launch-failed issue it names, verify `legion state --json` and the
 current Dispatch issue first. Then heal the verified condition: admit an eligible root, move
 an issue back to its intended status, or use the applicable daemon control path. Do not act
-on stale entries until their source artifact explains the anomaly.
+on stale entries until their source artifact explains the anomaly. An `admission-drift` entry
+needs no healing — the daemon added the tree back to (or removed it from) its admission list in
+the same run; verify only that the same issue does not recur in the next report, and file a
+LEGION issue with both reports if it does.
 
 ## Mentions