@sjawhar/opencode-legion-envoy 5.11.2 → 6.0.0

package/dist/src/server.js

@@ -15809,7 +15809,7 @@ function followsAsk(owner) {
   return `You follow this ask: its answer and replies reach you directly. For every event on ${owner.label}: envoy_subscribe ${owner.topic}`;
 }
 var triageAdviceShown = new Set;
-var SPEC_CHECK_REMINDER = 'Has a fresh reader checked this spec? Each claim about how a system works today should trace to code read or a command run, and each requirement to the human\'s words or a cited fact. If not, have a fresh read-only subagent (`plan-gap-analyst` on Oh My Pi) check it now and fix what it finds. See the `dispatch-first` skill, "Design in the spec".';
+var SPEC_CHECK_REMINDER = 'Has a fresh reader checked this spec? Each claim about how a system works today should trace to code read or a command run, and each requirement to the human\'s words or a cited fact. If not, have a fresh read-only subagent check it now and fix what it finds: on Oh My Pi, `task(agent="scout")`, or whatever read-only agent your host bundles; a Legion architect\'s own spec uses the Legion plugin\'s `plan-gap-analyst` agent instead, which only a Legion session has. See the `dispatch-first` skill, "Design in the spec".';
 function renderAdvice(tool, key, advice, opts) {
   if (advice === undefined)
     return [];

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sjawhar/opencode-legion-envoy",
-  "version": "5.11.2",
+  "version": "6.0.0",
   "license": "Apache-2.0",
   "type": "module",
   "main": "dist/src/server.js",

package/skills/AGENTS.md

@@ -1,8 +1,8 @@
 # Skills Layer
 
 Legion skills guide the architect and its sequential phase workers in a shared issue workspace.
-They are Markdown instructions loaded by Oh My Pi sessions; the daemon and OMP extension own
-event intake, process lifecycle, credentials, and role delivery.
+They are Markdown instructions loaded by Oh My Pi sessions; the daemon and the two Oh My Pi plugins
+(`packages/pi-envoy`, `packages/pi-legion`) own event intake, process lifecycle, credentials, and role delivery.
 
 | Skill | Who reads it | What it owns |
 | --- | --- | --- |
@@ -20,8 +20,9 @@ event intake, process lifecycle, credentials, and role delivery.
 | `thermonuclear-deep-review/` | the `thermonuclear-deep-review` agent, and the reviewer (the Security Guidelines) | the correctness rubric of the reviewer's pair, with its tagged, diff-triggered Security Guidelines and the attack on the PR body's claims (adapted from the MIT-licensed Thermos plugin in `cursor/plugins`; `LICENSE` beside it) |
 
 The owning skill above is where each contract is defined; a role prompt that needs a contract from its own seat points there or restates only its own step. This file lists and does not restate.
-A Legion prompt (a skill here, a role prompt, or an agent definition in `packages/pi-envoy/agents/`) names a task agent only as `task(agent="<name>")` and a skill it tells the model to load only as `skill://<name>`. Those are the two forms the Go daemon's boot gate and `legion probe-image` resolve through Oh My Pi, refusing by name one it cannot find; a dispatch or a load written any other way goes unchecked. An agent or skill Legion's prompts name is shipped here or in `packages/pi-envoy/agents/`, unless Oh My Pi bundles it.
-A skill file an agent loads stays under 51,200 bytes, Oh My Pi's spill threshold (a longer one arrives with its middle cut out), and a skill's detail lives in `references/` files linked as `skill://<name>/references/<file>.md`, never by relative path, which a read by path cuts at 300 lines. `packages/pi-envoy/src/skills-guard.test.ts` fails on a file at the threshold, on any `SKILL.md` body of 500 lines or more, on a skill whose frontmatter `name` is not its directory's name, on a `dispatch-first` over its budget, on a `skill://<name>/<path>` link that names a missing file or a missing `#heading`, and on a `legion-worker` reference nothing links.
+The skills here ship in two Oh My Pi plugins, and the partition is kept in one place, `scripts/pi-plugin-prepack.sh` at the repository root, keyed by package name: `@sjawhar/pi-envoy` (`packages/pi-envoy`) ships `dispatch`, `dispatch-first`, `dispatch-brainstorming` and `envoy`, the skills every session with Dispatch reads; `@sjawhar/pi-legion` (`packages/pi-legion`) ships `legion-architect`, `legion-controller`, `legion-oracle`, `legion-retro`, `legion-worker`, `ce-simplify-code`, `thermonuclear-code-quality` and `thermonuclear-deep-review`, the skills a Legion pane's prompts load. Each plugin's prepack stages its list into its `dist/skills`, and `packages/pi-shared/test/skills-partition.test.ts` holds the two lists to this directory: together they are every skill directory here, and none is in both. A link from a skill in one partition into a skill in the other (a Legion skill's link into `dispatch`) is written `skill://<name>/<path>`, never as a relative path: a staged partition is installed on its own, so a relative link out of it dangles, while a `skill://` link resolves by name once both plugins are installed.
+A Legion prompt (a skill here, a role prompt, or an agent definition in `packages/pi-legion/agents/`) names a task agent only as `task(agent="<name>")` and a skill it tells the model to load only as `skill://<name>`. Those are the two forms the Go daemon's boot gate and `legion probe-image` resolve through Oh My Pi, refusing by name one it cannot find; a dispatch or a load written any other way goes unchecked. An agent or skill Legion's prompts name is shipped here or in `packages/pi-legion/agents/`, unless Oh My Pi bundles it.
+A skill file an agent loads stays under 51,200 bytes, Oh My Pi's spill threshold (a longer one arrives with its middle cut out), and a skill's detail lives in `references/` files linked as `skill://<name>/references/<file>.md`, never by relative path, which a read by path cuts at 300 lines. The rules are `packages/pi-shared/test/skills-guard.ts`, run over each plugin's staged partition: `packages/pi-envoy/src/skills-guard.test.ts` over the Envoy plugin's four skills, with the `dispatch-first` budget check, and `packages/pi-legion/src/skills-guard.test.ts` over the Legion plugin's eight, with the daemon's prompts as linking roots and every `legion-worker` reference linked from somewhere. Each fails on a file at the threshold, on any `SKILL.md` body of 500 lines or more, on a skill whose frontmatter `name` is not its directory's name, on a `skill://<name>/<path>` link that names a missing file or a missing `#heading` (resolved against this directory, where both partitions live), and on a relative link that leaves the staged partition or names no file. The Envoy guard also fails on a `task(agent="<name>")` in the Envoy plugin's skills that names an agent neither that plugin nor Oh My Pi bundles (the bundled list read off the pinned binary's `omp agents unpack` under `LEGION_TEST_OMP`, never written down), since those skills reach a session with no other plugin installed; a `skill://legion-*` mention there is a sentence conditioned on a Legion role, inert for a person and right for a pane with both plugins, which the guard leaves alone.
 The text a worker boots with (its role prompt) lives in `packages/daemon/internal/prompts/roles/`,
 embedded in the `legion` binary and composed per role by `packages/daemon/internal/prompts/prompts.go`;
 `packages/daemon/internal/prompts/roles_test.go` holds the structural rules for those parts.

package/skills/dispatch-first/SKILL.md

@@ -50,7 +50,7 @@ found yourself.
 A design conversation with a person, or the implementation plan that follows one, uses
 `skill://dispatch-brainstorming`: read it before your first design question on a change, the spec,
 or that plan. It replaces superpowers' `brainstorming` and `writing-plans` here, even when the user
-invokes one by name. A Legion architect's own issue spec follows `skill://legion-architect`. Before a spec's first version and each approval request, have a fresh read-only subagent (on Oh My Pi, `task(agent="plan-gap-analyst")`) check it against the code, the human's words and any command output a claim rests on, and resolve what it flags.
+invokes one by name. Before a spec's first version and each approval request, have a fresh read-only subagent (on Oh My Pi, `task(agent="scout")`, or whatever read-only agent the host bundles) check it against the code, the human's words and any command output a claim rests on, and resolve what it flags. A Legion architect's own issue spec follows `skill://legion-architect`, and its fresh reader in that Legion session is the Legion plugin's `plan-gap-analyst` agent.
 
 ## Load the full skill before you write
 

package/skills/legion-architect/SKILL.md

@@ -77,14 +77,14 @@ exercise a criterion end to end, building that path is a child issue of this tre
   answers the tree's asks); under a personal token it goes to that token's owner, whom
   `dispatch_whoami` names. Set it only when a human told you a specific person owns that child.
 
-Specifications written into Dispatch follow `skill://dispatch`'s "Writing a spec" section.
+Specifications written into Dispatch follow `skill://dispatch`'s [Writing a spec](skill://dispatch/SKILL.md#writing-a-spec).
 Wave releases, child closures, and your own status are visible from the issue tree and the
 handoffs; do not narrate them into the spec or a `dispatch_message`. A to-do only a human can
 clear is a `dispatch_ask`.
 
 The issue's primary document **is** the root specification. Extend it in place: a new version
 that adds only the evidence each decision needs and what the human decides, each as a
-decision block (`skill://dispatch`, "Decision blocks"). The decomposition and its waves, how each
+[decision block](skill://dispatch/SKILL.md#decision-blocks). The decomposition and its waves, how each
 outcome is proven, and the integration test are your own calls: they go in the child issues and
 the planner's `.legion/<issue>/plan.json`, not the root spec. Never post a second "spec" artifact beside
 it (`dispatch_artifact` with the primary document's name replaces the human's document; do not do
@@ -112,7 +112,7 @@ legion({
 ```
 
 The decision blocks come first: settle every one as
-"Approval of a spec" (`skill://dispatch`) says before you request approval;
+[Approval of a spec](skill://dispatch/SKILL.md#approval-of-a-spec) says before you request approval;
 `dispatch_request_approval` refuses while one is open. Each answer reaches you, since you follow
 every ask you open. An approval request carries nothing new: request it only once the human has
 agreed to every point in the spec, so a point they have not agreed to gets its own decision block

package/skills/legion-controller/SKILL.md

@@ -26,8 +26,8 @@ For an interactive takeover from a hand-started OMP session, start OMP with
 `LEGION_DAEMON_URL`, `LEGION_PROJECT` (the daemon's project), `LEGION_STATE_DIR`, and `LEGION_GRANT_FILE`
 (an absolute path to a file only you can read, under a 0700 directory; the extension writes
 each command's grant there and every `bash` call is blocked without it) in its environment. Do
-not set `LEGION_CONTROLLER=1` — that marker is `legion controller start`'s own, and a session
-carrying it claims at startup. Then run:
+not set `LEGION_CONTROLLER=1` — that marker is the launched controller's own (`legion controller
+start`'s session, or the daemon's pod), and a session carrying it claims at startup. Then run:
 
 ```text
 /legion-claim-controller
@@ -50,12 +50,27 @@ retry. And the role does not follow `/new` or `/fork` in a takeover session —
 `LEGION_CONTROLLER=1` the new session is not a Legion session to the extension — so after either
 command run `/legion-claim-controller` again.
 
-The daemon holds nothing for a controller: daemon state and the Dispatch project remain
-authoritative, and the start procedure below reads what happened while no controller ran.
+Daemon state and the Dispatch project remain authoritative, and the start procedure below reads
+what happened while no controller ran. Who launched you is the deployment's `controller` setting:
+the operator, or the daemon itself. The `How this controller runs` part of your system prompt says
+which.
+
+### Started by the daemon
+
+Under `controller: daemon` the daemon launched you as a pod in the cluster and supervises you like
+a root architect: you run headless (`omp --mode rpc`), nobody types into your session, and nobody
+reads your replies as they appear. The extension registered with your launch's boot token, claimed
+the role, subscribed to the controller topic and reported ready; the daemon then sent your start
+message. When your pod dies the daemon relaunches it and resumes this same session, with a new
+start message, so run the start procedure each time one arrives. A human reaches you through
+Dispatch (a message to your session on the Agents page, a reply to an ask you opened, a mention) or
+Envoy: answer them where they will read it, a Dispatch message or reply, since text left only in
+your session reaches no one. `legion state` and `legion status <KEY> <status>` work as below. There
+is no `legion controller start` against this daemon, and nobody can replace you with one.
 
 ### Started by the operator
 
-The daemon launches no controller, under either runtime: the operator ran
+Under `controller: operator`, the default, the daemon launches no controller: 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`
@@ -78,8 +93,10 @@ mints a new secret, so your grants stop working and the role moves to the new se
 The Go daemon's controller topic is a wake for a session that is running when it is published.
 Envoy hands an Oh My Pi session no retained copy of a notice published before it subscribed, so a
 hold, a tree architect's failed claim, a new triage root, or a freed slot from while no controller
-ran never arrives as a wake. `legion controller start` opens your first turn with a start message
-(`Legion controller start: …`), so every start and restart runs this procedure with nothing typed.
+ran never arrives as a wake. Every launch opens your first turn with a start message
+(`Legion controller start: …`) — `legion controller start` passes it, and the daemon sends it to a
+controller it launched once that controller is ready — so every start and restart runs this
+procedure with nothing typed.
 At every start, after the claim recheck ([Turn discipline](#turn-discipline)) and before anything
 else:
 
@@ -350,7 +367,7 @@ priority first, then board rank ([Keeping the slots full](#keeping-the-slots-ful
    `unassigned`, `Unassigned — nobody's Inbox shows this tree's questions or its design approval
    until someone takes it from the issue header (Assignee, beside Priority)`. The design approval
    is promised only when the `Design gate policy:` line of your system prompt, which
-   `legion controller start` writes from the daemon's own configuration, says
+   whoever launched you writes from the daemon's own configuration, says
    `gates.design: root-issues`. Under `gates.design: off` nobody approves a design, so drop "and
    its design approval" (and "or its design approval") from the sentence. An unassigned root
    still runs; the architect's asks wait in every Inbox's Unassigned band.

package/skills/legion-worker/SKILL.md

@@ -167,7 +167,7 @@ other tree paused.
 
 ## Phase work
 
-Specifications written into Dispatch follow `skill://dispatch`'s "Writing a spec" section, except that a phase worker writes no decision block: it sends an open product, scope or design decision to its architect, which writes the block.
+Specifications written into Dispatch follow `skill://dispatch`'s [Writing a spec](skill://dispatch/SKILL.md#writing-a-spec), except that a phase worker writes no decision block: it sends an open product, scope or design decision to its architect, which writes the block.
 
 Follow the repository's normal engineering workflow and the assigned issue's acceptance
 criteria. Your phase's own charter and the predecessor handoffs you read define the phase