@sjawhar/opencode-legion-envoy 1.0.0 → 1.2.0

package/dist/src/server.js

@@ -13611,6 +13611,7 @@ var CommentEventPayloadSchema = object({
   reply_to: string2().nullish(),
   ask_id: string2().nullish(),
   ask_question: string2().optional(),
+  ask_state: _enum2(["open", "answered", "resolved"]).optional(),
   anchor: object({ quote: string2().optional() }).nullish(),
   suggestion: object({ replace_with: string2().optional() }).nullish(),
   author: object({ kind: string2(), id: string2() }).optional(),
@@ -14311,7 +14312,7 @@ function normalizeEnvoyUrl(value) {
 }
 
 // ../envoy-client/src/dispatch-config.ts
-import { readFileSync } from "fs";
+import { readFileSync as readFileSync2 } from "fs";
 import { homedir } from "os";
 import * as path from "path";
 
@@ -14320,6 +14321,21 @@ function messageFor(error) {
   return error instanceof Error ? error.message : String(error);
 }
 
+// ../envoy-client/src/secret-file.ts
+import { readFileSync } from "fs";
+function readSecretFile(variable, filePath) {
+  let contents;
+  try {
+    contents = readFileSync(filePath, "utf8");
+  } catch (error) {
+    throw new Error(`${variable} names ${filePath}, which could not be read: ${messageFor(error)}`);
+  }
+  const value = contents.trim();
+  if (value.length === 0)
+    throw new Error(`${variable} names ${filePath}, which is empty`);
+  return value;
+}
+
 // ../envoy-client/src/dispatch-config.ts
 var DEFAULT_SERVER_URL = "http://localhost:8766";
 function normalizeDispatchUrl(url2) {
@@ -14356,7 +14372,7 @@ function describeSchemaIssue(filePath, error) {
 function readEnvoyFile(filePath) {
   let raw;
   try {
-    raw = readFileSync(filePath, "utf-8");
+    raw = readFileSync2(filePath, "utf-8");
   } catch {
     return { kind: "absent" };
   }
@@ -14389,8 +14405,22 @@ function resolveDispatchConfig(env, options = {}) {
   };
   const rawUrl = explicitUrl !== undefined ? { value: explicitUrl, source: "DISPATCH_URL" } : merged.enabled === true ? { value: merged.serverUrl ?? DEFAULT_SERVER_URL, source: "dispatch.serverUrl" } : null;
   const url2 = rawUrl ? parsedDispatchUrl(rawUrl.value, rawUrl.source) : { url: null, error: null };
-  const token = env.DISPATCH_TOKEN ?? merged.token ?? null;
-  const tokenSource = env.DISPATCH_TOKEN === undefined ? "dispatch.token" : "DISPATCH_TOKEN";
+  let token;
+  let tokenSource;
+  if (env.DISPATCH_TOKEN_FILE !== undefined) {
+    tokenSource = "DISPATCH_TOKEN_FILE";
+    try {
+      token = readSecretFile(tokenSource, env.DISPATCH_TOKEN_FILE);
+    } catch (error) {
+      return { enabled: false, url: url2.url, token: null, error: messageFor(error) };
+    }
+  } else if (env.DISPATCH_TOKEN !== undefined) {
+    tokenSource = "DISPATCH_TOKEN";
+    token = env.DISPATCH_TOKEN;
+  } else {
+    tokenSource = "dispatch.token";
+    token = merged.token ?? null;
+  }
   if (url2.error !== null)
     return { enabled: false, url: null, token, error: url2.error };
   if (url2.url === null)

package/package.json

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

package/skills/dispatch/SKILL.md

@@ -118,6 +118,11 @@ in its Conversation card and reply thread. Resolution is not an answer: it never
 resolved. A human may reply to an open or answered ask; so may you, e.g. after finding the answer — use `reply_to_ask` on
 `dispatch_comment` (mutually exclusive with `reply_to`).
 
+A human reply while your ask is still open (the delivered `comment.created` carries `ask_state: open`) is a request for
+clarification, not an answer: the human did not understand the question or needs more before choosing. The ask now waits on you
+in their Inbox. Answer in the same thread with `dispatch_comment({ reply_to_ask })`, or reword the question itself with
+`dispatch_edit_ask` when the wording was the problem; either puts the ask back in front of them. Do not open a second ask.
+
 ## The Spec
 
 The spec holds requirements, design, acceptance, decisions, and rejected alternatives, structured per [Writing a spec](#writing-a-spec).

package/skills/legion-architect/SKILL.md

@@ -218,6 +218,7 @@ corresponding lifecycle procedure.
 | `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; `state: "approved"` proceeds toward retro (step 5) once the step 6 integration/merge-gate conditions are met. |
 | `pr-blocked` | 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. |
+| `pr-merged` | Payload `{type:"pr-merged", pr, mergeCommitSha}`. The merge queue landed the PR. This is your cue for step 7: post the sign-off comment naming that merge commit and set the issue `done`. Nothing else follows a merge. |
 | `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. 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. |

package/skills/legion-controller/SKILL.md

@@ -18,8 +18,9 @@ until that PR merges, this skill's contract is not yet runnable on `main`.
 The Legion extension claims `legion-<project>-controller` and registers controller readiness
 with the daemon during session startup. Do not handle a wake unless that startup succeeded.
 
-For an interactive takeover, start OMP with `LEGION_CONTROLLER_SECRET` and
-`LEGION_DAEMON_URL` in its environment, then run:
+For an interactive takeover, start OMP with `LEGION_CONTROLLER_SECRET` (or
+`LEGION_CONTROLLER_SECRET_FILE`, a path to a file holding it) and `LEGION_DAEMON_URL` in its
+environment, then run:
 
 ```text
 /legion-claim-controller

package/skills/legion-worker/SKILL.md

@@ -19,8 +19,9 @@ until that PR merges, this skill's contract is not yet runnable on `main`.
 
 The daemon spawns you as a separate `omp --mode rpc` process (behind `legion worker-shim`,
 in a tmux pane) with `LEGION_TREE`, `LEGION_ISSUE`, `LEGION_ROLE`, `LEGION_GENERATION`,
-`LEGION_BOOT_TOKEN`, `LEGION_DAEMON_URL`, `LEGION_STATE_DIR`, and `LEGION_WORKSPACE` in your
-environment (`LEGION_PROJECT` is also supplied, but nothing reads it). The extension
+`LEGION_BOOT_TOKEN_FILE` (a 0600 file under `$LEGION_STATE_DIR/secrets` holding your boot token;
+the extension reads it for you), `LEGION_DAEMON_URL`, `LEGION_STATE_DIR`, and `LEGION_WORKSPACE`
+in your environment (`LEGION_PROJECT` is also supplied, but nothing reads it). The extension
 completes the boot handshake for you at session start — it registers with the daemon, claims
 your role, and signals readiness. You never call `envoy_role_set` yourself.