Calendars and events, scoped to who's looking

A world already has hours and policies. What it didn't have was a timeline — the turnover happening Thursday, the maintenance window next week, the local event worth mentioning to a guest.

What shipped

A general events model built around two ideas: where an event comes from, and who it's for.

• Sources, not just entries. Events can come from a manual entry, an imported calendar (ICS today; read-only Google and CSV import as sources grow), or an override on top of an imported event — each source independently active, paused, or erroring.
• Typed events — ops, local, stay, turnover, maintenance, pricing, or reminder — so a calendar can hold very different kinds of information without losing structure.
• Visibility per event — guest, staff, or host — so a turnover note and a guest-facing local happening can live on the same calendar without ever being shown to the wrong audience.

Why scoped visibility matters here

A calendar that shows everything to everyone stops being useful fast — staff-only logistics have no business on a guest surface, and guests don't need to see internal turnover scheduling. Building visibility into the event itself, rather than filtering after the fact, means that boundary can't accidentally leak.