initial release from codex

Directory.Build.props

@@ -1 +1,9 @@
-<Project><PropertyGroup><TargetFramework>net10.0</TargetFramework><Nullable>enable</Nullable><ImplicitUsings>enable</ImplicitUsings><TreatWarningsAsErrors>true</TreatWarningsAsErrors></PropertyGroup></Project>
+<Project>
+  <PropertyGroup>
+    <TargetFramework>net10.0</TargetFramework>
+    <Version>0.1.0</Version>
+    <Nullable>enable</Nullable>
+    <ImplicitUsings>enable</ImplicitUsings>
+    <TreatWarningsAsErrors>true</TreatWarningsAsErrors>
+  </PropertyGroup>
+</Project>

MILESTONES.md

@@ -0,0 +1,69 @@
+# 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.
+- **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.
+
+## 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 | Confirm the release-candidate merge/default branch, tag `0.1.0`, build immutable artifacts, record checksums, and document rollback. The Gitea remote and candidate branch are present. |
+| 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
+
+- [ ] Merge or otherwise promote the reviewed release candidate onto the intended release branch.
+- [ ] Tag and archive version `0.1.0` with a reproducible build record and checksums.
+- [ ] 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**.

README.md

@@ -2,6 +2,10 @@
 
 A Linux-hosted hotel email workspace, developed separately from the Windows GuestOps application. **This is the first migration milestone, not a production-complete replacement.**
 
+Current development version: **0.1.0**
+
+Project progress is tracked in the [milestone report](MILESTONES.md). User-visible changes and release limitations are recorded in the [release notes](RELEASE_NOTES.md).
+
 ## Working in this milestone
 
 - Responsive React inbox, message search and status filters, editable saved drafts, approved hotel answers, activity history and hotel settings.

RELEASE_NOTES.md

@@ -0,0 +1,38 @@
+# GuestOps Release Notes
+
+## 0.1.0 — Unreleased
+
+This is the initial development release of GuestOps Web. It is not yet approved for live hotel operations.
+
+### 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:
+
+- 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.
+
+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.
+
+### 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 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.
+
+### 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.