# Build Roadmap

Phase 1 is complete and delivered. This document tracks what's next so
the remaining ~46 spec sections get built in a sane, testable order
rather than all at once.

## Phase 1 — DONE (this delivery)
Architecture, full DB schema, installer, Auth/RBAC (incl. cost-price
rule), Settings/white-label, Room & Room Type management, Reservation/
Front Desk engine with double-booking prevention, guest folio, check-in/
check-out, basic accounting posting, audit log, Royal Gold+Black UI shell.

## Phase 2 — Operations — DONE (this delivery)
- Housekeeping task board (assignment, status flow, automatic room-status sync)
- Maintenance/OPM ticketing (linked to rooms/equipment, priority/status flow,
  optional room-block on creation, resolution workflow with room restore)
- Guest CRM detail pages (search, profile, stay history, documents, blacklist flag)

## Phase 3 — Revenue centers + Inventory — DONE (this delivery)
- Inventory & Purchasing (stock movements, suppliers, POs, goods received
  posting through the shared InventoryService)
- Restaurant POS (menu, table tracking, dine-in/takeaway/room-service,
  room-charge → folio integration)
- Bar POS (same shared controller/service as restaurant, cost-price
  hidden from cashiers via `bar.view_cost_price`)
- Accounting integration: every direct-payment POS sale posts a balanced
  journal entry to the correct revenue account; room-charge sales post to
  accounting later at guest check-out via the existing folio pipeline

## Phase 4 — Additional service modules — DONE (this delivery)
- Swimming Pool (capacity-safe booking), Cinema (seat map with seat-level
  double-booking prevention), Salon/Spa (staff-level time-overlap
  prevention), Laundry, Events (hall overlap check + deposit/balance
  flow), Conference/Meeting rooms (room-level time-overlap prevention) —
  each reuses the Phase 1 booking-engine pattern (lock + re-check inside
  a transaction) and the shared `AncillaryPaymentService` for folio vs.
  direct-payment checkout.
- Cashier shift open/close + reconciliation (expected-vs-counted variance
  computed from actual posted accounting entries).

## Phase 5 — Payments — DONE (this delivery)
- Flutterwave & Paystack server-side integration: real adapters against
  each provider's initialize/verify API contract, plus webhook signature
  verification (not live-tested against the real APIs — this sandbox's
  network egress doesn't reach either provider — but orchestration logic
  was fully verified with dependency-injected fake adapters and real
  HTTP request/response cycles).
- Bank transfer manual confirmation workflow (pending → staff confirms →
  business effects apply, audit-logged).
- Applies uniformly across POS and all six Phase 4 ancillary modules via
  one shared `PaymentGatewayService` + `PaymentCompletionService`.
- Follow-up not yet built: guest self-service payment (currently
  staff-mediated only — `/payments/{reference}` requires a staff login),
  and live smoke-testing against real Flutterwave/Paystack test-mode keys.

## Phase 6 — Public website + guest portal + CMS — DONE (this delivery)
- Public marketing site (Home, Rooms, Gallery, Contact, CMS-driven policy
  pages) served with no login required.
- Public booking engine reusing `Reservation::isRoomAvailable()` /
  `createSafely()` verbatim from Phase 1 — public and staff bookings
  share one code path and can never disagree about availability.
- Guest self-service portal: separate auth system from staff, view
  bookings, self-cancel per policy (before arrival, hold/confirmed only).
  Self-service *rescheduling* is not yet built — noted below.
- CMS for pages/banners/galleries/testimonials, with a real image upload
  handler (extension + decoded-image validation, not just trusting the
  file extension).
- Follow-ups identified but not built this phase: reservation-hold
  auto-expiry (an unpaid public booking currently sits as `hold`
  indefinitely rather than releasing the room after a timeout — the
  `reservation_holds` table already exists in the schema for this and
  just needs a cron + wiring), and guest self-service rescheduling.

## Phase 7 — HR, Reports, Communication, Hardware — DONE (this delivery)
- HR module: departments, positions, employees, attendance, leave
  requests with approval-triggered attendance back-fill, salary/banking
  fields gated server-side (not just view-hidden) behind `hr.view_salary`.
- Full reports & analytics: occupancy/ADR/RevPAR, revenue by
  chart-of-accounts module, POS sales by revenue center, low-stock — all
  with CSV export sharing the exact same calculation as the on-screen view.
- Internal chat (polling-based, no websocket dependency) + a shared
  NotificationService wired into HR (leave requests) and Maintenance
  (ticket assignment), with an unread-count badge in the admin topbar.
- Real mysqldump-based backup/download/delete, with restore deliberately
  left as a documented manual step rather than a risky one-click action.
- Smart-lock adapter framework with a fully-working manual/physical-key
  adapter, wired non-blockingly into check-in/check-out. No real vendor
  hardware adapter — noted honestly rather than faked, since there's no
  hardware/API in this environment to build one against.

This completes the originally-planned seven-phase roadmap. See the
"What's intentionally NOT built yet" section in the README for the
honestly-scoped gaps that remain — PDF export, live gateway smoke-testing,
reservation-hold auto-expiry, guest rescheduling, financial statements,
and non-lock hardware (printers/scanners) are the main ones.