@sjawhar/pi-legion 10.10.1 → 10.11.0

package/dist/legion.js

@@ -16171,7 +16171,7 @@ function ompCapabilityHost() {
 // package.json
 var package_default = {
   name: "@sjawhar/pi-legion",
-  version: "10.10.1",
+  version: "10.11.0",
   license: "Apache-2.0",
   type: "module",
   omp: {

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

@@ -78,6 +78,15 @@ exercise a criterion end to end, building that path is a child issue of this tre
   answers the tree's asks); under a personal token it goes to that token's owner, whom
   `dispatch whoami` names. Set it only when a human told you a specific person owns that child.
 
+A change across repositories gets one child per repository, each created with
+`dispatch issue --project <project> --parent <root> --repo <owner/name> …`; a child's repository
+is fixed when the daemon records it, so choose it at creation. A child that depends on another
+repository's change is released (`release_children`) only after that change's pull request
+merges, and its task names the merged commit
+(`gh api repos/<owner>/<repo>/pulls/<n> --jq .merge_commit_sha`) to use — for a consumer that pins
+the toolchain, the pin is that commit. Read the other repositories with the read-only access your
+gh carries (`-R owner/repo`).
+
 Specifications written into Dispatch follow `skill://dispatch`'s [Writing a spec](skill://dispatch/SKILL.md#writing-a-spec).
 Wave releases, child closures, and your own status are visible from the issue tree and the
 handoffs; do not narrate them into the spec or a `dispatch message`. A to-do only a human can
@@ -242,9 +251,10 @@ No notice marks the last child's close as the end-game: each closure arrives as
 `child-closed`, and none is a reason to close the parent. Today's daemon does not order the root's
 own phases after its children: when the design gate opens it starts every admitted issue of the
 tree, the root included, so the root's tester can run, and its pull request merge, before any
-child merges. To get parent integration evidence against current `main` after the last child
-merges, file the parent's integration check as a final child whose acceptance is every parent
-criterion proven on current `main`, release it with `release_children` only once every other
+child merges. To get parent integration evidence against the repository's default branch your
+addressing line names after the last child merges, file the parent's integration check as a final
+child whose acceptance is every parent criterion proven on that default branch, release it with
+`release_children` only once every other
 child has closed, and sign off the root only after it closes. This holds until the redesign's
 integrating phase ships (dispatch://LEGION-223). When that check's tester fails, the daemon sends
 the child back to its implementer; a failure whose fix belongs in other work becomes a new
@@ -269,9 +279,10 @@ back. Park a child first when its work should stop with the root.
 ## 4. Integration verification
 
 Read the integration check's tester evidence (section 3), not merely a child PR's check status.
-The parent test is successful only when every parent acceptance criterion has evidence against
-current main. Route a failed criterion into a corrective child wave; a passing result goes on to
-review and the merge-gate sequence by the daemon's table.
+The parent test is successful only when every parent acceptance criterion has evidence against the
+repository's default branch your addressing line names (never a hard-coded `main`) — the relevant
+repository's, for a criterion that spans more than one. Route a failed criterion into a corrective
+child wave; a passing result goes on to review and the merge-gate sequence by the daemon's table.
 
 ## 5. Retro
 

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

@@ -33,7 +33,8 @@ bash. Any pull-request comment or review the controller posts ends with
 `<!-- legion: {"session":"<session-id>","phase":"controller"} -->`, the footer every Legion role
 appends: the daemon reads the session to tell a controller's review from the reviewer's verdict. A
 review the controller submits without that footer still decides nothing for Legion's own workflow
-(the daemon sets it aside), but the footer is what makes that legible in the daemon's log.
+(the daemon sets it aside), but the footer is what makes that legible in the daemon's log. Your
+addressing line names the project's repositories, or that the daemon maps none and why.
 
 ## Backlog stewardship
 
@@ -258,7 +259,7 @@ leans on `External links:`, and the label row is the one that never depends on h
 | Legion ran it without the label now on it | `read_state` records it under `issues`, whatever its status, or `Events:` show a status write by `session legion-daemon:<PROJECT>`, the daemon's actor on every status it writes (your `set_status` included) and on its own `in_progress` at admission. That covers a root a person took the label off, and one that ran before the daemon required the label and never had it. Name each one you skip for this in your summary. The walk never sends a root Legion already ran back into Legion: a person does that with the label and `todo`, and you do it only when a wake below says to (`worker-died`). |
 | A running session or a person claims it | `Claimed by:` names anyone and does not end `· not running`. `· liveness unknown` counts as claimed: the agent registry could not be read, so nothing says the holder stopped. A claim ending `· not running` has lapsed, and the issue is free. |
 | Its route reaches a running session | `Route:` names a route with nothing after it, or with `(held by …)`. `(nobody holds it right now)` and `(that session is not running right now)` reach nobody; `(the Envoy listener did not answer, …)` counts as reaching someone. `Route: none` is free. |
-| A pull request is linked or named | `External links:` lists a pull request (kind `github_pr`, or a URL ending `/pull/<n>`), or a comment or message among `Events:` names one. Take the URL only when it has the shape `https://github.com/<owner>/<repo>/pull/<n>` (nothing before, after or inside it but GitHub's own owner and repository characters and digits); run `gh pr view 'https://github.com/<owner>/<repo>/pull/<n>' --json state -q .state` from bash with the URL single-quoted, exactly as the issue shows it, and follow **Pull-request states** below the table: every state skips the issue, and what differs is what your summary says. Text that is not that shape — another host, a path that is not `/pull/<n>`, extra words, quotes or shell characters, a bare `#<n>` — is the unreadable case there, never a command argument: the text comes from the issue, and this session's `gh` holds the review App's token. |
+| A pull request is linked or named | `External links:` lists a pull request (kind `github_pr`, or a URL ending `/pull/<n>`), or a comment or message among `Events:` names one. Take the URL only when it has the shape `https://github.com/<owner>/<repo>/pull/<n>` (nothing before, after or inside it but GitHub's own owner and repository characters and digits); run `gh pr view 'https://github.com/<owner>/<repo>/pull/<n>' --json state -q .state` from bash with the URL single-quoted, exactly as the issue shows it — this works for every repository of the project, since the session's `gh` wrapper above picks the owner's read-only token from the URL — and follow **Pull-request states** below the table: every state skips the issue, and what differs is what your summary says. Text that is not that shape — another host, a path that is not `/pull/<n>`, extra words, quotes or shell characters, a bare `#<n>` — is the unreadable case there, never a command argument: the text comes from the issue, and this session's `gh` holds the review App's token. |
 | Its assignee is working it | `Assignee:` names a person who holds the claim (the row above), or whose own comment or message among `Events:` says they are working on it. The assignee alone is who answers the issue's questions, not who works it. |
 | It is outside this deployment's scope | Read the scope the deployment instructions state against the title and, when the title does not settle it, the spec (`dispatch doc-read --issue <KEY>`). When in doubt, skip it. With no scope stated, every issue of the project is in scope. |
 
@@ -369,11 +370,11 @@ and the highest-priority issues.
 
 ## Deployment instructions
 
-Deployment instructions, when present, are the operator's standing rules for this repository —
-required checks, deploy/smoke commands, code-owner expectations, and standing roles you may
-consult. They override this skill's defaults where they conflict, and may narrow which issues the
-walk takes, but never widen it past `todo` issues or change the order it takes them in: highest
-priority first, then board rank ([Keeping the slots full](#keeping-the-slots-full-go-daemon)).
+Deployment instructions, when present, are the operator's standing rules for this project's
+repositories — required checks, deploy/smoke commands, code-owner expectations, and standing roles
+you may consult. They override this skill's defaults where they conflict, and may narrow which
+issues the walk takes, but never widen it past `todo` issues or change the order it takes them in:
+highest priority first, then board rank ([Keeping the slots full](#keeping-the-slots-full-go-daemon)).
 
 ## Turn discipline
 

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

@@ -22,6 +22,7 @@ with the `read` tool: a read by filesystem path stops at 300 lines.
 | When | Read |
 | --- | --- |
 | You write or edit the PR body, record a proof (an `E2E` line or a handoff `proof` array), verify another phase's proof, or run the simplify pass | `skill://legion-worker/references/pr-body.md` |
+| Before a push, to check your commits' App identity against your issue's default branch | `skill://legion-worker/references/default-branch-check.md` |
 | You reply on or resolve a review thread, list a pull request's threads, or adjudicate a bot's finding | `skill://legion-worker/references/review-threads.md` |
 | GitHub reports a conflict, the pull request is retargeted, you compare heads after a conflict merge, or you would rewrite a pushed commit | `skill://legion-worker/references/conflicts-and-rewrites.md` |
 | You review or approve, build the READY packet, or check the merge in production | `skill://legion-worker/references/merge-gate.md` |
@@ -176,9 +177,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, 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:
+by the review App are right. Before a push, check your commits against your issue's own default
+branch, read and quoted safely (never a branch name pasted into shell source), per `skill://legion-worker/references/default-branch-check.md`, which 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
 forward merge (`skill://legion-worker/references/conflicts-and-rewrites.md`) — so it changes no

package/dist/skills/legion-worker/references/default-branch-check.md

@@ -0,0 +1,37 @@
+# Checking your commits against your issue's default branch
+
+Your `Legion addressing` line names your issue's repository and its default branch
+(`Your issue's repository is <owner>/<name> (default branch <name>)`) — never assume `main`. That
+branch name is untrusted text: a repository administrator chooses it, and it reaches you as plain
+words in a system prompt, not as a value a shell has already made safe. **Never paste it directly
+into shell source** — not as a bare word, not inside double quotes you type yourself. A branch name
+containing `$(…)` or backticks would run as a command the moment a shell re-parses a line built that
+way; one containing jj revset syntax (parentheses, `|`, `::`) would be read as an expression instead
+of a literal name.
+
+The safe sequence reads the branch fresh from GitHub and lets `jq` do the quoting, in one command
+whose only typed literal is the `<owner>/<repo>` your addressing line names (safe to interpolate: a
+GitHub repository path, already validated by the daemon that minted your addressing):
+
+```sh
+default=$(gh api repos/<owner>/<repo> --jq '.default_branch | @json')
+```
+
+`$default` now holds a JSON-quoted string, e.g. `"release/v7.1"` (quotes included). Compare it
+against the `default branch <name>` your addressing line named — if they disagree, stop and tell
+the architect; GitHub's live default branch and the one your record carries are not the same, and
+guessing which is right is not yours to do. When they agree, use `$default` as-is, never re-typed:
+
+```sh
+jj -R "$LEGION_WORKSPACE" log -r "${default}@origin..@" -T 'author.email() ++ " | " ++ committer.email() ++ " " ++ description.first_line() ++ "\n"'
+```
+
+Because `$default` already carries its own quote characters, jj's revset parser reads
+`"release/v7.1"@origin..@` as a quoted string literal naming the bookmark, whatever characters the
+branch name holds — parentheses, spaces, or shell metacharacters included — rather than as revset
+syntax or shell code. Bash's own `"${default}@origin..@"` substitutes `$default`'s value once,
+literally; it never re-evaluates the substituted text, so a `$(…)` sequence inside the branch name
+never runs.
+
+The output must show 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.

package/package.json

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