@sjawhar/opencode-legion-envoy 1.54.0 → 1.55.1

package/dist/src/server.js

@@ -14404,12 +14404,6 @@ var phaseHandoffSchema = exports_external.discriminatedUnion("phase", [
   testSchema,
   reviewSchema
 ]);
-var handoffMessageSchema = exports_external.object({
-  from: handoffPhase,
-  to: handoffPhase,
-  body: exports_external.string(),
-  timestamp: isoTimestamp
-});
 // ../contracts/src/subject.ts
 var AGENT_TOPIC_PREFIX = "notifications.agent.";
 var DISPATCH_TOPIC_PREFIX = "notifications.dispatch.";

package/package.json

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

package/skills/legion-controller/SKILL.md

@@ -59,23 +59,26 @@ command run `/legion-claim-controller` again.
 This handshake lets the daemon redeliver held controller work. It does not turn the controller
 into a state holder: daemon state and the Dispatch project remain authoritative.
 
-### Started by the operator (runtime: kubernetes)
-
-When the daemon runs inside a Kubernetes cluster it cannot open a terminal anywhere, so nobody
-launched your pane: the operator ran `legion controller start --config controller.yaml
-[--daemon-url <port-forward>]` on their own machine, and you are that foreground OMP session.
-The command fetched a fresh controller secret from the daemon with the operator's token, wrote it
-to a 0600 file under `LEGION_STATE_DIR` (`~/.local/state/legion/<project>-controller` by default)
-beside the `gh` shim and the `legion` launcher, and started you with `LEGION_CONTROLLER=1` and
-the same environment a tmux controller pane carries — so the extension claims the role and calls
-`/controller/ready` exactly as under tmux, and nothing changes in how you handle wakes. The
-daemon records you as `controllerLocator: {runtime: "kubernetes", external: true, sessionId,
-registeredAt}` and reads your liveness from the Envoy role registry (the holder of
+### Started by the operator
+
+When the daemon cannot open a terminal for you — the TypeScript daemon under `runtime: kubernetes`,
+and the Go daemon under either runtime, since it launches no controller — nobody launched your
+pane: the operator ran `legion controller start --config controller.yaml [--daemon-url <url>]` on
+their own machine, and you are that foreground OMP session. The command fetched a fresh controller
+secret from the daemon with the operator's token, wrote it to a 0600 file under `LEGION_STATE_DIR`
+(`~/.local/state/legion/<project>-controller` by default) beside the `gh` shim and the `legion`
+launcher, and started you with `LEGION_CONTROLLER=1` and the same environment a tmux controller pane
+carries, so nothing changes in how you handle wakes. Under the TypeScript daemon the extension
+claims the role and calls `/controller/ready` exactly as under tmux; under the Go daemon
+(`LEGION_DAEMON_API=go` in your environment) it registers on `/legion/v1/claims/register` with the
+secret, then claims the role. The daemon records you as `controllerLocator: {runtime, external:
+true, sessionId, registeredAt}`, `runtime` being the daemon's own (`kubernetes`, or `tmux` under the
+Go daemon). The TypeScript daemon reads your liveness from the Envoy role registry (the holder of
 `legion-<project>-controller` and its `last_seen`), not from a pane: keep the session running.
 Exiting it leaves the project without a controller until the operator runs the command again —
-the daemon logs `controller not registered; run legion controller start` once per boot-timeout
-interval and launches nothing itself. `legion state` and `legion status <KEY> <status>` work here
-over `LEGION_DAEMON_URL` (the port-forward). A second `legion controller start` replaces you: it
+the TypeScript daemon logs `controller not registered; run legion controller start` once per
+boot-timeout interval and launches nothing itself. `legion state` and `legion status <KEY>
+<status>` work here over `LEGION_DAEMON_URL`. A second `legion controller start` replaces you: it
 mints a new secret, so your grants stop working and the role moves to the new session.
 
 ## Deployment instructions

package/skills/legion-worker/SKILL.md

@@ -507,6 +507,14 @@ Write the phase-specific handoff: call the `legion` tool with `op: "handoff_writ
 and `data`: a JSON object of the phase-specific fields only. It runs `legion handoff write` in
 `$LEGION_WORKSPACE` and returns its output.
 
+A handoff built from the one already on disk (a test handoff that accumulates review rounds can
+pass 128 KiB) can instead be piped from bash, so you never re-emit the whole payload:
+`cd -- "$LEGION_WORKSPACE" && bun -e 'const h = await Bun.file(".legion/<phase>.json").json(); delete h.schemaVersion; delete h.phase; delete h.completed; <your edit to h>; console.log(JSON.stringify(h))' | legion handoff write --phase <phase>`.
+The program is single-quoted, so strings in your edit take double quotes. It is `bun` because the
+worker image a pod runs ships `bun` and not `jq`, and a devbox pane has the `bun` Legion builds
+with. With `--data` omitted, `legion handoff write` reads the JSON object from stdin. The CLI adds
+`schemaVersion`, `phase` and `completed` itself and refuses them in the data, hence the `delete`s.
+
 `handoff_write` validates the payload against the phase's schema before writing: an
 implement handoff without a well-formed `proof`, or a test handoff that reports no failure and
 carries no `proof` of its own, exits 1 naming the field and writes nothing.
@@ -558,9 +566,9 @@ approved head and restarts the review loop this rule exists to end.
 ## Completion: report to the architect, then stay
 
 Report completion to the architect: call the `legion` tool with `op: "handoff_complete"` and
-`summary`: two sentences for the architect. A worker never runs `legion handoff` from bash: the
-tool call is what the extension records, and a turn that ends with the phase still open gets one
-reminder.
+`summary`: two sentences for the architect. A worker never runs `legion handoff complete` from
+bash, where the extension refuses it: the tool call is what the extension records, and a turn that
+ends with the phase still open gets one reminder.
 
 This publishes your phase's completion to the architect's role and clears the daemon's
 record of this issue's active phase. Do not add pipeline labels, run a controller loop, or