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

Update milestone tracking after candidate promotion

Browse Source
This commit is contained in:
wolf-demon 2026-09-29 18:16:19 +01:00
parent aba4773cba
commit e843d7f292
2 changed files with 27 additions and 26 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
MILESTONES.md
View File

@ -8,7 +8,6 @@ This is the working delivery tracker for GuestOps Web. Update a milestone when i
## Status key
- **Implemented** — present on `main` and supported by code or automated-test evidence.
- **Release candidate** — implemented on `origin/codex/web-foundation` at `98628ab`, but not yet merged to `main` or 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.
@ -26,13 +25,13 @@ This is the working delivery tracker for GuestOps Web. Update a milestone when i
| # | 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. |
| 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. |

38
RELEASE_NOTES.md
View File

@ -1,38 +1,40 @@
# GuestOps Release Notes
## 0.1.0 — Unreleased
## Next release — Unreleased
This is the initial development release of GuestOps Web. It is not yet approved for live hotel operations.
The reviewed candidate is now promoted into the local `main` history. It is not yet approved for live hotel operations and does not become a release until the merge is pushed, CI evidence is retained and a new immutable semantic-version tag is approved.
### Current `main` baseline
- Responsive shared inbox, search and status filters, saved reply drafts, approved hotel answers, activity history, and hotel settings.
- ASP.NET Core authentication with protected cookies, password hashing, CSRF validation, login throttling, role checks, and server-derived hotel membership.
- Tenant-scoped MongoDB storage with optimistic concurrency, unique mailbox/message indexes, OAuth state expiry, and worker leases.
- Read-only Google OAuth and recent-message import foundation with checkpoint and duplicate protection.
- Preview mode, Linux container definitions, Nginx HTTPS example, and automated backend/frontend verification.
- Live email sending, PMS writes, payment workflows, and automatic FAQ replies remain disabled on `main`.
### Release-candidate scope
The reviewed candidate at `origin/codex/web-foundation` commit `98628ab` extends `0.1.0` with:
### Promoted scope
- AI-assisted reply suggestions and staff-reviewed Gmail sending.
- Approval-controlled OHIP PMS and NMI payment workflows.
- FAQ automation controls, team invitations, password recovery, and stronger Google connection recovery.
- Backup, restore, deployment, and diagnostic tooling.
- Backup, restore, deployment, diagnostic, release-evidence and rollback tooling.
These capabilities are candidate features until the branch is merged, tagged, deployed, and accepted. Google, PMS, and payment-provider acceptance must be completed separately; no live provider calls form part of the local review.
These capabilities still require their separately documented provider, host and operational acceptance. Google, PMS and payment-provider acceptance is not established by local automated tests.
### Known limitations and launch conditions
- Gate A still requires a reproducible release artifact, target-Debian deployment, persistent storage/key validation, monitoring, and a successful restore/rollback exercise.
- Gate A still requires a successful default-branch CI run, durable off-host release archive, target-Debian deployment, persistent storage/key validation, monitoring, and a successful restore/rollback exercise.
- Gate B still requires real Google acceptance and supervised staff testing. Before pilot use, safely paginate beyond the 500-conversation limit, protect drafts across every navigation path, make login throttling proxy-aware, and render dates in the saved hotel timezone—or record and approve explicit operational containment.
- Gate C still requires the Rezlynx/Guestline adapter and independently accepted PMS/payment workflows, plus privacy, identity, capacity, and release approvals.
- FAQ live mode and all external write actions must remain disabled until their corresponding acceptance gate has passed.
See [MILESTONES.md](MILESTONES.md) for the gate assessment, delivery sequence, and remaining work.
## 0.1.0 — 29 September 2026
The `0.1.0` tag identifies the initial GuestOps Web foundation. It is not approved for live hotel operations.
### Foundation scope
- Responsive shared inbox, search and status filters, saved reply drafts, approved hotel answers, activity history, and hotel settings.
- ASP.NET Core authentication with protected cookies, password hashing, CSRF validation, login throttling, role checks, and server-derived hotel membership.
- Tenant-scoped MongoDB storage with optimistic concurrency, unique mailbox/message indexes, OAuth state expiry, and worker leases.
- Read-only Google OAuth and recent-message import foundation with checkpoint and duplicate protection.
- Preview mode, Linux container definitions, Nginx HTTPS example, and automated backend/frontend verification.
- Live email sending, PMS writes, payment workflows, and automatic FAQ replies were disabled in this foundation.
### Versioning
The .NET projects and frontend package share version `0.1.0`. Future entries should follow semantic versioning and move this section from **Unreleased** to a dated release only after the exact commit and artifacts have been approved.
The .NET projects and frontend package currently share version `0.1.0`. Before the next approval tag, choose the next semantic version and update both files together. Move the **Next release** section to that version only after the exact commit, checksummed artifacts and acceptance evidence have been approved.