@sjawhar/opencode-legion-envoy 1.20.2 → 1.21.1

package/dist/src/server.js

@@ -13649,7 +13649,7 @@ var MessageEventPayloadSchema = object({
 });
 var DispatchTargetedMessagePayloadSchema = MessageEventPayloadSchema.extend({
   id: string2(),
-  issue_key: string2(),
+  issue_key: string2().nullable(),
   author: object({ kind: string2(), id: string2() }),
   body: string2(),
   target: string2(),
@@ -13662,6 +13662,7 @@ var MessageDeliveryEventPayloadSchema = object({
   attempt: number2().int().positive().optional(),
   delivery: _enum2(["btw", "aside", "steer"]).optional(),
   session_id: string2().optional(),
+  target: string2().optional(),
   title: string2().optional(),
   state: _enum2(["sent", "failed"]).optional(),
   error: string2().optional()
@@ -15634,17 +15635,18 @@ async function executeDispatchTool(input) {
     }
     case "dispatch_message": {
       const inReplyTo = messageInReplyTo(args);
-      const message = await client.message(issue(), {
+      const issueKey = issue();
+      const message = await client.message(issueKey, {
         body: stringArg(args, "body"),
         ...inReplyTo === undefined ? {} : { in_reply_to: inReplyTo },
         actor
       });
-      const messageRef = `dispatch://${message.issue_key}/message/${message.id}`;
+      const messageRef = `dispatch://${issueKey}/message/${message.id}`;
       return {
         text: `Posted message ${message.id} (${messageRef})`,
         details: {
-          issue: message.issue_key,
-          topic: dispatchIssueSubject(message.issue_key, ">"),
+          issue: issueKey,
+          topic: dispatchIssueSubject(issueKey, ">"),
           message: message.id
         }
       };

package/package.json

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

package/skills/envoy/SKILL.md

@@ -148,11 +148,16 @@ not construct a token from a partial issue reference.
 
 ## Legion exception lane
 
-`no_holder` and `delivery_failed` for a Legion role are daemon liveness signals, not reasons to
-add a second subscriber or manually retry. For example, treat a `delivery_failed` wake as the
-daemon's responsibility to revive or recreate the backing worker and re-deliver; otherwise it
-resurrects the root process with derived catch-up and the workspace handoffs. Raw delivery failures
-stay out of architect context.
+`no_holder`, `delivery_failed`, and `receipt_timeout` for a Legion role are daemon liveness
+signals, not reasons to add a second subscriber or manually retry. `no_holder`: no live session
+holds the role. `delivery_failed`: the message was not forwarded at all — the holder lookup
+failed, the holder was stale, or the publish errored. `receipt_timeout`: the listener forwarded
+the message to a registered, live holder and no receipt arrived inside the window; its payload
+keeps `original_topic`, `event_id`, `payload`, and the original `dedupe_key`, so the daemon can
+re-send the same message and the receiver's dedupe drops a copy that did arrive. Treat any of
+these wakes as the daemon's responsibility to revive or recreate the backing worker and
+re-deliver; otherwise it resurrects the root process with derived catch-up and the workspace
+handoffs. Raw delivery failures stay out of architect context.
 
 ## Slack
 

package/skills/legion-architect/SKILL.md

@@ -285,7 +285,11 @@ entire end-game sequence has completed.
 ## Wake routing
 
 Handle one delivered wake by verifying the relevant live artifact and then performing the
-corresponding lifecycle procedure.
+corresponding lifecycle procedure. Architect-addressed wakes always reach the architect that owns
+the payload issue: a claimed child sub-architect, otherwise the nearest claimed ancestor, then the
+root. A wake about an architect role's own launch reaches the architect above it. `phase-complete`,
+worker lifecycle, child lifecycle, and design-gate wakes are architect-only and never go to an
+active phase worker.
 
 | Wake | Procedure |
 | --- | --- |
@@ -305,8 +309,8 @@ corresponding lifecycle procedure.
 | `pr-merged` | Payload `{type:"pr-merged", pr, mergeCommitSha}`. The merge queue landed the PR. `spawn_worker` the **implementer** with the production-check task naming that merge commit (it resumes the same agent; a retired role has no live holder, so never `envoy_publish` for this). Its `phase-complete` is what brings you to step 7: verify the record on the pull request and this issue first, then sign off naming it and set the issue `done`. A merge is not the close. |
 | `pr-closed-unmerged` | Decide from current scope whether to reopen the work, send a fresh implementer, or cancel it with a reason. Delegate the repository action to the responsible phase worker and keep ownership. |
 | `issue-comment` | Interpret the comment in the issue's design context. Answer it, adjust the plan, or relay it via `envoy_publish` to the responsible worker's role token; scope and product decisions remain with you. |
-| `catchup-overseer` | Verify its gates, child counts, and PR verdicts against current artifacts, then resume the applicable numbered lifecycle step. It is a current-state snapshot, not a raw-event replay. `gates[LEGION_TREE].open` is the design gate's current state: `true` means the root spec is approved at its current version and you may spawn; `false` (or no `open` key, meaning no gate is registered) means the sequence in section 1 still applies. For each entry in its `phaseCompletions` (`{issue, role, summary, at}`, phases that completed while you were not live), handle it exactly as a `phase-complete` wake. Then compare `childCounts[LEGION_ISSUE].open` (the children not `done`) with `legion state` and Dispatch: any **open** released child — `todo` through `retro` — with no architect role claim gets `spawn_worker` for its architect, a `child-adopted` or `child-status` wake you missed while not live; a `done` child gets nothing, whether or not a lingering legacy tree of its own still shows in `legion state`. |
-| `worker-died` | Payload `{type:"worker-died", issue, role}`. The daemon probed and retried this role's worker through `MAX_LAUNCH_FAILURES` attempts and could not confirm a boot — never a raw-event replay or a silent revive. Reassess the work and `spawn_worker` again for the role (it resumes the same agent via `--resume` if a session file survived) or reassign it if the failure looks environmental, not agent-specific. |
+| `catchup-overseer` | Verify its child counts and PR verdicts against current artifacts, then resume the applicable lifecycle step. This is a current-state snapshot, not a raw-event replay. A root architect uses `gates[LEGION_TREE].open`: `true` means the root spec is approved and section 2 may continue; `false`, or no `open` key, means section 1 still applies. A resumed sub-architect receives `overseerCatchup(state, LEGION_ISSUE)` for its own subtree: its `gates` intentionally omits the root gate because a child spec is never gated. Do not request or register a gate; resume at section 2. Handle each `phaseCompletions` entry exactly as a `phase-complete` wake, then compare `childCounts[LEGION_ISSUE].open` with `legion state` and Dispatch before deciding the next action. |
+| `worker-died` | Payload `{type:"worker-died", issue, role}`. Two causes, one verdict: the daemon retried this role's boot through `MAX_LAUNCH_FAILURES` attempts and could not confirm it, or the worker booted and acknowledged every prompt without ever starting a turn through `MAX_PROMPT_RETIRES` retire-and-relaunch cycles (LEGION-93) — never a raw-event replay or a silent revive. Your next `spawn_worker` for the role is the retry (one cold launch, three prompts, and `worker-died` again if the agent is still broken). Reassess the work and `spawn_worker` again for the role (it resumes the same agent via `--resume` if a session file survived) or reassign it if the failure looks environmental, not agent-specific. |
 | `reopened` | Reopen the root lifecycle: inspect the reason and current artifacts, reassess scope and children, and resume at the first applicable numbered step. |
 
 ## Escalation judgment

package/skills/legion-retro/SKILL.md

@@ -45,7 +45,7 @@ before step 3. The design gate is not a substitute for review and retro.
 
 1. Re-read the issue, its acceptance criteria, the PR, test evidence, and review evidence.
    Confirm the PR carries both proofs: the implementer's own `E2E (implementer)` line and the tester's `E2E (tester)` line,
-   each naming a production-like surface (a scratch daemon, a smoke rig, a sandbox repository, a devN
+   each naming a production-like surface (the daemon's test harness (`packages/daemon/src/daemon/__tests__/`) and real-process fixtures; a live check at the operator's next daemon restart, recorded on the PR; a sandbox repository, a devN
    stack, staging, or a local stack with real migrations), a command or run id, an observation, a head
    SHA, and a negative control. If either is missing, or links only a unit suite, the retro's first
    durable learning is that gap and the issue goes back — to the implementer for its own proof, to the

package/skills/legion-worker/SKILL.md

@@ -22,13 +22,14 @@ completes the boot handshake for you at session start — it registers with the
 your role, and signals readiness. You never call `envoy_role_set` yourself.
 
 Your role token is not the issue key spelled out literally. The daemon encodes it as
-`legion-<project>-<KEY>-<role>`. For example, project `acme`, issue `LEGION-41`, role
-`architect` encodes to `legion-acme-LEGION-41-architect`. Never hand-format one for another
-role: your own role topic and your tree's architect's topic are stated at the end of your
-system prompt (a "Legion addressing" line the daemon appends), a sibling role's topic is
-yours with the trailing `-<role>` replaced, and the `roleToken` helper in `@legion/contracts`
-computes any other one exactly the way the daemon does — prefer a topic you've already
-been given before recomputing one.
+`legion-<project>-<KEY>-<role>`. For example, project `acme`, issue `LEGION-41`, role `architect`
+encodes to `legion-acme-LEGION-41-architect`. Never hand-format one for another role: your own role
+topic and the topic of the architect that owns your issue are stated at the end of your system
+prompt (a "Legion addressing" line the daemon appends: on a child issue that is the child's
+sub-architect when one is claimed, else the root's), a sibling role's topic is yours with the
+trailing `-<role>` replaced, and the `roleToken` helper in `@legion/contracts` computes any other
+one exactly the way the daemon does — prefer a topic you've already been given before recomputing
+one.
 
 If the handshake fails (a rejected boot token, or a bootstrap failure after your role
 registered), the extension logs it and exits the process outright — it does not retry, and
@@ -251,7 +252,7 @@ PR opens, and every later phase keeps it current rather than replacing it:
 ```
 ## Verification
 
-**CI:** `Tests` run <run-id> — jobs lint, pr-title, typecheck, test all success at <head-sha>.
+**CI:** `Tests` run <run-id> — jobs lint, typecheck, test all success at <head-sha>; `PR Title` run <run-id> — job pr-title success at <head-sha>.
 
 **Threads:** <n> resolved, 0 unresolved. Each disposed individually, never in bulk:
 - Thread <id>: fixed in <commit-sha> — <one line>.
@@ -276,6 +277,7 @@ Verified the implementer's proof by <re-running its command | driving the same s
 **Fast-follow:** <one named cleanup item and where it will land>, or "none".
 
 **Chain:** stacked on <base bookmark> frozen at <sha> / not stacked.
+**Retarget:** Retargeting a pull request to a new base does not re-run Tests; after a retarget, rebase onto the new base and push — the new head runs Tests against the new merge result — and cite that run in the PR body.
 ```
 
 - **Threads are dispositioned individually, never resolved in bulk.** Every open review
@@ -301,11 +303,11 @@ Verified the implementer's proof by <re-running its command | driving the same s
   changes behavior, hides an error, or breaks a gate is fixed here — never deferred.
   Findings about naming, duplication, or wording are batched into the single `Fast-follow`
   line instead of iterating per push.
-- **Rebase only on a real conflict.** Sami, 2026-09-11, verbatim:
+- **Rebase only on a real conflict, except after a base retarget.** Sami, 2026-09-11, verbatim:
   "Please don't do unnecessary rebases (i.e. unless there are merge conflicts). The CI queue is too long and slow."
-  The implementer rebases the issue branch only when GitHub reports it `CONFLICTING` or the
-  controller asks because of a conflict — never to pick up `main` or to refresh CI. A single
-  failed CI job is re-run on its own with `legion gh -- run rerun <run-id> --failed`, never by
+  The implementer rebases the issue branch only when GitHub reports it `CONFLICTING`, the controller asks
+  because of a conflict, or after the pull request is retargeted to a new base. Otherwise, never rebase to
+  pick up `main` or refresh CI. A single failed CI job is re-run on its own with `legion gh -- run rerun <run-id> --failed`, never by
   pushing a new commit. A conflict-forced rebase that leaves the branch's diff unchanged is a
   confirmation, not a new round (see *The unchanged-diff check* below). Before rebasing, record
   the fingerprint at the current tip; after pushing the rebased branch, record it at the new
@@ -317,9 +319,10 @@ Verified the implementer's proof by <re-running its command | driving the same s
   field names naming, duplication, or wording cleanup only; anything that changes behaviour,
   hides an error, or breaks a gate lands in this PR.
 - **The implementer proves the change before its phase completes, and writes the `E2E (implementer)` line when the pull request opens.**
-  The proof is the changed behaviour exercised on the surface a user reaches it through — a
-  scratch daemon, a smoke rig, a sandbox repository, a real browser, a devN stack, a local stack
-  with real migrations — with the exact command or run id, what was observed, the head SHA, and
+  The proof is the changed behaviour exercised on the surface a user reaches it through — the daemon's
+  test harness (`packages/daemon/src/daemon/__tests__/`) and real-process fixtures; a live check at the
+  operator's next daemon restart, recorded on the PR; a sandbox repository, a real browser, a devN stack,
+  or a local stack with real migrations — with the exact command or run id, what was observed, the head SHA,
   one negative control. The same proof goes into `.legion/implement.json` as its required `proof`
   array (`legion handoff write --phase implement` refuses a payload without one and names the
   field), and into the PR body, because the reviewer and the merger verify facts on GitHub and