@sjawhar/opencode-legion-envoy 5.6.0 → 5.6.1

package/package.json

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

package/skills/dispatch/references/messages.md

@@ -25,11 +25,11 @@ reply. A human may reply to your message in turn — the follow-up arrives as a
 `in_reply_to` names your message and whose `reply_body` quotes it; answer it the same way,
 `dispatch_message({ issue, in_reply_to: "<their reply id>", body })`, so the exchange reads as one
 thread. `dispatch_message` itself never carries `target` or `delivery`: agent-to-agent traffic goes
-through Envoy or the hub. A bearer that targets over HTTP names its own session in `actor`
-(`{kind: "session", id}`), and the card shows that session as the author. `GET /api/v1/agents`
-(any authenticated caller) lists live sessions with their capabilities (`aside`, `btw`, `steer`);
-target only a session that advertises the mode you want. Sending to a session with no issue
-(`POST /api/v1/agents/{session_id}/messages`) stays human-only.
+through Envoy or Oh My Pi's `agent://` messages. A bearer that targets over HTTP names its own
+session in `actor` (`{kind: "session", id}`), and the card shows that session as the author.
+`GET /api/v1/agents` (any authenticated caller) lists live sessions with their capabilities
+(`aside`, `btw`, `steer`); target only a session that advertises the mode you want. Sending to a
+session with no issue (`POST /api/v1/agents/{session_id}/messages`) stays human-only.
 
 ## Answering a direct message
 

package/skills/envoy/SKILL.md

@@ -122,8 +122,9 @@ envoy_send(
 
 `envoy_whoami`'s `session_id` is the address a reply to you reaches. Inside a `task` subagent it
 is the session that spawned you: a subagent registers no Envoy session of its own, so a peer
-answering it reaches that session, which relays to you over hub. The `subagent` field in that
-output carries your own host session id — it is not an address, so never hand it to a peer.
+answering it reaches that session, which relays to you with a `write` to your `agent://` address.
+The `subagent` field in that output carries your own host session id — it is not an address, so
+never hand it to a peer.
 
 `session_id` is empty when nothing can be reached: a process that took no Envoy identity, or a
 subagent whose spawning session this process can no longer place (it forked away, and other
@@ -134,8 +135,8 @@ would send your peers to an agent that never spawned you.
 Your own `envoy_publish` never reaches the agent that spawned you. The listener delivers nothing
 to the session a message names as its source, and inside a subagent that source is your parent,
 so a publish to a role it holds — or to any topic it subscribes to — is accepted and delivered to
-nobody. Use hub for that one hop. `envoy_send` to any other session, including a reply, is
-unaffected.
+nobody. Use a `write` to its `agent://` address for that one hop. `envoy_send` to any other
+session, including a reply, is unaffected.
 
 ### Delivery capabilities
 

package/skills/legion-worker/SKILL.md

@@ -62,11 +62,11 @@ workflow table. You may still use ordinary `task` subagents for your own phase w
 is a Legion role.
 Escalate a product, scope, design, cross-phase, or lifecycle decision to the owning architect with
 `envoy_publish` to its role topic (`notifications.role.` followed by its encoded token, see
-above), carrying the verified facts and the decision needed. `hub` only reaches subagents
-inside your own process, not the architect's separate one. Never write a decision block into a
-spec yourself: the architect decides whether the human must answer it and writes the block, since
-a new version of an approved root spec closes the tree's design gate. A standalone to-do only a
-human can do is a `dispatch_ask`, and its replies return to your own session.
+above), carrying the verified facts and the decision needed. A `write` to `agent://` only reaches
+agents inside your own process, not the architect's separate one. Never write a decision block
+into a spec yourself: the architect decides whether the human must answer it and writes the block,
+since a new version of an approved root spec closes the tree's design gate. A standalone to-do
+only a human can do is a `dispatch_ask`, and its replies return to your own session.
 
 Because the same agent is always resumed for its phase, you may receive more than one
 assignment across your lifetime: once the daemon ends your phase it suspends you, and when a later
@@ -152,9 +152,10 @@ new work.
 clone, so they all share one operation log: `jj undo`, `jj abandon`, and
 `jj op restore|revert|abandon|undo` rewrite it for every tree at once. The extension refuses them in every
 phase-worker pane before they run — a `bash` command in any position of a pipeline or `&&`
-chain, with or without `-R`, judged on the whole argument list; `eval` code; and a `hub`
-process start — from your own tool calls and from any `task` subagent you spawn (it runs in
-your pane, against the same log), and a `bash` command whose quoted text merely mentions `jj`
+chain, with or without `-R`, judged on the whole argument list (a supervised service's start
+included); `eval` code; and stdin written to a service (a `write` to `proc://<id>`) — from your
+own tool calls and from any `task` subagent you spawn (it runs in your pane, against the same
+log), and a `bash` command whose quoted text merely mentions `jj`
 with one of those words (a heredoc, an echo, a commit message) is refused too: write such text
 with the `write` tool or say "operation-log rollback" instead. `jj restore <paths>`,
 `jj op log`, and `jj op show` stay allowed. Recover forward only: a new commit