[test] store/admin has zero tests — and now owns every destructive operator control

[serge-ivo]

The gap

store/admin has zero tests — and as of 66fcc23 (#38/#41) it holds the most destructive controls in the product: suspend a user, unpublish or delete an agent, cancel an instance, change roles, revoke keys.

This needs no new infrastructure. vitest.config.ts already globs store/*/src/**/*.test.ts in its UNIT_TESTS project, with a comment noting the console was once missing from that glob so anything added there "would have passed locally and never run in CI". The harness is there; admin simply has nothing to run.

store/console shows the established pattern: 9 test files, all .test.ts (never .tsx), all pure logic extracted into lib/*.ts — surfaces, workInFlight, identity, triggerSchedule, teamwork. Zero render any component.

What to test

Follow that pattern — extract the decisions out of JSX into pure modules, then test the modules:

• Runtime status derivation. Four states, not two: live (relay socket) / offline / unknown (the list's fan-out budget returns null past 50) / no-runner-ever-registered. The bug this prevents is rendering null as offline — the DB's instance_runtime_nodes.status is never cleared on an unclean disconnect and already lies in the other direction, so a second wrong answer here is how an operator kills a healthy machine.
• force is never sent on the first attempt. The 409 must be surfaced with its live-subscriber count before forcing is offered at all.
• Echo gates: delete requires the slug, key revoke requires an explicit provider, suspend requires the login. Assert that a mismatched or empty echo cannot produce a request.
• Key revoke is per-provider. An omitted provider must never widen to "all keys".
• Self-targeting is refused — self-suspend and self-demote both lock the only operator out.
• Filter + pagination state — the page and the COUNT share one predicate server-side; assert the client can't send a filter to one and not the other.

Acceptance

• The guards above are covered by pure unit tests that run in the existing suite with no new dependency.
• Each test comment names the failure it prevents (repo convention).
• Logic needed for a test is moved to src/lib/*.ts rather than tested through a component.

Related: #38, #41. Sibling gap for JSX-resident logic: see the component-testing issue.

[serge-ivo]

Done — 73fa5e5

store/admin went from zero tests to 61, with no new dependency, in the existing UNIT_TESTS glob exactly as this issue predicted. Every decision was moved into src/lib/*.ts first (the #282 decision was (b) — push the logic down); the components are now renderers over those modules.

The four-state runtime derivation — runtime-status.ts, 8 tests

The one this issue calls highest-value, and it earned it: the naive implementation is a two-branch ternary and both extra states are silently wrong under it.

input	state	why it is not "offline"
connected: true, nodes ≥ 1	live	RelayDO holds a socket
connected: false, nodes ≥ 1	offline	we checked, it isn't there
connected: null, nodes ≥ 1	unknown	the list's fan-out budget was spent past 50 rows — we did not look
nodes = 0	no-runner	nobody ever ran pags up; there is no machine for connected to be about

Why conflating unknown with offline is the dangerous one, restated for the record: an operator who reads "offline" acts — restarts, reassigns, kills. And instance_runtime_nodes.status already lies in the other direction (never cleared on an unclean disconnect, so a machine dead for days still reads "online"). Two wrong answers pointing opposite ways is how a healthy runner gets killed by someone being careful.

One case the issue didn't list and I added: undefined degrades to unknown too. A row shape that predates runtimeConnected, or an API that stops sending it, must not become a confident negative — and undefined is falsy, so connected ? live : offline answers "offline" about a field nobody populated. There is also a shape test asserting all four states are reachable, so a refactor that folds one into another fails even if the cases are edited to match.

The rest

• force is never sent on the first attempt (danger.ts, 20 tests) — and it stopped being a convention. runArgs derives force from the recorded 409, and only a 409 sets that, so there is no reachable state in which a first attempt carries it. Also covered: a 409 on a non-forceable action stays a plain failure, a re-submit clears the stale error but keeps the 409 that armed forcing, and blockedCount returns null rather than a confident zero (a "0 live subscribers will be cancelled" line under a 409 tells the operator forcing is free).
• Echo gates reject a mismatched or empty echo — including the near-misses a sloppy comparison accepts: trailing space, leading space, case change. A gate that accepts "My-Agent " for "my-agent" is a speed bump, not a gate.
• Key revoke stays per-provider (moderation-policy.ts, 19 tests) — a blank provider now throws rather than being sent as an absent field for the server to interpret as "all of them".
• Self-targeting is refused — self-suspend, and self-demotion via the admin checkbox. Plus: it does not guess when useSelfId hasn't resolved (guessing "this might be me" disables moderation of a real account).
• Filter + pagination share one predicate (list-query.ts, 14 tests) — the query string and the page-reset key derive from a single field list, so a new filter cannot reach one and not the other. hasNext is computed from the last row shown, so the final page can't offer a Next that lands past the end and renders as "no matches".

Two bugs found by the extraction

1. The delete body sent the wrong string. It carried confirm: a.slug — the correct slug from props, regardless of what was typed. The echo gate was decorative: a regressed gate still produced a valid delete and the server's echo check could never fire. It now sends the operator's typed value, so both checks validate the same string.
2. Blank-provider revoke had no client-side floor at all (above).

Not tested, deliberately

The other ~20 admin pages (Errors, Usage, Spending, Ops, Trace, McpAudit, …) hold no destructive controls — they are read-only renderings of API responses, and testing them would assert that React renders. AuditTrail's refresh signal and RolesEditor's remount-on-save keying are rendering concerns; noted as the residue of option (b) on #282.

Each test comment names the failure it prevents, per repo convention, and each file carries codeOf() source-assertions (the store/console/src/lib/surfaces.test.ts idiom) that fail if the extracted decision is moved back into JSX.