@bettercms-ai/mcp 0.47.0 → 0.49.0

package/dist/index.js

@@ -1991,8 +1991,8 @@ var STRUCTURE_EXAMPLE_PAYLOAD = {
   doc: {
     schema: 1,
     folders: [
-      { id: "home:pages", parentId: null, name: "Static pages", icon: "files", sort: -3 },
-      { id: "home:collections", parentId: null, name: "Other content", icon: null, sort: -2 },
+      { id: "home:pages", parentId: null, name: "Other pages", icon: "files", sort: 1e3 },
+      { id: "home:collections", parentId: null, name: "Shared", icon: null, sort: 1001 },
       { id: "fld_std_blog", parentId: null, name: "Blog posts", icon: "newspaper", sort: 0 },
       { id: "fld_std_products", parentId: null, name: "Products", icon: "shopping-bag", sort: 1 }
     ],
@@ -2028,30 +2028,36 @@ ever changes.
 2. **Pinned at the top:** the home page, then each collection's LIST page (the dynamic page that
    lists it, e.g. /blog). A single document opens straight into the editor, so it is a pin, not a
    folder with one page in it.
-3. **One folder per content family.**
+3. **One folder per content family, named for the DETAIL type its route holds.** /blog gives
+   "Blog posts", /case-studies "Case studies", /careers "Jobs".
    - Blog: a "Blog posts" folder holding the blog collection. A folder with exactly one
      collection opens that collection's table directly.
    - Commerce: a "Products" folder holding the product collection AND its taxonomies (product
-     categories, product tags, materials, colours, sizes, merch collections, ...).
+     categories, product tags, merch collections, ...). Once there are more than four taxonomies,
+     the VARIANT OPTIONS (colours, sizes, materials) move into an "Attributes" subfolder; the
+     categories and tags stay beside the catalogue.
    - Decide the rest by the REFERENCE GRAPH: a collection that is referenced only by one family,
      or that references only one family (reviews \u2192 products), belongs in that family's folder.
      The family's main collection comes first, then the others in the order its fields reference
      them.
-4. **Other pages.** Standalone static pages go in the system folder \`home:pages\` ("Static
-   pages"). Code-only routes (a 404, a page built by code with nothing to edit) stay there too,
-   marked with the \`file-code\` icon. Pages that share a route (/legal/terms, /legal/privacy) get
-   a subfolder of Static pages; a large route family or one named for what it is (/docs/...) gets
-   its own top-level folder.
-5. **Shared taxonomies.** A vocabulary several families reference (Tags used by posts AND
-   products) goes in the system folder \`home:collections\`, named "Other content". So does
-   supporting content no family owns (testimonials, FAQs with no list page).
-6. **Icons** (lucide names): \`newspaper\` for posts, \`shopping-bag\` for products, \`book-open\`
-   for docs, \`files\` for Static pages, \`folder\` by default.
-7. **Depth:** nest at most 2 levels by default. The hard limit is 4; do not use it without a
+4. **Family order:** the site's navigation order; failing that, entry count, then name.
+5. **Other pages.** EVERY remaining standalone page goes in the system folder \`home:pages\`
+   ("Other pages") \u2014 no standalone page ever gets a top-level folder. Code-only routes (a 404, a
+   page built by code with nothing to edit) stay there too, marked with the \`file-code\` icon.
+   Pages that share a route (/legal/terms, /legal/privacy, /docs/...) get a subfolder of it.
+6. **Shared taxonomies.** A vocabulary several families reference (Tags used by posts AND
+   products) goes in the system folder \`home:collections\`, named "Shared". So does supporting
+   content no family owns (testimonials, FAQs with no list page).
+7. **Settings closes the sidebar.** \`home:globals\` ("Settings") holds NO pages or collections \u2014
+   navigation, header, footer, site settings and SEO defaults open from it in the dashboard. The
+   three system folders always sort BELOW the folders you make: \u2026 Other pages, Shared, Settings.
+8. **Icons** (lucide names): \`newspaper\` for posts, \`shopping-bag\` for products, \`book-open\`
+   for docs, \`files\` for Other pages, \`folder\` by default.
+9. **Depth:** nest at most 2 levels by default. The hard limit is 4; do not use it without a
    reason the user gave you.
-8. **Organisation only.** Never rename a page, change a slug, touch a schema or move content to
+10. **Organisation only.** Never rename a page, change a slug, touch a schema or move content to
    make a structure fit. The structure fits the site, not the other way round.
-9. **Page-bound models are not collections.** A page with fields has a content model bound to
+11. **Page-bound models are not collections.** A page with fields has a content model bound to
    it; it is never filed (400 \`NAV_PAGE_BOUND_MODEL\`). Organise the PAGE.
 
 ## The workflow
@@ -2084,14 +2090,15 @@ collection (\`cm_posts\`), a /shop list page (\`pg_shop\`, dynamic) for Products
 [pinned page] Home
 [pinned page] Blog            (/blog lists Blog)
 [pinned page] Shop            (/shop lists Products)
-[system folder] Static pages  icon=files
-  About, Contact, Not found (icon=file-code)
-[system folder] Other content
-  Tags                        (referenced by Blog AND Products: shared)
 [folder] Blog posts           icon=newspaper
   Blog
 [folder] Products             icon=shopping-bag
   Products, Product categories, Colours   (referenced only by Products)
+[system folder] Other pages   icon=files
+  About, Contact, Not found (icon=file-code)
+[system folder] Shared
+  Tags                        (referenced by Blog AND Products: shared)
+[system folder] Settings      (navigation, header, footer, site settings, SEO defaults)
 \`\`\`
 
 The exact \`set_content_structure\` payload (\`version: 0\` because the project had no structure):
@@ -2403,7 +2410,7 @@ function toField(f) {
     ...f.config ? { config: f.config } : {}
   };
 }
-var STRUCTURE_NOTE = 'ORGANISATION ONLY: folders never change a URL, slug, content or publish state, and nothing is rebuilt or delivered. Folders nest at most 4 levels deep (a page or collection may sit in a level-4 folder). Icons are lucide icon names, e.g. "folder", "file-text", "rows-3", "house" (a-z, 0-9 and dashes); null clears one. SYSTEM FOLDERS (CPO-129): "home:pages" (Static pages), "home:collections" (Collections) and "home:globals" (Globals) always exist, even when the document has no record for them. They stay at the top level and can never be moved or deleted (400 NAV_SYSTEM_FOLDER), but rename_folder and set_icon work on them and create their record on first use. TYPE PURITY: anything inside Static pages, at any depth, must be a page, and anything inside Collections must be a collection, and Globals holds NO pages or collections at all, because globals are not sidebar items (subfolders under Globals are allowed but stay empty). Any of these is 400 NAV_TYPE_MISMATCH. Your own folders hold either kind. ACCESS (CPO-131): Requires Admin or Developer access to CHANGE the structure, the same access as editing the schema; anyone who can read content can call get_content_structure. A 403 SCHEMA_ACCESS_REQUIRED means the person behind this connection is not an Admin or Developer: stop and tell the user, do not retry. ROOT PINS (CPO-132): folderId \'root\' pins a page or collection at the top level; null returns it to its home (Static pages / Collections). Pins sit above the folders, in their own order, and may be pages or collections. In a document a pin is folderId "home:root", a virtual id with no folder record (a folder record with that id is 400 NAV_SYSTEM_FOLDER). KIND CHECK: an id is either a page or a collection, never both, and a custom folder holds either \u2014 so move_to_folder and set_icon VERIFY that the id really is the `kind` you named on this branch, and refuse a mismatch with 400 NAV_KIND_MISMATCH naming the kind to use; call it again with that kind, which also clears the wrong-kind entry. An id that resolves to nothing is allowed (it may exist on another branch) and the result says so. set_content_structure never refuses: it returns `warnings` and `kindMismatches`. get_content_structure marks such items `kindMismatch: true` and lists them in `summary.kindMismatches`. PAGE-BOUND MODELS (CPO-135): a page with fields has a content model bound to it. That model is NOT a collection \u2014 get_content_structure never lists it among collections or in the tree, and move_to_folder / set_icon / set_content_structure refuse it with 400 NAV_PAGE_BOUND_MODEL naming the owning page (\'This model belongs to the page "\u2026"; organise the page.\'). Organise the PAGE instead, by its page id. If a stored document still references one it appears in `summary.hiddenItems` with `boundToPageId`, and the next single write drops it.';
+var STRUCTURE_NOTE = 'ORGANISATION ONLY: folders never change a URL, slug, content or publish state, and nothing is rebuilt or delivered. Folders nest at most 4 levels deep (a page or collection may sit in a level-4 folder). Icons are lucide icon names, e.g. "folder", "file-text", "rows-3", "house" (a-z, 0-9 and dashes); null clears one. SYSTEM FOLDERS (CPO-129): "home:pages" (Other pages), "home:collections" (Shared) and "home:globals" (Settings) always exist, even when the document has no record for them. They close the sidebar, below the folders you make, and can never be moved or deleted (400 NAV_SYSTEM_FOLDER), but rename_folder and set_icon work on them and create their record on first use. TYPE PURITY: anything inside Other pages, at any depth, must be a page, and anything inside Shared must be a collection, and Settings holds NO pages or collections at all, because globals are not sidebar items (subfolders under Settings are allowed but stay empty). Any of these is 400 NAV_TYPE_MISMATCH. Your own folders hold either kind. ACCESS (CPO-131): Requires Admin or Developer access to CHANGE the structure, the same access as editing the schema; anyone who can read content can call get_content_structure. A 403 SCHEMA_ACCESS_REQUIRED means the person behind this connection is not an Admin or Developer: stop and tell the user, do not retry. ROOT PINS (CPO-132): folderId \'root\' pins a page or collection at the top level; null returns it to its home (Other pages / Shared). Pins sit above the folders, in their own order, and may be pages or collections. In a document a pin is folderId "home:root", a virtual id with no folder record (a folder record with that id is 400 NAV_SYSTEM_FOLDER). KIND CHECK: an id is either a page or a collection, never both, and a custom folder holds either \u2014 so move_to_folder and set_icon VERIFY that the id really is the `kind` you named on this branch, and refuse a mismatch with 400 NAV_KIND_MISMATCH naming the kind to use; call it again with that kind, which also clears the wrong-kind entry. An id that resolves to nothing is allowed (it may exist on another branch) and the result says so. set_content_structure never refuses: it returns `warnings` and `kindMismatches`. get_content_structure marks such items `kindMismatch: true` and lists them in `summary.kindMismatches`. PAGE-BOUND MODELS (CPO-135): a page with fields has a content model bound to it. That model is NOT a collection \u2014 get_content_structure never lists it among collections or in the tree, and move_to_folder / set_icon / set_content_structure refuse it with 400 NAV_PAGE_BOUND_MODEL naming the owning page (\'This model belongs to the page "\u2026"; organise the page.\'). Organise the PAGE instead, by its page id. If a stored document still references one it appears in `summary.hiddenItems` with `boundToPageId`, and the next single write drops it.';
 function structureResult(d) {
   const message = d?.message;
   return ok(typeof message === "string" ? message : "Updated the Content structure.", d);
@@ -3077,7 +3084,7 @@ ${d.summary.outline}` : "Content structure.", d);
       def(
         "suggest_content_structure",
         "Propose the standard Content structure",
-        `READ-ONLY: propose the standard Content sidebar structure for the connected project (${STRUCTURE_PLAYBOOK_URI}) and write NOTHING. Runs the platform's own implementation of the standard over the project's pages, collections, their references and the routes its build serves: the home page and each collection's list page pinned at the top, one folder per content family (Blog posts, Products with its taxonomies, grouped by the reference graph), shared taxonomies in Other content, standalone and code-only pages in Static pages, at most 2 levels deep. Page-bound models are never filed. Returns { doc, version, hasDocument, outline, rationale }. To apply it: show the user the outline, then call set_content_structure with this doc and this version (the If-Match; a 412 means someone changed the sidebar, so suggest again). When hasDocument is true the project already has a structure somebody made: never replace it without the user's yes; file only what is new with move_to_folder instead.`,
+        `READ-ONLY: propose the standard Content sidebar structure for the connected project (${STRUCTURE_PLAYBOOK_URI}) and write NOTHING. Runs the platform's own implementation of the standard over the project's pages, collections, their references and the routes its build serves: the home page and each collection's list page pinned at the top, one folder per content family named for the detail type its route holds (Blog posts, Case studies, Jobs, Products with its taxonomies and an Attributes subfolder for its variant options), ordered by entry count (or the site navigation, when the caller supplies its link order), shared taxonomies in Shared, every remaining standalone and code-only page in Other pages, at most 2 levels deep. Page-bound models are never filed. Returns { doc, version, hasDocument, outline, rationale }. To apply it: show the user the outline, then call set_content_structure with this doc and this version (the If-Match; a 412 means someone changed the sidebar, so suggest again). When hasDocument is true the project already has a structure somebody made: never replace it without the user's yes; file only what is new with move_to_folder instead.`,
         z.object({
           maxDepth: z.number().int().min(1).max(4).optional().describe("folder nesting to propose; default 2 (the standard), 4 is the hard limit")
         }).shape,
@@ -3104,7 +3111,7 @@ ${d.outline}` : "Proposed Content structure.", d);
             items: z.array(z.object({
               kind: z.enum(["page", "collection"]),
               id: z.string().min(1).describe("page id or collection (content model) id"),
-              folderId: z.string().nullable().describe('folder id; "home:root" = pinned at the top level; null = its home (Static pages for a page, the Collections list for a collection)'),
+              folderId: z.string().nullable().describe('folder id; "home:root" = pinned at the top level; null = its home (Other pages for a page, the Shared list for a collection)'),
               sort: z.number(),
               icon: z.string().nullable()
             }))
@@ -3137,11 +3144,11 @@ ${d.outline}` : "Proposed Content structure.", d);
       def(
         "move_to_folder",
         "Move into a Content sidebar folder",
-        `Move a page, a collection or a folder into a folder. folderId null moves it back to its home: Static pages for a page, the Collections list for a collection, the top level for a folder. It lands after what is already there. Moving a folder takes its contents with it and is refused if the result would nest deeper than 4 levels or put a folder inside itself. ${STRUCTURE_NOTE}`,
+        `Move a page, a collection or a folder into a folder. folderId null moves it back to its home: Other pages for a page, the Shared list for a collection, the top level for a folder. It lands after what is already there. Moving a folder takes its contents with it and is refused if the result would nest deeper than 4 levels or put a folder inside itself. ${STRUCTURE_NOTE}`,
         z.object({
           kind: z.enum(["page", "collection", "folder"]),
           id: z.string().min(1).describe("the page id, collection (content model) id, or folder id"),
-          folderId: z.string().min(1).nullable().describe("target folder id; 'root' pins a page or collection at the top level (for a folder, 'root' is the top level); null moves it back to its home (Static pages, the Collections list, or the top level for a folder)")
+          folderId: z.string().min(1).nullable().describe("target folder id; 'root' pins a page or collection at the top level (for a folder, 'root' is the top level); null moves it back to its home (Other pages, the Shared list, or the top level for a folder)")
         }).shape,
         async (c, a) => structureResult(await data(c, "POST", `/management/content-structure/move`, { kind: a.kind, id: a.id, folderId: a.folderId }))
       ),
@@ -6062,7 +6069,7 @@ function buildServer(deps) {
     STRUCTURE_PLAYBOOK_URI,
     {
       title: "BetterCMS Content structure playbook",
-      description: "How to organise a project's Content sidebar: one place per document, the home page and list pages pinned, one folder per content family grouped by the reference graph, shared taxonomies in Other content, Static pages for the rest, at most 2 levels. With a worked set_content_structure payload.",
+      description: "How to organise a project's Content sidebar: one place per document, the home page and list pages pinned, one folder per content family named for the detail type its route holds and ordered by entry count, shared taxonomies in Shared, Other pages for the rest, Settings last, at most 2 levels. With a worked set_content_structure payload.",
       mimeType: "text/markdown"
     },
     () => ({