@sjawhar/pi-legion 9.8.0 → 9.8.2

package/dist/legion.js

@@ -15729,7 +15729,7 @@ function onEnvoyRoleRegained(listener) {
 // package.json
 var package_default = {
   name: "@sjawhar/pi-legion",
-  version: "9.8.0",
+  version: "9.8.2",
   license: "Apache-2.0",
   type: "module",
   omp: {
@@ -16515,6 +16515,45 @@ function createControllerSession(deps) {
 // src/handoff-commit.ts
 import { execFile as execFile2 } from "child_process";
 import { promisify as promisify2 } from "util";
+
+// src/git-lock.ts
+import { lstat } from "fs/promises";
+var GIT_LOCK_REPORTS = [
+  /The lockfile at '([^']+)' might need manual deletion/g,
+  /Unable to create '([^']+)': File exists/g
+];
+function age(ms) {
+  const total = Math.round(Math.abs(ms) / 1000);
+  const sign = ms < 0 && total > 0 ? "-" : "";
+  const hours = Math.floor(total / 3600);
+  const minutes = Math.floor(total % 3600 / 60);
+  const seconds = total % 60;
+  if (hours > 0)
+    return `${sign}${hours}h${minutes}m${seconds}s`;
+  if (minutes > 0)
+    return `${sign}${minutes}m${seconds}s`;
+  return `${sign}${seconds}s`;
+}
+async function staleGitLockNote(output, now = Date.now()) {
+  const locks = new Set;
+  for (const report of GIT_LOCK_REPORTS) {
+    for (const match of output.matchAll(report))
+      locks.add(match[1]);
+  }
+  const notes = [];
+  for (const lock of locks) {
+    const written = await lstat(lock).then((info) => info.mtimeMs, () => {
+      return;
+    });
+    if (written === undefined)
+      continue;
+    notes.push(`git lock ${lock} was last written ${age(now - written)} ago and blocks this command. Do not remove it while the issue's pod runs: another role's git, which this container cannot see, may hold it. Replacing the issue's pod removes it. Under the tmux runtime nothing removes it: remove it by hand only once no git or jj process on the host is using the repository.`);
+  }
+  return notes.join(`
+`);
+}
+
+// src/handoff-commit.ts
 var FILE_BACKED = {
   planning: { word: "plan", role: "planner" },
   implementing: { word: "implement", role: "implementer" },
@@ -16531,7 +16570,9 @@ var pathJj = async (args, cwd) => {
     return stdout.trim();
   } catch (error48) {
     const detail = error48 !== null && typeof error48 === "object" && "stderr" in error48 ? String(error48.stderr).trim() : error48 instanceof Error ? error48.message : String(error48);
-    throw new Error(`jj ${args.join(" ")} failed: ${detail}`);
+    const note = await staleGitLockNote(detail);
+    throw new Error(`jj ${args.join(" ")} failed: ${detail}${note === "" ? "" : `
+${note}`}`);
   }
 };
 function requiredVariable(env, name) {

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

@@ -197,7 +197,8 @@ credential can exist without any skill having told you so). When the evidence ge
 reachable, do not have a different running session perform the read on this tree's behalf and
 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 reports a production-check gap (section 6) and leave it
+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
 open until the human resolves it. A workaround substituted for that record only hides the gap
 from the next tree that hits it.
 
@@ -314,9 +315,12 @@ The daemon keeps this order from its fixed table; you start none of its steps:
    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, it opens a `dispatch ask` that starts
-   with the production gap and why it matters, then names the required step, its risk, and
-   outcome-named options. The issue waits for that answer.
+   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.
 
 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

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

@@ -180,7 +180,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, or the deploy/restart step a human will have to perform first>
+**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>
 
 <!-- legion: {"session":"<session-id>","phase":"retro"} -->
 EOF

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

@@ -151,8 +151,12 @@ review posted without a completion leaves the issue in reviewing until you finis
   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 a `dispatch ask` that starts with the
-  production gap and why it matters, then names the required install or restart step, its risk,
-  and outcome-named options. Keep the `Production:` line at `pending <what is missing>`, and
-  complete the check once the human answers. Never record a staging pass as the production check,
-  and never let the architect sign off on a `pending` line.
+  the previous commit, a slot nobody has run) and you cannot perform it yourself, ask the agent or
+  role the deployment instructions name for that deploy: `envoy_publish` to its role topic with the
+  merge commit and `expects_reply: required`, then wait on the production signal the instructions
+  name. Open a `dispatch ask` to a person only when the instructions name nobody for that deploy;
+  it starts with the production gap and why it matters, then names the required install or restart
+  step, its risk, and outcome-named options. Never ask anyone for approval to deploy. Keep the
+  `Production:` line at `pending <what is missing>`, and complete the check once that signal shows
+  the deploy carries the merge (or the person answers, when an ask was the route). Never record a
+  staging pass as the production check, and never let the architect sign off on a `pending` line.

package/package.json

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