GuestOps/MILESTONES.md

GuestOps Milestone Report

Version: 0.1.0
Last updated: 29 September 2026

This is the working delivery tracker for GuestOps Web. Update a milestone when its state changes and link the pull request, release artifact, test run, or acceptance record that proves the change.

Status key

• Implemented — present on main and supported by code or automated-test evidence.
• In progress — repository or environment work has started but an exit condition remains open.
• Acceptance required — implemented in code but still requires a real provider, Debian host, or operational exercise.
• Planned — work is not yet complete.
• Deferred — intentionally outside the current release gate.

Release gates

Gate	Outcome	Current assessment	Exit condition
A	Website operational	Not yet approved	Reproducible release on the target Debian host, persistent data/keys, HTTPS, monitoring, and a successful backup/restore drill.
B	Supervised hotel pilot	Not yet approved	Gate A plus real Google acceptance, staff workflow acceptance, controlled AI/FAQ activation, and closure or explicit containment of pilot usability and security findings.
C	Integrated rollout	Not yet approved	Gate B plus independently accepted PMS and payment integrations, identity/privacy controls, capacity evidence, and formal release approval.

Delivery milestones

#	Milestone	Gate	Status	Evidence and remaining work
1	Web foundation	A	Implemented	The current main branch provides the React workspace, ASP.NET Core API, tenant-scoped MongoDB access, read-only Google import foundation, preview mode, container definitions, and automated tests. Live provider and host acceptance still apply.
2	AI suggestions and reviewed Gmail sending	B	Implemented / acceptance required	Promoted to local main; verify real mailbox threading, reconnect/revocation, duplicate-send prevention, uncertain outcomes, and staff review before pilot use.
3	OHIP PMS workflow	C	Implemented / acceptance required	Proposal, approval, and execution controls are promoted to local main. Provider sandbox and contract-level acceptance remain independent requirements.
4	NMI payment workflow	C	Implemented / acceptance required	Payment proposal and approval controls are promoted to local main. Sandbox acceptance, reconciliation, expiry, and ambiguous-result recovery remain required.
5	FAQ automation	B	Implemented / acceptance required	Draft and approval controls are promoted to local main. Keep live automation disabled until knowledge quality, thresholds, and rollback behaviour pass acceptance.
6	Team onboarding and account recovery	B	Implemented / acceptance required	Invitation, password reset, and recovery flows are promoted to local main; verify deployed links, mail delivery, token expiry, and administrator recovery procedures.
7	Google connection recovery	B	Implemented / acceptance required	Connection epochs, checkpoint recovery, and revocation handling are promoted to local main; complete real Google acceptance and worker-restart exercises.
8	Operational readiness tooling	A	Implemented / acceptance required	Backup, restore, release, and diagnostic tooling is promoted to local main; execute it on the actual Debian host and retain evidence.
9	Gitea and reproducible releases	A	In progress	The reviewed candidate is promoted in the local main history. CI now records the full commit, matched application version, archive checksum and immutable image IDs, and the rollback procedure is documented. Push the merge, retain the successful release evidence off-host, and create a new immutable approval tag; the existing 0.1.0 tag remains attached to the original foundation release.
10	Debian deployment and persistence	A	In progress	Compose uses separate named database and shared key volumes, private host configuration, loopback-only API access and bounded logs. The confirmation-gated persistence drill verifies restart and container-recreation behaviour. Run it on the provisioned Debian host, complete HTTPS and controlled-reboot acceptance, and retain the evidence.
11	Backups, monitoring, and recovery	A	In progress	Encrypted backup and isolated restore tooling now includes opt-in systemd scheduling without command-line secrets. Install and test it on Debian, configure monitored off-host transfer and durable logs, name alert/retention owners, and retain evidence from a timed restore and recovery drill.
12	Google mailbox and reviewed-reply acceptance	B	In progress	The synthetic-data provider runbook, exact scenario set and restricted-record validator are implemented. Complete every scenario against the accepted Debian release and dedicated Google sandbox accounts, independently review the evidence, and retain the validated record.
13	Rezlynx/Guestline adapter	C	Planned	Obtain the provider contract and sandbox, implement the adapter and mapping, and accept idempotency, stale-data, ambiguous-write, and reconciliation paths.
14	Payment links and status	C	Planned	Select/confirm the payment-provider path, complete sandbox and webhook acceptance, and prove expiry, replay protection, reconciliation, and support recovery.
15	Knowledge, AI, and FAQ activation	B	In progress	Owners can run a bounded no-send batch evaluation against current FAQ rules and approved knowledge, with false-positive/negative results and documented zero-error activation thresholds and stop conditions. Curate hotel-specific cases, evaluate AI suggestions separately, train staff, name monitoring/rollback owners, and retain staged-activation evidence.
16	Identity, preferences, and privacy	B/C	In progress	Login throttling now uses the client address only after one-hop processing from the explicitly trusted reverse proxy. Finish privacy/retention decisions, preference coverage, identity acceptance and audit review.
17	Inbox usability and desktop parity	B	In progress	The inbox now uses tenant-scoped stable cursor pagination in pages of 50 and protects unsaved drafts during navigation, conversation selection, filtering and search changes. Inbox, activity, mailbox-health and FAQ-history timestamps use the saved hotel timezone; finish the remaining secondary screens and agreed desktop-parity acceptance.
18	Pilot, capacity, and release approval	B/C	Planned	Run the supervised pilot, exercise support and incident procedures, validate capacity, resolve pilot findings, and capture explicit go/no-go approval for wider rollout.

Delivery sequence

The current critical path is:

9 → 10 → 11 → 12 → 15 → 18

Milestones 13 (Guestline/Rezlynx) and 14 (payments) can progress as parallel provider tracks. They do not need to delay a Google-only supervised pilot, but both remain independently gated before Gate C.

Next actions

• Push the local release-candidate promotion to the intended default branch and retain its successful CI evidence.
• Choose the next semantic version, update both project version files, then create and archive a new immutable approval tag (the existing 0.1.0 tag identifies the foundation release).
• Deploy to the target Debian environment with persistent MongoDB and data-protection keys.
• Run and record backup, restore, restart, monitoring, and rollback exercises.
• Complete real Google mailbox acceptance without using production guest data.
• Resolve or explicitly contain the milestone 16–17 pilot findings listed above.
• Obtain the Guestline/Rezlynx interface contract and sandbox access.
• Agree the payment-provider acceptance and reconciliation plan.
• Capture named owners and target dates for milestones 9–18.

Tracking convention

For every status update, add the owner, target or completion date, and evidence link to the relevant row or to an issue referenced from that row. A milestone is not complete solely because code exists: provider and host acceptance must be recorded wherever the status says Acceptance required.