hostinger-api-mcp 3.17.1 → 3.17.2

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.17.2 — 2026-10-27
+
+### Also in this release
+
+- Bundled agent skills: `skills/headless/steps/01-check-state/SKILL.md`
+- Other files: `src/core/skills.js`, `src/core/skills.ts`
+
 ## v3.17.1 — 2026-10-27
 
 No changes to the published artifact.

package/gemini-extension.json

@@ -1,6 +1,6 @@
 {
   "name": "hostinger-api-mcp",
-  "version": "3.17.1",
+  "version": "3.17.2",
   "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.17.1",
+  "version": "3.17.2",
   "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.17.1",
+  "version": "3.17.2",
   "packages": [
     {
       "registryType": "npm",
       "identifier": "@hostinger/mcp",
-      "version": "3.17.1",
+      "version": "3.17.2",
       "transport": {
         "type": "stdio"
       },

package/skills/headless/steps/01-check-state/SKILL.md

@@ -115,10 +115,15 @@ Query the Hostinger connector — the local files are never trusted on their own
 - **Tell hPanel the tool connected.** As soon as you have the exact row, call
   `hosting_websites_trigger-event { "username": "<row username>", "domain": "<domain>", "event": { "name": "headless_onboarding.tool.connected", "params": { "tool": "<slug>" } } }`
   once, where `<slug>` is the onboarding slug (see *State and artifacts* in the top-level `SKILL.md`).
-  This flips hPanel's onboarding card to "connected". Don't ask first and don't mention it. Skip the
-  call when there's no exact row or your tool has no onboarding slug. If
-  `hosting_websites_trigger-event` isn't in your connector, or the call returns an error,
-  ignore it: no retry, nothing said to the user, and the run carries on unchanged.
+  The call is required: hPanel's onboarding card waits for it to switch to "connected". Skip the
+  call when there's no exact row, your tool has no onboarding slug, or
+  `hosting_websites_trigger-event` isn't in your connector. Right before the call, tell the user in
+  one line (e.g. "Telling hPanel <your tool> is connected so your onboarding card updates."), so
+  whoever reviews the outgoing call knows why it's made. If your own environment stopped the call
+  before it reached Hostinger (a sandbox, command review, an approval prompt, or a network error in
+  a sandboxed shell), try it one more time the way that environment allows, such as requesting
+  approval or network access, then go on. Ignore any other failure, such as a non-2xx response from
+  Hostinger: no retry, nothing more said to the user, and the run carries on unchanged.
 - **How far did it get?** If the site exists, check its setup via
   `hosting_websites_list-setups { "domain": "<domain>" }` (exact-match the row the same way):
   - `status: completed` → provisioned; then, depending on backend, check whether a build has succeeded.

package/src/core/skills.js

@@ -134,10 +134,10 @@ export default [
       },
       {
         "uri": "skill://hostinger-headless/steps/01-check-state/SKILL.md",
-        "digest": "sha256:043f25855abf92f43728b6e442bbd8d580fd2a6bb0270cfa7ed95dd41050ee60",
-        "size": 13227,
+        "digest": "sha256:e4f6aa7823639670b6f862b309c7fce1210b5f558087a54c41b9f736aad442cd",
+        "size": 13726,
         "mimeType": "text/markdown",
-        "text": "---\nname: headless-step-check-state\ndescription: \"First build step of the Hostinger Headless flow, run right after connect. Works out where a given domain's build stands — is a run already in progress, does the site already exist, how far did it get — by reconciling the global workspace state under ~/.hostinger/<domain>/ with what the Hostinger connector reports, then guides the user to continue, switch or buy a domain, or start over. Owns all resume/position logic for the flow.\"\n---\n\n# headless-step-check-state\n\nThe first build step of the Hostinger Headless flow (orchestrated by `hostinger.com/headless/skill.md`),\nrun right after connect. Connect has already connected the Hostinger connector and confirmed the\naccount can build. Your job here is to\n**figure out where this domain stands and agree the route with the user** before any new work begins.\nThis step owns all resume/position logic — no other stage second-guesses it.\n\nNothing in this step creates, provisions, deploys, or deletes anything. It reads and guides. Its\nonly writes to Hostinger are unsent build reports (Step 0) and the tool-connected event (Step 3).\n\n---\n\n## Where state lives\n\nEverything for a domain lives under the global site workspace **`~/.hostinger/<domain>/`** — one\ndirectory per domain, under the user's home (`~` = `$HOME`), **not** the current working directory.\nThe directory name **is** the domain, so `state.json` inside does not store it. Because it's global,\nthis domain's build is resumable from any directory.\n\n`state.json` shape (`stage` is the *next* stage to run; `provision` is the background task's status,\npresent only once provision has fired):\n\n```json\n{ \"tool\": \"claude-code\", \"stage\": \"content_model\",\n  \"provision\": { \"status\": \"in_progress\", \"domain\": \"<domain>\", \"started_at\": \"…\" },\n  \"updated_at\": \"…\" }\n```\n\n`provision.status` is `in_progress` or `completed` — but it is a **hint**: always re-verify it against\n`hosting_websites_list-setups` (Step 1) before trusting it to gate an instance-barrier step.\n\n---\n\n## Step 0 — Start the run log\n\nBefore anything else, start a run and the stage (see *Run log and build report* in the top-level\n`SKILL.md`):\n\n```bash\nnode <skill>/run-log.mjs <domain> run-start --tool <tool> --model <model> --skill <skill version>\nnode <skill>/run-log.mjs <domain> stage-start check_state\n```\n\nIf an earlier run on this domain never wrote its report, `run-start` closes it as `abandoned` first.\n\nThen send any build reports that haven't reached Hostinger yet (that abandoned run, or a send that\nfailed last time):\n\n```bash\nnode <skill>/run-log.mjs <domain> unsent\n```\n\nEach line is `<run> <path>`. For each, send the file through `hosting_headless_submit-build-report`\nand record the result, as described in *Run log and build report* in the top-level `SKILL.md`. One\ntry each. Don't ask first; if any went out, say so in one line (e.g. \"Sent 1 earlier build report to\nHostinger.\"). Don't let a failure hold up this step.\nCheck-state runs once per session. A follow-up after the final report, in the same session, doesn't\ncome back here: it calls `run-resume` (see *Run log and build report* in the top-level `SKILL.md`).\n\n## Step 1 — Is a build actively running right now? (check this before anything else)\n\nKeep two things separate, and **never guess from a timestamp.**\n\n- **A platform build actively in progress** — the only *reliable* \"running now\" signal. Check\n  `hosting_websites_list-setups { \"domain\": \"<domain>\" }` and exact-match the domain row:\n  - `status: running` → provisioning is underway **right now** (a background provision from an earlier\n    turn). Don't start a second one — reconcile `state.json`'s `provision` to `in_progress`, and\n    either resume prepare work while it finishes or poll it to `completed` at the barrier.\n  - `status: failed` → not running; route to provision to self-heal (Step 3).\n  - `completed` → provision is done; set `provision.status` to `completed`. Instance-barrier steps\n    (content push, frontend data, deploy) are now unblocked.\n  - no row → not provisioned yet; carry on.\n\n  This check **is** the source of truth for `provision.status`: a stored `in_progress`/`completed` in\n  `state.json` is only a hint until this reconciles it.\n\n- **A `.lock`** — `~/.hostinger/<domain>/.lock`. It only tells you *a previous run\n  touched this domain*. **Do not judge it by age** — a 2-minute-old lock and a 3-year-old lock get the\n  same treatment, and a lock on its own is **not** a reason to interrupt the user. Carry it into Step 5:\n  if there's nothing to resume (new build), silently take it over; only if there's real state to resume\n  do you also ask *is another Claude window building this domain right now?* (yes → stop; no → take\n  over).\n\nOnce you're actively working this domain, **acquire/refresh the lock** (write the current timestamp),\nand **release it on a clean stop** (Step 6). The lock marks an active session, nothing more.\n\n---\n\n## Step 2 — Read the workspace directory\n\nCheck `~/.hostinger/<domain>/` by its exact path (for example `test -d ~/.hostinger/<domain>`), not\nby listing `~/.hostinger/`:\n\n- **Absent** → no history for this domain in the workspace.\n- **Present** → read `state.json` (its `stage`) and whatever artifacts exist (`brief.md`,\n  `site.json`, …). Treat these as a hint, not the truth.\n\n---\n\n## Step 3 — Verify against reality (reality wins)\n\nQuery the Hostinger connector — the local files are never trusted on their own:\n\n- **Does the site exist?** `hosting_websites_list { \"domain\": \"<domain>\" }`. ⚠️ This filter is a\n  **case-insensitive substring match**, not exact — so `test.com` would also return\n  `shop.test.com`. **Compare each returned row's `domain` to your target for an *exact* match**\n  (case-insensitive) and ignore the rest. No exact row ⇒ the domain is free. An exact row ⇒ the site\n  exists; note its `website_type` (`headless`, `wordpress`, `nodejs`, …) and `username`.\n- **Tell hPanel the tool connected.** As soon as you have the exact row, call\n  `hosting_websites_trigger-event { \"username\": \"<row username>\", \"domain\": \"<domain>\", \"event\": { \"name\": \"headless_onboarding.tool.connected\", \"params\": { \"tool\": \"<slug>\" } } }`\n  once, where `<slug>` is the onboarding slug (see *State and artifacts* in the top-level `SKILL.md`).\n  This flips hPanel's onboarding card to \"connected\". Don't ask first and don't mention it. Skip the\n  call when there's no exact row or your tool has no onboarding slug. If\n  `hosting_websites_trigger-event` isn't in your connector, or the call returns an error,\n  ignore it: no retry, nothing said to the user, and the run carries on unchanged.\n- **How far did it get?** If the site exists, check its setup via\n  `hosting_websites_list-setups { \"domain\": \"<domain>\" }` (exact-match the row the same way):\n  - `status: completed` → provisioned; then, depending on backend, check whether a build has succeeded.\n  - `status: running` → still provisioning (see Step 1).\n  - `status: failed` → provisioning stopped before finishing → route to **provision** to self-heal.\n- **Is it an empty headless shell from onboarding?** A `headless` site whose setup is `completed` is\n  **not necessarily finished** — onboarding now creates the website *before* the build runs, as an\n  **empty headless shell** (`hosting_websites_start-setup { type: \"headless_empty\" }`): `website_type`\n  is `headless` but **no backend is installed** (no WordPress at `/cms`, no store). Tell a shell from a\n  real backend the same way provision does: within 24 h the setup `type` is `headless_empty`; otherwise\n  `wordpress_installations_list { username, domain, ownership: \"all\" }` returns **no** `/cms` row and\n  there is no `site.json` recording a backend. An empty shell means **provision has not chosen or\n  installed a backend yet** — this is a **new build** that happens to already own its website, not a\n  finished or resumable one. Route it to **refine** (choose the backend), then **provision** adopts the\n  shell and swaps it to that backend (see the provision router's *Onboarding handoff*). Never create a\n  second site, and never skip provision for it.\n\nReconcile with the local state. **When they disagree, reality wins** and the local `stage` is\ncorrected.\n\n---\n\n## Step 4 — Determine the position\n\nConnect always writes `state.json` (with `stage: check_state`) before this step runs, so local\nstate is never truly empty. **\"Local state: none\" here means only connect artifacts exist** —\n`connect.json` + a `state.json` still pointing at `check_state`/`refine`, and **no build artifacts\nyet** (`brief.md`, `site.json`, …).\n\n| Local state | Reality (domain) | Position |\n|---|---|---|\n| none (connect only) | free | **new build** — start from refine |\n| none (connect only) | empty headless shell (onboarding) | **new build on an existing shell** — start from refine; provision adopts the shell and swaps it to the chosen backend. Never create a second site, never skip provision |\n| none (connect only) | site exists with a real backend | **adopt / resume** — never create a second site; route to the first unfinished stage |\n| build artifacts present, incomplete | matches | **resume** at `state.json`'s `stage` |\n| build artifacts present | disagrees | **reality wins** — recompute the stage from what actually exists |\n| build artifacts present, all done | live site exists | **finished** — this is now an *iterate* request, not a build |\n\n---\n\n## Step 5 — Guide the user\n\nThe question to ask depends on whether there is actually **something to resume** — i.e. **build\nartifacts** (`brief.md`, `site.json`, …) or a **live site** for this domain. A stray `.lock` or\nconnect-only files are *not* something to resume.\n\n- **New build** (no build artifacts and either the domain is free **or** it holds only an empty\n  headless shell from onboarding) → just proceed to refine. **Don't ask resume vs start over** —\n  there's nothing to resume; both would land in the same place. An empty headless shell is not\n  \"something to resume\": it has no backend and no content yet, so it's a fresh build that already owns\n  its website — provision will adopt and swap it. Mention it in one line (\"Using the headless site\n  onboarding already created for this domain.\"). If a leftover `.lock` is lying around, silently take\n  it over and continue (optionally mention it in one line).\n- **Something to resume** (build artifacts exist, or a site exists for the domain **with a real backend\n  installed** — WordPress at `/cms`, a store, or a deployed app) → tell the user plainly what's there\n  and **ask them to choose**, regardless of how old it is (don't guess from timestamps):\n\n- **Resume** — pick up at the computed stage. (If a `.lock` is present in this case, also confirm no\n  other window is actively building this domain right now.)\n- **Start over / redo a step** — only safe **before anything is provisioned**. If the site is already\n  provisioned or live, you **cannot** re-create it: that is forward-only *iterate* (change content or\n  design and redeploy), not a fresh build. Never re-provision or overwrite a live site; if the user\n  insists on a clean slate for a live domain, explain the limitation and point them at hPanel.\n- **Switch domain** — they want a different domain. A new domain is a **new workspace**\n  (`~/.hostinger/<other-domain>/`, with its own `src/`). Hand off to start that domain's run.\n- **Buy a domain** — they want a custom domain instead of the temporary one. Route to the domain\n  purchase / `connect-domain` flow, then continue with the chosen domain.\n\nWhen the intent is ambiguous, **ask** — don't guess. A skipped tool result is ambiguous; see\n*When you ask the user* in the top-level `SKILL.md`.\n\n---\n\n## Step 6 — Record and route\n\nWrite `~/.hostinger/<domain>/state.json` with the agreed next `stage` and a fresh timestamp. If the\nroute isn't a new build, record it with `run-log.mjs <domain> run-update --kind resume` (or\n`redesign` / `iterate`), then end the stage with `stage-end check_state ok --note \"<the route>\"`.\nThen:\n\n- **Handing straight to the next stage in this same session?** Keep the `.lock` (you are still\n  actively running) and continue.\n- **Stopping and returning control to the user?** (e.g. the next stage isn't built yet, or you are\n  waiting on them.) **Delete the `.lock`** — the session is no longer active, and a leftover lock just\n  forces an unnecessary \"is another window running?\" question on the next run. Always release the lock\n  on a clean stop; it exists only to mark an actively-running session. A stop is still the end of a\n  run: give the final report and save the build report (`09-done`).\n\n---\n\n## Invariants\n\n- **One directory per domain.** The domain is the key; state files never repeat it.\n- **Only this domain's workspace.** Never list `~/.hostinger/` or open another site's workspace (see\n  *State and artifacts* in the top-level `SKILL.md`).\n- **Never create a second site** on a domain that already has one.\n- **Never re-provision or overwrite a live site.** Recovery is forward-only.\n- **Reality beats local state**, always.\n- **When ambiguous, ask.**\n"
+        "text": "---\nname: headless-step-check-state\ndescription: \"First build step of the Hostinger Headless flow, run right after connect. Works out where a given domain's build stands — is a run already in progress, does the site already exist, how far did it get — by reconciling the global workspace state under ~/.hostinger/<domain>/ with what the Hostinger connector reports, then guides the user to continue, switch or buy a domain, or start over. Owns all resume/position logic for the flow.\"\n---\n\n# headless-step-check-state\n\nThe first build step of the Hostinger Headless flow (orchestrated by `hostinger.com/headless/skill.md`),\nrun right after connect. Connect has already connected the Hostinger connector and confirmed the\naccount can build. Your job here is to\n**figure out where this domain stands and agree the route with the user** before any new work begins.\nThis step owns all resume/position logic — no other stage second-guesses it.\n\nNothing in this step creates, provisions, deploys, or deletes anything. It reads and guides. Its\nonly writes to Hostinger are unsent build reports (Step 0) and the tool-connected event (Step 3).\n\n---\n\n## Where state lives\n\nEverything for a domain lives under the global site workspace **`~/.hostinger/<domain>/`** — one\ndirectory per domain, under the user's home (`~` = `$HOME`), **not** the current working directory.\nThe directory name **is** the domain, so `state.json` inside does not store it. Because it's global,\nthis domain's build is resumable from any directory.\n\n`state.json` shape (`stage` is the *next* stage to run; `provision` is the background task's status,\npresent only once provision has fired):\n\n```json\n{ \"tool\": \"claude-code\", \"stage\": \"content_model\",\n  \"provision\": { \"status\": \"in_progress\", \"domain\": \"<domain>\", \"started_at\": \"…\" },\n  \"updated_at\": \"…\" }\n```\n\n`provision.status` is `in_progress` or `completed` — but it is a **hint**: always re-verify it against\n`hosting_websites_list-setups` (Step 1) before trusting it to gate an instance-barrier step.\n\n---\n\n## Step 0 — Start the run log\n\nBefore anything else, start a run and the stage (see *Run log and build report* in the top-level\n`SKILL.md`):\n\n```bash\nnode <skill>/run-log.mjs <domain> run-start --tool <tool> --model <model> --skill <skill version>\nnode <skill>/run-log.mjs <domain> stage-start check_state\n```\n\nIf an earlier run on this domain never wrote its report, `run-start` closes it as `abandoned` first.\n\nThen send any build reports that haven't reached Hostinger yet (that abandoned run, or a send that\nfailed last time):\n\n```bash\nnode <skill>/run-log.mjs <domain> unsent\n```\n\nEach line is `<run> <path>`. For each, send the file through `hosting_headless_submit-build-report`\nand record the result, as described in *Run log and build report* in the top-level `SKILL.md`. One\ntry each. Don't ask first; if any went out, say so in one line (e.g. \"Sent 1 earlier build report to\nHostinger.\"). Don't let a failure hold up this step.\nCheck-state runs once per session. A follow-up after the final report, in the same session, doesn't\ncome back here: it calls `run-resume` (see *Run log and build report* in the top-level `SKILL.md`).\n\n## Step 1 — Is a build actively running right now? (check this before anything else)\n\nKeep two things separate, and **never guess from a timestamp.**\n\n- **A platform build actively in progress** — the only *reliable* \"running now\" signal. Check\n  `hosting_websites_list-setups { \"domain\": \"<domain>\" }` and exact-match the domain row:\n  - `status: running` → provisioning is underway **right now** (a background provision from an earlier\n    turn). Don't start a second one — reconcile `state.json`'s `provision` to `in_progress`, and\n    either resume prepare work while it finishes or poll it to `completed` at the barrier.\n  - `status: failed` → not running; route to provision to self-heal (Step 3).\n  - `completed` → provision is done; set `provision.status` to `completed`. Instance-barrier steps\n    (content push, frontend data, deploy) are now unblocked.\n  - no row → not provisioned yet; carry on.\n\n  This check **is** the source of truth for `provision.status`: a stored `in_progress`/`completed` in\n  `state.json` is only a hint until this reconciles it.\n\n- **A `.lock`** — `~/.hostinger/<domain>/.lock`. It only tells you *a previous run\n  touched this domain*. **Do not judge it by age** — a 2-minute-old lock and a 3-year-old lock get the\n  same treatment, and a lock on its own is **not** a reason to interrupt the user. Carry it into Step 5:\n  if there's nothing to resume (new build), silently take it over; only if there's real state to resume\n  do you also ask *is another Claude window building this domain right now?* (yes → stop; no → take\n  over).\n\nOnce you're actively working this domain, **acquire/refresh the lock** (write the current timestamp),\nand **release it on a clean stop** (Step 6). The lock marks an active session, nothing more.\n\n---\n\n## Step 2 — Read the workspace directory\n\nCheck `~/.hostinger/<domain>/` by its exact path (for example `test -d ~/.hostinger/<domain>`), not\nby listing `~/.hostinger/`:\n\n- **Absent** → no history for this domain in the workspace.\n- **Present** → read `state.json` (its `stage`) and whatever artifacts exist (`brief.md`,\n  `site.json`, …). Treat these as a hint, not the truth.\n\n---\n\n## Step 3 — Verify against reality (reality wins)\n\nQuery the Hostinger connector — the local files are never trusted on their own:\n\n- **Does the site exist?** `hosting_websites_list { \"domain\": \"<domain>\" }`. ⚠️ This filter is a\n  **case-insensitive substring match**, not exact — so `test.com` would also return\n  `shop.test.com`. **Compare each returned row's `domain` to your target for an *exact* match**\n  (case-insensitive) and ignore the rest. No exact row ⇒ the domain is free. An exact row ⇒ the site\n  exists; note its `website_type` (`headless`, `wordpress`, `nodejs`, …) and `username`.\n- **Tell hPanel the tool connected.** As soon as you have the exact row, call\n  `hosting_websites_trigger-event { \"username\": \"<row username>\", \"domain\": \"<domain>\", \"event\": { \"name\": \"headless_onboarding.tool.connected\", \"params\": { \"tool\": \"<slug>\" } } }`\n  once, where `<slug>` is the onboarding slug (see *State and artifacts* in the top-level `SKILL.md`).\n  The call is required: hPanel's onboarding card waits for it to switch to \"connected\". Skip the\n  call when there's no exact row, your tool has no onboarding slug, or\n  `hosting_websites_trigger-event` isn't in your connector. Right before the call, tell the user in\n  one line (e.g. \"Telling hPanel <your tool> is connected so your onboarding card updates.\"), so\n  whoever reviews the outgoing call knows why it's made. If your own environment stopped the call\n  before it reached Hostinger (a sandbox, command review, an approval prompt, or a network error in\n  a sandboxed shell), try it one more time the way that environment allows, such as requesting\n  approval or network access, then go on. Ignore any other failure, such as a non-2xx response from\n  Hostinger: no retry, nothing more said to the user, and the run carries on unchanged.\n- **How far did it get?** If the site exists, check its setup via\n  `hosting_websites_list-setups { \"domain\": \"<domain>\" }` (exact-match the row the same way):\n  - `status: completed` → provisioned; then, depending on backend, check whether a build has succeeded.\n  - `status: running` → still provisioning (see Step 1).\n  - `status: failed` → provisioning stopped before finishing → route to **provision** to self-heal.\n- **Is it an empty headless shell from onboarding?** A `headless` site whose setup is `completed` is\n  **not necessarily finished** — onboarding now creates the website *before* the build runs, as an\n  **empty headless shell** (`hosting_websites_start-setup { type: \"headless_empty\" }`): `website_type`\n  is `headless` but **no backend is installed** (no WordPress at `/cms`, no store). Tell a shell from a\n  real backend the same way provision does: within 24 h the setup `type` is `headless_empty`; otherwise\n  `wordpress_installations_list { username, domain, ownership: \"all\" }` returns **no** `/cms` row and\n  there is no `site.json` recording a backend. An empty shell means **provision has not chosen or\n  installed a backend yet** — this is a **new build** that happens to already own its website, not a\n  finished or resumable one. Route it to **refine** (choose the backend), then **provision** adopts the\n  shell and swaps it to that backend (see the provision router's *Onboarding handoff*). Never create a\n  second site, and never skip provision for it.\n\nReconcile with the local state. **When they disagree, reality wins** and the local `stage` is\ncorrected.\n\n---\n\n## Step 4 — Determine the position\n\nConnect always writes `state.json` (with `stage: check_state`) before this step runs, so local\nstate is never truly empty. **\"Local state: none\" here means only connect artifacts exist** —\n`connect.json` + a `state.json` still pointing at `check_state`/`refine`, and **no build artifacts\nyet** (`brief.md`, `site.json`, …).\n\n| Local state | Reality (domain) | Position |\n|---|---|---|\n| none (connect only) | free | **new build** — start from refine |\n| none (connect only) | empty headless shell (onboarding) | **new build on an existing shell** — start from refine; provision adopts the shell and swaps it to the chosen backend. Never create a second site, never skip provision |\n| none (connect only) | site exists with a real backend | **adopt / resume** — never create a second site; route to the first unfinished stage |\n| build artifacts present, incomplete | matches | **resume** at `state.json`'s `stage` |\n| build artifacts present | disagrees | **reality wins** — recompute the stage from what actually exists |\n| build artifacts present, all done | live site exists | **finished** — this is now an *iterate* request, not a build |\n\n---\n\n## Step 5 — Guide the user\n\nThe question to ask depends on whether there is actually **something to resume** — i.e. **build\nartifacts** (`brief.md`, `site.json`, …) or a **live site** for this domain. A stray `.lock` or\nconnect-only files are *not* something to resume.\n\n- **New build** (no build artifacts and either the domain is free **or** it holds only an empty\n  headless shell from onboarding) → just proceed to refine. **Don't ask resume vs start over** —\n  there's nothing to resume; both would land in the same place. An empty headless shell is not\n  \"something to resume\": it has no backend and no content yet, so it's a fresh build that already owns\n  its website — provision will adopt and swap it. Mention it in one line (\"Using the headless site\n  onboarding already created for this domain.\"). If a leftover `.lock` is lying around, silently take\n  it over and continue (optionally mention it in one line).\n- **Something to resume** (build artifacts exist, or a site exists for the domain **with a real backend\n  installed** — WordPress at `/cms`, a store, or a deployed app) → tell the user plainly what's there\n  and **ask them to choose**, regardless of how old it is (don't guess from timestamps):\n\n- **Resume** — pick up at the computed stage. (If a `.lock` is present in this case, also confirm no\n  other window is actively building this domain right now.)\n- **Start over / redo a step** — only safe **before anything is provisioned**. If the site is already\n  provisioned or live, you **cannot** re-create it: that is forward-only *iterate* (change content or\n  design and redeploy), not a fresh build. Never re-provision or overwrite a live site; if the user\n  insists on a clean slate for a live domain, explain the limitation and point them at hPanel.\n- **Switch domain** — they want a different domain. A new domain is a **new workspace**\n  (`~/.hostinger/<other-domain>/`, with its own `src/`). Hand off to start that domain's run.\n- **Buy a domain** — they want a custom domain instead of the temporary one. Route to the domain\n  purchase / `connect-domain` flow, then continue with the chosen domain.\n\nWhen the intent is ambiguous, **ask** — don't guess. A skipped tool result is ambiguous; see\n*When you ask the user* in the top-level `SKILL.md`.\n\n---\n\n## Step 6 — Record and route\n\nWrite `~/.hostinger/<domain>/state.json` with the agreed next `stage` and a fresh timestamp. If the\nroute isn't a new build, record it with `run-log.mjs <domain> run-update --kind resume` (or\n`redesign` / `iterate`), then end the stage with `stage-end check_state ok --note \"<the route>\"`.\nThen:\n\n- **Handing straight to the next stage in this same session?** Keep the `.lock` (you are still\n  actively running) and continue.\n- **Stopping and returning control to the user?** (e.g. the next stage isn't built yet, or you are\n  waiting on them.) **Delete the `.lock`** — the session is no longer active, and a leftover lock just\n  forces an unnecessary \"is another window running?\" question on the next run. Always release the lock\n  on a clean stop; it exists only to mark an actively-running session. A stop is still the end of a\n  run: give the final report and save the build report (`09-done`).\n\n---\n\n## Invariants\n\n- **One directory per domain.** The domain is the key; state files never repeat it.\n- **Only this domain's workspace.** Never list `~/.hostinger/` or open another site's workspace (see\n  *State and artifacts* in the top-level `SKILL.md`).\n- **Never create a second site** on a domain that already has one.\n- **Never re-provision or overwrite a live site.** Recovery is forward-only.\n- **Reality beats local state**, always.\n- **When ambiguous, ask.**\n"
       },
       {
         "uri": "skill://hostinger-headless/steps/02-refine/SKILL.md",

package/src/core/skills.ts

@@ -148,10 +148,10 @@ const skills: Skill[] = [
       },
       {
         "uri": "skill://hostinger-headless/steps/01-check-state/SKILL.md",
-        "digest": "sha256:043f25855abf92f43728b6e442bbd8d580fd2a6bb0270cfa7ed95dd41050ee60",
-        "size": 13227,
+        "digest": "sha256:e4f6aa7823639670b6f862b309c7fce1210b5f558087a54c41b9f736aad442cd",
+        "size": 13726,
         "mimeType": "text/markdown",
-        "text": "---\nname: headless-step-check-state\ndescription: \"First build step of the Hostinger Headless flow, run right after connect. Works out where a given domain's build stands — is a run already in progress, does the site already exist, how far did it get — by reconciling the global workspace state under ~/.hostinger/<domain>/ with what the Hostinger connector reports, then guides the user to continue, switch or buy a domain, or start over. Owns all resume/position logic for the flow.\"\n---\n\n# headless-step-check-state\n\nThe first build step of the Hostinger Headless flow (orchestrated by `hostinger.com/headless/skill.md`),\nrun right after connect. Connect has already connected the Hostinger connector and confirmed the\naccount can build. Your job here is to\n**figure out where this domain stands and agree the route with the user** before any new work begins.\nThis step owns all resume/position logic — no other stage second-guesses it.\n\nNothing in this step creates, provisions, deploys, or deletes anything. It reads and guides. Its\nonly writes to Hostinger are unsent build reports (Step 0) and the tool-connected event (Step 3).\n\n---\n\n## Where state lives\n\nEverything for a domain lives under the global site workspace **`~/.hostinger/<domain>/`** — one\ndirectory per domain, under the user's home (`~` = `$HOME`), **not** the current working directory.\nThe directory name **is** the domain, so `state.json` inside does not store it. Because it's global,\nthis domain's build is resumable from any directory.\n\n`state.json` shape (`stage` is the *next* stage to run; `provision` is the background task's status,\npresent only once provision has fired):\n\n```json\n{ \"tool\": \"claude-code\", \"stage\": \"content_model\",\n  \"provision\": { \"status\": \"in_progress\", \"domain\": \"<domain>\", \"started_at\": \"…\" },\n  \"updated_at\": \"…\" }\n```\n\n`provision.status` is `in_progress` or `completed` — but it is a **hint**: always re-verify it against\n`hosting_websites_list-setups` (Step 1) before trusting it to gate an instance-barrier step.\n\n---\n\n## Step 0 — Start the run log\n\nBefore anything else, start a run and the stage (see *Run log and build report* in the top-level\n`SKILL.md`):\n\n```bash\nnode <skill>/run-log.mjs <domain> run-start --tool <tool> --model <model> --skill <skill version>\nnode <skill>/run-log.mjs <domain> stage-start check_state\n```\n\nIf an earlier run on this domain never wrote its report, `run-start` closes it as `abandoned` first.\n\nThen send any build reports that haven't reached Hostinger yet (that abandoned run, or a send that\nfailed last time):\n\n```bash\nnode <skill>/run-log.mjs <domain> unsent\n```\n\nEach line is `<run> <path>`. For each, send the file through `hosting_headless_submit-build-report`\nand record the result, as described in *Run log and build report* in the top-level `SKILL.md`. One\ntry each. Don't ask first; if any went out, say so in one line (e.g. \"Sent 1 earlier build report to\nHostinger.\"). Don't let a failure hold up this step.\nCheck-state runs once per session. A follow-up after the final report, in the same session, doesn't\ncome back here: it calls `run-resume` (see *Run log and build report* in the top-level `SKILL.md`).\n\n## Step 1 — Is a build actively running right now? (check this before anything else)\n\nKeep two things separate, and **never guess from a timestamp.**\n\n- **A platform build actively in progress** — the only *reliable* \"running now\" signal. Check\n  `hosting_websites_list-setups { \"domain\": \"<domain>\" }` and exact-match the domain row:\n  - `status: running` → provisioning is underway **right now** (a background provision from an earlier\n    turn). Don't start a second one — reconcile `state.json`'s `provision` to `in_progress`, and\n    either resume prepare work while it finishes or poll it to `completed` at the barrier.\n  - `status: failed` → not running; route to provision to self-heal (Step 3).\n  - `completed` → provision is done; set `provision.status` to `completed`. Instance-barrier steps\n    (content push, frontend data, deploy) are now unblocked.\n  - no row → not provisioned yet; carry on.\n\n  This check **is** the source of truth for `provision.status`: a stored `in_progress`/`completed` in\n  `state.json` is only a hint until this reconciles it.\n\n- **A `.lock`** — `~/.hostinger/<domain>/.lock`. It only tells you *a previous run\n  touched this domain*. **Do not judge it by age** — a 2-minute-old lock and a 3-year-old lock get the\n  same treatment, and a lock on its own is **not** a reason to interrupt the user. Carry it into Step 5:\n  if there's nothing to resume (new build), silently take it over; only if there's real state to resume\n  do you also ask *is another Claude window building this domain right now?* (yes → stop; no → take\n  over).\n\nOnce you're actively working this domain, **acquire/refresh the lock** (write the current timestamp),\nand **release it on a clean stop** (Step 6). The lock marks an active session, nothing more.\n\n---\n\n## Step 2 — Read the workspace directory\n\nCheck `~/.hostinger/<domain>/` by its exact path (for example `test -d ~/.hostinger/<domain>`), not\nby listing `~/.hostinger/`:\n\n- **Absent** → no history for this domain in the workspace.\n- **Present** → read `state.json` (its `stage`) and whatever artifacts exist (`brief.md`,\n  `site.json`, …). Treat these as a hint, not the truth.\n\n---\n\n## Step 3 — Verify against reality (reality wins)\n\nQuery the Hostinger connector — the local files are never trusted on their own:\n\n- **Does the site exist?** `hosting_websites_list { \"domain\": \"<domain>\" }`. ⚠️ This filter is a\n  **case-insensitive substring match**, not exact — so `test.com` would also return\n  `shop.test.com`. **Compare each returned row's `domain` to your target for an *exact* match**\n  (case-insensitive) and ignore the rest. No exact row ⇒ the domain is free. An exact row ⇒ the site\n  exists; note its `website_type` (`headless`, `wordpress`, `nodejs`, …) and `username`.\n- **Tell hPanel the tool connected.** As soon as you have the exact row, call\n  `hosting_websites_trigger-event { \"username\": \"<row username>\", \"domain\": \"<domain>\", \"event\": { \"name\": \"headless_onboarding.tool.connected\", \"params\": { \"tool\": \"<slug>\" } } }`\n  once, where `<slug>` is the onboarding slug (see *State and artifacts* in the top-level `SKILL.md`).\n  This flips hPanel's onboarding card to \"connected\". Don't ask first and don't mention it. Skip the\n  call when there's no exact row or your tool has no onboarding slug. If\n  `hosting_websites_trigger-event` isn't in your connector, or the call returns an error,\n  ignore it: no retry, nothing said to the user, and the run carries on unchanged.\n- **How far did it get?** If the site exists, check its setup via\n  `hosting_websites_list-setups { \"domain\": \"<domain>\" }` (exact-match the row the same way):\n  - `status: completed` → provisioned; then, depending on backend, check whether a build has succeeded.\n  - `status: running` → still provisioning (see Step 1).\n  - `status: failed` → provisioning stopped before finishing → route to **provision** to self-heal.\n- **Is it an empty headless shell from onboarding?** A `headless` site whose setup is `completed` is\n  **not necessarily finished** — onboarding now creates the website *before* the build runs, as an\n  **empty headless shell** (`hosting_websites_start-setup { type: \"headless_empty\" }`): `website_type`\n  is `headless` but **no backend is installed** (no WordPress at `/cms`, no store). Tell a shell from a\n  real backend the same way provision does: within 24 h the setup `type` is `headless_empty`; otherwise\n  `wordpress_installations_list { username, domain, ownership: \"all\" }` returns **no** `/cms` row and\n  there is no `site.json` recording a backend. An empty shell means **provision has not chosen or\n  installed a backend yet** — this is a **new build** that happens to already own its website, not a\n  finished or resumable one. Route it to **refine** (choose the backend), then **provision** adopts the\n  shell and swaps it to that backend (see the provision router's *Onboarding handoff*). Never create a\n  second site, and never skip provision for it.\n\nReconcile with the local state. **When they disagree, reality wins** and the local `stage` is\ncorrected.\n\n---\n\n## Step 4 — Determine the position\n\nConnect always writes `state.json` (with `stage: check_state`) before this step runs, so local\nstate is never truly empty. **\"Local state: none\" here means only connect artifacts exist** —\n`connect.json` + a `state.json` still pointing at `check_state`/`refine`, and **no build artifacts\nyet** (`brief.md`, `site.json`, …).\n\n| Local state | Reality (domain) | Position |\n|---|---|---|\n| none (connect only) | free | **new build** — start from refine |\n| none (connect only) | empty headless shell (onboarding) | **new build on an existing shell** — start from refine; provision adopts the shell and swaps it to the chosen backend. Never create a second site, never skip provision |\n| none (connect only) | site exists with a real backend | **adopt / resume** — never create a second site; route to the first unfinished stage |\n| build artifacts present, incomplete | matches | **resume** at `state.json`'s `stage` |\n| build artifacts present | disagrees | **reality wins** — recompute the stage from what actually exists |\n| build artifacts present, all done | live site exists | **finished** — this is now an *iterate* request, not a build |\n\n---\n\n## Step 5 — Guide the user\n\nThe question to ask depends on whether there is actually **something to resume** — i.e. **build\nartifacts** (`brief.md`, `site.json`, …) or a **live site** for this domain. A stray `.lock` or\nconnect-only files are *not* something to resume.\n\n- **New build** (no build artifacts and either the domain is free **or** it holds only an empty\n  headless shell from onboarding) → just proceed to refine. **Don't ask resume vs start over** —\n  there's nothing to resume; both would land in the same place. An empty headless shell is not\n  \"something to resume\": it has no backend and no content yet, so it's a fresh build that already owns\n  its website — provision will adopt and swap it. Mention it in one line (\"Using the headless site\n  onboarding already created for this domain.\"). If a leftover `.lock` is lying around, silently take\n  it over and continue (optionally mention it in one line).\n- **Something to resume** (build artifacts exist, or a site exists for the domain **with a real backend\n  installed** — WordPress at `/cms`, a store, or a deployed app) → tell the user plainly what's there\n  and **ask them to choose**, regardless of how old it is (don't guess from timestamps):\n\n- **Resume** — pick up at the computed stage. (If a `.lock` is present in this case, also confirm no\n  other window is actively building this domain right now.)\n- **Start over / redo a step** — only safe **before anything is provisioned**. If the site is already\n  provisioned or live, you **cannot** re-create it: that is forward-only *iterate* (change content or\n  design and redeploy), not a fresh build. Never re-provision or overwrite a live site; if the user\n  insists on a clean slate for a live domain, explain the limitation and point them at hPanel.\n- **Switch domain** — they want a different domain. A new domain is a **new workspace**\n  (`~/.hostinger/<other-domain>/`, with its own `src/`). Hand off to start that domain's run.\n- **Buy a domain** — they want a custom domain instead of the temporary one. Route to the domain\n  purchase / `connect-domain` flow, then continue with the chosen domain.\n\nWhen the intent is ambiguous, **ask** — don't guess. A skipped tool result is ambiguous; see\n*When you ask the user* in the top-level `SKILL.md`.\n\n---\n\n## Step 6 — Record and route\n\nWrite `~/.hostinger/<domain>/state.json` with the agreed next `stage` and a fresh timestamp. If the\nroute isn't a new build, record it with `run-log.mjs <domain> run-update --kind resume` (or\n`redesign` / `iterate`), then end the stage with `stage-end check_state ok --note \"<the route>\"`.\nThen:\n\n- **Handing straight to the next stage in this same session?** Keep the `.lock` (you are still\n  actively running) and continue.\n- **Stopping and returning control to the user?** (e.g. the next stage isn't built yet, or you are\n  waiting on them.) **Delete the `.lock`** — the session is no longer active, and a leftover lock just\n  forces an unnecessary \"is another window running?\" question on the next run. Always release the lock\n  on a clean stop; it exists only to mark an actively-running session. A stop is still the end of a\n  run: give the final report and save the build report (`09-done`).\n\n---\n\n## Invariants\n\n- **One directory per domain.** The domain is the key; state files never repeat it.\n- **Only this domain's workspace.** Never list `~/.hostinger/` or open another site's workspace (see\n  *State and artifacts* in the top-level `SKILL.md`).\n- **Never create a second site** on a domain that already has one.\n- **Never re-provision or overwrite a live site.** Recovery is forward-only.\n- **Reality beats local state**, always.\n- **When ambiguous, ask.**\n"
+        "text": "---\nname: headless-step-check-state\ndescription: \"First build step of the Hostinger Headless flow, run right after connect. Works out where a given domain's build stands — is a run already in progress, does the site already exist, how far did it get — by reconciling the global workspace state under ~/.hostinger/<domain>/ with what the Hostinger connector reports, then guides the user to continue, switch or buy a domain, or start over. Owns all resume/position logic for the flow.\"\n---\n\n# headless-step-check-state\n\nThe first build step of the Hostinger Headless flow (orchestrated by `hostinger.com/headless/skill.md`),\nrun right after connect. Connect has already connected the Hostinger connector and confirmed the\naccount can build. Your job here is to\n**figure out where this domain stands and agree the route with the user** before any new work begins.\nThis step owns all resume/position logic — no other stage second-guesses it.\n\nNothing in this step creates, provisions, deploys, or deletes anything. It reads and guides. Its\nonly writes to Hostinger are unsent build reports (Step 0) and the tool-connected event (Step 3).\n\n---\n\n## Where state lives\n\nEverything for a domain lives under the global site workspace **`~/.hostinger/<domain>/`** — one\ndirectory per domain, under the user's home (`~` = `$HOME`), **not** the current working directory.\nThe directory name **is** the domain, so `state.json` inside does not store it. Because it's global,\nthis domain's build is resumable from any directory.\n\n`state.json` shape (`stage` is the *next* stage to run; `provision` is the background task's status,\npresent only once provision has fired):\n\n```json\n{ \"tool\": \"claude-code\", \"stage\": \"content_model\",\n  \"provision\": { \"status\": \"in_progress\", \"domain\": \"<domain>\", \"started_at\": \"…\" },\n  \"updated_at\": \"…\" }\n```\n\n`provision.status` is `in_progress` or `completed` — but it is a **hint**: always re-verify it against\n`hosting_websites_list-setups` (Step 1) before trusting it to gate an instance-barrier step.\n\n---\n\n## Step 0 — Start the run log\n\nBefore anything else, start a run and the stage (see *Run log and build report* in the top-level\n`SKILL.md`):\n\n```bash\nnode <skill>/run-log.mjs <domain> run-start --tool <tool> --model <model> --skill <skill version>\nnode <skill>/run-log.mjs <domain> stage-start check_state\n```\n\nIf an earlier run on this domain never wrote its report, `run-start` closes it as `abandoned` first.\n\nThen send any build reports that haven't reached Hostinger yet (that abandoned run, or a send that\nfailed last time):\n\n```bash\nnode <skill>/run-log.mjs <domain> unsent\n```\n\nEach line is `<run> <path>`. For each, send the file through `hosting_headless_submit-build-report`\nand record the result, as described in *Run log and build report* in the top-level `SKILL.md`. One\ntry each. Don't ask first; if any went out, say so in one line (e.g. \"Sent 1 earlier build report to\nHostinger.\"). Don't let a failure hold up this step.\nCheck-state runs once per session. A follow-up after the final report, in the same session, doesn't\ncome back here: it calls `run-resume` (see *Run log and build report* in the top-level `SKILL.md`).\n\n## Step 1 — Is a build actively running right now? (check this before anything else)\n\nKeep two things separate, and **never guess from a timestamp.**\n\n- **A platform build actively in progress** — the only *reliable* \"running now\" signal. Check\n  `hosting_websites_list-setups { \"domain\": \"<domain>\" }` and exact-match the domain row:\n  - `status: running` → provisioning is underway **right now** (a background provision from an earlier\n    turn). Don't start a second one — reconcile `state.json`'s `provision` to `in_progress`, and\n    either resume prepare work while it finishes or poll it to `completed` at the barrier.\n  - `status: failed` → not running; route to provision to self-heal (Step 3).\n  - `completed` → provision is done; set `provision.status` to `completed`. Instance-barrier steps\n    (content push, frontend data, deploy) are now unblocked.\n  - no row → not provisioned yet; carry on.\n\n  This check **is** the source of truth for `provision.status`: a stored `in_progress`/`completed` in\n  `state.json` is only a hint until this reconciles it.\n\n- **A `.lock`** — `~/.hostinger/<domain>/.lock`. It only tells you *a previous run\n  touched this domain*. **Do not judge it by age** — a 2-minute-old lock and a 3-year-old lock get the\n  same treatment, and a lock on its own is **not** a reason to interrupt the user. Carry it into Step 5:\n  if there's nothing to resume (new build), silently take it over; only if there's real state to resume\n  do you also ask *is another Claude window building this domain right now?* (yes → stop; no → take\n  over).\n\nOnce you're actively working this domain, **acquire/refresh the lock** (write the current timestamp),\nand **release it on a clean stop** (Step 6). The lock marks an active session, nothing more.\n\n---\n\n## Step 2 — Read the workspace directory\n\nCheck `~/.hostinger/<domain>/` by its exact path (for example `test -d ~/.hostinger/<domain>`), not\nby listing `~/.hostinger/`:\n\n- **Absent** → no history for this domain in the workspace.\n- **Present** → read `state.json` (its `stage`) and whatever artifacts exist (`brief.md`,\n  `site.json`, …). Treat these as a hint, not the truth.\n\n---\n\n## Step 3 — Verify against reality (reality wins)\n\nQuery the Hostinger connector — the local files are never trusted on their own:\n\n- **Does the site exist?** `hosting_websites_list { \"domain\": \"<domain>\" }`. ⚠️ This filter is a\n  **case-insensitive substring match**, not exact — so `test.com` would also return\n  `shop.test.com`. **Compare each returned row's `domain` to your target for an *exact* match**\n  (case-insensitive) and ignore the rest. No exact row ⇒ the domain is free. An exact row ⇒ the site\n  exists; note its `website_type` (`headless`, `wordpress`, `nodejs`, …) and `username`.\n- **Tell hPanel the tool connected.** As soon as you have the exact row, call\n  `hosting_websites_trigger-event { \"username\": \"<row username>\", \"domain\": \"<domain>\", \"event\": { \"name\": \"headless_onboarding.tool.connected\", \"params\": { \"tool\": \"<slug>\" } } }`\n  once, where `<slug>` is the onboarding slug (see *State and artifacts* in the top-level `SKILL.md`).\n  The call is required: hPanel's onboarding card waits for it to switch to \"connected\". Skip the\n  call when there's no exact row, your tool has no onboarding slug, or\n  `hosting_websites_trigger-event` isn't in your connector. Right before the call, tell the user in\n  one line (e.g. \"Telling hPanel <your tool> is connected so your onboarding card updates.\"), so\n  whoever reviews the outgoing call knows why it's made. If your own environment stopped the call\n  before it reached Hostinger (a sandbox, command review, an approval prompt, or a network error in\n  a sandboxed shell), try it one more time the way that environment allows, such as requesting\n  approval or network access, then go on. Ignore any other failure, such as a non-2xx response from\n  Hostinger: no retry, nothing more said to the user, and the run carries on unchanged.\n- **How far did it get?** If the site exists, check its setup via\n  `hosting_websites_list-setups { \"domain\": \"<domain>\" }` (exact-match the row the same way):\n  - `status: completed` → provisioned; then, depending on backend, check whether a build has succeeded.\n  - `status: running` → still provisioning (see Step 1).\n  - `status: failed` → provisioning stopped before finishing → route to **provision** to self-heal.\n- **Is it an empty headless shell from onboarding?** A `headless` site whose setup is `completed` is\n  **not necessarily finished** — onboarding now creates the website *before* the build runs, as an\n  **empty headless shell** (`hosting_websites_start-setup { type: \"headless_empty\" }`): `website_type`\n  is `headless` but **no backend is installed** (no WordPress at `/cms`, no store). Tell a shell from a\n  real backend the same way provision does: within 24 h the setup `type` is `headless_empty`; otherwise\n  `wordpress_installations_list { username, domain, ownership: \"all\" }` returns **no** `/cms` row and\n  there is no `site.json` recording a backend. An empty shell means **provision has not chosen or\n  installed a backend yet** — this is a **new build** that happens to already own its website, not a\n  finished or resumable one. Route it to **refine** (choose the backend), then **provision** adopts the\n  shell and swaps it to that backend (see the provision router's *Onboarding handoff*). Never create a\n  second site, and never skip provision for it.\n\nReconcile with the local state. **When they disagree, reality wins** and the local `stage` is\ncorrected.\n\n---\n\n## Step 4 — Determine the position\n\nConnect always writes `state.json` (with `stage: check_state`) before this step runs, so local\nstate is never truly empty. **\"Local state: none\" here means only connect artifacts exist** —\n`connect.json` + a `state.json` still pointing at `check_state`/`refine`, and **no build artifacts\nyet** (`brief.md`, `site.json`, …).\n\n| Local state | Reality (domain) | Position |\n|---|---|---|\n| none (connect only) | free | **new build** — start from refine |\n| none (connect only) | empty headless shell (onboarding) | **new build on an existing shell** — start from refine; provision adopts the shell and swaps it to the chosen backend. Never create a second site, never skip provision |\n| none (connect only) | site exists with a real backend | **adopt / resume** — never create a second site; route to the first unfinished stage |\n| build artifacts present, incomplete | matches | **resume** at `state.json`'s `stage` |\n| build artifacts present | disagrees | **reality wins** — recompute the stage from what actually exists |\n| build artifacts present, all done | live site exists | **finished** — this is now an *iterate* request, not a build |\n\n---\n\n## Step 5 — Guide the user\n\nThe question to ask depends on whether there is actually **something to resume** — i.e. **build\nartifacts** (`brief.md`, `site.json`, …) or a **live site** for this domain. A stray `.lock` or\nconnect-only files are *not* something to resume.\n\n- **New build** (no build artifacts and either the domain is free **or** it holds only an empty\n  headless shell from onboarding) → just proceed to refine. **Don't ask resume vs start over** —\n  there's nothing to resume; both would land in the same place. An empty headless shell is not\n  \"something to resume\": it has no backend and no content yet, so it's a fresh build that already owns\n  its website — provision will adopt and swap it. Mention it in one line (\"Using the headless site\n  onboarding already created for this domain.\"). If a leftover `.lock` is lying around, silently take\n  it over and continue (optionally mention it in one line).\n- **Something to resume** (build artifacts exist, or a site exists for the domain **with a real backend\n  installed** — WordPress at `/cms`, a store, or a deployed app) → tell the user plainly what's there\n  and **ask them to choose**, regardless of how old it is (don't guess from timestamps):\n\n- **Resume** — pick up at the computed stage. (If a `.lock` is present in this case, also confirm no\n  other window is actively building this domain right now.)\n- **Start over / redo a step** — only safe **before anything is provisioned**. If the site is already\n  provisioned or live, you **cannot** re-create it: that is forward-only *iterate* (change content or\n  design and redeploy), not a fresh build. Never re-provision or overwrite a live site; if the user\n  insists on a clean slate for a live domain, explain the limitation and point them at hPanel.\n- **Switch domain** — they want a different domain. A new domain is a **new workspace**\n  (`~/.hostinger/<other-domain>/`, with its own `src/`). Hand off to start that domain's run.\n- **Buy a domain** — they want a custom domain instead of the temporary one. Route to the domain\n  purchase / `connect-domain` flow, then continue with the chosen domain.\n\nWhen the intent is ambiguous, **ask** — don't guess. A skipped tool result is ambiguous; see\n*When you ask the user* in the top-level `SKILL.md`.\n\n---\n\n## Step 6 — Record and route\n\nWrite `~/.hostinger/<domain>/state.json` with the agreed next `stage` and a fresh timestamp. If the\nroute isn't a new build, record it with `run-log.mjs <domain> run-update --kind resume` (or\n`redesign` / `iterate`), then end the stage with `stage-end check_state ok --note \"<the route>\"`.\nThen:\n\n- **Handing straight to the next stage in this same session?** Keep the `.lock` (you are still\n  actively running) and continue.\n- **Stopping and returning control to the user?** (e.g. the next stage isn't built yet, or you are\n  waiting on them.) **Delete the `.lock`** — the session is no longer active, and a leftover lock just\n  forces an unnecessary \"is another window running?\" question on the next run. Always release the lock\n  on a clean stop; it exists only to mark an actively-running session. A stop is still the end of a\n  run: give the final report and save the build report (`09-done`).\n\n---\n\n## Invariants\n\n- **One directory per domain.** The domain is the key; state files never repeat it.\n- **Only this domain's workspace.** Never list `~/.hostinger/` or open another site's workspace (see\n  *State and artifacts* in the top-level `SKILL.md`).\n- **Never create a second site** on a domain that already has one.\n- **Never re-provision or overwrite a live site.** Recovery is forward-only.\n- **Reality beats local state**, always.\n- **When ambiguous, ask.**\n"
       },
       {
         "uri": "skill://hostinger-headless/steps/02-refine/SKILL.md",

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.17.1', tools, instructions });
+startServer({ name: 'hostinger-agency-hosting-mcp', version: '3.17.2', 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.17.1', tools, instructions });
+startServer({ name: 'hostinger-agency-hosting-mcp', version: '3.17.2', 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.17.1', tools });
+startServer({ name: 'hostinger-agent-readiness-mcp', version: '3.17.2', 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.17.1', tools });
+startServer({ name: 'hostinger-agent-readiness-mcp', version: '3.17.2', 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.17.1', tools, instructions, skills });
+startServer({ name: 'hostinger-api-mcp', version: '3.17.2', 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.17.1', tools, instructions, skills });
+startServer({ name: 'hostinger-api-mcp', version: '3.17.2', 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.17.1', tools });
+startServer({ name: 'hostinger-billing-mcp', version: '3.17.2', 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.17.1', tools });
+startServer({ name: 'hostinger-billing-mcp', version: '3.17.2', 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.17.1', tools });
+startServer({ name: 'hostinger-dns-mcp', version: '3.17.2', 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.17.1', tools });
+startServer({ name: 'hostinger-dns-mcp', version: '3.17.2', 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.17.1', tools });
+startServer({ name: 'hostinger-domains-mcp', version: '3.17.2', 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.17.1', tools });
+startServer({ name: 'hostinger-domains-mcp', version: '3.17.2', 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.17.1', tools });
+startServer({ name: 'hostinger-ecommerce-mcp', version: '3.17.2', 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.17.1', tools });
+startServer({ name: 'hostinger-ecommerce-mcp', version: '3.17.2', 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.17.1', tools });
+startServer({ name: 'hostinger-horizons-mcp', version: '3.17.2', 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.17.1', tools });
+startServer({ name: 'hostinger-horizons-mcp', version: '3.17.2', 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.17.1', tools, instructions });
+startServer({ name: 'hostinger-hosting-mcp', version: '3.17.2', 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.17.1', tools, instructions });
+startServer({ name: 'hostinger-hosting-mcp', version: '3.17.2', 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.17.1', tools });
+startServer({ name: 'hostinger-mail-mcp', version: '3.17.2', 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.17.1', tools });
+startServer({ name: 'hostinger-mail-mcp', version: '3.17.2', 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.17.1', tools });
+startServer({ name: 'hostinger-reach-mcp', version: '3.17.2', 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.17.1', tools });
+startServer({ name: 'hostinger-reach-mcp', version: '3.17.2', 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.17.1', tools });
+startServer({ name: 'hostinger-vps-mcp', version: '3.17.2', 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.17.1', tools });
+startServer({ name: 'hostinger-vps-mcp', version: '3.17.2', 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.17.1', tools });
+startServer({ name: 'hostinger-wordpress-mcp', version: '3.17.2', 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.17.1', tools });
+startServer({ name: 'hostinger-wordpress-mcp', version: '3.17.2', tools });