/09-done

name: headless-step-done
description: "Step 9 (done) of the Hostinger Headless flow. Verifies the live site, then hands over the URLs (hPanel success page, main site, WordPress/store admin, dashboard), opens the success page in the browser on a successful run, and gives a summary of what was built and what the user can do next. Its final report format is also used whenever a run stops early."

headless-step-done

Verify the live site, then hand over the URLs (success page, main site, WordPress admin, dashboard), a summary of what was built, and what the user can do next. **On a successful run, open the success page for the user** (see *Open the success page*).

Verify the live site (brief)

On a run that deployed this session, re-confirm what you're about to hand over actually works (deploy already checked this — this is a quick re-confirm, not a full re-run):

• **Main site:** `GET https://<domain>/` → 200 (Next.js SSR: `x-powered-by: Next.js`; Astro SSG: static

HTML with real content).

• **WordPress admin:** `GET {urls.wp_admin}` → reachable (a login page, 200/302), not 404.
• **Backend API:** `GET {urls.rest_api}/posts?per_page=1` → 200 (WordPress); for a **WooCommerce** store

(`site.json → woocommerce.enabled`) also `GET {urls.store_api}/products?per_page=1` → 200; or the storefront API for the sales channel → 200 (Ecommerce).

• **Contact form** (`site.json → contact_form.enabled`): validate already sent a test submission, so

don't send another here. In the handover, tell the owner the contact page is live and enquiries email the **WordPress admin address** (via `wp_mail`) — and that for the most reliable delivery that address should be a Hostinger mailbox on the domain. If validate reported `mail_failed`, say so plainly instead of claiming the form sends.

If a check fails, say so in the outcome paragraph and don't claim the site is live.

Final report

Every run ends with this report, whether it finishes here or stops at an earlier stage (a dummy or missing step, a failed provision, the user pausing). Build it from `state.json`, `site.json`, `deploy.json` and what you actually did and checked in this run. Report only what you verified. Don't claim a stage passed if you didn't check it.

Write it in this order:

1. **One-paragraph outcome.** What was created and on which domain (bold it). If the run stopped early, name the stage it stopped at, why, and what the user will see right now (e.g. "the site root returns 403 until the frontend is deployed").

2. **Steps completed** — a table with one row per stage that ran:

| Stage | Result | |---|---| | connect | How the connector was reached, MCP version, how sign-in happened. | | 1 check state | New build / resumed at `<stage>` / adopted an existing site. | | 2 refine | What the brief is and which backend it chose (say if a sample brief was used). | | 3 provision | Plan and order used, how long setup took, which verification checks passed. | | 4 content model | What was created (counts of pages, posts, terms, menus, media, SEO) and how it was verified. | | … | One row for each further stage that ran (design, frontend, validate, deploy, done). |

Stages that didn't run are left out of the table and named in the outcome paragraph instead. Use the stage numbers and names from the orchestrator's flow table.

3. **Links** — every URL that exists at this point. Build the hPanel URLs from `site.json` (`order_id`, `username`, `domain`) and `state.json` (`tool`); take the rest from `site.json` / `deploy.json`. Lead with the one the user cares about most — the **main site** — then the admin and dashboards. **Don't list the success page here:** it opens on its own (see *Open the success page*), so printing its URL in the report is just noise — the only exception is when a browser can't be opened (handled in that section):

• **Main site (live):** `urls.site` (`https://<domain>`) — only once deployed.
• **WordPress admin (one-click auto-login):** for a WordPress backend, **mint and hand over the

auto-login redirect URL** — `wordpress_login_create-links { username, software: <site.json wordpress.install_id> }` returns a temporary link that logs the user straight into wp-admin. Give that URL as the admin link (it lands on `/cms/wp-admin`), so the user never needs a password. Also note the plain `urls.wp_admin` as a fallback. **Never print or store a password.** For a **WordPress + WooCommerce** store, this *same* wp-admin login is the store admin (wp-admin → WooCommerce → Products/Orders) — do **not** use the Ecommerce `store_admin` path. **Call out the one setup step under *Gaps / follow-ups*:** when `site.json → woocommerce.payment_enabled` is `false`, the owner must enable a payment method + a shipping zone in WooCommerce → Settings before checkout works (the catalog and cart already work). For a Hostinger **Ecommerce** store, link the store admin from `urls.store_admin` instead.

• **hPanel site dashboard:** `https://hpanel.hostinger.com/websites/<domain>` (the headless website

is installed by now).

• **Onboarding (resume):** `https://hpanel.hostinger.com/headless-onboarding/<order_id>/<username>/`
• **REST API** (for developers): `urls.rest_api`.

> URL shape note: `<username>` may be dropped from the onboarding/success URLs in a future hPanel > release. If a built URL 404s, retry the same path without the `/<username>` segment before > reporting it as broken.

4. **Where state lives** — the workspace path `~/.hostinger/<domain>/`, the `stage` that a resumed run will start from, and the build report `~/.hostinger/<domain>/report.html`.

5. **Gaps / follow-ups** (only if any) — a short numbered list of anything skipped, approximated or left for the user (e.g. no images generated, default WordPress content left in place).

Never include passwords, JWTs or other secrets in the report. F