@sjawhar/pi-legion 10.3.5 → 10.3.6

package/dist/legion.js

@@ -16148,7 +16148,7 @@ function onEnvoyRoleRegained(listener) {
 // package.json
 var package_default = {
   name: "@sjawhar/pi-legion",
-  version: "10.3.5",
+  version: "10.3.6",
   license: "Apache-2.0",
   type: "module",
   omp: {

package/dist/skills/legion-architect/SKILL.md

@@ -315,12 +315,14 @@ The daemon keeps this order from its fixed table; you start none of its steps:
    refuses a head that still carries `.legion/<issue>/`; the daemon posts
    `READY #<n> at <current sha> (approved at <approved sha>) for <KEY> (<pr url>)` on the Dispatch
    issue and publishes it to the project's merge queue role when one is set. The moment the daemon
-   accepts READY, the merger submits the pull request with
-   `gh pr merge <n> -R <owner>/<repo> --auto --squash --match-head-commit <head>` and tells you what
-   the command answered; the repository's required reviews and checks decide when it lands, and
-   Legion neither reads nor writes those rules. A READY the design gate refused is submitted later:
-   the merger submits nothing on a refusal, so once that spec version is approved and the daemon
-   posts the packet, tell the merger to submit it. If the merger reports a failed verification,
+   accepts READY, it submits the merge of that head itself, as the implement App and with GitHub's
+   expected-head check: a merge queue enqueues it, a pull request already mergeable merges at once,
+   a repository that allows auto-merge arms it, and in one that allows neither the daemon merges it
+   once GitHub reports it mergeable. The repository's required reviews and checks decide when it
+   lands, and Legion neither reads nor writes those rules; a review only a person can give is
+   waited for, never bypassed, and once given the daemon merges or the person does. A READY the
+   design gate refused is submitted by the daemon once that spec version is approved; nobody is
+   told to submit it. If the merger reports a failed verification,
    treat it like `pr-blocked`: the merger holds the phase, so tell it to move the issue back with
    `request_backward_move`, naming what failed; never bypass. A READY refused because the head
    still carries `.legion/<issue>/` goes back to `retro`, so the implementer's retro removes it.
@@ -404,6 +406,8 @@ active phase worker.
 | `pr-blocked` | Its `reason` names the pull request and the `max_fix_attempts` it reached, or reads `Issue reached review_round_cap=<N>.` (the end of this row). The count is of heads pushed onto a red verdict that changed something outside `.legion/` — handoff-only pushes (`.legion/` paths only) never count, a push by the review App (a planner's, tester's, reviewer's or architect's) never counts, and the head after a red the tester's red tests earned (a review-App push that changed a path outside `.legion/`, however many handoff-only pushes follow it) does not count either — so after the tester's handoff-only push onto the implementer's red, the implementer's next push does count; a push the daemon cannot classify (a listener without `changed_paths`, a list the listener stopped at 100 paths or 32,768 runes of text, a push listing no commits) does. Published once per exhausted count, not on every later red verdict for that count. Read the failed CI evidence and recovery attempts. The notice moves nothing, and no later CI red within the attempt that ran the count out (the counted head, and every head pushed on top of it until a push lands on a head CI judged green, the tester's red tests and handoff onto the held red included) sends the work back from `testing`, `reviewing`, `retro` or `merging` either: the issue stays in its phase until you move it, or a worker's own decision does (a tester's `fail`, a reviewer's request for changes). A head pushed onto green CI leaves that attempt, so its red still comes as a `checks-red`. In `implementing`, give the implementer the failing checks (`envoy_publish` to its role topic). In any later phase a worker holds, tell that worker (`envoy_publish` to its role topic) to move the issue back to `implementing` with `request_backward_move`, naming the failing checks, and the daemon starts the implementer; or file a corrective child. In `awaiting_merge`, where no worker holds a phase and a backward move is refused, open a `dispatch ask` naming the failing checks for the human who merges, as section 6 does for a conflict there. Do not treat the blocked PR as final. A `review_round_cap` reason is the implementer's round count instead: every move back to an earlier phase counts one, and the notice comes again with each round past the cap. It moves nothing either, since the round that reached the cap has already started its worker. Tell the rounds apart by what announced each: a tester's fail by its `phase-finished` with `verdict: "fail"`; a request for changes by the reviewer's `phase-finished` over a `CHANGES_REQUESTED` review; the daemon's own move by a `checks-red` notice, whose reason names either a conflict (`the head conflicts with <base>`) or the required checks that failed (`CI is red at <head>`); a worker's `request_backward_move` by a `phase-finished` from the role that asked, whose reason reaches only the task of the worker the move started, so ask that worker. Judge the cap by the rounds that are not conflicts. Conflict returns need nothing from you beyond the next round. Tester fails, requests for changes and CI-red returns (a `checks-red` notice is raised for CI only when a required check fails on code the branch pushed) are the work going in circles: narrow it, re-plan it with the responsible worker, or ask a human with `dispatch ask`. Judge a worker's backward move by the reason that worker gives. A move you ordered for a conflict found before `awaiting_merge` (section 6) is a conflict return. The merger's move back to `reviewing` because its task names no approved head is not the work going in circles either. A move that sends back code found wrong counts with the tester fails. |
 | `pr-merged` | Its `reason` names the pull request. The PR merged, under the repository's rules, before the issue reached `awaiting_merge`. The workflow runs on and asks no one to merge it: the daemon starts the **implementer** on the production check once the issue gets there, and you start nothing. Its `phase-finished` for `production_check` is what brings you to step 7: verify the record on the pull request and this issue first, then sign off naming it with `sign_off`. A merge is not the close. |
 | `pr-closed-unmerged` | Decide from current scope whether the work is reopened, started over (`park_child` then `rerun_child`, for a child), or ended with a reason. Delegate the repository action to the responsible phase worker and keep ownership. |
+| `merge-refused` | Its `reason` names the pull request, READY's head, what the daemon asked GitHub to do (merge, enqueue, or enable auto-merge for it), and GitHub's refusal, which a retry would meet again (squash merges disabled, a permission the implement App lacks). The daemon has stopped submitting that merge; the issue stays in `awaiting_merge`. The cause is a repository setting or an App permission, a person's to change: ask one with `dispatch ask`, naming the refusal and the pull request at READY's head, which that person merges under the repository's rules once it is fixed. The merge moves the issue on to its production check. Never bypass a rule. |
+| `merge-stalled` | Its `reason` names the pull request, the state and head GitHub shows (closed, or another head), since when GitHub has shown it, and READY's head, which the record still awaits. GitHub's last change to the pull request is more than 10 minutes old and the record never heard of it, so its webhook never reached the daemon: the daemon has stopped submitting that merge, and the issue stays in `awaiting_merge`. Read the pull request on GitHub. Open at READY's head, GitHub has caught up: a person merges it under the repository's rules, and the merge moves the issue on to its production check. Closed, or at another head the daemon never recorded: ask a person with `dispatch ask`, naming the pull request, what GitHub shows, and READY's head. Never bypass a rule. |
 | A reply on an ask you follow | Interpret the reply in the issue's design context. Answer in its thread (`dispatch comment --reply-to <comment id>`; under an open ask whose next move is yours, such as the approval request you must revise or hand back, `--reply-to-ask <ask id> --turn agent`, since a default-turn reply hands that request back to the human and a corrected `--summary` is then refused), then adjust the plan or relay it via `envoy_publish` to the responsible worker's role token; scope and product decisions remain with you. |
 | `worker-died` | Its `role` and `phase`. That role's claim failed: its launches or prompts ran out. For a phase worker the daemon holds the issue (phase `held`) and starts nothing more on it. Reassess the work, then decide with `retry_or_escalate`: `retry` when the failure looks agent-specific or transient, `escalate` to hand the held issue to the controller when it looks environmental. |
 | `held` | Its `role` and `phase` (the phase the issue left), or `phase` with `reason: "escalated"`. Without `reason`, that phase's worker ran out of launches or prompts: the issue is held (phase `held`), the `worker-died` that comes with it is yours to answer with `retry_or_escalate` as that row says, and the controller hears of the hold too. With `reason: "escalated"`, it records your own `escalate`: the controller has the issue now, and you start nothing for it. |

package/dist/skills/legion-retro/SKILL.md

@@ -30,7 +30,7 @@ retrospective's durable output.
    `jj diff --from <approved-sha> --to <tip-sha> --summary` in READY, and sends the READY packet
    with its completion, which refuses a head that still carries `.legion/<issue>/`; the daemon
    posts it on the Dispatch issue and publishes it to the project's merge-queue role when one is
-   configured. On READY's acceptance the merger submits the merge, and it lands under the
+   configured. On READY's acceptance the daemon submits the merge, and it lands under the
    repository's rules: its required reviews and checks, and its merge queue when it enables one.
 5. After that merge, the implementer — not the reviewer or merger — verifies the change in production
    and records it on the PR and the issue: the agent that developed it is responsible for testing

package/dist/skills/legion-worker/SKILL.md

@@ -307,12 +307,11 @@ line), the full definition of a proof, what the tester verifies, and the simplif
   afterwards is in the same reference: `skill://legion-worker/references/conflicts-and-rewrites.md`.
 - **The merge gate**, in order: the tester's evidence green → the reviewer's approval of the head
   → retro → the merger's READY → the merge → the implementer's production check. On READY's
-  acceptance the merger submits the pull request with
-  `gh pr merge <n> -R <owner>/<repo> --auto --squash --match-head-commit <head>`, unless the
-  answer's note begins `MANUAL_MERGE_REQUIRED:`, where a person merges it; the repository's
-  required reviews and checks decide when it lands
+  acceptance the daemon submits the merge of the head READY named, unless the answer's note begins
+  `MANUAL_MERGE_REQUIRED:`, where a person merges it; no role runs `gh pr merge`, and the
+  repository's required reviews and checks decide when it lands
   (`skill://legion-worker/references/merge-gate.md`). The reviewer's submissions, retro's commit,
-  the merger's READY and its submission, and the production check follow the same reference.
+  the merger's READY, the daemon's submission, and the production check follow the same reference.
 - **No surface reaches the changed path** is a report to the architect, never a reason to
   complete the phase: `skill://legion-worker/references/pr-body.md`.
 

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

@@ -1,8 +1,8 @@
 # The merge gate: review, retro, READY, and the production check
 
 Part of `skill://legion-worker`. Read it when you are the reviewer submitting a review or an
-approval, the implementer recording the production check, or the merger building READY and
-submitting the merge. Every path it cites is in sjawhar/legion.
+approval, the implementer recording the production check, or the merger building READY. Every
+path it cites is in sjawhar/legion.
 
 The order, in full: the tester's evidence green → the reviewer's approval of the head →
 retro → the merger's READY → the merge → the implementer's production check. The approved
@@ -126,44 +126,57 @@ reviewing until you finish.
   checks run in the daemon, which reads the pull request's head on GitHub and refuses, before
   recording anything, on each ground the merger's role prompt names in its `Go daemon workflow`
   part, by its code and with its remedy. That part is the one complete list of READY's refusals.
-  A refusal records nothing; the merger reports it to the architect unless it says to complete
+  A required check or workflow still running refuses nothing; a failed or missing one does. A
+  refusal records nothing; the merger reports it to the architect unless it says to complete
   again, and never pushes a commit to make CI run. On success the daemon posts the packet as a
   `dispatch message` on the issue, publishes it to the project's merge queue role when one is set,
   and says on the issue when that role has no live holder; the answer's `note` says when READY was
   published on a pull request a person already merged, whose head can no longer change, or on a
   base that requires no check, which the packet itself also says, or carries the by-hand note of a
   pull request a person merges.
-- **The merger submits the merge the moment READY is accepted, unless the answer says a person
-  merges it.** In the same turn, before anything else, it runs
-  `gh pr merge <n> -R <owner>/<repo> --auto --squash --match-head-commit <head>` with its pane's
-  plain `gh`: `<n>` the pull request number, `<head>` the full sha of the current head READY named.
-  A repository with a merge queue enqueues the pull request; one without arms auto-merge; one whose
-  rules are already satisfied merges at once. `--match-head-commit` has GitHub refuse the request
-  when the head has moved since READY read it. The repository's required reviews and checks decide
-  when it lands: the merger makes no merge by hand and bypasses no rule. It then tells the
-  architect with `envoy_publish` to its encoded role token what the command answered — enqueued,
-  auto-merge enabled, or merged — and the head. When the answer's `note` begins
-  `MANUAL_MERGE_REQUIRED:` (the pull request touches a path the project's `merge.by_hand` names),
-  READY stands but the merger submits nothing: it tells the architect the note and the head, and a
-  person merges under the repository's rules. The daemon tells that READY with the note at its head
-  and the packet's `Merge:` line replaced, so the issue and the merge queue role are never asked to
-  arm it. On any READY refusal it submits nothing, since an armed request would merge through the
-  gate the refusal names; a READY the design gate refused is submitted later, on the architect's
-  word, once the gate opens, and that turn runs only `gh` and a read of the READY the daemon posted
-  then: a refusal or a posted READY carrying the by-hand note is submitted by nobody. A push that
-  moves the head past a READY the gate holds voids it before then: the architect is told
-  `READY_HEAD_MOVED` and has the merger build a new READY at the new head. A
-  `gh pr merge` GitHub refuses is reported to the architect with its message; a person can still
-  merge after READY. The packet's second line records the step,
-  `Merge: submit on normal acceptance with gh pr merge <n> -R <owner>/<repo> --auto --squash --match-head-commit <head>`.
-- **The daemon disarms a merge no READY covers.** Auto-merge stays enabled across pushes, and
-  `--match-head-commit` is checked only when it is enabled, so the daemon itself disables the pull
+- **The daemon submits the merge the moment READY is accepted, unless the answer says a person
+  merges it.** It queues a `ready_merge` outbox row for the head READY named, and the row, as the
+  implement App, reads GitHub and then the record: while the issue still awaits that READY head, a
+  base with a merge queue gets the pull request enqueued; otherwise a pull request GitHub reports
+  mergeable now (`CLEAN`, `UNSTABLE` or `HAS_HOOKS`) is squash-merged, and one in a repository that
+  allows auto-merge is armed. Every request carries READY's head as GitHub's expected head, so
+  GitHub refuses it once the head has moved. In a repository that allows neither, the row waits,
+  reading GitHub again on the outbox's backoff, until GitHub reports the pull request mergeable —
+  a required check finishing, a required review a person gives — and then merges it. An arm or a
+  queue entry is not the end: the row keeps reading GitHub until GitHub reports the pull request
+  merged at READY's head, and submits again when the arm or entry is gone while the record still
+  awaits READY (a disarm sent before READY that GitHub applied late). GitHub's
+  rules decide each answer: the daemon bypasses none, and a person may merge it first. A refusal a
+  retry would meet again (squash merges disabled, a permission the App lacks) ends the row and is
+  told to the architect once (`merge-refused`), with GitHub's message. While the record still
+  awaits READY's head, GitHub showing the pull request closed or at another head is a webhook not
+  yet applied, so the row waits for the two to agree. Only once GitHub's last change to the pull
+  request is more than 10 minutes old, however long the row waited before, does the row end and
+  tell the architect once (`merge-stalled`). A reopen at READY's head reuses the row and takes it
+  from a run that read the record before the reopen. Any other failure retries.
+  No role runs `gh pr merge`. When the answer's `note` begins `MANUAL_MERGE_REQUIRED:` (the pull
+  request touches a path the project's `merge.by_hand` names), READY stands but the daemon submits
+  nothing: the merger tells the architect the note and the head, and a person merges under the
+  repository's rules. While an earlier auto-merge disarm for that pull request remains unfinished,
+  a by-hand READY refuses `READY_DISARM_PENDING`; retry it once the disarm finishes, so a stale
+  ordinary arm cannot merge the person-only head. Ordinary READY does not wait for the disarm. The
+  daemon tells that READY with the note at its head and the packet's `Merge:` line replaced, so the
+  issue and the merge queue role are never asked to arm it. A READY the design gate refused is
+  submitted by the daemon when the approval that opens the gate moves the issue to
+  `awaiting_merge`. A push that moves the head past a READY the gate holds voids it before then:
+  the architect is told `READY_HEAD_MOVED` and has the merger build a new READY at the new head.
+  The packet's second line records the step,
+  `Merge: the daemon submits pull request #<n> at <head> once READY is accepted`.
+- **The daemon disarms a merge no READY covers.** Auto-merge stays enabled across pushes, and the
+  expected head is checked only when it is enabled, so the daemon itself disables the pull
   request's auto-merge and takes it out of a merge queue, as the implement App, on any push or
   reopen but one landing on an awaiting READY's head, when READY is withdrawn (a push or reopen
   moved the head past it, its CI turned red, or it conflicts with its base, each of which sends the
   issue back to `implementing`), when a child is set back to `todo`, and when the issue leaves the
-  workflow. A by-hand READY covers no arm, so whoever arms it is undone. READY waits
-  (`READY_DISARM_PENDING`) until that disarm has finished. No role runs a disarm.
+  workflow. A by-hand READY covers no arm, so whoever arms it is undone. A `ready_merge` row whose
+  READY the record has left, or whose pull request the record holds closed, submits nothing; a pull
+  request reopened at an awaiting READY's head gets that head's merge submitted again. No role runs
+  a disarm.
 
 ## After the merge
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sjawhar/pi-legion",
-  "version": "10.3.5",
+  "version": "10.3.6",
   "license": "Apache-2.0",
   "type": "module",
   "omp": {