/07-validate

name: headless-step-validate
description: "Step 7 (validate) of the Hostinger Headless flow. OPTIONAL quick gate before deploy: every prior stage already self-verifies, so this is a fast confirmation (instance live + backend API answers with seeded content) plus optional local preview and user sign-off. Skip the heavy parts when nobody needs to approve."

headless-step-validate

> **Optional / fast.** Every stage before this one already verifies its own work (provision checks the > backend, content-model push checks the REST counts, frontend builds clean), and **deploy verifies the > live result**. So validate is **not** a re-run of all that — it's a quick confirmation, plus the > optional human preview/sign-off. **Skip Steps 3–4 (rebuild + approval) entirely** on an autonomous or > temp-domain run where no one is signing off; just do the two 10-second checks below and move on. Spend > time here only when a person wants to see it before it goes live.

**In:** project in `~/.hostinger/<domain>/src/`, `site.json`, `state.json`.

1 — Instance status (always, quick)

`provision.status == "completed"` **and** re-verify against the connector: `hosting_websites_list-setups { "domain": "<domain>" }`, exact-match the row → `completed`. Anything else → not ready; return to the instance barrier, don't deploy.

2 — Backend API status (WordPress / WooCommerce / Ecommerce, always, quick)

Hit the live API from `site.json` and confirm it answers **with the content the push created** — a 200 with an empty catalog means the push didn't land:

• **WordPress:** `GET {urls.rest_api}/posts?per_page=1` → 200 JSON array; check `X-WP-Total` against the

planned post count, and `GET {urls.rest_api}/media?per_page=1` → `X-WP-Total` matches the planned image count (more = duplicates).

• **WordPress + WooCommerce** (`site.json → woocommerce.enabled`): the WordPress check above **plus**

`GET {urls.store_api}/products?per_page=100` → 200 with the seeded products and `prices` (minor units); count matches the plan. Don't test checkout while `woocommerce.payment_enabled` is `false`.

• **Ecommerce:** query `urls.storefront_api` for the sales channel → 200 with the seeded products and

prices *(confirm against the store)*.

• **Contact form** (`site.json → contact_form.enabled`): POST one throwaway test submission (dummy

name/email/subject/message + CF7's hidden `_wpcf7*` fields — see `../04-content-model/wordpress/contact-form.md` §3) to `contact_form.feedback_url` and assert the JSON `status` is **`mail_sent`**. This is the one place a real send happens, so one test email reaches the owner — not several. `mail_failed` is a real finding: surface it to the user (CF7 is wired, but `wp_mail` delivery/SPF needs attention — a Hostinger mailbox on the domain is the most reliable recipient) and log it as an issue. A `validation_failed` means the test payload didn't match the form's fields — fix the field names in `site.json`, not the plugin. **Then check the honeypot:** POST a **second** throwaway submission with the same valid fields **plus** `contact_form.honeypot_field` **filled**, and assert the `status` is **`spam`** (no mail sent). Keep the real fields valid — CF7 validates **before** running the spam filter, so an invalid payload would return `validation_failed` and never reach the honeypot check. A `mail_sent` here means the `cf7-headless-spamguard` plugin isn't active — surface it and re-check its deploy.

Fail or counts off → fix content-model push before building against live data.

3 — Clean rebuild against the live API (optional — skip unless signing off)

Frontend already produced a clean build; only redo this if you want a from-scratch guarantee before a human sign-off. Remove the build output and rebuild; a failed or incomplete build is a stop (no fixtures, placeholder copy or `.htaccess` in the output).

• **Astro (SSG):** `rm -rf dist && npm run build && npm run check:dist`.
• **Next.js (SSR):** `rm -rf .next && npm run check && npm run build`.

4 — Preview & approval (optional — only when a person is signing off)

When someone wants to see it first: start the local preview (Astro: `npm run preview`; Next.js: `npx next start`), check desktop and mobile widths, navigation and a couple of key routes, and present it for **explicit approval**. If preview tooling is unavailable, give the user the command and URL. On an autonomous or temp-domain run, skip this — deploy will verify the live result anyway.

Then (after approval, or immediately if 3–4 were skipped): `state.json` → `stage: "deploy"`, fresh `updated_at`; leave `provision` unchanged.