What was reported
The incident record says that a 70-story component smoke pass was green before visual review found mobile problems. The reported symptoms were a bottom-sheet handle colliding with header text on narrow screens, low-contrast route badges in dark mode, and route-leg markers being clipped by a stacking or overflow boundary.
Those are plausible failures for a UI that depends on responsive CSS and layered map or sheet surfaces. They are not reproducible from this checkout. There is no Storybook configuration, 70-story source set, screenshot collection, Android device record, browser version, or commit that produces the reported 70/70 result. The count and symptoms should remain attributed to the incident record rather than presented as a locally verified run.
What the green check could and could not establish
A headless story check can prove that a component mounts, receives a prop, exposes an action, or produces the expected state. It cannot by itself prove where text wraps, whether a 28-pixel handle remains visually separate from a title, whether a dark-mode badge meets contrast, or whether an icon is painted above a clipped ancestor.
The current geometry test shows the distinction. It verifies the semantic mapping between a mobile sheet detent and a physical snap point:
it("maps semantic detents to physical snap points", () => { const heights = mobileSnapHeights(844) expect(snapPointForDetent("collapsed", heights)).toBe(heights.pill) expect(snapPointForDetent("partial", heights)).toBe(heights.partial) expect(snapPointForDetent("expanded", heights)).toBe(heights.full) expect(mobileDetent(heights.pill, heights)).toBe("collapsed") expect(mobileDetent(heights.partial, heights)).toBe("partial")})That is a useful current test in mobile-snap-sheet-geometry.test.ts. It protects the detent model. It does not inspect computed layout, font metrics, contrast, or paint order. The sheet implementation in mobile-snap-sheet.tsx still needs browser-level evidence for those questions.
The evidence trail stops before the visual comparison
The nearby UI history supports that the product was changing. Commit 27e7b31 moved map-owned styles and changed application UI files. Commit 9ad36b2 changed route chrome and offline UI and includes component tests. Commit 95ddd57 refreshes dashboard history UI. None of those commits is evidence of a Storybook run or an Android screenshot review.
The available PNGs are icons and temporary workspace captures with no reliable connection to this incident. They should not be published as before/after evidence. The missing artifact is specific: one named component, one named browser and device or viewport, a baseline image, and the changed image. Without that chain, a visual claim cannot be checked later.
What the postmortem should change
Keep semantic and interaction tests. Add visual evidence when a change can affect wrapping, spacing, contrast, clipping, stacking, or responsive composition. The review record should name the tested dimensions and state, show before and after images for the changed surface, and link the source change that produced them.
This is a recommendation from the failure analysis, not a claim that the repository currently enforces that process. The durable lesson is narrower: a passing DOM or state check is evidence about behavior at that level. It is not a visual approval.