hostinger-api-mcp 3.23.2 → 3.24.0

package/CHANGELOG.md

@@ -4,6 +4,13 @@ Generated at release time from the diff between the previous and current
 build. Tool changes are listed individually; everything else is summarised
 by area.
 
+## v3.24.0 — 2026-10-30
+
+### Also in this release
+
+- Bundled agent skills: `skills/headless/steps/09-done/SKILL.md`
+- Other files: `src/core/skills.js`, `src/core/skills.ts`
+
 ## v3.23.2 — 2026-10-30
 
 ### Also in this release

package/gemini-extension.json

@@ -1,6 +1,6 @@
 {
   "name": "hostinger-api-mcp",
-  "version": "3.23.2",
+  "version": "3.24.0",
   "description": "Hostinger API — manage domains, DNS, hosting, VPS, billing and more from Gemini CLI.",
   "mcpServers": {
     "hostinger": {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "hostinger-api-mcp",
-  "version": "3.23.2",
+  "version": "3.24.0",
   "mcpName": "io.github.hostinger/hostinger-api-mcp",
   "description": "MCP server for Hostinger API",
   "repository": {

package/server.json

@@ -6,12 +6,12 @@
     "url": "https://github.com/hostinger/api-mcp-server",
     "source": "github"
   },
-  "version": "3.23.2",
+  "version": "3.24.0",
   "packages": [
     {
       "registryType": "npm",
       "identifier": "@hostinger/mcp",
-      "version": "3.23.2",
+      "version": "3.24.0",
       "transport": {
         "type": "stdio"
       },

package/skills/headless/steps/09-done/SKILL.md

@@ -1,6 +1,6 @@
 ---
 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."
+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 plus explicit next steps — how to log in to wp-admin and reset the password, how to manage content, and how to finish WooCommerce/store setup so it can take orders. Its final report format is also used whenever a run stops early."
 ---
 
 # headless-step-done
@@ -52,14 +52,17 @@ Write it in this order:
    - **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.
+     that URL as the admin link (it lands on `/cms/wp-admin`), so the user never needs a password.
+     Alongside it, give the two ways back in that don't expire: the **login URL `{urls.wp_admin}`**
+     (`https://<domain>/cms/wp-admin` — the headless WordPress lives under `/cms`), and the **WP Admin
+     button in hPanel** (hPanel → the website → *WP Admin*). Note how to **reset the password**: on the
+     `/cms/wp-admin` login screen use **"Lost your password?"**, and WordPress emails a reset link to the
+     **WordPress admin email** (the address set at install, which the owner already has) — see *Next
+     steps* for an optional deliverability tip.
+     **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; the store setup the owner still needs is spelled out under *Next steps*. 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>/`
@@ -69,10 +72,34 @@ Write it in this order:
    > 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
+4. **Next steps** — what the user does now to actually use the site. Required on a successful run;
+   tailor the bullets to the backend and keep them concrete. This is the hand-holding the hPanel
+   success page can't give: don't just link wp-admin, tell them what to do once they're in.
+
+   - **Manage content (WordPress):** in wp-admin (the one-click link, the `/cms/wp-admin` login URL, or
+     hPanel → *WP Admin*) → **Posts**, **Pages**, **Media**, **Appearance → Menus**. Say how edits reach
+     the live site for *this* build: an **SSR** frontend re-reads the REST API each request, so changes
+     show up with no redeploy; an **SSG/static** build must be redeployed to pick up new content (read
+     `state.json → frontend.rendering`).
+   - **Log in later & reset the password:** repeat the two non-expiring routes (the `/cms/wp-admin` login
+     URL and hPanel's *WP Admin* button) and the **"Lost your password?"** reset. The reset link goes to
+     the **WordPress admin email** — the address set at install, which the owner already has — so nothing
+     extra is needed to receive it. Optionally, for more reliable delivery, they can create a mailbox on
+     the domain (hPanel → *Emails*) and set it as the admin address in **wp-admin → Settings → General**.
+   - **WordPress + WooCommerce — finish store setup so it can take orders.** The catalog and cart already
+     work, but **checkout stays off until the owner configures it in wp-admin**: WooCommerce → Settings →
+     **Payments** (enable at least one method) and → **Shipping** (add a zone with a rate), then confirm
+     products/prices and place a test order. When `site.json → woocommerce.payment_enabled` is `false`,
+     state plainly that this step is **required before any purchase works** — this is the gap owners hit.
+   - **Hostinger Ecommerce store:** when `site.json → ecommerce.payment_enabled` is `false`, finish
+     payment setup in the store admin (`urls.store_admin`) before the storefront can sell; otherwise it's
+     ready to take orders.
+   - **Webapp:** manage the app from hPanel → the website (environment variables, deployments, logs).
+
+5. **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
+6. **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. For wp-admin access, give the URL and

package/src/core/skills.js

@@ -253,10 +253,10 @@ export default [
       },
       {
         "uri": "skill://hostinger-headless/steps/09-done/SKILL.md",
-        "digest": "sha256:e1e5c09f0d6f01f1d911455a8e49667da715a37cca140105d08fc5e8a73e435d",
-        "size": 11209,
+        "digest": "sha256:896b76e2a90868df56a36d59010b18c4944cfca93233847b3e041c436e154bfa",
+        "size": 13831,
         "mimeType": "text/markdown",
-        "text": "---\nname: headless-step-done\ndescription: \"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.\"\n---\n\n# headless-step-done\n\nVerify the live site, then hand over the URLs (success page, main site, WordPress admin, dashboard), a\nsummary of what was built, and what the user can do next. **On a successful run, open the success page\nfor the user** (see *Open the success page*).\n\n## Final report\n\nEvery run ends with this report, whether it finishes here or stops at an earlier stage (a dummy or\nmissing step, a failed provision, the user pausing). On a run that deployed this session, run the\nchecks in *Verify the live site* below first. Build the report from `state.json`, `site.json`,\n`deploy.json` and what you actually did and checked in this run. Report only what you verified. Don't\nclaim a stage passed if you didn't check it.\n\nWrite it in this order:\n\n1. **One-paragraph outcome.** What was created and on which domain (bold it). If the run stopped\n   early, name the stage it stopped at, why, and what the user will see right now (e.g. \"the site\n   root returns 403 until the frontend is deployed\").\n\n2. **Steps completed.** This table is required on every run, including early stops: never replace\n   it with prose. Give one row per stage that ran, using the stage numbers and names from the\n   orchestrator's flow table. Leave out stages that didn't run and name them in the outcome\n   paragraph instead. A finished WordPress blog build looks like this:\n\n   | Stage | Result |\n   |---|---|\n   | connect | Hostinger connector reached over MCP (`@hostinger/mcp` 1.9.2); signed in through the browser login. |\n   | 1 check state | New build for `harbourlight.blog`; no earlier workspace. |\n   | 2 refine | Personal travel blog about coastal towns in the UK; backend: WordPress. |\n   | 3 provision | Business plan, order 41875230; setup took 6 min; domain, SSL and WordPress checks passed. |\n   | 4 content model | 5 pages, 8 posts, 6 categories, 1 menu, 14 images (Hostinger AI), SEO titles on every page; counts re-read from the REST API. |\n   | 5 design | \"Salt & Ink\" direction: serif headings, sea-blue accents; `design.md` and logo written, logo check passed. |\n   | 6 frontend | Next.js SSR with home, blog, post, category and contact pages wired to the REST API; local build passed. |\n   | 7 validate | Instance setup completed; REST API returned the 8 pushed posts; no preview (nobody signing off). |\n   | 8 deploy | Source uploaded, build finished in 3 min; site root returns 200. |\n   | 9 done | Main site, wp-admin and REST API re-checked live: all returned 200. |\n\n3. **Links** — every URL that exists at this point. Build the hPanel URLs from `site.json`\n   (`order_id`, `username`, `domain`) and the onboarding slug; take the rest from `site.json` /\n   `deploy.json`. Lead with the one the user cares about most — the **main site** — then the admin\n   and dashboards. **Don't list the success page here:** it opens on its own (see *Open the success\n   page*), so printing its URL in the report is just noise — the only exception is when a browser\n   can't be opened (handled in that section):\n\n   - **Main site (live):** `urls.site` (`https://<domain>`) — only once deployed.\n   - **WordPress admin (one-click auto-login):** for a WordPress backend, **mint and hand over the\n     auto-login redirect URL** — `wordpress_login_create-links { username, software: <site.json\n     wordpress.install_id> }` returns a temporary link that logs the user straight into wp-admin. Give\n     that URL as the admin link (it lands on `/cms/wp-admin`), so the user never needs a password. Also\n     note the plain `urls.wp_admin` as a fallback. **Never print or store a password.** For a\n     **WordPress + WooCommerce** store, this *same* wp-admin login is the store admin (wp-admin →\n     WooCommerce → Products/Orders) — do **not** use the Ecommerce `store_admin` path. **Call out the one\n     setup step under *Gaps / follow-ups*:** when `site.json → woocommerce.payment_enabled` is `false`,\n     the owner must enable a payment method + a shipping zone in WooCommerce → Settings before checkout\n     works (the catalog and cart already work). For a Hostinger **Ecommerce** store, link the store admin\n     from `urls.store_admin` instead.\n   - **hPanel site dashboard:** `https://hpanel.hostinger.com/websites/<domain>` (the headless website\n     is installed by now).\n   - **Onboarding (resume):** `https://hpanel.hostinger.com/headless-onboarding/<order_id>/<username>/`\n   - **REST API** (for developers): `urls.rest_api`.\n\n   > URL shape note: `<username>` may be dropped from the onboarding/success URLs in a future hPanel\n   > release. If a built URL 404s, retry the same path without the `/<username>` segment before\n   > reporting it as broken.\n\n4. **Where state lives** — the workspace path `~/.hostinger/<domain>/`, the `stage` that a\n   resumed run will start from, and the build report `~/.hostinger/<domain>/report.html`.\n\n5. **Gaps / follow-ups** (only if any) — a short numbered list of anything skipped, approximated or\n   left for the user (e.g. no images generated, default WordPress content left in place).\n\nNever include passwords, JWTs or other secrets in the report. For wp-admin access, give the URL and\noffer a one-click login link (`wordpress_login_create-links`), not credentials.\n\n## Verify the live site (brief)\n\nOn a run that deployed this session, re-confirm what you're about to hand over actually works (deploy\nalready checked this — this is a quick re-confirm, not a full re-run):\n\n- **Main site:** `GET https://<domain>/` → 200 (Next.js SSR: `x-powered-by: Next.js`; Astro SSG: static\n  HTML with real content).\n- **WordPress admin:** `GET {urls.wp_admin}` → reachable (a login page, 200/302), not 404.\n- **Backend API:** `GET {urls.rest_api}/posts?per_page=1` → 200 (WordPress); for a **WooCommerce** store\n  (`site.json → woocommerce.enabled`) also `GET {urls.store_api}/products?per_page=1` → 200; or the\n  storefront API for the sales channel → 200 (Ecommerce).\n- **Contact form** (`site.json → contact_form.enabled`): validate already sent a test submission, so\n  don't send another here. In the handover, tell the owner the contact page is live and enquiries email\n  the **WordPress admin address** (via `wp_mail`) — and that for the most reliable delivery that address\n  should be a Hostinger mailbox on the domain. If validate reported `mail_failed`, say so plainly instead\n  of claiming the form sends.\n\nIf a check fails, say so in the outcome paragraph and don't claim the site is live.\n\n## Open the success page\n\nOn a **successful** run (the deploy succeeded and the live checks passed), open the success page in the\nuser's **main / system browser** right after presenting the report, so they land on the hPanel\ncelebration/next-steps screen for their new site. This is a side effect only — **don't print the\nsuccess URL in the report output** (it just opens); the one exception is the can't-open-a-browser\nfallback below. Build the URL with `<tool>` as the running tool's onboarding slug (see *State and\nartifacts* in the top-level `SKILL.md`):\n\n```bash\n# Build the URL first, then open it with the OS default (main) browser — not an embedded one.\n# <tool> = the onboarding slug\nURL=\"https://hpanel.hostinger.com/headless-onboarding/<order_id>/<username>/success/<domain>/<tool>\"\nopen \"$URL\"        # macOS\n# xdg-open \"$URL\"  # Linux\n# start \"\" \"$URL\"  # Windows\n```\n\n- **Main browser only.** Use the OS opener above (`open` / `xdg-open` / `start`) so the page lands in\n  Chrome, Safari, Edge, or whatever the user actually uses. **Do not** open it in an embedded or\n  sandboxed browser (Cursor IDE browser / `cursor-ide-browser`, Playwright, Puppeteer, WebView, or\n  any in-agent browser tab). Those stay inside the tool session and the user won't see the\n  celebration page where they expect it.\n- Open it **once**, and only on a successful run — never on an early stop or a failed deploy.\n- If your tool can't open a browser (the command isn't available, or `open`/`xdg-open`/`start`\n  fails), don't treat it as a failure and **don't fall back to an embedded browser**. This is the\n  **one** case where you print the success URL — show it once in the report and tell the user to\n  open it themselves in their main browser.\n\n## Build report\n\nRight after the final report, save the build report for this run. It turns the run log (stage times\nfrom `run-log.json`, events from `events.jsonl`) into `reports/<run>.json` and `.html`, and copies the\nHTML to `report.html` in the workspace:\n\n```bash\nnode <skill>/run-log.mjs <domain> event good '{\"text\":\"<something that went well>\"}'   # one per thing, if not logged yet\nnode <skill>/run-log.mjs <domain> stage-end done ok\nnode <skill>/run-log.mjs <domain> report --outcome <live|stopped|failed> [--tokens '<json>']\n```\n\nThen send it to Hostinger: pass `reports/<run>.json` unchanged to `hosting_headless_submit-build-report`\nand run `report-sent <run>` (or `report-rejected <run>` on a 422). The `report` command prints the\nexact path and run id. Don't ask first; see *Run log and build report* in the top-level `SKILL.md`\nfor failures. Then tell the user in one line: \"Sent the build report to Hostinger to help improve\nthe flow.\" On a 422 say it's saved locally only; on any other failure say it'll be sent next session.\n\nIf the user asks for more changes after this report in the same session, call\n`run-log.mjs <domain> run-resume --reason \"<what they asked for>\"` before the work. Then log as\nusual and run `report` again when it's done. It updates this run's report in place, and the report\nlists the follow-up. Send the updated report the same way.\n\n- **Outcome:** `live` when the deploy succeeded this run, `failed` when a stage failed and you\n  couldn't recover, `stopped` for everything else (the user paused, a dummy or missing step). Leave\n  `--outcome` out and the script decides from the log.\n- **Before you write it,** check that every issue, correction and skill gap from this run is in\n  `events.jsonl`. Log any that are missing now; the report only shows what was logged.\n- **After you write it,** read the `warning:` lines `report` prints. They list logging gaps: a stage\n  that never ended, a start that was estimated, a stage logged with no duration, or (on a live build)\n  a stage that was never logged. Fix what you can: `stage-end` an open stage, or correct a start with\n  `stage-fix <stage> --started-ago <time>`, then run `report` again. What you can't fix stays in the report's\n  *Logging gaps* section.\n- **Tokens:** only what your tool tells you about your own usage (see *Run log and build report* in\n  the top-level `SKILL.md`).\n- In the final report's *Where state lives*, add the path to `report.html` so the user can open it.\n\nDo this on every run, including the early stops: those reports are the most useful ones.\n"
+        "text": "---\nname: headless-step-done\ndescription: \"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 plus explicit next steps — how to log in to wp-admin and reset the password, how to manage content, and how to finish WooCommerce/store setup so it can take orders. Its final report format is also used whenever a run stops early.\"\n---\n\n# headless-step-done\n\nVerify the live site, then hand over the URLs (success page, main site, WordPress admin, dashboard), a\nsummary of what was built, and what the user can do next. **On a successful run, open the success page\nfor the user** (see *Open the success page*).\n\n## Final report\n\nEvery run ends with this report, whether it finishes here or stops at an earlier stage (a dummy or\nmissing step, a failed provision, the user pausing). On a run that deployed this session, run the\nchecks in *Verify the live site* below first. Build the report from `state.json`, `site.json`,\n`deploy.json` and what you actually did and checked in this run. Report only what you verified. Don't\nclaim a stage passed if you didn't check it.\n\nWrite it in this order:\n\n1. **One-paragraph outcome.** What was created and on which domain (bold it). If the run stopped\n   early, name the stage it stopped at, why, and what the user will see right now (e.g. \"the site\n   root returns 403 until the frontend is deployed\").\n\n2. **Steps completed.** This table is required on every run, including early stops: never replace\n   it with prose. Give one row per stage that ran, using the stage numbers and names from the\n   orchestrator's flow table. Leave out stages that didn't run and name them in the outcome\n   paragraph instead. A finished WordPress blog build looks like this:\n\n   | Stage | Result |\n   |---|---|\n   | connect | Hostinger connector reached over MCP (`@hostinger/mcp` 1.9.2); signed in through the browser login. |\n   | 1 check state | New build for `harbourlight.blog`; no earlier workspace. |\n   | 2 refine | Personal travel blog about coastal towns in the UK; backend: WordPress. |\n   | 3 provision | Business plan, order 41875230; setup took 6 min; domain, SSL and WordPress checks passed. |\n   | 4 content model | 5 pages, 8 posts, 6 categories, 1 menu, 14 images (Hostinger AI), SEO titles on every page; counts re-read from the REST API. |\n   | 5 design | \"Salt & Ink\" direction: serif headings, sea-blue accents; `design.md` and logo written, logo check passed. |\n   | 6 frontend | Next.js SSR with home, blog, post, category and contact pages wired to the REST API; local build passed. |\n   | 7 validate | Instance setup completed; REST API returned the 8 pushed posts; no preview (nobody signing off). |\n   | 8 deploy | Source uploaded, build finished in 3 min; site root returns 200. |\n   | 9 done | Main site, wp-admin and REST API re-checked live: all returned 200. |\n\n3. **Links** — every URL that exists at this point. Build the hPanel URLs from `site.json`\n   (`order_id`, `username`, `domain`) and the onboarding slug; take the rest from `site.json` /\n   `deploy.json`. Lead with the one the user cares about most — the **main site** — then the admin\n   and dashboards. **Don't list the success page here:** it opens on its own (see *Open the success\n   page*), so printing its URL in the report is just noise — the only exception is when a browser\n   can't be opened (handled in that section):\n\n   - **Main site (live):** `urls.site` (`https://<domain>`) — only once deployed.\n   - **WordPress admin (one-click auto-login):** for a WordPress backend, **mint and hand over the\n     auto-login redirect URL** — `wordpress_login_create-links { username, software: <site.json\n     wordpress.install_id> }` returns a temporary link that logs the user straight into wp-admin. Give\n     that URL as the admin link (it lands on `/cms/wp-admin`), so the user never needs a password.\n     Alongside it, give the two ways back in that don't expire: the **login URL `{urls.wp_admin}`**\n     (`https://<domain>/cms/wp-admin` — the headless WordPress lives under `/cms`), and the **WP Admin\n     button in hPanel** (hPanel → the website → *WP Admin*). Note how to **reset the password**: on the\n     `/cms/wp-admin` login screen use **\"Lost your password?\"**, and WordPress emails a reset link to the\n     **WordPress admin email** (the address set at install, which the owner already has) — see *Next\n     steps* for an optional deliverability tip.\n     **Never print or store a password.** For a **WordPress + WooCommerce** store, this *same* wp-admin\n     login is the store admin (wp-admin → WooCommerce → Products/Orders) — do **not** use the Ecommerce\n     `store_admin` path; the store setup the owner still needs is spelled out under *Next steps*. For a\n     Hostinger **Ecommerce** store, link the store admin from `urls.store_admin` instead.\n   - **hPanel site dashboard:** `https://hpanel.hostinger.com/websites/<domain>` (the headless website\n     is installed by now).\n   - **Onboarding (resume):** `https://hpanel.hostinger.com/headless-onboarding/<order_id>/<username>/`\n   - **REST API** (for developers): `urls.rest_api`.\n\n   > URL shape note: `<username>` may be dropped from the onboarding/success URLs in a future hPanel\n   > release. If a built URL 404s, retry the same path without the `/<username>` segment before\n   > reporting it as broken.\n\n4. **Next steps** — what the user does now to actually use the site. Required on a successful run;\n   tailor the bullets to the backend and keep them concrete. This is the hand-holding the hPanel\n   success page can't give: don't just link wp-admin, tell them what to do once they're in.\n\n   - **Manage content (WordPress):** in wp-admin (the one-click link, the `/cms/wp-admin` login URL, or\n     hPanel → *WP Admin*) → **Posts**, **Pages**, **Media**, **Appearance → Menus**. Say how edits reach\n     the live site for *this* build: an **SSR** frontend re-reads the REST API each request, so changes\n     show up with no redeploy; an **SSG/static** build must be redeployed to pick up new content (read\n     `state.json → frontend.rendering`).\n   - **Log in later & reset the password:** repeat the two non-expiring routes (the `/cms/wp-admin` login\n     URL and hPanel's *WP Admin* button) and the **\"Lost your password?\"** reset. The reset link goes to\n     the **WordPress admin email** — the address set at install, which the owner already has — so nothing\n     extra is needed to receive it. Optionally, for more reliable delivery, they can create a mailbox on\n     the domain (hPanel → *Emails*) and set it as the admin address in **wp-admin → Settings → General**.\n   - **WordPress + WooCommerce — finish store setup so it can take orders.** The catalog and cart already\n     work, but **checkout stays off until the owner configures it in wp-admin**: WooCommerce → Settings →\n     **Payments** (enable at least one method) and → **Shipping** (add a zone with a rate), then confirm\n     products/prices and place a test order. When `site.json → woocommerce.payment_enabled` is `false`,\n     state plainly that this step is **required before any purchase works** — this is the gap owners hit.\n   - **Hostinger Ecommerce store:** when `site.json → ecommerce.payment_enabled` is `false`, finish\n     payment setup in the store admin (`urls.store_admin`) before the storefront can sell; otherwise it's\n     ready to take orders.\n   - **Webapp:** manage the app from hPanel → the website (environment variables, deployments, logs).\n\n5. **Where state lives** — the workspace path `~/.hostinger/<domain>/`, the `stage` that a\n   resumed run will start from, and the build report `~/.hostinger/<domain>/report.html`.\n\n6. **Gaps / follow-ups** (only if any) — a short numbered list of anything skipped, approximated or\n   left for the user (e.g. no images generated, default WordPress content left in place).\n\nNever include passwords, JWTs or other secrets in the report. For wp-admin access, give the URL and\noffer a one-click login link (`wordpress_login_create-links`), not credentials.\n\n## Verify the live site (brief)\n\nOn a run that deployed this session, re-confirm what you're about to hand over actually works (deploy\nalready checked this — this is a quick re-confirm, not a full re-run):\n\n- **Main site:** `GET https://<domain>/` → 200 (Next.js SSR: `x-powered-by: Next.js`; Astro SSG: static\n  HTML with real content).\n- **WordPress admin:** `GET {urls.wp_admin}` → reachable (a login page, 200/302), not 404.\n- **Backend API:** `GET {urls.rest_api}/posts?per_page=1` → 200 (WordPress); for a **WooCommerce** store\n  (`site.json → woocommerce.enabled`) also `GET {urls.store_api}/products?per_page=1` → 200; or the\n  storefront API for the sales channel → 200 (Ecommerce).\n- **Contact form** (`site.json → contact_form.enabled`): validate already sent a test submission, so\n  don't send another here. In the handover, tell the owner the contact page is live and enquiries email\n  the **WordPress admin address** (via `wp_mail`) — and that for the most reliable delivery that address\n  should be a Hostinger mailbox on the domain. If validate reported `mail_failed`, say so plainly instead\n  of claiming the form sends.\n\nIf a check fails, say so in the outcome paragraph and don't claim the site is live.\n\n## Open the success page\n\nOn a **successful** run (the deploy succeeded and the live checks passed), open the success page in the\nuser's **main / system browser** right after presenting the report, so they land on the hPanel\ncelebration/next-steps screen for their new site. This is a side effect only — **don't print the\nsuccess URL in the report output** (it just opens); the one exception is the can't-open-a-browser\nfallback below. Build the URL with `<tool>` as the running tool's onboarding slug (see *State and\nartifacts* in the top-level `SKILL.md`):\n\n```bash\n# Build the URL first, then open it with the OS default (main) browser — not an embedded one.\n# <tool> = the onboarding slug\nURL=\"https://hpanel.hostinger.com/headless-onboarding/<order_id>/<username>/success/<domain>/<tool>\"\nopen \"$URL\"        # macOS\n# xdg-open \"$URL\"  # Linux\n# start \"\" \"$URL\"  # Windows\n```\n\n- **Main browser only.** Use the OS opener above (`open` / `xdg-open` / `start`) so the page lands in\n  Chrome, Safari, Edge, or whatever the user actually uses. **Do not** open it in an embedded or\n  sandboxed browser (Cursor IDE browser / `cursor-ide-browser`, Playwright, Puppeteer, WebView, or\n  any in-agent browser tab). Those stay inside the tool session and the user won't see the\n  celebration page where they expect it.\n- Open it **once**, and only on a successful run — never on an early stop or a failed deploy.\n- If your tool can't open a browser (the command isn't available, or `open`/`xdg-open`/`start`\n  fails), don't treat it as a failure and **don't fall back to an embedded browser**. This is the\n  **one** case where you print the success URL — show it once in the report and tell the user to\n  open it themselves in their main browser.\n\n## Build report\n\nRight after the final report, save the build report for this run. It turns the run log (stage times\nfrom `run-log.json`, events from `events.jsonl`) into `reports/<run>.json` and `.html`, and copies the\nHTML to `report.html` in the workspace:\n\n```bash\nnode <skill>/run-log.mjs <domain> event good '{\"text\":\"<something that went well>\"}'   # one per thing, if not logged yet\nnode <skill>/run-log.mjs <domain> stage-end done ok\nnode <skill>/run-log.mjs <domain> report --outcome <live|stopped|failed> [--tokens '<json>']\n```\n\nThen send it to Hostinger: pass `reports/<run>.json` unchanged to `hosting_headless_submit-build-report`\nand run `report-sent <run>` (or `report-rejected <run>` on a 422). The `report` command prints the\nexact path and run id. Don't ask first; see *Run log and build report* in the top-level `SKILL.md`\nfor failures. Then tell the user in one line: \"Sent the build report to Hostinger to help improve\nthe flow.\" On a 422 say it's saved locally only; on any other failure say it'll be sent next session.\n\nIf the user asks for more changes after this report in the same session, call\n`run-log.mjs <domain> run-resume --reason \"<what they asked for>\"` before the work. Then log as\nusual and run `report` again when it's done. It updates this run's report in place, and the report\nlists the follow-up. Send the updated report the same way.\n\n- **Outcome:** `live` when the deploy succeeded this run, `failed` when a stage failed and you\n  couldn't recover, `stopped` for everything else (the user paused, a dummy or missing step). Leave\n  `--outcome` out and the script decides from the log.\n- **Before you write it,** check that every issue, correction and skill gap from this run is in\n  `events.jsonl`. Log any that are missing now; the report only shows what was logged.\n- **After you write it,** read the `warning:` lines `report` prints. They list logging gaps: a stage\n  that never ended, a start that was estimated, a stage logged with no duration, or (on a live build)\n  a stage that was never logged. Fix what you can: `stage-end` an open stage, or correct a start with\n  `stage-fix <stage> --started-ago <time>`, then run `report` again. What you can't fix stays in the report's\n  *Logging gaps* section.\n- **Tokens:** only what your tool tells you about your own usage (see *Run log and build report* in\n  the top-level `SKILL.md`).\n- In the final report's *Where state lives*, add the path to `report.html` so the user can open it.\n\nDo this on every run, including the early stops: those reports are the most useful ones.\n"
       }
     ]
   },

package/src/core/skills.ts

@@ -267,10 +267,10 @@ const skills: Skill[] = [
       },
       {
         "uri": "skill://hostinger-headless/steps/09-done/SKILL.md",
-        "digest": "sha256:e1e5c09f0d6f01f1d911455a8e49667da715a37cca140105d08fc5e8a73e435d",
-        "size": 11209,
+        "digest": "sha256:896b76e2a90868df56a36d59010b18c4944cfca93233847b3e041c436e154bfa",
+        "size": 13831,
         "mimeType": "text/markdown",
-        "text": "---\nname: headless-step-done\ndescription: \"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.\"\n---\n\n# headless-step-done\n\nVerify the live site, then hand over the URLs (success page, main site, WordPress admin, dashboard), a\nsummary of what was built, and what the user can do next. **On a successful run, open the success page\nfor the user** (see *Open the success page*).\n\n## Final report\n\nEvery run ends with this report, whether it finishes here or stops at an earlier stage (a dummy or\nmissing step, a failed provision, the user pausing). On a run that deployed this session, run the\nchecks in *Verify the live site* below first. Build the report from `state.json`, `site.json`,\n`deploy.json` and what you actually did and checked in this run. Report only what you verified. Don't\nclaim a stage passed if you didn't check it.\n\nWrite it in this order:\n\n1. **One-paragraph outcome.** What was created and on which domain (bold it). If the run stopped\n   early, name the stage it stopped at, why, and what the user will see right now (e.g. \"the site\n   root returns 403 until the frontend is deployed\").\n\n2. **Steps completed.** This table is required on every run, including early stops: never replace\n   it with prose. Give one row per stage that ran, using the stage numbers and names from the\n   orchestrator's flow table. Leave out stages that didn't run and name them in the outcome\n   paragraph instead. A finished WordPress blog build looks like this:\n\n   | Stage | Result |\n   |---|---|\n   | connect | Hostinger connector reached over MCP (`@hostinger/mcp` 1.9.2); signed in through the browser login. |\n   | 1 check state | New build for `harbourlight.blog`; no earlier workspace. |\n   | 2 refine | Personal travel blog about coastal towns in the UK; backend: WordPress. |\n   | 3 provision | Business plan, order 41875230; setup took 6 min; domain, SSL and WordPress checks passed. |\n   | 4 content model | 5 pages, 8 posts, 6 categories, 1 menu, 14 images (Hostinger AI), SEO titles on every page; counts re-read from the REST API. |\n   | 5 design | \"Salt & Ink\" direction: serif headings, sea-blue accents; `design.md` and logo written, logo check passed. |\n   | 6 frontend | Next.js SSR with home, blog, post, category and contact pages wired to the REST API; local build passed. |\n   | 7 validate | Instance setup completed; REST API returned the 8 pushed posts; no preview (nobody signing off). |\n   | 8 deploy | Source uploaded, build finished in 3 min; site root returns 200. |\n   | 9 done | Main site, wp-admin and REST API re-checked live: all returned 200. |\n\n3. **Links** — every URL that exists at this point. Build the hPanel URLs from `site.json`\n   (`order_id`, `username`, `domain`) and the onboarding slug; take the rest from `site.json` /\n   `deploy.json`. Lead with the one the user cares about most — the **main site** — then the admin\n   and dashboards. **Don't list the success page here:** it opens on its own (see *Open the success\n   page*), so printing its URL in the report is just noise — the only exception is when a browser\n   can't be opened (handled in that section):\n\n   - **Main site (live):** `urls.site` (`https://<domain>`) — only once deployed.\n   - **WordPress admin (one-click auto-login):** for a WordPress backend, **mint and hand over the\n     auto-login redirect URL** — `wordpress_login_create-links { username, software: <site.json\n     wordpress.install_id> }` returns a temporary link that logs the user straight into wp-admin. Give\n     that URL as the admin link (it lands on `/cms/wp-admin`), so the user never needs a password. Also\n     note the plain `urls.wp_admin` as a fallback. **Never print or store a password.** For a\n     **WordPress + WooCommerce** store, this *same* wp-admin login is the store admin (wp-admin →\n     WooCommerce → Products/Orders) — do **not** use the Ecommerce `store_admin` path. **Call out the one\n     setup step under *Gaps / follow-ups*:** when `site.json → woocommerce.payment_enabled` is `false`,\n     the owner must enable a payment method + a shipping zone in WooCommerce → Settings before checkout\n     works (the catalog and cart already work). For a Hostinger **Ecommerce** store, link the store admin\n     from `urls.store_admin` instead.\n   - **hPanel site dashboard:** `https://hpanel.hostinger.com/websites/<domain>` (the headless website\n     is installed by now).\n   - **Onboarding (resume):** `https://hpanel.hostinger.com/headless-onboarding/<order_id>/<username>/`\n   - **REST API** (for developers): `urls.rest_api`.\n\n   > URL shape note: `<username>` may be dropped from the onboarding/success URLs in a future hPanel\n   > release. If a built URL 404s, retry the same path without the `/<username>` segment before\n   > reporting it as broken.\n\n4. **Where state lives** — the workspace path `~/.hostinger/<domain>/`, the `stage` that a\n   resumed run will start from, and the build report `~/.hostinger/<domain>/report.html`.\n\n5. **Gaps / follow-ups** (only if any) — a short numbered list of anything skipped, approximated or\n   left for the user (e.g. no images generated, default WordPress content left in place).\n\nNever include passwords, JWTs or other secrets in the report. For wp-admin access, give the URL and\noffer a one-click login link (`wordpress_login_create-links`), not credentials.\n\n## Verify the live site (brief)\n\nOn a run that deployed this session, re-confirm what you're about to hand over actually works (deploy\nalready checked this — this is a quick re-confirm, not a full re-run):\n\n- **Main site:** `GET https://<domain>/` → 200 (Next.js SSR: `x-powered-by: Next.js`; Astro SSG: static\n  HTML with real content).\n- **WordPress admin:** `GET {urls.wp_admin}` → reachable (a login page, 200/302), not 404.\n- **Backend API:** `GET {urls.rest_api}/posts?per_page=1` → 200 (WordPress); for a **WooCommerce** store\n  (`site.json → woocommerce.enabled`) also `GET {urls.store_api}/products?per_page=1` → 200; or the\n  storefront API for the sales channel → 200 (Ecommerce).\n- **Contact form** (`site.json → contact_form.enabled`): validate already sent a test submission, so\n  don't send another here. In the handover, tell the owner the contact page is live and enquiries email\n  the **WordPress admin address** (via `wp_mail`) — and that for the most reliable delivery that address\n  should be a Hostinger mailbox on the domain. If validate reported `mail_failed`, say so plainly instead\n  of claiming the form sends.\n\nIf a check fails, say so in the outcome paragraph and don't claim the site is live.\n\n## Open the success page\n\nOn a **successful** run (the deploy succeeded and the live checks passed), open the success page in the\nuser's **main / system browser** right after presenting the report, so they land on the hPanel\ncelebration/next-steps screen for their new site. This is a side effect only — **don't print the\nsuccess URL in the report output** (it just opens); the one exception is the can't-open-a-browser\nfallback below. Build the URL with `<tool>` as the running tool's onboarding slug (see *State and\nartifacts* in the top-level `SKILL.md`):\n\n```bash\n# Build the URL first, then open it with the OS default (main) browser — not an embedded one.\n# <tool> = the onboarding slug\nURL=\"https://hpanel.hostinger.com/headless-onboarding/<order_id>/<username>/success/<domain>/<tool>\"\nopen \"$URL\"        # macOS\n# xdg-open \"$URL\"  # Linux\n# start \"\" \"$URL\"  # Windows\n```\n\n- **Main browser only.** Use the OS opener above (`open` / `xdg-open` / `start`) so the page lands in\n  Chrome, Safari, Edge, or whatever the user actually uses. **Do not** open it in an embedded or\n  sandboxed browser (Cursor IDE browser / `cursor-ide-browser`, Playwright, Puppeteer, WebView, or\n  any in-agent browser tab). Those stay inside the tool session and the user won't see the\n  celebration page where they expect it.\n- Open it **once**, and only on a successful run — never on an early stop or a failed deploy.\n- If your tool can't open a browser (the command isn't available, or `open`/`xdg-open`/`start`\n  fails), don't treat it as a failure and **don't fall back to an embedded browser**. This is the\n  **one** case where you print the success URL — show it once in the report and tell the user to\n  open it themselves in their main browser.\n\n## Build report\n\nRight after the final report, save the build report for this run. It turns the run log (stage times\nfrom `run-log.json`, events from `events.jsonl`) into `reports/<run>.json` and `.html`, and copies the\nHTML to `report.html` in the workspace:\n\n```bash\nnode <skill>/run-log.mjs <domain> event good '{\"text\":\"<something that went well>\"}'   # one per thing, if not logged yet\nnode <skill>/run-log.mjs <domain> stage-end done ok\nnode <skill>/run-log.mjs <domain> report --outcome <live|stopped|failed> [--tokens '<json>']\n```\n\nThen send it to Hostinger: pass `reports/<run>.json` unchanged to `hosting_headless_submit-build-report`\nand run `report-sent <run>` (or `report-rejected <run>` on a 422). The `report` command prints the\nexact path and run id. Don't ask first; see *Run log and build report* in the top-level `SKILL.md`\nfor failures. Then tell the user in one line: \"Sent the build report to Hostinger to help improve\nthe flow.\" On a 422 say it's saved locally only; on any other failure say it'll be sent next session.\n\nIf the user asks for more changes after this report in the same session, call\n`run-log.mjs <domain> run-resume --reason \"<what they asked for>\"` before the work. Then log as\nusual and run `report` again when it's done. It updates this run's report in place, and the report\nlists the follow-up. Send the updated report the same way.\n\n- **Outcome:** `live` when the deploy succeeded this run, `failed` when a stage failed and you\n  couldn't recover, `stopped` for everything else (the user paused, a dummy or missing step). Leave\n  `--outcome` out and the script decides from the log.\n- **Before you write it,** check that every issue, correction and skill gap from this run is in\n  `events.jsonl`. Log any that are missing now; the report only shows what was logged.\n- **After you write it,** read the `warning:` lines `report` prints. They list logging gaps: a stage\n  that never ended, a start that was estimated, a stage logged with no duration, or (on a live build)\n  a stage that was never logged. Fix what you can: `stage-end` an open stage, or correct a start with\n  `stage-fix <stage> --started-ago <time>`, then run `report` again. What you can't fix stays in the report's\n  *Logging gaps* section.\n- **Tokens:** only what your tool tells you about your own usage (see *Run log and build report* in\n  the top-level `SKILL.md`).\n- In the final report's *Where state lives*, add the path to `report.html` so the user can open it.\n\nDo this on every run, including the early stops: those reports are the most useful ones.\n"
+        "text": "---\nname: headless-step-done\ndescription: \"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 plus explicit next steps — how to log in to wp-admin and reset the password, how to manage content, and how to finish WooCommerce/store setup so it can take orders. Its final report format is also used whenever a run stops early.\"\n---\n\n# headless-step-done\n\nVerify the live site, then hand over the URLs (success page, main site, WordPress admin, dashboard), a\nsummary of what was built, and what the user can do next. **On a successful run, open the success page\nfor the user** (see *Open the success page*).\n\n## Final report\n\nEvery run ends with this report, whether it finishes here or stops at an earlier stage (a dummy or\nmissing step, a failed provision, the user pausing). On a run that deployed this session, run the\nchecks in *Verify the live site* below first. Build the report from `state.json`, `site.json`,\n`deploy.json` and what you actually did and checked in this run. Report only what you verified. Don't\nclaim a stage passed if you didn't check it.\n\nWrite it in this order:\n\n1. **One-paragraph outcome.** What was created and on which domain (bold it). If the run stopped\n   early, name the stage it stopped at, why, and what the user will see right now (e.g. \"the site\n   root returns 403 until the frontend is deployed\").\n\n2. **Steps completed.** This table is required on every run, including early stops: never replace\n   it with prose. Give one row per stage that ran, using the stage numbers and names from the\n   orchestrator's flow table. Leave out stages that didn't run and name them in the outcome\n   paragraph instead. A finished WordPress blog build looks like this:\n\n   | Stage | Result |\n   |---|---|\n   | connect | Hostinger connector reached over MCP (`@hostinger/mcp` 1.9.2); signed in through the browser login. |\n   | 1 check state | New build for `harbourlight.blog`; no earlier workspace. |\n   | 2 refine | Personal travel blog about coastal towns in the UK; backend: WordPress. |\n   | 3 provision | Business plan, order 41875230; setup took 6 min; domain, SSL and WordPress checks passed. |\n   | 4 content model | 5 pages, 8 posts, 6 categories, 1 menu, 14 images (Hostinger AI), SEO titles on every page; counts re-read from the REST API. |\n   | 5 design | \"Salt & Ink\" direction: serif headings, sea-blue accents; `design.md` and logo written, logo check passed. |\n   | 6 frontend | Next.js SSR with home, blog, post, category and contact pages wired to the REST API; local build passed. |\n   | 7 validate | Instance setup completed; REST API returned the 8 pushed posts; no preview (nobody signing off). |\n   | 8 deploy | Source uploaded, build finished in 3 min; site root returns 200. |\n   | 9 done | Main site, wp-admin and REST API re-checked live: all returned 200. |\n\n3. **Links** — every URL that exists at this point. Build the hPanel URLs from `site.json`\n   (`order_id`, `username`, `domain`) and the onboarding slug; take the rest from `site.json` /\n   `deploy.json`. Lead with the one the user cares about most — the **main site** — then the admin\n   and dashboards. **Don't list the success page here:** it opens on its own (see *Open the success\n   page*), so printing its URL in the report is just noise — the only exception is when a browser\n   can't be opened (handled in that section):\n\n   - **Main site (live):** `urls.site` (`https://<domain>`) — only once deployed.\n   - **WordPress admin (one-click auto-login):** for a WordPress backend, **mint and hand over the\n     auto-login redirect URL** — `wordpress_login_create-links { username, software: <site.json\n     wordpress.install_id> }` returns a temporary link that logs the user straight into wp-admin. Give\n     that URL as the admin link (it lands on `/cms/wp-admin`), so the user never needs a password.\n     Alongside it, give the two ways back in that don't expire: the **login URL `{urls.wp_admin}`**\n     (`https://<domain>/cms/wp-admin` — the headless WordPress lives under `/cms`), and the **WP Admin\n     button in hPanel** (hPanel → the website → *WP Admin*). Note how to **reset the password**: on the\n     `/cms/wp-admin` login screen use **\"Lost your password?\"**, and WordPress emails a reset link to the\n     **WordPress admin email** (the address set at install, which the owner already has) — see *Next\n     steps* for an optional deliverability tip.\n     **Never print or store a password.** For a **WordPress + WooCommerce** store, this *same* wp-admin\n     login is the store admin (wp-admin → WooCommerce → Products/Orders) — do **not** use the Ecommerce\n     `store_admin` path; the store setup the owner still needs is spelled out under *Next steps*. For a\n     Hostinger **Ecommerce** store, link the store admin from `urls.store_admin` instead.\n   - **hPanel site dashboard:** `https://hpanel.hostinger.com/websites/<domain>` (the headless website\n     is installed by now).\n   - **Onboarding (resume):** `https://hpanel.hostinger.com/headless-onboarding/<order_id>/<username>/`\n   - **REST API** (for developers): `urls.rest_api`.\n\n   > URL shape note: `<username>` may be dropped from the onboarding/success URLs in a future hPanel\n   > release. If a built URL 404s, retry the same path without the `/<username>` segment before\n   > reporting it as broken.\n\n4. **Next steps** — what the user does now to actually use the site. Required on a successful run;\n   tailor the bullets to the backend and keep them concrete. This is the hand-holding the hPanel\n   success page can't give: don't just link wp-admin, tell them what to do once they're in.\n\n   - **Manage content (WordPress):** in wp-admin (the one-click link, the `/cms/wp-admin` login URL, or\n     hPanel → *WP Admin*) → **Posts**, **Pages**, **Media**, **Appearance → Menus**. Say how edits reach\n     the live site for *this* build: an **SSR** frontend re-reads the REST API each request, so changes\n     show up with no redeploy; an **SSG/static** build must be redeployed to pick up new content (read\n     `state.json → frontend.rendering`).\n   - **Log in later & reset the password:** repeat the two non-expiring routes (the `/cms/wp-admin` login\n     URL and hPanel's *WP Admin* button) and the **\"Lost your password?\"** reset. The reset link goes to\n     the **WordPress admin email** — the address set at install, which the owner already has — so nothing\n     extra is needed to receive it. Optionally, for more reliable delivery, they can create a mailbox on\n     the domain (hPanel → *Emails*) and set it as the admin address in **wp-admin → Settings → General**.\n   - **WordPress + WooCommerce — finish store setup so it can take orders.** The catalog and cart already\n     work, but **checkout stays off until the owner configures it in wp-admin**: WooCommerce → Settings →\n     **Payments** (enable at least one method) and → **Shipping** (add a zone with a rate), then confirm\n     products/prices and place a test order. When `site.json → woocommerce.payment_enabled` is `false`,\n     state plainly that this step is **required before any purchase works** — this is the gap owners hit.\n   - **Hostinger Ecommerce store:** when `site.json → ecommerce.payment_enabled` is `false`, finish\n     payment setup in the store admin (`urls.store_admin`) before the storefront can sell; otherwise it's\n     ready to take orders.\n   - **Webapp:** manage the app from hPanel → the website (environment variables, deployments, logs).\n\n5. **Where state lives** — the workspace path `~/.hostinger/<domain>/`, the `stage` that a\n   resumed run will start from, and the build report `~/.hostinger/<domain>/report.html`.\n\n6. **Gaps / follow-ups** (only if any) — a short numbered list of anything skipped, approximated or\n   left for the user (e.g. no images generated, default WordPress content left in place).\n\nNever include passwords, JWTs or other secrets in the report. For wp-admin access, give the URL and\noffer a one-click login link (`wordpress_login_create-links`), not credentials.\n\n## Verify the live site (brief)\n\nOn a run that deployed this session, re-confirm what you're about to hand over actually works (deploy\nalready checked this — this is a quick re-confirm, not a full re-run):\n\n- **Main site:** `GET https://<domain>/` → 200 (Next.js SSR: `x-powered-by: Next.js`; Astro SSG: static\n  HTML with real content).\n- **WordPress admin:** `GET {urls.wp_admin}` → reachable (a login page, 200/302), not 404.\n- **Backend API:** `GET {urls.rest_api}/posts?per_page=1` → 200 (WordPress); for a **WooCommerce** store\n  (`site.json → woocommerce.enabled`) also `GET {urls.store_api}/products?per_page=1` → 200; or the\n  storefront API for the sales channel → 200 (Ecommerce).\n- **Contact form** (`site.json → contact_form.enabled`): validate already sent a test submission, so\n  don't send another here. In the handover, tell the owner the contact page is live and enquiries email\n  the **WordPress admin address** (via `wp_mail`) — and that for the most reliable delivery that address\n  should be a Hostinger mailbox on the domain. If validate reported `mail_failed`, say so plainly instead\n  of claiming the form sends.\n\nIf a check fails, say so in the outcome paragraph and don't claim the site is live.\n\n## Open the success page\n\nOn a **successful** run (the deploy succeeded and the live checks passed), open the success page in the\nuser's **main / system browser** right after presenting the report, so they land on the hPanel\ncelebration/next-steps screen for their new site. This is a side effect only — **don't print the\nsuccess URL in the report output** (it just opens); the one exception is the can't-open-a-browser\nfallback below. Build the URL with `<tool>` as the running tool's onboarding slug (see *State and\nartifacts* in the top-level `SKILL.md`):\n\n```bash\n# Build the URL first, then open it with the OS default (main) browser — not an embedded one.\n# <tool> = the onboarding slug\nURL=\"https://hpanel.hostinger.com/headless-onboarding/<order_id>/<username>/success/<domain>/<tool>\"\nopen \"$URL\"        # macOS\n# xdg-open \"$URL\"  # Linux\n# start \"\" \"$URL\"  # Windows\n```\n\n- **Main browser only.** Use the OS opener above (`open` / `xdg-open` / `start`) so the page lands in\n  Chrome, Safari, Edge, or whatever the user actually uses. **Do not** open it in an embedded or\n  sandboxed browser (Cursor IDE browser / `cursor-ide-browser`, Playwright, Puppeteer, WebView, or\n  any in-agent browser tab). Those stay inside the tool session and the user won't see the\n  celebration page where they expect it.\n- Open it **once**, and only on a successful run — never on an early stop or a failed deploy.\n- If your tool can't open a browser (the command isn't available, or `open`/`xdg-open`/`start`\n  fails), don't treat it as a failure and **don't fall back to an embedded browser**. This is the\n  **one** case where you print the success URL — show it once in the report and tell the user to\n  open it themselves in their main browser.\n\n## Build report\n\nRight after the final report, save the build report for this run. It turns the run log (stage times\nfrom `run-log.json`, events from `events.jsonl`) into `reports/<run>.json` and `.html`, and copies the\nHTML to `report.html` in the workspace:\n\n```bash\nnode <skill>/run-log.mjs <domain> event good '{\"text\":\"<something that went well>\"}'   # one per thing, if not logged yet\nnode <skill>/run-log.mjs <domain> stage-end done ok\nnode <skill>/run-log.mjs <domain> report --outcome <live|stopped|failed> [--tokens '<json>']\n```\n\nThen send it to Hostinger: pass `reports/<run>.json` unchanged to `hosting_headless_submit-build-report`\nand run `report-sent <run>` (or `report-rejected <run>` on a 422). The `report` command prints the\nexact path and run id. Don't ask first; see *Run log and build report* in the top-level `SKILL.md`\nfor failures. Then tell the user in one line: \"Sent the build report to Hostinger to help improve\nthe flow.\" On a 422 say it's saved locally only; on any other failure say it'll be sent next session.\n\nIf the user asks for more changes after this report in the same session, call\n`run-log.mjs <domain> run-resume --reason \"<what they asked for>\"` before the work. Then log as\nusual and run `report` again when it's done. It updates this run's report in place, and the report\nlists the follow-up. Send the updated report the same way.\n\n- **Outcome:** `live` when the deploy succeeded this run, `failed` when a stage failed and you\n  couldn't recover, `stopped` for everything else (the user paused, a dummy or missing step). Leave\n  `--outcome` out and the script decides from the log.\n- **Before you write it,** check that every issue, correction and skill gap from this run is in\n  `events.jsonl`. Log any that are missing now; the report only shows what was logged.\n- **After you write it,** read the `warning:` lines `report` prints. They list logging gaps: a stage\n  that never ended, a start that was estimated, a stage logged with no duration, or (on a live build)\n  a stage that was never logged. Fix what you can: `stage-end` an open stage, or correct a start with\n  `stage-fix <stage> --started-ago <time>`, then run `report` again. What you can't fix stays in the report's\n  *Logging gaps* section.\n- **Tokens:** only what your tool tells you about your own usage (see *Run log and build report* in\n  the top-level `SKILL.md`).\n- In the final report's *Where state lives*, add the path to `report.html` so the user can open it.\n\nDo this on every run, including the early stops: those reports are the most useful ones.\n"
       }
     ]
   },

package/src/servers/agency-hosting.js

@@ -4,4 +4,4 @@ import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/agency-hosting.js';
 import instructions from '../core/instructions.agency-hosting.js';
 
-startServer({ name: 'hostinger-agency-hosting-mcp', version: '3.23.2', tools, instructions });
+startServer({ name: 'hostinger-agency-hosting-mcp', version: '3.24.0', tools, instructions });

package/src/servers/agency-hosting.ts

@@ -4,4 +4,4 @@ import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/agency-hosting.js';
 import instructions from '../core/instructions.agency-hosting.js';
 
-startServer({ name: 'hostinger-agency-hosting-mcp', version: '3.23.2', tools, instructions });
+startServer({ name: 'hostinger-agency-hosting-mcp', version: '3.24.0', tools, instructions });

package/src/servers/agent-readiness.js

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/agent-readiness.js';
 
-startServer({ name: 'hostinger-agent-readiness-mcp', version: '3.23.2', tools });
+startServer({ name: 'hostinger-agent-readiness-mcp', version: '3.24.0', tools });

package/src/servers/agent-readiness.ts

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/agent-readiness.js';
 
-startServer({ name: 'hostinger-agent-readiness-mcp', version: '3.23.2', tools });
+startServer({ name: 'hostinger-agent-readiness-mcp', version: '3.24.0', tools });

package/src/servers/all.js

@@ -5,4 +5,4 @@ import tools from '../core/tools/all.js';
 import instructions from '../core/instructions.js';
 import skills from '../core/skills.js';
 
-startServer({ name: 'hostinger-api-mcp', version: '3.23.2', tools, instructions, skills });
+startServer({ name: 'hostinger-api-mcp', version: '3.24.0', tools, instructions, skills });

package/src/servers/all.ts

@@ -5,4 +5,4 @@ import tools from '../core/tools/all.js';
 import instructions from '../core/instructions.js';
 import skills from '../core/skills.js';
 
-startServer({ name: 'hostinger-api-mcp', version: '3.23.2', tools, instructions, skills });
+startServer({ name: 'hostinger-api-mcp', version: '3.24.0', tools, instructions, skills });

package/src/servers/billing.js

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/billing.js';
 
-startServer({ name: 'hostinger-billing-mcp', version: '3.23.2', tools });
+startServer({ name: 'hostinger-billing-mcp', version: '3.24.0', tools });

package/src/servers/billing.ts

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/billing.js';
 
-startServer({ name: 'hostinger-billing-mcp', version: '3.23.2', tools });
+startServer({ name: 'hostinger-billing-mcp', version: '3.24.0', tools });

package/src/servers/dns.js

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/dns.js';
 
-startServer({ name: 'hostinger-dns-mcp', version: '3.23.2', tools });
+startServer({ name: 'hostinger-dns-mcp', version: '3.24.0', tools });

package/src/servers/dns.ts

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/dns.js';
 
-startServer({ name: 'hostinger-dns-mcp', version: '3.23.2', tools });
+startServer({ name: 'hostinger-dns-mcp', version: '3.24.0', tools });

package/src/servers/domains.js

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/domains.js';
 
-startServer({ name: 'hostinger-domains-mcp', version: '3.23.2', tools });
+startServer({ name: 'hostinger-domains-mcp', version: '3.24.0', tools });

package/src/servers/domains.ts

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/domains.js';
 
-startServer({ name: 'hostinger-domains-mcp', version: '3.23.2', tools });
+startServer({ name: 'hostinger-domains-mcp', version: '3.24.0', tools });

package/src/servers/ecommerce.js

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/ecommerce.js';
 
-startServer({ name: 'hostinger-ecommerce-mcp', version: '3.23.2', tools });
+startServer({ name: 'hostinger-ecommerce-mcp', version: '3.24.0', tools });

package/src/servers/ecommerce.ts

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/ecommerce.js';
 
-startServer({ name: 'hostinger-ecommerce-mcp', version: '3.23.2', tools });
+startServer({ name: 'hostinger-ecommerce-mcp', version: '3.24.0', tools });

package/src/servers/horizons.js

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/horizons.js';
 
-startServer({ name: 'hostinger-horizons-mcp', version: '3.23.2', tools });
+startServer({ name: 'hostinger-horizons-mcp', version: '3.24.0', tools });

package/src/servers/horizons.ts

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/horizons.js';
 
-startServer({ name: 'hostinger-horizons-mcp', version: '3.23.2', tools });
+startServer({ name: 'hostinger-horizons-mcp', version: '3.24.0', tools });

package/src/servers/hosting.js

@@ -4,4 +4,4 @@ import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/hosting.js';
 import instructions from '../core/instructions.js';
 
-startServer({ name: 'hostinger-hosting-mcp', version: '3.23.2', tools, instructions });
+startServer({ name: 'hostinger-hosting-mcp', version: '3.24.0', tools, instructions });

package/src/servers/hosting.ts

@@ -4,4 +4,4 @@ import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/hosting.js';
 import instructions from '../core/instructions.js';
 
-startServer({ name: 'hostinger-hosting-mcp', version: '3.23.2', tools, instructions });
+startServer({ name: 'hostinger-hosting-mcp', version: '3.24.0', tools, instructions });

package/src/servers/mail.js

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/mail.js';
 
-startServer({ name: 'hostinger-mail-mcp', version: '3.23.2', tools });
+startServer({ name: 'hostinger-mail-mcp', version: '3.24.0', tools });

package/src/servers/mail.ts

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/mail.js';
 
-startServer({ name: 'hostinger-mail-mcp', version: '3.23.2', tools });
+startServer({ name: 'hostinger-mail-mcp', version: '3.24.0', tools });

package/src/servers/reach.js

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/reach.js';
 
-startServer({ name: 'hostinger-reach-mcp', version: '3.23.2', tools });
+startServer({ name: 'hostinger-reach-mcp', version: '3.24.0', tools });

package/src/servers/reach.ts

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/reach.js';
 
-startServer({ name: 'hostinger-reach-mcp', version: '3.23.2', tools });
+startServer({ name: 'hostinger-reach-mcp', version: '3.24.0', tools });

package/src/servers/vps.js

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/vps.js';
 
-startServer({ name: 'hostinger-vps-mcp', version: '3.23.2', tools });
+startServer({ name: 'hostinger-vps-mcp', version: '3.24.0', tools });

package/src/servers/vps.ts

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/vps.js';
 
-startServer({ name: 'hostinger-vps-mcp', version: '3.23.2', tools });
+startServer({ name: 'hostinger-vps-mcp', version: '3.24.0', tools });

package/src/servers/wordpress.js

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/wordpress.js';
 
-startServer({ name: 'hostinger-wordpress-mcp', version: '3.23.2', tools });
+startServer({ name: 'hostinger-wordpress-mcp', version: '3.24.0', tools });

package/src/servers/wordpress.ts

@@ -3,4 +3,4 @@
 import { startServer } from '../core/runtime.js';
 import tools from '../core/tools/wordpress.js';
 
-startServer({ name: 'hostinger-wordpress-mcp', version: '3.23.2', tools });
+startServer({ name: 'hostinger-wordpress-mcp', version: '3.24.0', tools });