@typeroll/mcp-server 0.45.64 → 0.45.66

package/skills/tr-content-write.md

@@ -115,6 +115,22 @@ shortening, adding a CTA, tweaking SEO description.
 Don't `update_page status:"published"` without an explicit "looks
 good, publish it" from the user. Same for `trigger_deploy`.
 
+## Instead of the content workflows
+
+`start_workflow` types `content_generation` and `content_improvement` run the
+model with the Organization's own AI key. On a Site without that access they
+fail with `failure_code: "ai_not_enabled"`; don't retry them. Do the work with
+this recipe and tell the user you did it yourself:
+
+- **Generate a page** (`content_generation { topic, tone?, audience? }`):
+  steps 1–5 for that topic, created as a draft.
+- **Improve content** (`content_improvement { limit? }`): `list_pages
+  status="published"` and `batch_read_pages`, rank the pages by thin text,
+  missing `seo_title`/`seo_description` and age (not updated for a year), and
+  rewrite the weakest few (five by default) in the site's voice. Keep facts,
+  URLs and structure; leave the rewrites as unsaved drafts and show previews
+  before anything is saved or published.
+
 ## SEO conventions worth knowing
 
 - **`kind: "article"`** for blog posts and news. Switches to

package/skills/tr-edit-site.md

@@ -1,6 +1,6 @@
 ---
 name: tr-edit-site
-description: Edit or create Typeroll pages with a person’s usual AI assistant. Confirm one site, find the right page, preview changes and save with permission.
+description: Edit or create Typeroll pages with a person’s usual AI assistant. Confirm one site, find the right page, handle everyday requests (page links, images, menus, site-wide changes, settings, analytics, structured data), preview changes and save with permission.
 ---
 
 # Work on one Typeroll site
@@ -33,6 +33,93 @@ description: Edit or create Typeroll pages with a person’s usual AI assistant.
    draft durable; saving and deploying are different actions. Publish only
    when authorized and readiness passes. Report the actual result and URL.
 
+## Everyday requests
+
+Read the page or global block first, change only what was asked, and keep
+everything else. When several pages fit the description, ask before editing.
+
+**Addresses and preview links.** `list_pages` and `read_page` return each
+page's `url` (its path). The public address is `get_site` → `urls.production`
+plus that path, and it serves the page only after it is published and
+deployed. Never invent a domain; when there is none, say why and offer a
+preview instead: `get_preview_link page_id=… include_working_copy:true` shows
+drafts and unpublished pages. Mint one link and reuse it while iterating.
+
+**Images the user provides.** Upload first: a URL with `upload_media_from_url`,
+a local file with `create_upload_url` (see `tr-images`); `list_media` finds
+existing ones. Use the returned CDN URL exactly. With a named target, place it
+there (`add_block` with `core/image` on a block page; an `<img>` with `alt` in
+`html_content` on an HTML page). Without one, ask what the image is for. Ask
+for alt text when none was given. Afterwards say in one sentence where it
+landed; to answer "has it been added?", read the page again rather than
+trusting the conversation.
+
+**Small edits and new pages.** Block pages: `get_page_blocks`, then
+`update_block` on the one block. HTML pages: `read_page`, then `update_page`
+with the complete `html_content`, never a fragment. New pages: `create_page`
+(draft by default) with a realistic start: heading, introduction and one
+section. A Page template is `update_page` `template` (an allowed ID, or null
+for the content type default). `discard_working_copy` throws an unsaved draft
+away. Publishing means saving the draft, `update_page` `status: "published"`
+(applies immediately) and, when the user wants it live now, `trigger_deploy`.
+
+**Site-wide changes are composition, not a series of page edits.** "Change
+every hero", "a CTA on every product page", "our phone number in every
+footer":
+
+1. `list_partials` shows what is already shared: header, footer and free
+   global blocks.
+2. If a fitting global block exists, edit it once. Run
+   `find_pages_using_block` first and tell the user the blast radius ("this
+   block is on 8 pages and one template — go ahead?"); a header or footer
+   among the results means every page.
+3. If nothing fits, propose a global block: `make_block_global` turns an
+   existing block into one, or `create_free_block` with a kebab-case ID. Place
+   it with `core/global_block` on block pages or `<x-include name="…" />` on
+   HTML pages. Layout that every Page of a type shares belongs in its Page
+   template (`tr-page-template`).
+4. Edit pages one by one only for content that really differs per page, such
+   as each page's SEO description. Confirm the page list first.
+
+"All 23 pages" or "every page" is a strong hint for a global block. Say what
+you will do and wait for confirmation before editing many pages.
+
+**Extract while you sweep.** Even when the user asked for per-page edits,
+pause when the same content is about to land on a third page and offer to
+make it a global block instead ("I'm adding the same CTA to several pages —
+make it a reusable `newsletter-cta` block so future edits happen once?").
+Check `list_partials` and `find_pages_using_block` first so you extend an
+existing block rather than create a duplicate.
+
+**Menu and footer.** `read_partial partial_id="header"`. In a block header,
+change the `core/navigation` block's `links` with `update_block`; in an HTML
+header, add the `<a href="/pricing">Pricing</a>` to the nav and write back the
+complete HTML with `update_partial`. The footer works the same way. Building
+either from scratch: `tr-header-footer`.
+
+**Settings, not page edits.** Brand colors, fonts, logo, icons and contact
+details are `update_site_settings` (admin), for example `colors.primary`. A new
+logo must be uploaded first. Analytics, advertising pixels and chat widgets
+are set by ID in the Integrations app (`read_app app_id="integrations"`, then
+`update_app`), not pasted as scripts; turn on the cookie banner
+(`update_site_settings` `cookie_consent: { enabled: true }`) so they wait for
+consent. Only a tag the Integrations catalog lacks goes in
+`cookie_consent.scripts_optional`. Both reach the site with the next deploy.
+
+**Redirects, forms, listings.** A renamed URL gets `create_redirect` (301
+unless the user says otherwise); changing a page's `path` creates one on save.
+Place forms with a `core/form` block or `<x-form id="…" />`, never a
+hand-written `<form>` (`tr-forms`). Lists of articles are a `core/page_list`
+block, never hand-written HTML (`tr-blog`).
+
+**Structured data.** For an FAQ, recipe or event page use `add_faq_schema`,
+`add_recipe_schema` or `add_event_schema` instead of hand-writing `json_ld`;
+see `tr-seo`.
+
+**When something is out of reach.** If a tool refuses, tell the user what they
+can do about it, not only the error. When no tool covers a request (billing,
+for example), say so plainly and point to the relevant portal page.
+
 ## Compact discovery
 
 Find tools with `search_tools`, inspect one schema with `describe_tool`, then

package/skills/tr-import-url.md

@@ -5,6 +5,10 @@ description: Use when the user wants to import or migrate content from a non-Wor
 
 # Import content from a non-WordPress site
 
+**Who runs this:** this recipe is for the user's own AI agent (Claude Code, Codex or
+another MCP client) working through MCP and the public API. The portal's built-in
+AI assistant has no migration tools: it does not import, convert or verify sites.
+
 **Before bulk conversion:** read `tr-migration-evidence` with `read_skill`.
 Complete its source baseline and one verified prototype per active template.
 Read target content to protect edits, not to justify accidental target defaults.
@@ -194,8 +198,11 @@ get_deploy_status job_id=<id>
   several. Fix it.
 - **Squarespace/Wix forms.** They won't work after import — the backend
   is vendor-locked. Create a Typeroll form instead: `create_form`.
-- **Analytics/tracking code.** If the source has GA4 or similar, don't
-  copy it into pages. Set it via `update_site_settings scripts_head="..."`.
+- **Scripts and tracking.** Never copy the source's JavaScript. Carry
+  analytics and advertising tags (GA4, GTM, Meta Pixel and others) over by
+  ID in the Integrations app, with the cookie banner enabled so they wait for
+  consent; never paste the vendor snippet into `scripts_head`. See
+  tr-migration-evidence, "Scripts, tracking and consent".
 - **Videos.** YouTube/Vimeo embeds are fine (`<iframe>` is allowed).
   Hosted MP4s need re-uploading if the source URL won't persist.
 

package/skills/tr-migrate-astro.md

@@ -5,6 +5,10 @@ description: Migrate an existing Astro site, including Astro Content Collections
 
 # Migrate an Astro site
 
+**Who runs this:** this recipe is for the user's own AI agent (Claude Code, Codex or
+another MCP client) working through MCP and the public API. The portal's built-in
+AI assistant has no migration tools: it does not import, convert or verify sites.
+
 **Before bulk conversion:** read `tr-migration-evidence` with `read_skill`.
 Complete its source baseline and one verified prototype per active template.
 Read target content to protect edits, not to justify accidental target defaults.
@@ -50,6 +54,9 @@ assume that a filename alone determines the production URL.
 - Browser scripts, integrations and server-rendered endpoints need separate
   review. A static Page cannot inherit a private server runtime by copying its
   source text. Configure the supported Forms/Extension runtime explicitly.
+  Do not copy client scripts; analytics and advertising tags move to the
+  Integrations app behind the cookie banner (tr-migration-evidence, "Scripts,
+  tracking and consent").
 
 Create templates with `create_page_template`, types with `create_content_type`,
 then one `create_page` per source record. Use returned Page IDs, not source IDs

package/skills/tr-migrate-multisite.md

@@ -5,6 +5,10 @@ description: Use when migrating SEVERAL sites at once — a WordPress multisite
 
 # Migrate a multisite / multi-domain family to Typeroll
 
+**Who runs this:** this recipe is for the user's own AI agent (Claude Code, Codex or
+another MCP client) working through MCP and the public API. The portal's built-in
+AI assistant has no migration tools: it does not import, convert or verify sites.
+
 **Before bulk conversion:** read `tr-migration-evidence` with `read_skill`.
 Complete its source baseline and one verified prototype per active template.
 Read target content to protect edits, not to justify accidental target defaults.
@@ -163,6 +167,11 @@ language and attribution. Use authorized synthetic tests with a safe recipient;
 record delivery UNVERIFIED when it cannot be tested safely. Never create real
 leads or send mail to third parties as a routine migration test.
 
+Scripts follow tr-migration-evidence, "Scripts, tracking and consent": copy no
+source JavaScript, and carry each market's own analytics and advertising IDs
+over in that site's Integrations app with its cookie banner enabled. Never
+reuse one market's tracking IDs on another.
+
 ## Phase 5 — Redirects for everything you didn't preserve
 
 Work the coverage report, not your memory:
@@ -271,6 +280,7 @@ new canonical build and is not an inventory-only operation):
 - [ ] Complete `verify_migration_urls` → 0 `missing`, 0 `broken_redirect`, 0 `error`, 0 untested variants
 - [ ] `record_migration_seo_acceptance` is accepted for the latest deploy
 - [ ] `get_migration_launch_report` → `launch_ready: true`
+- [ ] No source JavaScript copied; analytics/advertising via the Integrations app with the cookie banner on (`scripts.status: "clean"` in the launch report)
 - [ ] hreflang cluster written on both/all sides, absolute, final domains
 - [ ] `language` set on the site; `<html lang>` correct in the deployed HTML
 - [ ] Internal links rewritten (no lingering absolute links to the old domain)

package/skills/tr-migrate-wp.md

@@ -5,6 +5,10 @@ description: Use when the user asks to migrate a WordPress site to Typeroll, men
 
 # Migrate from WordPress to Typeroll
 
+**Who runs this:** this recipe is for the user's own AI agent (Claude Code, Codex or
+another MCP client) working through MCP and the public API. The portal's built-in
+AI assistant has no migration tools: it does not import, convert or verify sites.
+
 **Before bulk conversion:** read `tr-migration-evidence` with `read_skill`.
 Complete its source baseline and one verified prototype per active template.
 Read target content to protect edits, not to justify accidental target defaults.
@@ -146,6 +150,9 @@ a. Fetch from WP. Prefer the helper plugin's authenticated endpoint
 b. Clean the HTML. Strip Elementor / Gutenberg / Breakdance class
    soup. Drop empty `<div>` and `<span>` wrappers. Keep semantic tags,
    tables, iframes from known hosts (YouTube / Vimeo / Calendly).
+   Remove every `<script>`: plugin and theme JavaScript is never copied.
+   Analytics and advertising tags move to the Integrations app behind the
+   cookie banner (tr-migration-evidence, "Scripts, tracking and consent").
 
 c. Migrate referenced images with `upload_media_from_url`. The customer's
    transfer Worker copies and verifies them directly in R2. Use the returned
@@ -291,6 +298,11 @@ get_deploy_status job_id=<id>    # poll
 - **Image bandwidth.** R2 upload is metered. Use `find_pages_matching`
   contains="<old-domain>" on already-imported content to spot images
   that weren't transferred.
+- **Plugin JavaScript.** Never copy scripts from plugins, the theme or
+  WordPress core into settings, pages, partials or block types, and never
+  copy the cookie plugin. Carry analytics and advertising over by ID in the
+  Integrations app with `cookie_consent.enabled: true`. The launch report
+  fails on copied source scripts and on tracking outside consent.
 - **WP-specific JSON-LD** (Yoast, Rank Math) is usually wrong after a
   redesign because it references old URLs. Strip it; let Typeroll
   emit fresh Article/Page schemas via `kind: 'article'` + `author`.

package/skills/tr-migration-evidence.md

@@ -5,6 +5,10 @@ description: Source-first design baseline, native capability mapping and evidenc
 
 # Migration evidence contract
 
+**Who runs this:** this recipe is for the user's own AI agent (Claude Code, Codex or
+another MCP client) working through MCP and the public API. The portal's built-in
+AI assistant has no migration tools: it does not import, convert or verify sites.
+
 Use this shared contract with WordPress, Astro, URL and multisite recipes.
 Default to preserving the source appearance and behavior. A redesign requires
 explicit scope. A partly migrated target is not the design reference.
@@ -115,6 +119,33 @@ interaction and conversion separately; only use an authorized synthetic mode and
 safe recipient. Unavailable delivery remains UNVERIFIED. No real leads or mail
 to third parties merely to fill a checklist.
 
+## Scripts, tracking and consent
+
+Do not copy JavaScript from the source site. WordPress plugins and themes
+inject their own runtime: jQuery, sliders, lightboxes, form and cookie
+plugins, page builders (Elementor, Breakdance, Divi), emoji and AJAX calls to
+`admin-ajax.php` or `/wp-json/`. It loads from, or posts to, a site that is
+about to be switched off. Inventory every `<script>` on representative source
+pages (head and body, inline and external, and which plugin or theme it
+belongs to), then decide each one:
+
+| Source script | Decision |
+| --- | --- |
+| WordPress core, theme or plugin runtime | Never copy. Rebuild what it did with native blocks, Forms or settings, or report a platform gap (see "Report platform gaps"). |
+| Cookie plugin (CookieYes, Complianz, Cookiebot, Borlabs, …) | Never copy. Enable the site's cookie banner (`cookie_consent.enabled: true`) with Swedish or local text and the privacy policy URL. |
+| Analytics or advertising tag in the Integrations catalog (GA4, GTM, Meta Pixel, LinkedIn, TikTok, Hotjar, Clarity, Pinterest, Snap, Reddit, X, Microsoft Ads, HubSpot, Plausible, Fathom, Matomo) | Carry over the ID only: enable the Integrations app with the source's ID (`list_apps`, `update_app`). Enable the cookie banner; analytics and advertising integrations wait for the visitor's consent. Never paste the vendor snippet. |
+| Tracking tag the catalog does not cover | Only with the owner's approval, in `cookie_consent.scripts_optional` with the banner enabled. Never in `scripts_head`, `scripts_body_end`, `scripts_necessary`, pages or partials. |
+| Partner widget or embed the page needs to work | Prefer a native block or an iframe from an allowlisted host. Keep custom code minimal, record why, and do not load it from the source site. |
+
+Ask the owner to confirm the analytics IDs; never invent or reuse one from
+another market. Before launch, `get_migration_launch_report` must show
+`scripts.status: "clean"`: it fails on copied source-platform scripts
+(`source_runtime_script`), tracking outside consent
+(`tracking_outside_consent`) and analytics or advertising integrations without
+the banner (`tracking_without_consent_banner`). In the hosted preview, check
+that no request goes to the source host or `/wp-content/`, no tracking request
+fires before consent, and the tags fire after "accept all".
+
 ## Evidence record (repeat per recipe, viewport and state)
 
 - Source URL/date and target URL; Page/template IDs; exact publication ID.

package/skills/tr-new-site.md

@@ -34,7 +34,13 @@ read_app_documentation when needed; do not bundle private app guides locally.
 No Site yet? Use hosted MCP with an Organization key and create_site, or create it
 in the portal. To start from an AI site plan instead of a blank Site, use
 create_site_and_plan, poll get_workflow and approve its structure review only
-with the user's consent. Read back its ID before editing. Use one explicit Site/Version for
+with the user's consent. That AI plan needs the Organization's own portal AI
+key for new Sites; without it the call answers `403 ai_not_enabled` and the
+`site_planning` workflow fails with `failure_code: "ai_not_enabled"`. Then plan
+it yourself: `create_site`, propose the site name, tagline and page list (title,
+slug, purpose, target keywords) from the business description, get the
+user's approval, and build with this recipe. Tell the user you planned it
+yourself; don't retry the workflow. Read back its ID before editing. Use one explicit Site/Version for
 related operations. Larger changes to an existing site should use a branch.
 
 Before importing content or a media library, require get_import_readiness to pass.

package/skills/tr-seo.md

@@ -36,7 +36,8 @@ read_site_settings
 ```
 
 For each page, check:
-- Is `seo_title` set? (if not, Google uses `title` + suffix — often fine)
+- Is `seo_title` set? (if not, Google uses `title` + suffix — often fine;
+  aim for 50–60 characters, longer gets truncated)
 - Is `seo_description` set? (150–160 chars, unique per page, includes keywords)
 - Is `og_image` set for the homepage and key landing pages?
 - Does the page have exactly one `<h1>`?
@@ -79,6 +80,20 @@ update_page page_id="home" patch={
 }
 ```
 
+### 3b. URL and article conventions
+
+When creating or moving pages:
+
+- Slugs are lowercase kebab-case: `our-services`, not `Our_Services`.
+- Reflect hierarchy in the address. A team member lives at `/team/jane-doe`
+  (set `path`, or use a content type whose `route_template` adds the
+  prefix), not at `/jane-doe`. Breadcrumbs and their BreadcrumbList schema
+  follow the resolved route.
+- Blog posts and news get `kind: "article"` and an `author`: that emits
+  Article JSON-LD and `og:type=article`. No author means no author in the
+  rich result.
+- Give shared pages, especially articles, their own `og_image`.
+
 ### 4. Add Open Graph images
 
 Set `og_image` on pages that get shared on social media. If the site has
@@ -116,6 +131,37 @@ repeating it on every page (`null` clears it):
 update_site_settings organization={"name":"Acme Studio","logo":"<cdn_url>","same_as":["https://www.linkedin.com/company/acme"]}
 ```
 
+**FAQ, recipe and event pages have tools.** They validate the input, build
+the schema.org JSON-LD and merge it into the page's `json_ld` (a node of the
+same type is replaced, anything else is kept). Use them instead of
+hand-writing JSON-LD, and copy the content from what the page visibly shows:
+
+```
+add_faq_schema page_id="faq" items=[
+  {"question": "Do you deliver on weekends?", "answer": "Yes, Saturdays 9–15."}
+]
+add_recipe_schema page_id="kanelbullar" name="Kanelbullar"
+  ingredients=["500 g vetemjöl", "2 tsk kanel"] instructions=["Blanda degen.", "Grädda i 225 °C."]
+  prep_time="PT1H30M" cook_time="PT10M" recipe_yield="24 bullar" image_url="<cdn_url>"
+add_event_schema page_id="sommarkonsert" name="Sommarkonsert"
+  start_date="2026-06-12T19:00:00+02:00" location_name="Stadshuset"
+  location_address="Storgatan 1, Sundsvall" offers_price=250 offers_currency="SEK"
+```
+
+Rules they enforce: FAQ needs at least one question with an answer; a recipe
+needs a name, ingredients and steps, durations are ISO 8601 (`PT30M`) and
+URLs absolute; an event needs a name and an ISO 8601 `start_date` (include
+the UTC offset), `end_date` not before it, and a price needs
+`offers_currency`. Read the returned `warnings`: a recipe without an image or
+an event without a location is valid but not eligible for Google's rich
+results. Like other content writes they land in the draft — `save: true` or
+`commit_working_copy` when approved.
+
+FAQ markup only belongs on a page that visibly presents those questions and
+answers; Google penalizes FAQ markup for content the page does not show.
+
+For other types write `json_ld` yourself:
+
 ```
 update_page page_id="home" patch={
   "json_ld": "{\"@context\":\"https://schema.org\",\"@type\":\"LocalBusiness\",\"name\":\"Acme Studio\",\"url\":\"https://acme.se\",\"telephone\":\"+46812345\",\"address\":{\"@type\":\"PostalAddress\",\"streetAddress\":\"Drottninggatan 1\",\"addressLocality\":\"Stockholm\",\"postalCode\":\"111 51\",\"addressCountry\":\"SE\"}}"
@@ -124,16 +170,25 @@ update_page page_id="home" patch={
 
 **Important:** JSON-LD goes in the `json_ld` field as a JSON *string*
 (not a nested object). The renderer injects it inside
-`<script type="application/ld+json">`.
+`<script type="application/ld+json">`. To keep several nodes on one page,
+store them as `{"@context":"https://schema.org","@graph":[…]}` — the
+`add_*_schema` tools do this for you. Read the page first: an update
+replaces the whole `json_ld` value.
 
 Common schemas worth adding:
 - Homepage: `LocalBusiness` or `Organization`
 - About: `AboutPage`
 - Contact: `ContactPage`
 - Blog articles: auto-generated from `kind:"article"` + `author`
-- Events: `Event` with `startDate`, `location`
+- FAQ, recipe and event pages: the `add_*_schema` tools above
 - Products: `Product` with `offers`
 
+**Instead of the `schema_markup` workflow.** That workflow runs the model with
+the Organization's own AI key; on a Site without that access it fails with
+`failure_code: "ai_not_enabled"`. Don't retry it. Do the same work here: read
+each published page, pick the one type it genuinely represents (or none),
+apply the tool or `json_ld` above, and tell the user you did it yourself.
+
 ### 6. robots.txt
 
 The default robots.txt allows all crawlers. Update if needed:

package/skills/tr-starter-design.md

@@ -0,0 +1,79 @@
+---
+name: tr-starter-design
+description: Reference for the default design new Typeroll sites start with — CSS variables, spacing, radii, container width, header and footer skeletons. Read it when a site is blank or clearly follows these conventions and you need new markup or CSS to fit in; skip it for sites with their own design.
+---
+
+# Starter design system
+
+A reference for the *default* design that ships with new Typeroll sites.
+The customer may have replaced it — always inspect the actual header partial
+(`read_partial partial_id="header"`) and an existing page before assuming any
+of this is in use. On a site with its own design, mirror what is there.
+
+## CSS variables
+
+Colors (set in site settings `colors`; each key becomes `--color-<key>`,
+`text_light` becomes `--color-text-light`):
+  --color-primary       brand CTAs, links, accents
+  --color-secondary     supporting brand color (rarely used)
+  --color-accent        a third highlight (badges, callouts)
+  --color-background    page background (the body)
+  --color-surface       slightly raised areas (header, footer, cards)
+  --color-text          body copy + headings
+  --color-text-light    secondary text (captions, meta, footer fine-print)
+
+For subtle borders/dividers that follow the text color without being heavy,
+use `color-mix(in srgb, var(--color-text) 8%, transparent)` (6% for very soft).
+
+Spacing scale:
+  --spacing-xs (0.25rem)  --spacing-sm (0.5rem)  --spacing-md (1rem)
+  --spacing-lg (2rem)     --spacing-xl (4rem)
+
+Layout:
+  --container-medium (1080px)  Center page content with
+    `max-width: var(--container-medium); margin: 0 auto; padding: var(--spacing-md);`
+  --container-narrow (720px) and --container-wide (1400px) exist for prose
+    and wide layouts.
+
+Radii:
+  --radius-sm (0.25rem)  --radius-md (0.5rem)  --radius-lg (1rem)
+
+Typography (set in site settings `fonts`):
+  --font-heading  Use for h1-h6 and brand wordmark
+  --font-body     Default for everything else
+  --font-size-base (the rem baseline)
+
+Block-mode pages get these through the blocks and named styles; reach for the
+variables in custom CSS, HTML-mode pages and template markup.
+
+## Default header skeleton
+
+Surface-tinted bar with a hairline bottom border. Brand text on the left
+in the heading font, bold, slight negative letter-spacing. Nav on the
+right. Last nav item is typically a primary CTA: `background:
+var(--color-primary); color: var(--color-background); border-radius:
+var(--radius-md)`.
+
+## Default footer skeleton
+
+Three-column responsive grid (brand+tagline / Site links / Get in touch),
+then a fine-print row with copyright + Typeroll attribution. Top border
+uses the same color-mix() recipe as the header.
+
+## When to use this
+
+- A brand new site, or one where the header partial still matches this
+  layout.
+- A page or block where the customer wants something that "fits the rest
+  of the site" and the rest follows these conventions.
+
+## When NOT to use this
+
+- The customer has a totally different design (e.g. dark mode, custom
+  utility classes, no CSS variables, migrated theme).
+- The customer says "use this brand color" — honor their literal request
+  instead of substituting a CSS variable.
+- Mid-edit on an existing page that doesn't follow these conventions —
+  match what's already there.
+- Choosing a new palette or fonts is brand work (the MCP recipe `tr-brand`),
+  not this reference.