@sjawhar/opencode-legion-envoy 5.4.4 → 5.4.6

package/package.json

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

package/skills/dispatch/references/documents.md

@@ -82,7 +82,8 @@ because replying to an ask makes you one of its followers (see [Following](skill
 `quote` requires `artifact`; its anchor is pinned to the containing block while retaining the quote
 for display. Omit both for a floating issue comment. A reply (`reply_to`/`reply_to_ask`) takes no
 `quote`; it belongs to its parent's anchor. Reply to any comment in a thread; the server keeps
-threads flat. A reply to a resolved thread reopens it. Use `reply_to_ask` to reply directly under a
+threads flat. A reply to a resolved thread reopens it, except a decided suggestion's: a reply joins
+that thread and the suggestion stays accepted or rejected. Use `reply_to_ask` to reply directly under a
 question asked with `dispatch_ask`; `turn` (only with `reply_to_ask`) says who holds the turn after
 the reply — `agent` for a progress note that keeps the ask waiting on you, `human` (the default) when
 the human needs to act; see "Asking" in `skill://dispatch`. Comments are edited only by their author from the
@@ -99,7 +100,8 @@ dispatch_resolve_comment({ comment })
 8+ character id prefix is resolved against the owner's comments). It returns the owner details plus `comment`, and takes no reason —
 say what you did in a `reply_to` first if the thread needs it. The server lets any session or human resolve any open comment, so
 resolve only threads you opened or were asked to close; reopening a resolved thread is human-only (from the dashboard), though your
-reply to it reopens it. Asks are closed with `dispatch_resolve_ask` instead.
+reply to it reopens it - except a decided suggestion's, which your reply joins and leaves accepted or rejected. A reply to a pending
+suggestion whose text an edit removed lands as well. Asks are closed with `dispatch_resolve_ask` instead.
 
 An exact replacement for document text is a suggestion (`dispatch_suggest`), never a comment; a
 comment is for a question or a note the human answers in words. A human accepts a suggestion with

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

@@ -46,10 +46,14 @@ takes this order: write, commit and push the handoff; submit the review of the h
 made, by its SHA; then complete. An approval waits for the CI verdict to settle green at that head
 before you submit it, since an approval stands only on green checks and GitHub can dismiss one
 once the head moves, and a verdict that settles red there makes the round's decision a request for
-changes naming the failing checks; a request for changes does not wait, since it stands whatever
-CI says and the issue leaves reviewing with it. The verdict is of the checks and workflows the
-base branch requires, the set READY checks: red when one of them failed, and never red for a check
-the base branch does not require. A required check that was cancelled, or that the head's checks
+changes naming the failing checks, unless only review workflows the project declares
+(`projects.<KEY>.review_workflows`) are red on their own findings: then you answer their threads,
+have them resolved with `legion threads resolve` and re-run the failed run, as your role prompt
+says, and approve once it passes. Any other red required workflow is a failing check like any
+other. A request for changes does not wait, since it stands whatever CI says and the issue leaves
+reviewing with it. The verdict is of the checks and workflows the base branch requires, the set
+READY checks: red when one of them failed, and never red for a check the base branch does not
+require. A required check that was cancelled, or that the head's checks
 settled without, leaves no verdict until a later settlement decides it, since a run can be
 cancelled or not yet queued when the head settles; a required workflow's run on the head that is
 still going or has not happened leaves none either. A review of a head the handoff push

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

@@ -2,7 +2,8 @@
 
 Part of `skill://legion-worker`. Read it when you reply to, accept, or resolve a review thread,
 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.
+merger before READY, and the reviewer, who answers threads on every re-review and runs the command
+only when a review workflow the project declares is red on a bot's findings.
 Every path it cites is in sjawhar/legion.
 
 - **Threads are dispositioned individually, never resolved in bulk.** Every open review
@@ -15,7 +16,11 @@ Every path it cites is in sjawhar/legion.
   considers only the newest comment). The review App can reply on a thread but cannot resolve it:
   GitHub grants resolving a review thread to the pull request's author, and the implementer opens
   every Legion pull request (`docs/site/src/content/docs/legion/running-legion.md`, "The two
-  GitHub Apps").
+  GitHub Apps"). In the reviewer's pane (`LEGION_ROLE=reviewer`), `legion threads resolve` asks
+  the daemon instead (`POST /legion/v1/threads/resolve`), which resolves as the implementer's App
+  only the threads a bot outside Legion's role Apps opened whose newest submitted comment is the
+  reviewer's `Accepted:`, on the pull request of the reviewer's own issue, and prints the same
+  lines; the reviewer never holds the implementer's token.
   When `LEGION_GRANT_FILE` or `LEGION_GRANT` is set, use `legion threads resolve --pr <number> --repo <owner>/<repo>`.
   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
@@ -80,5 +85,9 @@ Every path it cites is in sjawhar/legion.
   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.
+  is the pull request author's App's, so your approval never waits on it, except when a review
+  workflow the project declares (`projects.<KEY>.review_workflows`) is red on its findings: such a
+  workflow passes on a re-run only once its threads are resolved, so you run `legion threads
+  resolve` (the daemon resolves the bot threads you accepted) and re-run the failed run before you
+  approve, as your role prompt says.
+  The merger resolves accepted threads that remain open before publishing READY.