@hostinger/mcp 3.4.1 → 3.5.0

package/CHANGELOG.md

@@ -4,6 +4,17 @@ 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.5.0 — 2026-10-21
+
+### Also in this release
+
+- Bundled agent skills: 8 files
+- Other files: `src/core/skills.js`, `src/core/skills.ts`
+
+## v3.4.2 — 2026-10-21
+
+No changes to the published artifact.
+
 ## v3.4.1 — 2026-10-21
 
 ### Operations

package/gemini-extension.json

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

package/package.json

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

package/server.json

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

package/skills/headless/steps/02-refine/SKILL.md

@@ -109,6 +109,13 @@ If the user asks for something outside the scope (user accounts, member areas, b
 calendar backend, user-generated content), say plainly that the headless flow doesn't support it yet
 and record it under **Out of scope** — don't promise it.
 
+> **A contact form *is* supported (WordPress backends).** If the user wants one, keep it in
+> **Must-haves** and name it "Contact form". Provision installs **Contact Form 7** on `/cms` and the
+> frontend wires a contact page whose form emails the site owner through WordPress's built-in
+> `wp_mail()` — no third-party service and no API keys. It's **opt-in**: built only when the brief asks
+> for it. (A form that needs accounts, payments or a booking calendar is still out of scope — this is a
+> plain name/email/message enquiry form.)
+
 ### Build mode — ask once (this one *is* a user choice)
 
 The backend is your call, but **how the frontend gets built is the user's** — because most of the time

package/skills/headless/steps/03-provision/wordpress/SKILL.md

@@ -190,6 +190,46 @@ it once `provision.status == "completed"`. The authoritative data-layer referenc
 > user for payment credentials. Store currency and address (`woocommerce_*` options) likewise aren't
 > settable headlessly — they follow the install default and the owner can change them in wp-admin.
 
+## Step 5b — Contact form (Contact Form 7) *(only when the brief's Must-haves include a contact form — skip otherwise)*
+
+Run this only when the brief's **Must-haves** include a contact form. It installs **Contact Form 7**
+(`contact-form-7`) on this same `/cms` install, so the frontend can render a contact page whose form
+emails the site owner through WordPress's built-in `wp_mail()` — no third-party service and no API keys.
+Like Yoast/WooCommerce this is **join-half** work: run it once `provision.status == "completed"`. The form
+itself (id + fields + recipient) — and a tiny **spam-guard plugin** that makes a honeypot work headlessly —
+are resolved/deployed in the content-model push — see
+[`../../04-content-model/wordpress/contact-form.md`](../../04-content-model/wordpress/contact-form.md).
+
+> **Why CF7 and not a bespoke mailer.** A contact form is maintained, spam-hardened functionality worth
+> reusing rather than reinventing (you *can* deploy a custom plugin to a headless `/cms` — see the
+> content-model cookbook — but you needn't write your own mailer). CF7 is a wordpress.org-slug plugin,
+> installs through the same management MCP as Yoast, and ships a **public, unauthenticated** submit
+> endpoint (`POST /cms/wp-json/contact-form-7/v1/contact-forms/<id>/feedback`). The frontend and `/cms`
+> are same-origin, so the browser posts to it directly — no proxy, no CORS, no secret on the client.
+
+1. **Install + activate CF7** (management MCP, async — poll, never blind-retry):
+   - `wordpress_plugins_install { username, software: <install_id>, plugins: ["contact-form-7"] }`
+   - Poll `wordpress_plugins_list-installed { username, software }` until `contact-form-7` shows `active`
+     (install + activate can complete together), or activate it with
+     `wordpress_plugins_activate { username, software, plugin: "contact-form-7" }`.
+   - **Don't install the `contact-form-7-honeypot` add-on.** It only acts when a `[honeypot]` form-tag is
+     present in the form — a wp-admin edit the headless agent can't make — so on the default form it does
+     nothing. Headless spam protection instead comes from a small **spam-guard plugin deployed in the
+     content-model push** (it hooks `wpcf7_spam`); see the cookbook.
+   - **Known quirk:** the `hostinger-wordpress` MCP sometimes returns **HTTP 500 even though the job
+     succeeded**. Treat a 500 as "verify, don't assume": poll `list-installed` before retrying, and
+     never fire a second install blindly.
+2. **Verify** `GET https://<domain>/cms/wp-json/` lists the **`contact-form-7/v1`** namespace, then
+   record `contact_form.enabled: true` in `site.json` (Step 6). If the install can't be confirmed after
+   one retry, record `contact_form.enabled: false`, tell the user in one line, and let the frontend
+   render the contact page without a form (graceful — not a build failure). Don't fail provision over it.
+
+The owner's email is **CF7's default recipient** (`[_site_admin_email]`, the admin address from
+install) — fine out of the box, so "does Hostinger set up the email?" is **yes** for basic delivery via
+`wp_mail`. Deliverability (SPF/DKIM) is most reliable when that address is a mailbox **on the same
+domain**; the content-model push keeps the default recipient and validate sends a test submission to
+confirm mail actually leaves. Never ask the user for mail credentials.
+
 ## Step 6 — Record `site.json`
 
 ```json
@@ -241,6 +281,29 @@ No passwords or tokens in `site.json`. When the user needs wp-admin, mint a one-
 }
 ```
 
+**For a brief with a contact form (CF7 installed in Step 5b), also add a `contact_form` block.**
+Provision records only `enabled` + `plugin` here; the content-model push fills `form_id`,
+`feedback_url`, `fields` and `honeypot_field` once it resolves the form and deploys the spam guard:
+
+```json
+{
+  "contact_form": {
+    "enabled": true,
+    "plugin": "contact-form-7",
+    "form_id": null,
+    "feedback_url": null,
+    "fields": [],
+    "honeypot_field": null,
+    "recipient": "site-admin-email"
+  }
+}
+```
+
+`form_id` / `feedback_url` / `fields` / `honeypot_field` stay `null` / `[]` until content-model resolves the form (the
+submit URL is `https://<domain>/cms/wp-json/contact-form-7/v1/contact-forms/<form_id>/feedback`).
+`recipient` is informational — CF7's `To` is `[_site_admin_email]`; no address, token or secret is
+stored in `site.json`.
+
 `rest_api` stays `wp/v2` (the WordPress content contract, for the blog/pages on the same site);
 `store_api` is the public storefront surface (browse/cart/coupons/checkout, no auth). `wc_rest_api`
 (`wc/v3`) is recorded only as the surface the **owner's own** integrations use with a consumer key they

package/skills/headless/steps/04-content-model/wordpress/SKILL.md

@@ -41,6 +41,20 @@ authenticated; the admin user context (`wp_set_current_user`) exists only *insid
 > (no custom plugin, no consumer key). Do the WordPress content below as normal, then run the **WooCommerce
 > catalog** section before you hand off.
 
+> **Needs more than posts and pages? See [`custom-plugins.md`](custom-plugins.md).** The per-site MCP can
+> create content *data* but can't register a **custom post type**, a **custom taxonomy**, or a **global
+> settings page** (footer text, phone, social links the frontend reads). When the content model calls for
+> those, author a small custom plugin and deploy it into the headless `/cms` with
+> `hosting_deploy { type: "wordpress-plugin", headless: true }`, exposing everything over REST for the
+> frontend. **Deploy the plugin first** (the schema — the deploy activates it), then the steps below populate
+> its entries through the MCP's native `cpt-create` ability (custom-taxonomy terms are seeded in the plugin — see the cookbook).
+
+> **A contact form on this site? See [`contact-form.md`](contact-form.md).** When the brief's
+> **Must-haves** include a contact form (`site.json → contact_form.enabled: true`), provision installed
+> **Contact Form 7**; this push resolves the form's numeric id + field names (in the **same session**)
+> and records them into `site.json` so the Step 6 frontend can submit to CF7's public feedback endpoint.
+> Run the **Contact form** section after the WordPress content below.
+
 ## Step 1 — Open the authenticated MCP session
 
 Mint a short-lived token through the Hostinger connector:
@@ -75,9 +89,10 @@ what's there; with discovery, list abilities, then execute by ability name. The
 cover this step (exact names come from discovery — don't hardcode them):
 
 `SettingsTools` · `CategoriesTools` · `TagsTools` · `MediaUploadTools` / `MediaTools` · `PagesTools` ·
-`PostsTools` · `MenusTools` / `NavigationTools` · `SeoTools`. A generic
-`RestEndpointTool` can reach any `wp/v2` route *through the authenticated session* if no dedicated tool
-fits.
+`PostsTools` · `MenusTools` / `NavigationTools` · `SeoTools`, plus **`cpt-*`** for custom post types. There
+is **no** generic `wp/v2` passthrough tool — every write goes through a dedicated ability, so a `wp/v2`
+route with no matching ability (e.g. the terms of a *custom* taxonomy) isn't reachable from the MCP;
+register and seed those in a custom plugin instead (see the backend's custom-plugins cookbook).
 
 Seen on a live install (Hostinger AI Assistant, discovery mode): the meta-tools are
 `hostinger-ai-discover-abilities`, `hostinger-ai-get-ability-info { name }` and
@@ -92,12 +107,18 @@ create answers **`200`** (not `201`) and the new object's `id` is **inside** `re
 ## Step 3 — Idempotency rule (makes resume safe)
 
 Every create is **list/get-by-slug first, then create only if absent** — a re-run must not duplicate.
-Use the matching read ability (or `RestEndpointTool` → `GET /wp/v2/posts?slug=…&status=any`): a hit →
-reuse its `id`; empty → create. Capture each returned `id` and record the id map back into
+Use the matching read ability (`posts-search`, `pages-search`, `categories-list`, `tags-list`,
+`cpt-search`, `media-search`, …): a hit → reuse its `id`; empty → create. Capture each returned `id` and record the id map back into
 `content-model.md` so later references resolve without re-querying.
 
 ## Step 4 — Create in dependency order
 
+> **Custom types/settings? Deploy the plugin before this list.** If the content model needs a custom post
+> type, taxonomy or global settings page, deploy that plugin **first** (the deploy activates it — see
+> [`custom-plugins.md`](custom-plugins.md)) so its REST routes exist — then the steps below populate its
+> entries through the MCP's native `cpt-create` ability, as they do core posts and pages (custom-taxonomy
+> terms are seeded in the plugin — the MCP has no taxonomy-term path; see the cookbook).
+
 0. **Remove WordPress's default content first.** A fresh install ships a **"Hello world!" post**
    (id 1), a **"Sample Page"**, and a default comment — they will otherwise show up on the live site.
    Delete the default post (`posts-delete { id: 1, force: true }`) and, if present, the sample page
@@ -216,6 +237,38 @@ the storefront Store API and the checkout gate): [`woocommerce.md`](woocommerce.
 > finishes it in wp-admin). Seeding + verifying the catalog over the Store API is the whole job; never call
 > `/checkout` or block on it. See the cookbook §4.
 
+## Contact form (Contact Form 7) *(only when `site.json → contact_form.enabled` is true — skip otherwise)*
+
+Provision installed Contact Form 7. Here, resolve the form the frontend submits to, deploy a tiny
+spam-guard plugin (a headless honeypot), and record both into `site.json`. Full recipe:
+[`contact-form.md`](contact-form.md). In short:
+
+1. **Find the form id (idempotent).** The per-site MCP has **no generic REST ability** and
+   `wpcf7_contact_form` is not a public CPT, so read the id by **probing the public feedback endpoint**:
+   a **`multipart/form-data`** `POST {urls.cms}/wp-json/contact-form-7/v1/contact-forms/<id>/feedback` with
+   `_wpcf7_unit_tag=wpcf7-f<id>-o1`, for `id` in `1`‒`30`. The hit is the id whose `200` JSON reply carries
+   `"contact_form_id": <id>` (plus a CF7 `"status"`) — the default **"Contact form 1"** (fields `your-name`,
+   `your-email`, `your-subject`, `your-message`); `404`/`wpcf7_not_found` is a miss, and anything else
+   (`415`, `403`, `429`, `5xx`) is inconclusive, never a hit. **The content type matters:** CF7 answers
+   `415` to a non-multipart body *before* it looks up the id, so a bare POST would wrongly pick id 1. Reuse
+   it on re-run. CF7's default mail already sends to `[_site_admin_email]`, so no recipient change is needed.
+   *(Fallback if nothing answers: hand the owner the one-click wp-admin login — `wordpress_login_create-links`
+   — to read the id from Contact → Contact Forms, the WooCommerce-checkout-gate owner-handoff pattern.)* See
+   the cookbook for the full method.
+2. **Deploy the spam guard (honeypot).** The `contact-form-7-honeypot` add-on can't work headlessly (it
+   needs a `[honeypot]` form-tag only an owner can add), so deploy a ~15-line `wpcf7_spam` plugin to `/cms`
+   with `hosting_deploy { type: "wordpress-plugin", slug: "cf7-headless-spamguard", headless: true }` — it
+   flags a submission as `spam` (no mail) when a fixed decoy field (`your_website`) is filled. Cookbook §2b.
+3. **Record into `site.json`** — fill the `contact_form` block provision started: `form_id`,
+   `feedback_url` (`{urls.cms}/wp-json/contact-form-7/v1/contact-forms/<form_id>/feedback`), `fields`
+   (the form's input names, e.g. `["your-name","your-email","your-subject","your-message"]`) and
+   `honeypot_field` (`"your_website"`, the decoy the frontend renders empty). Note the form id in
+   `content-model.md` under `## Created in WordPress`.
+
+> **Don't send a real test here.** Resolving the form id + fields is the whole job for this stage; the
+> throwaway `mail_sent` test belongs to **validate** (Step 7), so one dummy email reaches the owner, not
+> several. See the cookbook for the feedback contract and the hidden `_wpcf7*` fields the frontend needs.
+
 ## Step 6 — Hand off
 
 Update `state.json` (`provision` stays `completed`; advance `stage` toward the frontend **data**

package/skills/headless/steps/04-content-model/wordpress/contact-form.md

@@ -0,0 +1,227 @@
+# headless — Contact Form 7 cookbook (contact form on headless WordPress)
+
+A companion recipe to `SKILL.md` (WordPress content model). Use it whenever the brief's **Must-haves**
+include a contact form (`site.json → contact_form.enabled: true`). The goal: a contact page whose form,
+submitted from the **decoupled frontend**, sends the enquiry to the site owner by email using
+WordPress's built-in `wp_mail()` — no third-party form service, no API keys, no secret on the client.
+
+**Contact Form 7 is not a separate backend.** It is the `contact-form-7` plugin on the same headless
+WordPress install at `/cms` (installed in the provision step). This cookbook is the authoritative home for
+the contact-form data layer: how to **resolve the form** (content-model push), **deploy a spam guard**,
+what the **frontend submits** (Step 6), and how **validate** proves mail actually leaves.
+
+---
+
+## 1 — Why CF7, and why it works headlessly
+
+You **could** deploy a custom plugin into the headless `/cms` and write a bespoke mailer (see
+[`custom-plugins.md`](custom-plugins.md)), but a contact form is exactly the kind of maintained,
+spam-hardened functionality you should **reuse rather than reinvent**. CF7 is the right choice because:
+
+- It is a **wordpress.org-slug plugin** → installs through the same management MCP (`wordpress_plugins_install`)
+  as Yoast and WooCommerce. No custom code to deploy.
+- It ships a **public, unauthenticated submit endpoint**:
+  `POST {urls.cms}/wp-json/contact-form-7/v1/contact-forms/<form_id>/feedback`. Submissions don't need
+  the JWT or any key.
+- The frontend (apex domain) and `/cms` are **same-origin**, so the browser posts straight to that
+  endpoint — **no proxy route, no CORS, no credentials client-side.**
+- On submit CF7 runs its mail template through `wp_mail()`, which on Hostinger routes through the
+  server's mailer. The default form's `To` is `[_site_admin_email]` — the admin address set at install —
+  so **basic email delivery works out of the box.**
+
+**Spam protection comes from a tiny deployed plugin, not the Honeypot add-on.** CF7's own
+`contact-form-7-honeypot` add-on only acts when a `[honeypot]` form-tag is present in the form — a wp-admin
+edit the headless agent can't make — so on the default form it does **nothing**. Instead, deploy a
+~15-line `wpcf7_spam` guard into `/cms` (the capability from [`custom-plugins.md`](custom-plugins.md)): it
+rejects a submission whose decoy field is filled, with no owner step and no keys. See *§2b — Spam
+protection* below. (reCAPTCHA is the alternative but needs owner-provided Google keys set in wp-admin —
+out of reach for the headless agent.)
+
+---
+
+## 2 — Content-model push: resolve the form and record it
+
+A fresh CF7 install ships one form, **"Contact form 1"**, with the default fields `your-name`,
+`your-email`, `your-subject`, `your-message` and a submit, and mails `[_site_admin_email]`. You need
+its **numeric form id** (and, if you tailored the form, its field names) to build `feedback_url`.
+
+> **Reality check — how to read the id.** The per-site WP MCP (Hostinger AI Assistant, discovery mode)
+> exposes **no generic REST/`RestEndpointTool` ability**, and `wpcf7_contact_form` is **not a public CPT**
+> (it is absent from `cpt-list-types` and from `wp/v2/types`), so the MCP cannot read the form, and CF7's
+> own `GET /contact-form-7/v1/contact-forms` is capability-gated (no public read). The reliable,
+> tool-free way is to **probe the public feedback endpoint**, which needs no auth.
+
+1. **Find the form id by probing the feedback endpoint (idempotent).** For `id` in a small range
+   (`1`‒`30` covers a fresh install — the default form lands a few ids after the sample content), send a
+   **`multipart/form-data`** `POST {urls.cms}/wp-json/contact-form-7/v1/contact-forms/<id>/feedback` with
+   a single field `_wpcf7_unit_tag=wpcf7-f<id>-o1`. **The content type matters:** CF7 checks it *before*
+   it looks up the id and answers **415** to any non-multipart body, so a bare POST returns non-404 for
+   *every* id and would wrongly pick id 1.
+   - **Hit** → `200` whose JSON body carries `"contact_form_id": <id>` (matching the id you probed) and a
+     CF7 `"status"` (e.g. `validation_failed`). **This id is the form.** On a fresh single-form install
+     that is the only hit; reuse it on a re-run.
+   - **Miss** → `404` with `"code": "wpcf7_not_found"`. Keep going.
+   - **Inconclusive** → anything else (`415` from a wrong content type, `403`, `429`, `5xx`) is **not** a
+     hit — never select such an id. Fix the request or retry, widen the range, and fall back to the owner
+     handoff (step 2) if nothing resolves.
+
+   The default field names are `your-name`, `your-email`, `your-subject`, `your-message`. (A full test
+   submission that confirms both the id and the field names — and that mail actually sends — belongs to
+   **validate**, so you send just one real email; see §4.)
+
+2. **(Optional) tailor the form — owner-side.** The headless tooling can't edit the CF7 form (no REST
+   ability reaches it). If the design needs different fields, keep the default form for the build and note
+   it; the owner edits fields/recipient in wp-admin (Contact → Contact Forms) via the one-click login.
+   The default form is enough for a name/email/subject/message enquiry, and its recipient
+   (`[_site_admin_email]`) is already correct.
+
+3. **Record into `site.json`** — fill the `contact_form` block provision started:
+
+   ```json
+   {
+     "contact_form": {
+       "enabled": true,
+       "plugin": "contact-form-7",
+       "form_id": 4,
+       "feedback_url": "https://<domain>/cms/wp-json/contact-form-7/v1/contact-forms/4/feedback",
+       "fields": ["your-name", "your-email", "your-subject", "your-message"],
+       "cf7_version": "6.2.2",
+       "honeypot_field": "your_website",
+       "recipient": "site-admin-email"
+     }
+   }
+   ```
+
+   `cf7_version` is the installed CF7 version (from `wordpress_plugins_list-installed`) — the frontend
+   sends it as `_wpcf7_version`. `honeypot_field` is the decoy the spam guard checks (§2b) — the frontend
+   renders it empty and the server rejects a filled one. Also note the form id in `content-model.md`. No
+   address, token or secret goes into `site.json`.
+
+> **Fallback if the probe finds nothing** (an unusual install, or the default form was removed): mint a
+> one-click wp-admin link (`wordpress_login_create-links { username, software }`) and ask the owner to
+> read the form id from **Contact → Contact Forms** (the shortcode shows `id="…"`). Record it into
+> `site.json` and continue — the same owner-handoff used for the WooCommerce checkout gate, not a build
+> failure.
+
+> **Aside — Hostinger's own shortcode.** The per-site MCP's `pages-create` ability suggests
+> `[hostinger_contact_form]` for a contact form *inside a WordPress page*. That is server-rendered
+> shortcode output, not useful to a decoupled React frontend that reads REST JSON — this flow uses CF7's
+> JSON feedback endpoint instead. Mentioned only so the shortcode hint isn't mistaken for the headless path.
+
+---
+
+## 2b — Spam protection: deploy the honeypot guard
+
+CF7's default form has **no spam protection**, and the `contact-form-7-honeypot` add-on can't help
+headlessly (it needs a `[honeypot]` form-tag only an owner can add — see §1). Instead, deploy a tiny
+plugin that enforces a honeypot **server-side**, on the same REST feedback path the frontend uses. This
+reuses the custom-plugin deploy from [`custom-plugins.md`](custom-plugins.md) — the only moving part is one
+~15-line file.
+
+**Why it works.** CF7's `wpcf7_spam` filter runs inside `submit()`, which the REST feedback endpoint
+calls, so returning `true` sets the submission `status` to `spam` and **suppresses the mail**. The hook can
+read any posted field via `WPCF7_Submission::get_posted_data()` — including a decoy field that isn't a CF7
+form-tag, **as long as its name doesn't start with `_`** (CF7 strips `_`-prefixed keys). So the frontend
+sends a decoy field (empty for humans), and the guard flags the submission as spam when a bot fills it.
+
+1. **Write the guard** to `~/.hostinger/<domain>/plugins/cf7-headless-spamguard/cf7-headless-spamguard.php`:
+
+   ```php
+   <?php
+   /**
+    * Plugin Name: CF7 Headless Spam Guard
+    * Description: Server-side honeypot for Contact Form 7 submissions from a headless frontend.
+    * Version:     1.0.0
+    * Requires PHP: 7.4
+    * License:     GPL-2.0-or-later
+    */
+   if ( ! defined( 'ABSPATH' ) ) { exit; }
+
+   // Reject a submission whose decoy field is filled. The name is a fixed convention the frontend
+   // renders empty (site.json → contact_form.honeypot_field); it must NOT start with "_".
+   add_filter( 'wpcf7_spam', function ( $spam, $submission ) {
+   	if ( $spam ) { return $spam; }                        // keep any earlier spam verdict
+   	$decoy = $submission->get_posted_data( 'your_website' );
+   	if ( is_string( $decoy ) && trim( $decoy ) !== '' ) {
+   		$spam = true;                                     // bot filled it → status 'spam', no mail
+   	}
+   	return $spam;
+   }, 10, 2 );
+   ```
+
+2. **Deploy it** into the headless `/cms` (activates on install; idempotent — re-deploy to update):
+
+   ```json
+   { "operation": "hosting_deploy",
+     "params": {
+       "domain": "<domain>",
+       "type": "wordpress-plugin",
+       "path": "~/.hostinger/<domain>/plugins/cf7-headless-spamguard",
+       "slug": "cf7-headless-spamguard",
+       "headless": true } }
+   ```
+
+3. **Record** `contact_form.honeypot_field: "your_website"` in `site.json` (done in §2 step 3) so the
+   frontend knows which decoy to render. Keep the plugin **generic** (no site-specific values) — it's one
+   reusable artifact, not per-site code.
+
+> **Nonce note.** CF7's built-in spam check also flags nonce failure, but nonce verification is **inactive
+> for logged-out visitors by default** — which is why a plain headless submission returns `mail_sent`, not
+> `spam`. The guard adds the honeypot on top. Confirm end-to-end in validate (§4).
+
+---
+
+## 3 — What the frontend submits (Step 6 reference)
+
+The feedback endpoint expects `multipart/form-data` with the form's own fields **plus** CF7's hidden
+control fields. The frontend builds this in a `submitContactForm(data)` helper in the one data module:
+
+| Field | Value |
+|---|---|
+| each name in `contact_form.fields` | the user's input (`your-name`, `your-email`, …) |
+| `_wpcf7` | `contact_form.form_id` (number) |
+| `_wpcf7_version` | CF7 version string, e.g. `"5.9.8"` (not strictly validated) |
+| `_wpcf7_locale` | e.g. `"en_US"` |
+| `_wpcf7_unit_tag` | any stable string, e.g. `"wpcf7-f<form_id>-o1"` |
+| `_wpcf7_container_post` | `"0"` |
+| `contact_form.honeypot_field` (the decoy, e.g. `your_website`) | **empty** — rendered hidden/off-screen, `autocomplete="off"`, `tabindex="-1"`; the §2b guard rejects it as spam if filled |
+
+`POST` to `contact_form.feedback_url` and **do not set `Content-Type`** — let the browser add the
+multipart boundary. Same-origin, so no CORS and no secret.
+
+**Response** is JSON:
+
+```json
+{ "contact_form_id": 42, "status": "mail_sent", "message": "Thank you for your message. It has been sent.",
+  "invalid_fields": [], "posted_data_hash": "…" }
+```
+
+Branch on `status`:
+
+- `mail_sent` → success state (clear the form, show the thank-you message).
+- `validation_failed` → map each `invalid_fields[].field` to its input and show the message inline.
+- `spam` / `aborted` / `mail_failed` / `acceptance_missing` → a generic "couldn't send, try again" error.
+
+A user validation error is a **normal UI state, not a build error**. When `contact_form.enabled` is
+`false` or absent, the frontend renders the contact page with plain contact details and **no form**.
+
+---
+
+## 4 — Email delivery & the `wp_mail` caveat (what to tell the owner)
+
+CF7's default form mails `[_site_admin_email]` via `wp_mail()`, so **Hostinger does "set up" basic email
+by default** — nothing else to configure for the form to send. Two caveats worth surfacing:
+
+- **Deliverability.** `wp_mail` from a shared host can land in spam for external recipients without
+  SPF/DKIM. The most reliable recipient is a **Hostinger mailbox on the same domain**. Keep CF7's admin
+  recipient; if the owner wants a different inbox, point them to a same-domain mailbox.
+- **Prove it, don't assume it.** Validate (Step 7) POSTs a throwaway test submission and asserts
+  `status == "mail_sent"`. A `mail_failed` is a real finding — report it (CF7 is wired, but the mailer
+  needs attention), don't pass silently.
+- **Check the honeypot too.** Send one more throwaway submission with the decoy
+  (`contact_form.honeypot_field`) **filled** — it must come back `status: "spam"` with **no** mail. If it
+  returns `mail_sent`, the §2b guard plugin isn't active (re-check its deploy). The normal empty-decoy
+  submission still returns `mail_sent`, so this costs one extra throwaway email at most.
+
+Don't install an SMTP plugin or ask for mail credentials as part of this flow — the default `wp_mail`
+path is the intended behaviour; SMTP is an owner decision in wp-admin if deliverability needs hardening.