@ebitex/content-mcp 0.5.131 → 0.5.132
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
|
@@ -16,7 +16,7 @@ export const HELP_TOPICS = [
|
|
|
16
16
|
{
|
|
17
17
|
"slug": "components",
|
|
18
18
|
"title": "Authoring Components",
|
|
19
|
-
"body": "# Authoring Components\n\nA Component is one piece of content built from a Contract — for example,\na specific article. This guide covers creating and editing Components,\norganizing them in folders, and the friction the app shows you when a\nContract changes underneath a Component you've already created. See\n[Modeling content with Contracts](contracts.md) first if you haven't\ncreated a Contract yet.\n\n## Creating a Component\n\n1. From the Content page, select **New Component** (optionally after\n opening the folder you want it created in).\n2. Enter a **Name** — the **Id** fills in from it automatically and can\n still be edited by hand.\n3. Choose a **Contract**. If you started from a specific folder that\n restricts which Contracts are allowed there, only those (and their\n descendants) are offered.\n4. Fill in the form that appears — every field from the Contract, laid\n out in order. Fields marked with a red **\\*** are required.\n5. Select **Create**. If a required field is missing or a value doesn't\n match the Contract's rules, the field is highlighted with an\n explanation — fix it and select **Create** again.\n\n## Filling in fields\n\nMost fields are a straightforward text box, number box, or checkbox.\nA few work differently:\n\n- **Reference** and **Nested** are older field types kept working for\n existing Contracts, but no longer offered when adding a new field — new\n Contracts should use **Component** instead (below), which offers the\n same two behaviors plus a third, chosen per value instead of committed\n to for the whole field.\n- **Component** fields ask you to choose, each time you fill one in:\n **Choose…** to link to an existing Component (same search box as\n Reference, with **Change**/**Remove** once chosen); **Create new…** to\n create a brand-new Component and link to it in one step (fill in its\n name, Contract, and any required fields right there); or **Create\n inline…** to embed a value that only ever exists inside this one — pick\n a Contract and an **Edit** panel slides in, exactly like Nested below.\n If the Contract only allows one of these choices, only that one is\n offered. If a linked Component can't be found — most often because it\n was skipped during a promotion into this environment (see\n [content-environments.md](content-environments.md)'s \"Unresolved\n references\" section) — you'll see a distinct **Unresolved** badge\n instead of the usual resolved name, with a link to Component Sync to\n see the full picture and fix it. **Change**/**Remove** still work\n normally on an unresolved value.\n- **Blob** fields (images and other files) show an **Upload** button.\n Once uploaded, you'll see a preview (for images) and a link to download\n the file, plus a **Replace** button.\n- **Nested** fields show a small **Edit** panel once a Contract is chosen\n for them (automatically, if only one is allowed for that field, or via a\n picker if more than one is allowed) — selecting **Edit** opens the\n nested content in its own panel, sliding in over the current one. Any\n unsaved changes you've made — at every level — are kept even if you\n drill several levels deep and back out again; nothing is lost until you\n actually leave the page without saving. A Component field's own **Create\n inline…** choice opens the identical panel.\n- Fields marked **Localizable** always show a small translations icon next\n to their label — select it to add per-locale overrides alongside the\n default value. It's disabled (with an explanation on hover) until your\n organization has a language configured under **Localization** settings\n with at least one language added under it to translate into; once one\n exists, the icon becomes selectable. This works the same way for every\n field type, including Blob, Reference, Nested, Component, and\n Presentation fields: each locale gets its own independent\n **Upload**/**Edit**/**Choose…** affordance, so a Nested value's translated\n content — or a different linked Component or uploaded file per locale —\n is fully separate from the default. The default-locale row in the\n translations panel is always read-only (a reflection of the default\n value, not a second copy of it); translate from the other locale rows.\n- **Presentation** fields let you instantiate a Template inline — pick a\n Template, bind it to a Component, and set contextual values and settings\n for this specific placement. See\n [Presenting content with Templates](templates.md) for the full flow.\n\n## 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**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.\n\n## Contextual defaults\n\nFields marked Contextual on the Contract appear in a separate\n**\"Defaults for usage sites\"** section, clearly labeled optional — even if\nthe Contract also marks them Mandatory. That's intentional: a Contextual\nfield's real value is supplied wherever the content is *used*, not here;\nwhat you set in this section is only a fallback for places that don't\nsupply their own value.\n\n### Setting per-usage values on a Reference\n\nWhen you link to another Component via a Reference field (or a Component\nfield's **Choose…**/**Create new…** path — both link the same way), select\n**Contextual values** to open a panel listing that target's own Contextual\nfields, each with three distinct states you can switch between:\n\n- **Inheriting the Component's default** — nothing set here; the linked\n Component's own default value is used.\n- **Overridden** — set a value here to use instead of the default, just\n for this one link. This works for every field type the target Contract\n declares as Contextual, not just simple text/number/checkbox fields — a\n Contextual Reference field gets the same **Choose…** picker, a Contextual\n Blob field the same **Upload** button, and a Contextual Nested field the\n same drill-in **Edit** panel you'd see editing that field directly on a\n Component.\n- **Explicitly cleared** — select **Clear** to force \"no value\" at this\n usage, ignoring the default entirely (only available when the field\n isn't required).\n\nSelect **Reset to default** at any time to go back to inheriting. The same\nthree states and the same per-type widgets apply to a Presentation field's\nown contextual-values panel (see\n[Presenting content with Templates](templates.md)).\n\n### Editing the linked Component itself\n\nNext to **Contextual values**, a linked Component also offers **Quick\nedit**, which opens that Component in a layer over the page you're on —\nits own fields, its own **Save**, and a note of everywhere else it's used,\nsince saving changes it there too. How layers stack, and the difference\nbetween a layer that saves on its own and one that's part of your page, is\nexplained in\n[Editing something from where it's used](content-authoring.md#editing-something-from-where-its-used).\n\n## Organizing with folders\n\nThe **Content** page shows your folder tree on the left. Select the\n**+** icon next to a folder to create a subfolder inside it, the pencil\nicon to rename or move it, or the trash icon to delete it (only possible\nonce it's empty). Selecting a folder shows two tabs: **Contents** (the\nComponents inside it) and, if you have the right permissions, **Settings**\n(that folder's **Access rules**, **Allowed Contracts**, and editorial\nworkflow assignment).\n\nEach Component in the Contents tab is shown as a row with its Contract,\nName, Id, Version, and when it was last updated. Select the **Name** or\n**Last updated** column heading to sort by it. Above the list, a search\nbox and a single **Filter** button (showing a count once you've set any\nfilters) let you narrow by category and/or Contract; pagination appears\nonce a folder holds more Components than fit on one page.\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 to another folder\n\nOpen the Component, select the **Settings** tab, and select **Move…**\nnext to the **Folder** label. A picker lists every folder (and **Root**);\npick one to move the Component there once you save. A folder you don't\nhave edit access to is shown but disabled, with an explanation. A folder\nwhose **Allowed Contracts** don't include this Component's Contract is\ndisabled too — unlike an *existing* Component whose folder's rules later\nchange (the **Non-conforming** badge case above), a move that would\nviolate the target folder's rules is rejected outright, so the picker\nwon't offer it as an option in the first place.\n\n### Finding your way back to a folder\n\nThe Component editor shows a breadcrumb above its title (**Content** /\nthe folder it's in / the Component's name) — select the folder name to\nreturn straight to that folder's Contents tab, rather than using your\nbrowser's back button.\n\n## The upgrade badge\n\nIf a Contract changes after a Component was created from it, that\nComponent keeps working exactly as it did — nothing breaks automatically.\nInstead:\n\n- If the Component still satisfies the Contract's latest version, you'll\n see a badge offering **Upgrade to v_N_** — select it to move the\n Component onto the latest version immediately.\n- If it no longer satisfies the latest version, you'll see a\n **Not valid against latest** badge listing exactly what's wrong. Select\n **Start guided upgrade** to switch into editing against the latest\n version, fix the listed issues, and save — the Component moves onto the\n new version as part of that save.\n\nYou're never forced to upgrade; an older Component keeps validating against\nthe version it was created with until you choose to move it forward.\n\n## Asking the assistant to edit this Component\n\nThe help panel's question box (open it from the **?** icon) can see and edit the Component you have\nopen, not only answer questions about it — see **When the assistant can read and edit** in\n[Getting help](../general/getting-help.md). A field edit it makes saves immediately with the same\nversion history a manual edit gets; anything bigger, like deleting the Component, is proposed for\nyou to review first.\n"
|
|
19
|
+
"body": "# Authoring Components\n\nA Component is one piece of content built from a Contract — for example,\na specific article. This guide covers creating and editing Components,\norganizing them in folders, and the friction the app shows you when a\nContract changes underneath a Component you've already created. See\n[Modeling content with Contracts](contracts.md) first if you haven't\ncreated a Contract yet.\n\n## Creating a Component\n\n1. From the Content page, select **New Component** (optionally after\n opening the folder you want it created in).\n2. Enter a **Name** — the **Id** fills in from it automatically and can\n still be edited by hand.\n3. Choose a **Contract**. If you started from a specific folder that\n restricts which Contracts are allowed there, only those (and their\n descendants) are offered.\n4. Fill in the form that appears — every field from the Contract, laid\n out in order. Fields marked with a red **\\*** are required.\n5. Select **Create**. If a required field is missing or a value doesn't\n match the Contract's rules, the field is highlighted with an\n explanation — fix it and select **Create** again.\n\n## Filling in fields\n\nMost fields are a straightforward text box, number box, or checkbox.\nA few work differently:\n\n- **Reference** and **Nested** are older field types kept working for\n existing Contracts, but no longer offered when adding a new field — new\n Contracts should use **Component** instead (below), which offers the\n same two behaviors plus a third, chosen per value instead of committed\n to for the whole field.\n- **Component** fields ask you to choose, each time you fill one in:\n **Choose…** to link to an existing Component (same search box as\n Reference, with **Change**/**Remove** once chosen); **Create new…** to\n create a brand-new Component and link to it in one step (fill in its\n name, Contract, and any required fields right there); or **Create\n inline…** to embed a value that only ever exists inside this one — pick\n a Contract and an **Edit** panel slides in, exactly like Nested below.\n If the Contract only allows one of these choices, only that one is\n offered. If a linked Component can't be found — most often because it\n was skipped during a promotion into this environment (see\n [content-environments.md](content-environments.md)'s \"Unresolved\n references\" section) — you'll see a distinct **Unresolved** badge\n instead of the usual resolved name, with a link to Component Sync to\n see the full picture and fix it. **Change**/**Remove** still work\n normally on an unresolved value.\n- **Blob** fields (images and other files) show an **Upload** button.\n Once uploaded, you'll see a preview (for images) and a link to download\n the file, plus a **Replace** button.\n- **Nested** fields show a small **Edit** panel once a Contract is chosen\n for them (automatically, if only one is allowed for that field, or via a\n picker if more than one is allowed) — selecting **Edit** opens the\n nested content in its own panel, sliding in over the current one. Any\n unsaved changes you've made — at every level — are kept even if you\n drill several levels deep and back out again; nothing is lost until you\n actually leave the page without saving. A Component field's own **Create\n inline…** choice opens the identical panel.\n- Fields marked **Localizable** always show a small translations icon next\n to their label — select it to add per-locale overrides alongside the\n default value. It's disabled (with an explanation on hover) until your\n organization has a language configured under **Localization** settings\n with at least one language added under it to translate into; once one\n exists, the icon becomes selectable. This works the same way for every\n field type, including Blob, Reference, Nested, Component, and\n Presentation fields: each locale gets its own independent\n **Upload**/**Edit**/**Choose…** affordance, so a Nested value's translated\n content — or a different linked Component or uploaded file per locale —\n is fully separate from the default. The default-locale row in the\n translations panel is always read-only (a reflection of the default\n value, not a second copy of it); translate from the other locale rows.\n- **Presentation** fields let you instantiate a Template inline — pick a\n Template, bind it to a Component, and set contextual values and settings\n for this specific placement. See\n [Presenting content with Templates](templates.md) for the full flow.\n\n## Links to the live page\n\nIf the Contract has **External links**, they appear as buttons under the\nComponent's name, and at the top of the quick-edit panel. A button opens that\nComponent's page on your site in a new tab. If it is greyed out, the reason is\nwritten beside it, usually that the Component has not been published yet. The\nlink always shows what is *published*, not the changes you are typing. See\n[Links to your site](contracts.md) to set them up.\n\n## Editing a tree of Components\n\nWhen a Contract is set up to be edited as a tree (see\n[Editing fields as a tree](contracts.md)), its Component editor shows one\nsection, such as **Pedigree**, in place of the separate pickers. The Component\nyou are editing is the root, and each slot is a Component of its own.\n\n- **Chart or outline.** A slot-based tree such as a pedigree is drawn as a chart,\n one column per generation, or as an outline. Choose with the buttons above it;\n the outline is used on narrow screens. **Generations** shows fewer levels\n without changing anything. A list, such as the parts of a product, is always\n an outline you can collapse and expand.\n- **Fill a slot.** Select an empty slot to search for an existing Component, or\n **Create new** to make one on the spot. A slot only lists Components it can\n hold, such as dogs for a sire.\n- **Options you can't choose are greyed out, with the reason.** *Would become its\n own ancestor* or *Would contain itself* means choosing it would make something\n its own ancestor. *Already used elsewhere in this tree* appears when the\n Contract doesn't allow repeats. *Already in this list* means it is there\n already. If the server still refuses a change, the reason is shown above the\n tree.\n- **Edit without leaving.** **Edit** on a filled slot opens that Component in a\n panel over the page. Change it, save it and close the panel, and you are back\n in the tree.\n- **Change or remove.** Point at a filled slot for **Change** and the remove\n button. Removing only empties the slot; the Component itself is kept.\n- **A slot under an empty parent is greyed out**, because there is nothing to\n attach it to yet. Fill the parent first.\n- **A name with ×2 or \"in 2\"** is one Component that appears in more than one\n place. Editing it changes it everywhere.\n\n**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.\n\n## Contextual defaults\n\nFields marked Contextual on the Contract appear in a separate\n**\"Defaults for usage sites\"** section, clearly labeled optional — even if\nthe Contract also marks them Mandatory. That's intentional: a Contextual\nfield's real value is supplied wherever the content is *used*, not here;\nwhat you set in this section is only a fallback for places that don't\nsupply their own value.\n\n### Setting per-usage values on a Reference\n\nWhen you link to another Component via a Reference field (or a Component\nfield's **Choose…**/**Create new…** path — both link the same way), select\n**Contextual values** to open a panel listing that target's own Contextual\nfields, each with three distinct states you can switch between:\n\n- **Inheriting the Component's default** — nothing set here; the linked\n Component's own default value is used.\n- **Overridden** — set a value here to use instead of the default, just\n for this one link. This works for every field type the target Contract\n declares as Contextual, not just simple text/number/checkbox fields — a\n Contextual Reference field gets the same **Choose…** picker, a Contextual\n Blob field the same **Upload** button, and a Contextual Nested field the\n same drill-in **Edit** panel you'd see editing that field directly on a\n Component.\n- **Explicitly cleared** — select **Clear** to force \"no value\" at this\n usage, ignoring the default entirely (only available when the field\n isn't required).\n\nSelect **Reset to default** at any time to go back to inheriting. The same\nthree states and the same per-type widgets apply to a Presentation field's\nown contextual-values panel (see\n[Presenting content with Templates](templates.md)).\n\n### Editing the linked Component itself\n\nNext to **Contextual values**, a linked Component also offers **Quick\nedit**, which opens that Component in a layer over the page you're on —\nits own fields, its own **Save**, and a note of everywhere else it's used,\nsince saving changes it there too. How layers stack, and the difference\nbetween a layer that saves on its own and one that's part of your page, is\nexplained in\n[Editing something from where it's used](content-authoring.md#editing-something-from-where-its-used).\n\n## Organizing with folders\n\nThe **Content** page shows your folder tree on the left. Select the\n**+** icon next to a folder to create a subfolder inside it, the pencil\nicon to rename or move it, or the trash icon to delete it (only possible\nonce it's empty). Selecting a folder shows two tabs: **Contents** (the\nComponents inside it) and, if you have the right permissions, **Settings**\n(that folder's **Access rules**, **Allowed Contracts**, and editorial\nworkflow assignment).\n\nEach Component in the Contents tab is shown as a row with its Contract,\nName, Id, Version, and when it was last updated. Select the **Name** or\n**Last updated** column heading to sort by it. Above the list, a search\nbox and a single **Filter** button (showing a count once you've set any\nfilters) let you narrow by category and/or Contract; pagination appears\nonce a folder holds more Components than fit on one page.\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 to another folder\n\nOpen the Component, select the **Settings** tab, and select **Move…**\nnext to the **Folder** label. A picker lists every folder (and **Root**);\npick one to move the Component there once you save. A folder you don't\nhave edit access to is shown but disabled, with an explanation. A folder\nwhose **Allowed Contracts** don't include this Component's Contract is\ndisabled too — unlike an *existing* Component whose folder's rules later\nchange (the **Non-conforming** badge case above), a move that would\nviolate the target folder's rules is rejected outright, so the picker\nwon't offer it as an option in the first place.\n\n### Finding your way back to a folder\n\nThe Component editor shows a breadcrumb above its title (**Content** /\nthe folder it's in / the Component's name) — select the folder name to\nreturn straight to that folder's Contents tab, rather than using your\nbrowser's back button.\n\n## The upgrade badge\n\nIf a Contract changes after a Component was created from it, that\nComponent keeps working exactly as it did — nothing breaks automatically.\nInstead:\n\n- If the Component still satisfies the Contract's latest version, you'll\n see a badge offering **Upgrade to v_N_** — select it to move the\n Component onto the latest version immediately.\n- If it no longer satisfies the latest version, you'll see a\n **Not valid against latest** badge listing exactly what's wrong. Select\n **Start guided upgrade** to switch into editing against the latest\n version, fix the listed issues, and save — the Component moves onto the\n new version as part of that save.\n\nYou're never forced to upgrade; an older Component keeps validating against\nthe version it was created with until you choose to move it forward.\n\n## Asking the assistant to edit this Component\n\nThe help panel's question box (open it from the **?** icon) can see and edit the Component you have\nopen, not only answer questions about it — see **When the assistant can read and edit** in\n[Getting help](../general/getting-help.md). A field edit it makes saves immediately with the same\nversion history a manual edit gets; anything bigger, like deleting the Component, is proposed for\nyou to review first.\n"
|
|
20
20
|
},
|
|
21
21
|
{
|
|
22
22
|
"slug": "content-adapters",
|
|
@@ -71,7 +71,7 @@ export const HELP_TOPICS = [
|
|
|
71
71
|
{
|
|
72
72
|
"slug": "contracts",
|
|
73
73
|
"title": "Modeling content with Contracts",
|
|
74
|
-
"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## Creating a Contract\n\n1. From the Contracts list, select **New Contract**.\n2. Switch to the **General** tab. Enter a **Name** — everything else below\n fills in from it, so filling it in first saves retyping. **Id** — a\n short, URL-safe identifier made of lowercase letters, numbers, and\n hyphens — fills in from Name automatically; you can still edit it by\n hand before saving.\n3. Turn on **Abstract** if this Contract exists only to be extended by\n other Contracts, or to constrain what a field is allowed to point at —\n an abstract Contract can't be used to create content directly.\n4. Optionally choose a **Parent Contract**. Every field the parent\n declares is inherited automatically and shown read-only under\n \"Inherited fields\" on the **Fields** tab — you can't redefine or hide an\n inherited field, only add new ones of your own.\n5. Switch to the **Fields** tab (the default tab) and select **Add field**\n to add a field. The Fields list is a set of collapsible rows —\n selecting a row's name expands it to fill in its Name/Id, pick a\n **Field type**, and set its modifiers (see below), and collapses\n whichever row was open before it, so only one field's details are ever\n in view at once. Repeat for every field the Contract needs; drag a row\n by its handle to reorder it (or, from the keyboard, focus the handle,\n press Space to pick it up, use the arrow keys to move it, and Space\n again to drop it), or select the trash icon to remove one. A row with\n an unresolved error shows a warning icon even while collapsed, and a\n failed save automatically expands the first field that needs\n attention — or, for an error on the General tab (Name, Id, Parent\n Contract), switches you back to that tab.\n6. Select **Save** (visible from either tab). Before anything is saved, you'll see a banner telling\n you whether this is a brand-new Contract, an in-place update, or a\n change that creates a new *version* (see \"Versions\" below) — confirm to\n go ahead, or cancel to keep editing.\n\n## Field types and modifiers\n\nEvery field has a **Field type** (Short Text, Number, Boolean, Date, Link,\nComponent, Blob, Presentation, Rich Text, or Category — Long Text, URL,\nReference, Nested, and Experience Reference are deprecated and no longer\noffered for new fields, though any field already using one keeps working\nunchanged; see \"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, Short Text, Long Text, and Rich Text all 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, Short Text and Long Text share 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### Restricting a field to a fixed list of values\n\nShort Text, Long Text, 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 Short Text field can\nname a **Choice source** — an activated plugin that supplies the option\nlist live, kept automatically in sync with whatever it's connected to.\nThe first one, **ebitex Forms**, lists your organization's own published\nForms, so you can pick a form by name rather than typing its id — useful\nfor a field like \"which form should appear on this page.\" A field can use\neither Allowed values or a Choice source, never both.\n\nOnce a Choice source plugin is activated (in your organization's Settings)\nand picked in a field's settings, editing a Component with that field\nlooks exactly like a normal fixed-list field: buttons, a dropdown,\ncheckboxes, or a searchable picker, depending on how many options there\nare. If the source is temporarily unavailable — a misconfigured\nconnection, for example — you'll see a short message explaining that, and\nthe field falls back to a plain text box so you can still see and edit\nwhatever value is already saved; nothing else on the page is blocked from\nsaving while that happens.\n\n### Giving a field a default value\n\nMost field types — anything other than Component, Presentation, Rich\nText, and Category, which all point at other content rather than holding\na plain value — can be given a **Default value** in their expanded row.\nOnce set, every brand-new Component created from this Contract starts\nwith that value already filled in, instead of empty; editing or clearing\nthe default afterward never changes a Component that already exists. For a\nContextual field, its default becomes the Component's own fallback value —\nused whenever a specific placement doesn't override it.\n\n## Component fields\n\nA **Component** field holds a reference to another Component, an inline\n(embedded) value, or either — decided by whoever is *filling in* the field,\nnot fixed when you design the Contract:\n\n- **Linked** — points at another Component elsewhere in your organization;\n the two stay separate, and deleting a Component that's linked elsewhere\n is blocked until the link is removed first. Covers both picking an\n existing Component and creating a brand-new one to link to.\n- **Inline** — embeds another Component's content directly inside; there's\n no separate entity to manage, it's just part of the same document. Best\n for content that only ever makes sense as part of its parent (for\n example, an article's author details).\n\nIf you want to guarantee only one of these for a given field — say, a\n\"related articles\" field that should always link to a reusable Component,\nnever an inline one-off — the field's settings offer **Allowed value\nmodes**, a checklist of the two options above (at least one must stay\nchecked). Leaving both checked (the default) lets whoever fills in the\nfield choose either way each time. Either way, **allowedContractIds** lets\nyou restrict which Contracts are allowed — leave it empty to allow any\nContract (including descendants of one you do list).\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** on the **General** tab changes that. Choose **Edit as a tree**\nand 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\nvalidation and what is published are exactly as before, and it creates no new\nContract version.\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 **General**, under **Editing layout**, 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## 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"
|
|
74
|
+
"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## Creating a Contract\n\n1. From the Contracts list, select **New Contract**.\n2. Switch to the **General** tab. Enter a **Name** — everything else below\n fills in from it, so filling it in first saves retyping. **Id** — a\n short, URL-safe identifier made of lowercase letters, numbers, and\n hyphens — fills in from Name automatically; you can still edit it by\n hand before saving.\n3. Turn on **Abstract** if this Contract exists only to be extended by\n other Contracts, or to constrain what a field is allowed to point at —\n an abstract Contract can't be used to create content directly.\n4. Optionally choose a **Parent Contract**. Every field the parent\n declares is inherited automatically and shown read-only under\n \"Inherited fields\" on the **Fields** tab — you can't redefine or hide an\n inherited field, only add new ones of your own.\n5. Switch to the **Fields** tab (the default tab) and select **Add field**\n to add a field. The Fields list is a set of collapsible rows —\n selecting a row's name expands it to fill in its Name/Id, pick a\n **Field type**, and set its modifiers (see below), and collapses\n whichever row was open before it, so only one field's details are ever\n in view at once. Repeat for every field the Contract needs; drag a row\n by its handle to reorder it (or, from the keyboard, focus the handle,\n press Space to pick it up, use the arrow keys to move it, and Space\n again to drop it), or select the trash icon to remove one. A row with\n an unresolved error shows a warning icon even while collapsed, and a\n failed save automatically expands the first field that needs\n attention — or, for an error on the General tab (Name, Id, Parent\n Contract), switches you back to that tab.\n6. Select **Save** (visible from either tab). Before anything is saved, you'll see a banner telling\n you whether this is a brand-new Contract, an in-place update, or a\n change that creates a new *version* (see \"Versions\" below) — confirm to\n go ahead, or cancel to keep editing.\n\n## Field types and modifiers\n\nEvery field has a **Field type** (Short Text, Number, Boolean, Date, Link,\nComponent, Blob, Presentation, Rich Text, or Category — Long Text, URL,\nReference, Nested, and Experience Reference are deprecated and no longer\noffered for new fields, though any field already using one keeps working\nunchanged; see \"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, Short Text, Long Text, and Rich Text all 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, Short Text and Long Text share 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### Restricting a field to a fixed list of values\n\nShort Text, Long Text, 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 Short Text field can\nname a **Choice source** — an activated plugin that supplies the option\nlist live, kept automatically in sync with whatever it's connected to.\nThe first one, **ebitex Forms**, lists your organization's own published\nForms, so you can pick a form by name rather than typing its id — useful\nfor a field like \"which form should appear on this page.\" A field can use\neither Allowed values or a Choice source, never both.\n\nOnce a Choice source plugin is activated (in your organization's Settings)\nand picked in a field's settings, editing a Component with that field\nlooks exactly like a normal fixed-list field: buttons, a dropdown,\ncheckboxes, or a searchable picker, depending on how many options there\nare. If the source is temporarily unavailable — a misconfigured\nconnection, for example — you'll see a short message explaining that, and\nthe field falls back to a plain text box so you can still see and edit\nwhatever value is already saved; nothing else on the page is blocked from\nsaving while that happens.\n\n### Giving a field a default value\n\nMost field types — anything other than Component, Presentation, Rich\nText, and Category, which all point at other content rather than holding\na plain value — can be given a **Default value** in their expanded row.\nOnce set, every brand-new Component created from this Contract starts\nwith that value already filled in, instead of empty; editing or clearing\nthe default afterward never changes a Component that already exists. For a\nContextual field, its default becomes the Component's own fallback value —\nused whenever a specific placement doesn't override it.\n\n## Component fields\n\nA **Component** field holds a reference to another Component, an inline\n(embedded) value, or either — decided by whoever is *filling in* the field,\nnot fixed when you design the Contract:\n\n- **Linked** — points at another Component elsewhere in your organization;\n the two stay separate, and deleting a Component that's linked elsewhere\n is blocked until the link is removed first. Covers both picking an\n existing Component and creating a brand-new one to link to.\n- **Inline** — embeds another Component's content directly inside; there's\n no separate entity to manage, it's just part of the same document. Best\n for content that only ever makes sense as part of its parent (for\n example, an article's author details).\n\nIf you want to guarantee only one of these for a given field — say, a\n\"related articles\" field that should always link to a reusable Component,\nnever an inline one-off — the field's settings offer **Allowed value\nmodes**, a checklist of the two options above (at least one must stay\nchecked). Leaving both checked (the default) lets whoever fills in the\nfield choose either way each time. Either way, **allowedContractIds** lets\nyou restrict which Contracts are allowed — leave it empty to allow any\nContract (including descendants of one you do list).\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** on the **General** tab changes that. Choose **Edit as a tree**\nand 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\nvalidation and what is published are exactly as before, and it creates no new\nContract version.\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 **General**, under **Editing layout**, 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 - `{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"
|
|
75
75
|
},
|
|
76
76
|
{
|
|
77
77
|
"slug": "environment-refresh",
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"helpCorpus.generated.js","sourceRoot":"","sources":["../../src/resources/helpCorpus.generated.ts"],"names":[],"mappings":"AAAA,qDAAqD;AACrD,EAAE;AACF,kGAAkG;AAClG,oGAAoG;AAIpG,MAAM,CAAC,MAAM,WAAW,GAAgB;IACtC;QACE,MAAM,EAAE,iBAAiB;QACzB,OAAO,EAAE,0CAA0C;QACnD,MAAM,EAAE,knWAAknW;KAC3nW;IACD;QACE,MAAM,EAAE,aAAa;QACrB,OAAO,EAAE,aAAa;QACtB,MAAM,EAAE,wnGAAwnG;KACjoG;IACD;QACE,MAAM,EAAE,YAAY;QACpB,OAAO,EAAE,sBAAsB;QAC/B,MAAM,EAAE,
|
|
1
|
+
{"version":3,"file":"helpCorpus.generated.js","sourceRoot":"","sources":["../../src/resources/helpCorpus.generated.ts"],"names":[],"mappings":"AAAA,qDAAqD;AACrD,EAAE;AACF,kGAAkG;AAClG,oGAAoG;AAIpG,MAAM,CAAC,MAAM,WAAW,GAAgB;IACtC;QACE,MAAM,EAAE,iBAAiB;QACzB,OAAO,EAAE,0CAA0C;QACnD,MAAM,EAAE,knWAAknW;KAC3nW;IACD;QACE,MAAM,EAAE,aAAa;QACrB,OAAO,EAAE,aAAa;QACtB,MAAM,EAAE,wnGAAwnG;KACjoG;IACD;QACE,MAAM,EAAE,YAAY;QACpB,OAAO,EAAE,sBAAsB;QAC/B,MAAM,EAAE,kjbAAkjb;KAC3jb;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,kCAAkC;QAC3C,MAAM,EAAE,ggnBAAggnB;KACzgnB;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,0BAA0B;QACnC,MAAM,EAAE,6oLAA6oL;KACtpL;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,gCAAgC;QACzC,MAAM,EAAE,qyfAAqyf;KAC9yf;IACD;QACE,MAAM,EAAE,sBAAsB;QAC9B,OAAO,EAAE,sBAAsB;QAC/B,MAAM,EAAE,s3qBAAs3qB;KAC/3qB;IACD;QACE,MAAM,EAAE,eAAe;QACvB,OAAO,EAAE,qCAAqC;QAC9C,MAAM,EAAE,q3FAAq3F;KAC93F;IACD;QACE,MAAM,EAAE,yBAAyB;QACjC,OAAO,EAAE,4BAA4B;QACrC,MAAM,EAAE,2jRAA2jR;KACpkR;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,mBAAmB;QAC5B,MAAM,EAAE,6/HAA6/H;KACtgI;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,wvJAAwvJ;KACjwJ;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,oBAAoB;QAC7B,MAAM,EAAE,82WAA82W;KACv3W;IACD;QACE,MAAM,EAAE,WAAW;QACnB,OAAO,EAAE,iCAAiC;QAC1C,MAAM,EAAE,q+fAAq+f;KAC9+f;IACD;QACE,MAAM,EAAE,qBAAqB;QAC7B,OAAO,EAAE,qBAAqB;QAC9B,MAAM,EAAE,+iFAA+iF;KACxjF;IACD;QACE,MAAM,EAAE,eAAe;QACvB,OAAO,EAAE,mBAAmB;QAC5B,MAAM,EAAE,u/JAAu/J;KAChgK;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,mBAAmB;QAC5B,MAAM,EAAE,upIAAupI;KAChqI;IACD;QACE,MAAM,EAAE,iBAAiB;QACzB,OAAO,EAAE,iBAAiB;QAC1B,MAAM,EAAE,ugNAAugN;KAChhN;IACD;QACE,MAAM,EAAE,WAAW;QACnB,OAAO,EAAE,WAAW;QACpB,MAAM,EAAE,06NAA06N;KACn7N;IACD;QACE,MAAM,EAAE,YAAY;QACpB,OAAO,EAAE,oBAAoB;QAC7B,MAAM,EAAE,2hVAA2hV;KACpiV;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,+BAA+B;QACxC,MAAM,EAAE,g2EAAg2E;KACz2E;IACD;QACE,MAAM,EAAE,OAAO;QACf,OAAO,EAAE,OAAO;QAChB,MAAM,EAAE,i7FAAi7F;KAC17F;IACD;QACE,MAAM,EAAE,WAAW;QACnB,OAAO,EAAE,mCAAmC;QAC5C,MAAM,EAAE,8vKAA8vK;KACvwK;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,kBAAkB;QAC3B,MAAM,EAAE,6hJAA6hJ;KACtiJ;CACF,CAAA"}
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@ebitex/content-mcp",
|
|
3
|
-
"version": "0.5.
|
|
3
|
+
"version": "0.5.132",
|
|
4
4
|
"description": "An MCP server for ebitex Content: build and publish a content model from an AI agent.",
|
|
5
5
|
"license": "Apache-2.0",
|
|
6
6
|
"homepage": "https://developers.ebitex.io/getting-started/content-as-code/",
|