@fuzdev/fuz_app 0.147.0 → 0.149.0

package/dist/testing/CLAUDE.md

@@ -32,7 +32,7 @@ time (never runtime), where a throwing guard would break `vite build`.
 - `stub_handler()` — fresh `Response('stub')`.
 - `stub_mw` — pass-through middleware (`async (_c, next) => next()`).
 - `create_stub_app_deps()` — factory: fresh `AppDeps` with no-op keyring/password/`delete_file`, a `read_secure_file` that throws ENOENT (the no-token-file state), a `create_noop_stub` DB, silent `Logger`, no-op `audit`, an empty `connection_closer`.
-- `create_test_audit_emitter()` — no-op `AuditEmitter`; `emit` / `emit_role_grant_target` no-op, `emit_pool` resolves immediately, `notify` no-op, `add_listener` throws (use `create_recording_audit_emitter` for a listener-accepting emitter), `listener_count` returns 0, `drain_inflight` resolves immediately.
+- `create_test_audit_emitter()` — no-op `AuditEmitter`; `emit` / `emit_role_grant_target` no-op, `emit_pool` resolves immediately, `notify` no-op, `add_listener` throws (use `create_recording_audit_emitter` for a listener-accepting emitter), `listener_count` returns 0, `drain_inflight` resolves immediately, `is_tracking_inflight` returns `false`.
 - `create_stub_audit_sse()` — no-op `AuditLogSse` for surface-test wiring without booting real SSE. `on_audit_event` no-op (nothing is broadcast); `required_role` is `admin`; `registry` is a fresh `SubscriberRegistry` (live `.count` / `.close_*` for registry-state tests, isolated per call). For real SSE plumbing build via `create_audit_log_sse` against `create_test_app`.
 - `create_stub_api_middleware({include_daemon_token?, origin_carve_outs?})` — stub `MiddlewareSpec[]` matching `create_auth_middleware_specs`'s output (origin/session/request_context/bearer_auth, optional daemon_token) for surface generation without booting real auth — the same names, paths, order, and declared `errors` (`origin` declares a 403; `bearer_auth` and `daemon_token` declare none, since both soft-fail through `next()`), pinned against the real factory by `auth/middleware.mounted.test.ts`. The surface merges middleware errors into every route under the path, so a stub declaring more would widen the test surface with statuses the live server never returns. Each spec gets its own pass-through handler (not the shared `stub_mw`), so `assert_middleware_stack_mounted` tells the layers apart. See `auth/CLAUDE.md` §Middleware for the real stack.
 - `create_stub_app_backend(options?)` — stub `AppBackend` with no database: `create_stub_app_deps()` (or `options.deps`), no migration results, a `close` that does nothing (or `options.close`). For assembling a server in tests that never reach the database.
@@ -79,6 +79,15 @@ across the auth test suite. Use for query-level tests needing real DB rows
 but not a full session/token bundle. For tests also needing an API token +
 session cookie + role_grants, use `bootstrap_test_keeper` from `app_server.ts`.
 
+`create_test_extra_actor(db, account_id, name)` adds an actor to an
+account — the multi-actor edge — with `created_at` read from the wall clock
+(`clock_timestamp()`), not the transaction-fixed `NOW()` default. Actor lists
+sort `created_at, id`, so a shared `created_at` would order them by random id;
+seeded through it, the account's first actor sorts first and the extras in
+insert order. `_testing_reset` and the in-process setup seed `extra_actors`
+with it, as the Rust reset does with `query_create_actor_with_clock_timestamp`,
+so both spines list a multi-actor keeper's actors in one order.
+
 `create_test_role_grant_direct(db, input)` wraps `query_create_role_grant`
 for tests needing an active role_grant seeded directly, bypassing the
 production offer/accept consent flow. Use only when the test focuses on
@@ -103,6 +112,7 @@ mismatch.
 ### `audit_drift_guard.ts` — audit-emission validation
 
 - `install_audit_drift_guard()` — `beforeEach` resets + `afterEach` zero-checks the `audit_metadata_validation_failures` + `audit_unknown_event_type_failures` counters from `auth/audit_log_queries.ts` and the emitter's write-failure counter (`get_audit_write_failures` in `auth/audit_emitter.ts`). Call once at the top of any `describe_db` block firing audit emits — production validation and the emitter's write are fail-open, so without this any regression shipping a typo'd `event_type` or undeclared metadata field, or losing a row the database refused, is silent. A test that fails a write on purpose resets the counter (`reset_audit_write_failures`) once it has asserted it.
+- `assert_audit_event_metadata(event, {reject_unknown_keys?})` — the wire-side twin: parses a read audit row's `metadata` against its builtin event type's `audit_metadata_schemas` entry as declared, so a mistyped, `null`, or missing field fails while a consumer-added key passes (the schemas are `z.looseObject`, and a builtin's schema can't be overridden, so added keys are a consumer's only extension path). `reject_unknown_keys` closes the world: an undeclared key fails too, for a suite whose backend adds none. The wire schema leaves `metadata` a loose record and only the TS spine validates it, at insert and fail-open, so this is what holds every spine's rows to their event's contract. A consumer-registered event type passes unexamined. `list_audit_events` and the admin suite run it on every row they read, with `reject_unknown_keys` from the fixture's `reject_unknown_audit_metadata_keys` (a setup option on `default_cross_process_setup`, `default_in_process_setup` and `default_in_process_suite_options`); fuz_app's own spine wiring turns it on.
 - `assert_no_audit_drift()` — the zero-check itself, for a test that manages the counters. Pair with `await_pending_effects: true` (the `create_test_app` default) so fire-and-forget audit writes complete by response time.
 - `create_recording_audit_emitter(calls_ref?)` — no-op `AuditEmitter` pushing every `emit` and `emit_pool` call into `calls`. Pass `calls_ref` to write into a caller-owned array; omit to let the helper allocate. Returns `{emitter, calls}` — destructure `emitter` as the `audit` dep and read `calls` to assert. `add_listener` records (never fires) and returns a remover with the production semantics, so `listener_count` tracks what a server registered and released. Replaces per-file capturing emitters previously duplicated across `password_change.test.ts`, `audit_log.test.ts`, etc.
 - `RecordingAuditEmitter` — `{emitter: AuditEmitter; calls: Array<AuditLogInput>}`.
@@ -295,6 +305,87 @@ assert_schema_snapshots_equal(snapshot_deno, snapshot_rust, { a: 'deno', b: 'rus
 Each impl's _own_ tests still gate its DDL correctness independently — this
 pair is purely the cross-impl drift check.
 
+## Cross-impl differential
+
+The behavioral twin of the two parity gates above: where they compare
+declarations (DDL, the method set), this compares answers. Each impl is the
+oracle for the other — a case the table pins by status alone, or an extra
+field a loose output schema passes on one spine, shows up as a difference.
+
+- `cross_backend/differential_normalize.ts` — `normalize_differential_response({status, headers, body})`
+  → `DifferentialResponse` `{status, body, header_names}`. Volatile values
+  become positional placeholders per kind (`VOLATILE_VALUE_PATTERNS`: API
+  tokens, `tok_` token ids, lowercase UUIDs, `ISO8601_SECONDS` timestamps,
+  bare 64-hex digests — matched inside any string, object keys included): the
+  first UUID is `<uuid:1>`, a repeat of it `<uuid:1>` again, so identity
+  relations within one response survive while the values differ across
+  backends. Placeholders are positional, not tied to fixture identity, so two
+  ids that appear once each and trade places normalize equal. Only the
+  canonical spelling is placeholdered — an uppercase UUID or a millisecond
+  timestamp stays raw and differs — and a `blake3:` content address is
+  compared verbatim (equal bytes hash equal on both spines). Keys are sorted (and visited
+  in that order when numbering); array order is kept. `header_names` is the
+  sorted name set minus `VOLATILE_HEADER_NAMES` (framing and per-request
+  headers each server sets its own way); values are never compared —
+  `set-cookie` carries a fresh credential, and the contract header values are
+  the conformance table's `expect.headers` + no-fingerprint floor.
+  `diff_differential_responses(a, b)` → `DifferentialDiff[]`, one per leaf
+  path (`status`, `headers.<name>`, `body.error.data.reason`; an object one
+  side lacks diffs key by key, and an empty one against a missing one at its
+  own path), `differential_path_covers(covered, path)`,
+  `format_differential_diffs(diffs, labels)`.
+- `cross_backend/differential.ts` —
+  `describe_differential_conformance_tests({cases, backends: [a, b],
+  surface_source, rpc_endpoints, live_rpc_endpoints?, session_options,
+  principals?, known_divergences?, suite_name?})`, each backend `{name,
+  setup_test, ws?}`; methods resolve as the table resolves them
+  (`resolve_conformance_rpc_endpoints`).
+  `ws` on both runs the cases over their WebSocket endpoints, filtered by
+  `is_ws_conformance_case`, with the ledger checked against what is left; on
+  one alone, registration throws. Per case, each backend's own `setup_test`
+  (separate databases and keepers), the principal resolved and the request
+  sent through `send_conformance_case` (`conformance_table.ts`), both answers
+  normalized and diffed. The per-case `expect` is not asserted —
+  each backend's conformance leg holds it. `KnownDivergence` is the ledger
+  row: `{case_name | method, tracking_id, reason, what_differs}`, the names a
+  string or a list, `what_differs` the diff paths covered (a path covers
+  everything under it), each a string or a `KnownDivergencePath`
+  `{path, a?, b?}` pinning the value a side shows there (`undefined` for
+  nothing). A pin is compared with the normalized leaf value at the differing
+  path, so a placeholdered value never matches the raw one, an object pin
+  must list its keys sorted, and a parent-path pin never matches. A case may
+  differ at the paths of the entries it matches, with their values, and
+  nowhere else. `xfail_until`'s turns-red semantics clean
+  the ledger: a case a `case_name` entry names must still show it (checked in
+  that case's test), a `method` entry must still show on one of its cases
+  (checked by a closing test once they all ran — a filtered or failed run
+  leaves it unjudged, and the test skips when nothing was judged), and an
+  entry matching no case, or listing a case name that doesn't exist or a
+  method no case sends, fails —
+  the static half is `check_known_divergence_ledger(cases, ledger)`, exported
+  for checking a ledger without a backend. No other ignore path exists.
+
+fuz_app runs it under the `cross_backend_parity` project
+(`differential.cross.test.ts`, its ledger `differential_known_divergences.ts`
+in `src/test/cross_backend/`): every `conformance_*_cases.ts` array plus the
+generated auth rows (over the live mount too, so the cell verbs, the actor
+resolvers and the `_testing_*` backdoors are compared), TS spine vs
+`testing_spine_stub`, both on Postgres so no engine difference reads as a body
+difference. The same cases run again over
+WS, against `differential_ws_known_divergences` (the HTTP ledger without its
+header row). The multi-actor `conformance_acting_cases.ts` rows run with the
+generated rows on a keeper seeded with `extra_actors`, over both transports.
+The TS spine runs under `DEV` there, so its DEV-only diagnostics (Zod
+`issues` on `invalid_params`, the `X-Fuz-Auth-Debug` header) are ledger rows.
+The suite composition is `describe_spine_differential_suites`
+(`src/test/cross_backend/spine_differential.ts`), which takes the two
+backends and their ledgers. fuz_app also holds two TS runtimes to each other
+with it: the `cross_backend_ts_differential` project
+(`differential_ts.cross.test.ts`) dual-spawns the TS spine binary on Node and
+on Bun, both on `memory://`, against an empty ledger — both run under `DEV`,
+so the DEV-only rows show on both sides and differ nowhere. It needs no Rust
+or Postgres and runs in the `cross-ts` CI job.
+
 ## Assertions, coverage, helpers
 
 ### `assertions.ts` — surface + error-schema assertions
@@ -383,11 +474,15 @@ Support functions:
 
 Walks Zod schemas to generate valid values for adversarial/round-trip tests.
 
-- `detect_format(field_schema)` — reads `format` / `pattern` from the JSON Schema representation.
-- `generate_valid_value(field, field_schema)` — base-type switch producing a valid sample (UUIDs → nil UUID, strings → `'xxxxxxxxxx'`, numbers → `1`, objects → recurse, enums → first entry, etc.). For branded-string refinements, walks a fallback chain synthesized from the `pattern` string the JSON Schema representation exposes: fixed-length hex (`^[0-9a-f]{N}$` — blake3 / sha256 / md5 digests; `0`.repeat(N)), prefix-lengthed slug (`^<prefix>_[A-Za-z0-9_-]{N}$` — `ApiTokenId`-style ids; `<prefix>_` + `x`.repeat(N)), absolute path prefix, URL prefix. First candidate that `safeParse` accepts is used.
+- `to_field_json_schema(field_schema)` — the field's JSON Schema rendered with `io: 'input'`, so a `.transform()` or pipe field (`Username`) yields its input-side bounds and pattern instead of throwing; a `.nullable()` / `.nullish()` field's one non-null `anyOf` branch is returned; `null` for a type JSON Schema can't represent. A pipe yields its input stage only, and a `.refine()` never appears (a code-point length bound generates nothing). Every JSON Schema read in the generators goes through it.
+- `detect_format(field_schema)` — `detect_json_schema_format` over `to_field_json_schema`: the `format`, `'pattern'` for a regex, or `null`.
+- `generate_valid_value(field, field_schema)` — base-type switch producing a valid sample (UUIDs → nil UUID, strings → `'xxxxxxxxxx'`, numbers → `1`, objects → `generate_valid_object` against the field schema, so a nested refinement is satisfied too, enums → first entry, etc.). For branded-string refinements, walks a fallback chain synthesized from the `pattern` string the JSON Schema representation exposes: fixed-length hex (`^[0-9a-f]{N}$` — blake3 / sha256 / md5 digests; `0`.repeat(N)), prefix-lengthed slug (`^<prefix>_[A-Za-z0-9_-]{N}$` — `ApiTokenId`-style ids; `<prefix>_` + `x`.repeat(N)), absolute path prefix, URL prefix, two `/`-joined segments (an `owner/name` slug). First candidate that `safeParse` accepts is used.
+- `generate_valid_string_param(field, field_schema)` — a string a URL-sourced field (route param, query value) accepts: the nil UUID for a UUID field, else the first of `test_value`, the generated valid value as a string, `1`, `0`, `true`, `false`, the field's JSON Schema `default` or lower bound as a string (a preprocessed integer whose minimum is above one) and a synthesized string the field accepts; `null` when none does. The params and query case generators build their base from it.
 - `resolve_valid_path(path, params_schema?)` — swaps `:param` for a value the params schema accepts. Prefers `test_<name>` wherever the field schema admits it (the param name keeps failure messages readable); otherwise a UUID param takes the nil UUID and anything else is synthesized from the schema, percent-encoded. A synthesized value containing `/` is refused (it would route elsewhere) and falls back to `test_<name>`.
 - `to_route_content_type(route)` — the `Content-Type` a well-formed request to the route sends: `application/json`, or `application/octet-stream` for a `raw_body` route. Every `POST` route refuses anything else with 415 before its other gates, so every probe in the harnesses (auth, params and query fuzz, 404, data exposure, round trip) sends it, body or not.
-- `generate_valid_body(input_schema) => Record<string, unknown> | undefined` — builds a body satisfying the input schema. Throws with Zod `issues` if the generated body fails validation — surfaces broken generation logic with a descriptive error rather than a confusing 400 downstream.
+- `generate_valid_object(object_schema, schema) => {value, result}` — required and defaulted fields; when `schema` (refinements included) refuses those, each optional field alone in declaration order, the first that parses; failing that, the optional fields added cumulatively until it parses. Covers a `.refine()` over optional fields (at least one of, exactly one of, both of) at any depth, and, where one optional field suffices, keeps the others (an `acting` declared first) out. Returns the last `safeParse` result and leaves the throw to the caller. `format_zod_issues(error)` renders the issues for those errors.
+- `generate_valid_object_with_field(object_schema, schema, base, field)` — a valid object carrying `field`, built from the valid `base`: `base` itself when it carries the field; else the field joins `base`, with the optional fields `base` omits filled as `generate_valid_object` fills them (a pair rule: `scope_kind` needs `scope_id`); failing that, the field replaces `base`'s optional fields, refilled around it (exactly one of: adding `slug` drops `id`). `null` when no object the generator builds carries the field. The body a single-fault case on a field the base omits changes.
+- `generate_valid_body(input_schema) => Record<string, unknown> | undefined` — builds a body satisfying the input schema (`generate_valid_object`). Throws with Zod `issues` if the generated body fails validation — surfaces broken generation logic with a descriptive error rather than a confusing 400 downstream.
 
 ### `integration_helpers.ts` — route lookup + body checks
 
@@ -432,7 +527,7 @@ Also exported: `describe_adversarial_auth(options)` (group 3 on its own) and
 `build_error_schema_lookup(specs, middleware_specs?)` (pre-built
 `Map<string, RouteErrorSchemas>` for per-response validation).
 
-### `adversarial_input.ts` — schema-walk payload generation
+### `adversarial_input.ts` + `adversarial_input_cases.ts` — schema-walk payload generation
 
 `describe_adversarial_input({build, roles})` — fires input body / params /
 query validation failures at every route with correct-auth credentials so
@@ -440,11 +535,15 @@ validation middleware is actually exercised (not short-circuited by 401).
 All cases expect 400 with one of `ERROR_INVALID_REQUEST_BODY` /
 `_INVALID_JSON_BODY` / `_INVALID_ROUTE_PARAMS` / `_INVALID_QUERY_PARAMS`.
 
-Exported generators:
+The generators live in the hono-free `adversarial_input_cases.ts`, so the
+cross-process suites reuse them:
+
+- `generate_input_test_cases(input_schema, options?)` → `InputTestCase[]` — whole-body structural (non-object, extra key when `strictObject`), missing required fields, one wrong-type per field, null for required non-nullable, one format violation per constrained field, and boundary cases read from the field's input-side JSON Schema (`to_field_json_schema` — through a transform or pipe, and under a nullable's `anyOf`): the empty string, one under `minLength` (above one; a prefix of the valid value) and one over `maxLength`; below `minimum`, above `maximum`, at an exclusive bound, zero and negative for a positive-only field, a non-integer for an integer field and a value off a `multipleOf` grid (each half a step from the valid value, inside the range); the empty array, one under `minItems` (above one; the valid value's own items) and one over `maxItems`. A per-field case is emitted only when the field refuses its value (a `z.coerce` field given a wrong type, a pattern admitting the violation string, a preprocess that repairs the value: dropped), so no generated case is accidentally valid. Each per-field case is single-fault — valid but for the field it breaks: it changes one field of a valid base (`generate_valid_object`'s, or `options.base` (`InputTestCaseOptions`) for an input whose valid shape the generator can't reach), or, for a field that base omits, of the body `generate_valid_object_with_field` builds around it, so a case can't also break an object-level rule. A field no valid body carries keeps its wrong-type and null cases on the base and gets no format or boundary cases. Either base failing the schema throws, naming `options.label` (the method or route) when given. A per-field case names the field it breaks (`InputTestCase.field`; absent on the whole-body cases).
+- `expected_invalid_reason(input_schema, test_case)` → `string | undefined` — the `data.reason` an RPC refusal of the case owes: the broken field's `invalid_reason` (`schema_meta.ts`), resolved by the same `resolve_invalid_reason` the dispatcher resolves through, or none for an undeclared field or a whole-body case.
+- `generate_params_test_cases(params_schema)` → `ParamsTestCase[]` — format violations only (unconstrained string params accept anything), each one the field refuses.
+- `generate_query_test_cases(query_schema)` → `QueryTestCase[]` — missing required fields the field refuses to go without (a preprocessed field with a default accepts its absence) + format violations the field refuses.
 
-- `generate_input_test_cases(input_schema)` — whole-body structural (non-object, extra key when `strictObject`), missing required fields, one wrong-type per field, null for required non-nullable, one format violation per constrained field, numeric/array/string boundary cases via JSON Schema introspection.
-- `generate_params_test_cases(params_schema)` — format violations only (unconstrained string params accept anything).
-- `generate_query_test_cases(query_schema)` — missing required + format violations.
+Both build their base from `generate_valid_string_param` and check it against the whole schema, throwing when a field has no string it accepts or the record fails, so each case breaks one field of a valid record (a URL-sourced integer such as `db_routes`' `offset` / `limit` gets `'1'`, not a `test_value` it refuses).
 
 GET-with-input routes hit the RPC `?params=` query convention; invalid-JSON
 arrays there collapse to `ERROR_INVALID_REQUEST_BODY` (schema failure)
@@ -509,9 +608,15 @@ the response against declared schemas. DB-backed via `create_test_app`.
 Per-route test (`test.each`) — one line per route in the vitest output.
 
 Options: `{setup_test, surface_source, skip_routes?, input_overrides?, success_fixtures?}`.
-`input_overrides` is a `Map<"METHOD /path", body>` — override generated
-bodies for routes whose input schema can't round-trip cleanly (e.g. fields
-that must reference DB state).
+Principals and the 401 check are the RPC round-trip's (`pick_auth_principal`;
+`assert_route_authenticated` over `is_unauthenticated_refusal`, reading the
+flat `error`), and a non-`GET` route called as the authed
+account runs on a fresh account — a generated logout would otherwise end the
+shared session, leaving `/password` and every later authed route a vacuous
+401. `src/test/testing/round_trip.test.ts` pins both, the RPC test's twin.
+`input_overrides` is a `Map<"METHOD /path", body>` — override generated bodies
+for routes whose input schema can't round-trip cleanly (e.g. fields that must
+reference DB state).
 
 SSE routes are skipped by Content-Type sniff; `describe_sse_route_tests`
 picks them up separately.
@@ -521,9 +626,62 @@ picks them up separately.
 DB-backed round-trip for RPC: one POST test for all methods, one GET test
 for `side_effects: false` methods. Successful responses validate against
 `action.spec.output`; error responses validate as well-formed JSON-RPC error
-envelopes. Options: `{setup_test, surface_source, session_options, rpc_endpoints, skip_methods?, input_overrides?, success_fixtures?}`.
-The admin RPC auth test picks a session-based identity (`authed` / `admin` /
-bootstrapped keeper) based on `method.auth`; keeper uses the daemon token.
+envelopes. Three refusals fail instead of passing as an envelope: `method not
+found` (the backend lacks a method the surface declares), a crash — HTTP
+500, the `internal_error` code (-32603), or a ≥500 whose body is no JSON-RPC
+envelope — and a 401 to a non-public call (`assert_rpc_authenticated`): the
+call carried a credential its auth admits, so a 401 means it stopped working.
+A public method may still answer 401 (a wrong-password login), and so may a
+handler naming its own reason (below). A ≥500 carrying a declared code
+(`service_unavailable` 503, `timeout` 504, a consumer code declared with
+`register_jsonrpc_error_code`) is a server condition and passes like a
+4xx. The failure names the method, status, code and message; a non-JSON body
+is reported as text. Options: `{setup_test, surface_source, session_options,
+rpc_endpoints, skip_methods?, input_overrides?, success_fixtures?}`.
+`pick_rpc_auth` picks the principal from `method.auth` through
+`pick_auth_principal` (`integration_helpers.ts`, shared with the REST
+round-trip; `AuthPrincipal`): none for a public method, the keeper's daemon
+token when `credential_types` names it, the admin account's session for an
+admin-gated method, the keeper's session for another role, else the authed
+account's session. The 401 check is `is_unauthenticated_refusal`: a 401
+reading `authentication_required` or naming no reason fails; a handler's own
+401 reason on an authenticated call (`invalid_credentials` for a wrong current
+password) passes. So a handler that answers 401 to a valid credential must name
+its reason — `data.reason` over RPC, the flat `error` over REST: a reason-less
+401 reads as unauthenticated and fails the round-trip. TS's
+`jsonrpc_errors.unauthenticated(message)` sends no `data` unless given one, so
+pass `{reason}` as its second argument.
+
+A side-effecting method picked for the authed account runs on a fresh account
+of its own (`round_trip_uses_fresh_account`, keyed on the spec's
+`side_effects`): generated params omit optional fields, and an omitted target
+on a self-service method is the caller — `account_delete` with no
+`account_id` deletes it, `account_session_revoke_all` ends its session — which
+on the shared account would turn every later account method into a 401. Keyed
+on `side_effects` rather than a list of known destroyers, so a consumer's
+self-targeting method is covered without registering it. The keeper, its
+daemon token and the admin account stay shared (one keeper per fixture, and
+admin methods with generated nil ids target no existing account); a
+credential they lose still fails on the 401 check.
+`src/test/testing/rpc_round_trip.test.ts` pins both against a fake backend
+whose side-effecting method ends the caller's session.
+
+`success_fixtures` (`RpcSuccessFixtures`, method → `(fixture) =>
+Promise<RpcSuccessFixtureCase>`) drives a **success** response for a method
+whose generated nil ids can only refuse: the factory builds the row, then
+returns `{params, headers?}` — `headers` replaces the picked identity, for a
+row only its owner may act on. The response must be `ok`, not an internal
+failure, and parse against `output`. `cross_backend/rpc_success_fixtures.ts`
+— `create_spine_rpc_success_fixtures({rpc_path?})` builds the map for the
+standard spine methods that act on an existing row (`account_token_revoke`,
+`account_session_revoke`, `invite_delete`, `role_grant_revoke`,
+`role_grant_offer_accept` / `_decline` / `_retract`) from standard RPC
+actions and the builtin `ROLE_ADMIN` only, each factory on fresh accounts
+and calling as one of them, so any consumer mounting
+`create_standard_rpc_actions` can pass it. The fixtures run last on the
+describe's fixture, since they mutate.
+fuz_app wires it through the standard bundle and in the in-process
+`cross_backend/rpc_round_trip_spine.db.test.ts`.
 
 ### `sse_round_trip.ts` — `describe_sse_route_tests`
 
@@ -666,7 +824,12 @@ lifecycle (via `role_grant_offer_create` + `role_grant_offer_accept` +
 `role_grant_revoke` RPC flows — **not** REST, **not** direct
 `query_accept_offer`; see `auth/CLAUDE.md` for
 `role_grant_offer_action_specs.ts` + `role_grant_offer_actions.ts`),
-session / token management, audit log reads (RPC), admin-to-admin
+session / token management, audit log reads (RPC — every row read is
+parsed by `assert_audit_event_metadata`, closed to undeclared keys when the
+fixture asks, and the completeness test drives login, logout, the offer flow,
+grant + revoke, token create, password change, and — each where the surface
+mounts its actions — token revoke, session revoke, invite create + delete and
+`app_settings_update`), admin-to-admin
 isolation, error coverage, response schema validation.
 
 The shared `role_grant_offer_and_accept` helper (`role_grant_helpers.ts`)
@@ -679,6 +842,12 @@ from `db_entities.ts`.
 
 Required options: `{setup_test, surface_source, session_options, rpc_endpoints: RpcEndpointsSuiteOption, roles: RoleSchemaResult, admin_prefix?}`.
 
+fuz_app runs it cross-process through the standard bundle
+and in-process as a consumer wires it
+(`cross_backend/admin_integration_spine.db.test.ts`) — the in-process fixture's
+`create_account` inserts rows directly, writing no `invite_create` or `signup`
+audit row, so the suite expects neither from it.
+
 `rpc_endpoints` is `Array<RpcEndpointSpec> | ((ctx: AppServerContext) => Array<RpcEndpointSpec>)` —
 the same `RpcEndpointsSuiteOption` union every DB-backed suite accepts
 (`integration`, `admin_integration`, `audit_completeness`, `rate_limiting`,
@@ -763,6 +932,13 @@ invokes the right per-test fixture. Consumers wiring the standard surface
 call once instead of seven times; forgetting a suite no longer silently
 loses coverage.
 
+`rpc_success_fixtures`, `rpc_skip_methods` and `rpc_input_overrides`
+forward to the RPC round-trip's `success_fixtures`, `skip_methods` and
+`input_overrides` (same options on `describe_standard_cross_process_tests`;
+`describe_spine_cross_suites` also forwards `rpc_input_overrides` to
+`rpc_adversarial`) — `rpc_skip_methods` is the consumer escape hatch for a
+method the generic round-trip can't drive in its test wiring.
+
 `StandardTestOptions` requires `create_route_specs` (for rate_limiting) and
 `rpc_endpoints` (for admin/audit_completeness/rpc_round_trip); the admin
 suite's requirement is enforced at the type level so a missing
@@ -810,6 +986,7 @@ One-shot transport:
 - `RpcCallResult` — discriminated `{ok: true, status, headers, result}` / `{ok: false, status, headers, error: {code, message, data?}}`. `headers` is the lowercased-key response-header snapshot so callers can assert header-level properties (e.g. the conformance runner's no-fingerprint invariant).
 - `headers_to_record(headers)` — snapshot a `Headers` into a lowercased-key `Record<string, string>` (multi-value collapses to the comma-joined form; `Set-Cookie` excluded). Used by `rpc_call` and the conformance table's REST branch to thread response headers through for assertions.
 - `RpcCallArgs` — `{app, path, method, params?, headers?, id?, verb?}`. `verb` defaults to `'POST'`; use `'GET'` for `side_effects: false` methods.
+- `rpc_call_raw(args)` — the same request as `rpc_call`, the response unparsed: `RpcCallRawResult` `{status, headers, body}` with the whole envelope. `parse_rpc_call_result(raw, method)` turns it into an `RpcCallResult`; `rpc_call` is the two composed.
 - `rpc_call(args)` — merges `RPC_CALL_DEFAULT_HEADERS` (`host: 'localhost'`, `origin: 'http://localhost:5173'`, `Content-Type: 'application/json'`) under caller headers. Envelope-shape violations throw; JSON-RPC errors return `{ok: false, error}` so callers assert on `error.code` / `error.data.reason`.
 - `rpc_call_typed<T>(args, output_schema)` — parses the success `result` through the schema; throws on envelope failure, error response, or schema mismatch. Use `rpc_call` when the test needs to assert on error shapes.
 - `rpc_call_for_spec<TSpec>(args)` — spec-bound variant: takes `{..., spec, params}` in place of `{..., method, params}`. `params` is typed from `spec.input` and the success `result` is typed from `spec.output` (runtime-validated, same contract as `rpc_call_typed`). Error branch stays untyped (JSON-RPC `error.data` shapes vary per call site). Use at happy-path + denial-path call sites; fall back to `rpc_call` for adversarial tests that send deliberately-malformed params.
@@ -822,7 +999,7 @@ Registry lookups:
 - `RpcEndpointsSuiteOption` — union `Array<RpcEndpointSpec> | ((ctx: AppServerContext) => Array<RpcEndpointSpec>)` accepted by every DB-backed suite's `rpc_endpoints` field.
 - `resolve_rpc_endpoints_for_setup(rpc_endpoints, session_options)` — resolves the union to an array for setup-time inspection (path lookup, `find_rpc_action` presence checks). Factory form is invoked once with a stub `AppServerContext`; the produced actions are discarded because `create_app_server` invokes the factory a second time per-test with its real ctx. Safe when the factory is pure wrt endpoint `path` and action `spec.method` list.
 
-### `rpc_attack_surface.ts` — `describe_rpc_attack_surface_tests`
+### `rpc_attack_surface.ts` + `rpc_envelope_cases.ts` — `describe_rpc_attack_surface_tests`
 
 3 test groups for JSON-RPC endpoints:
 
@@ -833,13 +1010,13 @@ Registry lookups:
    - **keeper rejects non-daemon credentials** — session and api_token credentials are rejected even when the account has the keeper role (only `daemon_token` passes). The credential-type gate fires before the role gate (see `auth/CLAUDE.md` §Keeper auth shape).
    - correct auth passes (not 401/403)
    - GET unauthenticated for `side_effects: false` reads
-2. **RPC adversarial envelopes** — fixed set exercising dispatcher steps 1–2: non-JSON body, wrong `jsonrpc` version, missing `jsonrpc` / `method` / `id`, batch array, unknown method, GET missing `method`/`id`, GET invalid JSON params, GET non-object params, GET mutation method → `invalid_request`.
-3. **RPC adversarial params** — reuses `generate_input_test_cases` but filters out structural cases (those hit envelope validation at step 1, not params validation at step 5). Every case expects 400 `invalid_params`.
+2. **RPC adversarial envelopes** — the fixed set `create_rpc_envelope_cases(endpoint, {skip_methods?})` builds, exercising the envelope parse, method lookup, and GET read restriction: non-JSON body → `parse_error`, wrong `jsonrpc` version, missing `jsonrpc` / `method` / `id`, batch array, non-object POST `params` → `invalid_request`, unknown method → `method_not_found`, GET missing `method`/`id` → `invalid_request`, GET invalid-JSON params → `invalid_params`, GET non-object params on **every** read (each of `RPC_NON_OBJECT_PARAMS`: a number, an array, a string, a boolean) → `invalid_params`, GET mutation method → `invalid_request`, plus three ordering cases sent with no credential (an anonymous GET mutation and an anonymous batch, both `invalid_request`, never 401; an anonymous GET with non-object params on a read requiring an identity, the 401 — params validation runs after authorization). Each case is sent by the app its method's auth admits (`select_auth_app`) and pins status, code, echoed `id`, and `data.reason` (exact where the dispatcher sets one, absent otherwise) via `assert_rpc_envelope_refusal`. The cases are data (`RpcEnvelopeCase`) in the hono-free `rpc_envelope_cases.ts`, shared with the cross-process `describe_rpc_adversarial_cross_tests`; `to_rpc_envelope_request` builds a case's request, and `rpc_get_side_effects_reason(method)` is the GET read restriction's reason.
+3. **RPC adversarial params** — `generate_rpc_params_test_cases(input, options?)` (`rpc_envelope_cases.ts`): `generate_input_test_cases` minus its structural cases (a non-object `params` is refused at the envelope, not at params validation), taking the same `{base?, label?}`. Every case expects 400 `invalid_params` with `data.reason` the broken field's declared `invalid_reason` (`expected_invalid_reason`), absent for an undeclared field. Shared with the cross-process suite. `input_overrides` (method name → valid params) seeds a method's cases from that base; an override its schema refuses throws at collection, naming the method.
 
 Skips silently when `surface.rpc_endpoints` is empty. Uses stub deps — no
 DB needed.
 
-Options: `{build: () => AppSurfaceSpec, roles: Array<string>}`.
+Options: `{build: () => AppSurfaceSpec, roles: Array<string>, input_overrides?}`.
 
 **Opt-in bundles need their own per-bundle suite file.** Action bundles not
 folded into `create_standard_rpc_actions` (today `self_service_role_actions`,
@@ -874,10 +1051,17 @@ test-server core below (fuz_app's own domain-free `testing_spine_server`, run
 on Node + Deno + Bun). In-process is the fast feedback path; cross-process is the
 source of truth for wire-shape conformance.
 
+fuz_app's own spines run every single-backend suite below through one
+`describe_spine_cross_suites` call, `src/test/cross_backend/spine_suites.cross.test.ts`
+(§`cross_backend/spine_suites.ts`), so a suite's section names the suite, not a
+file; the dual-spawn and limiter-enabled suites name their own files.
+
 ### Fixture protocol + capabilities
 
 - `testing/cross_backend/setup.ts` — `SetupTest` / `TestFixture` /
-  `TestAccountFixture` / `CreateTestAccountOptions` types,
+  `CreateTestAccountOptions` types (`fixture.create_account` and
+  `fixture.extra_accounts` hand out `TestAccount`s from `app_server.ts`, built
+  by `to_test_account`),
   `default_in_process_setup(options)` (wraps `create_test_app`; pass
   `migration_namespaces` for suites needing tables beyond the auth-only
   default — the cell parity suite passes `[CELL_MIGRATION_NS]`, and
@@ -913,7 +1097,11 @@ source of truth for wire-shape conformance.
   lands with an email set — the hook the username-or-email login parity suite
   uses; the in-process path sets it directly on the inserted row. Must be a
   valid, per-test-unique `Email` (the `LOWER(email)` partial-unique index
-  rejects collisions). Caller-supplied `username`s pass through _as-is_ now that the DB
+  rejects collisions). The signup and login it drives go to the setup's
+  `signup_path` / `login_path` (default `SPINE_ACCOUNT_SIGNUP_PATH` /
+  `SPINE_ACCOUNT_LOGIN_PATH`, from `spine_surface_constants.ts`, which also
+  carries the other account routes, `SPINE_WS_PATH`, and the prefix).
+  Caller-supplied `username`s pass through _as-is_ now that the DB
   wipes between tests — hardcoded names like `'user_two'` work and the
   earlier uniquification prefix is gone. Every `TestFixture` also exposes
   `fresh_transport({origin?: string | null})` — cookie-jar-free probe;
@@ -930,22 +1118,34 @@ source of truth for wire-shape conformance.
 
 - `testing/cross_backend/capabilities.ts` — `BackendCapabilities` vocabulary
   (the **gating** flags `ws` / `sse` / `cell_crud` / `cell_relations` /
-  `cell_gated_create` / `account_lifecycle` / `fact_serving` / `ready` /
+  `cell_gated_create` / `account_lifecycle` / `fact_serving` /
+  `fact_serving_admin_hash` / `ready` /
   `account_status` / `peer_request` /
   `ws_handshake_pipelining` / `ws_account_actions` /
   `ws_role_gated` / `ws_refusal_body` — each has a `test_if`
   reader (`ws_refusal_body` picks how the front-door table reads a WS
   refusal instead); `peer_request` (server-initiated requests — the ActionPeer
-  `peer/ping` round-trip) is `true` for both the Rust spine and the TS spine
-  (`BackendWebsocketTransport.request_connection`); `ts_default_capabilities`
-  keeps it `false` like sse/ready until a backend wires the `peer/ping` HTTP +
-  WS mount), `test_if(cond, name, fn)`
-  for capability-gated cases, and `in_process_capabilities` preset. The
-  non-gating wiring facts (`bearer_auth` / `trusted_proxy` / `login_rate_limit`,
-  no `test_if` readers) live in the parallel `BackendShapeNotes` record
-  (`in_process_shape_notes`; `ts_default_shape_notes` / `rust_default_shape_notes`
-  in `default_backend_configs.ts`) — split out so the capability type stops
-  claiming gating it doesn't do. `cell_crud`
+  `peer/ping` round-trip) is `true` on fuz_app's Rust and TS spine presets
+  (`BackendWebsocketTransport.request_connection`); a backend states it
+  `true` once it wires the `peer/ping` HTTP + WS mount), `test_if(cond, name, fn)`
+  for capability-gated cases, and `in_process_capabilities` preset. Only
+  flags a suite reads are capabilities — a wiring fact that gates nothing is
+  not recorded. **Mount flags have no family default**: `MountFlag` names the
+  flags that describe a backend's own mounts (`ws`, `sse`, `cell_crud`,
+  `cell_relations`, `cell_gated_create`, `fact_serving`,
+  `fact_serving_admin_hash`, `ready`,
+  `peer_request`, `ws_account_actions`, `ws_role_gated`), and the family
+  defaults (`ts_default_capabilities` / `rust_default_capabilities`, typed
+  `FamilyDefaultCapabilities`) omit them and the `testing_backdoors` list (the
+  `_testing_*` backdoors the backend mounts, from `TESTING_BACKDOOR_METHODS` —
+  §Testing-backdoor declaration below; `[]` in-process, every one on fuz_app's
+  spine presets), with `capabilities` required on
+  `make_default_{ts,rust}_backend_config` — so a config that leaves one out
+  fails typecheck naming it, rather than silently skipping its suites. The
+  family defaults carry the declared surface's mounts (`account_lifecycle`,
+  `account_status`) and the runtime-behavior flags (`ws_handshake_pipelining`,
+  `ws_refusal_body`) of the family's reference runtime — Node for TS, hyper
+  for Rust; a backend on another runtime (Deno, Bun) overrides them. `cell_crud`
   gates the CRUD parity suite, `cell_relations` the relation / ACL / audit
   parity suite — both `true` on every backend that live-mounts the full cell
   surface (TS spine binary, in-process app, Rust stub). A backend mounting only
@@ -965,15 +1165,19 @@ source of truth for wire-shape conformance.
   auto-enumerated for shape/auth) — the flag gates the behavioral parity the
   generic round-trip can't drive (it can't delete the subject). `true` on every
   spine. `fact_serving`
-  gates `describe_fact_serving_cross_tests` (the cell-scoped per-reference +
-  admin-only bare-hash fact-serving parity suite, incl. the served fact's
-  hardening headers and bodyless masked 404s); like cells it stays off the
-  declared surface and is `true` on every spine that mounts the serve routes +
+  gates `describe_fact_serving_cross_tests` (the cell-scoped per-reference
+  fact-serving parity suite, incl. the served fact's hardening headers and
+  bodyless masked 404s); like cells it stays off the declared surface and is
+  `true` on every spine that mounts the cell-gated serve route +
   the `_testing_put_fact` seeder (whose optional `holder` records a
   `fact_holder` row, so a non-admin can reference what it seeds, and whose
   optional `external_url` writes a bare external row naming that URL, so the
   suite can pin that a URL naming another hash's file is refused) — it also
-  gates `describe_cell_ref_admission_cross_tests`. `ready` gates `describe_ready_cross_tests`
+  gates `describe_cell_ref_admission_cross_tests`. `fact_serving_admin_hash`
+  is the admin-only bare-hash route (`GET /api/facts/:hash`), its own flag
+  because a backend can serve the cell-gated route alone: it gates the
+  fact-serving suite's bare-hash cases (with `fact_serving`) and the bare-hash
+  cases of the query-shape and token-scope-surface suites. `ready` gates `describe_ready_cross_tests`
   (anonymous `GET /ready` → `200 {ready: true}` on a clean spine bootstrap);
   like cells/sse the `/ready` deploy gate stays off the declared surface, `true`
   on every spine that live-mounts it over the shared `expected_schema.json`.
@@ -993,7 +1197,7 @@ source of truth for wire-shape conformance.
   as it does behind auth, and `false` in-process, where there is no socket to
   write raw bytes to).
   `ws_account_actions` (the WS endpoint mounts the account actions — `true` on
-  fuz_app's own spine presets, `false` in the family defaults) gates the WS
+  fuz_app's own spine presets; a consumer states it like every mount flag) gates the WS
   round-trip suite's self-revocation case (which requires the reply ahead of
   the close on every backend) and, with `rpc_path`, its WS-mutation audit case
   (which calls `_testing_drain_effects`).
@@ -1026,6 +1230,171 @@ consumer needs partial opt-out, add the knob then.
 `bootstrap`, `rate_limiting_app_options`, `bootstrap_token`) — those drive
 the omitted suites.
 
+### `cross_backend/spine_suites.ts` — `describe_spine_cross_suites`
+
+One call that runs every shipped single-backend cross suite against one
+spawned backend: `describe_spine_cross_suites(handle, {surface_source,
+session_options, rpc_endpoints, live_rpc_endpoints?, roles?, setup?, exclude?,
+exclude_cases?, overrides?, rpc_success_fixtures?, rpc_skip_methods?, rpc_input_overrides?,
+rpc_max_body_bytes?, ws_max_message_bytes?})`.
+`live_rpc_endpoints` is the backend's whole live mount; given, `rpc_adversarial`
+also walks the methods it keeps off the declared surface. `rpc_input_overrides`
+reaches the standard bundle's RPC round-trip and `rpc_adversarial`'s
+`input_overrides`, so one valid body per method serves both; a key naming a
+method on neither the declared surface nor `live_rpc_endpoints` throws at
+collection. Without it a consumer writes a file per suite, and a suite added
+here never reaches it.
+
+- **The registry.** `SUITE_NAMES` / `SuiteName` — the closed set of suites the
+  call runs, each named by its module (`ws_round_trip` is
+  `describe_cross_process_ws_tests`, `standard` the standard bundle).
+  `STANDALONE_CROSS_SUITES` (keyed by the closed `StandaloneSuiteName`) names
+  the modules left out, each with why: the
+  `differential` (two handles), `login_security` and `ws_action_rate_limit`
+  (a backend spawned with live limiters, which the standard suites would
+  exhaust), and the `conformance_table` runner (the consumer's own cases).
+  `src/test/testing/cross_backend/spine_suites.test.ts` imports every module
+  under `cross_backend/` and holds the two lists to the ones exporting a
+  `describe_*` function, whatever the export form (the Bun and Deno adapters,
+  which load only on their own runtime, are held to naming no `describe_` at
+  all), so a new suite fails until it is registered or stated standalone; the
+  dispatch table
+  is a `Record<SuiteName, …>`, so a registered name without an entry fails
+  typecheck.
+- **Options from the handle.** Paths, cookie name and capabilities come from
+  `handle.config` — `to_cross_suite_options(handle)`, exported for a suite
+  called on its own — the daemon token from the handle, and each suite's
+  `setup_test` from `default_cross_process_setup` over the `setup` options
+  plus the seeding the suite needs (concatenated): a keeper-only
+  `non_admin_keeper` for the standard bundle's keeper ≠ admin probe, the
+  multi-actor keepers of `fact_serving` and `transport_composition`, the
+  offer grantor of `role_grant_offer_enumeration`, the `cell_editor` holder of
+  `cell_grant_role`. Suites are registered without a wrapping `describe`, so
+  test names match a standalone call.
+- **`ws_required_roles`** — the roles the backend's WS upgrade on `ws_path`
+  requires (an admin-gated `/api/ws`: `[ROLE_ADMIN]`). The suites that open
+  sockets for accounts they create (`credential_deadline`, `session_cap`,
+  `ws_round_trip`) create them holding these (`ws_account_roles`), and
+  `role_grant_offer_notification_ws` expects revoking one to close the socket
+  (its `ws_required_roles`) — one option for every socket a role gates.
+- **`rpc_max_body_bytes`** / **`ws_max_message_bytes`** — the backend's
+  request-body cap on `rpc_path` and its inbound WS message cap, when they
+  aren't the spine defaults (`SPINE_BODY_LIMIT_DEFAULT_BYTES`,
+  `DEFAULT_WS_MAX_MESSAGE_BYTES`). The first reaches `body_size`,
+  `body_size_smuggling` and `transport_composition`'s RPC over-cap row (each
+  takes it as `rpc_max_body_bytes`), the second `ws_round_trip`'s
+  `max_message_bytes` — one value per limit for every suite probing it.
+- **`exclude`** — `{[suite]: reason}`; the reason is required and shows in the
+  run as a skipped test. An empty reason, an unknown suite name, a suite
+  both excluded and overridden, `testing_backdoor` (it checks the backdoor
+  declaration the gating reads), or a suite already skipping itself for an
+  undeclared backdoor throws before anything registers.
+- **Backdoors.** `capabilities.testing_backdoors` must declare
+  `SPINE_SUITES_REQUIRED_BACKDOORS` (`_testing_reset`, every setup's per-test
+  reset, and `_testing_drain_effects`, the audit-read barrier), and
+  `_testing_put_fact` when `fact_serving` is declared; the call throws
+  otherwise. A suite every case of which drives another backdoor
+  (`SuiteEntry.backdoors`: `credential_deadline` →
+  `_testing_shorten_credential_expiry`, `origin_conformance` →
+  `_testing_origin_check`, `ws_outbound_overflow` →
+  `_testing_flood_notifications`) skips itself on a backend not declaring it,
+  as a skipped test beside the excludes whose reason names the backdoor; an
+  exclude, override or `exclude_cases` entry for it throws as dead.
+  `spine_suites.test.ts` holds the backdoors each suite module names — quoted
+  `_testing_*` names, `testing_*_action_spec` references, and the
+  `cross_put_fact` / `cross_drain_effects` seeders — to its entry's
+  `backdoors`, the required pair, or `_testing_put_fact` under
+  `capabilities.fact_serving`; a helper module the suite calls isn't read.
+- **`exclude_cases`** — `SuiteCaseExclusions`, `{[suite]: {[name path]:
+  reason}}`: single tests of a suite that runs, each by its name path (the
+  describe titles and the test name joined with `' > '` — what the reporter
+  prints after the file and any `describe` wrapping the call; a full path, not
+  a leaf name, so a title repeated under two describes names one test). One
+  `beforeEach` on the calling suite (`register_spine_case_exclusions`) skips
+  them at run time with `ctx.skip(reason)`, so the suite files stay as they
+  are and each shows as skipped with its reason; it finds a test's suite
+  from the top-level task ranges each suite registered (read through
+  `TestRunner.getCurrentSuite()` at collection), so an entry matches only
+  below its own suite. A reasonless entry, an empty suite map, or an entry for
+  an unknown, excluded or self-skipping suite, or for `testing_backdoor`,
+  throws at collection; an entry
+  naming no test its suite collected fails the closing test
+  (`check_spine_case_exclusions`, which reads the collected paths, so a
+  filtered run still checks them) — the dead-name check, as the known-divergence
+  ledger has.
+- **`overrides`** — `SuiteOverrides`, per suite a `Partial` of its own options
+  (`SuiteOptionsMap`), shallow-merged over the derived ones: a role list, an
+  `xfail`, a narrower capability set, `ws: undefined` to drop optional socket
+  cases (`session_cap` and `testing_backdoor` gate no case on `capabilities.ws`,
+  so `ws` is their only socket switch), `extra_methods` to fire a consumer's own
+  daemon-token seams through `testing_backdoor` (whose
+  `capabilities.testing_backdoors` an override can't change — the call throws
+  unless the merge keeps the backend's list). An entry can instead be a function of the derived
+  options returning the patch (`SuiteOverride`), for a change built on a
+  derived value — an `xfail` added to the derived multi-actor setup — so the
+  seeding isn't restated. After the merge, every option the suite's type
+  requires (each entry's `required` set, exhaustive by type) must be neither
+  `undefined` nor `''`, or the call throws at collection naming suite and key.
+- **Inputs the handle doesn't carry.** The declared surface is a required
+  option. Paths and roles that name the reference spines' mounts (the
+  role-gated WS endpoint and its roles) default to the `SPINE_*` constants —
+  a suite whose flag is off never reads them, and a backend mounting its own
+  overrides them. Anything else comes from the config when it can
+  (`session_cookie_codec`'s `cookie_keys` from `SECRET_FUZ_COOKIE_KEYS`), else
+  from `overrides`; with neither, the call throws naming the suite and the
+  field — provide it or exclude the suite.
+
+Each suite reads its own capability flags, so a backend's truthful
+`BackendConfig.capabilities` decides what runs. The role-shaped suites default
+to the spine's own roles — `cell_grant_role`'s `cell_editor`, the
+`participant` `role_grant_offer_lifecycle` offers and
+`role_grant_participation` confers — and take another through `suite_roles`
+(`SpineSuiteRoles`: `cell_grant`, `conferral`), which the call also seeds on
+the holder each needs (set it there, not in `overrides`, which would leave the
+seed on the default). A backend with only the builtin roles passes
+`{cell_grant: ROLE_KEEPER, conferral: ROLE_ADMIN}`: keeper reach is not admin
+reach, so every `cell_grant_role` arm still turns on the grant, while an admin
+views and edits every cell — `describe_cell_grant_role_cross_tests` refuses
+`ROLE_ADMIN` — and the scoped-assign case of `role_grant_participation` skips
+for a builtin. fuz_app's own wiring is
+`src/test/cross_backend/spine_suites.cross.test.ts`.
+
+### `cross_backend/rust_spine_consumer_surface.ts` — `create_rust_spine_consumer_surface_spec`
+
+The declared surface of a consumer served by the Rust spine, for its cross
+suites: `create_rust_spine_consumer_surface_spec({session_options,
+domain_action_specs, extra_rpc_actions?, roles?, exclude_methods?,
+rpc_path?, host_gate?})`, built on `create_test_app_surface_spec` from the hono-free route
+shapes. It declares `/health`, the `ACCOUNT_ROUTER_PATHS` under
+`/api/account` (`/status`, `/login`, `/logout`, `/password` — what
+`fuz_auth::account_router` mounts, so the TS-only `/verify` stays off), signup,
+bootstrap as a `surface_only` shape, the daemon-token layer the consumer test
+binaries wire, a `host_validation` stub layer at the head of the middleware
+list when `host_gate` says the server turns on the spine's opt-in host gate
+(default off), and one RPC endpoint: the standard actions (over `roles`), the
+`extra_rpc_actions` (opt-in families built against the stub context), then the
+request-response, non-protocol `domain_action_specs` minus `exclude_methods`
+(methods the spec-derived suites can't drive; an entry naming no domain spec
+throws). `create_rust_spine_consumer_rpc_endpoints(options)` is that endpoint
+alone, for `describe_spine_cross_suites`'s `rpc_endpoints`. Handlers are
+no-ops — live dispatch happens in the spawned binary. A server mounting no
+signup router (a single-keeper daemon) is not this shape.
+
+### `cross_backend/provided_context.ts` — `inject_backend_handle`
+
+Augments vitest's `ProvidedContext` with the keys the shipped global setups
+provide — `backend_handle` (`create_cross_backend_global_setup`) and
+`parity_handle_a` / `parity_handle_b` (`create_dual_spawn_global_setup`'s
+default keys) — and reads them: `inject_backend_handle()` /
+`inject_parity_handles()` return the handles rebuilt by
+`reconstruct_bootstrapped_handle`. The augmentation ships in the module's
+`.d.ts`, so a test file importing either helper gets the typed `inject` with
+no augmentation of its own — a type-only import of the module carries it too,
+and a global setup built on the shipped makers needs none. A project providing other
+keys — a dual spawn under its own `provide_keys`, a probe result — augments
+`ProvidedContext` for those itself; fuz_app's are in
+`src/test/cross_backend/cross_test_types.ts`.
+
 ### `cross_backend/conformance_table.ts` + `conformance_case.ts` + `xfail.ts` — declarative behavioral/security cases
 
 The opinionated behavioral/security layer on top of the spec-derived
@@ -1036,7 +1405,7 @@ conformance cases assert _expected behavior_ — the security negatives
 wire-shape check passes green on even when behavior is wrong.
 
 - `conformance_case.ts` — `ConformanceCase` Zod schema:
-  `{name, request: {method, params?, as, verb?}, expect: {status,
+  `{name, request: {method, params?, as, acting?, verb?}, expect: {status,
 error_reason?, fields?, headers?, equivalence_group?}, note?, xfail?}`. A case is **data** — `method`
   resolves its `input`/`output` from the live registry (RPC) or `RouteSpec`
   (the 6 REST auth routes), so the case never carries a schema. `as` is the
@@ -1069,10 +1438,17 @@ error_reason?, fields?, headers?, equivalence_group?}, note?, xfail?}`. A case i
   `expired_session` is the keeper behind an expired server-side session
   (`fixture.mint_expired_session()`: a backdated `auth_session` row behind a
   still-valid signed cookie, so the DB-row expiry gate is what refuses it).
+  `acting` (`ConformanceActingBinding`) has the runner fill `params.acting`
+  with a real actor id: `principal` (the actor of the account the
+  principal's credential names), `extra_actor` (`fixture.extra_actors[0]`),
+  `keeper_actor` (`fixture.actor`, foreign to every non-keeper principal);
+  params must then be an object or omitted, without an `acting` of their own,
+  and a principal presenting no account throws.
   `error_reason` is the imported
   `ERROR_*` constant (asserted against the RPC `error.data.reason` or the
-  REST flat-body `error`; the bare `unauthenticated()` 401 carries no
-  reason, so `status` pins that denial class). `equivalence_group` is the
+  REST flat-body `error`; the dispatcher's 401 carries
+  `authentication_required`, and a denial with no reason — a handler's bare
+  `forbidden` — is pinned by `status`). `equivalence_group` is the
   **negative-space** axis: every case tagged with the same group string must
   produce a **byte-identical** normalized response (`{status, body}`),
   asserted per impl after the case loop. It promotes a masked pair
@@ -1091,14 +1467,76 @@ error_reason?, fields?, headers?, equivalence_group?}, note?, xfail?}`. A case i
   backend-fingerprinting oracle). Headers are deliberately kept out of the
   `equivalence_group` `{status, body}` comparison (`Set-Cookie` / `Date` vary).
 - `conformance_table.ts` — `describe_conformance_table_tests({cases,
-setup_test, surface_source, capabilities, rpc_endpoints, session_options,
-principals?, suite_name?})`. Same `{setup_test, surface_source,
+setup_test, surface_source, capabilities, rpc_endpoints, live_rpc_endpoints?,
+session_options, principals?, ws?, suite_name?})`. A case's RPC method
+  resolves from `rpc_endpoints` first, then from `live_rpc_endpoints` — the
+  endpoints the backend live-mounts, for methods kept off the declared surface
+  (cell verbs, opt-in resolvers, `_testing_*` backdoors); a backend's whole
+  live mount is a fine value, since a declared method still resolves from the
+  declared surface. `resolve_conformance_rpc_endpoints({rpc_endpoints,
+  live_rpc_endpoints?, session_options})` (exported) builds that lookup list,
+  for the table and the differential alike. fuz_app's spine value is
+  `create_spine_live_rpc_endpoints()` (`full_spine_mount.ts`), the binary's
+  whole mount built on stub deps for resolution only. Same `{setup_test, surface_source,
 capabilities}` protocol every Tier 1 suite uses, so **one case array runs
   both transports** — in-process (`gro test`) and cross-process (the gate,
-  each backend's real auth resolution). `resolve_principal` maps the five
+  each backend's real auth resolution). `resolve_conformance_principal` (exported) maps the five
   always-available principals to fixture accessors; `role_holder` /
   `wrong_role` read a seeded `extra_accounts` username named via
-  `options.principals`.
+  `options.principals`. `send_conformance_case(c, {fixture, surface_source, principals?,
+  resolved_rpc_endpoints})` (exported) is the send half — principal resolved,
+  request sent, the raw `{target, status, headers, body}` back unasserted; the
+  table asserts on it, and the cross-backend differential compares two.
+  **WS leg:** `ws: WsEndpointTarget` (`{base_url, ws_path, origin?}`) on
+  either sends each case as one frame on an admitted socket the principal
+  opens — its headers on the upgrade, no `Origin` where the HTTP leg
+  suppresses it, its own actor as `?acting=`. Only the TS spine resolves an
+  actor at the upgrade, refusing a multi-actor account's upgrade without
+  `?acting=` (400 `actor_required`); the Rust spine's upgrade resolves the
+  account and ignores it. Per-frame dispatch resolves each frame's `acting` on
+  both. The leg always sends `?acting=`, so it does not cover that
+  upgrade-level difference; the front-door table's multi-actor row does. The frame is the envelope the HTTP
+  body is (`perform_action_result_to_envelope` on TS), so the response reads
+  `{status, headers: {}, body: frame}` with `status` the code's
+  `jsonrpc_error_code_to_http_status` (200 for a result) and every row holds
+  unchanged. What WS loses is headers — the TS DEV-only `X-Fuz-Auth-Debug`
+  among them. `is_ws_conformance_case(c)` (exported) is the filter: RPC, sent
+  `POST`, no header value pinned, a principal that can hold a socket — not
+  `anonymous` / `bearer_browser` / `malformed_bearer` / `expired_session`,
+  refused at the upgrade, nor `scoped_token`, refused `surface:ws_upgrade`
+  there (a narrowed bearer can never send a frame, so no per-frame scope row
+  exists; the front-door table pins the upgrade refusal). An equivalence
+  group left with one member on the WS leg is dropped. Cross-process only.
+- `conformance_rpc_auth.ts` — `generate_rpc_auth_conformance_cases({surface_source,
+  live_rpc_endpoints?, skip_methods?})` → `ConformanceCase[]` from each declared RPC method's
+  `RouteAuth`, then each live-mounted one the declared surface lacks
+  (`live_rpc_endpoints`, resolved — the rows then need the same endpoints on
+  the runner's `live_rpc_endpoints`): `anonymous` → 401 `authentication_required` for every method
+  needing an account or actor (all in the
+  `RPC_AUTH_ANONYMOUS_EQUIVALENCE_GROUP`, since the 401 must not vary by
+  method); for a `credential_types` gate, each builtin channel it refuses
+  (`keeper` = session, `token` = api_token, `daemon` = daemon_token, each the
+  keeper) → 403 `credential_type_required` with `required_credential_types`;
+  for `roles` on a method admitting a session, `fresh_non_admin` → 403
+  `insufficient_permissions` with `required_roles`; public methods get
+  nothing. Params are `generate_valid_body` minus its generated `acting`
+  (read before validation, so the generator's id would answer
+  `actor_not_on_account`), so a missing gate reaches the handler rather than
+  a 400. On an actor-bound method the credential and role rows bind
+  `acting: 'principal'` instead — both spines resolve the acting actor before
+  the credential gate, so a keeper with a second actor (`extra_actors`) would
+  otherwise answer `actor_required` — and the rows hold for a single-actor and
+  a multi-actor keeper alike. The rows pin each
+  gate, not its order against validation (the security slate's
+  401-before-400 rows do). Skips `PROTOCOL_ACTION_METHODS` (fixed shared specs,
+  WS-scoped — `cancel` has no reply, `peer/ping` is public — and covered by
+  the WS suites). Given the live mount, the `_testing_*` backdoors get rows too:
+  each is daemon-token-gated, so anonymous → 401 and the keeper's session and
+  API token → 403 `credential_type_required`. Exists
+  because the action-manifest parity gate compares declarations, not the
+  live gates, and the Rust spine dispatches its own. Input-dependent handler
+  checks stay hand-written rows. fuz_app spreads it into both conformance
+  legs.
 - `xfail.ts` — `xfail_until(tracking_id, reason, name, fn)`, a thin
   `test.fails` wrapper for deferred-by-design rows (visible + self-cleaning:
   turns red when the gap closes, forcing marker removal). In-scope gaps fail
@@ -1108,7 +1546,36 @@ capabilities}` protocol every Tier 1 suite uses, so **one case array runs
 Wire from a `.db.test.ts` (in-process) and a `.cross.test.ts`
 (cross-process) with the same case array — fuz_app's own runner-proof is
 `../../test/cross_backend/conformance.{db,cross}.test.ts` sharing
-`conformance_proof_cases.ts`.
+`conformance_proof_cases.ts`, the generated auth rows, and
+`conformance_admin_cases.ts` (offer list/history across accounts, invite
+errors, pagination bounds on the admin lists); two checks the table can't
+express ride beside it on both legs: the duplicate-invite refusal (two
+requests, `describe_invite_duplicate_tests` in `invite_duplicate.ts`) and the
+offer reads' cross-account refusal being identical for the keeper's real id
+and the nil id (`describe_offer_cross_account_tests` in
+`offer_cross_account.ts` — the existing id is known only to the fixture).
+The cross legs pass the spine's live mount, so the table also runs
+`conformance_actor_cases.ts` (`actor_lookup`'s empty-`ids` bound, the
+`actor_search` scope gate) and `conformance_cell_cases.ts` (the cell refusals
+one request reaches with no cell in place: `kind` inside `data`, `cell_get`
+naming neither `id` nor `path`, the relation lists naming neither or both
+endpoints — each `invalid_params` with its declared reason — a grant miss
+`cell_grant_not_found`, the `cell_list` pagination bounds and enum-valued
+filters, and the schema-first rows where a bad page or filter value must answer
+before a handler's reason; `conformance_cell_cases.test.ts` requires a `{}` row
+with a reason for every cell action whose input is marked
+`empty_input_handler_guarded`), with the
+generated rows over the off-surface methods; the in-process leg for those is
+`conformance_off_surface.db.test.ts`, over an app mounting the cell surface
+and the two resolvers. The cross leg runs the same cases
+over WS too, and both legs run `conformance_acting_cases.ts` with the
+generated rows on a keeper seeded with `extra_actors`: no `acting` or a
+malformed one → 400 `actor_required`; the nil id, an unused id and another
+account's real actor → one identical 400 `actor_not_on_account`; acting as
+the extra actor (no grants) → 403 `insufficient_permissions` on an admin
+method over a session and a bearer, and on the keeper-gated `account_purge`
+over the daemon token; acting as the bootstrap actor passes the same gates.
+The role gate reads the resolved actor's grants on both spines.
 
 ### `cross_backend/ws_round_trip.ts` — `describe_cross_process_ws_tests`
 
@@ -1119,7 +1586,7 @@ needs raw `base_url` / `ws_path` the standard bundle doesn't carry, mirroring
 how `describe_ws_round_trip_tests` sits beside `describe_standard_tests`
 in-process. `describe_cross_process_ws_tests({setup_test, capabilities,
 base_url, ws_path, origin?, rpc_path?, max_message_bytes?, logout_path?,
-password_path?, max_tokens?})` opens a live
+password_path?, max_tokens?, ws_account_roles?})` opens a live
 `WebSocket` via `create_ws_transport` (the `ws` npm package) and asserts
 cases against the upgrade stack `register_ws_endpoint` wires (origin →
 `require_auth` → dispatch): authed upgrade round-trips `heartbeat`,
@@ -1149,7 +1616,9 @@ bearer socket (a socket on its other token stays open);
 bearer socket of the token the cap evicts. The account-wide rows come from
 `cross_backend/revocation_drivers.ts` (`create_account_revocations`, shared
 with the SSE suite), and a case that opens several sockets closes whichever
-opened when a later open fails. Per-connection auth is enforced **at upgrade
+opened when a later open fails. The second accounts are created holding
+`ws_account_roles`, for a backend whose WS upgrade requires a role (an
+admin-gated `/api/ws` refuses a roleless account). Per-connection auth is enforced **at upgrade
 time**, so the negative upgrade cases assert the upgrade itself rejects, not
 a per-message error; the close cases prove a revocation closes an
 already-open socket, since per-message dispatch never re-checks credential
@@ -1168,7 +1637,7 @@ so it validates the transport without touching domain WS methods. Gated on
 `capabilities.ws`; cross-process only (needs a real bound socket — wire from
 a `*.cross.test.ts`, never an in-process setup). Authed cookies come from the
 fresh-per-test keeper via `fixture.transport.cookies()`, not the stale
-globalSetup handle. fuz_app's own wiring is `src/test/cross_backend/ws.cross.test.ts`.
+globalSetup handle.
 
 ### `cross_backend/role_grant_offer_notification_ws.ts` — `describe_role_grant_offer_notification_ws_tests`
 
@@ -1185,7 +1654,23 @@ lifecycle RPC over `fixture.transport`, then
 strict-parses the delivered frame against its canonical params schema from
 `auth/role_grant_offer_notifications.ts` (the guard against serialization drift —
 field / null / datetime / the flat revoke shape / the supersede `reason` +
-`cause_id`). Unlike `describe_cross_process_ws_tests` (consumer-agnostic,
+`cause_id`). Every case also opens a **bystander** — a third account's
+admitted socket, party to nothing the case drives — and once the targeted
+frame has landed sends a `heartbeat` on it and asserts it received nothing
+but the answers to its own requests. The barrier is what makes the silence
+mean something: both spines queue a fan-out to every recipient in one pass
+with no await in it, and neither writes a response ahead of a notification
+already queued for the same connection — the TS transport sends both through
+one outbound queue, and the Rust loop writes a connection's queued frames
+before a response (`flush_queued_frames`). So a frame the pass addressed to
+the bystander reaches it ahead of the barrier's response. That is strict on TS,
+which sends a fan-out in one synchronous closure. On Rust, `deliver_all` pushes
+to recipients one after another on one worker while the target's connection
+loop runs on another, so the target's frame can be written while the pass is
+still pushing — a window the barrier's round trip outlasts in practice. The
+check covers every pass of the drain: the Rust `PostCommitEffects::drain_all`
+joins effects whose notify futures push synchronously, so every pass
+completes in the drain's first poll. Unlike `describe_cross_process_ws_tests` (consumer-agnostic,
 `heartbeat`-only), this drives a real **domain** notification family — but one
 built from spine primitives only (accounts / role-grants / offers / WS), zero
 consumer domain, so it lives here and runs against any backend that wires the
@@ -1204,8 +1689,7 @@ grant and expects its socket to close with `WS_CLOSE_PERMISSION_REVOKED` (the
 notification may or may not land first, and is held to the flat shape when it
 does), where an ungated socket expects the frame. The offer/accept fixtures are `create_pending_role_grant_offer` /
 `create_active_role_grant` (`cross_backend/role_grant_cross_helpers.ts`).
-Gated on `capabilities.ws`; cross-process only. fuz_app's own wiring is
-`src/test/cross_backend/role_grant_offer_notification_ws.cross.test.ts`, and
+Gated on `capabilities.ws`; cross-process only. fuz_app's
 `role_grant_offer_notification_ws_gated.cross.test.ts` runs it again over the
 spine binaries' role-gated endpoint with `ws_required_roles` declared.
 
@@ -1227,7 +1711,6 @@ must hold `ROLE_ADMIN` and `scoped_role` (a role an admin can grant scoped).
 fuz_app's spine binaries mount `SPINE_ROLE_GATED_WS_PATH` gated on
 `SPINE_ROLE_GATED_WS_ROLES` (`admin` + `participant`). Gated on
 `capabilities.ws` and `capabilities.ws_role_gated`; cross-process only.
-fuz_app's own wiring is `src/test/cross_backend/ws_role_gated.cross.test.ts`.
 
 ### `cross_backend/peer_ping_ws.ts` — `describe_peer_ping_ws_tests`
 
@@ -1251,8 +1734,7 @@ the HTTP no-transport path. Gated on `capabilities.peer_request` — `true` on
 both the Rust spine and the TS spine (the `BackendWebsocketTransport.request_connection`
 path + `register_action_ws` response correlation); `peer/ping` is a protocol
 action (manifest-excluded), so parity is behavioral here, not via the manifest
-gate. Cross-process only; fuz_app's own wiring is
-`src/test/cross_backend/peer_ping_ws.cross.test.ts`.
+gate. Cross-process only.
 
 ### `cross_backend/ws_inbound_dispatch.ts` — `describe_ws_inbound_dispatch_cross_tests`
 
@@ -1267,8 +1749,7 @@ client's responder withholds the server's ping echo until the test releases
 it — so the suite gates on `capabilities.peer_request`.
 `describe_ws_inbound_dispatch_cross_tests({setup_test, capabilities, base_url,
 ws_path})`. The wire literals are independent copies of the producers'
-constants, so a value changed on one spine fails here. Cross-process only;
-fuz_app's own wiring is `src/test/cross_backend/ws_inbound_dispatch.cross.test.ts`.
+constants, so a value changed on one spine fails here. Cross-process only.
 
 ### `cross_backend/ws_outbound_overflow.ts` — `describe_ws_outbound_overflow_cross_tests`
 
@@ -1297,8 +1778,7 @@ flood action is daemon-token-gated, so the flooding socket upgrades with the
 daemon token and no `Origin` (`create_ws_transport`'s `origin: null`). The wire
 literals are independent copies of the producers' constants. Gated on
 `capabilities.ws`; cross-process only, and only for a backend that mounts the
-flood action on its WS endpoint. fuz_app's own wiring is
-`src/test/cross_backend/ws_outbound_overflow.cross.test.ts`.
+flood action on its WS endpoint.
 
 ### `cross_backend/ws_connection_cap.ts` — `describe_ws_connection_cap_cross_tests`
 
@@ -1326,8 +1806,7 @@ overridden; pass the consumer's value when it sets one, `null` (cap disabled)
 to skip. **Consumer-agnostic** like the WS round-trip suite (`heartbeat` only).
 A separate call rather than more cases on that suite because each case opens
 more than a cap's worth of real sockets. Gated on `capabilities.ws`;
-cross-process only. fuz_app's own wiring is
-`src/test/cross_backend/ws_connection_cap.cross.test.ts`.
+cross-process only.
 
 ### `cross_backend/session_cap.ts` — `describe_session_cap_cross_tests`
 
@@ -1335,12 +1814,13 @@ Parity for the per-account session cap over real HTTP: logging in past
 `max_sessions` (default `DEFAULT_MAX_SESSIONS`) never refuses a login and
 evicts the oldest session.
 `describe_session_cap_cross_tests({setup_test, max_sessions?, login_path?,
-status_path?, ws?})` — pass `ws` (`{base_url, ws_path, origin?}`) to also
+status_path?, ws?, ws_account_roles?})` — pass `ws` (`{base_url, ws_path, origin?}`) to also
 assert that the evicted session's socket is closed with
 `WS_CLOSE_SESSION_REVOKED` once the evicting login commits; omitted, that case
-is skipped, so a caller passes it only for a backend with `capabilities.ws`.
-Cross-process only. fuz_app's own wiring is
-`src/test/cross_backend/session_cap.cross.test.ts`.
+is skipped, so a caller passes it only for a backend with `capabilities.ws`;
+`ws_account_roles` gives that case's account roles, for a backend whose WS
+upgrade requires one.
+Cross-process only.
 
 ### `cross_backend/sse_round_trip.ts` — `describe_cross_process_sse_tests`
 
@@ -1370,8 +1850,7 @@ admin each drop its stream — the rows `create_account_revocations`
 session closes the oldest and leaves the rest open. The data-frame + close
 cases gate on `rpc_path` (they drive the standard account/admin actions); all
 cases gate on `capabilities.sse`. Cross-process only — wire from a
-`*.cross.test.ts`. fuz_app's own wiring is
-`src/test/cross_backend/sse.cross.test.ts`, which runs on every backend — the
+`*.cross.test.ts`. It runs on every fuz_app backend — the
 TS spines wire `audit_log_sse` and the Rust `spine_stub` serves the same
 stream.
 
@@ -1389,7 +1868,7 @@ covered on WS and SSE at once. The drivers stand alone too: `cross_post_as`
 `cross_admin_token_revoke_all`, and `cross_account_purge` (over the daemon
 token, no `Origin`).
 
-### `cross_backend/cell_crud.ts` + `cell_relations.ts` + `cell_gated_create.ts` — cell parity suites
+### `cross_backend/cell_crud.ts` + `cell_relations.ts` + `cell_gated_create.ts` + `cell_moderate.ts` — cell parity suites
 
 The cell-layer parity coverage is split across two sibling suites. Cells
 can't ride the generic `describe_rpc_round_trip_tests` (stateful verbs need a
@@ -1400,7 +1879,21 @@ cell validators (`describe_standard_cross_process_tests`' generic round-trip
 never sees them). Both parse every success response against the verb's Zod
 **output** schema, so a TS↔Rust envelope drift fails the suite — not just a
 payload-field drift. Call-site primitives (`cross_rpc_call` / `error_reason` /
-`expect_output`) live in `cross_backend/cell_cross_helpers.ts`; the shared
+`expect_output`) live in `cross_backend/cross_rpc.ts`, shared by every
+stateful cross suite (`RpcResult` carries the HTTP `status` beside the
+envelope; a reply that is no JSON object throws naming the method,
+the HTTP status and the body's head), and every
+suite that reads audit rows goes through `cross_backend/audit_cross_helpers.ts`
+— `list_audit_events(fixture, params, rpc_path?)` drains
+(`cross_drain_effects`, the `_testing_drain_effects` barrier, refusing an answer
+without `tracked: true`) before it lists and parses, so no reader skips the
+barrier and every read checks the barrier is live, and parses every row's metadata
+(`assert_audit_event_metadata`, closed to undeclared keys when the fixture's
+setup asked), so every reader holds the rows it reads to their event's
+schema. A suite pinning a row's values uses `assert_audit_metadata_fields(fixture,
+metadata, expected, absent?)` — each field compared on its own so a consumer's
+added key passes, the `absent` keys refused, and the whole object compared only
+when the fixture closed the world; the shared
 options shape is `RpcPathCapabilityGatedCrossSuiteOptions` from
 `cross_backend/setup.ts`. `cross_backend/wire_shapes.ts` carries
 `assert_iso8601_seconds` / `assert_iso8601_seconds_nullable` — the byte-level
@@ -1413,9 +1906,9 @@ an audit row, an admin account listing, and an offer's `created_at` /
 imperative cross suite aliases: `CrossSuiteOptions` (`setup_test` alone),
 `CapabilityGatedCrossSuiteOptions` (+ `capabilities` — `ready`),
 `RpcPathCrossSuiteOptions` (+ `rpc_path?` — origin, body-size (which adds `base_url`), actor
-lookup/search, app settings, testing backdoor), and the intersection
+lookup, app settings), and the intersection
 `RpcPathCapabilityGatedCrossSuiteOptions` (every `cell_*` suite, query-shape,
-token-scope surface, fact-serving, account lifecycle). A suite takes the
+token-scope surface, fact-serving, account lifecycle, testing backdoor). A suite takes the
 capability-carrying variant only when it actually gates cases on a flag, so
 the option type states whether the bundle is read.
 
@@ -1426,20 +1919,36 @@ the option type states whether the bundle is read.
   `path` write by non-admin → 403 on create + update; `cell_get` with no
   id/path → `invalid_params`; null-auth `cell_list` `created_by` →
   `invalid_params`; a `kind` at `CELL_KIND_LENGTH_MAX` stored whole, one
-  UTF-16 code unit past it → `invalid_params` on create and as a list filter).
+  UTF-16 code unit past it → `invalid_params` on create and as a list filter;
+  `cell_list` pages honoring `limit` + `offset`, a page holding visible rows
+  only and filling to `limit` past a newer run of rows the caller can't see —
+  two owners' private cells, read by a non-owner and by anon — and an admin's
+  pages tiling every row; a `data` that is no `CellData` — a non-object, or a
+  non-string `label` / `summary` — refused 400 `invalid_params` with the
+  generic message and no reason (no `data` beyond a TS spine's DEV-only
+  `issues`, an array of Zod issues) on `cell_create`, on `cell_update` of a
+  missing and of a hidden cell, and, with `cell_relations`, on `cell_clone`'s
+  `with_data_patch` — ahead of the 404 mask the same hidden-cell call answers
+  when well-typed, with the keeper's cell count unchanged; those cases run as
+  the keeper and plain accounts only, so a backend that refuses a non-admin
+  root cell can keep them through `exclude_cases` while excluding the rest).
 - **`describe_cell_relations_cross_tests`** (gates on
   `capabilities.cell_relations`) — the verbs beyond CRUD: grant lifecycle
   (actor-shaped editor grant enables edit, manage-tier `cell_grant_list`,
   revoke), the now-reachable `cell_visibility_manage_only` 403 (editor-grant
   holder can't flip visibility), field set / forward+reverse list / idempotent
   delete, item insert / ordered forward+reverse list / move / idempotent
-  delete, clone shallow (shares edges) vs deep (clones children), and
+  delete, an insert or move onto a taken position → `cell_item_position_taken`
+  with the rows unchanged, clone shallow (shares edges) vs deep (clones children), and
   manage-tier `cell_audit_list` (owner reads the timeline; a viewer-grant
   holder who can `cell_get` still gets the IDOR 404). Only **actor-shaped**
   grants are exercised — role-shaped principals need a closed role registry the
   Rust spine deliberately lacks.
-- **`describe_cell_gated_create_cross_tests`** + **`describe_cell_moderate_cross_tests`**
-  (gate on `capabilities.cell_gated_create`, **cross-only**) — the parent-aware
+- **`describe_cell_gated_create_cross_tests`** (`cell_gated_create.ts`) +
+  **`describe_cell_moderate_cross_tests`** (`cell_moderate.ts`)
+  (gate on `capabilities.cell_gated_create`, **cross-only**; both build their
+  spaces on `TEST_SPACE_POLICY`, exported beside the authorizer in
+  `test_cell_gated_create_authorize.ts`) — the parent-aware
   cell-creation authorizer (`CellCreateAuthorize`, **directory model**) +
   the `cell_moderate` verb parity proofs. Both spines mount the same
   `test_cell_gated_create_authorize` policy (its admin bypass and `min_role`
@@ -1453,7 +1962,9 @@ moderation_required}`, with `moderation` set per the verdict (`pending`+private
   **visible** one **403**s; plain parentless creates stay open. The moderate
   suite then proves the `pending → approved | rejected` transition: an admin
   (root manager) approves → public, the **author** self-approve → 403
-  (anti-self-approval), a non-viewer → 404, reject → stays private. It also
+  (anti-self-approval), a non-viewer → 404, reject → stays private, and a cell
+  with no governing root → 400 `cell_not_a_contribution` for any viewer, the
+  404 mask first for a non-viewer. It also
   pins the moderation read gate (a pending or rejected post reaches no
   non-steward reader past its author and admins on `cell_get`, `cell_list`,
   `cell_item_list`, and fact serving, even flipped public or granted while
@@ -1469,8 +1980,7 @@ moderation_required}`, with `moderation` set per the verdict (`pending`+private
 
 `cell_crud` / `cell_relations` gate `true` on TS + Rust (cells run on both, no
 `.skip`); `cell_gated_create` is cross-only (the policy is a spine-binary
-fixture). Cross-process wiring is `src/test/cross_backend/cell.cross.test.ts`
-(all the cell suites); the in-process legs (plain `gro test`) for crud/relations
+fixture). The in-process legs (plain `gro test`) for crud/relations
 are `src/test/auth/cell_crud_parity.db.test.ts`
 
 - `cell_relations_parity.db.test.ts`, sharing the full-surface
@@ -1486,11 +1996,59 @@ are `src/test/auth/cell_crud_parity.db.test.ts`
   `rust_spine_stub_backend_config()` as a convenience preset for the non-domain
   third spine consumer, but otherwise backend-specific paths and env are a
   consumer concern.
+- `testing/cross_backend/default_backend_configs.ts` —
+  `make_default_ts_backend_config` / `make_default_rust_backend_config`, the
+  family builders a consumer config composes: the env baseline (`HOST` bound
+  to `DEFAULT_TEST_BACKEND_HOST`, `127.0.0.1`; the port under
+  `port_env_var`; cookie keys; allowed origins; the bootstrap token path; the
+  Rust startup self-wipe), the default paths, and the required `capabilities`.
+  `daemon_token_dir_env` names the env var the binary reads its daemon-token
+  directory from, set to the `{dir}` whose `{dir}/run/daemon_token` is the
+  bootstrap's `daemon_token_path` (`to_daemon_token_dir`, which throws for a
+  path in another layout).
+- `testing/cross_backend/create_cross_backend_global_setup.ts` —
+  `create_cross_backend_global_setup({configs, derive_name?, provide_key?,
+  ensure_databases?, before_spawn?})`, the single-backend `globalSetup` maker:
+  the backend name derived from the vitest project name selects a config,
+  which is spawned, bootstrapped and provided. `before_spawn` (by backend
+  name; a key naming no config, an inherited one included, throws at
+  construction) runs first for the selected backend — `prepare_cargo_binary`
+  for a Rust one — then its config factory, then `ensure_databases: true`
+  creates the database the config's `postgres:` `env.DATABASE_URL` names
+  (`ensure_database_for_url`), then the spawn. A second argument
+  (`CrossBackendGlobalSetupDeps`) swaps the database creator and the spawn,
+  for testing the setup itself.
+- `testing/cross_backend/cargo_binary.ts` — `prepare_cargo_binary({workspace_dir,
+  package, bin?, profile?})` builds a Cargo binary (`cargo build -p --bin
+  --profile`, output inherited, a failed build throws) unless
+  `NO_REBUILD_ENV` (`FUZ_TESTING_NO_REBUILD`, `is_no_rebuild_requested`) asks
+  to skip it, and returns its path; `resolve_cargo_binary_path(options)` is the
+  path alone, for a config's `start_command` — under the `target_directory`
+  `cargo metadata` reports (memoized per process per workspace), in the
+  profile's directory (`to_cargo_profile_dir`: `dev` → `debug`;
+  `to_cargo_binary_path` reads it from the metadata JSON). Run as
+  `create_cross_backend_global_setup`'s `before_spawn` hook, the build happens
+  before the spawn's startup window, with its output shown. fuz_app's own stub
+  rebuild (`rebuild_rust_spine_stub`) is built on it.
+- `testing/cross_backend/postgres_database.ts` — `ensure_database(database,
+  server_url?, deps?)` (idempotent `createdb` on the server the URL names, its
+  password passed in the environment; `createdb`'s already-exists refusal is
+  the quiet success case, `is_createdb_already_exists`, and any other failure
+  is reported through `deps.warn` — `console.warn` by default — with
+  `createdb`'s stderr, never thrown), `ensure_database_for_url(url, deps?)` (the
+  database a `postgres:` URL names; anything else left alone),
+  `with_database_name`, `to_maintenance_database_url`, `redact_database_url`
+  (a URL fit to print), `is_postgres_url`. The harness creates a database only
+  when a setup asks, so a test role needs no `CREATEDB` grant otherwise.
 - `testing/cross_backend/spawn_backend.ts` — `spawn_backend(config) => BackendHandle`.
-  Writes the bootstrap token, spawns `detached: true` in its own process
-  group (so SIGTERM to the negative pid tears down descendants), polls
-  health, reads the deterministic daemon token from the binary-written
-  file. Registers exit-time + signal cleanup so vitest worker death or
+  Refuses a port that already accepts connections, writes the bootstrap
+  token, deletes a stale daemon-token file, spawns `detached: true` in its
+  own process group (so SIGTERM to the negative pid tears down descendants),
+  polls health (each probe request timed out), reads the deterministic daemon
+  token from the binary-written file. Keeps a bounded stderr tail
+  (`create_output_tail`) for an early exit's error — with its exit code or
+  signal — and for the log line an unexpected exit after startup writes.
+  Registers exit-time + signal cleanup so vitest worker death or
   Ctrl+C kills children before they strand ports.
 - `testing/transports/fetch_transport.ts` — cookie-threading HTTP transport
   satisfying `RpcTestTransport`. Carries a name-keyed cookie jar that
@@ -1530,6 +2088,18 @@ are `src/test/auth/cell_crud_parity.db.test.ts`
   opens and round-trips `heartbeat` (response id `WS_ADMISSION_PROBE_ID`) so the
   connection is admitted when it resolves; suites that wait for a push, or need
   connections registered in a known order, open through it.
+- `testing/cross_backend/ws_endpoint.ts` — `WsEndpointTarget`
+  (`{base_url, ws_path, origin?}`), the endpoint shape the socket-driving
+  cross suites take (flat, or as an optional `ws` on
+  `describe_session_cap_cross_tests`, `describe_testing_backdoor_cross_tests`
+  and the conformance table; `describe_transport_composition_cross_tests`
+  keeps its own nullable `base_url` and defaulted `ws_path`), and
+  `open_session_ws(target, account, {admitted, on_request?, headers?,
+  default_timeout_ms?})`, which opens a socket on an account's session cookie
+  (`to_session_cookie`, asserted present) with `target.origin` or `base_url`
+  as the `Origin` — through `create_admitted_ws_transport` when `admitted`,
+  `create_ws_transport` otherwise. The cookie is the account's static one, so
+  a session rotated through `fixture.transport` upgrades stale.
 - `testing/transports/ws_raw_client.ts` — `connect_raw_ws({port, hostname?, path, headers?, pipelined?})`
   → `RawWsClient` (`{frames, send_text, wait_for, destroy}`), a WebSocket client
   over a raw `node:net` socket for the two things a client library can't do:
@@ -1551,8 +2121,12 @@ are `src/test/auth/cell_crud_parity.db.test.ts`
   `raw_http_parse_response` (the first response, `null` until its head and
   framed body are whole), `raw_http_count_responses` (unanchored status-line
   count, so a response concatenated after a body is seen),
-  `raw_http_first_status`. Shared by the body-size, body-size smuggling, and
-  credential-header suites.
+  `raw_http_first_status`, `raw_http_header_lines` (headers as CRLF lines),
+  `raw_http_parse_json` (a body's JSON, `undefined` when it isn't), and
+  `RAW_HTTP_READ_TIMEOUT_MS`, the suites' default read window. Shared by the
+  body-size, body-size smuggling, credential-header, origin-scope and
+  transport-composition suites, which take the 1 MiB cap they probe from
+  `SPINE_BODY_LIMIT_DEFAULT_BYTES` (`spine_surface_constants.ts`).
 - `testing/transports/sse_frame_reader.ts` — `create_sse_frame_reader(reader, default_timeout_ms?)`,
   the transport-agnostic SSE framing core over a
   `ReadableStreamDefaultReader<Uint8Array>`: `\n\n` framing, per-read timeout,
@@ -1576,22 +2150,25 @@ are `src/test/auth/cell_crud_parity.db.test.ts`
   `create_testing_actions(deps, options)` factory returning the
   `_testing_reset` RPC action. Test binaries register it on their RPC
   endpoint; `default_cross_process_setup` fires it unconditionally per
-  test. Handler DELETEs every auth-namespace row (no keeper-preserve
-  filter), resets `app_settings` to production defaults, flips
-  `bootstrap_lock.bootstrapped = true`, inline-seeds a fresh keeper via
-  `create_test_account_with_credentials` (same primitive in-process uses,
-  keeping write semantics in parity), seeds any `extra_accounts` at the
-  same bootstrap-equivalent step (the only path for roles like
-  `ROLE_KEEPER` whose `grant_paths` is bootstrap-only), queues the refresh
+  test. Handler first fires the consumer-supplied `reset_state(db)`
+  callback for domain-state reset — before the auth wipe, because domain
+  rows depend on auth rows (a domain table with a restricting FK to `actor`
+  must empty before the actor delete) — then DELETEs every auth-namespace
+  row (no keeper-preserve filter), resets `app_settings` to production
+  defaults, flips `bootstrap_lock.bootstrapped = true`, inline-seeds a fresh
+  keeper via `create_test_account_with_credentials` (same primitive
+  in-process uses, keeping write semantics in parity), queues the refresh
   of `DaemonTokenState.keeper_account_id` to the new row as a post-commit
-  effect (so a reset that rolls back — a throwing `reset_state`, a failed
-  commit — leaves the cache on the keeper still in the database, and the
-  next reset can still authenticate), then fires the
-  consumer-supplied `reset_state(db)` callback for domain-state reset —
-  passed the **transactional** `Db` the auth wipe ran on, so DB-domain
-  consumers (e.g. fuz_forge truncating its cell / fact / file tables) reset
-  on the same connection rather than a separately-pooled one that would
-  deadlock against this open transaction under the in-memory drivers. Auth
+  effect as soon as the keeper exists (so a reset that rolls back — a
+  failing extra seed, a failed commit — leaves the cache on the keeper
+  still in the database, and the next reset can still authenticate), then
+  seeds any `extra_accounts` at the same bootstrap-equivalent step (the
+  only path for roles like `ROLE_KEEPER` whose `grant_paths` is
+  bootstrap-only). `reset_state` is passed the **transactional** `Db` the
+  auth wipe then runs on, so DB-domain consumers (e.g. fuz_forge truncating
+  its cell / fact / file tables) reset on the same connection rather than a
+  separately-pooled one that would deadlock against this open transaction
+  under the in-memory drivers. Auth
   gates on `credential_types: ['daemon_token']` — effectively keeper-only
   without forcing the `actor: 'required'` ⟺ `acting?: ActingActor`
   biconditional. No free-form runtime grant action exists — see the
@@ -1606,6 +2183,10 @@ are `src/test/auth/cell_crud_parity.db.test.ts`
   emitter must be built with `create_audit_emitter({track_inflight: true})`
   (the spine binary's `audit_factory` does — pinned by
   `cross_backend/testing_spine_server.audit.test.ts`), or the drain resolves at once.
+  The action answers `{ok: true, tracked}`, `tracked` read from
+  `audit.is_tracking_inflight()`, and `cross_drain_effects` refuses anything but
+  `tracked: true` — so a binary built over an untracked emitter fails its first
+  audit read rather than racing it. The Rust twin answers the same shape.
   The barrier is needed whatever the transport: HTTP on a binary running
   `await_pending_effects: true` settles a mutation's writes before
   responding, but WS replies before its effects flush, so a WS mutation's
@@ -1690,10 +2271,57 @@ refs); and a hidden cell's update, a create under a hidden parent, and a clone
 of a hidden source answer `404` whatever `data` names. Facts are put through
 `cross_put_fact` (exported by `fact_serving.ts`), whose `holder` maps onto
 `_testing_put_fact`'s optional `holder` key. Gated on
-`capabilities.fact_serving`; cross-process only. fuz_app's own wiring is
-`src/test/cross_backend/cell_ref_admission.cross.test.ts`; the in-process
+`capabilities.fact_serving`; cross-process only. The in-process
 cases are `src/test/auth/cell_ref_admission{,.fact_less}.db.test.ts`.
 
+### Malformed-envelope and invalid-params parity — `cross_backend/rpc_adversarial.ts`
+
+`describe_rpc_adversarial_cross_tests({setup_test, surface_source, rpc_path?,
+live_rpc_endpoints?, skip_methods?, input_overrides?, xfail_params?})` — the
+envelope and params groups of `describe_rpc_attack_surface_tests`, sent over
+`fixture.transport` to a spawned backend. The in-process groups run on stub
+apps, while the Rust spine parses envelopes and params by hand and the
+action-manifest parity gate
+compares no param schemas, so this is what holds the spines to one answer.
+
+- **envelopes** — every `create_rpc_envelope_cases` case, one test each, on a
+  fresh fixture; status, code, echoed `id`, and `data.reason` per case, and a
+  guard test that the endpoint has both a read and an authenticated mutation to
+  carry them.
+- **params** — one test per declared method, sending every
+  `generate_rpc_params_test_cases` case (seeded from the method's
+  `input_overrides` entry when it has one — the cases go as a single-actor
+  principal, so an override omits `acting`) and failing with the list of
+  cases not answered 400 `invalid_params` with the broken field's declared
+  `invalid_reason` as `data.reason` (`expected_invalid_reason`; none for an
+  undeclared field or a whole-body case). `xfail_params`
+  (`RpcParamsXfail` — `{method, labels, tracking_id, reason}`) moves the named
+  cases of a method into one `xfail_until` test each, for a known divergence on
+  one backend; the method's other cases keep their test, and an entry naming no
+  generated case fails. Pass it only for the backend that diverges — fuz_app
+  keys it on `RUST_SPINE_STUB_DEFAULT_NAME`.
+
+The authorized principal is the keeper on the first channel the method's auth
+admits — its session, else its daemon token or API token over a no-`Origin`
+transport — resolved through `resolve_conformance_principal`.
+**Preconditions:** the keeper holds every role a declared method gates on
+(`default_cross_process_setup` seeds `keeper` and `admin`; `extra_keeper_roles`
+for others) and has a single actor. No generated body carries a valid `acting`,
+and a malformed one reads as omitted ahead of validation on both spines, so a
+single-actor keeper resolves its actor and validation refuses; a keeper with a
+second actor answers `actor_required` first, so such a suite lists the
+actor-required methods in `skip_methods`.
+
+**Off the declared surface.** `live_rpc_endpoints` (resolved) adds the methods
+the endpoint at `rpc_path` live-mounts beyond the declared surface — cell
+verbs, opt-in resolvers, `_testing_*` backdoors — to both groups: their
+envelope cases in a group of their own, and a params test per method,
+`_testing_*` included (a daemon-only backdoor goes with the keeper's daemon
+token). fuz_app's spine self-test passes `create_spine_live_rpc_endpoints()`.
+Skips `_testing_*` on the declared surface and `PROTOCOL_ACTION_METHODS`, which
+`generate_rpc_auth_conformance_cases` skips too.
+Ungated; cross-process only.
+
 ### Token-scope surface parity — `cross_backend/token_scope_surface.ts`
 
 `describe_token_scope_surface_cross_tests({setup_test, capabilities, rpc_path?,
@@ -1708,7 +2336,7 @@ the spec-derived suites can't see it (REST routes, off the declared RPC surface)
 Mints a narrowed bearer through the production `account_token_create` path and
 fires it at the two surfaces whose denial **body** is observable over plain
 HTTP — the audit SSE stream (`capabilities.sse`) and the admin-only bare-hash
-fact read (`capabilities.fact_serving`) — asserting the exact flat
+fact read (`capabilities.fact_serving_admin_hash`) — asserting the exact flat
 `{error: 'token_scope_required', required_scope: 'surface:<name>'}` both spines
 contract on (`token_scope_denied_body` ↔
 `fuz_auth::token_scope_surface_denied_response`).
@@ -1733,20 +2361,21 @@ _does_ name, and a full bearer must get past the scope gate on the same route.
 The WS upgrade is deliberately omitted — `create_ws_transport` threads cookies,
 not bearer headers, and a refused upgrade's body isn't readable, so it can't
 serve a body-parity gate (its per-spine coverage stays in the two surface
-censuses). Cross-process only; fuz_app's own wiring is
-`src/test/cross_backend/token_scope_surface.cross.test.ts`.
+censuses). Cross-process only.
 
 ### Front-door contract — `cross_backend/transport_composition.ts`
 
 `describe_transport_composition_cross_tests({setup_test, capabilities, base_url,
-rpc_path?, origin?, rest_path?, password_path?, ws_path?, sse_path?})` — the per-transport
+rpc_path?, origin?, rest_path?, password_path?, ws_path?, sse_path?,
+multi_actor?, rpc_max_body_bytes?})` — the per-transport
 composition table: what each transport answers before per-action dispatch,
 when one request trips several refusals. Rows are REST `POST` (session-only
 `/api/account/logout`), RPC `POST`, RPC `GET`, the WS upgrade (gated on
 `capabilities.ws`) and the audit stream (`capabilities.sse`); columns are a
 foreign `Origin` with the keeper's session (→ 403 `forbidden_origin`), an
 over-cap declared length with a foreign `Origin` and no credential (→ 413
-`payload_too_large`, body-carrying rows only), no credential (→ 401
+`payload_too_large`, body-carrying rows only; one byte past the spine default,
+or past `rpc_max_body_bytes` on the RPC row), no credential (→ 401
 `authentication_required`), and a narrowed bearer with no `Origin` (→ 403
 `token_scope_required` naming `rpc:<method>` on RPC and `surface:ws_upgrade` on
 the upgrade; 403 `credential_type_required` on the session-only REST route and
@@ -1756,12 +2385,17 @@ envelope's `error.data`. A WS refusal's body is required where the backend
 declares `capabilities.ws_refusal_body`; where it doesn't (Node's
 `@hono/node-ws` drops the body), an empty body passes on its status and a sent
 one is still asserted. The table
-is the exported `transport_composition_cases` data. Given `base_url`, every
+is the exported `transport_composition_cases` data. `multi_actor:
+{setup_test, xfail?}` adds `transport_composition_multi_actor_cases`, run on
+a fixture whose keeper has `extra_actors`: the keeper's session upgrading with
+no `?acting=` → 400 `actor_required` (flat body), the TS upgrade's actor
+resolution. The Rust spine's upgrade resolves no actor and admits the socket,
+so fuz_app passes `xfail` (tracking id `rust-ws-upgrade-acting-fail-open`) for
+the Rust stub only. Given `base_url`, every
 probe is written to the socket (`raw_http_exchange`) and an over-cap request
 sends its head alone; with `base_url: null` the probes go through the
 fixture's transport and the WS rows skip. Not in the standard bundle. fuz_app's
-own wiring is `src/test/cross_backend/transport_composition.cross.test.ts` and
-the in-process `src/test/auth/transport_composition_parity.db.test.ts`.
+in-process leg is `src/test/auth/transport_composition_parity.db.test.ts`.
 
 `cross_backend/narrowed_api_token.ts` — `mint_narrowed_api_token({app,
 rpc_path, session_headers, methods, name?})` mints a method-scoped api token
@@ -1773,7 +2407,7 @@ principal.
 ### Credential deadline parity — `cross_backend/credential_deadline.ts`
 
 `describe_credential_deadline_cross_tests({setup_test, capabilities, base_url,
-ws_path, sse_path?, rpc_path?})` — a connection closes when the credential it
+ws_path, sse_path?, rpc_path?, ws_account_roles?})` — a connection closes when the credential it
 opened on expires: each case pulls a fresh account's credential expiries in to
 two seconds with `_testing_shorten_credential_expiry` before the open, then
 checks the connection still dispatches short of the deadline and closes at it.
@@ -1783,17 +2417,24 @@ stream on a session (`capabilities.sse`) ends; and a second seam call asking
 for a later expiry moves nothing (the seam only shortens). API token × audit
 stream is not reachable over the wire — the stock stream is session-only — so
 the Rust spine pins it on a widened gate and the TS twin shares one deadline
-wait across both transports. Cross-process only; fuz_app's own wiring is
-`src/test/cross_backend/credential_deadline.cross.test.ts`.
+wait across both transports. The cases run concurrently (`describe.concurrent`)
+under one `setup_test()` for the suite, each on its own account, so a leg waits
+out one deadline rather than one per case. `ws_account_roles` gives the
+socket cases' accounts roles, for a backend whose WS upgrade requires one.
+Cross-process only.
 
 ### Origin check scope parity — `cross_backend/origin_scope.ts`
 
-`describe_origin_scope_cross_tests({setup_test, capabilities, probe_path?})` —
-the origin check covers paths outside `/api`: on `GET /ready` (`probe_path`), a
-foreign `Origin` → 403 `forbidden_origin`, an absent or allowed one → 200. Gated
-on `capabilities.ready`. Runs both legs (the in-process
+`describe_origin_scope_cross_tests({setup_test, capabilities, probe_path?,
+base_url?, unrouted_status?})` — the origin check covers paths outside `/api`:
+on `GET /ready` (`probe_path`), a foreign `Origin` → 403 `forbidden_origin`, an
+absent or allowed one → 200, gated on `capabilities.ready`. On an unrouted
+path, ungated: a foreign `Origin` → 403, an absent one passes to the fallback
+(`unrouted_status`, default 404 — a backend whose fallback serves an SPA shell
+passes 200; the in-process leg runs that shape too), and an over-cap `POST`
+with a foreign `Origin` → 413. Runs both legs (the in-process
 `cross_backend/origin_scope_parity.db.test.ts` + the cross-process
-`origin_scope.cross.test.ts`).
+one call).
 
 ### Origin verification parity — `cross_backend/origin.ts`
 
@@ -1803,7 +2444,7 @@ imperative Origin-verification suite: absent `Origin` → request passes
 table's. Imperative (not a conformance-table row) because absent-Origin needs
 `fresh_transport({origin: null})`. Runs both legs (the
 in-process `auth/origin_parity.db.test.ts` + the cross-process
-`origin.cross.test.ts`). The promotion surfaced a twin-impl divergence — the
+one call). The promotion surfaced a twin-impl divergence — the
 Rust spine returned a plain-text body — now converged to the canonical TS
 `{error: "forbidden_origin"}` via `fuz_http::forbidden_origin_response()`.
 
@@ -1823,7 +2464,6 @@ keeper's daemon-token channel; the TS unit leg runs the same rows through
 `run_testing_origin_check` (`src/test/http/origin.conformance.test.ts`), so the
 Rust spine is held to the table without reading the file. Ungated; edit the
 table by hand — it is the statement of the grammar, not generated output.
-fuz_app's own wiring is `src/test/cross_backend/origin_conformance.cross.test.ts`.
 
 ### CORS simple-request parity — `cross_backend/simple_request.ts`
 
@@ -1839,7 +2479,7 @@ and login, form-encoded login, a forged `text/plain` logout with a session
 `application/json` with a charset is dispatched. The TS spine checks per route
 (`apply_route_specs`), the Rust spine in each JSON handler. Runs both legs:
 the in-process `auth/simple_request_parity.db.test.ts` and the cross-process
-`simple_request.cross.test.ts`.
+one call.
 
 ### Query-string shape parity — `cross_backend/query_shape.ts`
 
@@ -1850,7 +2490,7 @@ suite over the three spine surfaces that read a query:
 unknown keys ignored, anonymous junk query → 401 never a query 400), the
 JSON-RPC GET endpoint (`method` / `id` / `params` first-wins — a last-wins
 reader dispatches a different method per backend on the same request), and
-`GET /api/facts/:hash` (gated on `capabilities.fact_serving`; strict schema —
+`GET /api/facts/:hash` (gated on `capabilities.fact_serving_admin_hash`; strict schema —
 unknown key / malformed `acting` → 400 `invalid_query_params` **before** the
 401 guard, duplicated `acting` first-wins). Imperative because duplicated
 query keys can't be expressed through the structured RPC helpers. Pinned
@@ -1859,8 +2499,7 @@ after the Rust spine's derived-serde `Query` extractors were converged onto
 "duplicate field" 400 is an anonymously observable backend fingerprint).
 Cross-process only — the per-surface in-process TS pins live beside each
 module's own tests (`account_status.test.ts`, `action_rpc.test.ts`,
-`serve_fact_route.db.test.ts`); fuz_app's own wiring is
-`cross_backend/query_shape.cross.test.ts`.
+`serve_fact_route.db.test.ts`);
 
 ### Grant-verb role grammar parity — `cross_backend/role_grant_role_grammar.ts`
 
@@ -1875,8 +2514,7 @@ vacuous, and the same refusal for a role exactly at the length cap pins that
 boundary. Exists because the action-manifest parity gate captures no param
 schemas while the Rust spine parses params by hand, and the grant verbs write
 the role they refuse into their failure rows. Ungated; cross-process only (it
-reads the audit log behind `_testing_drain_effects`). fuz_app's own wiring is
-`src/test/cross_backend/role_grant_role_grammar.cross.test.ts`.
+reads the audit log behind `_testing_drain_effects`).
 
 ### API-token lifetime parity — `cross_backend/token_lifetime.ts`
 
@@ -1891,7 +2529,7 @@ schemas while the Rust spine hand-parses params — a spine that silently
 dropped the field would answer the same mint with a 200 and an eternal
 token; only the stored-state read-back catches it. Ungated (mint + list are
 on every spine's standard surface). Runs both legs
-(`token_lifetime_parity.db.test.ts` + `token_lifetime.cross.test.ts`).
+(`token_lifetime_parity.db.test.ts` + the cross-process one call).
 
 ### Readiness probe parity — `cross_backend/ready.ts`
 
@@ -1906,7 +2544,7 @@ success-path gate. Gated on `capabilities.ready`. Imperative (not a
 JSON-RPC envelope, and the probe needs `fresh_transport({origin: null})` —
 the same reasons the sibling `cross_backend/origin.ts` suite is imperative.
 Runs both legs (`cross_backend/ready_parity.db.test.ts` +
-`cross_backend/ready.cross.test.ts`).
+the cross-process one call).
 
 Both backends read the **same** committed
 `testing/cross_backend/expected_schema.json` (column-presence is engine-portable,
@@ -1931,15 +2569,35 @@ same MAC under `atob`), an unpadded signature, and correctly signed
 with `authentication_required`. Controls: re-signing the keeper cookie's
 payload reproduces it byte for byte and it authenticates, and a leading-zero
 `0N` authenticates (the `u64` bound is on the value, not the digit count).
-Ungated; cross-process only. fuz_app's own wiring is
-`src/test/cross_backend/session_cookie_codec.cross.test.ts`.
-
-### Testing-backdoor credential gate — `cross_backend/testing_backdoor.ts`
-
-`describe_testing_backdoor_cross_tests({setup_test, rpc_path?, ws?})` —
-the negative-credential parity suite for the `_testing_*` backdoor actions.
-For each `_testing_*` action (the privileged writes, the audit barrier, the
-connection flood, and the introspection reads) it fires three principals over real HTTP: **anonymous** →
+Ungated; cross-process only.
+
+### Testing-backdoor declaration + credential gate — `cross_backend/testing_backdoor.ts`
+
+`describe_testing_backdoor_cross_tests({setup_test, capabilities, rpc_path?,
+ws?, extra_methods?})` — the backend's backdoor declaration, then the
+negative-credential parity suite for the `_testing_*` backdoor actions.
+
+**Declaration.** `capabilities.testing_backdoors` lists the backdoors the
+backend mounts, from `TESTING_BACKDOOR_METHODS` (`spine_surface_constants.ts`,
+the one list; `spine_surface_constants.testing_backdoors.test.ts` holds it to
+the `_testing_*` actions fuz_app's spine binary mounts). Each known backdoor
+the list leaves out is sent anonymously and must answer `method_not_found`
+(404): both spines look the method up before they authenticate (the TS
+dispatcher's lookup step, the Rust `perform_action`'s), so an unmounted method
+answers that whatever the credential, and a mounted one a 401. Each declared
+one gets the rows below, whose anonymous row fails as "declared but not
+mounted" on a `method_not_found`. So the declaration can't lie in either
+direction, and the suites gated on it skip only what the backend lacks. A
+declared name outside the known list, or a duplicate, throws at collection.
+The suite runs on every backend, one declaring only the required backdoors
+included — `describe_spine_cross_suites` refuses to exclude it, skip any of
+its cases, or hand it other `capabilities` through `overrides`.
+
+**Credential gate.** For each declared backdoor (the privileged writes, the
+audit barrier, the connection flood, and the introspection reads), and each
+`extra_methods` entry (`TestingBackdoorProbe` `{method, params?}` — a
+consumer's own daemon-token seam, which must start with `_testing_` and not be
+a known backdoor), it fires three principals over real HTTP: **anonymous** →
 401 `unauthenticated`, **session** → 403 `forbidden` `credential_type_required`,
 **bearer** → 403 `forbidden` `credential_type_required` — and, when `ws`
 (`{base_url, ws_path, origin?}`) is passed, sends each on a socket opened with
@@ -1950,15 +2608,23 @@ on the real dispatcher (the spec-derived `describe_rpc_attack_surface_tests`
 never enumerates them because they're off the declared surface). Each method is
 sent with **valid** params so each case varies only the credential (validation
 runs after the gates — order is 401 → authz → 403 → 429 → 400); the handler never
-runs. Cited property: `docs/security.md`
-§Test Backdoor Actions. Cross-process only (the `_testing_*` actions are
-mounted on the spawned binary, not the in-process app — like the ws/sse
-suites); ungated, since every cross backend that uses
-`default_cross_process_setup` mounts them. fuz_app's own wiring is
-`src/test/cross_backend/testing_backdoor.cross.test.ts`. The complement is the
+runs. The known backdoors' params are a `Record<TestingBackdoorMethod, …>`, so a
+backdoor added to the list fails typecheck until it has them. Cited property:
+`docs/security.md` §Test Backdoor Actions. The credential rows run
+cross-process only (the `_testing_*` actions are mounted on the spawned binary,
+not the in-process app — like the ws/sse suites); in-process, an app mounting
+none declares none and gets the declaration rows alone, one per known backdoor
+— fuz_app's in-process leg is `cross_backend/testing_backdoor_parity.db.test.ts`,
+while its cross legs declare every backdoor, so they run no declaration row.
+The complement is the
 in-process spec-level gate test (`src/test/testing/testing_actions_auth.test.ts`,
 asserting each spec declares `credential_types: ['daemon_token']`) + the
-`assert_no_testing_methods` surface invariant.
+`assert_no_testing_methods` surface invariant. fuz_app's conformance table
+also covers the same gates, through the auth rows it generates over the live
+mount (`live_rpc_endpoints`), which the differential compares across spines;
+this suite stays for consumers whose backends mount the `_testing_*` actions
+without a conformance table over their live mount, and for the declaration
+check.
 
 ### Identity-primitive parity — `cross_backend/identity_parity.ts`
 
@@ -2015,7 +2681,7 @@ USERNAME_LENGTH_MAX]` = `[3, 39]` boundary edges (just-outside → 400,
 
 Ungated (login + signup are on every spine). Runs both legs via the shared
 `{setup_test}` protocol: in-process (`identity_parity.db.test.ts`, plain
-`gro test`) and cross-process (`identity_parity.cross.test.ts`).
+`gro test`) and cross-process (the one call).
 The accepted-case 403s rely on `create_spine_route_specs` zeroing
 `signup_fail_floor_ms` (mirroring `login_fail_floor_ms: 0`) so they don't each
 pay the 250ms denial floor.
@@ -2146,6 +2812,15 @@ need a real recipient): admin **assigns** `participant` to a fresh account
 `participant` → recipient **accepts** → a role_grant lands. The `role_holder`
 principal is seeded via `extra_accounts: [{username, roles: ['participant']}]`
 (bootstrap-cradle direct grant) and named through `principals.role_holder`.
+The replay cases count audit rows behind `_testing_drain_effects`, so the
+backend must mount it — every spine binary does; an in-process leg mounts
+`create_testing_drain_effects_action` over an emitter built with
+`track_inflight: true` (`conformance_participation.db.test.ts`).
+`role` (default `SPINE_PARTICIPANT_ROLE`) names the role conferred, which must
+be admin-grantable in the backend's registry; `scope_kind` (default `'space'`,
+or `null` for a builtin role) is the scope the scoped-assign case uses, and
+`null` skips it. A backend with only the builtin roles runs the suite with
+`ROLE_ADMIN` — the scoped case skips, as a builtin is global-only.
 
 Both legs run in-process (`conformance_participation.db.test.ts`, plain
 `gro test`) and cross-process (`conformance_participation.cross.test.ts`, TS
@@ -2154,6 +2829,38 @@ the `cross_backend_parity` action-manifest gate green (it was Rust-only before).
 Cited property: `docs/identity.md` + the role-gated-participation design
 (admin-only conferral, immediate assign).
 
+### Offer decline + retract refusals — `cross_backend/role_grant_offer_lifecycle.ts`
+
+`describe_role_grant_offer_lifecycle_cross_tests({setup_test, rpc_path?, role?})` —
+the error paths of the two verbs that end a pending offer without a grant,
+which the WS notification suite drives only on the happy path. Canonical
+answers, from the handlers and the queries behind them
+(`auth/role_grant_offer_actions.ts`, `auth/role_grant_offer_queries.ts`):
+
+- **not a party → 404** `not_found` with reason `role_grant_offer_not_found`.
+  Decline is scoped to the recipient account and retract to the grantor actor,
+  so a stranger, the grantor declining, or the recipient retracting hears what
+  a missing offer answers — the case compares the two refusals whole — and the
+  offer stays pending (`docs/security.md` §"404-over-403 is the general mask").
+  The scope check runs before the terminal check, so a stranger hears 404 on
+  a decided offer too.
+- **decided → 400** `invalid_request` with reason `role_grant_offer_terminal`:
+  a decline or retract after an accept, a second decline, a second retract,
+  and either after the other.
+- **audit**: a decline writes one `role_grant_offer_decline` row
+  (`account_id` / `actor_id` the recipient, `target_*` the grantor, metadata
+  `{offer_id, role, scope_id}` plus `reason` only when one was given), a
+  retract one `role_grant_offer_retract` row (the grantor, targeting the
+  recipient, no target actor on an account-grain offer); refusals write none.
+  Read through `list_audit_events`.
+
+The single-request rows — decline and retract of an id naming no offer → 404
+— are in the conformance security slate, so the differential sends them to
+both spines. The keeper is the grantor and offers `role` — an admin-grantable
+role, `SPINE_PARTICIPANT_ROLE` by default; `ROLE_ADMIN` serves a backend with
+only the builtin roles. Ungated. The
+in-process leg is on the drained setup of `conformance_participation.db.test.ts`.
+
 ### Building a TS test-server binary — `testing_server_core.ts` + adapters
 
 The reusable shape for standing up a **spawnable TS** cross-process test
@@ -2165,7 +2872,7 @@ re-roll the serve / daemon-info / WS-attach / drain boilerplate:
 - `testing/cross_backend/testing_server_deno.ts` — `create_deno_testing_adapter()` (`Deno.serve` + `@hono/deno`, an optional peer dep; `Deno` declared locally so it typechecks under the Node toolchain). Spawn the entry with `--sloppy-imports` (Deno doesn't do `.js`→`.ts`; Gro's loader does, so the Node path needs no flag).
 - `testing/cross_backend/testing_server_bun.ts` — `create_bun_testing_adapter()` (`Bun.serve` + `@hono/bun`'s module-level `getConnInfo`, `upgradeWebSocket`, and `websocket`; `Bun.serve` declared locally so it typechecks under the Node toolchain). Needs the optional `@hono/bun` peer dep (the counterpart to Node's `@hono/node-server` + `@hono/node-ws`; `Bun.serve` is built in), and Bun resolves `.js`→`.ts` natively (no flag, unlike Deno). Reuses `create_node_runtime` (Bun implements the `node:fs`/`node:process` surface). WS is module-level + stateless (like Deno) — the `websocket` handler is threaded into `serve`, where `Bun.serve` wants it, so no post-serve attach. It carries `maxPayloadLength` at twice `max_message_bytes` rather than Bun's 16 MiB default: past its cap Bun drops the socket without a close frame (1006), so the headroom leaves a message just over the limit to the per-message check (`WS_CLOSE_MESSAGE_TOO_BIG`, as on Node), while a grossly oversized one is refused before Bun buffers it whole.
 - `testing/cross_backend/default_spine_surface.ts` — the canonical no-domain spine surface (account/admin/audit/signup + bootstrap): `spine_session_options`, `spine_roles`, `create_spine_route_specs`, `spine_rpc_endpoints`, `create_spine_surface_spec`. This is the **declared** surface — the `create_standard_rpc_actions` bundle the spec-derived suites auto-enumerate. It passes `daemon_token: true` (both spine binaries mount the daemon-token layer) and leaves `GET /api/surface` at its default, off — the TS spine binary does too, and the Rust `testing_spine_stub` serves none. Shared by the spine_stub cross test, the TS cross tests, and the binary.
-- `testing/cross_backend/full_spine_mount.ts` — `build_full_spine_rpc_actions(deps, options)` — the **full** live RPC mount: the declared bundle **plus** the off-declared-surface families the binary live-mounts (`_testing_*` backdoors, the cell verb set, the opt-in `actor_lookup` / `actor_search` resolvers). `build_full_spine_mount(deps, options)` builds it once for both of the binary's endpoints, returning `FullSpineMount` (`{rpc_actions, ws_actions}`): the WS list is `protocol_actions` plus every RPC action not already among them, twinning the Rust `testing_spine_stub`, which serves one registry on RPC and WS (the one difference is `cancel` — a registered protocol action on TS, owned by the read loop on Rust). Single-sources the mount so the binary and the `spine_method_coverage` reconciliation test build the same list.
+- `testing/cross_backend/full_spine_mount.ts` — `build_full_spine_rpc_actions(deps, options)` — the **full** live RPC mount: the declared bundle **plus** the off-declared-surface families the binary live-mounts (`_testing_*` backdoors, the cell verb set, the opt-in `actor_lookup` / `actor_search` resolvers). `build_full_spine_mount(deps, options)` builds it once for both of the binary's endpoints, returning `FullSpineMount` (`{rpc_actions, ws_actions}`): the WS list is `protocol_actions` plus every RPC action not already among them, twinning the Rust `testing_spine_stub`, which serves one registry on RPC and WS (the one difference is `cancel` — a registered protocol action on TS, owned by the read loop on Rust). Single-sources the mount so the binary and the `spine_method_coverage` reconciliation test build the same list. `create_spine_live_rpc_endpoints()` wraps the list, built on stub deps, as one endpoint at `SPINE_RPC_PATH` — the `live_rpc_endpoints` value the conformance table, the differential and the auth-row generator resolve off-surface methods from (no handler built there runs).
 - `testing/cross_backend/ts_spine_backend_config.ts` — `ts_spine_node_backend_config()` / `ts_spine_deno_backend_config()` / `ts_spine_bun_backend_config()` presets (in-memory pglet, no external infra), the TS analog of `rust_spine_stub_backend_config()`.
 
 fuz_app's own binary wiring (`src/test/cross_backend/testing_spine_server{,_node,_deno,_bun}.ts`) is the worked example: ~one `build_app` over `create_app_backend` + `create_app_server` (`rate_limiters: 'disabled_for_testing'` plus whichever login / action limiters its env toggles built, `build_full_spine_mount`'s two lists on one `rpc_endpoints` entry and two `ws_endpoints` entries — `/api/ws` and the role-gated `SPINE_ROLE_GATED_WS_PATH` — sharing one `transport`, which is also the role-grant-offer `notification_sender`), reusing `default_spine_surface`. `src/test/cross_backend/testing_spine_server.db.test.ts` builds it with the Node adapter in-process and asserts its surface lists both WS endpoints (the gated one with its `required_roles`) and passes the surface invariants. The `_node`/`_deno`/`_bun` entries differ only in which adapter they wire — `build_spine_app` is runtime-agnostic. It leaves `create_app_server`'s `auth_cleanup` off, as the Rust `testing_spine_stub` leaves its twin unscheduled: a background pass would delete rows and write audit rows under a running suite. A consumer's cross-process test binary may schedule it when nothing its suites seed is already expired (the conformance table's `expired_session` principal seeds a backdated session row); an in-process harness leaves it off.