@ebitex/content-mcp 0.5.146 → 0.5.149

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -16,7 +16,7 @@ export const HELP_TOPICS = [
16
16
  {
17
17
  "slug": "components",
18
18
  "title": "Authoring Components",
19
- "body": "# Authoring Components\n\nA Component is one piece of content built from a Contract — for example,\na specific article. This guide covers creating and editing Components,\norganizing them in folders, and the friction the app shows you when a\nContract changes underneath a Component you've already created. See\n[Modeling content with Contracts](contracts.md) first if you haven't\ncreated a Contract yet.\n\n## Creating a Component\n\n1. From the Content page, select **New Component** (optionally after\n opening the folder you want it created in).\n2. Enter a **Name** — the **Id** fills in from it automatically and can\n still be edited by hand.\n3. Choose a **Contract**. If you started from a specific folder that\n restricts which Contracts are allowed there, only those (and their\n descendants) are offered.\n4. Fill in the form that appears — every field from the Contract, laid\n out in order. Fields marked with a red **\\*** are required.\n5. Select **Create**. If a required field is missing or a value doesn't\n match the Contract's rules, the field is highlighted with an\n explanation — fix it and select **Create** again.\n\n## Filling in fields\n\nMost fields are a straightforward text box, number box, or checkbox.\nA few work differently:\n\n- **Reference** and **Nested** are older field types kept working for\n existing Contracts, but no longer offered when adding a new field — new\n Contracts should use **Component** instead (below), which offers the\n same two behaviors plus a third, chosen per value instead of committed\n to for the whole field.\n- **Component** fields ask you to choose, each time you fill one in:\n **Choose…** to link to an existing Component (same search box as\n Reference, with **Change**/**Remove** once chosen); **Create new…** to\n create a brand-new Component and link to it in one step (fill in its\n name, Contract, and any required fields right there); or **Create\n inline…** to embed a value that only ever exists inside this one — pick\n a Contract and an **Edit** panel slides in, exactly like Nested below.\n If the Contract only allows one of these choices, only that one is\n offered. If a linked Component can't be found — most often because it\n was skipped during a promotion into this environment (see\n [content-environments.md](content-environments.md)'s \"Unresolved\n references\" section) — you'll see a distinct **Unresolved** badge\n instead of the usual resolved name, with a link to Component Sync to\n see the full picture and fix it. **Change**/**Remove** still work\n normally on an unresolved value.\n- **Blob** fields (images and other files) show an **Upload** button.\n Once uploaded, you'll see a preview (for images) and a link to download\n the file, plus a **Replace** button.\n- **Nested** fields show a small **Edit** panel once a Contract is chosen\n for them (automatically, if only one is allowed for that field, or via a\n picker if more than one is allowed) — selecting **Edit** opens the\n nested content in its own panel, sliding in over the current one. Any\n unsaved changes you've made — at every level — are kept even if you\n drill several levels deep and back out again; nothing is lost until you\n actually leave the page without saving. A Component field's own **Create\n inline…** choice opens the identical panel.\n- Fields marked **Localizable** always show a small translations icon next\n to their label — select it to add per-locale overrides alongside the\n default value. It's disabled (with an explanation on hover) until your\n organization has a language configured under **Localization** settings\n with at least one language added under it to translate into; once one\n exists, the icon becomes selectable. This works the same way for every\n field type, including Blob, Reference, Nested, Component, and\n Presentation fields: each locale gets its own independent\n **Upload**/**Edit**/**Choose…** affordance, so a Nested value's translated\n content — or a different linked Component or uploaded file per locale —\n is fully separate from the default. The default-locale row in the\n translations panel is always read-only (a reflection of the default\n value, not a second copy of it); translate from the other locale rows.\n- **Presentation** fields let you instantiate a Template inline — pick a\n Template, bind it to a Component, and set contextual values and settings\n for this specific placement. See\n [Presenting content with Templates](templates.md) for the full flow.\n\n## Links to the live page\n\nIf the Contract has **External links**, they appear as buttons under the\nComponent's name, and at the top of the quick-edit panel. A button opens that\nComponent's page on your site in a new tab. If it is greyed out, the reason is\nwritten beside it, usually that the Component has not been published yet. The\nlink always shows what is *published*, not the changes you are typing. See\n[Links to your site](contracts.md) to set them up.\n\n## Editing a tree of Components\n\nWhen a Contract is set up to be edited as a tree (see\n[Editing fields as a tree](contracts.md)), its Component editor shows one\nsection, such as **Pedigree**, in place of the separate pickers. The Component\nyou are editing is the root, and each slot is a Component of its own.\n\n- **Chart or outline.** A slot-based tree such as a pedigree is drawn as a chart,\n one column per generation, or as an outline. Choose with the buttons above it;\n the outline is used on narrow screens. **Generations** shows fewer levels\n without changing anything. A list, such as the parts of a product, is always\n an outline you can collapse and expand.\n- **Fill a slot.** Select an empty slot to search for an existing Component, or\n **Create new** to make one on the spot. A slot only lists Components it can\n hold, such as dogs for a sire.\n- **Options you can't choose are greyed out, with the reason.** *Would become its\n own ancestor* or *Would contain itself* means choosing it would make something\n its own ancestor. *Already used elsewhere in this tree* appears when the\n Contract doesn't allow repeats. *Already in this list* means it is there\n already. If the server still refuses a change, the reason is shown above the\n tree.\n- **Edit without leaving.** **Edit** on a filled slot opens that Component in a\n panel over the page. Change it, save it and close the panel, and you are back\n in the tree.\n- **Change or remove.** Point at a filled slot for **Change** and the remove\n button. Removing only empties the slot; the Component itself is kept.\n- **A slot under an empty parent is greyed out**, because there is nothing to\n attach it to yet. Fill the parent first.\n- **A name with ×2 or \"in 2\"** is one Component that appears in more than one\n place. Editing it changes it everywhere.\n\n**A slot can be described inline.** Some fields accept a description written\nin place instead of an existing Component, for example a dam who is not in your\narchive and never will be. Where a field allows it, the picker has an\n**Enter … inline instead** button. An inline slot is drawn with a dashed\noutline and an **Inline** chip, and its own slots (her sire and dam, say) are\ndrawn under it and filled in the same way as any other.\n\n- **Edit** on an inline slot opens its own fields in a panel at the side. The\n slots the tree draws are not repeated there. Choose **Done** to keep your\n changes.\n- **Change** or the remove button on an inline slot replaces or removes it\n *together with everything under it*. The picker says how many entries that\n is before you choose, and a notice with **Undo** appears for a few seconds\n afterwards. Undo puts the whole description back.\n- A field that only accepts an existing Component has no inline button.\n- Nothing else can point at an inline description, so it shows no ×2 count.\n\n**What saves when.** The first level, the slots of the Component you have open,\nis part of that Component: it is saved with **Save**, like any other field.\nSlots deeper down belong to the Components above them, so filling one saves that\nComponent straight away, and a **Saved as you go** note under the tree says so.\nA slot under an inline description belongs to the Component that holds the\ndescription, so it follows the same rule: with **Save** when that Component is\nthe one you have open, at once otherwise.\n\n## Contextual defaults\n\nFields marked Contextual on the Contract appear in a separate\n**\"Defaults for usage sites\"** section, clearly labeled optional — even if\nthe Contract also marks them Mandatory. That's intentional: a Contextual\nfield's real value is supplied wherever the content is *used*, not here;\nwhat you set in this section is only a fallback for places that don't\nsupply their own value.\n\n### Setting per-usage values on a Reference\n\nWhen you link to another Component via a Reference field (or a Component\nfield's **Choose…**/**Create new…** path — both link the same way), select\n**Contextual values** to open a panel listing that target's own Contextual\nfields, each with three distinct states you can switch between:\n\n- **Inheriting the Component's default** — nothing set here; the linked\n Component's own default value is used.\n- **Overridden** — set a value here to use instead of the default, just\n for this one link. This works for every field type the target Contract\n declares as Contextual, not just simple text/number/checkbox fields — a\n Contextual Reference field gets the same **Choose…** picker, a Contextual\n Blob field the same **Upload** button, and a Contextual Nested field the\n same drill-in **Edit** panel you'd see editing that field directly on a\n Component.\n- **Explicitly cleared** — select **Clear** to force \"no value\" at this\n usage, ignoring the default entirely (only available when the field\n isn't required).\n\nSelect **Reset to default** at any time to go back to inheriting. The same\nthree states and the same per-type widgets apply to a Presentation field's\nown contextual-values panel (see\n[Presenting content with Templates](templates.md)).\n\n### Editing the linked Component itself\n\nNext to **Contextual values**, a linked Component also offers **Quick\nedit**, which opens that Component in a layer over the page you're on —\nits own fields, its own **Save**, and a note of everywhere else it's used,\nsince saving changes it there too. How layers stack, and the difference\nbetween a layer that saves on its own and one that's part of your page, is\nexplained in\n[Editing something from where it's used](content-authoring.md#editing-something-from-where-its-used).\n\n## Organizing with folders\n\nThe **Authoring** page shows your folder tree on the left. At the top are **All components** (everything in\nthis environment, across every folder) and **Top level** (Components that aren't in any folder). Below them\nare your folders, each with a count; a folder's count includes everything beneath it. A long folder name wraps\nrather than being cut off.\n\nPoint at a folder to see its actions: the **+** icon creates a subfolder inside it, the pencil renames it or\nmoves it (choose where it goes under **Inside**), the trash icon deletes it (only possible once it's empty,\nand it asks first), and the handle drags it. Selecting a folder shows two tabs: **Contents** (the Components\ninside it) and, if you have the right permissions, **Settings** (that folder's **Access rules**, **Allowed\nContracts**, and editorial workflow assignment). The double-arrow at the top of the panel collapses the whole\ntree to a narrow rail of icons with count badges; select one to open that folder, or the arrow to bring the\npanel back.\n\nEach Component is a row with its title (its id underneath), Contract, publish status (**Draft**, **Published**,\n**Changed** or **Unpublished**), and who last updated it and when. Select the **Title** or **Updated** heading\nto sort by it. Above the list, a search box matches a title, id or Contract, and the **Contract** and\n**Category** chips narrow further; **Clear filters** resets them. Beneath the list, **Rows per page** and\n**Previous / Next** page through long folders, and a line says how many of the total you are looking at.\n\n### Moving Components by dragging, or with the menu\n\nDrag a Component by the handle at the start of its row onto a folder in the tree — or onto **Top level** to take\nit out of its folder — to move it. If you've ticked several rows, dragging one drags them all. A message\nconfirms what moved and offers **Undo**, which puts each Component back where it came from.\n\nTo move without dragging, open the row's **⋯** menu and choose **Move to folder…**, then pick the folder. When\nthe row is part of a selection, the menu says \"Move 3 selected to folder…\" and moves all of them. A folder you\ncan't edit is shown but not choosable. A move is not all-or-nothing: if a Component can't go there (the folder\ndoesn't allow its Contract, say, or you can't edit it), the message names it and why, and the rest still move.\nDragging a folder onto another moves the whole folder inside it; a folder can't be dropped into itself or one\nof its own subfolders. Folders are always listed alphabetically, so there is no manual order to drag into.\n\n### Working on several Components at once\n\nTick rows (the box in the heading ticks every row on the page) and a bar replaces the search tools, showing how\nmany are selected and in which publish states:\n\n- **Publish** applies to everything selected, and reads **Republish** when none of the selection is a draft.\n It opens the usual publish dialog, which lists what else would be published with them.\n- **Unpublish** applies only to what is published or changed. It shows \"2 of 5\" when some of the selection\n can't be unpublished, is switched off with the reason when none can, and asks you to confirm, with a breakdown\n of what comes off the live site.\n- **Move to folder…** moves what you can edit and says how many of the selection that is.\n\nUnder **Settings**:\n\n- **Access rules** restrict which roles can view, edit, delete, or publish\n content in that folder and everything below it (until a subfolder sets\n its own, narrower rules). No rules anywhere on a branch means it's open\n to every member. Select **Add Rule** to grant a role access: pick the\n role from the list and check whichever of View/Edit/Delete/Publish it\n should have. Editing, deleting, or publishing all imply viewing, so you\n don't need to check View separately for those.\n- **Allowed Contracts** restrict which Contracts new Components in that\n folder (and its subfolders, unless they set their own) can use — useful\n for keeping a folder focused on one kind of content. Select **Add\n Contract** and search for the Contract to allow; select **Remove** next\n to an already-allowed Contract to take it off the list. This only\n affects *new* or *moved* Components; it never breaks ones already there,\n though they'll show a **Non-conforming** badge as a reminder.\n\nIf you don't have permission to manage a folder's access rules or allowed\nContracts, you can still see what you're allowed to do there — the panel\njust won't let you change it.\n\n### Moving a Component from its own page\n\nOpen the Component, select the **Settings** tab, and select **Move…**\nnext to the **Folder** label. A picker lists every folder (and **Root**);\npick one to move the Component there once you save. A folder you don't\nhave edit access to is shown but disabled, with an explanation. A folder\nwhose **Allowed Contracts** don't include this Component's Contract is\ndisabled too — unlike an *existing* Component whose folder's rules later\nchange (the **Non-conforming** badge case above), a move that would\nviolate the target folder's rules is rejected outright, so the picker\nwon't offer it as an option in the first place.\n\n### Finding your way back to a folder\n\nThe Component editor shows a breadcrumb above its title (**Content** /\nthe folder it's in / the Component's name) — select the folder name to\nreturn straight to that folder's Contents tab, rather than using your\nbrowser's back button.\n\n## The upgrade badge\n\nIf a Contract changes after a Component was created from it, that\nComponent keeps working exactly as it did — nothing breaks automatically.\nInstead:\n\n- If the Component still satisfies the Contract's latest version, you'll\n see a badge offering **Upgrade to v_N_** — select it to move the\n Component onto the latest version immediately.\n- If it no longer satisfies the latest version, you'll see a\n **Not valid against latest** badge listing exactly what's wrong. Select\n **Start guided upgrade** to switch into editing against the latest\n version, fix the listed issues, and save — the Component moves onto the\n new version as part of that save.\n\nYou're never forced to upgrade; an older Component keeps validating against\nthe version it was created with until you choose to move it forward.\n\n## Asking the assistant to edit this Component\n\nThe help panel's question box (open it from the **?** icon) can see and edit the Component you have\nopen, not only answer questions about it — see **When the assistant can read and edit** in\n[Getting help](../general/getting-help.md). A field edit it makes saves immediately with the same\nversion history a manual edit gets; anything bigger, like deleting the Component, is proposed for\nyou to review first.\n"
19
+ "body": "# Authoring Components\n\nA Component is one piece of content built from a Contract — for example,\na specific article. This guide covers creating and editing Components,\norganizing them in folders, and the friction the app shows you when a\nContract changes underneath a Component you've already created. See\n[Modeling content with Contracts](contracts.md) first if you haven't\ncreated a Contract yet.\n\n## Creating a Component\n\n1. From the Content page, select **New Component** (optionally after\n opening the folder you want it created in).\n2. Enter a **Name** — the **Id** fills in from it automatically and can\n still be edited by hand.\n3. Choose a **Contract**. If you started from a specific folder that\n restricts which Contracts are allowed there, only those (and their\n descendants) are offered.\n4. Fill in the form that appears — every field from the Contract, laid\n out in order. Fields marked with a red **\\*** are required.\n5. Select **Create**. If a required field is missing or a value doesn't\n match the Contract's rules, the field is highlighted with an\n explanation — fix it and select **Create** again.\n\n## Filling in fields\n\nMost fields are a straightforward text box, number box, or checkbox.\nA few work differently:\n\n- **Reference** and **Nested** are older field types kept working for\n existing Contracts, but no longer offered when adding a new field — new\n Contracts should use **Component** instead (below), which offers the\n same two behaviors plus a third, chosen per value instead of committed\n to for the whole field.\n- **Component** fields ask you to choose, each time you fill one in:\n **Choose…** to link to an existing Component (same search box as\n Reference, with **Change**/**Remove** once chosen); **Create new…** to\n create a brand-new Component and link to it in one step (fill in its\n name, Contract, and any required fields right there); or **Create\n inline…** to embed a value that only ever exists inside this one — pick\n a Contract and an **Edit** panel slides in, exactly like Nested below.\n If the Contract only allows one of these choices, only that one is\n offered. If a linked Component can't be found — most often because it\n was skipped during a promotion into this environment (see\n [content-environments.md](content-environments.md)'s \"Unresolved\n references\" section) — you'll see a distinct **Unresolved** badge\n instead of the usual resolved name, with a link to Component Sync to\n see the full picture and fix it. **Change**/**Remove** still work\n normally on an unresolved value.\n- **Blob** fields (images and other files) show an **Upload** button.\n Once uploaded, you'll see a preview (for images) and a link to download\n the file, plus a **Replace** button.\n- **Nested** fields show a small **Edit** panel once a Contract is chosen\n for them (automatically, if only one is allowed for that field, or via a\n picker if more than one is allowed) — selecting **Edit** opens the\n nested content in its own panel, sliding in over the current one. Any\n unsaved changes you've made — at every level — are kept even if you\n drill several levels deep and back out again; nothing is lost until you\n actually leave the page without saving. A Component field's own **Create\n inline…** choice opens the identical panel.\n- Fields marked **Localizable** always show a small translations icon next\n to their label — select it to add per-locale overrides alongside the\n default value. It's disabled (with an explanation on hover) until your\n organization has a language configured under **Localization** settings\n with at least one language added under it to translate into; once one\n exists, the icon becomes selectable. This works the same way for every\n field type, including Blob, Reference, Nested, Component, and\n Presentation fields: each locale gets its own independent\n **Upload**/**Edit**/**Choose…** affordance, so a Nested value's translated\n content — or a different linked Component or uploaded file per locale —\n is fully separate from the default. The default-locale row in the\n translations panel is always read-only (a reflection of the default\n value, not a second copy of it); translate from the other locale rows.\n- **Presentation** fields let you instantiate a Template inline — pick a\n Template, bind it to a Component, and set contextual values and settings\n for this specific placement. See\n [Presenting content with Templates](templates.md) for the full flow.\n\n## Links to the live page\n\nIf the Contract has **External links**, they appear as buttons under the\nComponent's name, and at the top of the quick-edit panel. A button opens that\nComponent's page on your site in a new tab. If it is greyed out, the reason is\nwritten beside it, usually that the Component has not been published yet. The\nlink always shows what is *published*, not the changes you are typing. See\n[Links to your site](contracts.md) to set them up.\n\n## Editing a tree of Components\n\nWhen a Contract is set up to be edited as a tree (see\n[Editing fields as a tree](contracts.md)), its Component editor shows one\nsection, such as **Pedigree**, in place of the separate pickers. The Component\nyou are editing is the root, and each slot is a Component of its own.\n\n- **Chart or outline.** A slot-based tree such as a pedigree is drawn as a chart,\n one column per generation, or as an outline. Choose with the buttons above it;\n the outline is used on narrow screens. **Generations** shows fewer levels\n without changing anything. A list, such as the parts of a product, is always\n an outline you can collapse and expand.\n- **Fill a slot.** Select an empty slot to search for an existing Component, or\n **Create new** to make one on the spot. A slot only lists Components it can\n hold, such as dogs for a sire.\n- **Options you can't choose are greyed out, with the reason.** *Would become its\n own ancestor* or *Would contain itself* means choosing it would make something\n its own ancestor. *Already used elsewhere in this tree* appears when the\n Contract doesn't allow repeats. *Already in this list* means it is there\n already. If the server still refuses a change, the reason is shown above the\n tree.\n- **Edit without leaving.** **Edit** on a filled slot opens that Component in a\n panel over the page. Change it, save it and close the panel, and you are back\n in the tree.\n- **Change or remove.** Point at a filled slot for **Change** and the remove\n button. Removing only empties the slot; the Component itself is kept.\n- **A slot under an empty parent is greyed out**, because there is nothing to\n attach it to yet. Fill the parent first.\n- **A name with ×2 or \"in 2\"** is one Component that appears in more than one\n place. Editing it changes it everywhere.\n\n**A slot can be described inline.** Some fields accept a description written\nin place instead of an existing Component, for example a dam who is not in your\narchive and never will be. Where a field allows it, the picker has an\n**Enter … inline instead** button. An inline slot is drawn with a dashed\noutline and an **Inline** chip, and its own slots (her sire and dam, say) are\ndrawn under it and filled in the same way as any other.\n\n- **Edit** on an inline slot opens its own fields in a panel at the side. The\n slots the tree draws are not repeated there. Choose **Done** to keep your\n changes.\n- **Change** or the remove button on an inline slot replaces or removes it\n *together with everything under it*. The picker says how many entries that\n is before you choose, and a notice with **Undo** appears for a few seconds\n afterwards. Undo puts the whole description back.\n- A field that only accepts an existing Component has no inline button.\n- Nothing else can point at an inline description, so it shows no ×2 count.\n\n**What saves when.** The first level, the slots of the Component you have open,\nis part of that Component: it is saved with **Save**, like any other field.\nSlots deeper down belong to the Components above them, so filling one saves that\nComponent straight away, and a **Saved as you go** note under the tree says so.\nA slot under an inline description belongs to the Component that holds the\ndescription, so it follows the same rule: with **Save** when that Component is\nthe one you have open, at once otherwise.\n\n## Contextual defaults\n\nFields marked Contextual on the Contract appear in a separate\n**\"Defaults for usage sites\"** section, clearly labeled optional — even if\nthe Contract also marks them Mandatory. That's intentional: a Contextual\nfield's real value is supplied wherever the content is *used*, not here;\nwhat you set in this section is only a fallback for places that don't\nsupply their own value.\n\n### Setting per-usage values on a Reference\n\nWhen you link to another Component via a Reference field (or a Component\nfield's **Choose…**/**Create new…** path — both link the same way), select\n**Contextual values** to open a panel listing that target's own Contextual\nfields, each with three distinct states you can switch between:\n\n- **Inheriting the Component's default** — nothing set here; the linked\n Component's own default value is used.\n- **Overridden** — set a value here to use instead of the default, just\n for this one link. This works for every field type the target Contract\n declares as Contextual, not just simple text/number/checkbox fields — a\n Contextual Reference field gets the same **Choose…** picker, a Contextual\n Blob field the same **Upload** button, and a Contextual Nested field the\n same drill-in **Edit** panel you'd see editing that field directly on a\n Component.\n- **Explicitly cleared** — select **Clear** to force \"no value\" at this\n usage, ignoring the default entirely (only available when the field\n isn't required).\n\nSelect **Reset to default** at any time to go back to inheriting. The same\nthree states and the same per-type widgets apply to a Presentation field's\nown contextual-values panel (see\n[Presenting content with Templates](templates.md)).\n\n### Editing the linked Component itself\n\nNext to **Contextual values**, a linked Component also offers **Quick\nedit**, which opens that Component in a layer over the page you're on —\nits own fields, its own **Save**, and a note of everywhere else it's used,\nsince saving changes it there too. How layers stack, and the difference\nbetween a layer that saves on its own and one that's part of your page, is\nexplained in\n[Editing something from where it's used](content-authoring.md#editing-something-from-where-its-used).\n\n## Organizing with folders\n\nThe **Authoring** page shows your folder tree on the left. At the top are **All components** (everything in\nthis environment, across every folder) and **Top level** (Components that aren't in any folder). Below them\nare your folders, each with a count; a folder's count includes everything beneath it. A long folder name wraps\nrather than being cut off.\n\nPoint at a folder to see its actions: the **+** icon creates a subfolder inside it, the pencil renames it or\nmoves it (choose where it goes under **Inside**), the trash icon deletes it (only possible once it's empty,\nand it asks first), and the handle drags it. Selecting a folder shows two tabs: **Contents** (the Components\ninside it) and, if you have the right permissions, **Settings** (that folder's **Access rules**, **Allowed\nContracts**, and editorial workflow assignment). The double-arrow at the top of the panel collapses the whole\ntree to a narrow rail of icons with count badges; select one to open that folder, or the arrow to bring the\npanel back.\n\nEach Component is a row with its title (its id underneath), Contract, publish status (**Draft**, **Published**,\n**Changed** or **Unpublished**), and who last updated it and when. Select the **Title** or **Updated** heading\nto sort by it. Above the list, a search box matches a title, id or Contract, and the **Contract**,\n**Category** and **Status** chips narrow further; **Clear filters** resets them. **Status** lets you tick\none or more of Draft, Published, Changed and Unpublished, for example to find everything that has changed since\nit was published. The count under the list follows the filter, so it is the number that match, not the number\non the page. **Import**, beside **New Component**, opens the [bundle import](export-import.md) for bringing\nComponents in from another environment. Beneath the list, **Rows per page** and\n**Previous / Next** page through long folders, and a line says how many of the total you are looking at.\n\n### Moving Components by dragging, or with the menu\n\nDrag a Component by the handle at the start of its row onto a folder in the tree — or onto **Top level** to take\nit out of its folder — to move it. If you've ticked several rows, dragging one drags them all. A message\nconfirms what moved and offers **Undo**, which puts each Component back where it came from.\n\nTo move without dragging, open the row's **⋯** menu and choose **Move to folder…**, then pick the folder. When\nthe row is part of a selection, the menu says \"Move 3 selected to folder…\" and moves all of them. A folder you\ncan't edit is shown but not choosable. A move is not all-or-nothing: if a Component can't go there (the folder\ndoesn't allow its Contract, say, or you can't edit it), the message names it and why, and the rest still move.\nDragging a folder onto another moves the whole folder inside it; a folder can't be dropped into itself or one\nof its own subfolders. Folders are always listed alphabetically, so there is no manual order to drag into.\n\n### Working on several Components at once\n\nTick rows (the box in the heading ticks every row on the page) and a bar replaces the search tools, showing how\nmany are selected and in which publish states:\n\n- **Publish** applies to everything selected, and reads **Republish** when none of the selection is a draft.\n It opens the usual publish dialog, which lists what else would be published with them.\n- **Unpublish** applies only to what is published or changed. It shows \"2 of 5\" when some of the selection\n can't be unpublished, is switched off with the reason when none can, and asks you to confirm, with a breakdown\n of what comes off the live site.\n- **Move to folder…** moves what you can edit and says how many of the selection that is.\n\nUnder **Settings**:\n\n- **Access rules** restrict which roles can view, edit, delete, or publish\n content in that folder and everything below it (until a subfolder sets\n its own, narrower rules). No rules anywhere on a branch means it's open\n to every member. Select **Add Rule** to grant a role access: pick the\n role from the list and check whichever of View/Edit/Delete/Publish it\n should have. Editing, deleting, or publishing all imply viewing, so you\n don't need to check View separately for those.\n- **Allowed Contracts** restrict which Contracts new Components in that\n folder (and its subfolders, unless they set their own) can use — useful\n for keeping a folder focused on one kind of content. Select **Add\n Contract** and search for the Contract to allow; select **Remove** next\n to an already-allowed Contract to take it off the list. This only\n affects *new* or *moved* Components; it never breaks ones already there,\n though they'll show a **Non-conforming** badge as a reminder.\n\nIf you don't have permission to manage a folder's access rules or allowed\nContracts, you can still see what you're allowed to do there — the panel\njust won't let you change it.\n\n### Moving a Component from its own page\n\nOpen the Component, select the **Settings** tab, and select **Move…**\nnext to the **Folder** label. A picker lists every folder (and **Root**);\npick one to move the Component there once you save. A folder you don't\nhave edit access to is shown but disabled, with an explanation. A folder\nwhose **Allowed Contracts** don't include this Component's Contract is\ndisabled too — unlike an *existing* Component whose folder's rules later\nchange (the **Non-conforming** badge case above), a move that would\nviolate the target folder's rules is rejected outright, so the picker\nwon't offer it as an option in the first place.\n\n### Finding your way back to a folder\n\nThe Component editor shows a breadcrumb above its title (**Content** /\nthe folder it's in / the Component's name) — select the folder name to\nreturn straight to that folder's Contents tab, rather than using your\nbrowser's back button.\n\n## The upgrade badge\n\nIf a Contract changes after a Component was created from it, that\nComponent keeps working exactly as it did — nothing breaks automatically.\nInstead:\n\n- If the Component still satisfies the Contract's latest version, you'll\n see a badge offering **Upgrade to v_N_** — select it to move the\n Component onto the latest version immediately.\n- If it no longer satisfies the latest version, you'll see a\n **Not valid against latest** badge listing exactly what's wrong. Select\n **Start guided upgrade** to switch into editing against the latest\n version, fix the listed issues, and save — the Component moves onto the\n new version as part of that save.\n\nYou're never forced to upgrade; an older Component keeps validating against\nthe version it was created with until you choose to move it forward.\n\n## Asking the assistant to edit this Component\n\nThe help panel's question box (open it from the **?** icon) can see and edit the Component you have\nopen, not only answer questions about it — see **When the assistant can read and edit** in\n[Getting help](../general/getting-help.md). A field edit it makes saves immediately with the same\nversion history a manual edit gets; anything bigger, like deleting the Component, is proposed for\nyou to review first.\n"
20
20
  },
21
21
  {
22
22
  "slug": "content-adapters",
@@ -31,7 +31,7 @@ export const HELP_TOPICS = [
31
31
  {
32
32
  "slug": "content-composer",
33
33
  "title": "Building your site in Composer",
34
- "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 is where you choose its type and, for a\nPresentation page, what actually renders:\n\n- **Template** shows which Template is bound and the Contract it\n requires.\n- **Satisfied by** shows the actual chain that fills that requirement —\n either a Component directly, or one or more Adapters translating a\n Component's content into what the Template expects (see\n [Adapters](content-adapters.md) if that's new to you). This is a live\n view of the binding actually in effect, not just two separate names, and\n it's also where you do the actual work: the innermost box in the chain\n is where you pick a Template, bind a Component (or create one on the\n spot), and fine-tune it through the **Contextual values** and\n **Settings** panels described in\n [Presenting content with Templates](templates.md). If the Template\n declares a settings field that's both mandatory and Contextual, it must\n be filled in here — a page is the last stop for that value, so there's\n nowhere further downstream to inherit 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## The Configuration tab\n\nEverything about a page other than what it renders lives in\n**Configuration**: its name and slug, its location in the tree (parent,\nMove…), access rules and workflow assignment, classification tags, and —\nfor a non-root page — the option to delete it. **Name** is a labelled field\nhere, saved with **Save name and slug**. Deleting asks you to confirm first.\nIf you select another page while this one has unsaved edits, Composer asks\nbefore it drops them.\n\nPublish status and the page's actions — **Preview…**, **Promote…**, and a\n**Publish…**/**Republish…** button (once published, its own chevron opens\n**Unpublish**) — sit together in a row above the page name, visible no\nmatter which tab is open, since they matter regardless of what you're\ncurrently editing. A small workflow chip appears there too, once a page\nhas an editorial workflow assigned — select it to jump straight to the\nfull workflow panel in Configuration.\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\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\nA **Browse** toggle switches off the pins so you can click around the page\nthe way a visitor would — following links to see other pages of the same\nsite, still against your unsaved drafts.\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, and\n the panel says so — use it to edit 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 loaded, but it did not read the draft**,\n what you're looking at isn't your draft. Usually the site isn't set up for\n server previews yet, its key doesn't allow draft preview, or your browser\n blocked the site's cookie inside Composer. **Open the site in a new tab**\n gets around that last one.\n- Closing live preview ends the session straight away. Nobody can use it\n afterwards.\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 \"Access & workflow\" section:\n\n- **Access rules** grant 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- **Allowed Templates** 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"
34
+ "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 is where you choose its type and, for a\nPresentation page, what actually renders:\n\n- **Template** shows which Template is bound and the Contract it\n requires.\n- **Satisfied by** shows the actual chain that fills that requirement —\n either a Component directly, or one or more Adapters translating a\n Component's content into what the Template expects (see\n [Adapters](content-adapters.md) if that's new to you). This is a live\n view of the binding actually in effect, not just two separate names, and\n it's also where you do the actual work: the innermost box in the chain\n is where you pick a Template, bind a Component (or create one on the\n spot), and fine-tune it through the **Contextual values** and\n **Settings** panels described in\n [Presenting content with Templates](templates.md). If the Template\n declares a settings field that's both mandatory and Contextual, it must\n be filled in here — a page is the last stop for that value, so there's\n nowhere further downstream to inherit 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## The Configuration tab\n\nEverything about a page other than what it renders lives in\n**Configuration**: its name and slug, its location in the tree (parent,\nMove…), access rules and workflow assignment, classification tags, and —\nfor a non-root page — the option to delete it. **Name** is a labelled field\nhere. Deleting asks you to confirm first.\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\nPublish status and the page's actions — **Preview…**, **Promote…**, and a\n**Publish…**/**Republish…** button (once published, its own chevron opens\n**Unpublish**) — sit together in a row above the page name, visible no\nmatter which tab is open, since they matter regardless of what you're\ncurrently editing. A small workflow chip appears there too, once a page\nhas an editorial workflow assigned — select it to jump straight to the\nfull workflow panel in Configuration.\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\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\nA **Browse** toggle switches off the pins so you can click around the page\nthe way a visitor would — following links to see other pages of the same\nsite, still against your unsaved drafts.\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, and\n the panel says so — use it to edit 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 loaded, but it did not read the draft**,\n what you're looking at isn't your draft. Usually the site isn't set up for\n server previews yet, its key doesn't allow draft preview, or your browser\n blocked the site's cookie inside Composer. **Open the site in a new tab**\n gets around that last one.\n- Closing live preview ends the session straight away. Nobody can use it\n afterwards.\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 \"Access & workflow\" section:\n\n- **Access rules** grant 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- **Allowed Templates** 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"
35
35
  },
36
36
  {
37
37
  "slug": "content-environments",
@@ -101,7 +101,7 @@ export const HELP_TOPICS = [
101
101
  {
102
102
  "slug": "publishing",
103
103
  "title": "Publishing content",
104
- "body": "# Publishing content\n\nEverything you build in Content — Components and Experience nodes — stays\nprivate to your organization until you **publish** it. Publishing takes a\nsnapshot of what you're looking at and copies it into a separate,\nread-optimized space that the Content Delivery API serves to the outside\nworld. Editing something after it's published never changes what's live;\nyou have to publish again. (Developers building the site that shows this\ncontent start from `docs/content-sdk.md`.)\n\n## The lifecycle\n\nEvery publishable item shows a status badge:\n\n- **Draft** — never published.\n- **Published** — a snapshot is live, and it matches your current edits.\n- **Modified since publish** — a snapshot is live, but you've made\n changes since. Visitors still see the old snapshot until you publish\n again.\n- **Unpublished** — was published once, then taken down. The item still\n exists in Content; it's just not being served anymore.\n\n## Publishing an item\n\nSelect **Publish…** on a Component or an Experience node's detail panel.\nThis opens the **publish plan** — a list of everything that needs to go\nout together: the item itself, plus anything it depends on (a node's\nbound Component, a Component's own references, and so on, however deep\nthat chain goes).\n\nOn an item that's already live, the same button reads **Republish…** and\nsits next to **Unpublish** — use it to push new snapshots without taking\nanything down first. This is also how a change *inside* the dependency\nchain goes live: editing a published node's bound Component doesn't\nchange the node's own badge, but republishing the node re-freezes the\nwhole plan, the edited Component included.\n\nFor each item in the plan you'll see:\n\n- Its current status.\n- Whether it's valid to publish as-is. An invalid item is shown with its\n error and can't be included — fix the problem first, then reopen the\n plan.\n- A warning (not a blocker) if the item doesn't validate against the\n *latest* version of its Contract or Template, even though it's fine\n against the version it's actually pinned to. It will still publish; the\n warning is a heads-up that something upstream has moved on.\n\nUncheck anything you don't want to publish yet — a skipped item simply\nisn't included this time; nothing else in the plan is affected. If your\norganization has mapped more than one delivery environment from where\nyou're authoring (see [content-environments.md](content-environments.md)),\nchoose which one to publish to — otherwise it goes to the one delivery\nenvironment mapped here, exactly as before. Select **Publish** to go live\nwith everything still checked.\n\nPublishing requires the **Publish** permission on that item's branch\n(folder for Components, node branch for Experience nodes) — a separate\npermission from **Edit**, so an organization can have editors who can't\npush content live, and publishers who review before it goes out. If you\ndon't have it, the button is disabled and explains why.\n\n## Unpublishing\n\nSelect **Unpublish** to take a live item down immediately. Its URL (if it\nhad one) stops resolving. The item itself is untouched in Content — you\ncan publish it again at any time.\n\n**Images and files are different: unpublishing doesn't take them down.**\nThe first time an image or file field is published, it gets a permanent,\npublic link — anyone who has that link can still open it even after you\nunpublish the item that used it, or after you replace the image with a\ndifferent one. This is because the file's link never changes once\npublished (so it keeps working in caches, emails, and anywhere else it was\ncopied), and there's no way to \"recall\" a link once it's been shared.\nNothing changes about who can *edit* the file or where it appears in your\nsite — only the direct link to the file itself stays reachable.\n\nIf you publish a Component or page whose image field hasn't been made\npublic yet, **publishing itself requires a one-time setup on our end** —\nif that hasn't happened yet, publishing is blocked with a message saying\nso rather than silently publishing a broken image link. Contact support if\nyou see this.\n\n## Promoting content between environments\n\nIf your organization authors in more than one environment (Staging and\nProduction, say), **Promote…** — next to **Publish…** on a Component or\nExperience node — copies it, and everything it depends on, into another\nauthoring environment, ready to be published there in turn. This is\nseparate from publishing: promoting moves draft content between authoring\nspaces; publishing takes draft content live. See\n[content-environments.md](content-environments.md) for the full picture.\n\n## Renaming or moving a published Experience node\n\nIf you change a published node's slug (or move it), republishing\nre-computes every affected path. The **old** path automatically becomes a\nredirect to the new one, so existing links and bookmarks keep working —\nyou don't have to do anything extra. You can review and remove these\nredirects from a site's own **Manage** view under **Sites** (see below).\n\n## Keeping a page out of search results\n\nSome published pages shouldn't be advertised to search engines — a search\nresults page, an internal index, a section you'd rather people reached only\nfrom a link you sent them.\n\nOpen the page in **Composer**, go to the **Configuration** tab, and use\n**Search visibility**. Turning it off means the page is left out of the\n**sitemap** — the list of URLs your site gives search engines. Everything\nelse stays exactly as it was: the page is still published, still live, and\nstill works for anyone who visits or links to its URL.\n\nTwo things to know:\n\n- **It applies to everything beneath it.** Excluding a section page\n excludes every page under it too, however deep. A page excluded this way\n shows you which parent is responsible, with a link to it, so you can\n change it there.\n- **It takes effect when you publish.** Toggling it marks the page as\n **Modified**, exactly like editing its content — publish the page and the\n change reaches your live site.\n\nThis isn't the same as telling search engines not to *index* a page they\nalready know about. Leaving a page out of the sitemap means you aren't\nadvertising it; a search engine that finds it another way (a link from\nsomewhere else, say) can still list it.\n\n## When search engines are told a page changed\n\nYour sitemap tells search engines when each page last changed, so they know\nwhich pages are worth re-reading. You don't configure this and there's\nnothing to keep up to date — but it's worth knowing what it reflects:\n\n- It's the date the page's **content** last changed, not the date it was\n last published. Republishing a page you haven't edited doesn't move it,\n so publishing a whole site doesn't tell search engines that everything\n changed at once.\n- Renaming a page or editing its content moves it. Reordering pages or\n moving one to a different parent doesn't — neither changes what's on the\n page.\n- Editing the content a page is built from — the Component it's bound to —\n moves it too, even if you only publish that Component. Content nested a\n further step away (a Component referenced by *that* Component) doesn't,\n so the date can occasionally be a little older than the last real change.\n That's deliberate: an early date costs nothing, while a date that's too\n recent teaches search engines to stop trusting it.\n\n## Delivery settings\n\nThe **Delivery** page (in the app navigation) is where you manage delivery\nkeys — credentials external systems use to call the Content Delivery API.\nSelect **Create key**, give it a name, and copy the value shown — it's only\ndisplayed once. If more than one delivery environment is mapped here,\nchoose which one the key reads from. Revoke a key at any time to cut off\nwhatever's using it immediately.\n\nThere are two ways to use a key, and the **Browser-safe key** switch decides\nwhich you're creating:\n\n- **Server-side** (the default) — works from anywhere, so it must stay on\n your server, in a build step, or behind an edge function. Never put one in\n a web page.\n- **Browser-safe** — only works from the **allowed origins** (the websites\n you list, pre-filled from your sites' host mappings; add\n `http://localhost:<port>` for local development) and, optionally, the\n **allowed IP ranges** you list. Because it can't be used from anywhere\n else, it's safe to include in a website's own code. Everything a delivery\n key can read is already published, so a browser-safe key never exposes\n anything a visitor to your site couldn't see.\n\nEach key shows a **Browser-safe** or **Server-side** badge, and **Manage**\nlets you change a key's restrictions later — for example to add a new\nhostname. Removing every restriction from a browser-safe key asks you to\nconfirm, since that key may already be in a shipped site.\n\nRunning the same site against several delivery environments (development,\ntest, acceptance, production)? Create one browser-safe key per environment\nand give the site the matching key per deployment — the site's code stays\nidentical. To keep a non-production environment private, restrict its key\nto your office or VPN address range; the CMS never refuses to issue a key\nfor an environment. Not sure which address your office or server shows up\nas? Open `https://api.ebitex.io/diagnostics/client-address` from it — the\n`clientAddress` it returns is the one to allow.\n\nHost mapping and redirect aliases live on the **Sites** page instead — see\nbelow.\n\n## Host mapping and redirect aliases\n\nOpen **Sites** (in the app navigation) and select **Manage** on a site to\nreach:\n\n- **Host mapping** — which hostname(s) serve this site, for systems that\n resolve content by host rather than passing a site id explicitly. Enter\n one hostname per line and select **Save hosts**.\n- **Redirect aliases** — the list of old paths automatically created by\n renaming/moving this site's published nodes (see above). Delete one if\n you no longer want that old link to redirect.\n\nIf your authoring environment publishes to more than one delivery\nenvironment, a **Delivery environment** picker appears above the host\nmapping and redirect-alias sections — each delivery environment has its\nown independent set of hostnames and aliases, so choose which one you're\nviewing or editing before making a change. With a single delivery\nenvironment mapped, the picker stays hidden and there's nothing extra to\nchoose.\n\nManaging keys uses the same permission as Hub's API Keys page; host\nmapping and aliases use the same access-management permission as branch\nrules.\n"
104
+ "body": "# Publishing content\n\nEverything you build in Content — Components and Experience nodes — stays\nprivate to your organization until you **publish** it. Publishing takes a\nsnapshot of what you're looking at and copies it into a separate,\nread-optimized space that the Content Delivery API serves to the outside\nworld. Editing something after it's published never changes what's live;\nyou have to publish again. (Developers building the site that shows this\ncontent start from `docs/content-sdk.md`.)\n\n## The lifecycle\n\nEvery publishable item shows a status badge:\n\n- **Draft** — never published.\n- **Published** — a snapshot is live, and it matches your current edits.\n- **Modified since publish** — a snapshot is live, but you've made\n changes since. Visitors still see the old snapshot until you publish\n again.\n- **Unpublished** — was published once, then taken down. The item still\n exists in Content; it's just not being served anymore.\n\n## Publishing an item\n\nSelect **Publish…** on a Component or an Experience node's detail panel.\nThis opens the **publish plan** — a list of everything that needs to go\nout together: the item itself, plus anything it depends on (a node's\nbound Component, a Component's own references, and so on, however deep\nthat chain goes).\n\nOn an item that's already live, the same button reads **Republish…** and\nsits next to **Unpublish** — use it to push new snapshots without taking\nanything down first. This is also how a change *inside* the dependency\nchain goes live: editing a published node's bound Component doesn't\nchange the node's own badge, but republishing the node re-freezes the\nwhole plan, the edited Component included.\n\nFor each item in the plan you'll see:\n\n- Its current status.\n- Whether it's valid to publish as-is. An invalid item is shown with its\n error and can't be included — fix the problem first, then reopen the\n plan.\n- A warning (not a blocker) if the item doesn't validate against the\n *latest* version of its Contract or Template, even though it's fine\n against the version it's actually pinned to. It will still publish; the\n warning is a heads-up that something upstream has moved on.\n\nUncheck anything you don't want to publish yet — a skipped item simply\nisn't included this time; nothing else in the plan is affected. If your\norganization has mapped more than one delivery environment from where\nyou're authoring (see [content-environments.md](content-environments.md)),\nchoose which one to publish to — otherwise it goes to the one delivery\nenvironment mapped here, exactly as before. Select **Publish** to go live\nwith everything still checked.\n\nPublishing requires the **Publish** permission on that item's branch\n(folder for Components, node branch for Experience nodes) — a separate\npermission from **Edit**, so an organization can have editors who can't\npush content live, and publishers who review before it goes out. If you\ndon't have it, the button is disabled and explains why.\n\n## Unpublishing\n\nSelect **Unpublish** to take a live item down immediately. Its URL (if it\nhad one) stops resolving. The item itself is untouched in Content — you\ncan publish it again at any time.\n\n**Images and files are different: unpublishing doesn't take them down.**\nThe first time an image or file field is published, it gets a permanent,\npublic link — anyone who has that link can still open it even after you\nunpublish the item that used it, or after you replace the image with a\ndifferent one. This is because the file's link never changes once\npublished (so it keeps working in caches, emails, and anywhere else it was\ncopied), and there's no way to \"recall\" a link once it's been shared.\nNothing changes about who can *edit* the file or where it appears in your\nsite — only the direct link to the file itself stays reachable.\n\nIf you publish a Component or page whose image field hasn't been made\npublic yet, **publishing itself requires a one-time setup on our end** —\nif that hasn't happened yet, publishing is blocked with a message saying\nso rather than silently publishing a broken image link. Contact support if\nyou see this.\n\n## Promoting content between environments\n\nIf your organization authors in more than one environment (Staging and\nProduction, say), **Promote…** — next to **Publish…** on a Component or\nExperience node — copies it, and everything it depends on, into another\nauthoring environment, ready to be published there in turn. This is\nseparate from publishing: promoting moves draft content between authoring\nspaces; publishing takes draft content live. See\n[content-environments.md](content-environments.md) for the full picture.\n\n## Renaming or moving a published Experience node\n\nIf you change a published node's slug (or move it), republishing\nre-computes every affected path. The **old** path automatically becomes a\nredirect to the new one, so existing links and bookmarks keep working —\nyou don't have to do anything extra. You can review and remove these\nredirects from a site's own **Manage** view under **Sites** (see below).\n\n## Keeping a page out of search results\n\nSome published pages shouldn't be advertised to search engines — a search\nresults page, an internal index, a section you'd rather people reached only\nfrom a link you sent them.\n\nOpen the page in **Composer**, go to the **Configuration** tab, and use\n**Search visibility**. Turning it off (and selecting **Save**) means the page is left out of the\n**sitemap** — the list of URLs your site gives search engines. Everything\nelse stays exactly as it was: the page is still published, still live, and\nstill works for anyone who visits or links to its URL.\n\nTwo things to know:\n\n- **It applies to everything beneath it.** Excluding a section page\n excludes every page under it too, however deep. A page excluded this way\n shows you which parent is responsible, with a link to it, so you can\n change it there.\n- **It takes effect when you publish.** Toggling it marks the page as\n **Modified**, exactly like editing its content — publish the page and the\n change reaches your live site.\n\nThis isn't the same as telling search engines not to *index* a page they\nalready know about. Leaving a page out of the sitemap means you aren't\nadvertising it; a search engine that finds it another way (a link from\nsomewhere else, say) can still list it.\n\n## When search engines are told a page changed\n\nYour sitemap tells search engines when each page last changed, so they know\nwhich pages are worth re-reading. You don't configure this and there's\nnothing to keep up to date — but it's worth knowing what it reflects:\n\n- It's the date the page's **content** last changed, not the date it was\n last published. Republishing a page you haven't edited doesn't move it,\n so publishing a whole site doesn't tell search engines that everything\n changed at once.\n- Renaming a page or editing its content moves it. Reordering pages or\n moving one to a different parent doesn't — neither changes what's on the\n page.\n- Editing the content a page is built from — the Component it's bound to —\n moves it too, even if you only publish that Component. Content nested a\n further step away (a Component referenced by *that* Component) doesn't,\n so the date can occasionally be a little older than the last real change.\n That's deliberate: an early date costs nothing, while a date that's too\n recent teaches search engines to stop trusting it.\n\n## Delivery settings\n\nThe **Delivery** page (in the app navigation) is where you manage delivery\nkeys — credentials external systems use to call the Content Delivery API.\nSelect **Create key**, give it a name, and copy the value shown — it's only\ndisplayed once. If more than one delivery environment is mapped here,\nchoose which one the key reads from. Revoke a key at any time to cut off\nwhatever's using it immediately.\n\nThere are two ways to use a key, and the **Browser-safe key** switch decides\nwhich you're creating:\n\n- **Server-side** (the default) — works from anywhere, so it must stay on\n your server, in a build step, or behind an edge function. Never put one in\n a web page.\n- **Browser-safe** — only works from the **allowed origins** (the websites\n you list, pre-filled from your sites' host mappings; add\n `http://localhost:<port>` for local development) and, optionally, the\n **allowed IP ranges** you list. Because it can't be used from anywhere\n else, it's safe to include in a website's own code. Everything a delivery\n key can read is already published, so a browser-safe key never exposes\n anything a visitor to your site couldn't see.\n\nEach key shows a **Browser-safe** or **Server-side** badge, and **Manage**\nlets you change a key's restrictions later — for example to add a new\nhostname. Removing every restriction from a browser-safe key asks you to\nconfirm, since that key may already be in a shipped site.\n\nRunning the same site against several delivery environments (development,\ntest, acceptance, production)? Create one browser-safe key per environment\nand give the site the matching key per deployment — the site's code stays\nidentical. To keep a non-production environment private, restrict its key\nto your office or VPN address range; the CMS never refuses to issue a key\nfor an environment. Not sure which address your office or server shows up\nas? Open `https://api.ebitex.io/diagnostics/client-address` from it — the\n`clientAddress` it returns is the one to allow.\n\nHost mapping and redirect aliases live on the **Sites** page instead — see\nbelow.\n\n## Host mapping and redirect aliases\n\nOpen **Sites** (in the app navigation) and select **Manage** on a site to\nreach:\n\n- **Host mapping** — which hostname(s) serve this site, for systems that\n resolve content by host rather than passing a site id explicitly. Enter\n one hostname per line and select **Save hosts**.\n- **Redirect aliases** — the list of old paths automatically created by\n renaming/moving this site's published nodes (see above). Delete one if\n you no longer want that old link to redirect.\n\nIf your authoring environment publishes to more than one delivery\nenvironment, a **Delivery environment** picker appears above the host\nmapping and redirect-alias sections — each delivery environment has its\nown independent set of hostnames and aliases, so choose which one you're\nviewing or editing before making a change. With a single delivery\nenvironment mapped, the picker stays hidden and there's nothing extra to\nchoose.\n\nManaging keys uses the same permission as Hub's API Keys page; host\nmapping and aliases use the same access-management permission as branch\nrules.\n"
105
105
  },
106
106
  {
107
107
  "slug": "sample-references",
@@ -1 +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,knWAAknW;KAC3nW;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,2siBAA2siB;KACptiB;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,kCAAkC;QAC3C,MAAM,EAAE,ggnBAAggnB;KACzgnB;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,0BAA0B;QACnC,MAAM,EAAE,6oLAA6oL;KACtpL;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,gCAAgC;QACzC,MAAM,EAAE,m/fAAm/f;KAC5/f;IACD;QACE,MAAM,EAAE,sBAAsB;QAC9B,OAAO,EAAE,sBAAsB;QAC/B,MAAM,EAAE,k/qBAAk/qB;KAC3/qB;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,2jRAA2jR;KACpkR;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,mBAAmB;QAC5B,MAAM,EAAE,ywKAAywK;KAClxK;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,o7PAAo7P;KAC77P;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,oBAAoB;QAC7B,MAAM,EAAE,6sXAA6sX;KACttX;IACD;QACE,MAAM,EAAE,WAAW;QACnB,OAAO,EAAE,iCAAiC;QAC1C,MAAM,EAAE,+wkBAA+wkB;KACxxkB;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,u/JAAu/J;KAChgK;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,w/OAAw/O;KACjgP;IACD;QACE,MAAM,EAAE,YAAY;QACpB,OAAO,EAAE,oBAAoB;QAC7B,MAAM,EAAE,2hVAA2hV;KACpiV;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,i4KAAi4K;KAC14K;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,kBAAkB;QAC3B,MAAM,EAAE,6hJAA6hJ;KACtiJ;CACF,CAAA"}
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,knWAAknW;KAC3nW;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,smjBAAsmjB;KAC/mjB;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,kCAAkC;QAC3C,MAAM,EAAE,ggnBAAggnB;KACzgnB;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,0BAA0B;QACnC,MAAM,EAAE,6oLAA6oL;KACtpL;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,gCAAgC;QACzC,MAAM,EAAE,23gBAA23gB;KACp4gB;IACD;QACE,MAAM,EAAE,sBAAsB;QAC9B,OAAO,EAAE,sBAAsB;QAC/B,MAAM,EAAE,k/qBAAk/qB;KAC3/qB;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,2jRAA2jR;KACpkR;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,mBAAmB;QAC5B,MAAM,EAAE,ywKAAywK;KAClxK;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,o7PAAo7P;KAC77P;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,oBAAoB;QAC7B,MAAM,EAAE,6sXAA6sX;KACttX;IACD;QACE,MAAM,EAAE,WAAW;QACnB,OAAO,EAAE,iCAAiC;QAC1C,MAAM,EAAE,+wkBAA+wkB;KACxxkB;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,u/JAAu/J;KAChgK;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,w/OAAw/O;KACjgP;IACD;QACE,MAAM,EAAE,YAAY;QACpB,OAAO,EAAE,oBAAoB;QAC7B,MAAM,EAAE,ojVAAojV;KAC7jV;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,i4KAAi4K;KAC14K;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,kBAAkB;QAC3B,MAAM,EAAE,6hJAA6hJ;KACtiJ;CACF,CAAA"}
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@ebitex/content-mcp",
3
- "version": "0.5.146",
3
+ "version": "0.5.149",
4
4
  "description": "An MCP server for ebitex Content: build and publish a content model from an AI agent.",
5
5
  "license": "Apache-2.0",
6
6
  "homepage": "https://developers.ebitex.io/getting-started/content-as-code/",