@bettercms-ai/mcp 0.68.0 → 0.68.1

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