Wiki · Evidence & Verdicts
Receipt — calibration: every signal sorted to the DD/TDD metadata contract
How to read this page
Three ways to read this page. Precise is the document itself, exactly as it is written in the repository. Plain and Clear were written for this website to help you meet that document — they are about it. They are not it, and they are not evidence.
Eighty-seven dated pages: receipts, pre-registrations, handoffs, validation records and review verdicts. A receipt is written at the moment a piece of work was checked. It names what was claimed, the commit and the seed, what was actually run, and the outcome in one of a small set of controlled words. Then it names what the work did not achieve. That last part is what makes it a receipt rather than an announcement. A pre-registration is the same discipline run in advance: the conditions that would count as a pass and the conditions that would falsify the claim are written down before the run, so neither can be adjusted once the numbers arrive.
That is why so many small dated stubs are an audit trail rather than noise. No one of them is meant to be a good read. The value is in the sequence and in the dates, because you can watch a prediction be registered, then the run happen, then the verdict land — sometimes against the prediction. Pages here record a falsified result, a rejected fix, a retracted overclaim, and a green receipt that turned out not to be reproducible from the commit that carried it. A record that carried only successes would be worth a good deal less than this one.
A gentle way in is to read a pre-registration first, so the shape becomes familiar, then a result page, then one of the corrections. This section sits off the main navigation on purpose: it is the record you check the rest of the site against, not the place to begin.
What it is not: documentation, and not a summary. Nothing here has been tidied in hindsight. Every entry reads as of its date, a later entry may overturn an earlier one, and the presence of a page is not a claim that its result stood.
Your browser cannot switch reading levels, so the document itself is shown.
Precise — the source document
This is the document. Rendered from the repository at the commit above, with nothing rewritten for the web. A gate re-renders it on every deploy and fails the build if a single byte differs.
Date: 2026-07-17 · Track: studio · Gates: gate-ledger-schema-conformant,
hud-renderer-honesty — the operator's "cross check all signals true honest DD TDD meta data sorted."
D1 — the gate ledger conforms to its own schema (PASS)
Was: ~18 rows (this session's fan-out and HUD honesty gates) used a non-canonical shape
{gate, track, verdict, ts, claim, evidence} instead of production/schemas/gate_row.schema.json's
{schema_version, name, verdict, receipt_path, evidence_class, last_updated, …}. render_gates.cjs
reads receipt_path/evidence_class/phase, so those exact honesty gates rendered in docs/GATES.md
with Phase/Class/Receipt = "—" even though the receipts existed on disk. The DD/TDD metadata was not
sorted to its own contract — the operator's phrasing, precisely.
Fix: for each nonconformant gate name, a canonical superseding row was appended (append-only —
history is never mutated; render_gates.cjs shows the last row per name), mapping evidence → receipt_path,
gate → name, ts → last_updated, claim → pass_condition, verdict + receipt unchanged.
Proof:
distinct gates: 97
current rows failing schema: 0
current rows with missing receipt file: 0
ALL current gate rows are schema-conformant with real receipts.
docs/GATES.md now renders the once-orphaned gates with their Class and a linked receipt (e.g.
air-level-counts-program-picture … PASS │ B │ [hud_glance_honesty_2026-07-17.md]). Verdict: PASS.
D2 — the HUD renderer has honesty tests (PASS)
Was: the whole HUD test suite covered the SERVICE (SnapshotBuilder, PollWorker); the widget
renderer — where every WS-B render fix (B5 stale-greying, B6 SIGHT-blind, B7 recovery-repaint) lives —
had zero tests. The receipts' own standing rule: no green claim about the renderer is permitted
until this gate exists.
Fix: the widget's render-decision logic (which cannot depend on WPF) is extracted into pure,
testable static functions in UNI.Hud.Widget/RenderDecisions.cs, and a test project
UNI.Hud.Widget.Tests exercises them against null-colony / stale-air / stale-metric / blind-sight /
not-measured→recovery inputs and fails unless the surface reads "not measured" / greys / repaints.
Proof: the widget's honesty decisions now live in RenderDecisions.cs (pure, zero WPF deps) and
the widget CALLS them (air badge, egress floor, metric freshness, SIGHT header, colony dwell,
SectionCache recovery). UNI.Hud.Widget.Tests compiles RenderDecisions.cs directly (no WPF ProjectRef)
and exercises the SAME source — not a copy.
UNI.Hud.Widget.Tests: Passed! 22 / 22
Rehearsed against a deliberate regression (a test that never fails proves nothing): re-introducing
the three old lies — STREAMING_DARK => green, egress readers >= 1 (no floor), blind SIGHT not
warned — produced
Failed! - Failed: 3, Passed: 19
and restoring RenderDecisions.cs returned to 22 / 22. The deployed widget renders identically after
the extraction (captured live: OFF AIR, colony "frames advancing … last frame 0s ago", health above
the fold, footer "poll 443 · last 0s ago") — no behavioural regression, and both HUD suites are green
(51 service + 22 widget).
This gate landing upgrades hud-freshness-honest (B5), hud-sight-shows-blind (B6), and
hud-recovery-repaints (B7) from PARTIAL to PASS — the render-failure rehearsal they were waiting
on. Verdict: PASS.
sha256 8d69d586db3112fc — of the original file, so what was ingested stays checkable.
Plain — written for this website, not the source document
Two pieces of housekeeping, both finished. The first: a batch of rows in a ledger — a list added to and never edited — had been written in the wrong shape. So the page that renders the ledger showed dashes where a class and a link to the run's own record should have been, even though those files existed on disk. Rather than edit history, corrected rows were appended, because only the last row per name is rendered. The second: the part of a display that decides what to show had no tests at all. Its decision logic was lifted into plain functions and tested, including a rehearsal that put the old faults back to check the tests would notice.
Plain · written 2026-08-01 by claude-opus-5 · not yet checked by a person · about the document whose sha256 is 8d69d586db3112fc
Clear — written for this website, not the source document
A receipt — the file recording what was run — in two parts, both marked pass. The theme joining them is metadata that had drifted out of the shape its own contract required.
The first part is a ledger: a list that is added to and never edited. A batch of rows had been written with keys that did not match the schema the project publishes for them. Nothing was lost, but the renderer reads particular fields, so those entries appeared with empty class and receipt columns even though the receipts sat on disk. The fix respects append-only history: for each nonconformant name a corrected row was appended, mapping the old keys onto the contracted ones and leaving the verdict and the receipt itself untouched, and the renderer shows the last row per name. A short block of output states how many current rows now fail the schema and how many point at a receipt that is not there.
The second part is about tests that did not exist. The suite covered the service behind a display, but not the part that decides what the display should say, which is exactly where a run of honesty fixes had landed. The page quotes its own standing rule: no green claim about that part is permitted until this gate exists. The fix extracts the decision logic into pure functions with no dependency on the graphical framework, and a separate test project exercises them against the awkward inputs, including no data, stale data, a blind sensor, and recovery afterwards.
The part worth copying is the rehearsal. A test that never fails shows nothing, so the three old faults were deliberately put back and the suite went red in exactly three places, then green again once they were removed. The deployed display renders the same as before the extraction, and the page lists which earlier gates move from partial to pass now that this one exists.
Clear · written 2026-08-01 by claude-opus-5 · not yet checked by a person · about the document whose sha256 is 8d69d586db3112fc