@sjawhar/pi-legion 10.15.0 → 10.16.1

package/dist/legion.js

@@ -14122,6 +14122,16 @@ var DEFAULT_ISSUE_PAGE_LIMIT = 50;
 var ASK_TURNS = ["human", "agent"];
 var DELIVERY_CAPABILITIES = ["aside", "btw", "steer"];
 var DELIVERY_DUPLICATE_WINDOW_MS = 72 * 60 * 60 * 1000;
+var IssueDeployedEventPayloadSchema = exports_external.strictObject({
+  repo: exports_external.string(),
+  number: exports_external.number().int().positive(),
+  run_id: exports_external.number().int().positive(),
+  completed_at: exports_external.iso.datetime()
+});
+var DispatchServerStartedPayloadSchema = exports_external.strictObject({
+  commit: exports_external.string().min(1),
+  started_at: exports_external.iso.datetime()
+});
 var DispatchEventSchema = exports_external.object({
   issue_key: exports_external.string().nullable(),
   artifact_id: exports_external.string().nullish(),
@@ -15621,11 +15631,11 @@ var LEGION_WORKFLOW_PHASES = [
   "implementing",
   "testing",
   "reviewing",
+  "accepting",
   "retro",
   "merging",
   "awaiting_merge",
   "integrating",
-  "production_check",
   "done",
   "held"
 ];
@@ -15635,10 +15645,10 @@ var LEGION_PHASE_BACKWARD_TARGETS = [
   "implementing",
   "testing",
   "reviewing",
+  "accepting",
   "retro",
   "merging",
   "awaiting_merge",
-  "production_check",
   "done",
   "held"
 ];
@@ -15712,6 +15722,22 @@ var legionSlotView = exports_external.strictObject({
   admittedAt: timestamp,
   lentTo: issueKey.optional()
 });
+var legionCheckWakeView = exports_external.strictObject({
+  kind: nonEmptyString,
+  detail: exports_external.string(),
+  at: timestamp
+});
+var legionCheckView = exports_external.strictObject({
+  repo: nonEmptyString,
+  pullRequest: exports_external.number().int().positive(),
+  mergeCommit: exports_external.string(),
+  openedAt: timestamp,
+  looks: exports_external.number().int().nonnegative(),
+  lookOpen: exports_external.boolean(),
+  lastWake: legionCheckWakeView.optional(),
+  nextWakeAt: timestamp,
+  last: exports_external.boolean()
+});
 var legionPendingStatusWrite = exports_external.strictObject({
   issue: nonEmptyString,
   payload: exports_external.record(exports_external.string(), exports_external.unknown()),
@@ -15743,7 +15769,8 @@ var legionIssue = exports_external.strictObject({
   workers: exports_external.partialRecord(exports_external.enum(LEGION_ROLES), legionPhaseView),
   pullRequest: legionPullRequestView.optional(),
   designGate: legionGateView.optional(),
-  slot: legionSlotView.optional()
+  slot: legionSlotView.optional(),
+  check: legionCheckView.optional()
 });
 var daemonInfo = exports_external.strictObject({
   project: nonEmptyString,
@@ -15915,7 +15942,7 @@ var LegionHandoffCompleteRequest = exports_external.strictObject({
   summary: nonEmptyString,
   verdict: exports_external.string(),
   ready: exports_external.boolean(),
-  commit: nonEmptyString
+  commit: nonEmptyString.optional()
 });
 var LegionIssueStatusRequest = exports_external.strictObject({
   grantId: nonEmptyString,
@@ -15935,7 +15962,8 @@ var LegionWaveReleaseRequest = exports_external.strictObject({
 var LegionPhaseBackwardRequest = exports_external.strictObject({
   grantId: nonEmptyString,
   to: exports_external.enum(LEGION_PHASE_BACKWARD_TARGETS),
-  reason: nonEmptyString
+  reason: nonEmptyString,
+  issue: nonEmptyString.optional()
 });
 var LegionPhaseRetryRequest = exports_external.strictObject({
   grantId: nonEmptyString,
@@ -16885,7 +16913,7 @@ async function bootLegionClaim(host2) {
 // package.json
 var package_default = {
   name: "@sjawhar/pi-legion",
-  version: "10.15.0",
+  version: "10.16.1",
   license: "Apache-2.0",
   type: "module",
   omp: {
@@ -16897,7 +16925,7 @@ var package_default = {
     ]
   },
   legion: {
-    daemonApiVersion: 32
+    daemonApiVersion: 33
   },
   repository: {
     type: "git",
@@ -17320,10 +17348,13 @@ var PhaseOpArguments = exports_external.discriminatedUnion("op", [
   operation("read_record", { issue: requiredString("read_record", "issue") }),
   operation("handoff_complete", {
     summary: requiredString("handoff_complete", "summary"),
-    verdict: exports_external.enum(["pass", "fail"], { error: "handoff_complete's verdict is pass or fail" }).optional(),
+    verdict: exports_external.enum(["pass", "pending", "fail"], {
+      error: "handoff_complete's verdict is pass, pending or fail"
+    }).optional(),
     ready: exports_external.boolean({ error: "handoff_complete's ready is true or false" }).optional()
   }),
   operation("request_backward_move", {
+    issue: exports_external.string().optional(),
     to: exports_external.enum(LEGION_PHASE_BACKWARD_TARGETS, {
       error: (issue2) => typeof issue2.input === "string" && issue2.input.trim() !== "" ? `request_backward_move's to is one of ${LEGION_PHASE_BACKWARD_TARGETS.join(", ")}` : "request_backward_move requires to"
     }),
@@ -17356,8 +17387,12 @@ function phaseOpParameters(zod) {
   const byField = fields;
   return byField;
 }
+var PHASE_OP_SENTENCES = {
+  readRecord: "read_record returns the record of `issue` from the daemon's state. ",
+  requestBackwardMove: "request_backward_move returns an issue to an earlier phase (`to`, `reason`): a phase worker moves its own issue; " + "the tree's architect moves an issue in accepting, named by `issue`, back to implementing or testing, which counts a review round. "
+};
 function legionToolDescription(host2) {
-  return "Perform the workflow operation the Legion daemon assigned this role. The daemon advances phases; this tool cannot spawn workers. " + (host2.before ?? "") + "handoff_complete (phase workers and sub-architects; the daemon accepts a completion only from the role working the issue's current phase) " + "reports this phase complete: `summary` (two sentences for the architect, or the merger's READY packet), `verdict` pass|fail from the tester alone " + "(the daemon refuses a verdict from any other role), `ready: true` for the merger's READY. A handoff is a committed file, `.legion/<issue>/<phase>.json`: the pushed commit " + "carrying it is found here, with the pane's jj, and reported, so write it, commit it and push the branch (`jj git push`) before calling; this call " + "refuses, posting nothing, a handoff still in the working copy, missing, not committed on this branch, carried by another pane's commit, or not yet " + "on `legion/<issue>@origin`, each naming the remedy. The daemon refuses HANDOFF_NOT_NEW (the commit is the one you reported for your previous " + "phase: write and commit this phase's handoff) and, for READY, each refusal the merger's role names; a refused completion changed " + "nothing, so fix what it names and complete again. An accepted READY whose `note` begins MANUAL_MERGE_REQUIRED: is one a person merges: arm nothing. " + (host2.after ?? "") + `What a later phase needs goes in your handoff; a question for another live role goes to its role topic with ${host2.envoyPublish}.`;
+  return "Perform the workflow operation the Legion daemon assigned this role. The daemon advances phases; this tool cannot spawn workers. " + (host2.before ?? "") + "handoff_complete (phase workers and sub-architects; the daemon accepts a completion only from the role working the issue's current phase, " + "and the implementer's report on a look of its closed issue's production check) reports this phase complete: `summary` (two sentences for the " + "architect, or the merger's READY packet), `verdict` pass|fail from the tester alone on a phase completion (the daemon refuses a verdict from " + "any other role there) and pass|pending|fail from the implementer on a production check report (pending: production does not carry the merge " + "yet), `ready: true` for the merger's READY. A handoff is a committed " + "file, `.legion/<issue>/<phase>.json`: the pushed commit carrying it is found here, with the pane's jj, and reported, so write it, commit it and " + "push the branch (`jj git push`) before calling; this call refuses, posting nothing, a handoff still in the working copy, missing, not committed " + "on this branch, carried by another pane's commit, or not yet on `legion/<issue>@origin`, each naming the remedy. A production check report " + "(the task whose first line is `Production check of <KEY>`, handed to the implementer once the merge closed its issue) needs no handoff and no " + "commit: it carries its verdict and summary alone, and the daemon refuses it when no check is open (CHECK_NOT_OPEN). The daemon refuses " + "HANDOFF_NOT_NEW (the commit is the one you reported for your previous phase: write and commit this phase's handoff) and, for READY, each " + "refusal the merger's role names; a refused completion changed nothing, so fix what it names and complete again. An accepted READY whose `note` " + "begins MANUAL_MERGE_REQUIRED: is one a person merges: arm nothing. " + (host2.after ?? "") + `What a later phase needs goes in your handoff; a question for another live role goes to its role topic with ${host2.envoyPublish}.`;
 }
 async function mintClaimGrant(daemon, claim) {
   const { grantId } = await daemon.grant({
@@ -17393,8 +17428,27 @@ async function executePhaseOp(runtime, input) {
     case "read_record":
       return { record: recordFrom(await daemon.state(), args.issue) };
     case "handoff_complete": {
-      const { phase } = recordFrom(await daemon.state(), claim.issue);
-      const commit = await runtime.handoffCommit(phase, claim.role);
+      const record2 = recordFrom(await daemon.state(), claim.issue);
+      if (claim.role === "implementer" && record2.phase === "done") {
+        if (record2.check !== undefined) {
+          if (args.verdict === undefined) {
+            throw new Error("handoff_complete on a production check names a verdict of pass, pending or fail");
+          }
+          if (args.ready === true) {
+            throw new Error("handoff_complete on a production check is no READY: leave ready out");
+          }
+        }
+        return daemon.handoffComplete({
+          grantId: await mintClaimGrant(daemon, claim),
+          summary: args.summary,
+          verdict: args.verdict ?? "",
+          ready: false
+        });
+      }
+      if (args.verdict === "pending") {
+        throw new Error("handoff_complete's verdict is pass or fail on a phase completion; pending is a production check's");
+      }
+      const commit = await runtime.handoffCommit(record2.phase, claim.role);
       return daemon.handoffComplete({
         grantId: await mintClaimGrant(daemon, claim),
         summary: args.summary,
@@ -17403,13 +17457,24 @@ async function executePhaseOp(runtime, input) {
         commit
       });
     }
-    case "request_backward_move":
+    case "request_backward_move": {
+      let issue2;
+      if (claim.role === "architect") {
+        if (args.issue === undefined || args.issue.trim() === "") {
+          throw new Error("request_backward_move requires issue");
+        }
+        issue2 = args.issue;
+      } else if (args.issue !== undefined && args.issue !== claim.issue) {
+        throw new Error(`a phase worker moves only its own issue ${claim.issue}, not ${args.issue}`);
+      }
       await daemon.phaseBackward({
         grantId: await mintClaimGrant(daemon, claim),
         to: args.to,
-        reason: args.reason
+        reason: args.reason,
+        ...issue2 === undefined ? {} : { issue: issue2 }
       });
       return {};
+    }
   }
 }
 
@@ -17492,7 +17557,7 @@ function createLegionTool(deps) {
     label: "legion",
     description: legionToolDescription({
       envoyPublish: "envoy_publish",
-      after: "The controller's read_state returns the daemon's whole state and set_status moves an issue to todo, backlog or icebox. "
+      after: PHASE_OP_SENTENCES.requestBackwardMove + "sign_off is the architect's acceptance of an issue in accepting, moving it to retro; the daemon refuses it in every " + "other phase (SIGNOFF_OUTSIDE_ACCEPTING). " + "The controller's read_state returns the daemon's whole state and set_status moves an issue to todo, backlog or icebox. "
     }),
     defaultInactive: true,
     parameters: toolSchema(pi),

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

@@ -1,6 +1,6 @@
 ---
 name: legion-architect
-description: Own a Legion root or child issue through event-driven decomposition, waves, gates, integration, retro, sign-off, and close.
+description: Own a Legion root or child issue through event-driven decomposition, waves, gates, integration, acceptance, retro, and the merge that closes it.
 ---
 
 # Legion Architect
@@ -15,8 +15,9 @@ separate coordinator to finish necessary work.
 - Use the `legion` tool for lifecycle writes. Its issue key is the Dispatch key
   (pattern `^[A-Z][A-Z0-9]*-[0-9]+$`, e.g. `LEGION-41`).
 - The daemon starts every Legion role itself and sequences each issue's phases from its fixed
-  workflow table: planner, implementer, tester, reviewer, retro (the implementer again), merger,
-  and, after the pull request merges, the implementer's production check. One role works an
+  workflow table: planner, implementer, tester, reviewer, your acceptance (`accepting`, where no
+  worker runs), retro (the implementer again), merger, and the merge, which closes the issue; the
+  implementer's production check follows the close. One role works an
   issue at a time, and the handoff or event that ends its phase is what starts the next; you start,
   re-assign and order no worker. Message a known phase worker with `envoy_publish` to
   `notifications.role.` followed by its encoded role token. Phase workers escalate lifecycle,
@@ -221,7 +222,7 @@ reachable, do not have a different running session perform the read on this tree
 fold the result into the spec as if it were routine: write the missing capability as its own
 decision block — which external system, which read or write, why the spec needs it — addressed
 to the human, in the same spirit as the implementer's ask to a person when the deployment
-instructions name nobody for a deploy (section 6), and leave it
+instructions name nobody for a deploy (`skill://legion-worker/references/merge-gate.md`), and leave it
 open until the human resolves it. A workaround substituted for that record only hides the gap
 from the next tree that hits it.
 
@@ -250,12 +251,13 @@ stays out of the workflow.
 No notice marks the last child's close as the end-game: each closure arrives as its own
 `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 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
+tree, the root included, so the root's tester and reviewer can run, and the root reach `accepting`,
+before any child merges; your acceptance is where the root waits for its children (section 7). 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 accept the root (section 6) 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
 corrective child wave you create and release, and the tree returns to children-in-flight. Do not
@@ -268,9 +270,10 @@ registering its spec or asking for approval again. A child whose old root had no
 none, and its catch-up says `handed_over` without `carried`. Its workers already run their phases,
 so its architect decomposes nothing. It reads the root's phase from the catch-up (for a root
 `held`, the phase its `held` notice names). Before `awaiting_merge` it registers its spec, the gate
-its READY waits for, and starts nothing on that gate's `design-approved`; in `awaiting_merge` or
-`production_check` the READY is already through, so it registers no spec, asks no human to approve
-one, and signs off after the production check. `awaiting_merge` can move back: a red or
+its READY waits for, and starts nothing on that gate's `design-approved`; a child carried in
+`accepting` is yours to accept (section 6). In `awaiting_merge` the READY is already through, so it
+registers no spec and asks no human to approve one: the merge closes the issue, and the production
+check after it is the implementer's. `awaiting_merge` can move back: a red or
 conflicting head returns the root to `implementing` and its next READY reads the gate again, so if
 a later `ready-refused` arrives because the head was sent back, it registers then, as that row
 says. The child stays its own tree after hand-over; reopening the old root later does not take it
@@ -286,8 +289,8 @@ child wave; a passing result goes on to review and the merge-gate sequence by th
 
 ## 5. Retro
 
-Retro is mandatory for every issue that passed review, before merge, and the daemon runs it: when
-the reviewer's approval ends the review round, it moves the issue to `retro` and starts the
+Retro is mandatory for every issue that passed review, before the merge, and the daemon runs it:
+when your `sign_off` accepts the issue (section 6), it moves the issue to `retro` and starts the
 implementer on it, in the same agent's session, which stayed live after its phase ended (every
 started role stays live until its issue closes). You start nothing for it. Never `envoy_publish` to
 the implementer's role topic to start retro: the daemon's start is what records which role owns
@@ -303,18 +306,41 @@ came back empty, or that GitHub refused the body, it has pushed nothing and is s
 Answer it with `envoy_publish` to its role topic, saying how from the deployment instructions;
 when they do not say, open a `dispatch ask` naming the missing instruction.
 
-## 6. Architect sign-off and merge
+## 6. Acceptance and the merge
 
-Sign off only when scope is fully met, integration evidence is current, corrective work
-is complete, review is clean, retro completed, and no necessary work was silently
-deferred. Make the sign-off comment explicit about that evidence. Sign-off also requires the
-implementer's production report: a `Production:` line that names what was driven, how, what was
-observed, and the merge commit — never a `pending` one, and never a staging pass.
+The reviewer's approval of the head moves the issue to `accepting` (its Dispatch status stays
+`needs_review`), where no worker runs and the acceptance is yours; the reviewer's `phase-finished`
+notice with an `APPROVED` review is the cue. Read the evidence against every acceptance line of the
+spec and the plan: the tester's handoff (`.legion/<issue>/test.json` at the approved head), the PR
+body's `E2E (implementer)` and `E2E (tester)` lines, the reviewer's approval of that head by SHA
+(`gh api repos/<o>/<r>/pulls/<n>/reviews`), and, for a parent, that every child is `done`
+(section 3). Accept only when scope is fully met, integration evidence is current, corrective work
+is complete, review is clean, and no necessary work was silently deferred. Post the acceptance as a
+`dispatch comment` explicit about that evidence, then accept with `sign_off`, which runs only in
+`accepting` (refused `SIGNOFF_OUTSIDE_ACCEPTING` elsewhere) and moves the issue to `retro` with the
+status `retro`:
+
+```text
+dispatch comment --issue LEGION-40 --body-file - <<'EOF'
+<acceptance: scope, integration evidence, the tester's handoff, both E2E lines, the approved head>
+EOF
+legion({ op: "sign_off", issue: "LEGION-40" })
+```
+
+What fails goes back, not forward: `request_backward_move` with `issue` (your grant serves the
+tree, so the move names the issue), `to` `implementing` or `testing`, and a `reason` naming what
+fails; the daemon starts that phase's role with the reason in its task and counts a review round,
+as a reviewer's request for changes does. A `handoff_complete` from you in `accepting` is refused
+(`ACCEPTANCE_IS_SIGN_OFF`). CI red at the head in `accepting` returns the issue to `implementing`
+by the daemon's table, as in review. No `Production:` line is asked here: the production check is
+the implementer's after the merge closes the issue (section 7), and nothing after the merge is
+yours.
 
 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
+   `accepting`, where you accept it with `sign_off` or send it back; your `sign_off` moves it to
    `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
@@ -341,17 +367,10 @@ The daemon keeps this order from its fixed table; you start none of its steps:
    back to `reviewing`, the move's reason naming the code and what it found, so the reviewer runs a
    new round. A READY refused because the head still carries `.legion/<issue>/` goes back to
    `retro`, so the implementer's retro removes it.
-5. the merge lands under the repository's rules; 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
-   report exists. A defect it finds is a corrective child issue of this tree, not a note on a
-   closed one. If the implementer cannot perform the deploy itself, it asks the agent or role the
-   deployment instructions name for that deploy (an Envoy role), gives it the merge commit, and
-   waits on the production signal the instructions name; the issue waits with it. It opens a
-   `dispatch ask` to a person only when the instructions name nobody for that deploy, starting
-   with the production gap and why it matters, then naming the required step, its risk, and
-   outcome-named options. No one is ever asked for approval to deploy.
+5. the merge lands under the repository's rules and closes the issue (section 7). The implementer's
+   production check follows the close, in its own session and on the pull request; you are asked
+   nothing for it, and a defect it finds is filed as an issue of its own in the project, never as a
+   child of the closed one.
 
 What returns the tree to review: a changed diff — a commit above the approved head that
 touches anything outside `docs/solutions/` and the issue's `.legion/<issue>/`, or a
@@ -366,13 +385,14 @@ never a rebase, since a rebase rewrites every descendant of the chain's fork poi
 another tree's branch stacked on it), pushes it as every role pushes (`jj git push`; a genuine
 fast-forward, and a code push, so no `skip-checks: true` line), and posts the before/after fingerprints; the tester re-runs the bare gates only;
 the reviewer confirms and approves the new head by SHA (or continues its round if it had not
-approved); the daemon carries the issue on through retro to the merger, whose new READY packet the daemon posts.
+approved); the daemon carries the issue on through your acceptance and retro to the merger, whose new READY packet the daemon posts.
 This merge happens only when GitHub reports `CONFLICTING`
 (`gh pr view <n> --json mergeable,mergeStateStatus`); read that on every end-game
 wake — `phase-finished`, `catch-up`, `checks-red`, `review-stuck` — because a `CONFLICTING`
 PR gets no CI and no wake announces it. The moment you see it, tell the worker holding the issue's
 phase (`envoy_publish` to its role topic) to move the issue back to `implementing` with
-`request_backward_move`; in `awaiting_merge`, where no worker holds a phase, open a `dispatch ask`
+`request_backward_move`; in `accepting` the move is yours (`request_backward_move` with `issue`);
+in `awaiting_merge`, where no worker holds a phase, open a `dispatch ask`
 naming the conflict for the human who merges. Do not let the merger send a READY packet for an
 obsolete approval.
 
@@ -387,18 +407,24 @@ role topic, or its review body); the reviewer resolves none.
 
 ## 7. Close
 
-After the merge result and the implementer's production report are recorded, post the sign-off and
-close this issue with `sign_off`, which writes `done`:
-
-```text
-dispatch comment --issue LEGION-40 --body-file - <<'EOF'
-<sign-off: scope, integration evidence, review, retro, merge, and the implementer's production report>
-EOF
-legion({ op: "sign_off", issue: "LEGION-40" })
-```
-
-Closing a child supplies the closure event (`child-closed`) to its parent. Do not close a parent
-until the entire end-game sequence has completed.
+The merge closes the issue: when GitHub reports the pull request merged while the issue is in
+`awaiting_merge` (a merge before that closes it the moment it gets there), the daemon writes
+`done`. A child's close reaches you as `child-closed`; the daemon retires five of its six claims,
+suspends its implementer with its session kept, and sets its Sandbox `Suspended` with its volume,
+because the implementer still owes the production check: handed to it in its live session at the
+merge, it is work after the close that holds no pod while it waits for the deploy
+(`skill://legion-worker/references/merge-gate.md`, *The production check after the close*). A
+root's close writes `done`, frees the tree's admission slot, and lingers the tree for
+`linger_hours` with every member suspended; a child still in the workflow at the end of the linger
+is handed over (section 3), and the tree's close waits for a member's open check.
+
+Nothing of the check is yours: you post no sign-off after the merge and wait for no record. Its
+record lives on the pull request alone, since Dispatch refuses a write on a closed issue; a defect
+it finds is filed as an issue of its own in the project, never a child of the closed one; and
+`read_record` shows a closed issue's open check (`check`: the pull request, the merge commit, the
+looks, what woke the last one and when the next is due). A parent waits in `accepting` until
+every child is `done` (section 3): accepted earlier it would merge before its children, the state
+dispatch://LEGION-703 has the daemon rule out.
 
 ## Wake routing
 
@@ -418,13 +444,13 @@ active phase worker.
 | `child-not-recorded` | Its `reason` names a child your tree did not record and why: its repository resolves to none (neither it nor an ancestor names one, and the project has no default), or to one not mapped to the project, or to one the daemon leaves out for a missing GitHub App. The daemon said why on the child too. Set the child's repository to one of the project's (`dispatch issue-update --repo owner/name`), then release it again with `release_children`; tell the controller when the repository it needs is not served. |
 | `design-approved` | Its `version` is the approved one. A human approved the root spec document at its current version; the gate is open. Proceed to section 2 — except on a root whose catch-up said `handed_over`: its workers already run their phases, so start nothing; the approval releases any READY the gate refused. One whose `version` is the version a human's own answer to a decision block wrote, after an earlier approval (Dispatch carried that approval to it, section 1), opens nothing new: carry on, and release no wave because of it. |
 | `design-changes-requested` | Its `version` and `reason`. A human asked for changes to the root spec at `version`, for `reason`. Revise the spec as the reason asks and request approval again as section 1 says; stay parked; the gate is closed. |
-| `phase-finished` | The daemon has already moved the issue to its next phase by its fixed table and started that phase's role; you start nothing. Read the committed handoff for the finishing phase; if it shows unresolved gaps, tell the role now working the issue (`envoy_publish` to its role topic). A `planner` notice that names a departure from the spec's design defers to section 1's full condition: when the approved Summary, Acceptance, scope and settled decisions still hold, the plan is the record; otherwise change the root spec and request approval again as section 1 says. A `reviewer` notice whose GitHub review is `CHANGES_REQUESTED` needs nothing from you: the daemon has returned the issue to `implementing` (Dispatch `in_progress`) and started the **implementer**, whose correction goes through the tester and the reviewer again, never straight to retro. A `reviewer` notice with an `APPROVED` review means the daemon has started retro (step 5). An `implementer` notice for `production_check` is its production report: read the record on the pull request and the issue, then run step 7. A `tester` notice with `verdict: "fail"` — its handoff carries `implementerProof.verdict: "rejected"`, or a failure naming the production-like proof — has gone back to the **implementer** by the daemon's table; never supply the proof from another role. A worker that reports no surface reaches the changed path sends that report instead of completing its phase, so the daemon starts nothing more on that issue and the worker stays idle in its session, not suspended: file a child issue in this tree to build the surface (infrastructure, tooling, or a skill), and when that child's `child-closed` arrives, tell the waiting worker to continue with `envoy_publish` to its role topic. That report is never a reason to advance the phase. |
-| `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 a conflict (`the head conflicts with <base>`), the required checks that failed (`CI is red at <head>`), or the merge queue's failed merge and its failing run (`the merge queue took pull request #<n> out at READY's 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, or when the merge queue fails the merge) 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` for a READY refusal (`READY_UNREVIEWED_CHANGE`, or `READY_NOT_APPROVED` when its task names no approved head), and the reviewer's no-fix request for changes that follows it so the tester runs the head, are 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. |
+| `phase-finished` | The daemon has already moved the issue to its next phase by its fixed table and started that phase's role; you start nothing. Read the committed handoff for the finishing phase; if it shows unresolved gaps, tell the role now working the issue (`envoy_publish` to its role topic). A `planner` notice that names a departure from the spec's design defers to section 1's full condition: when the approved Summary, Acceptance, scope and settled decisions still hold, the plan is the record; otherwise change the root spec and request approval again as section 1 says. A `reviewer` notice whose GitHub review is `CHANGES_REQUESTED` needs nothing from you: the daemon has returned the issue to `implementing` (Dispatch `in_progress`) and started the **implementer**, whose correction goes through the tester and the reviewer again, never straight to retro. A `reviewer` notice with an `APPROVED` review means the issue is in `accepting` and the acceptance is yours (section 6): read the evidence, then `sign_off` or send it back with `request_backward_move`. A `tester` notice with `verdict: "fail"` — its handoff carries `implementerProof.verdict: "rejected"`, or a failure naming the production-like proof — has gone back to the **implementer** by the daemon's table; never supply the proof from another role. A worker that reports no surface reaches the changed path sends that report instead of completing its phase, so the daemon starts nothing more on that issue and the worker stays idle in its session, not suspended: file a child issue in this tree to build the surface (infrastructure, tooling, or a skill), and when that child's `child-closed` arrives, tell the waiting worker to continue with `envoy_publish` to its role topic. That report is never a reason to advance the phase. |
+| `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`, `accepting`, `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 `accepting`, where no worker holds a phase, the move is yours: `request_backward_move` with `issue`, naming the failing checks. 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 a conflict (`the head conflicts with <base>`), the required checks that failed (`CI is red at <head>`), or the merge queue's failed merge and its failing run (`the merge queue took pull request #<n> out at READY's 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; your own send-back from `accepting` by the reason you gave. 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, or when the merge queue fails the merge) 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` for a READY refusal (`READY_UNREVIEWED_CHANGE`, or `READY_NOT_APPROVED` when its task names no approved head), and the reviewer's no-fix request for changes that follows it so the tester runs the head, are 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 merge closes the issue the moment it reaches `awaiting_merge` (section 7), and you start nothing; the production check after the close is the implementer's, on the pull request, and asks nothing of you. Until then the phases run as they would, your acceptance included. |
 | `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. |
-| `merge-removed` | Its `reason` names who took the pull request out of the merge queue or turned its auto-merge off at READY's head after the daemon submitted it, or says GitHub turned it off on its own (over a repository setting such as a merge method the repository blocks) and names the App that submitted the merge, which GitHub names as the actor of its own disables; then what was removed, GitHub's reason (`manual`, `merge_conflict`, `manually_disabled`, `merge_commit_blocked`, …), when, and READY's head. It was not a failed merge, which comes as a `checks-red` instead. The daemon submits that merge no further, so the removal stands, and the issue stays in `awaiting_merge`. Read the pull request on GitHub. A `merge_conflict` conflicts with the base or with a pull request queued ahead of it: once the conflict is on the base, the daemon's own conflict check sends the issue back to `implementing` by itself. Otherwise ask a person with `dispatch ask` (the one who removed it, when the reason names a person rather than GitHub on its own), naming the pull request at READY's head and the reason; that person merges or queues it again under the repository's rules, and the merge moves the issue on to its production check. Never bypass a rule. |
+| `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 closes the issue. 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 closes the issue. 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. |
+| `merge-removed` | Its `reason` names who took the pull request out of the merge queue or turned its auto-merge off at READY's head after the daemon submitted it, or says GitHub turned it off on its own (over a repository setting such as a merge method the repository blocks) and names the App that submitted the merge, which GitHub names as the actor of its own disables; then what was removed, GitHub's reason (`manual`, `merge_conflict`, `manually_disabled`, `merge_commit_blocked`, …), when, and READY's head. It was not a failed merge, which comes as a `checks-red` instead. The daemon submits that merge no further, so the removal stands, and the issue stays in `awaiting_merge`. Read the pull request on GitHub. A `merge_conflict` conflicts with the base or with a pull request queued ahead of it: once the conflict is on the base, the daemon's own conflict check sends the issue back to `implementing` by itself. Otherwise ask a person with `dispatch ask` (the one who removed it, when the reason names a person rather than GitHub on its own), naming the pull request at READY's head and the reason; that person merges or queues it again under the repository's rules, and the merge closes the issue. 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-controller/SKILL.md

@@ -269,9 +269,9 @@ leans on `External links:`, and the label row is the one that never depends on h
 
 - `OPEN`: work in flight. Skip it; the issue stays where it is.
 - `MERGED`: the change landed. Take nothing and set nothing: an issue Legion ran is already skipped
-  by the `Legion ran it without the label now on it` row, and the daemon moves such an issue to its
-  production check itself on the merge event; one Legion did not run is someone's finished work with
-  the issue left open. Skip it and name it in your summary
+  by the `Legion ran it without the label now on it` row, and the daemon closes such an issue
+  itself on the merge event (its implementer's production check follows the close); one Legion did
+  not run is someone's finished work with the issue left open. Skip it and name it in your summary
   (`<KEY>: pull request <url> merged, the issue is still todo`) so a person closes it.
 - `CLOSED` (not merged): someone abandoned the change. Skip it and name it in your summary; the
   issue's owner decides what follows. For an issue Legion runs, the daemon tells its architect

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

@@ -20,7 +20,9 @@ retrospective's durable output.
 
 1. Tester green and all code-review cycles finish.
 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.
+   (`<issue>` is your `LEGION_ISSUE`), which every tester and reviewer round writes again. The
+   architect then accepts the issue (`accepting`) with `sign_off`, which starts this retro; one it
+   sends back to `implementing` or `testing` instead runs those phases again first.
 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
@@ -32,13 +34,14 @@ retrospective's durable output.
    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 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
-   in production. The architect's sign-off waits for that record.
-   The record is the pull request's `Production:` line, one pull-request comment, and a
-   `dispatch message` on the issue, each naming what was driven, how, what was observed, and the
-   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.
+5. That merge closes the issue: the daemon writes `done`, and the implementer — not the reviewer or
+   merger — is handed the production check in its live session, as work after the close: the agent
+   that developed the change is responsible for testing it in production, once production carries
+   the merge. The record is the pull request's `Production:` line and one pull-request comment,
+   naming what was driven, how, what was observed, the merge commit and what woke the look; nothing
+   is written on the closed issue, since Dispatch refuses it. A defect the check finds is filed as
+   an issue of its own in the project, never as a child of the closed one
+   (`skill://legion-worker/references/merge-gate.md`, *The production check after the close*).
 
 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
@@ -47,7 +50,7 @@ the approved head with no review round after it brings the base's paths above th
 refuses it (`READY_UNREVIEWED_CHANGE`) and the reviewer reviews the new head as a new round; one the
 conflict procedure sends back through `implementing` is confirmed before READY. 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
+and every approval, through the architect's acceptance, 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
@@ -174,7 +177,7 @@ 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. The message must carry this revived implementer's structured
+follows the merge's close of the issue. The message must carry this revived implementer's structured
 attribution footer with `phase` set to `retro`; the body is capped at 2,000 characters:
 
 ```bash
@@ -189,7 +192,7 @@ dispatch message --issue <KEY> --body-file - <<'EOF'
 
 **Proofs read:** implementer <surface/command>, tester <surface/command>.
 
-**Production check:** <what the implementer will drive after the merge, and any deploy or restart it waits on first, with the agent or role the deployment instructions name to perform it, or the person it asks when they name none>
+**Production check:** <what the implementer will drive in production once the merge closes the issue and production carries it, and the deploy or restart that carries it there, with the agent or role the deployment instructions name to perform it, or the person it asks when they name none; no reply is awaited, the daemon wakes the check on the deploy's event>
 
 <!-- legion: {"session":"<session-id>","phase":"retro"} -->
 EOF

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

@@ -88,8 +88,8 @@ into the branch only on a real conflict or a retarget
 implementer's own proof on a production-like surface at the head that merges, an applied simplify
 head included (`skill://legion-worker/references/pr-body.md#what-a-proof-is`,
 `skill://legion-worker/references/pr-body.md#the-rules-every-phases-evidence-follows`); and the
-implementer's production check after the merge
-(`skill://legion-worker/references/merge-gate.md#after-the-merge`).
+implementer's production check after the merge closes the issue
+(`skill://legion-worker/references/merge-gate.md#the-production-check-after-the-close`).
 
 ## Asking another role
 
@@ -304,12 +304,12 @@ line), the full definition of a proof, what the tester verifies, and the simplif
   forward merge and never `jj rebase`; the unchanged-diff fingerprint each role compares
   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 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, the daemon's submission, and the production check follow the same reference.
+  → the architect's acceptance → retro → the merger's READY → the merge, which closes the issue →
+  the implementer's production check, after the close. On READY's 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, the acceptance, retro's commit, READY, the daemon's submission, and the 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`.
 
@@ -370,9 +370,9 @@ check, or the `MANUAL_MERGE_REQUIRED:` note of a pull request a person merges).
 
 Retro's last commit removes `.legion/<issue>/` from the head that 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` reports the commit carrying the file. Retro, the merger and the
-post-merge production check write no `.legion/<issue>/<phase>.json`, commit no handoff, and report
-with `handoff_complete` alone, which reports the commit the workspace stands on.
+again, since `handoff_complete` reports the commit carrying the file. Retro and the merger write no
+`.legion/<issue>/<phase>.json`, commit no handoff, and report with `handoff_complete` alone, which
+reports the commit the workspace stands on; a look of the production check after the close reports with `handoff_complete` and a `verdict`, and no commit at all.
 
 **Every role pushes its own commits.** After the handoff commit — and, for the tester, the red
 tests it wrote — push the issue branch with the plain `jj` of your pane, from bash in your