AURA HMS — what is real, what is simulated, and how to check

Counted from the repository at build time

screens

46

business-logic modules

123

lines of business logic

28180

API routes

21

database migrations

44

tables under FORCE ROW LEVEL SECURITY

33

unit test files

365

browser test specs

24

visual baselines

60

commit-gate checks

99

design rules ratcheted

19

languages

2

Verify these from this link, now

1. the database is reachable from this deployment, as the restricted application role (not a superuser). GET /api/health/db → {"ok":true,"role":"aura_app"}
2. the ledger is append-only and hash-chained, and verification needs a signed-in tenant. GET /api/ledger/verify → {"ok":false,"reason":"no-session"} signed out; {"ok":true,...} for a signed-in tenant
3. sign-in is real (Supabase Auth: email + password, sign-up provisions a tenant). open the sign-in dialog from the header; a wrong password and an unknown email get the same message on purpose
4. tenant isolation is enforced by the database, not the browser. every table carries FORCE ROW LEVEL SECURITY (count above); the adversarial drill npm run db:prove runs eight attacks as the app role

Real today

• reservations, tape chart, check-in/out and folios; housekeeping; maintenance; duty log; night-audit date roll
• a hash-chained, append-only ledger with GST slabs sourced from the statute (India), credit notes, business dates
• revenue assurance: rate leakage, OTA true cost, settlement reconciliation joins, a leak report
• three product tiers from one codebase (homestay, hostel/PG, hotel chain) with entitlement-gated, code-split modules
• offline-capable client (IndexedDB) that syncs its ledger and inventory to Postgres through the API routes
• a design system whose colours are solved for contrast (70/70 in the proof table), two languages
• a property's own booking page that takes a stay from a guest with no account, and a desk that sees it within a minute; a room night sold once on the server whoever writes it; invoice and credit-note numbers issued by the server rather than the device; a night-audit pack that says whether it equals the server ledger; Form III for a foreign guest; and a full tenant export verifiable against the hash chain — each proven on the live link by a named probe under scripts/live/

Simulated today — stated, not hidden

• the channel CONNECTION: no OTA credentials exist yet, so nothing can arrive from a real OTA. The screen around it is not simulated — since 16 Sep a signed-in property's Channel Manager reads its real state from the server (it says this server holds no AxisRooms key for that property) and lists the channel bookings the server holds with no room; the ingest endpoint decides each delivery against the live schema — duplicate, stale, early, booked, no room, unknown room type — and an unplaced booking reaches the duty manager's dashboard (scripts/live/glancechannel.mjs, 8/8 on the link)
• payments: the settlement logic is real, no gateway is connected yet
• the demo property's operational data is seeded in the browser; a signed-in tenant's ledger, rooms, inventory and bookings sync to Postgres (all 40 migrations applied, the last on 16 Sep 2026) and were proven to cross devices on this link (scripts/live/booking.mjs); guest profiles do not sync yet — a guest name travels inside the booking id

What ships next

Acceptance test, dated 2026-10-03: One Indian property runs a paid month on AURA: its own login, bookings from one OTA and its own site, its own money, its own GST invoices and night audit, its Form C filed.