@sjawhar/pi-legion 10.19.9 → 10.19.10

package/dist/legion.js

@@ -16932,7 +16932,7 @@ async function bootLegionClaim(host2) {
 // package.json
 var package_default = {
   name: "@sjawhar/pi-legion",
-  version: "10.19.9",
+  version: "10.19.10",
   license: "Apache-2.0",
   type: "module",
   omp: {

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

@@ -170,14 +170,30 @@ what failed.
 
 Then push both commits with one push, so one CI run covers them (`<KEY>` is your `LEGION_ISSUE`):
 `cd -- "$LEGION_WORKSPACE" && jj -R "$LEGION_WORKSPACE" bookmark set legion/<KEY> -r @- && jj -R "$LEGION_WORKSPACE" git push --bookmark legion/<KEY>`.
-It carries `docs/solutions/` and the removal of `.legion/<KEY>/`, so it is not a handoff-only
-push: its head's message never ends with `skip-checks: true` and carries none of GitHub's
-`[skip ci]`-family keywords (`skill://legion-worker`, *Every role pushes its own commits*). When
-the push is refused after step 4 wrote the body (`jj git push` refuses a branch another role
+Its head's message never ends with `skip-checks: true` and carries none of GitHub's
+`[skip ci]`-family keywords (`skill://legion-worker`, *Every role pushes its own commits*).
+Retro's push never carries the line, whatever paths it touches, because it is the last push before the merge and a base that requires a check will not merge a head whose checks never ran.
+When the push is refused after step 4 wrote the body (`jj git push` refuses a branch another role
 moved; never force), write `<dir>/before.md` back the same way before you report the refusal to
-the architect with its output, so the body matches the head GitHub has. After the push, post one
-Dispatch message on
-the issue — `--issue` is your `LEGION_ISSUE`; Legion issues live on Dispatch, never on a GitHub
+the architect with its output, so the body matches the head GitHub has.
+
+When you have already pushed a head that wrongly carries the line — under an older copy of these
+instructions, say — read that pushed head's own commit message first and confirm it ends with
+`skip-checks: true`:
+`cd -- "$LEGION_WORKSPACE" && jj -R "$LEGION_WORKSPACE" log -r <the pushed head> --no-graph -T description`.
+The fix is to describe that same commit again without the line and push it once, which is the
+rewrite of an already-pushed commit:
+`skill://legion-worker/references/conflicts-and-rewrites.md#rewriting-pushed-commits`. Run that
+section's guard first; a non-empty guard result means another tree's work is built on the commit,
+so do not rewrite it — report the listed commits to the architect instead. Once the guard has
+cleared, the bookmark moves backwards with `--allow-backwards` and the branch is pushed once:
+that is the one non-fast-forward move the rewrite section sanctions, and not the force this
+skill's push step forbids when `jj git push` refuses a branch another role moved. The rewritten
+head is a code head, so GitHub runs the base branch's required checks on it from scratch, and the
+merge waits for them.
+
+After the push, post one Dispatch message on the issue — `--issue` is your `LEGION_ISSUE`; Legion
+issues live on Dispatch, never on a GitHub
 issue, so no `gh issue` write and no GitHub-issue comment — naming the documents, the
 one-to-three most useful takeaways, the two proofs you read, and the production check that
 follows the merge's close of the issue. The message must carry this revived implementer's structured

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

@@ -386,27 +386,27 @@ cd -- "$LEGION_WORKSPACE" && jj -R "$LEGION_WORKSPACE" bookmark set legion/<KEY>
 
 A push whose commits touch only `.legion/` (a handoff-only push) ends its head's commit message
 with `skip-checks: true` as the last line, preceded by two empty lines, so GitHub starts no
-workflow run for it and the daemon carries the code head's verdict to it. GitHub honours the
-trailer only in that shape — the last line, after two empty lines; one empty line is not enough,
-and GitHub then starts every workflow as if the line were not there (a planner's handoff push
-did exactly that in the first live run of this rule). jj keeps the two lines as written, where
-`git commit`'s default cleanup would collapse them. Write the line with trailers off for the one
-describe, since the pane's jj overlay would otherwise append `Omp-Session:` after it:
+workflow run for it and the daemon carries the code head's verdict to it.
+Retro's push never carries the line, whatever paths it touches, because it is the last push before the merge and a base that requires a check will not merge a head whose checks never ran.
+GitHub honours the trailer only in that shape — the last line, after two empty lines; one empty line
+is not enough, and GitHub then starts every workflow as if the line were not there (a planner's
+handoff push did exactly that in the first live run of this rule). jj keeps the two lines as
+written, where `git commit`'s default cleanup would collapse them. Write the line with trailers off
+for the one describe, since the pane's jj overlay would otherwise append `Omp-Session:` after it:
 
 ```bash
 jj -R "$LEGION_WORKSPACE" describe -r @- --config 'templates.commit_trailers=""' -m "$(jj -R "$LEGION_WORKSPACE" log -r @- --no-graph -T description)"$'\n\n\nskip-checks: true'
 ```
 
-Every other push — code, red tests, `docs/solutions/`, retro's removal of `.legion/<KEY>/`, a
-forward merge, a rewrite — carries no such line and none of GitHub's bracket keywords
-(`[skip ci]`, `[ci skip]`, `[no ci]`, `[skip actions]`, `[actions skip]`), which start no workflow
-wherever they stand. The daemon classifies a push by the paths its commits touch, never by the
-trailer: a wrong trailer stalls the issue (a trailered code push gets no verdict carried; a head
-with no CI is refused at READY) and never passes it. While the head commit carries
-`skip-checks: true`, a pull-request body edit alone starts no GitHub workflow run, so a check that
-re-judges the body re-runs on that head only after a later push; on a code head the same edit
-re-runs it at once. While the pull request conflicts with its base (GitHub shows it
-`CONFLICTING`), no workflow triggered `on: pull_request` runs for any of its activity types, so
+Every other push — code, red tests, `docs/solutions/`, a forward merge, a rewrite — carries no such
+line and none of GitHub's bracket keywords (`[skip ci]`, `[ci skip]`, `[no ci]`, `[skip actions]`,
+`[actions skip]`), which start no workflow wherever they stand. The daemon classifies a push by the
+paths its commits touch, never by the trailer: a wrong trailer stalls the issue (a trailered code
+push gets no verdict carried; a head with no CI is refused at READY) and never passes it. While the
+head commit carries `skip-checks: true`, a pull-request body edit alone starts no GitHub workflow
+run, so a check that re-judges the body re-runs on that head only after a later push; on a code
+head the same edit re-runs it at once. While the pull request conflicts with its base (GitHub shows
+it `CONFLICTING`), no workflow triggered `on: pull_request` runs for any of its activity types, so
 a body edit re-judges nothing there either; a push cures both, but only once the pull request is
 mergeable, so the implementer forward-merges a conflicting one first (*Reintegrating the base* in
 `skill://legion-worker/references/conflicts-and-rewrites.md`).

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

@@ -23,9 +23,10 @@ it, and any other change to the head voids it.
   `task(agent="thermonuclear-code-quality")` once at that head — the head the round reviews —
   and records the verdict. The `CI` fact is the checks that stand for the code under review:
   those GitHub ran for the newest push of the branch that started `pull_request` workflows, when
-  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
+  every commit above that push's head changes only `.legion/` (GitHub starts no workflow run for a
+  head whose commit message carries `skip-checks: true`, which every handoff-only push before
+  retro does; retro's push carries no such line, so its head does get GitHub's workflow runs of
+  its own). With `<o>/<r>`, `<n>`, `<base>`, `<headRefName>` and `<headRefOid>` from
   `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 `#`

package/package.json

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