Report freshness banner

Kind: WARNING, not ERROR. The five-kind taxonomy (bristlenose/ui_kinds.py) is explicit that a sixth is not to be invented, so the banner picks from what exists. ERROR means “did not complete; action needed” — right for the status page, where there is nothing to show. Here a complete artefact is on screen and only its currency is in question, which is what WARNING (“recoverable / partial / soft-degrade”) names. Reaching for ERROR would teach the researcher to distrust a report that is fine.

It is the status page folded to one line. Same glyph, same kind colour (--bn-sentiment-surprise), same <details> + <pre> disclosure carrying the same cause block. Nothing new is being said, so nothing new is being drawn — the two surfaces are one message at two sizes.

Genuinely new element, flagged. No banner/notice component exists in frontend/src/components/ or in theme/{atoms,molecules,organisms} — I checked before drawing. Every value above is an existing token; the component is new and needs your nod. Home would be theme/molecules/report-notice.css plus a small React component, not inline styles.

Which of the two you get is decided by evidence, never by how bad the failure looked: is there a coherent last-good artefact? That keeps us out of the business of maintaining a severity taxonomy of failures.

It also needs a real fix underneath, and this is the part worth scrutinising. The pipeline rewrites intermediate JSON stage by stage, so a failed run can leave stages 1–9 new and 10–12 old. A running serve only re-imports on a completed terminus, so today’s common case (provider outage, network, crash) never touches the DB — yesterday’s report is intact. The hole is a serve restart, whose startup import would happily ingest that mixed state. So the rule is one line with two consumers: the DB advances only on a completed terminus — the importer skips, and the page gate reads the same fact.

• Does a cancelled run earn a banner at all? Drawn above as INFO with no disclosure, because there is no cause to show and the researcher did it on purpose. But the sidebar’s own glyph rule already decided the sibling case — “a run they stopped is not news” — and the consistent reading of that is no banner for a cancelled run, only for a failed one. I lean to dropping it; the counter-argument is that “this isn’t the run you started” outlives the memory of cancelling.
• Dismissible? Drawn as not. It states a condition that persists until a successful run, and the fix is to re-run, so a dismiss button would mostly serve to let a researcher hide the fact and then present stale findings. The cost is a band on every lens until the condition clears.
• Sticky, or does it scroll away? Drawn scrolling. It re-appears on every lens switch, which is probably enough; sticky is heavier and steals vertical space from the content the researcher came for.
• The date. Drawn as “28 August”. It must come from the existing shared date rendering, not a new format — docs/design-shared-formats.md is explicit that a format with no shared stem is a format that drifts, and this one has a Python, a TypeScript and a Swift renderer to agree with.

Copy, unsettled on purpose (English gets hand-tuned before it is seeded to 21 locales). Three candidates for the leading sentence:

• “Showing the report from 28 August. The latest run failed.” — drawn above; says what you are looking at first, which is the fact the researcher needs.
• “This report is from 28 August. A more recent run failed.” — same order, softer, slightly longer.
• “Last analysed 28 August · latest run failed” — most compact, reads as chrome rather than prose; pairs best with the not-sticky choice.

The desktop sidebar row keeps its own failure glyph and diagnostic popover. That is a different fact in a different place — the row says this study’s run failed, the banner says this report predates it — and per the house rule status lives where its subject lives. Browser and CLI have no row at all, so the banner is their only signal either way.

One consequence to accept knowingly: with D4-B in, a failed-but-previously-analysed project serves the SPA, so its lenses are live and correctly lit. That is the same one-line flip in ArtifactPrior the lens work left waiting, and it lands in the same commit as the serve rule — the prior must always mirror the serve that is actually running.