@sjawhar/opencode-legion-envoy 1.18.1 → 1.19.0

package/dist/src/server.js

@@ -14006,6 +14006,15 @@ var HANDOFF_SCHEMA_VERSION = 1;
 var HANDOFF_PHASES = ["architect", "plan", "implement", "test", "review"];
 var isoTimestamp = string2().regex(/^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}/);
 var handoffPhase = _enum2(HANDOFF_PHASES);
+var nonEmpty = string2().min(1);
+var proofSchema = object({
+  criterion: nonEmpty,
+  surface: nonEmpty,
+  command: nonEmpty,
+  observed: nonEmpty,
+  headSha: nonEmpty,
+  negativeControl: nonEmpty
+}).passthrough();
 var routingHintsSchema = object({
   skipArchitect: boolean2().optional(),
   complexity: _enum2(["trivial", "small", "medium", "large"]).optional(),
@@ -14025,7 +14034,7 @@ var architectSchema = baseHandoffSchema.extend({
   subIssues: array(string2()).optional(),
   routingHints: routingHintsSchema,
   concerns: array(string2()).optional()
-});
+}).passthrough();
 var requiredSkillsSchema = object({
   implement: array(string2()).optional(),
   test: array(string2()).optional(),
@@ -14039,24 +14048,30 @@ var planSchema = baseHandoffSchema.extend({
   concerns: array(string2()).optional(),
   workflowRecommendation: string2().optional(),
   requiredSkills: requiredSkillsSchema
-});
+}).passthrough();
 var implementSchema = baseHandoffSchema.extend({
   phase: literal("implement"),
   filesChanged: array(string2()).optional(),
+  proof: array(proofSchema).min(1),
   trickyParts: array(string2()).optional(),
   deviations: array(string2()).optional(),
   openQuestions: array(string2()).optional(),
   subPlanningNeeded: boolean2().optional(),
   discoveredComplexity: array(string2()).optional(),
   suggestedSubWorkers: number2().optional()
-});
+}).passthrough();
 var testSchema = baseHandoffSchema.extend({
   phase: literal("test"),
   passed: number2().optional(),
   failed: number2().optional(),
   failures: array(object({ criterion: string2(), evidence: string2() }).passthrough()).optional(),
+  implementerProof: object({ verdict: _enum2(["verified", "rejected"]), how: nonEmpty }).passthrough(),
+  proof: array(proofSchema).min(1).optional(),
   documentationFeedback: string2().optional(),
   observations: array(string2()).optional()
+}).passthrough().refine((handoff) => (handoff.failures?.length ?? 0) > 0 || (handoff.failed ?? 0) > 0 || (handoff.proof?.length ?? 0) > 0, {
+  path: ["proof"],
+  message: "a passing test handoff needs the tester's own production-like proof"
 });
 var reviewSchema = baseHandoffSchema.extend({
   phase: literal("review"),
@@ -14065,13 +14080,13 @@ var reviewSchema = baseHandoffSchema.extend({
   minor: number2().optional(),
   verdict: _enum2(["approved", "changes_requested"]).optional(),
   keyFindings: array(object({ severity: string2(), file: string2(), description: string2() }).passthrough()).optional()
-});
+}).passthrough();
 var phaseHandoffSchema = discriminatedUnion("phase", [
-  architectSchema.passthrough(),
-  planSchema.passthrough(),
-  implementSchema.passthrough(),
-  testSchema.passthrough(),
-  reviewSchema.passthrough()
+  architectSchema,
+  planSchema,
+  implementSchema,
+  testSchema,
+  reviewSchema
 ]);
 var handoffMessageSchema = object({
   from: handoffPhase,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sjawhar/opencode-legion-envoy",
-  "version": "1.18.1",
+  "version": "1.19.0",
   "type": "module",
   "main": "dist/src/server.js",
   "exports": {

package/skills/AGENTS.md

@@ -42,3 +42,6 @@ A clean review ends with the `.legion/` deletion pushed by the implementer at th
 direction, which the reviewer then approves; retro records its learning in
 `docs/solutions/` and writes no handoff. GitHub comments and reviews carry the required Legion
 footer so the daemon can attribute artifacts to their worker session.
+The implement handoff carries the implementer's own production-like proof and the test handoff the
+tester's verdict on it plus the tester's own; `legion handoff write` refuses a payload the phase's
+schema rejects and names the field. Retro's message goes to the Dispatch issue (`dispatch_message`), never a GitHub issue.

package/skills/legion-architect/SKILL.md

@@ -222,7 +222,9 @@ file or rewrite the reviewer-approved head after cleanup.
 
 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.
+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.
 
 Preserve this order exactly:
 
@@ -242,6 +244,11 @@ Preserve this order exactly:
    merges. The merge queue merges under its own authority and the repository's own rules
    (branch protection, CODEOWNERS); whether a human must approve first is that repository's
    setting, not Legion's, and you never ask for or wait on such an approval.
+5. the merge queue merges; you then `spawn_worker` the **implementer** once more with the
+   production-check task. 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. Close 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; a deploy
+   the implementer cannot perform is its action ask, and the issue waits for it.
 
 What returns the tree to review: a changed diff — a commit above the approved head that
 touches anything outside `docs/solutions/`, or a rebase whose fingerprint (the `legion-worker`
@@ -264,11 +271,11 @@ and the implementer's and merger's runs of the command close every accepted one.
 
 ## 7. Close
 
-After the merge result and sign-off are recorded, post the sign-off and close this issue
-through the Legion write surface:
+After the merge result, the implementer's production report, and sign-off are recorded, post the
+sign-off and close this issue through the Legion write surface:
 
 ```text
-dispatch_comment({ issue: "LEGION-40", body: "<sign-off: scope, integration evidence, review, retro, and merge>" })
+dispatch_comment({ issue: "LEGION-40", body: "<sign-off: scope, integration evidence, review, retro, merge, and the implementer's production report>" })
 legion({ op: "set_status", issue: "LEGION-40", status: "done" })
 ```
 
@@ -289,13 +296,13 @@ corresponding lifecycle procedure.
 | `child-reopened` | Treat the completion edge as reset. Reassess the reopened child and return the tree to children-in-flight; do not continue an already-started end-game. |
 | `design-approved` | Payload `{type:"design-approved"}`. A human approved the root spec document at its current version; the gate is open. Proceed to section 2. |
 | `design-changes-requested` | Payload `{type:"design-changes-requested", version, reason, author?}`. A human asked for changes to the root spec at `version`, for `reason`. Revise the spec, call `dispatch_request_approval` again, and stay parked; the gate is closed. |
-| `phase-complete` | Payload `{type:"phase-complete", issue, role, summary}`. May arrive live or via `catchup-overseer`'s `phaseCompletions`. Read the committed handoff for that phase, then spawn the next phase's owner, or `spawn_worker` on the same role again to resume it with corrections if the handoff shows unresolved gaps. A `reviewer` completion whose GitHub review is `CHANGES_REQUESTED` (the daemon returns the issue's Dispatch status to `in_progress` for this, on the reviewer's completion and again when you spawn the corrective implementer unless the daemon already knows the issue is `in_progress`) means `spawn_worker` the **implementer** again with the review findings — thread URLs and blocking items — as its task, then route back through tester and reviewer in order; never `spawn_worker` the reviewer directly off this wake and never proceed to retro on this verdict. A reviewer completion with an `APPROVED` review proceeds to retro (step 5). A `reviewer` completion after a conflict-forced rebase whose review body names an unchanged fingerprint is a confirmation, not a round: if retro already completed, `spawn_worker` the merger; otherwise resume the step you were on. |
+| `phase-complete` | Payload `{type:"phase-complete", issue, role, summary}`. May arrive live or via `catchup-overseer`'s `phaseCompletions`. Read the committed handoff for that phase, then spawn the next phase's owner, or `spawn_worker` on the same role again to resume it with corrections if the handoff shows unresolved gaps. A `reviewer` completion whose GitHub review is `CHANGES_REQUESTED` (the daemon returns the issue's Dispatch status to `in_progress` for this, on the reviewer's completion and again when you spawn the corrective implementer unless the daemon already knows the issue is `in_progress`) means `spawn_worker` the **implementer** again with the review findings — thread URLs and blocking items — as its task, then route back through tester and reviewer in order; never `spawn_worker` the reviewer directly off this wake and never proceed to retro on this verdict. A reviewer completion with an `APPROVED` review proceeds to retro (step 5). A `reviewer` completion after a conflict-forced rebase whose review body names an unchanged fingerprint is a confirmation, not a round: if retro already completed, `spawn_worker` the merger; otherwise resume the step you were on. An `implementer` completion that follows the merge is its production report: read the record on the pull request and the issue, then run step 7 — the issue is already at `retro`, the daemon writes no status for this completion, and you set `done` yourself. A `tester` completion whose handoff carries `implementerProof.verdict: "rejected"`, or a failure naming the production-like proof, goes back to the **implementer** with that finding — never forward to the reviewer, and never by supplying the proof from another role. A worker that reports no surface reaches the changed path gets a child issue in this tree (infrastructure, tooling, or a skill) and a resume once it lands; that report is never a reason to advance the phase. |
 | `worker-queued` | Payload `{type:"worker-queued", issue, role}`. This role's task is queued for promotion — either the deployment's worker cap is full, or the live worker acknowledged the task without starting a turn and the daemon is retrying it (counted; the worker is replaced after three such failures, still with the same task). Do not respawn or retry — wait for `worker-started`. |
 | `worker-started` | Payload `{type:"worker-started", issue, role}`. A previously queued role has been promoted and is now running. Treat it exactly as a normal spawn: resume tracking that role's live session. |
 | `pr-ready` | Verify the live PR head, green status, and review state. Continue the review/retro/merger order only for that current head. |
 | `pr-review` | Payload `{type:"pr-review", state, author, body}`. Delivered to whichever role is currently active for the issue, falling back to you when no worker phase is active. Follows the same verdict rule as a reviewer's `phase-complete`: `state: "changes_requested"` sends the implementer back in with the review findings, then tester, then reviewer — never the reviewer again and never retro; that `spawn_worker` returns the issue to `in_progress` on its own (the daemon writes it for a corrective implementer whenever the PR's latest recorded review is changes requested, a human's after approval included), so you set nothing by hand; `state: "approved"` proceeds toward retro (step 5) once the step 6 integration/merge-gate conditions are met. `state: "approved"` on a rebased head whose body names an unchanged fingerprint is that confirmation: proceed to retro if it has not run, otherwise to the merger — never to a second retro or test round. |
 | `pr-blocked` | Payload `{type:"pr-blocked", pr, attempts}`. `attempts` counts heads pushed onto a red verdict that changed something outside `.legion/` — handoff-only pushes (`.legion/` paths only) never count; a push the daemon cannot classify (a listener without `changed_paths`, a list capped at 100, 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. Assign a focused implementer or corrective child, then return it through testing and review; do not treat the blocked PR as final. |
-| `pr-merged` | Payload `{type:"pr-merged", pr, mergeCommitSha}`. The merge queue landed the PR. This is your cue for step 7: post the sign-off comment naming that merge commit and set the issue `done`. Nothing else follows a merge. |
+| `pr-merged` | Payload `{type:"pr-merged", pr, mergeCommitSha}`. The merge queue landed the PR. `spawn_worker` the **implementer** with the production-check task naming that merge commit (it resumes the same agent; a retired role has no live holder, so never `envoy_publish` for this). Its `phase-complete` is what brings you to step 7: verify the record on the pull request and this issue first, then sign off naming it and set the issue `done`. A merge is not the close. |
 | `pr-closed-unmerged` | Decide from current scope whether to reopen the work, send a fresh implementer, or cancel it with a reason. Delegate the repository action to the responsible phase worker and keep ownership. |
 | `issue-comment` | Interpret the comment in the issue's design context. Answer it, adjust the plan, or relay it via `envoy_publish` to the responsible worker's role token; scope and product decisions remain with you. |
 | `catchup-overseer` | Verify its gates, child counts, and PR verdicts against current artifacts, then resume the applicable numbered lifecycle step. It is a current-state snapshot, not a raw-event replay. `gates[LEGION_TREE].open` is the design gate's current state: `true` means the root spec is approved at its current version and you may spawn; `false` (or no `open` key, meaning no gate is registered) means the sequence in section 1 still applies. For each entry in its `phaseCompletions` (`{issue, role, summary, at}`, phases that completed while you were not live), handle it exactly as a `phase-complete` wake. Then compare `childCounts[LEGION_ISSUE].open` (the children not `done`) with `legion state` and Dispatch: any **open** released child — `todo` through `retro` — with no architect role claim gets `spawn_worker` for its architect, a `child-adopted` or `child-status` wake you missed while not live; a `done` child gets nothing, whether or not a lingering legacy tree of its own still shows in `legion state`. |

package/skills/legion-retro/SKILL.md

@@ -28,6 +28,10 @@ retrospective's durable output.
    the change in production and records it on the PR and the issue (Sami, 2026-09-13, verbatim:
    "the agent that developed it should be 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.
 
 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 —
@@ -40,10 +44,12 @@ before step 3. The design gate is not a substitute for review and retro.
 ## Two perspectives
 
 1. Re-read the issue, its acceptance criteria, the PR, test evidence, and review evidence.
-   Confirm the PR's `E2E` line links a pre-merge proof on a production-like surface (a devN
-   stack, staging, or a local stack with real migrations). If it links only a unit suite or
-   nothing, the retro's first durable learning is that gap, and the issue goes back to the
-   tester before `READY`.
+   Confirm the PR carries both proofs: the implementer's own `E2E (implementer)` line and the tester's `E2E (tester)` line,
+   each naming a production-like surface (a scratch daemon, a smoke rig, a sandbox repository, a devN
+   stack, staging, or a local stack with real migrations), a command or run id, an observation, a head
+   SHA, and a negative control. If either is missing, or links only a unit suite, the retro's first
+   durable learning is that gap and the issue goes back — to the implementer for its own proof, to the
+   tester for the tester's — before `READY`.
    Do not rebase or create a new branch; work on the existing issue branch.
 2. Spawn one fresh-eyes subagent. Give it the issue and PR, ask it to inspect the diff and
    return concrete reusable learnings, and require it to return analysis rather than edit files.
@@ -75,8 +81,9 @@ related_issues:
 Commit the documentation on the existing issue branch, advance its existing bookmark, and push
 that branch. Do not create a replacement branch or bookmark. Then 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 and the
-one-to-three most useful takeaways. The message must carry this revived implementer's structured
+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
+follows the merge. The message must carry this revived implementer's structured
 attribution footer with `phase` set to `retro`; the body is capped at 2,000 characters:
 
 ```ts
@@ -90,6 +97,10 @@ dispatch_message({
 **Key takeaways:**
 - <reusable lesson>
 
+**Proofs read:** implementer <surface/command>, tester <surface/command>.
+
+**Production check:** <what the implementer will drive after the merge, or the action ask it opened>
+
 <!-- legion: {"session":"<session-id>","phase":"retro"} -->`,
 })
 ```
@@ -105,7 +116,8 @@ Before returning, verify all of the following:
 
 - The reviewer cleanup commit remains below the retro documentation commit, and the reviewer's
   approval of that cleanup head stands: the merger accepts the approved head plus this commit.
-- The learning documents and the Dispatch message both exist.
+- The learning documents and the Dispatch message both exist (never a GitHub issue comment).
+- Both proofs were read, and any gap in either is recorded as a learning.
 - No `.legion` file was created or modified by retro.
 - The fresh-eyes analysis was considered alongside the implementer's context.
 - The merger remains a subsequent step, not work performed by retro.

package/skills/legion-worker/SKILL.md

@@ -263,9 +263,16 @@ left open <thread URL> — newest reply by <login> is not an acceptance
 **Thermo:** thermonuclear-deep-review + thermonuclear-code-quality run once at <head-sha>:
 <verdict>. (omitted entirely on a docs-only PR — no thermo pass runs)
 
-**E2E:** <surface> — ran `<command or run id>`, observed <result>, at head <sha>.
+**E2E (implementer):** <surface> — ran `<command or run id>`, observed <result>, at head <sha>.
 Negative control: <deliberately broken input> → <refusal or failure observed>.
 
+**E2E (tester):** <surface> — ran `<command or run id>`, observed <result>, at head <sha>.
+Negative control: <deliberately broken input> → <refusal or failure observed>.
+Verified the implementer's proof by <re-running its command | driving the same surface independently>.
+
+**Production:** <what was checked in production, how, what was observed> — merge commit <sha>.
+(written by the implementer after the merge lands; `pending <what is missing>` until then)
+
 **Fast-follow:** <one named cleanup item and where it will land>, or "none".
 
 **Chain:** stacked on <base bookmark> frozen at <sha> / not stacked.
@@ -309,12 +316,26 @@ Negative control: <deliberately broken input> → <refusal or failure observed>.
 - **No deferrals.** Sami, 2026-09-11, verbatim: "My rule is no deferrals." The `Fast-follow:`
   field names naming, duplication, or wording cleanup only; anything that changes behaviour,
   hides an error, or breaks a gate lands in this PR.
-- The tester fills in the `E2E` section: the real surface a user reaches the criterion
+- **The implementer proves the change before its phase completes, and writes the `E2E (implementer)` line when the pull request opens.**
+  The proof is the changed behaviour exercised on the surface a user reaches it through — a
+  scratch daemon, a smoke rig, a sandbox repository, a real browser, a devN stack, a local stack
+  with real migrations — with the exact command or run id, what was observed, the head SHA, and
+  one negative control. The same proof goes into `.legion/implement.json` as its required `proof`
+  array (`legion handoff write --phase implement` refuses a payload without one and names the
+  field), and into the PR body, because the reviewer and the merger verify facts on GitHub and
+  never from a handoff. A unit or integration test is a regression lock, never proof of a
+  criterion.
+- **The tester verifies the implementer's proof and adds its own `E2E (tester)` line.** It re-runs
+  the implementer's command or drives the same surface independently, records the verdict in
+  `.legion/test.json` as `implementerProof` (`{verdict, how}`), and records its own proof beside
+  it. A test handoff whose predecessor carried no proof is a test failure, not a gap for the tester to fill:
+  record it in `failures` with `implementerProof.verdict: "rejected"`, complete the phase, and let
+  the architect return the issue to the implementer — the agent that developed the change owns
+  proving it. The tester's own proof names the real surface a user reaches the criterion
   through, the exact command or run id, what was observed, the head SHA, and one negative
-  control — a deliberately broken input and the refusal or failure it produced. A unit or
-  integration test is a regression lock, never proof of a criterion. The surface is
+  control — a deliberately broken input and the refusal or failure it produced. The surface is
   **production-like** — a devN stack, staging, or a local stack with real migrations, one that
-  has the resource the change touches — and the `E2E` line carries a **link** to that run,
+  has the resource the change touches — and each `E2E` line carries a **link** to that run,
   screenshot, or e2e; the merge queue does not approve a user-facing change without it, and a
   green unit suite is not it. Sami, 2026-09-13, verbatim: "They need to test everything in a
   production-like environment before merging, and it is the agent that develops the feature
@@ -340,6 +361,7 @@ Negative control: <deliberately broken input> → <refusal or failure observed>.
 - The reviewer verifies the `CI`, `Threads`, and `E2E` facts against GitHub directly —
   never from a handoff — then runs `task(agent="thermonuclear-deep-review")` and
   `task(agent="thermonuclear-code-quality")` once at that head and records the verdict.
+  Approval is refused while either `E2E (implementer)` or `E2E (tester)` is missing: `REQUEST_CHANGES` naming the missing line.
   Skip the `Thermo` line entirely on a docs-only PR. Submit **one review per round** —
   `REQUEST_CHANGES` when any correctness finding stands, otherwise `COMMENT` while the head
   still carries `.legion/`; `APPROVE` only for a head that carries no `.legion/` — the head
@@ -381,8 +403,9 @@ Negative control: <deliberately broken input> → <refusal or failure observed>.
   `no file changes above the approved head`); then the same with `'~docs/solutions'` appended,
   which must print nothing. Then it publishes `READY #<n> at <tip-sha>` naming the approved
   head, the tip, and that summary, plus the PR body's gate facts, to the merge queue's role
-  (`notifications.role.pr-queue`) with `envoy_publish`. The merger never merges; the queue
-  merges under its own authority.
+  (`notifications.role.pr-queue`) with `envoy_publish`. The READY packet names both the
+  implementer's and the tester's `E2E` lines; a missing one is reported to the architect instead
+  of published. The merger never merges; the queue merges under its own authority.
 - **After the queue merges, the implementer verifies in production.** Sami, 2026-09-13,
   verbatim: "the agent that developed it should be responsible for testing in production."
   The architect sends the implementer back once the merge lands; the implementer watches the
@@ -392,6 +415,29 @@ Negative control: <deliberately broken input> → <refusal or failure observed>.
   this: on 2026-09-12 a slot's entire staging gate passed at 00:02Z and its production-apply
   failed at 00:12Z on a resource staging never runs. If the slot fails on the change, the
   implementer owns the fix and the next slot.
+  The record has three places: the PR body's `Production:` line, one pull-request comment
+  carrying the Legion footer, and a `dispatch_message` on the issue — the reviewer and merger
+  read GitHub, the architect reads the issue. When the deploy that carries the merge has not
+  happened (a shared profile still holding the previous plugin release, a daemon still running
+  the previous commit, a slot nobody has run), open an action ask — `dispatch_ask` with
+  `kind: "action"` — naming the exact install or restart step, keep the `Production:` line at
+  `pending <what is missing>`, and complete the check once the human answers Done. Never record
+  a staging pass as the production check, and never let the architect sign off on a `pending`
+  line.
+
+## When no surface reaches the changed path
+
+No surface reaches the changed path is a report to the architect, never a reason to complete the phase.
+Say which surface is missing and what it would have to do — a rig that can spawn the role, a
+sandbox that holds the resource, a credential, a command that does not exist yet — and send it to
+the architect with `envoy_publish` to its role topic. The architect creates a child issue in this
+tree to build it (infrastructure, tooling, or a skill) and resumes you once it lands. Sami,
+2026-09-13, verbatim: "If there's anything blocking that, we need to fix it: if it's
+infrastructure, we need to fix it; if it's tooling, we need to develop it; if it's skills, we need
+to fix the skills." A code path whose first execution would be after the merge — a deploy
+workflow's inline step, a post-merge helper, a production-only resource — is untested until you
+have executed it somewhere production-like; completing with a unit-test-only handoff is the
+failure this rule exists to stop.
 
 ## The unchanged-diff check
 
@@ -440,6 +486,10 @@ cd -- "$LEGION_WORKSPACE" && \
   legion handoff write --phase <p> --data '<JSON object of phase-specific fields only>'
 ```
 
+`legion handoff write` validates the payload against the phase's schema before writing: an
+implement handoff without a well-formed `proof`, or a test handoff that reports no failure and
+carries no `proof` of its own, exits 1 naming the field and writes nothing.
+
 Then verify the durable artifact exists:
 
 ```bash