@sjawhar/opencode-legion-envoy 8.8.0 → 8.8.2

package/dist/src/server.js

@@ -15157,7 +15157,7 @@ var envoyToolSpecs = [
   },
   {
     name: "envoy_unsubscribe",
-    description: "Unsubscribe this session from Envoy topics, or remove all current subscriptions if topics are omitted.",
+    description: "Unsubscribe this session from Envoy topics, or remove all current subscriptions if topics are omitted. A subscription another plugin holds for this session's role stays, and the result lists it as kept.",
     arguments: (schema) => ({ topics: schema.array(schema.string()).optional() }),
     operation: EnvoyToolOperation.unsubscribe
   },
@@ -15190,7 +15190,7 @@ var envoyToolSpecs = [
   },
   {
     name: "envoy_role_set",
-    description: "Set the current session as the holder of a named role. Messages published to notifications.role.<role> route to this session.",
+    description: "Set the current session as the holder of a named role. Messages published to notifications.role.<role> route to this session. Moving to a different role is refused while another plugin holds subscriptions that last only as long as this session keeps its current role.",
     arguments: (schema) => ({ role: schema.string() }),
     operation: EnvoyToolOperation.setRole
   },

package/package.json

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

package/skills/dispatch-brainstorming/SKILL.md

@@ -18,9 +18,10 @@ follows is a document on the same issue. This skill replaces superpowers' `brain
 - There is no approval after each section, only the one at the end.
 - A small change gets a short spec, never a design in chat: its size shortens the spec and changes
   nothing about where the conversation happens.
-- No spec or plan file goes in the repository (`docs/superpowers/specs/`,
-  `docs/superpowers/plans/`, `docs/plans/`): the spec is the issue's primary document and the plan
-  is its `plan.md` document.
+- The spec is the issue's primary document and the plan is its `plan.md` document, in place of
+  superpowers' spec and plan files (`docs/superpowers/specs/`, `docs/superpowers/plans/`). A copy
+  also goes in the repository only when the person, the issue, its spec or the repository asks for
+  one.
 
 The brainstorming stages still shape what you ask: clarifying questions, then two or three
 approaches with a recommendation, then the design section by section. A question that depends on
@@ -28,8 +29,8 @@ no open answer goes out at once, whatever its stage.
 
 Read `skill://dispatch` before the first version: its "Writing a spec", "Decision blocks",
 "Writing for the human" and "Approval of a spec" sections define the spec's shape, each block's
-shape, and when approval is requested. A Legion phase worker never writes the spec; it sends a
-decision to its architect (`skill://legion-worker`).
+shape, and when approval is requested. A Legion phase worker never writes the issue's spec
+document; it sends a decision to its architect (`skill://legion-worker`).
 
 ## Where the spec lives
 
@@ -98,7 +99,7 @@ reactions, and so do corrections to it. Neither your model nor theirs is the sta
 
 Once the spec is approved — or, when the issue needed no spec at all (a bug fix with no design
 decision), once you have enough to plan from — the implementation plan is the issue's `plan.md`
-document, never its spec and never a repository file:
+document, never its spec:
 
 ```bash
 dispatch artifact --issue <KEY> --name plan.md --content-file - <<'EOF'
@@ -108,7 +109,9 @@ EOF
 
 Uploading `plan.md` again writes its next version. `writing-plans`'s content rules still apply in
 full — file structure, task right-sizing, bite-sized steps, no placeholders, the header, and its
-self-review — only where the plan lives changes: the issue's `plan.md`, never a repository file.
+self-review — only where the plan lives changes: the issue's `plan.md`, in place of a plan file.
+A copy in the repository, or spec code there, goes in only when the person, the issue, its spec or
+the repository asks for it.
 Technical choices inside the approved design are made in the plan and need no question. A plan
 never changes a decision the human made in the spec: a change to one goes back to the spec as a
 decision block, with the evidence for it.

package/skills/envoy/SKILL.md

@@ -200,6 +200,9 @@ fork's parent). If a different live session holds it — the parent of a `/fork`
 the child, or a second process on the same transcript — the listener refuses atomically and the
 resumed session logs a warning and holds nothing. Only an explicit `envoy_role_set` is
 last-claim-wins. Re-running `envoy_role_set` for a role this session already holds is harmless.
+Moving to a different role is refused while another plugin holds subscriptions that last only as
+long as this session keeps its current role (the refusal names them), and `envoy_unsubscribe`
+keeps those subscriptions open, listing them as kept.
 
 ## Legion role claims
 

package/skills/legion-worker/SKILL.md

@@ -248,17 +248,15 @@ gh pr comment <pr-number> \
 ## Planner artifact
 
 The plan lives in `.legion/<issue>/plan.json` and the issue's `plan.md` document, never in the issue's
-primary document, which is its spec; never commit a plan or spec file to the repository.
-No `docs/plans/*`, `docs/superpowers/plans/*`, or spec markdown goes into the pull request: plan
-and spec content goes into the issue, never into a PR (the root `AGENTS.md`
-calls its own `docs/plans/` human-authored design history, not a Legion artifact). A skill step that says "save the plan
-to a file" is satisfied by the handoff write in the completion gate below; the planner's only
-commit is `plan: record handoff`.
+primary document, which is its spec. Legion sets no rule on whether a plan or spec goes in the
+repository: the planner commits a plan, a spec or spec code when the issue, its spec or the
+repository asks for it. Otherwise, a skill step that says "save the plan to a file" is satisfied by
+the handoff write in the completion gate below.
 
 A plan that departs from the spec's design records the departure in `plan.md` and in the required
 `.legion/<issue>/plan.json` `specDepartures`: `[]` means no departure; otherwise each bounded record names
 the spec, plan, evidence and outcome. The planner's role prompt defines that record. The planner
-never edits the spec. Whether the spec changes is the architect's decision
+never edits the issue's spec document. Whether the spec changes is the architect's decision
 (`skill://legion-architect`, section 1), and the reviewer reads the plan beside the spec.
 
 ## Implementer push and pull request