feat(site): announcement bar — two-item carousel surfacing upcoming events alongside AdCP version

[geneticallymodifiedfoodforthought]

Summary

The announcement bar below the nav currently shows only the latest AdCP version. Add a two-item carousel (3–4s auto-rotation) so upcoming events share that real estate on every page load.

Motivation

The announcement bar is the highest-visibility strip on the site — it renders on every page, above the fold, before the user does anything. Events are the highest-conversion community touchpoint (chapter meetups, summits, industry gatherings). Today they're only discoverable on the Community page. Surfacing them globally captures visitors who never navigate there.

Proposed behaviour

• The bar rotates between two slots:
  • Slot 1 (existing): AdCP version pill + "What's new →" link
  • Slot 2 (new): Next upcoming event — name, date, and a "Register →" CTA
• Rotation interval: 3–4 seconds, pause on hover
• If no upcoming event is scheduled, the bar stays single-item (current behaviour, no empty slot)
• On mobile, same two-slot carousel; tap advances manually in addition to auto-rotation

Implementation notes

• Event data can be pulled from the same source that powers /community (the events API / list_events)
• "Next upcoming event" = earliest event with status: published and start_time > now
• The version slot copy and styling should remain unchanged so existing brand/docs links aren't disrupted
• Accessibility: respect prefers-reduced-motion — when set, show both items statically (e.g. separated by a divider) rather than rotating

Acceptance criteria

• Announcement bar rotates between version announcement and next event (3–4s)
• Rotation pauses on hover
• Falls back to single-item if no published upcoming event exists
• prefers-reduced-motion shows static two-item layout
• Mobile: works correctly at all breakpoints

[bokelley]

Thanks for filing!

Triage

Classification: Feature request
Bucket(s): web / site
Status: ready-for-human

What the experts said:

• css-expert: The prefers-reduced-motion fallback and non-breaking additive framing are sound, but flags a scope mismatch — the announcement bar currently lives only in server/public/index.html, not in the shared nav.js, so "every page load" site-wide would require threading event data through 100+ HTML files or refactoring the bar into the nav script — scope the issue doesn't acknowledge. Also flags potential layout shift without fixed-height slots before JS initializes.
• docs-expert: Flags version-signal dilution for the DSP/SSP implementer audience — today's banner carries a single release-candidate notice that implementers must act on; rotating it off-screen on a timer risks them landing mid-rotation and missing it. Also flags no stated fallback when the events API times out or returns 5xx (beyond the "no upcoming event" graceful-degradation case).

My take: Both experts agree the core idea is valid but two product questions need a human call before code lands: (1) should the release notice ever rotate off-screen given this audience, and (2) is the scope truly site-wide or homepage-only (the latter is tractable; the former requires a nav.js refactor not acknowledged in the issue).

@bokelley, your call: (A) homepage-only carousel where the version notice stays permanently visible and the event slot is additive — or (B) site-wide, with version pinned always-visible and event as a secondary strip, which requires a nav.js refactor and an explicit events-API timeout/fallback spec?

---

Triaged by Claude Code. Session: https://claude.ai/code/${CLAUDE_CODE_REMOTE_SESSION_ID}

---

Generated by Claude Code