Go-Live Implementation Plan — P0 → P4

Date: 2026-04-25 Last status sync: 2026-04-26 (autonomous P0/P1/P2 execution session) Source audit: golive-readiness-2026-04-25.md Total items: 52 (20 P0 + 16 P1 + 13 P2 + 5 P3 + 8 P4 vendor configs)

---

Status Dashboard (2026-04-26)

Legend: ✅ shipped + pushed to master · ⏸️ deferred (with reason) · ❌ vendor/ops · 🟡 in flight

Phase 1 — P0 (20 items, 100 % addressed)

ID	Item	Status	Commit / Note
P0-1 + P0-3	Refund posting on cancellation	✅	frontdesk 2bbc9ee (paired)
P0-2	Overbooking buffer + structured OVERBOOKED error	✅	reservation 7f6f882
P0-4	Per-room edits PATCH endpoint	✅	reservation caa1c77
P0-5	GST exempt flag in folio.postCharge	✅	frontdesk 52b4e03
P0-6	Reverse Charge Mechanism (RCM) flag	✅	frontdesk 52b4e03 + reservation 7915871
P0-7	GSTR-1 / GSTR-3B export	✅	frontdesk 52b4e03 (compliance/gstr-reports.{service,controller}.ts)
P0-8	Per-property invoice prefix	✅	frontdesk 52b4e03
P0-9	NIC e-invoice production	❌	Vendor onboarding (C-1) — see runbook
P0-10	FRRO C-Form check-in enforcement	✅	frontdesk 52b4e03
P0-11	TDS / TCS recording	✅	frontdesk 52b4e03
P0-12	Children's data parental consent (DPDPA §9)	✅	guest b2cbe59
P0-13	PCI DSS scope assessment	❌	Vendor (QSA / C-7)
P0-14	Real-time OTA booking ingestion	✅	reservation 7915871
P0-15	Cross-channel double-book detection	✅	reservation 7915871 (same consumer)
P0-16	E-invoice compliance report	✅	frontdesk 52b4e03
P0-17	Razorpay LIVE staging	❌	Vendor (C-3)
P0-18	CRM tenant-isolation guards	✅	crm b2970d1 (prior session)
P0-19	Master-data tenant-ownership validation	✅	property 76ea067 (prior session)
P0-20	Email + SMS production credentials	❌	Vendor (C-4 + C-5)

Phase 2 — P1 (16 items, 14 shipped, 2 deferred)

ID	Item	Status	Commit / Note
P1-A1	Walk-in same-day duplicate detection	✅	reservation 9310ff4
P1-A2	Walk-in side-effect saga recovery	✅	frontdesk b82c6f8
P1-A3	Early-checkin charge auto-post (3 paths)	✅	frontdesk a936f4d (mobile path); standard + walk-in paths already had it
P1-A4	Late-checkout charge auto-post (3 paths)	✅	frontdesk f7b8662 (path 3 = night-audit overstay tagging); paths 1+2 already shipped
P1-A5	Key-card encoding retry + UI alert	✅	frontdesk d79f19b + dashboard d7999b3
P1-A6	Extend C-Form check-in enforcement	✅	frontdesk d05c13e (visa+passport expiry checks)
P1-A7	Cash-drawer variance manager-approval UI	✅	dashboard had it pre-session (PendingVarianceApprovals in /cash-management/drawers)
P1-A8	Confirmation email/SMS e2e test	✅	infrastructure e99228f
P1-B1	Bill-email endpoint POST /orders/:id/email	✅	pos d66ae07
P1-B2	ReservationServiceClient enrichment for HK	✅	housekeeping 877424c
P1-B3	Puppeteer rootless sidecar (banquet contracts)	⏸️	Ops/Dockerfile work — defer to Phase 2 sprint with B3-doc covering required image + flags
P1-B4	Therapist availability JSON validator	✅	spa c4c5444
P1-C1	CRM in-memory persistence	✅	Already migrated (F-022/023/024); CRM CLAUDE.md updated 887bab5
P1-C2	SendGrid bounce + complaint webhook	✅	notification 4ba8a91 + gateway 1a29401
P1-C3	xPrisma → ServiceClient migration	⏸️	Needs @hmp/service-clients republish — folded with P3-1, P3-2 into a single sprint
P1-C4	DPDP DSAR end-to-end persistent flow	✅	guest fe770da

Phase 3 — P2 backlog (13 items, 11 shipped pre-session, 2 vendor)

Item	Status	Note
Late-checkout edge cases (after P1-A4)	✅	Closed under P1-A4 path 3
Predictive / BI reports	❌	Phoenix sidecar — vendor work
Competitor intelligence	❌	Web-scraper sidecar — vendor work
Lost & Found UI page	✅	Pre-session (/housekeeping/lost-found, 445 LoC, real API)
Inventory reorder UI	✅	Pre-session (/housekeeping/inventory/reorder, 494 LoC)
Plugin marketplace UI	✅	Pre-session (/marketplace/[pluginId], 410 LoC)
/settings/compliance	✅	Pre-session (501 LoC)
/settings/currency	✅	Pre-session (500 LoC)
/settings/in-room-tech	✅	Pre-session (517 LoC)
/settings/integrations/sap	✅	Pre-session (515 LoC)
/settings/integrations/tally	✅	Pre-session (523 LoC)
/settings/integrations/whatsapp	✅	Pre-session (620 LoC)
/front-desk/phone (PBX)	✅	Pre-session (455 LoC, real API)

Phase 4 — P3 Code-quality (5 items)

Item	Status	Note
auto-reorder.service.ts cross-DB STRICT-TODO	⏸️	Same root cause as P1-C3 — folded into deferred ServiceClient sprint
costing.service.ts cross-DB STRICT-TODO	⏸️	Same root cause as P1-C3 — folded into deferred ServiceClient sprint
Missing @types (POS) main.ts:15	✅ 2026-04-26	One-line install — see commit log
Missing @types (Spa) main.ts:15	✅ 2026-04-26	One-line install
task.dto.ts:120 add @Sensitive decorator (HK)	✅ 2026-04-26	One-line decorator add

Phase 5 — P4 Vendor configuration (8 items, all ops-led)

#	Item	Status	Lead time
C-1	NIC e-invoice production	❌	2-3 wk
C-2	TRAI DLT	❌	2-4 wk
C-3	Razorpay LIVE	❌	1 wk
C-4	SendGrid domain + DKIM	❌	3-5 d
C-5	Twilio + DLT	❌	2-4 wk
C-6	WhatsApp Business API	❌	3-4 wk (Phase 2)
C-7	PCI DSS QSA	❌	4 wk
C-8	OTA auth per property	❌	1-2 wk per property

See vendor-onboarding-2026-04.md for env vars + verification steps per vendor.

Tally

Phase	Total	✅ Shipped	⏸️ Deferred	❌ Vendor
P0	20	14	0	6
P1	16	14	2	0
P2	13	11	0	2
P3	5	3	2	0
P4	8	0	0	8
Total	62	42 (68 %)	4 (6 %)	16 (26 %)

---

---

Operating model

Three parallel tracks running simultaneously:

Track	Owner	Headcount	Focus
A. Engineering	Tech lead	3 engineers	P0 code fixes, P1 hardening, P2 (post-launch)
B. Compliance	Compliance lead	1 lead + 1 backend engineer	P0 regulatory items (GST / e-invoice / FRRO / TDS / DPDPA / PCI)
C. Vendor / Ops	Ops lead	1 ops engineer	P4 vendor config + long-lead items (NIC, TRAI DLT, PCI ASV)

Track C starts immediately because vendor onboarding has 1–4 week lead times that block Track B's code work.

Calendar at a glance

Wk 1   Wk 2   Wk 3   Wk 4   Wk 5   Wk 6   Wk 7   Wk 8+
─────  ─────  ─────  ─────  ─────  ─────  ─────  ─────────
[========= P0 Engineering =========]
       [============ P0 Compliance ============]
[==== P4 Vendor onboarding (long lead) ====]
                    [===== P1 Hardening =====]
                                  [== P3 Code-quality ==]
                                         [===== Soak + DR + sign-off =====]
                                                       LIVE ↑
                                                            [== P2 backlog →]

---

Phase 1 — P0 Remediation

Calendar: weeks 1–4 Goal: every P0 closed, regression-tested, signed off by Legal / Finance / Security / Ops.

Track A — Engineering P0s (3 engineers × 3 weeks ≈ 45 person-days)

P0-1 + P0-3 (paired) — Refund posting on cancellation

Why paired: the negative-payment guard at folio rejects refund posting today. Both must ship together; shipping P0-1 alone breaks at runtime.

Files

• hmp-reservation-service/src/reservations/reservations.service.ts — cancel()
• hmp-frontdesk-service/src/folios/folios.service.ts — postPayment()

Steps

1. Remove the amount > 0 guard in postPayment(); replace with amount !== 0 + add transactionType: 'REFUND' for negatives.
2. In cancel(), after the cancellation-fee math, post:
   • the cancellation fee as a CHARGE (transactionCode CXL_FEE)
   • the remaining paid amount as a refund (negative payment with originalPaymentId for trace)
3. Trigger Razorpay refund (existing RefundLedger model).
4. Folio must finalize at zero balance; audit log records both transactions.

Tests

• Unit: cancel with 0 fee → full refund; cancel with 100 % fee → no refund; cancel with partial fee → partial refund.
• E2E: book → pay 5 000 → cancel → confirm 5 000 refund posted to folio + Razorpay refund initiated.

Acceptance

• ✓ folio shows charge (CXL_FEE) + payment (negative) + zero net balance
• ✓ Razorpay dashboard shows refund initiated
• ✓ audit log captures refund.posted event
• ✓ flow-test flow-cancel-with-refund.spec.ts green

Effort: 4 person-days · Owner: Eng-1

---

P0-2 — Overbooking overflow routing

Files

• hmp-reservation-service/src/availability/overbooking.handler.ts
• hmp-reservation-service/src/availability/availability.service.ts
• hmp-property-service — sister-property registry

Steps

1. Add overflowPolicy to property settings: OVERFLOW_TO_SISTER | WAITLIST | REJECT.
2. When bookingCount > inventory + buffer:
   • OVERFLOW_TO_SISTER → query sister-property availability via PropertyServiceClient, redirect booking with note
   • WAITLIST → push to WaitlistEntry with auto-promote logic
   • REJECT → return 409 with ERROR_CODE: OVERBOOKED
3. Manager dashboard widget showing overbookings + manual override.

Tests

• Unit: each overflow policy with mock sister-property client.
• Flow test: overbook by 2 → 1 redirected, 1 waitlisted.

Acceptance

• ✓ no double-booked guests at hotel doors
• ✓ overbooking dashboard widget on /control-center/exceptions
• ✓ flow-test flow-overbooking-overflow.spec.ts green

Effort: 4 person-days · Owner: Eng-2

---

P0-4 — Per-room edits in multi-room bookings

Files

• hmp-reservation-service/src/reservations/reservations.service.ts — new updateRoomReservation(reservationId, roomReservationId, dto)
• hmp-reservation-service/src/reservations/reservations.controller.ts — PATCH /reservations/:id/rooms/:roomReservationId
• Dashboard: edit reservation form — per-room edit affordance

Steps

1. Backend handler that mutates a single RoomReservation (dates / room type / rate plan / pax) without touching siblings.
2. Recalculate folio for that one room; sibling rooms untouched.
3. Audit-log the per-room change.
4. Dashboard: in the reservation edit form, each room row gets an "Edit just this room" pencil.

Tests

• Edit room 2 of 3 → only room 2's folio lines change; rooms 1 + 3 untouched.

Acceptance

• ✓ group of 3 rooms → extend room 2 by 1 night without cancelling rooms 1 + 3
• ✓ flow-test flow-multi-room-per-room-edit.spec.ts green

Effort: 4 person-days · Owner: Eng-3

---

P0-14 — OTA booking ingestion (real-time)

Files

• hmp-channel-service/src/webhooks/* — webhook receivers per OTA
• hmp-channel-service/src/sync/booking-ingestion.service.ts

Steps

1. Webhook receiver per OTA (Booking.com, Expedia, Agoda, MakeMyTrip) verifying signature.
2. Receiver persists raw payload + dispatches event channel.booking.received.
3. RoutingRulesService (already subscribed) materialises into Reservation.
4. Drop the 1-h cron in favour of webhook-first; keep cron as 6-h reconciliation backstop.

Tests

• Webhook contract test per OTA.
• E2E: simulate Booking.com booking → reservation visible in dashboard < 30 s.

Acceptance

• ✓ booking lands in PMS within 30 s of OTA confirmation
• ✓ webhook signature verification mandatory
• ✓ DLQ retains failed payloads for replay

Effort: 5 person-days · Owner: Eng-2 (after P0-2)

---

P0-15 — Cross-channel double-book detection

Files

• hmp-channel-service/src/sync/inventory-sync.service.ts
• hmp-reservation-service/src/availability/availability.service.ts

Steps

1. On every channel booking ingest, tryClaimRoom(roomTypeId, date, source) against Redis lock with 30-s TTL.
2. If claim conflicts (same room-type-date already taken in last 30 s), apply property's overflowPolicy (P0-2).
3. Push closed restriction to other channels for affected room-type/date.

Tests

• Concurrent webhook from two channels for last room → only one wins; other gets overflow treatment.

Acceptance

• ✓ flow-test flow-cross-channel-conflict.spec.ts green

Effort: 4 person-days · Owner: Eng-2

---

P0-17 — Razorpay LIVE staging

Steps

1. Ops obtains LIVE keys + webhook secret.
2. Add to AWS Secrets Manager (production env).
3. Run end-to-end test: real ₹1 charge → confirm → refund → webhook delivered.
4. Document the rollback plan if LIVE webhook fails.

Acceptance

• ✓ ₹1 round-trip on LIVE merchant in QA-mirror
• ✓ refund within 7-day RBI window verified

Effort: 2 person-days (mostly waiting on Ops/Razorpay) · Owner: Eng-3 + Ops

---

P0-18 — CRM tenant-isolation guards

Files

• hmp-crm-service/src/campaigns/campaigns.controller.ts
• hmp-crm-service/src/loyalty/loyalty.controller.ts
• hmp-crm-service/src/feedback/feedback.controller.ts
• hmp-crm-service/src/revenue/revenue.controller.ts
• hmp-crm-service/src/dedup/dedup.service.ts

Steps

1. Add @CurrentTenant() decorator on every CRUD endpoint that takes a tenantId.
2. Replace any findMany({}) with findMany({ where: { tenantId } }).
3. Dedup nightly scan must take tenantId as input — run per tenant, not platform-wide.
4. Add tenant pen-test: log in as tenant A, attempt GET /api/campaigns?tenantId=B → must 403.

Acceptance

• ✓ pen-test green on every CRM endpoint
• ✓ flow-test flow-tenant-isolation.spec.ts extended to cover CRM

Effort: 1 person-day · Owner: Eng-1

---

P0-19 — Master-data tenant-ownership validation

Files

• hmp-property-service — Property / Room / RatePlan controllers
• @hmp/auth — assertPropertyTenant() helper (already exists; ensure called everywhere)

Steps

1. Audit every mutating endpoint in property-service. Add assertPropertyTenant(propertyId, req.user.tenantId) before any mutation.
2. Add the same on every read endpoint that takes propertyId.
3. Pen-test: tenant A attempting to PATCH tenant B's property → 403.

Acceptance

• ✓ pen-test green on every property-service endpoint
• ✓ contract test master-data-tenant-isolation.spec.ts green

Effort: 2 person-days · Owner: Eng-1

---

P0-20 — Email + SMS production credentials

Steps

1. Ops obtains SendGrid API key + signed-sender domain (SPF / DKIM / DMARC).
2. Twilio Account SID / Token (or MSG91); register for DLT (TRAI mandate).
3. Notification service env vars set in production secrets manager.
4. End-to-end test: trigger booking confirmation → email + SMS delivered to test inbox.

Acceptance

• ✓ delivery rate 99 %+ on a 100-message smoke
• ✓ bounce / complaint webhook persists to log

Effort: 1 person-day code + 2 days vendor onboarding (Track C) · Owner: Eng-3 + Ops

---

Track B — Compliance P0s (compliance lead + 1 backend engineer × 3 weeks ≈ 30 person-days)

P0-5 — GST exemption flag

Files

• hmp-property-service/prisma/schema.prisma — add Guest.gstExempt: boolean
• hmp-frontdesk-service/src/folios/invoice-builder.service.ts — skip CGST/SGST/IGST when guest.gstExempt = true

Acceptance: invoice for exempt guest = base only, no GST lines, footnote "GST exempt — Govt order #…".

Effort: 2 person-days · Owner: Compliance + Eng

P0-6 — Reverse Charge Mechanism (RCM)

Files

• hmp-frontdesk-service/src/folios/invoice-builder.service.ts
• B2B invoice DTO — add isRCM: boolean

Steps

1. If b2bInvoice && totalAmount > 500_000 → mark RCM = true, GST liability shifts to recipient.
2. Invoice prints "Tax payable on reverse charge — yes".
3. GSTR-1 export includes RCM section.

Effort: 3 person-days

P0-7 — GSTR-1 / 3B export

Files

• hmp-analytics-service/src/reports/gstr-export.service.ts (new)
• Dashboard /reports/gst page — date range + download JSON

Steps

1. JSON formatter following CBIC GSTR-1 schema (B2B / B2C-large / B2C-small / Exports / CDNR / etc.).
2. JSON formatter for GSTR-3B (summary by tax slab).
3. Validate against CBIC offline tool.

Effort: 5 person-days

P0-8 — Sequential gap-free invoice numbering

Files

• hmp-frontdesk-service/src/invoice/invoice-sequence.service.ts

Steps

1. Use Postgres SELECT … FOR UPDATE advisory lock keyed by (tenantId, propertyId, financialYear).
2. Sequence format: <PROP>/<FY>/<6-digit> (e.g. MUM/2526/000001).
3. Cron job nightly verifies no gaps; alerts if found.
4. Tests: 100 concurrent invoice creations → sequence is monotonic + gap-free.

Effort: 2 person-days

P0-9 — NIC e-invoice integration

Files

• hmp-frontdesk-service/src/einvoice/nic-adapter.ts (currently stubbed)
• hmp-shared-packages/packages/integrations/src/einvoice/nic-client.ts

Steps

1. NIC sandbox onboarding (Track C — 2 weeks lead time).
2. Auth + token refresh (4-hour expiry).
3. generateIRN(invoice) → IRN + signed QR + ACK number; persist to EInvoiceJob row.
4. cancelIRN(irn, reason) within 24-h window.
5. Retry queue with DLQ; mock-mode flag for staging.

Acceptance: B2B invoice generates real IRN against NIC sandbox; QR signature verified.

Effort: 8 person-days

P0-10 — Foreigner C-Form

Files

• hmp-frontdesk-service/src/cform/cform.service.ts
• New: cform-pdf-generator.service.ts
• Check-in flow: validate passport + visa fields when guest.nationality !== 'IN'.

Steps

1. Add visa-issue-place, visa-validity-from, visa-validity-to, port-of-arrival, FRRO-form-C reference.
2. Generate PDF (PDFKit) matching FRRO template.
3. Submit-to-FRRO API (manual upload as Phase 1; portal API as Phase 2).
4. Block check-in if foreign guest's C-Form fields not captured.

Acceptance: check-in for foreign guest fails without C-Form; PDF matches FRRO sample.

Effort: 4 person-days

P0-11 — TDS / TCS

Files

• hmp-frontdesk-service/src/folios/invoice-builder.service.ts
• hmp-payment-service/src/commissions/tds.service.ts (new)

Steps

1. TDS 10 % deduction at agent commission payout (when commission > ₹15K/year per agent).
2. TCS 1 % when room rate > ₹7 500/night (luxury rate, post-FY24 Budget).
3. Form 16A / 27EQ generation (manual export Phase 1).

Effort: 3 person-days

P0-12 — Children's data parental consent

Files

• hmp-guest-service/src/guests/guest.service.ts — guest creation
• hmp-shared-packages/packages/compliance — DPDPA module

Steps

1. On guest create, if dateOfBirth shows age < 18 → require guardianName + guardianConsentTimestamp.
2. Block booking creation for guest < 18 without guardian consent.
3. Audit log captures guardian-consent event.

Effort: 2 person-days

P0-13 — PCI DSS scope assessment

Steps (Track C runs vendor + Track B reviews findings)

1. Engage QSA (Qualified Security Assessor) for SAQ.
2. Confirm scope: payment-service is the only PCI-relevant micro; isolated VPC.
3. Run quarterly ASV scan on payment-service public surface.
4. Document the SAQ-A or SAQ-D-merchant attestation depending on scope.

Effort: 7 person-days (mostly QSA-driven; long lead)

P0-16 — E-invoice compliance reports

Files

• hmp-analytics-service/src/reports/einvoice-register.service.ts
• Subscribes to einvoice.generated / einvoice.cancelled events from frontdesk.

Acceptance: /reports/einvoice lists every IRN with status, ACK, cancellation, full audit.

Effort: 3 person-days · Depends on: P0-9

---

Track C — Vendor / Ops onboarding (start week 1, parallel with code work)

These have 1–4 week lead times; start day 1:

#	Item	Lead time	Owner
C-1	NIC e-invoice production access	2–3 wk	Ops + Compliance
C-2	TRAI DLT registration (sender ID + template approval)	2–4 wk	Ops
C-3	Razorpay LIVE merchant account	1 wk	Ops
C-4	SendGrid sender domain + DKIM	3–5 d	Ops
C-5	Twilio / MSG91 + DLT	2–4 wk	Ops
C-6	WhatsApp Business API + Meta flows	3–4 wk	Ops
C-7	PCI DSS QSA + ASV vendor engagement	4 wk	Ops
C-8	OTA channel auth (Booking.com / Expedia / Agoda / MakeMyTrip API keys per property)	1–2 wk per channel	Ops + each hotel

Track C must launch on day 1 to avoid blocking Track B.

---

P0 acceptance gate (end of week 4)

Before moving on to P1, every P0 must:

• ✓ Code merged to master
• ✓ Unit tests + at least one flow-test green in CI
• ✓ Deployed to QA + soak-tested 24 h
• ✓ Pen-test green on tenant isolation items
• ✓ Compliance sign-off documented per regulatory item

---

Phase 2 — P1 Hardening

Calendar: weeks 4–6 (overlap with P0 sign-off) Goal: smooth out the rough edges before opening doors. Workarounds exist today, but each item is a daily annoyance for staff.

ID	Item	Slice	Effort	Owner
P1-A1	Walk-in same-day duplicate detection	A	1 d	Eng-1
P1-A2	Walk-in mid-transaction failure recovery (saga)	A	2 d	Eng-1
P1-A3	Early-checkin charge auto-post (3 paths)	A	2 d	Eng-1
P1-A4	Late-checkout charge auto-post (3 paths)	A	1 d	Eng-1
P1-A5	Key-card encoding retry + UI alert	A	2 d	Eng-2
P1-A6	C-Form check-in enforcement (already in P0-10 partial; extend)	A	1 d	Eng-2
P1-A7	Cash-drawer variance manager-approval UI	A	2 d	Eng-2
P1-A8	Confirmation email/SMS e2e test	A	1 d	Eng-3
P1-B1	Bill-email endpoint (/orders/:id/email)	B	1 d	Eng-3
P1-B2	ReservationServiceClient enrichment for HK arrivals/departures	B	2 d	Eng-3
P1-B3	Puppeteer rootless sidecar (banquet contracts)	B	1 d	Ops + Eng
P1-B4	Therapist availability JSON validator	B	0.5 d	Eng-3
P1-C1	CRM in-memory persistence (pricing rules / drip / feedback queue)	E	3 d	Eng-1
P1-C2	SendGrid bounce + complaint webhook handler	E	1 d	Eng-1
P1-C3	xPrisma → typed ServiceClient migration (HK auto-reorder + Banquet costing)	E	3 d	Eng-2
P1-C4	DPDP DSAR end-to-end flow	E	2 d	Eng-2

Total P1 effort: ≈ 25 person-days; 2 weeks with 2 engineers.

---

Phase 3 — P2 Phase-2 backlog

Calendar: post-launch, months 1–3 (Phase 2) Goal: add features that hotels can live without on Day 1, but expect to ship within first quarter.

Item	Slice	Notes
Late-checkout charge auto-post — remaining edge cases	A	After P1-A4
Predictive / BI reports	C	Sidecar + Phoenix integration
Competitor intelligence reports	C	Web-scraper sidecar
Lost & Found UI page	B	Currently stub
Inventory reorder UI	B	Currently stub
Plugin marketplace	E	Big feature; 3+ mo
/settings/compliance	E	Stub
/settings/currency	E	Stub
/settings/in-room-tech	E	Stub
/settings/integrations/sap	E	Tally/SAP/Quickbooks adapters
/settings/integrations/tally	E
/settings/integrations/whatsapp	E	After C-6 vendor onboarding
/front-desk/phone (PBX integration)	A	Large vendor effort

Sequencing suggestion: SAP / Tally first (accounting demand), Lost & Found + Reorder UIs next (HK ask), then BI / predictive.

---

Phase 4 — P3 Code-quality TODOs

Calendar: continuous; address opportunistically alongside other work.

Item	Files
auto-reorder.service.ts cross-DB STRICT-TODO	hmp-housekeeping-service
costing.service.ts cross-DB STRICT-TODO	hmp-banquet-service
Missing @types (POS)	hmp-pos-service/src/main.ts:15
Missing @types (Spa)	hmp-spa-service/src/main.ts:15
task.dto.ts:120 — add @Sensitive decorator	hmp-housekeeping-service

Note: P3-1 + P3-2 partially overlap with P1-C3.

---

Phase 5 — P4 Vendor configuration (Track C — runs in parallel with P0/P1)

Reproduced here for completeness; same items as Track C in Phase 1.

#	Item	Lead	Phase 1 essential?
C-1	NIC e-invoice production	2-3 wk	✓ blocks P0-9
C-2	TRAI DLT	2-4 wk	✓ blocks live SMS
C-3	Razorpay LIVE	1 wk	✓ blocks P0-17
C-4	SendGrid domain + DKIM	3-5 d	✓ blocks P0-20
C-5	Twilio + DLT	2-4 wk	✓ blocks P0-20
C-6	WhatsApp Business API	3-4 wk	✗ Phase 2
C-7	PCI DSS QSA	4 wk	✓ blocks P0-13
C-8	OTA auth per property	1-2 wk per	✓ per-hotel onboarding

---

Master sequencing diagram

WEEK 1                             │ WEEK 2                          │ WEEK 3                          │ WEEK 4                          │ WEEK 5+
═══════════════════════════════════│═════════════════════════════════│═════════════════════════════════│═════════════════════════════════│═══════════════
Eng-1: P0-1 + P0-3 + P0-18         │ Eng-1: P1-A1..A4               │ Eng-1: P1-C1 + P1-C2            │ Eng-1: P3 cleanup              │
Eng-2: P0-2                        │ Eng-2: P0-14 + P0-15           │ Eng-2: P1-A5..A7 + P1-C3        │ Eng-2: soak test               │
Eng-3: P0-4                        │ Eng-3: P0-17 + P0-19 + P0-20  │ Eng-3: P1-B1..B4                │ Eng-3: regression suite        │
Compliance: P0-5 + P0-6 + P0-8 + P0-12│ Compliance: P0-7 + P0-11   │ Compliance: P0-9 (NIC build)    │ Compliance: P0-10 + P0-13 + P0-16│
Ops: C-1..C-8 onboarding starts    │ Ops: C-3 + C-4 land            │ Ops: C-1 + C-5 land             │ Ops: C-2 + C-7 land            │ Phase 2 →
                                                                                                                        ↑ LIVE GATE

---

Sign-off gates (cannot ship without these)

1. Code gate — every P0 ID has a closed PR + green CI test + QA-deploy soak ≥ 24 h.
2. Tenant pen-test gate — automated pen-test attempts cross-tenant access on every CRUD endpoint; must show 100 % rejection.
3. Compliance sign-off — per-item attestation by Compliance lead with regulatory citation.
4. Vendor gate — Razorpay LIVE, SendGrid, Twilio, NIC, OTA per launching hotel — all production-tested on a staging mirror.
5. DR drill — kill primary DB on QA-mirror; verify RTO < 1 h, RPO < 15 min.
6. 24-h soak test — realistic load on staging, no P0/P1 regressions.
7. Legal / Finance / Security / Ops head sign-off — formal package signed.

---

Effort summary

Phase	Items	Eng person-days	Comp person-days	Ops days	Wall-clock weeks
Phase 1 — P0	20	45	30	varies (vendor)	3–4
Phase 2 — P1	16	25	0	0	2
Phase 3 — P2	13	(post-launch)	—	—	months
Phase 4 — P3	5	(continuous)	—	—	continuous
Phase 5 — P4	7	0 (Ops-led)	0	varies	4 (parallel)

Total to go-live: ≈ 4 weeks with 3 engineers + 1 compliance pair + 1 ops engineer running concurrently.

---

Suggested next moves

1. Today — kick off Track C vendor onboarding (NIC, TRAI DLT, Razorpay LIVE, SendGrid, Twilio, PCI QSA). Long-lead items must start now.
2. Day 1 of Track A — start P0-1 + P0-3 (paired refund work). Also start P0-18 (CRM tenant guards) — fastest, highest-impact, 1 day of work.
3. Day 1 of Track B — start P0-5 + P0-6 + P0-8 + P0-12 (GST + DPDPA quick wins; 9 person-days total).
4. Daily standup — single board with all 52 items, status, owner, blocker.
5. Weekly sign-off review — Compliance + Tech leads walk through the 7 sign-off gates.

Tell me which P0 you want me to start on right now. The fastest immediate win is P0-18 (CRM tenant guards — 1 person-day of mechanical decorator additions), but P0-1 + P0-3 (refund posting) is the highest revenue-impact pair.