# [CANOFY-115] Smoke Test & Create Control Centre Records

**Type:** Story
**Epic:** New Client Onboarding — Automated AWS + Frappe Provisioning
**Stage key:** `smoke_test` (pipeline stage 15 of 15, final)
**Component:** `utils/onboarding_executor.py`, `utils/uptime_checker.py`

## User Story

**As** an operations engineer,
**I want** onboarding to verify the site is actually reachable before
declaring success, and only then register it in Control Centre,
**so that** a broken site never gets marked "Completed," and Control
Centre's inventory (`AWS Server`, `Bench Instance`, `Client Site`) always
reflects only real, working infrastructure.

## Description

1. Run an uptime check against the site (HTTPS if SSL configured, otherwise
   the IP-override fallback established in stage 12) — expect a `200`
   response.
2. Only on a successful check:
   - Create the `AWS Server` record (instance ID, region, type, etc.).
   - Create the `Bench Instance` record.
   - Create the `Client Site` record.
   - Link all three back onto `Onboarding Request`
     (`aws_server_created`, `bench_created`, `site_created`).
   - Set `Onboarding Request.onboarding_status = "Completed"`,
     `completed_at = now()`.
3. On failure, the stage (and therefore the whole run) fails — no partial
   Control Centre records are created, so a failed onboarding never leaves
   a half-registered, confusing inventory entry.

## Configuration / Prerequisites

- Depends on every prior stage having succeeded (this is intentionally the
  last stage — it's the pipeline's final gate).

## Acceptance Criteria

- [ ] A non-200 (or unreachable) response fails the stage — `Onboarding
      Request` stays `Failed`, no Control Centre records created.
- [ ] A successful check creates exactly one `AWS Server`, one `Bench
      Instance`, one `Client Site` — never duplicates on a retried run.
- [ ] All cross-links (`Onboarding Request` ↔ the three new records) are
      set correctly.
- [ ] `onboarding_status` only ever becomes `Completed` after this stage's
      uptime check passes — no earlier stage can set that status.

## Test Cases

| ID | Scenario | Steps | Expected Result |
|----|----------|-------|------------------|
| TC-1 | Happy path | Run stage against a fully provisioned, reachable site | Uptime check returns 200; `AWS Server`/`Bench Instance`/`Client Site` all created and linked; request marked `Completed` |
| TC-2 | Site unreachable | Simulate the site not responding (e.g. nginx down) | Stage fails; `onboarding_status` stays `Failed`; no Control Centre records created |
| TC-3 | No duplicate records on retry | Retry this stage after a transient failure, where the site is now reachable | Exactly one of each record created — not two, even though the stage ran twice |
| TC-4 | IP-override fallback | Run against a site with `ssl_configured=False` from stage 12 | Uptime check correctly uses `http://<elastic_ip>` with the right `Host` header, not `https://<site_name>` (which would fail with no valid cert) |
| TC-5 | Cross-link integrity | After a successful run, inspect `Onboarding Request` | `aws_server_created`, `bench_created`, `site_created` all point at the correct, real record names |