@sjawhar/opencode-legion-envoy 5.2.0 → 5.2.1

package/package.json

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

package/skills/legion-worker/SKILL.md

@@ -304,8 +304,8 @@ line), the full definition of a proof, what the tester verifies, and the simplif
 
 - **Review threads** are disposed of one by one, never in bulk, and only an `Accepted:` from the
   thread's opener (or, on a bot's thread, from the Legion reviewer) closes one. The implementer
-  runs `legion threads resolve` before every push that answers a review, and the merger before
-  READY: `skill://legion-worker/references/review-threads.md`.
+  runs `legion threads resolve` after every push that answers a review, before its completion,
+  and the merger before READY: `skill://legion-worker/references/review-threads.md`.
 - **No deferrals.** A finding that changes
   behaviour, hides an error, or breaks a gate is fixed in this pull request; naming, duplication,
   or wording cleanup is batched into the one `Fast-follow:` line instead of iterating per push.

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

@@ -39,7 +39,7 @@ confirmation or a new round, as the fingerprint decides (*The reviewer*, below,
   nothing restarts. Different: 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.
+  when every thread is settled enough to approve, and resolving one never gates your approval.
 
 A reviewer's phase ends with its completion, not with its review. A round that writes a handoff
 takes this order: write, commit and push the handoff; submit the review of the head that push

package/skills/legion-worker/references/pr-body.md

@@ -29,7 +29,7 @@ later phase keeps it current rather than replacing it:
 **Threads:** <n> resolved, 0 unresolved. Each disposed individually, never in bulk:
 - Thread <id>: fixed in <commit-sha> — <one line>.
 - Thread <id>: not a defect — <reason>.
-`legion threads resolve --pr <n> --repo <owner>/<repo>` at <head-sha>:
+`legion threads resolve --pr <n> --repo <owner>/<repo>`, run after the push that made <head-sha>:
 resolved <thread URL> — its opener's acceptance
 resolved <thread URL> — the Legion reviewer's acceptance of a bot's thread
 left open <thread URL> — newest reply by <login> is not an acceptance

package/skills/legion-worker/references/review-threads.md

@@ -1,8 +1,9 @@
 # Review threads
 
 Part of `skill://legion-worker`. Read it when you reply to, accept, or resolve a review thread,
-or run `legion threads resolve`: the implementer before every push that answers a review, the
-reviewer on every re-review, the merger before READY. Every path it cites is in sjawhar/legion.
+or run `legion threads resolve`: the implementer after every push that answers a review, the
+merger before READY, and the reviewer, who answers threads on every re-review and runs nothing.
+Every path it cites is in sjawhar/legion.
 
 - **Threads are dispositioned individually, never resolved in bulk.** Every open review
   thread gets its own line naming the fixing commit or the reason it isn't a defect. The
@@ -19,16 +20,19 @@ reviewer on every re-review, the merger before READY. Every path it cites is in
   When neither is set, add `--gh` to that command, which applies the fallback's rule below through
   your own `gh`; where no `legion` command is installed, use `gh api graphql` with the session's
   GitHub credential and the fallback below.
-  In a Legion pane, the **implementer** runs the command before every push that answers a review
-  (the corrective push and the final `.legion/` deletion push) and pastes its output into the
-  `Threads` section. The command resolves each unresolved thread whose newest submitted comment is
-  the opener's own `Accepted:` reply. On a thread a bot account opened that is none of Legion's
-  role Apps (the daemon names them, keyed by App role), the Legion reviewer's `Accepted:` also
-  closes it. GitHub cannot tell a CI bot, which never accepts, from a person whose `gh` is routed
-  to an App, so the reviewer adjudicates such a finding, and it may accept one an App-routed person
-  raised. The subject of a finding never closes it: the implementer's `Fixed in <commit>: …` or
-  `Declined: …` answers a thread and closes none. A thread either Legion App opened, a reviewer's
-  finding included, still needs its opener's `Accepted:`. It makes one `resolveReviewThread` per
+  In a Legion pane, the **implementer** runs the command after every push that answers a review
+  (the corrective push, and the final `.legion/` deletion push where the daemon has one) and
+  before its `handoff_complete`, and pastes its output, stamped with the head it just pushed, into
+  the `Threads` section. The output is then recorded against the head the reviewer will read, and
+  nothing reads thread state before the implementer's completion. The command resolves each
+  unresolved thread whose newest submitted comment is the opener's own `Accepted:` reply. On a
+  thread a bot account opened that is none of Legion's role Apps (the daemon names them, keyed by
+  App role), the Legion reviewer's `Accepted:` also closes it. GitHub cannot tell a CI bot, which
+  never accepts, from a person whose `gh` is routed to an App, so the reviewer adjudicates such a
+  finding, and it may accept one an App-routed person raised. The subject of a finding never
+  closes it: the implementer's `Fixed in <commit>: …` or `Declined: …` answers a thread and closes
+  none. A thread either Legion App opened, a reviewer's finding included, still needs its opener's
+  `Accepted:`. It makes one `resolveReviewThread` per
   thread, prints `resolved <url> — <whose acceptance>` (its opener's, or the Legion reviewer's on a
   bot's thread, so the ledger shows which) or `left open <url> — newest reply by <login> is …`
   naming why, and exits 1 naming the thread's URL and GitHub's message when GitHub refuses one.
@@ -63,10 +67,18 @@ reviewer on every re-review, the merger before READY. Every path it cites is in
   Re-read `reviewThreads` and confirm that thread's `isResolved` is true. In either route, report
   a refused resolution to the architect, which opens an ask for a human to resolve the thread by
   hand — never skip it silently. The merger runs the command once more before publishing READY
-  and does not publish while any `left open` line remains.
+  and does not publish while any `left open` line remains. That run is where every accepted
+  thread's resolution is guaranteed, since the merge queue's gate counts the unresolved threads at
+  the head. Acceptances posted after the implementer's last run are resolved here.
 
 - **The reviewer, on a re-review.** When you re-review after a corrective push, answer every
-  thread you opened in one of the three forms above — `Accepted:` is the only reply the
-  implementer's `legion threads resolve` acts on — and approve only once every thread you opened
-  carries your `Accepted:` reply and the implementer's run has resolved it (verify
-  `isResolved: true` with `gh api graphql`, never from the PR body).
+  thread you opened, and every thread a bot opened that is none of Legion's role Apps, in one of
+  the three forms above — `Accepted:` is the only reply `legion threads resolve` acts on. A bot's
+  finding you cannot accept becomes your own: leave it `Still open:` and request changes.
+  Approve once each of those threads has your own `Accepted:` as its newest submitted comment,
+  whether or not GitHub shows the thread resolved yet, and every other unresolved thread its
+  opener's (read the newest comments with `gh api graphql`, never from the PR body). Another
+  opener's thread that a person resolved with GitHub's button, with no `Accepted:`, gates nothing:
+  neither `legion threads resolve` nor the merge queue's gate counts a resolved thread. Resolution
+  is the pull request author's App's, so your approval never waits on it. The merger resolves
+  accepted threads that remain open before publishing READY.