@sjawhar/pi-legion 10.3.2 → 10.3.4

package/dist/legion.js

@@ -16148,7 +16148,7 @@ function onEnvoyRoleRegained(listener) {
 // package.json
 var package_default = {
   name: "@sjawhar/pi-legion",
-  version: "10.3.2",
+  version: "10.3.4",
   license: "Apache-2.0",
   type: "module",
   omp: {
@@ -16160,7 +16160,7 @@ var package_default = {
     ]
   },
   legion: {
-    daemonApiVersion: 25
+    daemonApiVersion: 27
   },
   repository: {
     type: "git",
@@ -17385,7 +17385,7 @@ function workspaceRecreatedNotice(environment, issue2) {
     return;
   return {
     id: crypto.randomUUID(),
-    content: `Your workspace was recreated since your last turn: it holds what was pushed to legion/${issue2} ` + "(main if nothing was), and anything you had not pushed is gone. Before you continue, check " + "the workspace against what you remember doing and re-read your last handoff."
+    content: `Your workspace was recreated since your last turn: it holds what was pushed to legion/${issue2} ` + "(the repository's default branch if nothing was), and anything you had not pushed is gone. " + "Before you continue, check the workspace against what you remember doing and re-read your " + "last handoff."
   };
 }
 function workspaceRecreatedMessage(notice) {

package/dist/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/dist/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/dist/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/dist/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.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sjawhar/pi-legion",
-  "version": "10.3.2",
+  "version": "10.3.4",
   "license": "Apache-2.0",
   "type": "module",
   "omp": {
@@ -12,7 +12,7 @@
     ]
   },
   "legion": {
-    "daemonApiVersion": 25
+    "daemonApiVersion": 27
   },
   "repository": {
     "type": "git",