@bettercms-ai/mcp 0.68.0 → 0.68.2

package/dist/index.js

@@ -6712,6 +6712,11 @@ conversion is yours to write.
 5. Codemod the templates. Read each value from the CMS (\`@bettercms-ai/astro\` /
    \`@bettercms-ai/next\` client, or the \`bcms-content.json\` build snapshot), KEEP the in-code
    copy as the fallback, and declare the binding on the element that already renders it.
+   Read the snapshot ONLY through a supported reader: the helper \`npx @bettercms-ai/convert\`
+   writes (\`bcms\`, \`bcmsRows\`, \`bcmsImage\`) or \`publishedEntry(slug)\` from
+   \`@bettercms-ai/sdk\`. Never hand-write a parser of the file: a row holds its values under
+   \`data\`, so \`row.title\` is undefined and the page renders its fallback on every publish. An
+   editable image is \`bcmsImage(page, path, importedImage)\`, never the bare import with a stamp.
    Prefer schema-derived bindings \u2014 the TypeGen analogue:
    \`npx @bettercms-ai/codegen --bindings-out src/bettercms.bindings.generated.ts\`, then spread
    \`{...bcms.home.hero.title}\` / \`{...bcms.blog.features.$(i)}\`. The hand form is
@@ -6746,7 +6751,7 @@ conversion is yours to write.
       \`bcms-content.json\` into the repo root before \`build\`, with a key it mints per build: no
       repo secret feeds it. (The secret a connect sets, \`BCMS_API_KEY_<RUNG>\` such as
       \`BCMS_API_KEY_PROD\`, is the validation workflows' key; they fall back to the shared
-      \`BCMS_API_KEY\` only for a repo whose last connect predates it.) Read that file, with in-code
+      \`BCMS_API_KEY\` only for a repo whose last connect predates it.) Read that file (step 5's readers), with in-code
       fallbacks so a local or CI build without it still renders.
     - ARCHIVE (\`deploy_project\`, inline or by \`uploadKey\`): the sandbox build runs with no env
       and no network content step, by design. So the archive MUST SHIP its own
@@ -7035,9 +7040,10 @@ Do not stop at the plan or at a partial receipt \u2014 finish the whole site, ne
 10. \`get_next_steps\`: if it lists \`upgrade-section-roots\` (section spacing and style handles), in the repo run
    \`npx @bettercms-ai/convert@latest --upgrade-sections --root . --dry-run\`, read the plan, then run it for real. For every
    root its receipt lists as \`skipped\`, pass the block down by hand: \`{...sectionRootAttrs(block)}\` on the section root, or
-   \`data-bcms-style=""\` plus \`style={...}\` from \`block.style\`. Run \`--verify-styles\` again and restore what it lists (the
-   marker and the inline style from \`block.style\` are allowed; changing a class or an existing style is not). Deploy,
-   poll, call \`get_next_steps\` again and tell me what it still lists. Not listed: say so and move on; invent no work.
+   \`data-bcms-style=""\` plus \`style={...}\` from \`block.style\`. For \`upgrade-element-styles\` (field width, spacing, text handles)
+   do the same with \`npx @bettercms-ai/convert@latest --upgrade-element-styles --root . --dry-run\`. Run \`--verify-styles\` again
+   and restore what it lists (the marker, and the inline style from \`block.style\` or \`fieldAttrs\`, are allowed; changing a class
+   or an existing style is not). Deploy, poll, call \`get_next_steps\` again, tell me what it still lists. Not listed: say so; invent no work.
 11. Ask me whether to commit and push to my repository, commit only, or leave it uncommitted (unpushed, the
    next rebuild from my repo drops it). Touch git only as I answer.`;
 var FIELD_UI_PROMPT = {