@sjawhar/opencode-legion-envoy 1.39.0 → 1.40.0

package/dist/src/server.js

@@ -14277,12 +14277,19 @@ var stateIssue = strictObject({
   parent: nonEmptyString.optional(),
   lastAppliedSeq: number2().int().nonnegative().optional()
 });
+var stateWorkspaceLost = strictObject({
+  at: nonEmptyString,
+  generation: number2().int().nonnegative(),
+  fromRef: nonEmptyString,
+  previousSessionId: nonEmptyString.optional()
+});
 var stateTree = strictObject({
   status: _enum2(TREE_STATUSES),
   generation: number2().int().nonnegative(),
   launchFailures: number2().int().nonnegative(),
   readyConfirmedAt: number2().optional(),
-  locator: stateTreeLocator.optional()
+  locator: stateTreeLocator.optional(),
+  workspaceLost: stateWorkspaceLost.optional()
 });
 var stateGate = strictObject({
   artifactId: nonEmptyString,
@@ -14296,7 +14303,8 @@ var stateRole = strictObject({
   sessionId: nonEmptyString.optional(),
   readyConfirmedAt: number2().optional(),
   launchFailures: number2().int().nonnegative().optional(),
-  locator: stateLocator.optional()
+  locator: stateLocator.optional(),
+  workspaceLost: stateWorkspaceLost.optional()
 });
 var stateQueuedWorkerIdentity = {
   roleToken: nonEmptyString,
@@ -14335,7 +14343,8 @@ var LegionDaemonApi = {
     request: strictObject({
       secret: nonEmptyString,
       sessionId: nonEmptyString,
-      ompSessionFile: nonEmptyString.optional()
+      ompSessionFile: nonEmptyString.optional(),
+      pluginVersion: nonEmptyString
     }),
     response: object({})
   },
@@ -14350,7 +14359,8 @@ var LegionDaemonApi = {
       rootSessionId: nonEmptyString,
       agentId: nonEmptyString,
       bootToken: nonEmptyString,
-      ompSessionFile: nonEmptyString
+      ompSessionFile: nonEmptyString,
+      pluginVersion: nonEmptyString
     }),
     response: object({
       roleTokens: record(string2(), string2()),
@@ -14392,7 +14402,8 @@ var LegionDaemonApi = {
       bootToken: nonEmptyString,
       sessionId: nonEmptyString,
       agentId: nonEmptyString,
-      ompSessionFile: nonEmptyString
+      ompSessionFile: nonEmptyString,
+      pluginVersion: nonEmptyString
     }),
     response: object({
       roleToken: nonEmptyString,

package/package.json

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

package/skills/legion-architect/SKILL.md

@@ -308,6 +308,7 @@ active phase worker.
 | `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`. `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. |
+| `worker-recovered` | Payload `{type:"worker-recovered", issue, role, fromRef, delivery?}`. The worker's tree volume was lost and the daemon replaced it from the committed handoff on `fromRef`. `delivery: "spawned"` means the current assignment was preserved on the new worker; do not resend it. `delivery: "queued"` means that preserved assignment awaits capacity; wait for `worker-started`. Without `delivery`, inspect `.legion/` and the active phase before deciding whether work needs a new assignment. |
 | `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. |
 | `pr-blocked` | Payload `{type:"pr-blocked", pr, attempts}`. `attempts` counts heads pushed onto a red verdict that changed something outside `.legion/` — handoff-only pushes (`.legion/` paths only) never count; a push the daemon cannot classify (a listener without `changed_paths`, a list capped at 100, a push listing no commits) does. Published once per exhausted count, not on every later red verdict for that count. Read the failed CI evidence and recovery attempts. Assign a focused implementer or corrective child, then return it through testing and review; do not treat the blocked PR as final. |

package/skills/legion-controller/SKILL.md

@@ -112,6 +112,7 @@ quoted here.
 | `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 |
 | READY packet seen on a Dispatch issue (via issue subscription) | READY line + gate facts | No action: a human merges; the merger has already notified the queue role if the project has one |
+| `worker-recovered` (role `architect`) from the daemon | issue, fromRef | A root architect's tree volume was lost; it restarted as a new session. Verify the tree is active in `legion state` and that the architect posts its next step on the issue within one resync interval; otherwise treat it as an anomaly. |
 | Closed-tree activity (comment, review, CI on a closed tree) | issue, root, event summary | Read the artifact; if work should resume, `legion status <root> todo`; otherwise no action — the event is not held or redelivered |
 | Direct user message | — | Always first |
 

package/skills/legion-worker/SKILL.md

@@ -111,6 +111,10 @@ predecessor phases already wrote. The durable copy lives in
 `$LEGION_WORKSPACE/.legion/<phase>.json`. If a committed handoff conflicts with memory or a prior
 transcript, the committed file wins: it is the copy that survived.
 
+If your system prompt begins with `Your workspace was recreated…`, read
+`.legion/workspace-recovered.json`, then your phase's committed handoff, and reconcile before any
+new work.
+
 ## jj Safety Rules
 
 - **Always `jj -R "$LEGION_WORKSPACE" new` to create isolated commits.** Never