futuresens/GuestOps
6
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
GuestOps/docs/migration.md

6.8 KiB
Raw Blame History

Migration status

Source: wolf-demon/GuestOps, hardened desktop commit 18b983bf402ecdded6430fd40bc4d3320587595a on codex/audit-safety-fixes. The desktop repository is unchanged by this web migration.

Milestone 1: inbox and persistence

The existing Windows business model, booking preflight checks, body cleaner, extraction parser and secret redactor are copied into GuestOps.Core, which targets .NET 10 without WinForms. They retain the original namespaces to make later adapter migration reviewable.

GuestOps.Api owns the web endpoints and MongoDB infrastructure. GuestOps.Worker currently references this project to share the storage/Google adapter without duplicating it. A later separation into an Infrastructure project can occur when PMS adapters are ported; it is not necessary for the present read-only worker.

Local JSON stores and process mutexes are not reused in production. MongoDB enforces uniqueness for message import and mailbox ownership; version predicates prevent lost updates. Every application data read/update takes a server-derived hotel ID. Only login lookup and the trusted worker perform narrowly defined global queries.

The UI is an operational inbox rather than a port of the desktop booking grid. Real installations start empty. The sample hotel exists only in explicitly enabled Development preview mode. The preview banner remains visible at compact widths.

Authentication uses ASP.NET cookie protection and its password hasher. Sessions expire after eight hours and validate the user's active status and role on each request. Owner provisioning remains an administrator CLI operation. Milestone 6 adds owner-issued staff invitations and assisted account recovery; transactional email recovery remains future work.

Gmail permissions are read-only. The worker fetches plain-text bodies and skips automated/list/bounce messages. It does not fetch attachments, mark messages read, delete them, send mail, or call a PMS. Initial import is seven days, 25 messages per worker cycle. Unfinished pages retain their checkpoint, and overlap between synchronization windows is deduplicated. Milestone 7 adds guarded checkpoint restart and connection recovery; full history repair remains future work.

Milestone 2: AI drafts and staff-approved delivery

Implemented optional OpenAI draft generation, validated hotel answer references, per-hotel owner controls, staff-approved Gmail sending, immutable MongoDB approval snapshots, worker claims and uncertain-delivery verification. Live provider acceptance remains pending. See reply setup and recovery. Automatic sending remains disabled. The read-only description above describes milestone 1 defaults; sending now requires explicit additional configuration and consent.

Milestone 3: reviewed OHIP reservation updates

Implemented exact confirmation lookup, internal notes and owner-approved stay-date changes, with tenant-specific server credentials, MongoDB proposals, duplicate approval prevention, stale-booking checks and read-only recovery of uncertain results. Live OHIP sandbox acceptance is pending; writes remain off by default. See PMS setup and limitations.

Milestone 4: NMI hosted invoices and reconciliation

Implemented owner-reviewed invoice creation, unique payment references, customer-email approval, tenant-specific merchant configuration, partial/paid invoice status and read-only recovery after lost responses. The hosted payment link is delivered by NMI's invoice email; the published API does not guarantee a URL for insertion into GuestOps replies. Live sandbox acceptance remains pending. See payment setup and limits.

Milestone 5: controlled FAQ auto-replies

Implemented seven exact FAQ question rules, approved-answer version binding, test/live modes, durable daily quotas, Gmail thread rechecks and staff handover for rejected automatic replies. Plain-text messages only; broad natural-language matching is not claimed. Live Gmail and rule acceptance remains pending. See automation setup and limits.

Milestone 6: team accounts and hotel onboarding

Implemented owner-issued single-use invitation and recovery links, staff disable/restore controls, session invalidation after password changes, server-admin owner recovery and a setup checklist derived from saved hotel state. Links are copied and shared privately; GuestOps does not send recovery emails. See account setup and limits.

Milestone 7: Google mailbox lifecycle and recovery

Implemented owner-only disconnect/reconnect and import restart controls, synchronization health, revoked-access recovery, retry delays, page recovery and connection-bound reply approvals. Local disconnect removes saved credentials; provider grant revocation is a separate Google account action. See mailbox operation and acceptance.

Milestone 8: operational readiness

Implemented owner-only workspace health, database readiness, worker heartbeat, Linux deployment preflight, maintenance-window encrypted database/key/configuration backup and an isolated restore drill. The drill verifies collection counts, indexes and actual key decryption. Scheduling, off-server copies and production disaster cutover remain operator tasks; the Debian server rehearsal is still required. See operations and recovery.

Remaining milestones

  1. Run dedicated Google test-mailbox acceptance, add full thread aggregation and history repair, and rehearse server backup/restore before the first hotel pilot.
  2. Add verified transactional email for invitations and recovery notifications, MFA, granular roles and user preferences.
  3. Run a representative live AI draft evaluation, improve retrieval and evidence presentation, and approve the selected provider data-processing arrangements.
  4. Extend the implemented durable reply queue with operator recovery tooling and broaden the controlled FAQ rules only after live acceptance. Preserve the rule that uncertain sends are never blindly replayed.
  5. Validate the OHIP adapter against the property sandbox, extend supported PMS operations and validate NMI hosted invoices with the merchant sandbox. Add direct payment URLs only when a supported provider contract is available. Do not enable these by merely copying desktop settings or toggling a feature flag.

Windows DPAPI settings must not be copied to Linux as usable credentials. Re-enter provider credentials through the server setup and reauthorize each mailbox. No existing hotel data has been transferred.

Capacity and operations

Target supplied by the owner: Debian 12, 4 CPU cores, 7.6 GiB RAM, 18 GiB free disk; MongoDB on the same machine. Compose includes conservative starting memory limits and capped logs, not a capacity guarantee. Keep database/key backups off-server and do not import entire mailboxes by default. Establish retention and restore testing before real guest data is used.