16 KiB
16 KiB
GuestOps Milestone Report
Version: 0.2.1 release candidate Last updated: 30 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.
Milestones at a glance
This summary explains what each milestone delivers and where it currently stands. The release-gate and delivery tables below contain the detailed evidence and exit conditions.
| # | Milestone | What it delivers | Current position |
|---|---|---|---|
| 1 | Web foundation | The React application, ASP.NET Core API, tenant-isolated MongoDB storage, preview mode, and container foundation. | Implemented. The application foundation and automated tests are on main. |
| 2 | AI suggestions and reviewed Gmail sending | AI-assisted reply drafts and staff-reviewed Gmail delivery with safety and duplicate-send controls. | Implemented; acceptance required. Real Gmail threading, revocation, uncertain-send, and staff-review scenarios still need live evidence. |
| 3 | OHIP PMS workflow | Internal proposal, approval, and execution controls for PMS operations. | Implemented; acceptance required. The workflow exists, but provider-contract and sandbox acceptance remain outstanding. |
| 4 | NMI payment workflow | Internal payment proposal, approval, status, expiry, and reconciliation controls. | Implemented; acceptance required. The workflow exists, but real payment-provider sandbox acceptance remains outstanding. |
| 5 | FAQ automation | Knowledge-based FAQ drafting, test mode, approval controls, and guarded live automation. | Implemented; acceptance required. Live mode remains disabled pending quality, false-positive, monitoring, and rollback acceptance. |
| 6 | Team onboarding and account recovery | Staff invitations, password setup/reset, access disable/restore, and administrator recovery. | Implemented; acceptance required. Deployed link delivery, expiry, recovery, and administrator procedures still need operational evidence. |
| 7 | Google connection recovery | OAuth reconnect, checkpoint recovery, grant revocation handling, and worker restart safety. | Implemented; acceptance required. Dedicated Google-account and worker-restart exercises have not yet been accepted. |
| 8 | Operational readiness tooling | Release verification, diagnostics, encrypted backup, restore, preflight, and persistence tools. | Implemented; acceptance required. The tools must still be run against the exact release on the Debian host. |
| 9 | Gitea and reproducible releases | A checksummed source package, Ansible-controlled installation, recorded image identities, retained artifacts, and approval tagging. | In progress. The runner-free deterministic packager is implemented and the Gitea Action is removed; the release-line identity must be confirmed, then the package, Ansible installation evidence, and approval record must be retained. |
| 10 | Debian deployment and persistence | Secure Debian/Compose deployment, HTTPS, persistent database and key volumes, and reboot/recreation proof. | In progress. The verified Ansible handoff now covers commit-bound installation, boot services, Nginx validation, listener restrictions and public HTTPS; privileged installation, firewall review, controlled reboot and supervised persistence evidence remain open. |
| 11 | Backups, monitoring, and recovery | Scheduled encrypted backups, verified off-host transfer, Zabbix monitoring, restore, and rollback rehearsal. | In progress. The Ansible operations handoff now installs validated systemd units, public-key-only backup support, transfer retry and restricted Zabbix status; secret provisioning, durable-log confirmation, manual backup, timed restore, rollback and independent evidence remain open. |
| 12 | Google mailbox acceptance | End-to-end Gmail consent, import, recovery, reviewed sending, reconciliation, and revocation evidence. | In progress. The runbook, record validator and release-bound Gate B bundle integration exist; the live synthetic-data exercise and independent review remain outstanding. |
| 13 | Rezlynx/Guestline adapter | The real PMS provider adapter, mappings, idempotency, reconciliation, and ambiguous-write handling. | Planned. Provider contract and sandbox access are still required before implementation and acceptance. |
| 14 | Payment links and status | The real payment-provider integration, webhooks, expiry, replay protection, and reconciliation. | Planned. The provider path and sandbox acceptance plan still need to be confirmed and completed. |
| 15 | Knowledge, AI, and FAQ activation | Supervised knowledge-quality, AI-draft, FAQ test-mode, staff-training, and stop-control acceptance. | Implemented; acceptance required. Evaluation tooling and cross-release bundle validation exist; the supervised evaluation, staff training and independent approval remain outstanding. |
| 16 | Identity, preferences, and privacy | Account/session controls, hotel preferences, privacy inventory, retention decisions, and audit review. | Implemented; acceptance required. Legal and operational decisions, identity checks, and independent review remain outstanding. |
| 17 | Inbox usability and desktop parity | Stable pagination, protected unsaved drafts, hotel-timezone display, and desktop workflow parity. | Implemented; acceptance required. Automated checks pass; the supervised desktop exercise and independent approval remain outstanding. |
| 18 | Pilot, capacity, and release approval | Capacity proof, incident exercise, five-business-day hotel pilot, findings closure, and Gate B approval. | In progress. The integrated bundle validator now enforces one archive, release record, image set, environment, capacity report, pilot record and approval decision; live prerequisites, incident rehearsal, five-day pilot and named approvals remain open. |
| 19 | Account security and self-service | TOTP MFA, recovery codes, transactional email, granular roles, preferences, and security notifications. | Implemented on the development branch; acceptance required. Keep it separate until 0.2.1 is approved and tagged, then review, merge, and version it as 0.3.0. |
Status key
- Implemented — present on
mainand 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 | deploy/package_source.py now packages only an explicit committed ref, verifies matched application versions, produces deterministic gzip output and a SHA-256 source record, and refuses overwrite. Hand that package to a version-selected Ansible playbook following the CMS/CMSFront pattern. Ansible must verify and install it, build commit-tagged images, record their immutable IDs, and deploy without a Gitea runner. Retain the package/install evidence off-host and resolve the release-line/tag identity before approval; the existing 0.1.0 tag remains attached to the 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 Ansible handoff verifies the source on both controller and host, enables Docker/Nginx at boot, installs and validates the reviewed proxy, rejects exposed API/MongoDB listeners, and requires trusted public HTTPS before selecting the release. Run it on the provisioned Debian host, review the firewall, complete the confirmation-gated persistence drill and controlled reboot, and retain independent evidence. |
| 11 | Backups, monitoring, and recovery | A | In progress | Encrypted backup and isolated restore tooling includes opt-in systemd scheduling, checksum-verified rsync transfer, restricted Zabbix status, guarded local retention and a release-bound acceptance validator. The Ansible operations playbook now verifies the selected release and private-file modes, imports only the recovery public key, validates and installs the units, enables transfer/monitoring, leaves backup scheduling off until manual acceptance, and fetches non-sensitive evidence. Provision secrets and durable logs, configure central alerts/retention, run the manual backup plus timed restore and rollback drills, and retain independent approval. |
| 12 | Google mailbox and reviewed-reply acceptance | B | In progress | The synthetic-data provider runbook, exact scenario set and restricted-record validator are implemented and wired into the Gate B bundle validator. 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 | Implemented / acceptance required | Owners can run a bounded no-send batch evaluation, and a release-bound acceptance record enforces positive/negative coverage, zero FAQ errors, separate AI review, staff training, stop-control evidence and named monitoring/rollback owners. The integrated Gate B bundle rejects release or environment mismatches. Complete the supervised evaluation and retain independent approval. |
| 16 | Identity, preferences, and privacy | B/C | Implemented / acceptance required | Login throttling trusts the client address only after one-hop processing by the configured proxy. A release-bound review now covers owner-controlled preferences, account/session controls, data inventory, retention/deletion/legal-hold ownership, provider decisions, audit evidence and known identity limitations. Complete the legal/operational decisions and independently approve the record. |
| 17 | Inbox usability and desktop parity | B | Implemented / acceptance required | The inbox uses tenant-scoped stable cursor pagination in pages of 50 and protects unsaved drafts during route/history navigation, reload, conversation selection, filtering and search. Operational timestamps use the saved hotel timezone, and a release-bound desktop-parity acceptance record is implemented. The implementation and preview HTTP suite pass; run the supervised exercise against the approved release and retain independent approval. |
| 18 | Pilot, capacity, and release approval | B/C | In progress | The 0.2.1 Gate B candidate has bounded capacity, five-business-day pilot, incident and final-decision validators plus an integrated bundle check that binds every prerequisite to one release and verifies the retained capacity/pilot checksums. Retain the exact package and Ansible evidence, complete the live Gate A/B exercises, resolve or contain findings, and retain separate hotel-owner and technical approval. Gate C remains dependent on milestones 13 and 14. |
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
- Merge the Action removal and release-process update to the intended default branch; that resulting commit becomes the new package candidate.
- Preserve the published
0.2.0tag unchanged and use the clean0.2.1candidate line frommain, excluding Milestone 19 application code. - Create and checksum the approved source archive with
deploy/package_source.py, add/select it in the GuestOps Ansible playbook, and retain the package and installation evidence. - Create and archive the immutable
0.2.1approval tag only after Gate B approval. - 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.