@sjawhar/pi-legion 10.22.1 → 10.23.1

package/dist/legion.js

@@ -14480,7 +14480,7 @@ var dispatchToolSpecs = [
       spec: z2.string().describe(`Optional initial primary-document markdown. ${SPEC_WRITING_POINTER}`).optional(),
       labels: z2.array(z2.string({ min: 1, max: 40 }), { max: 20 }).describe("Optional initial labels, at most 20 labels of up to 40 characters.").optional(),
       priority: z2.number({ int: true, min: 0, max: 3 }).describe("Optional coarse priority, a number from 0 to 3: 0 is highest and 3 is lowest.").optional(),
-      assignee: z2.string().describe("Email of the person who answers this issue's asks (someone who has signed in to Dispatch); defaults to your owner when you act for a person, else the parent's assignee, else unassigned.").optional(),
+      assignee: z2.string().describe("Email of the person who answers this issue's asks (someone who has signed in to Dispatch); defaults to your owner when you act for a person, else the parent's assignee, else the project's default assignee when it still names a person who has signed in, else unassigned.").optional(),
       components: componentsArgument(z2).optional(),
       repo: z2.string().describe("The repository the issue targets, owner/name, mapped to the issue's project in Settings; a child inherits its parent's when unset, and an issue with none on its parent chain takes the project's default.").optional()
     })
@@ -14858,7 +14858,7 @@ var dispatchToolSpecs = [
   {
     name: "dispatch_whoami",
     example: {},
-    description: "Who Dispatch takes this session for: {session, owner}. owner is the lowercase email of the person whose personal token you run under (the default assignee of issues you create), or null under the shared token.",
+    description: "Who Dispatch takes this session for: {session, owner}. owner is the lowercase email of the person whose personal token you run under (the first choice of assignee for issues you create), or null under the shared token, in which case a create with no assignee falls back to the parent's assignee and then to the project's default assignee.",
     arguments: () => ({}),
     strict: true
   }
@@ -16937,7 +16937,7 @@ async function bootLegionClaim(host2) {
 // package.json
 var package_default = {
   name: "@sjawhar/pi-legion",
-  version: "10.22.1",
+  version: "10.23.1",
   license: "Apache-2.0",
   type: "module",
   omp: {

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

@@ -77,7 +77,8 @@ exercise a criterion end to end, building that path is a child issue of this tre
   relationship from `--parent`. Keep the returned issue keys in ordered waves; a child is
   inert until released. Do not pass `--assignee`: the default keeps the tree's questions in one
   Inbox — under the shared token a child inherits its parent's assignee (the human who
-  answers the tree's asks); under a personal token it goes to that token's owner, whom
+  answers the tree's asks), and where no parent names one the project's default assignee, which
+  a person sets on the Settings page; under a personal token it goes to that token's owner, whom
   `dispatch whoami` names. Set it only when a human told you a specific person owns that child.
 
 A change across repositories gets one child per repository, each created with

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

@@ -282,8 +282,9 @@ and the person it names, are:
 Each `curl` in this skill and its references reads `DISPATCH_URL` and `DISPATCH_TOKEN_FILE`, which
 `legion controller start` sets only when `controller.yaml` names `dispatch_url`. A read that fails
 or prints no JSON array admits nothing and acts on nothing, and an assignment that does not print
-the issue with its new `assignee` leaves it unassigned (`400 ASSIGNEE_NOT_ALLOWED` names an email
-nobody has signed in to Dispatch with). Name either, with its first line, in your summary.
+the issue with its new `assignee` leaves the issue's assignee as the read showed it
+(`400 ASSIGNEE_NOT_ALLOWED` names an email nobody has signed in to Dispatch with). Name either,
+with its first line, in your summary.
 
 ## Daily report (Go daemon)
 
@@ -307,9 +308,11 @@ EOF
 legion({ op: "set_status", issue: "<report KEY>", status: "icebox" })
 ```
 
-With no person known, leave out `--assignee`. While the issue's `Assignee:` says `unassigned`,
-each report opens with one sentence asking a person to take the issue from its header, since its
-asks reach only the Inbox's `Unassigned` filter.
+With no person known, leave out `--assignee`: the issue then goes to your token's owner, or, under
+the shared token, to the project's default assignee when a person set one on the Settings page, and
+is otherwise unassigned. While the issue's `Assignee:` says `unassigned`, each report opens with
+one sentence asking a person to take the issue from its header, since its asks reach only the
+Inbox's `Unassigned` filter.
 
 Each time you read it, keep it answerable. `Status: done` means someone closed it: Dispatch
 refuses an ask or a message there (`409 ISSUE_CLOSED`) and hides its open asks, so reopen it with
@@ -442,8 +445,10 @@ themselves: an issue reaches Legion only when a person hands it over
    is promised only when the `Design gate policy:` line of your system prompt, which
    whoever launched you writes from the daemon's own configuration, says
    `gates.design: root-issues`. Under `gates.design: off` nobody approves a design, so drop "and
-   its design approval" (and "or its design approval") from the sentence. An unassigned root
-   still runs; its architect's asks reach no default Inbox list, only the `Unassigned` filter.
+   its design approval" (and "or its design approval") from the sentence. Take the line from the
+   read, never from how the issue was created: an issue filed with no assignee still lands on the
+   project's default assignee where a person set one. An unassigned root still runs; its
+   architect's asks reach no default Inbox list, only the `Unassigned` filter.
 
 ## Architect escalation
 

package/dist/skills/legion-controller/references/slack-mentions.md

@@ -81,7 +81,8 @@ For a person's mention, take the first of these that fits.
   Legion take…"); a request for someone to look at something, or one that does not say who, gets
   no label and waits for a person to hand it over. Never label a request outside the scope the
   deployment instructions state. Reply with the new issue's key, its title, the link and assignee
-  the `Created` line names (Dispatch assigns the issue to your token's owner when you name nobody),
+  the `Created` line names (naming nobody, Dispatch assigns the issue to your token's owner, or,
+  under the shared token, to the project's default assignee when a person set one),
   and whether Legion will take it: with the label, triage admits it in its next turn unless it
   should wait.
 - **Something an issue's architect owns.** A question about a tree's design, a change of direction,

package/dist/skills/legion-worker/references/tools.md

@@ -13,8 +13,11 @@ which you have; those need no runner.
 
 - `psql` — the Dispatch browser suite (`bun run e2e`) resets its database for every spec through
   `packages/dispatch/e2e/psql.ts`, which `seed.ts` calls, and the local stack (`bun run
-  dispatch:local`, `packages/dispatch/e2e/local-instance.ts`) refuses to start without it on
-  `PATH` — so a role whose change owes that suite can run it.
+  dispatch:local`, `packages/dispatch/e2e/local-instance.ts`) refuses to start without `go`,
+  `psql`, `flock` and `openssl` on `PATH`, and without `docker` too unless a `DATABASE_URL` is
+  given. The image carries `go`, `flock` and `openssl`, a `DATABASE_URL` stands in for `docker`,
+  and `psql` was the one a role had no way to supply — so a role whose change owes that suite can
+  run it.
 - `redis-cli` — no repository of the project speaks Redis today; it is carried anyway, at about a
   megabyte, because a second image roll costs more than a megabyte.
 - `sqlite3` — a repository's own SQLite fixture or database has no other way to open from a shell,
@@ -88,8 +91,10 @@ variable the runtime sets for you there or under a path on that volume your harn
 itself — but outside the issue's workspace (`$LEGION_WORKSPACE`, under `/legion/workspaces`) and
 the runtime's own directories (`/legion/repos`, `/legion/feed`, `/legion/sessions`); and after
 the command exits nothing else resolves differently. The workspace is excluded because its jj
-working copy tracks every new file, so a root written there is added to the change every role
-shares; the one write into it that is sanctioned is a repository's own dependency install into
+working copy tracks every new file under jj's `snapshot.max-new-file-size` (1 MiB in a role
+container), so a root written there is added to the change every role shares, and a larger new
+file is left untracked, every jj command in the workspace then warning `Refused to snapshot some
+files`. The one write into it that is sanctioned is a repository's own dependency install into
 its ignored directories, below. The variables the runtime sets on the volume, where a tool's own
 cache already goes, are
 `XDG_CACHE_HOME` (`/legion/scratch/cache`), `XDG_DATA_HOME`, `XDG_STATE_HOME`, `TMPDIR`, `GOCACHE`,

package/package.json

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