@ebitex/content-mcp 1.1.261 → 1.1.267

package/dist/resources/helpCorpus.generated.js

@@ -16,7 +16,7 @@ export const HELP_TOPICS = [
     {
         "slug": "components",
         "title": "Authoring Components",
-        "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 existing…** to link to an existing Component (same search box as\n  Reference); or the **Create** menu, whose **Create new…** creates a\n  brand-new Component and links to it in one step (fill in its name,\n  Contract, and any required fields right there), and whose **Write\n  inline…** embeds a value that only ever exists inside this one — pick a\n  Contract and an **Edit** panel slides in, exactly like Nested below. If\n  the Contract only allows one of these choices, only that one is offered,\n  and the field says so. Once filled, the value is a card with a **Component** header (and the **✕**\n  that removes it) over its name and\n  kind, one main button (**Edit**, which opens a linked Component in a layer\n  over the page, or the inline value itself), a **⋯** menu holding **Change…** and\n  **Contextual values**, and a **✕** that removes the value. 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. **Choose another** and the **✕**\n  still work 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## Noting which channels a Component is made for\n\nOn a Component's **Settings** tab, **Made for** lets you note that it suits **Email**, **Web**, or\nboth. It is optional and only advises: it never stops you saving or publishing, and a Component with\nno note is \"unknown\". Pages that are noted for a channel warn about Components that say they are not\nmade for it. The **Made for** column in the Components list shows the note. See\n[Building your site in Composer](content-composer.md#made-for).\n\n## Status, and what to do next\n\nUnder the Component's name, one **status strip** says whether it can be published and, if not, why. It also\nholds the next step, so you do not have to hunt for it:\n\n- **Draft**, **Published** or **Modified since it was published**, with one line about the live site\n  (\"The live site shows an older version\").\n- If your organization uses an [editorial workflow](content-workflow.md) for this folder, the strip shows the\n  workflow's state beside the headline. While that state does not allow publishing it reads **Can't be\n  published yet**, and the workflow's next step (for example **Approve**) sits beside it. Choose it, add an\n  optional comment and confirm, all without leaving the Content tab. **Republish…** stays available, but it is\n  no longer the highlighted button; its tooltip gives the reason, and the publish panel explains the block.\n- Once the state allows publishing it reads **Ready to publish** and **Publish…** is highlighted instead.\n- If you have edited since a review was started, the strip says so, and that publishing will use the version\n  that was reviewed.\n- A Component that no longer fits its folder's rules gets a **Move it…** row.\n- If the Component has translations in progress, they are listed here too, with **Review…** for one that is\n  waiting for you.\n\nThe full workflow panel, with its comment box and **Cancel run**, and the complete translations list stay on the\n**Settings** tab. Where the Component is used (**Used in N places**) and whether it is **Inherited** are in the line\nunder the name.\n\n## Version history\n\nEvery time a Component's content is saved, ebitex keeps a copy, so you can\nsee what changed, who changed it, and undo an unwanted edit.\n\nOpen the **More actions** menu near the top of a Component and choose\n**Version history…**. Each entry shows a version number, who saved it and\nwhen. Select an entry to see what changed compared to the version before\nit: the fields that were added, removed or changed, named as you see them\nin the editor. The very first version has nothing to compare against.\n\nSaving the exact same content twice in a row doesn't add an entry: only a\nsave that actually changes something does. Entries can show **Unknown**\ninstead of a name when none was recorded, which is the case for changes\nmade by promotion, import or inheritance rather than by a person typing in\nthe editor. It doesn't mean the person has left your organization.\n\n**Restoring** a version puts that version's name and document back as the\nComponent's current content. Its folder stays where it is. Nothing is\ndeleted: restoring adds a *new* entry to the history, marked **restored**,\nso you can undo a restore by restoring again. Any unsaved edits on the page\nare discarded when you restore, and the confirmation says so. A restore\ndoes not publish anything. If the restored content differs from what is live\nthe Component reads **Modified** until you publish it; if it matches what is\nlive, it reads Published again.\n\nRestoring needs a permission beyond the one for viewing history (today,\nOwners hold it), and the same edit access on the folder that saving does.\nWithout them the option is shown but disabled, with the reason on hover.\nIt is also unavailable on an inherited Component: its history belongs to the\nenvironment that owns it, so restore it there. Viewing history needs the version-history permission, which Members\nhold; a role you manage that should see history needs it added on the\nRoles page.\n\nTwo things worth knowing before you restore:\n\n- **Referenced items aren't included.** A version remembers this Component's\n  own name and document, not what an item it references looked like at that\n  time. A restored version shows those items as they are today.\n- **A version can become unrestorable.** If it was written against a version\n  of its Contract that no longer exists, or points at content that has since\n  been deleted, restoring explains why and leaves the Component unchanged.\n\nIf someone else saves the Component while you have its history open, a\nrestore is rejected like an ordinary save would be. Reload to see the latest\ncontent, then try again.\n\nPages in the Composer have the same **Version history…** action. Their history\nis read-only for now: you can see what changed and who changed it, but not\nrestore a page.\n\n## Jumping to a field\n\nWhen a Contract has eight or more fields, a **Jump to field** menu appears beside the **Content** and **Settings**\ntabs. Choosing a field scrolls to it and puts the cursor there. A red dot marks a field that needs attention after\na failed save.\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**Records from another app.** A field can take records that another app owns, such as dogs held in\nData, instead of Components. The tree draws them the same way, and the first level (the slots of the\nComponent you are editing) is changed like any other. What is beneath it belongs to the other app, and\nwhat you can do to it is decided by that app, record by record. Where it lets you edit a record, **Edit**\nopens that record in a panel and **Save** saves it **there**, under its own rules (a refusal is shown on the\nfield it names); slots beneath it can be added, changed and removed, and are saved there too. Where it does\nnot, the record is shown but cannot be changed: a slot it has not filled reads *not set*, and **Edit**\nbecomes **Open in** the other app, which opens its own screen for that record in a new tab. If the other app has no screen for a\nrecord, no link is offered. When a slot takes only that app's records, the picker also offers **Create a {record kind} in {app}** (only for a kind you are allowed to create there): it opens that app's own form, starts with the name you typed in the search box, and **Save** makes the record **there** and puts it in the slot. Cancelling makes nothing. A record it cannot return, because it was deleted or because you may not see it, is shown as *Unavailable* and does not stop the page.\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 existing…**/**Create new…** path — both link the same way),\nopen the card's **⋯** menu and select **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\nA linked Component's main button is **Edit** (the layer is titled Quick edit), 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### Making copies of a Component\n\nWhen you need several near-identical records (a litter, a series of events,\nproduct variants), build one and **duplicate** it. Open the Component and\nselect **Duplicate…** next to **Preview…**. The button is there whenever you\ncould create a Component in the same folder, and absent when you couldn't.\n\nChoose a **number of copies** (1 to 25) and a **name**. Each copy is named\nwith a number after it (`Puppy A 1`, `Puppy A 2`, …), and the dialog previews\nthe first three, with their external ids, before you start.\n\n- **Values are copied, references are shared.** A copy gets its own\n  copy of every value in the document. A Component it *references* is not\n  copied: every copy points at the same one, so changing that referenced\n  Component changes it in all of them.\n- **Copies are drafts.** They are not published, and carry none of the\n  original's published state, history, workflow state, or where it is used.\n  They sit in the same folder and use the same Contract as the original.\n- **Copies are made from the saved version.** If you have unsaved edits, the\n  dialog says so; save first if you want them included.\n- **External ids** follow the original's (`puppy-a-copy-1`) and move to the\n  next free number if one is taken, so a batch never fails over a clash.\n\nCopies are created one at a time. If your plan only has room for some of them,\nthe dialog says how many fit and won't start until the number is lowered. If\nsomething goes wrong part-way, it lists which copies exist, which failed and\nwhich were never attempted, and offers **Create the remaining N**, which\ncarries on from where it stopped instead of making extras. If the original no\nlonger matches the latest version of its Contract, nothing is created and the\ndialog names the field to fix first.\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 assistant (open it from the magenta ebitex-mark icon in the header, beside **?**) can see and edit the\nComponent you have open, not only answer questions about it — see **The assistant** 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"
+        "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 existing…** to link to an existing Component (same search box as\n  Reference); or the **Create** menu, whose **Create new…** creates a\n  brand-new Component and links to it in one step (fill in its name,\n  Contract, and any required fields right there), and whose **Write\n  inline…** embeds a value that only ever exists inside this one — pick a\n  Contract and an **Edit** panel slides in, exactly like Nested below. A\n  step with only one possible outcome is skipped: if the Create menu would hold\n  one item, that item is the button; if only one Contract is allowed there is no\n  Contract to pick; and a new inline value opens for editing straight away. If\n  the Contract only allows one of these choices, only that one is offered,\n  and the field says so. Once filled, the value is a card with a **Component** header (and the **✕**\n  that removes it) over its name and\n  kind, one main button (**Edit**, which opens a linked Component in a layer\n  over the page, or the inline value itself), a **⋯** menu holding **Change…** and\n  **Contextual values**, and a **✕** that removes the value. 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. **Choose another** and the **✕**\n  still work 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## Noting which channels a Component is made for\n\nOn a Component's **Settings** tab, **Made for** lets you note that it suits **Email**, **Web**, or\nboth. It is optional and only advises: it never stops you saving or publishing, and a Component with\nno note is \"unknown\". Pages that are noted for a channel warn about Components that say they are not\nmade for it. The **Made for** column in the Components list shows the note. See\n[Building your site in Composer](content-composer.md#made-for).\n\n## Status, and what to do next\n\nUnder the Component's name, one **status strip** says whether it can be published and, if not, why. It also\nholds the next step, so you do not have to hunt for it:\n\n- **Draft**, **Published** or **Modified since it was published**, with one line about the live site\n  (\"The live site shows an older version\").\n- If your organization uses an [editorial workflow](content-workflow.md) for this folder, the strip shows the\n  workflow's state beside the headline. While that state does not allow publishing it reads **Can't be\n  published yet**, and the workflow's next step (for example **Approve**) sits beside it. Choose it, add an\n  optional comment and confirm, all without leaving the Content tab. **Republish…** stays available, but it is\n  no longer the highlighted button; its tooltip gives the reason, and the publish panel explains the block.\n- Once the state allows publishing it reads **Ready to publish** and **Publish…** is highlighted instead.\n- If you have edited since a review was started, the strip says so, and that publishing will use the version\n  that was reviewed.\n- A Component that no longer fits its folder's rules gets a **Move it…** row.\n- If the Component has translations in progress, they are listed here too, with **Review…** for one that is\n  waiting for you.\n\nThe full workflow panel, with its comment box and **Cancel run**, and the complete translations list stay on the\n**Settings** tab. Where the Component is used (**Used in N places**) and whether it is **Inherited** are in the line\nunder the name.\n\n## Version history\n\nEvery time a Component's content is saved, ebitex keeps a copy, so you can\nsee what changed, who changed it, and undo an unwanted edit.\n\nOpen the **More actions** menu near the top of a Component and choose\n**Version history…**. Each entry shows a version number, who saved it and\nwhen. Select an entry to see what changed compared to the version before\nit: the fields that were added, removed or changed, named as you see them\nin the editor. The very first version has nothing to compare against.\n\nSaving the exact same content twice in a row doesn't add an entry: only a\nsave that actually changes something does. Entries can show **Unknown**\ninstead of a name when none was recorded, which is the case for changes\nmade by promotion, import or inheritance rather than by a person typing in\nthe editor. It doesn't mean the person has left your organization.\n\n**Restoring** a version puts that version's name and document back as the\nComponent's current content. Its folder stays where it is. Nothing is\ndeleted: restoring adds a *new* entry to the history, marked **restored**,\nso you can undo a restore by restoring again. Any unsaved edits on the page\nare discarded when you restore, and the confirmation says so. A restore\ndoes not publish anything. If the restored content differs from what is live\nthe Component reads **Modified** until you publish it; if it matches what is\nlive, it reads Published again.\n\nRestoring needs a permission beyond the one for viewing history (today,\nOwners hold it), and the same edit access on the folder that saving does.\nWithout them the option is shown but disabled, with the reason on hover.\nIt is also unavailable on an inherited Component: its history belongs to the\nenvironment that owns it, so restore it there. Viewing history needs the version-history permission, which Members\nhold; a role you manage that should see history needs it added on the\nRoles page.\n\nTwo things worth knowing before you restore:\n\n- **Referenced items aren't included.** A version remembers this Component's\n  own name and document, not what an item it references looked like at that\n  time. A restored version shows those items as they are today.\n- **A version can become unrestorable.** If it was written against a version\n  of its Contract that no longer exists, or points at content that has since\n  been deleted, restoring explains why and leaves the Component unchanged.\n\nIf someone else saves the Component while you have its history open, a\nrestore is rejected like an ordinary save would be. Reload to see the latest\ncontent, then try again.\n\nPages in the Composer have the same **Version history…** action. Their history\nis read-only for now: you can see what changed and who changed it, but not\nrestore a page.\n\n## Jumping to a field\n\nWhen a Contract has eight or more fields, a **Jump to field** menu appears beside the **Content** and **Settings**\ntabs. Choosing a field scrolls to it and puts the cursor there. A red dot marks a field that needs attention after\na failed save.\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**Records from another app.** A field can take records that another app owns, such as dogs held in\nData, instead of Components. The tree draws them the same way, and the first level (the slots of the\nComponent you are editing) is changed like any other. What is beneath it belongs to the other app, and\nwhat you can do to it is decided by that app, record by record. Where it lets you edit a record, **Edit**\nopens that record in a panel and **Save** saves it **there**, under its own rules (a refusal is shown on the\nfield it names); slots beneath it can be added, changed and removed, and are saved there too. Where it does\nnot, the record is shown but cannot be changed: a slot it has not filled reads *not set*, and **Edit**\nbecomes **Open in** the other app, which opens its own screen for that record in a new tab. If the other app has no screen for a\nrecord, no link is offered. When a slot takes only that app's records, the picker also offers **Create a {record kind} in {app}** (only for a kind you are allowed to create there): it opens that app's own form, starts with the name you typed in the search box, and **Save** makes the record **there** and puts it in the slot. Cancelling makes nothing. A record it cannot return, because it was deleted or because you may not see it, is shown as *Unavailable* and does not stop the page.\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 existing…**/**Create new…** path — both link the same way),\nopen the card's **⋯** menu and select **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\nA linked Component's main button is **Edit** (the layer is titled Quick edit), 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### Making copies of a Component\n\nWhen you need several near-identical records (a litter, a series of events,\nproduct variants), build one and **duplicate** it. Open the Component and\nselect **Duplicate…** next to **Preview…**. The button is there whenever you\ncould create a Component in the same folder, and absent when you couldn't.\n\nChoose a **number of copies** (1 to 25) and a **name**. Each copy is named\nwith a number after it (`Puppy A 1`, `Puppy A 2`, …), and the dialog previews\nthe first three, with their external ids, before you start.\n\n- **Values are copied, references are shared.** A copy gets its own\n  copy of every value in the document. A Component it *references* is not\n  copied: every copy points at the same one, so changing that referenced\n  Component changes it in all of them.\n- **Copies are drafts.** They are not published, and carry none of the\n  original's published state, history, workflow state, or where it is used.\n  They sit in the same folder and use the same Contract as the original.\n- **Copies are made from the saved version.** If you have unsaved edits, the\n  dialog says so; save first if you want them included.\n- **External ids** follow the original's (`puppy-a-copy-1`) and move to the\n  next free number if one is taken, so a batch never fails over a clash.\n\nCopies are created one at a time. If your plan only has room for some of them,\nthe dialog says how many fit and won't start until the number is lowered. If\nsomething goes wrong part-way, it lists which copies exist, which failed and\nwhich were never attempted, and offers **Create the remaining N**, which\ncarries on from where it stopped instead of making extras. If the original no\nlonger matches the latest version of its Contract, nothing is created and the\ndialog names the field to fix first.\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 assistant (open it from the magenta ebitex-mark icon in the header, beside **?**) can see and edit the\nComponent you have open, not only answer questions about it — see **The assistant** 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"
     },
     {
         "slug": "content-adapters",
@@ -71,7 +71,7 @@ export const HELP_TOPICS = [
     {
         "slug": "contracts",
         "title": "Modeling content with Contracts",
-        "body": "# Modeling content with Contracts\n\nContracts define the field structure your content adheres to — think of a\nContract as a blueprint (for example \"Article\" or \"Author\") that every\nComponent built from it must follow. You need to belong to an organization to\nuse it — see [Creating an organization and inviting\nteammates](../hub/organizations.md) if you haven't set one up yet.\n\n## The Contracts list\n\n**Modeling > Contracts** lists every Contract with its name, its id (smaller, underneath), whether it is\nconcrete or abstract, which Contract it extends, how many fields it has, what it is used as, and when it\nlast changed.\n\n**What a Contract is used for is worked out from how it is used, never set by hand.** The row of buttons above\nthe list filters by it, with a count on each, and a Contract can sit in several at once:\n\n- **Components** — Components have been created from it.\n- **Experiences** — a Component of this Contract is the content of a page in your Experience tree.\n- **Templates** — it is a Template's own settings Contract. (A Contract a Template merely *supports* is an\n  ordinary content Contract, so it shows under Components, not here.)\n- **Base** — it is abstract, or other Contracts extend it.\n- **Not used yet** — nothing references it. This is the clean-up list.\n\nThe **Used as** column spells it out, for example *Components 17 · Experiences 4*. Search matches a name or an\nid, and **Kind** and **Source** narrow further (a Contract can come from a provider, or be inherited from\nanother environment; both are read-only here and say so).\n\nEach row's **⋯** menu offers **Open** (or **View**, for one you can't edit), **Where used** and **Delete…**.\nDelete is switched off while anything uses the Contract, and says how many places do. Tick several rows to\ndelete them together; it tells you how many of the selection it can actually delete.\n\n## Creating a Contract\n\n1. From the Contracts list, select **New Contract**.\n2. Switch to the **General** tab. Enter a **Name** — everything else below\n   fills in from it, so filling it in first saves retyping. **Id** — a\n   short, URL-safe identifier made of lowercase letters, numbers, and\n   hyphens — fills in from Name automatically; you can still edit it by\n   hand before saving.\n3. Turn on **Abstract** if this Contract exists only to be extended by\n   other Contracts, or to constrain what a field is allowed to point at —\n   an abstract Contract can't be used to create content directly.\n4. Optionally choose a **Parent Contract**. Every field the parent\n   declares is inherited automatically and shown read-only under\n   \"Inherited fields\" on the **Fields** tab — you can't redefine or hide an\n   inherited field, only add new ones of your own.\n   You can also choose **Based on a platform Contract**. A platform Contract is one the product\n   provides (today, **Unlock page**) and always brings its own fields, read-only and first in the list.\n   Base a Contract on **Unlock page** to make its Experiences usable as the page visitors see when they may\n   not read a members-only page (see [Members-only pages](visitor-access.md)). Setting or changing it adds or removes fields,\n   so it can be a breaking change, and you are asked to confirm when it is.\n5. Switch to the **Fields** tab (the default tab). The fields are a list on the left and the\n   selected field's settings are on the right. Select **Add field** and choose a type from the\n   searchable list (each type says what it is for); the new field opens for you to name. Then fill in\n   its Name and Id, change its type with **Change…**, and turn its modifiers on or off (see below).\n   Repeat for every field the Contract needs; drag a row by its handle to reorder it (or, from the\n   keyboard, use the **Move up** and **Move down** buttons on the field, or focus the handle, press\n   Space to pick it up, use the arrow keys to move it, and Space again to drop it), or select\n   **Delete field** to remove one. Fields inherited from a parent are collected under their own\n   heading, collapsed; select one to see its settings, read-only. A row with an unresolved error shows\n   a warning mark, and a failed save selects the first field that needs attention — or, for an error on\n   the General tab (Name, Id, Parent Contract), switches you back to that tab.\n6. A bar at the bottom counts your **unsaved changes** (select it to see each one in words: \"Added the\n   field Heading\", \"Turned on Mandatory for Body\") and says how saving will land. A change that would\n   make existing Components fail validation shows **Breaking change** *before* you save; saving it\n   asks you to confirm and names each reason, because it creates a new *version* (see \"Versions\"\n   below). **Discard** puts every edit back. Select **Save changes** (or **Create Contract** for a new\n   one) — the bar is visible from every tab.\n\n### Asking the assistant to draft one\n\nIf your organization has the assistant turned on, you can describe a Contract instead of building it field\nby field. On the New Contract form, open the assistant (the magenta ebitex-mark icon in the header, beside\n**?**) and ask — for example, \"Create me a Contract for a CTA Banner\". It proposes a Contract as a\n**Suggested** card listing the name and each field with its type. Nothing is saved until you select\n**Accept**, which fills in the form and saves it the same way **Create Contract** does; **Dismiss** discards\nit. Either way you can keep editing afterwards. See [Getting help](../general/getting-help.md).\n\n## Field types and modifiers\n\nEvery field has a **Field type** (Text, Number, Boolean, Date, Link,\nComponent, Blob, Presentation, Rich Text, or Category — Short Text, Long Text,\nURL, Reference, Nested, and Experience Reference are deprecated and no longer\noffered for new fields, though any field already using one keeps working\nunchanged; see \"Text fields\" and \"Component fields\" below) plus up to five\nindependent modifiers, each shown as a toggle whose label changes with\nits state:\n\n- **Mandatory / Optional** — required, or not. For a Contextual field,\n  this only applies where the field is actually used, not on the\n  Component itself (see \"Contextual fields\" in\n  [Authoring Components](components.md)).\n- **Multiple / Single** — a list of values instead of one.\n- **Localized / Same in every locale** — a default value plus per-locale\n  overrides.\n- **Contextual / On the Component** — the value lives where the field is\n  *used*, not on the Component that declares it — useful for something\n  like a \"theme\" that should vary by where content is placed, not by the\n  content itself.\n- **Personalized / Same for every audience** — audience-conditioned\n  variant alternatives — see\n  [Personalizing content by audience](content-personalization.md).\n\nSome field types add an extra toggle of their own alongside these five —\nfor example, Text and Rich Text both show an **Allow\ntoken injection** toggle, since it's specific to text-bearing fields\nrather than something every field type needs.\n\nEach field type has its own extra settings, shown once you pick a type —\nfor example, Text has an optional pattern plus\nlength limits, all grouped together under **Validation** (a label you\nselect to expand, staying expanded automatically whenever something\ninside still needs your attention), Component lets you restrict which\nContracts are allowed (and, optionally, which of the two modes below), and\nBlob lets you restrict file types and maximum size.\n\n### Date fields\n\nA **Date** field has one extra setting, **Include time** — off shows and\nedits just a calendar date; on adds a time of day too. Either way, the\ndate/time you enter is shown in your own local time zone, and switching\nthis setting on or off later is a normal (additive) change, not something\nthat requires a new version.\n\n### Text fields\n\n**Text** is the one plain-text type. Turn on **Multiple lines** in its\nsettings and the editor becomes a larger box that keeps line breaks;\nleave it off for a single line such as a title. Either way the stored\nvalue is the same plain string, so switching the setting later never\nchanges or loses anything already written.\n\n**Short Text** and **Long Text** are the two types Text replaces. A field\nthat already uses one keeps working, but a new field cannot take it. To\nmove an existing field over, open it and choose **Convert to Text**: its\nsettings carry over unchanged (a Long Text field also becomes **Multiple\nlines**), every value already written is kept as it is, and the change\ndoes not by itself create a new Contract version.\n\n### Restricting a field to a fixed list of values\n\nText, Number, and Date fields can be restricted to a\nfixed set of **Allowed values** in their settings — useful for something\nlike a status field that should only ever be \"Draft,\" \"In review,\" or\n\"Published,\" rather than any free-text string. Leave it empty to allow\nany value.\n\nHow the field is edited then depends on whether it also allows multiple\nvalues and how many options you listed: a small list of single-value\noptions shows as buttons to pick one of; a longer list shows as a\ndropdown; combined with **Multiple**, a small list shows as checkboxes and\na longer one as a searchable picker. Narrowing this list later (removing a\nvalue that was previously allowed) is a breaking change, since an\nexisting Component might already hold it; adding a new value is additive.\n\n### Picking options from another system\n\nInstead of typing a fixed list of Allowed values, a Text field can\nname a **Choice source** — an activated plugin that supplies the option\nlist live, kept automatically in sync with whatever it's connected to.\nThe first one, **ebitex Forms**, lists your organization's own published\nForms, so you can pick a form by name rather than typing its id — useful\nfor a field like \"which form should appear on this page.\" A field can use\neither Allowed values or a Choice source, never both.\n\nOnce a Choice source plugin is activated (in your organization's Settings)\nand picked in a field's settings, editing a Component with that field\nlooks exactly like a normal fixed-list field: buttons, a dropdown,\ncheckboxes, or a searchable picker, depending on how many options there\nare. If the source is temporarily unavailable — a misconfigured\nconnection, for example — you'll see a short message explaining that, and\nthe field falls back to a plain text box so you can still see and edit\nwhatever value is already saved; nothing else on the page is blocked from\nsaving while that happens.\n\n### Giving a field a default value\n\nMost field types — anything other than Component, Presentation, Rich\nText, and Category, which all point at other content rather than holding\na plain value — can be given a **Default value** in their expanded row.\nOnce set, every brand-new Component created from this Contract starts\nwith that value already filled in, instead of empty; editing or clearing\nthe default afterward never changes a Component that already exists. For a\nContextual field, its default becomes the Component's own fallback value —\nused whenever a specific placement doesn't override it.\n\n## Component fields\n\nA **Component** field holds a reference to another Component, an inline\n(embedded) value, or either — decided by whoever is *filling in* the field,\nnot fixed when you design the Contract:\n\n- **Linked** — points at another Component elsewhere in your organization;\n  the two stay separate, and deleting a Component that's linked elsewhere\n  is blocked until the link is removed first. Covers both picking an\n  existing Component and creating a brand-new one to link to.\n- **Inline** — embeds another Component's content directly inside; there's\n  no separate entity to manage, it's just part of the same document. Best\n  for content that only ever makes sense as part of its parent (for\n  example, an article's author details).\n\nIf you want to guarantee only one of these for a given field — say, a\n\"related articles\" field that should always link to a reusable Component,\nnever an inline one-off — the field's settings offer **Allowed value\nmodes**, a checklist of the two options above (at least one must stay\nchecked). Leaving both checked (the default) lets whoever fills in the\nfield choose either way each time. Either way, **allowedContractIds** lets\nyou restrict which Contracts are allowed. The list has three states, and the\nbuilder says which one it is in: **Any Contract** (nothing set, so any Contract,\nincluding descendants of one you do list), a list of Contracts (exactly those),\nand **Nothing allowed** (an empty list: no Contract can be chosen). **Allow any**\nclears the list back to the first state, **Allow none** empties it, and removing\nthe last Contract from a list leaves **Nothing allowed** rather than silently\nallowing everything. The same three states apply to every allow-list in a\nfield's settings (Templates, category groups, link kinds and protocols, inline\nembed kinds, markdown features and content types). Value modes are the exception:\na field must allow at least one, so that list can be left out but never emptied.\n\nExisting Contracts may still have the older, separate **Reference** and\n**Nested** field types — a Reference field is equivalent to a Component\nfield restricted to Linked only, and a Nested field to one restricted to\nInline only. They keep working exactly as before; a new field just uses\nComponent instead.\n\n## Giving a Contract a title field\n\nContent built from a Contract needs a human label — the name shown in a site's\nnavigation menu, in a breadcrumb trail, and beside each item in a listing.\n**Title field** on the **General** tab is where you choose which field that\nlabel comes from.\n\nIt is a picker, not something you type. Choose a field; if the field you chose\nholds a nested block, a second dropdown appears so you can choose the field\ninside it — up to four levels deep. Only fields a title can actually come from\nare offered: text fields as the final choice, and nested blocks as the steps in\nbetween.\n\n**Set it once, on the most general Contract that has the field.** The choice is\ninherited, so if your \"Web page\" Contract declares its `title` field, every\nContract that extends it — Article, Landing page, and so on — uses the same one\nwith nothing more to set up. A Contract that needs a different field can choose\nits own, which takes over. When a Contract inherits its title field, the picker\nshows it read-only and names the Contract it came from, with **Override** to\nchoose a different one and **Clear** to remove it.\n\nA few notes on what to expect:\n\n- **It applies from the next publish.** Choosing a title field doesn't change\n  anything already published — each Component picks it up when it is next\n  published.\n- **Editing the title text is a Component publish.** Change the wording and\n  republish that Component, and its label updates everywhere it appears. You do\n  not need to republish the pages that use it.\n- **If it can't be resolved, the page's own name is used instead** — its\n  internal name from Composer. That happens when no Contract in the chain\n  declares a title field, when the field named no longer exists, or when the\n  content isn't published. Nothing breaks; you just see the internal name, which\n  is a good hint that the title field needs attention.\n- **A localizable title field is worth choosing.** One value covers every\n  locale, and each visitor sees theirs.\n\nIf the same piece of content appears in more than one place and should be named\ndifferently at each, make the title field **contextual** — then each page that\nuses it supplies its own wording. Bear in mind that a contextual title belongs to\nthe page, so changing it means republishing that page rather than the content.\n\n## Editing fields as a tree\n\nSome content refers to more of the same kind of content: a dog has a sire and a\ndam who are dogs too, a product is built from parts that are products, a person\nreports to a person. Building that with one picker per field means creating the\nfurthest ancestor first and working back towards the one you actually wanted.\n\n**Editing layout**, pinned under the fields on the **Fields** tab, changes that. Choose\n**Edit as a tree** and the Component editor draws those fields as one tree, where you fill in any\nslot directly. It only changes how the fields are edited. The fields, their validation and what is\npublished are exactly as before, and it creates no new Contract version, so a change to just the\nlayout is saved without a version bump. A preview beside the settings draws the chart or outline you\nhave chosen, using your own field names, and the fields in the tree carry an **In tree** chip.\nRenaming a field in the tree updates the layout, and removing it, or changing it to a type a tree\ncan't use, takes it out of the layout.\n\nTo set it up:\n\n1. Give the Contract the fields that point at itself: two or more single-value\n   Component fields (a sire and a dam), or one list field (parts). Each should\n   allow the Contract, or a Contract that extends it.\n2. On **Fields**, select **Editing layout**, then choose **Edit as a tree**.\n3. Tick the fields that make up the tree and choose how many generations (or\n   levels) to show.\n4. Choose whether the same Component may appear more than once.\n\n**Repeats.** *Allow across branches* lets one Component sit in several places, as\nin line-breeding or a part used in two assemblies. *Never* means each Component\nmay appear once in the whole tree, which suits an org chart or a taxonomy. If\nyou switch to *Never* on content that already repeats, the repeats are kept and\nnothing is rewritten; only a new repeat is refused. Either way, something can\nnever contain itself.\n\n**Inheritance.** Like the title field, the choice is inherited. Set it once on the\ngeneral Contract (a \"Pedigree dog\") and every Contract that extends it, such as\n\"Dog\" and \"Bitch\", edits as a tree. A Contract can choose its own, or choose\n*Ordinary fields (do not inherit the tree)* to opt out.\n\nIf the fields you tick no longer exist or no longer fit, the editor simply shows\nthe ordinary fields, so a Contract is never left uneditable.\n\n## Links to your site\n\nA Component has no page of its own, so nothing in Content takes you from a\nComponent to the page on your site that shows it. **External links** on the\n**General** tab adds that. Each link is a button in the Component editor that\nopens the page for the Component you are looking at, for example a dog's\nprintable pedigree or a blog post on the live site.\n\nTo add one:\n\n1. On **General**, under **External links**, choose **Declare links**.\n2. Give the link a **Label**, the words on the button.\n3. Write the **URL template**. It starts with `{origin}`, `https://` or\n   `http://`, and can use the Component's own details:\n   - `{id}` and `{externalId}`: the Component's id and external id.\n   - `{field:name}`: the value of one of its fields. A field inside an inline\n     value is written with dots, such as `{field:owner.name}`.\n   - `{key:sire}`: the **key** of the record a reference field points at, for\n     a page that is addressed by that key. A litter can link to a pedigree\n     page with `{origin}/pedigree?sire={key:sire}&dam={key:dam}`. A reference\n     with nothing chosen, or a value written in by hand rather than chosen\n     from the records, leaves its place empty, so a litter with an outside dam\n     still links; the link is switched off only when none of the `{key:}`\n     fields has a value.\n   - `{origin}`: the address of the **Site** you choose, always followed by a\n     `/`. It is how one Contract can point at the right host in every\n     environment.\n4. Choose the **Site** (when you used `{origin}`) and whether the link is\n   **Enabled** always or **Once published**.\n\nA live example under the form shows the link built from one of this Contract's\nown Components, so you can see it before you save. You can add up to five links.\n\n**What authors see.** A link that works opens in a new tab. A link that cannot\nwork is greyed and says why beside it: *Publish this Component first* for a\ndraft, *Needs a value for \"name\"* when a field it uses is empty, or that the Site\nhas no host yet. A Component with unpublished changes still has a live page, so\nits link works and says it shows the published version.\n\n**Safe by design.** A value from a field can never change where a link points:\nvalues are encoded into one part of the address, and the template's scheme and\nhost cannot use fields at all.\n\n**Nothing else changes.** Links are only shown in the editor. They create no new\nContract version, change no Component and appear in nothing your site receives.\nLike the tree, they are inherited: a Contract can declare its own, or choose\n*No links (do not inherit)*.\n\n## Versions\n\nEvery save is classified automatically:\n\n- **Additive** changes (adding an optional field, loosening a limit, …)\n  update the Contract's current version in place.\n- **Breaking** changes (removing a field, adding a *mandatory* field,\n  tightening a limit, …) create a new version, leaving the old one intact\n  so Components already pinned to it keep working.\n\nThe **History** tab on a Contract's page lists every version and\nwhat fields it resolved to. Existing Components aren't forced to update\nwhen a Contract changes — see \"The upgrade badge\" in\n[Authoring Components](components.md) for how that friction is surfaced\nand resolved.\n"
+        "body": "# Modeling content with Contracts\n\nContracts define the field structure your content adheres to — think of a\nContract as a blueprint (for example \"Article\" or \"Author\") that every\nComponent built from it must follow. You need to belong to an organization to\nuse it — see [Creating an organization and inviting\nteammates](../hub/organizations.md) if you haven't set one up yet.\n\n## The Contracts list\n\n**Modeling > Contracts** lists every Contract with its name, its id (smaller, underneath), whether it is\nconcrete or abstract, which Contract it extends, how many fields it has, what it is used as, and when it\nlast changed.\n\n**What a Contract is used for is worked out from how it is used, never set by hand.** The row of buttons above\nthe list filters by it, with a count on each, and a Contract can sit in several at once:\n\n- **Components** — Components have been created from it.\n- **Experiences** — a Component of this Contract is the content of a page in your Experience tree.\n- **Templates** — it is a Template's own settings Contract. (A Contract a Template merely *supports* is an\n  ordinary content Contract, so it shows under Components, not here.)\n- **Base** — it is abstract, or other Contracts extend it.\n- **Not used yet** — nothing references it. This is the clean-up list.\n\nThe **Used as** column spells it out, for example *Components 17 · Experiences 4*. Search matches a name or an\nid, and **Kind** and **Source** narrow further (a Contract can come from a provider, or be inherited from\nanother environment; both are read-only here and say so).\n\nEach row's **⋯** menu offers **Open** (or **View**, for one you can't edit), **Where used** and **Delete…**.\nDelete is switched off while anything uses the Contract, and says how many places do. Tick several rows to\ndelete them together; it tells you how many of the selection it can actually delete.\n\n## Creating a Contract\n\n1. From the Contracts list, select **New Contract**.\n2. Switch to the **General** tab. Enter a **Name** — everything else below\n   fills in from it, so filling it in first saves retyping. **Id** — a\n   short, URL-safe identifier made of lowercase letters, numbers, and\n   hyphens — fills in from Name automatically; you can still edit it by\n   hand before saving.\n3. Turn on **Abstract** if this Contract exists only to be extended by\n   other Contracts, or to constrain what a field is allowed to point at —\n   an abstract Contract can't be used to create content directly.\n4. Optionally choose a **Parent Contract**. Every field the parent\n   declares is inherited automatically and shown read-only under\n   \"Inherited fields\" on the **Fields** tab — you can't redefine or hide an\n   inherited field, only add new ones of your own.\n   You can also choose **Based on a platform Contract**. A platform Contract is one the product\n   provides (today, **Unlock page**) and always brings its own fields, read-only and first in the list.\n   Base a Contract on **Unlock page** to make its Experiences usable as the page visitors see when they may\n   not read a members-only page (see [Members-only pages](visitor-access.md)). Setting or changing it adds or removes fields,\n   so it can be a breaking change, and you are asked to confirm when it is.\n5. Switch to the **Fields** tab (the default tab). The fields are a list on the left and the\n   selected field's settings are on the right. Select **Add field** and choose a type from the\n   searchable list (each type says what it is for); the new field opens for you to name. Then fill in\n   its Name and Id, change its type with **Change…**, and turn its modifiers on or off (see below).\n   Repeat for every field the Contract needs; drag a row by its handle to reorder it (or, from the\n   keyboard, use the **Move up** and **Move down** buttons on the field, or focus the handle, press\n   Space to pick it up, use the arrow keys to move it, and Space again to drop it), or select\n   **Delete field** to remove one. Fields inherited from a parent are collected under their own\n   heading, collapsed; select one to see its settings, read-only. A row with an unresolved error shows\n   a warning mark, and a failed save selects the first field that needs attention — or, for an error on\n   the General tab (Name, Id, Parent Contract), switches you back to that tab.\n6. A bar at the bottom counts your **unsaved changes** (select it to see each one in words: \"Added the\n   field Heading\", \"Turned on Mandatory for Body\") and says how saving will land. A change that would\n   make existing Components fail validation shows **Breaking change** *before* you save; saving it\n   asks you to confirm and names each reason, because it creates a new *version* (see \"Versions\"\n   below). **Discard** puts every edit back. Select **Save changes** (or **Create Contract** for a new\n   one) — the bar is visible from every tab.\n\n### Asking the assistant to draft one\n\nIf your organization has the assistant turned on, you can describe a Contract instead of building it field\nby field. On the New Contract form, open the assistant (the magenta ebitex-mark icon in the header, beside\n**?**) and ask — for example, \"Create me a Contract for a CTA Banner\". It proposes a Contract as a\n**Suggested** card listing the name and each field with its type. Nothing is saved until you select\n**Accept**, which fills in the form and saves it the same way **Create Contract** does; **Dismiss** discards\nit. Either way you can keep editing afterwards. See [Getting help](../general/getting-help.md).\n\n## Field types and modifiers\n\nEvery field has a **Field type** (Text, Number, Boolean, Date, Link,\nComponent, Blob, Presentation, Rich Text, or Category — Short Text, Long Text,\nURL, Reference, Nested, and Experience Reference are deprecated and no longer\noffered for new fields, though any field already using one keeps working\nunchanged; see \"Text fields\" and \"Component fields\" below) plus up to five\nindependent modifiers, each shown as a toggle whose label changes with\nits state:\n\n- **Mandatory / Optional** — required, or not. For a Contextual field,\n  this only applies where the field is actually used, not on the\n  Component itself (see \"Contextual fields\" in\n  [Authoring Components](components.md)).\n- **Multiple / Single** — a list of values instead of one.\n- **Localized / Same in every locale** — a default value plus per-locale\n  overrides.\n- **Contextual / On the Component** — the value lives where the field is\n  *used*, not on the Component that declares it — useful for something\n  like a \"theme\" that should vary by where content is placed, not by the\n  content itself.\n- **Personalized / Same for every audience** — audience-conditioned\n  variant alternatives — see\n  [Personalizing content by audience](content-personalization.md).\n\nSome field types add an extra toggle of their own alongside these five —\nfor example, Text and Rich Text both show an **Allow\ntoken injection** toggle, since it's specific to text-bearing fields\nrather than something every field type needs.\n\nEach field type has its own extra settings, shown once you pick a type —\nfor example, Text has an optional pattern plus\nlength limits, all grouped together under **Validation** (a label you\nselect to expand, staying expanded automatically whenever something\ninside still needs your attention), Component lets you restrict which\nContracts are allowed (and, optionally, which of the two modes below), and\nBlob lets you restrict file types and maximum size.\n\n### Date fields\n\nA **Date** field has a **Kind of value**, which decides what it stores:\n\n- **Instant (a moment in time)** is the default. It stores one exact moment.\n  Its **Include time** setting is off to show and edit just a calendar date, or\n  on to add a time of day. The date or time you enter is shown in your own\n  local time zone, and switching **Include time** later is a normal (additive)\n  change, not something that requires a new version.\n- **Calendar date (no time zone)** stores a day such as `2026-12-25`, for a\n  birthday, an anniversary or a \"valid from\" date. It means the same day\n  everywhere.\n- **Time of day (no time zone)** stores a clock time such as `16:00`, for\n  opening hours or a doors-open time. It means the same time wherever the\n  viewer is, so keep the place's own time zone in a separate field if it\n  matters. A time that is after midnight, such as closing at 2 AM, is stored as\n  `02:00`; the model that uses it decides it means the next morning.\n\nThe editor shows a date picker for a calendar date and a time picker for a time\nof day. Changing the **Kind of value** of a field that already has values\nchanges the shape of what is stored, so it is a breaking change: ebitex asks you\nto save a new version, and existing values are not converted.\n\n### Text fields\n\n**Text** is the one plain-text type. Turn on **Multiple lines** in its\nsettings and the editor becomes a larger box that keeps line breaks;\nleave it off for a single line such as a title. Either way the stored\nvalue is the same plain string, so switching the setting later never\nchanges or loses anything already written.\n\n**Short Text** and **Long Text** are the two types Text replaces. A field\nthat already uses one keeps working, but a new field cannot take it. To\nmove an existing field over, open it and choose **Convert to Text**: its\nsettings carry over unchanged (a Long Text field also becomes **Multiple\nlines**), every value already written is kept as it is, and the change\ndoes not by itself create a new Contract version.\n\n### Restricting a field to a fixed list of values\n\nText, Number, and Date fields can be restricted to a\nfixed set of **Allowed values** in their settings — useful for something\nlike a status field that should only ever be \"Draft,\" \"In review,\" or\n\"Published,\" rather than any free-text string. Leave it empty to allow\nany value.\n\nHow the field is edited then depends on whether it also allows multiple\nvalues and how many options you listed: a small list of single-value\noptions shows as buttons to pick one of; a longer list shows as a\ndropdown; combined with **Multiple**, a small list shows as checkboxes and\na longer one as a searchable picker. Narrowing this list later (removing a\nvalue that was previously allowed) is a breaking change, since an\nexisting Component might already hold it; adding a new value is additive.\n\n### Picking options from another system\n\nInstead of typing a fixed list of Allowed values, a Text field can\nname a **Choice source** — an activated plugin that supplies the option\nlist live, kept automatically in sync with whatever it's connected to.\nThe first one, **ebitex Forms**, lists your organization's own published\nForms, so you can pick a form by name rather than typing its id — useful\nfor a field like \"which form should appear on this page.\" A field can use\neither Allowed values or a Choice source, never both.\n\nOnce a Choice source plugin is activated (in your organization's Settings)\nand picked in a field's settings, editing a Component with that field\nlooks exactly like a normal fixed-list field: buttons, a dropdown,\ncheckboxes, or a searchable picker, depending on how many options there\nare. If the source is temporarily unavailable — a misconfigured\nconnection, for example — you'll see a short message explaining that, and\nthe field falls back to a plain text box so you can still see and edit\nwhatever value is already saved; nothing else on the page is blocked from\nsaving while that happens.\n\n### Giving a field a default value\n\nMost field types — anything other than Component, Presentation, Rich\nText, and Category, which all point at other content rather than holding\na plain value — can be given a **Default value** in their expanded row.\nOnce set, every brand-new Component created from this Contract starts\nwith that value already filled in, instead of empty; editing or clearing\nthe default afterward never changes a Component that already exists. For a\nContextual field, its default becomes the Component's own fallback value —\nused whenever a specific placement doesn't override it.\n\n## Component fields\n\nA **Component** field holds a reference to another Component, an inline\n(embedded) value, or either — decided by whoever is *filling in* the field,\nnot fixed when you design the Contract:\n\n- **Linked** — points at another Component elsewhere in your organization;\n  the two stay separate, and deleting a Component that's linked elsewhere\n  is blocked until the link is removed first. Covers both picking an\n  existing Component and creating a brand-new one to link to.\n- **Inline** — embeds another Component's content directly inside; there's\n  no separate entity to manage, it's just part of the same document. Best\n  for content that only ever makes sense as part of its parent (for\n  example, an article's author details).\n\nIf you want to guarantee only one of these for a given field — say, a\n\"related articles\" field that should always link to a reusable Component,\nnever an inline one-off — the field's settings offer **Allowed value\nmodes**, a checklist of the two options above (at least one must stay\nchecked). Leaving both checked (the default) lets whoever fills in the\nfield choose either way each time. Either way, **allowedContractIds** lets\nyou restrict which Contracts are allowed. The list has three states, and the\nbuilder says which one it is in: **Any Contract** (nothing set, so any Contract,\nincluding descendants of one you do list), a list of Contracts (exactly those),\nand **Nothing allowed** (an empty list: no Contract can be chosen). **Allow any**\nclears the list back to the first state, **Allow none** empties it, and removing\nthe last Contract from a list leaves **Nothing allowed** rather than silently\nallowing everything. The same three states apply to every allow-list in a\nfield's settings (Templates, category groups, link kinds and protocols, inline\nembed kinds, markdown features and content types). Value modes are the exception:\na field must allow at least one, so that list can be left out but never emptied.\n\nExisting Contracts may still have the older, separate **Reference** and\n**Nested** field types — a Reference field is equivalent to a Component\nfield restricted to Linked only, and a Nested field to one restricted to\nInline only. They keep working exactly as before; a new field just uses\nComponent instead.\n\n## Giving a Contract a title field\n\nContent built from a Contract needs a human label — the name shown in a site's\nnavigation menu, in a breadcrumb trail, and beside each item in a listing.\n**Title field** on the **General** tab is where you choose which field that\nlabel comes from.\n\nIt is a picker, not something you type. Choose a field; if the field you chose\nholds a nested block, a second dropdown appears so you can choose the field\ninside it — up to four levels deep. Only fields a title can actually come from\nare offered: text fields as the final choice, and nested blocks as the steps in\nbetween.\n\n**Set it once, on the most general Contract that has the field.** The choice is\ninherited, so if your \"Web page\" Contract declares its `title` field, every\nContract that extends it — Article, Landing page, and so on — uses the same one\nwith nothing more to set up. A Contract that needs a different field can choose\nits own, which takes over. When a Contract inherits its title field, the picker\nshows it read-only and names the Contract it came from, with **Override** to\nchoose a different one and **Clear** to remove it.\n\nA few notes on what to expect:\n\n- **It applies from the next publish.** Choosing a title field doesn't change\n  anything already published — each Component picks it up when it is next\n  published.\n- **Editing the title text is a Component publish.** Change the wording and\n  republish that Component, and its label updates everywhere it appears. You do\n  not need to republish the pages that use it.\n- **If it can't be resolved, the page's own name is used instead** — its\n  internal name from Composer. That happens when no Contract in the chain\n  declares a title field, when the field named no longer exists, or when the\n  content isn't published. Nothing breaks; you just see the internal name, which\n  is a good hint that the title field needs attention.\n- **A localizable title field is worth choosing.** One value covers every\n  locale, and each visitor sees theirs.\n\nIf the same piece of content appears in more than one place and should be named\ndifferently at each, make the title field **contextual** — then each page that\nuses it supplies its own wording. Bear in mind that a contextual title belongs to\nthe page, so changing it means republishing that page rather than the content.\n\n## Editing fields as a tree\n\nSome content refers to more of the same kind of content: a dog has a sire and a\ndam who are dogs too, a product is built from parts that are products, a person\nreports to a person. Building that with one picker per field means creating the\nfurthest ancestor first and working back towards the one you actually wanted.\n\n**Editing layout**, pinned under the fields on the **Fields** tab, changes that. Choose\n**Edit as a tree** and the Component editor draws those fields as one tree, where you fill in any\nslot directly. It only changes how the fields are edited. The fields, their validation and what is\npublished are exactly as before, and it creates no new Contract version, so a change to just the\nlayout is saved without a version bump. A preview beside the settings draws the chart or outline you\nhave chosen, using your own field names, and the fields in the tree carry an **In tree** chip.\nRenaming a field in the tree updates the layout, and removing it, or changing it to a type a tree\ncan't use, takes it out of the layout.\n\nTo set it up:\n\n1. Give the Contract the fields that point at itself: two or more single-value\n   Component fields (a sire and a dam), or one list field (parts). Each should\n   allow the Contract, or a Contract that extends it.\n2. On **Fields**, select **Editing layout**, then choose **Edit as a tree**.\n3. Tick the fields that make up the tree and choose how many generations (or\n   levels) to show.\n4. Choose whether the same Component may appear more than once.\n\n**Repeats.** *Allow across branches* lets one Component sit in several places, as\nin line-breeding or a part used in two assemblies. *Never* means each Component\nmay appear once in the whole tree, which suits an org chart or a taxonomy. If\nyou switch to *Never* on content that already repeats, the repeats are kept and\nnothing is rewritten; only a new repeat is refused. Either way, something can\nnever contain itself.\n\n**Inheritance.** Like the title field, the choice is inherited. Set it once on the\ngeneral Contract (a \"Pedigree dog\") and every Contract that extends it, such as\n\"Dog\" and \"Bitch\", edits as a tree. A Contract can choose its own, or choose\n*Ordinary fields (do not inherit the tree)* to opt out.\n\nIf the fields you tick no longer exist or no longer fit, the editor simply shows\nthe ordinary fields, so a Contract is never left uneditable.\n\n## Links to your site\n\nA Component has no page of its own, so nothing in Content takes you from a\nComponent to the page on your site that shows it. **External links** on the\n**General** tab adds that. Each link is a button in the Component editor that\nopens the page for the Component you are looking at, for example a dog's\nprintable pedigree or a blog post on the live site.\n\nTo add one:\n\n1. On **General**, under **External links**, choose **Declare links**.\n2. Give the link a **Label**, the words on the button.\n3. Write the **URL template**. It starts with `{origin}`, `https://` or\n   `http://`, and can use the Component's own details:\n   - `{id}` and `{externalId}`: the Component's id and external id.\n   - `{field:name}`: the value of one of its fields. A field inside an inline\n     value is written with dots, such as `{field:owner.name}`.\n   - `{key:sire}`: the **key** of the record a reference field points at, for\n     a page that is addressed by that key. A litter can link to a pedigree\n     page with `{origin}/pedigree?sire={key:sire}&dam={key:dam}`. A reference\n     with nothing chosen, or a value written in by hand rather than chosen\n     from the records, leaves its place empty, so a litter with an outside dam\n     still links; the link is switched off only when none of the `{key:}`\n     fields has a value.\n   - `{origin}`: the address of the **Site** you choose, always followed by a\n     `/`. It is how one Contract can point at the right host in every\n     environment.\n4. Choose the **Site** (when you used `{origin}`) and whether the link is\n   **Enabled** always or **Once published**.\n\nA live example under the form shows the link built from one of this Contract's\nown Components, so you can see it before you save. You can add up to five links.\n\n**What authors see.** A link that works opens in a new tab. A link that cannot\nwork is greyed and says why beside it: *Publish this Component first* for a\ndraft, *Needs a value for \"name\"* when a field it uses is empty, or that the Site\nhas no host yet. A Component with unpublished changes still has a live page, so\nits link works and says it shows the published version.\n\n**Safe by design.** A value from a field can never change where a link points:\nvalues are encoded into one part of the address, and the template's scheme and\nhost cannot use fields at all.\n\n**Nothing else changes.** Links are only shown in the editor. They create no new\nContract version, change no Component and appear in nothing your site receives.\nLike the tree, they are inherited: a Contract can declare its own, or choose\n*No links (do not inherit)*.\n\n## Versions\n\nEvery save is classified automatically:\n\n- **Additive** changes (adding an optional field, loosening a limit, …)\n  update the Contract's current version in place.\n- **Breaking** changes (removing a field, adding a *mandatory* field,\n  tightening a limit, …) create a new version, leaving the old one intact\n  so Components already pinned to it keep working.\n\nThe **History** tab on a Contract's page lists every version and\nwhat fields it resolved to. Existing Components aren't forced to update\nwhen a Contract changes — see \"The upgrade badge\" in\n[Authoring Components](components.md) for how that friction is surfaced\nand resolved.\n"
     },
     {
         "slug": "deployment-keys",

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

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

package/package.json

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