Audit of every human-facing scheduling surface against boas.dev v3.4.0 (azure #38bdf8, Bricolage Grotesque, procedural edge, dark #06090b), the plan to unify the drift, and two directions for the operator's "one unified view." Proposal only — nothing builds until you pick.
| Surface | Owner / repo | Design system | v3.4.0 | Evidence |
|---|---|---|---|---|
| meet /m, /p, /auth, error | metis · meet-boas-dev | boas.dev v3.4.0 | yes | renderers carry Bricolage + #38bdf8 + feTurbulence, 0 green · PR#160 live |
| meet /api/reschedule | metis · meet-boas-dev | boas.dev v3.4.0 | yes | reskin-port shipped today · PR#164 live (deploy cb776929) |
| meet emails (OTP, invite, confirm, reschedule, cancel, host) | metis · meet-boas-dev | v3.4.0 email-hybrid | yes | OTP+invite live-sent (008/009); suite staged |
| meet /me — hero | metis · meet-boas-dev | boas.dev v3.4.0 | yes | the original v3 exemplar |
| meet /me — dashboard body | metis · meet-boas-dev | partial / unscanned | partial | hero V3; body not yet swept — UNVERIFIED |
| pantheon.boas.dev/calendar — the calendar app | apollo · infra-pantheon | Pantheon cockpit v2.0.0 | NO | KEY ANSWER: --pantheon-* tokens, #22c55e phosphor, #0a0a0a void, JetBrains-only, no Bricolage/edge · 9 files w/ #22c55e |
| cal.boas.dev (booking page) | proteus · Cal.com self-host | Cal.com native | ceiling | free tier: brand-color + dark/light only; custom CSS/fonts = enterprise |
| boas.dev marketing | boas-dev/brand | boas.dev v3.4.0 | anchor | the canonical system — the reference, not a drift |
Headline: the meet side is fully v3.4.0 (shipped this session). The calendar app is the single biggest drift — it's still on the retired Pantheon operator-cockpit green (#22c55e), a different design system entirely. It is the one operator-facing scheduling surface not on boas.dev v3.4.0. cal.boas.dev can only approach v3.4.0 (azure accent + dark) within Cal.com's free tier — it cannot take Bricolage or the procedural edge without an enterprise plan.
| Move | Who fixes | Effort | Notes / blockers |
|---|---|---|---|
| Calendar app → v3.4.0 | apollo (my infra-pantheon FE) | M–L | swap the --pantheon-* token bridge → --c-* (#38bdf8); add Bricolage; restyle calendar-theme.css (react-big-calendar chrome), EventModal, EventTile, ICSPanel, kind-colors. Coordinate with athena: is the WHOLE Hub shell going v3.4.0, or just the calendar surface inside the cockpit? |
| /me dashboard body → v3.4.0 | apollo | S–M | scan + finish off the hero's tokens |
| cal.boas.dev → as close as tier allows | proteus (owner) | ceiling | set brand color #38bdf8 + dark; logo. Full skin blocked on Cal.com enterprise — flag to operator |
| Email suite v3 → deploy | metis | S | staged + render-verified; just needs prod cutover |
The operator wants calendar + scheduling + meet to read as one product. Two ways to mean that:
One new surface (e.g. pantheon.boas.dev) that fuses calendar grid + upcoming meetings + pending proposals + booking into a single dashboard. New information architecture.
Keep the distinct surfaces (each does its job well), unify them with one v3.4.0 skin + a shared boas.dev top-nav/chrome tying calendar, /me, /p, /m together. The "one product" read comes from identical tokens + shared frame, not a merged screen.
Recommendation — B, with a light "Today" landing that can grow into A. The arc is already functionally live; the fastest path to one product is unifying the skin (calendar app → v3.4.0) and adding shared boas.dev chrome — a unified read with no IA rebuild and no new standing surface. A full merged portal (A) can layer on later once the skin is one. Embedded operator call: the calendar app is today the internal operator cockpit (pantheon.brand.json explicitly "NOT a client surface"). Moving it to client v3.4.0 means deciding whether pantheon.boas.dev/calendar is client-facing or stays operator-internal — that choice rides on top of A-vs-B. Out of scope here: "deploy on boas.com" is a domain/infra migration (athena/proteus/hades), not this design task.