pi-legion 3.0.3 → 4.0.0

package/docs/contracts/status-panel-v1.md

@@ -0,0 +1,174 @@
+# Status panel v1 — `/legion` 大盘的 status 面板 + status 字段缺口补齐
+
+> 冻结契约。合并权人裁定，worker 不得自行解释矛盾，遇矛盾向父会话报告。
+> 基线：`3071dee` (3.1.0)，`npm run typecheck` = 0、`npm test` = 0。
+
+## 0. 目标
+
+1. 在 `/legion` 全屏大盘（`src/tui/viz/`）新增 `status` 面板，把目前只存在于聊天文本里的 `/legion status` 数据搬到大盘上。
+2. 补齐 `/legion status` 的已知缺口：`supervisor=unknown`、`owner` 缺失、无内存、无 context tokens、`usage` 未格式化。
+
+## 1. 不可违反的既有约束
+
+| 约束 | 锚点 |
+| --- | --- |
+| **禁止给 `legion.db` 加列、禁止升 `LEGION_DB_USER_VERSION`** | `docs/spawn-mode-visibility-v1.md:143`、`test/unit/legion-schema-sentinel.test.ts` |
+| 运行时零外部依赖（Node stdlib only） | `CONTRIBUTING.md:215` |
+| 每行 `visibleWidth === w`（严格相等，非 ≤） | `test/unit/legion-viz.test.ts:417-434,628,911,1464,1630` |
+| 平台降级不得抛错：非 Linux 返回空值 | 先例 `src/supervisor/proc-tree.ts:44` |
+| `spawnMode` 缺失必须渲染 `unknown`，**绝不猜 `rpc`** | `src/extension/runtime.ts:84-89`、`test/unit/runtime.test.ts:1490-1501` |
+
+## 2. 设计决策
+
+### D1 — 新增第 5 个 pane，但 portrait 不渲染
+
+- `wide` / `stacked` 新增 `status` rect；`portrait` 的 `layout.status` 返回**零面积 rect** `{x,y,w:0,h:0}`。
+- 理由：portrait `46×24` 实测 `galaxy=5 chart=10 timing=3 log=3`，`bodyH=21`，4 个 pane 最小高之和 `3+10+3+3=19`，仅剩 2 行 —— 物理上装不下第 5 个 pane（最小 3 行）。`timing`/`log` 在 `h=3` 时内框 `h=1`，`drawTiming`/`drawLog` 本就提前 return，**portrait 极矮时这两个 pane 已是空壳**。
+- `frame()` 在 `h<3` 已早退且不画任何东西，所以零面积 rect 天然安全，无需特判绘制。
+- **Tab 必须跳过零面积 pane**：新增 `availablePanes(layout)`，返回 `h>0` 的 pane 列表；`handleViewKey` 增加可选第 4 参 `panes`，**缺省 = 全部 pane**（保证既有测试不变）。
+- 被否决：(a) 全布局都加 → portrait 溢出 footer；(b) status 复用 timing 做可切换视图 → 隐藏态发现性差，且 `drawTiming` 宽度算术已很紧；(c) 把 status 塞进 log → 语义冲突。
+
+### D2 — inprocess 内存口径：只显示 host rss，禁止按子 agent 摊派
+
+- `rpc` 子 agent：有独立 pid → 显示 per-child `rss`。
+- `inprocess` 子 agent：**没有独立进程**（`inprocess-supervisor.ts:751-754` 只返回 name+sessionFile）。面板与 status 文本中 **inprocess 行的 rss 列留空/`—`**，另起一行显示 `host rss <N> MB · shared by N inprocess`。
+- **严禁**按 token 比例把 host rss 摊到子 agent 头上 —— 那是编造数据，用户会拿它做决策。
+- 理由：诚实性优先于信息密度。
+
+### D3 — pid 穿透（不加 DB 列）
+
+链路：`ChildHandle.pid` → `Handle.pid` → `TrackedJobInput.pid` → `StatusEntry.pid` → `VizNode.pid`。
+
+- `src/shared/types.ts:482` `Handle` **当前无 pid**，必须加 `pid?: number`。
+- `src/runs/orchestrator.ts:800` 附近（`spawnMode: mode` 同处）写入 `...(result.pid ? { pid: result.pid } : {})`。
+- `TrackedJobInput`（`src/extension/runtime.ts:73-107`）加 `pid?: number`；`index.ts:2675` 的 `runtime.track({...})` 补传。
+- pid 不落盘是既有事实，**不新增持久化**——viz 只在当前宿主进程可见，跨进程显示为未知。
+
+### D4 — context tokens：扩 `ParsedSession`，不做百分比
+
+- `accumulateUsage`（`src/shared/session.ts:124-136`）在累加的同时，把**最后一条 assistant message** 的 `input + cacheRead + cacheWrite` 记到 `ParsedSession.lastContextTokens`。
+- `LiveProgress`（`src/shared/progress.ts:9-28`）加 `contextTokens?: number`；`progressFromSession` 投影；`mergeProgress` 用「later wins」语义。
+- **不显示百分比**：`contextWindow` 在 JSONL 中不存在，全仓零命中。要百分比就得引模型注册表，超出本契约范围。显示绝对值 `ctx 24.3K tok`。
+- 被否决：直读 session JSONL 最后一条 assistant usage → 与既有 `parseSessionFile` 重复解析，且绕过 `accumulateUsage` 单一事实源。
+
+### D5 — 修 `childStatus` 漏传（现存 bug）
+
+`index.ts:926-946` 的 `childStatus` 回调补 `spawnMode` 与 `owner`：
+
+- `spawnMode: child.spawnMode`（run.json 已有值，`src/shared/types.ts:365-373`）
+- `owner:` 用既有 `runOwnerStatus(runDir)`（`src/runs/owner.ts:60` 返回 `live|dead|unknown`）
+- 正确范例：`index.ts:1417-1428`、`index.ts:2887-2899`（这两处**已传** spawnMode）。
+- 这是纯 bug fix，与新增面板解耦，可独立验收。
+
+### D6 — 所有新字段一律 optional
+
+`VizNode` 新增字段必须 optional，否则 3 处字面量构造编译失败：`test/unit/legion-viz.test.ts:18-20`、`test/unit/legion-stop.test.ts:92`、`src/tui/viz/panels.ts:103-105`。
+
+投影沿用仓库惯例 `...(cond ? {k:v} : {})`（`model.ts:72-79`），**不写 `undefined` 字面量**。
+
+### D7 — status 面板字段集与宽度降级档位
+
+表头 1 行 + 可选页脚 1 行；列按**绝对列数**分层（沿用 `drawTiming` 惯例）：
+
+| 内框宽 | 列 |
+| --- | --- |
+| `w >= 72` | `name · role · state · supervisor · ctx · rss · turns` |
+| `w >= 52` | `name · state · supervisor · ctx` |
+| `w >= 36` | `name · state · ctx` |
+| `w >= 20` | `name · state` |
+| `w < 20` | 不画（return） |
+
+- 守卫：`if (r.w < 20 || r.h < 2) return;`（`drawTiming` 用 `w<8,h<2`；本面板列多，下限提到 20）
+- `footerH = rows.length > 0 && r.h >= 4 ? 1 : 0`；`rowsAvail = max(0, r.h - 1 - footerH)`
+- **所有 `cv.text` 必须带 `maxX` 或先 `ellipsize`** —— 禁止复制 `drawLog`（`panels.ts:530-532`）的越界 bug。
+- `rss` 列：rpc → `152M`；inprocess → `—`；未知 → `—`。**不得写大写单位**（`legion-viz.test.ts:927` 的字符类只含小写 a-z），用 `M` 会红 → 改用 `m`；或把该断言一并更新（见 §5）。
+
+### D8 — Tab 顺序：status 追加到末尾
+
+`PANES = ["galaxy","chart","timing","log","status"]`（`src/tui/viz/view.ts:36`）。
+
+- 追加在末尾使 `legion-viz.test.ts:442`（chart）、`:444`（timing）、`:446`（log）**全部继续通过**，只需新增一条 status 断言。
+- 被否决：插入 timing 与 log 之间 → 直接打红 3 条既有断言，且 `:1588-1593` 再红一条。
+
+## 3. 文件所有权（严格边界，禁止越界）
+
+### Worker A — 数据管道 + status 文本（先做）
+
+| 文件 | 性质 |
+| --- | --- |
+| `src/supervisor/proc-memory.ts` | **新增**：`readProcRss(pid)`，读 `/proc/<pid>/status` 的 `VmRSS`/`VmHWM`，非 Linux / 读失败 / pid 已退 → `undefined`，绝不抛 |
+| `src/shared/types.ts` | 改：`Handle.pid?`、`ParsedSession.lastContextTokens?` |
+| `src/shared/session.ts` | 改：`accumulateUsage` 记录最后一条 assistant 的 context tokens |
+| `src/shared/progress.ts` | 改：`LiveProgress.contextTokens?` + `progressFromSession` + `mergeProgress` |
+| `src/runs/orchestrator.ts` | 改：`Handle` 写入 `pid` |
+| `src/extension/runtime.ts` | 改：`TrackedJobInput.pid?`、`statusEntryFromJob`/`statusEntryFromNode` 写 `spawnMode/pid/contextTokens/rss`、`renderLiveChildStatus` 增 memory/ctx 行 |
+| `src/tui/status.ts` | 改：`StatusEntry` 加 `spawnMode?/pid?/contextTokens?/rss?`（**不动 `formatWidgetLines`**） |
+| `index.ts` | 改：`childStatus` 补 `spawnMode`/`owner`；`runtime.track` 补 `pid` |
+| `test/unit/proc-memory.test.ts` | **新增** |
+| `test/unit/legion-status.test.ts` | 改：新增字段断言（`:110-147`、`:192-254` 现有断言**不得放宽**，只追加） |
+| `test/unit/runtime.test.ts` | 改：`renderLiveChildStatus` 新行断言 |
+
+**Worker A 严禁触碰**：`src/tui/viz/**`、`src/tui/tree-view.ts`、`src/tui/live-overlay.ts`、`docs/**`。
+
+### Worker B — viz 面板（等 A 合入后）
+
+| 文件 | 性质 |
+| --- | --- |
+| `src/tui/viz/layout.ts` | 改：`LegionLayout.status: Rect` + 三批分支 + `availablePanes` |
+| `src/tui/viz/panels.ts` | 改：`Pane` 联合加 `"status"`；**新增 `drawStatus`**；**不修改** 既有 4 个 draw* |
+| `src/tui/viz/view.ts` | 改：`PANES` 末尾追加；`frame`+`drawStatus` 调用；`clampList` 支持 `"status"`；`handleViewKey` 第 4 参 `panes` |
+| `src/tui/viz/model.ts` | 改：`VizNode` 加 optional 字段 + `nodesFromEntries` 投影 |
+| `test/unit/legion-viz.test.ts` | 改：新增 status 面板断言（§5 清单） |
+
+**Worker B 严禁触碰**：`src/extension/**`、`src/shared/**`、`src/runs/**`、`src/tui/status.ts`、`index.ts`。
+
+## 4. 分阶段与验收
+
+| 阶段 | 内容 | 验收 |
+| --- | --- | --- |
+| P1 | Worker A 全量 | `npm run typecheck` && `npm test` |
+| P2 | Worker B 全量（依赖 P1 已合入） | `npm run typecheck` && `npm test` |
+
+每个阶段必须 **typecheck 0 / test 0**。首个非零退出即判 rejected。
+
+## 5. 必须同步更新的测试（逐条）
+
+| 测试 | 原因 | 期望 |
+| --- | --- | --- |
+| `legion-viz.test.ts:417-434` | 新增 status 面板标题 | 追加 `plain.some(l => l.includes("status"))`；**不得放宽** `visibleWidth === w` |
+| `legion-viz.test.ts:437-459` | Tab 顺序末尾新增 | 在 `:446` 后追加 `handleViewKey("\t")` → `assert.equal(state.focus, "status")`；既有 3 条保留 |
+| `legion-viz.test.ts:160-183` | layout 新字段 | `for (const r of [galaxy,chart,timing,log,status])` 加入界内断言；**portrait 跳过 status**（零面积） |
+| `legion-viz.test.ts:872-901` | 几何锁 | portrait 段保持四段相接断言不变；wide 段新增「右列三段相接」断言 |
+| `legion-viz.test.ts:927` | header 字符类 | 若 header 未变则不动；**status 面板内容不写入 header** |
+| `legion-viz.test.ts` 新增块 | `drawStatus` 单测 | 覆盖 D7 四档宽度 + `w<20` 退化 + inprocess `rss` 为 `—` |
+| `legion-status.test.ts:110-147` | 新增 memory/ctx 行 | 既有首行/`alive`/`execution snapshot` 断言保留，追加新行断言 |
+| `legion-status.test.ts:192-254` | `formatTree` 未变 | **不动**（`formatTree` 不在本契约改动范围） |
+
+## 6. 风险与裁决
+
+| 风险 | 裁决 |
+| --- | --- |
+| `drawLog` 内框 `w<=14` 写出 rect 右边界（`panels.ts:530-532`） | **顺手修**：给该 `cv.text` 补 `maxX: r.x + r.w`。属 P2 范围，单独 commit，附回归断言。理由：Worker B 正在改同一文件，且新面板极易复制此模式。**勘误**：`Canvas.text` 的 `maxX` 是**排他上界**（`canvas.ts:39` `if (col >= limit) break`），而 `frame()` 返回的是内框、其右边框列即 `r.x + r.w`，所以「保住最后一个合法内格且不碰边框」的值是 `r.x + r.w`（与 `frame()` / `drawStatus` 一致）。本文早期写的 `r.x + r.w - 1` 会少吃一格，已按 #251 评审改为 `r.x + r.w`。 |
+| view 层 `layout.timing.h - 3` 与 draw 层 `innerH-1-footerH` off-by-one（`view.ts:90`） | **本契约不修**。改动会影响 `timingVisible` 语义与既有断言，独立提 issue。新面板**必须**用精确公式，不照抄 `-3`。 |
+| portrait 零面积 status 被 Tab 跳过 | 由 `availablePanes` 保证；`handleViewKey` 缺省参数保证既有测试不变 |
+| pid 跨进程不可见 | 接受。viz 显示 `—`，不猜。 |
+| `readProcRss` 的 pid 复用 race | **实现为「不打印」**：`!alive` 时直接不读 `/proc`，返回 `undefined`。v1 无 last-known 缓存设施（`memoryLine` 无状态、`TrackedJob` 无 rss 字段），新增缓存需额外的失效规则，比不打印更易说谎。`(last)` 分支**明确不在 v1 范围**。读取必须 try/catch。 |
+
+## 7. 契约修订点
+
+- 本文件即新增契约，无需改动 `docs/legion-v2-contract.md` §10.1（三层 UI 定义不变，status 面板属第 2 层内部枚举新增）。
+- `docs/tui-viewer-contract.md:202` 的禁改清单**不包含** `src/tui/viz/**`，Worker B 无需先修订该文档。
+- `README.md` 的「Three-layer visualization」段落可在 P2 后追加一句 status 面板说明（可选，非门禁）。
+
+## 8. 契约勘误（P1 实施中记录）
+
+1. **§5 必改测试表漏列 `test/unit/progress.test.ts`**。D4 的 `progressFromSession` 投影让该文件两处完整对象 `deepEqual` 机械性必红。实际处理：加 `contextTokens: 10` 两行，属**加强断言**（新字段被钉死），零删除。
+2. **`runtime.test.ts` 既有 D2 测试与 §6 冲突**。该测试原本用 `alive: false` + pid 断言「有 memory 行」，与 pid 复用防护直接矛盾。实际处理：把前置条件改为 `alive: true`，断言文本/正则/非 Linux 分支全部原样保留，强度不变。
+3. **`(last)` 展示未实现**（见 §6 修订）。
+
+## 9. 修订历史
+
+| 日期 | 版本 | 说明 |
+| --- | --- | --- |
+| 2026-10-19 | v1 | 初版。父会话直接裁定（planner 卡死于「声称写文档但从不落盘」，已止损）。 |
+| 2026-10-19 | v1.1 | P1 交付后补：pid 复用裁决改为「不打印」；记录 3 条勘误。 |

package/docs/inprocess-supervisor.md

@@ -11,7 +11,7 @@ with `INVALID_PARAMS` — the fallback only covers the implicit default.
 | Mode | Good for | Avoid when |
 |---|---|---|
 | `inprocess` (default; auto-fallback below) | Short, trusted fan-out; lower spawn latency; simpler approval / UI fan-in | Need OS worktree, separate credentials, crash isolation |
-| `rpc` (fallback: worktree / non-pi kind; or explicit `spawnMode: rpc`) | Long runs, untrusted tasks, need crash / env / cwd isolation, **worktree** | Cold-start cost dominates |
+| `rpc` (fallback: worktree; or explicit `spawnMode: rpc`) | Long runs, untrusted tasks, need crash / env / cwd isolation, **worktree** | Cold-start cost dominates |
 
 There is no single global default in the config sense: omitting `spawnMode`
 means "inprocess if this role can run in-process, otherwise rpc". Roles that
@@ -62,10 +62,46 @@ worktree: false        # explicit inprocess + worktree: true is still refused
 | Concurrent alive | `legion.maxActiveNodes` | `inprocess.maxActive` (default **30**; **8** when the block is present without `maxActive`) |
 | Children / node | `legion.maxChildrenPerNode` | `inprocess.maxChildrenPerNode` (default **8**) |
 | Wait timeout | agent `timeoutMs` / wait default | `inprocess.waitTimeoutMs` (no default) |
+| Queue depth | `inprocess.maxQueuedLaunches` (shared by both paths) | `inprocess.maxQueuedLaunches` (default **32**) |
+| Queue wait | `inprocess.launchQueueTimeoutMs` (shared by both paths) | `inprocess.launchQueueTimeoutMs` (default **900000** = 15 min) |
 
 Never fall back across columns: in-process limits are read from
 `subagents.inprocess.*` only, never from the `legion.*` keys.
 
+### Launch admission queue (#266)
+
+A launch that hits a **queueable** gate waits in an in-memory queue instead of
+throwing `BUDGET_EXCEEDED`, and is admitted automatically when a slot frees. The
+caller gets `▶ scout-7 (scout) supervisor=inprocess queued(3)` back immediately
+and treats the work as dispatched.
+
+| Gate | Queued? | Why |
+|---|---|---|
+| `inprocess.maxChildrenPerNode` | ✅ | pure concurrency: the slot always frees |
+| `inprocess.maxActive` | ✅ | same |
+| `legion.maxChildrenPerNode` (`max_children_per_node`) | ✅ | same, RPC path |
+| `legion.maxActiveNodes` (`max_active_nodes`) | ✅ | same, RPC path |
+| `maxDepth` / `maxSpawnsPerSession` / ledger `max_depth` | ❌ | waiting cannot satisfy them; a queue would disguise a permanent failure as a 15-minute delay |
+| `maxChildrenPerNode: 0` | ❌ | 0 means "no children at all" — impossible to satisfy |
+| `parent_not_found`, memory gate, `NAME_TAKEN`, unknown/disabled role, `inprocess`+`worktree`, model scope | ❌ | not a concurrency gate |
+
+The two queue bounds are **shared** by both backends on purpose: one scheduler,
+not one per spawn mode. Overflow is an immediate hard refusal
+(`launch queue overflow (32/32)`), a timeout is reported as
+`launch queue timed out after Ns ('<name>')`, and **neither ever creates a
+ledger row, a run directory, a worktree or a session file** — a queued launch has
+reserved nothing yet.
+
+Admission is event-driven (a child reaching `retired`/`exited` frees its slot)
+with one `unref`'d fallback recheck, because the ledger can also be freed by
+another process. An `idle` child (turn ended, not yet collected) **still holds
+its slot**, exactly as before.
+
+Known limit: the queue is in memory, so a process restart drops it. The leftover
+`queued` records in `run.json` are inert — `collect`/`steer` on one says
+`never started: the launch queue was lost …` instead of `unknown child`, and
+`stop` cleans it up.
+
 Omitting an `inprocess.*` key is **not** unlimited. The documented defaults
 mirror `legion.*`, so a deployment with no `subagents.inprocess` block at all
 still runs under `maxDepth: 4` / `maxChildrenPerNode: 8` / `maxActive: 30`.
@@ -187,9 +223,6 @@ a decode rate.
 
 ## Refusals
 
-- `kind !== "pi"` → `INVALID_PARAMS` regardless of `spawnMode`: only `pi` roles
-  are supported, so a non-`pi` role is refused up front and never reaches the
-  worktree fallback
 - `worktree: true` + explicit `inprocess` → `INVALID_PARAMS` (an omitted
   `spawnMode` falls back to `rpc` instead)
 - A non-centurion requesting `worktree: true` is **not** a refusal: it is

package/docs/legion-v2-contract.md

@@ -101,7 +101,9 @@ interface LegionSupervisor {
 | `pane close` 杀进程 | stdin close 优雅退出；超时 SIGTERM；仍超时 SIGKILL；后代进程按进程组清场（REV-16） |
 | `run.json` herdr 字段 | 载体改为 `{supervisor: "rpc", node_id}`，`paneId/tabId` 删除 |
 
-### 3.3 判定链不变：成败仍以 session jsonl 为唯一权威（F26–F33）。collect 复用 `waitForQuiet` + `parseSessionFile` + `deriveOutcome`，收割后顺手写 `node_settled` 事件 + 更新 nodes 行。
+### 3.3 判定链不变：成败仍以 session jsonl 为唯一权威（F26–F33）。collect 复用 `parseSessionFile` + `deriveOutcome`（+ `waitSettled` 的 settle 事件）收割，收割后顺手写 `node_settled` 事件 + 更新 nodes 行。
+
+> 修订（#232）：原文此处写作「collect 复用 `waitForQuiet` + ...」。`waitForQuiet`（2.5s 安静窗口 stat 轮询）已由 #232 / PR #244 删除——`waitSettled` 本身就是事件驱动的，`settled` 之后再对 append-only 文件轮询 size 得不到任何新信息。判定链的输入与权威性未变。
 
 ### 3.4 每节点身份：`ownerToken` 语义改为「树根 session id + node id」；多会话同 repo 隔离靠 node id 命名空间（替代 `parentPaneId` 过滤）。
 
@@ -116,6 +118,7 @@ interface LegionSupervisor {
 - 根会话**首次 launch 时**创建：`<rootRunDir>/legion.db`（`.pi-subagents/runs/<runId>/` 下）
 - 绝对路径经 env **`PI_LEGION_DB`** 随 `lineageEnv()` 逐层下发——任何深度的 supervisor 直连同一个库，不经父节点转发（RPC spawn 的 env 由宿主直接控制，F35 类丢失坑不复存在）
 - 连接约定：每 supervisor 进程一连接；`PRAGMA journal_mode=WAL; PRAGMA busy_timeout=5000;`；写入均为短事务 prepared statement
+  - **WAL 是前置条件，不是请求**：`PRAGMA journal_mode=WAL` 是**查询**，返回值才是实际生效的 journal mode，它可能在**不报错**的情况下降级（网络/FUSE 挂载无 shared-memory 支持、只读介质、争用锁）。`openLegionDb()` 因此**读取返回值并在其为文件库时校验**：非 `wal` 直接抛错，在启动期炸掉，而不是带着「已开 WAL」的假设继续跑、把问题拖成后发性数据事故。`:memory:` 是唯一的刻意豁免——SQLite 对内存库不实现 WAL、永远报 `memory`，而该库本来就不跨进程存活（由 `PRAGMA database_list` 的空 `file` 判定，不是靠路径字符串匹配）。测试见 `test/unit/legion-db.test.ts`。
 
 ### 4.2 Schema（`PRAGMA user_version = 1`）
 
@@ -177,6 +180,7 @@ CREATE TABLE messages (              -- 邮件（§8）
   created_at   INTEGER NOT NULL
 );
 CREATE INDEX idx_messages_inbox ON messages(to_node, delivered, id);
+CREATE INDEX idx_messages_rate ON messages(from_node, created_at);   -- from_node 维度的限速 COUNT（§8，REV-19）
 ```
 
 ### 4.3 事件类型枚举（闭集，新增需修订契约）
@@ -187,6 +191,14 @@ CREATE INDEX idx_messages_inbox ON messages(to_node, delivered, id);
 
 ### 4.4 与 run.json 的关系（D20）：run.json 保留为 per-run 权威记录（resume 凭据、原子写、写锁、坏文件隔离原样不动）。legion.db 是树级索引+账本，**可重建**：`legion-rebuild` 命令遍历 nodes 各 run_id 的 run.json + session jsonl 重建 nodes/events（best effort，验收项 M2-h）。
 
+**「可重建」的确切边界（实测，勿过度引用）**：重建**不是**无损复原，以下三类事实在当前 `rebuildLegionDb()` 实现中**无来源、不可恢复**（「无来源」= 该函数不读取/不映射这些字段，不等于磁盘上没有；见每条的括注）——
+
+1. **节点字段**：`phase` / `phase_since` / `rework_count` / `contract_path` / `task_summary` 一律回落为 `null` / `0`。根因是 `NodeSource`（`src/legion/rebuild.ts:37`）根本没有这几个字段，`run.json` 也不携带 phase（`RunRecord` 无该字段），而 `insertNode` 对缺省值填 `?? null` / `?? 0`。
+2. **events 塌缩为合成事件**：重建每个节点只产出一条 `node_launched`（或按终态 `node_settled` / `node_failed` / `node_retired`），payload 为 `{ recovered: true, fromSession }`。`phase_change` / `budget_refused` / `mail_sent` / `tree_finalized` / `orphan_detected` / `phase_timeout` / `node_blocked` / `node_resumed` 等**全部无幸存者**——`ChildRecord` 只留终态，而**当前**的 rebuild 不解析 session jsonl 里的工具调用流水（§4.3 把树级语义事件与工具级明细分在两处）。这是对**当前实现**的陈述，不是「jsonl 里没有」：`legion_mail` 的 subject/body（`legion-tools.ts:412-413`）与 `legion_phase` 的 `to`（:458）确实以工具调用记录的形式存在于**发送方**会话 jsonl 中，未来说的 rebuild 完全可以（且应该）把它们解析回来。
+3. **messages 永不重建**：`INSERT INTO messages` 只存在于 `mail.ts`（`sendMail` :209 与 bounce 通知 :294）；`rebuild.ts:79` 只有条件 `DELETE`（`preserveMessages === false` 时）而**无对应 INSERT**。`ChildRecord` 不含 subject/body，`mail_sent` 的 payload 只有 `{messageId, toNode}`。故 **`messages` 表一旦丢失即不可再生**（同样限于当前实现：正文可从发送方 jsonl 的工具调用参数中恢复；但**未投递**的消息若发送方会话文件也已轮转/删除，正文即永久消失）。
+
+因此 §4.4 的「可重建」只能支撑**索引/聚合层可重算**这一层结论，**不能**用来论证「丢写无代价」——phase 状态机断点、预算拒绝、邮件正文都不在重建范围内。任何以「反正能重建」为由放松持久性的论证都必须先与本节对账。实测方法：构造含 5 类真实事件的账本 + 一封带 subject/body 的邮件 + 一个填满 phase 字段的 centurion 节点，跑真实 `rebuildLegionDb()`（`test/unit/legion-rebuild.test.ts` 之外的一次性探针），行数自 6→2、上述字段全清空、邮件行因默认 `preserveMessages` 而**幸存但不可再生**。
+
 ### 4.5 写入权责：节点行由**其父的 supervisor** 写（launch 插入、settled/failed 更新、心跳刷新）；phase 字段仅由状态机引擎（§7）迁移；usage 由各 supervisor 轮询 upsert（默认 30s，仅 running 节点）。LLM 永不直连库——唯一入口是扩展实现的工具（§8.4），child-guard 禁止 bash 触碰 legion.db（§13）。
 
 ## 5. 节点标识与命名
@@ -363,6 +375,7 @@ interface LegionEventBus {
 | `maxDepth`（全树深度） | 4 | 硬顶 = `MAX_NESTED_PATH_ENTRIES`（血缘路径在 4 处饱和；settings/env 超 4 截断——告警在 M1-integration 的 launch 路径接入，M0 阶段截断静默可接受）。每进程生效上限 C：根 `C = min(env 运营者覆盖, settings.legion.maxDepth, 4)`；深度 d、上限 C 的父 launch 角色 R：先过闸门 `d+1 > C` → BUDGET_EXCEEDED；再经 `PI_SUBAGENT_MAX_DEPTH` 下发 `C子 = min(C, d + R, 4)`（R 缺省=不收紧；非法值按叶子 R=1 处理；语义 = 子树代数含自身，位置无关，只收紧不放宽）。不变量：C子 ≤ C父，且每进程 depth ≤ maxDepth |
 | `maxChildrenPerNode`（单节点扇出） | 8 | 父 supervisor 查自己 **live** 子节点数（`starting`/`running`/`blocked`；`settled`/`failed`/`retired` 不占槽，session 可保留 resume） |
 | `maxActiveNodes`（全树并发 running+starting） | 30 | **全树真闸门**（替代只当 hint 的 maxConcurrentAgents）：launch 前一条 SQL，超限 BUDGET_EXCEEDED + `budget_refused` 事件 |
+| `maxQueuedLaunches`（准入队列上限，#266） | 32 | 只有扇出/并发两类闸门可排队（`max_children_per_node`、`max_active_nodes`，以及 in-process 的 `maxChildrenPerNode`/`maxActive`）；队列满 → 立即硬拒 `launch queue overflow (N/32)`，不留账本行。`maxDepth`/`max_active_nodes` 之外的深度与 spawn 预算**永不排队**。键名 `subagents.inprocess.maxQueuedLaunches`，两个后端共用同一个值 |
 
 ### 11.2 心跳与孤儿：postman 循环每次刷新直接子节点 `updated_at`。根 supervisor 每 60s 扫描：非终态 + `updated_at` 超 90s = `orphan_detected` 事件 + mail 通知 CEO。恢复 = resume 链（CEO 裁决，auto-resume 默认关）。孤儿判定可判定化：**非终态 ∧ 无活跃进程 ∧ 心跳超时**。
 
@@ -417,7 +430,7 @@ interface LegionEventBus {
 ### M2 军团树（组织层：db + centurion + 状态机 + 邮件）
 
 - **归属**：新增 `src/legion/{db,nodes,events,usage,mail,state-machine,budget,rebuild}.ts`、`agents/centurion.md`、`src/extension/legion-tools.ts`；修改 `orchestrator.ts`（launch 落库/树命名/预算查库/子树 worktree——经 REV-17 收为 centurion 专属，非 centurion 请求 warns 一次后降级）、`src/runs/worktree.ts`（subtree 模式）、`src/runs/args.ts`（env 增 `PI_LEGION_DB`/`PI_LEGION_NODE_ID`）、`src/agents/agents.ts`、`index.ts`（队级 resume、collect 落库）
-- **验收**：(a) 三层树 e2e：CEO→centurion→workers×2 全阶段走通（契约落盘→并行实施→review verdict→verify 实跑→done 收队 + squash MR）；(b) rework 循环：review major→回 implementing→复审通过；(c) rework≥2 → failed 上抛；(d) kill centurion 进程 → 孤儿报警 → resume 恢复整队、settled 组员不复活、运行中组员上下文延续；(e) `maxActiveNodes` 超限拒派 + 事件；(f) 邮件：同级/父子/父←子通、跨子树拒发并提示路由、retired 收件人唤醒投递、终态收件人退信；(g) WAL 压测：60 模拟 supervisor 并发写 5 分钟，busy 超时率 <0.1%；(h) `legion-rebuild` 从 run.json+jsonl 重建 nodes/events；(i) 非 pi kind 明确拒绝
+- **验收**：(a) 三层树 e2e：CEO→centurion→workers×2 全阶段走通（契约落盘→并行实施→review verdict→verify 实跑→done 收队 + squash MR）；(b) rework 循环：review major→回 implementing→复审通过；(c) rework≥2 → failed 上抛；(d) kill centurion 进程 → 孤儿报警 → resume 恢复整队、settled 组员不复活、运行中组员上下文延续；(e) `maxActiveNodes` 超限拒派 + 事件；(f) 邮件：同级/父子/父←子通、跨子树拒发并提示路由、retired 收件人唤醒投递、终态收件人退信；(g) WAL 压测：60 模拟 supervisor 并发写 5 分钟，busy 超时率 <0.1%（**实测 2026-10-22 通过**：60 个 `fork` 子进程、各持一连接、共享一库，postman 节奏每 ~2s 一短事务，300s 内 9004 次尝试 / 9004 提交 / 0 次 busy = 0.000%；成功事务 p50 1.03ms / p95 1.99ms / p99 4.92ms。复跑：`npm run test:wal-stress`；CI 快速守卫 `test/unit/wal-concurrency.test.ts` 只钉住 busy_timeout 生效、WAL/超时前置条件与零 busy，**不证明** 5 分钟跨进程结论）；(h) `legion-rebuild` 从 run.json+jsonl 重建 nodes/events；(i) 非 pi kind 明确拒绝
 
 ### M3 可视化
 
@@ -462,3 +475,6 @@ interface LegionEventBus {
 | 2026-10-11 | REV-15 | §6.1 centurion 角色卡的 `team: be-value` 改为可选省略：be-value 是示例值，仓库/用户 settings 均未定义该队，不覆盖时子进程收警告并退化全 roster。team 字段语义 = 可选的默认队绑定（须真实存在），省略即全 roster。触发：reviewer-6 对 PR #13 的范围外观察 |
 | 2026-10-12 | REV-16 | §3.2 retire 链加固：SIGTERM 超时后升级 SIGKILL（新 option `killTimeoutMs`，默认 1s），并在 retire 时枚举子 pi 的后代进程（/proc 祖先链），按进程组 SIGTERM→SIGKILL 清场（排除 supervisor 自身进程组与子 pi 自身 pid）。触发：2026-10-12 孤儿 `node --test` 进程泄露事故（两个 PPID=1 进程各烧 4h20m CPU，SIGTERM 无效，人工 SIGKILL 收场）。子契约：`docs/retire-hardening-contract.md`（FROZEN-1） |
 | 2026-10-19 | REV-17 | §9 worktree 收为 centurion 专属（权限变更，按 §15-4 走修订）：① 判定以角色名 `centurion` 为准，centurion 卡一律拿子树 worktree、嵌套 centurion 拿 nested worktree；② 其余角色一律不拿——删除「`acceptance.role: writer` 自动补 `worktree: true`」的隐式默认，`agents/worker.md` 从 `worktree: true` 改为显式 `worktree: false`（`agents/centurion.md` 的 `true` 与 `agents/prototype.md` 的 `false` 不变）；③ 违规一律**降级为 `false` + `console.warn` 一次**，**不抛错**（抛错会阻断 launch）；`subagent({ worktree: true })` 显式传参同样降级。不改 `resolveLaunchWorktree` 的优先级链（不变式 I5），不新增事件类型，不改 `spawnMode` 仲裁逻辑。原因：issue #214（worktree 收为 centurion 专属，与 §9 已冻结的「组员一律 `worktree: false`」对齐；实现向契约收敛，隔离边界继续由「每棵子树」承载） |
+| 2026-10-19 | REV-18 | v4 收紧为仅 kind: pi；AGENT_KINDS 收敛为 ["pi"]；非 pi 值忽略并按 pi 启动。字段不删（值域收窄）；`spawnMode` 的 `rpc`/`inprocess` 不受影响。契约：`docs/contracts/drop-non-pi-kinds-v4.md`（D1，v4.0.0） |
+| 2026-10-21 | REV-19 | §4.2 新增索引 `idx_messages_rate ON messages(from_node, created_at)`（schema 变更，按 §15-4 走修订）。原因：`sendMail` 的限速 COUNT（`src/legion/mail.ts`，`WHERE from_node = ? AND created_at > ?`）在**写事务内**执行且 `messages` 无任何保留策略（`DELETE FROM messages` 仅见于 `rebuild.ts` 且只在 `preserveMessages === false`），实测 50k 行时由 `SCAN messages` 变为覆盖索引 `SEARCH`，成本随运行时长单调劣化。零行为变更：COUNT 结果不变，仅查询计划改变。**不改 `user_version`**（仍为 1），因此**既有 legion.db 不会获得该索引**——`migrate()` 在 `user_version === 1` 时提前返回，`SCHEMA_V1` 只在版本 0 执行。**且 `legion-rebuild` 不能修复它**：`rebuildLegionDb()` 拿的是已打开的 connection，事务内只发 `DELETE FROM usage/events/nodes`（以及 `preserveMessages === false` 时的 `DELETE FROM messages`），**没有 DROP/CREATE TABLE，也不重跑 `SCHEMA_V1`**；行删光后索引集合原封不动。实测：旧账本跑完 `rebuildLegionDb()` 与 close+reopen 后均仍为 `["idx_messages_inbox"]`，只有**删掉 legion.db 文件后重新打开**（走版本 0 建库）才会得到 `idx_messages_rate`。故补救方式**仅限重建账本文件本身**（legion.db 是可丢弃的树级索引，§4.4：从 run.json + session jsonl 重新生成），不是跑 rebuild 命令。接受此代价：每棵树各自新建 legion.db，长跑账本才需要人工删库重启。代价度量（50k 行表，200 发送者）：限速 COUNT 由 `SCAN` 的 ~3327 µs/call 降至 ~6.6 µs/call（**~500x**，该量级稳定复现）；写侧索引维护在已开事务内的单行 INSERT 上是**零点几 µs/行量级（低双位数百分比）**，方向确定但**具体倍数机器相关且不可移植**（同一代码在不同环境实测 +32% 到 +47% 不等，勿当常数引用）；一次**含 COMMIT 的**单行写入被 fsync 主导（数百 µs、高方差），索引那零点几 µs 在该噪声内不可分辨。净效应每封信仍是 ms 量级的节省，且随行数增长而扩大。不新增「打开时补建索引」后门（会让契约漂移）。不引入 `messages` 保留策略（另立产品决策：归属、是否借用 `eventRetentionDays`、bounce 风暴是否单独限流）。触发：issue #237 P9 |
+| 2026-10-22 | REV-20 | ① §4.1 显式写下 WAL **前置条件**：`PRAGMA journal_mode=WAL` 是查询、返回值才是实际生效模式，可在不报错的情况下降级，故 `openLegionDb()` 校验返回值、文件库非 `wal` 即抛错（`:memory:` 刻意豁免，由 `PRAGMA database_list` 的空 `file` 判定）。② §4.4 补「可重建」的**实测边界**：phase/phase_since/rework_count/contract_path/task_summary 全部不可恢复（`NodeSource` 无这些字段）；events 塌缩为每节点一条合成事件（phase_change/mail_sent/budget_refused/tree_finalized 等零幸存）；`messages` 无任何重建路径（INSERT 仅存在于 `mail.ts`，`rebuild.ts` 只有条件 DELETE）。按 §15-4 走修订的理由：②是**订正一条会误导持久性推理的既有断言**（原文「可重建」被当成放松丢写的前提），①是把一句被隐含的实现假设升为契约明文。非 schema/事件类型/权限变更，`user_version` 不变；**未触碰** `synchronous` / `journal_mode` 的取值 / `temp_store` / `cache_size` / `mmap_size`（`synchronous=NORMAL` 提案已评估**否决**：生产写速率 0.53–5.47 tx/s，`FULL` 占空比 0.027–0.273%，而 `NORMAL` 会把掉电窗口从单事务放大到上个 checkpoint 以来的全部事务、且长活读者下无界）。触发：issue #236 　**注（对 REV-19 措辞的澄清）**：REV-19 原文写「legion.db 是可丢弃的树级索引」，该断言的语境**仅是**「旧账本拿不到新索引、补救只能删库重开」这一 schema 索引场景，并非「账本可随意丢弃」。本修订不追改 REV-19 的历史正文（修订日志按 §15-1 追加、保留当时的实际决定），而在此澄清其适用范围：可丢弃的**只是索引层**，`messages` 与 phase 状态断点不在重建覆盖内（见 §4.4）。 |

package/docs/performance-2026-10-19.md

@@ -0,0 +1,199 @@
+# Performance measurements (2026-10-19)
+
+Measured on `v3.1.0` (`3071dee`), Node v24.13.1, one container. **Absolute
+milliseconds drift with the machine; the ratios and the call chains are the
+findings.** Reproduce with `npm run test:perf`.
+
+These numbers back the perf issues (#236–#241). The harness lives in
+`test/perf/` so a fix can turn each one around. Regression tests that pin an
+open defect say so in their name and in a comment next to the assertion.
+
+## Tier 1 — user-visible latency and correctness
+
+### P1 · `collect()` burns ~2.5s per child in a fixed sleep
+
+`Orchestrator.collect()` receives `wait === "settled"` from the supervisor (the
+child's turn ended), then still awaits `waitForQuiet`, which polls
+`statSync(sessionFile)` until the size has been stable for
+`DEFAULTS.settleQuietMs` (2500ms).
+
+Measured on the real `Orchestrator` + `FakeSupervisor` + a real session JSONL,
+changing only the quiet window:
+
+```text
+collect(), production settings     2509 ms
+collect(), settleQuietMs = 0        503 ms
+=> ~2007 ms of dead time per successful collect
+```
+
+Guarding nothing: when `collect()` enters that branch the session's last
+assistant message is already terminal **and on disk** (`stopReason: "stop"`,
+`lastTurnMissing: false`). For an append-only file, a terminal message cannot
+grow afterwards.
+
+Root cause: `LegionSupervisor.onEvent` exists (`src/supervisor/types.ts`) and
+both backends already publish settle events, but `src/runs/orchestrator.ts`
+never subscribes — every post-`waitSettled` wait degrades to stat polling. The
+same root cause drives `waitOutTransientConnection` (worst case 1800 full
+`parseSessionFile` calls, ~500ms `POLL_INTERVAL_MS` cadence) and
+`collectArtifactGrowing`.
+
+> **Status after #232** (kept for the measurement record; the numbers above are
+> the pre-fix baseline): `waitForQuiet` is gone (PR #244). The two remaining poll
+> loops keep their channel but had their *cost* cut:
+> `waitOutTransientConnection` re-parses only when the artifact size changed and
+> backs off 500ms → 4s (default 900s deadline: 1800 full parses → 1 parse, 228
+> cheap polls); `collectArtifactGrowing` samples the grace window at 50ms so it
+> returns as soon as the artifact grows instead of always one full 500ms later.
+> Fixing the *channel* (subscribing `onEvent`) stays open — see #232.
+> Pinned by `test/unit/collect-polling.test.ts`.
+
+Test: `test/perf/collect-latency.test.ts` (virtual clock: the injected
+`now`/`sleep` deps measure the window without sleeping).
+
+### P2 · one `node_abandoned` row permanently stalls the event bus
+
+`src/runs/hygiene.ts` writes `type = 'node_abandoned'`, but
+`LEGION_EVENT_TYPES` does not contain it and `mapEvent` throws on an unknown
+type. `createDbEventSource` records the error and leaves the cursor
+unadvanced, so every 250ms poll re-reads the same poisoned batch and throws again:
+
+```text
+valid ledger:            delivered=3  cursor=3  errors=0
+after one poison row:    delivered=0  cursor=0  errors=4
+repeat poll:             delivered=0  cursor=0  errors=4
+```
+
+The cross-process view is dead from that point on, and the poll spins at 4Hz.
+Reachable whenever hygiene marks a stale `starting/running/blocked` node and
+any process later attaches to that ledger.
+
+Test: `test/perf/event-bus.test.ts`, the `REGRESSION (open defect)` case.
+
+## Tier 2 — costs that scale with load
+
+### P3 · live-overlay re-reads the whole session file on every append
+
+`readSessionDelta` compares `statSync().size` against `cursor.fileSize`, then —
+on any change — does `readFileSync(sessionFile, "utf8")` **from byte 0** and
+re-parses every line. The byte offset is already stored in the cursor; it is
+used only as a change flag, never as a read offset.
+
+```text
+4.9MB session, poll with no append:   31.9 ms   (full re-read)
+4.9MB session, tail-read prototype:    0.05 ms  (stat only)  => ~600x
+```
+
+Cost grows with session length while the trigger rate grows with token rate, so
+the viewer gets slower the longer the turn runs.
+
+### P4 · `attachUsageTotals` is an N+1 (72% of the UI snapshot)
+
+`src/legion/usage.ts` calls `getUsage` once per node inside a `map`. Measured at
+400 nodes: `getSubtree` 2.62ms + `attachUsageTotals` 6.90ms = 9.64ms per
+snapshot. A single `WHERE node_id IN (...)` batch measured **8.95ms -> 0.90ms**
+(9.9x) with byte-identical output.
+
+Runs twice per second from the 500ms refresh, plus once per bus event
+(`src/extension/runtime.ts` subscribes to every event type except `text_delta`).
+
+Test: `test/perf/ledger.test.ts` (asserts the N+1 exceeds the CTE).
+
+### P5 · heartbeats pay one fsync per child
+
+`refreshHeartbeats` loops `updateNode` per child; each is an implicit
+transaction under the default `synchronous=FULL` (only `busy_timeout`,
+`foreign_keys`, `journal_mode` are set in `src/legion/db.ts`).
+
+```text
+8 children, per-child autocommit    3.83 ms   (479 us/child)
+8 children, one transaction         0.99 ms   (124 us/child)  => 3.9x
+60 children                        31.6 ms  -> 8.2 ms
+```
+
+### P6 · no statement cache: every `prepare()` recompiles
+
+45 `prepare()` call sites; the data layer exposes only `exec/prepare/close`.
+
+```text
+prepare-per-call   30.1 us/op
+reused statement    9.2 us/op
+getNode x400       15.7 ms -> 4.8 ms  (3.2x)
+```
+
+> **Status after #236 P2** (kept for the measurement record; the numbers above
+> are the pre-fix baseline): `prepare()` is now served from a bounded
+> per-connection LRU (cap 64) installed *inside* the data layer, so all 46 call
+> sites reuse compiled statements without being touched. Re-measured on the
+> same harness: prepare-per-call 30.96/28.43/31.75 → 8.86/9.61/11.89 us/op,
+> `getNode` x400 17.36/17.34/16.99 → 4.64/4.63/6.49 ms (3.6x). The `getSubtree`
+> snapshot barely moves (0.64 → 0.47 ms) because it was already few statements.
+> A schema-mutating `exec()` (`ALTER`/`CREATE`/`DROP`/`REINDEX`/`VACUUM`)
+> invalidates the cache, since a cached `SELECT *` keeps the column set it
+> compiled against. Pinned by `test/unit/legion-statement-cache.test.ts`
+> (asserts statement identity, compile counts and invalidation — not timing).
+> `synchronous` / `temp_store` / `cache_size` / `mmap_size` stay untouched: P3
+> is a maintainer口径 decision, and the recon here measured those at near-zero
+> benefit (0.33 MB db, 85 pages; default `cache_size` already holds 512 pages).
+
+### P7 · `structuredClone` spends the incremental-parse win
+
+`parseSessionFile` keeps a dev/ino/offset fingerprint cache (#36) but then
+returns `structuredClone(state.parsed)`:
+
+```text
+6.9MB session: cold 73.3ms, warm 3.24ms
+structuredClone(parsed)          3.95ms   (~106% of the warm call)
+```
+
+Called once per job and once per node per 500ms refresh. Note the honest
+bound: a **warm** pass over 60 distinct sessions is only 12.3ms (~2% of the
+tick). The cliff is the 64-entry LRU cap — past that every tick is cold
+(measured 312ms for the same pass).
+
+### P8 · event replay: the cursor starts at 0
+
+`createDbEventSource` defaults `cursor = 0`, so attaching to a ledger with
+history replays it from the oldest row, and each replayed event triggers a
+snapshot: 300 events x 3.42ms = **1027ms** of blocking work on attach. Seeding
+from `MAX(id)` makes it one query.
+
+## Tier 3 — smaller, still measured
+
+### P9 · `messages` rate-limit is a full table SCAN
+
+`SELECT COUNT(*) FROM messages WHERE from_node = ? AND created_at > ?` has no
+covering index. At 50,000 rows: **5.04ms** per `sendMail`, `EXPLAIN QUERY PLAN`
+says `SCAN messages`. The table also has no retention policy.
+
+> Measurement note: a first attempt reported 0.04ms because the default
+> `ratePer5Min` limit kept the table at zero rows. Re-measured by inserting rows
+> directly — the SCAN is real.
+
+### P10 · six synchronous git processes per first launch
+
+`orchestrator.ts` calls `isInsideChildWorktree(this.cwd)` twice in the same
+branch (lines 608 and 615) with the same argument:
+
+```text
+isInsideChildWorktree x1    9.4 ms  (2 execFileSync)
+isInsideChildWorktree x2   16.0 ms  <- 4 processes, 2 of them redundant
+isGitRepo x1                3.6 ms
+=> 6 synchronous git processes per first centurion launch
+```
+
+All `execFileSync`, so they block the parent event loop; provision adds one
+`bash -lc` (login shell, default 600s timeout).
+
+## Deliberately not measured / open decisions
+
+- `PRAGMA synchronous = NORMAL`: would cut every autocommit write a further
+  4–5x. WAL-safe against corruption but can lose the last transactions on power
+  loss. Needs an explicit decision; the contract only fixes WAL + `busy_timeout`.
+- The contract asks for a 60-supervisor concurrent-WAL stress run
+  (`docs/legion-v2-contract.md`, "busy timeout rate < 0.1%"). **Implemented
+  2026-10-22** as `npm run test:wal-stress` (`test/stress/wal-stress.ts` +
+  `wal-worker.ts`): 60 forked processes x 1 connection each x postman cadence
+  (1 txn / 2 s) x 300 s -> 9004 attempts, 0 busy (0.000%), p50 1.03 ms /
+  p95 1.99 ms / p99 4.92 ms. That measurement does not revisit the
+  `synchronous` question above: it ran on the shipped `FULL`.