@bettercms-ai/mcp 0.66.4 → 0.67.0

package/dist/skills/bettercms/references/bindings.md

@@ -60,13 +60,16 @@ value over everything else inside it, so:
   and bind that. An `<li>` that renders nothing but the value is itself the leaf.
 - **A link or button label beside an icon.** In `<a href="…"><svg/> Sign up</a>`, put the label
   in its own `<span>` with the field, and the `href` on the anchor through `data-bcms-props`
-  (`cta.href|url|href`). A binding on the anchor's text deletes the icon.
+  (`cta.href|url|href`). A binding on the anchor's text deletes the icon. A call to action is a
+  `button` field rendered with `BcmsButton` ([components.md](components.md)).
 - **SVG text is never bound; the icon is.** No field is derived from the text inside an `<svg>`,
   and no binding there is measured. Each inline icon IS an editable `image` field (`config.media:
   "icon"`, an svg value): an editor swaps it. Never remove one to tidy a form; group it.
-- **Icon-only links in the nav and footer** take their field name from the anchor's
-  `aria-label`, then the SVG `<title>`. Give each one an `aria-label`, or every social link is
-  named `link` and an editor cannot tell them apart.
+- **Icon-only links in the nav and footer** take their field name from what a screen reader
+  reads: the anchor's `aria-label`, its `sr-only` text, a `title`, the SVG `<title>` or an `alt`
+  (never `<style>` or `<script>` text). Give each one an `aria-label` or `sr-only` label, or every
+  social link is named `link` and an editor cannot tell them apart. A row of them is a "Links" or
+  "Social links" list; each row keeps its own name in its values.
 
 ### The site's design is not yours to change
 
@@ -131,7 +134,9 @@ helpers rather than by hand.
   keep inside a bound element. A value with no element never reaches the page, and one that
   would corrupt its element is refused and named.
 - Read the report, not the screen. Clean = `coverage.pending` empty and the mode you expect. Each
-  `unmatched` reason names a fix in the source. A `fallback` flag means the build carried no
+  `unmatched` reason names a fix in the source. A Global Layout Section is reported only on the
+  routes that render it (`layoutRoutes` lists each route's Sections): a docs page on its own layout
+  is not missing the nav, so never add one there. A `fallback` flag means the build carried no
   `bcms-brief` meta and was measured against the latest pin. Only a release creates the report;
   a content apply later updates its Layout rows.
 

package/dist/skills/bettercms/references/components.md

@@ -168,9 +168,14 @@ A code-built site ships only what its templates draw, whatever the page's `block
   `upgrade-section-roots`. The fix is the codemod's `--upgrade-sections` mode, latest version, at
   the repo root (`--dry-run` first); give each root it reports as skipped (`OWN_STYLE`, `SPREAD`,
   `BLOCK_ID_ONLY`, …) its block style by hand, confirm with `--verify-styles`, push and release.
-- **A `button` field renders with `BcmsButton`** (`path`, `value`): one `<a>` carrying
-  `data-variant` and `data-size`, so the site's CSS decides what each look looks like and the
-  editor repaints it live.
+- **A `button` field renders with `BcmsButton`** (`path`, `value`): one `<a data-bcms-button>`
+  carrying `data-variant` and `data-size`, so the site's CSS decides what each look looks like and
+  every look control (style, size, arrow, icon, new tab) applies on the canvas and on publish.
+  Without the SDK, write that same anchor: `data-bcms-button="<path>"`, the label in its own
+  `<span data-bcms-field="<path>.label">`, the href through `data-bcms-props`. The arrow is the
+  `svg.bcms-btn-arrow` it draws; never leave a hand-written arrow `<svg>` beside it, or turning
+  the arrow off leaves one behind. A CTA whose look is hard-coded tells the editor "Style lives
+  in the site's code".
 
 ## 6. Preview source
 

package/dist/skills/bettercms/references/getting-started.md

@@ -68,7 +68,8 @@ and `get_componentize_plan` proposes nothing more.
 0. A build brings in only SEO and meta, media, the brand and the models `bcms-content.json`
    declares. Pages, collections, forms, bindings and components come from `editor_setup`: run it
    and poll `editor_setup { check: true }` until `ready` before anything below. Run it again
-   whenever `get_deploy_status` reports `editorSetup` `stale`. It also fills missing meta from the
+   whenever `get_deploy_status` reports `editorSetup` `stale`: a re-run retires the auto fields its
+   new derive supersedes and keeps any a person edited, so never delete those by hand. It also fills missing meta from the
    page copy, merges identical components and switches to declared bindings when the build proves
    them; the receipt stays yours (it is the codemod's account of your repo).
 1. Explore the repo (the "Read when" column of SKILL.md's reference table names the signals) and

package/dist/skills/bettercms/references/localization.md

@@ -20,7 +20,9 @@ Two things are called a "language" here, and they are separate:
 
 | Piece | How it works |
 |---|---|
-| The project's locales | `localeConfig.locales`, set by the owner in the dashboard (project settings). A `locale` outside it is refused with 400; an empty list means a single-language project |
+| The project's locales | `localeConfig.locales`: the owner's list (project settings) plus every page language an import finds. A `locale` outside it is refused with 400; an empty list means a single-language project. Tags are stored canonical (`zh-CN` → `zh-cn`) |
+| A page's language | `list_pages` / `get_page` return `language` (its `locale`, else the `<html lang>` its import declared; null = the default) and `path`. Set it with `create_page` / `update_page` `locale` |
+| Address a page | By id or `path` (`/de/construction/safety`). A slug repeats across language folders, so a bare slug works only when one page has it; otherwise the tool refuses with each match's id, path and language. Never guess one |
 | Translate an entry with AI | `translate_entry` { entryId, targetLocale, slug?, fields? } creates the translation as a DRAFT with `locale` and `translationOf` set (AI credits: 402/403 when out or not on the plan). Text and longtext are translated; rich text and documents are copied for you to translate; `meta` lists which. `409 locale_conflict`: that translation exists, so edit it instead |
 | Create one by hand | `create_content_entry` or `create_page` with `locale` and `translationOf` = the source's id, never another translation's. One row per locale per source (a second is `409 locale_conflict`); `update_content_entry` / `update_page` change either, null clears |
 | Find them | `list_content_entries` `where: { locale: 'fr' }`; default-language rows have a null `locale`, so they match `{ locale: { ne: 'fr' } }`, never `eq` |
@@ -35,8 +37,8 @@ Import derives deeper locale routes (`/fr/about`) as pages in a URL folder (`fr`
 the language its `<html lang>` declares, and the Content sidebar files them under Pages › <language>.
 A locale prefix is never a collection, but a collection's localized posts (`/fr/blog/post-1`, its
 `<html lang>` agreeing) are entries of that collection with `locale` set, `translationOf` the post
-their hreflang alternate (else their slug) names, slug `<slug>-<locale>`; the project's locales gain
-each language found. An edit to `/about` never reaches `/fr/about`; edit each page or entry.
+their hreflang alternate (else their slug) names, slug `<slug>-<locale>`, served at
+`/<locale>/<collection>/<slug>`; the project's locales gain each language found. An edit to `/about` never reaches `/fr/about`; edit each page or entry.
 
 ## 2. Never model
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bettercms-ai/mcp",
-  "version": "0.66.4",
+  "version": "0.67.0",
   "type": "module",
   "description": "BetterCMS MCP server — schema, content, forms + components authoring tools over the Management API, authed via OAuth device-code.",
   "bin": {