@sjawhar/pi-legion 10.7.2 → 10.8.1

package/dist/legion.js

@@ -16171,7 +16171,7 @@ function ompCapabilityHost() {
 // package.json
 var package_default = {
   name: "@sjawhar/pi-legion",
-  version: "10.7.2",
+  version: "10.8.1",
   license: "Apache-2.0",
   type: "module",
   omp: {
@@ -16183,7 +16183,7 @@ var package_default = {
     ]
   },
   legion: {
-    daemonApiVersion: 29
+    daemonApiVersion: 30
   },
   repository: {
     type: "git",
@@ -16461,8 +16461,11 @@ var LegionControllerSecretResponse = exports_external.strictObject({
   designGate: exports_external.enum(["root-issues", "off"])
 });
 var LegionControllerCredentialResponse = exports_external.strictObject({
-  hosts: nonEmptyString,
-  config: nonEmptyString,
+  owners: exports_external.record(nonEmptyString, exports_external.strictObject({
+    hosts: nonEmptyString,
+    config: nonEmptyString
+  })),
+  default: nonEmptyString,
   app: exports_external.enum(["implement", "review"]),
   expiresAt: timestamp
 });
@@ -17125,16 +17128,18 @@ function stepPhaseStall(state, input) {
     case "handoff-complete":
       return { state: "closed" };
     case "inbound-event":
-      return { state: state === "quiet" ? "open" : state };
-    case "settle":
-      if (state !== "open")
+      return { state: state === "quiet" || state === "text-call" ? "open" : state };
+    case "settle": {
+      if (state !== "open" && state !== "text-call")
         return { state };
       if (WAITING_REPLY.test(input.lastAssistantText))
         return { state: "quiet" };
-      return {
-        state: "quiet",
-        followUp: TOOL_CALL_SHAPED.test(input.lastAssistantText) ? TEXT_TOOL_CALL + FOLLOW_UP : FOLLOW_UP
-      };
+      const textCall = TOOL_CALL_SHAPED.test(input.lastAssistantText);
+      if (state === "text-call") {
+        return textCall ? { state: "quiet", followUp: TEXT_TOOL_CALL + FOLLOW_UP } : { state: "quiet" };
+      }
+      return textCall ? { state: "text-call", followUp: TEXT_TOOL_CALL + FOLLOW_UP } : { state: "quiet", followUp: FOLLOW_UP };
+    }
   }
 }
 function inboundKind(message) {
@@ -17157,7 +17162,7 @@ function assistantText(message) {
 `);
 }
 function isPhaseStall(value) {
-  return value === "closed" || value === "open" || value === "quiet";
+  return value === "closed" || value === "open" || value === "text-call" || value === "quiet";
 }
 function restorePhaseStall(branch) {
   for (let index = branch.length - 1;index >= 0; index -= 1) {
@@ -17295,7 +17300,7 @@ function createLegionTool(deps) {
   return {
     name: "legion",
     label: "legion",
-    description: "Perform the workflow operation the Legion daemon assigned this role. The daemon advances phases; this tool cannot spawn workers. " + "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 when your role's " + "instructions require one, `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. " + "The controller's read_state returns the daemon's whole state and set_status moves an issue to todo, backlog or icebox. " + "What a later phase needs goes in your handoff; a question for another live role goes to its role topic with envoy_publish.",
+    description: "Perform the workflow operation the Legion daemon assigned this role. The daemon advances phases; this tool cannot spawn workers. " + "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. " + "The controller's read_state returns the daemon's whole state and set_status moves an issue to todo, backlog or icebox. " + "What a later phase needs goes in your handoff; a question for another live role goes to its role topic with envoy_publish.",
     defaultInactive: true,
     parameters: toolSchema(pi),
     execute: async (_id, parameters, _signal, _onUpdate, context) => {

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

@@ -16,13 +16,15 @@ The Legion extension registers this session with the daemon as the controller an
 `legion-<project>-controller` during session startup. Do not handle a wake unless that startup
 succeeded.
 
-The session's `gh` acts as the review App's bot account (`gh api graphql -f query='{viewer{login}}'` names it) from
-`GH_CONFIG_DIR`, a directory Legion keeps current: in the pod the daemon launches, through the
-controller's role Secret the daemon refreshes every minute; in `legion controller start`'s session,
-through that command's own refresh loop. `gh pr view`, `gh api` and the rest read and write GitHub
-as that App. Against a daemon with no GitHub App, `legion controller start` says so when it starts
-(`[legion] the daemon has no GitHub App to act as; the controller's gh acts as nobody`), and `gh`
-acts as nobody. The controller reads Dispatch and the daemon's state, and applies its controller
+The session's `gh` acts as the review App's bot account (`gh api graphql -f query='{viewer{login}}'`
+names it) from `LEGION_GH_OWNERS_DIR`, one read-only directory per GitHub owner of the project,
+which Legion refreshes every minute (the daemon through the controller pod's role Secret, `legion
+controller start` through its own loop). That `gh` is Legion's wrapper: it reads with the token of
+the owner a command names (`-R owner/repo`, `repos/owner/repo` in `gh api`, a GitHub URL) and with
+the first owner's (`GH_CONFIG_DIR`) otherwise, so name the repository. Against a daemon with no
+GitHub App, `legion controller start` says so when it starts (`[legion] the daemon has no GitHub
+App to act as; the controller's gh acts as nobody`), and `gh` acts as nobody. The controller reads
+Dispatch and the daemon's state, and applies its controller
 capability, through the `legion` tool alone: `op: "read_state"` returns the daemon's whole state
 (`issues.<KEY>.phase`, `issues.<KEY>.holdReason`, `issues.<KEY>.architect`, `admission.cap`,
 `admission.active`, `admission.waiting`, `capabilities[]`, `daemon.project`), and `op: "set_status"`
@@ -58,7 +60,7 @@ The command checks that `LEGION_PROJECT` is the daemon's project, registers this
 daemon, and claims the Envoy role for it; the `legion` tool's controller operations then work in
 this session, each `set_status` minting its grant in-process from the registration's secret. A
 takeover session gets no token file from Legion: `legion controller start` and the pod write
-`GH_CONFIG_DIR`'s token, but a hand-started session's `gh` is whatever its own environment gives it.
+`LEGION_GH_OWNERS_DIR`'s tokens, but a hand-started session's `gh` is what its environment gives it.
 The takeover moves the role and the daemon's recorded session id to this session. Never pass a
 secret as a command argument or copy it into a transcript. The Envoy
 registration heartbeat keeps the role afterwards, so `/legion-claim-controller` is the manual

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

@@ -198,21 +198,21 @@ Your pane's `gh` and `git` already carry your role's GitHub identity; invoke Git
 gh <gh args…>
 ```
 
-How `gh` works in a worker pane. `GH_CONFIG_DIR` names a read-only directory holding gh's own
-`hosts.yml` (your role's GitHub App installation token, user `x-access-token`) and `config.yml`,
-which the daemon rewrites in place from its cached lease so it never expires under you; the `gh`
-on your `PATH` is the ordinary binary and reads it on every call, `git` reads the same file
-through the clone's `credential.helper` (`!gh auth git-credential`), and `GH_TOKEN`,
-`GITHUB_TOKEN` and `GH_HOST` are set empty so nothing outranks it. Never run `gh auth login`,
-`gh auth setup-git`, `gh config set` or `gh alias set`: there is no login state to create, and the
-directory is read-only. One rule nothing enforces: **Legion's issues live on Dispatch, never on
+How `gh` works in a worker pane. `LEGION_GH_OWNERS_DIR` holds one read-only gh directory per
+GitHub owner of the project (`hosts.yml`, an App installation token, and `config.yml`), which the
+daemon rewrites in place so no token expires under you: your issue's owner's, which `GH_CONFIG_DIR`
+names, holds your role's App token; every other owner's the same App's, read-only. Your `gh` picks
+the directory of the owner a command names (`-R owner/repo`, `repos/owner/repo` in `gh api`, a
+GitHub URL), your issue's owner's otherwise, so name the repository whenever it is not your
+issue's; `git` picks by the remote URL's owner (`!legion git-credential`). `GH_TOKEN`,
+`GITHUB_TOKEN` and `GH_HOST` are empty so nothing outranks the files. Never run `gh auth login`,
+`gh auth switch`, `gh auth setup-git`, `gh config set` or `gh alias set`: there is no login state
+to create. One rule nothing enforces: **Legion's issues live on Dispatch, never on
 GitHub issues** — no `gh issue` write and no non-GET `gh api` call to an `/issues` path
 (pull-request conversation comments live on that path too; edit them with `gh pr comment`); use
 `dispatch message` or `dispatch comment` on your `LEGION_ISSUE`. The `legion` tool's own daemon
 calls carry a credential of their own, minted in-process; `gh` and `git` never see it, and you
-never `cat`, `echo`, copy, or `export` a token. A `task` subagent, an `eval` subprocess, or a
-background job in your pane inherits the same `GH_CONFIG_DIR` and so the same credential, for as
-long as it runs.
+never `cat`, `echo`, copy, or `export` a token; a `task` subagent or background job inherits them.
 
 **Other credentials your pod may already carry.** Before reporting that a read is unreachable,
 check for them rather than assuming none exist: `AGENT_SECRETS_URL` and `AGENT_SECRETS_KEY_DIR`
@@ -265,8 +265,8 @@ The implementer opens the pull request. After its implementation commit and veri
 pushes the issue branch under this exact name with the one push procedure every role uses
 (*Every role pushes its own commits*, below).
 
-The shared clone's `credential.helper` is `!gh auth git-credential`, so `jj git push`
-authenticates as your role's App from the same file your `gh` reads. Never handle a token.
+`jj git push` authenticates as your role's App through the clone's `!legion git-credential`, from
+the file your `gh` reads for your issue's repository. Never handle a token.
 
 Then open the pull request with `gh pr create`. The PR body **must** contain the
 line `Dispatch: <KEY>` — the daemon's fallback link from a PR to its Dispatch issue when the
@@ -328,7 +328,7 @@ or `review`), with the ordinary `write` tool: a JSON object with `schemaVersion:
 phase's own fields exactly as your role prompt spells them — the planner's `requiredSkills`,
 `gapAnalysis`, `planReview` and `specDepartures` records; the implementer's `proof` array; the
 tester's `implementerProof`, `failures` and, whenever it reports no failure, its own `proof`; the
-reviewer's `verdict`, counts and `keyFindings`. Nothing stamps the first four for you. Each `proof`
+reviewer's `decision`, counts and `keyFindings`. Nothing stamps the first four for you. Each `proof`
 entry, in either phase, is an object of six non-empty strings: `criterion` (the acceptance line it
 proves), `surface`, `command`, `observed`, `headSha` (the commit it ran at) and `negativeControl`.
 A handoff built from the one already on disk (a test handoff that accumulates review rounds) is
@@ -342,10 +342,10 @@ cd -- "$LEGION_WORKSPACE" && \
 ```
 
 Then push (below) and report completion: call the `legion` tool with `op: "handoff_complete"` and
-`summary` (two sentences for the architect; the tester adds `verdict: "pass"` or `"fail"`, the
-merger `ready: true`). **Push before you complete is a hard rule.** `handoff_complete` finds, with
-your pane's jj, the newest commit on the issue branch that carries `.legion/<KEY>/<phase>.json`
-and reports it to the daemon, and refuses — posting nothing — while:
+`summary` (two sentences for the architect; the tester, and no other role, adds `verdict: "pass"`
+or `"fail"`; the merger `ready: true`). **Push before you complete is a hard rule.**
+`handoff_complete` finds, with your pane's jj, the newest commit on the issue branch that carries
+`.legion/<KEY>/<phase>.json` and reports it to the daemon, and refuses — posting nothing — while:
 
 - the file has a change still in the working copy: commit it, then complete again;
 - the file is missing from the workspace: write it, then commit and push it;
@@ -429,8 +429,9 @@ Report completion to the architect: call the `legion` tool with `op: "handoff_co
 (`handoff_complete`; `read_record`, your issue's record, which is what "re-read your issue
 record" means; and `request_backward_move`), and nothing of yours runs `legion` from bash. The
 tool call is what the extension's phase stall records, and a turn that ends with the phase still
-open gets one reminder; do not complete again on that reminder when your first completion was
-accepted — it stands, and a second is refused because the issue has already left your phase.
+open gets one reminder (two when the first is answered with the tool call written as text again);
+do not complete again on a reminder when your first completion was accepted — it stands, and a
+second is refused because the issue has already left your phase.
 
 This publishes your phase's completion to the architect's role and clears the daemon's
 record of this issue's active phase. Do not add pipeline labels, run a controller loop, or

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sjawhar/pi-legion",
-  "version": "10.7.2",
+  "version": "10.8.1",
   "license": "Apache-2.0",
   "type": "module",
   "omp": {
@@ -12,7 +12,7 @@
     ]
   },
   "legion": {
-    "daemonApiVersion": 29
+    "daemonApiVersion": 30
   },
   "repository": {
     "type": "git",