2.8 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.
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
Agree the concurrency, latency, error-rate and resource-headroom targets before running the probe. The generated result reports observations, not a pass/fail claim. Repeat after a warm-up, investigate every error, and retain host metrics with the report. Do not point the probe at a live hotel or increase its built-in bounds to simulate a denial of service.
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.