@ebitex/content-mcp 1.0.217 → 1.0.219

package/dist/resources/helpCorpus.generated.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"helpCorpus.generated.d.ts","sourceRoot":"","sources":["../../src/resources/helpCorpus.generated.ts"],"names":[],"mappings":"AAKA,MAAM,MAAM,SAAS,GAAG;IAAE,IAAI,EAAE,MAAM,CAAC;IAAC,KAAK,EAAE,MAAM,CAAC;IAAC,IAAI,EAAE,MAAM,CAAA;CAAE,CAAA;AAErE,eAAO,MAAM,WAAW,EAAE,SAAS,EAwIlC,CAAA"}
+{"version":3,"file":"helpCorpus.generated.d.ts","sourceRoot":"","sources":["../../src/resources/helpCorpus.generated.ts"],"names":[],"mappings":"AAKA,MAAM,MAAM,SAAS,GAAG;IAAE,IAAI,EAAE,MAAM,CAAC;IAAC,KAAK,EAAE,MAAM,CAAC;IAAC,IAAI,EAAE,MAAM,CAAA;CAAE,CAAA;AAErE,eAAO,MAAM,WAAW,EAAE,SAAS,EA6IlC,CAAA"}

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: **Change** on\nthe Template and on the Component, **Configure** where there are settings or contextual values to\nfill in, **Mapping** on an Adapter, and **Quick edit** on the Component. 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  empty 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: **Change** on\nthe Template and on the Component, **Configure** where there are settings or contextual values to\nfill in, **Mapping** on an Adapter, and **Quick edit** on the Component. 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"
     },
     {
         "slug": "content-environments",
@@ -61,7 +61,7 @@ export const HELP_TOPICS = [
     {
         "slug": "content-taxonomy",
         "title": "Taxonomy",
-        "body": "# Taxonomy\n\nOrganize your content with named classification trees — usable both as tags on Components,\nExperience pages, and Contracts (for findability and bulk operations) and as a field type your\nContracts can use directly.\n\n## Where the vocabulary lives\n\nThe category groups and categories themselves — the **vocabulary** — belong to your organization, not\nto Content alone: the same \"Topics\" or \"Regions\" that classify a Component can classify an asset in\nAssets. They are managed in **Hub › Taxonomy** (see the Hub guide), where each group shows where it is\nin use.\n\nContent's own **Taxonomy** page, under **Configure**, answers a different question: **which of the\norganization's groups can editors use in this environment?** A group is only visible here once it has\nbeen added, and other environments — including a sub-tenant's — never see a group nobody added to\nthem. The page has two lists:\n\n- **In this environment** — the groups editors can tag with and pick in Category fields here, with\n  how many categories each has and whether it carries a metadata Contract here. **Remove from this\n  environment** hides a group from pickers again; it is disabled, with the reason, while anything\n  here is still tagged with one of its categories, a Category field value still names one, or a\n  Category field on a Contract restricts to the group. Removing never deletes the group, its\n  categories, or anything already tagged.\n- **Available to add** — the organization's groups not yet in use here. **Add to this environment**\n  makes one usable; optionally give it a metadata document here at the same time (below).\n\nWith nothing added yet, the page shows one message with **Choose groups to add** and **New group**; the longer\nexplanation of how categories are shared is behind **How categories work** under the title.\n\nAdding and removing needs the **Manage Content taxonomy** permission (`content.taxonomy.manage`).\n**New group** creates a group in the organization vocabulary *and* adds it here in one step; because\nit writes the vocabulary it also needs `platform.taxonomy.manage`.\n\n### Editing the tree from Content\n\nBelow the two lists, the page shows the vocabulary for every group added here — the same tree editor\nHub uses. If you hold `platform.taxonomy.manage` you can add, rename, move and delete categories right\nthere; a change applies in every environment and app at once. Without it the tree is read-only, and\neach button says so.\n\n### Missing a group?\n\nIf the group you expect is not in the category picker, it has not been added to this environment.\nSomeone with `content.taxonomy.manage` sees a **Manage groups in this environment** link at the\nbottom of the picker that goes straight to the Taxonomy page; everyone else simply does not see the\ngroup, which is the point.\n\n## CategoryGroups and Categories\n\nA **CategoryGroup** is the root of one tree — \"Topics,\" \"Regions,\" \"Campaigns.\"\n\nA **Category** is one node in a group's tree. Each category has:\n\n- A **key** (used in paths and safe to keep even if you change the display value)\n- A **display value** — localizable, like any other text in the app\n- **Selectable** — turned off, a category becomes a purely structural branch: something you can\n  nest other categories under, but never assign to content directly. Use this for organizing\n  headings like \"Seating\" that shouldn't themselves be a tag.\n\nA category can be nested under another category in the same group, to any depth. You can't delete\na category (or turn off its Selectable flag) while anything in any app still references it — the\ndialog lists every usage, per app and environment, so you can decouple them first.\n\n### Metadata\n\nWhen adding a group to an environment (or creating one from Content), you can optionally attach a\n**metadata Contract** — the same kind of structure definition you use for content, but describing\nextra information every category in this group should carry *in this environment* (an icon name, a\ncolor, a short blurb). If a group has a metadata Contract here, every category in it gets a\n**Metadata** editor in the tree. Metadata is Content's and per environment: the organization's\nvocabulary carries none, and removing the group from an environment removes its metadata Contract and\ndocuments there.\n\n## Tagging content\n\nOpen any Component (under its **Settings** tab), Experience page, or Contract (under its\n**General** tab) and find the **Categories** panel. **Add tag…** opens a picker scoped to one\ngroup at a time (or a specific group, if the page only allows one); pick any selectable category\nand it's added. Only groups added to the current environment are offered. Tags are separate from\nany Category field value the item's Contract might also have — think of tags as sticky notes for\nfinding and grouping things, not part of the content itself. Tagging a Contract needs the same\npermission that lets you edit the Contract at all; Templates can't be tagged yet.\n\n## Filtering by category\n\nThe Component library has a **Filter by category** control — pick a category and the list narrows\nto everything tagged with it (or a category nested under it). Select several items from a filtered\nlist and use **Publish N selected…** to publish them all together through the usual publish dialog,\nwhich shows the combined set of everything each selected item depends on.\n\nThe Experience page has the same **Filter by category** control on its site tree. Because the tree\nonly loads a branch's children when you expand it, picking a category automatically expands every\nancestor branch needed to reach each matching page, highlights the matches, and dims everything\nelse that's visible without hiding it — so you can still see where a match sits relative to the\nrest of the site. Clearing the filter leaves the tree as you left it.\n\n## Filtering which Contract you pick\n\nWhen adding new content from an Experience page's payload editor — \"New Component\" or \"Create\ninline\" — the Contract picker offers a **Filter by category** button. Pick a category and the\nchoices narrow to Contracts tagged with it; **Clear** brings back the full list. This is a\nconvenience for a large Contract library — it defaults to showing every eligible Contract, and you\ncan always clear the filter to reach one that isn't tagged.\n\n## Using a Category field on a Contract\n\nWhen building a Contract, add a field with type **Category**. In its settings, you can restrict\nwhich CategoryGroup(s) the field accepts — leave it empty to allow any group. In the Component\neditor, that field shows a **Choose…** button opening the same category picker; the chosen\ncategory displays as its full path (e.g. `topics/tech/ai`).\n\n## What happens when you rename or move a category\n\nRenaming a category, or moving it to a different parent, updates everywhere it's referenced\nimmediately — in every environment and app, no republishing needed. What *does* require\nrepublishing is a **tag added after publish**: a Component's set of published categories is frozen\nat publish time, exactly like its content. If you tag something new and want that reflected in\ndelivered results, publish it again.\n\n## Promotion and inheritance\n\nThe vocabulary exists in every environment already, so promoting tagged content never copies\ncategories. What rides along is the **group's presence**: promoting something tagged with a group\nnot yet added to the target adds it there (with its metadata Contract, if any), so the tags still\nvalidate. Environment inheritance works the same way — a child environment inherits which groups its\nparent has added, and their metadata, as read-only.\n\n## External taxonomy\n\nIf your organization has registered a content provider that also supplies taxonomy, its groups and\ncategories appear in the picker and the Taxonomy page alongside your own — marked **synced** and\nread-only. They belong to the environment the provider is registered in rather than to the\norganization vocabulary, and work identically to your own categories everywhere except editing:\nyou can tag content with them and use them in Category fields, but changing them happens on the\nprovider's own side, refreshed the same way its other content is.\n"
+        "body": "# Taxonomy\n\nOrganize your content with named classification trees — usable both as tags on Components,\nExperience pages, and Contracts (for findability and bulk operations) and as a field type your\nContracts can use directly.\n\n## Where the vocabulary lives\n\nThe category groups and categories themselves — the **vocabulary** — belong to your organization, not\nto Content alone: the same \"Topics\" or \"Regions\" that classify a Component can classify an asset in\nAssets. They are managed in **Hub › Taxonomy** (see the Hub guide), where each group shows where it is\nin use.\n\nContent's own **Taxonomy** page, under **Configure**, answers a different question: **which of the\norganization's groups can editors use in this environment?** A group is only visible here once it has\nbeen added, and other environments — including a sub-tenant's — never see a group nobody added to\nthem. The page has two lists:\n\n- **In this environment** — the groups editors can tag with and pick in Category fields here, with\n  how many categories each has and whether it carries a metadata Contract here. **Remove from this\n  environment** hides a group from pickers again; it is disabled, with the reason, while anything\n  here is still tagged with one of its categories, a Category field value still names one, or a\n  Category field on a Contract restricts to the group. Removing never deletes the group, its\n  categories, or anything already tagged.\n- **Available to add** — the organization's groups not yet in use here. **Add to this environment**\n  makes one usable; optionally give it a metadata document here at the same time (below).\n\nWith nothing added yet, the page shows one message with **Choose groups to add** and **New group**; the longer\nexplanation of how categories are shared is behind **How categories work** under the title.\n\nAdding and removing needs the **Manage Content taxonomy** permission (`content.taxonomy.manage`).\n**New group** creates a group in the organization vocabulary *and* adds it here in one step; because\nit writes the vocabulary it also needs `platform.taxonomy.manage`.\n\n### Editing the tree from Content\n\nBelow the two lists, the page shows the vocabulary for every group added here — the same tree editor\nHub uses. If you hold `platform.taxonomy.manage` you can add, rename, move and delete categories right\nthere; a change applies in every environment and app at once. Without it the tree is read-only, and\neach button says so.\n\n### Missing a group?\n\nIf the group you expect is not in the category picker, it has not been added to this environment.\nSomeone with `content.taxonomy.manage` sees a **Manage groups in this environment** link at the\nbottom of the picker that goes straight to the Taxonomy page; everyone else simply does not see the\ngroup, which is the point.\n\n## CategoryGroups and Categories\n\nA **CategoryGroup** is the root of one tree — \"Topics,\" \"Regions,\" \"Campaigns.\"\n\nA **Category** is one node in a group's tree. Each category has:\n\n- A **key** (used in paths and safe to keep even if you change the display value)\n- A **display value** — localizable, like any other text in the app\n- **Selectable** — turned off, a category becomes a purely structural branch: something you can\n  nest other categories under, but never assign to content directly. Use this for organizing\n  headings like \"Seating\" that shouldn't themselves be a tag.\n\nA category can be nested under another category in the same group, to any depth. You can't delete\na category (or turn off its Selectable flag) while anything in any app still references it — the\ndialog lists every usage, per app and environment, so you can decouple them first.\n\n### Metadata\n\nWhen adding a group to an environment (or creating one from Content), you can optionally attach a\n**metadata Contract** — the same kind of structure definition you use for content, but describing\nextra information every category in this group should carry *in this environment* (an icon name, a\ncolor, a short blurb). If a group has a metadata Contract here, every category in it gets a\n**Metadata** editor in the tree. Metadata is Content's and per environment: the organization's\nvocabulary carries none, and removing the group from an environment removes its metadata Contract and\ndocuments there.\n\n## Tagging content\n\nOpen any Component (under its **Settings** tab), Experience page, or Contract (under its\n**General** tab) and find the **Categories** panel. **Add tag…** opens a picker scoped to one\ngroup at a time (or a specific group, if the page only allows one); pick any selectable category\nand it's added. Only groups added to the current environment are offered. Tags are separate from\nany Category field value the item's Contract might also have — think of tags as sticky notes for\nfinding and grouping things, not part of the content itself. Tagging a Contract needs the same\npermission that lets you edit the Contract at all; Templates can't be tagged yet.\n\n## Filtering by category\n\nThe Component library has a **Filter by category** control — pick a category and the list narrows\nto everything tagged with it (or a category nested under it). Select several items from a filtered\nlist and use **Publish N selected…** to publish them all together through the usual publish dialog,\nwhich shows the combined set of everything each selected item depends on.\n\nThe Experience page has the same **Filter by category** control on its site tree. Because the tree\nonly loads a branch's children when you expand it, picking a category automatically expands every\nancestor branch needed to reach each matching page, highlights the matches, and dims everything\nelse that's visible without hiding it — so you can still see where a match sits relative to the\nrest of the site. Clearing the filter leaves the tree as you left it.\n\n## Filtering which Contract you pick\n\nWhen adding new content from an Experience page's payload editor — \"New Component\" or \"Create\ninline\" — the Contract picker offers a **Filter by category** button. Pick a category and the\nchoices narrow to Contracts tagged with it; **Clear** brings back the full list. This is a\nconvenience for a large Contract library — it defaults to showing every eligible Contract, and you\ncan always clear the filter to reach one that isn't tagged.\n\n## Using a Category field on a Contract\n\nWhen building a Contract, add a field with type **Category**. In its settings, you can restrict\nwhich CategoryGroup(s) the field accepts — leave it unset (**Any group**) to allow any group, or tick the groups it accepts. Unticking the last group leaves **Nothing allowed**, which is not the same as any group; **Allow any** returns to the default. In the Component\neditor, that field shows a **Choose…** button opening the same category picker; the chosen\ncategory displays as its full path (e.g. `topics/tech/ai`).\n\n## What happens when you rename or move a category\n\nRenaming a category, or moving it to a different parent, updates everywhere it's referenced\nimmediately — in every environment and app, no republishing needed. What *does* require\nrepublishing is a **tag added after publish**: a Component's set of published categories is frozen\nat publish time, exactly like its content. If you tag something new and want that reflected in\ndelivered results, publish it again.\n\n## Promotion and inheritance\n\nThe vocabulary exists in every environment already, so promoting tagged content never copies\ncategories. What rides along is the **group's presence**: promoting something tagged with a group\nnot yet added to the target adds it there (with its metadata Contract, if any), so the tags still\nvalidate. Environment inheritance works the same way — a child environment inherits which groups its\nparent has added, and their metadata, as read-only.\n\n## External taxonomy\n\nIf your organization has registered a content provider that also supplies taxonomy, its groups and\ncategories appear in the picker and the Taxonomy page alongside your own — marked **synced** and\nread-only. They belong to the environment the provider is registered in rather than to the\norganization vocabulary, and work identically to your own categories everywhere except editing:\nyou can tag content with them and use them in Category fields, but changing them happens on the\nprovider's own side, refreshed the same way its other content is.\n"
     },
     {
         "slug": "content-workflow",
@@ -71,7 +71,7 @@ export const HELP_TOPICS = [
     {
         "slug": "contracts",
         "title": "Modeling content with Contracts",
-        "body": "# Modeling content with Contracts\n\nContracts define the field structure your content adheres to — think of a\nContract as a blueprint (for example \"Article\" or \"Author\") that every\nComponent built from it must follow. You need to belong to an organization to\nuse it — see [Creating an organization and inviting\nteammates](../hub/organizations.md) if you haven't set one up yet.\n\n## The Contracts list\n\n**Modeling > Contracts** lists every Contract with its name, its id (smaller, underneath), whether it is\nconcrete or abstract, which Contract it extends, how many fields it has, what it is used as, and when it\nlast changed.\n\n**What a Contract is used for is worked out from how it is used, never set by hand.** The row of buttons above\nthe list filters by it, with a count on each, and a Contract can sit in several at once:\n\n- **Components** — Components have been created from it.\n- **Experiences** — a Component of this Contract is the content of a page in your Experience tree.\n- **Templates** — it is a Template's own settings Contract. (A Contract a Template merely *supports* is an\n  ordinary content Contract, so it shows under Components, not here.)\n- **Base** — it is abstract, or other Contracts extend it.\n- **Not used yet** — nothing references it. This is the clean-up list.\n\nThe **Used as** column spells it out, for example *Components 17 · Experiences 4*. Search matches a name or an\nid, and **Kind** and **Source** narrow further (a Contract can come from a provider, or be inherited from\nanother environment; both are read-only here and say so).\n\nEach row's **⋯** menu offers **Open** (or **View**, for one you can't edit), **Where used** and **Delete…**.\nDelete is switched off while anything uses the Contract, and says how many places do. Tick several rows to\ndelete them together; it tells you how many of the selection it can actually delete.\n\n## Creating a Contract\n\n1. From the Contracts list, select **New Contract**.\n2. Switch to the **General** tab. Enter a **Name** — everything else below\n   fills in from it, so filling it in first saves retyping. **Id** — a\n   short, URL-safe identifier made of lowercase letters, numbers, and\n   hyphens — fills in from Name automatically; you can still edit it by\n   hand before saving.\n3. Turn on **Abstract** if this Contract exists only to be extended by\n   other Contracts, or to constrain what a field is allowed to point at —\n   an abstract Contract can't be used to create content directly.\n4. Optionally choose a **Parent Contract**. Every field the parent\n   declares is inherited automatically and shown read-only under\n   \"Inherited fields\" on the **Fields** tab — you can't redefine or hide an\n   inherited field, only add new ones of your own.\n5. Switch to the **Fields** tab (the default tab). The fields are a list on the left and the\n   selected field's settings are on the right. Select **Add field** and choose a type from the\n   searchable list (each type says what it is for); the new field opens for you to name. Then fill in\n   its Name and Id, change its type with **Change…**, and turn its modifiers on or off (see below).\n   Repeat for every field the Contract needs; drag a row by its handle to reorder it (or, from the\n   keyboard, use the **Move up** and **Move down** buttons on the field, or focus the handle, press\n   Space to pick it up, use the arrow keys to move it, and Space again to drop it), or select\n   **Delete field** to remove one. Fields inherited from a parent are collected under their own\n   heading, collapsed; select one to see its settings, read-only. A row with an unresolved error shows\n   a warning mark, and a failed save selects the first field that needs attention — or, for an error on\n   the General tab (Name, Id, Parent Contract), switches you back to that tab.\n6. A bar at the bottom counts your **unsaved changes** (select it to see each one in words: \"Added the\n   field Heading\", \"Turned on Mandatory for Body\") and says how saving will land. A change that would\n   make existing Components fail validation shows **Breaking change** *before* you save; saving it\n   asks you to confirm and names each reason, because it creates a new *version* (see \"Versions\"\n   below). **Discard** puts every edit back. Select **Save changes** (or **Create Contract** for a new\n   one) — the bar is visible from every tab.\n\n### Asking the assistant to draft one\n\nIf your organization has the assistant turned on, you can describe a Contract instead of building it field\nby field. On the New Contract form, open the assistant (the magenta ebitex-mark icon in the header, beside\n**?**) and ask — for example, \"Create me a Contract for a CTA Banner\". It proposes a Contract as a\n**Suggested** card listing the name and each field with its type. Nothing is saved until you select\n**Accept**, which fills in the form and saves it the same way **Create Contract** does; **Dismiss** discards\nit. Either way you can keep editing afterwards. See [Getting help](../general/getting-help.md).\n\n## Field types and modifiers\n\nEvery field has a **Field type** (Text, Number, Boolean, Date, Link,\nComponent, Blob, Presentation, Rich Text, or Category — Short Text, Long Text,\nURL, Reference, Nested, and Experience Reference are deprecated and no longer\noffered for new fields, though any field already using one keeps working\nunchanged; see \"Text fields\" and \"Component fields\" below) plus up to five\nindependent modifiers, each shown as a toggle whose label changes with\nits state:\n\n- **Mandatory / Optional** — required, or not. For a Contextual field,\n  this only applies where the field is actually used, not on the\n  Component itself (see \"Contextual fields\" in\n  [Authoring Components](components.md)).\n- **Multiple / Single** — a list of values instead of one.\n- **Localized / Same in every locale** — a default value plus per-locale\n  overrides.\n- **Contextual / On the Component** — the value lives where the field is\n  *used*, not on the Component that declares it — useful for something\n  like a \"theme\" that should vary by where content is placed, not by the\n  content itself.\n- **Personalized / Same for every audience** — audience-conditioned\n  variant alternatives — see\n  [Personalizing content by audience](content-personalization.md).\n\nSome field types add an extra toggle of their own alongside these five —\nfor example, Text and Rich Text both show an **Allow\ntoken injection** toggle, since it's specific to text-bearing fields\nrather than something every field type needs.\n\nEach field type has its own extra settings, shown once you pick a type —\nfor example, Text has an optional pattern plus\nlength limits, all grouped together under **Validation** (a label you\nselect to expand, staying expanded automatically whenever something\ninside still needs your attention), Component lets you restrict which\nContracts are allowed (and, optionally, which of the two modes below), and\nBlob lets you restrict file types and maximum size.\n\n### Date fields\n\nA **Date** field has one extra setting, **Include time** — off shows and\nedits just a calendar date; on adds a time of day too. Either way, the\ndate/time you enter is shown in your own local time zone, and switching\nthis setting on or off later is a normal (additive) change, not something\nthat requires a new version.\n\n### Text fields\n\n**Text** is the one plain-text type. Turn on **Multiple lines** in its\nsettings and the editor becomes a larger box that keeps line breaks;\nleave it off for a single line such as a title. Either way the stored\nvalue is the same plain string, so switching the setting later never\nchanges or loses anything already written.\n\n**Short Text** and **Long Text** are the two types Text replaces. A field\nthat already uses one keeps working, but a new field cannot take it. To\nmove an existing field over, open it and choose **Convert to Text**: its\nsettings carry over unchanged (a Long Text field also becomes **Multiple\nlines**), every value already written is kept as it is, and the change\ndoes not by itself create a new Contract version.\n\n### Restricting a field to a fixed list of values\n\nText, Number, and Date fields can be restricted to a\nfixed set of **Allowed values** in their settings — useful for something\nlike a status field that should only ever be \"Draft,\" \"In review,\" or\n\"Published,\" rather than any free-text string. Leave it empty to allow\nany value.\n\nHow the field is edited then depends on whether it also allows multiple\nvalues and how many options you listed: a small list of single-value\noptions shows as buttons to pick one of; a longer list shows as a\ndropdown; combined with **Multiple**, a small list shows as checkboxes and\na longer one as a searchable picker. Narrowing this list later (removing a\nvalue that was previously allowed) is a breaking change, since an\nexisting Component might already hold it; adding a new value is additive.\n\n### Picking options from another system\n\nInstead of typing a fixed list of Allowed values, a Text field can\nname a **Choice source** — an activated plugin that supplies the option\nlist live, kept automatically in sync with whatever it's connected to.\nThe first one, **ebitex Forms**, lists your organization's own published\nForms, so you can pick a form by name rather than typing its id — useful\nfor a field like \"which form should appear on this page.\" A field can use\neither Allowed values or a Choice source, never both.\n\nOnce a Choice source plugin is activated (in your organization's Settings)\nand picked in a field's settings, editing a Component with that field\nlooks exactly like a normal fixed-list field: buttons, a dropdown,\ncheckboxes, or a searchable picker, depending on how many options there\nare. If the source is temporarily unavailable — a misconfigured\nconnection, for example — you'll see a short message explaining that, and\nthe field falls back to a plain text box so you can still see and edit\nwhatever value is already saved; nothing else on the page is blocked from\nsaving while that happens.\n\n### Giving a field a default value\n\nMost field types — anything other than Component, Presentation, Rich\nText, and Category, which all point at other content rather than holding\na plain value — can be given a **Default value** in their expanded row.\nOnce set, every brand-new Component created from this Contract starts\nwith that value already filled in, instead of empty; editing or clearing\nthe default afterward never changes a Component that already exists. For a\nContextual field, its default becomes the Component's own fallback value —\nused whenever a specific placement doesn't override it.\n\n## Component fields\n\nA **Component** field holds a reference to another Component, an inline\n(embedded) value, or either — decided by whoever is *filling in* the field,\nnot fixed when you design the Contract:\n\n- **Linked** — points at another Component elsewhere in your organization;\n  the two stay separate, and deleting a Component that's linked elsewhere\n  is blocked until the link is removed first. Covers both picking an\n  existing Component and creating a brand-new one to link to.\n- **Inline** — embeds another Component's content directly inside; there's\n  no separate entity to manage, it's just part of the same document. Best\n  for content that only ever makes sense as part of its parent (for\n  example, an article's author details).\n\nIf you want to guarantee only one of these for a given field — say, a\n\"related articles\" field that should always link to a reusable Component,\nnever an inline one-off — the field's settings offer **Allowed value\nmodes**, a checklist of the two options above (at least one must stay\nchecked). Leaving both checked (the default) lets whoever fills in the\nfield choose either way each time. Either way, **allowedContractIds** lets\nyou restrict which Contracts are allowed — leave it empty to allow any\nContract (including descendants of one you do list). The list reads **Any Contract**\nwhen it is empty, and **Allow any** clears it back to that in one step. A field\nwhose Contract comes from an integration can instead be limited to *no* Contract\nat all, shown as **No Contract (nothing allowed)**: nothing can be chosen for it\nuntil the integration allows something.\n\nExisting Contracts may still have the older, separate **Reference** and\n**Nested** field types — a Reference field is equivalent to a Component\nfield restricted to Linked only, and a Nested field to one restricted to\nInline only. They keep working exactly as before; a new field just uses\nComponent instead.\n\n## Giving a Contract a title field\n\nContent built from a Contract needs a human label — the name shown in a site's\nnavigation menu, in a breadcrumb trail, and beside each item in a listing.\n**Title field** on the **General** tab is where you choose which field that\nlabel comes from.\n\nIt is a picker, not something you type. Choose a field; if the field you chose\nholds a nested block, a second dropdown appears so you can choose the field\ninside it — up to four levels deep. Only fields a title can actually come from\nare offered: text fields as the final choice, and nested blocks as the steps in\nbetween.\n\n**Set it once, on the most general Contract that has the field.** The choice is\ninherited, so if your \"Web page\" Contract declares its `title` field, every\nContract that extends it — Article, Landing page, and so on — uses the same one\nwith nothing more to set up. A Contract that needs a different field can choose\nits own, which takes over. When a Contract inherits its title field, the picker\nshows it read-only and names the Contract it came from, with **Override** to\nchoose a different one and **Clear** to remove it.\n\nA few notes on what to expect:\n\n- **It applies from the next publish.** Choosing a title field doesn't change\n  anything already published — each Component picks it up when it is next\n  published.\n- **Editing the title text is a Component publish.** Change the wording and\n  republish that Component, and its label updates everywhere it appears. You do\n  not need to republish the pages that use it.\n- **If it can't be resolved, the page's own name is used instead** — its\n  internal name from Composer. That happens when no Contract in the chain\n  declares a title field, when the field named no longer exists, or when the\n  content isn't published. Nothing breaks; you just see the internal name, which\n  is a good hint that the title field needs attention.\n- **A localizable title field is worth choosing.** One value covers every\n  locale, and each visitor sees theirs.\n\nIf the same piece of content appears in more than one place and should be named\ndifferently at each, make the title field **contextual** — then each page that\nuses it supplies its own wording. Bear in mind that a contextual title belongs to\nthe page, so changing it means republishing that page rather than the content.\n\n## Editing fields as a tree\n\nSome content refers to more of the same kind of content: a dog has a sire and a\ndam who are dogs too, a product is built from parts that are products, a person\nreports to a person. Building that with one picker per field means creating the\nfurthest ancestor first and working back towards the one you actually wanted.\n\n**Editing layout**, pinned under the fields on the **Fields** tab, changes that. Choose\n**Edit as a tree** and the Component editor draws those fields as one tree, where you fill in any\nslot directly. It only changes how the fields are edited. The fields, their validation and what is\npublished are exactly as before, and it creates no new Contract version, so a change to just the\nlayout is saved without a version bump. A preview beside the settings draws the chart or outline you\nhave chosen, using your own field names, and the fields in the tree carry an **In tree** chip.\nRenaming a field in the tree updates the layout, and removing it, or changing it to a type a tree\ncan't use, takes it out of the layout.\n\nTo set it up:\n\n1. Give the Contract the fields that point at itself: two or more single-value\n   Component fields (a sire and a dam), or one list field (parts). Each should\n   allow the Contract, or a Contract that extends it.\n2. On **Fields**, select **Editing layout**, then choose **Edit as a tree**.\n3. Tick the fields that make up the tree and choose how many generations (or\n   levels) to show.\n4. Choose whether the same Component may appear more than once.\n\n**Repeats.** *Allow across branches* lets one Component sit in several places, as\nin line-breeding or a part used in two assemblies. *Never* means each Component\nmay appear once in the whole tree, which suits an org chart or a taxonomy. If\nyou switch to *Never* on content that already repeats, the repeats are kept and\nnothing is rewritten; only a new repeat is refused. Either way, something can\nnever contain itself.\n\n**Inheritance.** Like the title field, the choice is inherited. Set it once on the\ngeneral Contract (a \"Pedigree dog\") and every Contract that extends it, such as\n\"Dog\" and \"Bitch\", edits as a tree. A Contract can choose its own, or choose\n*Ordinary fields (do not inherit the tree)* to opt out.\n\nIf the fields you tick no longer exist or no longer fit, the editor simply shows\nthe ordinary fields, so a Contract is never left uneditable.\n\n## Links to your site\n\nA Component has no page of its own, so nothing in Content takes you from a\nComponent to the page on your site that shows it. **External links** on the\n**General** tab adds that. Each link is a button in the Component editor that\nopens the page for the Component you are looking at, for example a dog's\nprintable pedigree or a blog post on the live site.\n\nTo add one:\n\n1. On **General**, under **External links**, choose **Declare links**.\n2. Give the link a **Label**, the words on the button.\n3. Write the **URL template**. It starts with `{origin}`, `https://` or\n   `http://`, and can use the Component's own details:\n   - `{id}` and `{externalId}`: the Component's id and external id.\n   - `{field:name}`: the value of one of its fields. A field inside an inline\n     value is written with dots, such as `{field:owner.name}`.\n   - `{key:sire}`: the **key** of the record a reference field points at, for\n     a page that is addressed by that key. A litter can link to a pedigree\n     page with `{origin}/pedigree?sire={key:sire}&dam={key:dam}`. A reference\n     with nothing chosen, or a value written in by hand rather than chosen\n     from the records, leaves its place empty, so a litter with an outside dam\n     still links; the link is switched off only when none of the `{key:}`\n     fields has a value.\n   - `{origin}`: the address of the **Site** you choose, always followed by a\n     `/`. It is how one Contract can point at the right host in every\n     environment.\n4. Choose the **Site** (when you used `{origin}`) and whether the link is\n   **Enabled** always or **Once published**.\n\nA live example under the form shows the link built from one of this Contract's\nown Components, so you can see it before you save. You can add up to five links.\n\n**What authors see.** A link that works opens in a new tab. A link that cannot\nwork is greyed and says why beside it: *Publish this Component first* for a\ndraft, *Needs a value for \"name\"* when a field it uses is empty, or that the Site\nhas no host yet. A Component with unpublished changes still has a live page, so\nits link works and says it shows the published version.\n\n**Safe by design.** A value from a field can never change where a link points:\nvalues are encoded into one part of the address, and the template's scheme and\nhost cannot use fields at all.\n\n**Nothing else changes.** Links are only shown in the editor. They create no new\nContract version, change no Component and appear in nothing your site receives.\nLike the tree, they are inherited: a Contract can declare its own, or choose\n*No links (do not inherit)*.\n\n## Versions\n\nEvery save is classified automatically:\n\n- **Additive** changes (adding an optional field, loosening a limit, …)\n  update the Contract's current version in place.\n- **Breaking** changes (removing a field, adding a *mandatory* field,\n  tightening a limit, …) create a new version, leaving the old one intact\n  so Components already pinned to it keep working.\n\nThe **History** tab on a Contract's page lists every version and\nwhat fields it resolved to. Existing Components aren't forced to update\nwhen a Contract changes — see \"The upgrade badge\" in\n[Authoring Components](components.md) for how that friction is surfaced\nand resolved.\n"
+        "body": "# Modeling content with Contracts\n\nContracts define the field structure your content adheres to — think of a\nContract as a blueprint (for example \"Article\" or \"Author\") that every\nComponent built from it must follow. You need to belong to an organization to\nuse it — see [Creating an organization and inviting\nteammates](../hub/organizations.md) if you haven't set one up yet.\n\n## The Contracts list\n\n**Modeling > Contracts** lists every Contract with its name, its id (smaller, underneath), whether it is\nconcrete or abstract, which Contract it extends, how many fields it has, what it is used as, and when it\nlast changed.\n\n**What a Contract is used for is worked out from how it is used, never set by hand.** The row of buttons above\nthe list filters by it, with a count on each, and a Contract can sit in several at once:\n\n- **Components** — Components have been created from it.\n- **Experiences** — a Component of this Contract is the content of a page in your Experience tree.\n- **Templates** — it is a Template's own settings Contract. (A Contract a Template merely *supports* is an\n  ordinary content Contract, so it shows under Components, not here.)\n- **Base** — it is abstract, or other Contracts extend it.\n- **Not used yet** — nothing references it. This is the clean-up list.\n\nThe **Used as** column spells it out, for example *Components 17 · Experiences 4*. Search matches a name or an\nid, and **Kind** and **Source** narrow further (a Contract can come from a provider, or be inherited from\nanother environment; both are read-only here and say so).\n\nEach row's **⋯** menu offers **Open** (or **View**, for one you can't edit), **Where used** and **Delete…**.\nDelete is switched off while anything uses the Contract, and says how many places do. Tick several rows to\ndelete them together; it tells you how many of the selection it can actually delete.\n\n## Creating a Contract\n\n1. From the Contracts list, select **New Contract**.\n2. Switch to the **General** tab. Enter a **Name** — everything else below\n   fills in from it, so filling it in first saves retyping. **Id** — a\n   short, URL-safe identifier made of lowercase letters, numbers, and\n   hyphens — fills in from Name automatically; you can still edit it by\n   hand before saving.\n3. Turn on **Abstract** if this Contract exists only to be extended by\n   other Contracts, or to constrain what a field is allowed to point at —\n   an abstract Contract can't be used to create content directly.\n4. Optionally choose a **Parent Contract**. Every field the parent\n   declares is inherited automatically and shown read-only under\n   \"Inherited fields\" on the **Fields** tab — you can't redefine or hide an\n   inherited field, only add new ones of your own.\n   You can also choose **Based on a platform Contract**. A platform Contract is one the product\n   provides (today, **Unlock page**) and always brings its own fields, read-only and first in the list.\n   Base a Contract on **Unlock page** to make its Experiences usable as the page visitors see when they may\n   not read a members-only page (see [Members-only pages](visitor-access.md)). Setting or changing it adds or removes fields,\n   so it can be a breaking change, and you are asked to confirm when it is.\n5. Switch to the **Fields** tab (the default tab). The fields are a list on the left and the\n   selected field's settings are on the right. Select **Add field** and choose a type from the\n   searchable list (each type says what it is for); the new field opens for you to name. Then fill in\n   its Name and Id, change its type with **Change…**, and turn its modifiers on or off (see below).\n   Repeat for every field the Contract needs; drag a row by its handle to reorder it (or, from the\n   keyboard, use the **Move up** and **Move down** buttons on the field, or focus the handle, press\n   Space to pick it up, use the arrow keys to move it, and Space again to drop it), or select\n   **Delete field** to remove one. Fields inherited from a parent are collected under their own\n   heading, collapsed; select one to see its settings, read-only. A row with an unresolved error shows\n   a warning mark, and a failed save selects the first field that needs attention — or, for an error on\n   the General tab (Name, Id, Parent Contract), switches you back to that tab.\n6. A bar at the bottom counts your **unsaved changes** (select it to see each one in words: \"Added the\n   field Heading\", \"Turned on Mandatory for Body\") and says how saving will land. A change that would\n   make existing Components fail validation shows **Breaking change** *before* you save; saving it\n   asks you to confirm and names each reason, because it creates a new *version* (see \"Versions\"\n   below). **Discard** puts every edit back. Select **Save changes** (or **Create Contract** for a new\n   one) — the bar is visible from every tab.\n\n### Asking the assistant to draft one\n\nIf your organization has the assistant turned on, you can describe a Contract instead of building it field\nby field. On the New Contract form, open the assistant (the magenta ebitex-mark icon in the header, beside\n**?**) and ask — for example, \"Create me a Contract for a CTA Banner\". It proposes a Contract as a\n**Suggested** card listing the name and each field with its type. Nothing is saved until you select\n**Accept**, which fills in the form and saves it the same way **Create Contract** does; **Dismiss** discards\nit. Either way you can keep editing afterwards. See [Getting help](../general/getting-help.md).\n\n## Field types and modifiers\n\nEvery field has a **Field type** (Text, Number, Boolean, Date, Link,\nComponent, Blob, Presentation, Rich Text, or Category — Short Text, Long Text,\nURL, Reference, Nested, and Experience Reference are deprecated and no longer\noffered for new fields, though any field already using one keeps working\nunchanged; see \"Text fields\" and \"Component fields\" below) plus up to five\nindependent modifiers, each shown as a toggle whose label changes with\nits state:\n\n- **Mandatory / Optional** — required, or not. For a Contextual field,\n  this only applies where the field is actually used, not on the\n  Component itself (see \"Contextual fields\" in\n  [Authoring Components](components.md)).\n- **Multiple / Single** — a list of values instead of one.\n- **Localized / Same in every locale** — a default value plus per-locale\n  overrides.\n- **Contextual / On the Component** — the value lives where the field is\n  *used*, not on the Component that declares it — useful for something\n  like a \"theme\" that should vary by where content is placed, not by the\n  content itself.\n- **Personalized / Same for every audience** — audience-conditioned\n  variant alternatives — see\n  [Personalizing content by audience](content-personalization.md).\n\nSome field types add an extra toggle of their own alongside these five —\nfor example, Text and Rich Text both show an **Allow\ntoken injection** toggle, since it's specific to text-bearing fields\nrather than something every field type needs.\n\nEach field type has its own extra settings, shown once you pick a type —\nfor example, Text has an optional pattern plus\nlength limits, all grouped together under **Validation** (a label you\nselect to expand, staying expanded automatically whenever something\ninside still needs your attention), Component lets you restrict which\nContracts are allowed (and, optionally, which of the two modes below), and\nBlob lets you restrict file types and maximum size.\n\n### Date fields\n\nA **Date** field has one extra setting, **Include time** — off shows and\nedits just a calendar date; on adds a time of day too. Either way, the\ndate/time you enter is shown in your own local time zone, and switching\nthis setting on or off later is a normal (additive) change, not something\nthat requires a new version.\n\n### Text fields\n\n**Text** is the one plain-text type. Turn on **Multiple lines** in its\nsettings and the editor becomes a larger box that keeps line breaks;\nleave it off for a single line such as a title. Either way the stored\nvalue is the same plain string, so switching the setting later never\nchanges or loses anything already written.\n\n**Short Text** and **Long Text** are the two types Text replaces. A field\nthat already uses one keeps working, but a new field cannot take it. To\nmove an existing field over, open it and choose **Convert to Text**: its\nsettings carry over unchanged (a Long Text field also becomes **Multiple\nlines**), every value already written is kept as it is, and the change\ndoes not by itself create a new Contract version.\n\n### Restricting a field to a fixed list of values\n\nText, Number, and Date fields can be restricted to a\nfixed set of **Allowed values** in their settings — useful for something\nlike a status field that should only ever be \"Draft,\" \"In review,\" or\n\"Published,\" rather than any free-text string. Leave it empty to allow\nany value.\n\nHow the field is edited then depends on whether it also allows multiple\nvalues and how many options you listed: a small list of single-value\noptions shows as buttons to pick one of; a longer list shows as a\ndropdown; combined with **Multiple**, a small list shows as checkboxes and\na longer one as a searchable picker. Narrowing this list later (removing a\nvalue that was previously allowed) is a breaking change, since an\nexisting Component might already hold it; adding a new value is additive.\n\n### Picking options from another system\n\nInstead of typing a fixed list of Allowed values, a Text field can\nname a **Choice source** — an activated plugin that supplies the option\nlist live, kept automatically in sync with whatever it's connected to.\nThe first one, **ebitex Forms**, lists your organization's own published\nForms, so you can pick a form by name rather than typing its id — useful\nfor a field like \"which form should appear on this page.\" A field can use\neither Allowed values or a Choice source, never both.\n\nOnce a Choice source plugin is activated (in your organization's Settings)\nand picked in a field's settings, editing a Component with that field\nlooks exactly like a normal fixed-list field: buttons, a dropdown,\ncheckboxes, or a searchable picker, depending on how many options there\nare. If the source is temporarily unavailable — a misconfigured\nconnection, for example — you'll see a short message explaining that, and\nthe field falls back to a plain text box so you can still see and edit\nwhatever value is already saved; nothing else on the page is blocked from\nsaving while that happens.\n\n### Giving a field a default value\n\nMost field types — anything other than Component, Presentation, Rich\nText, and Category, which all point at other content rather than holding\na plain value — can be given a **Default value** in their expanded row.\nOnce set, every brand-new Component created from this Contract starts\nwith that value already filled in, instead of empty; editing or clearing\nthe default afterward never changes a Component that already exists. For a\nContextual field, its default becomes the Component's own fallback value —\nused whenever a specific placement doesn't override it.\n\n## Component fields\n\nA **Component** field holds a reference to another Component, an inline\n(embedded) value, or either — decided by whoever is *filling in* the field,\nnot fixed when you design the Contract:\n\n- **Linked** — points at another Component elsewhere in your organization;\n  the two stay separate, and deleting a Component that's linked elsewhere\n  is blocked until the link is removed first. Covers both picking an\n  existing Component and creating a brand-new one to link to.\n- **Inline** — embeds another Component's content directly inside; there's\n  no separate entity to manage, it's just part of the same document. Best\n  for content that only ever makes sense as part of its parent (for\n  example, an article's author details).\n\nIf you want to guarantee only one of these for a given field — say, a\n\"related articles\" field that should always link to a reusable Component,\nnever an inline one-off — the field's settings offer **Allowed value\nmodes**, a checklist of the two options above (at least one must stay\nchecked). Leaving both checked (the default) lets whoever fills in the\nfield choose either way each time. Either way, **allowedContractIds** lets\nyou restrict which Contracts are allowed. The list has three states, and the\nbuilder says which one it is in: **Any Contract** (nothing set, so any Contract,\nincluding descendants of one you do list), a list of Contracts (exactly those),\nand **Nothing allowed** (an empty list: no Contract can be chosen). **Allow any**\nclears the list back to the first state, **Allow none** empties it, and removing\nthe last Contract from a list leaves **Nothing allowed** rather than silently\nallowing everything. The same three states apply to every allow-list in a\nfield's settings (Templates, category groups, link kinds and protocols, inline\nembed kinds, markdown features and content types). Value modes are the exception:\na field must allow at least one, so that list can be left out but never emptied.\n\nExisting Contracts may still have the older, separate **Reference** and\n**Nested** field types — a Reference field is equivalent to a Component\nfield restricted to Linked only, and a Nested field to one restricted to\nInline only. They keep working exactly as before; a new field just uses\nComponent instead.\n\n## Giving a Contract a title field\n\nContent built from a Contract needs a human label — the name shown in a site's\nnavigation menu, in a breadcrumb trail, and beside each item in a listing.\n**Title field** on the **General** tab is where you choose which field that\nlabel comes from.\n\nIt is a picker, not something you type. Choose a field; if the field you chose\nholds a nested block, a second dropdown appears so you can choose the field\ninside it — up to four levels deep. Only fields a title can actually come from\nare offered: text fields as the final choice, and nested blocks as the steps in\nbetween.\n\n**Set it once, on the most general Contract that has the field.** The choice is\ninherited, so if your \"Web page\" Contract declares its `title` field, every\nContract that extends it — Article, Landing page, and so on — uses the same one\nwith nothing more to set up. A Contract that needs a different field can choose\nits own, which takes over. When a Contract inherits its title field, the picker\nshows it read-only and names the Contract it came from, with **Override** to\nchoose a different one and **Clear** to remove it.\n\nA few notes on what to expect:\n\n- **It applies from the next publish.** Choosing a title field doesn't change\n  anything already published — each Component picks it up when it is next\n  published.\n- **Editing the title text is a Component publish.** Change the wording and\n  republish that Component, and its label updates everywhere it appears. You do\n  not need to republish the pages that use it.\n- **If it can't be resolved, the page's own name is used instead** — its\n  internal name from Composer. That happens when no Contract in the chain\n  declares a title field, when the field named no longer exists, or when the\n  content isn't published. Nothing breaks; you just see the internal name, which\n  is a good hint that the title field needs attention.\n- **A localizable title field is worth choosing.** One value covers every\n  locale, and each visitor sees theirs.\n\nIf the same piece of content appears in more than one place and should be named\ndifferently at each, make the title field **contextual** — then each page that\nuses it supplies its own wording. Bear in mind that a contextual title belongs to\nthe page, so changing it means republishing that page rather than the content.\n\n## Editing fields as a tree\n\nSome content refers to more of the same kind of content: a dog has a sire and a\ndam who are dogs too, a product is built from parts that are products, a person\nreports to a person. Building that with one picker per field means creating the\nfurthest ancestor first and working back towards the one you actually wanted.\n\n**Editing layout**, pinned under the fields on the **Fields** tab, changes that. Choose\n**Edit as a tree** and the Component editor draws those fields as one tree, where you fill in any\nslot directly. It only changes how the fields are edited. The fields, their validation and what is\npublished are exactly as before, and it creates no new Contract version, so a change to just the\nlayout is saved without a version bump. A preview beside the settings draws the chart or outline you\nhave chosen, using your own field names, and the fields in the tree carry an **In tree** chip.\nRenaming a field in the tree updates the layout, and removing it, or changing it to a type a tree\ncan't use, takes it out of the layout.\n\nTo set it up:\n\n1. Give the Contract the fields that point at itself: two or more single-value\n   Component fields (a sire and a dam), or one list field (parts). Each should\n   allow the Contract, or a Contract that extends it.\n2. On **Fields**, select **Editing layout**, then choose **Edit as a tree**.\n3. Tick the fields that make up the tree and choose how many generations (or\n   levels) to show.\n4. Choose whether the same Component may appear more than once.\n\n**Repeats.** *Allow across branches* lets one Component sit in several places, as\nin line-breeding or a part used in two assemblies. *Never* means each Component\nmay appear once in the whole tree, which suits an org chart or a taxonomy. If\nyou switch to *Never* on content that already repeats, the repeats are kept and\nnothing is rewritten; only a new repeat is refused. Either way, something can\nnever contain itself.\n\n**Inheritance.** Like the title field, the choice is inherited. Set it once on the\ngeneral Contract (a \"Pedigree dog\") and every Contract that extends it, such as\n\"Dog\" and \"Bitch\", edits as a tree. A Contract can choose its own, or choose\n*Ordinary fields (do not inherit the tree)* to opt out.\n\nIf the fields you tick no longer exist or no longer fit, the editor simply shows\nthe ordinary fields, so a Contract is never left uneditable.\n\n## Links to your site\n\nA Component has no page of its own, so nothing in Content takes you from a\nComponent to the page on your site that shows it. **External links** on the\n**General** tab adds that. Each link is a button in the Component editor that\nopens the page for the Component you are looking at, for example a dog's\nprintable pedigree or a blog post on the live site.\n\nTo add one:\n\n1. On **General**, under **External links**, choose **Declare links**.\n2. Give the link a **Label**, the words on the button.\n3. Write the **URL template**. It starts with `{origin}`, `https://` or\n   `http://`, and can use the Component's own details:\n   - `{id}` and `{externalId}`: the Component's id and external id.\n   - `{field:name}`: the value of one of its fields. A field inside an inline\n     value is written with dots, such as `{field:owner.name}`.\n   - `{key:sire}`: the **key** of the record a reference field points at, for\n     a page that is addressed by that key. A litter can link to a pedigree\n     page with `{origin}/pedigree?sire={key:sire}&dam={key:dam}`. A reference\n     with nothing chosen, or a value written in by hand rather than chosen\n     from the records, leaves its place empty, so a litter with an outside dam\n     still links; the link is switched off only when none of the `{key:}`\n     fields has a value.\n   - `{origin}`: the address of the **Site** you choose, always followed by a\n     `/`. It is how one Contract can point at the right host in every\n     environment.\n4. Choose the **Site** (when you used `{origin}`) and whether the link is\n   **Enabled** always or **Once published**.\n\nA live example under the form shows the link built from one of this Contract's\nown Components, so you can see it before you save. You can add up to five links.\n\n**What authors see.** A link that works opens in a new tab. A link that cannot\nwork is greyed and says why beside it: *Publish this Component first* for a\ndraft, *Needs a value for \"name\"* when a field it uses is empty, or that the Site\nhas no host yet. A Component with unpublished changes still has a live page, so\nits link works and says it shows the published version.\n\n**Safe by design.** A value from a field can never change where a link points:\nvalues are encoded into one part of the address, and the template's scheme and\nhost cannot use fields at all.\n\n**Nothing else changes.** Links are only shown in the editor. They create no new\nContract version, change no Component and appear in nothing your site receives.\nLike the tree, they are inherited: a Contract can declare its own, or choose\n*No links (do not inherit)*.\n\n## Versions\n\nEvery save is classified automatically:\n\n- **Additive** changes (adding an optional field, loosening a limit, …)\n  update the Contract's current version in place.\n- **Breaking** changes (removing a field, adding a *mandatory* field,\n  tightening a limit, …) create a new version, leaving the old one intact\n  so Components already pinned to it keep working.\n\nThe **History** tab on a Contract's page lists every version and\nwhat fields it resolved to. Existing Components aren't forced to update\nwhen a Contract changes — see \"The upgrade badge\" in\n[Authoring Components](components.md) for how that friction is surfaced\nand resolved.\n"
     },
     {
         "slug": "deployment-keys",
@@ -137,6 +137,11 @@ export const HELP_TOPICS = [
         "slug": "translation-jobs",
         "title": "Translation jobs",
         "body": "# Translation jobs\n\nTranslate a Component's text into another locale automatically, then review the result before it\nlands in your content — or skip the review entirely if you'd rather it apply right away.\n\n## Kicking off a translation\n\nOpen a Component and choose **Translate…** in its header. Pick one or more target locales (only\nlocales your organization has configured beyond the default show up here — add one in Settings\nfirst if you don't see the one you need), pick a translator if your organization has more than one\nactivated, and confirm. One job starts per locale you selected.\n\nOnly certain fields are ever translated: plain text and rich text fields marked as localizable,\nand only their default (root-locale) value — fields that hold a list of values, or that vary by\naudience, aren't picked up by this pass. A field whose target locale already has a value is left\nalone unless you check **Retranslate fields that already have a value in the target locale**.\n\nJobs still in progress are listed in the Component's status strip, under its name, with **Review…** for one that is\nwaiting for you. The complete list, including finished and failed jobs, is on the **Settings** tab.\n\n## What \"review\" means\n\nWhether a job needs your approval before it takes effect depends on whether the folder the\nComponent lives in has a **translation workflow** assigned (see\n[Editorial workflow](content-workflow.md)) — the same governance mechanism that gates publishing,\napplied here to translated text instead:\n\n- **No translation workflow assigned**: the job applies immediately — the proposed translations are\n  written straight into the Component, no review step in between.\n- **A translation workflow is assigned**: the job's proposed values sit in **awaiting review** until\n  someone acts on them. Depending on how the workflow was built, that might mean an automatic\n  decision (for example, routing certain locales straight through with no human step at all) or a\n  real review step where a person has to look at it.\n\nTo assign one, create a **Translation workflow** under **Workflow**, then open the folder's\ngovernance panel and pick it under **Translation review**. That picker appears once at least one\ntranslation workflow exists; before then, the folder simply has no translation section, which is\nthe \"applies immediately\" case above.\n\nEither way, once a job applies, the translated text is simply part of the Component from then on —\nthere's nothing left to indicate it arrived via a translation job.\n\n## Reviewing proposed translations\n\nOpen the **Translations** panel on a Component (or click through from wherever the job is listed)\nto see each job's status and, for a job awaiting review, every proposed value side by side with the\noriginal: the source text above, an editable text box below holding the machine translation. Edit\nthe proposed text directly if it needs a tweak, then mark each item **Accept** or **Reject** —\naccepting is also the default if you don't touch an item at all, since a translated value with no\nobjection raised is assumed good.\n\nOnce every item you care about has been handled, use the workflow's own transition buttons (for\nexample **Approve**) to move the job forward. Depending on how many review steps the workflow\ndefines, approving might finish the job right away or hand it to a second reviewer — the panel\nalways shows what happens next.\n\nRejecting sends the job to its own end state without writing anything into the Component — nothing\nis applied, and the proposed translations are discarded.\n\n## What \"stale\" means\n\nIf someone edits the Component's own text while a translation job is sitting in review, the job\nnotices at the moment it's finally approved: any item whose original source text has since changed\nis marked **stale** rather than applied, since the translation was proposed against text that no\nlonger exists. A stale item doesn't block the rest of the job — every other item still applies\nnormally — but the stale field itself is left untouched, and translating it again (a fresh job) is\nthe way to pick up the new wording.\n\n## Deleting a Component with translation history\n\nA Component that still has a translation job **in progress** (queued, translating, or awaiting\nreview) can't be deleted until that job finishes one way or another — finish the review, or reject\nit, then delete. A Component whose translation jobs have all already finished (applied, discarded,\nor failed) has no such restriction — deleting the Component removes that history along with it.\n\n## Permissions\n\nKicking off a translation job requires edit access to the Component. Acting on a job under review\nfollows the same rules as any other workflow transition — see\n[Editorial workflow](content-workflow.md#permissions).\n"
+    },
+    {
+        "slug": "visitor-access",
+        "title": "Members-only pages (visitor access)",
+        "body": "# Members-only pages (visitor access)\n\nYou can keep a whole site, a section or a single page for the members of an **audience**. Everyone else is served an **unlock page** instead, and the restricted page's content, title and address are not sent to them at all. The restriction is enforced by the server, not by the page, so it holds whatever your website does.\n\nThis is different from [personalization](content-personalization.md), which changes what a page *says* for a visitor. A personalized page is still sent to everyone; a restricted page is not.\n\nThe **Visitor access** card appears only when your organization has visitor access turned on. If you do not see it, ask an organization Owner. Changing a rule needs the **Manage visitor access** permission; anyone who can see a page can read who may see it.\n\n## Setting a rule\n\nOpen a page, a section or the site's top page in **Composer** and find the **Visitor access** card. Choose one of three:\n\n- **Follow the parent.** The page is restricted if the closest page above it with a rule is. On the site's top page this reads **Follow the default** and means public.\n- **Open to everyone.** Overrides a restriction above, so one page in a members-only section can be public.\n- **Restrict to an audience.** Choose the audience. Only its members are served the page, and everything under it that follows it.\n\nThe card also says, in a sentence, who can see the page now, and where the rule comes from when it is inherited. Click the name to go there.\n\nA rule is saved at once, but, like any other change to a page, it reaches your website only when the page is **published**. Publishing a restricted page also publishes its unlock page and any restricted section above it that is not yet published, so a restriction is never missing from the live site.\n\n### Who can see this page\n\nThe table at the bottom of the card shows what happens to each kind of visitor, so you can check a rule without trying it:\n\n| Visitor | What happens |\n|---|---|\n| Not a member | Gets the unlock page |\n| Member, email not verified | Opens the page, or is asked to confirm their email, depending on the audience (below) |\n| Member, verified | Opens the page |\n\n### Which audiences you can choose\n\nOnly an audience with **stored members** can be chosen: one whose rule is about a person, such as \"has bought twice\". An audience that reads something about the visit, such as the language of the page, is worked out for each request, and a request can claim anything, so it cannot grant access.\n\nEach audience carries its own setting for how strict its access is (see [Audiences and lifecycle](../audience/lifecycle-and-audiences.md#visitor-access)):\n\n- **Open membership.** Being a member is enough. The audience can name a form that makes someone a member, and the unlock page offers it. Anyone can type anyone else's email into a form, so this suits pages where that does not matter, such as a whitepaper.\n- **Verified access.** A member must also prove they hold their email address, by following a link emailed to it. The unlock page offers a sign-in. Use this for anything that matters.\n\nThe card says which of the two the chosen audience uses, and that it is set in the Audience app, not on the page.\n\n## The unlock page\n\nThe unlock page is an **Experience** like any other, built on the **Unlock page** platform Contract. It has a heading, a message, an optional teaser, and the label of the button that opens the way in. It is always public, even when it sits inside a restricted section.\n\nChoose it in the **Unlock page** line of the card:\n\n- **A page of its own.** Pick any Experience that qualifies. For a restricted placement you can also override the heading, message, teaser and button label **per language**, so one unlock page serves many places with the right words for each.\n- **The site default.** If a placement chooses none, visitors see the site's default unlock page. Set it from **Edit site default** on the card, or from the **Default unlock page** card on the site's top page.\n- **The plain built-in message.** If nothing is chosen anywhere, or the chosen page is not published, visitors see \"Members only\" and a short message in English. They always get an answer.\n\nTo make an Experience that can be chosen, base its Contract on the **Unlock page** platform Contract: in the Contract builder, choose it under **Based on a platform Contract**. Its four fields then appear at the top of the Contract, read-only. A Template that supports that Contract can then render an Experience of it. The card warns you if a page you chose no longer qualifies.\n\nA restricted page depends on its unlock page: publishing, promoting and exporting the page carry the unlock page along, and an unlock page that a rule uses cannot be deleted while it is in use.\n\n## In the page tree\n\nRestricted pages carry a badge in the tree: the audience's name where the rule is set, and **inherited** below it. An unlock page is marked **Unlock page**.\n\n**Preview as** above the tree strikes through the pages a kind of visitor would not be served: **Not a member**, **Member, email not verified** or **Member, verified**. **Editor** clears it. It draws what the rules say; it does not sign you in as anyone.\n\n## Things worth knowing\n\n- A restricted page never appears in the sitemap or in navigation for a visitor who may not read it.\n- Removing someone from an audience takes effect within minutes: a visitor's access is re-checked every few minutes while they browse.\n- Switching visitor access off for your organization stops editing, but any rule already set keeps being enforced. To open a page, change its rule.\n- Deleting an audience that a rule uses is refused until the rule is changed; the refusal lists where it is used.\n- A restriction protects the **page**, not the things it points at. Content written directly in a restricted page is protected with it, but a shared Component that the page *references*, or a file in Assets, can still be reached by someone who already knows its address. Keep anything that must stay private written directly in the page.\n"
     }
 ];
 //# sourceMappingURL=helpCorpus.generated.js.map

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,yzZAAyzZ;KACl0Z;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,+vzBAA+vzB;KACxwzB;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,0iNAA0iN;KACnjN;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,gCAAgC;QACzC,MAAM,EAAE,8rsBAA8rsB;KACvssB;IACD;QACE,MAAM,EAAE,sBAAsB;QAC9B,OAAO,EAAE,sBAAsB;QAC/B,MAAM,EAAE,o1qBAAo1qB;KAC71qB;IACD;QACE,MAAM,EAAE,eAAe;QACvB,OAAO,EAAE,qCAAqC;QAC9C,MAAM,EAAE,q3FAAq3F;KAC93F;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,w8PAAw8P;KACj9P;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,moQAAmoQ;KAC5oQ;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,oBAAoB;QAC7B,MAAM,EAAE,ujYAAujY;KAChkY;IACD;QACE,MAAM,EAAE,WAAW;QACnB,OAAO,EAAE,iCAAiC;QAC1C,MAAM,EAAE,k7oBAAk7oB;KAC37oB;IACD;QACE,MAAM,EAAE,iBAAiB;QACzB,OAAO,EAAE,iBAAiB;QAC1B,MAAM,EAAE,0uHAA0uH;KACnvH;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,upIAAupI;KAChqI;IACD;QACE,MAAM,EAAE,iBAAiB;QACzB,OAAO,EAAE,iBAAiB;QAC1B,MAAM,EAAE,ugNAAugN;KAChhN;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,qBAAqB;QAC7B,OAAO,EAAE,qBAAqB;QAC9B,MAAM,EAAE,yrIAAyrI;KAClsI;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,+BAA+B;QACxC,MAAM,EAAE,g2EAAg2E;KACz2E;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,g8KAAg8K;KACz8K;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,kBAAkB;QAC3B,MAAM,EAAE,yvJAAyvJ;KAClwJ;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,yzZAAyzZ;KACl0Z;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,+vzBAA+vzB;KACxwzB;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,0iNAA0iN;KACnjN;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,gCAAgC;QACzC,MAAM,EAAE,8rsBAA8rsB;KACvssB;IACD;QACE,MAAM,EAAE,sBAAsB;QAC9B,OAAO,EAAE,sBAAsB;QAC/B,MAAM,EAAE,o1qBAAo1qB;KAC71qB;IACD;QACE,MAAM,EAAE,eAAe;QACvB,OAAO,EAAE,qCAAqC;QAC9C,MAAM,EAAE,q3FAAq3F;KAC93F;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,w8PAAw8P;KACj9P;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,izQAAizQ;KAC1zQ;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,oBAAoB;QAC7B,MAAM,EAAE,ujYAAujY;KAChkY;IACD;QACE,MAAM,EAAE,WAAW;QACnB,OAAO,EAAE,iCAAiC;QAC1C,MAAM,EAAE,8xqBAA8xqB;KACvyqB;IACD;QACE,MAAM,EAAE,iBAAiB;QACzB,OAAO,EAAE,iBAAiB;QAC1B,MAAM,EAAE,0uHAA0uH;KACnvH;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,upIAAupI;KAChqI;IACD;QACE,MAAM,EAAE,iBAAiB;QACzB,OAAO,EAAE,iBAAiB;QAC1B,MAAM,EAAE,ugNAAugN;KAChhN;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,qBAAqB;QAC7B,OAAO,EAAE,qBAAqB;QAC9B,MAAM,EAAE,yrIAAyrI;KAClsI;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,+BAA+B;QACxC,MAAM,EAAE,g2EAAg2E;KACz2E;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,g8KAAg8K;KACz8K;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,0hMAA0hM;KACniM;CACF,CAAA"}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ebitex/content-mcp",
-  "version": "1.0.217",
+  "version": "1.0.219",
   "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/",