@sjawhar/opencode-legion-envoy 0.29.0 → 0.31.0

package/dist/src/server.js

@@ -13874,8 +13874,17 @@ var legionRole = _enum2(LEGION_ROLES);
 var requiredUnknown = unknown().refine((value) => value !== undefined, {
   message: "Required"
 });
-var ARCHITECT_MUTABLE_LABELS = ["needs-approval"];
-var architectMutableLabel = _enum2(ARCHITECT_MUTABLE_LABELS);
+var LIFECYCLE_STATUSES = [
+  "triage",
+  "icebox",
+  "backlog",
+  "todo",
+  "in_progress",
+  "testing",
+  "needs_review",
+  "retro",
+  "done"
+];
 var architectCapability = strictObject({
   tree: nonEmptyString,
   sessionId: nonEmptyString,
@@ -13928,33 +13937,10 @@ var LegionDaemonApi = {
     request: architectCapability.extend({ generation: number2().int() }),
     response: object({})
   },
-  IssueCreate: {
-    request: architectCapability.extend({
-      title: nonEmptyString,
-      body: nonEmptyString,
-      labels: array(architectMutableLabel).optional()
-    }),
-    response: object({ issue: nonEmptyString, url: nonEmptyString })
-  },
   WaveRelease: {
-    request: architectCapability.extend({ children: array(nonEmptyString).optional() }),
+    request: architectCapability.extend({ issues: array(nonEmptyString).optional() }),
     response: object({ released: array(nonEmptyString) })
   },
-  Comment: {
-    request: architectCapability.extend({ issue: nonEmptyString, body: nonEmptyString }),
-    response: object({ commentId: number2().int(), url: nonEmptyString })
-  },
-  PostBody: {
-    request: architectCapability.extend({ issue: nonEmptyString, body: nonEmptyString }),
-    response: object({})
-  },
-  Labels: {
-    request: architectCapability.extend({
-      issue: nonEmptyString,
-      add: array(architectMutableLabel).optional()
-    }),
-    response: object({ labels: array(nonEmptyString) })
-  },
   Escalate: {
     request: architectCapability.extend({
       kind: _enum2(["re-file", "capacity", "cross-tree"]),
@@ -13962,10 +13948,6 @@ var LegionDaemonApi = {
     }),
     response: object({})
   },
-  IssueClose: {
-    request: architectCapability.extend({ issue: nonEmptyString, comment: string2().optional() }),
-    response: object({})
-  },
   ProvisioningCredential: {
     request: architectCapability.extend({ issue: nonEmptyString }),
     response: object({ token: nonEmptyString })
@@ -14028,16 +14010,16 @@ var LegionDaemonApi = {
       secret: nonEmptyString
     })
   },
-  GatesApprove: {
-    request: controllerIssue,
+  IssueStatus: {
+    request: controllerIssue.extend({
+      status: _enum2(LIFECYCLE_STATUSES),
+      tree: nonEmptyString.optional(),
+      sessionId: nonEmptyString.optional()
+    }),
     response: object({})
   },
-  Admission: {
-    request: controllerIssue,
-    response: object({ result: _enum2(["spawned", "queued"]) })
-  },
-  Backlog: {
-    request: controllerIssue.extend({ marker: nonEmptyString }),
+  GatesRegister: {
+    request: architectCapability.extend({ issue: nonEmptyString, askId: nonEmptyString }),
     response: object({})
   },
   Grant: {

package/package.json

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

package/skills/github/SKILL.md

@@ -104,7 +104,7 @@ gh api graphql -f query='query {
 Add a label to an issue (additive — does not remove existing labels):
 
 ```bash
-gh issue edit $ISSUE_NUMBER --add-label "needs-approval" -R $OWNER/$REPO
+gh issue edit $ISSUE_NUMBER --add-label "bug" -R $OWNER/$REPO
 ```
 
 **Parameters:**
@@ -114,7 +114,7 @@ gh issue edit $ISSUE_NUMBER --add-label "needs-approval" -R $OWNER/$REPO
 
 **Example:**
 ```bash
-gh issue edit 123 --add-label "needs-approval" -R acme/backend
+gh issue edit 123 --add-label "bug" -R acme/backend
 ```
 
 ### Remove Label
@@ -122,7 +122,7 @@ gh issue edit 123 --add-label "needs-approval" -R acme/backend
 Remove a label from an issue:
 
 ```bash
-gh issue edit $ISSUE_NUMBER --remove-label "needs-approval" -R $OWNER/$REPO
+gh issue edit $ISSUE_NUMBER --remove-label "wontfix" -R $OWNER/$REPO
 ```
 
 **Parameters:**
@@ -132,7 +132,7 @@ gh issue edit $ISSUE_NUMBER --remove-label "needs-approval" -R $OWNER/$REPO
 
 **Example:**
 ```bash
-gh issue edit 123 --remove-label "legion-backlog" -R acme/backend
+gh issue edit 123 --remove-label "wontfix" -R acme/backend
 ```
 
 ### Comment on Issue

package/skills/legion-architect/SKILL.md

@@ -10,29 +10,31 @@ with human-created children; either way you own its complete outcome. Work from
 wakes and current artifacts. Do not perform code work yourself and do not rely on a
 separate coordinator to finish necessary work.
 
+This skill documents the target Dispatch-native contract. The `legion` tool's
+`register_gate`/`release_wave`/`set_status` ops, the Dispatch key format, and the
+`dispatch_*` tool family land with PR B (#TBD); until that PR merges, this skill's contract
+is not yet runnable on `main`.
+
 ## Tool and ownership boundaries
 
-- Use the `legion` tool for lifecycle writes. Its issue key format is
-  `owner/repo#number`.
+- Use the `legion` tool for lifecycle writes. Its issue key is the Dispatch key
+  (pattern `^[A-Z][A-Z0-9]*-[0-9]+$`, e.g. `LEGION-41`).
 - Use `legion({ op: "spawn_worker", issue, role, task })` for every Legion role spawn.
   Message a known phase worker with `envoy_publish` to `notifications.role.` followed by
   its encoded role token (the token `spawn_worker` returned for it); re-assign it by
   calling `spawn_worker` again on the same existing role, which resumes the same process
   instead of starting a fresh one. Phase workers escalate lifecycle, scope, and
   cross-phase matters the same way: `envoy_publish` to your own encoded token. Any role
-  may use `dispatch` directly for a standalone human question; replies return to the
+  may use `dispatch_ask` directly for a standalone human question; replies return to the
   asking session.
 - The daemon spawns each role as its own process with the issue's context already in its
   environment. Never hand-format a role token: the daemon encodes one as
-  `legion-<project>-<encoded-owner>__<encoded-repo>-<number>-<role>` (escaping `_`, `.`,
-  and `-` within the owner/repo names); for example, project `acme`, issue
-  `sjawhar/legion#41`, role `architect` encodes to `legion-acme-sjawhar__legion-41-architect`.
-  Reuse a token you already hold (your own, or one `spawn_worker` returned) or compute
-  another with the `roleToken` helper from `@legion/contracts` exactly the way the daemon
-  does.
-- Use only the live label vocabulary: `needs-approval`, `human-approved`,
-  `legion-child`, and `legion-backlog`. Do not attempt to apply a label whose ownership
-  belongs to the controller or Sami.
+  `legion-<project>-<KEY>-<role>`; for example, project `acme`, issue `LEGION-41`, role
+  `architect` encodes to `legion-acme-LEGION-41-architect`. Reuse a token you already
+  hold (your own, or one `spawn_worker` returned) or compute another with the
+  `roleToken` helper from `@legion/contracts` exactly the way the daemon does.
+- There is no label vocabulary. Dispatch status replaces the board, and the design gate
+  is a `dispatch_ask` answered `Approve`, not a label. Never attempt to apply a label.
 - Deferring necessary work is failure. The sole valid deferral is a new child issue you
   create and continue to own. Re-file a genuinely independent child through the
   controller rather than treating it as an abandoned dependency.
@@ -46,7 +48,7 @@ exercise a criterion end to end, building that path is a child issue of this tre
 
 - **Existing children:** adopt them. Do not replace or re-decompose human-created work.
   Put every adopted child into the initial wave. **You MUST call**
-  `legion({ op: "wave_release", children: ["owner/repo#41", "owner/repo#42"] })`
+  `legion({ op: "release_wave", issues: ["LEGION-41", "LEGION-42"] })`
   **before any `spawn_worker` call for an adopted child.** Until release, the daemon
   holds that child's role activity. Then spawn each child's daemon-managed sub-architect
   owner.
@@ -54,16 +56,19 @@ exercise a criterion end to end, building that path is a child issue of this tre
   completed and integrated as one unit. Otherwise create complete child issues with:
 
   ```text
-  legion({
-    op: "issue_create",
+  dispatch_issue({
+    project: "<project>",
+    parent: "<root issue>",
     title: "<child outcome>",
-    body: "<acceptance criteria, scope, and context>",
-    labels: []
+    spec: "<acceptance criteria, scope, and context>"
   })
   ```
 
-  The daemon establishes the sub-issue relationship and the `legion-child` label. Keep
-  the returned issue keys in ordered waves; a child is inert until released.
+  `project` is the issue key's prefix before `-<n>` (e.g. `LEGSMOKE-3` → `LEGSMOKE`) — not
+  the role-token `<project>` (the daemon's own project, e.g. `acme`), a different string. A
+  root session has `LEGION_TREE == LEGION_ISSUE`. The daemon establishes the sub-issue
+  relationship from `parent`. Keep the returned issue keys in ordered waves; a child is
+  inert until released.
 
 Write one root specification containing the accepted scope, adoption/decomposition,
 waves, acceptance criteria, and integration test. When the config-armed root design gate
@@ -71,20 +76,18 @@ applies, run this exact sequence **before any Legion-role spawn**, including a
 sub-architect:
 
 ```text
-legion({ op: "post_spec", issue: "<root issue>", body: "<root specification>" })
-legion({ op: "label_add", issue: "<root issue>", label: "needs-approval" })
-dispatch({
-  parent: "<root issue>",
-  subject: "Legion design approval requested",
-  context: "<what the tree is, what triggered the gate>",
-  question: "<specification summary and the decision requested>"
+dispatch_artifact({ issue: "<root issue>", name: "spec.md", content: "<root specification>", primary: true, summary: "<one-line summary>" })
+askId = dispatch_ask({
+  issue: "<root issue>",
+  question: "<specification summary and the decision requested>",
+  options: [{ label: "Approve" }, ...]
 })
+legion({ op: "register_gate", issue: "<root issue>", askId })
 ```
 
 Then park. Do not release a wave or spawn a Legion role until a later delivered wake
-shows `human-approved` on the root. You never add that label yourself. Approval covers
-the entire tree: later waves, re-scopes, and integration-failure children do not repeat
-this sequence.
+shows `design-approved` on the root. Approval covers the entire tree: later waves,
+re-scopes, and integration-failure children do not repeat this sequence.
 
 ## 2. Children in flight
 
@@ -92,7 +95,7 @@ Release only the next useful wave, then give its owners their work. A release is
 explicit lifecycle write:
 
 ```text
-legion({ op: "wave_release", children: ["owner/repo#41", "owner/repo#42"] })
+legion({ op: "release_wave", issues: ["LEGION-41", "LEGION-42"] })
 ```
 
 After release, spawn each relevant owner; for example:
@@ -100,7 +103,7 @@ After release, spawn each relevant owner; for example:
 ```text
 legion({
   op: "spawn_worker",
-  issue: "owner/repo#41",
+  issue: "LEGION-41",
   role: "architect",
   task: "Own this child through its lifecycle and report its evidence."
 })
@@ -122,7 +125,7 @@ and current `main` integration surface:
 ```text
 legion({
   op: "spawn_worker",
-  issue: "owner/repo#40",
+  issue: "LEGION-40",
   role: "tester",
   task: "Verify this parent issue against its acceptance criteria on current main; return reproducible integration evidence."
 })
@@ -181,15 +184,12 @@ If anything changes the approved head, return to review; do not let the merger p
 
 ## 7. Close
 
-After the merge result and sign-off are recorded, close this issue through the Legion
-write surface and include the sign-off comment:
+After the merge result and sign-off are recorded, post the sign-off and close this issue
+through the Legion write surface:
 
 ```text
-legion({
-  op: "issue_close",
-  issue: "owner/repo#40",
-  comment: "<sign-off: scope, integration evidence, review, retro, Sami approval, and merge>"
-})
+dispatch_comment({ issue: "LEGION-40", body: "<sign-off: scope, integration evidence, review, retro, Sami approval, and merge>" })
+legion({ op: "set_status", issue: "LEGION-40", status: "done" })
 ```
 
 Closing a child supplies the closure event to its parent. Do not close a parent until the
@@ -220,6 +220,6 @@ corresponding lifecycle procedure.
 
 Controller-actionable matters are exactly re-filing a genuinely independent child,
 capacity, and cross-tree conflict. Use the Legion escalation operation for those. Handle
-everything else in the tree, or use `dispatch` for a human question; workers may reach
-Sami directly with `dispatch` the same way. Do not create a wait loop for any wake
+everything else in the tree, or use `dispatch_ask` for a human question; workers may reach
+Sami directly with `dispatch_ask` the same way. Do not create a wait loop for any wake
 source.

package/skills/legion-controller/SKILL.md

@@ -9,6 +9,10 @@ The controller is the one persistent, wake-driven session for a Legion project.
 triage, escalation, and human-interaction judgments; it never does phase-worker work or
 routes raw events into an architect.
 
+This skill documents the target Dispatch-native contract. The `legion` tool's `set_status`
+op, `dispatch_read`/`dispatch_issue`, and the Dispatch key format land with PR B (#TBD);
+until that PR merges, this skill's contract is not yet runnable on `main`.
+
 ## Start and claim the controller role
 
 The Legion extension claims `legion-<project>-controller` and registers controller readiness
@@ -23,11 +27,11 @@ For an interactive takeover, start OMP with `LEGION_CONTROLLER_SECRET` and
 
 The command resolves the project from daemon state, claims the Envoy role for the current
 session, and posts readiness before controller commands can act. It retains the environment
-capability for `legion admit` and `legion backlog`. Never pass a secret as a command argument
+capability for `legion({ op: "set_status", issue, status })`. Never pass a secret as a command argument
 or copy it into a transcript.
 
 This handshake lets the daemon redeliver held controller work. It does not turn the controller
-into a state holder: daemon state and GitHub artifacts remain authoritative.
+into a state holder: daemon state and the Dispatch project remain authoritative.
 
 ## Turn discipline
 
@@ -36,7 +40,7 @@ into a state holder: daemon state and GitHub artifacts remain authoritative.
 - **One wake = one turn.** Handle exactly the wake's implication, then end the turn. Never
   poll, idle-loop, or wait for another event.
 - **Wakes are advisory.** Before any side effect, verify the current daemon state and the
-  relevant GitHub artifact. A stale or duplicate wake may cost a read, never a wrong action.
+  relevant Dispatch issue. A stale or duplicate wake may cost a read, never a wrong action.
 - **Controller state is disposable.** Do not reconstruct or preserve local controller
   bookkeeping between turns.
 
@@ -44,52 +48,59 @@ into a state holder: daemon state and GitHub artifacts remain authoritative.
 
 | Wake | Content | Controller action |
 |---|---|---|
-| New issue added to the project board (webhook: issue opened / project item added; resync heals misses) | issue ref + triage context (incl. pre-existing children) | Triage: spawn root process via daemon admission, or park in the daemon-state backlog |
-| Backlog eligibility | slot freed / priority change | Reconsider parked items; deliberately-backlogged issues carry a marker so resync doesn't re-flag them |
-| Architect escalation (controller-actionable only: re-file a child as a root issue, capacity, cross-tree conflicts) | request + context | Judge and act; issue-scoped human Q&A goes through `dispatch` from the owning architect, not here |
-| Resync report | artifact-driven anomaly list (zero-owner trees, erroring issues) | Verify against fresh state, then dispatch/heal |
-| Mention | Slack/GitHub @mention text | Answer, or route to the owning issue's architect role |
-| Closed-tree activity (comment, review, CI on a closed tree) | issue, root, event summary | Read the artifact; if work should resume, `legion admit <root>`; otherwise no action — the event is not held or redelivered |
+| New issue created in the Dispatch project (`issue.created`, status `triage`; resync heals misses) | issue key + triage context (incl. pre-existing children) | Triage: `legion({ op: "set_status", issue, status: "todo" })` to admit, or set `backlog`/`icebox` to park |
+| Backlog eligibility | slot freed / priority change | Reconsider parked items and move the eligible root to `todo` |
+| Architect escalation (controller-actionable only: re-file a child as a root issue, capacity, cross-tree conflicts) | request + context | Judge and act; issue-scoped human Q&A goes through `dispatch_ask` from the owning architect, not here |
+| Resync report | artifact-driven anomaly list (zero-owner trees, untriaged-open, launch-failed) | Verify against fresh state, then heal |
+| `child-status` | child key + status transition | Not controller-actionable by default; if the daemon could not route it to the parent's architect role, verify the transition and forward it with `envoy_publish` |
+| Mention | Slack/GitHub PR @mention text | Answer, or route to the owning issue's architect role |
+| Closed-tree activity (comment, review, CI on a closed tree) | issue, root, event summary | Read the artifact; if work should resume, `legion({ op: "set_status", issue: root, status: "todo" })`; otherwise no action — the event is not held or redelivered |
 | Direct user message | — | Always first |
 
 ## New issue triage
 
-1. Read `legion state --json`, then inspect the reported GitHub issue with `gh issue view`.
-   Verify the issue is on this project board, is eligible for a root process, and whether it
-   has pre-existing children. GitHub and daemon state, not the wake text, decide triage.
+1. Read `legion state --json`, then inspect the reported Dispatch issue with `dispatch_read`.
+   Verify the issue is in this project, is eligible for a root process, and whether it
+   has pre-existing children. Dispatch and daemon state, not the wake text, decide triage.
 2. If it should run now, admit the root issue:
 
-   ```bash
-   legion admit <issue>
+   ```text
+   legion({ op: "set_status", issue: "<issue>", status: "todo" })
    ```
 
-3. If it should deliberately wait, record a durable reason instead of leaving it unowned:
+3. If it should deliberately wait, move it to a parked status instead of leaving it in
+   `triage`:
 
-   ```bash
-   legion backlog <issue> --marker <reason>
+   ```text
+   legion({ op: "set_status", issue: "<issue>", status: "backlog" })
    ```
 
-   The marker is required: it distinguishes intentional backlog from a missed wake during
-   resync. Do not triage a system-created child as a root issue.
+   (or `status: "icebox"` for longer-term deferral). Dispatch status is the durable record;
+   there is no separate marker to maintain. Do not triage a system-created child as a root
+   issue.
 
 ## Backlog eligibility
 
-When a slot frees or priority changes, use `legion state --json` and the current issue
-artifact to reconsider marked backlog entries. Admit the selected root with `legion admit
-<issue>`. Keep an item backlogged only with a current, explicit marker; changing the marker
-is a deliberate controller decision, not a no-op.
+When a slot frees or priority changes, use `legion state --json` and the current Dispatch
+issue to reconsider parked roots. Admit the selected root with
+`legion({ op: "set_status", issue, status: "todo" })`. Moving an item to or from `backlog`/
+`icebox` is a deliberate controller decision, not a no-op.
 
 ## Architect escalation
 
 Only decide controller-actionable escalations: re-filing independent work, capacity, and
-cross-tree conflicts. Issue-scoped human Q&A goes through `dispatch` from the owning
+cross-tree conflicts. Issue-scoped human Q&A goes through `dispatch_ask` from the owning
 architect, not the controller.
 
-For an independence judgment, verify the child and its parent against GitHub and current
-daemon state. If the work belongs in an independent root:
+For an independence judgment, verify the child and its parent against current daemon state
+and the Dispatch issue. If the work belongs in an independent root:
 
-1. File a **fresh root issue** with `gh`, carrying the necessary context.
-2. Close the child and leave a pointer to the new root issue.
+1. File a **fresh root issue** with `dispatch_issue({ project, title, spec })` (no `parent`).
+   `project` is the issue key's prefix before `-<n>` (e.g. `LEGSMOKE-3` → `LEGSMOKE`) — not
+   the role-token `<project>` (the daemon's own project, e.g. `acme`), a different string.
+2. Park the child (`legion({ op: "set_status", issue: child, status: "icebox" })`) and leave
+   a pointer to the new root issue. The controller's capability is `todo`/`backlog`/`icebox`
+   only — only the owning architect or the daemon closes an issue as `done`.
 3. Admit or deliberately backlog the new root through the normal triage procedure.
 
 Never promote a child in place. Resolve capacity and cross-tree conflicts from verified
@@ -98,11 +109,11 @@ judgments.
 
 ## Resync report
 
-Treat a resync report as an anomaly list, not an instruction. For every zero-owner tree or
-erroring issue it names, verify `legion state --json` and the current GitHub artifact first.
-Then heal the verified condition: admit an eligible root, restore a deliberately backlogged
-marker, or use the applicable daemon control path. Do not act on erroring or stale entries
-until their source artifact explains the anomaly.
+Treat a resync report as an anomaly list, not an instruction. For every zero-owner tree,
+untriaged-open, or launch-failed issue it names, verify `legion state --json` and the
+current Dispatch issue first. Then heal the verified condition: admit an eligible root, move
+an issue back to its intended status, or use the applicable daemon control path. Do not act
+on stale entries until their source artifact explains the anomaly.
 
 ## Mentions
 
@@ -111,13 +122,3 @@ human-facing information. Otherwise resolve the authoritative owning architect r
 route the verified context with `envoy_publish`. Do not route raw event traffic or invent a
 role token from a partial issue reference.
 
-## Label vocabulary
-
-Use only the project labels below, with their stated ownership:
-
-| Label | Applied by | Removed by | Meaning |
-|---|---|---|---|
-| `needs-approval` | architect | controller/Sami when applying `human-approved` | design gate armed, awaiting Sami |
-| `human-approved` | Sami or controller | Sami | design gate open |
-| `legion-child` | daemon | never | system-created child |
-| `legion-backlog` | controller | controller | deliberately unowned root |

package/skills/legion-worker/SKILL.md

@@ -11,6 +11,10 @@ phase gets its own long-lived process against the same jj workspace, run in turn
 the phase assigned to you, report its completion to the architect, and leave the durable
 copy the next phase can trust.
 
+This skill documents the target Dispatch-native contract. `LEGION_ISSUE` as a Dispatch key,
+the `dispatch_ask` tool, and the `Dispatch: <KEY>` PR-body linkage land with PR B (#TBD);
+until that PR merges, this skill's contract is not yet runnable on `main`.
+
 ## Identity, scope, and role
 
 The daemon spawns you as a separate `omp --mode rpc` process (behind `legion worker-shim`,
@@ -21,13 +25,11 @@ completes the boot handshake for you at session start — it registers with the
 your role, and signals readiness. You never call `envoy_role_set` yourself.
 
 Your role token is not the issue key spelled out literally. The daemon encodes it as
-`legion-<project>-<encoded-owner>__<encoded-repo>-<number>-<role>`, escaping `_`, `.`, and
-`-` within the owner and repo names (`_u`, `_d`, `_h`) so `__` is always the one safe
-separator. For example, project `acme`, issue `sjawhar/legion#41`, role `architect` encodes
-to `legion-acme-sjawhar__legion-41-architect`. Never hand-format one for another role: your
-own role topic and your tree's architect's topic are stated at the end of your system
-prompt (a "Legion addressing" line the daemon appends), a sibling role's topic is yours
-with the trailing `-<role>` replaced, and the `roleToken` helper in `@legion/contracts`
+`legion-<project>-<KEY>-<role>`. For example, project `acme`, issue `LEGION-41`, role
+`architect` encodes to `legion-acme-LEGION-41-architect`. Never hand-format one for another
+role: your own role topic and your tree's architect's topic are stated at the end of your
+system prompt (a "Legion addressing" line the daemon appends), a sibling role's topic is
+yours with the trailing `-<role>` replaced, and the `roleToken` helper in `@legion/contracts`
 computes any other one exactly the way the daemon does — prefer a topic you've already
 been given before recomputing one.
 
@@ -47,7 +49,7 @@ Escalate a product, scope, cross-phase, or lifecycle decision to the owning arch
 `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. For a durable question that needs
-Sami directly, you may use the raw `dispatch` MCP tool yourself; replies return to your own
+Sami directly, you may use `dispatch_ask` yourself; replies return to your own
 session.
 
 Because the same agent is always resumed for its phase, you may receive more than one
@@ -133,11 +135,13 @@ capability it needs; invoke GitHub through the credential helper:
 legion gh -- <gh args…>
 ```
 
-## GitHub comment attribution
+## GitHub PR comment attribution
 
-Append this exact structured footer to **every** GitHub issue comment, pull-request
-comment, and review that this phase posts. It preserves session provenance on the artifact
-itself so work stays attributable to the session that produced it:
+Append this exact structured footer to **every** pull-request comment and review that this
+phase posts on GitHub. It preserves session provenance on the artifact itself so work stays
+attributable to the session that produced it. Dispatch comments carry session provenance
+natively through their own `actor`/`origin` fields; this footer is only for GitHub PR
+artifacts:
 
 ```html
 <!-- legion: {"session":"<session-id>","phase":"<phase>"} -->
@@ -146,7 +150,7 @@ itself so work stays attributable to the session that produced it:
 For example:
 
 ```bash
-legion gh -- issue comment <issue-number> \
+legion gh -- pr comment <pr-number> \
   --body $'Verification complete.\n\n<!-- legion: {"session":"<session-id>","phase":"<phase>"} -->' \
   --repo <owner>/<repo>
 ```
@@ -159,17 +163,19 @@ procedure:
 
 ```bash
 cd -- "$LEGION_WORKSPACE" && \
-  jj -R "$LEGION_WORKSPACE" bookmark set legion/issue-<n> && \
-  jj -R "$LEGION_WORKSPACE" git push --bookmark legion/issue-<n> --allow-new
+  jj -R "$LEGION_WORKSPACE" bookmark set legion/<KEY> && \
+  jj -R "$LEGION_WORKSPACE" git push --bookmark legion/<KEY>
 ```
 
 The provisioned issue workspace configures `credential.helper` with the daemon's absolute
 credential command, so `jj -R "$LEGION_WORKSPACE" git push` authenticates transparently
 through the same session capability. Never handle a token.
 
-Then open the pull request with `legion gh -- pr create`. The credential helper and
-`legion gh` provide the GitHub identity; never export, fetch, or replace a token. Other
-phases advance the existing branch rather than creating a replacement bookmark or PR.
+Then open the pull request with `legion gh -- pr create`. The PR body **must** contain the
+line `Dispatch: <KEY>` — the daemon's fallback link from a PR to its Dispatch issue when the
+branch name alone is ambiguous. The credential helper and `legion gh` provide the GitHub
+identity; never export, fetch, or replace a token. Other phases advance the existing branch
+rather than creating a replacement bookmark or PR.
 
 ## PR body and merge-queue discipline
 
@@ -243,13 +249,13 @@ cd -- "$LEGION_WORKSPACE" && \
 ```
 
 If the issue bookmark exists locally, advance it and push it with the provisioned
-credential helper. `--allow-new` also publishes the locally provisioned bookmark on its
-first push:
+credential helper. `--bookmark` also publishes the locally provisioned bookmark on its
+first push — a bookmark not yet tracking a remote one is tracked automatically:
 
 ```bash
 cd -- "$LEGION_WORKSPACE" && \
-  jj -R "$LEGION_WORKSPACE" bookmark set legion/issue-<n> && \
-  jj -R "$LEGION_WORKSPACE" git push --bookmark legion/issue-<n> --allow-new
+  jj -R "$LEGION_WORKSPACE" bookmark set legion/<KEY> && \
+  jj -R "$LEGION_WORKSPACE" git push --bookmark legion/<KEY>
 ```
 
 Do not report phase completion until the write, existence check, and handoff commit
@@ -279,5 +285,5 @@ session, if this phase's work needs to run again.
 
 When blocked on lifecycle, scope, or cross-phase matters, `envoy_publish` the owning
 architect a concise message: issue, phase, verified observation, what you tried, and the
-decision required. Reach for `dispatch` yourself only for a standalone human question
+decision required. Reach for `dispatch_ask` yourself only for a standalone human question
 outside that coordination.

package/skills/linear/SKILL.md

@@ -39,7 +39,7 @@ Returns: title, description, status, labels, comments, attachments.
 linear_linear(action="update", id="ABC-123", state="Done")
 linear_linear(action="update", id="ABC-123", priority=1)
 linear_linear(action="update", id="ABC-123", assignee="me")
-linear_linear(action="update", id="ABC-123", labels=["legion-backlog", "existing-label"])
+linear_linear(action="update", id="ABC-123", labels=["bug", "existing-label"])
 ```
 
 **Labels array replaces all labels.** Fetch current labels first, then append.