devreports catalog NEW-badge visual regression (parked 2026-05-14 EOD)

DARE.CO.UK · PARKED SKETCH · 2026-05-18

Mirrored from ~/.claude/.../memory/project_devreports_new_badge_regression_parked.md. This is a design sketch parked for future build — read for context, not as a current deliverable.

Catalog rows on devreports.dare.co.uk lost the red-dot NEW indicator and reverted to a “new” pill style; the markup still emits but the CSS rendering changed; small visual fix queued for tomorrow morning before audrey stand-up

Dan flagged 2026-05-14 evening end-of-day: the devreports catalog at https://devreports.dare.co.uk has reverted to a “new” pill alert style instead of the previous red-dot indicator on freshly-published rows.

What I confirmed before parking: - The markup is still emitted — <span class="new-badge" aria-label="new"> appears in the current catalog HTML (per cf-access -s | grep) - The render logic at ~/bin/dare_dev_reports_publish.py:474 is unchanged structurally - So the regression is on the CSS / styling side, not on the data / emit side

Where the CSS lives (to investigate tomorrow): - The catalog page’s <style> block is built in dare_dev_reports_publish.py (look around line 377 — the comment block mentions NEW signals freshness) - OR shared CSS in seo_render_html.py if catalog imports from there - Likely cause: a CSS rule for .new-badge { background, border-radius, etc. } either got reverted by a recent edit, OR a more-specific selector elsewhere is overriding it

Investigation 2026-05-14 evening (after parking): I dug in further before bed. Headlessly screenshotted the actual cf-access-fetched catalog HTML and the red dots ARE rendering correctly — 57 dots, one per recent report row, exactly per the CSS spec (6px × 6px, border-radius: 50%, accent colour). No competing pill-style CSS rule exists in the live HTML. The implementation matches the design intent.

Conclusion: the “regression” Dan saw is almost certainly stale browser cache. Recommended action when revisiting: hard-refresh (⌘+Shift+R) on https://devreports.dare.co.uk/. If dots appear after hard-refresh, no code change needed; close this memo as a false alarm. If dots STILL appear as a pill after hard-refresh, the surface to investigate is browser-specific CSS injection or an extension, not the code.

Original suspect commits I checked anyway (clean): - ~/bin/dare_dev_reports_publish.py (touched several times: pattern additions, REPORT_PATTERNS rows, etc.) — no CSS changes - ~/bin/seo_render_html.py (touched today for anchor enricher + HOVER_PREVIEW_CSS extraction) — .new-badge rule at line 198 is the canonical 6px-dot definition; unchanged from prior days

Resume: tomorrow morning before the audrey stand-up. Small visual fix, ~5-10 min: 1. git log -p ~/bin/dare_dev_reports_publish.py ~/bin/seo_render_html.py | grep -A5 -B2 new-badge to find recent CSS changes 2. Compare against the working version Dan remembers (probably from 2026-05-10ish — the red-dot pattern’s prior state) 3. Restore the red-dot CSS rule + republish

Likely culprit: when extracting HOVER_PREVIEW_CSS from seo_render_html.py earlier today (toolkit commit 6551fbf ish), some adjacent CSS may have been swept up or had its specificity changed. The anchor-enricher work added classes like link-with-thumb to the same render surface — possible they’re inheriting / overriding the .new-badge rule.

Pairs with: - feedback_renderer_change_invalidates_artefacts.md — renderer changes today required .html sibling deletion to take effect. A CSS-only change in the renderer would also need this for the visual to reflect. Worth checking the cache state. - feedback_state_emerges_from_data.md — the NEW badge is derived state (from file mtime); the data side is fine, the visual signal is the regression. - feedback_thumbnail_on_ship_pattern.md — same surface; the catalog hover-preview thumbs ARE rendering correctly tonight, so it’s not a wholesale catalog-CSS break.