@bettercms-ai/mcp 0.65.0 → 0.65.2

package/dist/index.js

@@ -4949,7 +4949,7 @@ ${res.warnings.join("\n")}` : summary, res.data);
       def(
         "get_deploy_status",
         "Get deploy/build status",
-        "Get the connected project's deploy/build status: state (idle|queued|building|categorizing|failed), whether it's publishing, the live commit sha, when it went live, and any build error. `categorizing` means the bytes are live but the import's setup lanes (content, pages, bindings) are still running, so `publishing` is still true and the site is not ready to edit yet. Poll this after deploy_project until state is idle with your sha live. `release` is the newest release (id, sha, status, phaseMarks, error, createdAt): while an uploaded build ingests or releases, state is `building`, `release.sha` the new sha and `lastLiveSha` still the old one; a failed deploy shows `release.status` failed with its `error`, and `held` state (`held.by`: staff, archived or no-subdomain) means the release waits until that is cleared. Also returns `canvas.lane` (the editor's live-preview lane for this site: `bridge` / `draft-route` / `none`) and `editorUrl`, the visual editor to hand the user.",
+        "Get the connected project's deploy/build status: state (idle|queued|building|categorizing|failed), whether it's publishing, the live commit sha, when it went live, and any build error. `categorizing` means the bytes are live (`publishing` false) but the setup lanes (content, pages, bindings) are still running: not ready to edit yet. Poll this after deploy_project until state is idle with your sha live. `release` is the newest release (id, sha, status, phaseMarks, error, createdAt): while an uploaded build ingests or releases, state is `building`, `release.sha` the new sha and `lastLiveSha` still the old one; a failed deploy shows `release.status` failed with its `error`, and `held` state (`held.by`: staff, archived or no-subdomain) means the release waits until that is cleared. Also returns `canvas.lane` (the editor's live-preview lane for this site: `bridge` / `draft-route` / `none`) and `editorUrl`, the visual editor to hand the user.",
         z.object({}).shape,
         async (c) => ok("Deploy status.", await data(c, "GET", `/management/projects/deploy-status`))
       ),
@@ -6298,10 +6298,12 @@ but a code-built site ships only what its own templates draw:
   itself, in order, each section root stamped \`data-bcms-block="<blockId>"\`. \`npx @bettercms-ai/convert
   --componentize\` writes that loop (\`src/lib/bcms-sections.ts\`) and the stamps. Until it ships, the canvas
   only ARRANGES the static build to match the draft (a section the build never rendered is stood in for
-  by a server render), the editor locks Add section and reordering on routes whose code sets the
-  sections, and each such route leads \`submit_conversion_receipt\`'s \`pending\` with a
-  \`SECTIONS_UNSTAMPED\` row, so \`complete\` stays false. Never hard-code a page's bands in a template
-  whose order the CMS owns.
+  by a server render); the editor still saves added, moved and swapped sections but says the live site
+  keeps its own order, and offers "Let BetterCMS control section order" (that same codemod, committed
+  to the connected repository); and each such route leads \`submit_conversion_receipt\`'s \`pending\`
+  with a \`SECTIONS_UNSTAMPED\` row, so \`complete\` stays false. Never hard-code a page's bands, or
+  literal \`data-bcms-block\` ids, in a template whose order the CMS owns: a release measures whether
+  the stamped roots come out in the CMS order (\`ordered\` on the binding report's structure row).
 - A placement the site never renders (a leftover nav, footer or modal its layout draws) moves
   nothing: the editor counts section moves in RENDERED sections only and locks that row. Remove
   such placements; do not reorder around them.