Umbrella & Design System (PL-T184)
At a glance
Foundation layer for the entire chain-venue platform. A per-tenant ChainVenueProfile document holds operational configuration in one place — opening rules, booking knobs, payment toggles — and a typed booking-color token system gives every booking type a consistent visual identity across calendar, floorplan, customer CMS and operator console, with WCAG AA enforced in CI.
How it works
When a CHAIN tenant onboards, the platform seeds a single ChainVenueProfile document keyed to the tenant. This profile is the authoritative source for opening rules, booking-engine knobs, payment toggles, smart-upsell rules, marketing automation, and any other knobs the operator can tune. Loading the profile is a single Mongo read with no joins, so console screens and storefronts stay snappy even on tablet hardware behind the bar.
The profile is fetched via GET /chain/venue-profile and mutated via PUT /chain/venue-profile — both admin-gated. Every mutation is recorded in an audit trail so support can answer "who changed the cancellation window last Tuesday" without guesswork. The booking-color token system defines eight booking types (court_play, table_dining, event_corporate, event_private, event_drop_in, tournament, maintenance, staff_shift), each with three variants (chip, surface, border) and two modes (light, dark).
Tokens are emitted as CSS custom properties consumed by both the marketing site (www) and the tenant-CMS (web), and shared with admin via packages/shared. Two CI tools enforce quality at PR time: audit-booking-colors.mjs checks WCAG AA contrast across every token combination, and audit-booking-premium-criteria.mjs blocks regressions against the documented UX bar. The result is one config-shaped contract and one visual contract that every other subsystem in the chain-venue domain plugs into.
Key capabilities
- Single ChainVenueProfile document per tenant — authoritative operational config
- Eight booking types × three variants × two modes color-token matrix
- Admin-only profile read + write endpoints with full audit logging
- Default seeding on CHAIN tenant onboarding — zero-config day-one launch
- WCAG AA contrast audit enforced in CI
- Booking premium-criteria CI gate prevents UX regressions
- Shared CSS custom properties consumed by www + web + admin
In practice
A new boule-bar operator signs the chain-tier contract on Monday morning. The onboarding job provisions the tenant, seeds a ChainVenueProfile with sensible defaults, and the operator lands on the admin dashboard with everything wired up. They open Settings → Venue Profile, raise the cancellation window from 4 h to 24 h, flip dynamic_pricing_enabled on, and save.
The audit log records the change with their user_id and timestamp. By Friday, when district manager asks why peak-hour quotes look different, support pulls the audit trail and shows exactly when and by whom the toggle was flipped. Meanwhile, the booking calendar, floorplan, and customer-CMS all render bookings in the correct color-coded chips because every surface reads from the same shared token file.
Features in this subsystem
9| ID | Status | Features |
|---|---|---|
| F22.00.01 | Shipped | Booking color token system (8 types × 3 variants × 2 modes) ✅ |
| F22.00.02 | Shipped | CSS custom properties for www and web ✅ |
| F22.00.03 | Shipped | ChainVenueProfile Beanie model ✅ |
| F22.00.04 | Shipped | GET /chain/venue-profile (admin-only) ✅ |
| F22.00.05 | Shipped | PUT /chain/venue-profile (admin-only) ✅ |
| F22.00.06 | Shipped | Audit logging on all profile mutations ✅ |
| F22.00.07 | Shipped | Default seeding on CHAIN tenant onboarding ✅ |
| F22.00.08 | Shipped | WCAG AA audit tool (audit-booking-colors.mjs) ✅ |
| F22.00.09 | Shipped | Booking premium-criteria CI gate (audit-booking-premium-criteria.mjs) ✅ |
Stakeholders who need this subsystem
Surfaces in 6 stakeholder analyses