@bettercms-ai/mcp 0.66.6 → 0.67.1

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 field the stamped build renders on no route is flagged `stale: true` on its schema — kept, hidden in the editor, cleared by the release that binds it again — and is not listed. 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,31 @@ 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".
+- **Render a CTA as one button** (the fix a 409 `CODE_RENDERED_ROUTE` names: its `next` gives the
+  `route` and the pair's `keys`). On a route the site's app renders, the code reads the keys it
+  declares, so the swap is made in code, on a branch, never on the default one:
+  1. Find the anchor. Search the repo for the keys; follow them through props and bindings tables
+     to the component that writes the `<a>` (a page passes them to a layout component, which
+     passes them to the button component).
+  2. Render it with `BcmsButton` (`@bettercms-ai/astro/components/BcmsButton.astro`, or
+     `BcmsButton` from `@bettercms-ai/next`) under ONE key: the link key without `-href`. Pass
+     `value` as the entry's button when it holds one, else `{ label, href }` from the copy and
+     href the page renders today, so nothing changes until someone edits it. Keep the anchor's
+     classes on `class`.
+  3. Remove the old pair's stamps and reads for that anchor (`data-bcms-field`, `data-bcms-props`,
+     the lookups of the two old keys). Leave other callers of a shared component working.
+  4. Open a pull request. After it is merged and the site rebuilt, run `editor_setup`, then check
+     the page: the anchor carries `data-bcms-button="<key>"` and `get_binding_report` lists no
+     unmatched path for it. The button field is added by that build and starts from the pair's
+     label and link.
 
 ## 6. Preview source
 

package/dist/skills/bettercms/references/content-modeling.md

@@ -94,7 +94,9 @@ sitemap), RSS (dated by `publishedAt`), `llms.txt` (one link per published item)
   `create_page` and model writes. A page that already holds a pair (`primaryCtaText` +
   `primaryCtaHref`) becomes one button with `update_field` `{ pageId, path: "primaryCtaText",
   mergeHref: "primaryCtaHref" }`: each entry's DRAFT gets `{ label, href }` and keeps the old values,
-  so code still reading them keeps rendering; the live copy changes on publish. Inside a component
+  so code still reading them keeps rendering; the live copy changes on publish. On a route the
+  site's app renders at request time the merge is refused (409 `CODE_RENDERED_ROUTE`): change the
+  code to draw the CTA with `BcmsButton`, and the next build adds the button field. Inside a component
   a CTA is a `button` block whose `props.text` and `props.href` two props target.
 - Never model SEO columns ([seo.md](seo.md)), Form questions (they live on the Form document) or
   Global Layout values as content fields.

package/dist/skills/bettercms/references/dock-input.md

@@ -83,8 +83,11 @@ bettercms/inputs/<name>.tsx
 
 - `<name>` is the `ui.input.name`: lowercase letters, digits and dashes, 1 to 48 characters,
   starting with a letter (`button-look`, `brand-swatch`).
-- The default export is the component. The file also calls `mountDockInput(Component)`, which
-  speaks the protocol (section 6) so the component only deals with props.
+- The default export is the component, and the file does nothing else. The build wraps it in
+  `mountDockInput`, which speaks the protocol (section 6), so the component only deals with props.
+  Never call `mountDockInput` in the file: the input would mount twice.
+- The site needs `react`, `react-dom` and `@bettercms-ai/dock-input` in its `devDependencies`
+  (plus `@bettercms-ai/kit` for kit components). The build bundles them into the input.
 - Keep it small and self-contained: kit components and the field's own data, no app imports.
 
 ## 6. Protocol summary

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 flags the auto fields the
+   build no longer renders `stale` (hidden in the editor, never deleted) and never one 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.6",
+  "version": "0.67.1",
   "type": "module",
   "description": "BetterCMS MCP server — schema, content, forms + components authoring tools over the Management API, authed via OAuth device-code.",
   "bin": {