@bettercms-ai/mcp 0.76.5 → 0.76.6

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

@@ -297,3 +297,43 @@ fields, submitUrl). After the binding pass, run the codemod's forms mode (`npx
 @bettercms-ai/convert --forms`, with the brief and a receipt file) to wire them into the
 repository's own `<form>` elements. Read `forms.pending`, and publish every form `forms.notes` names in the Forms tab: a draft
 form rejects every submission with a 403.
+
+## Editor setup, proposals and binding decisions
+
+`editor_setup` derives what a build no longer imports: a build brings in SEO/meta, media, brand and
+the models `bcms-content.json` declares; editor setup adds pages, collections, forms, bindings,
+button and section components (when the authoring preference is components), Component Groups and
+the Content sidebar. `get_deploy_status` `editorSetup` reports its state.
+
+The complete brief's `proposals` (page 1, at most 50; `proposalsMore` when there are more) list
+what the last convert found and no field owns: `{ id, kind, target, text, suggested?, evidence? }`.
+`id` is `pr_` and 16 hex and survives re-runs; `target` is a `file:line:col` locator only. Kinds:
+`unaddressable` and `code-candidate` (copy no field owns), `inert` (declared, nothing reads it),
+`mismatch` (declares one path, reads another), `flatten` (two leaves in one element).
+
+Answer them with `editor_setup { declare: [item, …] }` (at most 100 items, one result each;
+`check: true` with `declare` is a dry run that stores nothing):
+
+- `{ op: "accept", ids }` takes each proposal's `suggested` op. A proposal with none refuses.
+- `{ op: "bind", id, path, owner? }` binds the copy to an existing field; `owner` is a route or
+  `layout`. The next convert writes it into the source (a mismatch's declaration is rewritten; an
+  attribute or an expression is reported `manual` in `receipt.decisionsApplied`). A `bind` waits as
+  `decision-pending` until a build proves the new read; one still pending after the next release
+  blocks the gate. A declared element is corrected through its `mismatch` proposal id.
+- `{ op: "code", id, why, system? }` keeps it in code. `why` is one of `runtime`, `external`,
+  `derived`, `stylesheet`, `decorative`, `embed`, `legal`, and the system checks its evidence;
+  without it the item refuses `evidence-missing` (bind it, pick the reason that fits, or a person
+  marks it in Overview). The next convert writes `data-bcms-code-owned="text why:<id>"`; the
+  `code` counts once a build carries it. Each convert re-checks the
+  facts: one whose reason no longer holds becomes `evidence-lost`, blocks the gate, and returns to
+  the proposals to decide again. Facts are same-file only: a value from another file needs a person.
+- `{ op: "reject", ids }` drops the suggestion; the copy stays unaddressable. A person's reject of
+  an AI `code` is its Undo: the next convert removes the token.
+- `{ op: "clear", decisionId }` undoes a decision.
+
+A person's decision beats yours: add `force: true` and a `reason` (shown to them) only when they
+asked for it. Refusals per item: `target-unknown`, `path-not-in-schema`, `owner-mismatch`,
+`locked-by-person`, `slot-mismatch`, `evidence-missing`, `declaration-conflict`, `invalid-item`.
+Until a convert that emits proposals has submitted its receipt, every id refuses `target-unknown`.
+`get_next_steps` `receipt.decisions` counts `stored`, `materialized`, `proven`, `pending` (open
+proposals) and `lost`; stop when `pending` is 0.

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

@@ -81,7 +81,7 @@ Never let a component contain itself, directly or through a child.
 
 ## 3. Names and groups
 
-The import's kit entry (`kit: suggested <id> <score>`, the `hint` of its row in `receipt.gate.kit`) is only a suggestion: nothing is recorded, and nothing waits on it. The props already carry the ui that suggestion gives. For each component, read `bettercms://kit/entry/{id}`, check its `htmlSignals` against the section's own HTML and its pitfalls against the props, then confirm it or pick the right one from its category in `bettercms://kit` and name it with `update_component { kitEntry }`. Setting or changing `kitEntry` puts that entry's ui over the derived ui: where the entry specifies a tab, group, control or preview key for a prop, the entry wins; what it says nothing about stays as derived; ui you or a person set is kept. The `no-kit-match` exemption needs a note.
+The import's kit entry (`kit: suggested <id> <score>`, the `hint` of its row in `receipt.gate.kit`) is only a suggestion: nothing is recorded, and nothing waits on it. The props already carry the ui that suggestion gives. For each component, read `bettercms://kit/entry/{id}`, check its `htmlSignals` against the section's own HTML and its pitfalls against the props, then confirm it or pick the right one from its category in `bettercms://kit` and name it with `update_component { kitEntry }`. Setting or changing `kitEntry` puts that entry's ui over the derived ui: where the entry specifies a tab, group, control or preview key for a prop, the entry wins; what it says nothing about stays as derived; ui you or a person set is kept. It also carries the entry's rules (showIf, limits, patterns, options, required) onto props that have none of their own. A component whose props still lack some gets a `gate.kit` row with `drift` listing each one as `path.key=value`: add them with `update_component { props }`, or record `kit-drift-accepted` with a note. The `no-kit-match` exemption needs a note.
 
 Name a family by what it is (`Hero`, `CTA`, `Testimonials`) and each variant by how it looks
 (`Hero / Split`, `CTA / Centered`). Never put a page name in a reusable definition; which pages

package/package.json

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