hostinger-api-mcp 3.25.1 → 3.27.0

package/src/core/skills.ts

@@ -232,24 +232,17 @@ const skills: Skill[] = [
       },
       {
         "uri": "skill://hostinger-headless/steps/05-design/SKILL.md",
-        "digest": "sha256:0050de12d624cd066bb9e8f1feb1386dec820e70b2e99e83c116c3c2d94e62a9",
-        "size": 39766,
+        "digest": "sha256:7b112a9cdbff35fc4a12a3eee861ca4a27f29437f0d5cbd912209286ccc5a24f",
+        "size": 31791,
         "mimeType": "text/markdown",
-        "text": "---\nname: headless-step-design\ndescription: \"Step 5 (design) of the Hostinger Headless flow. Derives three distinct design directions from brief.md (plus any reference sites and brand assets), lets the user pick one in a single question, checks the chosen one against the 8-point grid and WCAG 2.2 AA, designs the logo as outlined SVG (wordmark, icon mark, favicon), following any logo wish the owner gave, then writes design.md — tokens, type, logo, components, per-page composition, accessibility and imagery — as the contract the frontend implements (the framework/stack is chosen later by the frontend step). When the brief says to keep an existing look, writes design.md from that look and its own logo instead. Prepare work: runs during the provision wait and never touches the backend.\"\n---\n\n# headless-step-design\n\nTurn the brief into a look the user has chosen, and write it down so the frontend can't drift from\nit. **One question, three options, one spec.** The output is **files** (`design.md` plus the logo),\nnot a conversation: the frontend step implements `design.md`, not the chat.\n\n**In:** `brief.md` (required), `content-model.md` (if it exists yet), reference sites and assets the\nuser gave. **Out:** `~/.hostinger/<domain>/design.md` and the logo files in\n`~/.hostinger/<domain>/brand/`.\n\n> ## ⚠️ Build mode: \"Bring your own frontend\"? This step defers to the user\n> Read `brief.md` → **Build mode** first. When it is **Bring your own frontend**, the user drives the\n> design — **do not generate three directions or write a prescriptive `design.md` over their project.**\n> The frontend already exists (or the user vibe-codes it with you); your job is to follow *their*\n> direction, not impose one. Skip Steps 1–7 below, *Keep the current look* included, even when\n> **Design direction** keeps the look of the app in this folder: their own code already carries it.\n> Either write nothing, or capture only what the user explicitly asks for (a short note of their\n> stated colours/vibe) so the frontend step has it, then do Step 7's `state.json` update so the flow\n> moves on to frontend. The logo and token work here apply only when **Build mode is \"Agent designs\n> and builds\"**.\n\nThis is **prepare work**: it runs while provision settles (see *Background provision & the instance\nbarrier* in the top-level `SKILL.md`). Nothing here calls the Hostinger connector or the backend.\n\n**Keep it short.** Refine already asked about tone and look; don't ask again. The step asks the user\n**one** question: either the keep/change question (Step 1 and *Keep the current look*) or the three\ndirections (Step 4), never both. \"You decide\" is a valid answer.\n\n**Talk like a person, not a designer.** Everything the user reads describes how the site will\n**look and feel**: colours by name (\"hot pink, butter yellow\"), lettering by feel (\"big chunky\nrounded headlines\"), and the details they'll notice (\"photos tilted like stickers on a scrapbook\").\nNo hex codes, font names, or design and tech words (palette, accent, tokens, shape language,\ncontrast, favicon, wordmark, lockup, WCAG, 8-point grid, Next.js, SSR, `state.json`), even when\nthe owner's own brand guide names them. This covers every message until the step ends, including\nthe keep/change question, your one-line confirmation after the pick and the message you hand off\nwith.\n\n**Two hard rules apply to every direction, however loud or quiet it is:**\n\n- **The 8-point grid.** Every spacing, sizing and layout value is a multiple of 8 px (details in\n  5.2).\n- **WCAG 2.2 Level AA.** Colour, focus, motion, target size and reflow are decided here, so the\n  frontend can't build them wrong (details in 5.1 and 5.3).\n\nThese rules are for you, not the user. **Never mention them**: no grid, contrast, WCAG or\naccessibility talk in anything the user reads, and no \"all options follow…\" reassurances. The user\njudges the look in the preview; the rules just make sure it works.\n\n---\n\n## Step 1 — Read the workspace, then the resume check\n\nRead `brief.md`, `state.json`, and `content-model.md` if it exists.\n\n- **`design.md` already exists and this is not a redesign** → don't overwrite it. Describe the\n  current look in two or three plain sentences and ask: *keep it, or change something?* That is this\n  step's one question.\n  - **Keep** → leave the file alone and go straight to the `state.json` update at the end of Step 7.\n  - **Change** → edit only what they asked for, re-run the 5.x checks on what changed, then save.\n- **The site is already deployed** (`deploy.json` exists, or `state.json` has `deployed_at`) and the\n  user asked for a different look → this is a **redesign**. Tell them plainly: their content stays\n  as it is, only the look changes, and they'll see a preview before it goes live. Then run Steps 2–7\n  as normal. The current `design.md` becomes one more signal in Step 2, so carry over what the user\n  wants to keep and move away from the rest.\n- **The brief says to keep the current look** (*Design direction* says so in the owner's words:\n  \"keep the look we have\", \"same look, new platform\") → follow *Keep the current look* below instead\n  of Steps 2–6. No three directions and no new logo. A live site, screenshots or a brand guide alone\n  are signals for Step 2, not a request to keep.\n\n### Keep the current look\n\n1. **Read the look from what the brief points at.** A live site: use Step 2's reference-site method\n   (computed fonts, colours by painted area, the feel), but this site is the owner's own, so take its\n   logo file as it is (the header `<img>` or inline `<svg>`, plus its favicon if it has one) and save\n   it unchanged in `brand/`. Screenshots or a brand guide: read the colours and lettering from them;\n   a logo seen only in a screenshot counts as no logo file, so list \"logo file needed\" under gaps in\n   the final report. The app in this folder (the path under `brief.md` → **Existing project**):\n   read its source; no build or browser needed.\n   - *Colours:* the theme tokens (Tailwind v4 `@theme`, v3 `tailwind.config.*` `theme`/`theme.extend`,\n     `:root` custom properties), ranked by how often the code uses them (class names, `var()`), with\n     the page background and body text taken from the root layout or `body`.\n   - *Fonts:* theme font tokens, `@fontsource` imports or dependencies, Google Fonts `<link>` or\n     `@import`, and the `font-family` on `body` and headings.\n   - *Logo:* files named `logo*` in `public/`, `static/`, `src/assets/` or `assets/`;\n     `favicon*`, `icon*` or `apple-icon*` in `public/`, `static/`, `app/` or `src/app/`; or the icon\n     declared by `<link rel=\"icon\">` in `index.html` or the root layout's `metadata.icons`. Copy them\n     unchanged into `brand/`.\n\n   Files or exact colours and fonts the owner supplied win over anything you read.\n2. **Confirm in one question.** Describe the kept look in two plain sentences and ask: *keep it, or\n   change something?* \"Keep the look we have\" still gets this question; skip it only when the brief\n   says to change nothing at all (\"keep it exactly as it is\"). A skipped tool result is not Keep; see\n   *When you ask the user* in the top-level `SKILL.md`. Change →\n   apply only what they asked for; a request for a new logo runs Step 6 for the logo alone.\n3. **Check it** as in Step 5. The kept colours are fixed like brand colours: a pair that fails gets a\n   shade of the same hue in that role only. Spacing moves to the nearest grid value, and a font\n   without an `@fontsource` package swaps to the closest one that resolves (5.4).\n4. **Logo.** Reuse the existing logo and favicon unchanged; never redraw or recolour them. With no\n   existing logo, the header shows the site name as text in the kept display font, and no logo is\n   designed.\n5. **Write `design.md`** (Step 7) from the kept look, then hand off as usual. In **Logo**:\n   - *Files* and *Use* name the files as saved (a `.png` stays a `.png`), or say \"No favicon kept\".\n   - *Built from* says \"Kept, not rebuilt\". *Measured* still gives the width at `--logo-h-sm`\n     (≤ 192 px; else lower `--logo-h-sm` or show the name as text on small screens), and the header\n     link has `alt` = the site name and a target of at least 24 px (as in Step 6).\n   - With no logo: *Files* says \"None\", *Use* says the header link holds the site name as text in\n     `--font-display` and the browser's default favicon stays, and the *Don't* line is dropped.\n\n## Step 2 — Collect the signals\n\nBefore inventing anything, gather what already constrains the design:\n\n| Signal | Where | How it constrains |\n|---|---|---|\n| Tone, purpose, audience | `brief.md` → *Tone*, *Purpose*, *Audience* | Sets the mood all three directions must fit |\n| Brand assets | `brief.md` → *Assets* | Logo, brand colours and fonts are **fixed** in every direction. Never recolour a supplied logo; Step 6 uses it instead of designing one |\n| Pages and entities | `content-model.md` → *Navigation*, *Pages*, *Articles*; if it doesn't exist yet, `brief.md` → *Pages* | Drives the component inventory and page composition |\n| Reference sites | URLs in the brief or the conversation | Cues to borrow (see below) |\n| Images already sourced | `content-model.md` → the image lines under *Articles* (skip if none yet) | Glance at a few at small size; keep accents from clashing with their dominant colours |\n| Current design (redesign only) | existing `design.md` | What to keep, what to move away from |\n\n**Reference sites.** Open each one in a real browser if you have one. Static fetches are often\nblocked or rate-limited; without a browser, fetch the HTML and its linked CSS instead. If neither\nworks, say so in one line and continue from the brief alone. Pull **cues**:\n\n- **Fonts:** the computed `font-family` of `h1`/`h2` and of body `p`.\n- **Colours:** background colours weighted by painted area (element width × height), the top 5–8.\n  Skip transparent and semi-transparent backgrounds and overlays (cookie banners, modals, chat\n  widgets). Text colours come from headings, paragraphs and links.\n- **Feel:** look at the first screen and one further down (screenshots shown to you, not saved in\n  the workspace) and note what creates the feel: type weight, colour blocking, shapes, density.\n\n**Borrow cues, never assets** (the owner's own site under *Keep the current look* is the exception).\nDon't use its logo, copy, images or exact layout. **The brief wins** over the live site when they\ndisagree (the user's words are what they want). Note the mismatch in the direction.\n\n**Brand colours that fail contrast** are still fixed, but only in roles where they pass. A pale brand\nyellow can be a background band or a large decorative shape, never body text. Say so in the\ndirection.\n\n## Step 3 — Derive three directions\n\nWrite three directions that **all fit the brief** but are **genuinely different**. Vary at least two\nof: palette (temperature, saturation, light vs. dark), type personality (geometric, grotesk, serif,\ndisplay), and shape language (sharp vs. round, flat vs. outlined, airy vs. dense). Three shades of\none idea is not a choice. Neither is a wildcard that ignores the brief.\n\nOrder them: **A is the recommendation**, the closest reading of the brief and references. B and C\npush in different directions.\n\nEach direction carries exactly this:\n\n- **Name** — 2–3 evocative words (\"Sticker-book maximal\", \"Quiet gallery\").\n- **Mood** — one line on how the site feels.\n- **Palette** — 5–7 hex colours with roles (base, text, primary accent, secondary accents, surface).\n  These are the core colours the user sees; Step 5 may add derived shades (link, muted, error,\n  focus) as tokens.\n- **Type** — a display font and a body font, both self-hostable through `@fontsource`.\n- **Shape language** — corners, borders, shadows and density in one phrase (\"chunky 3 px ink\n  outlines, hard 8 px offset shadows, tilted cards\").\n- **Signature element** — the one memorable move (a scrolling marquee, stickers, oversized numerals,\n  a duotone photo treatment). If it moves on its own, it gets a pause control (5.3).\n- **Logo idea** — one line on how the name becomes a logo, using a move from Step 6 (\"letters\n  bounce in different colours and the O is a smiley\"). When the brief carries a logo wish (*Design\n  direction* or *Assets*), every direction's logo idea is that wish in its own style. A wish is words\n  describing a logo; a logo file in *Assets* is a supplied logo and wins (Step 6).\n\n**Only offer what can pass.** Before asking, run two quick gates on **all three**:\n\n1. **Contrast gate.** Every colour that will carry text (base, surfaces, and any accent used as a\n   text block) has a palette text colour reaching **4.5:1** on it. Two text colours are fine (dark on\n   light blocks, light on dark ones). Accents that only ever hold large text need 3:1.\n2. **Font gate.** Each font resolves on npm, and the display font also has a static `@fontsource`\n   package, because the logo is built from it (5.4).\n\nA direction that fails either gate gets adjusted, not offered as-is. Don't offer a look that only\nworks by breaking the rules, such as body text on a neon accent or a marquee that can't be stopped.\nLoud is fine; inaccessible is not.\n\n**Avoid the template look** unless the brief asks for neutral: Inter or Roboto everywhere, a\nblue-to-purple gradient hero, centred hero with three feature cards, grey cards on white. Every\ndirection should look like *this* site, not a starter theme.\n\n## Step 4 — Ask once\n\nAsk **one** question, with A marked as the recommendation. With a structured question UI (multiple\nchoice plus an \"other\" field), each option's **label** is the direction's name and its\n**description** is one or two plain sentences, under ~160 characters. Without one, write each\noption as one line in the same shape.\n\nThe description says what the site would feel like, the main colours by name, what the lettering\nis like, the logo idea, and the one detail they'll remember. Hex codes and font names stay in your\nnotes. The question may end with one plain clause saying they can add a logo idea to their pick, but\nnever suggest one or give an example: that idea would end up in the logo.\n\n> **Sticker-book maximal** — Loud and playful, like a scrapbook: candy pink, butter yellow and lilac,\n> chunky headlines, tilted sticker photos and a bouncy logo with a smiley O.\n\n> **Midnight disco** — A dark, glowing night-out feel: deep purple with neon pink, yellow and\n> turquoise, heavy rounded headlines and a logo like a neon sign.\n\nThen:\n\n- **Pick** → use it as written, and confirm the look in one line.\n- **\"You decide\"** → use A, and tell them in one line which look you went with.\n- **Skipped tool result** → not an answer: write the three directions as plain lines\n  and wait for the reply (see *When you ask the user* in the top-level `SKILL.md`).\n- **A mix** (\"A's colours with C's fonts\") → merge them. Don't ask again.\n- **Something else** → build a direction from what they said, run Step 5, and use it. Don't send\n  three new options.\n\n**Logo wish.** An answer can carry a logo idea next to the pick (\"A, and make the logo a little\nteapot\"); it replaces the chosen direction's logo idea, and wins over a wish from the brief.\nWhenever the logo follows a wish, from the answer or the brief, add it once to the line that confirms\nthe pick: *\"The logo follows your idea: a little teapot.\"* If the kit can't draw it as said (a\ndetailed illustration, a photo), build its closest kit version and name what you simplified in that\nsame line. Don't ask a follow-up.\n\nDon't ask about anything else in this step.\n\n## Step 5 — Check the chosen direction\n\nFix any problem found here by adjusting the direction, not by asking the user. Don't report these\nchecks or their fixes; the user sees the result in the preview.\n\n### 5.1 Contrast — WCAG 2.2 SC 1.4.3 and 1.4.11\n\n**Which pairs count:** walk the component inventory you're about to write (Components table). For\neach component, list every foreground/background combination in every state: default, hover,\nfocus, active, error. Include text on coloured bands (footer links on dark, marquee text, chips),\nplaceholder text and photo credits. Compute the WCAG contrast ratio for each:\n\n| Kind | Examples | Minimum |\n|---|---|---|\n| Body text | paragraphs, links, footer text, input text, placeholder text, captions | **4.5:1** |\n| Large text | ≥ 24 px regular, or ≥ 18.66 px (14 pt) bold | **3:1** |\n| Non-text | input and button boundaries (when the outline is the only edge), focus indicator against each adjacent colour, icons that carry meaning, chip outlines | **3:1** |\n\nA pair that fails gets a darker or lighter shade of the **same hue**; never drop a brand colour. A\nnew shade becomes a token (for example `--color-link` or `--color-muted`). Disabled controls and\npure decoration are exempt, but say which elements those are. **Text on photos** needs a scrim or\nsolid backing that gets the text to 4.5:1 against the lightest part of the image. If you can't\nguarantee that, don't put text on photos. Record every pair and its ratio in `design.md`.\n\n```js\n// node -e: relative luminance + contrast ratio, hex in → ratio out\nconst L = h => { const c = h.match(/\\w\\w/g).map(x => parseInt(x, 16) / 255)\n  .map(v => v <= 0.03928 ? v / 12.92 : ((v + 0.055) / 1.055) ** 2.4);\n  return 0.2126 * c[0] + 0.7152 * c[1] + 0.0722 * c[2]; };\nconst ratio = (a, b) => { const [x, y] = [L(a), L(b)].sort((m, n) => n - m); return (x + 0.05) / (y + 0.05); };\n```\n\n### 5.2 The 8-point grid\n\nValues are checked in px at the default 16 px root (`0.5rem` = 8 px).\n\n| What | Rule |\n|---|---|\n| Spacing (padding, margin, gap) | Multiples of 8: `8 16 24 32 48 64 96 128`. **4 px** is the only half-step, and only inside small components (chip padding, icon-to-label gap) |\n| Component sizes | Heights and fixed widths are multiples of 8. Buttons, nav items and inputs are **48 px** tall minimum |\n| Radii | `8 16 24 32`, or `999px` for pills. 4 px only on elements under 32 px tall |\n| Line heights | Fixed-size text: multiples of 8 (16/24, 18/32, 24/32), or of 4 for text ≤ 14 px (12/16, 14/20). Fluid headings (`clamp()` sizes) use a unitless line-height (1.0–1.2) and are exempt, because their line box can't stay on the grid at every size |\n| Fluid spacing | `clamp()` for spacing or sizes uses grid values at both ends. Fluid **font sizes** are exempt |\n| Shadow offsets | 4 or 8 multiples |\n| Layout | Content width, gutters and breakpoints are multiples of 8 (e.g. `1200`, `768`, `1024`, `1280`) |\n| Exempt | Border and outline widths (1–4 px), focus offset, font sizes, the `999px` pill radius, the 4-multiple line heights above, and anything that isn't a length (angles like a `-2deg` tilt, durations, opacity) |\n\nEvery value in the **Tokens** block must pass this table.\n\n### 5.3 WCAG 2.2 AA — what the design must decide\n\nThese criteria are settled at design time. Write each answer into the **Accessibility** section of\n`design.md`.\n\n| Criterion | The design must specify |\n|---|---|\n| 1.4.1 Use of colour | Links in running text are underlined, not colour-only. States (active nav, selected, error) also change shape, weight or an icon, not only colour |\n| 1.4.4 Resize text | Font sizes in `rem`; nothing breaks at 200 % zoom |\n| 1.4.10 Reflow | Works at **320 CSS px** wide with no horizontal scroll. Every component has a stated ≤ 320 px behaviour; decorative pieces never widen the page |\n| 1.4.12 Text spacing | No fixed-height boxes around text, so nothing clips when a user overrides spacing (line-height 1.5, paragraph spacing 2×, letter-spacing 0.12 em, word-spacing 0.16 em). Fixed line-height tokens are fine; clipping is not |\n| 2.2.2 Pause, Stop, Hide | Anything that moves on its own for more than 5 s (marquee, carousel, animated sticker) has a **visible pause control**, and doesn't move at all under `prefers-reduced-motion`. Hover-to-pause alone doesn't count |\n| 2.3.1 Three flashes | Nothing flashes more than 3 times a second |\n| 2.4.7 Focus visible | One focus style (e.g. 3 px outline, 2 px offset) whose colour reaches 3:1 against **every** surface it can appear on. Name a second colour for surfaces where the first fails |\n| 2.4.11 Focus not obscured *(new in 2.2)* | Sticky headers, cookie bars and chat bubbles never cover the focused element. Either the header isn't sticky, or `scroll-padding-top: var(--header-h)` |\n| 2.5.8 Target size *(new in 2.2)* | Interactive targets ≥ 24 × 24 px with spacing. On this grid: **48 px** for buttons, nav and inputs, ≥ 24 px for inline icon buttons |\n| 3.2.6 Consistent help *(new in 2.2)* | The contact or help link sits in the same place on every page (e.g. last nav item and footer) |\n| 3.3.2 Labels | Every form field has a visible label; placeholders are never the only label |\n| 1.1.1 Text alternatives | Content images get alt text describing what they show; purely decorative images and shapes get empty alt or `aria-hidden` |\n\n### 5.4 Fonts resolve\n\nFor each family, prefer the variable package and fall back to the static one:\n`npm view @fontsource-variable/<slug> version`, then `npm view @fontsource/<slug> version`. One must\nanswer with a version. If neither does, swap to the closest family that does. Record the exact\npackage names. The **display** family must also resolve as a static package\n(`npm view @fontsource/<slug> version`): the static packages ship `.woff` files the logo kit can\nread; the variable ones ship only `.woff2`.\n\n### 5.5 The header fits on one line\n\nThe header is where a cramped width shows first: the logo, every nav item and the call-to-action\nbutton share one row, and when they run out of room they wrap mid-phrase (\"Services &\" over\n\"Pricing\", \"Book\" over \"Appointment\"). That always looks broken. Decide it here so the frontend\ncan't build it that way.\n\n- **Labels never break mid-phrase.** Nav links and the header button get `white-space: nowrap`, so a\n  two-word label stays on one line or not at all.\n- **Collapse before it wraps — not at 320 px.** The inline nav is replaced by a menu (hamburger)\n  button at the width where the logo, all nav items and the button stop fitting on one line, which is\n  usually wider than the mobile breakpoint. Estimate that width from the number of nav items and their\n  label lengths, round up to a multiple of 8, and make it the header's own breakpoint. Below it, only\n  the logo and the menu button show; the nav items and the CTA move into the opened menu.\n- **Keep header labels short.** A nav label is one or two short words; a button label is a two-word\n  verb phrase at most (\"Book now\", not \"Book an Appointment\"). When the content model gives a long\n  navigation label, the header may show a shorter form (\"Contact & Booking\" → \"Contact\") while the\n  page keeps its full name — note the shortened label in the **Header + nav** row.\n- Record the header breakpoint in *Grid, shape & motion* and the `nowrap` + collapse rule in the\n  **Header + nav** component row (and its `≤ 320 px` cell).\n\n## Step 6 — Design the logo\n\n**The user supplied a logo** → copy it into `brand/` unchanged, note it in the **Logo** section, and\nskip the rest of this step. Never redraw or recolour it.\n\nOtherwise, turn the brief's **Site name**, spelled as the user confirmed it, into a **designed** logo:\nshaped, coloured and composed. Typing the name in the display font with an emoji or symbol next to it\ndoesn't count. Build the chosen direction's **logo idea** (as replaced by any logo wish, Step 4) with\none or two of these moves:\n\n| Move | What it is | Suits |\n|---|---|---|\n| **Letter swap** | One letter becomes a simple shape tied to the subject: O → smiley, sun, loaf, plate, eye; I → candle, pencil, brush; A → roof, tent. Swap **one character** only, even if the letter appears twice, and the word must still read | Playful, friendly brands |\n| **Bounce** | Letters tilt ±3–6° and bob off the baseline, each in a palette colour, with an ink outline and hard shadow | Loud, maximal directions |\n| **Stack** | The name split over 2–3 lines on coloured tiles, or set as a tight block | Long names, bold directions |\n| **Tag** | The main word large; a short second word on a pill, ribbon or tab | Two-part names (\"Dopamine Den\") |\n| **Seal** | The name around a ring, with a monogram or symbol in the middle | A secondary mark (footer, hero sticker, social avatar), never the header logo |\n| **Typographic contrast** | Weight, style or case contrast between words (a light italic word next to a heavy upright one), custom tight spacing, one shared stroke or cut between letters | Quiet, refined, editorial directions |\n\nNo emoji, clip-art, gradients, or details that vanish at small sizes. Colours come only from the\npalette (base and surface colours count).\n\n### Build it with the logo kit\n\nThe kit (`logo-kit.mjs`, next to this file) does the error-prone parts: it outlines letters into\nvector paths, sets text on a circle, draws the outline-and-shadow treatment, measures, validates\nthe output, checks the sizes and renders a preview. You write the composition. Copy the kit into\n`brand/` so the build is self-contained and a redesign can re-run it:\n\n```bash\nmkdir -p ~/.hostinger/<domain>/brand && cd ~/.hostinger/<domain>/brand\ncp <the folder this SKILL.md is in>/logo-kit.mjs .\nnpm init -y >/dev/null && npm i opentype.js @resvg/resvg-js @fontsource/<display-slug>\n```\n\nWrite `brand/logo-build.mjs`, import from `./logo-kit.mjs`, and always run it from `brand/`\n(packages resolve from the working directory):\n\n| Kit function | Use |\n|---|---|\n| `loadFont(slug, weight, style)` | Loads a static `@fontsource` weight across all its subsets (`latin`, `latin-ext`, …), so accented letters like Ė or Ł resolve; `style` is `'normal'` or `'italic'`. Throws if that weight or style isn't in the package, so pick another |\n| `layout(font, text, size)` | Kerned glyph positions, total width, `capHeight`, `xHeight`; place letters one by one for bounce or swap. Throws if a character isn't in the font |\n| `glyphPath(glyph, x, baselineY, size)` / `textPath(font, text, x, baselineY, size)` | Outlined path data for one letter or a whole word. For typographic contrast, load two weights or styles and set each word with `textPath` |\n| `pathBox(font, text, x, baselineY, size)` | Tight box around a word's outlines; size the viewBox from it plus room for outlines, shadows and tilt |\n| `arcText(font, text, { cx, cy, r, size })` | Letters around a circle, for seals |\n| `sticker(d, { fill, ink, strokeWidth, shadow, shadowColor, transform })` | Ink outline + hard offset shadow, for outlined directions. On dark backgrounds give the outline and shadow a palette colour that shows (`shadowColor` defaults to `ink`) |\n| `svgDoc({ width, height, title, body })` | Root SVG with `role=\"img\"` and a `<title>` |\n| `check(svg)` | Throws on `NaN`, live `<text>`, a missing title or viewBox, or an `&` that isn't an XML entity. Run it on every file before writing |\n| `tile(size, fill)` | The rounded tile for the mark and favicon; draw the symbol after it |\n| `widthBudget(letterHeight, height)` | The widest viewBox that still fits 192 px on small screens, for a logo of that height; see below |\n| `checkLogo({ logo, mark, favicon, letterHeight, background })` | Runs `check()` on all three files, checks their sizes and renders `brand/logo-preview.png`; see below |\n\nWrap every file in `svgDoc()`, never a hand-written `<svg>` or `<title>`: it escapes the site name,\nand one bare `&` (as in \"Salt & Pepper\") makes the browser show nothing.\n\nNever call opentype's `path.toPathData()` directly; the kit's serializer exists because opentype.js\n2.0 writes `NaN` into some paths, and browsers silently stop drawing at the first `NaN`.\n\n### Deliver four files\n\n| File | What | Must read clearly at |\n|---|---|---|\n| `brand/logo.svg` | The primary, mostly horizontal logo for the header | Its header display heights (desktop and small screens) |\n| `brand/logo-mark.svg` | A square icon from the same idea (initial, monogram or the swapped symbol) on a `tile()` in a palette colour | 32 px |\n| `brand/favicon.svg` | The simplest form of the mark: same tile, no shadow, no thin details, outlines thickened if it has any | 16 px, on both light and dark browser tab bars |\n| `brand/logo-build.mjs` | The script that built them, with `package.json`, kept so a redesign can adjust it | — |\n\nAdd `brand/logo-seal.svg` only if the direction uses a seal as a secondary mark. Delete\n`brand/node_modules` when you're done; a redesign runs `npm i` in `brand/` first.\n\n**Compose within the budget, so the first build passes.** The small-screen logo is at most 192 px\nwide with letters at least 16 px tall, so the whole logo can be only about 10–12 times as wide as\nits smallest letters are tall, whatever its height. On one line that's about ten letters plus a\nsymbol; a longer name stacks or tags, and a second word set at half size halves the room. Size the\nviewBox in `logo-build.mjs` against `widthBudget(letterHeight, viewBoxHeight)`, the exact limit at\nthe heights the kit picks; with your own `heights`, the FAIL line gives the limit. Draw the mark's\nsymbol from simple, recognisable shapes that still read at 32 px; fine natural forms like petals or\nleaves turn to mush.\n\n**Check the sizes and look at it after every build.** `letterHeight` is in viewBox units: the\n`xHeight` from `layout()` when the logo is mostly lowercase, `capHeight` when it's mostly capitals;\nfor mixed fonts, the smaller word's. End `logo-build.mjs` with:\n\n```js\ncheckLogo({ logo, mark, favicon, letterHeight, background: '<page background colour>' });\n```\n\nIt picks the header heights for you: `--logo-h-sm` is the smallest multiple of 8 that makes the\nletters 16 px, and `--logo-h` the same but at least 48 px, both at most 80 px, so a stacked lockup\nkeeps its words large or sets the mark beside them. Pass `heights: { desktop, small }` only when the\ndirection needs a larger header logo. It first prints `--logo-h`, `--logo-h-sm` and the **Measured**\nline for `design.md`, then PASS or FAIL for the logo's letters ≥ 16 px at both\nheights, width ≤ 192 px on small screens, headroom around everything drawn and heights in multiples\nof 8; for the mark and favicon sitting on a `tile()` with nothing clipped and room around\nthe symbol; and for no shadow on the favicon. Every FAIL names its fixes and the number to reach. It\nthen renders `logo-preview.png` (the logo at both heights on the page background, the mark at 32 px\nand favicon at 16 px on light and dark strips, each also enlarged), and throws if anything failed.\n\nThen read `logo-preview.png`; don't search for another renderer or read the SVG source. Rebuild only\nfor a FAIL line or something in the preview that reads wrong, such as collisions, a clipped or\nclearly off-centre mark, or a favicon detail that turns to mush, and fix everything you saw in one\nrebuild. Optical nudges of a few pixels and the header height aren't reasons to rebuild. A symbol\ngets one redraw: if it still reads wrong, replace it with a simpler form of the idea, such as the\ninitial, in the next build. If the kit says \"preview not rendered\", rely on the size check and list\n\"logo not visually checked\" under gaps in the final report.\n\nThe logo is exempt from text-contrast minimums, but the header link around it needs `alt` = the site\nname and a target of at least 24 px.\n\nDon't show the logo to the user in this step; they see it in the preview.\n\n## Step 7 — Write `design.md` and hand off\n\nWrite `design.md` from the template below. Fill every section. The **Tokens** block is copied\nverbatim into the frontend's global stylesheet, so it must be valid CSS. Every colour, font, type\nsize, line height, space, radius and shadow used elsewhere in the file must exist in it as a token.\nThe template's token list is the **minimum**: add what the design needs (`--color-error`,\n`--color-on-accent`, `--leading-h3`…) under the same naming scheme.\n**Breakpoints are the one exception**: CSS custom properties don't work inside `@media`, so they are\nlisted in *Grid, shape & motion* as plain px values.\n\nThen update `state.json`: set `\"stage\": \"frontend\"` (also for a redesign: restyle, then validate and\ndeploy) and `updated_at` to the current UTC time (ISO 8601). Don't touch `provision` or add\nother keys.\n\nIf content prepare hasn't sourced images yet, it now follows `design.md` → **Imagery** (see\n`04-content-model/SKILL.md`).\n\nHand off in one or two plain sentences, as *Talk like a person* says: \"The look is set: warm cream,\nbrown lettering, berry buttons and your loaf logo.\" Nothing after it: no font names, file names or\nstages, and gaps such as a missing icon file or a font that may not load go in the final report.\n\n## `design.md` template\n\n````markdown\n# Design — <domain>\n\n> Direction **<name>**, selected on <YYYY-MM-DD> from three options (others offered: <B name>,\n> <C name>). <\"Picked by the user.\" | \"User said 'you decide'; recommendation A used.\" |\n> \"Merged by the user: <what>.\"> — or, when kept: \"Kept the owner's current look from <site URL |\n> screenshots | brand guide>, confirmed on <YYYY-MM-DD>.\"\n\n## Direction\n<2–3 sentences: the mood, what it borrows from the references (and any brief/reference mismatch),\nthe signature element.>\n\n## Stack\n**<chosen by the frontend step>** — design doesn't decide the stack. The frontend step (06) picks and\nconfirms the framework (default Next.js SSR; ecommerce must be SSR) and records it in\n`state.json → frontend`. Leave this as a placeholder for the frontend step to fill in.\n\n## Tokens\n```css\n:root {\n  /* colour — semantic names, never \"--pink-2\" */\n  --color-base: #…;      --color-text: #…;      --color-surface: #…;    --color-muted: #…;\n  --color-primary: #…;   --color-accent-1: #…;  --color-accent-2: #…;   --color-link: #…;\n  --color-focus: #…;     --color-focus-alt: #…; /* for surfaces where --color-focus is < 3:1 */\n  /* type */\n  --font-display: '<Family> Variable', <fallback stack>;\n  --font-body: '<Family> Variable', <fallback stack>;\n  --text-body: …rem;   --leading-body: …rem;    /* 8-multiple in px */\n  --text-small: …rem;  --leading-small: …rem;   /* 4-multiple in px */\n  --text-h1: clamp(…rem, …, …rem);  --text-h2: clamp(…);  --text-h3: …rem;\n  --leading-display: 1.05;          /* unitless; fluid headings are grid-exempt */\n  /* 8-point grid */\n  --space-half: 4px;  --space-1: 8px;   --space-2: 16px;  --space-3: 24px;  --space-4: 32px;\n  --space-6: 48px;    --space-8: 64px;  --space-12: 96px; --space-16: 128px;\n  --target-min: 48px;\n  /* shape */\n  --radius-sm: 8px;  --radius-card: …;  --radius-pill: 999px;\n  --border: …;  --shadow: …;  --shadow-hover: …;\n  --focus-ring: 3px solid var(--color-focus);  --focus-offset: 2px;\n  /* layout */\n  --content-max: …px;  /* multiple of 8 */\n  --header-h: …px;     /* header band height, multiple of 8; scroll-padding-top uses it if sticky */\n  --logo-h: …px;       /* header logo height on desktop, multiple of 8 */\n  --logo-h-sm: …px;    /* on small screens; logo ≤ 192 px wide at this height */\n}\n```\n\n## Palette roles\n| Token | Hex | Used for |\n|---|---|---|\n\n## Contrast\n| Foreground | Background | Kind (body text / large text / non-text) | Ratio | Needs | Passes |\n|---|---|---|---|---|---|\n\n## Type\n- **Display:** <family> (`@fontsource-variable/<slug>@<version>`), weights …, tracking …; sizes `--text-h1…h3`, `--leading-display`\n- **Body:** <family> (`@fontsource-variable/<slug>@<version>`); `--text-body` / `--leading-body`, measure ≤ 68ch\n\n## Logo\n- **Concept:** <the move(s), and what any swapped letter or symbol stands for, plus \"From the owner:\n  '<their words>'\" only when it follows their wish | \"Supplied by the user\" | \"Kept from <source>\" |\n  \"No logo: owner kept the current look\" (header shows the site name as text in `--font-display`)>\n- **Built from:** `@fontsource/<display-slug>@<version>`, weight(s)/style(s) …\n- **Files:** `brand/logo.svg` (header, `--logo-h` desktop / `--logo-h-sm` small screens),\n  `brand/logo-mark.svg`, `brand/favicon.svg`<, `brand/logo-seal.svg`>; source `brand/logo-build.mjs`\n- **Measured:** letters … px tall at `--logo-h-sm`; width … px at `--logo-h-sm`\n- **Use:** the frontend copies `brand/*.svg` into `public/`. Header: `<a href=\"/\"><img src=\"/logo.svg\"\n  alt=\"<Site name>\" style=\"height: var(--logo-h)\"></a>` (switch to `--logo-h-sm` on small screens).\n  Favicon: `<link rel=\"icon\" href=\"/favicon.svg\" type=\"image/svg+xml\">`\n- **Don't:** recolour, stretch, add effects, or retype the logo as live text.\n\n## Grid, shape & motion\n<section padding desktop/mobile (space tokens), gutters, breakpoints in px (multiples of 8), borders,\nradii, shadows, hover behaviour, every animation and its pause control, and \"no motion under\nprefers-reduced-motion\".>\n\n## Accessibility (WCAG 2.2 AA)\n- **Focus:** <style; which colour on which surface>\n- **Targets:** <48 px controls; inline exceptions>\n- **Links & states:** <underline rule; how active/error states differ beyond colour>\n- **Motion:** <what moves, where its pause control is>\n- **Sticky elements:** <none | header uses --header-h + scroll-padding-top>\n- **Help:** <where the contact link sits on every page>\n- **Text on images:** <none | scrim spec and resulting ratio>\n- **Reflow:** <anything special at 320 px>\n- **Exempt from contrast:** <disabled controls / decorative shapes, named>\n\n## Components\n| Component | Renders (from content model) | Look | ≤ 320 px |\n|---|---|---|---|\n| Header + nav | Navigation items | … Nav links and the button never wrap (`white-space: nowrap`); the inline nav collapses to a menu button at <px> (the width it stops fitting one line). | Logo + menu button only; nav items and CTA inside the menu |\n| Post card | Article: image, category, title, excerpt | … | … |\n| … | | | |\n\n## Page composition\n- **<Page>** — <sections top to bottom, each naming its component and band colour>\n- …\n\n## Imagery\n<subjects, mood and colour fit for photos; search keywords; treatment (frame, crop ratio, radius,\nduotone…); alt text written from what the photo shows.>\n\n## Don'ts\n- <3–6 site-specific rules, e.g. \"no grey cards\", \"never put body text on the primary accent\">\n````\n\n## Invariants\n\n- **One question.** Refine owns discovery; this step only chooses among directions (or keeps the\n  existing look).\n- **8-point grid, always.** No spacing, size, radius or breakpoint off the grid except the listed\n  exemptions.\n- **WCAG 2.2 AA is the floor.** No direction is offered, chosen or written that fails it. Brand\n  colours keep their hue but only appear in roles where they pass.\n- **The header never wraps.** Nav labels and the header button stay on one line (`white-space:\n  nowrap`); the inline nav collapses to a menu button at the width it stops fitting, not only at the\n  mobile breakpoint (5.5).\n- **Brand assets are fixed.** A supplied logo, colour or font appears in every direction, unchanged.\n- **A logo is designed, not typed.** Outlined SVG paths built with the logo kit, never live text,\n  emoji or clip-art, and always readable at its smallest use. The one exception: a kept look with no\n  logo shows the site name as text and gets no new logo.\n- **Self-hosted fonts only** (`@fontsource`). No Google Fonts or other font CDN links in the output.\n- **The tokens block is the only source of values** (breakpoints excepted). Components and pages\n  reference tokens, never raw hex codes, pixel values or font names.\n- **No backend calls.** Design never waits on provision and never writes to the instance.\n- **Never overwrite an existing `design.md` silently.** Keep or change, as in Step 1.\n"
-      },
-      {
-        "uri": "skill://hostinger-headless/steps/05-design/logo-kit.mjs",
-        "digest": "sha256:64973dff8fa33d2d12cd33374af9a1ac1cc9740990c90d5326f4997a96943f2b",
-        "size": 21426,
-        "mimeType": "text/plain",
-        "text": "// Hostinger Headless — logo kit (step 05-design).\n//\n// Primitives for building a designed logo as outlined SVG: the letters become vector paths, so the\n// logo needs no web font and renders identically everywhere. The agent composes the design; this\n// file only does the parts that are easy to get wrong.\n//\n// Workflow (from ~/.hostinger/<domain>/brand/, so packages and this kit sit next to the build):\n//   cp <installed skill>/steps/05-design/logo-kit.mjs .\n//   npm init -y && npm i opentype.js @resvg/resvg-js @fontsource/<display-family-slug>\n//   node logo-build.mjs          // your script: import { … } from './logo-kit.mjs'\n//                                // then read logo-preview.png\n//   rm -rf node_modules          // package.json keeps the deps; a redesign runs `npm i` again\n//\n// Packages resolve from the current working directory, so run the build from brand/.\n\nimport { createRequire } from 'node:module';\nimport { readFileSync, writeFileSync } from 'node:fs';\nimport { join } from 'node:path';\n\nconst requireFromCwd = createRequire(join(process.cwd(), 'logo-build.js'));\nconst opentype = requireFromCwd('opentype.js');\n// Optional: without resvg the kit still builds logos, it just can't measure what's drawn or render.\nconst Resvg = (() => {\n  try {\n    return requireFromCwd('@resvg/resvg-js').Resvg;\n  } catch {\n    return null;\n  }\n})();\n\n// @fontsource splits each weight into unicode subsets; `latin` alone has no ą č ę ė į š ų ū ž,\n// ő, ł, đ… so load every subset that exists and look each character up across them.\nconst SUBSETS = ['latin', 'latin-ext', 'vietnamese', 'cyrillic', 'cyrillic-ext', 'greek', 'greek-ext'];\n\nfunction parseWoff(file) {\n  const buf = readFileSync(file);\n  return opentype.parse(buf.buffer.slice(buf.byteOffset, buf.byteOffset + buf.byteLength));\n}\n\n/**\n * Load a static @fontsource weight (the static packages ship .woff, which opentype.js reads;\n * variable packages ship only .woff2, which it can't). The returned font is the `latin` subset\n * with `charToGlyph` widened to every other subset in the package, so accented letters resolve.\n * @param {string} slug  family slug, e.g. \"unbounded\"\n * @param {number} weight e.g. 900\n */\nexport function loadFont(slug, weight = 400, style = 'normal') {\n  const fonts = [];\n  for (const subset of SUBSETS) {\n    let file;\n    try {\n      file = requireFromCwd.resolve(`@fontsource/${slug}/files/${slug}-${subset}-${weight}-${style}.woff`);\n    } catch {\n      continue;\n    }\n    fonts.push(parseWoff(file));\n  }\n  if (!fonts.length) throw new Error(`logo-kit: @fontsource/${slug} has no ${weight} ${style} .woff files`);\n  const [primary] = fonts;\n  const own = primary.charToGlyph.bind(primary);\n  primary.charToGlyph = (ch) => {\n    for (const font of fonts) {\n      const glyph = font === primary ? own(ch) : font.charToGlyph(ch);\n      if (glyph.index) {\n        glyph.kitFont = font;\n        return glyph;\n      }\n    }\n    return own(ch);\n  };\n  return primary;\n}\n\nconst VIEWBOX = /viewBox=\"0 0 ([\\d.]+) ([\\d.]+)\"/;\n\nconst num = (v) => {\n  if (!Number.isFinite(v)) throw new Error(`logo-kit: non-finite coordinate ${v}`);\n  return +v.toFixed(2);\n};\n\n/**\n * Serialize an opentype Path to SVG path data. Use this instead of path.toPathData():\n * opentype.js 2.0 emits \"NaN\" when a coordinate's fraction is a tiny float residue\n * (its roundDecimal builds strings like \"5.6e-14e+2\"), and the browser silently stops drawing\n * the path at the first NaN.\n */\nexport function toD(path) {\n  return path.commands\n    .map((c) => {\n      switch (c.type) {\n        case 'Z':\n          return 'Z';\n        case 'Q':\n          return `Q${num(c.x1)} ${num(c.y1)} ${num(c.x)} ${num(c.y)}`;\n        case 'C':\n          return `C${num(c.x1)} ${num(c.y1)} ${num(c.x2)} ${num(c.y2)} ${num(c.x)} ${num(c.y)}`;\n        default:\n          return `${c.type}${num(c.x)} ${num(c.y)}`;\n      }\n    })\n    .join('');\n}\n\n/**\n * Lay out a string with kerning. Positions are relative to x = 0 on the baseline.\n * One glyph per character: no ligatures or other substitutions, so `char` always matches its glyph\n * (and fonts whose substitution tables opentype.js can't run still work).\n * @returns {{ glyphs: { glyph, char: string, x: number, width: number }[], width: number, ascent: number, capHeight: number, xHeight: number }}\n */\nexport function layout(font, text, size, { tracking = 0 } = {}) {\n  const scale = size / font.unitsPerEm;\n  const chars = [...text];\n  const glyphs = chars.map((ch) => font.charToGlyph(ch));\n  glyphs.forEach((glyph, i) => {\n    if (!glyph.index && chars[i].trim()) {\n      throw new Error(`logo-kit: \"${chars[i]}\" is not in this font (it would render as an empty box); pick a font that has it`);\n    }\n  });\n  let x = 0;\n  const out = glyphs.map((glyph, i) => {\n    // Kerning pairs only exist inside one subset file; across subsets the indexes don't match.\n    if (i && (glyphs[i - 1].kitFont ?? font) === (glyph.kitFont ?? font)) {\n      const kern = font.getKerningValue(glyphs[i - 1], glyph);\n      x += (Number.isFinite(kern) ? kern : 0) * scale + tracking;\n    }\n    const item = { glyph, char: chars[i] ?? '', x, width: glyph.advanceWidth * scale };\n    x += item.width;\n    return item;\n  });\n  const capHeight = (font.tables.os2?.sCapHeight || font.ascender * 0.7) * scale;\n  const xHeight = (font.tables.os2?.sxHeight || font.ascender * 0.5) * scale;\n  return { glyphs: out, width: x, ascent: font.ascender * scale, capHeight, xHeight };\n}\n\n/**\n * Tight bounding box of a word's outlines at (x, baselineY), before any transform. Use it to size\n * the viewBox; add room for outlines, shadows and rotations yourself.\n * @returns {{ x1: number, y1: number, x2: number, y2: number }}\n */\nexport function pathBox(font, text, x, baselineY, size, opts) {\n  const path = new opentype.Path();\n  for (const g of layout(font, text, size, opts).glyphs) path.extend(g.glyph.getPath(x + g.x, baselineY, size));\n  return path.getBoundingBox();\n}\n\n/** Path data for one glyph with its origin at (x, baselineY). */\nexport const glyphPath = (glyph, x, baselineY, size) => toD(glyph.getPath(x, baselineY, size));\n\n/** Path data for a whole string starting at (x, baselineY). */\nexport function textPath(font, text, x, baselineY, size, opts) {\n  return layout(font, text, size, opts)\n    .glyphs.map((g) => glyphPath(g.glyph, x + g.x, baselineY, size))\n    .join('');\n}\n\n/**\n * Set text around a circle (seals, badges). Each glyph is centred on its arc position and rotated\n * to stand on the circle. `fill: true` stretches the spacing so the text closes the full ring.\n * @returns {{ d: string, transform: string, char: string }[]} style each glyph however you like\n */\nexport function arcText(font, text, { cx, cy, r, size, startDeg = -90, fill = true }) {\n  const { glyphs, width, capHeight } = layout(font, text, size);\n  const k = fill ? (2 * Math.PI * r) / width : 1;\n  const offset = fill ? 0 : -width / 2; // centred on startDeg when not filling\n  return glyphs.map((g) => {\n    const along = (g.x + g.width / 2 + offset) * k;\n    const angle = along / r + (startDeg * Math.PI) / 180;\n    const px = cx + r * Math.cos(angle);\n    const py = cy + r * Math.sin(angle);\n    const deg = (angle * 180) / Math.PI + 90;\n    return {\n      d: glyphPath(g.glyph, -g.width / 2, capHeight / 2, size),\n      transform: `translate(${num(px)} ${num(py)}) rotate(${num(deg)})`,\n      char: g.char,\n    };\n  });\n}\n\n/**\n * The outlined \"cut-out\" treatment: an ink outline drawn behind the fill (paint-order) plus an\n * optional hard offset shadow. `shadowColor` defaults to the ink; set it separately on dark\n * backgrounds, where a dark ink outline vanishes but a coloured shadow still reads.\n * Returns SVG markup.\n */\nexport function sticker(d, { fill, ink = '#000', strokeWidth = 8, shadow = 8, shadowColor = ink, transform = '' }) {\n  const t = transform ? ` transform=\"${transform}\"` : '';\n  const shade = shadow\n    ? `<path data-kit=\"shadow\" d=\"${d}\" fill=\"${shadowColor}\" stroke=\"${shadowColor}\" stroke-width=\"${strokeWidth}\" stroke-linejoin=\"round\" transform=\"translate(${shadow} ${shadow})\"/>`\n    : '';\n  return `<g${t}>${shade}<path d=\"${d}\" fill=\"${fill}\" stroke=\"${ink}\" stroke-width=\"${strokeWidth}\" stroke-linejoin=\"round\" paint-order=\"stroke\"/></g>`;\n}\n\n/** The solid rounded tile behind `logo-mark.svg` and `favicon.svg`; draw the symbol after it. */\nexport function tile(size, fill) {\n  return `<rect data-kit=\"tile\" width=\"${num(size)}\" height=\"${num(size)}\" rx=\"${num(size / 4)}\" fill=\"${fill}\"/>`;\n}\n\n/** Root SVG with an accessible name. Pass a distinct `id` if two logos are inlined on one page. */\nexport function svgDoc({ width, height, title, body, id = 'logo-title' }) {\n  const esc = String(title).replace(/&/g, '&amp;').replace(/</g, '&lt;');\n  return `<svg xmlns=\"http://www.w3.org/2000/svg\" viewBox=\"0 0 ${num(width)} ${num(height)}\" role=\"img\" aria-labelledby=\"${id}\"><title id=\"${id}\">${esc}</title>${body}</svg>`;\n}\n\n/**\n * Validate a finished SVG string before writing it. Throws on: NaN/undefined/Infinity in the\n * markup, live <text> (the logo must be outlined), a missing <title>, a missing viewBox, or an \"&\" that\n * doesn't start an XML entity (a browser shows nothing for an SVG file that isn't well-formed XML).\n * @returns {{ bytes: number }}\n */\nexport function check(svg) {\n  const problems = markupProblems(svg);\n  if (problems.length) throw new Error(`logo-kit check failed: ${problems.join('; ')}`);\n  return { bytes: Buffer.byteLength(svg) };\n}\n\nfunction markupProblems(svg) {\n  const problems = [];\n  if (/NaN|undefined|Infinity/.test(svg)) problems.push('contains NaN/undefined/Infinity');\n  if (/&(?!(?:amp|lt|gt|quot|apos|#\\d+|#x[\\dA-Fa-f]+);)/.test(svg)) {\n    problems.push('contains a bare \"&\" or an HTML-only entity such as &nbsp;; build the file with svgDoc(), which escapes the title');\n  }\n  if (/<text[\\s>]/.test(svg)) problems.push('contains <text>; outline the letters with textPath/glyphPath');\n  if (!/<title[^>]*>[^<]+<\\/title>/.test(svg)) problems.push('missing <title>');\n  if (!VIEWBOX.test(svg)) problems.push('missing or invalid viewBox');\n  return problems;\n}\n\nconst MIN_LETTER_PX = 16;\nconst MAX_SMALL_WIDTH_PX = 192;\nconst MIN_DESKTOP_PX = 48;\nconst MAX_HEADER_PX = 80; // automatic heights only: taller header logos crowd the nav, and stacked lockups reached 144\nconst HEADROOM = 0.02; // of the viewBox height, on every edge\nconst CLIP_SLACK = 0.5; // viewBox units of anti-aliasing a \"nothing outside the viewBox\" check allows\n\nfunction viewBoxOf(svg) {\n  const m = svg.match(VIEWBOX);\n  if (!m) throw new Error('logo-kit: missing or invalid viewBox');\n  return { width: +m[1], height: +m[2] };\n}\n\n/** Gap between everything drawn (strokes, shadows, transforms) and each viewBox edge, smallest first. */\nfunction edgeGaps(svg, vb) {\n  const b = new Resvg(svg).getBBox();\n  if (!b) return [];\n  const gaps = { top: b.y, bottom: vb.height - b.y - b.height, left: b.x, right: vb.width - b.x - b.width };\n  return Object.entries(gaps).sort((a, b) => a[1] - b[1]);\n}\n\nconst px = (v) => +v.toFixed(1);\nconst ceil1 = (v) => Math.ceil(v * 10) / 10;\nconst ceil8 = (v) => Math.ceil(v / 8) * 8;\nconst floor8 = (v) => Math.floor(v / 8) * 8;\n\nconst minHeaderPx = (letterHeight, height) => ceil8((MIN_LETTER_PX * height) / letterHeight);\nconst maxWidthAt = (height, smallPx) => Math.floor((MAX_SMALL_WIDTH_PX * height) / smallPx);\n\nfunction autoHeights(letterHeight, height) {\n  const small = Math.min(minHeaderPx(letterHeight, height), MAX_HEADER_PX);\n  return { desktop: Math.max(small, MIN_DESKTOP_PX), small };\n}\n\n/**\n * The widest viewBox a logo of this height can have and still fit 192 px on small screens at the\n * height `checkLogo` picks. Call it while composing, before the first build: it is roughly\n * 10–12 × `letterHeight`, so a long name stacks or tags instead of running on one line.\n * @param {number} letterHeight viewBox units, as passed to `checkLogo`\n * @param {number} height the viewBox height\n */\nexport function widthBudget(letterHeight, height) {\n  return maxWidthAt(height, autoHeights(letterHeight, height).small);\n}\n\n/** Collects PASS/FAIL/SKIP lines; `print` returns how many failed. */\nfunction sizeReport(label, vb) {\n  const lines = [];\n  return {\n    rule(ok, text, fix) {\n      lines.push(ok ? `PASS ${text}` : `FAIL ${text} → ${fix}`);\n    },\n    skip(text) {\n      lines.push(`SKIP ${text}`);\n    },\n    headroom(svg, of) {\n      if (!Resvg) return this.skip('headroom: install @resvg/resvg-js to measure it');\n      const [edge, gap] = edgeGaps(svg, vb)[0] ?? [];\n      if (edge === undefined) return this.skip(`headroom: nothing drawn on ${of}`);\n      const min = HEADROOM * vb.height;\n      this.rule(gap >= min, `headroom ${px(gap)} at the ${edge} of ${of} (≥ ${px(min)} viewBox units)`,\n        `add ${ceil1(min - gap)} viewBox units at the ${edge}: grow the viewBox on that side or move the drawing in; accents, descenders, tilt, outline and shadow all need room`);\n    },\n    print() {\n      console.log(`${label} (viewBox ${px(vb.width)} × ${px(vb.height)}):`);\n      for (const line of lines) console.log(`  ${line}`);\n      return lines.filter((l) => l.startsWith('FAIL')).length;\n    },\n  };\n}\n\nfunction logoSizes(svg, { letterHeight, heights }) {\n  if (!letterHeight || (heights && (!heights.desktop || !heights.small))) {\n    throw new TypeError('logo-kit checkLogo: pass letterHeight, and heights: { desktop, small } only to set both');\n  }\n  const vb = viewBoxOf(svg);\n  const report = sizeReport('logo.svg', vb);\n  const minHeaderH = minHeaderPx(letterHeight, vb.height);\n  const maxSmall = floor8((MAX_SMALL_WIDTH_PX * vb.height) / vb.width);\n  const { desktop, small } = heights ?? autoHeights(letterHeight, vb.height);\n  const lettersAt = (h) => (letterHeight / vb.height) * h;\n  const width = (vb.width / vb.height) * small;\n  const canLowerSmall = small > minHeaderH && minHeaderH <= maxSmall;\n  const widthFixes = [\n    ...(canLowerSmall ? [`--logo-h-sm ${minHeaderH === maxSmall ? minHeaderH : `${minHeaderH}–${maxSmall}`} px passes both`] : []),\n    `make the viewBox at most ${maxWidthAt(vb.height, small)} units wide (now ${px(vb.width)}) at this height: stack or tag the words, tighten gaps, or show logo-mark.svg with the name beside it on small screens`,\n  ];\n\n  report.rule(desktop % 8 === 0 && small % 8 === 0, `heights ${desktop} / ${small} px are multiples of 8`, 'round them to multiples of 8');\n  const capped = !heights && minHeaderH > MAX_HEADER_PX;\n  const minLetterAtCap = ceil1((MIN_LETTER_PX * vb.height) / MAX_HEADER_PX);\n  const maxHeightAtCap = Math.floor((letterHeight * MAX_HEADER_PX) / MIN_LETTER_PX);\n  const lettersFixes = (name) => capped\n    ? [`the header logo stops at ${MAX_HEADER_PX} px: make letterHeight at least ${minLetterAtCap} viewBox units (now ${px(letterHeight)})`,\n      `make the viewBox at most ${maxHeightAtCap} units tall (now ${px(vb.height)}): trim empty space or set the mark beside the words instead of above them`]\n    : [`raise ${name} to ${minHeaderH} px or more`, 'enlarge the letters inside the viewBox', 'trim empty viewBox space'];\n  const letterChecks = desktop === small ? [['--logo-h and --logo-h-sm', small]] : [['--logo-h', desktop], ['--logo-h-sm', small]];\n  for (const [name, h] of letterChecks) {\n    report.rule(lettersAt(h) >= MIN_LETTER_PX, `letters ${px(lettersAt(h))} px tall at ${name} ${h} px (≥ ${MIN_LETTER_PX})`,\n      lettersFixes(name).join(', or '));\n  }\n  report.rule(width <= MAX_SMALL_WIDTH_PX, `width ${px(width)} px at --logo-h-sm ${small} px (≤ ${MAX_SMALL_WIDTH_PX})`,\n    widthFixes.join(', or '));\n  report.headroom(svg, 'the viewBox');\n  const measured = `- **Measured:** letters ${px(lettersAt(small))} px tall at \\`--logo-h-sm\\`; width ${px(width)} px at \\`--logo-h-sm\\``;\n  return { report, heights: { desktop, small }, measured };\n}\n\nfunction tileChecks(svg, { favicon = false } = {}) {\n  const vb = viewBoxOf(svg);\n  const report = sizeReport(favicon ? 'favicon.svg' : 'logo-mark.svg', vb);\n  const tileTag = svg.match(/<rect data-kit=\"tile\"[^>]*\\/>/)?.[0];\n  report.rule(Boolean(tileTag), 'drawn on a tile()', \"draw the tile with the kit's tile(size, fill)\");\n  if (!Resvg) report.skip('clipping: install @resvg/resvg-js to measure it');\n  else {\n    const gap = edgeGaps(svg, vb)[0]?.[1] ?? 0;\n    report.rule(gap >= -CLIP_SLACK, 'nothing drawn outside the viewBox', 'shrink or move the drawing in; the tile already fills the viewBox');\n  }\n  if (tileTag) report.headroom(svg.replace(tileTag, ''), 'the tile');\n  if (favicon) {\n    report.rule(!/data-kit=\"shadow\"|<filter|drop-shadow/.test(svg), 'no shadow', 'pass shadow: 0 to sticker() and draw no other shadow');\n  }\n  return report;\n}\n\nfunction renderPreview({ logo, mark, favicon, heights, background, out }) {\n  const render = (svg, h, zoom) => {\n    const img = new Resvg(svg, { fitTo: { mode: 'height', value: h } }).render();\n    return { w: img.width * zoom, h: img.height * zoom, href: `data:image/png;base64,${img.asPng().toString('base64')}` };\n  };\n  const tiles = (fill) => ({ fill, items: [render(mark, 32, 1), render(mark, 32, 4), render(favicon, 16, 1), render(favicon, 16, 8)] });\n  const bands = [\n    {\n      label: `logo.svg at --logo-h ${heights.desktop} px and --logo-h-sm ${heights.small} px, then 2×, on the page background`,\n      fill: background,\n      items: [render(logo, heights.desktop, 1), render(logo, heights.small, 1), render(logo, heights.desktop, 2), render(logo, heights.small, 2)],\n    },\n    { label: 'light: logo-mark.svg at 32 px and 4×, favicon.svg at 16 px and 8×', ...tiles('#f1f3f4') },\n    { label: 'dark: the same', ...tiles('#202124') },\n  ];\n  const PAD = 16;\n  const LABEL = 28;\n  let body = '';\n  let y = 0;\n  let width = 480;\n  for (const { label, fill, items } of bands) {\n    const rowH = Math.max(...items.map((i) => i.h)) + PAD * 2;\n    body += `<text x=\"${PAD}\" y=\"${y + 19}\" font-family=\"sans-serif\" font-size=\"13\" fill=\"#555\">${label}</text>`;\n    y += LABEL;\n    body += `<rect y=\"${y}\" width=\"100%\" height=\"${rowH}\" fill=\"${fill}\"/>`;\n    let x = PAD;\n    for (const i of items) {\n      body += `<image href=\"${i.href}\" x=\"${x}\" y=\"${y + (rowH - i.h) / 2}\" width=\"${i.w}\" height=\"${i.h}\" image-rendering=\"optimizeSpeed\"/>`;\n      x += i.w + PAD * 2;\n    }\n    width = Math.max(width, x - PAD);\n    y += rowH;\n  }\n  const sheet = `<svg xmlns=\"http://www.w3.org/2000/svg\" width=\"${width}\" height=\"${y}\"><rect width=\"100%\" height=\"100%\" fill=\"#fff\"/>${body}</svg>`;\n  writeFileSync(out, new Resvg(sheet).render().asPng());\n}\n\n/**\n * Check the three finished files and render one PNG to look at instead of the SVG source.\n * Throws first if any file fails `check()`.\n * - logo.svg: letters ≥ 16 px at both header heights, width ≤ 192 px on small screens, 2% headroom\n *   around everything drawn, heights in multiples of 8. Without `heights`, `--logo-h-sm` is the\n *   smallest multiple of 8 that makes the letters 16 px, and `--logo-h` the same but at least 48 px;\n *   both stop at 80 px, so letters too small for 80 px fail.\n * - logo-mark.svg, favicon.svg: drawn on a `tile()`, nothing outside the viewBox, 2% headroom\n *   around the symbol; the favicon has no shadow.\n * - logo-preview.png: the logo at both heights on the page background, the mark at 32 px and the\n *   favicon at 16 px on a light and a dark strip, each also enlarged with hard pixels.\n * Prints the heights and the Measured line first, then every PASS/FAIL line, each failure with its\n * fixes, renders the preview, then throws if anything failed.\n * @param {object} o\n * @param {number} o.letterHeight viewBox units: `layout().xHeight` (mostly lowercase) or\n *   `.capHeight` (capitals) of the smaller word\n * @param {{ desktop: number, small: number }} [o.heights] set both header heights yourself\n * @param {string} [o.background] the page background colour\n * @returns {{ heights: { desktop: number, small: number }, measured: string }} heights for\n *   `--logo-h` / `--logo-h-sm`, and the design.md → Logo → **Measured** line\n */\nexport function checkLogo({ logo, mark, favicon, letterHeight, heights, background = '#ffffff', out = 'logo-preview.png' }) {\n  // resvg can't measure or render a file check() rejects, so these fail before any size line.\n  const broken = Object.entries({ 'logo.svg': logo, 'logo-mark.svg': mark, 'favicon.svg': favicon })\n    .flatMap(([name, svg]) => markupProblems(svg).map((p) => `${name}: ${p}`));\n  if (broken.length) throw new Error(`logo-kit checkLogo: ${broken.join('; ')}`);\n  const sizes = logoSizes(logo, { letterHeight, heights });\n  // First, so piping the output through `head` can't cut them off.\n  console.log(`--logo-h: ${sizes.heights.desktop}px; --logo-h-sm: ${sizes.heights.small}px`);\n  console.log(sizes.measured);\n  const reports = [sizes.report, tileChecks(mark), tileChecks(favicon, { favicon: true })];\n  const failed = reports.reduce((n, r) => n + r.print(), 0);\n  if (Resvg) {\n    renderPreview({ logo, mark, favicon, heights: sizes.heights, background, out });\n    console.log(`preview: read ${out}`);\n  } else {\n    console.log('preview not rendered: @resvg/resvg-js is not installed; list \"logo not visually checked\" under gaps');\n  }\n  if (failed) throw new Error(`logo-kit checkLogo: ${failed} check(s) failed, see the FAIL lines above`);\n  return { heights: sizes.heights, measured: sizes.measured };\n}\n"
+        "text": "---\nname: headless-step-design\ndescription: \"Step 5 (design) of the Hostinger Headless flow. Derives three distinct design directions from brief.md (plus any reference sites and brand assets), lets the user pick one in a single question, checks the chosen one against the 8-point grid and WCAG 2.2 AA, draws the logo (the site name as text beside a small SVG icon that is also the favicon), following any logo wish the owner gave, then writes design.md — tokens, type, logo, components, per-page composition, accessibility and imagery — as the contract the frontend implements (the framework/stack is chosen later by the frontend step). When the brief says to keep an existing look, writes design.md from that look and its own logo instead. Prepare work: runs during the provision wait and never touches the backend.\"\n---\n\n# headless-step-design\n\nTurn the brief into a look the user has chosen, and write it down so the frontend can't drift from\nit. **One question, three options, one spec.** The output is **files** (`design.md` plus the logo),\nnot a conversation: the frontend step implements `design.md`, not the chat.\n\n**In:** `brief.md` (required), `content-model.md` (if it exists yet), reference sites and assets the\nuser gave. **Out:** `~/.hostinger/<domain>/design.md` and the logo files in\n`~/.hostinger/<domain>/brand/`.\n\n> ## ⚠️ Build mode: \"Bring your own frontend\"? This step defers to the user\n> Read `brief.md` → **Build mode** first. When it is **Bring your own frontend**, the user drives the\n> design — **do not generate three directions or write a prescriptive `design.md` over their project.**\n> The frontend already exists (or the user vibe-codes it with you); your job is to follow *their*\n> direction, not impose one. Skip Steps 1–7 below, *Keep the current look* included, even when\n> **Design direction** keeps the look of the app in this folder: their own code already carries it.\n> Either write nothing, or capture only what the user explicitly asks for (a short note of their\n> stated colours/vibe) so the frontend step has it, then do Step 7's `state.json` update so the flow\n> moves on to frontend. The logo and token work here apply only when **Build mode is \"Agent designs\n> and builds\"**.\n\nThis is **prepare work**: it runs while provision settles (see *Background provision & the instance\nbarrier* in the top-level `SKILL.md`). Nothing here calls the Hostinger connector or the backend.\n\n**Keep it short.** Refine already asked about tone and look; don't ask again. The step asks the user\n**one** question: either the keep/change question (Step 1 and *Keep the current look*) or the three\ndirections (Step 4), never both. \"You decide\" is a valid answer.\n\n**Talk like a person, not a designer.** Everything the user reads describes how the site will\n**look and feel**: colours by name (\"hot pink, butter yellow\"), lettering by feel (\"big chunky\nrounded headlines\"), and the details they'll notice (\"photos tilted like stickers on a scrapbook\").\nNo hex codes, font names, or design and tech words (palette, accent, tokens, shape language,\ncontrast, favicon, wordmark, lockup, WCAG, 8-point grid, Next.js, SSR, `state.json`), even when\nthe owner's own brand guide names them. This covers every message until the step ends, including\nthe keep/change question, your one-line confirmation after the pick and the message you hand off\nwith.\n\n**Two hard rules apply to every direction, however loud or quiet it is:**\n\n- **The 8-point grid.** Every spacing, sizing and layout value is a multiple of 8 px (details in\n  5.2).\n- **WCAG 2.2 Level AA.** Colour, focus, motion, target size and reflow are decided here, so the\n  frontend can't build them wrong (details in 5.1 and 5.3).\n\nThese rules are for you, not the user. **Never mention them**: no grid, contrast, WCAG or\naccessibility talk in anything the user reads, and no \"all options follow…\" reassurances. The user\njudges the look in the preview; the rules just make sure it works.\n\n---\n\n## Step 1 — Read the workspace, then the resume check\n\nRead `brief.md`, `state.json`, and `content-model.md` if it exists.\n\n- **`design.md` already exists and this is not a redesign** → don't overwrite it. Describe the\n  current look in two or three plain sentences and ask: *keep it, or change something?* That is this\n  step's one question.\n  - **Keep** → leave the file alone and go straight to the `state.json` update at the end of Step 7.\n  - **Change** → edit only what they asked for, re-run the 5.x checks on what changed, then save.\n- **The site is already deployed** (`deploy.json` exists, or `state.json` has `deployed_at`) and the\n  user asked for a different look → this is a **redesign**. Tell them plainly: their content stays\n  as it is, only the look changes, and they'll see a preview before it goes live. Then run Steps 2–7\n  as normal. The current `design.md` becomes one more signal in Step 2, so carry over what the user\n  wants to keep and move away from the rest.\n- **The brief says to keep the current look** (*Design direction* says so in the owner's words:\n  \"keep the look we have\", \"same look, new platform\") → follow *Keep the current look* below instead\n  of Steps 2–6. No three directions and no new logo. A live site, screenshots or a brand guide alone\n  are signals for Step 2, not a request to keep.\n\n### Keep the current look\n\n1. **Read the look from what the brief points at.** A live site: use Step 2's reference-site method\n   (computed fonts, colours by painted area, the feel), but this site is the owner's own, so take its\n   logo file as it is (the header `<img>` or inline `<svg>`, plus its favicon if it has one) and save\n   it unchanged in `brand/`. Screenshots or a brand guide: read the colours and lettering from them;\n   a logo seen only in a screenshot counts as no logo file, so list \"logo file needed\" under gaps in\n   the final report. The app in this folder (the path under `brief.md` → **Existing project**):\n   read its source; no build or browser needed.\n   - *Colours:* the theme tokens (Tailwind v4 `@theme`, v3 `tailwind.config.*` `theme`/`theme.extend`,\n     `:root` custom properties), ranked by how often the code uses them (class names, `var()`), with\n     the page background and body text taken from the root layout or `body`.\n   - *Fonts:* theme font tokens, `@fontsource` imports or dependencies, Google Fonts `<link>` or\n     `@import`, and the `font-family` on `body` and headings.\n   - *Logo:* files named `logo*` in `public/`, `static/`, `src/assets/` or `assets/`;\n     `favicon*`, `icon*` or `apple-icon*` in `public/`, `static/`, `app/` or `src/app/`; or the icon\n     declared by `<link rel=\"icon\">` in `index.html` or the root layout's `metadata.icons`. Copy them\n     unchanged into `brand/`.\n\n   Files or exact colours and fonts the owner supplied win over anything you read.\n2. **Confirm in one question.** Describe the kept look in two plain sentences and ask: *keep it, or\n   change something?* \"Keep the look we have\" still gets this question; skip it only when the brief\n   says to change nothing at all (\"keep it exactly as it is\"). A skipped tool result is not Keep; see\n   *When you ask the user* in the top-level `SKILL.md`. Change →\n   apply only what they asked for; a request for a new logo runs Step 6 for the logo alone.\n3. **Check it** as in Step 5. The kept colours are fixed like brand colours: a pair that fails gets a\n   shade of the same hue in that role only. Spacing moves to the nearest grid value, and a font\n   without an `@fontsource` package swaps to the closest one that resolves (5.4).\n4. **Logo.** Reuse the existing logo and favicon unchanged; never redraw or recolour them. With no\n   existing logo, the header shows the site name as text in the kept display font; no icon is drawn.\n5. **Write `design.md`** (Step 7) from the kept look, then hand off as usual. In **Logo**:\n   - *Files* and *Use* name the files as saved (a `.png` stays a `.png`), or say \"No favicon kept\".\n   - With no logo: *Files* says \"None\", *Use* says the header link holds the site name as text in\n     `--font-display` and the browser's default favicon stays, and the *Don't* line is dropped.\n\n## Step 2 — Collect the signals\n\nBefore inventing anything, gather what already constrains the design:\n\n| Signal | Where | How it constrains |\n|---|---|---|\n| Tone, purpose, audience | `brief.md` → *Tone*, *Purpose*, *Audience* | Sets the mood all three directions must fit |\n| Brand assets | `brief.md` → *Assets* | Logo, brand colours and fonts are **fixed** in every direction. Never recolour a supplied logo; Step 6 uses it instead of drawing an icon |\n| Pages and entities | `content-model.md` → *Navigation*, *Pages*, *Articles*; if it doesn't exist yet, `brief.md` → *Pages* | Drives the component inventory and page composition |\n| Reference sites | URLs in the brief or the conversation | Cues to borrow (see below) |\n| Images already sourced | `content-model.md` → the image lines under *Articles* (skip if none yet) | Glance at a few at small size; keep accents from clashing with their dominant colours |\n| Current design (redesign only) | existing `design.md` | What to keep, what to move away from |\n\n**Reference sites.** Open each one in a real browser if you have one. Static fetches are often\nblocked or rate-limited; without a browser, fetch the HTML and its linked CSS instead. If neither\nworks, say so in one line and continue from the brief alone. Pull **cues**:\n\n- **Fonts:** the computed `font-family` of `h1`/`h2` and of body `p`.\n- **Colours:** background colours weighted by painted area (element width × height), the top 5–8.\n  Skip transparent and semi-transparent backgrounds and overlays (cookie banners, modals, chat\n  widgets). Text colours come from headings, paragraphs and links.\n- **Feel:** look at the first screen and one further down (screenshots shown to you, not saved in\n  the workspace) and note what creates the feel: type weight, colour blocking, shapes, density.\n\n**Borrow cues, never assets** (the owner's own site under *Keep the current look* is the exception).\nDon't use its logo, copy, images or exact layout. **The brief wins** over the live site when they\ndisagree (the user's words are what they want). Note the mismatch in the direction.\n\n**Brand colours that fail contrast** are still fixed, but only in roles where they pass. A pale brand\nyellow can be a background band or a large decorative shape, never body text. Say so in the\ndirection.\n\n## Step 3 — Derive three directions\n\nWrite three directions that **all fit the brief** but are **genuinely different**. Vary at least two\nof: palette (temperature, saturation, light vs. dark), type personality (geometric, grotesk, serif,\ndisplay), and shape language (sharp vs. round, flat vs. outlined, airy vs. dense). Three shades of\none idea is not a choice. Neither is a wildcard that ignores the brief.\n\nOrder them: **A is the recommendation**, the closest reading of the brief and references. B and C\npush in different directions.\n\nEach direction carries exactly this:\n\n- **Name** — 2–3 evocative words (\"Sticker-book maximal\", \"Quiet gallery\").\n- **Mood** — one line on how the site feels.\n- **Palette** — 5–7 hex colours with roles (base, text, primary accent, secondary accents, surface).\n  These are the core colours the user sees; Step 5 may add derived shades (link, muted, error,\n  focus) as tokens.\n- **Type** — a display font and a body font, both self-hostable through `@fontsource`.\n- **Shape language** — corners, borders, shadows and density in one phrase (\"chunky 3 px ink\n  outlines, hard 8 px offset shadows, tilted cards\").\n- **Signature element** — the one memorable move (a scrolling marquee, stickers, oversized numerals,\n  a duotone photo treatment). If it moves on its own, it gets a pause control (5.3).\n- **Logo idea** — one line on the small icon beside the name (\"a smiling sun in butter yellow with\n  an ink outline\"). When the brief carries a logo wish (*Design direction* or *Assets*), every\n  direction's logo idea is that wish in its own style. A wish is words\n  describing a logo; a logo file in *Assets* is a supplied logo and wins (Step 6).\n\n**Only offer what can pass.** Before asking, run two quick gates on **all three**:\n\n1. **Contrast gate.** Every colour that will carry text (base, surfaces, and any accent used as a\n   text block) has a palette text colour reaching **4.5:1** on it. Two text colours are fine (dark on\n   light blocks, light on dark ones). Accents that only ever hold large text need 3:1.\n2. **Font gate.** Each font resolves on npm (5.4).\n\nA direction that fails either gate gets adjusted, not offered as-is. Don't offer a look that only\nworks by breaking the rules, such as body text on a neon accent or a marquee that can't be stopped.\nLoud is fine; inaccessible is not.\n\n**Avoid the template look** unless the brief asks for neutral: Inter or Roboto everywhere, a\nblue-to-purple gradient hero, centred hero with three feature cards, grey cards on white. Every\ndirection should look like *this* site, not a starter theme.\n\n## Step 4 — Ask once\n\nAsk **one** question, with A marked as the recommendation. With a structured question UI (multiple\nchoice plus an \"other\" field), each option's **label** is the direction's name and its\n**description** is one or two plain sentences, under ~160 characters. Without one, write each\noption as one line in the same shape.\n\nThe description says what the site would feel like, the main colours by name, what the lettering\nis like, the logo idea, and the one detail they'll remember. Hex codes and font names stay in your\nnotes. The question may end with one plain clause saying they can add a logo idea to their pick, but\nnever suggest one or give an example: that idea would end up in the logo.\n\n> **Sticker-book maximal** — Loud and playful, like a scrapbook: candy pink, butter yellow and lilac,\n> chunky headlines, tilted sticker photos and a smiling-sun logo.\n\n> **Midnight disco** — A dark, glowing night-out feel: deep purple with neon pink, yellow and\n> turquoise, heavy rounded headlines and a logo like a neon sign.\n\nThen:\n\n- **Pick** → use it as written, and confirm the look in one line.\n- **\"You decide\"** → use A, and tell them in one line which look you went with.\n- **Skipped tool result** → not an answer: write the three directions as plain lines\n  and wait for the reply (see *When you ask the user* in the top-level `SKILL.md`).\n- **A mix** (\"A's colours with C's fonts\") → merge them. Don't ask again.\n- **Something else** → build a direction from what they said, run Step 5, and use it. Don't send\n  three new options.\n\n**Logo wish.** An answer can carry a logo idea next to the pick (\"A, and make the logo a little\nteapot\"); it replaces the chosen direction's logo idea, and wins over a wish from the brief.\nWhenever the logo follows a wish, from the answer or the brief, add it once to the line that confirms\nthe pick: *\"The logo follows your idea: a little teapot.\"* If it can't be a small icon as said (a\ndetailed illustration, a photo), draw a simple version of it and name what you simplified in that\nsame line. Don't ask a follow-up.\n\nDon't ask about anything else in this step.\n\n## Step 5 — Check the chosen direction\n\nFix any problem found here by adjusting the direction, not by asking the user. Don't report these\nchecks or their fixes; the user sees the result in the preview.\n\n### 5.1 Contrast — WCAG 2.2 SC 1.4.3 and 1.4.11\n\n**Which pairs count:** walk the component inventory you're about to write (Components table). For\neach component, list every foreground/background combination in every state: default, hover,\nfocus, active, error. Include text on coloured bands (footer links on dark, marquee text, chips),\nplaceholder text and photo credits. Compute the WCAG contrast ratio for each:\n\n| Kind | Examples | Minimum |\n|---|---|---|\n| Body text | paragraphs, links, footer text, input text, placeholder text, captions | **4.5:1** |\n| Large text | ≥ 24 px regular, or ≥ 18.66 px (14 pt) bold | **3:1** |\n| Non-text | input and button boundaries (when the outline is the only edge), focus indicator against each adjacent colour, icons that carry meaning, chip outlines | **3:1** |\n\nA pair that fails gets a darker or lighter shade of the **same hue**; never drop a brand colour. A\nnew shade becomes a token (for example `--color-link` or `--color-muted`). Disabled controls and\npure decoration are exempt, but say which elements those are. **Text on photos** needs a scrim or\nsolid backing that gets the text to 4.5:1 against the lightest part of the image. If you can't\nguarantee that, don't put text on photos. Record every pair and its ratio in `design.md`.\n\n```js\n// node -e: relative luminance + contrast ratio, hex in → ratio out\nconst L = h => { const c = h.match(/\\w\\w/g).map(x => parseInt(x, 16) / 255)\n  .map(v => v <= 0.03928 ? v / 12.92 : ((v + 0.055) / 1.055) ** 2.4);\n  return 0.2126 * c[0] + 0.7152 * c[1] + 0.0722 * c[2]; };\nconst ratio = (a, b) => { const [x, y] = [L(a), L(b)].sort((m, n) => n - m); return (x + 0.05) / (y + 0.05); };\n```\n\n### 5.2 The 8-point grid\n\nValues are checked in px at the default 16 px root (`0.5rem` = 8 px).\n\n| What | Rule |\n|---|---|\n| Spacing (padding, margin, gap) | Multiples of 8: `8 16 24 32 48 64 96 128`. **4 px** is the only half-step, and only inside small components (chip padding, icon-to-label gap) |\n| Component sizes | Heights and fixed widths are multiples of 8. Buttons, nav items and inputs are **48 px** tall minimum |\n| Radii | `8 16 24 32`, or `999px` for pills. 4 px only on elements under 32 px tall |\n| Line heights | Fixed-size text: multiples of 8 (16/24, 18/32, 24/32), or of 4 for text ≤ 14 px (12/16, 14/20). Fluid headings (`clamp()` sizes) use a unitless line-height (1.0–1.2) and are exempt, because their line box can't stay on the grid at every size |\n| Fluid spacing | `clamp()` for spacing or sizes uses grid values at both ends. Fluid **font sizes** are exempt |\n| Shadow offsets | 4 or 8 multiples |\n| Layout | Content width, gutters and breakpoints are multiples of 8 (e.g. `1200`, `768`, `1024`, `1280`) |\n| Exempt | Border and outline widths (1–4 px), focus offset, font sizes, the `999px` pill radius, the 4-multiple line heights above, and anything that isn't a length (angles like a `-2deg` tilt, durations, opacity) |\n\nEvery value in the **Tokens** block must pass this table.\n\n### 5.3 WCAG 2.2 AA — what the design must decide\n\nThese criteria are settled at design time. Write each answer into the **Accessibility** section of\n`design.md`.\n\n| Criterion | The design must specify |\n|---|---|\n| 1.4.1 Use of colour | Links in running text are underlined, not colour-only. States (active nav, selected, error) also change shape, weight or an icon, not only colour |\n| 1.4.4 Resize text | Font sizes in `rem`; nothing breaks at 200 % zoom |\n| 1.4.10 Reflow | Works at **320 CSS px** wide with no horizontal scroll. Every component has a stated ≤ 320 px behaviour; decorative pieces never widen the page |\n| 1.4.12 Text spacing | No fixed-height boxes around text, so nothing clips when a user overrides spacing (line-height 1.5, paragraph spacing 2×, letter-spacing 0.12 em, word-spacing 0.16 em). Fixed line-height tokens are fine; clipping is not |\n| 2.2.2 Pause, Stop, Hide | Anything that moves on its own for more than 5 s (marquee, carousel, animated sticker) has a **visible pause control**, and doesn't move at all under `prefers-reduced-motion`. Hover-to-pause alone doesn't count |\n| 2.3.1 Three flashes | Nothing flashes more than 3 times a second |\n| 2.4.7 Focus visible | One focus style (e.g. 3 px outline, 2 px offset) whose colour reaches 3:1 against **every** surface it can appear on. Name a second colour for surfaces where the first fails |\n| 2.4.11 Focus not obscured *(new in 2.2)* | Sticky headers, cookie bars and chat bubbles never cover the focused element. Either the header isn't sticky, or `scroll-padding-top: var(--header-h)` |\n| 2.5.8 Target size *(new in 2.2)* | Interactive targets ≥ 24 × 24 px with spacing. On this grid: **48 px** for buttons, nav and inputs, ≥ 24 px for inline icon buttons |\n| 3.2.6 Consistent help *(new in 2.2)* | The contact or help link sits in the same place on every page (e.g. last nav item and footer) |\n| 3.3.2 Labels | Every form field has a visible label; placeholders are never the only label |\n| 1.1.1 Text alternatives | Content images get alt text describing what they show; purely decorative images and shapes get empty alt or `aria-hidden` |\n\n### 5.4 Fonts resolve\n\nFor each family, prefer the variable package and fall back to the static one:\n`npm view @fontsource-variable/<slug> version`, then `npm view @fontsource/<slug> version`. One must\nanswer with a version. If neither does, swap to the closest family that does. Record the exact\npackage names.\n\n### 5.5 The header fits on one line\n\nThe header is where a cramped width shows first: the logo, every nav item and the call-to-action\nbutton share one row, and when they run out of room they wrap mid-phrase (\"Services &\" over\n\"Pricing\", \"Book\" over \"Appointment\"). That always looks broken. Decide it here so the frontend\ncan't build it that way.\n\n- **Labels never break mid-phrase.** Nav links and the header button get `white-space: nowrap`, so a\n  two-word label stays on one line or not at all.\n- **Collapse before it wraps — not at 320 px.** The inline nav is replaced by a menu (hamburger)\n  button at the width where the logo, all nav items and the button stop fitting on one line, which is\n  usually wider than the mobile breakpoint. Estimate that width from the number of nav items and their\n  label lengths, round up to a multiple of 8, and make it the header's own breakpoint. Below it, only\n  the logo and the menu button show; the nav items and the CTA move into the opened menu. At 320 px\n  the icon, the site name (`--text-logo`, `white-space: nowrap`) and the menu button still fit one\n  row; lower `--text-logo` for a long name until they do. A supplied or kept logo and the menu\n  button must fit too; lower `--logo-h` (still ≥ 24 px) until they do.\n- **Keep header labels short.** A nav label is one or two short words; a button label is a two-word\n  verb phrase at most (\"Book now\", not \"Book an Appointment\"). When the content model gives a long\n  navigation label, the header may show a shorter form (\"Contact & Booking\" → \"Contact\") while the\n  page keeps its full name — note the shortened label in the **Header + nav** row.\n- Record the header breakpoint in *Grid, shape & motion* and the `nowrap` + collapse rule in the\n  **Header + nav** component row (and its `≤ 320 px` cell).\n\n## Step 6 — Draw the logo\n\n**The user supplied a logo** → copy it into `brand/` unchanged, note it in the **Logo** section, and\nskip the rest of this step. Never redraw or recolour it.\n\nOtherwise the logo is the brief's **Site name**, spelled as the user confirmed it, as text in the\ndisplay font, beside one small icon. Write the icon by hand as `brand/logo-mark.svg`: the chosen\ndirection's **logo idea** (or the owner's logo wish, Step 4) in palette colours, simple enough to\nread at 16 px on light and dark tab bars, because it is also the favicon. Give it a `viewBox` and\nno text inside: the name beside it is the text. No emoji or raster clip-art.\n\nKeep it quick: a few minutes, no installs, build scripts or preview loops.\n\nDon't show the logo to the user in this step; they see it in the preview.\n\n## Step 7 — Write `design.md` and hand off\n\nWrite `design.md` from the template below. Fill every section. The **Tokens** block is copied\nverbatim into the frontend's global stylesheet, so it must be valid CSS. Every colour, font, type\nsize, line height, space, radius and shadow used elsewhere in the file must exist in it as a token.\nThe template's token list is the **minimum**: add what the design needs (`--color-error`,\n`--color-on-accent`, `--leading-h3`…) under the same naming scheme.\n**Breakpoints are the one exception**: CSS custom properties don't work inside `@media`, so they are\nlisted in *Grid, shape & motion* as plain px values.\n\nThen update `state.json`: set `\"stage\": \"frontend\"` (also for a redesign: restyle, then validate and\ndeploy) and `updated_at` to the current UTC time (ISO 8601). Don't touch `provision` or add\nother keys.\n\nIf content prepare hasn't sourced images yet, it now follows `design.md` → **Imagery** (see\n`04-content-model/SKILL.md`).\n\nHand off in one or two plain sentences, as *Talk like a person* says: \"The look is set: warm cream,\nbrown lettering, berry buttons and your loaf logo.\" Nothing after it: no font names, file names or\nstages, and gaps such as a missing icon file or a font that may not load go in the final report.\n\n## `design.md` template\n\n````markdown\n# Design — <domain>\n\n> Direction **<name>**, selected on <YYYY-MM-DD> from three options (others offered: <B name>,\n> <C name>). <\"Picked by the user.\" | \"User said 'you decide'; recommendation A used.\" |\n> \"Merged by the user: <what>.\"> — or, when kept: \"Kept the owner's current look from <site URL |\n> screenshots | brand guide>, confirmed on <YYYY-MM-DD>.\"\n\n## Direction\n<2–3 sentences: the mood, what it borrows from the references (and any brief/reference mismatch),\nthe signature element.>\n\n## Stack\n**<chosen by the frontend step>** — design doesn't decide the stack. The frontend step (06) picks and\nconfirms the framework (default Next.js SSR; ecommerce must be SSR) and records it in\n`state.json → frontend`. Leave this as a placeholder for the frontend step to fill in.\n\n## Tokens\n```css\n:root {\n  /* colour — semantic names, never \"--pink-2\" */\n  --color-base: #…;      --color-text: #…;      --color-surface: #…;    --color-muted: #…;\n  --color-primary: #…;   --color-accent-1: #…;  --color-accent-2: #…;   --color-link: #…;\n  --color-focus: #…;     --color-focus-alt: #…; /* for surfaces where --color-focus is < 3:1 */\n  /* type */\n  --font-display: '<Family> Variable', <fallback stack>;\n  --font-body: '<Family> Variable', <fallback stack>;\n  --text-body: …rem;   --leading-body: …rem;    /* 8-multiple in px */\n  --text-small: …rem;  --leading-small: …rem;   /* 4-multiple in px */\n  --text-h1: clamp(…rem, …, …rem);  --text-h2: clamp(…);  --text-h3: …rem;\n  --leading-display: 1.05;          /* unitless; fluid headings are grid-exempt */\n  /* 8-point grid */\n  --space-half: 4px;  --space-1: 8px;   --space-2: 16px;  --space-3: 24px;  --space-4: 32px;\n  --space-6: 48px;    --space-8: 64px;  --space-12: 96px; --space-16: 128px;\n  --target-min: 48px;\n  /* shape */\n  --radius-sm: 8px;  --radius-card: …;  --radius-pill: 999px;\n  --border: …;  --shadow: …;  --shadow-hover: …;\n  --focus-ring: 3px solid var(--color-focus);  --focus-offset: 2px;\n  /* layout */\n  --content-max: …px;  /* multiple of 8 */\n  --header-h: …px;     /* header band height, multiple of 8; scroll-padding-top uses it if sticky */\n  --logo-h: …px;       /* header icon (or supplied logo) height, multiple of 8, ≥ 24 */\n  --text-logo: …rem;   /* site name beside the icon; icon + name + menu button fit at 320 px */\n}\n```\n\n## Palette roles\n| Token | Hex | Used for |\n|---|---|---|\n\n## Contrast\n| Foreground | Background | Kind (body text / large text / non-text) | Ratio | Needs | Passes |\n|---|---|---|---|---|---|\n\n## Type\n- **Display:** <family> (`@fontsource-variable/<slug>@<version>`), weights …, tracking …; sizes `--text-h1…h3`, `--leading-display`\n- **Body:** <family> (`@fontsource-variable/<slug>@<version>`); `--text-body` / `--leading-body`, measure ≤ 68ch\n\n## Logo\n- **Concept:** <what the icon shows, plus \"From the owner: '<their words>'\" only when it follows\n  their wish | \"Supplied by the user\" | \"Kept from <source>\" | \"No logo: owner kept the current look\"\n  (header shows the site name as text in `--font-display`)>\n- **Files:** `brand/logo-mark.svg` (header icon at `--logo-h`, and the favicon)\n- **Use:** the frontend copies `brand/` into `public/`. Header: `<a href=\"/\"><img src=\"/logo-mark.svg\"\n  alt=\"\" style=\"height: var(--logo-h)\"><Site name></a>`, the name as text in `--font-display`, so\n  the link's accessible name is the site name. Favicon: `<link rel=\"icon\" href=\"/logo-mark.svg\"\n  type=\"image/svg+xml\">`. A supplied or kept logo goes in the link alone, as\n  `<img src=\"/<file>\" alt=\"<Site name>\" style=\"height: var(--logo-h)\">`, with its own favicon if one\n  was supplied or kept, else the browser default.\n- **Don't:** recolour or stretch the icon, or replace the name text with an image of it.\n\n## Grid, shape & motion\n<section padding desktop/mobile (space tokens), gutters, breakpoints in px (multiples of 8), borders,\nradii, shadows, hover behaviour, every animation and its pause control, and \"no motion under\nprefers-reduced-motion\".>\n\n## Accessibility (WCAG 2.2 AA)\n- **Focus:** <style; which colour on which surface>\n- **Targets:** <48 px controls; inline exceptions>\n- **Links & states:** <underline rule; how active/error states differ beyond colour>\n- **Motion:** <what moves, where its pause control is>\n- **Sticky elements:** <none | header uses --header-h + scroll-padding-top>\n- **Help:** <where the contact link sits on every page>\n- **Text on images:** <none | scrim spec and resulting ratio>\n- **Reflow:** <anything special at 320 px>\n- **Exempt from contrast:** <disabled controls / decorative shapes, named>\n\n## Components\n| Component | Renders (from content model) | Look | ≤ 320 px |\n|---|---|---|---|\n| Header + nav | Navigation items | … Nav links and the button never wrap (`white-space: nowrap`); the inline nav collapses to a menu button at <px> (the width it stops fitting one line). | Logo + menu button only; nav items and CTA inside the menu |\n| Post card | Article: image, category, title, excerpt | … | … |\n| … | | | |\n\n## Page composition\n- **<Page>** — <sections top to bottom, each naming its component and band colour>\n- …\n\n## Imagery\n<subjects, mood and colour fit for photos; search keywords; treatment (frame, crop ratio, radius,\nduotone…); alt text written from what the photo shows.>\n\n## Don'ts\n- <3–6 site-specific rules, e.g. \"no grey cards\", \"never put body text on the primary accent\">\n````\n\n## Invariants\n\n- **One question.** Refine owns discovery; this step only chooses among directions (or keeps the\n  existing look).\n- **8-point grid, always.** No spacing, size, radius or breakpoint off the grid except the listed\n  exemptions.\n- **WCAG 2.2 AA is the floor.** No direction is offered, chosen or written that fails it. Brand\n  colours keep their hue but only appear in roles where they pass.\n- **The header never wraps.** Nav labels and the header button stay on one line (`white-space:\n  nowrap`); the inline nav collapses to a menu button at the width it stops fitting, not only at the\n  mobile breakpoint (5.5).\n- **Brand assets are fixed.** A supplied logo, colour or font appears in every direction, unchanged.\n- **The logo is the name plus a simple icon.** The site name as text in the display font beside a\n  small hand-written SVG icon that is also the favicon, or a supplied or kept logo unchanged. No\n  emoji or raster clip-art. A kept look with no logo shows the name as text and gets no icon.\n- **Self-hosted fonts only** (`@fontsource`). No Google Fonts or other font CDN links in the output.\n- **The tokens block is the only source of values** (breakpoints excepted). Components and pages\n  reference tokens, never raw hex codes, pixel values or font names.\n- **No backend calls.** Design never waits on provision and never writes to the instance.\n- **Never overwrite an existing `design.md` silently.** Keep or change, as in Step 1.\n"
       },
       {
         "uri": "skill://hostinger-headless/steps/06-frontend/SKILL.md",
-        "digest": "sha256:3f8eef1d5cf6057798c6c95d4b0b13a3ba3f08ac36e4c93428248b196134c123",
-        "size": 14939,
+        "digest": "sha256:9bb68eb2f7a72ccb553fb0565e03c405e1b8c86078264e1b9521ebb586c52d3f",
+        "size": 14972,
         "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 under Build mode \"Bring your own frontend\"** (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. An existing app under **Build mode \"Agent\n>   designs and builds\"** takes this shape too, but starts from its source: copy the project at\n>   `brief.md` → **Existing project** into `~/.hostinger/<domain>/src/`, keep its framework, screens,\n>   features and data wiring, and rebuild its UI to `design.md` instead of scaffolding a new project.\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), including\n  one rebuilt under **Agent designs and builds**; 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  - **Decode WordPress text.** WordPress returns titles and names HTML-encoded (`Tea &#038; Cake`,\n    `don&#8217;t`). Add the `entities` package and, in the one data module, run every title, name\n    and SEO field you render as plain text (posts, pages, terms, Yoast, Store API products and\n    categories) through `decodeHTML` once; strip an excerpt's tags first if you show it as text.\n    Leave HTML fields (`content.rendered`, an excerpt shown as HTML) as they are, and never inject a\n    decoded field as raw HTML.\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"
+        "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 under Build mode \"Bring your own frontend\"** (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. An existing app under **Build mode \"Agent\n>   designs and builds\"** takes this shape too, but starts from its source: copy the project at\n>   `brief.md` → **Existing project** into `~/.hostinger/<domain>/src/`, keep its framework, screens,\n>   features and data wiring, and rebuild its UI to `design.md` instead of scaffolding a new project.\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), including\n  one rebuilt under **Agent designs and builds**; 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- Build the **logo** and favicon exactly as `design.md` → **Logo** → *Use* says; never recolour or redraw\n  what is in `brand/`.\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  - **Decode WordPress text.** WordPress returns titles and names HTML-encoded (`Tea &#038; Cake`,\n    `don&#8217;t`). Add the `entities` package and, in the one data module, run every title, name\n    and SEO field you render as plain text (posts, pages, terms, Yoast, Store API products and\n    categories) through `decodeHTML` once; strip an excerpt's tags first if you show it as text.\n    Leave HTML fields (`content.rendered`, an excerpt shown as HTML) as they are, and never inject a\n    decoded field as raw HTML.\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",
@@ -267,10 +260,10 @@ const skills: Skill[] = [
       },
       {
         "uri": "skill://hostinger-headless/steps/09-done/SKILL.md",
-        "digest": "sha256:896b76e2a90868df56a36d59010b18c4944cfca93233847b3e041c436e154bfa",
-        "size": 13831,
+        "digest": "sha256:d25373a65a889f1a170294f37fce4d2bbf11aeb14d7cff63f126a867b5c480ed",
+        "size": 13817,
         "mimeType": "text/markdown",
-        "text": "---\nname: headless-step-done\ndescription: \"Step 9 (done) of the Hostinger Headless flow. Verifies the live site, then hands over the URLs (hPanel success page, main site, WordPress/store admin, dashboard), opens the success page in the browser on a successful run, and gives a summary of what was built plus explicit next steps — how to log in to wp-admin and reset the password, how to manage content, and how to finish WooCommerce/store setup so it can take orders. Its final report format is also used whenever a run stops early.\"\n---\n\n# headless-step-done\n\nVerify the live site, then hand over the URLs (success page, main site, WordPress admin, dashboard), a\nsummary of what was built, and what the user can do next. **On a successful run, open the success page\nfor the user** (see *Open the success page*).\n\n## Final report\n\nEvery run ends with this report, whether it finishes here or stops at an earlier stage (a dummy or\nmissing step, a failed provision, the user pausing). On a run that deployed this session, run the\nchecks in *Verify the live site* below first. Build the report from `state.json`, `site.json`,\n`deploy.json` and what you actually did and checked in this run. Report only what you verified. Don't\nclaim a stage passed if you didn't check it.\n\nWrite it in this order:\n\n1. **One-paragraph outcome.** What was created and on which domain (bold it). If the run stopped\n   early, name the stage it stopped at, why, and what the user will see right now (e.g. \"the site\n   root returns 403 until the frontend is deployed\").\n\n2. **Steps completed.** This table is required on every run, including early stops: never replace\n   it with prose. Give one row per stage that ran, using the stage numbers and names from the\n   orchestrator's flow table. Leave out stages that didn't run and name them in the outcome\n   paragraph instead. A finished WordPress blog build looks like this:\n\n   | Stage | Result |\n   |---|---|\n   | connect | Hostinger connector reached over MCP (`@hostinger/mcp` 1.9.2); signed in through the browser login. |\n   | 1 check state | New build for `harbourlight.blog`; no earlier workspace. |\n   | 2 refine | Personal travel blog about coastal towns in the UK; backend: WordPress. |\n   | 3 provision | Business plan, order 41875230; setup took 6 min; domain, SSL and WordPress checks passed. |\n   | 4 content model | 5 pages, 8 posts, 6 categories, 1 menu, 14 images (Hostinger AI), SEO titles on every page; counts re-read from the REST API. |\n   | 5 design | \"Salt & Ink\" direction: serif headings, sea-blue accents; `design.md` and logo written, logo check passed. |\n   | 6 frontend | Next.js SSR with home, blog, post, category and contact pages wired to the REST API; local build passed. |\n   | 7 validate | Instance setup completed; REST API returned the 8 pushed posts; no preview (nobody signing off). |\n   | 8 deploy | Source uploaded, build finished in 3 min; site root returns 200. |\n   | 9 done | Main site, wp-admin and REST API re-checked live: all returned 200. |\n\n3. **Links** — every URL that exists at this point. Build the hPanel URLs from `site.json`\n   (`order_id`, `username`, `domain`) and the onboarding slug; take the rest from `site.json` /\n   `deploy.json`. Lead with the one the user cares about most — the **main site** — then the admin\n   and dashboards. **Don't list the success page here:** it opens on its own (see *Open the success\n   page*), so printing its URL in the report is just noise — the only exception is when a browser\n   can't be opened (handled in that section):\n\n   - **Main site (live):** `urls.site` (`https://<domain>`) — only once deployed.\n   - **WordPress admin (one-click auto-login):** for a WordPress backend, **mint and hand over the\n     auto-login redirect URL** — `wordpress_login_create-links { username, software: <site.json\n     wordpress.install_id> }` returns a temporary link that logs the user straight into wp-admin. Give\n     that URL as the admin link (it lands on `/cms/wp-admin`), so the user never needs a password.\n     Alongside it, give the two ways back in that don't expire: the **login URL `{urls.wp_admin}`**\n     (`https://<domain>/cms/wp-admin` — the headless WordPress lives under `/cms`), and the **WP Admin\n     button in hPanel** (hPanel → the website → *WP Admin*). Note how to **reset the password**: on the\n     `/cms/wp-admin` login screen use **\"Lost your password?\"**, and WordPress emails a reset link to the\n     **WordPress admin email** (the address set at install, which the owner already has) — see *Next\n     steps* for an optional deliverability tip.\n     **Never print or store a password.** For a **WordPress + WooCommerce** store, this *same* wp-admin\n     login is the store admin (wp-admin → WooCommerce → Products/Orders) — do **not** use the Ecommerce\n     `store_admin` path; the store setup the owner still needs is spelled out under *Next steps*. For a\n     Hostinger **Ecommerce** store, link the store admin from `urls.store_admin` instead.\n   - **hPanel site dashboard:** `https://hpanel.hostinger.com/websites/<domain>` (the headless website\n     is installed by now).\n   - **Onboarding (resume):** `https://hpanel.hostinger.com/headless-onboarding/<order_id>/<username>/`\n   - **REST API** (for developers): `urls.rest_api`.\n\n   > URL shape note: `<username>` may be dropped from the onboarding/success URLs in a future hPanel\n   > release. If a built URL 404s, retry the same path without the `/<username>` segment before\n   > reporting it as broken.\n\n4. **Next steps** — what the user does now to actually use the site. Required on a successful run;\n   tailor the bullets to the backend and keep them concrete. This is the hand-holding the hPanel\n   success page can't give: don't just link wp-admin, tell them what to do once they're in.\n\n   - **Manage content (WordPress):** in wp-admin (the one-click link, the `/cms/wp-admin` login URL, or\n     hPanel → *WP Admin*) → **Posts**, **Pages**, **Media**, **Appearance → Menus**. Say how edits reach\n     the live site for *this* build: an **SSR** frontend re-reads the REST API each request, so changes\n     show up with no redeploy; an **SSG/static** build must be redeployed to pick up new content (read\n     `state.json → frontend.rendering`).\n   - **Log in later & reset the password:** repeat the two non-expiring routes (the `/cms/wp-admin` login\n     URL and hPanel's *WP Admin* button) and the **\"Lost your password?\"** reset. The reset link goes to\n     the **WordPress admin email** — the address set at install, which the owner already has — so nothing\n     extra is needed to receive it. Optionally, for more reliable delivery, they can create a mailbox on\n     the domain (hPanel → *Emails*) and set it as the admin address in **wp-admin → Settings → General**.\n   - **WordPress + WooCommerce — finish store setup so it can take orders.** The catalog and cart already\n     work, but **checkout stays off until the owner configures it in wp-admin**: WooCommerce → Settings →\n     **Payments** (enable at least one method) and → **Shipping** (add a zone with a rate), then confirm\n     products/prices and place a test order. When `site.json → woocommerce.payment_enabled` is `false`,\n     state plainly that this step is **required before any purchase works** — this is the gap owners hit.\n   - **Hostinger Ecommerce store:** when `site.json → ecommerce.payment_enabled` is `false`, finish\n     payment setup in the store admin (`urls.store_admin`) before the storefront can sell; otherwise it's\n     ready to take orders.\n   - **Webapp:** manage the app from hPanel → the website (environment variables, deployments, logs).\n\n5. **Where state lives** — the workspace path `~/.hostinger/<domain>/`, the `stage` that a\n   resumed run will start from, and the build report `~/.hostinger/<domain>/report.html`.\n\n6. **Gaps / follow-ups** (only if any) — a short numbered list of anything skipped, approximated or\n   left for the user (e.g. no images generated, default WordPress content left in place).\n\nNever include passwords, JWTs or other secrets in the report. For wp-admin access, give the URL and\noffer a one-click login link (`wordpress_login_create-links`), not credentials.\n\n## Verify the live site (brief)\n\nOn a run that deployed this session, re-confirm what you're about to hand over actually works (deploy\nalready checked this — this is a quick re-confirm, not a full re-run):\n\n- **Main site:** `GET https://<domain>/` → 200 (Next.js SSR: `x-powered-by: Next.js`; Astro SSG: static\n  HTML with real content).\n- **WordPress admin:** `GET {urls.wp_admin}` → reachable (a login page, 200/302), not 404.\n- **Backend API:** `GET {urls.rest_api}/posts?per_page=1` → 200 (WordPress); for a **WooCommerce** store\n  (`site.json → woocommerce.enabled`) also `GET {urls.store_api}/products?per_page=1` → 200; or the\n  storefront API for the sales channel → 200 (Ecommerce).\n- **Contact form** (`site.json → contact_form.enabled`): validate already sent a test submission, so\n  don't send another here. In the handover, tell the owner the contact page is live and enquiries email\n  the **WordPress admin address** (via `wp_mail`) — and that for the most reliable delivery that address\n  should be a Hostinger mailbox on the domain. If validate reported `mail_failed`, say so plainly instead\n  of claiming the form sends.\n\nIf a check fails, say so in the outcome paragraph and don't claim the site is live.\n\n## Open the success page\n\nOn a **successful** run (the deploy succeeded and the live checks passed), open the success page in the\nuser's **main / system browser** right after presenting the report, so they land on the hPanel\ncelebration/next-steps screen for their new site. This is a side effect only — **don't print the\nsuccess URL in the report output** (it just opens); the one exception is the can't-open-a-browser\nfallback below. Build the URL with `<tool>` as the running tool's onboarding slug (see *State and\nartifacts* in the top-level `SKILL.md`):\n\n```bash\n# Build the URL first, then open it with the OS default (main) browser — not an embedded one.\n# <tool> = the onboarding slug\nURL=\"https://hpanel.hostinger.com/headless-onboarding/<order_id>/<username>/success/<domain>/<tool>\"\nopen \"$URL\"        # macOS\n# xdg-open \"$URL\"  # Linux\n# start \"\" \"$URL\"  # Windows\n```\n\n- **Main browser only.** Use the OS opener above (`open` / `xdg-open` / `start`) so the page lands in\n  Chrome, Safari, Edge, or whatever the user actually uses. **Do not** open it in an embedded or\n  sandboxed browser (Cursor IDE browser / `cursor-ide-browser`, Playwright, Puppeteer, WebView, or\n  any in-agent browser tab). Those stay inside the tool session and the user won't see the\n  celebration page where they expect it.\n- Open it **once**, and only on a successful run — never on an early stop or a failed deploy.\n- If your tool can't open a browser (the command isn't available, or `open`/`xdg-open`/`start`\n  fails), don't treat it as a failure and **don't fall back to an embedded browser**. This is the\n  **one** case where you print the success URL — show it once in the report and tell the user to\n  open it themselves in their main browser.\n\n## Build report\n\nRight after the final report, save the build report for this run. It turns the run log (stage times\nfrom `run-log.json`, events from `events.jsonl`) into `reports/<run>.json` and `.html`, and copies the\nHTML to `report.html` in the workspace:\n\n```bash\nnode <skill>/run-log.mjs <domain> event good '{\"text\":\"<something that went well>\"}'   # one per thing, if not logged yet\nnode <skill>/run-log.mjs <domain> stage-end done ok\nnode <skill>/run-log.mjs <domain> report --outcome <live|stopped|failed> [--tokens '<json>']\n```\n\nThen send it to Hostinger: pass `reports/<run>.json` unchanged to `hosting_headless_submit-build-report`\nand run `report-sent <run>` (or `report-rejected <run>` on a 422). The `report` command prints the\nexact path and run id. Don't ask first; see *Run log and build report* in the top-level `SKILL.md`\nfor failures. Then tell the user in one line: \"Sent the build report to Hostinger to help improve\nthe flow.\" On a 422 say it's saved locally only; on any other failure say it'll be sent next session.\n\nIf the user asks for more changes after this report in the same session, call\n`run-log.mjs <domain> run-resume --reason \"<what they asked for>\"` before the work. Then log as\nusual and run `report` again when it's done. It updates this run's report in place, and the report\nlists the follow-up. Send the updated report the same way.\n\n- **Outcome:** `live` when the deploy succeeded this run, `failed` when a stage failed and you\n  couldn't recover, `stopped` for everything else (the user paused, a dummy or missing step). Leave\n  `--outcome` out and the script decides from the log.\n- **Before you write it,** check that every issue, correction and skill gap from this run is in\n  `events.jsonl`. Log any that are missing now; the report only shows what was logged.\n- **After you write it,** read the `warning:` lines `report` prints. They list logging gaps: a stage\n  that never ended, a start that was estimated, a stage logged with no duration, or (on a live build)\n  a stage that was never logged. Fix what you can: `stage-end` an open stage, or correct a start with\n  `stage-fix <stage> --started-ago <time>`, then run `report` again. What you can't fix stays in the report's\n  *Logging gaps* section.\n- **Tokens:** only what your tool tells you about your own usage (see *Run log and build report* in\n  the top-level `SKILL.md`).\n- In the final report's *Where state lives*, add the path to `report.html` so the user can open it.\n\nDo this on every run, including the early stops: those reports are the most useful ones.\n"
+        "text": "---\nname: headless-step-done\ndescription: \"Step 9 (done) of the Hostinger Headless flow. Verifies the live site, then hands over the URLs (hPanel success page, main site, WordPress/store admin, dashboard), opens the success page in the browser on a successful run, and gives a summary of what was built plus explicit next steps — how to log in to wp-admin and reset the password, how to manage content, and how to finish WooCommerce/store setup so it can take orders. Its final report format is also used whenever a run stops early.\"\n---\n\n# headless-step-done\n\nVerify the live site, then hand over the URLs (success page, main site, WordPress admin, dashboard), a\nsummary of what was built, and what the user can do next. **On a successful run, open the success page\nfor the user** (see *Open the success page*).\n\n## Final report\n\nEvery run ends with this report, whether it finishes here or stops at an earlier stage (a dummy or\nmissing step, a failed provision, the user pausing). On a run that deployed this session, run the\nchecks in *Verify the live site* below first. Build the report from `state.json`, `site.json`,\n`deploy.json` and what you actually did and checked in this run. Report only what you verified. Don't\nclaim a stage passed if you didn't check it.\n\nWrite it in this order:\n\n1. **One-paragraph outcome.** What was created and on which domain (bold it). If the run stopped\n   early, name the stage it stopped at, why, and what the user will see right now (e.g. \"the site\n   root returns 403 until the frontend is deployed\").\n\n2. **Steps completed.** This table is required on every run, including early stops: never replace\n   it with prose. Give one row per stage that ran, using the stage numbers and names from the\n   orchestrator's flow table. Leave out stages that didn't run and name them in the outcome\n   paragraph instead. A finished WordPress blog build looks like this:\n\n   | Stage | Result |\n   |---|---|\n   | connect | Hostinger connector reached over MCP (`@hostinger/mcp` 1.9.2); signed in through the browser login. |\n   | 1 check state | New build for `harbourlight.blog`; no earlier workspace. |\n   | 2 refine | Personal travel blog about coastal towns in the UK; backend: WordPress. |\n   | 3 provision | Business plan, order 41875230; setup took 6 min; domain, SSL and WordPress checks passed. |\n   | 4 content model | 5 pages, 8 posts, 6 categories, 1 menu, 14 images (Hostinger AI), SEO titles on every page; counts re-read from the REST API. |\n   | 5 design | \"Salt & Ink\" direction: serif headings, sea-blue accents; `design.md` and logo icon written. |\n   | 6 frontend | Next.js SSR with home, blog, post, category and contact pages wired to the REST API; local build passed. |\n   | 7 validate | Instance setup completed; REST API returned the 8 pushed posts; no preview (nobody signing off). |\n   | 8 deploy | Source uploaded, build finished in 3 min; site root returns 200. |\n   | 9 done | Main site, wp-admin and REST API re-checked live: all returned 200. |\n\n3. **Links** — every URL that exists at this point. Build the hPanel URLs from `site.json`\n   (`order_id`, `username`, `domain`) and the onboarding slug; take the rest from `site.json` /\n   `deploy.json`. Lead with the one the user cares about most — the **main site** — then the admin\n   and dashboards. **Don't list the success page here:** it opens on its own (see *Open the success\n   page*), so printing its URL in the report is just noise — the only exception is when a browser\n   can't be opened (handled in that section):\n\n   - **Main site (live):** `urls.site` (`https://<domain>`) — only once deployed.\n   - **WordPress admin (one-click auto-login):** for a WordPress backend, **mint and hand over the\n     auto-login redirect URL** — `wordpress_login_create-links { username, software: <site.json\n     wordpress.install_id> }` returns a temporary link that logs the user straight into wp-admin. Give\n     that URL as the admin link (it lands on `/cms/wp-admin`), so the user never needs a password.\n     Alongside it, give the two ways back in that don't expire: the **login URL `{urls.wp_admin}`**\n     (`https://<domain>/cms/wp-admin` — the headless WordPress lives under `/cms`), and the **WP Admin\n     button in hPanel** (hPanel → the website → *WP Admin*). Note how to **reset the password**: on the\n     `/cms/wp-admin` login screen use **\"Lost your password?\"**, and WordPress emails a reset link to the\n     **WordPress admin email** (the address set at install, which the owner already has) — see *Next\n     steps* for an optional deliverability tip.\n     **Never print or store a password.** For a **WordPress + WooCommerce** store, this *same* wp-admin\n     login is the store admin (wp-admin → WooCommerce → Products/Orders) — do **not** use the Ecommerce\n     `store_admin` path; the store setup the owner still needs is spelled out under *Next steps*. For a\n     Hostinger **Ecommerce** store, link the store admin from `urls.store_admin` instead.\n   - **hPanel site dashboard:** `https://hpanel.hostinger.com/websites/<domain>` (the headless website\n     is installed by now).\n   - **Onboarding (resume):** `https://hpanel.hostinger.com/headless-onboarding/<order_id>/<username>/`\n   - **REST API** (for developers): `urls.rest_api`.\n\n   > URL shape note: `<username>` may be dropped from the onboarding/success URLs in a future hPanel\n   > release. If a built URL 404s, retry the same path without the `/<username>` segment before\n   > reporting it as broken.\n\n4. **Next steps** — what the user does now to actually use the site. Required on a successful run;\n   tailor the bullets to the backend and keep them concrete. This is the hand-holding the hPanel\n   success page can't give: don't just link wp-admin, tell them what to do once they're in.\n\n   - **Manage content (WordPress):** in wp-admin (the one-click link, the `/cms/wp-admin` login URL, or\n     hPanel → *WP Admin*) → **Posts**, **Pages**, **Media**, **Appearance → Menus**. Say how edits reach\n     the live site for *this* build: an **SSR** frontend re-reads the REST API each request, so changes\n     show up with no redeploy; an **SSG/static** build must be redeployed to pick up new content (read\n     `state.json → frontend.rendering`).\n   - **Log in later & reset the password:** repeat the two non-expiring routes (the `/cms/wp-admin` login\n     URL and hPanel's *WP Admin* button) and the **\"Lost your password?\"** reset. The reset link goes to\n     the **WordPress admin email** — the address set at install, which the owner already has — so nothing\n     extra is needed to receive it. Optionally, for more reliable delivery, they can create a mailbox on\n     the domain (hPanel → *Emails*) and set it as the admin address in **wp-admin → Settings → General**.\n   - **WordPress + WooCommerce — finish store setup so it can take orders.** The catalog and cart already\n     work, but **checkout stays off until the owner configures it in wp-admin**: WooCommerce → Settings →\n     **Payments** (enable at least one method) and → **Shipping** (add a zone with a rate), then confirm\n     products/prices and place a test order. When `site.json → woocommerce.payment_enabled` is `false`,\n     state plainly that this step is **required before any purchase works** — this is the gap owners hit.\n   - **Hostinger Ecommerce store:** when `site.json → ecommerce.payment_enabled` is `false`, finish\n     payment setup in the store admin (`urls.store_admin`) before the storefront can sell; otherwise it's\n     ready to take orders.\n   - **Webapp:** manage the app from hPanel → the website (environment variables, deployments, logs).\n\n5. **Where state lives** — the workspace path `~/.hostinger/<domain>/`, the `stage` that a\n   resumed run will start from, and the build report `~/.hostinger/<domain>/report.html`.\n\n6. **Gaps / follow-ups** (only if any) — a short numbered list of anything skipped, approximated or\n   left for the user (e.g. no images generated, default WordPress content left in place).\n\nNever include passwords, JWTs or other secrets in the report. For wp-admin access, give the URL and\noffer a one-click login link (`wordpress_login_create-links`), not credentials.\n\n## Verify the live site (brief)\n\nOn a run that deployed this session, re-confirm what you're about to hand over actually works (deploy\nalready checked this — this is a quick re-confirm, not a full re-run):\n\n- **Main site:** `GET https://<domain>/` → 200 (Next.js SSR: `x-powered-by: Next.js`; Astro SSG: static\n  HTML with real content).\n- **WordPress admin:** `GET {urls.wp_admin}` → reachable (a login page, 200/302), not 404.\n- **Backend API:** `GET {urls.rest_api}/posts?per_page=1` → 200 (WordPress); for a **WooCommerce** store\n  (`site.json → woocommerce.enabled`) also `GET {urls.store_api}/products?per_page=1` → 200; or the\n  storefront API for the sales channel → 200 (Ecommerce).\n- **Contact form** (`site.json → contact_form.enabled`): validate already sent a test submission, so\n  don't send another here. In the handover, tell the owner the contact page is live and enquiries email\n  the **WordPress admin address** (via `wp_mail`) — and that for the most reliable delivery that address\n  should be a Hostinger mailbox on the domain. If validate reported `mail_failed`, say so plainly instead\n  of claiming the form sends.\n\nIf a check fails, say so in the outcome paragraph and don't claim the site is live.\n\n## Open the success page\n\nOn a **successful** run (the deploy succeeded and the live checks passed), open the success page in the\nuser's **main / system browser** right after presenting the report, so they land on the hPanel\ncelebration/next-steps screen for their new site. This is a side effect only — **don't print the\nsuccess URL in the report output** (it just opens); the one exception is the can't-open-a-browser\nfallback below. Build the URL with `<tool>` as the running tool's onboarding slug (see *State and\nartifacts* in the top-level `SKILL.md`):\n\n```bash\n# Build the URL first, then open it with the OS default (main) browser — not an embedded one.\n# <tool> = the onboarding slug\nURL=\"https://hpanel.hostinger.com/headless-onboarding/<order_id>/<username>/success/<domain>/<tool>\"\nopen \"$URL\"        # macOS\n# xdg-open \"$URL\"  # Linux\n# start \"\" \"$URL\"  # Windows\n```\n\n- **Main browser only.** Use the OS opener above (`open` / `xdg-open` / `start`) so the page lands in\n  Chrome, Safari, Edge, or whatever the user actually uses. **Do not** open it in an embedded or\n  sandboxed browser (Cursor IDE browser / `cursor-ide-browser`, Playwright, Puppeteer, WebView, or\n  any in-agent browser tab). Those stay inside the tool session and the user won't see the\n  celebration page where they expect it.\n- Open it **once**, and only on a successful run — never on an early stop or a failed deploy.\n- If your tool can't open a browser (the command isn't available, or `open`/`xdg-open`/`start`\n  fails), don't treat it as a failure and **don't fall back to an embedded browser**. This is the\n  **one** case where you print the success URL — show it once in the report and tell the user to\n  open it themselves in their main browser.\n\n## Build report\n\nRight after the final report, save the build report for this run. It turns the run log (stage times\nfrom `run-log.json`, events from `events.jsonl`) into `reports/<run>.json` and `.html`, and copies the\nHTML to `report.html` in the workspace:\n\n```bash\nnode <skill>/run-log.mjs <domain> event good '{\"text\":\"<something that went well>\"}'   # one per thing, if not logged yet\nnode <skill>/run-log.mjs <domain> stage-end done ok\nnode <skill>/run-log.mjs <domain> report --outcome <live|stopped|failed> [--tokens '<json>']\n```\n\nThen send it to Hostinger: pass `reports/<run>.json` unchanged to `hosting_headless_submit-build-report`\nand run `report-sent <run>` (or `report-rejected <run>` on a 422). The `report` command prints the\nexact path and run id. Don't ask first; see *Run log and build report* in the top-level `SKILL.md`\nfor failures. Then tell the user in one line: \"Sent the build report to Hostinger to help improve\nthe flow.\" On a 422 say it's saved locally only; on any other failure say it'll be sent next session.\n\nIf the user asks for more changes after this report in the same session, call\n`run-log.mjs <domain> run-resume --reason \"<what they asked for>\"` before the work. Then log as\nusual and run `report` again when it's done. It updates this run's report in place, and the report\nlists the follow-up. Send the updated report the same way.\n\n- **Outcome:** `live` when the deploy succeeded this run, `failed` when a stage failed and you\n  couldn't recover, `stopped` for everything else (the user paused, a dummy or missing step). Leave\n  `--outcome` out and the script decides from the log.\n- **Before you write it,** check that every issue, correction and skill gap from this run is in\n  `events.jsonl`. Log any that are missing now; the report only shows what was logged.\n- **After you write it,** read the `warning:` lines `report` prints. They list logging gaps: a stage\n  that never ended, a start that was estimated, a stage logged with no duration, or (on a live build)\n  a stage that was never logged. Fix what you can: `stage-end` an open stage, or correct a start with\n  `stage-fix <stage> --started-ago <time>`, then run `report` again. What you can't fix stays in the report's\n  *Logging gaps* section.\n- **Tokens:** only what your tool tells you about your own usage (see *Run log and build report* in\n  the top-level `SKILL.md`).\n- In the final report's *Where state lives*, add the path to `report.html` so the user can open it.\n\nDo this on every run, including the early stops: those reports are the most useful ones.\n"
       }
     ]
   },

package/src/core/tools/all.js

@@ -6362,6 +6362,173 @@ export default [
     ],
     "group": "ecommerce"
   },
+  {
+    "name": "gpu_catalog_pool-groups",
+    "title": "Get pool groups",
+    "annotations": {
+      "title": "Get pool groups",
+      "readOnlyHint": true,
+      "destructiveHint": false
+    },
+    "description": "Retrieve GPU pool groups, ordered by name.\n\nEach group bundles the pools of one GPU model and lists its currently available pools,\nwhether any of them is available and the lowest hourly price among its instance types.\nThe price is returned even when the group is out of stock.\n\nUse this endpoint to show which GPU models can be ordered and from what price.",
+    "method": "GET",
+    "path": "/api/gpu/v1/pools/groups",
+    "inputSchema": {
+      "type": "object",
+      "properties": {
+        "currency": {
+          "type": "string",
+          "description": "Currency of the returned prices, `USD` by default",
+          "enum": [
+            "USD",
+            "ARS",
+            "AMD",
+            "AUD",
+            "AZN",
+            "BDT",
+            "BRL",
+            "BTC",
+            "BYN",
+            "CAD",
+            "CHF",
+            "CLP",
+            "CNY",
+            "COP",
+            "CZK",
+            "DKK",
+            "EGP",
+            "EUR",
+            "GBP",
+            "GEL",
+            "HKD",
+            "HRK",
+            "HUF",
+            "IDR",
+            "ILS",
+            "INR",
+            "JPY",
+            "KGS",
+            "KRW",
+            "KZT",
+            "MAD",
+            "MXN",
+            "MYR",
+            "NGN",
+            "NOK",
+            "NZD",
+            "PEN",
+            "PHP",
+            "PKR",
+            "PLN",
+            "SEK",
+            "SGD",
+            "THB",
+            "TJS",
+            "TRY",
+            "TWD",
+            "UAH",
+            "VND",
+            "ZAR"
+          ]
+        }
+      },
+      "required": []
+    },
+    "security": [
+      {
+        "apiToken": []
+      }
+    ],
+    "group": "gpu"
+  },
+  {
+    "name": "gpu_catalog_pool-instance-types",
+    "title": "Get pool instance types",
+    "annotations": {
+      "title": "Get pool instance types",
+      "readOnlyHint": true,
+      "destructiveHint": false
+    },
+    "description": "Retrieve the instance types offered by a specified GPU pool, ordered by CPU core count.\n\nEach instance type describes its CPU, memory and storage, and its hourly price.\nOnly instance types that can currently be ordered are returned.\n\nUse this endpoint to choose the `pool_instance_id` for a new GPU instance.",
+    "method": "GET",
+    "path": "/api/gpu/v1/pools/{poolId}/instances",
+    "inputSchema": {
+      "type": "object",
+      "properties": {
+        "poolId": {
+          "type": "integer",
+          "description": "GPU pool ID"
+        }
+      },
+      "required": [
+        "poolId"
+      ]
+    },
+    "security": [
+      {
+        "apiToken": []
+      }
+    ],
+    "group": "gpu"
+  },
+  {
+    "name": "gpu_catalog_pool-os-templates",
+    "title": "Get pool OS templates",
+    "annotations": {
+      "title": "Get pool OS templates",
+      "readOnlyHint": true,
+      "destructiveHint": false
+    },
+    "description": "Retrieve the OS templates that can be installed on a specified GPU pool instance type.\n\nUse this endpoint to choose the `os_template_id` for a new GPU instance.",
+    "method": "GET",
+    "path": "/api/gpu/v1/pools/{poolId}/instances/{poolInstanceId}/os-templates",
+    "inputSchema": {
+      "type": "object",
+      "properties": {
+        "poolId": {
+          "type": "integer",
+          "description": "GPU pool ID"
+        },
+        "poolInstanceId": {
+          "type": "integer",
+          "description": "GPU pool instance type ID"
+        }
+      },
+      "required": [
+        "poolId",
+        "poolInstanceId"
+      ]
+    },
+    "security": [
+      {
+        "apiToken": []
+      }
+    ],
+    "group": "gpu"
+  },
+  {
+    "name": "gpu_catalog_pool",
+    "title": "Get pool list",
+    "annotations": {
+      "title": "Get pool list",
+      "readOnlyHint": true,
+      "destructiveHint": false
+    },
+    "description": "Retrieve all available GPU pools, ordered by name.\n\nA pool serves GPU accelerators of one model from a single region.\n\nUse this endpoint to choose a pool before listing its instance types.",
+    "method": "GET",
+    "path": "/api/gpu/v1/pools",
+    "inputSchema": {
+      "type": "object",
+      "properties": {},
+      "required": []
+    },
+    "security": [
+      {
+        "apiToken": []
+      }
+    ],
+    "group": "gpu"
+  },
   {
     "name": "horizons_websites_clone",
     "title": "Clone website",