Judge every rendered claim, over the whole set of states that render one

[systemslibrarian]

Five of the six lane fixes in audits/LANE-VERDICT-HARNESS-2026-09-21.md apply to this lab. Fix 5 is a constraint and was honoured: branch protection was not touched in either direction, confirmed read-only at the API (build + verdict-coverage required, enforce_admins: false, force-push and deletions disabled) — which is why this is a pull request.

Baselines

Every run below used CI=1, so Playwright started its own server on this lab's pinned port 4698 (tools/playwright-ports.json) and no reused listener could turn a mutation into a false survivor.

	Result
Unmutated baseline BEFORE any edit (ab679b9)	21 passed (15.0s)
Unmutated baseline AFTER all edits	23 passed (31.7s) (+ Tests 24 passed (24) unit)

Two gaps confirmed by survival, not by argument

Both were run against the suite exactly as it stood at ab679b9, before any harness change.

S1 — the record verdict's plate, pinned green (Fix 1). src/ui/app.ts sets verdict.className and verdict.dataset.status in separate expressions. Replacing the class expression with the constant 'verdict verdict-pass' leaves a green pass plate reading "RETRIEVED — AND WRONG".

  21 passed (13.9s)

SURVIVED. Seven assertions covered that marker's text and its data-status; none covered what a reader actually sees.

S2 — the size formula's total, a literal (Fix 4/6). = ${parts.total} bytes replaced with = 290 bytes, correct only at the default 65,536-record domain.

  21 passed (13.9s)

SURVIVED, because nothing in the suite ever moved #size-domain.

Mutations run against the new harness

All twelve were actually run; none is recorded from reasoning. Baseline was green in the same session for each.

Fix 1 — record-match, the same S1 mutation

Error: record-match is painted as alarm while its text says "RETRIEVED — AND WRONG / 1 of 16 bytes differ"

expect(received).toBe(expected) // Object.is equality

Expected: "rgb(66, 29, 36)"
Received: "rgb(15, 53, 43)"

   at verdict-assertions.ts:45

KILLED — 1 failed / 22 passed, on that marker's own assertion.

Fix 4/6 — key-size-formula, the same S2 mutation

Error: the formula states this domain's own measured parts: 17 + (17 × log₂ 16) + 1 = 290 bytes

expect(received).toEqual(expected) // deep equality

  Array [
    17,
    17,
    16,
    1,
-   86,
+   290,
  ]

KILLED — 1 failed / 22 passed. Note the domain in the failure: log₂ 16. It is the walk over all four domain options that makes this visible at all.

Fix 2/3 — the denominator itself, data-claim="chor-query-bytes" deleted from index.html

Error: mutations registered for measurements this page never renders

- Array []
+ Array [
+   "chor-query-bytes",
+ ]

and, from the stray-measurement scan:

Error: unmarked measurements on the page: [
  {
    "tag": "span",
    "id": "chor-byte-label",
    "reason": "measurement rendered outside a data-claim marker: \"8,192 bytes · 65,536 bits\"",
    "text": "8,192 bytes · 65,536 bits"
  },

KILLED — 5 failed / 18 passed, both coverage directions plus the scan, all on the mutation's own subject.

The remaining measurement claims

Marker	Mutation	Verbatim	Result
chor-query-bytes	domainSize / 8 → / 4	Error: chor-query-bytes measured value / Expected: 2 / Received: 4	KILLED (1 failed / 22 passed)
key-part-root	rendered root parts.rootMaterial → - 1	Error: key-part-root measured value / Expected: 17 / Received: 16	KILLED (1 failed / 22 passed)
key-part-levels	rendered levels + perLevel	Error: key-part-levels measured value / Expected: 68 / Received: 85	KILLED (1 failed / 22 passed)
key-part-final	rendered final → 2 B	Error: key-part-final measured value / Expected: 1 / Received: 2	KILLED (1 failed / 22 passed)
key-bytes-total	rendered total serialized.length - 1	Error: key-bytes-total measured value / Expected: 86 / Received: 85	KILLED (2 failed / 21 passed)
dpf-key-bytes	label renders parts.correctionWords	Error: dpf-key-bytes measured value / Expected: 86 / Received: 68	KILLED (1 failed / 22 passed)
prg-node-width	* 8 + 2 → * 8	Error: prg-node-width measured value / Expected: 258 / Received: 256	KILLED (1 failed / 22 passed)

key-bytes-total failed two tests, and the second is worth reading: the server-tile test now derives the key size it expects from that claim rather than from a literal 290, so it went red too —

Error: server-view-0 text
Expected substring: "one party-0 key of 289 B"
Received string:    "1Server 0 · one party-0 key of 290 B · folded 33,077 of 65,536 records"

One mutation run and REJECTED as evidence

key-part-root was first attempted at the source: const ROOT_MATERIAL_BYTES = 1 + SECURITY_BYTES → SECURITY_BYTES in src/dpf/serialize.ts. The key stops round-tripping and the whole suite goes red — 6 passed, with the first failure being locator('#step-value') Expected: "3 / 4" Received: "4 / 4", nothing to do with the marker. Per the lane's rule that is not a readable kill, so it is not the recorded mutation. The recorded one flips only that claim. The rejection is written into the registry entry so the deeper mutation is not "helpfully" restored later.

Two previously recorded verdict mutations, re-run through the new helper

Marker	Mutation	Verbatim	Result
single-share	namesAPoint: lit === 1 → lit >= 1	Error: single-share text / Expected pattern: /ONE KEY ONLY · k0 alone lights \d+ of \d+ leaves, naming no point/ / Received string: "!ONE KEY ONLY · k0 alone lights exactly 1 of 16 leaves, so this share names a point by itself"	KILLED (1 failed / 22 passed)
record-match (the previously recorded shape)	reconstruct drops server 1: byte ^ (answer1[index] & 0)	Expected: "0000a179b775501af95aeda6e57ca896" / Received: "0000cb3c7630d6e4d53e25f1bcda4ba4"	KILLED (4 failed / 19 passed). Honest note: the first failing assertion is the shelf-oracle comparison inside the record-match test, not the expectVerdict line. It is that marker's own test, and the registry now records the stronger class-pin mutation instead, because that one is the only mutation in the set that distinguishes a plate from a sentence.

No mutation survived the new harness. No mutation timed out. The six verdict mutations already recorded at ab679b9 and not re-run here (tree-point, collusion-recovery, server-view-0, server-view-1, collusion-state, no-authentication) keep their original records; the harness change only strengthened their assertions.

Fix 6, enumerated for this lab

driveEveryState visits every option of every control that changes what renders, each control on its own, never the cross-product:

Control	Options visited
#alpha-range	all 16 secret indices
expansion stepper (#step-back / #step-next)	all 5 levels, down and back up
#new-keys	one option, exercised once
#size-domain	all 4 domains (16 / 256 / 4,096 / 65,536 records)
#collusion-toggle	both states, and again through a fetch for the tile it paints
#tamper-toggle	both states, with its own fetch
#fetch-record	exercised throughout
#shelf-alpha	not an enumerable option set — a 65,536-value number input, so its two rendering classes stand in: the in-range fetch and the rejection that renders no result
.key-inspector disclosure	opened, because both scans skip elements with no client rects, so a closed disclosure hid the serialized key dump from the denominator entirely

No control on this page was judged not to change what renders, so nothing was skipped on that ground.

Catalog-affecting findings

None. Nothing in crypto-lab was edited. The card's copy and chips remain accurate: the page still teaches two-server DPF PIR, and the one page string that was a standing constant rather than a measurement (AES-128-CTR → 2(λ + 1) bits) is now rendered from a real expandSeed() and reads AES-128-CTR → 2(λ + 1) = 258 bits per node.

🤖 Generated with Claude Code

https://claude.ai/code/session_01UH9YUUhdeWXJz141Zy8FxW