@bettercms-ai/convert 0.4.0 → 0.6.0

package/CHANGELOG.md

@@ -1,5 +1,39 @@
 # @bettercms-ai/convert
 
+## 0.6.0
+
+### Minor Changes
+
+- 5ad31fd: Astro SSR draft recipe now names `@astrojs/node` standalone, the auto-injected draft routes, and `loadPage` + `loadComponents`.
+
+## 0.5.0
+
+### Minor Changes
+
+- The conversion now decides the site's LIVE PREVIEW LANE, and says so in the receipt.
+
+  A converted site is static, so the visual editor can frame the real build but has nowhere to
+  put a DRAFT — it falls back to the platform's approximate renderer and stops looking like the
+  site. A Next page that already renders through `<BcmsBlocks>` gets the fix applied: the import
+  moves to `@bettercms-ai/next/draft-bridge` and the element becomes
+  `<BcmsDraftBridge slug={…} …/>`, which listens for the editor's push.
+
+  🔴 THE SLUG IS THE WHOLE RISK, so it is never guessed. It has to come from the component's own
+  scope (`slug`, `params`, `page`) or from a route literal the brief can name; anything else is
+  `CANVAS_BRIDGE_MANUAL` with the file and the line. A bridge wired to the wrong slug is a page
+  that silently never updates in the editor — worse than no bridge, because the editor's chip
+  then claims a live lane.
+
+  Astro is refused wholesale with `SSR_DRAFT_ROUTE` and the recipe in `hint`: bridging it needs
+  either `<BcmsLiveBlocks client:load>` from `@bettercms-ai/astro` or a server render, and
+  migrating somebody's site to SSR is a deploy-shaped decision, never a codemod's.
+
+  The receipt gains `canvas: { lane: "bridge" | "pending", files? }`. The two lane reasons ride
+  `paths.pending` — the one list every reader already looks at — but are OUTSIDE the arithmetic
+  (`declared === rewritten + alreadyDeclared + pending.length`): a lane row is a fact about the
+  site, not an unbound field, and counting it would make every hand-written site report one
+  phantom missing path forever.
+
 ## 0.4.0
 
 The workspace lockfile records this version: a lock still naming 0.3.0 makes a frozen install
@@ -69,7 +103,7 @@ reject the checkout, which is what broke the migrator image on #616.
   has; a `bcmsField` the file demonstrably builds from our helper is left alone and only its
   bindings are wrapped; anything else is `SECTION_UNMIGRATABLE`.
 
-  🔴 A NAME IS NOT A PROVENANCE. Reusing anything *called* `bcmsFields` trusted an import from
+  🔴 A NAME IS NOT A PROVENANCE. Reusing anything _called_ `bcmsFields` trusted an import from
   any module at all — `import { bcmsFields } from "./their-utils"` is a different function with
   the same name — and any coexisting `bcmsField` vouched for itself. The specifier must RESOLVE
   to the helper module this package writes (through the project's own aliases), and `bcmsField`
@@ -175,7 +209,7 @@ reject the checkout, which is what broke the migrator image on #616.
   catch, reached through the check itself. Two shapes are provable: a string literal and NOTHING
   else, and a template literal whose every interpolation is an INDEX (`[${i}]`, what a repeater
   writes, which cannot change the prefix). Everything else — `{computedPath}`, `{"a" + x}`,
-  `` {`${prefix}.title`} `` — is opaque, and opaque is `PROP_MAP_INCONSISTENT`.
+  ``{`${prefix}.title`}`` — is opaque, and opaque is `PROP_MAP_INCONSISTENT`.
 
 - `COPY_MODE_MISMATCH` ignores sections the SERVER already refused.
 
@@ -196,7 +230,7 @@ reject the checkout, which is what broke the migrator image on #616.
 
   The in-place call site — `<Hero bind="hero" page={pageSnapshot("home")} />` — is written by
   the codemod from the plan and carries no `blockId` and no `overrides`; it never consults the
-  CMS's blocks at all, which is exactly what makes the inline form componentisation *without*
+  CMS's blocks at all, which is exactly what makes the inline form componentisation _without_
   the page builder. Emitting it for a placement whose copy has MOVED rendered the page's field
   group and declared the page lane for an address that no longer holds anything. The component
   is still written; the page is left as its author wrote it.
@@ -266,7 +300,7 @@ reject the checkout, which is what broke the migrator image on #616.
   the dashboard renders. The committed helper needed nothing: `bcmsRows` already passes a
   nested array through untouched and `bcmsSection` hands a section its group whole.
 
-  The bindings are `` data-bcms-field={`cards[${i}].items[${j}].label`} `` and the shape is
+  The bindings are ``data-bcms-field={`cards[${i}].items[${j}].label`}`` and the shape is
   `cards[*].items[*].label`; the loop now REPORTS the bindings it wrote, both loop variables
   included, instead of the caller re-deriving a literal the file does not contain. ONE level
   of nesting — what the plan mints and what the component prop validator accepts — so a leaf

package/README.md

@@ -71,6 +71,18 @@ A path counts as rewritten only when EVERY located occurrence of it was. A value
 the home page and a shared header is two places a reader sees it, and converting one of them reads
 as a finished job.
 
+**It also decides the live-preview lane.** A Next page already rendering through `<BcmsBlocks>`
+gets its import moved to `@bettercms-ai/next/draft-bridge` and its element rewritten to
+`<BcmsDraftBridge slug={…} …/>`, so the visual editor can re-render your DRAFTS with your own
+components instead of falling back to the platform's approximate renderer. The slug is never
+guessed — it comes from the component's own scope (`slug`, `params`, `page`) or a route literal the
+brief can name, and anything else is `CANVAS_BRIDGE_MANUAL` with the file and line, because a
+bridge on the wrong slug is a page that silently never updates. Astro gets `SSR_DRAFT_ROUTE` and
+the recipe: use `<BcmsLiveBlocks client:load>` from `@bettercms-ai/astro`, or render those routes
+on a server. The verdict is `canvas: { lane, files? }` on the receipt; the two lane reasons ride
+`paths.pending` but are outside the arithmetic above — they are facts about the site, not unbound
+fields.
+
 **A declaration this package did not write still counts.** An element that names the target —
 `data-bcms-field`, `data-bcms-layout-field` or an address in `data-bcms-props` — but gets its copy
 some other way (a literal somebody left there, the project's own data module) is DECLARED: the