@ebitex/content-mcp 1.1.268 → 1.1.271

package/dist/resources/helpCorpus.generated.js

@@ -31,7 +31,7 @@ export const HELP_TOPICS = [
     {
         "slug": "content-composer",
         "title": "Building your site in Composer",
-        "body": "# Building your site in Composer\n\nComposer is where content becomes a website. A **site** is a named tree of\n**pages**; each page's slug (and its ancestors' slugs) form its **path** —\nthe URL it will eventually be served at. A page can be pure structure (a\n**Folder**, with no page of its own, just a place to organize its\nchildren), or it can carry a payload: either a **Presentation** (content\nshown at that path) or a **Redirect** (send visitors somewhere else).\nContracts, Components, and Templates (see\n[Modeling content with Contracts](contracts.md),\n[Authoring Components](components.md), and\n[Presenting content with Templates](templates.md)) define *what* content\nis and *how* it's presented; Composer decides *where* it lives. Nothing\nbuilt here is publicly visible yet — publishing is a later phase.\n\nComposer is the suite's *top-down* authoring surface — site, then tree,\nthen page. [Content](content-authoring.md) is its *bottom-up* counterpart:\nthe Component library, edited independently of any one page. Both appear\nas their own item in the sidebar.\n\n## Choosing a site\n\nComposer's header has a site switcher — select it to see every site in\nthis organization and pick one, or select **Manage sites →** to create,\nrename, or delete a site. Composer's tree always shows exactly one site's\npages at a time; switching sites swaps the whole tree beneath it.\n\nSites themselves are managed from **Settings > Sites**: create a new one\nby name, rename an existing one, or delete one (deleting a site deletes\nits entire page tree, including every page's payload — typing the site's\nname confirms you mean it).\n\n## Building the tree\n\nA large tree can be searched by category — see \"Filtering by category\" in\n[Taxonomy](content-taxonomy.md) for how the tree's own **Filter by\ncategory** control auto-expands to reveal matches without hiding anything\nelse.\n\nTo add a page:\n\n1. Select the parent page (the site's own root, shown at the top of the\n   tree, or any page under it), then select **+ Add page** at the top of\n   the tree panel.\n2. Pick a type — **Presentation**, **Redirect**, or **Folder** —\n   Presentation is pre-selected, since it's what most new pages are for.\n   You can change a page's type at any time later, from its own\n   Experience tab.\n3. Enter a **Name** — the path preview beneath it fills in from it\n   automatically (`/campaigns-launch`, for example). You can give the page\n   a different slug later, from its **Configuration** tab.\n4. Select **Create**.\n\nEvery page shows its computed **path** at the top of the detail panel —\nthe site root's own path is always `/`.\n\n### Localized slugs\n\nA page's slug can have a different value per locale, just like other\nlocalizable content — select the translate icon beside **Slug** (in the\n**Configuration** tab) to add per-locale overrides. Two sibling pages can\nnever resolve to the same slug in the same locale, whether that's their\nshared default or one sibling's override colliding with another's\ndefault; you'll see exactly which locale and which sibling conflicts if\nthat happens.\n\n### Moving and reordering pages\n\nThe tree supports two different drags, depending on where you drop:\n\n- Drop a page **onto** another page to reparent it there — the dropped\n  page becomes that page's child.\n- Drop a page **between** two sibling rows to reorder it among its\n  current siblings, without changing its parent.\n\nEither kind of drag can also be done without a mouse: select **Move…** in\na page's **Configuration** tab and pick a target the same way dragging\nwould. You can't move a page into itself or one of its own descendants,\nand a site's root can't be moved or reordered at all — it has no grip\nhandle to drag by, and its Configuration tab shows no **Move…** button.\n\nIf someone else changes the tree while you're mid-drag, Composer notices,\nrefreshes the sibling list automatically, and asks you to try again rather\nthan silently applying a stale order.\n\nDeleting a page requires it to have no children first; a page that's the\ntarget of a **Redirect** elsewhere in the tree can't be deleted until that\nredirect is removed or repointed. A site's root can't be deleted from\nComposer at all — that's a **Settings > Sites** action, since it deletes\nthe whole tree beneath it.\n\n## The Experience tab\n\nA page's **Experience** tab opens with one question: **What does `/path` do?** The three\nanswers are the page's type, and exactly one is true of an address at a time:\n\n- **Presentation** shows a page built from a Template and a Component.\n- **Redirect** sends visitors to another page.\n- **Folder** only groups the pages beneath it, and has no content of its own.\n\nWhat sits below the question is only the chosen type's settings. Choosing a different type is an\nedit like any other: it shows in the save bar, and nothing changes until you save. Use the arrow\nkeys to move between the three.\n\nFor a **Presentation** page, the card below the question shows how the page is built, as pieces\nthat fit together from top to bottom:\n\n- **Template, sets the shape.** The layout. It decides the shape of content the page needs: a\n  Contract, which is a list of fields. It shows the shape it **needs**.\n- **Adapter, reshapes to fit.** Only there when the Component's shape is not the one the Template\n  needs. It shows the shape it **takes** and the shape it **gives**. See\n  [Adapters](content-adapters.md) if that's new to you.\n- **Component, fills the shape.** The content itself: its text, images and fields. It shows the\n  shape it **is**.\n\nBetween each pair is a joint. A tick means the shapes fit. A red mark means they do not, and a row\nbeneath offers **Add an Adapter…** to bridge them. Each piece keeps its own actions: **Quick edit**\nis the Component's main button, and **Change**, **Configure** (where there are settings or\ncontextual values to fill in) and **Mapping** are in the **⋯** menu on the Template, Component or\nAdapter row. Anything that still needs a value or a review appears as a line at the foot of the\ncard with its own button. See\n[Presenting content with Templates](templates.md) for the **Contextual values** and **Settings**\npanels. If the Template declares a settings field that's both mandatory and Contextual, it must be\nfilled in here: a page is the last stop for that value, so there's nowhere further downstream to\ninherit it from. **Quick edit** opens the\n  bound Component itself in a layer over the tree — and the same layer\n  opens *this* page from any Link or Experience-reference field elsewhere\n  that points at it; see\n  [Editing something from where it's used](content-authoring.md#editing-something-from-where-its-used).\n\nSwitching a page's type here always lands you on that type's own normal\nstarting point (no Template chosen yet, no redirect target chosen yet) —\nit never carries over or invents a binding from whatever the page was\nbefore.\n\nFor a **Redirect** page, select **Pick a target page…** and browse to it.\nA page can't redirect to itself. A **Folder** page has no payload of its\nown — it exists only to organize the pages beneath it.\n\n## Version history for a page\n\nChoose **Version history…** from **More actions** to see every saved version of\nthe selected page: who changed it, when, and what changed (its name, address,\nand content). Page history is read-only: it shows you what the page used to\nsay, but restoring an earlier version isn't available yet. See\n[Version history](components.md#version-history) for how history works for\nComponents.\n\n## The Configuration tab\n\nEverything about a page other than what it renders lives in **Configuration**. The settings most\npeople use stay in view: the page's **Name** and **Made for** (below), its **Slug**, its **Location**\nin the tree (parent, Move…), and its **Categories**. Everything else is folded into **Advanced**, a single row that\nsays how those settings are set while it is closed, for example *Access: no rules · Templates: any ·\nReview: none · Search engines: listed*. Open it for:\n\n- **Who can work on this branch**: access rules.\n- **Templates pages here can use**: which Templates new pages here may use.\n- **Review before publishing**: the editorial workflow assigned to this page.\n- **Search engines**: whether the page is listed in your sitemap.\n\n**Delete this page**, for a non-root page, stays separate at the bottom and asks you to confirm\nfirst.\n\n### Made for\n\nUnder **Name**, **Made for** notes which channels the page is built for: **Email**, **Web**, or\nboth. It is optional and only advises. It never stops you saving or publishing, and a page with no\nnote is simply \"unknown\", which warns about nothing.\n\nWhen a page is made for a channel, the **Experience** tab warns you about any Component it uses that\nsays it is not (for example a page made for email that uses a Component marked **Web** only). The\nwarning lists those Components, and it also covers Components used inside other Components. It follows\nthe note as you change it, before you save. A Component with no note never triggers it.\n\nOther apps read the note too. Audience's template picker shows each page as **Made for email**, **Made\nfor web only** or **No channel noted**, and still lets you choose a web-only page after a warning.\n\nA page has one **Save** bar along the bottom, whichever tab is open. It counts\neverything you have changed on the page (name, slug, search visibility, page\ntype and what it shows) and lists each change when you select the count.\n**Save** writes them all; **Discard** puts them back. If part of a save is\nrefused, for example a slug a sibling page already uses, the bar keeps listing\nwhat is still unsaved and says why. If you select another page while this one\nhas unsaved edits, Composer asks\nbefore it drops them.\n\nUnder the page's name, one **status strip** says whether the page can be published. It reads\n**Draft**, **Published** or **Modified since it was published**, with a line about what the live site\nshows, and it holds **Publish…** or **Republish…**. If the page has an editorial workflow, the strip\nshows the workflow's state and its next step (for example **Approve**) beside it, so you can move it\non without leaving the tab. While the state does not allow publishing it reads **Can't be published\nyet**; **Republish…** is still there, but it is not the highlighted button, and the publish panel\nexplains the block. The page's other actions, **Preview**, **Promote…** and **Unpublish**, are in the\nrow above, and **Used in N places** is beside the path. The full workflow panel, with its comment box\nand **Cancel run**, is in **Configuration**.\n\nIf you have **unsaved changes**, the strip says so and offers **Save changes**. Publishing and\npromoting use the *saved* page, so pressing **Publish…** or **Promote…** with unsaved changes asks\nfirst, naming each change. Choose **Save and publish** to save and then publish, **Publish the saved\nversion** to publish without them, or **Cancel**. The Component editor asks the same question.\n\n## Live preview\n\nClick **Preview…** on any page to open live preview: your site, rendered\nright there in Composer, showing your unsaved draft — not what's actually\npublished. Nothing you do here goes live until you choose to publish it.\n\nAcross the top of live preview:\n\n- **The host.** The address of the site being previewed, with what it does\n  underneath: **Click-to-edit** (the site can show pins and be clicked\n  through) or **Reloads on change** (the site builds its pages on its own\n  server; see below). If your site has more than one address, choose one\n  here. The list is managed under **Settings › Sites**.\n- **Edit and Browse.** Hover either for what it does. **Edit** shows pins\n  you can click to change content; **Browse** hides them so you can click\n  through the site like a visitor.\n- **Phone, Tablet and Full** set how wide the page is. You can also drag the\n  page's left or right edge to any width, with a readout and a snap to\n  Phone and Tablet. The panel on the right has its own handle on its left\n  edge, so you can make the page phone-sized and still keep room to edit.\n  Press an arrow key on a handle to move it 10 px (50 with Shift), or\n  double-click it to reset. Both widths are remembered.\n- **Language and audience** (for example *Default language · Everyone*)\n  opens **Preview as a visitor**, to see the page as a visitor in another\n  language or audience would, or to show referenced content in full.\n- **Open site** opens the page in its own browser tab.\n\nOn a phone-sized screen the header has three rows: the page name and status\nwith **Close**, then the host with **Pins** and **⋯** (Open site, Language and\naudience), then Edit and Browse. **Pins** opens the panel as a sheet from the\nbottom, and the width handles are not shown.\n\nPress **Esc** to close an open Quick edit form; press it again to close live\npreview.\n\nThe page renders with numbered pins over anything you can edit. Shape\ntells you what a pin is, so it reads even in black and white:\n\n- A **magenta circle** is a single field — a headline, a paragraph, a date.\n- A **solid blue rounded rectangle** is a whole Component — either the\n  Presentation bound at that spot, or something rendered outside the page\n  itself (see \"Also on this page\" below).\n- A **dashed blue rounded rectangle** is content produced by an Adapter —\n  mapped in from somewhere else, with no field of its own on this page.\n- A **red rectangle** marks something that couldn't be resolved.\n\nEvery pinned part of the page also gets a light outline in its pin's own\ncolor the whole time you're in Edit mode, not just on hover — so you can\nsee everything on the page that's editable at a glance, before you click\nanything. Hovering or selecting a pin (from the page or from its row in\nthe panel on the right) strengthens that outline and shows a tag naming\nwhat it is.\n\nWhat clicking a pin does depends on its shape:\n\n- A **field** pin opens a small **docked editor** right at the top of the\n  panel — no matter how deep inside the page's content that field actually\n  lives — with its name, its type, and a magenta **Own save** badge, above\n  the rest of the page summary (dimmed while you're editing). Deep inside\n  something (a section, a card, a list item), the docked editor also shows\n  a breadcrumb (\"Referenced by *the page* → *Section 4* *Statement* →\n  `actions`\") so you know exactly where you are. What docks depends on the\n  field:\n  - A **Component**, **Reference**, or **Presentation** field — the kind\n    that points at other content — gets a compact list: one row per item,\n    with a label, where it links to (if anywhere), a drag handle to\n    reorder, an edit button, a remove button, and an **Add item** row at\n    the bottom. Click a row's edit button to open that item — an item\n    authored right here opens its own full editor; an item that's really a\n    separate, shared Component re-targets this same panel to that\n    Component instead of opening a second one.\n  - Every other field (Rich text, a plain text field, a date, and so on)\n    gets its own usual editor, docked as a single row.\n  Type, then **Save** or **Cancel** — or **Open full editor** if you'd\n  rather see the whole Component or page it belongs to.\n  A pin whose field can't be matched this way falls back to opening the\n  whole Component or page in full, with that field already focused.\n- A **Component** pin (solid rectangle) opens that Component for editing\n  in full, the same as clicking **Quick edit** next to it — a magenta\n  **Own save** badge marks it while you're in it.\n- An **Adapter-mapped** pin (dashed rectangle) never opens an editor\n  directly — there's no field of yours behind it. Instead it explains\n  where the content comes from: which Adapter produced it, and a look at\n  the actual source underneath. From there, **Edit source field** jumps\n  straight to the one field that's a direct, one-to-one copy (when there\n  is one), and **Edit mapping…** opens the mapping itself for a deeper\n  change.\n- A **red (unresolved)** pin opens on whatever it belongs to, so you can\n  see and fix why it isn't resolving.\n\nType in a docked or full editor, and the page updates within a second or\nso either way.\n\n**Browse** switches off the pins so you can click around the page the way a\nvisitor would — following links to see other pages of the same site, still\nagainst your unsaved drafts. The panel says the pins are hidden on purpose;\nswitch back to **Edit** to see them.\n\n**Also on this page** lists anything the site renders that isn't part of\nthe page itself — a shared header or footer, for instance. These are\nedited and saved the same way as anything else with a pin: click **Quick\nedit** next to it, make your change, and save. Because a shared header or\nfooter isn't part of any one page, saving it doesn't publish it along with\nthe page — after saving, use the **Publish…** button that appears right\nthere to make the change live. If a site is set up to show something\nthat doesn't exist in the environment you're working in, it's listed as\n**not in this environment** — nothing to worry about, and never something\nthat stops the rest of the page from previewing normally.\n\n### Previewing a site that renders on its server\n\nSome sites build every page on their own server and send finished pages to\nthe browser, with nothing re-drawn in the browser afterwards. Live preview\ncan't hand those sites your draft directly, so it works a little\ndifferently there.\n\nYour developer sets it up once:\n\n- Under **Settings › Sites**, open the site and set its host's **Live\n  preview** to **Server**.\n- Under **API Keys**, the site's key needs **Allow draft preview** turned\n  on. Only a server-side key can have it.\n\nAfter that, live preview on that host behaves like this:\n\n- Composer starts a private preview session for you. Your draft, unsaved\n  edits included, goes to that session, and the site's server reads it from\n  there.\n- Each time you pause typing, the page reloads with your latest edits. That\n  takes a moment longer than on other sites.\n- **Pins work if the site adds one script.** Out of the box a\n  server-rendered site has nothing running in the browser to draw pins.\n  Where Edit and Browse would be, live preview shows **Reloads on change**,\n  and the panel says pins aren't available on this site — use it to edit\n  the page and the Component it shows.\n  If your developer adds ebitex's preview script to the site (a single\n  `<script>` tag, and marks which part of the page shows which field), you\n  get the same numbered pins and click-to-edit as any other site. Nothing\n  changes for visitors: the script does nothing unless Composer is framing\n  the page. Ask them for \"the ebitex preview script\" and point them at\n  developers.ebitex.io.\n- Only the page you're previewing shows your draft. Follow a link and the\n  other page shows what's published — and if the site runs the script,\n  Composer follows you there and starts previewing that page instead.\n- If the preview says **The site is showing its published page, not your\n  draft**, what you're looking at isn't your draft. Usually the site isn't\n  set up for server previews yet, its key doesn't allow draft preview, or\n  your browser blocked the site's cookie inside Composer. **Open the site in\n  a new tab** gets around that last one. **Copy details for your developer**\n  puts what they need on your clipboard, and **Technical details** shows it\n  on screen.\n- Closing live preview ends the session straight away. Nobody can use it\n  afterwards.\n\n### If the preview can't reach the site\n\nIf the site isn't answering, a message appears above the page: **The site\nisn't answering at *address***. It may not be running, or it may not be set\nup for preview yet. **Try again** checks again, **Open the site in a new tab**\nshows you what the site itself does, and **Copy details for your developer**\nputs the likely causes on your clipboard to send on. The same causes are\nunder **Technical details**.\n\n## Opening a page from the site itself\n\nWhen you're signed in to Content and browsing one of your own published sites, a small **Click to\nedit** button appears in the corner of the page. It takes you straight to that page in Composer, with\nlive preview already open.\n\nIf the page belongs to a **different organization** than the one you're currently working in, Content\nswitches for you and shows a notice saying so, with a **Switch back** button. That switch applies to\nyour whole ebitex session — Hub and Forms in other tabs will show the new organization the next time\nyou navigate in them — so the notice stays until you dismiss it.\n\nA few cases where the link won't open a page, and what each means:\n\n- **\"This page no longer exists, or belongs to an organization you are not currently signed in to.\"**\n  Either the page was deleted, or it belongs to an organization you're not a member of. If a\n  colleague sent you the link, ask them to add you to that organization.\n- **Nothing switches and the page doesn't load.** The site's hostname isn't mapped to a site in any\n  organization you belong to. Check **Settings > Delivery** for that organization's host mappings.\n- **Two organizations claim the same hostname.** Content won't guess which one you meant. Fix the\n  duplicate mapping in **Settings > Delivery**, then follow the link again.\n\n## Restricting what can go where\n\nTwo governance controls apply to a branch of the tree, the same way they\napply to Component folders (see \"Folders and access rules\" in\n[Authoring Components](components.md)) — both live in the **Configuration**\ntab's **Advanced** section:\n\n- **Who can work on this branch** (access rules) grants specific roles view/edit/delete/publish on a\n  branch — no rules anywhere on the branch means it's open to everyone; a\n  rule anywhere on a root even restricts an entire site. A role needs view\n  to see a branch at all; edit, delete, and publish are each independent\n  beyond that.\n- **Templates pages here can use** restricts which Templates a Presentation payload\n  can use anywhere at or beneath a page — useful for keeping, say, a\n  campaigns section limited to a handful of approved layouts. Leaving it\n  unset allows any Template. Tightening this later never breaks a payload\n  already in place; it's only checked when a payload is assigned or\n  changed.\n\nBoth panels are only editable by someone with elevated access-management\npermission; everyone else sees a read-only summary of what they\npersonally can do on that branch.\n"
+        "body": "# Building your site in Composer\n\nComposer is where content becomes a website. A **site** is a named tree of\n**pages**; each page's slug (and its ancestors' slugs) form its **path** —\nthe URL it will eventually be served at. A page can be pure structure (a\n**Folder**, with no page of its own, just a place to organize its\nchildren), or it can carry a payload: either a **Presentation** (content\nshown at that path) or a **Redirect** (send visitors somewhere else).\nContracts, Components, and Templates (see\n[Modeling content with Contracts](contracts.md),\n[Authoring Components](components.md), and\n[Presenting content with Templates](templates.md)) define *what* content\nis and *how* it's presented; Composer decides *where* it lives. Nothing\nbuilt here is publicly visible yet — publishing is a later phase.\n\nComposer is the suite's *top-down* authoring surface — site, then tree,\nthen page. [Content](content-authoring.md) is its *bottom-up* counterpart:\nthe Component library, edited independently of any one page. Both appear\nas their own item in the sidebar.\n\n## Choosing a site\n\nComposer's header has a site switcher — select it to see every site in\nthis organization and pick one, or select **Manage sites →** to create,\nrename, or delete a site. Composer's tree always shows exactly one site's\npages at a time; switching sites swaps the whole tree beneath it.\n\nSites themselves are managed from **Settings > Sites**: create a new one\nby name, rename an existing one, or delete one (deleting a site deletes\nits entire page tree, including every page's payload — typing the site's\nname confirms you mean it).\n\n## Building the tree\n\nA large tree can be searched by category — see \"Filtering by category\" in\n[Taxonomy](content-taxonomy.md) for how the tree's own **Filter by\ncategory** control auto-expands to reveal matches without hiding anything\nelse.\n\nTo add a page:\n\n1. Select the parent page (the site's own root, shown at the top of the\n   tree, or any page under it), then select **+ Add page** at the top of\n   the tree panel.\n2. Pick a type — **Presentation**, **Redirect**, or **Folder** —\n   Presentation is pre-selected, since it's what most new pages are for.\n   You can change a page's type at any time later, from its own\n   Experience tab.\n3. Enter a **Name** — the path preview beneath it fills in from it\n   automatically (`/campaigns-launch`, for example). You can give the page\n   a different slug later, from its **Configuration** tab.\n4. Select **Create**.\n\nEvery page shows its computed **path** at the top of the detail panel —\nthe site root's own path is always `/`.\n\n### Localized slugs\n\nA page's slug can have a different value per locale, just like other\nlocalizable content — select the translate icon beside **Slug** (in the\n**Configuration** tab) to add per-locale overrides. Two sibling pages can\nnever resolve to the same slug in the same locale, whether that's their\nshared default or one sibling's override colliding with another's\ndefault; you'll see exactly which locale and which sibling conflicts if\nthat happens.\n\n### Moving and reordering pages\n\nThe tree supports two different drags, depending on where you drop:\n\n- Drop a page **onto** another page to reparent it there — the dropped\n  page becomes that page's child.\n- Drop a page **between** two sibling rows to reorder it among its\n  current siblings, without changing its parent.\n\nEither kind of drag can also be done without a mouse: select **Move…** in\na page's **Configuration** tab and pick a target the same way dragging\nwould. You can't move a page into itself or one of its own descendants,\nand a site's root can't be moved or reordered at all — it has no grip\nhandle to drag by, and its Configuration tab shows no **Move…** button.\n\nIf someone else changes the tree while you're mid-drag, Composer notices,\nrefreshes the sibling list automatically, and asks you to try again rather\nthan silently applying a stale order.\n\nDeleting a page requires it to have no children first; a page that's the\ntarget of a **Redirect** elsewhere in the tree can't be deleted until that\nredirect is removed or repointed. A site's root can't be deleted from\nComposer at all — that's a **Settings > Sites** action, since it deletes\nthe whole tree beneath it.\n\n## The Experience tab\n\nA page's **Experience** tab opens with one question: **What does `/path` do?** The three\nanswers are the page's type, and exactly one is true of an address at a time:\n\n- **Presentation** shows a page built from a Template and a Component.\n- **Redirect** sends visitors to another page.\n- **Folder** only groups the pages beneath it, and has no content of its own.\n\nWhat sits below the question is only the chosen type's settings. Choosing a different type is an\nedit like any other: it shows in the save bar, and nothing changes until you save. Use the arrow\nkeys to move between the three.\n\nFor a **Presentation** page, the card below the question shows how the page is built, as pieces\nthat fit together from top to bottom:\n\n- **Template, sets the shape.** The layout. It decides the shape of content the page needs: a\n  Contract, which is a list of fields. It shows the shape it **needs**.\n- **Adapter, reshapes to fit.** Only there when the Component's shape is not the one the Template\n  needs. It shows the shape it **takes** and the shape it **gives**. See\n  [Adapters](content-adapters.md) if that's new to you.\n- **Component, fills the shape.** The content itself: its text, images and fields. It shows the\n  shape it **is**.\n\nBetween each pair is a joint. A tick means the shapes fit. A red mark means they do not, and a row\nbeneath offers **Add an Adapter…** to bridge them. Each piece keeps its own actions: **Quick edit**\nis the Component's main button, and **Change**, **Configure** (where there are settings or\ncontextual values to fill in) and **Mapping** are in the **⋯** menu on the Template, Component or\nAdapter row. Anything that still needs a value or a review appears as a line at the foot of the\ncard with its own button. See\n[Presenting content with Templates](templates.md) for the **Contextual values** and **Settings**\npanels. If the Template declares a settings field that's both mandatory and Contextual, it must be\nfilled in here: a page is the last stop for that value, so there's nowhere further downstream to\ninherit it from. **Quick edit** opens the\n  bound Component itself in a layer over the tree — and the same layer\n  opens *this* page from any Link or Experience-reference field elsewhere\n  that points at it; see\n  [Editing something from where it's used](content-authoring.md#editing-something-from-where-its-used).\n\nSwitching a page's type here always lands you on that type's own normal\nstarting point (no Template chosen yet, no redirect target chosen yet) —\nit never carries over or invents a binding from whatever the page was\nbefore.\n\nFor a **Redirect** page, select **Pick a target page…** and browse to it.\nA page can't redirect to itself. A **Folder** page has no payload of its\nown — it exists only to organize the pages beneath it.\n\n## Version history for a page\n\nChoose **Version history…** from **More actions** to see every saved version of\nthe selected page: who changed it, when, and what changed (its name, address,\nand content). Page history is read-only: it shows you what the page used to\nsay, but restoring an earlier version isn't available yet. See\n[Version history](components.md#version-history) for how history works for\nComponents.\n\n## The Configuration tab\n\nEverything about a page other than what it renders lives in **Configuration**. The settings most\npeople use stay in view: the page's **Name** and **Made for** (below), its **Slug**, its **Location**\nin the tree (parent, Move…), and its **Categories**. Everything else is folded into **Advanced**, a single row that\nsays how those settings are set while it is closed, for example *Access: no rules · Templates: any ·\nReview: none · Search engines: listed*. Open it for:\n\n- **Who can work on this branch**: access rules.\n- **Templates pages here can use**: which Templates new pages here may use.\n- **Review before publishing**: the editorial workflow assigned to this page.\n- **Search engines**: whether the page is listed in your sitemap.\n\n**Delete this page**, for a non-root page, stays separate at the bottom and asks you to confirm\nfirst.\n\n### Made for\n\nUnder **Name**, **Made for** notes which channels the page is built for: **Email**, **Web**, or\nboth. It is optional and only advises. It never stops you saving or publishing, and a page with no\nnote is simply \"unknown\", which warns about nothing.\n\nWhen a page is made for a channel, the **Experience** tab warns you about any Component it uses that\nsays it is not (for example a page made for email that uses a Component marked **Web** only). The\nwarning lists those Components, and it also covers Components used inside other Components. It follows\nthe note as you change it, before you save. A Component with no note never triggers it.\n\nOther apps read the note too. Audience's template picker shows each page as **Made for email**, **Made\nfor web only** or **No channel noted**, and still lets you choose a web-only page after a warning.\n\nA page has one **Save** bar along the bottom, whichever tab is open. It counts\neverything you have changed on the page (name, slug, search visibility, page\ntype and what it shows) and lists each change when you select the count.\n**Save** writes them all; **Discard** puts them back. If part of a save is\nrefused, for example a slug a sibling page already uses, the bar keeps listing\nwhat is still unsaved and says why. If you select another page while this one\nhas unsaved edits, Composer asks\nbefore it drops them.\n\nUnder the page's name, one **status strip** says whether the page can be published. It reads\n**Draft**, **Published** or **Modified since it was published**, with a line about what the live site\nshows, and it holds **Publish…** or **Republish…**. If the page has an editorial workflow, the strip\nshows the workflow's state and its next step (for example **Approve**) beside it, so you can move it\non without leaving the tab. While the state does not allow publishing it reads **Can't be published\nyet**; **Republish…** is still there, but it is not the highlighted button, and the publish panel\nexplains the block. The page's other actions, **Preview**, **Promote…** and **Unpublish**, are in the\nrow above, and **Used in N places** is beside the path. The full workflow panel, with its comment box\nand **Cancel run**, is in **Configuration**.\n\nIf you have **unsaved changes**, the strip says so and offers **Save changes**. Publishing and\npromoting use the *saved* page, so pressing **Publish…** or **Promote…** with unsaved changes asks\nfirst, naming each change. Choose **Save and publish** to save and then publish, **Publish the saved\nversion** to publish without them, or **Cancel**. The Component editor asks the same question.\n\n## Live preview\n\nClick **Preview…** on any page to open live preview: your site, rendered\nright there in Composer, showing your unsaved draft — not what's actually\npublished. Nothing you do here goes live until you choose to publish it.\n\nAcross the top of live preview:\n\n- **The host.** The address of the site being previewed, with what it does\n  underneath: **Click-to-edit** (the site can show pins and be clicked\n  through) or **Reloads on change** (the site builds its pages on its own\n  server; see below). If your site has more than one address, choose one\n  here. The list is managed under **Settings › Sites**.\n- **Edit and Browse.** Hover either for what it does. **Edit** shows pins\n  you can click to change content; **Browse** hides them so you can click\n  through the site like a visitor.\n- **Phone, Tablet and Full** set how wide the page is. You can also drag the\n  page's left or right edge to any width, with a readout and a snap to\n  Phone and Tablet. The panel on the right has its own handle on its left\n  edge, so you can make the page phone-sized and still keep room to edit.\n  Press an arrow key on a handle to move it 10 px (50 with Shift), or\n  double-click it to reset. Both widths are remembered.\n- **Language and audience** (for example *Default language · Everyone*)\n  opens **Preview as a visitor**, to see the page as a visitor in another\n  language or audience would, or to show referenced content in full.\n- **Open site** opens the page in its own browser tab.\n\nOn a phone-sized screen the header has three rows: the page name and status\nwith **Close**, then the host with **Pins** and **⋯** (Open site, Language and\naudience), then Edit and Browse. **Pins** opens the panel as a sheet from the\nbottom, and the width handles are not shown.\n\nPress **Esc** to close an open Quick edit form; press it again to close live\npreview.\n\n### Preview a section, a header or a shared Component\n\nYou do not need a page to preview a presentation.\n\n- **A section on a page.** On the card of any presentation field, click\n  **Preview**. Live preview opens on that page with the section's pin already\n  selected. If the page does not draw that section, the panel says\n  **Not on this page** beside it.\n- **A shared Component.** In the Component editor, **Preview…** opens live\n  preview with the Component shown inside a real page that uses it. The\n  **Framed in** chip switches to another page that uses it, and your choice is\n  remembered for that Component. If only one page uses it, you are not asked.\n  Pages that use it through another Component are included.\n- **A site header or footer.** A Component your site draws around every page\n  (for example `ebitex-site-chrome`) is previewed on any page of the site,\n  the site's home page by default, and the page you pick is remembered for the\n  site. If the page you picked does not show it, the preview says so and\n  offers another page.\n\nWhat a preview of one page proves: how your draft looks there. Another page\nmay place the same Component differently, so use **Framed in** to check a\nsecond one. Things only your site's code controls, such as a sticky header or\nfonts, are judged on the live site. A Component that no page uses yet cannot\nbe framed this way until a later release; **Show the resolved output instead**\nopens the raw result.\n\nThe page renders with numbered pins over anything you can edit. Shape\ntells you what a pin is, so it reads even in black and white:\n\n- A **magenta circle** is a single field — a headline, a paragraph, a date.\n- A **solid blue rounded rectangle** is a whole Component — either the\n  Presentation bound at that spot, or something rendered outside the page\n  itself (see \"Also on this page\" below).\n- A **dashed blue rounded rectangle** is content produced by an Adapter —\n  mapped in from somewhere else, with no field of its own on this page.\n- A **red rectangle** marks something that couldn't be resolved.\n\nEvery pinned part of the page also gets a light outline in its pin's own\ncolor the whole time you're in Edit mode, not just on hover — so you can\nsee everything on the page that's editable at a glance, before you click\nanything. Hovering or selecting a pin (from the page or from its row in\nthe panel on the right) strengthens that outline and shows a tag naming\nwhat it is.\n\nWhat clicking a pin does depends on its shape:\n\n- A **field** pin opens a small **docked editor** right at the top of the\n  panel — no matter how deep inside the page's content that field actually\n  lives — with its name, its type, and a magenta **Own save** badge, above\n  the rest of the page summary (dimmed while you're editing). Deep inside\n  something (a section, a card, a list item), the docked editor also shows\n  a breadcrumb (\"Referenced by *the page* → *Section 4* *Statement* →\n  `actions`\") so you know exactly where you are. What docks depends on the\n  field:\n  - A **Component**, **Reference**, or **Presentation** field — the kind\n    that points at other content — gets a compact list: one row per item,\n    with a label, where it links to (if anywhere), a drag handle to\n    reorder, an edit button, a remove button, and an **Add item** row at\n    the bottom. Click a row's edit button to open that item — an item\n    authored right here opens its own full editor; an item that's really a\n    separate, shared Component re-targets this same panel to that\n    Component instead of opening a second one.\n  - Every other field (Rich text, a plain text field, a date, and so on)\n    gets its own usual editor, docked as a single row.\n  Type, then **Save** or **Cancel** — or **Open full editor** if you'd\n  rather see the whole Component or page it belongs to.\n  A pin whose field can't be matched this way falls back to opening the\n  whole Component or page in full, with that field already focused.\n- A **Component** pin (solid rectangle) opens that Component for editing\n  in full, the same as clicking **Quick edit** next to it — a magenta\n  **Own save** badge marks it while you're in it.\n- An **Adapter-mapped** pin (dashed rectangle) never opens an editor\n  directly — there's no field of yours behind it. Instead it explains\n  where the content comes from: which Adapter produced it, and a look at\n  the actual source underneath. From there, **Edit source field** jumps\n  straight to the one field that's a direct, one-to-one copy (when there\n  is one), and **Edit mapping…** opens the mapping itself for a deeper\n  change.\n- A **red (unresolved)** pin opens on whatever it belongs to, so you can\n  see and fix why it isn't resolving.\n\nType in a docked or full editor, and the page updates within a second or\nso either way.\n\n**Browse** switches off the pins so you can click around the page the way a\nvisitor would — following links to see other pages of the same site, still\nagainst your unsaved drafts. The panel says the pins are hidden on purpose;\nswitch back to **Edit** to see them.\n\n**Also on this page** lists anything the site renders that isn't part of\nthe page itself — a shared header or footer, for instance. These are\nedited and saved the same way as anything else with a pin: click **Quick\nedit** next to it, make your change, and save. Because a shared header or\nfooter isn't part of any one page, saving it doesn't publish it along with\nthe page — after saving, use the **Publish…** button that appears right\nthere to make the change live. If a site is set up to show something\nthat doesn't exist in the environment you're working in, it's listed as\n**not in this environment** — nothing to worry about, and never something\nthat stops the rest of the page from previewing normally.\n\n### Previewing a site that renders on its server\n\nSome sites build every page on their own server and send finished pages to\nthe browser, with nothing re-drawn in the browser afterwards. Live preview\ncan't hand those sites your draft directly, so it works a little\ndifferently there.\n\nYour developer sets it up once:\n\n- Under **Settings › Sites**, open the site and set its host's **Live\n  preview** to **Server**.\n- Under **API Keys**, the site's key needs **Allow draft preview** turned\n  on. Only a server-side key can have it.\n\nAfter that, live preview on that host behaves like this:\n\n- Composer starts a private preview session for you. Your draft, unsaved\n  edits included, goes to that session, and the site's server reads it from\n  there.\n- Each time you pause typing, the page reloads with your latest edits. That\n  takes a moment longer than on other sites.\n- **Pins work if the site adds one script.** Out of the box a\n  server-rendered site has nothing running in the browser to draw pins.\n  Where Edit and Browse would be, live preview shows **Reloads on change**,\n  and the panel says pins aren't available on this site — use it to edit\n  the page and the Component it shows.\n  If your developer adds ebitex's preview script to the site (a single\n  `<script>` tag, and marks which part of the page shows which field), you\n  get the same numbered pins and click-to-edit as any other site. Nothing\n  changes for visitors: the script does nothing unless Composer is framing\n  the page. Ask them for \"the ebitex preview script\" and point them at\n  developers.ebitex.io.\n- Only the page you're previewing shows your draft. Follow a link and the\n  other page shows what's published — and if the site runs the script,\n  Composer follows you there and starts previewing that page instead.\n- If the preview says **The site is showing its published page, not your\n  draft**, what you're looking at isn't your draft. Usually the site isn't\n  set up for server previews yet, its key doesn't allow draft preview, or\n  your browser blocked the site's cookie inside Composer. **Open the site in\n  a new tab** gets around that last one. **Copy details for your developer**\n  puts what they need on your clipboard, and **Technical details** shows it\n  on screen.\n- Closing live preview ends the session straight away. Nobody can use it\n  afterwards.\n\n### If the preview can't reach the site\n\nIf the site isn't answering, a message appears above the page: **The site\nisn't answering at *address***. It may not be running, or it may not be set\nup for preview yet. **Try again** checks again, **Open the site in a new tab**\nshows you what the site itself does, and **Copy details for your developer**\nputs the likely causes on your clipboard to send on. The same causes are\nunder **Technical details**.\n\n## Opening a page from the site itself\n\nWhen you're signed in to Content and browsing one of your own published sites, a small **Click to\nedit** button appears in the corner of the page. It takes you straight to that page in Composer, with\nlive preview already open.\n\nIf the page belongs to a **different organization** than the one you're currently working in, Content\nswitches for you and shows a notice saying so, with a **Switch back** button. That switch applies to\nyour whole ebitex session — Hub and Forms in other tabs will show the new organization the next time\nyou navigate in them — so the notice stays until you dismiss it.\n\nA few cases where the link won't open a page, and what each means:\n\n- **\"This page no longer exists, or belongs to an organization you are not currently signed in to.\"**\n  Either the page was deleted, or it belongs to an organization you're not a member of. If a\n  colleague sent you the link, ask them to add you to that organization.\n- **Nothing switches and the page doesn't load.** The site's hostname isn't mapped to a site in any\n  organization you belong to. Check **Settings > Delivery** for that organization's host mappings.\n- **Two organizations claim the same hostname.** Content won't guess which one you meant. Fix the\n  duplicate mapping in **Settings > Delivery**, then follow the link again.\n\n## Restricting what can go where\n\nTwo governance controls apply to a branch of the tree, the same way they\napply to Component folders (see \"Folders and access rules\" in\n[Authoring Components](components.md)) — both live in the **Configuration**\ntab's **Advanced** section:\n\n- **Who can work on this branch** (access rules) grants specific roles view/edit/delete/publish on a\n  branch — no rules anywhere on the branch means it's open to everyone; a\n  rule anywhere on a root even restricts an entire site. A role needs view\n  to see a branch at all; edit, delete, and publish are each independent\n  beyond that.\n- **Templates pages here can use** restricts which Templates a Presentation payload\n  can use anywhere at or beneath a page — useful for keeping, say, a\n  campaigns section limited to a handful of approved layouts. Leaving it\n  unset allows any Template. Tightening this later never breaks a payload\n  already in place; it's only checked when a payload is assigned or\n  changed.\n\nBoth panels are only editable by someone with elevated access-management\npermission; everyone else sees a read-only summary of what they\npersonally can do on that branch.\n"
     },
     {
         "slug": "content-environments",
@@ -46,7 +46,7 @@ export const HELP_TOPICS = [
     {
         "slug": "content-modelling",
         "title": "Modelling your content: best practices",
-        "body": "# Modelling your content: best practices\n\nHow to shape Contracts, Templates and Components so a site is easy to build, easy to change and hard to break. It applies whether you model in Content, through the API, or as code, and it is the model the starter kit follows. Read it before you create anything, and read [Building a content model through the API](agent-authoring.md) for the mechanics.\n\n## The one idea\n\n**A Contract holds what is said. A Template holds how it is shown.**\n\n- A **Contract** has editorial fields only: a heading, a body, an image, a link, a label. Nothing about width, colour, columns, emphasis or order of appearance.\n- A **Template** says how a Contract is drawn, and owns a **settings Contract** for every choice that belongs to a *place*: width, background, appearance, layout, a card's emphasis, a banner's tone, a grid's columns, how an accordion opens.\n- A **presentation** is the pair in use: a Template, its settings, and a Component. The same Component can appear on many pages, each with its own settings, so it looks or behaves differently in each, and the words live in one place.\n\nIf you catch yourself adding \"layout\", \"width\" or \"variant\" to a content Contract, it belongs in a Template's settings.\n\n## Choose the right kind of field\n\n| You want | Use | Why |\n|---|---|---|\n| A hero or a list of sections on a page | A **presentation** field, with the Templates it accepts | An editor picks how it is drawn, sets the choices for that place, and supplies the content |\n| A part with no life of its own (a button inside a hero, a tab's label) | An **inline** component | Nothing else can point at it, and it is deleted with what holds it |\n| A thing reused across pages (a testimonial, a venue) | A **reference** to a Component | One edit changes it everywhere |\n| One of a closed set of choices (a theme, a tone) | A **category** from a group | A renderer maps the key; an organization can rename or extend the values |\n| Media | A reference to an **Assets** item | The media library owns files, not Content |\n\nPrefer a presentation field over a component field whenever the thing is *drawn* on a page. A component field gives the editor no place to say how.\n\n## Templates and Contracts\n\n- **One Template per Contract by default.** A Template may also support a Contract another Template supports. That is the right tool when the *same* content needs two genuinely different presentations (a statement and a feature over the same heading, body, media and links): keep the Contract generic and add a Template, instead of copying the Contract.\n- A Template can list several supported Contracts, so a generic abstract parent (\"heading, body, media, links\") can serve one Template for every Contract beneath it.\n- **A renderer is chosen by Template, never by Contract.** That is what makes the many-to-one case work, and what makes a container reusable: it hands each item to the same dispatch the page uses.\n- **A Contract has one parent.** Shared settings are therefore a chain, not a mix: a base for sections (width, background, appearance, anchor), a base for grid cells that extends it (adds span), then each Template's own. Model the chain you need; you cannot inherit two bases.\n- Make a shared base **abstract** so it is never placed on its own.\n\n## Containers are components, not special cases\n\nTabs, accordions, carousels and grids hold *other presentations*. Model them as higher-order components:\n\n- The container has an **inline list of item Contracts**. An item is a **label** (content, localizable) plus an **enumerable presentation field** limited to the Templates suitable inside it.\n- A whole FAQ is then one Component you can reuse on every page that needs it.\n- **How a container behaves** (one drawer open at a time or independent, which start open, how many columns) is a **setting of its Template**, not content. The same Component can behave differently wherever it is used.\n- A container accepts **leaf Templates only**. Never let a container accept itself or another container: Contracts and Templates would depend on each other in a loop and cannot be installed in order.\n\n## Allow-lists\n\n- A presentation field names the Templates it accepts (`allowedTemplateIds`); a component field names its Contracts and modes. **Unset means anything. An empty list means nothing.** Say which you mean, and give an editor a clear control to switch.\n- Prefer an **explicit list** for a field with a clear purpose (a hero accepts the Hero Template only; sections never accept the Hero or the page itself). The cost is that a Template you add later is not offered until you add it to the list, which is a deliberate step, not a surprise.\n- Leave a field **open** only when anything really is valid.\n\n## Settings and vocabularies\n\n- Put every closed choice in a **category group**, never free text, so a renderer can map a key and an organization can edit the values. A category key is what a renderer maps, so **never rename a key**.\n- A category field takes **no default**: an unset choice means \"the renderer's default\". When a nested part should follow its parent, add an explicit **inherit** value to the group and treat it, and an unset value, as \"the parent's\". A renderer can then cascade it (an appearance on a section reaches everything inside it, and a nested part that chooses its own overrides it).\n- Keep a theme or any page-wide look in the **page Template's settings**, so the same page Component can be drawn differently.\n- Keep identifiers and settings **non-localizable**; make prose (headings, body, labels) **localizable**.\n\n## Naming\n\n- Field ids are **kebab-case** (`primary-action`, `meta-title`). A field id is a property name in every delivered document, a path in filters and ordering, and a key in queries, and those accept kebab-case only. A model that ships camelCase ids is uneditable later.\n- Give everything you ship a **prefix** so a customer's own keys can never collide with it. Do not shadow keys that other apps own (the Assets Contracts).\n- Name an editor-built page an **experience**, and avoid the word \"page\" in keys: the same content can be a page, a section of one, or an email.\n\n## Building a renderer\n\n- Register one renderer per **Template** in the SDK's renderer map: `{ ...kitRenderers, 'my-template': MyRenderer }`. A Template with no renderer shows the host's fallback and never breaks the page.\n- A renderer receives the Template, its **settings** and the Component's **content**. Draw inside the shared frame so the Template's width, background, anchor and appearance apply, and so your Template joins the appearance cascade.\n- Read a category by its **key**, with a fallback for a key you do not know, so a value an organization adds degrades to the default rather than breaking the page.\n- Test against a **real delivery response** (install the model, publish, read it back), not one you wrote by hand: a hand-written fixture can pass while the real server sends something else.\n\n## Shipping a model to others\n\nIf you distribute a model (a starter kit, a template for clients), treat it like an API:\n\n- **Semver.** A change to a shipped Contract or Template's shape is a **major** version. Within a major version, mark things deprecated and leave them in place.\n- **Never mix a new major version into an older install.** Give each major version a **marker** Contract that exists only in it. An environment that holds some of the model but not the marker holds an earlier version: refuse the install, write nothing, and leave the existing copy exactly as it is.\n- Install the model into **two organizations in one database** in a test: ids that the model carries must be rewritten per organization.\n- **Save every Contract unchanged** through the real save rules after installing it. An import writes without asking those rules, so a model can install cleanly and still be impossible to edit.\n- Give people a **migration note** with every breaking release, even if the answer is \"install into a new environment\".\n\n## A checklist\n\n1. Does every Contract hold only editorial content?\n2. Is every placement, appearance or behaviour choice a setting of a Template?\n3. Is every closed choice a category with no default, and every nested follow-the-parent choice an `inherit`?\n4. Does every presentation field name the Templates it accepts, and do containers accept leaf Templates only?\n5. Are all field ids kebab-case and all prose localizable?\n6. Is there a renderer for every Template, registered by Template?\n7. If you ship it: is there a major-version marker, a changelog, and a test that installs it twice and saves every Contract?\n"
+        "body": "# Modelling your content: best practices\n\nHow to shape Contracts, Templates and Components so a site is easy to build, easy to change and hard to break. It applies whether you model in Content, through the API, or as code, and it is the model the starter kit follows. Read it before you create anything, and read [Building a content model through the API](agent-authoring.md) for the mechanics.\n\n## The one idea\n\n**A Contract holds what is said. A Template holds how it is shown.**\n\n- A **Contract** has editorial fields only: a heading, a body, an image, a link, a label. Nothing about width, colour, columns, emphasis or order of appearance.\n- A **Template** says how a Contract is drawn, and owns a **settings Contract** for every choice that belongs to a *place*: width, background, appearance, layout, a card's emphasis, a banner's tone, a grid's columns, how an accordion opens.\n- A **presentation** is the pair in use: a Template, its settings, and a Component. The same Component can appear on many pages, each with its own settings, so it looks or behaves differently in each, and the words live in one place.\n\nIf you catch yourself adding \"layout\", \"width\" or \"variant\" to a content Contract, it belongs in a Template's settings.\n\n## Choose the right kind of field\n\n| You want | Use | Why |\n|---|---|---|\n| A hero or a list of sections on a page | A **presentation** field, with the Templates it accepts | An editor picks how it is drawn, sets the choices for that place, and supplies the content |\n| A part with no life of its own (a button inside a hero, a tab's label) | An **inline** component | Nothing else can point at it, and it is deleted with what holds it |\n| A thing reused across pages (a testimonial, a venue) | A **reference** to a Component | One edit changes it everywhere |\n| One of a closed set of choices (a theme, a tone) | A **category** from a group | A renderer maps the key; an organization can rename or extend the values |\n| Media | A reference to an **Assets** item | The media library owns files, not Content |\n\nPrefer a presentation field over a component field whenever the thing is *drawn* on a page. A component field gives the editor no place to say how.\n\n## Templates and Contracts\n\n- **One Template per Contract by default.** A Template may also support a Contract another Template supports. That is the right tool when the *same* content needs two genuinely different presentations (a statement and a feature over the same heading, body, media and links): keep the Contract generic and add a Template, instead of copying the Contract.\n- A Template can list several supported Contracts, so a generic abstract parent (\"heading, body, media, links\") can serve one Template for every Contract beneath it.\n- **A renderer is chosen by Template, never by Contract.** That is what makes the many-to-one case work, and what makes a container reusable: it hands each item to the same dispatch the page uses.\n- **A Contract has one parent.** Shared settings are therefore a chain, not a mix: a base for sections (width, background, appearance, anchor), a base for grid cells that extends it (adds span), then each Template's own. Model the chain you need; you cannot inherit two bases.\n- Make a shared base **abstract** so it is never placed on its own.\n\n## Containers are components, not special cases\n\nTabs, accordions, carousels and grids hold *other presentations*. Model them as higher-order components:\n\n- The container has an **inline list of item Contracts**. An item is a **label** (content, localizable) plus an **enumerable presentation field** limited to the Templates suitable inside it.\n- A whole FAQ is then one Component you can reuse on every page that needs it.\n- **How a container behaves** (one drawer open at a time or independent, which start open, how many columns) is a **setting of its Template**, not content. The same Component can behave differently wherever it is used.\n- A container accepts **leaf Templates only**. Never let a container accept itself or another container: Contracts and Templates would depend on each other in a loop and cannot be installed in order.\n- The one exception is a **grouping** container, a heading over a list of presentations (the kit's Group). It may hold the other containers (a heading over a grid, over an accordion), and it must never hold itself, so there is still no loop. Give it its own settings for width, background, appearance, spacing and alignment, so one appearance and one spacing govern a heading and what it introduces, and a presentation inside can still choose its own appearance.\n\n## Site-wide presentations: a header and a footer\n\nA presentation can be delivered only as a page at a path or as a **field of another document**, never alone by id. So something every page shares (a header, a footer) is a presentation held by a small **standalone Component** with a fixed external id. The app fetches that Component by its id, once per session, and draws the two presentations through the same renderers as everything else, so each still has a Template and its own settings and a host can replace either by registering its own renderer. Do not make them page nodes: a node is a public route, appears in the site tree and in its navigation, and needs excluding from search. Publish the holder as its own root, because no page refers to it, and let a half that is not published draw nothing so a site without one is unchanged.\n\n## Allow-lists\n\n- A presentation field names the Templates it accepts (`allowedTemplateIds`); a component field names its Contracts and modes. **Unset means anything. An empty list means nothing.** Say which you mean, and give an editor a clear control to switch.\n- Prefer an **explicit list** for a field with a clear purpose (a hero accepts the Hero Template only; sections never accept the Hero or the page itself). The cost is that a Template you add later is not offered until you add it to the list, which is a deliberate step, not a surprise.\n- Leave a field **open** only when anything really is valid.\n\n## Settings and vocabularies\n\n- Put every closed choice in a **category group**, never free text, so a renderer can map a key and an organization can edit the values. A category key is what a renderer maps, so **never rename a key**.\n- A category field takes **no default**: an unset choice means \"the renderer's default\". When a nested part should follow its parent, add an explicit **inherit** value to the group and treat it, and an unset value, as \"the parent's\". A renderer can then cascade it (an appearance on a section reaches everything inside it, and a nested part that chooses its own overrides it).\n- Keep a theme or any page-wide look in the **page Template's settings**, so the same page Component can be drawn differently.\n- Keep identifiers and settings **non-localizable**; make prose (headings, body, labels) **localizable**.\n\n## Naming\n\n- Field ids are **kebab-case** (`primary-action`, `meta-title`). A field id is a property name in every delivered document, a path in filters and ordering, and a key in queries, and those accept kebab-case only. A model that ships camelCase ids is uneditable later.\n- Give everything you ship a **prefix** so a customer's own keys can never collide with it. Do not shadow keys that other apps own (the Assets Contracts).\n- Name an editor-built page an **experience**, and avoid the word \"page\" in keys: the same content can be a page, a section of one, or an email.\n\n## Building a renderer\n\n- Register one renderer per **Template** in the SDK's renderer map: `{ ...kitRenderers, 'my-template': MyRenderer }`. A Template with no renderer shows the host's fallback and never breaks the page.\n- A renderer receives the Template, its **settings** and the Component's **content**. Draw inside the shared frame so the Template's width, background, anchor and appearance apply, and so your Template joins the appearance cascade.\n- Read a category by its **key**, with a fallback for a key you do not know, so a value an organization adds degrades to the default rather than breaking the page.\n- Test against a **real delivery response** (install the model, publish, read it back), not one you wrote by hand: a hand-written fixture can pass while the real server sends something else.\n\n## Shipping a model to others\n\nIf you distribute a model (a starter kit, a template for clients), treat it like an API:\n\n- **Semver.** A change to a shipped Contract or Template's shape is a **major** version. Within a major version, mark things deprecated and leave them in place.\n- **Never mix a new major version into an older install.** Give each major version a **marker** Contract that exists only in it. An environment that holds some of the model but not the marker holds an earlier version: refuse the install, write nothing, and leave the existing copy exactly as it is.\n- Install the model into **two organizations in one database** in a test: ids that the model carries must be rewritten per organization.\n- **Save every Contract unchanged** through the real save rules after installing it. An import writes without asking those rules, so a model can install cleanly and still be impossible to edit.\n- Give people a **migration note** with every breaking release, even if the answer is \"install into a new environment\".\n\n## A checklist\n\n1. Does every Contract hold only editorial content?\n2. Is every placement, appearance or behaviour choice a setting of a Template?\n3. Is every closed choice a category with no default, and every nested follow-the-parent choice an `inherit`?\n4. Does every presentation field name the Templates it accepts, and do containers accept leaf Templates only?\n5. Are all field ids kebab-case and all prose localizable?\n6. Is there a renderer for every Template, registered by Template?\n7. If you ship it: is there a major-version marker, a changelog, and a test that installs it twice and saves every Contract?\n"
     },
     {
         "slug": "content-personalization",
@@ -126,7 +126,7 @@ export const HELP_TOPICS = [
     {
         "slug": "rendering-your-site",
         "title": "Rendering your site",
-        "body": "# Rendering your site\n\nRead this before you write any code that fetches published content. Content is published to the\n**Content Delivery API**, and ebitex ships a client for it: **`@ebitex/content-sdk`** on npm (and\n`Ebitex.Content.Delivery` on NuGet for a .NET server). Use it unless you have a reason not to. The\nreasons are below, because a hand-written client looks easy on the day it is written and costs the\nmost later.\n\nThis page is for the person or agent building the site that shows the content. Building the content\nmodel itself is [Building a content model through the API](agent-authoring.md).\n\n## Start from the SDK\n\n```sh\nnpm install @ebitex/content-sdk\n```\n\n- **A Vite and React site** that renders in the browser: `createContentClient` and the components in\n  `@ebitex/content-sdk/react`.\n- **A Next.js (or other server-rendered) site**: the same package, with the key kept on the server.\n  The guide is *Render content on a server* at developers.ebitex.io.\n- **A .NET server**: `Ebitex.Content.Delivery`.\n\nGuides, the API reference and the SDK reference are all at **developers.ebitex.io**. For the exact\nshape of a request or a response, read the OpenAPI document at `https://api.ebitex.io/openapi/public.json`\nrather than inferring it from a few responses you have seen.\n\n## What you stop maintaining\n\nA site that calls the Delivery API with its own `fetch` code owns all of this, and none of it shows\nup until something breaks:\n\n- **Path resolution, components, streams and facets, media and response parsing.** The SDK has one\n  method per endpoint and is updated when the API is. A client written against the responses seen on\n  one day is wrong the first day the API adds a member or a mode.\n- **The sitemap.** `buildSitemapDocuments` (in `@ebitex/content-sdk/sitemap`) splits at the protocol\n  limits, writes the index, and emits `hreflang` alternates when given a `localeUrl`. A hand-built\n  sitemap usually has none of these, and joining URLs by string concatenation produces addresses\n  like `//sitemap.xml`.\n- **Live preview and click-to-edit.** `@ebitex/content-sdk/preview` needs the annotated responses\n  of a preview session. A client that parses only the fields it renders discards the annotations,\n  so the editor cannot point at anything on the page. This is the feature a hand-written client\n  most often loses without anyone noticing.\n- **Locale addressing.** Under the *path prefix* and *locale host* strategies every address the API\n  returns already carries its language (see [Locale addressing](locale-addressing.md)). A client\n  that adds its own `/${locale}` prefix doubles it (`/fr/fr/cafes`), and one that assumes a prefix\n  where the site has none links its home page to a 404.\n- **Caching and invalidation.** What may be cached, for how long, under which key, and what a\n  publish should purge.\n- **References that need expanding.** A delivered Presentation is usually a reference. A renderer\n  that does not ask the API to resolve it renders a hollow page and nothing reports it.\n\nIf you do write your own client, treat that list as the checklist of what you are taking on.\n\n## Building in a sandbox\n\nAn organization an agency is building for a client is a **sandbox**. Every Delivery API response from it carries an `X-Ebitex-Sandbox` header and `X-Robots-Tag: noindex`, so a site rendered from it is not indexed by search engines. The SDK reads the header: the client's `sandbox` property says whether the content came from a sandbox, `buildSitemapDocuments` answers a `robots` document that disallows everything while it does, and `onSandbox` lets your renderer add a visible marker. When the sandbox goes live the header disappears and the same code serves a normal site, with nothing to change. See [Agencies and sandboxes](../hub/agencies.md).\n\n## Moving a hand-written client to the SDK\n\nYou can move in steps and keep your own renderers and parsers:\n\n1. Install the package and create a client with the same key you use now.\n2. Replace the fetch calls with the client's methods, one endpoint at a time. The responses are the\n   API's own, so the code that reads them keeps working.\n3. Remove any locale prefix your code adds, if the site's locale addressing is not *invariant*.\n4. Replace the sitemap and `robots` code with `buildSitemapDocuments`.\n5. Add the preview bridge from `@ebitex/content-sdk/preview`, and have your preview route call the\n   preview endpoints so the responses carry their annotations.\n6. Delete the hand-written client and its tests.\n\n## Related\n\n- [Building a content model through the API](agent-authoring.md): the model, before the site\n- [Locale addressing](locale-addressing.md): how addresses carry a language\n- [Publishing content](publishing.md): what the Delivery API serves, and when\n- [Management keys](management-keys.md) and [Deployment keys](deployment-keys.md): the two kinds of key\n"
+        "body": "# Rendering your site\n\nRead this before you write any code that fetches published content. Content is published to the\n**Content Delivery API**, and ebitex ships a client for it: **`@ebitex/content-sdk`** on npm (and\n`Ebitex.Content.Delivery` on NuGet for a .NET server). Use it unless you have a reason not to. The\nreasons are below, because a hand-written client looks easy on the day it is written and costs the\nmost later.\n\nThis page is for the person or agent building the site that shows the content. Building the content\nmodel itself is [Building a content model through the API](agent-authoring.md).\n\n## Start from the SDK\n\n```sh\nnpm install @ebitex/content-sdk\n```\n\n- **A Vite and React site** that renders in the browser: `createContentClient` and the components in\n  `@ebitex/content-sdk/react`.\n- **A Next.js (or other server-rendered) site**: the same package, with the key kept on the server.\n  The guide is *Render content on a server* at developers.ebitex.io.\n- **A .NET server**: `Ebitex.Content.Delivery`.\n\nGuides, the API reference and the SDK reference are all at **developers.ebitex.io**. For the exact\nshape of a request or a response, read the OpenAPI document at `https://api.ebitex.io/openapi/public.json`\nrather than inferring it from a few responses you have seen.\n\n## What you stop maintaining\n\nA site that calls the Delivery API with its own `fetch` code owns all of this, and none of it shows\nup until something breaks:\n\n- **Path resolution, components, streams and facets, media and response parsing.** The SDK has one\n  method per endpoint and is updated when the API is. A client written against the responses seen on\n  one day is wrong the first day the API adds a member or a mode.\n- **The sitemap.** `buildSitemapDocuments` (in `@ebitex/content-sdk/sitemap`) splits at the protocol\n  limits, writes the index, and emits `hreflang` alternates when given a `localeUrl`. A hand-built\n  sitemap usually has none of these, and joining URLs by string concatenation produces addresses\n  like `//sitemap.xml`.\n- **Live preview and click-to-edit.** `@ebitex/content-sdk/preview` needs the annotated responses\n  of a preview session. A client that parses only the fields it renders discards the annotations,\n  so the editor cannot point at anything on the page. This is the feature a hand-written client\n  most often loses without anyone noticing.\n- **Locale addressing.** Under the *path prefix* and *locale host* strategies every address the API\n  returns already carries its language (see [Locale addressing](locale-addressing.md)). A client\n  that adds its own `/${locale}` prefix doubles it (`/fr/fr/cafes`), and one that assumes a prefix\n  where the site has none links its home page to a 404.\n- **Caching and invalidation.** What may be cached, for how long, under which key, and what a\n  publish should purge.\n- **References that need expanding.** A delivered Presentation is usually a reference. A renderer\n  that does not ask the API to resolve it renders a hollow page and nothing reports it.\n\nIf you do write your own client, treat that list as the checklist of what you are taking on.\n\n## Previewing a section or a shared Component\n\nLive preview needs nothing new from your site to preview a presentation. The bridge renders whatever document it is sent on any page, so a shared Component is previewed inside a real page that uses it, and a header or footer your site mounts with `<StandaloneComponent>` is previewed on any page that draws it. See [Preview a section, a header or a shared Component](content-composer.md).\n\n## Building in a sandbox\n\nAn organization an agency is building for a client is a **sandbox**. Every Delivery API response from it carries an `X-Ebitex-Sandbox` header and `X-Robots-Tag: noindex`, so a site rendered from it is not indexed by search engines. The SDK reads the header: the client's `sandbox` property says whether the content came from a sandbox, `buildSitemapDocuments` answers a `robots` document that disallows everything while it does, and `onSandbox` lets your renderer add a visible marker. When the sandbox goes live the header disappears and the same code serves a normal site, with nothing to change. See [Agencies and sandboxes](../hub/agencies.md).\n\n## Moving a hand-written client to the SDK\n\nYou can move in steps and keep your own renderers and parsers:\n\n1. Install the package and create a client with the same key you use now.\n2. Replace the fetch calls with the client's methods, one endpoint at a time. The responses are the\n   API's own, so the code that reads them keeps working.\n3. Remove any locale prefix your code adds, if the site's locale addressing is not *invariant*.\n4. Replace the sitemap and `robots` code with `buildSitemapDocuments`.\n5. Add the preview bridge from `@ebitex/content-sdk/preview`, and have your preview route call the\n   preview endpoints so the responses carry their annotations.\n6. Delete the hand-written client and its tests.\n\n## Related\n\n- [Building a content model through the API](agent-authoring.md): the model, before the site\n- [Locale addressing](locale-addressing.md): how addresses carry a language\n- [Publishing content](publishing.md): what the Delivery API serves, and when\n- [Management keys](management-keys.md) and [Deployment keys](deployment-keys.md): the two kinds of key\n"
     },
     {
         "slug": "sample-references",
@@ -136,7 +136,7 @@ export const HELP_TOPICS = [
     {
         "slug": "starter-kit",
         "title": "Starter kits",
-        "body": "# Starter kits\n\nA **starter kit** gives you a working set of Contracts, Templates, categories and a demo experience, so you start from something instead of nothing. Install it once, then change anything you like: it becomes your own content and never updates by itself.\n\n## Adding a starter kit\n\nOpen **Starter kits** under **Tools**.\n\n1. Read what the kit will add and what you already have, and any permission you are missing. The page tells you before you start, not after.\n2. If Assets is not connected, connect it from the same page first. The kit's media fields choose from your Assets library.\n3. Leave **Include the demo experience** on if you want a finished example to learn from, or clear it to add only the building blocks. The demo's items are all named \"Demo\".\n4. Select **Install the kit**.\n\nWhen it finishes the page tells you the kit is installed, and links to your Contracts and Templates.\n\n## What is safe\n\n- Nothing you already have is changed. If an item with the same name exists, it is left exactly as it is and the preview tells you.\n- Running it again adds only what is missing.\n- If anything goes wrong, nothing from that attempt is kept.\n\n## How the kit is built\n\nThe kit separates **what a section says** from **how it is shown**.\n\n- A **Contract** holds only the content: a hero's heading and lead, a card's title and summary, a tab's label.\n- A **Template** says how a Contract is drawn, and has its own **settings** for the choices that belong to a place: width, background, appearance, a card's emphasis, a banner's tone, a grid's columns, how an accordion behaves.\n- An experience's **Hero** and **Sections** are *presentations*: you choose a Template, set its settings, and give it a Component. The same Component can be used on many pages, each with its own settings, so it looks or behaves differently in each.\n- **Tabs** and **Accordion** hold their own items. Each item is a label and the presentations inside it, so a whole FAQ is one Component you can reuse on every page that needs it.\n- Two Templates can present the same Contract in different ways. Make a second Template over a Contract when the same words need a different look, rather than copying the Contract.\n\n## After you install\n\nEverything is yours. Edit a Contract, rename a category, restyle a theme, or delete what you do not need. Nothing is linked back to the kit, and a newer version of the kit never changes what you have. Installing again adds only what is missing.\n\nA new **major** version of the kit is not mixed into an earlier one, because its Templates would sit beside Contracts of the old shape. If your environment holds an earlier version, the install tells you so and changes nothing; your copy is left exactly as it is. To use the new version, install it into a new environment or organization.\n\nTo use your own Template in an experience's **Sections**, open the experience's Contract and add your Template to the Sections field's allowed Templates. The kit lists the Templates it accepts, so Hero and the experience itself can never be placed as a section.\n\n## Themes and appearances\n\nAn experience has a **theme**, which sets its colours, type and spacing, chosen in the experience Template's settings; leave it empty for the default. A section can have an **appearance** that adjusts the theme for that section and everything nested inside it; leave it on **Inherit** to take the parent's. Themes and appearances are categories, so you edit them under **Categories**.\n\n## Pictures and video\n\nMedia fields use the Assets app, so Assets has to be connected to Content before the kit can be installed. The Starter kits page offers the one-step **Connect Assets** card when it is not.\n"
+        "body": "# Starter kits\n\nA **starter kit** gives you a working set of Contracts, Templates, categories and a demo experience, so you start from something instead of nothing. Install it once, then change anything you like: it becomes your own content and never updates by itself.\n\n## Adding a starter kit\n\nOpen **Starter kits** under **Tools**.\n\n1. Read what the kit will add and what you already have, and any permission you are missing. The page tells you before you start, not after.\n2. If Assets is not connected, connect it from the same page first. The kit's media fields choose from your Assets library.\n3. Leave **Include the demo experience** on if you want a finished example to learn from, or clear it to add only the building blocks. The demo's items are all named \"Demo\".\n4. Select **Install the kit**.\n\nWhen it finishes the page tells you the kit is installed, and links to your Contracts and Templates.\n\n## What is safe\n\n- Nothing you already have is changed. If an item with the same name exists, it is left exactly as it is and the preview tells you.\n- Running it again adds only what is missing.\n- If anything goes wrong, nothing from that attempt is kept.\n\n## How the kit is built\n\nThe kit separates **what a section says** from **how it is shown**.\n\n- A **Contract** holds only the content: a hero's heading and lead, a card's title and summary, a tab's label.\n- A **Template** says how a Contract is drawn, and has its own **settings** for the choices that belong to a place: width, background, appearance, a card's emphasis, a banner's tone, a grid's columns, how an accordion behaves.\n- An experience's **Hero** and **Sections** are *presentations*: you choose a Template, set its settings, and give it a Component. The same Component can be used on many pages, each with its own settings, so it looks or behaves differently in each.\n- **Tabs** and **Accordion** hold their own items. Each item is a label and the presentations inside it, so a whole FAQ is one Component you can reuse on every page that needs it.\n- Two Templates can present the same Contract in different ways. Make a second Template over a Contract when the same words need a different look, rather than copying the Contract.\n\n## A header and footer for the whole site\n\nThe kit has a **Site chrome** Component with a **Header** and a **Footer**. The header holds the logo, the site name, a few links and one button; the footer holds the logo, a line of text, links and a copyright line. Pick the logo from Assets.\n\n1. Open the **Site chrome** Component in **Authoring** and change the header and footer. The header's Template settings say whether it stays on screen as the page scrolls, how large the logo is and its appearance; the footer's say its appearance.\n2. **Publish the Site chrome Component itself.** It is not part of any page, so publishing a page does not publish it, and the installer never publishes anything.\n3. Your site fetches it by its id, so every page gets the same header and footer, and a change to it is live everywhere after you publish.\n\nIf it is not published, the pages are drawn without a header and footer and nothing breaks.\n\n## Groups: a heading over what belongs together\n\nA **Group** is a section with an optional eyebrow (a small label) and heading, and any number of presentations inside it: a heading over three cards, a heading over a list of questions. Its Template's settings give the whole group its width, background, appearance and anchor, and **Spacing** (compact, standard, spacious) and **Align** (the heading at the start or centred). Set an appearance on the Group and everything inside takes it; a presentation inside can choose its own.\n\nIf you installed an earlier version of the kit, add **Group** to your experience Contract's **Sections** allowed Templates, as you would for any Template of your own.\n\n## Icons on features\n\nA Feature's **Icon** can be the name of one of the kit's line icons (`billiards`, `target`, `beer`, `bolt`, `puzzle`, `palette`, `star`, `check`, `heart`, `clock`, `pin`, `phone`, `mail`, `shield`, `users`, `trophy`), drawn in your accent colour, or any other text such as an emoji, which is drawn as written.\n\n## After you install\n\nEverything is yours. Edit a Contract, rename a category, restyle a theme, or delete what you do not need. Nothing is linked back to the kit, and a newer version of the kit never changes what you have. Installing again adds only what is missing.\n\nA new **major** version of the kit is not mixed into an earlier one, because its Templates would sit beside Contracts of the old shape. If your environment holds an earlier version, the install tells you so and changes nothing; your copy is left exactly as it is. To use the new version, install it into a new environment or organization.\n\nTo use your own Template in an experience's **Sections**, open the experience's Contract and add your Template to the Sections field's allowed Templates. The kit lists the Templates it accepts, so Hero and the experience itself can never be placed as a section.\n\n## Themes and appearances\n\nAn experience has a **theme**, which sets its colours, type and spacing, chosen in the experience Template's settings; leave it empty for the default. A section can have an **appearance** that adjusts the theme for that section and everything nested inside it; leave it on **Inherit** to take the parent's. Themes and appearances are categories, so you edit them under **Categories**.\n\n## Pictures and video\n\nMedia fields use the Assets app, so Assets has to be connected to Content before the kit can be installed. The Starter kits page offers the one-step **Connect Assets** card when it is not.\n"
     },
     {
         "slug": "tasks",

package/dist/resources/helpCorpus.generated.js.map

@@ -1 +1 @@
-{"version":3,"file":"helpCorpus.generated.js","sourceRoot":"","sources":["../../src/resources/helpCorpus.generated.ts"],"names":[],"mappings":"AAAA,qDAAqD;AACrD,EAAE;AACF,kGAAkG;AAClG,oGAAoG;AAIpG,MAAM,CAAC,MAAM,WAAW,GAAgB;IACtC;QACE,MAAM,EAAE,iBAAiB;QACzB,OAAO,EAAE,0CAA0C;QACnD,MAAM,EAAE,sqaAAsqa;KAC/qa;IACD;QACE,MAAM,EAAE,aAAa;QACrB,OAAO,EAAE,aAAa;QACtB,MAAM,EAAE,wnGAAwnG;KACjoG;IACD;QACE,MAAM,EAAE,YAAY;QACpB,OAAO,EAAE,sBAAsB;QAC/B,MAAM,EAAE,870BAA870B;KACv80B;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,kCAAkC;QAC3C,MAAM,EAAE,06nBAA06nB;KACn7nB;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,0BAA0B;QACnC,MAAM,EAAE,i9OAAi9O;KAC19O;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,gCAAgC;QACzC,MAAM,EAAE,60sBAA60sB;KACt1sB;IACD;QACE,MAAM,EAAE,sBAAsB;QAC9B,OAAO,EAAE,sBAAsB;QAC/B,MAAM,EAAE,o9lBAAo9lB;KAC79lB;IACD;QACE,MAAM,EAAE,eAAe;QACvB,OAAO,EAAE,qCAAqC;QAC9C,MAAM,EAAE,q3FAAq3F;KAC93F;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,wCAAwC;QACjD,MAAM,EAAE,miRAAmiR;KAC5iR;IACD;QACE,MAAM,EAAE,yBAAyB;QACjC,OAAO,EAAE,4BAA4B;QACrC,MAAM,EAAE,ksRAAksR;KAC3sR;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,mBAAmB;QAC5B,MAAM,EAAE,oxRAAoxR;KAC7xR;IACD;QACE,MAAM,EAAE,iBAAiB;QACzB,OAAO,EAAE,4CAA4C;QACrD,MAAM,EAAE,22GAA22G;KACp3G;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,UAAU;QACnB,MAAM,EAAE,iqQAAiqQ;KAC1qQ;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,oBAAoB;QAC7B,MAAM,EAAE,okYAAokY;KAC7kY;IACD;QACE,MAAM,EAAE,WAAW;QACnB,OAAO,EAAE,iCAAiC;QAC1C,MAAM,EAAE,ousBAAousB;KAC7usB;IACD;QACE,MAAM,EAAE,iBAAiB;QACzB,OAAO,EAAE,iBAAiB;QAC1B,MAAM,EAAE,g6HAAg6H;KACz6H;IACD;QACE,MAAM,EAAE,qBAAqB;QAC7B,OAAO,EAAE,qBAAqB;QAC9B,MAAM,EAAE,+iFAA+iF;KACxjF;IACD;QACE,MAAM,EAAE,eAAe;QACvB,OAAO,EAAE,mBAAmB;QAC5B,MAAM,EAAE,u9JAAu9J;KACh+J;IACD;QACE,MAAM,EAAE,MAAM;QACd,OAAO,EAAE,MAAM;QACf,MAAM,EAAE,y9FAAy9F;KACl+F;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,mBAAmB;QAC5B,MAAM,EAAE,o+LAAo+L;KAC7+L;IACD;QACE,MAAM,EAAE,iBAAiB;QACzB,OAAO,EAAE,iBAAiB;QAC1B,MAAM,EAAE,6uNAA6uN;KACtvN;IACD;QACE,MAAM,EAAE,WAAW;QACnB,OAAO,EAAE,WAAW;QACpB,MAAM,EAAE,0oSAA0oS;KACnpS;IACD;QACE,MAAM,EAAE,YAAY;QACpB,OAAO,EAAE,oBAAoB;QAC7B,MAAM,EAAE,y5YAAy5Y;KACl6Y;IACD;QACE,MAAM,EAAE,QAAQ;QAChB,OAAO,EAAE,QAAQ;QACjB,MAAM,EAAE,spOAAspO;KAC/pO;IACD;QACE,MAAM,EAAE,qBAAqB;QAC7B,OAAO,EAAE,qBAAqB;QAC9B,MAAM,EAAE,i2JAAi2J;KAC12J;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,+BAA+B;QACxC,MAAM,EAAE,g2EAAg2E;KACz2E;IACD;QACE,MAAM,EAAE,aAAa;QACrB,OAAO,EAAE,cAAc;QACvB,MAAM,EAAE,2qHAA2qH;KACprH;IACD;QACE,MAAM,EAAE,OAAO;QACf,OAAO,EAAE,OAAO;QAChB,MAAM,EAAE,i7FAAi7F;KAC17F;IACD;QACE,MAAM,EAAE,WAAW;QACnB,OAAO,EAAE,mCAAmC;QAC5C,MAAM,EAAE,69KAA69K;KACt+K;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,kBAAkB;QAC3B,MAAM,EAAE,yvJAAyvJ;KAClwJ;IACD;QACE,MAAM,EAAE,gBAAgB;QACxB,OAAO,EAAE,qCAAqC;QAC9C,MAAM,EAAE,qiPAAqiP;KAC9iP;CACF,CAAA"}
+{"version":3,"file":"helpCorpus.generated.js","sourceRoot":"","sources":["../../src/resources/helpCorpus.generated.ts"],"names":[],"mappings":"AAAA,qDAAqD;AACrD,EAAE;AACF,kGAAkG;AAClG,oGAAoG;AAIpG,MAAM,CAAC,MAAM,WAAW,GAAgB;IACtC;QACE,MAAM,EAAE,iBAAiB;QACzB,OAAO,EAAE,0CAA0C;QACnD,MAAM,EAAE,sqaAAsqa;KAC/qa;IACD;QACE,MAAM,EAAE,aAAa;QACrB,OAAO,EAAE,aAAa;QACtB,MAAM,EAAE,wnGAAwnG;KACjoG;IACD;QACE,MAAM,EAAE,YAAY;QACpB,OAAO,EAAE,sBAAsB;QAC/B,MAAM,EAAE,870BAA870B;KACv80B;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,kCAAkC;QAC3C,MAAM,EAAE,06nBAA06nB;KACn7nB;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,0BAA0B;QACnC,MAAM,EAAE,i9OAAi9O;KAC19O;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,gCAAgC;QACzC,MAAM,EAAE,uxvBAAuxvB;KAChyvB;IACD;QACE,MAAM,EAAE,sBAAsB;QAC9B,OAAO,EAAE,sBAAsB;QAC/B,MAAM,EAAE,o9lBAAo9lB;KAC79lB;IACD;QACE,MAAM,EAAE,eAAe;QACvB,OAAO,EAAE,qCAAqC;QAC9C,MAAM,EAAE,q3FAAq3F;KAC93F;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,wCAAwC;QACjD,MAAM,EAAE,m0TAAm0T;KAC50T;IACD;QACE,MAAM,EAAE,yBAAyB;QACjC,OAAO,EAAE,4BAA4B;QACrC,MAAM,EAAE,ksRAAksR;KAC3sR;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,mBAAmB;QAC5B,MAAM,EAAE,oxRAAoxR;KAC7xR;IACD;QACE,MAAM,EAAE,iBAAiB;QACzB,OAAO,EAAE,4CAA4C;QACrD,MAAM,EAAE,22GAA22G;KACp3G;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,UAAU;QACnB,MAAM,EAAE,iqQAAiqQ;KAC1qQ;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,oBAAoB;QAC7B,MAAM,EAAE,okYAAokY;KAC7kY;IACD;QACE,MAAM,EAAE,WAAW;QACnB,OAAO,EAAE,iCAAiC;QAC1C,MAAM,EAAE,ousBAAousB;KAC7usB;IACD;QACE,MAAM,EAAE,iBAAiB;QACzB,OAAO,EAAE,iBAAiB;QAC1B,MAAM,EAAE,g6HAAg6H;KACz6H;IACD;QACE,MAAM,EAAE,qBAAqB;QAC7B,OAAO,EAAE,qBAAqB;QAC9B,MAAM,EAAE,+iFAA+iF;KACxjF;IACD;QACE,MAAM,EAAE,eAAe;QACvB,OAAO,EAAE,mBAAmB;QAC5B,MAAM,EAAE,u9JAAu9J;KACh+J;IACD;QACE,MAAM,EAAE,MAAM;QACd,OAAO,EAAE,MAAM;QACf,MAAM,EAAE,y9FAAy9F;KACl+F;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,mBAAmB;QAC5B,MAAM,EAAE,o+LAAo+L;KAC7+L;IACD;QACE,MAAM,EAAE,iBAAiB;QACzB,OAAO,EAAE,iBAAiB;QAC1B,MAAM,EAAE,6uNAA6uN;KACtvN;IACD;QACE,MAAM,EAAE,WAAW;QACnB,OAAO,EAAE,WAAW;QACpB,MAAM,EAAE,0oSAA0oS;KACnpS;IACD;QACE,MAAM,EAAE,YAAY;QACpB,OAAO,EAAE,oBAAoB;QAC7B,MAAM,EAAE,y5YAAy5Y;KACl6Y;IACD;QACE,MAAM,EAAE,QAAQ;QAChB,OAAO,EAAE,QAAQ;QACjB,MAAM,EAAE,spOAAspO;KAC/pO;IACD;QACE,MAAM,EAAE,qBAAqB;QAC7B,OAAO,EAAE,qBAAqB;QAC9B,MAAM,EAAE,0xKAA0xK;KACnyK;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,+BAA+B;QACxC,MAAM,EAAE,g2EAAg2E;KACz2E;IACD;QACE,MAAM,EAAE,aAAa;QACrB,OAAO,EAAE,cAAc;QACvB,MAAM,EAAE,0mLAA0mL;KACnnL;IACD;QACE,MAAM,EAAE,OAAO;QACf,OAAO,EAAE,OAAO;QAChB,MAAM,EAAE,i7FAAi7F;KAC17F;IACD;QACE,MAAM,EAAE,WAAW;QACnB,OAAO,EAAE,mCAAmC;QAC5C,MAAM,EAAE,69KAA69K;KACt+K;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,kBAAkB;QAC3B,MAAM,EAAE,yvJAAyvJ;KAClwJ;IACD;QACE,MAAM,EAAE,gBAAgB;QACxB,OAAO,EAAE,qCAAqC;QAC9C,MAAM,EAAE,qiPAAqiP;KAC9iP;CACF,CAAA"}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ebitex/content-mcp",
-  "version": "1.1.268",
+  "version": "1.1.271",
   "description": "An MCP server for ebitex Content: build and publish a content model from an AI agent.",
   "license": "Apache-2.0",
   "homepage": "https://developers.ebitex.io/getting-started/content-as-code/",