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.
- **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 | Planned | Provision the target host, HTTPS and reverse proxy; persist MongoDB, data-protection keys, logs, and configuration; then verify restart and upgrade behaviour. |
| 11 | Backups, monitoring, and recovery | A | Planned | Schedule backups, define alerts and ownership, prove off-host retention, and perform a timed restore and recovery drill. |
| 12 | Google mailbox and reviewed-reply acceptance | B | Planned | Complete OAuth verification, import/send acceptance, reconnect/revocation tests, identity-change handling, and duplicate/uncertain-send drills with a sandbox mailbox. |
| 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 | Planned | Curate approved hotel knowledge, evaluate suggestion quality, set thresholds, train staff, and stage activation with monitoring and a kill switch. |
| 16 | Identity, preferences, and privacy | B/C | Planned | Finish operational identity controls, privacy/retention decisions, hotel preferences, audit review, and proxy-aware login rate limiting. |
| 17 | Inbox usability and desktop parity | B | Planned | Add safe pagination beyond 500 conversations, protect unsaved drafts across all navigation/filter/search paths, honour hotel timezones, and close agreed desktop-parity gaps. |
| 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**.