test(verify): harness.one-composition pays the boot's first load at module scope (#23181 slice 4) (#23994)

Part of #23181
Clause-②: no

Slice 4 of #23181, the `@objectstack/verify` row. One test file pays the
harness boot's first load at module scope through slice 3's
`boot-warm-up.testkit.ts`: `harness.one-composition.test.ts` (+7 / -0).
Three more candidates were measured and left unchanged (below, with
their numbers). Test files only; nothing in the package's `files[]`
moves.

## The reading this slice works from

The newest run of `measure-test-shard-timings --diff` is run
`38897658479` (job `116961908568`, 2026-10-16T12:01Z). It is a
`pull_request` dry run of the refresh lane (`shard-timings-refresh.yml`,
head `f8bacd05b4`), so the dataset was not committed, but every step
ran, the per-file list included. Its window is six hourly full-battery
runs, `38858901527` (2026-10-16T06:01Z) through `38891051243` (11:01Z),
all after slice 3 landed (`72329942f9`, 2026-10-15T07:01Z). No scheduled
or dispatched refresh has run since `38340176409` (2026-10-13), the run
the card's table comes from. The lane's cron is Monday 05:30 UTC.

It lists 124 files over budget, 8 of them in `@objectstack/verify` (the
job log's "every test file over budget" block):

| file | refresh `38897658479` | card (`38340176409`) | this slice |
|:--|--:|--:|:--|
| `src/unique-scope.test.ts` | 45.63 s | 84.2 s | held off (the
boot-cost source slice) |
| `src/parent-write-reach.test.ts` | 35.97 s | 64.0 s | held off |
| `src/dashboard-window.test.ts` | 31.06 s | not on the row | measured,
not changed |
| `src/delete-behavior.test.ts` | 18.90 s | 46.4 s | held off |
| `src/held-session-vendor-admin-doors.pin.test.ts` | 17.08 s | not on
the row (landed 2026-10-14) | measured, not changed |
| `src/harness.one-composition.test.ts` | 11.28 s | 31.9 s | **changed**
|
| `src/harness.key-custody.test.ts` | 10.54 s | 28.1 s | measured, not
changed |
| `src/handle.test.ts` | 10.27 s | 38.3 s | already has the warm-up
(slice 3) |

The two elevated-door rows slice 3 changed are gone from the list. So
are 16 other rows, 15 of them on files nobody changed (for example
`handle.automation-door`, `harness.host-resolution`,
`erasure-transaction-authorization`), including all eight files slice 3
projected under 10 s with the warm-up. Files still listed and unchanged
read 0.35x to 0.56x of their card values. This window is six runs
against the card's twenty, so its maxima are lower across the board, and
the departure of the two elevated-door rows cannot be credited to the
warm-up alone.

## Measurement

Isolated, interleaved A/B on one shared 4-vCPU box: for each file, an
untracked copy of the base file (blob-identical to `0b6956490`) and the
changed file, alternated in three rounds (base first, then head first,
then base first), one vitest process each, `--maxWorkers=2`, through
`os-verify-lock`. Clocked = the default reporter's file line (hooks plus
tests, collection excluded), the quantity `report-test-timings.mjs`
captures in CI; the agent-detection variables were unset so vitest picks
that reporter. Projection = head median x (refresh reading / base
median), slice 3's rule with the newest reading in place of the card's.

| file | base ms (3 rounds) | head ms (3 rounds) | median | refresh |
projected | verdict |
|:--|:--|:--|:--|--:|--:|:--|
| `harness.one-composition` | 10141, 10022, 10568 | 8342, 8474, 9068 |
10141 to 8474 (-16%) | 11.28 s | 9.4 s | **kept** |
| `harness.key-custody` | 5811, 6781, 7669 | 4426, 4642, 4654 | 6781 to
4642 (-32%) | 10.54 s | 7.2 s | reverted: the warm-up masks a pin
(below) |
| `held-session-vendor-admin-doors.pin` | 9736, 8825, 9478 | 7164, 6794,
7018 | 9478 to 7018 (-26%) | 17.08 s | 12.6 s | reverted: does not cross
|
| `dashboard-window` | 13921, 15097, 14801 | 10892, 10699, 11721 | 14801
to 10892 (-26%) | 31.06 s | 22.9 s | reverted: does not cross |

The cost moves rather than vanishes: each changed file's vitest `import`
(collection) median grew by 2.4 to 5.4 s, and the whole isolated
`Duration` moved by -0.6 to +1.8 s. For `harness.one-composition`,
`Duration` went 34.01 to 35.31 s by median.

`harness.one-composition` crosses by 0.6 s on this window's ratio
(1.11x). On the card's window ratio (3.2x) it would not. The next landed
refresh decides.

## Why `harness.key-custody` keeps its first boot

The warm-up crosses the line there, but it is not neutral. `harness.ts`
builds its crypto provider once per process (`processCryptoProvider ??=
...`), on the first boot. With the warm-up, that first boot is the
warm-up's, at module scope, outside the keyless development posture each
of the file's describes sets up. An ablation proves the consequence. The
cached provider was made the default, minting `new
LocalCryptoProvider()`, with `HOME` and `OS_HOME` pointed at a scratch
directory and the prediction written first:

- base copy (no warm-up): **1 failed / 6 passed**, "no key material is
created, before or after stop()", as predicted;
- head (warm-up): **7 passed**, as predicted. The key file landed in the
scratch home, the process's own key home, where no case looks.

So the warm-up would blind the file's empty-key-home pin to that
regression, and in that regression it would mint a key in the host's
real key home. The file goes back to its base bytes. Restore proven by
`ablation-replace`: blob `704910003254` == HEAD, `git diff HEAD` empty.

A second ablation checks that `harness.one-composition` has no such
coupling. `release()` was made to never free `LIVE_CONFIGURATIONS`, the
instance rule's key. Both legs went **2 failed / 8 passed**, the same
two cases ("a sequential re-boot works: boot, stop, boot" and "a refused
or failed boot does not hold the configuration"). The prediction was the
same failing set in both legs. The warm-up boots and stops a
configuration of its own, so it neither masks nor causes an
instance-rule failure. Restore proven the same way.

## Assertions kept

`harness.one-composition.test.ts` diff is +7 / -0: one import, a
three-line comment and `await warmUpBoot();`, slice 3's pattern. Its 13
`it`/`describe` title lines hash identically at `0b6956490` and HEAD
(sha256 prefix `57c7423423e9709c`), and `expect(` is 21 = 21. No
timeout, budget or roster entry moved. No test was removed, skipped or
moved.

## Tests and gates (at `ae6662dde`, a merge of `origin/main`
`022c6e799`)

- `pnpm --filter @objectstack/verify test` through `os-verify-lock`:
Test Files 41 passed (41), Tests 362 passed (362), exit 0.
- `pnpm --filter @objectstack/verify typecheck`: exit 0 (`tsc --noEmit`,
`check:test-typecheck` OK). `tsc -p tsconfig.test.json --listFilesOnly`
lists the changed file; `tsconfig.json` excludes it by design.
- The A/B head runs: 10/10 passed in every round.
- `node scripts/pm/dispatch-gates.mjs --commands --repo
objectstack-ai/objectstack` derived 50 commands for the one changed
path. All 50 exited 0; `pnpm check:dual-build-cjs-loads` first answered
exit 3 (PREREQUISITE NOT MET) and exited 0 after a full `turbo run
build` (76/76 tasks). `--ran`: "50 derived, 50 run, 0 NOT-MEASURED, 0
UNRUN". The derivation was taken three commits behind `origin/main`; the
three family files that moved are none of the 50.
- Extras: `pnpm check:verify-stand-in` exit 0 (2 guarded, 18 exempt, 10
call sites); `pnpm exec eslint --no-inline-config
packages/verify/src/harness.one-composition.test.ts` exit 0. The
repo-wide `pnpm lint` is CI's (`Lint & Repo Gates`).

## Acceptance notes

- `boot-warm-up.testkit.ts` says the warm-up "shares nothing a case
asserts on" and that what stays warm is process-level module state. The
harness's process-cached crypto provider is process-level state a case
can assert on, as `harness.key-custody` does. The testkit is not edited
here; carried to the seat, not filed.
- `held-session-vendor-admin-doors.pin` turns on SSO and the `admin`
plugin by environment in its `beforeAll`. A default-options warm-up
cannot pay those loads, and its proof cases are most of what remains.
- `dashboard-window` keeps about 10.9 s isolated after the warm-up,
mostly its proof runs.
- Both are measured here and left for a later slice.

---
_Generated by [Claude
Code](https://claude.ai/code/session_018t6a5rvqPRvEDMCVVW9kYT)_

---------

Co-authored-by: Claude <noreply@anthropic.com>

Author: objectstack-fleet[bot]

packages/verify/src/harness.one-composition.test.ts

@@ -25,8 +25,15 @@ import { join } from 'node:path';
 import { afterAll, afterEach, describe, expect, it } from 'vitest';
 import { defineStack } from '@objectstack/spec';
 import { bootStack, type VerifyStack } from './harness.js';
+import { warmUpBoot } from './boot-warm-up.testkit.js';
 
 const BOOT_TIMEOUT = 120_000;
+
+// The boot's first load, paid during collection rather than in the first
+// case's clock (see `boot-warm-up.testkit.ts`). The first boot below uses the
+// default options.
+await warmUpBoot();
+
 const PROBE = 'com.example.one-composition.probe';
 const PROBE_SERVICE = 'one-composition.probe';