@ebitex/content-mcp 0.5.120 → 0.5.129
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## 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"
|
|
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## 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",
|
|
@@ -96,7 +96,7 @@ export const HELP_TOPICS = [
|
|
|
96
96
|
{
|
|
97
97
|
"slug": "proposals",
|
|
98
98
|
"title": "Proposals",
|
|
99
|
-
"body": "# Proposals\n\nA **proposal** is content somebody outside your organization has offered — a breeder submitting a\nlitter, a partner sending an event, anything a form or another system can produce. It sits in\nContent waiting for one of your people to look at it.\n\nNothing offered this way reaches your site on its own. A proposal is not a page, not a Component, and\nnot published: it becomes content only when somebody approves it, and approving is what creates the\nComponent.\n\n## Where to find them\n\n**Proposals** in the sidebar lists everything offered, grouped by what has happened to it:\n**Awaiting review**, **Approved**, **Rejected**. Anything waiting on *you* specifically also appears\nin [Tasks](tasks.md), alongside pages awaiting approval and translations awaiting acceptance.\n\nAny member of the environment can open the page. Whether you can actually approve or reject\nsomething is decided by the workflow, not by a separate permission.\n\n## Reviewing one\n\nThe review screen has two halves.\n\nOn the left, **As received** — exactly what the sender sent, unchanged and never thrown away. Each\nvalue shows the name the sender used. If something they sent matches no field on your Contract, it is\nstill shown here, marked, rather than quietly dropped. Copy across anything worth keeping.\n\nOn the right, the ordinary content form for the Contract, prefilled where a sent value clearly\nmatched a field. Matching ignores capitalisation and punctuation, so a form field named `hip_score`\nfills in a Contract field called `hip-score` without anyone configuring anything.\n\n**Some things are deliberately left blank.** A sent value is plain text; a field that holds a list, a\nlink to another item, an image, or personalised variants needs more than plain text to be filled in\nsafely. Rather than guess, Content leaves those to you — the sent value is still on the left, so\nnothing is lost.\n\nFinish the form, then choose one of the actions at the bottom. Those buttons are the transitions your\nworkflow allows your role to fire, so they carry your own wording, not ours.\n\n## What approving and rejecting do\n\n**Approve** creates a Component, as a **Draft**, in the folder the proposal was offered for. It does\nnot publish it — publishing is the same step it is for anything else. The proposal is kept, and\nrecords which Component it became.\n\n**Reject** creates nothing and deletes nothing. The proposal and everything sent with it stay, so you\ncan look back at what was offered and declined.\n\nEither way, whatever record the sender's own system keeps is untouched.\n\n## Setting it up\n\nTwo things have to exist before anything can be offered.\n\n**A proposal workflow, assigned to the destination folder.** Create one under **Workflows**, choosing\nthe **Proposal review** kind, then assign it to the folder (or any folder above it) on that folder's\nown access and workflow settings, where it appears as a **Proposal review** picker.\n\nCreate the workflow first: that picker only appears once at least one Proposal review workflow\nexists, since until then there would be nothing for it to offer. A folder with none assigned says so\nplainly, and says what it means — offers to that folder will be refused.\n\nThis is required, not optional. Without it there would be nobody to review what arrives, so Content\nrefuses the offer outright and tells the sender why — rather than accepting content nobody will\never look at.\n\n**A key that can only propose.** Under **API keys**, create one whose only scope is\n*content.management.proposals*. A key holding just that can offer proposals and can do nothing\nelse — it cannot read your content and cannot write any. Give it to whoever is sending.\n\n## Where proposals come from\n\nContent does not care what sent a proposal. It records three things about the sender — a kind, a\nreference, and a label — stores them exactly as given, and never contacts the sender again. Anything\nthat can make an HTTP request with the key above can offer content: a partner's own server, a\nscheduled job, a script.\n\n**An ebitex form is the ready-made option.** If the thing you want reviewed is something people fill\nin, build a form in Forms and connect it — no code, and no field mapping, because Content matches\nwhat the form sent against your Contract's fields by name. See\n[Offering submissions to Content](../forms/forms.md) for the three setup steps.\n\nWhat the reviewer sees is the same either way: the same page, the same two panels, the same\napprove-or-reject. A form-sent proposal is labelled with the form's name; another system's is\nlabelled with whatever it chose to send.\n\n## Why something might not appear\n\n**It was refused at the door.** The sender gets a clear reason: an unknown Contract, an unknown\nfolder, or no proposal workflow on that folder.\n\n**The same thing was sent twice.** Offers are identified by the sender's own reference, so re-sending\nthe same one returns the original rather than filing a duplicate. That makes it safe for a sender to\nretry after a failure.\n\n**It is for a folder you cannot see.** Proposals for branches outside your access are not listed at\nall.\n\n**You are in a different environment.** Proposals belong to the environment their key is bound to.\n\n## Related\n\n- [Tasks](tasks.md) — everything waiting on you, across every kind of review\n- [Workflows](content-workflow.md) — designing the review itself\n- [Forms](../forms/forms.md) — building a form and connecting it as a source of proposals\n"
|
|
99
|
+
"body": "# Proposals\n\nA **proposal** is content somebody outside your organization has offered — a breeder submitting a\nlitter, a partner sending an event, anything a form or another system can produce. It sits in\nContent waiting for one of your people to look at it.\n\nNothing offered this way reaches your site on its own. A proposal is not a page, not a Component, and\nnot published: it becomes content only when somebody approves it, and approving is what creates the\nComponent.\n\n## Where to find them\n\n**Proposals** in the sidebar lists everything offered, grouped by what has happened to it:\n**Awaiting review**, **Approved**, **Rejected**. Anything waiting on *you* specifically also appears\nin [Tasks](tasks.md), alongside pages awaiting approval and translations awaiting acceptance.\n\nAny member of the environment can open the page. Whether you can actually approve or reject\nsomething is decided by the workflow, not by a separate permission.\n\n## Reviewing one\n\nThe review screen has two halves.\n\nOn the left, **As received** — exactly what the sender sent, unchanged and never thrown away. Each\nvalue shows the name the sender used. If something they sent matches no field on your Contract, it is\nstill shown here, marked, rather than quietly dropped. Copy across anything worth keeping.\n\nOn the right, the ordinary content form for the Contract, prefilled where a sent value clearly\nmatched a field. Matching ignores capitalisation and punctuation, so a form field named `hip_score`\nfills in a Contract field called `hip-score` without anyone configuring anything.\n\n**A field made of parts can be prefilled too.** If a Contract field holds a value typed in place (an *inline* component, such as an author with a name and an email) and the sender used keys named after the field and the part, like `author-name` and `author-email`, the review fills in that inline value and marks each of those keys **Filled into Author**. Where the field allows more than one Contract, the one matching the most keys is used, and if two match equally the one the field lists first is.\n\n**Possible matches.** When a field allows a link to an existing item as well, and the value that was filled in has a title, a **Possible matches** panel appears above the form listing up to five existing items with a similar name. **Use this one** replaces the typed-in value with a link to that item, and **Undo** puts back exactly what was sent. Nothing is ever linked for you: a name is only a hint, and linking the wrong item is worse than typing it again. Whatever the sender typed stays on the left either way.\n\n**Some things are deliberately left blank.** A sent value is plain text; a field that holds a list, a\nlink to another item, an image, or personalised variants needs more than plain text to be filled in\nsafely. Rather than guess, Content leaves those to you — the sent value is still on the left, so\nnothing is lost.\n\nFinish the form, then choose one of the actions at the bottom. Those buttons are the transitions your\nworkflow allows your role to fire, so they carry your own wording, not ours.\n\n## What approving and rejecting do\n\n**Approve** creates a Component, as a **Draft**, in the folder the proposal was offered for. It does\nnot publish it — publishing is the same step it is for anything else. The proposal is kept, and\nrecords which Component it became.\n\n**Reject** creates nothing and deletes nothing. The proposal and everything sent with it stay, so you\ncan look back at what was offered and declined.\n\nEither way, whatever record the sender's own system keeps is untouched.\n\n## Setting it up\n\nTwo things have to exist before anything can be offered.\n\n**A proposal workflow, assigned to the destination folder.** Create one under **Workflows**, choosing\nthe **Proposal review** kind, then assign it to the folder (or any folder above it) on that folder's\nown access and workflow settings, where it appears as a **Proposal review** picker.\n\nCreate the workflow first: that picker only appears once at least one Proposal review workflow\nexists, since until then there would be nothing for it to offer. A folder with none assigned says so\nplainly, and says what it means — offers to that folder will be refused.\n\nThis is required, not optional. Without it there would be nobody to review what arrives, so Content\nrefuses the offer outright and tells the sender why — rather than accepting content nobody will\never look at.\n\n**A key that can only propose.** Under **API keys**, create one whose only scope is\n*content.management.proposals*. A key holding just that can offer proposals and can do nothing\nelse — it cannot read your content and cannot write any. Give it to whoever is sending.\n\n## Where proposals come from\n\nContent does not care what sent a proposal. It records three things about the sender — a kind, a\nreference, and a label — stores them exactly as given, and never contacts the sender again. Anything\nthat can make an HTTP request with the key above can offer content: a partner's own server, a\nscheduled job, a script.\n\n**An ebitex form is the ready-made option.** If the thing you want reviewed is something people fill\nin, build a form in Forms and connect it — no code, and no field mapping, because Content matches\nwhat the form sent against your Contract's fields by name. See\n[Offering submissions to Content](../forms/forms.md) for the three setup steps.\n\nWhat the reviewer sees is the same either way: the same page, the same two panels, the same\napprove-or-reject. A form-sent proposal is labelled with the form's name; another system's is\nlabelled with whatever it chose to send.\n\n## Why something might not appear\n\n**It was refused at the door.** The sender gets a clear reason: an unknown Contract, an unknown\nfolder, or no proposal workflow on that folder.\n\n**The same thing was sent twice.** Offers are identified by the sender's own reference, so re-sending\nthe same one returns the original rather than filing a duplicate. That makes it safe for a sender to\nretry after a failure.\n\n**It is for a folder you cannot see.** Proposals for branches outside your access are not listed at\nall.\n\n**You are in a different environment.** Proposals belong to the environment their key is bound to.\n\n## Related\n\n- [Tasks](tasks.md) — everything waiting on you, across every kind of review\n- [Workflows](content-workflow.md) — designing the review itself\n- [Forms](../forms/forms.md) — building a form and connecting it as a source of proposals\n"
|
|
100
100
|
},
|
|
101
101
|
{
|
|
102
102
|
"slug": "publishing",
|
|
@@ -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,k9VAAk9V;KAC39V;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,s2XAAs2X;KAC/2X;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,o7MAAo7M;KAC77M;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/dist/tools/catalog.d.ts
CHANGED
|
@@ -21,12 +21,27 @@ import { type EntityKind } from '../routes.js';
|
|
|
21
21
|
* key acquiring one.
|
|
22
22
|
*/
|
|
23
23
|
export declare const AUTHENTICATED: "*";
|
|
24
|
+
/**
|
|
25
|
+
* The three entity kinds `content_write` may commit immediately from the in-app assistant (spec
|
|
26
|
+
* 939-ai-inline-assistant) rather than as a deferred suggestion: `component` and `node` implement
|
|
27
|
+
* `IVersionedEntity` server-side; `nodePayload` writes the same `ExperienceNode` row through its own
|
|
28
|
+
* route (`PUT /experience/nodes/{id}/payload`) and so qualifies too. `contract` does **not** — it
|
|
29
|
+
* implements only `IConcurrencyProtected` (a bespoke additive/breaking generation counter, not the
|
|
30
|
+
* generic save-history surface) — so it stays deferred like every other non-versioned kind. This
|
|
31
|
+
* field carries no meaning for `content-mcp` itself (an external agent's write always executes
|
|
32
|
+
* directly, immediately, regardless of tier); it exists here only so this file stays the one place
|
|
33
|
+
* that states the fact, mirrored server-side by `ManagementToolCatalog.ContentWriteImmediateKinds`
|
|
34
|
+
* and held in parity by `tool-catalogue.json`.
|
|
35
|
+
*/
|
|
36
|
+
export declare const CONTENT_WRITE_IMMEDIATE_KINDS: readonly ["component", "node", "nodePayload"];
|
|
24
37
|
export type ToolDescriptor = {
|
|
25
38
|
name: string;
|
|
26
39
|
requiredScope: string;
|
|
27
40
|
readOnly: boolean;
|
|
28
41
|
/** Present only for the three tools whose `kind` parameter is drawn from `WRITABLE_KINDS`. */
|
|
29
42
|
kinds?: readonly EntityKind[];
|
|
43
|
+
/** Present only for `content_write` — see {@link CONTENT_WRITE_IMMEDIATE_KINDS}. */
|
|
44
|
+
immediateKinds?: readonly EntityKind[];
|
|
30
45
|
};
|
|
31
46
|
export declare const TOOL_CATALOG: readonly ToolDescriptor[];
|
|
32
47
|
/** Whether `session` may see the named tool, per the catalogue's `requiredScope`. */
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"catalog.d.ts","sourceRoot":"","sources":["../../src/tools/catalog.ts"],"names":[],"mappings":"AAAA,OAAO,EAAkB,KAAK,UAAU,EAAE,MAAM,cAAc,CAAA;AAG9D;;;;;;;;;;;;GAYG;AAEH;;;;;;;GAOG;AACH,eAAO,MAAM,aAAa,EAAG,GAAY,CAAA;AAEzC,MAAM,MAAM,cAAc,GAAG;IAC3B,IAAI,EAAE,MAAM,CAAA;IACZ,aAAa,EAAE,MAAM,CAAA;IACrB,QAAQ,EAAE,OAAO,CAAA;IACjB,8FAA8F;IAC9F,KAAK,CAAC,EAAE,SAAS,UAAU,EAAE,CAAA;
|
|
1
|
+
{"version":3,"file":"catalog.d.ts","sourceRoot":"","sources":["../../src/tools/catalog.ts"],"names":[],"mappings":"AAAA,OAAO,EAAkB,KAAK,UAAU,EAAE,MAAM,cAAc,CAAA;AAG9D;;;;;;;;;;;;GAYG;AAEH;;;;;;;GAOG;AACH,eAAO,MAAM,aAAa,EAAG,GAAY,CAAA;AAEzC;;;;;;;;;;;GAWG;AACH,eAAO,MAAM,6BAA6B,+CAAgD,CAAA;AAE1F,MAAM,MAAM,cAAc,GAAG;IAC3B,IAAI,EAAE,MAAM,CAAA;IACZ,aAAa,EAAE,MAAM,CAAA;IACrB,QAAQ,EAAE,OAAO,CAAA;IACjB,8FAA8F;IAC9F,KAAK,CAAC,EAAE,SAAS,UAAU,EAAE,CAAA;IAC7B,oFAAoF;IACpF,cAAc,CAAC,EAAE,SAAS,UAAU,EAAE,CAAA;CACvC,CAAA;AAED,eAAO,MAAM,YAAY,EAAE,SAAS,cAAc,EAqBxC,CAAA;AAQV,qFAAqF;AACrF,wBAAgB,aAAa,CAAC,OAAO,EAAE;IAAE,GAAG,CAAC,KAAK,EAAE,MAAM,GAAG,OAAO,CAAA;CAAE,EAAE,QAAQ,EAAE,MAAM,GAAG,OAAO,CAGjG"}
|
package/dist/tools/catalog.js
CHANGED
|
@@ -22,6 +22,19 @@ import { SCOPE_AUTHORING, SCOPE_PUBLISH, SCOPE_READ } from '../session.js';
|
|
|
22
22
|
* key acquiring one.
|
|
23
23
|
*/
|
|
24
24
|
export const AUTHENTICATED = '*';
|
|
25
|
+
/**
|
|
26
|
+
* The three entity kinds `content_write` may commit immediately from the in-app assistant (spec
|
|
27
|
+
* 939-ai-inline-assistant) rather than as a deferred suggestion: `component` and `node` implement
|
|
28
|
+
* `IVersionedEntity` server-side; `nodePayload` writes the same `ExperienceNode` row through its own
|
|
29
|
+
* route (`PUT /experience/nodes/{id}/payload`) and so qualifies too. `contract` does **not** — it
|
|
30
|
+
* implements only `IConcurrencyProtected` (a bespoke additive/breaking generation counter, not the
|
|
31
|
+
* generic save-history surface) — so it stays deferred like every other non-versioned kind. This
|
|
32
|
+
* field carries no meaning for `content-mcp` itself (an external agent's write always executes
|
|
33
|
+
* directly, immediately, regardless of tier); it exists here only so this file stays the one place
|
|
34
|
+
* that states the fact, mirrored server-side by `ManagementToolCatalog.ContentWriteImmediateKinds`
|
|
35
|
+
* and held in parity by `tool-catalogue.json`.
|
|
36
|
+
*/
|
|
37
|
+
export const CONTENT_WRITE_IMMEDIATE_KINDS = ['component', 'node', 'nodePayload'];
|
|
25
38
|
export const TOOL_CATALOG = [
|
|
26
39
|
{ name: 'content_whoami', requiredScope: AUTHENTICATED, readOnly: true },
|
|
27
40
|
{ name: 'content_describe', requiredScope: SCOPE_READ, readOnly: true },
|
|
@@ -29,7 +42,13 @@ export const TOOL_CATALOG = [
|
|
|
29
42
|
{ name: 'content_get', requiredScope: SCOPE_READ, readOnly: true, kinds: WRITABLE_KINDS },
|
|
30
43
|
{ name: 'content_topology', requiredScope: SCOPE_READ, readOnly: true },
|
|
31
44
|
{ name: 'content_operation_status', requiredScope: SCOPE_READ, readOnly: true },
|
|
32
|
-
{
|
|
45
|
+
{
|
|
46
|
+
name: 'content_write',
|
|
47
|
+
requiredScope: SCOPE_AUTHORING,
|
|
48
|
+
readOnly: false,
|
|
49
|
+
kinds: WRITABLE_KINDS,
|
|
50
|
+
immediateKinds: CONTENT_WRITE_IMMEDIATE_KINDS,
|
|
51
|
+
},
|
|
33
52
|
{ name: 'content_delete', requiredScope: SCOPE_AUTHORING, readOnly: false, kinds: WRITABLE_KINDS },
|
|
34
53
|
{ name: 'content_publish', requiredScope: SCOPE_PUBLISH, readOnly: false },
|
|
35
54
|
// Corrected from SCOPE_WRITE (spec 887): the tool's own always-executed first call, /export,
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"catalog.js","sourceRoot":"","sources":["../../src/tools/catalog.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,cAAc,EAAmB,MAAM,cAAc,CAAA;AAC9D,OAAO,EAAE,eAAe,EAAE,aAAa,EAAE,UAAU,EAAE,MAAM,eAAe,CAAA;AAE1E;;;;;;;;;;;;GAYG;AAEH;;;;;;;GAOG;AACH,MAAM,CAAC,MAAM,aAAa,GAAG,GAAY,CAAA;
|
|
1
|
+
{"version":3,"file":"catalog.js","sourceRoot":"","sources":["../../src/tools/catalog.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,cAAc,EAAmB,MAAM,cAAc,CAAA;AAC9D,OAAO,EAAE,eAAe,EAAE,aAAa,EAAE,UAAU,EAAE,MAAM,eAAe,CAAA;AAE1E;;;;;;;;;;;;GAYG;AAEH;;;;;;;GAOG;AACH,MAAM,CAAC,MAAM,aAAa,GAAG,GAAY,CAAA;AAEzC;;;;;;;;;;;GAWG;AACH,MAAM,CAAC,MAAM,6BAA6B,GAAG,CAAC,WAAW,EAAE,MAAM,EAAE,aAAa,CAAU,CAAA;AAY1F,MAAM,CAAC,MAAM,YAAY,GAA8B;IACrD,EAAE,IAAI,EAAE,gBAAgB,EAAE,aAAa,EAAE,aAAa,EAAE,QAAQ,EAAE,IAAI,EAAE;IACxE,EAAE,IAAI,EAAE,kBAAkB,EAAE,aAAa,EAAE,UAAU,EAAE,QAAQ,EAAE,IAAI,EAAE;IACvE,EAAE,IAAI,EAAE,cAAc,EAAE,aAAa,EAAE,UAAU,EAAE,QAAQ,EAAE,IAAI,EAAE;IACnE,EAAE,IAAI,EAAE,aAAa,EAAE,aAAa,EAAE,UAAU,EAAE,QAAQ,EAAE,IAAI,EAAE,KAAK,EAAE,cAAc,EAAE;IACzF,EAAE,IAAI,EAAE,kBAAkB,EAAE,aAAa,EAAE,UAAU,EAAE,QAAQ,EAAE,IAAI,EAAE;IACvE,EAAE,IAAI,EAAE,0BAA0B,EAAE,aAAa,EAAE,UAAU,EAAE,QAAQ,EAAE,IAAI,EAAE;IAC/E;QACE,IAAI,EAAE,eAAe;QACrB,aAAa,EAAE,eAAe;QAC9B,QAAQ,EAAE,KAAK;QACf,KAAK,EAAE,cAAc;QACrB,cAAc,EAAE,6BAA6B;KAC9C;IACD,EAAE,IAAI,EAAE,gBAAgB,EAAE,aAAa,EAAE,eAAe,EAAE,QAAQ,EAAE,KAAK,EAAE,KAAK,EAAE,cAAc,EAAE;IAClG,EAAE,IAAI,EAAE,iBAAiB,EAAE,aAAa,EAAE,aAAa,EAAE,QAAQ,EAAE,KAAK,EAAE;IAC1E,6FAA6F;IAC7F,8FAA8F;IAC9F,iGAAiG;IACjG,6FAA6F;IAC7F,EAAE,IAAI,EAAE,kBAAkB,EAAE,aAAa,EAAE,UAAU,EAAE,QAAQ,EAAE,KAAK,EAAE;CAChE,CAAA;AAEV,SAAS,aAAa,CAAC,IAAY;IACjC,MAAM,UAAU,GAAG,YAAY,CAAC,IAAI,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,IAAI,CAAC,IAAI,KAAK,IAAI,CAAC,CAAA;IAClE,IAAI,CAAC,UAAU;QAAE,MAAM,IAAI,KAAK,CAAC,8BAA8B,IAAI,8BAA8B,CAAC,CAAA;IAClG,OAAO,UAAU,CAAA;AACnB,CAAC;AAED,qFAAqF;AACrF,MAAM,UAAU,aAAa,CAAC,OAAwC,EAAE,QAAgB;IACtF,MAAM,EAAE,aAAa,EAAE,GAAG,aAAa,CAAC,QAAQ,CAAC,CAAA;IACjD,OAAO,aAAa,KAAK,aAAa,IAAI,OAAO,CAAC,GAAG,CAAC,aAAa,CAAC,CAAA;AACtE,CAAC"}
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@ebitex/content-mcp",
|
|
3
|
-
"version": "0.5.
|
|
3
|
+
"version": "0.5.129",
|
|
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/",
|