Placemakr Dupont CircleLive
Back to Support

Release Notes

v0.1.0 — Webhook Receiver + pms-join-miss Alert (June 2026)

Unblocked by Alicia confirming webhook subscribe permissions on the Placemakr API Gateway. OSVL now has a verified public receiver for forwarded Apaleo + Breezeway events, an Admin view of recent traffic, and a new pms-join-miss alert that surfaces unmatched Breezeway ↔ Apaleo references in real time.

What's new

  • Public receiver at /api/public/pms-webhook — POST only, OPTIONS for gateway probes. HMAC-SHA256 verifies X-Placemakr-Signature (t=<unix>,v1=<hex>) against PMS_WEBHOOK_SIGNING_SECRET over the raw request body. Replay window: 5 minutes. Replays deduped by X-Placemakr-Delivery (in-memory LRU, 1024 entries).
  • In-memory ingest buffer — last 200 accepted events with trimmed payload preview (id / event_type / topic / reference_property_id / status), plus an accepted/rejected counter and last-received timestamp. Persistence intentionally deferred until Coverage v2 (v0.0.13) introduces the first DB tables.
  • Snapshot invalidation — any forwarded Apaleo reservation/*, unit/*, unitgroup/*, booking/*, or maintenance/* event calls invalidateApaleoSnapshot(), so the next dashboard read refetches within the 60s React Query window instead of waiting it out. Closes the polling lag for live properties.
  • pms-join-miss alert rule — for every Breezeway event whose reference_property_id is not present in the current Apaleo snapshot (property ids ∪ unit ids), the receiver records a join-miss. /alerts reads the live list via getJoinMissAlertsFn and renders one High severity alert per unmatched reference, with occurrence count and last-seen time. TTL 24h per reference; deduped per reference id.
  • Admin → PMS Webhook Receiver card — signing-secret status, accepted/rejected counters, join-miss count, copy-to-clipboard for the receiver URL, and a live table of the 10 most recent events (source, type, delivery id, time). Polls every 15s.

Why it matters

  • Live properties don't wait 60 seconds for an Apaleo change to show on the Dashboard anymore — the webhook flushes the snapshot cache the moment the event lands.
  • The Apaleo ↔ Breezeway join is now actively monitored. Previously join coverage was a one-shot metric inside getApaleoSnapshotFn; it now generates an alert the first time a real event references an unmapped id, which is how operators will actually catch missing tenant mappings during the pilot.

One-time operator step

Subscribe the receiver via the Placemakr API Gateway (POST /v1/webhooks/subscriptions). The gateway returns a signingSecret once — paste it into Lovable as PMS_WEBHOOK_SIGNING_SECRET (Project → Secrets). Until that secret is set the receiver returns 503 receiver not configured for every POST.

Explicitly deferred

  • DB-backed event log + dead-letter UI — promoted alongside Coverage v2 (v0.0.13).
  • Breezeway PmsSource adapter (v0.0.11) — HK / maintenance tasks still come from the demo seed; the receiver records the events but task pages don't consume them yet.

No data or schema changes

Pure additive — new route, new server fn, one new secret. Existing demo / Apaleo flows untouched.

v0.0.10 — Dashboard Cut-Over to PmsSource (June 2026)

Closes the loop on v0.0.9. The Apaleo adapter is now actually visible to operators — flipping VITE_PMS_SOURCE=apaleo propagates through Property Dashboard, Daily Operations, Housekeeping, and Coverage Planner, not just the Configuration health card.

What's new

  • usePmsUnits / usePmsOccupancy hooks (src/hooks/usePmsData.ts) — React Query wrappers around getPmsSource().getUnits() and getOccupancy(). Cache keys include the active source id (["pms", sourceId, kind, propertyId]) so source flips produce a clean cache partition with no cross-source bleed. staleTime: 60s matches the Apaleo snapshot cache.
  • Four dashboards rewired — Property Dashboard, Daily Operations, Housekeeping, and Coverage Planner now read units + forecast through the hooks. Under VITE_PMS_SOURCE=demo the hooks resolve synchronously from in-memory data (no loading flicker). Under apaleo the first paint shows demo as fallback, then swaps to live data once the snapshot resolves.
  • Clean separation of PMS vs non-PMS data — units and occupancy come from the active PmsSource; staff, shifts, MoD assignments, coverage requirements, HK tasks, maintenance tasks, and alerts continue to come from OSVL Configuration / demo seed. Apaleo doesn't own scheduling, so we don't pretend it does.

Why it matters

  • Operators: setting VITE_PMS_SOURCE=apaleo is now a real go-live switch. Unit status badges, occupancy KPIs, turn counts, and the 14-day forecast all reflect the live tenant within 60 seconds (or instantly via Refresh now).
  • Pilot rollout: a property can be flipped to live PMS data without redeploying. The cut-over is reversible — flip back to demo and the in-memory seed returns.

Explicitly deferred

  • Apaleo webhook receiver + pms-join-miss alert (v0.1.0) — still blocked on Alicia confirming event names.
  • Breezeway PmsSource adapter (v0.0.11) — HK tasks and maintenance tasks still come from the demo seed; the Breezeway adapter is the next ticket and will replace them.
  • Multi-property switcher — all four routes are hard-coded to prop-1. Property selection is a separate UX ticket; the hooks already accept any propertyId.

No data or schema changes

Pure read-side wiring — no migrations, no new tables, no env additions.

v0.0.9 — Apaleo PmsSource Adapter (June 2026)

Promotes Apaleo from "reachable for ping/snapshot" to a fully-implemented PmsSource. Flipping VITE_PMS_SOURCE=apaleo now flips Configuration's health panel to Live, populates real row counts and last-sync time from a live Apaleo snapshot, and exposes a Refresh now action that invalidates the snapshot cache on demand.

What's new

  • Apaleo → OSVL mapper (src/lib/pms/apaleo/map.ts) — translates ApaleoProperty / ApaleoUnit / ApaleoReservation into the demo-shaped Property / Unit / OccupancyForecast / ReservationRow types the app already consumes. Status mapping: active maintenance window → maintenance-hold, Dirty → dirty, CleanToBeInspected → inspecting, Clean + isOccupied → in-progress, Clean → ready.
  • Apaleo PmsSource adapter (src/lib/pms/apaleo.ts) — async implementation backed by getApaleoSnapshotFn. One snapshot powers all four reads (properties / units / reservations / occupancy) via an in-module 60-second cache. On fetch failure the last good snapshot is retained and getHealth() reports the degraded state.
  • Factory wiring — IMPLEMENTED_SOURCES.apaleo now points at the real adapter. isRequestedSourceLive() returns true when the env flag is apaleo, and the Admin "Falling back to Demo" pill flips to Live.
  • Live snapshot in Admin — the PMS Data Source card uses useQuery to prime the snapshot when Apaleo is active. Last-sync, latency, unit count, property count, and reservation count all reflect the real snapshot once it loads. A Fetch error — serving stale badge surfaces when the underlying server fn fails but a prior snapshot is still cached.
  • Refresh now button — clears the 60s cache and re-fetches on demand.

Privacy

  • Guest names from Apaleo reservations are not surfaced in OSVL (currentGuest stays undefined under the Apaleo adapter). Pilot scope is operational status, not guest PII.

Why it matters

  • Walter / Allie: connecting a real Apaleo tenant is now a credentials-only operation. No code change needed to go live.
  • Operators: the Configuration panel becomes a real heartbeat — last-sync timestamp comes from an actual round-trip, not a synthetic "now".

Explicitly deferred (next cut)

  • Dashboard / Daily Operations / Housekeeping / Coverage wire-through. Those four pages still read directly from getPropertyData("prop-1", ...) because they mix PMS data (units / occupancy) with non-PMS data (staff / shifts / HK tasks) in tight useMemos. Migrating each to useQuery against getPmsSource() is its own focused ticket — tracked for v0.0.10.
  • Apaleo webhook receiver + pms-join-miss alert — still blocked on Alicia confirming event names and configuring a subscription against /api/public/apaleo/webhook.
  • Breezeway PmsSource adapter — separate ticket; HK-focused, lands after Apaleo cut-over is validated.

No data or schema changes

Pure adapter work — no migrations, no new tables.

v0.0.8 — PMS Source Selection Plumbing (June 2026)

Makes the Demo → live-PMS switchover a config change rather than a code change. The actual data flip on dashboards stays gated on a live PmsSource adapter being built against Apaleo (deferred until join coverage is verified end-to-end and Alicia's webhook details land), but every wire underneath the flip is now in place and visible.

What's new

  • VITE_PMS_SOURCE env flag is now respected at runtime. getPmsSource() reads the flag, validates it against the known catalog (demo / breezeway / apaleo / azure), and selects the requested source. Unknown values fall back to demo silently.
  • Requested vs effective source separation. New helpers getRequestedPmsSourceId() and isRequestedSourceLive() let the UI distinguish "operator asked for Apaleo" from "Apaleo adapter exists and is driving data". Today only the Demo adapter is implemented, so any non-demo selection cleanly falls back instead of crashing dashboards.
  • Active selection panel on Configuration. The PMS Data Source card now shows the current VITE_PMS_SOURCE value, a Live / Falling back to Demo status pill, and a one-liner explaining which pages the active source is driving.
  • PmsSourceBadge is fallback-aware. When the operator has requested a live source but no adapter exists yet, the badge renders Demo (fallback → Apaleo) in warning colors so KPI provenance is never ambiguous. A new optional sourceId prop pins a badge to a specific source for metrics that are always sourced from one system (e.g. Breezeway tasks).

Why it matters

  • Walter / Allie: the flip from pilot data to live PMS data no longer requires a code release. Once an adapter ships, it's a single env-var change to promote it.
  • Operators: ambiguity about whether a KPI came from Demo or live data is now resolved at the badge level, including the in-between state where a live source has been requested but the adapter isn't ready.

Explicitly deferred (still v0.0.9 territory)

  • The Apaleo PmsSource adapter itself — mapping ApaleoProperty / ApaleoUnit / ApaleoReservation into the demo-shaped Property / Unit / OccupancyForecast types the dashboards consume. Today IMPLEMENTED_SOURCES.apaleo is null and the factory falls back.
  • Promoting Apaleo from opt-in to default. Default stays Demo until both the adapter and the join-coverage gate are green.
  • Replacing Demo KPIs on Dashboard, Daily Operations, and Housekeeping with Apaleo reservations + Breezeway tasks. The seam is ready; the wiring isn't pulled through until the adapter exists.

No data or schema changes

Pure plumbing release — no migrations, no new tables, no demo data changes.

v0.0.7 — MoD Frequency Caps (June 2026)

Closes the last enforcement gap in the Coverage Planner: the MoD frequency caps in the scheduling rules are now tracked and visibly flagged. Eligibility (managers only), weekend coverage, and close/open conflict detection were already live in v0.0.3 — this release makes the burnout-prevention caps observable too.

What's new

  • MoD Fairness panel on the Coverage Planner — table per eligible manager showing MoD shifts assigned in the rolling 7-day window, their cap, and a status pill (OK / At cap / Over by N).
  • Frequency caps enforced: GM/OM ≤ 3 MoD shifts/week, FO and HK managers ≤ 2 MoD shifts/week. Caps come straight from the Coverage & Scheduling Rules card on Configuration.
  • Inline overflow chips on the 7-Day Rotation Preview — any AM or PM slot assigned to a manager who exceeds their cap gets a red Over cap chip directly on the rotation row.
  • Card-level warning header when any manager is over cap, with a count badge in the panel title.

Why it matters

  • Property managers can spot fairness drift at a glance — no more reading the rotation row-by-row to count who is doing too many MoD shifts.
  • Walter / Allie: caps from the SOW are now visible enforcement, not just policy text in the Admin rules table.

No data or schema changes

Pure presentation layer. Cap logic reads existing demo shifts via isMoD and groups by staffId; GM/OM detection uses the gm* email prefix seeded in demo data and will switch to a proper role field once we move off Demo PMS in v0.0.8.

v0.0.6 — Apaleo Direct Connector (June 2026)

Second PMS-derived source landed. Apaleo joins Breezeway behind the same PmsSource seam. Demo PMS still drives dashboards by default; Apaleo is reachable for connectivity testing and snapshot pulls today, opt-in via VITE_PMS_SOURCE=apaleo once join coverage is verified.

Connector

  • Auth: OAuth2 client credentials against identity.apaleo.com. Secrets: APALEO_CLIENT_ID, APALEO_CLIENT_SECRET, APALEO_TOKEN_URL, APALEO_BASE_URL — all read inside the server function handler.
  • Scopes granted by Alicia Barnash: accounts.read properties.read reservations.read units.read unitgroups.read.
  • Endpoints: /v1/inventory/properties, /v1/inventory/units, /v1/inventory/unit-groups, /v1/reservations, /v1/account.
  • Token caching: in-memory on the server isolate, 30s safety window.
  • Polling cadence: properties/unit-groups daily; units hourly; reservations on a 7-day forward window every 15 min.

Admin

  • Test connection button on the Configuration page now pings Apaleo and surfaces latency + sample count, matching the Breezeway flow.
  • Apaleo row in the PMS Data Source panel flipped to Configured.

Cross-system join

getApaleoSnapshotFn returns a joinCoverage summary comparing Breezeway reference_property_id values against Apaleo property IDs — the same join surfaced in the snapshot endpoint, ready to wire into the pms-join-miss alert in v0.0.7.

Webhooks (requested, not yet built)

Reply sent to Alicia requesting subscriptions to:

  • Reservation lifecycle: reservation.created, reservation.changed, reservation.checked-in, reservation.checked-out, reservation.canceled.
  • Unit status: unit.changed, unit.cleaning-status-changed (exact event name TBD against the linked spec). Receiver endpoint (/api/public/apaleo/webhook, HMAC-verified) deferred to v0.0.7.

Explicitly out of scope this release

  • No webhook receiver yet — polling covers the v1 use cases.
  • No write-back to Apaleo.
  • Reservation-assignment events not requested (not in granted scopes).

v0.0.5 — Breezeway Staging Connector (June 2026)

First real PMS-derived data source wired in behind the existing PmsSource seam. Demo PMS remains the default for dashboards; Breezeway is reachable for connectivity testing and ready to power housekeeping/maintenance task surfaces once Apaleo lands and the cross-system join is verified.

Connector

  • Auth: OAuth2 client credentials against the Placemakr API Gateway. Credentials live in server-only secrets (BREEZEWAY_CLIENT_ID, BREEZEWAY_CLIENT_KEY, BREEZEWAY_TOKEN_URL, BREEZEWAY_BASE_URL) and are read inside the server function handler — never bundled into the browser.
  • Endpoints: /v1/breezeway/properties, /v1/breezeway/tasks, /v1/breezeway/people, /v1/breezeway/templates.
  • Token caching: in-memory on the server isolate with a 30s safety window before expiry.
  • Polling cadence: tasks on a 2-day rolling updated_at window (day-granularity is all the proxy currently supports); properties daily.
  • Rate limit: 300 req/min on the proxy — comfortable headroom; no backoff layer added for pilot.

Admin

  • Test connection button on the Configuration page now executes a live ping against the Breezeway proxy via a server function. Surfaces latency and a friendly error if the call fails.
  • Breezeway listed as a separate row in the PMS Data Source panel with status Configured (vs. Apaleo/Azure still marked Not configured pending the integration decision).

Documentation

  • User Guide → PMS Integration Readiness now documents the Breezeway connector: auth method, endpoints, refresh cadence, rate limit, join key (reference_property_id → Apaleo Unit ID), and the webhook gap.
  • OpenAPI spec for the Placemakr API Gateway saved at src/lib/pms/breezeway/openapi.json as reference (not used at runtime).

Notable discovery

The same Placemakr API Gateway also exposes Apaleo read endpoints (/v1/apaleo/properties, /v1/apaleo/reservations, etc.). This narrows the Azure-vs-Apaleo decision: a single gateway can serve both. Captured as an open question for the integration discussion.

Explicitly out of scope this release

  • No PMS-source switch on dashboards — Demo still drives KPIs until Apaleo lands and the join key is validated.
  • No webhook receiver — polling is sufficient at current cadence.
  • No Apaleo connector — same OAuth pattern will apply once the integration path is confirmed.

v0.0.4 — PMS Integration Seam & SOW Reconciliation (April 2026)

Architectural and product groundwork landed while the client decides between direct Apaleo and Azure Data Warehouse as the PMS integration path. The connector implementation itself is intentionally deferred — everything in this release is path-agnostic and ships value the day credentials arrive.

Status: Connector implementation pending client decision on Azure DW vs Apaleo direct.

Integration-agnostic seam

  • PmsSource interface — new src/lib/pms/types.ts defining the read contract OSVL needs (getReservations, getUnits, getOccupancy, getProperties, getLastSyncAt, getHealth).
  • Demo source wrapper — src/lib/pms/demo.ts wraps the existing seeded data behind the same interface so the rest of the app already consumes data through the seam.
  • Source factory — getPmsSource() selects the active implementation. Ships defaulting to Demo. Adding Apaleo / Azure later is a single new file plus a factory switch.
  • Routes refactored — Dashboard, Coverage Planner, Housekeeping Planner, and Daily Operations all read through the seam. Zero behaviour change today, single swap-in point tomorrow.

Admin Data Source panel

  • New PMS Data Source card on Configuration showing every known source (Demo, Apaleo, Azure) with status, last sync, latency, and row counts.
  • Sources without a connector are marked Not configured for transparency.
  • Per-source Test connection action returns a real status for active sources and a friendly "Pending integration approach" message for sources awaiting the client decision.
  • New PMS Data Requirements card listing every field OSVL reads, who consumes it, and the expected refresh cadence.

Stale-feed alert rule

  • New pms-feed-stale rule fires when the active source has not produced fresh data within 60 minutes.
  • Reads getLastSyncAt() from the active source. In demo mode the source returns now() so the rule stays dormant — it only surfaces against a real connector.
  • Wired into the Alerts page and the Dashboard alerts panel so the UI surface is built and tested before real data can trigger it.

Data source badges across the UI

  • Small Demo PMS badge appears next to dashboard KPIs, housekeeping demand, coverage demand, and unit readiness counts.
  • Badge reads from the active source's id and auto-flips to Apaleo or Azure the day a real connector is wired in.

Documentation

  • New PMS Integration Readiness section in the User Guide covering both Azure and Apaleo paths, what OSVL reads (and never writes), and the stale-feed fallback.
  • Two downloadable client intake checklists generated for whichever path the client picks:
    • OSVL_PMS_Intake_Apaleo_v1.pdf — OAuth client, scopes, webhook approval, sandbox env, PII confirmation.
    • OSVL_PMS_Intake_Azure_v1.pdf — service type, server/db, auth method, table/view names, network access, non-prod env, PII-free view request.

Explicitly out of scope this release

  • apaleo.ts and azure-warehouse.ts connector implementations
  • OAuth/secret storage wiring
  • Webhook receiver route
  • Any Azure relay / Private Endpoint plumbing

v0.0.3 — Coverage Visibility & On-Call Config (April 2026)

Iterative improvements to the Coverage Planner and Admin configuration based on follow-up requests.

Coverage Planner

  • MoD Rotation Explainer — Added an on-page explanation showing how the daily AM/PM MoD rotation is selected (eligibility pool, rotation order, fairness caps for GM/OM and FO/HK managers).
  • Weekend MoD Alert Panel — New dedicated panel above the MoD schedule that lists each weekend date with missing AM or PM slots. Each entry includes a "View in rotation" link that smooth-scrolls to the affected row and briefly highlights it.
  • Today vs Last 7 Days Toggle — Added a tab control to switch between today's snapshot and a rolling 7-day view. The range view surfaces aggregate KPIs (Avg Staff/Day, Total MoD Shifts, Exception Days) and a daily summary table flagging weekend gaps and close/open conflicts.

On-Call Maintenance Rotation

  • New configuration object — Added OnCallRotation to the data model with rotation owner, role, contact phone/email, cadence, and escalation path. Each property now carries a maintenanceOnCall record.
  • Admin page — New "On-Call Maintenance Rotation" table documenting the owner and escalation path per property.
  • Coverage Planner — Replaced the static overnight maintenance note with a dynamic "Overnight Maintenance Coverage — Source" card that pulls from the property's on-call configuration.

v0.0.2 — Client Feedback Updates (April 2026)

Schedule model corrections based on feedback from Walter Stanley (VP, Property Operations) and Allie Ayers (Sr. Director, Property Operations).

Coverage Model

  • Property-wide MoD — MoD is now assigned at the property level (1 AM + 1 PM), not per department. The role rotates daily across eligible managers (FO, HK, GM/OM).
  • Weekend MoD = AM + PM — Saturday and Sunday now require both AM and PM Manager-on-Duty coverage. A new high-severity alert fires when either slot is missing.
  • Coverage Planner refresh — MoD section redesigned as a property-level slot table (MoD AM / MoD PM) instead of stacking under each department.

Maintenance

  • Maintenance shifts are now AM & PM only. Overnight maintenance is covered by the on-call rotation, not scheduled shifts.
  • Coverage Requirements table no longer shows maintenance overnight or evening rows.

Housekeeping

  • Cleaning staff (room attendants) are out of scope for OSVL scheduling for now and are excluded from generated shifts and coverage gap math.
  • Housekeeping Planner now shows a banner clarifying the page tracks task demand only — staffing recommendations are informational.
  • Coverage Planner housekeeping rows reflect managers/supervisors only.

Stakeholders

  • Added Allie Ayers — Sr. Director, Property Operations alongside Walter Stanley as primary client stakeholders.

v0.0.1 — Initial Preview (April 2026)

This is the first preview release of the Operational Scheduling Visibility Layer (OSVL) for Placemakr. All features below are functional with seeded demo data for three properties.

Property Dashboard

  • KPI cards displaying occupancy percentage, arrivals today, departures today, and turns needed
  • Unit Status Bar — horizontal visualization showing the distribution of unit statuses (ready, dirty, in-progress, maintenance-hold, inspecting)
  • Today's Coverage summary table with department, shift type, assigned count vs. required, and MoD indicator
  • Active Alerts panel showing the most recent operational alerts with severity badges
  • 14-Day Occupancy Forecast with color-coded tiles (green <75%, amber 75–89%, red 90%+) showing daily occupancy, arrivals (↓), and departures (↑)

Daily Operations Board

  • KPI row: Units Ready, HK Tasks, Maintenance Tasks, Units in Hold
  • Unit Readiness progress bar with status breakdown
  • Maintenance Queue table showing unit number, issue description, priority indicator (🔴🟡🟢), and status badge
  • Unit Readiness Grid — color-coded grid of 60 units with tooltips showing unit number and status

Housekeeping Planner

  • Demand KPIs: Departures (Turns), Stayovers, Total Tasks with estimated hours, and Recommended Staff count
  • Today's Progress bar with completion percentage and task counts (completed, in-progress, pending)
  • Shift workload breakdown — Morning (70% of load) and Afternoon (30% of load) with estimated hours and recommended staff per shift
  • Task Queue table with unit number, clean type (checkout/stayover), status badge, priority indicator, and estimated time

Coverage Planner

  • KPI cards: Total Staff Today, MoD Assigned (managers only), Coverage Gaps, and Close/Open Conflicts
  • Manager-on-Duty Schedule table for today showing manager name, department, shift type, and time
  • MoD policy note: only managers (FO, HK, GM/OM) are eligible — supervisors excluded
  • Close/Open Shift Conflicts section — highlights staff scheduled for 11 PM close followed by 7 AM open with destructive badge
  • 7-Day Coverage Overview — weekly grid showing shift counts per day with MoD and conflict badges

Alerts & Exceptions

  • Severity summary badges at top: Critical, High, Medium counts plus total
  • Full alert list with severity color-coding, category labels, messages, and detail text
  • Alert types included: Schedule Conflicts (close/open violations), Housekeeping (dirty unit threshold exceeded), Maintenance (backlog warnings), Coverage (weekend/overnight MoD gaps)

Configuration

  • Properties table showing all three demo properties (Dupont Circle, Wall Street, Ballston) with unit counts and manager allocations (FO, HK, GM/OM)
  • Shift Templates table: Morning (7a–3p), Afternoon (3p–11p), Overnight (11p–7a) with department applicability
  • Coverage & Scheduling Rules table with six active rules:
    • Close/Open Prevention
    • MoD Eligibility (managers only)
    • GM/OM MoD Frequency (3/week max)
    • FO/HK Manager MoD Frequency (2/week max)
    • Weekend Coverage requirement
    • Overnight Maintenance on-call

Support Center

  • Support hub page with cards linking to User Guide, Release Notes, and Contact/Feedback
  • User Guide — comprehensive documentation with scrollable table-of-contents sidebar
  • Release Notes — versioned changelog (this page) with TOC sidebar
  • Collapsible sidebar with navigation links to all seven sections
  • Responsive layout adapting to desktop viewports
  • Consistent design system using semantic color tokens (foreground, muted, primary, destructive, warning, success, info)

Demo Data

  • Three seeded properties: Placemakr Dupont Circle (120 units), Wall Street (85 units), Ballston (95 units)
  • Deterministic data generation (seeded PRNG) for consistent server/client rendering
  • Realistic unit status distribution: ~55% ready, ~20% dirty, ~13% in-progress, ~7% maintenance-hold, ~5% inspecting
  • Staff roster with managers and staff across Front Desk, Housekeeping, and Maintenance departments
  • 7-day shift schedule with automatic close/open conflict seeding
  • Housekeeping and maintenance task generation based on unit statuses

Planned — v0.0.2

  • Property switcher — select between Dupont Circle, Wall Street, and Ballston
  • Interactive shift editing with drag-and-drop
  • Database backend with Lovable Cloud for persistent data
  • Staff assignment for housekeeping and maintenance tasks
  • Alert acknowledgment persistence
  • Export schedules and coverage reports as CSV