@sjawhar/pi-legion 8.3.1 → 8.4.1

package/README.md

@@ -17,8 +17,9 @@ pi-envoy").
 
 The Legion daemon's boot gate (`packages/daemon/internal/daemon/bootgate.go`) refuses to start
 unless the Oh My Pi a pane will run loads this plugin at the daemon's contract
-(`legion.daemonApiVersion` in `package.json`, currently 14) and loads `@sjawhar/pi-envoy` with it,
-so both go into the Oh My Pi profile the daemon's panes use:
+(`legion.daemonApiVersion` in this package's `package.json`, equal to `DaemonAPIVersion` in
+`packages/daemon/internal/api/version.go`) and loads `@sjawhar/pi-envoy` with it, so both go into
+the Oh My Pi profile the daemon's panes use:
 
 ```sh
 omp plugin install @sjawhar/pi-envoy && omp plugin install @sjawhar/pi-legion

package/dist/legion.js

@@ -15193,7 +15193,7 @@ function onEnvoyRoleRegained(listener) {
 // package.json
 var package_default = {
   name: "@sjawhar/pi-legion",
-  version: "8.3.1",
+  version: "8.4.1",
   license: "Apache-2.0",
   type: "module",
   omp: {
@@ -15205,7 +15205,7 @@ var package_default = {
     ]
   },
   legion: {
-    daemonApiVersion: 15
+    daemonApiVersion: 16
   },
   repository: {
     type: "git",
@@ -15412,13 +15412,21 @@ var legionAgentSecretsLoginView = exports_external.strictObject({
   state: exports_external.string(),
   code: exports_external.string()
 });
+var legionCapabilityState = exports_external.strictObject({
+  name: nonEmptyString,
+  status: exports_external.enum(["present", "installed", "unchecked", "live", "withheld", "decided", "open"]),
+  detail: nonEmptyString,
+  decision: nonEmptyString.optional(),
+  configLine: nonEmptyString.optional()
+});
 var LegionStateResponse = exports_external.strictObject({
   daemon: daemonInfo,
   admission: legionAdmission,
   issues: exports_external.record(exports_external.string(), legionIssue),
   pendingStatusWrites: exports_external.array(legionPendingStatusWrite),
   controllerLocator: legionControllerLocator.optional(),
-  agentSecretsLogin: legionAgentSecretsLoginView.optional()
+  agentSecretsLogin: legionAgentSecretsLoginView.optional(),
+  capabilities: exports_external.array(legionCapabilityState)
 });
 var LegionRegisterResponse = exports_external.strictObject({
   claimToken: nonEmptyString,
@@ -16066,7 +16074,7 @@ function handoffSchemaFields(z2) {
     ready: z2.boolean().optional()
   };
 }
-var HANDOFF_DESCRIPTION = "Handoff actions (phase workers; the daemon accepts a completion only from the role working " + "the issue's current phase, never from an architect): handoff_write writes this phase's handoff " + "(`phase`, and `data`: the phase-specific fields as a JSON object, never the schemaVersion, " + "phase, completed and issue the command writes itself) to `.legion/<issue>/<phase>.json` in " + "the issue workspace; handoff_read returns the handoffs (every phase, or `phase`); " + "handoff_complete reports this phase complete to the daemon (`summary`: two sentences for the " + "architect, or the merger's READY packet; `verdict` pass|fail when your role's instructions " + "require one; `ready: true` for the merger's READY; no `phase` is needed, and one other than " + "your own is refused). Each " + "returns the command's output; a failed action changed nothing. What a later phase needs goes " + "in your handoff; a question for another live role goes to its role topic with envoy_publish.";
+var HANDOFF_DESCRIPTION = "Handoff actions (phase workers; the daemon accepts a completion only from the role working " + "the issue's current phase, never from an architect): handoff_write writes this phase's handoff " + "(`phase`, and `data`: the phase-specific fields as a JSON object, never the schemaVersion, " + "phase, completed and issue the command writes itself) to `.legion/<issue>/<phase>.json` in " + "the issue workspace; handoff_read returns the handoffs (every phase, or `phase`), a handoff " + "retro's removal of `.legion/<issue>/` took off the head read from the commit before it; " + "handoff_complete reports this phase complete to the daemon (`summary`: two sentences for the " + "architect, or the merger's READY packet; `verdict` pass|fail when your role's instructions " + "require one; `ready: true` for the merger's READY; no `phase` is needed, and one other than " + "your own is refused). Each " + "returns the command's output; a failed action changed nothing. What a later phase needs goes " + "in your handoff; a question for another live role goes to its role topic with envoy_publish.";
 function rootArchitectHandoffRefusal(operation) {
   return `${operation} is not available to a root architect session; a root architect reads handoffs with \`legion handoff read [--phase <phase>]\` from bash`;
 }

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

@@ -236,9 +236,10 @@ the implementer's role topic to start retro: the daemon's start is what records
 the task.
 
 Wait for the implementer to report its durable retro result. Retro output is
-`docs/solutions/`, the PR body content the repository's instructions derive from the pull
-request's changed paths at that commit, and one `dispatch_message` on the issue; it must not create
-a `.legion` file or rewrite the reviewer-approved head. When the implementer reports that it cannot
+`docs/solutions/`, its last commit removing the issue's `.legion/<issue>/` from the head a human
+merges, the PR body content the repository's instructions derive from the pull request's changed
+paths at that head, and one `dispatch_message` on the issue; it must write no handoff or
+rewrite the reviewer-approved head. When the implementer reports that it cannot
 compute that body content or do the work a line of it affirms, that its read of the body failed or
 came back empty, or that GitHub refused the body, it has pushed nothing and is still in its phase.
 Answer it with `envoy_publish` to its role topic, saying how from the deployment instructions;
@@ -256,20 +257,21 @@ The daemon keeps this order from its fixed table; you start none of its steps:
 
 1. tester green and review cycles complete;
 2. on a clean review, the reviewer approves the head by SHA, and the daemon moves the issue to
-   `retro`. No role pushes a `.legion/` deletion: the approved head still carries `.legion/`. The
-   daemon strips whatever `.legion/` main still carries from the next issue's branch before any of
-   its roles start, so that tree's own merge carries the removal onto the default branch; no
-   operator sweep follows;
-3. retro commits its learnings under `docs/solutions/` on top of the approved head; that
-   commit does not void the approval and never returns the tree to the tester or reviewer;
-4. the merger verifies the current head is the reviewer-approved head plus only commits that
-   change `docs/solutions/` (`jj diff --from <approved-sha> --to <tip-sha> --summary`, quoted in
-   READY) and sends the READY packet with its completion; the daemon posts
+   `retro`. The approved head still carries the issue's handoffs, `.legion/<issue>/`;
+3. retro commits its learnings under `docs/solutions/` on top of the approved head, then, as the
+   one final commit, the removal of `.legion/<issue>/`, so no merge carries a handoff onto the
+   default branch (dispatch://LEGION-605); those commits do not void the approval and never return
+   the tree to the tester or reviewer;
+4. the merger verifies the current head is the reviewer-approved head plus only retro's commits,
+   those that change `docs/solutions/` and that removal (`jj diff --from <approved-sha> --to
+   <tip-sha> --summary`, quoted in READY) and sends the READY packet with its completion, which
+   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. Legion never merges; a human merges under the repository's
    GitHub branch-protection and CODEOWNERS rules. 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.
+   `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.
 5. a human merges; the daemon then starts the **implementer** once more, on the production check.
    It drives the changed path in production through the user's own access path and records
    what it saw on the pull request and on this issue. Sign off only after the implementer's production
@@ -279,9 +281,10 @@ The daemon keeps this order from its fixed table; you start none of its steps:
    outcome-named options. The issue waits for that answer.
 
 What returns the tree to review: a changed diff — a commit above the approved head that
-touches anything outside `docs/solutions/`, or a conflict-resolution merge whose fingerprint
+touches anything outside `docs/solutions/` and the issue's `.legion/<issue>/`, or a
+conflict-resolution merge whose fingerprint
 (the unchanged-diff check, `skill://legion-worker/references/conflicts-and-rewrites.md`) differs from the approved head's. What does not: retro's
-`docs/solutions/` commit, and a merge forced by a GitHub-reported conflict whose fingerprint
+`docs/solutions/` commit and its removal of `.legion/<issue>/`, and a merge forced by a GitHub-reported conflict whose fingerprint
 is unchanged. For that merge, the worker holding the issue's phase moves it back to `implementing`
 with `request_backward_move`, and the daemon runs the phases from there: the implementer merges
 the bookmark forward with the

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

@@ -171,7 +171,13 @@ unsent:
 - `tick on <PROJECT>`: the daemon's periodic wake, a minute after it starts and then every
   `controller_wake_interval_seconds` (an hour by default), whatever the slots. An earlier walk
   that found nothing, a day with no event, and [a tree waiting on a root
-  claim](#trees-waiting-on-a-root-claim-go-daemon) all get a turn from it.
+  claim](#trees-waiting-on-a-root-claim-go-daemon) all get a turn from it. Its payload's
+  `openCapabilities`, when present, names the deployment capabilities (the secrets broker, model
+  fallback, every role's CPU and memory limits) the deployment's own configuration leaves open with
+  no decision recorded. `legion state --json` lists every row under `capabilities`, each open one
+  with its `detail` and the `configLine` to write into `legion.yaml`
+  (`capabilities.decided.<name>: "<reason>"`); name them in the day's report. A gap is the
+  operator's to close or to decide, never yours, and it never stops the walk.
 
 **Scope first.** The scope the deployment instructions state decides which issues are candidates
 at all, before anything below. When they say you hand Legion no issue yourself, or that Legion
@@ -291,6 +297,10 @@ every pull request by its URL.
 - **The slots and the walk.** The free slots, as **How many** counts them, then this turn's walk
   when it made one: what it took, and how many candidates each row of the table skipped, so a
   reader can see why a free slot stays empty.
+- **Open capabilities.** Each row of `capabilities` in `legion state --json` whose `status` is
+  `open` (the `tick` payload's `openCapabilities`): its name, its `detail`, and its `configLine`,
+  the `legion.yaml` line that records a decision. The operator closes or decides it; you only
+  report it, and a report with none says nothing of them.
 
 A day with nothing finished says so in one sentence. When the lists do not fit, keep the counts
 and the highest-priority issues.
@@ -328,7 +338,7 @@ priority first, then board rank ([Keeping the slots full](#keeping-the-slots-ful
 | New issue created in the Dispatch project, status `triage`: `triage on <KEY>` (payload `{kind: "triage"}`) on the controller topic, for an unrecorded root carrying the `legion` label only ("Issues handed to Legion" above); the start procedure above catches one sent while no controller ran | issue key + triage context (incl. pre-existing children) | Triage: `legion status <KEY> todo` to admit, or set `backlog`/`icebox` to park |
 | `slot-free on <KEY>` from the Go daemon (payload `{kind: "slot-free"}`) | the root whose slot the daemon released with no waiting root to take it | Verify a free slot in `legion state --json`, then fill it ([Keeping the slots full](#keeping-the-slots-full-go-daemon)) |
 | `todo on <KEY>` from the Go daemon (payload `{kind: "todo"}`) | an issue not handed to Legion that changed while in `todo` and a slot stood free, sent half a minute later | Verify a free slot, then walk the whole `todo` list ([Keeping the slots full](#keeping-the-slots-full-go-daemon)) |
-| `tick on <PROJECT>` from the Go daemon (payload `{kind: "tick"}`) | the project key; the daemon's periodic wake, whatever the slots | Recheck the trees waiting on a claim, then walk if a slot is free; post the day's report if this is the day's first turn |
+| `tick on <PROJECT>` from the Go daemon (payload `{kind: "tick", openCapabilities?: [<name>, …]}`) | the project key; the daemon's periodic wake, whatever the slots; `openCapabilities` names the deployment capabilities with no decision, each with its detail and `capabilities.decided.<name>` line under `capabilities` in `legion state --json` | Recheck the trees waiting on a claim, then walk if a slot is free — a gap never stops the walk; post the day's report if this is the day's first turn, naming each open capability in it (the operator closes or decides it) |
 | Architect escalation (controller-actionable only: re-file a child as a root issue, capacity, cross-tree conflicts) | request + context | Judge and act; the owning architect writes an issue-design decision as a decision block and opens `dispatch_ask` only for a human to-do |
 | Mention | Slack/GitHub PR @mention text | Answer, or route to the owning issue's architect role |
 | `held on <KEY>` from the Go daemon (payload `{kind: "held", phase, role?, reason?}`) | the held issue, the phase it left, and the role whose claim failed, or `reason: "escalated"` | Verify the hold in `legion state` (the issue's phase is `held`). Without `reason`, a phase worker's launches or prompts ran out and the tree's architect decides retry or escalate: no action. With `reason: "escalated"` (on the record, `issues.<KEY>.holdReason` is `escalated`), the architect sent it to you: handle it as an architect escalation below. Parking the tree is `legion status <root> backlog`; setting the root back to `todo` later re-admits it as a new generation, which starts again from its architect |

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

@@ -19,20 +19,19 @@ Follow this ordering exactly. It keeps the reviewed branch clean while preservin
 retrospective's durable output.
 
 1. Tester green and all code-review cycles finish.
-2. The reviewer approves the head. It still carries `.legion/`: no role removes it before the
-   merge. The daemon strips whatever `.legion/` main still carries from the next issue's branch
-   before any of its roles start, so that tree's own merge carries the removal onto the default
-   branch; no operator sweep follows.
-3. Run this retro: commit durable learnings to `docs/solutions/`, bring the pull request body's
-   path-derived content up to date for that commit before you push it, and post the retro
-   message on the Dispatch issue.
-   Retro writes **no `.legion` file**, so it never changes the approved head's handoffs.
-4. The merger verifies the tip is the approved head plus commits that change only
-   `docs/solutions/` — `jj diff --from <approved-sha> --to <tip-sha> --summary`, quoted in READY —
-   and sends the READY packet with its completion; the daemon posts it on the Dispatch issue and
-   publishes it to the project's merge-queue role when one is configured. A human merges under the
-   repository's GitHub branch-protection and CODEOWNERS requirements; GitHub's merge queue
-   participates only when the repository enables it.
+2. The reviewer approves the head. It still carries the issue's handoffs, `.legion/<issue>/`
+   (`<issue>` is your `LEGION_ISSUE`), which every tester and reviewer round writes again.
+3. Run this retro (*Durable outputs*, below): its learnings under `docs/solutions/`, then one final
+   commit removing `.legion/<issue>/`, pushed together, and the retro message on the Dispatch
+   issue. Retro writes **no handoff**. The removal exists because a squash merge commits the head
+   merged into the base, and nothing on the base reads a handoff; the handoffs stay on the issue
+   branch below that commit.
+4. The merger verifies the tip is the approved head plus retro's commits, quotes their
+   `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. A human merges under the repository's GitHub branch-protection and CODEOWNERS
+   requirements; GitHub's merge queue participates only when the repository enables it.
 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
    in production. The architect's sign-off waits for that record.
@@ -41,10 +40,12 @@ retrospective's durable output.
    merge commit. A defect the production check finds becomes a corrective child issue of the same tree,
    owned by the architect and implemented by the same implementer; the parent stays open until it lands.
 
-Retro's commit sits above the reviewer's approved head and the approval stands: a commit that
-changes only `docs/solutions/` does not void it, and the tree goes from retro to the merger —
-never back to the tester or reviewer. A conflict-forced rebase after retro moves these documents
-with the branch; retro does not re-run.
+Retro's commits sit above the reviewer's approved head and the approval stands: commits that
+change only `docs/solutions/`, and the one that removes `.legion/<issue>/`, do not void it, and the
+tree goes from retro to the merger — never back to the tester or reviewer. A conflict-forced
+rebase after retro moves these commits with the branch. Any round after retro (a conflict round, a
+round a red CI sends back, a re-review) writes `.legion/<issue>/` again, and every approval moves
+the issue to retro once more: each retro ends with the removal again, or READY is refused.
 
 Do not start retro before step 2 or skip it because the change seems mechanical; the merger's
 `READY` comes only after step 3. The design gate is not a substitute for review and retro.
@@ -106,24 +107,30 @@ related_issues:
 ```
 
 Commit the documentation on the existing issue branch. Do not create a replacement branch or
-bookmark.
-
-Before you push that commit, bring up to date the body content the repository derives from the
+bookmark. Then commit the removal of the issue's handoffs as the one final commit, touching
+nothing else, when the head still holds them:
+`cd -- "$LEGION_WORKSPACE" && if [ -e ".legion/${LEGION_ISSUE:?}" ]; then rm -r -- ".legion/${LEGION_ISSUE:?}" && jj -R "$LEGION_WORKSPACE" split -m "retro: remove .legion/${LEGION_ISSUE:?}/ before READY" ".legion/${LEGION_ISSUE:?}"; fi`.
+A retro that commits no learning makes that commit alone; a retro after an earlier removal with no
+handoff written since has nothing to remove and makes none (without the guard, `rm -r` would fail
+on the missing directory and that retro would stop there).
+
+Before you push those commits, bring up to date the body content the repository derives from the
 pull request's changed paths. A repository can require such content, a line naming a checklist
 for each class of changed path for instance, and have a required check read it from the PR body.
-When your commit adds a `docs/solutions/` path the approved body never accounted for, that check
-fails at your head; the merger reports a stale body rather than rewriting it, and READY refuses a
-head whose required check failed, so the tree stops at the merger.
+When your commits add a `docs/solutions/` path the approved body never accounted for, or take away
+the `.legion/` paths it did, that check fails at your head; the merger reports a stale body rather
+than rewriting it, and READY refuses a head whose required check failed, so the tree stops at the
+merger.
 
 1. Read what the deployment instructions in your system prompt, and the agent guide and pull
    request template of the repository you are working in, derive from the changed paths. When
    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 commit, the files
+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 | <commit>)' --to <commit> --name-only`
-   lists them, `<base>` the pull request's base branch and `<commit>` your docs commit. Where a
+   `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
    line affirms work, such as a checklist completed for a class of path, do that work for the
-   paths your commit adds before you write the line: the line is a claim. That work may change
+   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
    anything else above the approved head voids the approval.
 3. In a fresh `mktemp -d` directory outside `$LEGION_WORKSPACE` (the one place you write outside
@@ -139,16 +146,17 @@ head whose required check failed, so the tree stops at the merger.
    `cd -- "$LEGION_WORKSPACE" && legion gh -- api --method PATCH repos/{owner}/{repo}/pulls/{number} -F body=@<dir>/body.md`.
    The checks the push starts read the body as it stands then; an edit after the push re-runs
    only a check that also starts on an edited body. Such a check re-runs now at the approved
-   head, on a diff without your commit, and may fail there; READY reads the head your push makes.
+   head, on a diff without your commits, and may fail there; READY reads the head your push makes.
 
 When you cannot compute that content, cannot do the work a line affirms within
 `docs/solutions/`, the body read fails or comes back empty, or GitHub refuses the body, push
 nothing and do not complete: tell the architect with `envoy_publish` to its role topic, naming
 what failed.
 
-Then push the commit with `legion push`. When the push is refused after step 4 wrote the body,
-write `<dir>/before.md` back the same way before you report the refusal to the architect, so the
-body matches the head GitHub has. After the push, post one Dispatch message on
+Then push both commits with one `legion push`, so one CI run covers them. When the push is
+refused after step 4 wrote the body, write `<dir>/before.md` back the same way before you report
+the refusal to the architect, 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
 issue, and the `gh` shim refuses every GitHub-issue write — naming the documents, the
 one-to-three most useful takeaways, the two proofs you read, and the production check that
@@ -174,23 +182,27 @@ dispatch_message({
 })
 ```
 
-The `docs/solutions/` commit, the PR body lines that commit makes stale, and the Dispatch message
-are the only retro outputs. Never write a handoff, phase artifact, local feedback log, or
-completion label, and add or change nothing under `.legion/`. Report completion with the `legion`
-tool's `handoff_complete` alone (its summary: two sentences for the architect) — no
-`handoff_write`.
+The `docs/solutions/` commit, the removal of `.legion/<issue>/`, the PR body lines those commits
+make stale, and the Dispatch message are the only retro outputs. Never write a handoff, phase
+artifact, local feedback log, or completion label, and change nothing under `.legion/` but that
+removal. Report completion with the `legion` tool's `handoff_complete` alone (its summary: two
+sentences for the architect) — no `handoff_write`.
 
 ## Completion check
 
 Before returning, verify all of the following:
 
-- The reviewer-approved head remains below the retro documentation commit, and the reviewer's
-  approval of that head stands: the merger accepts the approved head plus this commit.
+- The reviewer-approved head remains below the retro commits, and the reviewer's approval of that
+  head stands: the merger accepts the approved head plus the documentation commit and the removal.
 - The learning documents and the Dispatch message both exist (never a GitHub issue comment).
 - The PR body carries what the repository's instructions derive from the pull request's changed
   paths at the retro head, written back before that head's push, and each line that affirms work
   affirms work you did; or the instructions derive nothing.
 - Both proofs were read, and any gap in either is recorded as a learning.
-- No `.legion` file was created or modified by retro.
+- Retro wrote no handoff, and when the head held `.legion/<issue>/`, its last commit, pushed,
+  removed it and nothing else:
+  `cd -- "$LEGION_WORKSPACE" && jj -R "$LEGION_WORKSPACE" file list -r <head> "root:.legion/${LEGION_ISSUE:?}"`
+  prints nothing (`root:` names the path from the repository root, so a run from another directory
+  cannot print nothing by failing).
 - The fresh-eyes analysis was considered alongside the implementer's context.
 - The merger remains a subsequent step, not work performed by retro.

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

@@ -121,8 +121,7 @@ moves the issue to `implementing` and interrupts your turn, and the implementer
 that turn has ended. Do not resume the interrupted work afterward.
 
 On every start, and especially after revival or re-creation, read the issue and then the
-committed predecessor handoffs in lifecycle order from
-`$LEGION_WORKSPACE/.legion/<issue>/`:
+committed predecessor handoffs in lifecycle order, with the `legion` tool's `handoff_read`:
 
 1. `architect.json`
 2. `plan.json`
@@ -132,8 +131,8 @@ committed predecessor handoffs in lifecycle order from
 
 Read only files that precede the assigned phase. Each was held to its phase's rules when it was
 written (`handoff_write`, in the completion gate below): fields the phase does not declare passed
-untouched and reach the next worker. The `legion` tool's `handoff_read` returns each file as it
-stands in the workspace.
+untouched and reach the next worker. The `legion` tool's `handoff_read` returns them; its
+description says where it reads each one from.
 Write the phase-specific fields the next phase and the architect need, consistent with what
 predecessor phases already wrote. The durable copy lives in
 `$LEGION_WORKSPACE/.legion/<issue>/<phase>.json`. If a committed handoff conflicts with memory or a prior
@@ -414,12 +413,12 @@ report to the architect with the output, never a force-push. The merger makes no
 pushes nothing.
 
 Do not report phase completion until the write, existence check, handoff commit, and push
-succeed. This is the committed copy the next phase reads after revival. No phase removes
-`.legion/`: the reviewer approves a head that carries it. The daemon strips any `.legion/` still on
-main from the next issue's branch before any of its roles start (dispatch://LEGION-565), so that
-tree's own merge carries the removal onto the default branch; no operator sweep follows. Retro and
-the post-merge production check write no `.legion/<issue>/<phase>.json`, commit no handoff, and
-report with `handoff_complete` alone (below).
+succeed. This is the committed copy the next phase reads after revival. Retro's last commit
+removes `.legion/<issue>/` from the head a human merges (`skill://legion-retro`); a round after
+it, such as one a withdrawn READY sends back, writes and commits its own handoff again, since
+`handoff_complete` refuses a handoff that commit removed. Retro and the post-merge production
+check write no `.legion/<issue>/<phase>.json`, commit no handoff, and report with
+`handoff_complete` alone (below).
 
 ## Completion: report to the architect, then stay
 

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

@@ -5,15 +5,15 @@ approval, the implementer recording the production check, or the merger building
 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 human merge → the implementer's production check. No role
-removes `.legion/` before the merge: the approved head carries it. The daemon strips whatever
-`.legion/` main still carries from the next issue's branch before any of its roles start
-(dispatch://LEGION-565), so that tree's own merge carries the removal onto the default branch; no
-operator sweep follows. After the approval, only retro's `docs/solutions/` commit leaves it
-standing on its own (*Retro*, below). A conflict-forced merge goes back to the reviewer for a
-confirmation or a new round, as the fingerprint decides (*The reviewer*, below, and
-`skill://legion-worker/references/conflicts-and-rewrites.md`), and any other change to the head
-voids it.
+retro → the merger's READY → the human merge → the implementer's production check. The approved
+head carries the issue's handoffs, `.legion/<issue>/`; retro's last commit removes them from the
+head a human merges (dispatch://LEGION-605), since a squash merge commits that head merged into
+the default branch and nothing there reads a handoff, and READY refuses a head that still
+carries them. After the approval, only retro's commits leave it standing on their own: those that
+change only `docs/solutions/`, and that removal (*Retro*, below). A conflict-forced merge goes back
+to the reviewer for a confirmation or a new round, as the fingerprint decides (*The reviewer*,
+below, and `skill://legion-worker/references/conflicts-and-rewrites.md`), and any other change to
+the head voids it.
 
 ## The reviewer
 
@@ -63,15 +63,16 @@ review posted without a completion leaves the issue in reviewing until you finis
 
 ## Retro
 
-- **Retro's commit does not void the reviewer's approval.** After the reviewer approves the
-  head, retro commits its learnings under `docs/solutions/` on top of it; that commit
-  stays, the approval stands, and the tree goes to the merger — never back to the tester or
-  reviewer. Anything else above the approved head does void it, and the merger tells the
-  architect the head must return to review instead of completing. A conflict-forced rebase
-  after retro moves those documents with the branch; retro never re-runs.
+- **Retro's commits do not void the reviewer's approval.** Retro's commits above the approved
+  head, its `docs/solutions/` learnings and its last commit removing `.legion/<issue>/`
+  (`skill://legion-retro` gives the steps), leave the approval standing, and the tree goes to the
+  merger — never back to the tester or reviewer. Anything else above the approved head does void
+  it, and the merger tells the architect the head must return to review instead of completing. A
+  conflict-forced rebase after retro moves those commits with the branch. Every approval moves the
+  issue to retro again, so each retro ends with the removal again.
 - **Retro brings the PR body's path-derived content up to date before its push.** Whatever the
   repository's instructions derive from the pull request's changed paths (a checklist named for
-  each class of path, read by a required check), retro recomputes for the whole diff at its commit
+  each class of path, read by a required check), retro recomputes for the whole diff at its head
   and writes into the live body before `legion push` (`skill://legion-retro`), since the merger
   reports a stale body rather than rewriting it. A body edit changes no commit, so the approval
   stands.
@@ -84,8 +85,11 @@ review posted without a completion leaves the issue in reviewing until you finis
   exits 1 (report the thread to the architect instead), then proves that rule with two commands.
   First `cd -- "$LEGION_WORKSPACE" && jj -R "$LEGION_WORKSPACE" git fetch && jj -R
   "$LEGION_WORKSPACE" diff --from <approved-sha> --to <tip-sha> --summary`, whose output is quoted
-  in READY (an empty output is quoted as `no file changes above the approved head`); then the same
-  with `'~docs/solutions'` appended, which must print nothing. *The READY packet* is
+  in READY; then the same with the one fileset `'~(docs/solutions | .legion/<issue>)'` appended,
+  which must print nothing (jj unions separate path arguments, so two of them leave nothing out).
+  READY itself refuses a head that still carries `.legion/<issue>/` (the merger tells the
+  architect, which has it move the issue back to `retro`), and publishes a pull request a person
+  already merged unread (`packages/daemon/internal/prompts/go/merger.md`). *The READY packet* is
   `READY #<n> at <current sha> (approved at <approved sha>) for <KEY> (<pr url>)`
   (the shape `packages/daemon/internal/prompts/roles/merger.md` defines), then the PR body's
   `Outcome:` line and its `Not proven / risk:` value — every bullet under that label joined with

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sjawhar/pi-legion",
-  "version": "8.3.1",
+  "version": "8.4.1",
   "license": "Apache-2.0",
   "type": "module",
   "omp": {
@@ -12,7 +12,7 @@
     ]
   },
   "legion": {
-    "daemonApiVersion": 15
+    "daemonApiVersion": 16
   },
   "repository": {
     "type": "git",