5.7 KiB
Supervised pilot, capacity and release approval
Milestone 18 is an evidence exercise against the exact approved release, not a feature toggle. Use synthetic data for capacity work and a separately approved, tightly supervised hotel cohort for the pilot. Keep provider writes and FAQ live mode disabled until their individual acceptance records are approved.
Before the pilot, complete the Gate B automation, identity and privacy acceptance as well as the Google and desktop exercises. These reviews must use the same release identifiers as the final decision.
Read-only capacity probe
The capacity probe logs in once with a dedicated sandbox staff account and sends bounded concurrent GET requests to readiness, hotel settings and cursor-paginated inbox endpoints. It never calls provider integrations, creates records, edits drafts or retains response bodies. Run it only during an approved sandbox window and monitor CPU, memory, MongoDB latency, disk, Nginx and application errors independently.
read -r -p 'Capacity account email: ' CAPACITY_EMAIL
read -r -s -p 'Capacity account password: ' CAPACITY_PASSWORD
export CAPACITY_EMAIL CAPACITY_PASSWORD
python3 deploy/capacity_probe.py \
--origin https://sandbox-guestops.futuresens.co.uk \
--requests 500 --concurrency 10 \
--release-commit FULL_40_CHARACTER_SHA \
--release-record-sha256 RELEASE_RECORD_SHA256 \
--output /secure/acceptance/capacity.json \
--confirm-sandbox
unset CAPACITY_EMAIL CAPACITY_PASSWORD
For the 0.2.0 Gate B candidate, the approved targets are concurrency 10, p95 latency at or below 500 ms, error rate at or below 1%, and at least 25% CPU and memory headroom on the documented four-core, 7.6 GiB host. The generated result reports HTTP observations, not a pass/fail claim. Repeat after a warm-up, investigate every error, and retain independently captured host metrics with the report. Hash both retained files for the approval record. Do not point the probe at a live hotel or increase its built-in bounds to simulate a denial of service.
Five-business-day supervised pilot
Use one approved hotel and named hotel, technical and rollback owners. Start only after the prerequisite evidence below has passed. Keep PMS writes, payment creation and FAQ live mode disabled. Complete one daily review on each of five business days and stop for tenant leakage, credential exposure, data loss, an unapproved or duplicate send, an unreconciled uncertain send, failed rollback or loss of monitoring.
Copy deploy/pilot-run.example.json to the restricted evidence store and replace all placeholders. Resolve critical and high findings; lower-severity findings may be contained only with an owner, expiry and objective rollback trigger. Validate and hash the final record:
python3 deploy/pilot_run.py /secure/acceptance/pilot-run.json
sha256sum /secure/acceptance/pilot-run.json
The example deliberately fails while daily reviews are not-run. A structurally valid record does not substitute for the five elapsed business days or independent evidence review.
Pilot exit record
The go/no-go record must bind all evidence to the same release commit and release-record checksum. Record named owners, dates, evidence locations, findings and explicit dispositions for:
- default-branch CI and immutable release archive;
- Debian preflight, HTTPS, persistence and controlled reboot;
- encrypted off-host backup and timed isolated restore;
- Google mailbox and reviewed-send acceptance;
- knowledge, AI and FAQ test-mode evaluation;
- identity, privacy, retention and audit review;
- inbox pagination, draft protection, timezone and desktop-parity acceptance;
- capacity targets, observed host headroom and expected pilot workload;
- support, rollback, provider-reconciliation and incident exercises;
- every pilot usability or security finding.
Approval requires separate named decisions from the hotel pilot owner and technical release owner. Gate C additionally requires independently accepted PMS and payment-provider evidence. A conditional approval must identify the containment, owner, expiry and rollback trigger; an unresolved finding is not silently converted into acceptance. Retain the signed decision with the release rather than committing guest, credential or incident data to this repository.
Copy deploy/pilot-approval.example.json into the restricted release store and complete it only after reviewing the referenced evidence. Approval schema version 2 binds the five-day pilot record and both the capacity report and independently captured host metrics. The example is intentionally invalid while its decision is pending. For a contained finding, record its named owner, future expiry and objective rollback trigger. Validate the completed record with:
python3 deploy/pilot_approval.py /secure/acceptance/pilot-approval.json
The validator requires the exact Gate B evidence set, or that set plus independently accepted PMS and payment-provider evidence for Gate C. It also verifies that observed concurrency meets the pre-agreed target and that p95 latency and error rate remain within their pre-agreed bounds. Structural validation does not inspect evidence or authorize rollout by itself.
Complete the incident and rollback exercise before marking incident-support as passed. Its record must use the same release identifiers and target gate as this decision. Reference the retained exercise record and validator output; do not substitute a local automated-test result for the supervised exercise.
Complete the desktop-parity acceptance exercise before marking inbox-usability as passed. Bind it to the same release identifiers and retain its independently reviewed record outside the repository.