@sjawhar/opencode-legion-envoy 8.3.3 → 8.3.5

package/dist/dispatch.js

@@ -14043,7 +14043,7 @@ var dispatchToolSpecs = [
       status: "done",
       reason: "Shipped in owner/repo#7; verified on the production dashboard."
     },
-    description: "Update an existing issue: move its lifecycle status, retitle it, replace its labels, set " + "its priority, link a URL (the pull request that delivers it, a run, a document), set its " + "route, set or clear its parent, replace the issues it is blocked by, or attach it to " + "architecture components. Status is one of " + `${ISSUE_STATUSES.join(", ")}; outside Legion, move it yourself as the work advances; inside ` + "Legion the daemon moves it. external_links are " + "merged into the issue's existing links by URL, so linking the pull request you just opened " + "keeps every earlier link. components replaces the issue's own attachment. Closing an issue " + "(status done) requires reason, the note that says why: it is posted on the issue as a " + "message, then the issue closes, because a closed issue refuses messages, comments, and " + "artifacts; reason goes only with status done. A closed issue takes only rank, components, " + "and a reopening status (any status but done); everything else, priority included, waits " + "for the reopen. " + "priority is yours to set and a human overrides it; rank, the board's own order, is not " + "settable here. At least one " + `field besides issue is required. ${ISSUE_REFERENCE}`,
+    description: "Update an existing issue: move its lifecycle status, retitle it, replace its labels, set " + "its priority, link a URL (the pull request that delivers it, a run, a document), set its " + "route, set or clear its parent, replace the issues it is blocked by, or attach it to " + "architecture components. Status is one of " + `${ISSUE_STATUSES.join(", ")}; outside Legion, move it yourself as the work advances; inside ` + "Legion the daemon moves it. A non-empty external_links is " + "merged into the issue's existing links by URL, so linking the pull request you just opened " + "keeps every earlier link; an empty external_links removes every link instead. components " + "replaces the issue's own attachment. Closing an issue " + "(status done) requires reason, the note that says why: it is posted on the issue as a " + "message, then the issue closes, because a closed issue refuses messages, comments, and " + "artifacts; reason goes only with status done. A closed issue takes only rank, components, " + "a reopening status (any status but done), and an external_links write that adds no new " + "link (so a link can move to the issue that replaced it); everything else, priority " + "included, waits for the reopen. " + "priority is yours to set and a human overrides it; rank, the board's own order, is not " + "settable here. At least one " + `field besides issue is required. ${ISSUE_REFERENCE}`,
     arguments: (z2) => ({
       issue: z2.string().describe(ISSUE_REFERENCE),
       status: z2.enum(ISSUE_STATUSES).describe("New lifecycle status.").optional(),
@@ -14051,7 +14051,7 @@ var dispatchToolSpecs = [
       title: z2.string({ min: 1, max: ISSUE_TITLE_MAX }).describe("Replacement title, at most 1,000 characters.").optional(),
       labels: z2.array(z2.string({ min: 1, max: 40 }), { max: 20 }).describe("Replacement label set, at most 20 labels of up to 40 characters; replaces every existing label.").optional(),
       priority: z2.number({ int: true, min: 0, max: 3 }).nullable().optional().describe("Coarse priority: 0 is P0 (highest) through 3 is P3 (lowest); null clears it."),
-      external_links: z2.array(z2.string({ min: 1 })).describe("URLs to link; merged into the issue's existing external links by URL.").optional(),
+      external_links: z2.array(z2.string({ min: 1 })).describe("URLs to link; a non-empty list merges into the issue's existing external links by URL, an empty list removes every link instead.").optional(),
       route: z2.string().describe("Route the issue to role:<name> or session:<id>; an empty string clears it.").optional(),
       parent: z2.string().describe("Parent issue key in the same project; an empty string clears the parent.").optional(),
       blocked_by: z2.array(z2.string({ min: 1 }), { max: MAX_ISSUE_BLOCKERS }).describe("Replacement list of issue keys in the same project this issue waits on; [] clears it. Dispatch refuses a dependency cycle.").optional(),
@@ -17515,6 +17515,7 @@ async function executeDispatchTool(input) {
       }
       const linked = before.external_links.map((link) => link.url);
       const newLinks = requestedLinks?.filter((url2) => !linked.includes(url2)) ?? [];
+      const sentLinks = requestedLinks === undefined ? undefined : requestedLinks.length === 0 ? [] : [...before.external_links, ...newLinks.map((url2) => ({ url: url2 }))];
       let after;
       try {
         after = await client.updateIssue(issueKey, {
@@ -17526,7 +17527,7 @@ async function executeDispatchTool(input) {
           ...parent === undefined ? {} : { parent: parent === "" ? null : parent },
           ...blockedBy === undefined ? {} : { blocked_by: blockedBy },
           ...components === undefined ? {} : { components },
-          ...requestedLinks === undefined ? {} : { external_links: [...before.external_links, ...newLinks.map((url2) => ({ url: url2 }))] },
+          ...sentLinks === undefined ? {} : { external_links: sentLinks },
           actor
         });
       } catch (error48) {
@@ -17548,7 +17549,7 @@ async function executeDispatchTool(input) {
         ...labels === undefined ? [] : [after.labels.length === 0 ? "labels cleared" : `labels ${after.labels.join(", ")}`],
         ...priority === undefined ? [] : [after.priority === null ? "priority cleared" : `priority -> P${after.priority}`],
         ...requestedLinks === undefined ? [] : [
-          newLinks.length === 0 ? `already linked ${requestedLinks.join(", ")} ${linkCount}` : `linked ${newLinks.join(", ")} ${linkCount}`
+          requestedLinks.length === 0 ? "external links cleared" : newLinks.length === 0 ? `already linked ${requestedLinks.join(", ")} ${linkCount}` : `linked ${newLinks.join(", ")} ${linkCount}`
         ],
         ...route === undefined ? [] : [after.route === null ? "route cleared" : `route ${after.route}`],
         ...parent === undefined ? [] : [after.parent === null ? "parent cleared" : `parent -> ${after.parent}`],

package/dist/src/server.js

@@ -13900,7 +13900,7 @@ var dispatchToolSpecs = [
       status: "done",
       reason: "Shipped in owner/repo#7; verified on the production dashboard."
     },
-    description: "Update an existing issue: move its lifecycle status, retitle it, replace its labels, set " + "its priority, link a URL (the pull request that delivers it, a run, a document), set its " + "route, set or clear its parent, replace the issues it is blocked by, or attach it to " + "architecture components. Status is one of " + `${ISSUE_STATUSES.join(", ")}; outside Legion, move it yourself as the work advances; inside ` + "Legion the daemon moves it. external_links are " + "merged into the issue's existing links by URL, so linking the pull request you just opened " + "keeps every earlier link. components replaces the issue's own attachment. Closing an issue " + "(status done) requires reason, the note that says why: it is posted on the issue as a " + "message, then the issue closes, because a closed issue refuses messages, comments, and " + "artifacts; reason goes only with status done. A closed issue takes only rank, components, " + "and a reopening status (any status but done); everything else, priority included, waits " + "for the reopen. " + "priority is yours to set and a human overrides it; rank, the board's own order, is not " + "settable here. At least one " + `field besides issue is required. ${ISSUE_REFERENCE}`,
+    description: "Update an existing issue: move its lifecycle status, retitle it, replace its labels, set " + "its priority, link a URL (the pull request that delivers it, a run, a document), set its " + "route, set or clear its parent, replace the issues it is blocked by, or attach it to " + "architecture components. Status is one of " + `${ISSUE_STATUSES.join(", ")}; outside Legion, move it yourself as the work advances; inside ` + "Legion the daemon moves it. A non-empty external_links is " + "merged into the issue's existing links by URL, so linking the pull request you just opened " + "keeps every earlier link; an empty external_links removes every link instead. components " + "replaces the issue's own attachment. Closing an issue " + "(status done) requires reason, the note that says why: it is posted on the issue as a " + "message, then the issue closes, because a closed issue refuses messages, comments, and " + "artifacts; reason goes only with status done. A closed issue takes only rank, components, " + "a reopening status (any status but done), and an external_links write that adds no new " + "link (so a link can move to the issue that replaced it); everything else, priority " + "included, waits for the reopen. " + "priority is yours to set and a human overrides it; rank, the board's own order, is not " + "settable here. At least one " + `field besides issue is required. ${ISSUE_REFERENCE}`,
     arguments: (z2) => ({
       issue: z2.string().describe(ISSUE_REFERENCE),
       status: z2.enum(ISSUE_STATUSES).describe("New lifecycle status.").optional(),
@@ -13908,7 +13908,7 @@ var dispatchToolSpecs = [
       title: z2.string({ min: 1, max: ISSUE_TITLE_MAX }).describe("Replacement title, at most 1,000 characters.").optional(),
       labels: z2.array(z2.string({ min: 1, max: 40 }), { max: 20 }).describe("Replacement label set, at most 20 labels of up to 40 characters; replaces every existing label.").optional(),
       priority: z2.number({ int: true, min: 0, max: 3 }).nullable().optional().describe("Coarse priority: 0 is P0 (highest) through 3 is P3 (lowest); null clears it."),
-      external_links: z2.array(z2.string({ min: 1 })).describe("URLs to link; merged into the issue's existing external links by URL.").optional(),
+      external_links: z2.array(z2.string({ min: 1 })).describe("URLs to link; a non-empty list merges into the issue's existing external links by URL, an empty list removes every link instead.").optional(),
       route: z2.string().describe("Route the issue to role:<name> or session:<id>; an empty string clears it.").optional(),
       parent: z2.string().describe("Parent issue key in the same project; an empty string clears the parent.").optional(),
       blocked_by: z2.array(z2.string({ min: 1 }), { max: MAX_ISSUE_BLOCKERS }).describe("Replacement list of issue keys in the same project this issue waits on; [] clears it. Dispatch refuses a dependency cycle.").optional(),

package/package.json

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

package/skills/dispatch/references/issues.md

@@ -85,7 +85,7 @@ issues you own as well as the root. An issue left at `triage` while work is unde
 Waiting for the deploy lane is not a status and is never announced.
 
 ```bash
-# PATCH /api/v1/issues/{key} — status, title, labels, priority, external links (merged by URL), route, parent, blocked_by
+# PATCH /api/v1/issues/{key} — status, title, labels, priority, external links (merged by URL, or cleared by an empty list), route, parent, blocked_by
 dispatch issue-update --issue PROJ-175 --status testing
 dispatch issue-update --issue PROJ-175 --status done --reason 'Shipped in owner/repo#7; verified on the production dashboard.'
 dispatch issue-update --issue PROJ-175 --priority 1   # 0–3; see Priority is yours to set
@@ -100,8 +100,9 @@ error names the posted message; after a timeout or a server error it also says t
 landed, so read the issue's status first. A retry points its reason at the posted message rather
 than repeating it.
 
-The two clears differ: `--clear-priority` sends null, while `--parent ''` and `--route ''` clear with an
-empty string. Guessing the other one is a refusal either way.
+The three clears differ: `--clear-priority` sends null, `--parent ''` and `--route ''` clear with an
+empty string, and `--clear-external-links` / `--clear-blocked-by` send an empty list. Guessing the
+wrong shape is a refusal either way.
 
 Link the pull request that delivers the issue with `--external-link` when you open it; the issue page
 renders its state and checks from that link, and `dispatch read` lists it under `External links:`.
@@ -122,7 +123,8 @@ Priority is the coarse bucket a backlog is read by: `0` is P0, the highest, thro
 lowest, and `null` clears it. Agents set it (`dispatch://LEGION/artifact/issue-status-conventions-md`)
 — on creation, and on a grooming pass over issues that have none — and say what you set and why;
 the human overrides anything they disagree with from the dashboard. A closed
-issue takes only `rank`, `components`, and a reopening `status` (any status but `done`);
+issue takes only `rank`, `components`, a reopening `status` (any status but `done`), and an
+external-links write that adds no new link (so a link can move to the issue that replaced it);
 everything else, `priority` included, waits for the reopen (`409 ISSUE_CLOSED`). So reopen it
 first, then set the priority — the two cannot go in one command. `rank` itself is not a flag:
 reorder it the way [Issue reads](#board-rank-priority-and-assignee-on-a-read) describes, through `PATCH /api/v1/issues/{key}`.

package/skills/legion-retro/SKILL.md

@@ -133,8 +133,8 @@ merger.
    they derive nothing, skip steps 2 to 4 and go on to the push.
 2. Compute it the way they say, for the paths the pull request changes at your head, the files
    GitHub lists on it:
-   `cd -- "$LEGION_WORKSPACE" && jj -R "$LEGION_WORKSPACE" git fetch && jj -R "$LEGION_WORKSPACE" diff --from 'fork_point(<base>@origin | <head>)' --to <head> --name-only`
-   lists them, `<base>` the pull request's base branch and `<head>` your removal commit. Where a
+   `base=$(gh pr view <n> -R <owner>/<repo> --json baseRefName -q '.baseRefName | @json') && cd -- "$LEGION_WORKSPACE" && jj -R "$LEGION_WORKSPACE" git fetch && jj -R "$LEGION_WORKSPACE" diff --from "fork_point(${base}@origin | <head>)" --to <head> --name-only`
+   lists them, `base` the pull request's base branch as a jj string literal (never a name pasted between quotes) and `<head>` your removal commit. Where a
    line affirms work, such as a checklist completed for a class of path, do that work for the
    paths your commits add before you write the line: the line is a claim. That work may change
    files under `docs/solutions/` only, folded into your docs commit before the push, since

package/skills/legion-worker/SKILL.md

@@ -176,8 +176,8 @@ config is one file shared by every issue workspace of the clone. Legion has two
 one per role: your role's App is the **implement** App if you are the implementer or the merger,
 and the **review** App if you are the planner, tester, reviewer, or an architect; your pane's
 `JJ_USER` and `JJ_EMAIL` name your role's App's bot account. A planner's commits authored
-by the review App are right. Before a push, check
-`jj -R "$LEGION_WORKSPACE" log -r 'main@origin..@' -T 'author.email() ++ " | " ++ committer.email() ++ " " ++ description.first_line() ++ "\n"'`
+by the review App are right. Before a push, check, with GitHub's default branch read as a jj string literal in the same command (never a name pasted between quotes),
+`default=$(gh api repos/<owner>/<repo> --jq '.default_branch | @json') && jj -R "$LEGION_WORKSPACE" log -r "${default}@origin..@" -T 'author.email() ++ " | " ++ committer.email() ++ " " ++ description.first_line() ++ "\n"'`
 shows your role's App in both columns **on every commit you made** — not on the whole list:
 earlier phases' commits are legitimately authored by their own role's App. Their *committer* is
 a different matter, and no longer noise to accept. Resolving a conflict rewrites nothing — it is a

package/skills/legion-worker/references/conflicts-and-rewrites.md

@@ -11,7 +11,7 @@ Every path it cites is in sjawhar/legion.
   merge, never `jj rebase`.**
   The implementer merges the base into the issue branch only when GitHub reports it `CONFLICTING`, the controller asks
   because of a conflict, or after the pull request is retargeted to a new base. Otherwise, never reintegrate the base to
-  pick up `main` or refresh CI (a single failed CI job is re-run on its own: *A red CI job* in
+  pick up the default branch or refresh CI (a single failed CI job is re-run on its own: *A red CI job* in
   `skill://legion-worker`). A conflict-forced rebase that leaves the branch's diff unchanged is a
   confirmation, not a new round (see *The unchanged-diff check* below); that name is the event's,
   kept by the rules below and the learnings that cite it, and the operation it names is always
@@ -28,10 +28,15 @@ Every path it cites is in sjawhar/legion.
   `-r` all rewrite descendants; `-r` only re-parents them to fill the hole, which is worse).
   Resolve the conflict with a forward merge instead of a rewrite — merge the branch's own
   bookmark with the destination in one new commit, so nothing existing is rewritten and nothing
-  built on your prior commits, in this tree or another, ever moves:
+  built on your prior commits, in this tree or another, ever moves. `base` is the pull request's
+  base branch (the repository's default branch unless the pull request is stacked), read as a jj
+  string literal: jj parses a bare bookmark name as an expression, and a name pasted between
+  quotes can close them itself (`release"@origin|"stable` would select `release` and `stable`), so
+  the revset is built from the serialized name alone:
 
   ```bash
-  jj -R "$LEGION_WORKSPACE" new legion/<KEY> main@origin -m "merge: resolve conflict against main@origin"
+  base=$(gh pr view <n> -R <owner>/<repo> --json baseRefName -q '.baseRefName | @json') && \
+    jj -R "$LEGION_WORKSPACE" new legion/<KEY> "${base}@origin" -m "merge: resolve conflict against ${base}@origin"
   ```
 
   Merge from the bookmark, never from `@`: a handoff split leaves `@` an empty, undescribed
@@ -44,8 +49,9 @@ Every path it cites is in sjawhar/legion.
   pushes its own commits* in `skill://legion-worker`; a merge is a code push, so its head carries
   no `skip-checks: true` line): the merge descends from both the bookmark's old position and the
   destination, so it is a genuine fast-forward and *Rewriting pushed commits* never applies.
-- **After a retarget.** Retargeting a pull request to a new base does not re-run Tests. Merge the
-  bookmark onto the new base (`jj new legion/<KEY> <new base> -m "<message>"`) and push it the
+- **After a retarget.** Retargeting a pull request to a new base does not re-run Tests. Read
+  `base` again and merge the bookmark onto it in one command
+  (`base=$(gh pr view <n> -R <owner>/<repo> --json baseRefName -q '.baseRefName | @json') && jj -R "$LEGION_WORKSPACE" new legion/<KEY> "${base}@origin" -m "<message>"`) and push it the
   ordinary way — a genuine fast-forward, never `--allow-backwards` — so the new head runs Tests
   against the new merge result, and cite that run in the PR body.
 
@@ -55,20 +61,23 @@ The fingerprint every role compares after a conflict-forced rebase (every flag a
 verified on jj 0.45.1):
 
 ```bash
+base=$(gh pr view <n> -R <owner>/<repo> --json baseRefName -q '.baseRefName | @json') && \
 cd -- "$LEGION_WORKSPACE" && jj -R "$LEGION_WORKSPACE" git fetch && \
-  jj -R "$LEGION_WORKSPACE" diff --from "fork_point(main@origin | <head-sha>)" --to <head-sha> \
+fingerprint=$(set -o pipefail; jj -R "$LEGION_WORKSPACE" diff --from "fork_point(${base}@origin | <head-sha>)" --to <head-sha> \
     --git --context 0 '~(.legion | docs/solutions)' \
-  | sed -e '/^@@/d' -e '/^index /d' | sha256sum
+  | sed -e '/^@@/d' -e '/^index /d' | sha256sum) && echo "$fingerprint"
 ```
 
 - `<head-sha>` is a full commit SHA; a jj commit id is the git SHA GitHub shows.
-- `fork_point(main@origin | <head-sha>)` is the base the branch was cut from *at that head*:
-  the old base for the pre-rebase head, the new base for the rebased one, so one command
-  serves both sides. On a stacked PR substitute its base branch for `main`
-  (`gh pr view <n> --json baseRefName`).
-- A head the rebase hid is still addressable by its SHA in the shared workspace. A SHA the
-  workspace cannot resolve (`jj -R "$LEGION_WORKSPACE" log -r <sha>` errors) counts as a
-  changed diff — never as unchanged.
+- `fork_point(${base}@origin | <head-sha>)` is the base the branch was cut from *at that head*:
+  the old base for the pre-rebase head, the new base for the rebased one, so one command serves
+  both sides. `base` is the pull request's base branch as a jj string literal, as in the merge
+  above.
+- A head the rebase hid is still addressable by its SHA in the shared workspace. The check
+  prints a fingerprint only when every step of it succeeded: the base read, the fetch and the
+  diff (`pipefail` keeps the diff's failure through `sed` and `sha256sum`, which would otherwise
+  hash empty input to `e3b0c442…`). A nonzero exit or no printed fingerprint (a failed read of the
+  base, or a SHA the workspace cannot resolve) counts as a changed diff — never as unchanged.
 - `--context 0` drops context lines; the `sed` drops `@@` hunk headers (line positions move
   on a rebase) and `index` lines (blob ids move when the base's copy of a file changed). What
   is left is exactly the added and removed lines per file.

package/skills/legion-worker/references/merge-gate.md

@@ -25,12 +25,20 @@ the head voids it.
   every commit above that push's head changes only `.legion/` (a push that changes only
   `.legion/` carries `skip-checks: true`, so GitHub runs no workflow for it). With `<o>/<r>`,
   `<n>`, `<base>`, `<headRefName>` and `<headRefOid>` from
-  `gh pr view <n> --json baseRefName,headRefOid,headRefName`, four reads. The required set, from
-  the base branch's rulesets
-  (`gh api repos/<o>/<r>/rules/branches/<base> --jq '.[] | select(.type=="required_status_checks") | .parameters.required_status_checks[].context'`)
-  and its branch protection, when it has any
-  (`gh api repos/<o>/<r>/branches/<base> --jq '.protection.required_status_checks.checks[].context'`);
-  a read GitHub refuses is reported to the architect, never guessed. The CI head, the head of the
+  `gh pr view <n> --json baseRefName,headRefOid,headRefName`, four reads. The required set is the
+  base branch's rulesets' required checks and its branch protection's, when it has any. Both
+  branch endpoints take the base as a URL path, each segment escaped and each `/` kept (a raw `#`
+  or `%` reads another branch), built in the same command from the name GitHub returns, never
+  pasted or carried over from an earlier command:
+
+  ```bash
+  base=$(gh pr view <n> -R <o>/<r> --json baseRefName -q .baseRefName) && \
+    base_path=$(jq -rn --arg b "$base" '$b | split("/") | map(@uri) | join("/")') && \
+    echo rulesets: && gh api "repos/<o>/<r>/rules/branches/$base_path" --jq '.[] | select(.type=="required_status_checks") | .parameters.required_status_checks[].context' && \
+    echo protection: && gh api "repos/<o>/<r>/branches/$base_path" --jq '.protection.required_status_checks.checks[].context'
+  ```
+
+  A read GitHub refuses stops the command there, and is reported to the architect, never guessed. The CI head, the head of the
   branch's newest `pull_request` run
   (`gh api 'repos/<o>/<r>/actions/runs?branch=<headRefName>&event=pull_request&per_page=30' --jq '.workflow_runs[0].head_sha'`,
   newest first); the PR body's `CI:` line names runs at that same commit
@@ -62,7 +70,8 @@ the head voids it.
   `APPROVE`: submit one more `APPROVE` naming the new head by SHA, its body naming both SHAs
   and the fingerprint — a confirmation, not a round; no thermo pass, no thread pass. Equal and
   that review was `COMMENT` or `REQUEST_CHANGES`: continue that round against the new head;
-  nothing restarts. Different: a new round — thermo again, one review.
+  nothing restarts. Different, or either run printed no fingerprint: a new round — thermo again,
+  one review.
 - Answer every thread you opened, and every thread a bot opened that is none of Legion's role
   Apps, as `skill://legion-worker/references/review-threads.md` says; the same reference says
   when every thread is settled enough to approve, and resolving one never gates your approval.