@bettercms-ai/mcp 0.35.0 → 0.36.0

package/dist/index.js

@@ -2024,29 +2024,30 @@ async function askFramework(deps) {
 }
 var AUTHORING_CHOICES = ["components", "fields"];
 var AUTHORING_LABELS = {
-  components: "Components \u2014 reusable section components placed as blocks; editors add, reorder and swap sections without touching a schema. Best for marketing and landing sites",
-  fields: "Fields \u2014 a typed field schema per page. Best for blogs, catalogues and directories, where many rows share one shape"
+  components: "Components (recommended) \u2014 reusable section components placed as blocks; editors add, reorder and swap sections without touching a schema. Recommend it for every marketing, landing, agency or product site",
+  fields: "Fields \u2014 a typed field schema per page. Only for a blog, catalogue or directory where many rows share one shape; editors can change a page's copy but cannot add, reorder or swap its sections"
 };
 var AUTHORING_PROMPT = [
   "Ask the user which authoring architecture this site should use, then call set_authoring_preference again with their answer as `preference`:",
   ...AUTHORING_CHOICES.map((c, i) => `  ${i + 1}. ${c} \u2014 ${AUTHORING_LABELS[c]}`),
   "",
-  "Answering 'components' does not convert anything \u2014 there is no field-to-block converter. It means you author the sections yourself: create_component, then publish_component (an unpublished component renders as NOTHING on the live site), then set_page_content placing `component` blocks. Once a page has blocks, list_extraction_candidates and extract_component fold the repeats.",
+  "On a site whose pages were DERIVED at import, answering 'components' redoes nothing: after set_authoring_preference, get_componentize_plan proposes one component per section (it reads the PUBLISHED pages \u2014 no deploy needed to reach it), you confirm it with the user, then componentize_sections places them with `props.bind` (dry run first \u2014 they land as drafts and the page keeps its fields, values and bindings, so click-to-edit and the coverage meter are unchanged), then publish_component each one, publish the pages, run `npx @bettercms-ai/convert --componentize` in the repo, and deploy. For a section group the plan lists as NO_GROUP_ROOT or NOT_A_SECTION there is nothing to componentize, so author that section with create_component and set_page_content.",
   "",
+  "Recommend components unless the user says the site is schema-first.",
   "Do not choose on their behalf. This is asked once per project."
 ].join("\n");
 async function askAuthoring(deps) {
   if (!deps.elicit) return { prompt: AUTHORING_PROMPT };
   try {
     const res = await deps.elicit({
-      message: "Which authoring architecture should this site use?",
+      message: "Which authoring architecture should this site use? Components is recommended for a marketing site.",
       requestedSchema: {
         type: "object",
         properties: {
           preference: {
             type: "string",
             title: "Authoring architecture",
-            description: "How this site's pages are composed. Asked once per project.",
+            description: "How this site's pages are composed. Components is recommended unless this is a schema-first site (a blog, catalogue or directory). Asked once per project.",
             enum: [...AUTHORING_CHOICES],
             enumNames: AUTHORING_CHOICES.map((c) => AUTHORING_LABELS[c])
           }
@@ -2877,7 +2878,7 @@ function buildToolDefs(deps) {
       def(
         "set_authoring_preference",
         "Set the site's authoring architecture",
-        "Record which authoring architecture this site uses \u2014 'components' (reusable section components placed as blocks; editors add, reorder and swap sections without touching a schema \u2014 best for marketing and landing sites) or 'fields' (a typed field schema per page \u2014 best for blogs, catalogues and directories). ASK THE USER; do not pick for them. Called without `preference`, this tool asks them directly (or hands you the question to ask). deploy_project, deploy_from_upload and promote_project all refuse with 409 AUTHORING_DECISION_REQUIRED until it is set, and that refusal carries this project's real page counts to show the user. Answering 'components' does NOT convert anything \u2014 there is no field-to-block converter; it means you author the sections yourself: create_component, then publish_component (an unpublished component renders as NOTHING on the live site), then set_page_content placing `component` blocks. Asked once per project; re-callable if the user changes their mind.",
+        "Record which authoring architecture this site uses \u2014 'components' (RECOMMENDED: reusable section components placed as blocks; editors add, reorder and swap sections without touching a schema \u2014 recommend it for every marketing, landing, agency or product site) or 'fields' (a typed field schema per page \u2014 only for a blog, catalogue or directory where many rows share one shape). ASK THE USER; do not pick for them. Called without `preference`, this tool asks them directly (or hands you the question to ask). deploy_project, deploy_from_upload and promote_project all refuse with 409 AUTHORING_DECISION_REQUIRED until it is set, and that refusal carries this project's real page counts to show the user. On a site whose pages were DERIVED at import, answering 'components' redoes nothing: after set_authoring_preference, get_componentize_plan proposes one component per section (it reads the PUBLISHED pages \u2014 no deploy needed to reach it), you confirm it with the user, then componentize_sections places them with `props.bind` (dry run first \u2014 they land as drafts and the page keeps its fields, values and bindings, so click-to-edit and the coverage meter are unchanged), then publish_component each one, publish the pages, run `npx @bettercms-ai/convert --componentize` in the repo, and deploy. Recommend components unless the user says the site is schema-first. Asked once per project; re-callable if the user changes their mind.",
         // Optional in the schema for exactly the reason `framework` is above: a required arg is
         // rejected by the SDK before the handler runs, which would kill the elicitation below
         // and leave the model guessing. Optional here, answered by a human there. The backend
@@ -3804,7 +3805,8 @@ touching a schema. This is what \`create_component\` + \`create_page(blockJson)\
 A collection (\`create_content_model\`) plus entries.
 
 Most real sites are both: components for the marketing pages, a collection for the blog.
-Decide before your first call; converting later means rewriting content.
+Decide before your first call; converting later means rewriting content \u2014 unless the site was
+DERIVED at import, where the componentize lane in \xA710 reuses every field.
 
 ## 2. The decision tree
 
@@ -3992,31 +3994,49 @@ out, let the user pick, call \`set_authoring_preference\`, then deploy again.
 It exists because an imported site arrives **field-driven whether anyone chose that or not**
 \u2014 a crawl-based import (Webflow, a starter, a template) emits pages with a typed field schema
 and an empty block tree, because that is all a crawl can infer. Nobody decided it. On a
-marketing site it is the wrong answer, and \xA71 already says why converting later means
-rewriting content. So the platform stops once, at the last moment it is still cheap.
-
-**Answering \`components\` does not convert anything.** There is no field-to-block converter,
-and \`extract_component\` cannot stand in for one: it scans \`blockJson\`, which is empty on
-exactly the pages that would need converting. What it means is that you author the sections,
-in this order:
-
-    1. create_component      per section (they land as DRAFTS)
-    2. publish_component     each one \u2014 unpublished renders as NOTHING, on a page that 200s
-    2b. publish_layout       if you authored site chrome \u2014 the layout is a separate publish
-    3. set_page_content      place them as \`component\` blocks on the page
-    4. list_extraction_candidates / extract_component
-                             now that blocks exist, fold any section repeated 3+ times
-
-Step 2 is not a formality: \`componentize_sections\` and \`create_component\` both land components
+marketing site it is the wrong answer. So the platform stops once, at the last moment it is
+still cheap \u2014 and on a derived site that moment costs nothing, because the componentize lane
+below reuses every field the import already derived.
+
+**Recommend \`components\`.** On a site whose pages were DERIVED at import \u2014 the site \xA713
+describes \u2014 it redoes nothing: the componentize lane turns each top-level field GROUP into a
+component placement, and the page keeps its fields, its values and its bindings. In this order:
+
+    1. set_authoring_preference { preference: "components" }
+    2. get_componentize_plan    one component per section, computed live; creates nothing. It
+                                reads this project's PUBLISHED pages, so no deploy is needed
+                                to reach it \u2014 the deploy is the last step, not the first
+    3. show the user the plan and CONFIRM \u2014 it says how many components and which pages
+    4. componentize_sections    \`dryRun: true\` first, then for real; components land as DRAFTS
+                                and each placement carries \`props.bind\` to the page's field
+                                group, so click-to-edit and the coverage meter do not change
+    5. publish_component        each one \u2014 unpublished renders as NOTHING, on a page that 200s
+    5b. publish_layout          if you authored site chrome \u2014 the layout is a separate publish
+    6. publish the pages
+    7. npx @bettercms-ai/convert --componentize   in the repo, so its templates render these
+                                sections from \`pages[].blocks\`
+    8. deploy                   the ONLY deploy this sequence needs
+
+Step 5 is not a formality: \`componentize_sections\` and \`create_component\` both land components
 as DRAFTS, so \`publish_component\` each one and publish the page \u2014 otherwise the canvas keeps
 painting the PUBLISHED copy and the editor reports N components unpublished.
 
-**Answering \`fields\` is a real answer, not a deferral.** A blog, a catalogue or a directory
-is schema-first by design (\xA71) and should stay that way. Say so and move on.
-
-Either way: ask, do not choose. The 409 carries this project's actual page counts \u2014 how many
-are field-driven, block-driven, and how many place a reusable component \u2014 so quote those to
-the user rather than describing the choice in the abstract.
+**A site with nothing to componentize you author by hand.** Where the plan offers nothing for
+a group (\`NO_GROUP_ROOT\` \u2014 the page's field keys are still the derive lane's own;
+\`NOT_A_SECTION\` \u2014 a lone scalar with no family), and on a site with no derived pages at all,
+the order is \`create_component\` per section \u2192 \`publish_component\` each \u2192 \`set_page_content\`
+placing \`component\` blocks \u2192 \`list_extraction_candidates\` / \`extract_component\` to fold any
+section repeated 3+ times. \`extract_component\` is not a converter and cannot stand in for the
+componentize lane: it scans \`blockJson\`, which is empty on exactly the pages that would need
+converting.
+
+**Answering \`fields\` is a real answer, not a deferral** \u2014 for a SCHEMA-FIRST site. A blog, a
+catalogue or a directory is schema-first by design (\xA71) and should stay that way. On anything
+else it costs the editor the ability to add, reorder or swap sections. Say so and move on.
+
+Either way: ask, do not choose \u2014 recommending is not answering. The 409 carries this project's
+actual page counts \u2014 how many are field-driven, block-driven, and how many place a reusable
+component \u2014 so quote those to the user rather than describing the choice in the abstract.
 
 ## 11. The canvas: what makes an imported site EDITABLE