@sjawhar/pi-legion-envoy 1.24.2 → 1.24.3

package/dist/legion.js

@@ -30852,7 +30852,7 @@ function createLegionTool(deps) {
   return {
     name: "legion",
     label: "legion",
-    description: "Perform a Legion lifecycle write through the Legion daemon. " + "register_gate records the root spec document a human must approve: `artifactId` is the " + "document id (a UUID) and `version` the version number, both copied from the `artifact` and " + "`version` fields of dispatch_request_approval's result \u2014 never the slug or file name you " + "passed to that tool. " + `spawn_worker's response "status" means: "spawned" \u2014 a fresh pane just opened and is ` + 'running now; "resumed" \u2014 an existing worker was prompted directly over its live socket, ' + "or (if its boot has not confirmed yet) its task was recorded to deliver once that boot " + 'completes; "queued" \u2014 the running-worker cap is full, the task was recorded and this ' + 'role will start on its own once a slot frees. Never re-spawn a role after "resumed" or ' + '"queued" \u2014 wait for the worker-started notification instead.',
+    description: "Perform a Legion lifecycle write through the Legion daemon. " + "register_gate records the root spec document a human must approve: `artifactId` is the " + "document id (a UUID) and `version` the version number, both copied from the `artifact` and " + "`version` fields of dispatch_request_approval's result \u2014 never the slug or file name you " + "passed to that tool. " + `spawn_worker's response "status" means: "spawned" \u2014 a fresh pane just opened and is ` + 'running now; "resumed" \u2014 an existing worker was prompted directly over its live socket ' + "and its turn started, or (if its boot has not confirmed yet) its task was recorded to " + 'deliver once that boot completes; "queued" \u2014 the task was recorded and this role will ' + "start on its own: either the running-worker cap is full, or the live worker acknowledged " + "the task without starting a turn and the daemon is retrying it. Never re-spawn a role " + 'after "resumed" or "queued" \u2014 wait for the worker-started notification instead.',
     defaultInactive: true,
     parameters: legionToolSchema(pi),
     execute: async (_id, parameters, _signal, _onUpdate, context) => {
@@ -30961,25 +30961,6 @@ function createLegionTool(deps) {
   };
 }
 
-// src/legion/workspace-helpers.ts
-async function setJjIdentity(cwd, gitName, gitEmail) {
-  for (const [key, value] of [
-    ["user.name", gitName],
-    ["user.email", gitEmail]
-  ]) {
-    const child = Bun.spawn(["jj", "config", "set", "--repo", key, JSON.stringify(value)], {
-      cwd,
-      stdout: "ignore",
-      stderr: "pipe"
-    });
-    const exitCode = await child.exited;
-    if (exitCode === 0)
-      continue;
-    const stderr = await new Response(child.stderr).text();
-    throw new Error(`jj config set ${key} failed: ${stderr.trim()}`);
-  }
-}
-
 // extensions/envoy.ts
 import { existsSync } from "fs";
 import { dirname, resolve } from "path";
@@ -35047,7 +35028,6 @@ function legionExtension(pi) {
     if (bootstrap)
       return bootstrap;
     const bootToken = requiredSecret(process.env, "LEGION_BOOT_TOKEN");
-    const workspace = requiredEnvironment(process.env, "LEGION_WORKSPACE");
     bootstrap = (async () => {
       const { sessionFile, agentId } = await persistedTranscript(context);
       const started = await (async () => {
@@ -35071,7 +35051,6 @@ function legionExtension(pi) {
       })();
       try {
         await exportJjSessionAttribution(sessionFile, requiredEnvironment(process.env, "LEGION_STATE_DIR"));
-        await setJjIdentity(workspace, started.gitName, started.gitEmail);
         capability = {
           kind: "phase-worker",
           sessionID,

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

@@ -290,7 +290,7 @@ corresponding lifecycle procedure.
 | `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. |
-| `worker-queued` | Payload `{type:"worker-queued", issue, role}`. The deployment's worker cap is full; this role's spawn is queued. Do not respawn or retry — wait for `worker-started`. |
+| `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. |

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

@@ -149,9 +149,22 @@ Commit attribution is automatic: the extension exports a `JJ_CONFIG` overlay whe
 session starts, so every jj commit you make carries an `Omp-Session: <this-session-id>`
 trailer with no action from you. Do not add attribution trailers by hand.
 
-The jj configuration already supplies your phase's plus-addressed author and committer
-identity. Do not override Git identity configuration. Your session receives the credential
-capability it needs; invoke GitHub through the credential helper:
+Your pane's environment already supplies your phase's author and committer identity
+(`JJ_USER`/`JJ_EMAIL` and the Git author/committer variables, set by the daemon when it opened
+the pane; the daemon also re-authors the workspace's working copy for your role at each
+assignment, since `jj split`/`jj describe` keep its author). Never set or override
+`user.name`/`user.email` in any jj or Git scope — not `jj config set`, not `--config`, not
+`git config`: `--config` outranks the pane environment and would put the wrong App back on your
+commits, and the repository-scoped jj config is one file shared by every issue workspace of the
+clone. Before a push, check
+`jj -R "$LEGION_WORKSPACE" log -r 'main@origin..@' -T 'author.email() ++ " | " ++ committer.email() ++ " " ++ description.first_line() ++ "\n"'`
+shows your role's App in both columns **on every commit you made** — not on the whole list:
+earlier phases' commits are legitimately authored by their own role's App, and a conflict-forced
+rebase legitimately sets the committer of every rebased commit, other roles' included, to the
+rebaser. A wrong identity on your own commit is a pane-environment problem to report to the
+architect, not something to pin (`docs/solutions/legion/shared-main-repo-hazards-for-concurrent-issue-workspaces.md`,
+Hazard 1). Your session receives the credential capability it needs; invoke GitHub through the
+credential helper:
 
 ```bash
 legion gh -- <gh args…>

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sjawhar/pi-legion-envoy",
-  "version": "1.24.2",
+  "version": "1.24.3",
   "type": "module",
   "omp": {
     "extensions": [