hostinger-api-mcp 3.14.0 → 3.15.0

package/CHANGELOG.md

@@ -4,6 +4,34 @@ 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.15.0 — 2026-10-27
+
+### Operations
+
+- Added `hosting_websites_trigger-event` — Trigger website event
+
+### Also in this release
+
+- Documentation: `README.md`
+- Bundled agent skills: `skills/headless/steps/01-check-state/SKILL.md`
+- Request handling and authentication: `src/core/runtime.js`, `src/core/runtime.ts`
+- Other files: `src/core/skills.js`, `src/core/skills.ts`
+- Build and packaging: `types.d.ts`
+
+## v3.14.1 — 2026-10-27
+
+### Operations
+
+- Added `hosting_cache_status` — Get cache status
+- Changed the description of `hosting_cache_toggle-cacheless`
+- Changed the description of `hosting_cache_toggle-website`
+
+### Also in this release
+
+- Documentation: `README.md`
+- Request handling and authentication: `src/core/runtime.js`, `src/core/runtime.ts`
+- Build and packaging: `types.d.ts`
+
 ## v3.14.0 — 2026-10-27
 
 ### Also in this release

package/README.md

@@ -69,7 +69,7 @@ pnpm update -g @hostinger/mcp
 
 This package installs the following MCP server commands:
 
-- `hostinger-api-mcp` — unified server over every operation (416 total)
+- `hostinger-api-mcp` — unified server over every operation (418 total)
 - `hostinger-agency-hosting-mcp` — 42 operations for agency-hosting
 - `hostinger-agent-readiness-mcp` — 3 operations for agent-readiness
 - `hostinger-billing-mcp` — 9 operations for billing
@@ -77,7 +77,7 @@ This package installs the following MCP server commands:
 - `hostinger-domains-mcp` — 42 operations for domains
 - `hostinger-ecommerce-mcp` — 29 operations for ecommerce
 - `hostinger-horizons-mcp` — 6 operations for horizons
-- `hostinger-hosting-mcp` — 66 operations for hosting
+- `hostinger-hosting-mcp` — 68 operations for hosting
 - `hostinger-mail-mcp` — 38 operations for mail
 - `hostinger-reach-mcp` — 69 operations for reach
 - `hostinger-vps-mcp` — 67 operations for vps
@@ -1828,6 +1828,13 @@ Check deployment status, build status, build logs and why a build failed (failur
 - **Method**: `custom`
 - **Path**: `custom`
 
+#### hosting_websites_trigger-event
+
+Tell Hostinger that something happened on this website, so Hostinger services such as hPanel can react to it. `event.name` picks the event and decides which `event.params` it takes. The call changes nothing on the website.
+
+- **Method**: `custom`
+- **Path**: `custom`
+
 #### hosting_cache_clear-website
 
 Permanently clears all server-side cache for the website at once. Use it when content was
@@ -1840,6 +1847,24 @@ installation living in a subdirectory, pass the directory query parameter to cle
 - **Method**: `DELETE`
 - **Path**: `/api/hosting/v1/accounts/{username}/websites/{domain}/cache/clear`
 
+#### hosting_cache_status
+
+Returns the caching state of the website: whether server-side caching is enabled and whether
+development (cacheless) mode is on. Works for the main domain, addon websites, parked domains
+and subdomains of the account; each reports its own settings and does not inherit them from
+its parent website.
+
+`is_enabled` is the setting changed by `Toggle website cache` and reflects a toggle
+immediately. `is_cacheless_mode_enabled` is true while development mode is on; caching is then
+bypassed even when `is_enabled` is true. `Toggle cacheless mode` is applied in the background,
+so this flag can take a few minutes to follow it.
+
+The domain must be the exact website name as listed on the account, without a `www.` prefix.
+Returns 404 when the domain is not a website on the account.
+
+- **Method**: `GET`
+- **Path**: `/api/hosting/v1/accounts/{username}/websites/{domain}/cache/status`
+
 #### hosting_cache_toggle-cacheless
 
 Turns development (cacheless) mode on or off, based on the enabled flag. When enabled, nothing
@@ -1847,6 +1872,9 @@ is cached, effectively turning off all caching for the website; use it while act
 testing changes, debugging issues, or when real-time updates must be visible. Disable it after
 finishing development work to restore the performance benefits of caching.
 
+The change is applied in the background and can take a few minutes. Use `Get cache status` to
+check the current state.
+
 - **Method**: `PATCH`
 - **Path**: `/api/hosting/v1/accounts/{username}/websites/{domain}/cacheless-mode/toggle`
 
@@ -1857,7 +1885,8 @@ faster page loads, reduced server load, and improved user experience; recommende
 websites. Disabling may impact performance; to temporarily bypass caching while developing or
 debugging, prefer toggling cacheless mode instead.
 
-Does nothing if caching is already in the requested state.
+Does nothing if caching is already in the requested state. Use `Get cache status` to check the
+current state.
 
 - **Method**: `PATCH`
 - **Path**: `/api/hosting/v1/accounts/{username}/websites/{domain}/cache/toggle`

package/gemini-extension.json

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

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

@@ -12,7 +12,7 @@ account can build. Your job here is to
 This step owns all resume/position logic — no other stage second-guesses it.
 
 Nothing in this step creates, provisions, deploys, or deletes anything. It reads and guides. Its
-only writes to Hostinger are reports: unsent build reports (Step 0) and the connected tool (Step 3).
+only writes to Hostinger are unsent build reports (Step 0) and the tool-connected event (Step 3).
 
 ---
 
@@ -113,11 +113,11 @@ Query the Hostinger connector — the local files are never trusted on their own
   (case-insensitive) and ignore the rest. No exact row ⇒ the domain is free. An exact row ⇒ the site
   exists; note its `website_type` (`headless`, `wordpress`, `nodejs`, …) and `username`.
 - **Tell hPanel the tool connected.** As soon as you have the exact row, call
-  `hosting_headless_report-tool-connected { "username": "<row username>", "domain": "<domain>", "tool": "<slug>" }`
+  `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_headless_report-tool-connected` isn't in your connector, or the call returns an error,
+  `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.
 - **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):

package/src/core/runtime.js

@@ -66,7 +66,7 @@ const GetSkillRequestSchema = z.object({
 
 /**
  * MCP Server for Hostinger API
- * Generated from OpenAPI spec version 2.4.2
+ * Generated from OpenAPI spec version 2.4.3
  */
 class MCPServer {
   constructor({ name, version, tools, instructions, skills = [] }) {
@@ -316,6 +316,8 @@ class MCPServer {
         return await this.handleListJavascriptDeployments(params);
       case 'hosting_show-js-deployment-logs':
         return await this.handleShowJsDeploymentLogs(params);
+      case 'hosting_websites_trigger-event':
+        return await this.handleHostingTriggerWebsiteEvent(params);
       case 'agency-hosting_deploy-node-static-website':
         return await this.handleNodeStaticDeploy(params);
       case 'agency-hosting_deploy-php-application':
@@ -2782,6 +2784,54 @@ class MCPServer {
     };
   }
 
+  async handleHostingTriggerWebsiteEvent(params) {
+    const { username, domain, event } = params;
+    const baseUrl = this.baseUrl.endsWith("/") ? this.baseUrl : `${this.baseUrl}/`;
+    const url = new URL(`api/hosting/v1/accounts/${encodeURIComponent(String(username))}/websites/${encodeURIComponent(String(domain))}/events/trigger`, baseUrl).toString();
+
+    try {
+      const bearerToken = await this.getAuthToken();
+
+      const config = {
+        method: 'post',
+        url,
+        headers: {
+          ...this.headers,
+          'Authorization': `Bearer ${bearerToken}`,
+          'Content-Type': 'application/json'
+        },
+        data: { event },
+        timeout: 60000, // 60s
+        validateStatus: function (status) {
+          return status < 500;
+        }
+      };
+
+      const response = await axios(config);
+
+      if (response.status < 200 || response.status >= 300) {
+        throw new ApiExecutionError(response.status, response.data);
+      }
+
+      return response.data;
+
+    } catch (error) {
+      const errorMessage = error instanceof Error ? error.message : String(error);
+      this.log('error', `Failed to trigger website event: ${errorMessage}`);
+
+      if (axios.isAxiosError(error)) {
+        const responseData = error.response?.data;
+        const responseStatus = error.response?.status;
+        this.log('error', 'API Error Details:', {
+          status: responseStatus,
+          data: typeof responseData === 'object' ? JSON.stringify(responseData) : responseData
+        });
+      }
+
+      throw error;
+    }
+  }
+
   agencyHosting_normalizePath(pathString) {
     return pathString.replace(/\\/g, '/');
   }

package/src/core/runtime.ts

@@ -97,7 +97,7 @@ interface Skill { uri: string; frontmatter: Record<string, unknown>; resources:
 
 /**
  * MCP Server for Hostinger API
- * Generated from OpenAPI spec version 2.4.2
+ * Generated from OpenAPI spec version 2.4.3
  */
 class MCPServer {
   private readonly name: string;
@@ -347,6 +347,8 @@ class MCPServer {
         return await this.handleListJavascriptDeployments(params);
       case 'hosting_show-js-deployment-logs':
         return await this.handleShowJsDeploymentLogs(params);
+      case 'hosting_websites_trigger-event':
+        return await this.handleHostingTriggerWebsiteEvent(params);
       case 'agency-hosting_deploy-node-static-website':
         return await this.handleNodeStaticDeploy(params);
       case 'agency-hosting_deploy-php-application':
@@ -2819,6 +2821,54 @@ class MCPServer {
     };
   }
 
+  private async handleHostingTriggerWebsiteEvent(params: Record<string, unknown>): Promise<unknown> {
+    const { username, domain, event } = params;
+    const baseUrl = this.baseUrl.endsWith("/") ? this.baseUrl : `${this.baseUrl}/`;
+    const url = new URL(`api/hosting/v1/accounts/${encodeURIComponent(String(username))}/websites/${encodeURIComponent(String(domain))}/events/trigger`, baseUrl).toString();
+
+    try {
+      const bearerToken = await this.getAuthToken();
+
+      const config: AxiosRequestConfig = {
+        method: 'post',
+        url,
+        headers: {
+          ...this.headers,
+          'Authorization': `Bearer ${bearerToken}`,
+          'Content-Type': 'application/json'
+        },
+        data: { event },
+        timeout: 60000, // 60s
+        validateStatus: function (status: number): boolean {
+          return status < 500;
+        }
+      };
+
+      const response = await axios(config);
+
+      if (response.status < 200 || response.status >= 300) {
+        throw new ApiExecutionError(response.status, response.data);
+      }
+
+      return response.data;
+
+    } catch (error) {
+      const errorMessage = error instanceof Error ? error.message : String(error);
+      this.log('error', `Failed to trigger website event: ${errorMessage}`);
+
+      if (axios.isAxiosError(error)) {
+        const responseData = error.response?.data;
+        const responseStatus = error.response?.status;
+        this.log('error', 'API Error Details:', {
+          status: responseStatus,
+          data: typeof responseData === 'object' ? JSON.stringify(responseData) : responseData
+        });
+      }
+
+      throw error;
+    }
+  }
+
   private agencyHosting_normalizePath(pathString: string): string {
     return pathString.replace(/\\/g, '/');
   }

package/src/core/skills.js

@@ -134,10 +134,10 @@ export default [
       },
       {
         "uri": "skill://hostinger-headless/steps/01-check-state/SKILL.md",
-        "digest": "sha256:1c6cd793a02758c65d46fecb8e7d8fe1c50544dcc3bbde23b22786ebd24f754c",
-        "size": 13173,
+        "digest": "sha256:043f25855abf92f43728b6e442bbd8d580fd2a6bb0270cfa7ed95dd41050ee60",
+        "size": 13227,
         "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 reports: unsent build reports (Step 0) and the connected tool (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_headless_report-tool-connected { \"username\": \"<row username>\", \"domain\": \"<domain>\", \"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_headless_report-tool-connected` 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  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"
       },
       {
         "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:1c6cd793a02758c65d46fecb8e7d8fe1c50544dcc3bbde23b22786ebd24f754c",
-        "size": 13173,
+        "digest": "sha256:043f25855abf92f43728b6e442bbd8d580fd2a6bb0270cfa7ed95dd41050ee60",
+        "size": 13227,
         "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 reports: unsent build reports (Step 0) and the connected tool (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_headless_report-tool-connected { \"username\": \"<row username>\", \"domain\": \"<domain>\", \"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_headless_report-tool-connected` 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  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"
       },
       {
         "uri": "skill://hostinger-headless/steps/02-refine/SKILL.md",

package/src/core/tools/all.js

@@ -559,6 +559,76 @@ export default [
     "group": "hosting",
     "hidden": true
   },
+  {
+    "name": "hosting_websites_trigger-event",
+    "title": "Trigger website event",
+    "annotations": {
+      "title": "Trigger website event",
+      "readOnlyHint": false,
+      "destructiveHint": false
+    },
+    "topic": "hosting",
+    "description": "Tell Hostinger that something happened on this website, so Hostinger services such as hPanel can react to it. `event.name` picks the event and decides which `event.params` it takes. The call changes nothing on the website.",
+    "method": "",
+    "path": "",
+    "inputSchema": {
+      "type": "object",
+      "properties": {
+        "username": {
+          "type": "string",
+          "description": "Username of the hosting account that owns the website, as hosting_websites_list returns it"
+        },
+        "domain": {
+          "type": "string",
+          "description": "Domain name of the website (e.g., example.com)"
+        },
+        "event": {
+          "type": "object",
+          "description": "Event to trigger; `name` decides which `params` it takes",
+          "properties": {
+            "name": {
+              "type": "string",
+              "description": "Name of the event. `headless_onboarding.tool.connected`: an AI coding tool started building this website with the Hostinger headless skill, so hPanel shows the tool as connected; send it once per skill run; takes `params.tool`.",
+              "enum": [
+                "headless_onboarding.tool.connected"
+              ]
+            },
+            "params": {
+              "type": "object",
+              "description": "Fields of the event",
+              "properties": {
+                "tool": {
+                  "type": "string",
+                  "description": "Lowercase slug of the AI coding tool. Known slugs: `claude` (Claude Code), `cursor` (Cursor), `codex` (Codex), `vscode` (VS Code), `antigravity` (Antigravity) and `devin` (Devin). For any other tool, send its own slug.",
+                  "pattern": "^[a-z0-9-]{1,32}$"
+                }
+              },
+              "required": [
+                "tool"
+              ],
+              "additionalProperties": false
+            }
+          },
+          "required": [
+            "name",
+            "params"
+          ],
+          "additionalProperties": false
+        }
+      },
+      "required": [
+        "username",
+        "domain",
+        "event"
+      ]
+    },
+    "security": [],
+    "custom": true,
+    "templateFile": "trigger-website-event.template.js",
+    "templateFileTS": "trigger-website-event.template.ts",
+    "handlerMethod": "handleHostingTriggerWebsiteEvent",
+    "group": "hosting"
+  },
   {
     "name": "agency-hosting_datacenters_list",
     "title": "List available datacenters",
@@ -6209,6 +6279,41 @@ export default [
     ],
     "group": "hosting"
   },
+  {
+    "name": "hosting_cache_status",
+    "title": "Get cache status",
+    "annotations": {
+      "title": "Get cache status",
+      "readOnlyHint": true,
+      "destructiveHint": false
+    },
+    "description": "Returns the caching state of the website: whether server-side caching is enabled and whether\ndevelopment (cacheless) mode is on. Works for the main domain, addon websites, parked domains\nand subdomains of the account; each reports its own settings and does not inherit them from\nits parent website.\n\n`is_enabled` is the setting changed by `Toggle website cache` and reflects a toggle\nimmediately. `is_cacheless_mode_enabled` is true while development mode is on; caching is then\nbypassed even when `is_enabled` is true. `Toggle cacheless mode` is applied in the background,\nso this flag can take a few minutes to follow it.\n\nThe domain must be the exact website name as listed on the account, without a `www.` prefix.\nReturns 404 when the domain is not a website on the account.",
+    "method": "GET",
+    "path": "/api/hosting/v1/accounts/{username}/websites/{domain}/cache/status",
+    "inputSchema": {
+      "type": "object",
+      "properties": {
+        "username": {
+          "type": "string",
+          "description": "username parameter"
+        },
+        "domain": {
+          "type": "string",
+          "description": "Domain name"
+        }
+      },
+      "required": [
+        "username",
+        "domain"
+      ]
+    },
+    "security": [
+      {
+        "apiToken": []
+      }
+    ],
+    "group": "hosting"
+  },
   {
     "name": "hosting_cache_toggle-cacheless",
     "title": "Toggle cacheless mode",
@@ -6218,7 +6323,7 @@ export default [
       "destructiveHint": true,
       "idempotentHint": true
     },
-    "description": "Turns development (cacheless) mode on or off, based on the enabled flag. When enabled, nothing\nis cached, effectively turning off all caching for the website; use it while actively developing,\ntesting changes, debugging issues, or when real-time updates must be visible. Disable it after\nfinishing development work to restore the performance benefits of caching.",
+    "description": "Turns development (cacheless) mode on or off, based on the enabled flag. When enabled, nothing\nis cached, effectively turning off all caching for the website; use it while actively developing,\ntesting changes, debugging issues, or when real-time updates must be visible. Disable it after\nfinishing development work to restore the performance benefits of caching.\n\nThe change is applied in the background and can take a few minutes. Use `Get cache status` to\ncheck the current state.",
     "method": "PATCH",
     "path": "/api/hosting/v1/accounts/{username}/websites/{domain}/cacheless-mode/toggle",
     "inputSchema": {
@@ -6259,7 +6364,7 @@ export default [
       "destructiveHint": true,
       "idempotentHint": true
     },
-    "description": "Turns server-side caching for the website on or off, based on the enabled flag. Enable it for\nfaster page loads, reduced server load, and improved user experience; recommended for production\nwebsites. Disabling may impact performance; to temporarily bypass caching while developing or\ndebugging, prefer toggling cacheless mode instead.\n\nDoes nothing if caching is already in the requested state.",
+    "description": "Turns server-side caching for the website on or off, based on the enabled flag. Enable it for\nfaster page loads, reduced server load, and improved user experience; recommended for production\nwebsites. Disabling may impact performance; to temporarily bypass caching while developing or\ndebugging, prefer toggling cacheless mode instead.\n\nDoes nothing if caching is already in the requested state. Use `Get cache status` to check the\ncurrent state.",
     "method": "PATCH",
     "path": "/api/hosting/v1/accounts/{username}/websites/{domain}/cache/toggle",
     "inputSchema": {