@bettercms-ai/mcp 0.83.0 → 0.83.1

package/dist/skills/bettercms/references/componentize.md

@@ -1,185 +1,185 @@
----
-title: "Componentizing a site"
-description: "Turn a derived, fields-only site into sections backed by components: reading the plan, confirming it, applying it, and the repository half with its receipt."
----
-
-# Componentizing a site, and deciding what each band becomes
-
-Read with [components.md](components.md); § numbers below are that file's. Doctrine: §10 of
-`bettercms://playbook/schema`.
-
-## 1. Classify every band first
-
-Look at the source component, the rendered band, its CSS and its props on every route before
-deciding. Matching copy or a shared class name does not make two bands one component.
-
-| Band | Becomes |
-|---|---|
-| Navigation, footer, a truly sitewide bar | Chrome: a component in the Global Layout (§4) |
-| Same structure and the same editor fields on several pages | One component; layout differences are variants of one `sectionType` |
-| Different content contract (other fields, other order) | Its own family, even when it looks alike |
-| Genuinely unique | Still a section: a one-off `section` block or a single-use component |
-| Card, button, badge, quote inside a section | Part of that section: a `group`/`table` prop, or a nested component |
-
-Inside a section, pick the smallest shape that holds the children:
-
-- **Small identical items** (FAQ rows, feature bullets, logos): a `group` or `table` prop.
-- **One replaceable child with its own layout or variants** (a hero's media treatment): a `slot`
-  prop. It holds one instance, and never sits inside a `group` or `table` row.
-- **Several different children**: the section's ordered children when the set is fixed; a `slot`
-  prop with `config.multiple` when the editor picks and orders them.
-
-Never let a component contain itself, directly or through a child.
-
-## 2. The componentize lane (a site whose pages `editor_setup` derived)
-
-1. `get_componentize_plan { summary: true }` first (no values; the full plan is hundreds of KB,
-   and `paged: true` reads it 10 pages at a time). It creates nothing and is computed live from
-   the PUBLISHED pages. Each field group is one section, and every page gets its OWN components
-   (`home-hero`, `about-hero`); a locale copy reuses its default page's. A collection template
-   (`pattern: "{slug}"`) is planned once and every prop reads the entry being rendered: only its
-   prose body and lists of object rows are sections. Read `pending` for what it will not offer:
-   `NO_GROUP_ROOT` (keys are still the derive lane's own, such as `h1-welcome`: rename them into
-   families first), `NOT_A_SECTION` (a lone scalar or page metadata; `detail: ENTRY_METADATA` is
-   a template's frontmatter: author, images, tags and dates stay entry fields; `detail: DECLINED`
-   is a group the user declined) and `IMAGE_AS_TEXT` (a text field holding an image path; it plans
-   once the field is an image). A nav, footer or
-   modal group is `NOT_A_SECTION` with `detail: LAYOUT_CHROME`: chrome is the Layout on every
-   site, never a page band. Author the real sections among those with `create_component` and
-   `set_page_content` instead. The other codes need no decision: `ALREADY_COMPONENTIZED` (a
-   placement exists), `EMPTY_GROUP` (no field holds a value), `NESTED_REPEATER` (a repeater three
-   deep; two levels become a nested `table` sub-field) and `PAGE_NOT_EMPTY` (the page holds
-   blocks this lane does not own, and it will not overwrite them).
-2. Show the user the sections, how many components it creates and which pages it rewrites.
-   Confirm before writing. A group the user says is not a section: `componentize_sections
-   { digest, sections: [groupKey], pageIds, decline: true }` (`decline: false` undoes it). The
-   plan is done when it proposes nothing that was not declined.
-3. `componentize_sections` with the plan's `digest` and `dryRun: true`. Read
-   `components.wouldDuplicate` (§8). A 409 `stale-plan` means the site changed: read the plan
-   again and confirm again. Then run it for real.
-4. What it writes: each component as a DRAFT, and each page's draft blocks as an ordered list of
-   instances. By default each instance carries `props.bind` and the words stay in the page's
-   field group, so bindings and the coverage meter do not move. `copy: "instance"` is the
-   page-builder model: each placement takes its group's CURRENT draft values into its own
-   `props.overrides` (a repeater becomes one `table` prop holding every row), records the page
-   path each came from in `props.source`, and drops `props.bind`. The old fields are kept and
-   marked `origin: "componentized"`; nothing is deleted. Running it twice is safe: an existing placement comes back as
-   `ALREADY_COMPONENTIZED`.
-5. `publish_component` for each, then publish the pages. An unpublished component renders
-   nothing on the live site.
-6. The repository half. With no checkout, `componentize_sections { digest, codemod: true }` runs
-   the section-order codemod on the repo's own Actions (`skipped` means there is no repo it may
-   commit to). In a checkout, run the codemod with `--componentize` and a `--receipt` file, commit
-   and push the files it wrote, and hand that receipt verbatim to `submit_componentize_receipt`. It records
-   each extracted section as the source of the component with the same slug, so no
-   `set_component_source` per component is needed. Deploy. A page whose bands could not be
-   lifted is wrapped where it stands instead (§5).
-7. Output validation, from step 3 of §6.
-8. Editor chrome, last and not optional: the components this lane made have bare props. Load
-   [editor-chrome.md](editor-chrome.md) and run step 8 of the repair order in
-   [finish-site.md](finish-site.md) for each one; `extract_component` ends the same way.
-
-## 3. Names and groups
-
-The import's kit entry (`kit: suggested <id> <score>`, the `hint` of its row in `receipt.gate.kit`) is only a suggestion: nothing is recorded, and nothing waits on it. The props already carry the ui that suggestion gives. For each component, read `bettercms://kit/entry/{id}`, check its `htmlSignals` against the section's own HTML and its pitfalls against the props, then confirm it or pick the right one from its category in `bettercms://kit` and name it with `update_component { kitEntry }`. Setting or changing `kitEntry` puts that entry's ui over the derived ui: where the entry specifies a tab, group, control or preview key for a prop, the entry wins; what it says nothing about stays as derived; ui you or a person set is kept. It also carries the entry's rules (showIf, limits, patterns, options, required) onto props that have none of their own. A component whose props still lack some gets a `gate.kit` row with `drift` listing each one as `path.key=value`: add them with `update_component { props }`, or record `kit-drift-accepted` with a note. The `no-kit-match` exemption needs a note.
-
-Name a family by what it is (`Hero`, `CTA`, `Testimonials`) and each variant by how it looks
-(`Hero / Split`, `CTA / Centered`). Never put a page name in a reusable definition; which pages
-use it is a usage question (§8). The componentize lane files a section under its page's slug
-(`home-hero`) but keeps the name the section's own (`Hero`). Its components go into the Component
-Group you pass as `group` (a folder of the dashboard's Components tab), else into one named for
-the section family: nav, header, footer or menu into Layout, an unnamed section into Sections,
-any other into the family's own name (Hero, FAQ). Keep related fields together in the
-order an editor reads them:
-
-```text
-Hero / Split
-  Heading · Description
-  Primary button: Label · Link · Style
-  Secondary button: Label · Link · Style
-  Image: Asset · Alt text
-```
-
-Expose variants and style tokens, never raw class names, CSS strings or HTML.
-
-**Name props from the code, not the copy.** An import labels a prop by its role (`Text`,
-`Heading`) and writes its help from that role, and older imports by the copy itself (`.00`).
-Read the section's source and use its own names: `pricing.starterKit.cents` → `Cents`,
-`billingFrequency` → `Billing frequency`. Where you know more than the role does, write the
-prop's help text: what it is for, where it shows, any limit ("Shown after the price, such as per
-month."), never its label or value again. Apply both in one `update_component` call: `propLabel` and
-`propHelpText`, keyed by prop key. Repeated cards (plans, features, team members) are ONE `table`
-prop whose rows are the cards (`Plans`: Name · Description · Price · Cents · Billing frequency ·
-Features · Button), never a set of props per card, so an editor opens one plan at a time and can
-add a third. `get_next_steps` lists `labels-are-copy` until every field is named.
-
-## 4. Proof, per family
-
-A write that returned 200 proves nothing about the page. For each family, check in the preview
-and after publish:
-
-- one default edit reaches every instance without an override, and no other;
-- one instance override changes only that placement;
-- one variant swap keeps the content (read the swap warnings, §3);
-- one nested child edit stays inside its own instance;
-- one chrome edit reaches every route.
-
-Then `get_binding_report` and `get_site_composition` (§9).
-
-## 5. The page wrap (`--sections`): sections that stay in the site's code
-
-Lifting a band into a component (§2) needs an inline run and a plan. A page built from imported
-section components with props has neither, and it does not need them: `--sections` wraps the
-page's top-level sections in `<BcmsSections>`, one named slot each, so the site's own build draws
-them in the CMS page's order, with each block's spacing and style, and draws a section added in
-the editor between them. It changes no section's markup, props, classes or styles.
-
-`bettercms init` runs it before the agent starts and commits it locally
-(`chore(bettercms): render sections from BetterCMS`); the dispatch of step 6 runs it after
-`--componentize`. Do not redo or revert that commit. Pushing it is the user's decision. To run
-it yourself, in a clean checkout:
-
-```sh
-npx @bettercms-ai/convert --sections --root . --dry-run   # the plan, per page
-npx @bettercms-ai/convert --sections --root .
-npx @bettercms-ai/convert --verify-styles --root .        # must report no style edits
-```
-
-A page file that only draws a view component (`<HomeView locale="en" />`) is wrapped in the
-view's file, where its sections are written; the dry run names that file per page, and the page
-itself only gains the prop that tells the view which page it is ([astro.md](astro.md),
-[next.md](next.md)). A lone component that is itself one section is wrapped in the page.
-
-A page it leaves alone keeps rendering as before, and is listed with one of these:
-
-| Reason | The page | What you do |
-|---|---|---|
-| `SECTION_RUN_NOT_FOUND` | Returns markup from several places, or has loose text between sections | Give it one root, wrap loose text in an element, run again; or write the wrap by hand |
-| `SECTION_RUN_NOT_CONTIGUOUS` | A child with `slot="…"`, a `<script>` or a `<style>` sits between two sections | Move it above or below the sections, run again |
-| `SECTIONS_IN_LAYOUT` | Gives its layout no children: the layout draws the sections | Move the sections into the page, or wrap them by hand in the layout for that one page |
-| `SECTION_RUN_DYNAMIC` | A `[slug]` route no collection page has for its item template (a parameter above the last segment, or no collection at that path) | Nothing: its sections stay in code. A collection's own `[slug]` file is wrapped once, for the collection page, and every entry draws that list |
-| `CLIENT_COMPONENT` | A `"use client"` page that exports more than the page | Move those exports to a server file and run it again. Any other client page is wrapped: it moves into `page.client.tsx` and its page file becomes the server parent that reads the order |
-| `PAGE_PROPS_IN_USE` | Pages Router page on `getInitialProps`, a data function it only re-exports, or a rest parameter | Add `bcmsSections` to its props by hand ([next.md](next.md)) |
-| `PAGE_UNKNOWN` | No CMS page for the route | Create and publish the page, run again |
-| `DIALECT_UNSUPPORTED` | Markdown, MDX or HTML | Nothing: the body is one `document` field |
-| `NAME_TAKEN` | Already uses the name `BcmsSections` for something else | Rename that, run again |
-| `SDK_REQUIRED` | The repo's SDK predates the component | Add `--add-sdk`, install, run again |
-| `VIEW_IMPORT_UNRESOLVED` | Draws one component, and its import names no file: an alias no tsconfig or jsconfig of the repository declares (one inherited through `extends` is not read) | Declare the alias in the config's own `compilerOptions.paths`, or import the view by a relative path; run again |
-| `VIEW_DEPTH_EXCEEDED` | Its sections are more than three components below the page | Wrap by hand in the file that writes them, and pass the page down ([astro.md](astro.md), [next.md](next.md)) |
-| `VIEW_SHARED_INCOMPATIBLE` | Draws a view another page draws too, and the CMS names the view's sections differently on the two (or one is a page and the other a collection's item template, in Astro) | Give each page a view of its own, or make the two CMS pages place the same binds, then run again |
-
-The by-hand markup is in [astro.md](astro.md) and [next.md](next.md), and it follows the rules of
-[animation.md](animation.md) §10: slot tags around sections you do not edit, no new element. On
-a wrapped page two notes ask for a hand edit. `ROOT_IS_COMPONENT` (Next): the section moves and
-takes its spacing on a box around it, which is one block box once styled; write its child as a
-function and spread the root props on the component's root element to style the root itself.
-`EXPRESSION`: a `.map()` or a conditional is ONE section; to move its rows separately, give each
-row its own slot.
-
-Slots are written `code:<bind>` unless the page already places that bind; a `code:` slot is
-never removed by the list. After the page's placements exist, run `--sections` again (or
-`bettercms init`): it writes those slots bare, and from then on removing the block removes the
-section. Any other framework gets `FRAMEWORK_UNSUPPORTED` and no write.
-
-Check: after the build, the route's row in `get_binding_report` reads `stamped` equal to `placed`
-and `ordered: true`.
+---
+title: "Componentizing a site"
+description: "Turn a derived, fields-only site into sections backed by components: reading the plan, confirming it, applying it, and the repository half with its receipt."
+---
+
+# Componentizing a site, and deciding what each band becomes
+
+Read with [components.md](components.md); § numbers below are that file's. Doctrine: §10 of
+`bettercms://playbook/schema`.
+
+## 1. Classify every band first
+
+Look at the source component, the rendered band, its CSS and its props on every route before
+deciding. Matching copy or a shared class name does not make two bands one component.
+
+| Band | Becomes |
+|---|---|
+| Navigation, footer, a truly sitewide bar | Chrome: a component in the Global Layout (§4) |
+| Same structure and the same editor fields on several pages | One component; layout differences are variants of one `sectionType` |
+| Different content contract (other fields, other order) | Its own family, even when it looks alike |
+| Genuinely unique | Still a section: a one-off `section` block or a single-use component |
+| Card, button, badge, quote inside a section | Part of that section: a `group`/`table` prop, or a nested component |
+
+Inside a section, pick the smallest shape that holds the children:
+
+- **Small identical items** (FAQ rows, feature bullets, logos): a `group` or `table` prop.
+- **One replaceable child with its own layout or variants** (a hero's media treatment): a `slot`
+  prop. It holds one instance, and never sits inside a `group` or `table` row.
+- **Several different children**: the section's ordered children when the set is fixed; a `slot`
+  prop with `config.multiple` when the editor picks and orders them.
+
+Never let a component contain itself, directly or through a child.
+
+## 2. The componentize lane (a site whose pages `editor_setup` derived)
+
+1. `get_componentize_plan { summary: true }` first (no values; the full plan is hundreds of KB,
+   and `paged: true` reads it 10 pages at a time). It creates nothing and is computed live from
+   the PUBLISHED pages. Each field group is one section, and every page gets its OWN components
+   (`home-hero`, `about-hero`); a locale copy reuses its default page's. A collection template
+   (`pattern: "{slug}"`) is planned once and every prop reads the entry being rendered: only its
+   prose body and lists of object rows are sections. Read `pending` for what it will not offer:
+   `NO_GROUP_ROOT` (keys are still the derive lane's own, such as `h1-welcome`: rename them into
+   families first), `NOT_A_SECTION` (a lone scalar or page metadata; `detail: ENTRY_METADATA` is
+   a template's frontmatter: author, images, tags and dates stay entry fields; `detail: DECLINED`
+   is a group the user declined) and `IMAGE_AS_TEXT` (a text field holding an image path; it plans
+   once the field is an image). A nav, footer or
+   modal group is `NOT_A_SECTION` with `detail: LAYOUT_CHROME`: chrome is the Layout on every
+   site, never a page band. Author the real sections among those with `create_component` and
+   `set_page_content` instead. The other codes need no decision: `ALREADY_COMPONENTIZED` (a
+   placement exists), `EMPTY_GROUP` (no field holds a value), `NESTED_REPEATER` (a repeater three
+   deep; two levels become a nested `table` sub-field) and `PAGE_NOT_EMPTY` (the page holds
+   blocks this lane does not own, and it will not overwrite them).
+2. Show the user the sections, how many components it creates and which pages it rewrites.
+   Confirm before writing. A group the user says is not a section: `componentize_sections
+   { digest, sections: [groupKey], pageIds, decline: true }` (`decline: false` undoes it). The
+   plan is done when it proposes nothing that was not declined.
+3. `componentize_sections` with the plan's `digest` and `dryRun: true`. Read
+   `components.wouldDuplicate` (§8). A 409 `stale-plan` means the site changed: read the plan
+   again and confirm again. Then run it for real.
+4. What it writes: each component as a DRAFT, and each page's draft blocks as an ordered list of
+   instances. By default each instance carries `props.bind` and the words stay in the page's
+   field group, so bindings and the coverage meter do not move. `copy: "instance"` is the
+   page-builder model: each placement takes its group's CURRENT draft values into its own
+   `props.overrides` (a repeater becomes one `table` prop holding every row), records the page
+   path each came from in `props.source`, and drops `props.bind`. The old fields are kept and
+   marked `origin: "componentized"`; nothing is deleted. Running it twice is safe: an existing placement comes back as
+   `ALREADY_COMPONENTIZED`.
+5. `publish_component` for each, then publish the pages. An unpublished component renders
+   nothing on the live site.
+6. The repository half. With no checkout, `componentize_sections { digest, codemod: true }` runs
+   the section-order codemod on the repo's own Actions (`skipped` means there is no repo it may
+   commit to). In a checkout, run the codemod with `--componentize` and a `--receipt` file, commit
+   and push the files it wrote, and hand that receipt verbatim to `submit_componentize_receipt`. It records
+   each extracted section as the source of the component with the same slug, so no
+   `set_component_source` per component is needed. Deploy. A page whose bands could not be
+   lifted is wrapped where it stands instead (§5).
+7. Output validation, from step 3 of §6.
+8. Editor chrome, last and not optional: the components this lane made have bare props. Load
+   [editor-chrome.md](editor-chrome.md) and run step 8 of the repair order in
+   [finish-site.md](finish-site.md) for each one; `extract_component` ends the same way.
+
+## 3. Names and groups
+
+The import's kit entry (`kit: suggested <id> <score>`, the `hint` of its row in `receipt.gate.kit`) is only a suggestion: nothing is recorded, and nothing waits on it. The props already carry the ui that suggestion gives. For each component, read `bettercms://kit/entry/{id}`, check its `htmlSignals` against the section's own HTML and its pitfalls against the props, then confirm it or pick the right one from its category in `bettercms://kit` and name it with `update_component { kitEntry }`. Setting or changing `kitEntry` puts that entry's ui over the derived ui: where the entry specifies a tab, group, control or preview key for a prop, the entry wins; what it says nothing about stays as derived; ui you or a person set is kept. It also carries the entry's rules (showIf, limits, patterns, options, required) onto props that have none of their own. A component whose props still lack some gets a `gate.kit` row with `drift` listing each one as `path.key=value`: add them with `update_component { props }`, or record `kit-drift-accepted` with a note. The `no-kit-match` exemption needs a note.
+
+Name a family by what it is (`Hero`, `CTA`, `Testimonials`) and each variant by how it looks
+(`Hero / Split`, `CTA / Centered`). Never put a page name in a reusable definition; which pages
+use it is a usage question (§8). The componentize lane files a section under its page's slug
+(`home-hero`) but keeps the name the section's own (`Hero`). Its components go into the Component
+Group you pass as `group` (a folder of the dashboard's Components tab), else into one named for
+the section family: nav, header, footer or menu into Layout, an unnamed section into Sections,
+any other into the family's own name (Hero, FAQ). Keep related fields together in the
+order an editor reads them:
+
+```text
+Hero / Split
+  Heading · Description
+  Primary button: Label · Link · Style
+  Secondary button: Label · Link · Style
+  Image: Asset · Alt text
+```
+
+Expose variants and style tokens, never raw class names, CSS strings or HTML.
+
+**Name props from the code, not the copy.** An import labels a prop by its role (`Text`,
+`Heading`) and writes its help from that role, and older imports by the copy itself (`.00`).
+Read the section's source and use its own names: `pricing.starterKit.cents` → `Cents`,
+`billingFrequency` → `Billing frequency`. Where you know more than the role does, write the
+prop's help text: what it is for, where it shows, any limit ("Shown after the price, such as per
+month."), never its label or value again. Apply both in one `update_component` call: `propLabel` and
+`propHelpText`, keyed by prop key. Repeated cards (plans, features, team members) are ONE `table`
+prop whose rows are the cards (`Plans`: Name · Description · Price · Cents · Billing frequency ·
+Features · Button), never a set of props per card, so an editor opens one plan at a time and can
+add a third. `get_next_steps` lists `labels-are-copy` until every field is named.
+
+## 4. Proof, per family
+
+A write that returned 200 proves nothing about the page. For each family, check in the preview
+and after publish:
+
+- one default edit reaches every instance without an override, and no other;
+- one instance override changes only that placement;
+- one variant swap keeps the content (read the swap warnings, §3);
+- one nested child edit stays inside its own instance;
+- one chrome edit reaches every route.
+
+Then `get_binding_report` and `get_site_composition` (§9).
+
+## 5. The page wrap (`--sections`): sections that stay in the site's code
+
+Lifting a band into a component (§2) needs an inline run and a plan. A page built from imported
+section components with props has neither, and it does not need them: `--sections` wraps the
+page's top-level sections in `<BcmsSections>`, one named slot each, so the site's own build draws
+them in the CMS page's order, with each block's spacing and style, and draws a section added in
+the editor between them. It changes no section's markup, props, classes or styles.
+
+`bettercms init` runs it before the agent starts and commits it locally
+(`chore(bettercms): render sections from BetterCMS`); the dispatch of step 6 runs it after
+`--componentize`. Do not redo or revert that commit. Pushing it is the user's decision. To run
+it yourself, in a clean checkout:
+
+```sh
+npx @bettercms-ai/convert --sections --root . --dry-run   # the plan, per page
+npx @bettercms-ai/convert --sections --root .
+npx @bettercms-ai/convert --verify-styles --root .        # must report no style edits
+```
+
+A page file that only draws a view component (`<HomeView locale="en" />`) is wrapped in the
+view's file, where its sections are written; the dry run names that file per page, and the page
+itself only gains the prop that tells the view which page it is ([astro.md](astro.md),
+[next.md](next.md)). A lone component that is itself one section is wrapped in the page.
+
+A page it leaves alone keeps rendering as before, and is listed with one of these:
+
+| Reason | The page | What you do |
+|---|---|---|
+| `SECTION_RUN_NOT_FOUND` | Returns markup from several places, or has loose text between sections | Give it one root, wrap loose text in an element, run again; or write the wrap by hand |
+| `SECTION_RUN_NOT_CONTIGUOUS` | A child with `slot="…"`, a `<script>` or a `<style>` sits between two sections | Move it above or below the sections, run again |
+| `SECTIONS_IN_LAYOUT` | Gives its layout no children: the layout draws the sections | Move the sections into the page, or wrap them by hand in the layout for that one page |
+| `SECTION_RUN_DYNAMIC` | A `[slug]` route no collection page has for its item template (a parameter above the last segment, or no collection at that path) | Nothing: its sections stay in code. A collection's own `[slug]` file is wrapped once, for the collection page, and every entry draws that list |
+| `CLIENT_COMPONENT` | A `"use client"` page that exports more than the page | Move those exports to a server file and run it again. Any other client page is wrapped: it moves into `page.client.tsx` and its page file becomes the server parent that reads the order |
+| `PAGE_PROPS_IN_USE` | Pages Router page on `getInitialProps`, a data function it only re-exports, or a rest parameter | Add `bcmsSections` to its props by hand ([next.md](next.md)) |
+| `PAGE_UNKNOWN` | No CMS page for the route | Create and publish the page, run again |
+| `DIALECT_UNSUPPORTED` | Markdown, MDX or HTML | Nothing: the body is one `document` field |
+| `NAME_TAKEN` | Already uses the name `BcmsSections` for something else | Rename that, run again |
+| `SDK_REQUIRED` | The repo's SDK predates the component | Add `--add-sdk`, install, run again |
+| `VIEW_IMPORT_UNRESOLVED` | Draws one component, and its import names no file: an alias no tsconfig or jsconfig of the repository declares (one inherited through `extends` is not read) | Declare the alias in the config's own `compilerOptions.paths`, or import the view by a relative path; run again |
+| `VIEW_DEPTH_EXCEEDED` | Its sections are more than three components below the page | Wrap by hand in the file that writes them, and pass the page down ([astro.md](astro.md), [next.md](next.md)) |
+| `VIEW_SHARED_INCOMPATIBLE` | Draws a view another page draws too, and the CMS names the view's sections differently on the two (or one is a page and the other a collection's item template, in Astro) | Give each page a view of its own, or make the two CMS pages place the same binds, then run again |
+
+The by-hand markup is in [astro.md](astro.md) and [next.md](next.md), and it follows the rules of
+[animation.md](animation.md) §10: slot tags around sections you do not edit, no new element. On
+a wrapped page two notes ask for a hand edit. `ROOT_IS_COMPONENT` (Next): the section moves and
+takes its spacing on a box around it, which is one block box once styled; write its child as a
+function and spread the root props on the component's root element to style the root itself.
+`EXPRESSION`: a `.map()` or a conditional is ONE section; to move its rows separately, give each
+row its own slot.
+
+Slots are written `code:<bind>` unless the page already places that bind; a `code:` slot is
+never removed by the list. After the page's placements exist, run `--sections` again (or
+`bettercms init`): it writes those slots bare, and from then on removing the block removes the
+section. Any other framework gets `FRAMEWORK_UNSUPPORTED` and no write.
+
+Check: after the build, the route's row in `get_binding_report` reads `stamped` equal to `placed`
+and `ordered: true`.