7.2 KiB
7.2 KiB
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
mainand supported by code or automated-test evidence. - Release candidate — implemented on
origin/codex/web-foundationat98628ab, but not yet merged tomainor released. - 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 | Release candidate / acceptance required | Implemented on 98628ab; verify real mailbox threading, reconnect/revocation, duplicate-send prevention, uncertain outcomes, and staff review before pilot use. |
| 3 | OHIP PMS workflow | C | Release candidate / acceptance required | Proposal, approval, and execution controls are on 98628ab. Provider sandbox and contract-level acceptance remain independent requirements. |
| 4 | NMI payment workflow | C | Release candidate / acceptance required | Payment proposal and approval controls are on 98628ab. Sandbox acceptance, reconciliation, expiry, and ambiguous-result recovery remain required. |
| 5 | FAQ automation | B | Release candidate / acceptance required | Draft and approval controls are on 98628ab. Keep live automation disabled until knowledge quality, thresholds, and rollback behaviour pass acceptance. |
| 6 | Team onboarding and account recovery | B | Release candidate / acceptance required | Invitation, password reset, and recovery flows are on 98628ab; verify deployed links, mail delivery, token expiry, and administrator recovery procedures. |
| 7 | Google connection recovery | B | Release candidate / acceptance required | Connection epochs, checkpoint recovery, and revocation handling are on 98628ab; complete real Google acceptance and worker-restart exercises. |
| 8 | Operational readiness tooling | A | Release candidate / acceptance required | Backup, restore, release, and diagnostic tooling is on 98628ab; 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.0tag 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.