@sjawhar/pi-legion 10.8.3 → 10.10.0

package/dist/legion.js

@@ -16171,7 +16171,7 @@ function ompCapabilityHost() {
 // package.json
 var package_default = {
   name: "@sjawhar/pi-legion",
-  version: "10.8.3",
+  version: "10.10.0",
   license: "Apache-2.0",
   type: "module",
   omp: {
@@ -16183,7 +16183,7 @@ var package_default = {
     ]
   },
   legion: {
-    daemonApiVersion: 30
+    daemonApiVersion: 32
   },
   repository: {
     type: "git",
@@ -16340,6 +16340,7 @@ var legionPhaseView = exports_external.strictObject({
   rounds: exports_external.number().int().nonnegative()
 });
 var legionPullRequestView = exports_external.strictObject({
+  repo: nonEmptyString,
   number: exports_external.number().int().positive(),
   head: nonEmptyString,
   checksVerdict: nonEmptyString.optional(),
@@ -16380,6 +16381,8 @@ var legionIssue = exports_external.strictObject({
   generation: exports_external.number().int().nonnegative(),
   phase: exports_external.enum(LEGION_PHASES),
   status: nonEmptyString,
+  repo: nonEmptyString.optional(),
+  defaultBranch: nonEmptyString.optional(),
   holdReason: exports_external.literal("escalated").optional(),
   architect: legionClaimView.optional(),
   workers: exports_external.partialRecord(exports_external.enum(LEGION_ROLES), legionPhaseView),
@@ -16418,6 +16421,29 @@ var legionCapabilityState = exports_external.strictObject({
   configLine: nonEmptyString.optional(),
   source: exports_external.enum(["configuration", "boot"]).optional()
 });
+var legionCacheView = exports_external.strictObject({
+  repo: nonEmptyString,
+  sandbox: nonEmptyString,
+  state: exports_external.enum(["starting", "cloning", "ready", "failing", "refused"]),
+  reason: nonEmptyString.optional(),
+  ready: exports_external.boolean(),
+  address: nonEmptyString.optional(),
+  head: nonEmptyString.optional(),
+  lastFetchAt: timestamp.optional(),
+  bytes: exports_external.number().int().positive().optional(),
+  healthError: nonEmptyString.optional(),
+  retainedUntil: timestamp.optional()
+});
+var legionRepositories = exports_external.strictObject({
+  owners: exports_external.array(nonEmptyString),
+  mapped: exports_external.array(exports_external.strictObject({
+    repo: nonEmptyString,
+    default: exports_external.boolean(),
+    cache: legionCacheView.optional()
+  })),
+  refused: exports_external.array(exports_external.strictObject({ repo: nonEmptyString, reason: nonEmptyString })),
+  caches: exports_external.array(legionCacheView)
+});
 var LegionStateResponse = exports_external.strictObject({
   daemon: daemonInfo,
   admission: legionAdmission,
@@ -16427,7 +16453,8 @@ var LegionStateResponse = exports_external.strictObject({
   strandedClaims: exports_external.array(legionStrandedClaim),
   controllerLocator: legionControllerLocator.optional(),
   agentSecretsLogin: legionAgentSecretsLoginView.optional(),
-  capabilities: exports_external.array(legionCapabilityState)
+  capabilities: exports_external.array(legionCapabilityState),
+  repositories: legionRepositories
 });
 var LegionRegisterResponse = exports_external.strictObject({
   claimToken: nonEmptyString,

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

@@ -404,6 +404,7 @@ active phase worker.
 | `child-status` | A child of your tree left the workflow or re-entered it; the notice's reason names the child and its new status. `todo` (a human's move, your `release_children`, or your `rerun_child`) means the child runs again under your tree from planning, and the daemon starts it; you start nothing. `backlog`, `icebox` or `triage` (a human's move, or your `park_child`) means the daemon has suspended the child's workers, and it advances no further until it is set back to `todo`. What the rest of the tree does is your decision. |
 | `child-closed` | Read the child completion and remaining open children. Re-scope open work, park obsolete work with `park_child`, and release an appropriate next wave with `release_children`. When a worker waits on this child for a missing surface (see `phase-finished`), tell it to continue with `envoy_publish` to its role topic. The last child's close is not the end-game (section 3). |
 | `child-release-stalled` | Its `reason` names a child your `release_children` released while Dispatch already showed it `todo`, and that child's parent, whose release has not reached the daemon after three tries. Read the parent's record with the `legion` tool's `read_record` (`issue` the parent); run `release_children` for the child again once the parent is recorded in your tree, and tell the controller if it never is. |
+| `child-not-recorded` | Its `reason` names a child your tree did not record and why: its repository resolves to none (neither it nor an ancestor names one, and the project has no default), or to one not mapped to the project, or to one the daemon leaves out for a missing GitHub App. The daemon said why on the child too. Set the child's repository to one of the project's (`dispatch issue-update --repo owner/name`), then release it again with `release_children`; tell the controller when the repository it needs is not served. |
 | `design-approved` | Its `version` is the approved one. A human approved the root spec document at its current version; the gate is open. Proceed to section 2 — except on a root whose catch-up said `handed_over`: its workers already run their phases, so start nothing; the approval releases any READY the gate refused. One whose `version` is the version a human's own answer to a decision block wrote, after an earlier approval (Dispatch carried that approval to it, section 1), opens nothing new: carry on, and release no wave because of it. |
 | `design-changes-requested` | Its `version` and `reason`. A human asked for changes to the root spec at `version`, for `reason`. Revise the spec as the reason asks and request approval again as section 1 says; stay parked; the gate is closed. |
 | `phase-finished` | The daemon has already moved the issue to its next phase by its fixed table and started that phase's role; you start nothing. Read the committed handoff for the finishing phase; if it shows unresolved gaps, tell the role now working the issue (`envoy_publish` to its role topic). A `planner` notice that names a departure from the spec's design defers to section 1's full condition: when the approved Summary, Acceptance, scope and settled decisions still hold, the plan is the record; otherwise change the root spec and request approval again as section 1 says. A `reviewer` notice whose GitHub review is `CHANGES_REQUESTED` needs nothing from you: the daemon has returned the issue to `implementing` (Dispatch `in_progress`) and started the **implementer**, whose correction goes through the tester and the reviewer again, never straight to retro. A `reviewer` notice with an `APPROVED` review means the daemon has started retro (step 5). An `implementer` notice for `production_check` is its production report: read the record on the pull request and the issue, then run step 7. A `tester` notice with `verdict: "fail"` — its handoff carries `implementerProof.verdict: "rejected"`, or a failure naming the production-like proof — has gone back to the **implementer** by the daemon's table; never supply the proof from another role. A worker that reports no surface reaches the changed path sends that report instead of completing its phase, so the daemon starts nothing more on that issue and the worker stays idle in its session, not suspended: file a child issue in this tree to build the surface (infrastructure, tooling, or a skill), and when that child's `child-closed` arrives, tell the waiting worker to continue with `envoy_publish` to its role topic. That report is never a reason to advance the phase. |

package/package.json

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