@aiquants/daily-report 0.42.0 → 0.44.0

package/README.md

@@ -3,13 +3,14 @@
 Reusable **daily-report** feature package: a virtual-scrolling report list and detail UI with optimistic updates and SSE real-time sync (React Router
 v7 / v8), and a drizzle (**mssql**) server layer. It follows the `@aiquants/authz-*` DI layering: every app-specific concern (authentication, user
 resolution, id obfuscation, Redis, legacy tables, the page chrome) is injected through ports, so the package carries no application- or
-domain-specific knowledge. It is one module with three entries:
+domain-specific knowledge. It is one module with four entries:
 
 | Entry | Contents | Environment |
 | :--- | :--- | :--- |
-| `@aiquants/daily-report` | Types; the strict wire readers (`dailyReportDetailSchema` and `dailyReportSseMessageSchema`, built on the package's in-place reader; `readIdsStreamChunkLine` with `forEachIdsStreamRow`; `readDailyReportSearchMarksAnswer`); the action wire contract and the endpoint tables; the attachment URL codec and the thumbnail variants; the business-date normalizer and the echo-id pattern; the logger contract; the search wire types | isomorphic |
+| `@aiquants/daily-report` | Types; the strict wire readers (`dailyReportDetailSchema` and `dailyReportSseMessageSchema`, built on the package's in-place reader; `readIdsStreamChunkLine` with `forEachIdsStreamRow`; `readDailyReportSearchMarksAnswer`); the action wire contract and the endpoint tables; the attachment URL codec and the thumbnail variants; the business-date normalizer and the echo-id pattern; the logger contract; the search wire types (the search, the search-marks and the per-id `reports` answers) | isomorphic |
 | `@aiquants/daily-report/client` | `DailyReportPage`, list/detail components, hooks, action context, route helpers | browser (React) |
 | `@aiquants/daily-report/server` | `createDailyReportServer` (service + loaders/actions), `defineDailyReportSchema`, SSE fan-out reader, SQL result cache, the sharp thumbnail renderer | node |
+| `@aiquants/daily-report/testing` | `createDailyReportTestInstrumentation` (the views' test handle, the row pass's counters and the re-estimate counters, provided through the client entry's `DailyReportInstrumentationContext` in a host's test build only) and the types of the row pass's events | browser (tests) |
 
 ## Contents
 
@@ -87,7 +88,7 @@ pnpm add @aiquants/daily-report @aiquants/virtualscroll @aiquants/swipe-overlay
 names with ref callbacks that return a cleanup.
 `zod` may be 3.25.76 or later, zod 4 included (`>=3.25.76 <5.0.0`): the package reads zod only through its `zod/v3` entry, which every version in that
 range ships, so the shipped declarations compile and a mismatch names the same issue codes whichever version the host installs.
-The peer floor of `@aiquants/virtualscroll` is **3.17.0**: install 3.17.0 or later.
+The peer floor of `@aiquants/virtualscroll` is **3.18.0**: install 3.18.0 or later.
 Both views name their active row through its `activeItemIndex`, which renders `aria-activedescendant` in the same render as the row and keeps that
 row mounted, count that row as shown only beyond its `activeItemVisibleInset`, describe an empty composite by its empty text, and skip the rendering
 of far rows through its `itemZones` and `useVirtualScrollItem`; they bind its focus-ring colour variable `--aqvs-focus-ring-color` to the row outline
@@ -545,9 +546,12 @@ its payload — with one strict parser each, after authentication and before any
   The mismatch names the failing paths and the issue codes only, never a value (`<path>: <code>` items joined by a semicolon and a space, the root as
   `(root)`), so a host debugging a version skew or a rewriting proxy learns which fields failed and nothing it received reaches a log.
   The package's client fails the action with `[daily-report] <intent> answered a body that is not its result (<mismatch>)`, and reads the `report` and
-  `business-date` endpoints with strict schemas (`{ report }` and `{ reports }` of `dailyReportDetailSchema`): a body that does not match rejects with
+  `business-date` endpoints with strict schemas (`{ report }` and `{ reports }` of `dailyReportDetailSchema`) and the `reports` endpoint with the
+  strict schema of its per-id outcomes (`{ outcomes }`: exactly one outcome per requested id, in request order, so a missing, duplicate, unrequested
+  or reordered id fails the whole answer): a body that does not match rejects with
   `[daily-report] <endpoint> answered a body that does not match its schema (<mismatch>)`, a status other than 2xx with
-  `[daily-report] <endpoint> answered HTTP <status>`.
+  `[daily-report] <endpoint> answered HTTP <status>`, and a `failed` outcome rejects only that report's readers with
+  `[daily-report] reports answered the outcome failed for report <id>` (the batch's other reports settle; [Requests](#requests) under the text search).
   Every detail on the wire — an SSE message's report or posted comment, the action's answer and the read endpoints' answers — is read by one strict
   reader of the shape, on which `dailyReportDetailSchema` is built: it checks the parsed JSON value where it lies and outputs that same value when it
   conforms, so a conforming answer is neither copied nor reshaped (a zod object schema would copy every report's whole tree).
@@ -569,8 +573,9 @@ its payload — with one strict parser each, after authentication and before any
   viewer's id (`userId` of `DailyReportPage`, which the host's loader builds with this port) with the comment's author id (which the service writes
   with it), for comments that arrive by SSE too; an implementation that returns another text on every call (a fresh salt, for example) makes the
   viewer's own comments look like someone else's.
-- `redis` — `getClient()` (get/incr/xAdd/xRange/xRevRange) + `createClient()` (blocking xRead). Structurally matches a `node-redis` v5 client. If
-  omitted, SSE publishing is skipped (with a warning) and epoch is disabled.
+- `redis` — `getClient()` (get/incr/xAdd/xRange/xRevRange/xInfoStream) + `createClient()` (blocking xRead). Structurally matches a `node-redis` v5
+  client. The SSE catch-up from the stream origin reads XINFO STREAM's `length` and `entries-added`, which Redis 7.0 and later report (**Catch-up**
+  under the SSE route). If omitted, SSE publishing is skipped (with a warning) and epoch is disabled.
 - `externalSources[]` — When `Hub.source_type` matches, performs a `LEFT JOIN` on `Hub.source_id_num = idColumn` and converts fields via `mapRow`.
 - `draftLabelNames` — **Required**: the database label names that mark a draft, the canonical one first (such as `["Draft", "Work in Progress"]`,
   since sources may call their drafts by different names). `createDailyReportService` copies and freezes the list, and throws
@@ -595,7 +600,7 @@ its payload — with one strict parser each, after authentication and before any
   shared draft-label test, beside the hub row) or true when its creation category is one of the names; a row whose flag reads as anything but 1 or 0
   throws.
   The client compares no name: the views open the viewer's own draft in the editor by `isDraft` alone, so a draft named by any of the names, or by a
-  variant the collation equates, behaves as one ([Client wiring](#client-wiring)). The SSE stream's key carries the wire version (`<streamKey>:v3`),
+  variant the collation equates, behaves as one ([Client wiring](#client-wiring)). The SSE stream's key carries the wire version (`<streamKey>:v4`; [Realtime architecture](#realtime-architecture)),
   so an entry written before `isDraft` existed is never read.
 - `resolveVisibleSourceTypes(request, { reason })` — **Required row-level authorization port.** Returns the `Hub.source_type` values this request may
   view, or the explicit opt-out `{ unrestricted: "<reason>" }` of a deployment that does not restrict by source type. Applies uniformly to every server
@@ -639,7 +644,7 @@ its payload — with one strict parser each, after authentication and before any
 
   The client has no host logger port: its four channels of the same list write to the console from `info` — `[DailyReportActionProvider]` (the action
   provider: a failed action, the queue of SSE messages about uncached reports, a cache reload), `[DailyReportDetailLoader]` (the detail loading: a
-  stale update of a report's cache, a failed prefetch of a business date),
+  stale update of a report's cache, a failed prefetch of a business date, a failed refetch that left the shown report in place),
   `[DailyReportIdsStream]` (the ids stream client: a revalidation that gave up, a rejected malformed line, which ends the attempt, a skipped line of
   an unknown kind, a malformed stream anchor) and `[DailyReportSseConnection]` (the SSE connection hook).
   Every line, the server's and the client's, carries exactly one channel prefix: no message spells a `[DailyReport…]` prefix of its own.
@@ -698,12 +703,15 @@ writes no line in the refusal record below (it is not a cross-site refusal). Eac
 Each route's decisions — the name its refusals are recorded under (`api`, `action`, `sse` or `attachment`), the navigations it serves from another
 origin, its answer to a data request and its 403 — come from one policy of that route, so they cannot be paired wrongly, and an endpoint added with a
 streaming body is refused from the start.
+The cross-origin rule itself is `crossOriginRefusal` of `@aiquants/request-isolation` (a dependency of this package, so every package that adopts it
+refuses the same requests): a route's policy extends that package's `CrossOriginPolicy` (which navigations from another origin it serves), and the
+rule answers why it refuses (`cross-origin-fetch` or `foreign-origin`, below), which the refusal record writes.
 
 | Request | Answer |
 | --- | --- |
 | `Sec-Fetch-Site: same-origin` or `none` (a load the user started: the address bar, a bookmark) | Served: authentication and the route's own checks follow |
-| Any other `Sec-Fetch-Site` — `same-site` (another origin of the same site, such as a sibling subdomain), `cross-site` or an unknown value | 403 before authentication, unless the request is a top-level document navigation that the route serves: method `GET`, `Sec-Fetch-Mode: navigate`, `Sec-Fetch-Dest` exactly `document`, and a route policy that accepts it. Only the attachment route accepts one, and only for an original (`inline` or `download`, read by the loader's own strict query parser): a link in another page opens or downloads the original. The API, SSE and thumbnail routes accept no navigation from another origin |
-| No `Sec-Fetch-Site` | A safe method (`GET`, `HEAD`, `OPTIONS`) is served. An unsafe method is decided by `Origin`: no `Origin` is served (not a browser page), an `Origin` whose host is the host the request was addressed to (`new URL(request.url).host`, which the adapter builds from `Host`) is served, and `null`, an unparsable value, another host or another port is 403 |
+| Any other `Sec-Fetch-Site` — `same-site` (another origin of the same site, such as a sibling subdomain), `cross-site` or an unknown value | 403 (`cross-origin-fetch`) before authentication, unless the request is a top-level document navigation that the route serves: method `GET`, `Sec-Fetch-Mode: navigate`, `Sec-Fetch-Dest` exactly `document`, and a route policy that accepts it. Only the attachment route accepts one, and only for an original (`inline` or `download`, read by the loader's own strict query parser): a link in another page opens or downloads the original. The API, SSE and thumbnail routes accept no navigation from another origin |
+| No `Sec-Fetch-Site` | A safe method (`GET`, `HEAD`, `OPTIONS`) is served. An unsafe method is decided by `Origin`: no `Origin` is served (not a browser page), an `Origin` whose host is the host the request was addressed to (`new URL(request.url).host`, which the adapter builds from `Host`) is served, and `null`, an unparsable value, another host or another port is 403 (`foreign-origin`) |
 
 - **Requests without Fetch Metadata**: a browser sends no `Sec-Fetch-*` to an origin that is not potentially trustworthy (plain HTTP other than
   `localhost`), so such a request comes either from a client that is not a browser or from a page of such an origin. A browser always sends `Origin`
@@ -721,7 +729,9 @@ streaming body is refused from the start.
 - **The refusal record**: each handler factory keeps one bounded record of its refusals (state per factory), written on the `[DailyReportIsolation]`
   channel: to the configured `logger` with that prefix, or by default to the console from the `warn` level.
   A refusal with no open window writes one warn line at once,
-  `cross_site_rejected route=<api|action|sse|attachment> site=<value> mode=<value> dest=<value> method=<method>` (`-` for an absent header; a value
+  `cross_site_rejected route=<api|action|sse|attachment> reason=<cross-origin-fetch|foreign-origin> site=<value> mode=<value> dest=<value> method=<method>`
+  (the reason says which half of the rule refused: `cross-origin-fetch` when the Fetch Metadata names another origin, `foreign-origin` when a request
+  without Fetch Metadata uses an unsafe method and an `Origin` that does not name the request's host; it carries nothing the request sent; `-` for an absent header; a value
   outside the specification's shape — lower-case letters and hyphens, at most 32 characters — is written as the JSON string of its first 32
   characters, so a sender cannot forge the line's fields), and opens a window of 60 s that every route of the factory shares; later refusals in the
   window are only counted, per route.
@@ -784,8 +794,9 @@ reason is the audit trail, so `grep -rn "unrestricted:"` in the host lists every
   `"Internal"`, the package's own source type for the reports it creates (`DAILY_REPORT_INTERNAL_SOURCE_TYPE` on the shared entry). They are *not* your
   authorization resource keys; mapping a resource key (e.g. `report_legacy`) onto a source type (e.g. `legacy`) is the consuming app's job. Read the
   canonical set at boot from `dailyReportServer.knownSourceTypes` (frozen: `Internal` first, then each adapter's in order) and assert your mapping
-  against it — an unknown token silently matches zero rows. Fold your tokens with `foldDailyReportSourceTypeToken` (shared entry), the fold the server
-  applies to the tokens it reads, instead of a copy of it.
+  against it — an unknown token silently matches zero rows. Fold your tokens with `foldDailyReportSourceTypeToken` (the shared entry, and the client entry for route modules that ship
+  to the browser: the shared entry is not split, so importing the fold from it carries a second copy of shared modules into the route's chunk), the
+  fold the server applies to the tokens it reads, instead of a copy of it.
   Two adapters whose source types are equal ignoring case (an exact duplicate included), or an adapter whose source type is `Internal` in any case,
   stop `createDailyReportService` and `createDailyReportServer` with a `RangeError`
   (`[daily-report] externalSources[1].sourceType must be a source type that differs, ignoring case, from externalSources[0].sourceType "legacy"; got "Legacy"`):
@@ -1617,8 +1628,8 @@ and without the retry the victim would answer 500 and lose what it wrote.
 
 ### Realtime architecture
 
-1. Mutation services publish to Redis Stream (`<streamKey>:v3`, `daily-report:sse-stream:v3` by default: the key carries the wire version of the
-   embedded report, so a deployment that changes a required key of it reads no entry an older version wrote, and the stream of the previous version
+1. Mutation services publish to Redis Stream (`<streamKey>:v4`, `daily-report:sse-stream:v4` by default: the key carries the wire version of the
+   stream's messages and their embedded report, so a deployment that changes a required key of them reads no entry an older version wrote, and the stream of the previous version
    stops growing and can be deleted by hand; a host that reads or writes the stream itself, such as an integration test, builds the key with the
    server entry's `buildDailyReportSseStreamKey(streamKey)` instead of restating the version) in sequence:
    `invalidate -> epoch increment -> SSE publish`.
@@ -1627,20 +1638,27 @@ and without the retry the victim would answer 500 and lose what it wrote.
    `DailyReportSseReaderPort` — `ready()` and `subscribe(onEntry, onError)`, with the contract under **`connected` frame** below — which is the type a
    host's own reader implements: a plain object with the two methods is accepted, while the class type, which has private fields, would refuse one.
    The reader reads each live entry once per process and hands every subscriber the same frozen value (`DailyReportSseStreamEntry`:
-   `{ id, message }`): `message` is the entry's `data` field parsed as JSON and validated by `dailyReportSseMessageSchema` — the validated message
-   (`parsed`), the JSON value as published (`published`, with the server-only fields) and its text (`text`) — or `null` when the field is absent, is
-   not JSON or fails the schema (the last two logged once at `error`; such an entry is written to no connection — fail-closed — while the reader's own
-   read position moves past it).
-   Each connection only filters that value (recipient, source-type visibility, comment redaction) and never changes it, and the frame texts of the
-   variants that differ from the published text — without `recipientRawUserId`, and with the embedded report's comments emptied — are built at most
-   once per message and shared by every connection that writes them, so a live entry costs one parse in proportion to its size plus a filter per
-   connection, not one parse per connection.
+   `{ id, message }`): `message` is the entry's `data` field parsed as JSON and validated by the stream form `dailyReportSseStreamMessageSchema` (the
+   only form that declares the server-only fields: the six types that may be addressed — status-update, comment-add, comment-delete, report-create,
+   report-update and report-publish — carry the recipient's internal id `recipientRawUserId`, and the three that embed a report also the writer's,
+   `actorRawUserId`) — the validated message (`parsed`) and the JSON value as published (`published`, which only the recipient filter reads) — or
+   `null` when the field is absent, is not JSON or fails the schema (the last two logged once at `error`; such an entry is written to no connection —
+   fail-closed — while the reader's own read position moves past it).
+   Each connection only filters that value (recipient, source-type visibility, comment redaction, the actor) and never changes it. Every frame is
+   built from the parsed message, never from the published value or text: the message without its server-only fields, typed as the delivered form,
+   so a server-only field left in a frame fails the type check, and a key the stream schema does not know never reaches a viewer. A message that
+   embeds no report has one frame for every viewer; one that embeds a report has at most four — with the viewer's `viewerIsActor`, its comments
+   emptied for a viewer who may not read them — each built at most once per message and shared by every connection that writes it, so a live entry
+   costs one parse in proportion to its size plus a filter per connection, not one parse per connection, and every frame is one line of JSON.
    A host's own reader keeps the same contract: it reads an entry once — `readDailyReportSseStreamEntry(raw, logger)` (server entry) reads it as the
    package's reader does — and hands the same value to every subscriber.
 3. `sse.loader` is built on `@aiquants/sse/server` (`createSseResponse`, `terminalStreamResponse`, `startSseHeartbeat`, `readLastEventId`). Its
    responses carry the SSE response headers of `@aiquants/sse`, the routes' security headers (**Security headers** in [The API route](#the-api-route))
-   and the forwarded `Set-Cookie`, and no `Connection` or other hop-by-hop header (which HTTP/2 forbids). `recipientRawUserId` is filtered server-side
-   and removed before transmission to prevent internal ID leaks. Catch-up and live entries pass through the same filters (recipient, source-type
+   and the forwarded `Set-Cookie`, and no `Connection` or other hop-by-hop header (which HTTP/2 forbids). `recipientRawUserId` and `actorRawUserId` are read
+   server-side and never written to a viewer, to prevent internal ID leaks; each connection writes `viewerIsActor` instead (whether its viewer made
+   the write), so the delivered form (`dailyReportSseMessageSchema`, the root entry's `DailyReportSseMessage`) declares `viewerIsActor` and no internal id
+   on any type. The delivered schema does not refuse a key it does not know (it drops it), so a long-lived tab keeps accepting a newer server's
+   messages that carry additive fields; what a viewer receives is decided by the frame builder above. Catch-up and live entries pass through the same filters (recipient, source-type
    visibility, comment redaction).
 4. On the client, `useDailyReportSseConnection` runs on `useReopeningEventSource` (`@aiquants/sse/react`): full-jitter backoff from 2 s to 30 s, the
    failure count reset only after 60 s of healthy open (the 45 s stale window plus one heartbeat period), one native browser reconnect (which carries
@@ -1658,6 +1676,9 @@ and without the retry the victim would answer 500 and lose what it wrote.
    A comment that arrives by SSE is the viewer's own exactly when its author id equals the viewer's (`userId`, from the deterministic `encodeUserId`
    port), whichever tab or device posted it; a comment of another user with the same text as one being posted is never taken for it, and a posted
    comment's temporary id becomes its real id only through its own action's answer.
+   A report message (create, update, publish) is the viewer's own write exactly when it carries `viewerIsActor: true`: the client then caches the
+   payload's read and star state as its own write's answer, so the writer's other tabs and devices see their own create as read; otherwise it merges the
+   shared fields and keeps the viewer's own read and star state (false for a report it has not cached), so no write leaks its writer's state.
    Each action holds its own lock on the report it changes (its release frees only that lock and only once), so an overlapping action, an SSE change
    (which records the change time without locking) and the 1 s lock after a creation (which a later hold only extends) never end one another's locks.
 
@@ -1682,15 +1703,17 @@ unexpected error, a request that is not the package's client (another origin's p
 | Malformed cursor | 200, `retry: 86400000` → `event: resync-required` | rereads the ids (server cache bypassed) and reopens from the new anchor |
 | Cursor older than the oldest retained entry (the stream is trimmed with `MAXLEN ~ streamMaxLen`) | 200, `connected` → heartbeat → `retry: 86400000` → `event: resync-required` → end | same as above |
 | The start of a catch-up page is trimmed away before the page is read | 200, the entries delivered so far → `retry: 86400000` → `event: resync-required` → end | same as above |
-| Empty stream, or a cursor inside the retained window or in the future | 200, `connected` → heartbeat → catch-up (every entry) → live | continues |
-| Redis failure during the catch-up, or the stream tail cannot be read while the shared reader fixes its read position (`ready()` rejects; on the path without a cursor before `connected` is written) | the body ends (`producer-failed`) | one native reconnect with `Last-Event-ID`, then the utility's own backoff; the cursor is kept |
+| The stream origin `0-0` as the cursor (the anchor of an ids read on an empty stream) while the stream has removed an entry (XINFO STREAM's `entries-added` exceeds its `length`: trimmed or deleted) | 200, `connected` → heartbeat → `retry: 86400000` → `event: resync-required` → end | same as above |
+| Empty stream (any cursor: no page is read, and entries appended later arrive live), a cursor inside the retained window or in the future, or the origin `0-0` while the stream has removed no entry (the catch-up starts at the stream's first entry) | 200, `connected` → heartbeat → catch-up (every entry) → live | continues |
+| Redis failure during the catch-up, an XINFO STREAM reply without the counts (`length` and `entries-added` must be safe integers with `entries-added` ≥ `length` ≥ 0; a Redis older than 7.0 has no `entries-added`), or the stream tail cannot be read while the shared reader fixes its read position (`ready()` rejects; on the path without a cursor before `connected` is written) | the body ends (`producer-failed`) | one native reconnect with `Last-Event-ID`, then the utility's own backoff; the cursor is kept |
 
 - **Resume cursor**: `readLastEventId` reads the `Last-Event-ID` header first, then the `lastEventId` query parameter
   (`DAILY_REPORT_SSE_CURSOR_PARAM`). The browser's own reconnect reuses the URL it opened with (a stale query) but sends a fresh header, so the header
   is always the newer value. A cursor must be a Redis stream id of the form `<ms>-<seq>` with 1–15 digits per part; anything else is answered with
   `resync-required`. The client URL-encodes the cursor.
 - **`connected` frame**: `data: {"type":"connected"}` with `id:` set to the resume position (the cursor, or the newest entry at connect time when
-  there is no cursor). On the cursor path it is written before any Redis round trip.
+  there is no cursor), and without `id:` while that position names no entry (the origin cursor `0-0`, or an empty stream without a cursor). On the
+  cursor path it is written before any Redis round trip.
   Without a cursor it is written only after the shared reader has fixed its read position (`DailyReportSseReader.ready()`), so every entry appended
   after a client sees `connected` reaches that client; on the cursor path the catch-up is read after that point instead, so nothing appended between
   the catch-up and the position fix is lost.
@@ -1711,9 +1734,15 @@ unexpected error, a request that is not the package's client (another origin's p
   most 64 MiB into the process, also when every entry is as large as an event can be. A catch-up reads its pages per connection; a catch-up of 1,000
   small events takes 113 round trips (one check of the oldest entry and 112 pages, each new page reading 9 entries after its start).
 - **Catch-up**: entries after the cursor are read in pages of `DAILY_REPORT_SSE_CATCH_UP_BATCH` (`xRange` is inclusive, so each page skips its start
-  id) until the stream end; every entry is delivered. When a page does not start with its start id, the oldest retained entry is read again: if it is
-  newer than the start id, the range after it may have been trimmed, so the connection ends with `resync-required` instead of silently skipping it (a
-  cursor that is simply not an entry id inside the retained window continues).
+  id) until the stream end; every entry is delivered. The catch-up first reads the oldest retained entry. An empty stream reads no page, for any
+  cursor: the shared reader, subscribed before the catch-up, delivers every entry appended later live (a page read would take an entry appended
+  meanwhile for a trimmed range). A cursor that names an entry is witnessed by the oldest retained entry: when that is newer than the cursor, the
+  range after the cursor may have been trimmed, so the connection ends with `resync-required`. The stream origin `0-0` names no entry, so its witness
+  is that the stream has never removed an entry (XINFO STREAM's `entries-added` equals its `length`): the oldest retained entry is then the first the
+  stream ever got, and the first page starts there and delivers it too; otherwise the connection ends with `resync-required`. When a page does not
+  start with its start id, the oldest retained entry is read again: if it is newer than the start id, the range after it may have been trimmed, so the
+  connection ends with `resync-required` instead of silently skipping it (a cursor that is simply not an entry id inside the retained window
+  continues).
 - **Ids on the wire only increase**: live entries that arrive during the catch-up are queued, not written. The catch-up stops in front of the first
   queued entry (the fan-out reader delivers every entry after it in order), then the queue is written in id order and later live entries are written
   as they arrive. Writing a live entry first would let a disconnect move the client's resume position past catch-up entries it never received, and an
@@ -1725,8 +1754,11 @@ unexpected error, a request that is not the package's client (another origin's p
   provisional line). The service reads it inside the cached fetcher **before** the SQL, so every cache path (bucket hit,
   joining an in-flight fetch, refresh-ahead) returns an array that already reflects every update up to the anchor. The
   SSE hook does not connect until an anchor arrives and then uses it as the first cursor, which closes the gap between
-  loading the ids and opening the stream. `null` means "position unknown" (empty stream, no redis, read failure): the
-  hook then opens without a cursor and the server starts from the newest entry at connect time.
+  loading the ids and opening the stream. An empty stream anchors at the stream origin `"0-0"`, which the hook sends as
+  its cursor like any other anchor, so a report published between the ids read and the connect arrives through the
+  catch-up (**Catch-up** above). `null` means only "position unknown" (no redis, a read failure, or a viewer without an
+  internal user): the hook then opens without a cursor and the server starts from the newest entry at connect time,
+  so an entry appended between the ids read and the connect is not delivered (the gap that an unknown position leaves).
 - **Delivery is idempotent**: an anchor can be up to one ids-cache TTL old; replaying from it is safe because `report-*` messages upsert and
   `comment-add` is matched by comment id.
 - **Event size**: the service writes an event to the stream only when its JSON is at most 6,356,992 bytes: the action's form cap (1 MiB,
@@ -1978,37 +2010,51 @@ The 400s come in order, all before any service call: `q` and `combine` (`Invalid
 (`Invalid search query` with the plan's `reason`). `q` stays required: a blank `q` (`q=` included) with a filter is the filters-only search, and
 without one it is still the 400 `empty`.
 A request without filter parameters adds no condition to the SQL: its statement and parameters are those of the text search alone.
-`GET {apiBasePath}/reports?ids=<id,id,...>` (distinct canonical ids, at most 100) answers the visible details among them, `{ reports }`. Neither is
-cached on the server.
+`GET {apiBasePath}/reports?ids=<id,id,...>` (distinct canonical ids, at most 100) answers one outcome per requested id, in request order, `{ outcomes }`
+(`DailyReportSearchDetailsAnswer` of `DailyReportSearchDetailOutcome`): `ok` with the report (its delivered JSON copy, read strictly), `not_found`
+for an id the viewer cannot read, a missing id and a deleted report alike (never told apart, so the answer is no existence oracle), or `failed` for a
+report the viewer may read whose own assembly failed (its display fields, its mapping, its JSON copy or the strict read of that copy); the server logs a
+`failed` report's id and cause on its logger, and the answer carries no cause, so the batch's other ids are answered. The cause is logged once per
+read and report in a window of 60 s (`[DailyReportService] <read>: report <id> passed the visibility predicate but its own assembly failed` at
+`error`, the read being the service method, `getDailyReportDetailsByIdsByExternalId` here and `markDailyReportSearchHits` for the marks); later
+failures of that report in that read are only counted, and the window's end writes them as one `warn` line,
+`[DailyReportService] failed_report_suppressed count=<n> since=<the window's start, ISO> read=<read> report=<id>`, so a broken report that every
+batch asks for writes a bounded number of lines. The reports are read in slices under the request's signal, like the marks (**Slices** below).
+A failure before or across the
+visibility predicate (the viewer's resolution, the query, the batched label, comment and attachment reads, the canonical draft label) fails the whole
+request with 500, since a per-id `failed` for an id that never passed the predicate would tell it apart from `not_found`. Neither is cached on the
+server.
 `reports` has an admission of its own from the same factory, never the search's: 2 × the larger of `concurrency` and
 `DAILY_REPORT_SEARCH_BATCHES_IN_FLIGHT` (2, the batch reads the client keeps in flight) reads at once per process, of which one viewer holds at most
 half, so a viewer always passes the client's two concurrent reads (a `concurrency` of 1 admits 4 per process),
 and 10 × `rateLimitPerMinute` reads per viewer and minute, in a bucket apart from the search's, so paging through a large answer neither runs out of
 reads nor spends the searches.
-Its order is the search's: the ids (400), then a viewer without an internal user answered `{ reports: [] }` with no admission and no dataset query,
+Its order is the search's: the ids (400), then a viewer without an internal user answered every id `not_found` with no admission and no dataset query,
 then the admission with the request's signal (an aborted request takes no slot, returns its token and gets the bodyless 503; a read that finds the
 gate full or its viewer at its share waits for a slot like a search-marks batch, for at most 2 s, then gets 429 with `Retry-After: 1`; an empty bucket
-is 429 with one window's `Retry-After`), the query, and the slot's release whatever the outcome. Its refusal lines name `route=reports`.
+is 429 with one window's `Retry-After`), the read with the request's signal (in slices, yielding to the event loop between them), and the slot's
+release whatever the outcome. Its refusal lines name `route=reports`.
 `GET {apiBasePath}/search-marks?q=<text>&combine=intersection|union&ids=<id,id,...>` (the shown answer's query and at most 100 distinct canonical ids,
 the rows a view draws) answers `{ wordsDigest, reports, deferred }` (`DailyReportSearchMarksAnswer`): in `reports`, for each requested report the
-viewer may read that the answer's budget holds (below), once, its id, the mask of the keywords it matches (`matchedSets`: bit i for keyword i, for an
+viewer may read, whose delivered copy the server assembles (as `reports` does: a report that fails to assemble is logged and left out like an unreadable
+one, so one broken report never removes the marks of its neighbours) and that the answer's budget holds (below), once, its id, the mask of the keywords it matches (`matchedSets`: bit i for keyword i, for an
 OR of two or more keywords;
 `null` otherwise) and the marks of every non-empty field value the views draw (`fields`, by key: `subject`, `content`, `author`, `employeeName`,
 `updatedBy`, `category`, `creationCategory`, `customerName`, `interviewer:<i>:name|affiliation`, `attachment:<i>` and `comment:<id>:author|content`,
 the comment's id in the list `useDailyReportComments` returns).
 In `deferred`, the ids of the readable requested reports past the budget, in the answer's order (empty when it held them all), so a requested id is in
-`reports`, in `deferred`, or — not readable — in neither, and never twice. `wordsDigest` is the digest of the answer's `words`.
+`reports`, in `deferred`, or — not readable, or failed to assemble — in neither, and never twice. `wordsDigest` is the digest of the answer's `words`.
 A field's marks (`DailyReportSearchFieldMarks`) are the fingerprint of the raw value they were computed on (FNV-1a 32 over its UTF-16 units) and
 either `ranges`, flat `[start, end, tier]` triples in UTF-16 offsets of that value,
 or `dense: true` without `ranges`, for a field with more ranges than `maxFieldRanges` (10,000: more marks than a reader can tell apart, whose drawing
 alone would add tens of ms to the client's render; a one-letter word over a report of 21,200 units marks about 2,000). The client's reader refuses a
 field with both, a `dense` that is not `true`, a `deferred` id that was not requested, is listed twice or also has marks, and an answer that defers
-ids without carrying a report (the server always answers the first report, so such an answer breaks the contract, and asking again would make no
-progress).
+ids without carrying a report (the server always answers the first assembled report, so such an answer breaks the contract, and asking again would
+make no progress).
 A field's triples are its maximal runs of one tier, overlapping and adjacent occurrences merged into one, so they never overlap and a field carries at
 most one triple per UTF-16 unit of its value.
 An answer has a budget: at most 500,000 ranges and 4,000,000 raw UTF-16 units of the fields it marks.
-The reports are marked in the answer's order, and the first is always answered, so every request makes progress; from the first later report that
+The reports are marked in the answer's order, and the first assembled report is always answered, so every request makes progress; from the first later report that
 would take the answer past either bound (its units are counted before a field is marked, its ranges after), every report is deferred: its fields are
 not marked and its id goes to `deferred`, for the client to ask again (**Arrival** under **Highlights** below).
 The budget holds whole a one-letter word over 100 reports of 21,200 units each (about 200,000 ranges and 2,120,000 units; 1.6–2.9 MB, against 2.2 MB
@@ -2026,7 +2072,9 @@ runs, and its marks equal those of the per-occurrence definition byte for byte.
 work passes 8 ms or 5 ms have passed on the
 process's monotonic clock, and the first step of a slice always runs, so every slice makes progress), and the service yields to the event loop and
 checks the request's signal between two slices,
-inside a field too. No step of the work is longer than a block of 0.5 ms of estimated work, except the index text of one piece of a line (at most
+inside a field too. The delivered read slices the same way, with the same slicing, before the marks and as the whole of `reports` (a report's JSON
+copy and strict read are one step, so the read yields before the next report once a slice has run 5 ms, and the longest synchronous block of a
+`reports` answer is its one serialization); before the marks the service yields once more after it, so the marks start a fresh slice. No step of the work is longer than a block of 0.5 ms of estimated work, except the index text of one piece of a line (at most
 4,000 units) and one grapheme cluster longer than a
 block of the segmentation: on values of 1,000,000 units — only line breaks, one letter per line, invisible characters with line breaks, a fullwidth
 `ＡＢ` line with no cut between its pieces,
@@ -2049,17 +2097,19 @@ Its order is the search's and the details': 404 without the `search` block, 400
 400 for the ids, then a viewer without an internal user answered `{ wordsDigest, reports: [], deferred: [] }` with no admission and no dataset query,
 then the admission with the request's signal, the marks (in slices, yielding to the event loop between slices, inside a field too), the slot's release
 whatever the outcome, and the JSON. It is not cached on the server either.
-The service takes the request's signal too (`markDailyReportSearchHits(scope, userId, plan, ids, { signal })`) and checks it before each read and
-after each yield, stopping at the next slice once the client has left, between two slices of one field too.
-Options that are not an object carrying an `AbortSignal` stop the call before any query with a host-facing error: an omitted `options` or `signal` is
-a `TypeError`
-(`[daily-report] markDailyReportSearchHits: options.signal must be the request's AbortSignal (new AbortController().signal for a call that is never aborted)`),
-any other value a `RangeError` ending with `; got <value>`.
-The route always passes the request's signal; drizzle cannot cancel a running query, so the slot is held until the read in progress ends. A request
+Both per-id reads of the service take the request's signal (`markDailyReportSearchHits(scope, userId, plan, ids, { signal })` and
+`getDailyReportDetailsByIdsByExternalId(scope, ids, externalId, { signal })`) and check it before each query and after each yield, stopping at the
+next slice once the client has left, between two slices of one field too.
+Options that are not an object carrying an `AbortSignal` stop the call before any query with a host-facing error naming the method: an omitted
+`options` or `signal` is a `TypeError`
+(`[daily-report] markDailyReportSearchHits: options.signal must be the request's AbortSignal (new AbortController().signal for a call that is never aborted)`,
+and the same with `getDailyReportDetailsByIdsByExternalId`), any other value a `RangeError` ending with `; got <value>`.
+The two routes always pass the request's signal; drizzle cannot cancel a running query, so the slot is held until the read in progress ends. A request
 whose client left — while it waited, when its slot was granted, at one of the service's checks or after the service answered — is answered 503 without
 a body, with `Retry-After` and `Cache-Control: no-store` and no ETag, and writes no error line;
-the four search routes share this answer and its checks (the search, `reports` and `search-facets` pass no signal to their services and check it when
-the slot is granted and when the read ends; a read that fails with an error of its own is still the 500), and the refusal of an aborted request is
+the four search routes share this answer and its checks (the search and `search-facets` pass no signal to their services and check it when the slot
+is granted and when the read ends, `reports` and `search-marks` pass it to theirs; a read that fails with an error of its own is still the 500), and
+the refusal of an aborted request is
 never recorded as busy, on any of them (`search-facets` included).
 Its 200 carries no ETag and `Cache-Control: no-store` (serialized once, with the shared security headers), and so does every other answer of the
 endpoint — its 400, 404 and 429, the router's 405 and 500 for it, and that 503 —, as every answer of the API route that is not a 200 does (**The API
@@ -2118,8 +2168,8 @@ line wraps instead of truncating;
 it comes first in the field's description (before the syntax help), and the field is `aria-invalid` only for an invalid query (busy, unavailable and
 other failures are no input errors).
 The AND / OR toggle and the filter toggle share one look: a 24 px pill with 12 px semibold text, in the field face (OR; the closed filter row), whose
-boundary comes from the text-field token as the field's does, or the filled face (AND; the open filter row), blue-700 under white text (dark blue-600)
-and `Highlight` under `HighlightText` in forced colours (**Text fields** in [Selection and focus appearance](#selection-and-focus-appearance)).
+boundary comes from the text-field token as the field's does, or the filled face (AND; the open filter row), blue-800 under white text (dark: a light
+blue-300 fill under slate-950 text) and `Highlight` under `HighlightText` in forced colours (**Text fields** in [Selection and focus appearance](#selection-and-focus-appearance)).
 The faces differ only in colour, so a toggle that changes its face moves nothing. Each toggle stacks its current label and an invisible reserved label
 in one grid cell — the AND / OR toggle the other mode's label, the filter toggle its label with the largest number of selected values (every filter at
 its limit) —,
@@ -2131,14 +2181,17 @@ and that a match found through a reading is underlined with dots.
 While a search request runs or after it failed, the views keep the list they showed; an answer replaces the list in its order (a report the provider
 marked removed is left out), and the header shows the hit count. While an answer shows, the rows read their details by id in batches (`reports?ids=`)
 instead of by business date, and an answer goes into the per-report cache only, never into a business date's cached list.
-A row's id joins the waiting ids at the first animation frame after rows stop entering and leaving, so a fast scroll or a held key requests nothing
-for the rows it passes, and a window that stops waits at most one frame.
-The batches are decided when they are sent, by the scheduler the search marks use: from the rows still waiting, newest first, up to 100 ids a request
+Each view leads its rows' inputs: it keeps its rendered rows and 24–40 rows beyond each rendered edge subscribed to the details and the marks, in
+chunks of 8 rows (32 on each side after a jump; **Highlights** below), so the rows a held key mounts find their details already loaded.
+An id joins the waiting ids at the first animation frame after rows stop entering and leaving, so a fast scroll requests nothing for the rows it
+passes and the lead let go, and a window that stops waits at most one frame.
+The batches are decided when they are sent, by the scheduler the search marks use: from the ids still waiting, newest first, up to 100 ids a request
 and `DAILY_REPORT_SEARCH_BATCHES_IN_FLIGHT` (2) requests at once per API base path (an aborted request keeps its slot until its fetch settles), each
 sent `cache: "no-cache"` with a signal of its own.
-A row that unmounts leaves its load, so an id no row waits for is not sent, a request none of whose rows waits any more is aborted, and a row that
-comes back asks again. A report a 2xx answer lacks reads as `null` (not visible, or deleted), and another status, a body that does not match the
-schema or a network failure is the rows' error (`[daily-report] reports answered HTTP <status>` for a status).
+A row that unmounts leaves its load, and the details of a report are loaded once for all of its readers (the rows, the lead, the side pane), so an
+id nothing waits for is not sent, a request none of whose ids is still waited for is aborted, and a row that comes back asks again. A report a 2xx answer lacks reads as `null` (not visible, or deleted), and another status, a body that does not match the
+schema or a network failure is the rows' error (`[daily-report] reports answered HTTP <status>` for a status), except over a report a row already
+shows: a failed refetch of an expired report leaves it in place (the shared detail record under `useDailyReportDetail` below).
 A 429 whose `Retry-After` is at most 5 s (it covers a full admission gate's `Retry-After: 1` and stays below the rate bucket's 60 s window) keeps the
 rows loading, with no error and no `null`, and asks once more after that delay for the rows still waiting; a second 429, or one without such a
 `Retry-After`, is the error.
@@ -2244,7 +2297,7 @@ While an answer shows, the List cards, the side pane and the DetailList rows mar
   fill continues under the `…` while its underline ends at the last character shown (a cut at a mark's start shows a filled `…` alone).
   An `interviewerWithAffiliation` template that does not insert the name and the affiliation verbatim (it rewrites them, uses one twice, or words
   itself by their values) draws the pill plain. `LIKE` counts an occurrence inside a grapheme cluster, so such a match marks the whole cluster.
-- **Look**: one token: yellow-200 under slate-900 (dark yellow-800 under yellow-50; 15.33:1 and 6.61:1 on any surface, since the mark sets its own
+- **Look**: one token: yellow-200 under slate-900 (dark yellow-900 under yellow-50; 15.33:1 and 8.38:1 on any surface, since the mark sets its own
   text colour), a solid underline for a word and a dotted one for a reading (a cue that does not depend on colour), and the system `Mark` / `MarkText`
   in forced colours.
   It writes `margin`, `border` and `padding` 0 and inherits the font, so a host's `mark` rule cannot change it and a mark changes no width, no line
@@ -2265,34 +2318,46 @@ While an answer shows, the List cards, the side pane and the DetailList rows mar
 - **Arrival**: the screen holds one marks store per shown answer (inside the client bundle), only while a view draws an answer that has words: without
   `config.search`, before the first answer is drawn, for a filters-only answer (it has no words, so nothing is marked and no match indicator shows),
   after the release and for a view rendered on its own there is none, and the DOM is the plain one.
-  A row wraps its subtree in the package's marks scope, which subscribes to the report's marks while the row is mounted and hands them to its leaves
-  through one row context (the marks, their revalidation, the row's tally and the indicator's settings) that only the scope provides:
+  A row hands its marks scope the marks of the unit that drew its card: the row reads the report's details and marks through its input source from
+  the moment it mounts as a shell (the first subscriber of a report asks for its marks) and draws them with its units (**Rows mount in two passes**
+  under [Keyboard, focus and selection](#keyboard-focus-and-selection-list--detaillist)), so a card whose marks are known is drawn with them in its first
+  commit, never plain first, and marks that arrive later are drawn by one unit of the row, which keeps the row's box (the row stays skippable).
+  The desktop side pane reads the marks with a deferred reader instead: its first render after a change of report draws the text plain, and the marks
+  follow in a deferred render.
+  The scope subscribes to nothing: it hands the marks to its leaves through one row context (the marks, their revalidation, the row's tally and the
+  indicator's settings) that only the scope provides, and settles the row's tally in its own layout effect, after its leaves registered;
   a leaf, a match indicator or a List card's match description drawn outside a scope while the screen holds a store stops with an error naming the
   package, so no leaf draws marks that no tally counts.
-  The row body reads no marks, so an arrival re-renders only the scope, the marked leaves and the match indicator — never the row's body, header,
-  attachment list or comment section, and never another row; a newly mounted row draws its text plain first and its marks in a deferred render.
+  The card body reads no marks, so an arrival re-renders only the row's container and frame once (one unit) or the side pane's marks scope, then the
+  scope, the marked leaves and the match indicator — never the row's body, header, attachment list or comment section, and never another row.
   A leaf registers in its row's tally only once the row's marks have arrived (the indicator and the description say nothing about a row without
-  marks), so a row that mounts during a held key adds no tally work before its marks, and the tally builds its summary when it is read and tells its
-  readers once, at the end of the task that changed it, however many leaves registered in it.
+  marks), in one layout effect that revalidates, registers and returns its unregistration (an opaque token that removes exactly that registration),
+  so a row that mounts during a held key adds no tally work before its marks, and the tally builds its summary when it is read and tells its readers
+  once, at the end of the task that changed it, however many leaves registered in it: a card's match description is complete by the end of the task
+  that committed the card.
+  While an answer is shown, each view also keeps the rows beyond its rendered range subscribed (the input lead: 24–40 rows beyond each rendered edge,
+  8 more on the side it travels towards whenever fewer than 24 remain, 32 on each side after a jump), so a row that mounts during a held key finds its
+  marks and details in the stores.
   A report's first subscription reaches the requests through a batching window of 240 ms: outside a window it is handed on at once, together with the
   subscriptions of the same task, and opens a window; the subscriptions made inside the window are handed on together at its end, which opens the next
-  window while rows keep mounting, and a row that leaves inside the window asks for nothing.
-  A held key mounts one row per key at the overscan's edge, 15 rows and about 0.5 s of key repeats before the row shows, so a request at the window's
-  end is answered and drawn before its rows are visible, while a hold sends about one request per window (4–5 in each 1.2 s hold of the perf harness).
+  window while first subscriptions keep coming, and a report whose subscribers all left inside the window asks for nothing.
+  During a held key the windows are opened by the lead's chunks of 8 rows, one chunk every 8 keys (about 240 ms at a 30 ms repeat), so a chunk never
+  waits for the window the previous chunk opened, and a 40-key hold sends 4–5 requests per store; a row is the first subscriber of its report only
+  when the lead does not hold it yet (the view's first render, after a jump, or a scroll faster than the lead).
   The epoch's renewal, a field's revalidation, a 429's retry and the deferred ids do not wait for the window.
   The requests are decided at send time: a subscribed report waits in one queue, and each free request slot — two in flight at most — takes the newest
-  waiting reports that a row still subscribes to, at most 100 a request, never cached. A report whose rows left while it waited is dropped, so a
-  scroll or a held key sends nothing for the rows it passed, and the window it stops on goes out in the first free slot.
-  A request whose rows have all left is aborted (the server then stops computing its marks; **Requests** above), and a row that leaves before its
+  waiting reports that are still subscribed (by a row or the lead), at most 100 a request, never cached. A report whose subscribers left while it waited
+  is dropped, so a scroll sends nothing for the rows it passed and the lead let go, and the window it stops on goes out in the first free slot.
+  A request none of whose reports is still subscribed is aborted (the server then stops computing its marks; **Requests** above), and a row that leaves before its
   marks were sent, or whose request was aborted, asks again when it returns.
   An aborted request keeps its slot until its fetch settles, so the requests in flight, aborted ones included, never exceed the two the server's
   per-viewer wait queue is sized for while it still winds the aborted ones down.
   The store keeps one record per report (its marks, the send order that brought them, the epoch it was asked in, its 429 retry and its revalidations)
-  and forgets the oldest records of reports no row subscribes to beyond 400 (2 × the two requests in flight × 100: the answers still in flight and as
-  many rows just left), so its memory follows the drawn window, not the distance scrolled; a forgotten report asks again when a row subscribes to it.
+  and forgets the oldest records of reports nothing subscribes to beyond 400 (2 × the two requests in flight × 100: the answers still in flight and as
+  many reports just let go), so its memory follows the drawn rows and their lead, not the distance scrolled; a forgotten report asks again when it is
+  subscribed again.
   The ids an answer defers (`deferred`, past the server's budget) are asked again through the same scheduler, once the answer arrived in the epoch it
-  was sent and carried at least one report: an id a row still subscribes to is queued again, any other is given back, so a row that returns asks
-  again.
+  was sent and carried at least one report: an id still subscribed is queued again, any other is given back, so a row that returns asks again.
   The server always answers a request's first report, so every re-ask makes progress and the re-asks end with the ids asked in the epoch; a deferral
   without any report breaks the contract and is not asked again (those rows stay plain for the epoch), and a previous epoch's deferral is not queued
   (the epoch's renewal asked again for every subscribed report).
@@ -2304,7 +2369,7 @@ While an answer shows, the List cards, the side pane and the DetailList rows mar
   painted and the field asks once for fresh marks. An answer whose `wordsDigest` differs from the shown answer's words is dropped; a quiet re-query of
   the same search makes the marks stale and the mounted rows ask again;
   401 and 403 call `onSessionExpired`; a 429 whose `Retry-After` is at most 60 s (one window of the server's rate bucket) is asked again once, after
-  that delay, for the reports a row still subscribes to then (one whose rows left meanwhile asks again when a row returns), and a 429 without a
+  that delay, for the reports still subscribed then (one whose subscribers left meanwhile asks again when it is subscribed again), and a 429 without a
   `Retry-After`, or with a longer one, sets no timer and leaves its reports plain for the answer's epoch (a delay of 2^31 ms or more would overflow
   the timer and ask again at once);
   any other failure of the request — a network failure, an abort, another status, a body that is not JSON — leaves those rows plain for as long as the
@@ -2345,9 +2410,13 @@ narrow for the author and the slot the slot drops to a 16 px line of its own ins
   A DetailList row's description (`aria-describedby`) ends with that element while the screen holds a marks store, so moving through the rows with the
   arrow keys reads the sentences each row shows.
 - A List card shows no slot. While the screen holds a marks store, the description of its row and of its primary button ends, after the preview,
-  with a `hidden` element inside the card's marks scope (`SearchMatchDescription`, `data-daily-report-search-match-description`) that holds the marked
-  fields' sentence alone (empty while the card draws no match; the List does not announce a hidden match), so the active row's announcement says what
-  matched and whether only a reading did. Without a store the card's description is unchanged.
+  with a `hidden` element inside the card's marks scope (`SearchMatchDescription`, `data-daily-report-search-match-description`) that holds the same
+  sentences the DetailList row's indicator holds for the same report under the same answer, built by one rule: the matched keywords, the marked fields
+  and the hidden match (a card whose leaves draw none of the report's matches — a report matched only in the body beyond the preview, for example —
+  says the hidden match in the List, while the DetailList, which draws the whole body, names the content field). The element has no box, so the
+  sentences never change the row's height, and each description reads them once; they are empty until the marks arrive. So the active row's
+  announcement says how many keywords matched, what matched, whether only a reading did and whether the match lies outside the card. Without a store
+  the card's description is unchanged.
 
 ## Client wiring
 
@@ -2407,14 +2476,29 @@ render (`[daily-report] config.headingLevel must be an integer from 2 to 5 …;
 `DailyReportPage` is layout-agnostic (header rendering via `renderHeader` slot, error boundaries/footer control managed by the app). For fine-grained
 usage, `DailyReportActionProvider`, `DailyReportResolvedContent`, `useDailyReportDetail`, etc. can be imported individually.
 Every field `useDailyReportDetail(reportHubId, businessDate)` returns — `report`, `error`, `isLoading` and `isRefetching` — belongs to the id it is
-called with: the hook keeps them as one record keyed by the id. On the first render after the id changes it already returns that id's starting state:
-its cached report (one definition, also used by the loading effect: the report cache, expired entries included, then the business date's cached list),
-`isLoading` only when nothing is cached, no error and no refetch yet — never the previous id's report, error or loading flags.
-An expired cached report is therefore drawn at once, never preceded by `null`, and refetched behind it; an answer that arrives for an earlier id, or
-after the component unmounted, is dropped. An id of 0 or less fetches nothing and returns no report (0 also returns an `Invalid ID` error).
-The first load of a report that is not cached starts inside the hook's effect, with no task between the row's mount and its request, so a held arrow
-key's stream of keydowns cannot postpone it until the key is released; only the refetch of an expired cached report waits 120 ms, to absorb rows that
-only scroll past. Loads of reports of one business date share one request.
+called with. The details of a report live in one record per report id that every reader of the screen shares — the views' rows, the views' input
+lead while a search answer is shown, the List's side pane and the hook — so one report has one record and one load whoever reads it: its first
+reader's subscription starts the load and its last reader's leaving stops it (an answer that arrives after that is dropped), and a cache write
+reaches the readers of its own report only, once per answer. The hook copies the record into state at default priority. On the first render after
+the id changes it already returns that id's starting state: its cached report (one definition, also used by the load: the report cache, expired
+entries included, then the business date's cached list), `isLoading` only when nothing is cached, no error and no refetch yet — never the previous
+id's report, error or loading flags. An expired cached report is therefore drawn at once, never preceded by `null`, and refetched behind it. An id of
+0 or less fetches nothing and returns no report (0 also returns an `Invalid ID` error). A row and the side pane that show one report share its
+record, so they never run two loads of it at once, and readers waiting on one load of a report not shown yet receive its failure once each. A
+settled report is shared with every later reader while its cache entry is fresh. Once the entry has expired, a reader that subscribes to the record
+— the side pane, which is rebuilt for every report it shows, a row that mounts, an id that enters the input lead's band — re-validates it after
+120 ms (the same wait as the refetch below), even while a row keeps the record open: the record keeps the expired report meanwhile (never a loading
+state), every reader that subscribes before the answer shares the one request, and the answer reaches every reader once; a report selected again
+inside its TTL is not fetched. A refetch of a shown report that fails (the re-validation, or the first reader's refetch of an expired cached report)
+leaves the report in place with no error and only logs a warning on `[DailyReportDetailLoader]`, so the next new reader re-validates again. A settled
+load error is not shared either: a reader that subscribes to a record holding an error — a row that mounts, an id that enters the input lead's band,
+the side pane — asks again, and the answer replaces the error. Only a new subscription asks again or re-validates (a re-render or a second
+subscription of the same listener does not, so a row that keeps showing a failure or an expired report never loops), and a refusal of the viewer's
+session (401 or 403, which cannot succeed before `onSessionExpired` has run) is shared like an answer: it becomes the record's error even over a
+shown report, and no new reader asks again or re-validates.
+The first load of a report that is not cached starts inside its first reader's subscription, with no task between the row's mount and its request,
+so a held arrow key's stream of keydowns cannot postpone it until the key is released; only the refetch of an expired cached report waits 120 ms, to
+absorb rows that only scroll past. Loads of reports of one business date share one request.
 
 Mutation failures (save / publish / delete / comment) are surfaced through an error seam: inject `config.onError(info: DailyReportErrorInfo)` to route
 them into your own toast/notification system, or omit it to use the package's built-in notice. Failures on a continuation that resolves after a
@@ -2700,8 +2784,8 @@ view, and no script computes or writes a height.
   text anyway.
 - **Empty list**: an empty view shows exactly one message, `VirtualScroll`'s own empty state with the engine label `labels.noItems` (en "No items", ja
   「項目がありません」), which `VirtualScroll` draws over the top of its content, out of the flow, so an empty view keeps the same box. The views render no
-  message of their own; they only theme the engine's (on `VirtualScroll`'s root: 16 px above and below, slate-500 in light and slate-400 in dark:
-  4.55:1 and 7.66:1 against the page, where the engine's default grey reaches only 4.17:1 in dark).
+  message of their own; they only theme the engine's (on `VirtualScroll`'s root: 16 px above and below, in the quiet text colour: 7.39:1 and 9.75:1
+  against the page in light and dark, where the engine's default grey reaches only 4.17:1 in dark).
   Because the views pass an active row (`activeItemIndex`, `null` while the list is empty), `VirtualScroll` draws the message outside the composite —
   in a layer over the composite's box, with the same pixels and the same `.aqvs-no-items-container` / `.aqvs-no-items-text` hooks — and names it first
   in the composite's `aria-describedby`, before the key help: the `treegrid` owns nothing but rows, and a screen reader entering an empty view (a
@@ -2761,7 +2845,8 @@ the resize handle and the side pane lie outside the list.
   leaving the view and unmounting end it without applying it.
   On a slow device the keys therefore never queue up, and the selection stops when the key is released. `Ctrl+Home` / `Ctrl+End` are never
   accumulated. While a stream lasts, the desktop side pane keeps showing the report the stream started from (see **List side pane** below), and rows
-  far from the active row stay shells (see **Rows mount in two passes** below).
+  get their bodies only in the frames without a key, far rows behind the travel direction after the key is released (see **Rows mount in two
+  passes** below).
 - **Ignored keys**: `Alt` / `Ctrl` / `Meta` / `Shift` combinations other than `Ctrl+Home` / `Ctrl+End` alone (so `Ctrl+PageDown` and `Shift+End` keep
   their browser meaning); an event whose default is already prevented; IME composition (`isComposing` or `keyCode` 229);
   keys whose target is neither the view's composite nor a control inside one of its rows (the scroll bar, the side pane, the mobile overlay); the
@@ -2852,35 +2937,86 @@ the resize handle and the side pane lie outside the list.
   renderer do not render, and no context value changes per key.
   The app's keyboard harness counts the style and layout work that starts inside a keydown dispatch or inside a frame callback the key caused: 0 in
   every run of its nine conditions.
-- **Rows mount in two passes.** A row that a commit mounts outside the visible range first renders as a **shell**: its row frame, with its role,
-  id, position, set size, level and selection, named by the report's ISO business date and `aria-busy="true"`, and an empty surface
-  (`data-daily-report-row-shell`) that fills the box `VirtualScroll` gives the row, so nothing moves when the body arrives.
-  One scheduler per view then advances the rows one at a time — a shell to its body, a body that still draws an older report to the latest loaded one
-  (a report that arrived by a load's answer or an SSE update) — each unit applied with `flushSync` as one commit of its own, in a slot that runs right
-  after a frame's rendering (a `MessageChannel` task armed from the scheduler's own task by `requestAnimationFrame`, never from a keydown, a commit or a
-  held key's frame).
-  The order is by zone — visible, then the active row's reach, then near, then far (**Far rows skip rendering** below) — and within a zone by the
-  distance from the active row, the side the keys travel towards first. A slot applies one unit, and a second when the next pending unit is visible or
-  in reach.
-  A row that becomes visible with a pending unit renders its body inside the commit that made it visible, so a visible row is never a shell. A newer
-  loaded report for a row that is already visible is applied inside the commit that brings it, outside a key hold, so such a row never shows an outdated
-  rendering of a loaded report while no key is held. A commit that brings a pending row into the reach or the near band wakes a sleeping scheduler, so
-  the rows a key can reveal get their bodies in a slot before that key.
-  While a key is held, the scheduler keeps its slots out of the frames that render the keys:
-  - far units wait: far rows stay shells and take no arriving card until the key is released;
-  - a slot applies one unit, and a second only when both rows have boxes of a fixed size (the List's slots): two measured DetailList bodies do not fit
-    one key-free frame;
-  - a slot runs only when the frame that renders its commit starts before the next repeat keydown can arrive. The next keydown is predicted from the
-    hold's own keydowns (the median interval of the latest 8 and their earliest phase; `predictNextHoldKey`), and the frame interval is the shortest
-    gap between the scheduler's consecutive frame callbacks, measured again for each hold. The decision is taken in the frame callback that would arm
-    the slot, and taken again when the slot runs (a key that arrived after the frame began, or a frame that ran long, holds the unit back to the next
-    frame); while the cadence or the frame interval is still unknown (the first one or two frames of a hold), no slot runs;
-  - a newer loaded report for a visible row waits for the next slot that runs, ranked first.
-
-  So during a hold the units go to the frames without a key commit, and a row the keys reveal before a slot reached it renders its body in the key's
-  own commit (counted).
-  Decisions never wait for the drawing: the safety valve that removes a row whose report no longer exists, and a DetailList body's draft and
-  ownership, its opening of the viewer's own draft in the editor and its edit button's action, read the loaded report itself.
+- **Rows mount in two passes.** A row that a commit mounts outside the visible range first renders as a **shell**: its row frame, with its role, id,
+  position, set size, level and selection, and a surface (`data-daily-report-row-shell`) that fills the box `VirtualScroll` gives the row, so nothing
+  moves when the body arrives. The surface is the card's surface without content (the card surface token: its radius, border, colours and shadow),
+  so the selection ring and the focus outline around a shell are concentric with it as around a card, and the resting surface does not change when
+  the card lands. While the report's details are still loading, the shell is named by the report's ISO business date and is
+  `aria-busy="true"`. Once the details are in the store, the shell is a **named shell**: it holds, hidden, the card's own name and the parts of the
+  card's description that do not depend on drawing (the row state, the attachment marker with its count, the source badge's text, the List preview and
+  the matched-keywords sentence), made by the same functions as the card's, so the active descendant announces the row as it will read as a card. Only
+  the matched-fields and outside-view sentences, which the drawn leaves report, arrive with the card. The settled DOM never contains a shell.
+  One scheduler per view then advances the rows one at a time — a shell to its body, a body that still draws older inputs to the latest ones (a report
+  that arrived by a load's answer or an SSE update, or the report's search marks) — each unit applied with `flushSync` as one commit of its own.
+  A row reads its report's details and search marks through one input source from the moment it mounts, and a unit draws what the source holds when it
+  is applied, so an arriving answer never re-renders a row by itself: a row renders only through its units and its own state (such as its edit form).
+  - **Units commit only in key-free frames.** The scheduler applies units only inside its own frame callback, and only when nothing of a key happened
+    since its previous callback: no `keydown` or `keyup` was dispatched in the view's window (two passive capture listeners that only count, so they
+    read nothing), the held key's stream applied no step in a frame callback, and the stream holds no accumulated step. A unit the scheduler applies
+    in its own frame callback therefore never renders in the frame that renders a key, a single press included; a unit commits elsewhere only in the
+    two cases named below (a row that becomes visible, and a newer input of a visible row outside a key hold). The first callback after the scheduler
+    wakes only calibrates. The scheduler arms itself
+    with a `MessageChannel` message and calls `requestAnimationFrame` only from its own message and callbacks — never from a keydown, a commit or the
+    held key's frame — with one exception: when a key hold starts (in its first repeat keydown, before the hold's first step) in a view that has a
+    measured row (each mounted row declares how its box is sized, and the DetailList's rows are measured), and the scheduler has no frame requested and
+    has not classified the hold yet, it requests one bare listening frame there (it applies no unit, writes no DOM and reads no clock in the keydown),
+    and its `hold-start` event says so (`listening`), so a harness that counts frames requested in a keydown as key work can tell the scheduler's frame
+    apart. A view whose rows all have fixed boxes (the List) never listens, since the key frames' evidence below classifies measured rows only: during
+    a hold its scheduler sleeps whenever no unit can run.
+  - **A frame's share.** A key-free frame applies its first unit, then more units only while their measured costs (the p90 of the latest 32 per kind
+    of unit, known after 8; kinds are a box sizing and a change: a body over a shell, a change that can change the box, the marks alone) fit half the
+    frame interval and the time left in the frame. At today's costs a DetailList card takes one frame, and the List packs 1–3 rows. A frame whose
+    callbacks started late (a GC or a long task ran before them) skips its first unit when that unit no longer fits (a 2 ms margin); a unit of a
+    visible or reach row is skipped by at most one late frame in a row.
+  - **Order.** By zone — visible, then the active row's reach, then near, then far (**Far rows skip rendering** below) — and within a zone by the
+    distance from the active row, the side the keys travel towards first; equal ranks keep the order the units were added in. The travel direction is
+    the active row's move, read at every frame callback and, during a hold, whenever units are ranked, so a hold takes its direction from its first
+    key step (a hold upwards draws the far rows above from its first key) and never from a jump before it. While a key is held, far rows ahead in the
+    travel direction are drawn after the near ones, so the rows a hold brings into the reach already have their bodies; far rows behind wait for the
+    key's release. While the active row is pinned outside the rendered range or absent (a wheel or a fling), the rows are ranked by the pane instead:
+    those ahead of the pane's travel first, by their distance from the visible range, and while the pane moves, the units of one viewport ahead of it
+    are never skipped as late, so the rows a fling passes are drawn before they become visible.
+  - **Visible rows are never stale.** A row that becomes visible with a pending unit renders its body inside the commit that made it visible, so a
+    visible row is never a shell and never shows outdated data or marks (counted), with one exception on a device where a card exceeds a frame (below). Outside a key hold, a newer input of a row that is already visible
+    is drawn at once: in the commit that brings it, or, when it arrives as a store notification, in one commit at the end of the notifying task.
+  - **Search answers lead the rows' inputs.** While a search answer is shown, each view keeps its rendered rows and 24–40 rows beyond each rendered
+    edge subscribed to the details and the marks (8 more rows on the side it travels towards whenever fewer than 24 remain, 32 on each side after a
+    jump), from its range report, which `VirtualScroll` delivers in a frame callback, never inside a keydown. A row that mounts during a held key finds
+    its details and marks already loaded, so every unit of a hold draws one complete card with its marks, and the requests leave in chunks (4–5 per
+    store in a 40-key hold; after a jump one request per store carries the rendered window and 2 × 32 rows, at most 96 ids). The lead holds its
+    subscriptions per store and releases only the swapped store's: a new answer (a new marks store) re-leases the marks and keeps the details and their
+    request in flight, so it never asks for the same ids twice; a new details store also forgets the edges and leases as after a jump. The by-date
+    views keep the by-date prefetch.
+  - **Heights settle in the frame that lays the body out.** The DetailList's row-height delivery — one `ResizeObserver` per view, made from the
+    view's own window where its scroll container attaches, beside the scheduler, and disconnected when the container detaches — commits each delivery
+    in one synchronous commit:
+    the row's height, `VirtualScroll`'s positions (with the compensation above the visible start) and the row's settled state land in the frame that
+    laid the body out. A row that this commit reveals, or a body whose box it changes, is measured before the delivery ends and observed at the
+    view's next frame callback, so no observation starts inside a delivery and the browser never reports "ResizeObserver loop completed with
+    undelivered notifications".
+  With a 30 ms key repeat at 60 Hz, a hold has about 0.8 key-free frames per key and brings about one row per key into the reach, so a 40-key hold
+  keeps several bodied rows ahead of the active row; holds longer than about 60 keys draw the bodies they reveal inside the key's own commit (one
+  complete card each, counted).
+  On a device where a DetailList card exceeds a frame, a held key draws no card in its frames. The scheduler classifies the device from what it
+  measures, with no device constant: a kind of unit exceeds the frame when its measured p50 exceeds the class limit, the display's frame interval
+  floored at the 60 Hz interval, less 2 ms. That is 14.67 ms on a 60 Hz display and on a faster one alike: an interval more than 1 ms below 16.67 ms
+  (a display above about 64 Hz) is judged as 16.67 ms, because the frame targets are written for 60 Hz frames, so the class follows the device's CPU
+  and not the display's rate (a 120 Hz display's own interval less 2 ms, 6.33 ms, would classify every DetailList hold at 1×). The interval is the
+  display's, read from the frames that were not pushed back, so a slow device does not stretch it. During a hold and for the DetailList's measured
+  cards, a kind also exceeds the frame when the median of the hold's key frames does (from 3 samples: the key frames' own weight, measured even
+  while the scheduler draws nothing, from their busy time, or from their cadence when a frame's work outlasted the class limit and missed the vsync
+  after it, which a gap of 1.5 display intervals past the vsync before the one nearest the limit's end shows: 1.5 intervals at 60 Hz, 2.5 at 120 Hz
+  and 144 Hz). The end-of-frame message of the frame after which the scheduler slept adds no sample: it waits behind input and rendering, so its time
+  measures that wait, not the frame. On such a device the rows that enter
+  the visible range during the hold stay named shells, the scheduler sleeps, and after the key's release it draws the active row's card first and then
+  the visible shells in their visible order. At 1× no kind ever exceeds the frame on a 60, 120 or 144 Hz display (a DetailList card's p50 is
+  7.3–8.4 ms and the key frames' median at most about 13.6 ms), so every entering row is complete at its entry. With the
+  CPU slowed 4× before a 40-key hold, the hold classifies itself by its 6th or 7th key, 23–26 rows enter as named shells, and the next frame's p95 is
+  27.4–45.1 ms (median 33.4) against the 33 ms target. The List's rows fit a frame even then, so the List keeps every row complete at its entry.
+  Decisions never wait for the drawing: the card and the error surface are both drawn from the unit's snapshot, and only the safety valve that
+  removes a row whose report no longer exists, the busy state of a row whose card or error waits for its unit (a load error that arrived but is not
+  drawn yet keeps the row's skeleton, never a "not found" surface), and a DetailList body's draft and ownership, its opening of the viewer's own draft
+  in the editor and its edit button's action read the row's current details.
 - **Far rows skip rendering.** Every mounted row lies in one zone, computed in the render that positions the rows from that render's own scroll
   position (half-open intervals in content pixels, V the viewport's size, s the scroll position): **visible** when it intersects [s, s + V);
   **reach** when it intersects the active row's reach, from V above the row before the active one to V below the row after it — every row that a
@@ -2999,7 +3135,14 @@ the resize handle and the side pane lie outside the list.
     (re-recording there would read the clamped position against the previous list's rows, name another report and leave the view displaced by up to
     the last row's height).
   - **Scrolls `VirtualScroll` makes for the user** (wheel, drag, the scroll bar, inertia) are recorded each time the view reports its visible range,
-    once per frame. A list change in the frame before that report first advances the anchor by the distance scrolled since it was recorded and
+    once per frame. During a fling far beyond the rendered window the rows are ranked by the pane (those ahead of its travel first) and the rows of
+    one viewport ahead of a moving pane are drawn before they become visible (**Rows mount in two passes**). Over rows of one height (the List)
+    wheeling back by the same distance lands where the fling started. Over measured rows (the DetailList) a fling is not yet symmetric: the rows it
+    passes before they are drawn are laid out at the measured estimate (below) and change to their own heights when they are drawn above the pane, and
+    `VirtualScroll`'s compensation keeps the visible rows in place, so a plain 20,000 px fling and back lands 156–548 px away from where it started
+    (measured in Chromium with React's development build, where a card takes 10–26 ms to draw, so the rows a fling passes are measured late); the
+    visible rows never jump, and content that was drawn and measured never moves: wheeling there and back in steps that each wait until the rows they
+    mount are drawn lands on the start report exactly. A list change in the frame before that report first advances the anchor by the distance scrolled since it was recorded and
     restores from there: it neither undoes the user's scroll nor shifts the content by a row.
     Over rows of one height (the List) the new anchor follows from the distance by arithmetic; over measured rows (the DetailList) it walks the
     previous list's row heights from the anchor to the report now at the top, so the walk is bounded by the rows passed since the record (one frame's
@@ -3058,7 +3201,12 @@ the resize handle and the side pane lie outside the list.
   rows are the whole set; the views' `VirtualScroll` always counts the rows given.
   The markers are the attachment marker (`<labels.attachments>: <count>`) and the source badge (its full `name` when the configuration gives one,
   otherwise its label); a description references only the markers that are painted. A shell, and a row without content (loading, failed, missing,
-  editing), is named by its ISO business date, with `aria-busy="true"` while its report or its body is still to come. ★, 既読, 編集 and 削除 carry
+  editing), is named by its ISO business date, with `aria-busy="true"` while its report or its body is still to come, and is described by the state
+  it shows, so the active descendant's announcement never reduces a visible state to a date: a failed row by its error message
+  (`labels.reportSummaryLoadFailed` in the List, `labels.reportLoadFailed` in the DetailList), a List row the server did not find by
+  `labels.reportNotFound`, and a DetailList row that shows its edit form — the viewer's own draft opens there by itself — by a visually hidden
+  `labels.rowEditingState({ isDraft })` (en "Editing draft" / "Editing", ja 「下書きを編集中」 / 「編集中」). A shell and a loading skeleton have no
+  description. ★, 既読, 編集 and 削除 carry
   `aria-label` equal to their `title` and no `aria-pressed`; no element of a view carries `aria-current`.
   The active row is never skipped, so its name and description are always complete; a far row that skips rendering is absent from the accessibility
   tree (**Far rows skip rendering** above). The package's tests compute the active row's name and description in both views; how real screen readers
@@ -3119,6 +3267,9 @@ the resize handle and the side pane lie outside the list.
   the comment form: see [External Source Badge Configuration](#external-source-badge-configuration-sourcetypeconfigs)).
   The comment field is named by that heading (`aria-labelledby`; `labels.comments`), which renders whenever the form does, so the field has a name of
   its own in the DetailList row, the side pane and the mobile overlay; its placeholder (`labels.commentPlaceholder`) stays a hint, not its name.
+  While a post is sent, the field keeps the draft, read-only, with the submit button disabled, and empties only when the post is accepted; a refused
+  post (401, 403, a 5xx) leaves the draft, its text and its caret untouched, so a viewer whose session ended sends it again after signing in
+  (the package's part of WCAG 2.2.5; keeping a draft across a navigation or a reload is the host's).
   A report of a source that takes no comments and has none shows no empty section, and deleting the last comment of such a report removes the section,
   so focus goes to the report's anchor above.
 - **Mobile detail overlay** (List, single-column layout): the platform's modal dialog, a `<dialog data-daily-report-mobile-overlay>` (implicit
@@ -3176,6 +3327,7 @@ and their versions, and per step either a pass or the text announced.
 | Empty and no-category views | A search that matches nothing, and a viewer who may see no category: Tab into the view | The composite is announced by its title, described by the empty text (「項目がありません」) and the keyboard help, with no row; for the viewer without a category, the page's notice (「閲覧できる日報の区分がありません。…」) is reached in browse mode before the view |
 | Overlay close | Phone layout, List: open a report's overlay with Enter on the composite and close it with Escape; open it with a tap and close it with the close button | After the keyboard close, focus is on the composite and the same row is announced as active; after the tap close, focus is on the card's primary button, announced with its position first |
 | Touch hand-back in the DetailList | Touch reader, DetailList: in the active row of your own report from a source that takes no comments, delete its last comment (the trash button, then the confirmation) | The comment section leaves and focus lands on the row's name heading, announced as the report's date, author and subject (not on the list as a whole) |
+| Held key on a slow device | Desktop, DetailList with a search answer shown, Chrome's CPU throttling at 4× (DevTools, Performance): hold ArrowDown for about 40 keys, then release | While the key is held, each active row is announced with its name and its description (state, attachments, source, the matched-keywords sentence), even when its card has not been drawn; after the release, the active row's card arrives first and its description gains the matched-fields sentence; nothing is announced twice |
 | Far rows | Browse mode (NVDA, JAWS, Narrator) or swiping (VoiceOver on iOS, TalkBack) past the visible rows | The rows within one viewport of the visible range are reached; rows farther away are reached only once the list has scrolled near them (**Far rows skip rendering**); the active row is always reached |
 | Switch Access | Android, Switch Access with Chrome, List on the phone layout: scan to a card and select it, then close the overlay with its close button | The card is reachable by scanning and opens the overlay; after the close, focus (which Switch Access follows) is on that card's primary button, or on the composite when the page recorded no pointer input for the action (a hand-back after no recorded input lands on the composite): record which, and that scanning continues from there |
 | Forced colours | Windows contrast theme (forced colours) with the keyboard: move the active row with the arrows, wheel it out of view, then press a key | The selected row shows the system's `Highlight` outline, the active row's keyboard outline shows in the system colour while it is visible, and the composite's 2 px pane ring shows while the active row is out of view |
@@ -3252,8 +3404,9 @@ luminance by 0.026 in the light theme, and a `shadow-md` brings the ring down to
   Measured in Chromium 148 at 412 × 915 and 2.625: with bodies rounded to 4 px, a DetailList row of 980 px ended at 6,478.5 device pixels and the
   surface edge of the next row blended into two rows of device pixels; rounded to q, the revealed row's surface top sits at device pixel 273 in every
   reveal.
-  A row that has not been measured yet is laid out at an estimate of 352 px (88 u = 44 × 8), also on the lattice at every ratio of the domain, so the
-  unmeasured rows above the window move the rows below by whole device pixels. An image attachment tile is padded to q as well (**Tile** in
+  A row that has not been measured yet is laid out at the view's measured estimate — the median of the heights the view has measured, rounded up to
+  8 px (2 u), and 440 px (110 u) until it has measured one; the view applies a changed estimate only at rest, with the first visible report kept in
+  place — also on the lattice at every ratio of the domain, so the unmeasured rows above the window move the rows below by whole device pixels. An image attachment tile is padded to q as well (**Tile** in
   [Attachment display](#attachment-display)), so the rows below an image grid stay on whole device pixels.
 - **List card**: a wrapping row of the primary button and the action row (markers and toggles), with the preview always on the next line. The primary
   button takes the remaining width but never less than 96 px, enough for the business-date pill, and the action row keeps to the card's end; on a card
@@ -3399,16 +3552,19 @@ luminance by 0.026 in the light theme, and a `shadow-md` brings the ring down to
 
 - **Text fields**: the comment input, the edit form's `Input` and `Textarea` and the search field, and the outline of the search band's toggles in
   their field face (the OR toggle and the closed filter toggle), take their boundary and placeholder from one token: a 1 px slate-500 border in both
-  schemes and a slate-500 placeholder (dark slate-400).
+  schemes and a placeholder in the quiet text colour (below).
   Each field declares its own `border border-solid` beside its inset and its own package fill (white, the comment input slate-50 turning white on
   focus; dark slate-900, the comment input slate-800 turning slate-900); none reads the host's `--input`, `--muted-foreground`, `--primary` or
   `--destructive`.
   The boundary reaches the 3:1 of WCAG 1.4.11 against every surface a field sits on and against the field's own fill, its focus fill included (light:
-  4.76 on white and 4.55 on slate-50; dark: 3.74 on slate-900, 3.07 on slate-800 and 4.23 on slate-950), and the placeholder reaches 4.5:1 on each
-  field's fill.
-  The toggles' filled face (AND, and the open filter toggle) is a blue-700 fill (dark blue-600), whose edge is its boundary (6.52:1 on the page, dark
-  3.84:1), under white text (6.82:1, dark 5.25:1); it stands 6.82:1 (dark 3.40:1) from the field face's fill, so open and closed differ in more than
-  hue, and forced colours draw it as `Highlight` under `HighlightText` while the field face keeps the forced button colours.
+  4.76 on white and 4.55 on slate-50; dark: 3.74 on slate-900, 3.07 on slate-800 and 4.23 on slate-950), and the placeholder reaches 7:1 on each
+  field's fill (light: 7.73 on white, 7.39 on the comment input's slate-50; dark: 8.62 on slate-900, 7.07 on the comment input's slate-800).
+  The toggles' filled face (AND, and the open filter toggle) is a blue-800 fill under white text in light and a light blue-300 fill under slate-950
+  text in dark, whose edge is its boundary (8.43:1 on the page, dark 11.12:1), with its text at 8.82:1 (dark 11.12:1); it stands 8.82:1 (dark 9.83:1)
+  from the field face's fill, so open and closed differ in more than hue, and the blue-400 focus outline, drawn 2 px outside the face, stands 1.45:1
+  from the dark fill. No dark fill under white text can meet both the 7:1 of the text and the 3:1 of the fill against the page, since the two ratios
+  multiply to white against the slate-950 page, 20.16 < 7 × 3. Forced colours draw it as `Highlight` under `HighlightText` while the field face keeps
+  the forced button colours.
   `src/client/ui/ui-state-contrast.spec.ts` computes these pairs for every site from the site's own classes (so a site that drops the token fails),
   and its host-token guard covers the token, the primitives and the sites.
 
@@ -3622,8 +3778,25 @@ luminance by 0.026 in the light theme, and a `shadow-md` brings the ring down to
   are exactly the token's, and the search box's spec renders every status message in both locales and checks that the line carries the token and no
   truncating class.
 - **Type and contrast**: no text is smaller than 12 px (`text-xs`; a scan of every module under `src/client` rejects a smaller arbitrary size,
-  `src/client/components/report-views.spec.tsx`); text reaches 4.5:1 and the indicators 3:1 in both themes (section labels slate-500 / slate-400: 4.77
-  / 7.09). The floating tap-scroll circle hides while the view root carries `data-daily-report-keyboard-focus` (through the class both views pass in
+  `src/client/components/report-views.spec.tsx`); every text colour reaches 7:1 (WCAG 1.4.6, AAA) against every surface it can sit on, in both themes
+  and every state (hover, active, `aria-*`, `data-*`, translucent surfaces composited over theirs), and the indicators 3:1:
+  `src/client/ui/aaa-text-contrast.spec.ts` scans every class literal of the shipped client (and the comment authors' colours) that sets a text colour,
+  refuses one without a registered surface, and measures each against its surfaces. The quiet text (section labels, metadata, placeholders, the empty
+  view, inactive tabs) is one token, `--aqdr-text-quiet` (light `oklch(44% 0.046 257.417)`, dark `oklch(77% 0.040 256.788)`: slate-500's and
+  slate-400's hue and chroma), whose lightness `src/client/ui/aaa-quiet-text.spec.ts` solves from the surfaces it sits on (light 7.06–7.73, dark
+  7.07–9.75). A source badge's colours are the host's (**External Source Badge Configuration**). Targets stay at WCAG 2.5.8's 24 px, except the
+  List's resize handle with its 10 px hit area and the 8 px scroll bar beside it (**Side pane** above); 2.5.5's 44 px is not claimed.
+- **WCAG 2.2 AAA beyond contrast**: met are 1.4.9 (no images of text), 2.1.3 (every function by the keyboard, the List splitter's arrow keys
+  included), 2.2.3 (nothing on a timer; **The built-in notice**), 2.3.2 (no flashes), 2.3.3 (motion follows `prefers-reduced-motion`), 2.4.8 (the page
+  and the report headings tell where the viewer is), 2.4.9 (links name their purpose), 2.4.10 (sections carry headings), 2.4.12 and 2.4.13 (the focus
+  is never obscured, and its outline is 2 px at 3:1), 3.1.3, 3.1.4 (abbreviated source badges, **External Source Badge Configuration**), 3.2.5 and
+  3.3.6. Not met, by decision: 2.2.4 (Interruptions): live updates (SSE) apply as they arrive, with no pause, and
+  the scroll anchoring keeps the rows on screen in place. Not met at AA: 2.5.8 for the List's resize handle and the scroll bar beside it, and 2.5.7 for
+  the List's splitter (**Side pane** above): a path without dragging belongs to `@aiquants/resize-panels`, and larger hit areas for the handle and the
+  bar wait for the same layout pass as 2.5.5. Not claimed yet: 2.5.5 (44 px targets), 1.4.8 (a line measure and the List preview's
+  leading) and 3.3.5 (a help control for the search syntax), which need a layout pass, and 3.1.6 (readings of names), which needs readings from the
+  host's directory. 2.2.5 is met by the package for a refused comment post (**One comment section rule** above); keeping work across a
+  re-authentication elsewhere is the host's, as is 2.2.6 (telling users how long a session lasts). The floating tap-scroll circle hides while the view root carries `data-daily-report-keyboard-focus` (through the class both views pass in
   `VirtualScroll`'s tap-scroll circle options).
 - **Action buttons and icons**: the List card's star and read toggles, the star, read, edit and delete buttons of the DetailList header and the side
   pane, and the trash button of the viewer's comments share one 24 px round target that never shrinks, with a 16 px SVG icon centred in it (4 px on
@@ -3905,7 +4078,7 @@ DOM hooks are `data-*` attributes, test ids and ARIA; class names are styling an
 | `[data-daily-report-row="<id>"]` | Row frame of both views (`role="row"` with `id`, `aria-rowindex`, `aria-posinset`, `aria-setsize`, `aria-level` and an explicit `aria-selected`; the set size is the declared total while the ids stream delivers and `-1` before it is declared, see **Screen readers**), in every load state |
 | `[data-daily-report-active]` | The active row's frame (the row the composite's `aria-activedescendant` names) |
 | `[data-daily-report-row-surface]` | Surface of a row frame (`role="gridcell"`): its direct child that paints the selection ring and the focus outline, in every load state (opaque and never animated; a loading pulse runs inside it) |
-| `[data-daily-report-row-shell]` | The empty surface of a shell: a row mounted outside the visible range whose body is still to come (**Rows mount in two passes**) |
+| `[data-daily-report-row-shell]` | The surface of a shell, the card's surface without content: a row mounted outside the visible range whose body is still to come (**Rows mount in two passes**) |
 | `[data-daily-report-card]` | List card surface (present while the card is shown) |
 | `button[data-daily-report-button="<id>"]` | List card primary button (the click target that selects, and the pointer hand-back target; never a Tab stop, `tabIndex=-1`) |
 | `[data-daily-report-row-focus]` | A row's own focus target, where a pointer or touch hand-back lands: the List card's primary button, or the DetailList card's visually hidden name heading (`tabIndex=-1`; never a Tab stop) |
@@ -3932,17 +4105,30 @@ Only the package writes `data-daily-report-keyboard-focus`, `data-daily-report-s
 their own content inside a view — but never set them. When the pane content matters, wait for `data-displayed-report-id`, not `data-report-id`: during
 a key's render the frame already names the new selection while the content still shows the previous report.
 
+A host's test build instruments the views by providing `createDailyReportTestInstrumentation()` (testing entry) through
+`DailyReportInstrumentationContext` (client entry) around the page; production provides none, so no view carries a test handle or reports a row-pass
+event there, and none of the testing entry's code is in the client bundle. A view reads the context once, when it mounts. Instrumented,
 `[data-testid="daily-report-list"]` and `[data-testid="daily-report-detail-list"]` carry a `__virtualScroll` accessor for end-to-end tests, with the
 same shape in both views. It is the read-only part of the current `VirtualScroll` handle — `getViewportSize()`, `getScrollPosition()`,
 `getScrollAnchor()`, `getRange()` and `getFenwickSize()` — plus `findReportIndex(id)`, `getReportItem(index)` and `getReportIds(limit = 20)` over the
-view's committed list, and one way to move the position, `revealIndex(index, options)`.
-The client entry exports the contract as types, so a host's tests import it instead of restating it (type-only, no bundle bytes):
-`DailyReportViewTestHandle` is the accessor, `DailyReportViewTestReadHandle` its read-only part, and `DailyReportRevealOptions` the options of
-`revealIndex`, which are the second argument of `VirtualScroll`'s `scrollToIndex` (its alignment and offset, as the peer defines them).
+view's committed list, one way to move the position, `revealIndex(index, options)`, and one read-only view of the view's row pass:
+`rowPass.counters()`, the counts of its events since the view mounted, read when it is called — `syncReleases` (units drawn synchronously, in a
+commit or a notification's microtask commit), `deferredVisible` (units of a frame-exceeding kind kept pending when their row became visible during a
+hold), `oversizeFrames` (key-free frames whose first unit alone exceeded the frame's share), `lateFrames` (late key-free frames the pass skipped),
+`lateForcedFrames` (late key-free frames it applied a unit in regardless) and `unitFrames` (frames that applied units) — and
+`rowPass.unitKinds()`, the latest `p50`, `p90` and `budget` (the class limit: the frame interval, floored at the 60 Hz interval on a faster display,
+less the late-frame margin) of each unit kind its unit frames
+reported — and one read-only view of the view's re-estimates: `estimate.counters()` — `reEstimates` (position changes `VirtualScroll` made for a
+new row-height estimate, the cause `re-estimate`) and `reEstimatesInMotion` (those made while the view moved: during a key hold or while it
+scrolled; 0 by design, since the view applies an estimate at rest only). A performance probe reads them before and after a key hold and reports the
+differences, so it copies none of the pass's constants or rules (**Rows mount in two passes**).
+The testing entry exports the contract as types, so a host's tests import it instead of restating it (type-only):
+`DailyReportViewTestHandle` is the accessor, `DailyReportViewTestReadHandle` its read-only part, and `DailyReportRevealOptions` (client entry) the
+options of `revealIndex`, which are the second argument of `VirtualScroll`'s `scrollToIndex` (its alignment and offset, as the peer defines them).
 `revealIndex` goes through the view's scroller (the `VirtualScroll` alignment of `scrollToIndex`, then the anchor's record, like a key move; see
 **Host selections and list changes**), so a list change right after it keeps the revealed report in place. The accessor has none of the handle's
-functions that move the position (`scrollToIndex`, `scrollBy`, `scrollTo`, `applyWheel`, `updateItemSize`) and no selection backdoor: select through
-the UI (a click, the keys). Read it on every use; it is `undefined` while the list is not mounted.
+functions that move the position (`scrollToIndex`, `scrollBy`, `scrollTo`, `applyWheel`, `updateItemSize`, `setItemHeightEstimate`) and no
+selection backdoor: select through the UI (a click, the keys). Read it on every use; it is `undefined` while the list is not mounted.
 
 ### Localization (`locale` / `labels`)
 
@@ -3960,9 +4146,9 @@ locale**: English (`"en"`, the default) and Japanese (`"ja"`). Pick the language
 />
 ```
 
-- **One surface for all wording.** The catalog covers the 11 engine chrome keys of `@aiquants/virtualscroll` plus 110 own keys: field headings, the
-  page title (`title`, passed to `renderHeader` and used as the accessible name of both lists), the lists' keyboard help, the row state and the List
-  card's position read to screen readers, tabs, buttons, placeholders, the `confirm()` text, stream badges, the search box, its filter row and the
+- **One surface for all wording.** The catalog covers the 11 engine chrome keys of `@aiquants/virtualscroll` plus 111 own keys: field headings, the
+  page title (`title`, passed to `renderHeader` and used as the accessible name of both lists), the lists' keyboard help, the row states (read and
+  starred, editing) and the List card's position read to screen readers, tabs, buttons, placeholders, the `confirm()` text, stream badges, the search box, its filter row and the
   search's match indicator, the status screen and the page's status region and the mutation-failure message with its repeat count. The engine part of
   each catalog is `@aiquants/virtualscroll`'s own catalog of the same locale, reused by value, so the scroll arrows, the names of the scroll bar and
   its thumb, and the "No items" text always speak the same language as the rest.
@@ -3970,12 +4156,12 @@ locale**: English (`"en"`, the default) and Japanese (`"ja"`). Pick the language
   and the 11 engine keys of the resolved labels to their `VirtualScroll`. The engine label object keeps
   its identity while its values are unchanged, so rebuilding `config.labels` on every render does not
   re-render the memoized list subtree.
-- **Formatter keys.** Twenty-one keys take arguments and are functions: `totalCount(count)`,
+- **Formatter keys.** Twenty-two keys take arguments and are functions: `totalCount(count)`,
   `debounce(milliseconds)`, `streamProgressCount(loaded)`, `streamProgressRatio(loaded, total, percent)`,
   `streamRetrying(loaded)`, `reportLoadFailed(reportHubId)`, `reportSummaryLoadFailed(reportHubId)`,
   `interviewerWithAffiliation(name, affiliation)`, `operationFailed(operation)` (`operation` is a
   `DailyReportOperation`: `create` / `update` / `publish` / `delete` / `addComment` / `deleteComment` /
-  `toggleStar` / `toggleRead`), `noticeRepeated(count)`, `rowState({ isRead, isStarred })`, `listRowPosition(position, total)`,
+  `toggleStar` / `toggleRead`), `noticeRepeated(count)`, `rowState({ isRead, isStarred })`, `rowEditingState({ isDraft })`, `listRowPosition(position, total)`,
   `listRowPositionInUnknownTotal(position)`,
   `searchHitCount(count)`, `searchFailed(failure)` (`failure` is `invalid` / `busy` / `unavailable` / `failed`),
   `searchMatchedKeywords(matched, total)`, `searchMatchedKeywordsDescription(matched, total)`, `searchFieldMatched(field)` and
@@ -3986,7 +4172,7 @@ locale**: English (`"en"`, the default) and Japanese (`"ja"`). Pick the language
   locale built once (the row positions and counts re-render on every stream publish); a host override receives
   the raw number and formats it itself.
 - **Fail-fast**: an unsupported `locale` (`"EN"`, `"ja-JP"`, `"fr"`, `""`, `null`, ...) throws a
-  `RangeError` at render. So do an unknown `labels` key (a key error that lists the 121 keys), a string
+  `RangeError` at render. So do an unknown `labels` key (a key error that lists the 122 keys), a string
   key whose value is not a string with non-whitespace content, and a formatter key whose value is not a
   function. An `undefined` value keeps the catalog value.
 - **`config` has a closed key set**: `apiBasePath`, `ssePath`, `locale`, `labels`,
@@ -4024,7 +4210,7 @@ locale**: English (`"en"`, the default) and Japanese (`"ja"`). Pick the language
   grouping follows `locale` (`en` → `"en-US"`, `ja` → `"ja-JP"`) and dates stay in ISO form. Packages
   that do format dates (for example `@aiquants/period-slider`) name that separate axis `formatLocale`.
 
-Exported API (`@aiquants/daily-report/client`): `DAILY_REPORT_LABEL_KEYS` (all 121 keys, the 11 engine keys
+Exported API (`@aiquants/daily-report/client`): `DAILY_REPORT_LABEL_KEYS` (all 122 keys, the 11 engine keys
 first), `DAILY_REPORT_LABEL_CATALOGS` (the frozen catalogs), `resolveDailyReportLabels(locale, labels)`
 (the effective frozen labels — the catalog object itself when `labels` is `undefined`), the resolved
 `locale` / `labels` on `useDailyReportConfig()`, and the types `DailyReportLocale` (= `VirtualScrollLocale`),
@@ -4130,6 +4316,7 @@ first), `DAILY_REPORT_LABEL_CATALOGS` (the frozen catalogs), `resolveDailyReport
 | `operationFailed` | the error notice / `DailyReportErrorInfo.message` | `("update")` → Failed to save the report. Please try again later. | `("update")` → 日報の保存に失敗しました。時間をおいて再度お試しください。 |
 | `noticeRepeated` | the error notice, beside its message when failures with the same message follow one another (`count` is how many came in a row, from 2; part of the notice's name) | `(2)` → (2 times) | `(2)` → (2 回目) |
 | `rowState` | visually hidden row state, the first description of a card row in both views and the second of the List card's primary button | `({ isRead: false, isStarred: true })` → Unread, starred | `({ isRead: false, isStarred: true })` → 未読、スター付き |
+| `rowEditingState` | visually hidden state of a DetailList row that shows its edit form in place of the card (the viewer's own draft opens there by itself), the row's description | `({ isDraft: true })` → Editing draft; `({ isDraft: false })` → Editing | `({ isDraft: true })` → 下書きを編集中; `({ isDraft: false })` → 編集中 |
 | `listRowPosition` | visually hidden position of a List card in the list, the first description of its primary button (`position` is 1-based; `total` is the size of the views' set) | `(3, 1234)` → 3 of 1,234 | `(3, 1234)` → 全 1,234 件中 3 件目 |
 | `listRowPositionInUnknownTotal` | the same position while the size of the views' set is unknown (the ids stream has not declared its total yet), in place of `listRowPosition`; it also ends the description of a card row in both views while the size is unknown | `(3)` → Item 3 | `(3)` → 3 件目 |
 | `searchFieldMatched` | match sentences of a row (the DetailList row's and the side pane's hidden indicator sentences, the List card's hidden match description): a field heading the row's leaves marked with a typed word's mark (`field` is the heading's resolved label) | `("Author")` → Author matched | `("作成者")` → 作成者で一致 |
@@ -4145,23 +4332,29 @@ prevents the package from hardcoding specific third-party service names or desig
 sourceTypeConfigs: {
     Internal: {
         label: "Native",
-        badgeClassName: "bg-green-100 text-green-800 dark:bg-green-900/30 dark:text-green-400",
+        badgeClassName: "bg-emerald-100 text-emerald-900 dark:bg-emerald-900/30 dark:text-emerald-400",
     },
     ExternalCRM: {
         label: "External CRM",
-        badgeClassName: "bg-red-100 text-red-800 dark:bg-red-900/30 dark:text-red-400",
+        badgeClassName: "bg-red-100 text-red-900 dark:bg-red-900/30 dark:text-red-300",
     },
     LegacyPortal: {
         label: "LP",
         name: "Legacy Portal",
-        badgeClassName: "bg-blue-100 text-blue-800 dark:bg-blue-900/30 dark:text-blue-400",
+        badgeClassName: "bg-blue-100 text-blue-800 dark:bg-blue-900/30 dark:text-blue-300",
     },
 }
 ```
 
-- `label` is the text on the badge. When it is an abbreviation, give the full name in `name` (WCAG 3.1.4): the badge then renders the label as
-  `<abbr title="<name>">` (pointer users see the expansion), hides the abbreviation from assistive technology and reads the name once instead. Without
-  `name` the badge shows its label and nothing is substituted.
+- The badge's colours are the host's: the package's 7:1 guard reads only the package's own classes, so a `badgeClassName` must keep its text at 7:1
+  (WCAG 1.4.6) itself, against its fill composited over the card and over the overlay in both schemes (light: white under both; dark: `slate-900/70`
+  over `slate-950` under the card, `slate-900` under the overlay). The pairs above do, by the package's contrast math at the lower of the two
+  surfaces: 8.47:1 light and 7.93:1 dark for emerald (the built-in `Internal` badge's own pair), 8.22:1 and 8.54:1 for red, 7.23:1 and 8.63:1 for
+  blue. A `-800` text on a green or red `-100` fill falls short in light (6.45:1 and 6.86:1), and a red or blue `-400` text on a `-900/30` fill falls
+  short in dark (5.68:1 and 5.94:1 over the overlay).
+- `label` is the text on the badge. When it is an abbreviation, give the full name in `name` (WCAG 3.1.4): a badge whose label differs from its `name`
+  renders the label as `<abbr title="<name>">` (pointer users see the expansion), hides the abbreviation from assistive technology and reads the name
+  once instead. Without `name`, or with a `name` equal to the label (which abbreviates nothing), the badge shows its label and nothing is substituted.
   A `name` that is given must be a non-blank string; anything else (`""`, `"  "`, `null`, a number) throws a `RangeError` at render that names the
   source type.
 - The badge is part of the row description (see [Keyboard, focus and selection](#keyboard-focus-and-selection-list--detaillist)): the List card's
@@ -4278,7 +4471,9 @@ Documenting a name here is no reason to export it, and the values that tune the
     `DAILY_REPORT_SEARCH_BATCHES_IN_FLIGHT` (2, the batched reads the package's client keeps in flight per API base path, from which the server sizes
     a viewer's share of the `reports` and `search-marks` admissions), and the answer of `search-marks`: `DailyReportSearchMarksAnswer`
     (`{ wordsDigest, reports, deferred }`) of `DailyReportSearchReportMarks` (a report's id, `matchedSets` and `fields`) and
-    `DailyReportSearchFieldMarks` (a field's `fingerprint`, with its `ranges` or `dense: true`).
+    `DailyReportSearchFieldMarks` (a field's `fingerprint`, with its `ranges` or `dense: true`), and the answer of `reports`:
+    `DailyReportSearchDetailsAnswer` (`{ outcomes }`, one `DailyReportSearchDetailOutcome` per requested id in request order: `ok` with its `report`,
+    `not_found` or `failed`).
 - **client** (`@aiquants/daily-report/client`, React):
   - Components: `DailyReportPage` / `DailyReportResolvedContent` / `DailyReportList` / `DailyReportDetailList` / `DailyReportAttachmentIndicator`, the
     providers `DailyReportConfigProvider` / `DailyReportActionProvider` / `DailyReportErrorProvider` (required above the action provider:
@@ -4307,6 +4502,8 @@ Documenting a name here is no reason to export it, and the values that tune the
     session's client is not public. The route helpers `createDailyReportClientLoader` / `dailyReportShouldRevalidate`.
   - Configuration and wording: `defaultDailyReportClientConfig` / `resolveDailyReportLabels` / `DAILY_REPORT_LABEL_CATALOGS` /
     `DAILY_REPORT_LABEL_KEYS` / `resolveSourceTypeConfig`.
+  - The source-type fold `foldDailyReportSourceTypeToken`, the same function as the shared entry's, for the host's route modules that ship to the
+    browser (the shared entry is not split, so a route module that imports the fold from it carries a second copy of shared modules into its chunk).
   - The search's filter controls: `DAILY_REPORT_SEARCH_FILTER_FACETS` with its type `DailyReportSearchFilterFacet` (the filters in the filter row's
     order, `author`, `sourceType` and `customer`), and the contract of the control a host renders in each filter cell:
     `DailyReportSearchFilterSelectRenderer` (what `config.search.renderFilterSelect` is) /
@@ -4317,20 +4514,30 @@ Documenting a name here is no reason to export it, and the values that tune the
     slot P**), so rows are located by `[data-daily-report-row]` or the test handle.
   - The rows' shape: `DailyReportRows` (`Pick<ReadonlyArray<DailyReportItem>, "length" | "at"> & Iterable<DailyReportItem>`: what
     `DailyReportActionState.items` is and both views' `dailyReportItems` take; a plain array is one too).
+  - The selection's phase: `DailyReportSelectionPhase` (`"held"` for each key of a held-key repeat stream, `"settled"` for every other selection and
+    once at a stream's end: the second argument of both views' `onSelectItem`). Every way a stream ends (the key's release, another key, a pointer
+    press, a wheel, focus leaving the view, the view unmounting) passes the stream's last selection once as `"settled"`, unless the host settled
+    another selection during the stream or no key of the stream selected. A host may record `"held"` selections without rendering them; rendering
+    them is also correct, at the cost of a render per key.
   - Types: `DailyReportClientConfigInput` / `DailyReportClientConfigDefaults` / `DailyReportClientConfig` (the resolved configuration
     `useDailyReportConfig` returns) / `DailyReportHeaderProps` (what `renderHeader` receives) / `DailyReportSearchSettingInput` /
     `DailyReportSearchSetting` (`config.search` as passed and as resolved) / `DailyReportSourceTypeConfig` (one entry of `sourceTypeConfigs`) /
     `DailyReportLocale` / `DailyReportLabels` / `DailyReportLabelOverrides` / `DailyReportOperation` / `DailyReportErrorInfo` /
     `DailyReportSseConnectionStatus`,
-    and the end-to-end test handle's contract `DailyReportViewTestHandle` / `DailyReportViewTestReadHandle` / `DailyReportRevealOptions` /
-    `DailyReportListNavigationHandle` (the read-only getters of the views' `VirtualScroll` handle that `DailyReportViewTestReadHandle` builds on) (see
-    [Test hooks](#test-hooks)).
+    the options of the test handle's reveal `DailyReportRevealOptions` and `DailyReportListNavigationHandle` (the read-only getters of the views'
+    `VirtualScroll` handle that the testing entry's `DailyReportViewTestReadHandle` builds on) (see [Test hooks](#test-hooks)).
+  - Test instrumentation: `DailyReportInstrumentationContext` (null by default; a host's test build provides the testing entry's instrumentation
+    through it, and production provides none) with its value's contract `DailyReportInstrumentation` / `DailyReportInstrumentedView` /
+    `DailyReportViewInstrumentation` (see [Test hooks](#test-hooks)).
 - **server** (`@aiquants/daily-report/server`, Node.js):
   - Factories: `createDailyReportServer` (whose `knownSourceTypes` lists the package's own source type, `Internal`, then each `externalSources`
     adapter's, frozen) / `createDailyReportService` (`getDailyReportIdsByExternalId` returns `{ items, streamAnchor, snapshot }`;
     `readSseStreamAnchor`; `attachmentDelivery`, `null` without the `attachments` block; `titleMaxLength`;
     and for the search `searchLimits`, `null` without the `search` block, `searchFilterSourceTypes` (the source types a filter may name: frozen, the
-    very array of `knownSourceTypes`), `searchDailyReports` (it takes `DailyReportSearchCriteria`), `getDailyReportDetailsByIdsByExternalId`,
+    very array of `knownSourceTypes`), `searchDailyReports` (it takes `DailyReportSearchCriteria`), `getDailyReportDetailsByIdsByExternalId` (it
+    answers one `DailyReportSearchDetailOutcome` per requested id, in request order, and takes the request's `{ signal }` like
+    `markDailyReportSearchHits`: validated before any query, its reason thrown at the next check after an abort, before a query or after a yield
+    between two reports' copies),
     `markDailyReportSearchHits` (it takes the request's `{ signal }`, validated before any query, and throws its reason at its next check after an
     abort, before a read or after a yield between two slices of the marks; its answer holds the reports within the marks budget and defers the rest),
     `listDailyReportSearchFacets`, `reconcileSearchIndex`) / `createDailyReportHandlers` / `defineDailyReportSchema` / `defineDailyReportSearchSchema`
@@ -4344,7 +4551,7 @@ Documenting a name here is no reason to export it, and the values that tune the
     decode-work and walk bounds, for a host's conformance checks) / `DAILY_REPORT_ATTACHMENT_THUMBNAIL_OUTPUT_MEDIA_TYPES` /
     `DAILY_REPORT_ATTACHMENT_THUMBNAIL_MAX_OUTPUT_BYTES`.
   - SSE and caching: `buildDailyReportSseStreamKey(streamKey)` (the Redis stream key the service writes and reads the SSE entries of, the base key
-    with the wire version appended, `<streamKey>:v3`, for a host that reads or writes the stream itself) / `DailyReportSseReader` /
+    with the wire version appended, `<streamKey>:v4`, for a host that reads or writes the stream itself) / `DailyReportSseReader` /
     `readDailyReportSseStreamEntry(raw, logger)` (reads one Redis stream entry, `{ id, message }` as the client returns it, once: `{ entry, json }`,
     the frozen `StreamEntry` the shared reader hands every subscriber and the entry's parsed JSON value; for a host whose own reader keeps the same
     contract) /
@@ -4369,7 +4576,10 @@ Documenting a name here is no reason to export it, and the values that tune the
     the ports' own types `DailyReportResolveUserId` / `DailyReportEncodeUserId` / `DailyReportResolveVisibleSourceTypes` (with
     `DailyReportVisibleSourceTypes`, `DailyReportVisibilityDimensions`, `DailyReportVisibilityOptOut` (the explicit opt-out
     `{ unrestricted: <reason> }`), `DailyReportVisibilityResolveContext` and `DailyReportVisibilityResolveReason`) / `DailyReportRedisClient` / `DailyReportRedisBlockingClient` / `DailyReportRedisStreamMessage` /
-    `DailyReportSseEntryMessage` (an entry's message read once) / `DailyReportExternalSource` (an `externalSources` adapter),
+    `DailyReportSseEntryMessage` (an entry's message read once: `parsed`, a `DailyReportSseStreamMessage` — the message as the service writes it to
+    the stream, read by `dailyReportSseStreamMessageSchema`: the types that may be addressed carry the server-only `recipientRawUserId`, and the types
+    that embed a report also the server-only `actorRawUserId`, which the delivery replaces with each viewer's `viewerIsActor` — and `published`, the JSON
+    value as written, which only the recipient filter reads; every frame is built from `parsed`) / `DailyReportExternalSource` (an `externalSources` adapter),
     the injected tables `DailyReportHubTable` / `DailyReportInternalTable` / `DailyReportCommentTable` / `DailyReportLabelTable` /
     `DailyReportHubLabelTable` / `DailyReportUserStatusTable` / `DailyReportUserTable` / `DailyReportAttachmentTable` (the members of
     `DailyReportTables`), the service's rows `DailyReportUserStatusRow` / `DailyReportIdsSource`,
@@ -4390,6 +4600,13 @@ Documenting a name here is no reason to export it, and the values that tune the
     `DailyReportSearchCriteria` (what `searchDailyReports` takes: `{ plan, filters }`, the plan `null` for a filters-only search) /
     `DailyReportSearchFilters` (the parsed filters, each `null` when unset: the source types as a lower-case set, the authors and customers as
     `DailyReportSearchNameFilter`, a non-empty tuple) / `DailyReportSearchFacets` (the answer of `search-facets`).
+- **testing** (`@aiquants/daily-report/testing`, a host's tests):
+  - `createDailyReportTestInstrumentation()`, the value a host's test build provides through `DailyReportInstrumentationContext` (see
+    [Test hooks](#test-hooks)).
+  - Types: `DailyReportViewTestHandle` (the views' test handle) / `DailyReportViewTestReadHandle` (its read-only part) /
+    `DailyReportRowPassCounters` / `DailyReportRowPassKindReading` (what its `rowPass` reads) and the row pass's events it counts,
+    `DailyReportRowPassEvent` / `DailyReportRowPassUnitFrameEvent` / `DailyReportRowPassUnitKind` / `DailyReportRowBoxSizing` /
+    `DailyReportRowUnitChange`, and `DailyReportReEstimateCounters` (what its `estimate` reads: the re-estimates and those made in motion).
 
 ## License