@sjawhar/pi-legion-envoy 7.8.0 → 7.8.1

package/dist/legion.js

@@ -17555,7 +17555,7 @@ function endInjectedUserTurns(sessionID) {
 // package.json
 var package_default = {
   name: "@sjawhar/pi-legion-envoy",
-  version: "7.8.0",
+  version: "7.8.1",
   license: "Apache-2.0",
   type: "module",
   omp: {
@@ -18491,7 +18491,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/<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`); " + "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

@@ -86,7 +86,7 @@ The issue's primary document **is** the root specification. Extend it in place:
 that adds only the evidence each decision needs and what the human decides, each as a
 decision block (`skill://dispatch`, "Decision blocks"). The decomposition and its waves, how each
 outcome is proven, and the integration test are your own calls: they go in the child issues and
-the planner's `.legion/plan.json`, not the root spec. Never post a second "spec" artifact beside
+the planner's `.legion/<issue>/plan.json`, not the root spec. Never post a second "spec" artifact beside
 it (`dispatch_artifact` with the primary document's name replaces the human's document; do not do
 that).
 The design gate's approval step runs only when the `Design gate policy` sentence of your
@@ -161,7 +161,7 @@ evidence the human did not weigh that would change the decision, such as a measu
 settled choice cannot meet the Acceptance; then that decision block names the decision and that
 evidence. A plan never overturns a settled decision on its own. A design change that leaves all
 four intact, such as a planner's measurement that finds a better way to build the same outcome,
-goes in the plan (the issue's `plan.md` document and `.legion/plan.json`), never into the approved
+goes in the plan (the issue's `plan.md` document and `.legion/<issue>/plan.json`), never into the approved
 spec, even where the spec's text describes the older design; the reviewer reads the plan beside the
 spec. When a planner's phase-finished notice names a departure from the spec's design, defer to
 this section's full condition: only when the approved Summary, Acceptance, scope and settled

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

@@ -117,7 +117,8 @@ answer questions or to keep editing. Do not create new commits, run
 (and, for the implementer, pushed) — a code change belongs to whichever phase is active now.
 
 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/`:
+committed predecessor handoffs in lifecycle order from
+`$LEGION_WORKSPACE/.legion/<issue>/`:
 
 1. `architect.json`
 2. `plan.json`
@@ -131,11 +132,11 @@ untouched and reach the next worker. The `legion` tool's `handoff_read` returns
 stands in the workspace.
 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/<phase>.json`. If a committed handoff conflicts with memory or a prior
+`$LEGION_WORKSPACE/.legion/<issue>/<phase>.json`. If a committed handoff conflicts with memory or a prior
 transcript, the committed file wins: it is the copy that survived.
 
 If your system prompt begins with `Your workspace was recreated…`, read
-`.legion/workspace-recovered.json`, then your phase's committed handoff, and reconcile before any
+`.legion/<issue>/workspace-recovered.json`, then your phase's committed handoff, and reconcile before any
 new work.
 
 ## jj Safety Rules
@@ -272,7 +273,7 @@ legion gh -- pr comment <pr-number> \
 
 ## Planner artifact
 
-The plan lives in `.legion/plan.json` and the issue's `plan.md` document, never in the issue's
+The plan lives in `.legion/<issue>/plan.json` and the issue's `plan.md` document, never in the issue's
 primary document, which is its spec; never commit a plan or spec file to the repository.
 No `docs/plans/*`, `docs/superpowers/plans/*`, or spec markdown goes into the pull request: plan
 and spec content goes into the issue, never into a PR (the root `AGENTS.md`
@@ -281,7 +282,7 @@ to a file" is satisfied by the handoff write in the completion gate below; the p
 commit is `plan: record handoff`.
 
 A plan that departs from the spec's design records the departure in `plan.md` and in the required
-`.legion/plan.json` `specDepartures`: `[]` means no departure; otherwise each bounded record names
+`.legion/<issue>/plan.json` `specDepartures`: `[]` means no departure; otherwise each bounded record names
 the spec, plan, evidence and outcome. The planner's role prompt defines that record. The planner
 never edits the spec. Whether the spec changes is the architect's decision
 (`skill://legion-architect`, section 1), and the reviewer reads the plan beside the spec.
@@ -344,7 +345,7 @@ and `data`: a JSON object of the phase-specific fields only. It runs `legion han
 
 A handoff built from the one already on disk (a test handoff that accumulates review rounds can
 pass 128 KiB) can instead be piped from bash, so you never re-emit the whole payload:
-`cd -- "$LEGION_WORKSPACE" && bun -e 'const h = await Bun.file(".legion/<phase>.json").json(); delete h.schemaVersion; delete h.phase; delete h.completed; <your edit to h>; console.log(JSON.stringify(h))' | legion handoff write --phase <phase>`.
+`cd -- "$LEGION_WORKSPACE" && bun -e 'const h = await Bun.file(".legion/<issue>/<phase>.json").json(); delete h.schemaVersion; delete h.phase; delete h.completed; <your edit to h>; console.log(JSON.stringify(h))' | legion handoff write --phase <phase>`.
 The program is single-quoted, so strings in your edit take double quotes. It is `bun` because the
 worker image a pod runs ships `bun` and not `jq`, and a devbox pane has the `bun` Legion builds
 with. With `--data` omitted, `legion handoff write` reads the JSON object from stdin. The CLI adds
@@ -359,14 +360,14 @@ either phase, is an object of six non-empty strings: `criterion` (the acceptance
 Then verify the durable artifact exists:
 
 ```bash
-test -f "$LEGION_WORKSPACE/.legion/<phase>.json"
+test -f "$LEGION_WORKSPACE/.legion/<issue>/<phase>.json"
 ```
 
 Then commit that exact handoff file onto the issue branch:
 
 ```bash
 cd -- "$LEGION_WORKSPACE" && \
-  jj -R "$LEGION_WORKSPACE" split -m "<phase>: record handoff" .legion/<phase>.json
+  jj -R "$LEGION_WORKSPACE" split -m "<phase>: record handoff" .legion/<issue>/<phase>.json
 ```
 
 **Every role pushes its own commits.** After the handoff commit — and, for the tester, the red
@@ -400,8 +401,8 @@ succeed. This is the committed copy the next phase reads after revival. No phase
 `.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/<phase>.json`, commit no handoff, and report with
-`handoff_complete` alone (below).
+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/pr-body.md

@@ -87,13 +87,13 @@ and the tester's proof below are both this proof.
 ## The rules every phase's evidence follows
 
 - **The implementer proves the change before its phase completes, and writes the `E2E (implementer)` line when the pull request opens.**
-  The proof is the one defined above. It goes into `.legion/implement.json` as the required `proof`
+  The proof is the one defined above. It goes into `.legion/<issue>/implement.json` as the required `proof`
   array (`handoff_write` for phase `implement` refuses a payload without one, or with a blank or
   whitespace-only field, and names the field), and into the PR body, because the reviewer and the
   merger verify facts on GitHub and never from a handoff.
 - **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, and records the verdict in
-  `.legion/test.json` as `implementerProof` (`{verdict, how}`).
+  `.legion/<issue>/test.json` as `implementerProof` (`{verdict, how}`).
   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 with
   `verdict: "fail"`, and the daemon returns the issue to the implementer — the agent that developed the change owns
@@ -105,7 +105,7 @@ and the tester's proof below are both this proof.
   until the implementer has executed it against a devN stack; if no surface can reach it, the
   tester names that missing surface as the blocker instead of passing the phase. Environment or
   secret-scrub evidence (e.g. "`LEGION_*`/`DISPATCH_*`/`ENVOY_*` unset") is recorded once, in
-  `.legion/test.json`, and only when the issue's acceptance criteria call for it — never
+  `.legion/<issue>/test.json`, and only when the issue's acceptance criteria call for it — never
   re-pasted into the PR body each round. After a conflict-forced rebase, compute the
   fingerprint (*The unchanged-diff check* in
   `skill://legion-worker/references/conflicts-and-rewrites.md`) at the head your `E2E` line

package/package.json

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