@sjawhar/pi-legion 10.7.2 → 10.8.0

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.0",
   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
 });

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

package/package.json

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