hostinger-api-mcp 3.10.0 → 3.10.1

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.10.1 — 2026-10-26
+
+### Also in this release
+
+- Bundled agent skills: `skills/headless/steps/06-frontend/SKILL.md`, `skills/headless/steps/08-deploy/SKILL.md`
+- Other files: `src/core/skills.js`, `src/core/skills.ts`
+
 ## v3.10.0 — 2026-10-26
 
 ### Also in this release

package/gemini-extension.json

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

package/skills/headless/steps/06-frontend/SKILL.md

@@ -162,6 +162,12 @@ Guidelines (framework-agnostic):
 - **No `.htaccess`** in the project (deploy would overwrite the live one); don't commit `node_modules`
   or build output.
 - Set `engines.node` to `22` (the deploy builds on Node 22).
+- **Next.js 16+ only:** set the `build` script to `next build --webpack`, not plain `next build`. Next.js
+  16 defaults `next build` to **Turbopack**, whose native compiler needs a newer glibc than the Hostinger
+  build server has, so a Turbopack build fails on deploy and won't fall back to webpack. Webpack builds
+  clean there. The `--webpack` flag exists only on Next.js 16+; on **Next.js 15.x** leave the build script
+  as plain `next build` (it already defaults to webpack). (Alternative: pin Next.js to `15.x`, keeping
+  plain `next build`.)
 
 ## Step 4 — Hand off
 

package/skills/headless/steps/08-deploy/SKILL.md

@@ -46,12 +46,28 @@ static frameworks serve their output dir as files. If unsure of a framework's ou
 framework's own build output, but **always pass `appType`/`outputDirectory` on the deploy call with the
 framework's correct values** — don't rely on auto-detection (it returns null → 403).
 
+> ## ⚠️ Next.js 16+: build with webpack, not Turbopack (recurring deploy failure)
+> Next.js 16 makes **Turbopack** the default bundler for `next build`. Turbopack's native (Rust)
+> compiler needs a newer **glibc** than the Hostinger build server ships, so the server build aborts
+> with a "glibc too old" error — and Turbopack **does not fall back** to webpack on its own, so the
+> deploy fails every time. **Fix: build with webpack.** On **Next.js 16+** the project's `build` script
+> in `package.json` must be `next build --webpack` (not plain `next build`); `buildScript` on the deploy
+> call stays `"build"` — that's what runs it. The `--webpack` flag exists only on Next.js 16+; on
+> **Next.js 15.x** leave the build script as plain `next build` (it already defaults to webpack).
+> **Confirm this in `package.json` before deploying** (the frontend step scaffolds it this way — see
+> `../06-frontend`). Alternative, only if you must avoid the `--webpack` flag: pin Next.js to `15.x`
+> (keeping plain `next build`), whose `next build` still defaults to webpack. Next.js only — other
+> frameworks are unaffected.
+
 ## Step 1 — Pre-flight
 
 1. **Instance live.** `provision.status == "completed"`, re-verified with
    `hosting_websites_list-setups { "domain": "<domain>" }`.
 2. **Build output exists locally** (the framework's output dir — e.g. `.next/`, `dist/`, `.output/`) and
    the project builds clean (frontend/validate already did this). If not, go back.
+   - **Next.js 16+:** `package.json`'s `build` script is `next build --webpack`, not plain `next build` —
+     the server's glibc can't run Turbopack's native compiler (see the box above). On Next.js 15.x leave it
+     as plain `next build`. Fix it here if it isn't.
 3. **Env vars (only if used).** Build-time vars (e.g. `NEXT_PUBLIC_*`) must be set **before** the build
    with `hosting_nodejs_replace-environment-variables` (full replace). Never put secrets in the repo or
    the archive. **Webapp with a database:** that full replace wipes the `DB_*`/`DATABASE_URL` that

package/src/core/skills.js

@@ -232,10 +232,10 @@ export default [
       },
       {
         "uri": "skill://hostinger-headless/steps/06-frontend/SKILL.md",
-        "digest": "sha256:2783b21dd7cd261a93b084c2f9718b91c29deee1a158b0c240102bde6ed8a512",
-        "size": 13449,
+        "digest": "sha256:78a73a17fcff1d5ff8a6476e612b79d42809e9e36009b5db2b21153249904d4c",
+        "size": 13998,
         "mimeType": "text/markdown",
-        "text": "---\nname: headless-step-frontend\ndescription: \"Step 6 (frontend) of the Hostinger Headless flow. Builds the website that renders the backend's content. Figures out (or confirms) the framework — defaulting to Next.js SSR — implements the look already chosen in design.md (the design step's contract), and builds the source into src/. Only ask for the clarifications you actually need.\"\n---\n\n# headless-step-frontend\n\nBuild the site's frontend against the backend from `site.json`, implementing the look the design step\nalready chose and wrote to **`design.md`** (plus the logo in `brand/`). The design is decided; this step\nis where it becomes real code. There's no per-framework recipe — use good judgement, follow `design.md`\nas the contract, and ask only for the clarifications you genuinely need. **Out:** source in the site\nworkspace `~/.hostinger/<domain>/src/`.\n\n> ## ⚠️ Build mode: \"Bring your own frontend\"? Read this first (any backend)\n> Read `brief.md` → **Build mode**. When it is **Bring your own frontend**, the user already has a\n> frontend (the project in the folder the command was run in) and this step **wires it to the backend\n> from `site.json` — it does not scaffold a new project and there is usually no `design.md` to\n> implement** (the design step deferred to the user). **Use their project as the source**: copy or\n> point `~/.hostinger/<domain>/src/` at it, keep its framework and UI, and collaborate on changes at\n> the user's direction (vibe-code with them). Your job is to connect it to the live backend (WordPress\n> `wp/v2` reads, the WooCommerce/Ecommerce Store API, env/keys) and make it deployable (set\n> `engines.node` to `22`, remove any `.htaccess`), then hand off to deploy. This generalises the Webapp\n> \"existing app\" case below to WordPress and Ecommerce too. When **Build mode is \"Agent designs and\n> builds\"**, ignore this box and proceed normally (scaffold + implement `design.md`).\n\n> ## ⚠️ Webapp backend? Read this first\n> A `webapp` brief has **no CMS/store and no `content-model.md`** — the app owns its own data (its own\n> API, or the MySQL database recorded in `site.json → database`). It comes in two shapes, decided back in\n> **refine**:\n>\n> - **An existing app the user brought to deploy** (refine routes \"deploy my app\" here). **Use their\n>   project as the source** — copy/point `~/.hostinger/<domain>/src/` at it and keep its own framework and\n>   UI. **Do not scaffold a new project, and do not re-implement `design.md` over it** (so **the design\n>   step does not apply** to an app that brings its own UI). Your job is only to make it deployable: set\n>   `engines.node` to `22`, remove any `.htaccess`, wire its data/env, then hand off to deploy. **Skip the\n>   Step 2 design pass**, and ignore the `content-model.md` requirement in Step 3.\n> - **A new app built from the brief.** Scaffold and build it from `brief.md` (and `design.md` if the\n>   design step produced one — design *does* run for a from-scratch app). Its data is owned by the app, so\n>   there is still **no `content-model.md`** to bind against.\n>\n> Framework choice (Step 1), the build, and hand-off (Step 4) apply to both. The per-backend bullets in\n> Step 3 are **WordPress / WooCommerce / Ecommerce only** — for a webapp follow the Webapp bullet there.\n\n## Step 1 — Pick the framework (guess → default → confirm)\n\n**The rendering is already decided in `brief.md` → Rendering** (SSR or SSG, set during refine). Honour\nit, and the backend constraint:\n\n- **Ecommerce → SSR required** (carts/search need per-request rendering). Any SSR framework works —\n  Next.js is the default, not a requirement (Express, Nuxt, SvelteKit, etc. are all fine).\n- **WordPress + WooCommerce → SSR required** (same reason — cart/checkout need per-request rendering).\n- **WordPress → SSG (Astro)** when the brief says SSG, otherwise **SSR (Next.js default)**.\n- **Webapp → the app's own stack.** An **existing app** keeps its current framework (don't impose one); a\n  **new app** uses whatever fits the brief (SSR or SPA). Either way it deploys as a Node.js app (Step 8) —\n  an SSR app runs a server, a SPA builds to static output.\n- Map rendering → framework: **`ssr` → Next.js**, **`ssg` → Astro** — unless the brief/prompt explicitly\n  names another supported framework, in which case use that.\n\nSupported frameworks (what the Hostinger build pipeline can deploy — the `app_type` in Step 8 deploy):\n\n- **Server/SSR-capable:** Next.js, Nuxt.js, Astro, SvelteKit, Express, NestJS, Fastify.\n- **Static / SPA:** React, Vue, Angular, Vite, Parcel, Preact, Svelte, (Astro / SvelteKit static too).\n\nConfirm the framework with the user in one line only if the brief left it open. Record the choice in\n`state.json`:\n\n```json\n{ \"frontend\": { \"framework\": \"nextjs\", \"rendering\": \"ssr\" } }\n```\n\nIf the brief is silent, default to **Next.js SSR**. Ecommerce must be SSR (never SSG) — but the SSR\nframework itself is free to be any supported one, not just Next.js.\n\n## Step 2 — Implement `design.md` (don't re-design)\n\nThe look was already chosen and written by the design step. **Read `~/.hostinger/<domain>/design.md` and\nimplement it faithfully** — tokens (colour, type, spacing), components, per-page composition, imagery and\naccessibility — plus the logo files in `brand/`. Don't re-run design questions or invent a new direction here.\n\n- Treat `design.md` as the contract: the built pages should match its tokens, type scale, components and\n  per-page composition, and the 8-point grid / WCAG 2.2 AA rules it carries.\n- Use the **logo** from `brand/` as-is (wordmark, icon mark, favicon); never recolour or redraw it.\n- If `design.md` is **missing** (e.g. a resumed older build), fall back to `brief.md → Design direction`\n  (reference site, colours, brand, adjectives) and a tasteful, accessible default — but prefer `design.md`\n  whenever it exists.\n- **Don't gate on approval here** — the result is shown at **validate** (Step 7).\n\n**Only ask about the code, and only if it matters** (design decisions belong in the design step):\n- Where the **source should live** — default `~/.hostinger/<domain>/src/`; ask only if they want a\n  specific folder or an existing repo.\n- **Git** — initialise / connect / push (default: a local project, no remote).\n- A specific **component library** or technical must-have, if they implied one.\n\n## Step 3 — Build against the backend\n\nTwo phases around the instance barrier (see the top-level `SKILL.md`): scaffold + build the shell while\nprovision settles, then wire live data once `provision.status == \"completed\"`.\n\nRead the backend from `site.json`:\n\n- **WordPress** → `urls.rest_api` (`wp/v2`), public read. Content is in the posts/pages/categories/media\n  the content-model push created; nav/plan come from `content-model.md`. Map each item's **SEO** from its\n  `yoast_head_json` into the page `<head>` (title, description, Open Graph, JSON-LD schema) — Yoast is\n  installed by default at provision (`site.json → seo.enabled: true`). If `seo.enabled` is `false`\n  (Yoast absent), fall back to generating per-page title/description/OG tags from each item's content.\n  - **Contact form** (`site.json → contact_form.enabled: true`, any WordPress backend) → render the\n    contact page's form and submit it **client-side** to Contact Form 7's public feedback endpoint. Put a\n    `submitContactForm(data)` helper in the one data module: build a `FormData` with the field names from\n    `contact_form.fields` (e.g. `your-name`, `your-email`, `your-subject`, `your-message`) **plus CF7's\n    hidden fields** — `_wpcf7` = `contact_form.form_id`, `_wpcf7_version`, `_wpcf7_locale` (e.g. `en_US`),\n    `_wpcf7_unit_tag` (any stable string), `_wpcf7_container_post` = `0` — and `POST` it to\n    `contact_form.feedback_url` **without setting `Content-Type`** (let the browser add the multipart\n    boundary). `/cms` is same-origin, so no CORS and no secret. Branch on the JSON `status`: `mail_sent`\n    → success state; `validation_failed` → map `invalid_fields[].field` to per-input errors;\n    `spam`/`aborted`/`mail_failed` → a generic \"couldn't send, try again\" message. Include the honeypot\n    decoy field named in `contact_form.honeypot_field` (e.g. `your_website`), rendered hidden/off-screen,\n    **empty**, `autocomplete=\"off\"`, `tabindex=\"-1\"` — the deployed spam guard rejects it if filled. A user\n    validation error is a **normal UI state, not a build error**. When `contact_form.enabled` is `false` or absent, render the contact page with\n    plain contact details and **no form** — graceful, like disabled checkout; never half-build. Full\n    contract: `../04-content-model/wordpress/contact-form.md` §3.\n- **WordPress + WooCommerce** (`site.json → woocommerce.enabled: true`) → the WordPress bullet above **plus**\n  the store. Read the catalog over the **public WooCommerce Store API** (`site.json → urls.store_api`,\n  `/cms/wp-json/wc/store/v1`, no auth, open CORS): `GET /products` (prices are **integer minor units** on\n  `prices.price` with `prices.currency_minor_unit` — divide to display), `GET /products/categories`. Cart,\n  coupons and checkout are **client-side** against the Store API with the `Nonce` + `Cart-Token` headers\n  (`GET /cart`, `POST /cart/add-item`, `/cart/apply-coupon`, `POST /checkout`) — see\n  `../04-content-model/wordpress/woocommerce.md`. **Never embed a consumer key client-side**; the\n  storefront is fully public. Blog/pages on the same site still come from `urls.rest_api` (`wp/v2`) + Yoast.\n  - **Honour `site.json → woocommerce.payment_enabled`.** It is `false` until the owner enables a payment\n    gateway + shipping in wp-admin (that config isn't reachable headlessly — see the provision note). While\n    `false`, build the full catalog, product pages and the client-side cart as normal, but render a\n    graceful disabled-checkout state (e.g. a disabled \"Checkout\" with \"Checkout isn't set up yet\"), **don't\n    call `/checkout`**, and don't treat it as a build error. When `true`, wire checkout (`payment_method`\n    `\"cod\"` works out of the box).\n- **Ecommerce** → the **public Hostinger Storefront Core V2 API** (`https://api-ecommerce.hostinger.com/v2`,\n  no auth, open CORS), keyed on the **custom sales channel** (`site.json → ecommerce.sales_channel.id`):\n  `GET /channels/<scha_*>/products` (prices are **minor units** on variants), `POST /channels/<scha_*>/checkout`\n  for buying. Cart is client-side; never embed a token. Read\n  `ecommerce_miscellaneous_custom-storefront-setup-instructions` for the authoritative, current guide.\n  - **Honour `site.json → ecommerce.payment_enabled`.** When it is `false` (free account / no paid\n    Ecommerce plan — see the provision gate), there is **no checkout**: build the full catalog, product\n    pages and the client-side cart as normal, but **do not call the checkout endpoint**. Instead render\n    a clear, graceful state at the checkout step — e.g. a disabled \"Checkout\" button with a short note\n    like \"Online checkout isn't available on this plan yet\" (and/or a contact/enquiry fallback). A\n    missing checkout is **not** a build error here — never leave the storefront half-built, throw, or\n    retry checkout because payment is off. When `payment_enabled` is `true`, wire checkout normally.\n- **Webapp** → **no `content-model.md` and no headless backend to read**. The app uses its own data source:\n  the MySQL database from `site.json → database` (through the `DB_*` / `DATABASE_URL` env vars — set at\n  provision/deploy, see `../03-provision/webapp/SKILL.md` Step 3; `127.0.0.1` only resolves on the server,\n  not locally), or whatever external API the app calls. For an existing app, keep its data layer as-is.\n\nGuidelines (framework-agnostic):\n\n- **One data module** is the single place that talks to the backend (e.g. `src/lib/data.ts`) — one file\n  to inspect, one base URL to switch. Keep it swappable so the shell can build against stubs first.\n- **Fetch at request time for SSR** (fresh content, no rebuild); a static build fetches at build time.\n- **A failed or incomplete fetch is an error, not a silent empty/placeholder.** Planned content missing\n  from the API is a build error too — a site that builds with holes ships with holes. *(WordPress/Ecommerce;\n  a webapp has no planned content to check.)*\n- **`content-model.md` is the source for what should exist** (pages, nav, collections mapping) — for\n  WordPress/Ecommerce only; a **webapp has no `content-model.md`**.\n- **No `.htaccess`** in the project (deploy would overwrite the live one); don't commit `node_modules`\n  or build output.\n- Set `engines.node` to `22` (the deploy builds on Node 22).\n\n## Step 4 — Hand off\n\nConfirm the project builds clean locally against the live backend, no placeholder/fixture content\nremains, and `state.json → frontend` matches what you built. Update `state.json` (`stage: \"validate\"`).\nValidate (Step 7) owns the clean rebuild + user preview; deploy (Step 8) ships it with the `app_type`\nand output directory that match the chosen framework + rendering.\n\n> **Webapp:** just confirm the app builds clean and `state.json → frontend` is right — there's no\n> `content-model.md` or headless backend to check. A DB-backed app can't reach its database locally\n> (`127.0.0.1` is server-only), so its data layer is verified **after** deploy, not here.\n"
+        "text": "---\nname: headless-step-frontend\ndescription: \"Step 6 (frontend) of the Hostinger Headless flow. Builds the website that renders the backend's content. Figures out (or confirms) the framework — defaulting to Next.js SSR — implements the look already chosen in design.md (the design step's contract), and builds the source into src/. Only ask for the clarifications you actually need.\"\n---\n\n# headless-step-frontend\n\nBuild the site's frontend against the backend from `site.json`, implementing the look the design step\nalready chose and wrote to **`design.md`** (plus the logo in `brand/`). The design is decided; this step\nis where it becomes real code. There's no per-framework recipe — use good judgement, follow `design.md`\nas the contract, and ask only for the clarifications you genuinely need. **Out:** source in the site\nworkspace `~/.hostinger/<domain>/src/`.\n\n> ## ⚠️ Build mode: \"Bring your own frontend\"? Read this first (any backend)\n> Read `brief.md` → **Build mode**. When it is **Bring your own frontend**, the user already has a\n> frontend (the project in the folder the command was run in) and this step **wires it to the backend\n> from `site.json` — it does not scaffold a new project and there is usually no `design.md` to\n> implement** (the design step deferred to the user). **Use their project as the source**: copy or\n> point `~/.hostinger/<domain>/src/` at it, keep its framework and UI, and collaborate on changes at\n> the user's direction (vibe-code with them). Your job is to connect it to the live backend (WordPress\n> `wp/v2` reads, the WooCommerce/Ecommerce Store API, env/keys) and make it deployable (set\n> `engines.node` to `22`, remove any `.htaccess`), then hand off to deploy. This generalises the Webapp\n> \"existing app\" case below to WordPress and Ecommerce too. When **Build mode is \"Agent designs and\n> builds\"**, ignore this box and proceed normally (scaffold + implement `design.md`).\n\n> ## ⚠️ Webapp backend? Read this first\n> A `webapp` brief has **no CMS/store and no `content-model.md`** — the app owns its own data (its own\n> API, or the MySQL database recorded in `site.json → database`). It comes in two shapes, decided back in\n> **refine**:\n>\n> - **An existing app the user brought to deploy** (refine routes \"deploy my app\" here). **Use their\n>   project as the source** — copy/point `~/.hostinger/<domain>/src/` at it and keep its own framework and\n>   UI. **Do not scaffold a new project, and do not re-implement `design.md` over it** (so **the design\n>   step does not apply** to an app that brings its own UI). Your job is only to make it deployable: set\n>   `engines.node` to `22`, remove any `.htaccess`, wire its data/env, then hand off to deploy. **Skip the\n>   Step 2 design pass**, and ignore the `content-model.md` requirement in Step 3.\n> - **A new app built from the brief.** Scaffold and build it from `brief.md` (and `design.md` if the\n>   design step produced one — design *does* run for a from-scratch app). Its data is owned by the app, so\n>   there is still **no `content-model.md`** to bind against.\n>\n> Framework choice (Step 1), the build, and hand-off (Step 4) apply to both. The per-backend bullets in\n> Step 3 are **WordPress / WooCommerce / Ecommerce only** — for a webapp follow the Webapp bullet there.\n\n## Step 1 — Pick the framework (guess → default → confirm)\n\n**The rendering is already decided in `brief.md` → Rendering** (SSR or SSG, set during refine). Honour\nit, and the backend constraint:\n\n- **Ecommerce → SSR required** (carts/search need per-request rendering). Any SSR framework works —\n  Next.js is the default, not a requirement (Express, Nuxt, SvelteKit, etc. are all fine).\n- **WordPress + WooCommerce → SSR required** (same reason — cart/checkout need per-request rendering).\n- **WordPress → SSG (Astro)** when the brief says SSG, otherwise **SSR (Next.js default)**.\n- **Webapp → the app's own stack.** An **existing app** keeps its current framework (don't impose one); a\n  **new app** uses whatever fits the brief (SSR or SPA). Either way it deploys as a Node.js app (Step 8) —\n  an SSR app runs a server, a SPA builds to static output.\n- Map rendering → framework: **`ssr` → Next.js**, **`ssg` → Astro** — unless the brief/prompt explicitly\n  names another supported framework, in which case use that.\n\nSupported frameworks (what the Hostinger build pipeline can deploy — the `app_type` in Step 8 deploy):\n\n- **Server/SSR-capable:** Next.js, Nuxt.js, Astro, SvelteKit, Express, NestJS, Fastify.\n- **Static / SPA:** React, Vue, Angular, Vite, Parcel, Preact, Svelte, (Astro / SvelteKit static too).\n\nConfirm the framework with the user in one line only if the brief left it open. Record the choice in\n`state.json`:\n\n```json\n{ \"frontend\": { \"framework\": \"nextjs\", \"rendering\": \"ssr\" } }\n```\n\nIf the brief is silent, default to **Next.js SSR**. Ecommerce must be SSR (never SSG) — but the SSR\nframework itself is free to be any supported one, not just Next.js.\n\n## Step 2 — Implement `design.md` (don't re-design)\n\nThe look was already chosen and written by the design step. **Read `~/.hostinger/<domain>/design.md` and\nimplement it faithfully** — tokens (colour, type, spacing), components, per-page composition, imagery and\naccessibility — plus the logo files in `brand/`. Don't re-run design questions or invent a new direction here.\n\n- Treat `design.md` as the contract: the built pages should match its tokens, type scale, components and\n  per-page composition, and the 8-point grid / WCAG 2.2 AA rules it carries.\n- Use the **logo** from `brand/` as-is (wordmark, icon mark, favicon); never recolour or redraw it.\n- If `design.md` is **missing** (e.g. a resumed older build), fall back to `brief.md → Design direction`\n  (reference site, colours, brand, adjectives) and a tasteful, accessible default — but prefer `design.md`\n  whenever it exists.\n- **Don't gate on approval here** — the result is shown at **validate** (Step 7).\n\n**Only ask about the code, and only if it matters** (design decisions belong in the design step):\n- Where the **source should live** — default `~/.hostinger/<domain>/src/`; ask only if they want a\n  specific folder or an existing repo.\n- **Git** — initialise / connect / push (default: a local project, no remote).\n- A specific **component library** or technical must-have, if they implied one.\n\n## Step 3 — Build against the backend\n\nTwo phases around the instance barrier (see the top-level `SKILL.md`): scaffold + build the shell while\nprovision settles, then wire live data once `provision.status == \"completed\"`.\n\nRead the backend from `site.json`:\n\n- **WordPress** → `urls.rest_api` (`wp/v2`), public read. Content is in the posts/pages/categories/media\n  the content-model push created; nav/plan come from `content-model.md`. Map each item's **SEO** from its\n  `yoast_head_json` into the page `<head>` (title, description, Open Graph, JSON-LD schema) — Yoast is\n  installed by default at provision (`site.json → seo.enabled: true`). If `seo.enabled` is `false`\n  (Yoast absent), fall back to generating per-page title/description/OG tags from each item's content.\n  - **Contact form** (`site.json → contact_form.enabled: true`, any WordPress backend) → render the\n    contact page's form and submit it **client-side** to Contact Form 7's public feedback endpoint. Put a\n    `submitContactForm(data)` helper in the one data module: build a `FormData` with the field names from\n    `contact_form.fields` (e.g. `your-name`, `your-email`, `your-subject`, `your-message`) **plus CF7's\n    hidden fields** — `_wpcf7` = `contact_form.form_id`, `_wpcf7_version`, `_wpcf7_locale` (e.g. `en_US`),\n    `_wpcf7_unit_tag` (any stable string), `_wpcf7_container_post` = `0` — and `POST` it to\n    `contact_form.feedback_url` **without setting `Content-Type`** (let the browser add the multipart\n    boundary). `/cms` is same-origin, so no CORS and no secret. Branch on the JSON `status`: `mail_sent`\n    → success state; `validation_failed` → map `invalid_fields[].field` to per-input errors;\n    `spam`/`aborted`/`mail_failed` → a generic \"couldn't send, try again\" message. Include the honeypot\n    decoy field named in `contact_form.honeypot_field` (e.g. `your_website`), rendered hidden/off-screen,\n    **empty**, `autocomplete=\"off\"`, `tabindex=\"-1\"` — the deployed spam guard rejects it if filled. A user\n    validation error is a **normal UI state, not a build error**. When `contact_form.enabled` is `false` or absent, render the contact page with\n    plain contact details and **no form** — graceful, like disabled checkout; never half-build. Full\n    contract: `../04-content-model/wordpress/contact-form.md` §3.\n- **WordPress + WooCommerce** (`site.json → woocommerce.enabled: true`) → the WordPress bullet above **plus**\n  the store. Read the catalog over the **public WooCommerce Store API** (`site.json → urls.store_api`,\n  `/cms/wp-json/wc/store/v1`, no auth, open CORS): `GET /products` (prices are **integer minor units** on\n  `prices.price` with `prices.currency_minor_unit` — divide to display), `GET /products/categories`. Cart,\n  coupons and checkout are **client-side** against the Store API with the `Nonce` + `Cart-Token` headers\n  (`GET /cart`, `POST /cart/add-item`, `/cart/apply-coupon`, `POST /checkout`) — see\n  `../04-content-model/wordpress/woocommerce.md`. **Never embed a consumer key client-side**; the\n  storefront is fully public. Blog/pages on the same site still come from `urls.rest_api` (`wp/v2`) + Yoast.\n  - **Honour `site.json → woocommerce.payment_enabled`.** It is `false` until the owner enables a payment\n    gateway + shipping in wp-admin (that config isn't reachable headlessly — see the provision note). While\n    `false`, build the full catalog, product pages and the client-side cart as normal, but render a\n    graceful disabled-checkout state (e.g. a disabled \"Checkout\" with \"Checkout isn't set up yet\"), **don't\n    call `/checkout`**, and don't treat it as a build error. When `true`, wire checkout (`payment_method`\n    `\"cod\"` works out of the box).\n- **Ecommerce** → the **public Hostinger Storefront Core V2 API** (`https://api-ecommerce.hostinger.com/v2`,\n  no auth, open CORS), keyed on the **custom sales channel** (`site.json → ecommerce.sales_channel.id`):\n  `GET /channels/<scha_*>/products` (prices are **minor units** on variants), `POST /channels/<scha_*>/checkout`\n  for buying. Cart is client-side; never embed a token. Read\n  `ecommerce_miscellaneous_custom-storefront-setup-instructions` for the authoritative, current guide.\n  - **Honour `site.json → ecommerce.payment_enabled`.** When it is `false` (free account / no paid\n    Ecommerce plan — see the provision gate), there is **no checkout**: build the full catalog, product\n    pages and the client-side cart as normal, but **do not call the checkout endpoint**. Instead render\n    a clear, graceful state at the checkout step — e.g. a disabled \"Checkout\" button with a short note\n    like \"Online checkout isn't available on this plan yet\" (and/or a contact/enquiry fallback). A\n    missing checkout is **not** a build error here — never leave the storefront half-built, throw, or\n    retry checkout because payment is off. When `payment_enabled` is `true`, wire checkout normally.\n- **Webapp** → **no `content-model.md` and no headless backend to read**. The app uses its own data source:\n  the MySQL database from `site.json → database` (through the `DB_*` / `DATABASE_URL` env vars — set at\n  provision/deploy, see `../03-provision/webapp/SKILL.md` Step 3; `127.0.0.1` only resolves on the server,\n  not locally), or whatever external API the app calls. For an existing app, keep its data layer as-is.\n\nGuidelines (framework-agnostic):\n\n- **One data module** is the single place that talks to the backend (e.g. `src/lib/data.ts`) — one file\n  to inspect, one base URL to switch. Keep it swappable so the shell can build against stubs first.\n- **Fetch at request time for SSR** (fresh content, no rebuild); a static build fetches at build time.\n- **A failed or incomplete fetch is an error, not a silent empty/placeholder.** Planned content missing\n  from the API is a build error too — a site that builds with holes ships with holes. *(WordPress/Ecommerce;\n  a webapp has no planned content to check.)*\n- **`content-model.md` is the source for what should exist** (pages, nav, collections mapping) — for\n  WordPress/Ecommerce only; a **webapp has no `content-model.md`**.\n- **No `.htaccess`** in the project (deploy would overwrite the live one); don't commit `node_modules`\n  or build output.\n- Set `engines.node` to `22` (the deploy builds on Node 22).\n- **Next.js 16+ only:** set the `build` script to `next build --webpack`, not plain `next build`. Next.js\n  16 defaults `next build` to **Turbopack**, whose native compiler needs a newer glibc than the Hostinger\n  build server has, so a Turbopack build fails on deploy and won't fall back to webpack. Webpack builds\n  clean there. The `--webpack` flag exists only on Next.js 16+; on **Next.js 15.x** leave the build script\n  as plain `next build` (it already defaults to webpack). (Alternative: pin Next.js to `15.x`, keeping\n  plain `next build`.)\n\n## Step 4 — Hand off\n\nConfirm the project builds clean locally against the live backend, no placeholder/fixture content\nremains, and `state.json → frontend` matches what you built. Update `state.json` (`stage: \"validate\"`).\nValidate (Step 7) owns the clean rebuild + user preview; deploy (Step 8) ships it with the `app_type`\nand output directory that match the chosen framework + rendering.\n\n> **Webapp:** just confirm the app builds clean and `state.json → frontend` is right — there's no\n> `content-model.md` or headless backend to check. A DB-backed app can't reach its database locally\n> (`127.0.0.1` is server-only), so its data layer is verified **after** deploy, not here.\n"
       },
       {
         "uri": "skill://hostinger-headless/steps/07-validate/SKILL.md",
@@ -246,10 +246,10 @@ export default [
       },
       {
         "uri": "skill://hostinger-headless/steps/08-deploy/SKILL.md",
-        "digest": "sha256:a45c01ae27975a636fa200c386e8a56397dff4847ba62f72e11fd69990d82ea2",
-        "size": 10613,
+        "digest": "sha256:c6f2ef2d62ae4ba0ab7686148e1898585c8c93bcb22e91c2bcf25b80f7bd987d",
+        "size": 12010,
         "mimeType": "text/markdown",
-        "text": "---\nname: headless-step-deploy\ndescription: \"Step 8 (deploy) of the Hostinger Headless flow. Archives the frontend source, then deploys through the connector's one-shot hosting_deploy (type nodejs — it uploads the source, runs npm install and the build on the server) with the chosen framework's build settings (appType + output dir) passed explicitly, polls to completion with hosting_get-deployment, verifies the live site and that the backend survived, then writes deploy.json.\"\n---\n\n# headless-step-deploy\n\nShip the frontend to the live domain through the Hostinger connector. You hand the connector a zip of\nthe project **source** and it uploads it, runs `npm install` + the build script on the server, and\nserves the result. **Out:** `deploy.json`.\n\nThis is an **instance-barrier** step: run it only after `provision.status == \"completed\"` and validate\n(if run) has passed. All operations go through the connector (`execute`).\n\n**In:** the project in `~/.hostinger/<domain>/src/`, `site.json` (`username`, `urls`), `state.json`\n(`frontend.framework`, `frontend.rendering`).\n\n> ## ⚠️ The one rule that makes this work: pass build settings explicitly\n> If you let `hosting_deploy` **auto-detect** build settings, for a headless site that detection returns\n> **null** (`appType:null`, `outputDirectory:null`, Node 20) — the build \"completes\" but the **root\n> serves 403** (no `appType`/output → the vhost serves a directory with no entry). This is reproducible.\n> **Always pass `appType`, `outputDirectory`, `nodeVersion`, `buildScript`, `packageManager` and\n> `rootDirectory` on the `hosting_deploy` call** with the framework's values; the deploy then resolves\n> them and serves correctly, and `/cms` is preserved.\n\n## Build configurations\n\nMap `frontend.framework` (from `state.json`) to its `appType` + build output directory, and pass those\non the `hosting_deploy` call. `appType` is the framework's value, e.g. `next`, `nuxt`, `astro`,\n`svelte-kit`, `nest`, `express`, `fastify`, `react`, `create-react-app`, `gatsby`, `vite`, `vue`,\n`angular`, `parcel`, `svelte`, `other`.\n\nCommon cases (all `nodeVersion: 22`, `buildScript: \"build\"`, `packageManager: \"npm\"`, `rootDirectory: \".\"`):\n\n| Framework / mode | Local config | `appType` | `outputDirectory` |\n|---|---|---|---|\n| **Next.js — SSR** *(default)* | `output: 'standalone'` | `next` | `.next` |\n| **Nuxt — SSR** | default | `nuxt` | `.output` |\n| **SvelteKit — SSR** | node adapter | `svelte-kit` | `build` |\n| **Astro — static** | `output: 'static'` | `astro` | `dist` |\n| **Vite / React / Vue — static (SPA)** | — | `vite` (or `react`/`vue`) | `dist` |\n| **Express / NestJS / Fastify — server** | — | `express`/`nest`/`fastify` | build output dir |\n\nSSR/server frameworks run a persistent Node process (root sends `x-powered-by` / `cache-control: no-store`);\nstatic frameworks serve their output dir as files. If unsure of a framework's output dir, check the\nframework's own build output, but **always pass `appType`/`outputDirectory` on the deploy call with the\nframework's correct values** — don't rely on auto-detection (it returns null → 403).\n\n## Step 1 — Pre-flight\n\n1. **Instance live.** `provision.status == \"completed\"`, re-verified with\n   `hosting_websites_list-setups { \"domain\": \"<domain>\" }`.\n2. **Build output exists locally** (the framework's output dir — e.g. `.next/`, `dist/`, `.output/`) and\n   the project builds clean (frontend/validate already did this). If not, go back.\n3. **Env vars (only if used).** Build-time vars (e.g. `NEXT_PUBLIC_*`) must be set **before** the build\n   with `hosting_nodejs_replace-environment-variables` (full replace). Never put secrets in the repo or\n   the archive. **Webapp with a database:** that full replace wipes the `DB_*`/`DATABASE_URL` that\n   `hosting_databases_setup-website` injected (the generated password reads back masked), so set all app\n   vars in the same replace and, if you can't, first reset the password with\n   `hosting_databases_change-password` and resend every `DB_*`/`DATABASE_URL` — see\n   `../03-provision/webapp/SKILL.md` Step 3.\n\n## Step 2 — Archive the source\n\nZip the project **source** with `package.json` at the archive root. **Include** the app/source,\n`public/`, the framework config (`next.config.mjs` / `astro.config.mjs`), `tsconfig.json`,\n`package.json`, `package-lock.json`, `.nvmrc`. **Exclude** `node_modules/`, the build output\n(`.next/`, `dist/`, `out/`), `.git/`, and any `.htaccess` — the server installs and builds from source.\n\n```bash\ncd ~/.hostinger/<domain>/src\nzip -r -X ../app.zip . -x 'node_modules/*' '.next/*' 'dist/*' 'out/*' '.git/*' '**/.htaccess'\n```\n\n## Step 3 — Deploy (one shot: settings + upload + build)\n\nPass the framework's build settings **inline** on the deploy call — there is no separate settings step.\n`path` is the archive from Step 2 (or the source directory itself; `hosting_deploy` archives a directory\nfor you, skipping `node_modules/`, `.git/` and `.env`, but it does **not** read `.gitignore`, so the\nbuild output must already be absent).\n\n```json\n{ \"operation\": \"hosting_deploy\",\n  \"params\": {\n    \"domain\": \"<domain>\",\n    \"path\": \"/absolute/path/to/.hostinger/<domain>/app.zip\",\n    \"type\": \"nodejs\",\n    \"appType\": \"<framework appType, e.g. next>\",\n    \"outputDirectory\": \"<framework output dir, e.g. .next>\",\n    \"nodeVersion\": 22,\n    \"buildScript\": \"build\",\n    \"packageManager\": \"npm\",\n    \"rootDirectory\": \".\" } }\n```\n\n`hosting_deploy` uploads the source and triggers `npm install` + the build **end-to-end** — do not call\nany upload or build operation yourself. It returns a build `buildUuid` at once. This **overwrites the\nwebsite root** (expected) and keeps `/cms` intact. Passing `appType`/`outputDirectory` explicitly is what\nkeeps the root from serving 403 (see the rule above).\n\n## Step 4 — Poll to completion\n\nPoll `hosting_get-deployment { \"domain\": \"<domain>\", \"buildUuid\": \"<buildUuid>\" }` with backoff until\n`build.state` is `completed`. On `failed`, the same response carries the end of the build log and the\nfailure analysis — read it, fix locally, re-archive and redeploy (pass `fromLine`, the line count from\nthe previous call, to read only new log output). `hosting_get-deployment` also returns the build settings\nstored for the site: `appType`/`outputDirectory`/`nodeVersion` should echo what you passed; if they read\n`null`, the settings didn't take — fix the deploy call before continuing. For an SSR app that built but\nhangs, `hosting_nodejs_restart-application { username, domain }` recovers the server without a rebuild.\n\n## Step 5 — Verify the live site (all must pass)\n\n| Check | How | Expect |\n|---|---|---|\n| Root serves | `GET https://<domain>/` | **200** (not 403 / 404) |\n| SSR is live *(server frameworks)* | response headers | `x-powered-by` present, `cache-control: no-store` |\n| Static serves *(static frameworks)* | `GET https://<domain>/` | 200 HTML with real home content |\n| Key routes | a couple of planned routes + one deep route | 200, real content |\n| **Backend survived** *(WordPress / WooCommerce)* | `GET https://<domain>/cms/wp-json/wp/v2/posts?per_page=1` | 200 |\n\n> **Only WordPress (including WordPress + WooCommerce) has a `/cms` on the domain**, so the *Backend\n> survived* check is WordPress-only.\n> - **WordPress + WooCommerce:** also confirm the store survived the deploy —\n>   `GET https://<domain>/cms/wp-json/wc/store/v1/products?per_page=1` → 200. There is nothing external to\n>   link (no sales-channel step — that's Ecommerce only). **Checkout** stays owner-completed: when\n>   `site.json → woocommerce.payment_enabled` is `false`, don't test `/checkout`; a catalog that serves 200\n>   is a passing, complete deploy.\n> - **Ecommerce:** the backend is the **Hostinger Ecommerce store**, read over the external Storefront API\n>   (`api-ecommerce.hostinger.com`) — nothing a deploy touches lives on this domain. There is no `/cms`;\n>   confirm the storefront still fetches products as a frontend check if you like. **Only check that\n>   checkout can be reached when `site.json → ecommerce.payment_enabled` is `true`** — on a free account\n>   (`payment_enabled: false`) there is no checkout, so **skip that check entirely**; a catalog that serves\n>   200 is a passing, complete deploy. Never fail or hold the deploy because checkout is unavailable.\n> - **Webapp:** no content backend at all — the whole root is the app. Skip the check; `/cms` won't resolve.\n\nA `completed` build whose root 403s almost always means the build settings weren't passed to\n`hosting_deploy` (null settings) — pass them and redeploy. Caching can briefly serve a stale root;\nre-check after ~30 s.\n\n## Step 6 — Record `deploy.json`\n\n```json\n{\n  \"build_uuid\": \"…\",\n  \"stack\": \"nextjs\",\n  \"rendering\": \"ssr\",\n  \"app_type\": \"next\",\n  \"output_directory\": \".next\",\n  \"node_version\": 22,\n  \"method\": \"hosting_deploy (type: nodejs, settings passed inline)\",\n  \"deployed_at\": \"…\",\n  \"verified_at\": \"…\",\n  \"urls\": { \"live\": \"https://<domain>\", \"cms\": \"https://<domain>/cms\" },\n  \"checks\": { \"root\": 200, \"ssr_headers\": true, \"backend_preserved\": true }\n}\n```\n\nNo secrets in `deploy.json`. The `urls.cms` field and the `backend_preserved` check above are\n**WordPress-only** — adjust the record to the backend:\n\n- **WordPress:** keep `urls.cms` and `checks.backend_preserved` as shown.\n- **WordPress + WooCommerce:** keep `urls.cms` + `checks.backend_preserved` (it *is* WordPress), and add\n  `urls.store_api` from `site.json`; no external link step.\n- **Ecommerce:** omit `urls.cms`/`backend_preserved`; record the store URLs instead (`urls.storefront_api`,\n  `urls.store_admin` from `site.json`) and link the custom sales channel to the live domain —\n  `ecommerce_sales-channels_update { store_id, sales_channel_id, url }` (see the ecommerce provision step).\n- **Webapp:** omit `urls.cms` and `backend_preserved` entirely — `urls` is just `{ \"live\": \"https://<domain>\" }`.\n\nUpdate `state.json` (`stage` → `done`), then continue to Step 9 (done).\n\n---\n\n## Note — one deploy path, and never `type: \"static\"`\n\n`hosting_deploy` is the only path: give its `path` either the source **directory** (it archives it for\nyou) or a local **archive** (`zip`, `tar`, `tar.gz`, `tgz`, `7z`) — there is no separate upload or build\nstep to fall back to. Either way pass the explicit `appType`/`outputDirectory`/`nodeVersion`/\n`buildScript`/`packageManager`/`rootDirectory` from the table. Never deploy a headless site with\n`type: \"static\"` — it serves the directory as plain files and can overwrite `/cms`.\n"
+        "text": "---\nname: headless-step-deploy\ndescription: \"Step 8 (deploy) of the Hostinger Headless flow. Archives the frontend source, then deploys through the connector's one-shot hosting_deploy (type nodejs — it uploads the source, runs npm install and the build on the server) with the chosen framework's build settings (appType + output dir) passed explicitly, polls to completion with hosting_get-deployment, verifies the live site and that the backend survived, then writes deploy.json.\"\n---\n\n# headless-step-deploy\n\nShip the frontend to the live domain through the Hostinger connector. You hand the connector a zip of\nthe project **source** and it uploads it, runs `npm install` + the build script on the server, and\nserves the result. **Out:** `deploy.json`.\n\nThis is an **instance-barrier** step: run it only after `provision.status == \"completed\"` and validate\n(if run) has passed. All operations go through the connector (`execute`).\n\n**In:** the project in `~/.hostinger/<domain>/src/`, `site.json` (`username`, `urls`), `state.json`\n(`frontend.framework`, `frontend.rendering`).\n\n> ## ⚠️ The one rule that makes this work: pass build settings explicitly\n> If you let `hosting_deploy` **auto-detect** build settings, for a headless site that detection returns\n> **null** (`appType:null`, `outputDirectory:null`, Node 20) — the build \"completes\" but the **root\n> serves 403** (no `appType`/output → the vhost serves a directory with no entry). This is reproducible.\n> **Always pass `appType`, `outputDirectory`, `nodeVersion`, `buildScript`, `packageManager` and\n> `rootDirectory` on the `hosting_deploy` call** with the framework's values; the deploy then resolves\n> them and serves correctly, and `/cms` is preserved.\n\n## Build configurations\n\nMap `frontend.framework` (from `state.json`) to its `appType` + build output directory, and pass those\non the `hosting_deploy` call. `appType` is the framework's value, e.g. `next`, `nuxt`, `astro`,\n`svelte-kit`, `nest`, `express`, `fastify`, `react`, `create-react-app`, `gatsby`, `vite`, `vue`,\n`angular`, `parcel`, `svelte`, `other`.\n\nCommon cases (all `nodeVersion: 22`, `buildScript: \"build\"`, `packageManager: \"npm\"`, `rootDirectory: \".\"`):\n\n| Framework / mode | Local config | `appType` | `outputDirectory` |\n|---|---|---|---|\n| **Next.js — SSR** *(default)* | `output: 'standalone'` | `next` | `.next` |\n| **Nuxt — SSR** | default | `nuxt` | `.output` |\n| **SvelteKit — SSR** | node adapter | `svelte-kit` | `build` |\n| **Astro — static** | `output: 'static'` | `astro` | `dist` |\n| **Vite / React / Vue — static (SPA)** | — | `vite` (or `react`/`vue`) | `dist` |\n| **Express / NestJS / Fastify — server** | — | `express`/`nest`/`fastify` | build output dir |\n\nSSR/server frameworks run a persistent Node process (root sends `x-powered-by` / `cache-control: no-store`);\nstatic frameworks serve their output dir as files. If unsure of a framework's output dir, check the\nframework's own build output, but **always pass `appType`/`outputDirectory` on the deploy call with the\nframework's correct values** — don't rely on auto-detection (it returns null → 403).\n\n> ## ⚠️ Next.js 16+: build with webpack, not Turbopack (recurring deploy failure)\n> Next.js 16 makes **Turbopack** the default bundler for `next build`. Turbopack's native (Rust)\n> compiler needs a newer **glibc** than the Hostinger build server ships, so the server build aborts\n> with a \"glibc too old\" error — and Turbopack **does not fall back** to webpack on its own, so the\n> deploy fails every time. **Fix: build with webpack.** On **Next.js 16+** the project's `build` script\n> in `package.json` must be `next build --webpack` (not plain `next build`); `buildScript` on the deploy\n> call stays `\"build\"` — that's what runs it. The `--webpack` flag exists only on Next.js 16+; on\n> **Next.js 15.x** leave the build script as plain `next build` (it already defaults to webpack).\n> **Confirm this in `package.json` before deploying** (the frontend step scaffolds it this way — see\n> `../06-frontend`). Alternative, only if you must avoid the `--webpack` flag: pin Next.js to `15.x`\n> (keeping plain `next build`), whose `next build` still defaults to webpack. Next.js only — other\n> frameworks are unaffected.\n\n## Step 1 — Pre-flight\n\n1. **Instance live.** `provision.status == \"completed\"`, re-verified with\n   `hosting_websites_list-setups { \"domain\": \"<domain>\" }`.\n2. **Build output exists locally** (the framework's output dir — e.g. `.next/`, `dist/`, `.output/`) and\n   the project builds clean (frontend/validate already did this). If not, go back.\n   - **Next.js 16+:** `package.json`'s `build` script is `next build --webpack`, not plain `next build` —\n     the server's glibc can't run Turbopack's native compiler (see the box above). On Next.js 15.x leave it\n     as plain `next build`. Fix it here if it isn't.\n3. **Env vars (only if used).** Build-time vars (e.g. `NEXT_PUBLIC_*`) must be set **before** the build\n   with `hosting_nodejs_replace-environment-variables` (full replace). Never put secrets in the repo or\n   the archive. **Webapp with a database:** that full replace wipes the `DB_*`/`DATABASE_URL` that\n   `hosting_databases_setup-website` injected (the generated password reads back masked), so set all app\n   vars in the same replace and, if you can't, first reset the password with\n   `hosting_databases_change-password` and resend every `DB_*`/`DATABASE_URL` — see\n   `../03-provision/webapp/SKILL.md` Step 3.\n\n## Step 2 — Archive the source\n\nZip the project **source** with `package.json` at the archive root. **Include** the app/source,\n`public/`, the framework config (`next.config.mjs` / `astro.config.mjs`), `tsconfig.json`,\n`package.json`, `package-lock.json`, `.nvmrc`. **Exclude** `node_modules/`, the build output\n(`.next/`, `dist/`, `out/`), `.git/`, and any `.htaccess` — the server installs and builds from source.\n\n```bash\ncd ~/.hostinger/<domain>/src\nzip -r -X ../app.zip . -x 'node_modules/*' '.next/*' 'dist/*' 'out/*' '.git/*' '**/.htaccess'\n```\n\n## Step 3 — Deploy (one shot: settings + upload + build)\n\nPass the framework's build settings **inline** on the deploy call — there is no separate settings step.\n`path` is the archive from Step 2 (or the source directory itself; `hosting_deploy` archives a directory\nfor you, skipping `node_modules/`, `.git/` and `.env`, but it does **not** read `.gitignore`, so the\nbuild output must already be absent).\n\n```json\n{ \"operation\": \"hosting_deploy\",\n  \"params\": {\n    \"domain\": \"<domain>\",\n    \"path\": \"/absolute/path/to/.hostinger/<domain>/app.zip\",\n    \"type\": \"nodejs\",\n    \"appType\": \"<framework appType, e.g. next>\",\n    \"outputDirectory\": \"<framework output dir, e.g. .next>\",\n    \"nodeVersion\": 22,\n    \"buildScript\": \"build\",\n    \"packageManager\": \"npm\",\n    \"rootDirectory\": \".\" } }\n```\n\n`hosting_deploy` uploads the source and triggers `npm install` + the build **end-to-end** — do not call\nany upload or build operation yourself. It returns a build `buildUuid` at once. This **overwrites the\nwebsite root** (expected) and keeps `/cms` intact. Passing `appType`/`outputDirectory` explicitly is what\nkeeps the root from serving 403 (see the rule above).\n\n## Step 4 — Poll to completion\n\nPoll `hosting_get-deployment { \"domain\": \"<domain>\", \"buildUuid\": \"<buildUuid>\" }` with backoff until\n`build.state` is `completed`. On `failed`, the same response carries the end of the build log and the\nfailure analysis — read it, fix locally, re-archive and redeploy (pass `fromLine`, the line count from\nthe previous call, to read only new log output). `hosting_get-deployment` also returns the build settings\nstored for the site: `appType`/`outputDirectory`/`nodeVersion` should echo what you passed; if they read\n`null`, the settings didn't take — fix the deploy call before continuing. For an SSR app that built but\nhangs, `hosting_nodejs_restart-application { username, domain }` recovers the server without a rebuild.\n\n## Step 5 — Verify the live site (all must pass)\n\n| Check | How | Expect |\n|---|---|---|\n| Root serves | `GET https://<domain>/` | **200** (not 403 / 404) |\n| SSR is live *(server frameworks)* | response headers | `x-powered-by` present, `cache-control: no-store` |\n| Static serves *(static frameworks)* | `GET https://<domain>/` | 200 HTML with real home content |\n| Key routes | a couple of planned routes + one deep route | 200, real content |\n| **Backend survived** *(WordPress / WooCommerce)* | `GET https://<domain>/cms/wp-json/wp/v2/posts?per_page=1` | 200 |\n\n> **Only WordPress (including WordPress + WooCommerce) has a `/cms` on the domain**, so the *Backend\n> survived* check is WordPress-only.\n> - **WordPress + WooCommerce:** also confirm the store survived the deploy —\n>   `GET https://<domain>/cms/wp-json/wc/store/v1/products?per_page=1` → 200. There is nothing external to\n>   link (no sales-channel step — that's Ecommerce only). **Checkout** stays owner-completed: when\n>   `site.json → woocommerce.payment_enabled` is `false`, don't test `/checkout`; a catalog that serves 200\n>   is a passing, complete deploy.\n> - **Ecommerce:** the backend is the **Hostinger Ecommerce store**, read over the external Storefront API\n>   (`api-ecommerce.hostinger.com`) — nothing a deploy touches lives on this domain. There is no `/cms`;\n>   confirm the storefront still fetches products as a frontend check if you like. **Only check that\n>   checkout can be reached when `site.json → ecommerce.payment_enabled` is `true`** — on a free account\n>   (`payment_enabled: false`) there is no checkout, so **skip that check entirely**; a catalog that serves\n>   200 is a passing, complete deploy. Never fail or hold the deploy because checkout is unavailable.\n> - **Webapp:** no content backend at all — the whole root is the app. Skip the check; `/cms` won't resolve.\n\nA `completed` build whose root 403s almost always means the build settings weren't passed to\n`hosting_deploy` (null settings) — pass them and redeploy. Caching can briefly serve a stale root;\nre-check after ~30 s.\n\n## Step 6 — Record `deploy.json`\n\n```json\n{\n  \"build_uuid\": \"…\",\n  \"stack\": \"nextjs\",\n  \"rendering\": \"ssr\",\n  \"app_type\": \"next\",\n  \"output_directory\": \".next\",\n  \"node_version\": 22,\n  \"method\": \"hosting_deploy (type: nodejs, settings passed inline)\",\n  \"deployed_at\": \"…\",\n  \"verified_at\": \"…\",\n  \"urls\": { \"live\": \"https://<domain>\", \"cms\": \"https://<domain>/cms\" },\n  \"checks\": { \"root\": 200, \"ssr_headers\": true, \"backend_preserved\": true }\n}\n```\n\nNo secrets in `deploy.json`. The `urls.cms` field and the `backend_preserved` check above are\n**WordPress-only** — adjust the record to the backend:\n\n- **WordPress:** keep `urls.cms` and `checks.backend_preserved` as shown.\n- **WordPress + WooCommerce:** keep `urls.cms` + `checks.backend_preserved` (it *is* WordPress), and add\n  `urls.store_api` from `site.json`; no external link step.\n- **Ecommerce:** omit `urls.cms`/`backend_preserved`; record the store URLs instead (`urls.storefront_api`,\n  `urls.store_admin` from `site.json`) and link the custom sales channel to the live domain —\n  `ecommerce_sales-channels_update { store_id, sales_channel_id, url }` (see the ecommerce provision step).\n- **Webapp:** omit `urls.cms` and `backend_preserved` entirely — `urls` is just `{ \"live\": \"https://<domain>\" }`.\n\nUpdate `state.json` (`stage` → `done`), then continue to Step 9 (done).\n\n---\n\n## Note — one deploy path, and never `type: \"static\"`\n\n`hosting_deploy` is the only path: give its `path` either the source **directory** (it archives it for\nyou) or a local **archive** (`zip`, `tar`, `tar.gz`, `tgz`, `7z`) — there is no separate upload or build\nstep to fall back to. Either way pass the explicit `appType`/`outputDirectory`/`nodeVersion`/\n`buildScript`/`packageManager`/`rootDirectory` from the table. Never deploy a headless site with\n`type: \"static\"` — it serves the directory as plain files and can overwrite `/cms`.\n"
       },
       {
         "uri": "skill://hostinger-headless/steps/09-done/SKILL.md",

package/src/core/skills.ts

@@ -246,10 +246,10 @@ const skills: Skill[] = [
       },
       {
         "uri": "skill://hostinger-headless/steps/06-frontend/SKILL.md",
-        "digest": "sha256:2783b21dd7cd261a93b084c2f9718b91c29deee1a158b0c240102bde6ed8a512",
-        "size": 13449,
+        "digest": "sha256:78a73a17fcff1d5ff8a6476e612b79d42809e9e36009b5db2b21153249904d4c",
+        "size": 13998,
         "mimeType": "text/markdown",
-        "text": "---\nname: headless-step-frontend\ndescription: \"Step 6 (frontend) of the Hostinger Headless flow. Builds the website that renders the backend's content. Figures out (or confirms) the framework — defaulting to Next.js SSR — implements the look already chosen in design.md (the design step's contract), and builds the source into src/. Only ask for the clarifications you actually need.\"\n---\n\n# headless-step-frontend\n\nBuild the site's frontend against the backend from `site.json`, implementing the look the design step\nalready chose and wrote to **`design.md`** (plus the logo in `brand/`). The design is decided; this step\nis where it becomes real code. There's no per-framework recipe — use good judgement, follow `design.md`\nas the contract, and ask only for the clarifications you genuinely need. **Out:** source in the site\nworkspace `~/.hostinger/<domain>/src/`.\n\n> ## ⚠️ Build mode: \"Bring your own frontend\"? Read this first (any backend)\n> Read `brief.md` → **Build mode**. When it is **Bring your own frontend**, the user already has a\n> frontend (the project in the folder the command was run in) and this step **wires it to the backend\n> from `site.json` — it does not scaffold a new project and there is usually no `design.md` to\n> implement** (the design step deferred to the user). **Use their project as the source**: copy or\n> point `~/.hostinger/<domain>/src/` at it, keep its framework and UI, and collaborate on changes at\n> the user's direction (vibe-code with them). Your job is to connect it to the live backend (WordPress\n> `wp/v2` reads, the WooCommerce/Ecommerce Store API, env/keys) and make it deployable (set\n> `engines.node` to `22`, remove any `.htaccess`), then hand off to deploy. This generalises the Webapp\n> \"existing app\" case below to WordPress and Ecommerce too. When **Build mode is \"Agent designs and\n> builds\"**, ignore this box and proceed normally (scaffold + implement `design.md`).\n\n> ## ⚠️ Webapp backend? Read this first\n> A `webapp` brief has **no CMS/store and no `content-model.md`** — the app owns its own data (its own\n> API, or the MySQL database recorded in `site.json → database`). It comes in two shapes, decided back in\n> **refine**:\n>\n> - **An existing app the user brought to deploy** (refine routes \"deploy my app\" here). **Use their\n>   project as the source** — copy/point `~/.hostinger/<domain>/src/` at it and keep its own framework and\n>   UI. **Do not scaffold a new project, and do not re-implement `design.md` over it** (so **the design\n>   step does not apply** to an app that brings its own UI). Your job is only to make it deployable: set\n>   `engines.node` to `22`, remove any `.htaccess`, wire its data/env, then hand off to deploy. **Skip the\n>   Step 2 design pass**, and ignore the `content-model.md` requirement in Step 3.\n> - **A new app built from the brief.** Scaffold and build it from `brief.md` (and `design.md` if the\n>   design step produced one — design *does* run for a from-scratch app). Its data is owned by the app, so\n>   there is still **no `content-model.md`** to bind against.\n>\n> Framework choice (Step 1), the build, and hand-off (Step 4) apply to both. The per-backend bullets in\n> Step 3 are **WordPress / WooCommerce / Ecommerce only** — for a webapp follow the Webapp bullet there.\n\n## Step 1 — Pick the framework (guess → default → confirm)\n\n**The rendering is already decided in `brief.md` → Rendering** (SSR or SSG, set during refine). Honour\nit, and the backend constraint:\n\n- **Ecommerce → SSR required** (carts/search need per-request rendering). Any SSR framework works —\n  Next.js is the default, not a requirement (Express, Nuxt, SvelteKit, etc. are all fine).\n- **WordPress + WooCommerce → SSR required** (same reason — cart/checkout need per-request rendering).\n- **WordPress → SSG (Astro)** when the brief says SSG, otherwise **SSR (Next.js default)**.\n- **Webapp → the app's own stack.** An **existing app** keeps its current framework (don't impose one); a\n  **new app** uses whatever fits the brief (SSR or SPA). Either way it deploys as a Node.js app (Step 8) —\n  an SSR app runs a server, a SPA builds to static output.\n- Map rendering → framework: **`ssr` → Next.js**, **`ssg` → Astro** — unless the brief/prompt explicitly\n  names another supported framework, in which case use that.\n\nSupported frameworks (what the Hostinger build pipeline can deploy — the `app_type` in Step 8 deploy):\n\n- **Server/SSR-capable:** Next.js, Nuxt.js, Astro, SvelteKit, Express, NestJS, Fastify.\n- **Static / SPA:** React, Vue, Angular, Vite, Parcel, Preact, Svelte, (Astro / SvelteKit static too).\n\nConfirm the framework with the user in one line only if the brief left it open. Record the choice in\n`state.json`:\n\n```json\n{ \"frontend\": { \"framework\": \"nextjs\", \"rendering\": \"ssr\" } }\n```\n\nIf the brief is silent, default to **Next.js SSR**. Ecommerce must be SSR (never SSG) — but the SSR\nframework itself is free to be any supported one, not just Next.js.\n\n## Step 2 — Implement `design.md` (don't re-design)\n\nThe look was already chosen and written by the design step. **Read `~/.hostinger/<domain>/design.md` and\nimplement it faithfully** — tokens (colour, type, spacing), components, per-page composition, imagery and\naccessibility — plus the logo files in `brand/`. Don't re-run design questions or invent a new direction here.\n\n- Treat `design.md` as the contract: the built pages should match its tokens, type scale, components and\n  per-page composition, and the 8-point grid / WCAG 2.2 AA rules it carries.\n- Use the **logo** from `brand/` as-is (wordmark, icon mark, favicon); never recolour or redraw it.\n- If `design.md` is **missing** (e.g. a resumed older build), fall back to `brief.md → Design direction`\n  (reference site, colours, brand, adjectives) and a tasteful, accessible default — but prefer `design.md`\n  whenever it exists.\n- **Don't gate on approval here** — the result is shown at **validate** (Step 7).\n\n**Only ask about the code, and only if it matters** (design decisions belong in the design step):\n- Where the **source should live** — default `~/.hostinger/<domain>/src/`; ask only if they want a\n  specific folder or an existing repo.\n- **Git** — initialise / connect / push (default: a local project, no remote).\n- A specific **component library** or technical must-have, if they implied one.\n\n## Step 3 — Build against the backend\n\nTwo phases around the instance barrier (see the top-level `SKILL.md`): scaffold + build the shell while\nprovision settles, then wire live data once `provision.status == \"completed\"`.\n\nRead the backend from `site.json`:\n\n- **WordPress** → `urls.rest_api` (`wp/v2`), public read. Content is in the posts/pages/categories/media\n  the content-model push created; nav/plan come from `content-model.md`. Map each item's **SEO** from its\n  `yoast_head_json` into the page `<head>` (title, description, Open Graph, JSON-LD schema) — Yoast is\n  installed by default at provision (`site.json → seo.enabled: true`). If `seo.enabled` is `false`\n  (Yoast absent), fall back to generating per-page title/description/OG tags from each item's content.\n  - **Contact form** (`site.json → contact_form.enabled: true`, any WordPress backend) → render the\n    contact page's form and submit it **client-side** to Contact Form 7's public feedback endpoint. Put a\n    `submitContactForm(data)` helper in the one data module: build a `FormData` with the field names from\n    `contact_form.fields` (e.g. `your-name`, `your-email`, `your-subject`, `your-message`) **plus CF7's\n    hidden fields** — `_wpcf7` = `contact_form.form_id`, `_wpcf7_version`, `_wpcf7_locale` (e.g. `en_US`),\n    `_wpcf7_unit_tag` (any stable string), `_wpcf7_container_post` = `0` — and `POST` it to\n    `contact_form.feedback_url` **without setting `Content-Type`** (let the browser add the multipart\n    boundary). `/cms` is same-origin, so no CORS and no secret. Branch on the JSON `status`: `mail_sent`\n    → success state; `validation_failed` → map `invalid_fields[].field` to per-input errors;\n    `spam`/`aborted`/`mail_failed` → a generic \"couldn't send, try again\" message. Include the honeypot\n    decoy field named in `contact_form.honeypot_field` (e.g. `your_website`), rendered hidden/off-screen,\n    **empty**, `autocomplete=\"off\"`, `tabindex=\"-1\"` — the deployed spam guard rejects it if filled. A user\n    validation error is a **normal UI state, not a build error**. When `contact_form.enabled` is `false` or absent, render the contact page with\n    plain contact details and **no form** — graceful, like disabled checkout; never half-build. Full\n    contract: `../04-content-model/wordpress/contact-form.md` §3.\n- **WordPress + WooCommerce** (`site.json → woocommerce.enabled: true`) → the WordPress bullet above **plus**\n  the store. Read the catalog over the **public WooCommerce Store API** (`site.json → urls.store_api`,\n  `/cms/wp-json/wc/store/v1`, no auth, open CORS): `GET /products` (prices are **integer minor units** on\n  `prices.price` with `prices.currency_minor_unit` — divide to display), `GET /products/categories`. Cart,\n  coupons and checkout are **client-side** against the Store API with the `Nonce` + `Cart-Token` headers\n  (`GET /cart`, `POST /cart/add-item`, `/cart/apply-coupon`, `POST /checkout`) — see\n  `../04-content-model/wordpress/woocommerce.md`. **Never embed a consumer key client-side**; the\n  storefront is fully public. Blog/pages on the same site still come from `urls.rest_api` (`wp/v2`) + Yoast.\n  - **Honour `site.json → woocommerce.payment_enabled`.** It is `false` until the owner enables a payment\n    gateway + shipping in wp-admin (that config isn't reachable headlessly — see the provision note). While\n    `false`, build the full catalog, product pages and the client-side cart as normal, but render a\n    graceful disabled-checkout state (e.g. a disabled \"Checkout\" with \"Checkout isn't set up yet\"), **don't\n    call `/checkout`**, and don't treat it as a build error. When `true`, wire checkout (`payment_method`\n    `\"cod\"` works out of the box).\n- **Ecommerce** → the **public Hostinger Storefront Core V2 API** (`https://api-ecommerce.hostinger.com/v2`,\n  no auth, open CORS), keyed on the **custom sales channel** (`site.json → ecommerce.sales_channel.id`):\n  `GET /channels/<scha_*>/products` (prices are **minor units** on variants), `POST /channels/<scha_*>/checkout`\n  for buying. Cart is client-side; never embed a token. Read\n  `ecommerce_miscellaneous_custom-storefront-setup-instructions` for the authoritative, current guide.\n  - **Honour `site.json → ecommerce.payment_enabled`.** When it is `false` (free account / no paid\n    Ecommerce plan — see the provision gate), there is **no checkout**: build the full catalog, product\n    pages and the client-side cart as normal, but **do not call the checkout endpoint**. Instead render\n    a clear, graceful state at the checkout step — e.g. a disabled \"Checkout\" button with a short note\n    like \"Online checkout isn't available on this plan yet\" (and/or a contact/enquiry fallback). A\n    missing checkout is **not** a build error here — never leave the storefront half-built, throw, or\n    retry checkout because payment is off. When `payment_enabled` is `true`, wire checkout normally.\n- **Webapp** → **no `content-model.md` and no headless backend to read**. The app uses its own data source:\n  the MySQL database from `site.json → database` (through the `DB_*` / `DATABASE_URL` env vars — set at\n  provision/deploy, see `../03-provision/webapp/SKILL.md` Step 3; `127.0.0.1` only resolves on the server,\n  not locally), or whatever external API the app calls. For an existing app, keep its data layer as-is.\n\nGuidelines (framework-agnostic):\n\n- **One data module** is the single place that talks to the backend (e.g. `src/lib/data.ts`) — one file\n  to inspect, one base URL to switch. Keep it swappable so the shell can build against stubs first.\n- **Fetch at request time for SSR** (fresh content, no rebuild); a static build fetches at build time.\n- **A failed or incomplete fetch is an error, not a silent empty/placeholder.** Planned content missing\n  from the API is a build error too — a site that builds with holes ships with holes. *(WordPress/Ecommerce;\n  a webapp has no planned content to check.)*\n- **`content-model.md` is the source for what should exist** (pages, nav, collections mapping) — for\n  WordPress/Ecommerce only; a **webapp has no `content-model.md`**.\n- **No `.htaccess`** in the project (deploy would overwrite the live one); don't commit `node_modules`\n  or build output.\n- Set `engines.node` to `22` (the deploy builds on Node 22).\n\n## Step 4 — Hand off\n\nConfirm the project builds clean locally against the live backend, no placeholder/fixture content\nremains, and `state.json → frontend` matches what you built. Update `state.json` (`stage: \"validate\"`).\nValidate (Step 7) owns the clean rebuild + user preview; deploy (Step 8) ships it with the `app_type`\nand output directory that match the chosen framework + rendering.\n\n> **Webapp:** just confirm the app builds clean and `state.json → frontend` is right — there's no\n> `content-model.md` or headless backend to check. A DB-backed app can't reach its database locally\n> (`127.0.0.1` is server-only), so its data layer is verified **after** deploy, not here.\n"
+        "text": "---\nname: headless-step-frontend\ndescription: \"Step 6 (frontend) of the Hostinger Headless flow. Builds the website that renders the backend's content. Figures out (or confirms) the framework — defaulting to Next.js SSR — implements the look already chosen in design.md (the design step's contract), and builds the source into src/. Only ask for the clarifications you actually need.\"\n---\n\n# headless-step-frontend\n\nBuild the site's frontend against the backend from `site.json`, implementing the look the design step\nalready chose and wrote to **`design.md`** (plus the logo in `brand/`). The design is decided; this step\nis where it becomes real code. There's no per-framework recipe — use good judgement, follow `design.md`\nas the contract, and ask only for the clarifications you genuinely need. **Out:** source in the site\nworkspace `~/.hostinger/<domain>/src/`.\n\n> ## ⚠️ Build mode: \"Bring your own frontend\"? Read this first (any backend)\n> Read `brief.md` → **Build mode**. When it is **Bring your own frontend**, the user already has a\n> frontend (the project in the folder the command was run in) and this step **wires it to the backend\n> from `site.json` — it does not scaffold a new project and there is usually no `design.md` to\n> implement** (the design step deferred to the user). **Use their project as the source**: copy or\n> point `~/.hostinger/<domain>/src/` at it, keep its framework and UI, and collaborate on changes at\n> the user's direction (vibe-code with them). Your job is to connect it to the live backend (WordPress\n> `wp/v2` reads, the WooCommerce/Ecommerce Store API, env/keys) and make it deployable (set\n> `engines.node` to `22`, remove any `.htaccess`), then hand off to deploy. This generalises the Webapp\n> \"existing app\" case below to WordPress and Ecommerce too. When **Build mode is \"Agent designs and\n> builds\"**, ignore this box and proceed normally (scaffold + implement `design.md`).\n\n> ## ⚠️ Webapp backend? Read this first\n> A `webapp` brief has **no CMS/store and no `content-model.md`** — the app owns its own data (its own\n> API, or the MySQL database recorded in `site.json → database`). It comes in two shapes, decided back in\n> **refine**:\n>\n> - **An existing app the user brought to deploy** (refine routes \"deploy my app\" here). **Use their\n>   project as the source** — copy/point `~/.hostinger/<domain>/src/` at it and keep its own framework and\n>   UI. **Do not scaffold a new project, and do not re-implement `design.md` over it** (so **the design\n>   step does not apply** to an app that brings its own UI). Your job is only to make it deployable: set\n>   `engines.node` to `22`, remove any `.htaccess`, wire its data/env, then hand off to deploy. **Skip the\n>   Step 2 design pass**, and ignore the `content-model.md` requirement in Step 3.\n> - **A new app built from the brief.** Scaffold and build it from `brief.md` (and `design.md` if the\n>   design step produced one — design *does* run for a from-scratch app). Its data is owned by the app, so\n>   there is still **no `content-model.md`** to bind against.\n>\n> Framework choice (Step 1), the build, and hand-off (Step 4) apply to both. The per-backend bullets in\n> Step 3 are **WordPress / WooCommerce / Ecommerce only** — for a webapp follow the Webapp bullet there.\n\n## Step 1 — Pick the framework (guess → default → confirm)\n\n**The rendering is already decided in `brief.md` → Rendering** (SSR or SSG, set during refine). Honour\nit, and the backend constraint:\n\n- **Ecommerce → SSR required** (carts/search need per-request rendering). Any SSR framework works —\n  Next.js is the default, not a requirement (Express, Nuxt, SvelteKit, etc. are all fine).\n- **WordPress + WooCommerce → SSR required** (same reason — cart/checkout need per-request rendering).\n- **WordPress → SSG (Astro)** when the brief says SSG, otherwise **SSR (Next.js default)**.\n- **Webapp → the app's own stack.** An **existing app** keeps its current framework (don't impose one); a\n  **new app** uses whatever fits the brief (SSR or SPA). Either way it deploys as a Node.js app (Step 8) —\n  an SSR app runs a server, a SPA builds to static output.\n- Map rendering → framework: **`ssr` → Next.js**, **`ssg` → Astro** — unless the brief/prompt explicitly\n  names another supported framework, in which case use that.\n\nSupported frameworks (what the Hostinger build pipeline can deploy — the `app_type` in Step 8 deploy):\n\n- **Server/SSR-capable:** Next.js, Nuxt.js, Astro, SvelteKit, Express, NestJS, Fastify.\n- **Static / SPA:** React, Vue, Angular, Vite, Parcel, Preact, Svelte, (Astro / SvelteKit static too).\n\nConfirm the framework with the user in one line only if the brief left it open. Record the choice in\n`state.json`:\n\n```json\n{ \"frontend\": { \"framework\": \"nextjs\", \"rendering\": \"ssr\" } }\n```\n\nIf the brief is silent, default to **Next.js SSR**. Ecommerce must be SSR (never SSG) — but the SSR\nframework itself is free to be any supported one, not just Next.js.\n\n## Step 2 — Implement `design.md` (don't re-design)\n\nThe look was already chosen and written by the design step. **Read `~/.hostinger/<domain>/design.md` and\nimplement it faithfully** — tokens (colour, type, spacing), components, per-page composition, imagery and\naccessibility — plus the logo files in `brand/`. Don't re-run design questions or invent a new direction here.\n\n- Treat `design.md` as the contract: the built pages should match its tokens, type scale, components and\n  per-page composition, and the 8-point grid / WCAG 2.2 AA rules it carries.\n- Use the **logo** from `brand/` as-is (wordmark, icon mark, favicon); never recolour or redraw it.\n- If `design.md` is **missing** (e.g. a resumed older build), fall back to `brief.md → Design direction`\n  (reference site, colours, brand, adjectives) and a tasteful, accessible default — but prefer `design.md`\n  whenever it exists.\n- **Don't gate on approval here** — the result is shown at **validate** (Step 7).\n\n**Only ask about the code, and only if it matters** (design decisions belong in the design step):\n- Where the **source should live** — default `~/.hostinger/<domain>/src/`; ask only if they want a\n  specific folder or an existing repo.\n- **Git** — initialise / connect / push (default: a local project, no remote).\n- A specific **component library** or technical must-have, if they implied one.\n\n## Step 3 — Build against the backend\n\nTwo phases around the instance barrier (see the top-level `SKILL.md`): scaffold + build the shell while\nprovision settles, then wire live data once `provision.status == \"completed\"`.\n\nRead the backend from `site.json`:\n\n- **WordPress** → `urls.rest_api` (`wp/v2`), public read. Content is in the posts/pages/categories/media\n  the content-model push created; nav/plan come from `content-model.md`. Map each item's **SEO** from its\n  `yoast_head_json` into the page `<head>` (title, description, Open Graph, JSON-LD schema) — Yoast is\n  installed by default at provision (`site.json → seo.enabled: true`). If `seo.enabled` is `false`\n  (Yoast absent), fall back to generating per-page title/description/OG tags from each item's content.\n  - **Contact form** (`site.json → contact_form.enabled: true`, any WordPress backend) → render the\n    contact page's form and submit it **client-side** to Contact Form 7's public feedback endpoint. Put a\n    `submitContactForm(data)` helper in the one data module: build a `FormData` with the field names from\n    `contact_form.fields` (e.g. `your-name`, `your-email`, `your-subject`, `your-message`) **plus CF7's\n    hidden fields** — `_wpcf7` = `contact_form.form_id`, `_wpcf7_version`, `_wpcf7_locale` (e.g. `en_US`),\n    `_wpcf7_unit_tag` (any stable string), `_wpcf7_container_post` = `0` — and `POST` it to\n    `contact_form.feedback_url` **without setting `Content-Type`** (let the browser add the multipart\n    boundary). `/cms` is same-origin, so no CORS and no secret. Branch on the JSON `status`: `mail_sent`\n    → success state; `validation_failed` → map `invalid_fields[].field` to per-input errors;\n    `spam`/`aborted`/`mail_failed` → a generic \"couldn't send, try again\" message. Include the honeypot\n    decoy field named in `contact_form.honeypot_field` (e.g. `your_website`), rendered hidden/off-screen,\n    **empty**, `autocomplete=\"off\"`, `tabindex=\"-1\"` — the deployed spam guard rejects it if filled. A user\n    validation error is a **normal UI state, not a build error**. When `contact_form.enabled` is `false` or absent, render the contact page with\n    plain contact details and **no form** — graceful, like disabled checkout; never half-build. Full\n    contract: `../04-content-model/wordpress/contact-form.md` §3.\n- **WordPress + WooCommerce** (`site.json → woocommerce.enabled: true`) → the WordPress bullet above **plus**\n  the store. Read the catalog over the **public WooCommerce Store API** (`site.json → urls.store_api`,\n  `/cms/wp-json/wc/store/v1`, no auth, open CORS): `GET /products` (prices are **integer minor units** on\n  `prices.price` with `prices.currency_minor_unit` — divide to display), `GET /products/categories`. Cart,\n  coupons and checkout are **client-side** against the Store API with the `Nonce` + `Cart-Token` headers\n  (`GET /cart`, `POST /cart/add-item`, `/cart/apply-coupon`, `POST /checkout`) — see\n  `../04-content-model/wordpress/woocommerce.md`. **Never embed a consumer key client-side**; the\n  storefront is fully public. Blog/pages on the same site still come from `urls.rest_api` (`wp/v2`) + Yoast.\n  - **Honour `site.json → woocommerce.payment_enabled`.** It is `false` until the owner enables a payment\n    gateway + shipping in wp-admin (that config isn't reachable headlessly — see the provision note). While\n    `false`, build the full catalog, product pages and the client-side cart as normal, but render a\n    graceful disabled-checkout state (e.g. a disabled \"Checkout\" with \"Checkout isn't set up yet\"), **don't\n    call `/checkout`**, and don't treat it as a build error. When `true`, wire checkout (`payment_method`\n    `\"cod\"` works out of the box).\n- **Ecommerce** → the **public Hostinger Storefront Core V2 API** (`https://api-ecommerce.hostinger.com/v2`,\n  no auth, open CORS), keyed on the **custom sales channel** (`site.json → ecommerce.sales_channel.id`):\n  `GET /channels/<scha_*>/products` (prices are **minor units** on variants), `POST /channels/<scha_*>/checkout`\n  for buying. Cart is client-side; never embed a token. Read\n  `ecommerce_miscellaneous_custom-storefront-setup-instructions` for the authoritative, current guide.\n  - **Honour `site.json → ecommerce.payment_enabled`.** When it is `false` (free account / no paid\n    Ecommerce plan — see the provision gate), there is **no checkout**: build the full catalog, product\n    pages and the client-side cart as normal, but **do not call the checkout endpoint**. Instead render\n    a clear, graceful state at the checkout step — e.g. a disabled \"Checkout\" button with a short note\n    like \"Online checkout isn't available on this plan yet\" (and/or a contact/enquiry fallback). A\n    missing checkout is **not** a build error here — never leave the storefront half-built, throw, or\n    retry checkout because payment is off. When `payment_enabled` is `true`, wire checkout normally.\n- **Webapp** → **no `content-model.md` and no headless backend to read**. The app uses its own data source:\n  the MySQL database from `site.json → database` (through the `DB_*` / `DATABASE_URL` env vars — set at\n  provision/deploy, see `../03-provision/webapp/SKILL.md` Step 3; `127.0.0.1` only resolves on the server,\n  not locally), or whatever external API the app calls. For an existing app, keep its data layer as-is.\n\nGuidelines (framework-agnostic):\n\n- **One data module** is the single place that talks to the backend (e.g. `src/lib/data.ts`) — one file\n  to inspect, one base URL to switch. Keep it swappable so the shell can build against stubs first.\n- **Fetch at request time for SSR** (fresh content, no rebuild); a static build fetches at build time.\n- **A failed or incomplete fetch is an error, not a silent empty/placeholder.** Planned content missing\n  from the API is a build error too — a site that builds with holes ships with holes. *(WordPress/Ecommerce;\n  a webapp has no planned content to check.)*\n- **`content-model.md` is the source for what should exist** (pages, nav, collections mapping) — for\n  WordPress/Ecommerce only; a **webapp has no `content-model.md`**.\n- **No `.htaccess`** in the project (deploy would overwrite the live one); don't commit `node_modules`\n  or build output.\n- Set `engines.node` to `22` (the deploy builds on Node 22).\n- **Next.js 16+ only:** set the `build` script to `next build --webpack`, not plain `next build`. Next.js\n  16 defaults `next build` to **Turbopack**, whose native compiler needs a newer glibc than the Hostinger\n  build server has, so a Turbopack build fails on deploy and won't fall back to webpack. Webpack builds\n  clean there. The `--webpack` flag exists only on Next.js 16+; on **Next.js 15.x** leave the build script\n  as plain `next build` (it already defaults to webpack). (Alternative: pin Next.js to `15.x`, keeping\n  plain `next build`.)\n\n## Step 4 — Hand off\n\nConfirm the project builds clean locally against the live backend, no placeholder/fixture content\nremains, and `state.json → frontend` matches what you built. Update `state.json` (`stage: \"validate\"`).\nValidate (Step 7) owns the clean rebuild + user preview; deploy (Step 8) ships it with the `app_type`\nand output directory that match the chosen framework + rendering.\n\n> **Webapp:** just confirm the app builds clean and `state.json → frontend` is right — there's no\n> `content-model.md` or headless backend to check. A DB-backed app can't reach its database locally\n> (`127.0.0.1` is server-only), so its data layer is verified **after** deploy, not here.\n"
       },
       {
         "uri": "skill://hostinger-headless/steps/07-validate/SKILL.md",
@@ -260,10 +260,10 @@ const skills: Skill[] = [
       },
       {
         "uri": "skill://hostinger-headless/steps/08-deploy/SKILL.md",
-        "digest": "sha256:a45c01ae27975a636fa200c386e8a56397dff4847ba62f72e11fd69990d82ea2",
-        "size": 10613,
+        "digest": "sha256:c6f2ef2d62ae4ba0ab7686148e1898585c8c93bcb22e91c2bcf25b80f7bd987d",
+        "size": 12010,
         "mimeType": "text/markdown",
-        "text": "---\nname: headless-step-deploy\ndescription: \"Step 8 (deploy) of the Hostinger Headless flow. Archives the frontend source, then deploys through the connector's one-shot hosting_deploy (type nodejs — it uploads the source, runs npm install and the build on the server) with the chosen framework's build settings (appType + output dir) passed explicitly, polls to completion with hosting_get-deployment, verifies the live site and that the backend survived, then writes deploy.json.\"\n---\n\n# headless-step-deploy\n\nShip the frontend to the live domain through the Hostinger connector. You hand the connector a zip of\nthe project **source** and it uploads it, runs `npm install` + the build script on the server, and\nserves the result. **Out:** `deploy.json`.\n\nThis is an **instance-barrier** step: run it only after `provision.status == \"completed\"` and validate\n(if run) has passed. All operations go through the connector (`execute`).\n\n**In:** the project in `~/.hostinger/<domain>/src/`, `site.json` (`username`, `urls`), `state.json`\n(`frontend.framework`, `frontend.rendering`).\n\n> ## ⚠️ The one rule that makes this work: pass build settings explicitly\n> If you let `hosting_deploy` **auto-detect** build settings, for a headless site that detection returns\n> **null** (`appType:null`, `outputDirectory:null`, Node 20) — the build \"completes\" but the **root\n> serves 403** (no `appType`/output → the vhost serves a directory with no entry). This is reproducible.\n> **Always pass `appType`, `outputDirectory`, `nodeVersion`, `buildScript`, `packageManager` and\n> `rootDirectory` on the `hosting_deploy` call** with the framework's values; the deploy then resolves\n> them and serves correctly, and `/cms` is preserved.\n\n## Build configurations\n\nMap `frontend.framework` (from `state.json`) to its `appType` + build output directory, and pass those\non the `hosting_deploy` call. `appType` is the framework's value, e.g. `next`, `nuxt`, `astro`,\n`svelte-kit`, `nest`, `express`, `fastify`, `react`, `create-react-app`, `gatsby`, `vite`, `vue`,\n`angular`, `parcel`, `svelte`, `other`.\n\nCommon cases (all `nodeVersion: 22`, `buildScript: \"build\"`, `packageManager: \"npm\"`, `rootDirectory: \".\"`):\n\n| Framework / mode | Local config | `appType` | `outputDirectory` |\n|---|---|---|---|\n| **Next.js — SSR** *(default)* | `output: 'standalone'` | `next` | `.next` |\n| **Nuxt — SSR** | default | `nuxt` | `.output` |\n| **SvelteKit — SSR** | node adapter | `svelte-kit` | `build` |\n| **Astro — static** | `output: 'static'` | `astro` | `dist` |\n| **Vite / React / Vue — static (SPA)** | — | `vite` (or `react`/`vue`) | `dist` |\n| **Express / NestJS / Fastify — server** | — | `express`/`nest`/`fastify` | build output dir |\n\nSSR/server frameworks run a persistent Node process (root sends `x-powered-by` / `cache-control: no-store`);\nstatic frameworks serve their output dir as files. If unsure of a framework's output dir, check the\nframework's own build output, but **always pass `appType`/`outputDirectory` on the deploy call with the\nframework's correct values** — don't rely on auto-detection (it returns null → 403).\n\n## Step 1 — Pre-flight\n\n1. **Instance live.** `provision.status == \"completed\"`, re-verified with\n   `hosting_websites_list-setups { \"domain\": \"<domain>\" }`.\n2. **Build output exists locally** (the framework's output dir — e.g. `.next/`, `dist/`, `.output/`) and\n   the project builds clean (frontend/validate already did this). If not, go back.\n3. **Env vars (only if used).** Build-time vars (e.g. `NEXT_PUBLIC_*`) must be set **before** the build\n   with `hosting_nodejs_replace-environment-variables` (full replace). Never put secrets in the repo or\n   the archive. **Webapp with a database:** that full replace wipes the `DB_*`/`DATABASE_URL` that\n   `hosting_databases_setup-website` injected (the generated password reads back masked), so set all app\n   vars in the same replace and, if you can't, first reset the password with\n   `hosting_databases_change-password` and resend every `DB_*`/`DATABASE_URL` — see\n   `../03-provision/webapp/SKILL.md` Step 3.\n\n## Step 2 — Archive the source\n\nZip the project **source** with `package.json` at the archive root. **Include** the app/source,\n`public/`, the framework config (`next.config.mjs` / `astro.config.mjs`), `tsconfig.json`,\n`package.json`, `package-lock.json`, `.nvmrc`. **Exclude** `node_modules/`, the build output\n(`.next/`, `dist/`, `out/`), `.git/`, and any `.htaccess` — the server installs and builds from source.\n\n```bash\ncd ~/.hostinger/<domain>/src\nzip -r -X ../app.zip . -x 'node_modules/*' '.next/*' 'dist/*' 'out/*' '.git/*' '**/.htaccess'\n```\n\n## Step 3 — Deploy (one shot: settings + upload + build)\n\nPass the framework's build settings **inline** on the deploy call — there is no separate settings step.\n`path` is the archive from Step 2 (or the source directory itself; `hosting_deploy` archives a directory\nfor you, skipping `node_modules/`, `.git/` and `.env`, but it does **not** read `.gitignore`, so the\nbuild output must already be absent).\n\n```json\n{ \"operation\": \"hosting_deploy\",\n  \"params\": {\n    \"domain\": \"<domain>\",\n    \"path\": \"/absolute/path/to/.hostinger/<domain>/app.zip\",\n    \"type\": \"nodejs\",\n    \"appType\": \"<framework appType, e.g. next>\",\n    \"outputDirectory\": \"<framework output dir, e.g. .next>\",\n    \"nodeVersion\": 22,\n    \"buildScript\": \"build\",\n    \"packageManager\": \"npm\",\n    \"rootDirectory\": \".\" } }\n```\n\n`hosting_deploy` uploads the source and triggers `npm install` + the build **end-to-end** — do not call\nany upload or build operation yourself. It returns a build `buildUuid` at once. This **overwrites the\nwebsite root** (expected) and keeps `/cms` intact. Passing `appType`/`outputDirectory` explicitly is what\nkeeps the root from serving 403 (see the rule above).\n\n## Step 4 — Poll to completion\n\nPoll `hosting_get-deployment { \"domain\": \"<domain>\", \"buildUuid\": \"<buildUuid>\" }` with backoff until\n`build.state` is `completed`. On `failed`, the same response carries the end of the build log and the\nfailure analysis — read it, fix locally, re-archive and redeploy (pass `fromLine`, the line count from\nthe previous call, to read only new log output). `hosting_get-deployment` also returns the build settings\nstored for the site: `appType`/`outputDirectory`/`nodeVersion` should echo what you passed; if they read\n`null`, the settings didn't take — fix the deploy call before continuing. For an SSR app that built but\nhangs, `hosting_nodejs_restart-application { username, domain }` recovers the server without a rebuild.\n\n## Step 5 — Verify the live site (all must pass)\n\n| Check | How | Expect |\n|---|---|---|\n| Root serves | `GET https://<domain>/` | **200** (not 403 / 404) |\n| SSR is live *(server frameworks)* | response headers | `x-powered-by` present, `cache-control: no-store` |\n| Static serves *(static frameworks)* | `GET https://<domain>/` | 200 HTML with real home content |\n| Key routes | a couple of planned routes + one deep route | 200, real content |\n| **Backend survived** *(WordPress / WooCommerce)* | `GET https://<domain>/cms/wp-json/wp/v2/posts?per_page=1` | 200 |\n\n> **Only WordPress (including WordPress + WooCommerce) has a `/cms` on the domain**, so the *Backend\n> survived* check is WordPress-only.\n> - **WordPress + WooCommerce:** also confirm the store survived the deploy —\n>   `GET https://<domain>/cms/wp-json/wc/store/v1/products?per_page=1` → 200. There is nothing external to\n>   link (no sales-channel step — that's Ecommerce only). **Checkout** stays owner-completed: when\n>   `site.json → woocommerce.payment_enabled` is `false`, don't test `/checkout`; a catalog that serves 200\n>   is a passing, complete deploy.\n> - **Ecommerce:** the backend is the **Hostinger Ecommerce store**, read over the external Storefront API\n>   (`api-ecommerce.hostinger.com`) — nothing a deploy touches lives on this domain. There is no `/cms`;\n>   confirm the storefront still fetches products as a frontend check if you like. **Only check that\n>   checkout can be reached when `site.json → ecommerce.payment_enabled` is `true`** — on a free account\n>   (`payment_enabled: false`) there is no checkout, so **skip that check entirely**; a catalog that serves\n>   200 is a passing, complete deploy. Never fail or hold the deploy because checkout is unavailable.\n> - **Webapp:** no content backend at all — the whole root is the app. Skip the check; `/cms` won't resolve.\n\nA `completed` build whose root 403s almost always means the build settings weren't passed to\n`hosting_deploy` (null settings) — pass them and redeploy. Caching can briefly serve a stale root;\nre-check after ~30 s.\n\n## Step 6 — Record `deploy.json`\n\n```json\n{\n  \"build_uuid\": \"…\",\n  \"stack\": \"nextjs\",\n  \"rendering\": \"ssr\",\n  \"app_type\": \"next\",\n  \"output_directory\": \".next\",\n  \"node_version\": 22,\n  \"method\": \"hosting_deploy (type: nodejs, settings passed inline)\",\n  \"deployed_at\": \"…\",\n  \"verified_at\": \"…\",\n  \"urls\": { \"live\": \"https://<domain>\", \"cms\": \"https://<domain>/cms\" },\n  \"checks\": { \"root\": 200, \"ssr_headers\": true, \"backend_preserved\": true }\n}\n```\n\nNo secrets in `deploy.json`. The `urls.cms` field and the `backend_preserved` check above are\n**WordPress-only** — adjust the record to the backend:\n\n- **WordPress:** keep `urls.cms` and `checks.backend_preserved` as shown.\n- **WordPress + WooCommerce:** keep `urls.cms` + `checks.backend_preserved` (it *is* WordPress), and add\n  `urls.store_api` from `site.json`; no external link step.\n- **Ecommerce:** omit `urls.cms`/`backend_preserved`; record the store URLs instead (`urls.storefront_api`,\n  `urls.store_admin` from `site.json`) and link the custom sales channel to the live domain —\n  `ecommerce_sales-channels_update { store_id, sales_channel_id, url }` (see the ecommerce provision step).\n- **Webapp:** omit `urls.cms` and `backend_preserved` entirely — `urls` is just `{ \"live\": \"https://<domain>\" }`.\n\nUpdate `state.json` (`stage` → `done`), then continue to Step 9 (done).\n\n---\n\n## Note — one deploy path, and never `type: \"static\"`\n\n`hosting_deploy` is the only path: give its `path` either the source **directory** (it archives it for\nyou) or a local **archive** (`zip`, `tar`, `tar.gz`, `tgz`, `7z`) — there is no separate upload or build\nstep to fall back to. Either way pass the explicit `appType`/`outputDirectory`/`nodeVersion`/\n`buildScript`/`packageManager`/`rootDirectory` from the table. Never deploy a headless site with\n`type: \"static\"` — it serves the directory as plain files and can overwrite `/cms`.\n"
+        "text": "---\nname: headless-step-deploy\ndescription: \"Step 8 (deploy) of the Hostinger Headless flow. Archives the frontend source, then deploys through the connector's one-shot hosting_deploy (type nodejs — it uploads the source, runs npm install and the build on the server) with the chosen framework's build settings (appType + output dir) passed explicitly, polls to completion with hosting_get-deployment, verifies the live site and that the backend survived, then writes deploy.json.\"\n---\n\n# headless-step-deploy\n\nShip the frontend to the live domain through the Hostinger connector. You hand the connector a zip of\nthe project **source** and it uploads it, runs `npm install` + the build script on the server, and\nserves the result. **Out:** `deploy.json`.\n\nThis is an **instance-barrier** step: run it only after `provision.status == \"completed\"` and validate\n(if run) has passed. All operations go through the connector (`execute`).\n\n**In:** the project in `~/.hostinger/<domain>/src/`, `site.json` (`username`, `urls`), `state.json`\n(`frontend.framework`, `frontend.rendering`).\n\n> ## ⚠️ The one rule that makes this work: pass build settings explicitly\n> If you let `hosting_deploy` **auto-detect** build settings, for a headless site that detection returns\n> **null** (`appType:null`, `outputDirectory:null`, Node 20) — the build \"completes\" but the **root\n> serves 403** (no `appType`/output → the vhost serves a directory with no entry). This is reproducible.\n> **Always pass `appType`, `outputDirectory`, `nodeVersion`, `buildScript`, `packageManager` and\n> `rootDirectory` on the `hosting_deploy` call** with the framework's values; the deploy then resolves\n> them and serves correctly, and `/cms` is preserved.\n\n## Build configurations\n\nMap `frontend.framework` (from `state.json`) to its `appType` + build output directory, and pass those\non the `hosting_deploy` call. `appType` is the framework's value, e.g. `next`, `nuxt`, `astro`,\n`svelte-kit`, `nest`, `express`, `fastify`, `react`, `create-react-app`, `gatsby`, `vite`, `vue`,\n`angular`, `parcel`, `svelte`, `other`.\n\nCommon cases (all `nodeVersion: 22`, `buildScript: \"build\"`, `packageManager: \"npm\"`, `rootDirectory: \".\"`):\n\n| Framework / mode | Local config | `appType` | `outputDirectory` |\n|---|---|---|---|\n| **Next.js — SSR** *(default)* | `output: 'standalone'` | `next` | `.next` |\n| **Nuxt — SSR** | default | `nuxt` | `.output` |\n| **SvelteKit — SSR** | node adapter | `svelte-kit` | `build` |\n| **Astro — static** | `output: 'static'` | `astro` | `dist` |\n| **Vite / React / Vue — static (SPA)** | — | `vite` (or `react`/`vue`) | `dist` |\n| **Express / NestJS / Fastify — server** | — | `express`/`nest`/`fastify` | build output dir |\n\nSSR/server frameworks run a persistent Node process (root sends `x-powered-by` / `cache-control: no-store`);\nstatic frameworks serve their output dir as files. If unsure of a framework's output dir, check the\nframework's own build output, but **always pass `appType`/`outputDirectory` on the deploy call with the\nframework's correct values** — don't rely on auto-detection (it returns null → 403).\n\n> ## ⚠️ Next.js 16+: build with webpack, not Turbopack (recurring deploy failure)\n> Next.js 16 makes **Turbopack** the default bundler for `next build`. Turbopack's native (Rust)\n> compiler needs a newer **glibc** than the Hostinger build server ships, so the server build aborts\n> with a \"glibc too old\" error — and Turbopack **does not fall back** to webpack on its own, so the\n> deploy fails every time. **Fix: build with webpack.** On **Next.js 16+** the project's `build` script\n> in `package.json` must be `next build --webpack` (not plain `next build`); `buildScript` on the deploy\n> call stays `\"build\"` — that's what runs it. The `--webpack` flag exists only on Next.js 16+; on\n> **Next.js 15.x** leave the build script as plain `next build` (it already defaults to webpack).\n> **Confirm this in `package.json` before deploying** (the frontend step scaffolds it this way — see\n> `../06-frontend`). Alternative, only if you must avoid the `--webpack` flag: pin Next.js to `15.x`\n> (keeping plain `next build`), whose `next build` still defaults to webpack. Next.js only — other\n> frameworks are unaffected.\n\n## Step 1 — Pre-flight\n\n1. **Instance live.** `provision.status == \"completed\"`, re-verified with\n   `hosting_websites_list-setups { \"domain\": \"<domain>\" }`.\n2. **Build output exists locally** (the framework's output dir — e.g. `.next/`, `dist/`, `.output/`) and\n   the project builds clean (frontend/validate already did this). If not, go back.\n   - **Next.js 16+:** `package.json`'s `build` script is `next build --webpack`, not plain `next build` —\n     the server's glibc can't run Turbopack's native compiler (see the box above). On Next.js 15.x leave it\n     as plain `next build`. Fix it here if it isn't.\n3. **Env vars (only if used).** Build-time vars (e.g. `NEXT_PUBLIC_*`) must be set **before** the build\n   with `hosting_nodejs_replace-environment-variables` (full replace). Never put secrets in the repo or\n   the archive. **Webapp with a database:** that full replace wipes the `DB_*`/`DATABASE_URL` that\n   `hosting_databases_setup-website` injected (the generated password reads back masked), so set all app\n   vars in the same replace and, if you can't, first reset the password with\n   `hosting_databases_change-password` and resend every `DB_*`/`DATABASE_URL` — see\n   `../03-provision/webapp/SKILL.md` Step 3.\n\n## Step 2 — Archive the source\n\nZip the project **source** with `package.json` at the archive root. **Include** the app/source,\n`public/`, the framework config (`next.config.mjs` / `astro.config.mjs`), `tsconfig.json`,\n`package.json`, `package-lock.json`, `.nvmrc`. **Exclude** `node_modules/`, the build output\n(`.next/`, `dist/`, `out/`), `.git/`, and any `.htaccess` — the server installs and builds from source.\n\n```bash\ncd ~/.hostinger/<domain>/src\nzip -r -X ../app.zip . -x 'node_modules/*' '.next/*' 'dist/*' 'out/*' '.git/*' '**/.htaccess'\n```\n\n## Step 3 — Deploy (one shot: settings + upload + build)\n\nPass the framework's build settings **inline** on the deploy call — there is no separate settings step.\n`path` is the archive from Step 2 (or the source directory itself; `hosting_deploy` archives a directory\nfor you, skipping `node_modules/`, `.git/` and `.env`, but it does **not** read `.gitignore`, so the\nbuild output must already be absent).\n\n```json\n{ \"operation\": \"hosting_deploy\",\n  \"params\": {\n    \"domain\": \"<domain>\",\n    \"path\": \"/absolute/path/to/.hostinger/<domain>/app.zip\",\n    \"type\": \"nodejs\",\n    \"appType\": \"<framework appType, e.g. next>\",\n    \"outputDirectory\": \"<framework output dir, e.g. .next>\",\n    \"nodeVersion\": 22,\n    \"buildScript\": \"build\",\n    \"packageManager\": \"npm\",\n    \"rootDirectory\": \".\" } }\n```\n\n`hosting_deploy` uploads the source and triggers `npm install` + the build **end-to-end** — do not call\nany upload or build operation yourself. It returns a build `buildUuid` at once. This **overwrites the\nwebsite root** (expected) and keeps `/cms` intact. Passing `appType`/`outputDirectory` explicitly is what\nkeeps the root from serving 403 (see the rule above).\n\n## Step 4 — Poll to completion\n\nPoll `hosting_get-deployment { \"domain\": \"<domain>\", \"buildUuid\": \"<buildUuid>\" }` with backoff until\n`build.state` is `completed`. On `failed`, the same response carries the end of the build log and the\nfailure analysis — read it, fix locally, re-archive and redeploy (pass `fromLine`, the line count from\nthe previous call, to read only new log output). `hosting_get-deployment` also returns the build settings\nstored for the site: `appType`/`outputDirectory`/`nodeVersion` should echo what you passed; if they read\n`null`, the settings didn't take — fix the deploy call before continuing. For an SSR app that built but\nhangs, `hosting_nodejs_restart-application { username, domain }` recovers the server without a rebuild.\n\n## Step 5 — Verify the live site (all must pass)\n\n| Check | How | Expect |\n|---|---|---|\n| Root serves | `GET https://<domain>/` | **200** (not 403 / 404) |\n| SSR is live *(server frameworks)* | response headers | `x-powered-by` present, `cache-control: no-store` |\n| Static serves *(static frameworks)* | `GET https://<domain>/` | 200 HTML with real home content |\n| Key routes | a couple of planned routes + one deep route | 200, real content |\n| **Backend survived** *(WordPress / WooCommerce)* | `GET https://<domain>/cms/wp-json/wp/v2/posts?per_page=1` | 200 |\n\n> **Only WordPress (including WordPress + WooCommerce) has a `/cms` on the domain**, so the *Backend\n> survived* check is WordPress-only.\n> - **WordPress + WooCommerce:** also confirm the store survived the deploy —\n>   `GET https://<domain>/cms/wp-json/wc/store/v1/products?per_page=1` → 200. There is nothing external to\n>   link (no sales-channel step — that's Ecommerce only). **Checkout** stays owner-completed: when\n>   `site.json → woocommerce.payment_enabled` is `false`, don't test `/checkout`; a catalog that serves 200\n>   is a passing, complete deploy.\n> - **Ecommerce:** the backend is the **Hostinger Ecommerce store**, read over the external Storefront API\n>   (`api-ecommerce.hostinger.com`) — nothing a deploy touches lives on this domain. There is no `/cms`;\n>   confirm the storefront still fetches products as a frontend check if you like. **Only check that\n>   checkout can be reached when `site.json → ecommerce.payment_enabled` is `true`** — on a free account\n>   (`payment_enabled: false`) there is no checkout, so **skip that check entirely**; a catalog that serves\n>   200 is a passing, complete deploy. Never fail or hold the deploy because checkout is unavailable.\n> - **Webapp:** no content backend at all — the whole root is the app. Skip the check; `/cms` won't resolve.\n\nA `completed` build whose root 403s almost always means the build settings weren't passed to\n`hosting_deploy` (null settings) — pass them and redeploy. Caching can briefly serve a stale root;\nre-check after ~30 s.\n\n## Step 6 — Record `deploy.json`\n\n```json\n{\n  \"build_uuid\": \"…\",\n  \"stack\": \"nextjs\",\n  \"rendering\": \"ssr\",\n  \"app_type\": \"next\",\n  \"output_directory\": \".next\",\n  \"node_version\": 22,\n  \"method\": \"hosting_deploy (type: nodejs, settings passed inline)\",\n  \"deployed_at\": \"…\",\n  \"verified_at\": \"…\",\n  \"urls\": { \"live\": \"https://<domain>\", \"cms\": \"https://<domain>/cms\" },\n  \"checks\": { \"root\": 200, \"ssr_headers\": true, \"backend_preserved\": true }\n}\n```\n\nNo secrets in `deploy.json`. The `urls.cms` field and the `backend_preserved` check above are\n**WordPress-only** — adjust the record to the backend:\n\n- **WordPress:** keep `urls.cms` and `checks.backend_preserved` as shown.\n- **WordPress + WooCommerce:** keep `urls.cms` + `checks.backend_preserved` (it *is* WordPress), and add\n  `urls.store_api` from `site.json`; no external link step.\n- **Ecommerce:** omit `urls.cms`/`backend_preserved`; record the store URLs instead (`urls.storefront_api`,\n  `urls.store_admin` from `site.json`) and link the custom sales channel to the live domain —\n  `ecommerce_sales-channels_update { store_id, sales_channel_id, url }` (see the ecommerce provision step).\n- **Webapp:** omit `urls.cms` and `backend_preserved` entirely — `urls` is just `{ \"live\": \"https://<domain>\" }`.\n\nUpdate `state.json` (`stage` → `done`), then continue to Step 9 (done).\n\n---\n\n## Note — one deploy path, and never `type: \"static\"`\n\n`hosting_deploy` is the only path: give its `path` either the source **directory** (it archives it for\nyou) or a local **archive** (`zip`, `tar`, `tar.gz`, `tgz`, `7z`) — there is no separate upload or build\nstep to fall back to. Either way pass the explicit `appType`/`outputDirectory`/`nodeVersion`/\n`buildScript`/`packageManager`/`rootDirectory` from the table. Never deploy a headless site with\n`type: \"static\"` — it serves the directory as plain files and can overwrite `/cms`.\n"
       },
       {
         "uri": "skill://hostinger-headless/steps/09-done/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.10.0', tools, instructions });
+startServer({ name: 'hostinger-agency-hosting-mcp', version: '3.10.1', 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.10.0', tools, instructions });
+startServer({ name: 'hostinger-agency-hosting-mcp', version: '3.10.1', 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.10.0', tools });
+startServer({ name: 'hostinger-agent-readiness-mcp', version: '3.10.1', 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.10.0', tools });
+startServer({ name: 'hostinger-agent-readiness-mcp', version: '3.10.1', 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.10.0', tools, instructions, skills });
+startServer({ name: 'hostinger-api-mcp', version: '3.10.1', 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.10.0', tools, instructions, skills });
+startServer({ name: 'hostinger-api-mcp', version: '3.10.1', 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.10.0', tools });
+startServer({ name: 'hostinger-billing-mcp', version: '3.10.1', 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.10.0', tools });
+startServer({ name: 'hostinger-billing-mcp', version: '3.10.1', 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.10.0', tools });
+startServer({ name: 'hostinger-dns-mcp', version: '3.10.1', 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.10.0', tools });
+startServer({ name: 'hostinger-dns-mcp', version: '3.10.1', 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.10.0', tools });
+startServer({ name: 'hostinger-domains-mcp', version: '3.10.1', 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.10.0', tools });
+startServer({ name: 'hostinger-domains-mcp', version: '3.10.1', 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.10.0', tools });
+startServer({ name: 'hostinger-ecommerce-mcp', version: '3.10.1', 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.10.0', tools });
+startServer({ name: 'hostinger-ecommerce-mcp', version: '3.10.1', 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.10.0', tools });
+startServer({ name: 'hostinger-horizons-mcp', version: '3.10.1', 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.10.0', tools });
+startServer({ name: 'hostinger-horizons-mcp', version: '3.10.1', 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.10.0', tools, instructions });
+startServer({ name: 'hostinger-hosting-mcp', version: '3.10.1', 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.10.0', tools, instructions });
+startServer({ name: 'hostinger-hosting-mcp', version: '3.10.1', 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.10.0', tools });
+startServer({ name: 'hostinger-mail-mcp', version: '3.10.1', 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.10.0', tools });
+startServer({ name: 'hostinger-mail-mcp', version: '3.10.1', 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.10.0', tools });
+startServer({ name: 'hostinger-reach-mcp', version: '3.10.1', 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.10.0', tools });
+startServer({ name: 'hostinger-reach-mcp', version: '3.10.1', 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.10.0', tools });
+startServer({ name: 'hostinger-vps-mcp', version: '3.10.1', 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.10.0', tools });
+startServer({ name: 'hostinger-vps-mcp', version: '3.10.1', 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.10.0', tools });
+startServer({ name: 'hostinger-wordpress-mcp', version: '3.10.1', 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.10.0', tools });
+startServer({ name: 'hostinger-wordpress-mcp', version: '3.10.1', tools });