5.4 KiB
Google mailbox acceptance
This runbook records real provider acceptance for one dedicated sandbox mailbox using synthetic messages only. It does not enable a production mailbox, FAQ automation, PMS writes or payment creation. Run it only after the exact release artifact has passed the Debian preflight and persistence drill.
Keep screenshots, Gmail message source, provider console records and request diagnostics in the restricted acceptance store. Do not commit mailbox addresses, authorization codes, refresh/access tokens, guest data, cookies, raw OAuth callbacks or raw evidence. The repository record contains only opaque evidence references.
Preparation and stop conditions
Record the release commit, release-record SHA-256, image IDs, environment, operator, approver and maintenance window. Use two dedicated Google test accounts so the different-account rejection can be exercised without a personal account. Send only clearly synthetic messages between controlled recipients.
Start with AI drafts, staff sending, FAQ live mode, PMS writes and payment creation disabled. Confirm the OAuth redirect URI exactly matches the HTTPS sandbox. Stop immediately if a mailbox appears under the wrong hotel, a recipient differs from the review screen, an unapproved message is sent, a duplicate is observed, provider output exposes credentials, or an uncertain outcome is about to be blindly retried. Preserve evidence and follow the incident process.
Required scenarios
| Record ID | Exercise | Passing evidence |
|---|---|---|
oauth-readonly |
Connect sandbox mailbox A with sending disabled; inspect consent and saved health. | Only the expected read scope is granted, callback succeeds over HTTPS, mailbox identity is correct, and no credential appears in UI/log evidence. |
initial-import |
Send several synthetic plain-text inbox messages before and during the seven-day window, including an automated/list message. | Eligible messages import with correct sender, subject and reply identity; excluded automated mail and out-of-window mail do not appear. |
duplicate-import |
Restart the import pass twice and restart the worker during a paginated pass. | Each provider message appears once and the pass resumes without losing its window. |
same-account-reconnect |
Disconnect locally, reconnect mailbox A and inspect retained conversations/drafts. | Mailbox identity is retained, connection identity rotates, history remains, and synchronization resumes without duplicates. |
different-account-rejected |
Start reconnect for mailbox A but choose sandbox mailbox B. | The reconnect is rejected and mailbox A remains disconnected without B being attached to the hotel. |
provider-revocation |
Remove the app grant in Google's account controls, allow the worker to observe it, then reconnect A. | Health reports reconnection required without repeated provider calls; an owner reconnect restores synchronization. |
reviewed-send |
Enable server and hotel staff sending, reconnect for send consent, save a synthetic reply and approve its exact recipient/body. | One message appears in Gmail Sent and at the controlled recipient with the approved body, sender and stable message identity. |
gmail-threading |
Inspect the reviewed send in both Gmail accounts. | Gmail places it in the intended thread and message source contains the expected reply headers without CC/BCC. |
duplicate-approval |
Concurrently submit or repeat approval for the same imported message, then restart the worker. | Exactly one Gmail message exists; later approval/replay attempts are rejected or show the completed delivery. |
uncertain-send-reconciliation |
Use an approved, reviewed provider-test method to create or use an uncertain result; never induce it against uncontrolled recipients. | The item stays held, is not automatically resent, and “Verify in Gmail Sent” marks it sent only when the stable identity, sender, recipient and SENT label uniquely match. If the environment cannot safely induce uncertainty, this scenario remains unpassed. |
sending-stop-control |
Queue a reviewed synthetic reply, disable hotel sending before worker submission, and observe the result. | Nothing reaches Gmail and the item is rejected for staff action; re-enabling does not silently submit an old automatic approval. |
After each provider-side change, allow for the documented worker interval and capture timestamps in UTC. Treat Gmail acceptance as provider submission, not proof of final delivery; inspect the controlled recipient and any bounce separately.
Record and approval
Copy deploy/google-acceptance.example.json to the restricted acceptance store outside the checkout. Replace all placeholders, change a scenario to pass only after reviewing its restricted evidence, and use opaque ticket or evidence IDs without email addresses. A different person should complete acceptedBy after checking all evidence and confirming the stop conditions did not occur.
Validate the completed record:
python3 deploy/google_acceptance.py /secure/acceptance/google-mailbox-release.json
The validator checks completeness, immutable release identifiers, ordered UTC timestamps, an HTTPS origin, all required passing scenarios and safe evidence references. It cannot inspect or prove the underlying evidence. Retain the record with the release and link its restricted location from the milestone tracker; do not mark milestone 12 accepted merely because the validator succeeds.