The medium metric card discloses its history coverage
Row ui-db-d3 part 3b — decider receipt f34db768a: the collapsed view a PM actually opens said nothing, and now says what the line covers
16 Sept 2026 · branch ui-db-d3-p3b · captured against propflow-stage · at c8f4d75d20
Data note. Every name and balance below comes from propflow-stage, which is anonymized by construction (ADR-0097/0110 — phones in the impossible +1000 NPA, emails @example.test). The identical capture against prod would carry real tenants' names and balances and is not safe to attach anywhere, which is why the generator refuses to run against one.
1 · WIDE — three medium cards, three different coverages, one clause each
The dashboard's default render. Under each card's context sentence there is now one quiet line: History: 1 of 74 properties on Occupancy, History: 66 of 74 properties on Monthly Revenue and on NOI. Before this PR none of the three said anything at any width — the caption rode showTrendChart, which is large only, and the dashboard renders these cards at medium. That gap was found by a FAILED assert on #8826's capture, not by a test, and ruling f34db768a is the answer to it.
The three numbers differing is the point. Occupancy's monthly store reaches one building of seventy-four; the money metrics reach sixty-six. One cue per metric, composed per metric — not one card-wide sentence, and not a guess.
Why it leads with the word History — the ruling's stated cost-if-wrong. The hero above it (78.6%, $679,469) is computed across EVERY property in scope; only the stored monthly line behind it is narrower. A bare “1 of 74 properties” under that headline reads as a claim about the headline itself, which is both false and far more alarming than the truth. Every branch of historyCoverageCue begins with History, and the test file asserts that rather than trusting it.
Asserted in the captured DOM — History: 1 of 74 properties · History: 66 of 74 properties · 513 of 653 occupied. Both distinct cues are asserted BY VALUE — if the cue ever became one card-wide sentence, or leaked the hero's own scope, these strings stop matching. The context sentence is asserted alongside so a capture that silently lost the card's existing copy cannot pass as a success.
2 · NARROW — the same cards at 900px: one line, no wrap, no reflow
The card type's medium form is the pre-canvas default and is byte-identical territory, so the question this section answers is whether a new line in it survives a narrow column. It does: the cue is white-space: nowrap with text-overflow: ellipsis and the full string on title, because a caveat that wraps under a hero reads as a broken sentence rather than as a caveat.
At this width the grid reflows the three cards and the Occupancy card's own context sentence wraps to two lines — that wrap is pre-existing and is visible on origin/main too. The cue underneath it stays on one.
Asserted in the captured DOM — History: 1 of 74 properties · History: 66 of 74 properties. Same strings at a different width. An ellipsis would truncate the rendered TEXT, so the fact that both full strings are still in the DOM at 900px is the no-truncation proof; the picture is the no-wrap proof.
The complete-coverage card is proved by mount test, not captured — and why
The ruling asks for a positive control: a card whose history covers the whole scope renders no cue at all. This environment has no instance of one on the All-Properties view — all three monthly-backed metrics are partial here (1 of 74, 66 of 74, 66 of 74), which is exactly why the disclosure was ruled necessary. The only scope where the cue would legitimately vanish is a single-property one, and selecting a property puts a real customer property NAME in the header of a published capture; the capture pipeline's contact gate classifies emails and phones and nothing else, so it would not stop that.
So the control lives in history-coverage-cue.test.tsx, and it asserts more than the picture could: HistoryCoverageCue returns null rather than an empty span, so the card has no element and no gap — an empty span would still take the card's line-height and shift everything under it, which is precisely the spacing regression a screenshot of a complete card would be there to rule out. Four of that file's cases pass against origin/main as well (the medium form's other flags unchanged, a caller passing no cue unchanged, LARGE and SMALL drawing no cue either way), which is what proves the harness mounts a real card rather than failing to mount at all.
Not in this part: the per-month clause (Partial months: 2 of 3 in May '26) belongs to #8826, still open — it lands INSIDE the rider this cue is composed from, so it arrives here on rebase with no further wiring. A per-point marker on the chart itself remains out: ObservabilityChart is 1445 lines shared across the app.