Phase 1 Go-Live — Flow Coverage Gap Analysis
Date: 2026-04-24
Author: Platform Registry program (paper audit)
Inputs: flow-{1..10}-*.spec.ts in hmp-infrastructure/testing/flow-tests/src/flows/; Platform Registry under hmp-docs/registry/; Q4-FINDINGS.md; FD-2026-04-23-{001..044}.yaml.
Summary
| Metric | Count |
|---|---|
| Total flows | 10 |
| Fully covered (all sub-items tested + stories+impls present) | 2 |
| Partial coverage (some sub-items missing test or story gaps) | 7 |
| Uncovered (major sub-items absent) | 1 |
Overall state: Every flow has at least a spec file and at least one implementing story, but Flows 5, 7, 8 and 10 still carry backend bugs or soft-skipped assertions from the Q4 triage (see Q4-FINDINGS.md). Legend for the Sub-items column: ok = covered with real assertions; soft = test present but soft-skips on error (does not hard-fail); UNKNOWN = not obviously covered in the spec; n/a = no sub-item given.
Per-flow breakdown
Flow 1 — Tenant Onboarding
| Field | Value |
|---|---|
| Spec file | flow-1-tenant-onboarding.spec.ts |
| Registry stories | ST-001-001 (login), ST-001-002 (refresh), ST-001-011 (user CRUD/invite), ST-002-001 (property create), ST-002-009 (onboarding tagged) |
| Sub-items tested | (i) signup ok; (ii) login with new creds ok; (iii) empty dashboard ok; (iv) create first property ok; (v) cross-tenant isolation A↔B ok |
| APIs touched (top 5) | AP-auth-POST-auth-login, AP-auth-GET-auth-me (+ me/properties), AP-auth-POST-onboarding-tenantid-activate, AP-property-POST-properties, POST /api/tenants/signup (no registry AP-ID yet — gap) |
| Key screens | SC-dashboard-login, SC-admin-login, SC-admin-onboarding |
| Known blockers | Signup endpoint POST /api/tenants/signup has no registered AP-auth-POST-tenants-signup entry in the API registry. Tenant-code case sensitivity is not asserted. INTERNAL_SERVICE_TOKEN missing at QA has broken cross-service TENANT_CREATED propagation twice (see memory feedback_qa-internal-service-token.md). |
| Gap summary | Coverage of the happy path is solid. Missing: API registry row for the signup endpoint; no test for the invite-user flow in ST-001-011; the "empty dashboard" check is only a property-list check (no widgets/reports). |
Flow 2 — Property Onboarding (Name/Address/Map, Pictures, Room Types+Amenities, Rooms, Rate Plans, Tax, Cancellation)
| Field | Value |
|---|---|
| Spec file | flow-2-property-onboarding.spec.ts |
| Registry stories | ST-002-001 (property CRUD), ST-002-002 (room-type + amenities), ST-002-003 (rooms), ST-002-005 (rate plans), ST-002-006 (cancellation policy), ST-002-007 (seasonal rates), ST-002-009 (tax config) |
| Sub-items tested | (i) Name/Address ok, Google Map coords UNKNOWN (removed — UpdatePropertyDto has no lat/lng, see Q4 test-bug fix); (ii) Pictures ok (S2 presigned S3 URL — no actual upload or gallery reorder asserted); (iii) Room types + amenities ok; (iv) Rooms ok (bulk 10); (v) Rate plans ok; (vi) Tax info ok; (vii) Cancellation policy ok |
| APIs touched (top 5) | AP-property-PUT-properties-id, AP-property-POST-properties-id-photos (via upload-url), AP-property-POST-rooms-bulk, AP-property-POST-rate-plans, AP-property-POST-cancellation-policies |
| Key screens | SC-dashboard-settings-property, SC-dashboard-settings-rooms, SC-dashboard-settings-property-taxes |
| Known blockers | Sub-item (i) "Google Map" coordinates: backend DTO gap — UpdatePropertyDto has no latitude/longitude fields (Q4-FINDINGS test-bug classification masks what is really a product gap for the "pin on Google Map" requirement). Sub-item (ii) picture upload chain: only presigned URL is asserted; no S3 PUT, no AP-property-POST-properties-id-photos round-trip, no reorder test. |
| Gap summary | 5 of 7 sub-items strongly tested; Google Map pinning and the full photo upload→list→reorder chain are not exercised. Both are likely required for a guest-facing booking engine (photo gallery) and for a marketing-grade PDP. |
Flow 3 — Booking Engine Integration (customer books → shows on Reservations)
| Field | Value |
|---|---|
| Spec file | flow-3-booking-engine.spec.ts |
| Registry stories | ST-011-001 (search+availability), ST-011-002 (rate-plan compare), ST-011-003 (guest details), ST-003-001 (create reservation), ST-003-002 (list) |
| Sub-items tested | (i) Customer books → availability ok, create reservation ok, payment initiate+verify via proxy ok, reservation appears on staff list ok, detail includes guest/source/totals ok |
| APIs touched (top 5) | AP-reservation-POST-booking-engine-search-availability, AP-reservation-POST-reservations (booking-engine path), POST /api/booking-engine/payments/initiate-v2 (proxy), AP-reservation-POST-booking-engine-payments-verify, AP-reservation-GET-reservations-id |
| Key screens | SC-booking-direction-a-landingpage / -resultspage / -checkoutpage, SC-booking-direction-a-confirmationpage, SC-dashboard-reservations-id |
| Known blockers | None critical in Q4 triage. Booking payment is mandatory via backend proxy per feedback_payment-service-is-jwt-gated.md — never @Public on payment-service. Historical issue: POST /reservations 30s downstream slowness (Phase 7.5 memory) — not re-verified in Phase 1 Q4. |
| Gap summary | Strong happy-path coverage. Not tested: booking amendment + cancellation from guest-facing manage-booking page, rate-parity vs OTA, embed-widget flow, multi-language locale round-trip, rate-plan comparison UI assertions. |
Flow 4 — Staff checks Reservations with all details
| Field | Value |
|---|---|
| Spec file | flow-4-reservation-review.spec.ts |
| Registry stories | ST-003-002 (search/list), ST-003-003 (calendar view), ST-003-001 (create), ST-003-004 (modify) |
| Sub-items tested | (n/a — only one sub-item): S1 GET /reservations/:id full payload ok; S2 arrivals board soft (marked SOFT_SKIP — not gateway-routed yet); S3 /allowed-transitions soft (TODO — endpoint may be missing); S4 tenant isolation ok |
| APIs touched (top 5) | AP-reservation-GET-reservations-id, AP-reservation-GET-properties-propertyid-reservations (arrivals), AP-reservation-POST-reservations-search, AP-frontdesk-GET-properties-propertyid-arrivals (soft-skipped — routing gap) |
| Key screens | SC-dashboard-reservations, SC-dashboard-reservations-id, SC-dashboard-front-desk-arrivals |
| Known blockers | Arrivals endpoint not gateway-routed (S2 soft-skip). /allowed-transitions endpoint not implemented (S3 soft-skip) — blocks staff UI that needs to know which status buttons to enable. Both are low-risk but affect Flow 4 acceptance. |
| Gap summary | Detail-view read is well covered; arrivals list endpoint (used by the Front Desk arrivals board) is soft-skipped, and allowed-transitions is listed as TODO. Neither is captured as a drift finding yet. |
Flow 5 — FrontDesk/Housekeeping upcoming-guest updates (Room Move, Extend, All HK)
| Field | Value |
|---|---|
| Spec file | flow-5-fd-hk-updates.spec.ts |
| Registry stories | ST-005-009 (room move/upgrade), ST-003-004 (modify/extend), ST-006-001 (room status board), ST-006-002 (HK tasks CRUD), ST-006-003 (maintenance) |
| Sub-items tested | (i) Room Move soft (test catches 400 and skips — see Q4 TEST-BUG fix; only runs when a 2nd VACANT_CLEAN room and a CHECKED_IN reservation are available); (ii) Extend ok (PUT /reservations/:id +2 nights, nights assertion); (iii) All HK: DIRTY-set soft (Q4-FINDING-002 — gateway routes PATCH /rooms/:id/status to property-service), task create ok, task assign ok, task complete ok, status board ok; Sub-flow D maintenance create+list ok |
| APIs touched (top 5) | AP-frontdesk-POST-front-desk-room-move, AP-reservation-PUT-reservations-id, AP-housekeeping-POST-tasks, AP-housekeeping-PATCH-tasks-id-assign, AP-housekeeping-PATCH-rooms-id-status (routing bug), AP-housekeeping-GET-rooms-status |
| Key screens | SC-dashboard-housekeeping, SC-dashboard-housekeeping-tasks, SC-dashboard-housekeeping-maintenance, SC-dashboard-front-desk-calendar, SC-dashboard-front-desk-check-in-id |
| Known blockers | Q4-FINDING-002 (MEDIUM) — HK status via REST broken: PATCH /api/rooms/:id/status falls through gateway's longest-prefix matcher to property-service, which rejects HK enum values. WebSocket path works but REST UI does not. Fix requires a gateway services.config.ts + proxy.controller.ts pattern-route entry (two-file rule). Room move path hits a DTO precondition — move only allowed on CHECKED_IN reservations (test uses CONFIRMED, so soft-skips). |
| Gap summary | Largest functional gap in Phase 1. Three sub-items are soft-skipped: room move (reservation status precondition), HK DIRTY REST path (routing bug), 2nd-room availability (setup gap). Extend + HK task lifecycle + maintenance are clean. |
Flow 6 — Frontdesk check-in with mandatory details (Indian + International)
| Field | Value |
|---|---|
| Spec file | flow-6-check-in.spec.ts |
| Registry stories | ST-005-001 (standard check-in), ST-005-003 (folio mgmt), ST-004-003 (guest ID/Aadhaar masking), ST-003-009 (walk-in) |
| Sub-items tested | (i) Indian (Aadhaar masking+GST): Aadhaar 12-digit check-in ok; Aadhaar-<12 rejection ok (FINDING-F6-01); OPEN folio auto-created ok; room OCCUPIED ok. GST computation on folio is NOT asserted in this spec (checked in Flow 8/9 instead). Aadhaar-masking of persisted value is NOT asserted — only the input format is validated. (ii) International (Passport+CForm): passport check-in with formC data ok; missing passportNo rejected ok; C-Form list endpoint ok; C-Form entry exists ok. |
| APIs touched (top 5) | AP-frontdesk-POST-check-in-reservationid, AP-frontdesk-GET-folios-by-reservation-reservationid, AP-frontdesk-GET-frontdesk-cform, AP-frontdesk-POST-walk-in, AP-reservation-PATCH-reservations-id-status |
| Key screens | SC-dashboard-front-desk-check-in-id, SC-dashboard-front-desk-arrivals, SC-dashboard-guest-self-checkin-token |
| Known blockers | Aadhaar-at-rest masking is NOT validated by the test (ST-005-001 AC says "Aadhaar masked to last 4 digits" but no assertion). C-Form APIs are not claimed by any story (FD-2026-04-23-025 — feature-gap finding). GST slab logic coverage sits in Flow 9 only. Room HK status post-check-in is checked but may warn if the field is absent (optional assertion). |
| Gap summary | Both guest types have reasonable happy-path coverage. Missing: Aadhaar masking assertion (compliance risk — DPDP Act 2023), formal C-Form story, and a test that posts first-night room charge to verify GST slab. |
Flow 7 — Guest room-service food order (POS → Folio)
| Field | Value |
|---|---|
| Spec file | flow-7-pos-to-folio.spec.ts |
| Registry stories | ST-007-001 (outlets), ST-007-005 (KOT), ST-007-007 (room charge posting — in-progress), ST-005-003 (folio mgmt) |
| Sub-items tested | (i) Charges in Folio: Scenario 1 create ROOM_SERVICE order ok, add line items ok, post room-charge soft (FINDING-001 — 403 SAFEGUARD_BLOCKED), folio balance increment soft (depends on previous); Scenario 2 KOT chain ok up to post, then soft; Scenario 3 analytics MV consumed (describe only — no it block found, likely empty); Scenario 4 closed-folio 4xx ok |
| APIs touched (top 5) | AP-pos-POST-orders, AP-pos-POST-orders-id-items, AP-pos-POST-orders-id-kot, AP-pos-POST-orders-id-room-charge, AP-frontdesk-POST-folios-id-charges |
| Key screens | SC-dashboard-pos, SC-dashboard-pos-orders, SC-dashboard-pos-kitchen, SC-dashboard-front-desk-folio-id |
| Known blockers | Q4-FINDING-001 (HIGH) — room charge blocked end-to-end: frontdesk CheckinService.checkIn() does not call reservationClient.updateRoomId(...) after check-in; reservation-service still has null/stale roomId, POS validateRoomChargeReservation fails with 403. Fix: add updateRoomId to @hmp/service-clients ReservationServiceClient, add PATCH /api/reservations/:id/room endpoint, call from frontdesk. ST-007-007 is in-progress (not built) and acknowledges the guardrail. Scenario 3 (analytics MV consumed) appears to have no executable it — paper-audit flag. |
| Gap summary | The most important go-live blocker. Happy path fails on 403 — the safeguard is correct but the upstream write is missing. Scenario 3 analytics event assertion is likely empty. |
Flow 8 — Guest Check-out (Invoice generated correctly)
| Field | Value |
|---|---|
| Spec file | flow-8-check-out.spec.ts |
| Registry stories | ST-005-002 (checkout), ST-005-003 (folio + invoice PDF), ST-012-002/003 (report side-effects, indirect) |
| Sub-items tested | (i) Invoice: Scenario 1 settle folio+close ok; Scenario 2 e-invoice generate → job queue → COMPLETED + 64-char IRN + CGST/SGST/IGST > 0 ok; Scenario 3 check-out happy path + CHECKED_OUT sync ok; Scenario 4 blocked on unsettled balance ok; Scenario 5 idempotent e-invoice (same IRN) ok |
| APIs touched (top 5) | AP-frontdesk-POST-folios-id-payments, AP-frontdesk-POST-folios-id-settle, POST /api/einvoice/generate, GET /api/einvoice/jobs/:jobId, AP-frontdesk-POST-check-out-reservationid |
| Key screens | SC-dashboard-front-desk-check-out-id (not in registry listing — possible gap), SC-dashboard-front-desk-departures, SC-dashboard-front-desk-folio-id |
| Known blockers | paymentMode: 'CREDIT_CARD' fix applied in Q4 (was 'CARD', caused Prisma 500). B2B IRN above ₹50,000 threshold is NOT explicitly asserted. SC-dashboard-front-desk-check-out-id referenced by ST-005-002 but not present in the screens registry listing scanned. Invoice PDF download (AP-frontdesk-GET-folios-id-invoice-pdf) is not hit in this spec. |
| Gap summary | One of the strongest-covered flows. Missing: PDF invoice fetch, explicit B2C vs B2B branching at ₹50k threshold, emailed-invoice assertion (compliance requirement per ST-005-002 AC). |
Flow 9 — Night Audit
| Field | Value |
|---|---|
| Spec file | flow-9-night-audit.spec.ts |
| Registry stories | ST-005-004 (night audit, in-progress), ST-005-003 (folio posting), ST-012-005 (day-end + GST analytics) |
| Sub-items tested | (n/a — only one sub-item): S1 pre-audit 4 counters ok, validate warnings ok; S2 dryRun start returns structured report ok; S3 post room charges (describe only — no it, likely empty); S4 advance business date (describe only — likely empty); S5 completion audit-log history ok (smoke); S6 409 on double-start (describe only — likely empty); S7 role gate FRONT_DESK=403 ok; smoke history list ok |
| APIs touched (top 5) | AP-frontdesk-GET-night-audit-propertyid-pre-audit-report, AP-frontdesk-POST-night-audit-propertyid-start, AP-frontdesk-GET-night-audit-propertyid-status, AP-frontdesk-GET-night-audit-propertyid-history, AP-frontdesk-POST-night-audit-id-rollback (not exercised) |
| Key screens | SC-dashboard-night-audit |
| Known blockers | ST-005-004 status is in-progress (tag: note:automated-scheduling-and-rollback-not-fully-implemented). Three describe blocks (S3/S4/S6) appear to have no executable it — the most safety-critical steps (actual charge posting, business-date advance, double-run lock) are not verified end-to-end. Dry-run covers the envelope only. |
| Gap summary | Significant. Spec exercises dry-run + role gate but stops short of validating the real posting, business-date advance, and rollback. The property seed is unlikely to have been designed for this, so real-data assertions have been deferred. High risk for Phase 1 go-live. |
Flow 10 — Reports + Dashboards show correct data
| Field | Value |
|---|---|
| Spec file | flow-10-reports.spec.ts |
| Registry stories | ST-012-001 (KPI widgets), ST-012-002 (arrivals/departures/in-house), ST-012-003 (revenue by source/segment/roomType), ST-012-005 (day-end GST), ST-012-006 (export) |
| Sub-items tested | (n/a — composite): S1 revenue daily (date+revenue+adr+revpar+occupancy+roomNightsSold) ok; S2 monthly ×12 ok; S3 occupancy array ok; S4 guest report (arrivals/departures/inHouse/cancellations/noShows) ok; S5 e-invoice report (irn+invoiceNo+GST fields+status) ok; S6 source-wise rollup ok; S7 room-type revenue ok; S8 ageing buckets 0-30/31-60/61-90/90+ ok; S9 /api/dashboard/today composite ok; S10 tenant isolation 403/empty ok |
| APIs touched (top 5) | AP-analytics-GET-reports-revenue-daily, AP-analytics-GET-reports-revenue-monthly, AP-analytics-GET-analytics-dashboard-today, AP-analytics-GET-analytics-dashboard-metrics, AP-analytics-GET-reports-occupancy |
| Key screens | SC-dashboard-reports, SC-dashboard-reports-category, SC-dashboard-pos-reports, SC-dashboard-chain-reports |
| Known blockers | The spec validates shape, not correctness against seed data. Every story ST-012-001/002/003/005/006 is in-progress (not built). MV hydration depends on EventDispatcherService (Redis Streams) subscribing to 9 topics; if SKIP_EVENT_SUBSCRIPTIONS=true per compose gotcha in CLAUDE.md, the MVs can be empty and the report returns [] which may still pass shape-only assertions. |
| Gap summary | Breadth is good (10 scenarios); depth is weak — no numeric cross-check of a seeded reservation against its report row. Several analytics stories remain in-progress. |
Top 5 cross-flow blockers
- Q4-FINDING-001 (HIGH) — frontdesk does not write
roomIdback to reservation-service after check-in. Blocks the POS → Folio room-charge flow (Flow 7) end-to-end. Fix is mechanical: addupdateRoomIdonReservationServiceClient, publish@hmp/service-clientsbump, addPATCH /api/reservations/:id/room, call fromCheckinService.checkIn. Impact: Flows 6→7→8 (check-in → POS → check-out) all ride on this. - Q4-FINDING-002 (MEDIUM) — gateway routes
PATCH /api/rooms/:id/statusto property-service becauseservices.config.tslongest-prefix fails on/rooms/:id/status. WebSocket HK path works; REST does not. Impact: Flow 5 Sub-flow C and any dashboard UI that calls REST directly. Fix is the two-file rule (services.config.ts+proxy.controller.ts). - ST-005-004 Night Audit is
in-progress. Real posting (S3), business-date advance (S4), and double-run lock (S6) are not asserted in the spec. Impact: Flow 9 — the most operationally-critical batch for a hotel. Scheduled execution and rollback are flagged as not fully implemented. - Analytics stories ST-012-001/002/003/005/006 all
in-progress; spec only asserts shape. Combined with theSKIP_EVENT_SUBSCRIPTIONScompose gotcha, reports can be empty and still pass. Impact: Flow 10 — Phase 1 go-live claim of "reports show correct data" is not defensible without numeric cross-checks. - Drift-checker residue + feature-gap findings (FD-2026-04-23-020..044). Dozens of frontdesk routes (service recovery, petty cash, forex, guest portal, hardware, C-Form, sponsor, bank deposit, refund ledger, in-room, night-audit extras) have no owning story. None individually block a flow, but they represent ~110 unsupervised endpoints shipping to Phase 1. Impact: Flows 4, 6, 8 indirectly — Compliance / Finance users run into unspecified behaviour.
Recommended next actions (ordered by impact)
- Fix Q4-FINDING-001 (roomId back-sync): ship
updateRoomIdmethod + gateway-less internal PATCH on reservation-service +@hmp/service-clientspublish. Unblock Flow 7 hard assertion (removeconsole.warnsoft-skip). - Fix Q4-FINDING-002 (gateway routing for
PATCH /rooms/:id/status): register housekeeping-service pattern route inservices.config.ts+@Allinproxy.controller.ts; verify_RouterExplorer ... Mappedlog line; remove soft-skip from Flow 5 S3. - Complete ST-005-004 Night Audit (or explicitly scope Phase 1 to dry-run only): implement actual S3 posting + S4 business-date advance + S6 double-run lock; add
itblocks to currently-emptydescribeshells in Flow 9. - Harden Flow 10 analytics assertions: seed one reservation per source, run night audit, then assert numeric equality (revenue row total = sum of roomReservation.rateAmount ± GST). Enforce
SKIP_EVENT_SUBSCRIPTIONS=falsefor every non-gateway service in every compose file. - Fill Flow 2 gaps: add
latitude/longitudetoUpdatePropertyDto+ Google Maps pin screen assertion (sub-item i); exercise presigned-URL → S3 PUT →GET /photos→ reorder chain (sub-item ii). - Add Aadhaar-at-rest masking assertion in Flow 6 — fetch the guest/folio after check-in and verify persisted Aadhaar ends in a 4-digit tail with asterisks/mask prefix. DPDP Act 2023 compliance gate.
- Register
POST /api/tenants/signupin the API registry (AP-auth-POST-tenants-signup) and link to ST-001-011 or a new onboarding story. Signup is Phase 1's front-door endpoint and must not remain undocumented. - Implement
GET /api/reservations/:id/allowed-transitions(Flow 4 S3 TODO) and gateway-route the arrivals endpoint used by S2; remove both soft-skips. - Triage Service Recovery + Petty Cash + C-Form (FD-2026-04-23-020/021/025) for Phase 1 acceptance: either create owning stories or mark "deferred to Phase 2" and remove from the user-facing test surface.
- Add B2B IRN ≥ ₹50,000 branching + invoice-PDF fetch + email-invoice assertions to Flow 8. ST-005-002 requires them; the current spec asserts only generic IRN generation.
This is a paper audit. No tests were executed. Findings reflect spec-level coverage and registry cross-references as of 2026-04-23.