@ebitex/content-mcp 0.5.165 → 0.5.177

package/dist/resources/helpCorpus.generated.js

@@ -51,7 +51,7 @@ export const HELP_TOPICS = [
     {
         "slug": "content-providers",
         "title": "Content providers",
-        "body": "# Content providers\n\nContent providers let you bring in read-only content from an external system — a product catalog,\na digital asset manager, anything a plugin has been built for — so it sits alongside your own\nComponents everywhere you'd normally reference one: Reference fields, Presentation bindings,\npublished pages.\n\n## Registering a provider\n\nOpen **Plugins** under **Settings** in the app navigation, then select **Add plugin**. A content provider is one *type* of plugin; the **Type** list is where you choose it. Adding requires a plugin to\nalready be **activated** for your organization (an administrator does this from Hub's plugin\nsettings first — this page just registers an *instance* of an already-activated plugin).\n\n1. Choose **Content provider** as the **Type**, then the plugin from the **Plugin** dropdown.\n2. Give it a **name**, which is its **provider key** — a short, lowercase, hyphenated name (e.g. `example-products`).\n   This becomes part of every reference stored against items from this provider, so **choose it\n   once and don't expect to rename it later**; changing your mind means removing the plugin and\n   adding it again under a new key.\n3. Fill in whatever configuration the plugin asks for — this varies per plugin, and any field\n   marked sensitive (an API key, say) is write-only: once saved, you'll only ever see that it's\n   set, never the value itself.\n4. Set a **cache TTL** — how long (in seconds) a fetched item is reused before Content checks the\n   external system again when serving published content. Lower values mean fresher data with more\n   load on the external system; higher values mean better performance but slower-to-appear\n   changes.\n5. Select **Add plugin**. Content contacts the provider and pulls in the Contracts (content types)\n   it describes — you'll see them show up in the Contract library, badged with the provider's\n   name.\n\nIf your organization authors in more than one environment and a provider is already registered in\none of them, use **Copy from another environment** instead of registering from scratch — pick the\nsource environment and the provider key, and its full configuration (including anything sensitive)\ncomes along without you re-entering it. See [content-environments.md](content-environments.md).\n\n## Using provider content\n\nWherever you can pick a Component — a Reference field, or a Presentation's bound Component — the\npicker now shows a row of tabs: **Core** (your own content) plus one tab per registered provider.\nSwitch tabs to browse or search that provider's items; not every provider supports search, in\nwhich case the search box is disabled for that tab. Once picked, an external item behaves like any\nother reference: you can still add your own decoration on top of it (a headline, a promotional\nlabel — whatever the provider's Contract declares as an editable-here field) without touching the\nexternal system at all.\n\nIf an external item is later removed on the provider's side, or the provider becomes temporarily\nunreachable, the reference shows as unresolved rather than blocking your save — you can fix it\nwhenever the item (or the provider) is available again.\n\n## Registering your Assets library\n\nIf your organization uses Assets, register it like any other provider and pick **ebitex Assets** as\nthe plugin. It asks for one thing, an **API key**. Mint that key in Assets under **Settings →\nChannels**, on the channel you want this registration to see. What the key can see is decided there,\nnot in Content: the channel's folders, its categories, and whether private assets are included. Use a\nseparate registration, with its own channel's key, for each site or audience that should see a\ndifferent slice of the library.\n\nOnce registered, a Reference field can be limited to **Image**, **Video** or **Document**, and the\npicker's Assets tab shows only those, with a thumbnail and a line such as \"Image · 1600×900 · de\nrendition\". A field that lists an Assets type must allow **Reference** (not only inline). See\n[Assets](../assets/library.md) for the library itself.\n\nA change you make in Assets reaches published pages without republishing, after a short delay: the\ncache TTL above plus the delivery cache. Deleting an asset turns every reference to it into an\nunresolved one.\n\n## Refreshing and removing\n\nProvider Contracts don't update automatically — select **Refresh Contracts** on a registration\nwhenever the external system's own content types have changed. Refreshing can add new Contracts,\nupdate existing ones, and remove ones no longer described (removal is blocked if something still\ndepends on it — a Reference field constraint or a Template's supported-Contracts list — with the\nusages listed so you can address them first).\n\n**Remove** takes a provider out entirely, along with its synced Contracts — blocked the same\nway if any content still references it. Once you confirm, existing references to that provider\nkey become permanently unresolved.\n\n## Permissions\n\nAdding, editing, refreshing, and removing providers requires its own \"Manage Content\nproviders\" permission — ask an Owner or administrator to grant it if the add/refresh/\nremove actions aren't available to you. Anyone with organization membership can view\nregistered providers and use them in a picker.\n"
+        "body": "# Content providers\n\nContent providers let you bring in read-only content from an external system — a product catalog,\na digital asset manager, anything a plugin has been built for — so it sits alongside your own\nComponents everywhere you'd normally reference one: Reference fields, Presentation bindings,\npublished pages.\n\n## Registering a provider\n\nOpen **Plugins** under **Settings** in the app navigation, then select **Add plugin**. A content provider is one *type* of plugin; the **Type** list is where you choose it. Adding requires a plugin to\nalready be **activated** for your organization (an administrator does this from Hub's plugin\nsettings first — this page just registers an *instance* of an already-activated plugin).\n\n1. Choose **Content provider** as the **Type**, then the plugin from the **Plugin** dropdown.\n2. Give it a **name**, which is its **provider key** — a short, lowercase, hyphenated name (e.g. `example-products`).\n   This becomes part of every reference stored against items from this provider, so **choose it\n   once and don't expect to rename it later**; changing your mind means removing the plugin and\n   adding it again under a new key.\n3. Fill in whatever configuration the plugin asks for — this varies per plugin, and any field\n   marked sensitive (an API key, say) is write-only: once saved, you'll only ever see that it's\n   set, never the value itself.\n4. Set a **cache TTL** — how long (in seconds) a fetched item is reused before Content checks the\n   external system again when serving published content. Lower values mean fresher data with more\n   load on the external system; higher values mean better performance but slower-to-appear\n   changes.\n5. Select **Add plugin**. Content contacts the provider and pulls in the Contracts (content types)\n   it describes — you'll see them show up in the Contract library, badged with the provider's\n   name.\n\nIf your organization authors in more than one environment and a provider is already registered in\none of them, use **Copy from another environment** instead of registering from scratch — pick the\nsource environment and the provider key, and its full configuration (including anything sensitive)\ncomes along without you re-entering it. See [content-environments.md](content-environments.md).\n\n## Using provider content\n\nWherever you can pick a Component — a Reference field, or a Presentation's bound Component — the\npicker now shows a row of tabs: **Core** (your own content) plus one tab per registered provider.\nSwitch tabs to browse or search that provider's items; not every provider supports search, in\nwhich case the search box is disabled for that tab. Once picked, an external item behaves like any\nother reference: you can still add your own decoration on top of it (a headline, a promotional\nlabel — whatever the provider's Contract declares as an editable-here field) without touching the\nexternal system at all.\n\nIf an external item is later removed on the provider's side, or the provider becomes temporarily\nunreachable, the reference shows as unresolved rather than blocking your save — you can fix it\nwhenever the item (or the provider) is available again.\n\n## Registering your Assets library\n\nIf your organization uses Assets, register it like any other provider and pick **ebitex Assets** as\nthe plugin. It asks for one thing, an **API key**. Mint that key in Assets under **Settings →\nChannels**, on the channel you want this registration to see. What the key can see is decided there,\nnot in Content: the channel's folders, its categories, and whether private assets are included. Use a\nseparate registration, with its own channel's key, for each site or audience that should see a\ndifferent slice of the library.\n\nOnce registered, a Reference field can be limited to **Image**, **Video** or **Document**, and the\npicker's Assets tab shows only those, with a thumbnail and a line such as \"Image · 1600×900 · de\nrendition\". A field that lists an Assets type must allow **Reference** (not only inline). See\n[Assets](../assets/library.md) for the library itself.\n\nA change you make in Assets reaches published pages without republishing, after a short delay: the\ncache TTL above plus the delivery cache. Deleting an asset turns every reference to it into an\nunresolved one.\n\n## Registering your Data records\n\nIf your organization uses Data, pick **ebitex Data** as the plugin. It asks for two things: a **delivery key**\nand the **partition** that key reads (its key, for example `drakeshead`). Mint the key in Data under **Settings →\nDelivery keys**, as a server key. Registering checks that the partition you typed is the one the key reads and\nrefuses it otherwise, so a typo cannot point a page at the wrong data.\n\nEach Data model appears as a read-only Contract, and a Reference field can point at one of its records. Shapes\nContent cannot describe on its own, such as a reference from one record to another, come through whole and\nunchanged. A change you make in Data reaches published pages after a short delay (the cache TTL above plus the\ndelivery cache).\n\n**A record a page points at cannot be deleted in Data.** The delete is refused and the pages are listed, in every\nenvironment of your organization. Remove the reference from those pages first. If Content cannot be checked at that\nmoment the delete is refused too, with a message to try again, rather than risk leaving a page with a missing\nrecord.\n\n## Refreshing and removing\n\nProvider Contracts don't update automatically — select **Refresh Contracts** on a registration\nwhenever the external system's own content types have changed. Refreshing can add new Contracts,\nupdate existing ones, and remove ones no longer described (removal is blocked if something still\ndepends on it — a Reference field constraint or a Template's supported-Contracts list — with the\nusages listed so you can address them first).\n\n**Remove** takes a provider out entirely, along with its synced Contracts — blocked the same\nway if any content still references it. Once you confirm, existing references to that provider\nkey become permanently unresolved.\n\n## Permissions\n\nAdding, editing, refreshing, and removing providers requires its own \"Manage Content\nproviders\" permission — ask an Owner or administrator to grant it if the add/refresh/\nremove actions aren't available to you. Anyone with organization membership can view\nregistered providers and use them in a picker.\n"
     },
     {
         "slug": "content-streams",
@@ -101,7 +101,7 @@ export const HELP_TOPICS = [
     {
         "slug": "proposals",
         "title": "Proposals",
-        "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**A name sent for a link.** A form often sends a link field as just a name, for example a choice from a list of known people. That arrives as plain text beside the form, and the same **Possible matches** panel searches the existing items the field allows for it. If exactly one existing item has exactly that name (capital letters and spaces at the ends are ignored), it is linked for you, and the panel says **Matched … by name**. **Undo** empties the field, and it is not linked again. If two items share the name, or the only hits are similar names, nothing is linked and you choose.\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. The proposal is kept, and records which Component it became.\n\nIf you can publish in that folder, an **Approve and publish** button appears beside Approve (it\nshows a moment after the page loads, once your access has been checked). It approves, then opens the\nusual Publish dialog for the new Component, and nothing goes live until you confirm there. Closing\nthe dialog leaves the Component as a Draft.\n\nAfter approving, the page shows an **Approved** card saying whether the Component was published,\nwith **Open Component** to go straight to it, **Publish** if it is still a Draft, and **Back to\nproposals**.\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"
+        "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**A name sent for a link.** A form often sends a link field as just a name, for example a choice from a list of known people. That arrives as plain text beside the form, and the same **Possible matches** panel searches the existing items the field allows for it. If exactly one existing item has exactly that name (capital letters and spaces at the ends are ignored), it is linked for you, and the panel says **Matched … by name**. **Undo** empties the field, and it is not linked again. If two items share the name, or the only hits are similar names, nothing is linked and you choose.\n\n**When the items live in a connected service.** A field can allow items that a connected service holds, such as a record in Data or a file in Assets, rather than items in Content itself. The panel then searches that service instead, using the service's own search (Data finds names that **start with** what was sent, so a name typed from the middle of a longer one is not found). A choice list backed by such a service sends the item's **key** rather than its name, so if exactly one item of an allowed type has exactly that key, it is linked for you and the panel says **Matched … by key**. An item of a type the field does not allow is never linked this way. If the service cannot be reached the panel stays out of the way and you choose the item yourself.\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. The proposal is kept, and records which Component it became.\n\nIf you can publish in that folder, an **Approve and publish** button appears beside Approve (it\nshows a moment after the page loads, once your access has been checked). It approves, then opens the\nusual Publish dialog for the new Component, and nothing goes live until you confirm there. Closing\nthe dialog leaves the Component as a Draft.\n\nAfter approving, the page shows an **Approved** card saying whether the Component was published,\nwith **Open Component** to go straight to it, **Publish** if it is still a Draft, and **Back to\nproposals**.\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"
     },
     {
         "slug": "publishing",

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

@@ -1 +1 @@
-{"version":3,"file":"helpCorpus.generated.js","sourceRoot":"","sources":["../../src/resources/helpCorpus.generated.ts"],"names":[],"mappings":"AAAA,qDAAqD;AACrD,EAAE;AACF,kGAAkG;AAClG,oGAAoG;AAIpG,MAAM,CAAC,MAAM,WAAW,GAAgB;IACtC;QACE,MAAM,EAAE,iBAAiB;QACzB,OAAO,EAAE,0CAA0C;QACnD,MAAM,EAAE,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,y7vBAAy7vB;KACl8vB;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,kCAAkC;QAC3C,MAAM,EAAE,06nBAA06nB;KACn7nB;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,0BAA0B;QACnC,MAAM,EAAE,6oLAA6oL;KACtpL;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,gCAAgC;QACzC,MAAM,EAAE,2zqBAA2zqB;KACp0qB;IACD;QACE,MAAM,EAAE,sBAAsB;QAC9B,OAAO,EAAE,sBAAsB;QAC/B,MAAM,EAAE,k/qBAAk/qB;KAC3/qB;IACD;QACE,MAAM,EAAE,eAAe;QACvB,OAAO,EAAE,qCAAqC;QAC9C,MAAM,EAAE,q3FAAq3F;KAC93F;IACD;QACE,MAAM,EAAE,yBAAyB;QACjC,OAAO,EAAE,4BAA4B;QACrC,MAAM,EAAE,2jRAA2jR;KACpkR;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,mBAAmB;QAC5B,MAAM,EAAE,ywKAAywK;KAClxK;IACD;QACE,MAAM,EAAE,iBAAiB;QACzB,OAAO,EAAE,4CAA4C;QACrD,MAAM,EAAE,22GAA22G;KACp3G;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,UAAU;QACnB,MAAM,EAAE,moQAAmoQ;KAC5oQ;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,oBAAoB;QAC7B,MAAM,EAAE,+9XAA+9X;KACx+X;IACD;QACE,MAAM,EAAE,WAAW;QACnB,OAAO,EAAE,iCAAiC;QAC1C,MAAM,EAAE,46lBAA46lB;KACr7lB;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,MAAM;QACd,OAAO,EAAE,MAAM;QACf,MAAM,EAAE,y9FAAy9F;KACl+F;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,mBAAmB;QAC5B,MAAM,EAAE,upIAAupI;KAChqI;IACD;QACE,MAAM,EAAE,iBAAiB;QACzB,OAAO,EAAE,iBAAiB;QAC1B,MAAM,EAAE,ugNAAugN;KAChhN;IACD;QACE,MAAM,EAAE,WAAW;QACnB,OAAO,EAAE,WAAW;QACpB,MAAM,EAAE,w/OAAw/O;KACjgP;IACD;QACE,MAAM,EAAE,YAAY;QACpB,OAAO,EAAE,oBAAoB;QAC7B,MAAM,EAAE,i4YAAi4Y;KAC14Y;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,+BAA+B;QACxC,MAAM,EAAE,g2EAAg2E;KACz2E;IACD;QACE,MAAM,EAAE,OAAO;QACf,OAAO,EAAE,OAAO;QAChB,MAAM,EAAE,i7FAAi7F;KAC17F;IACD;QACE,MAAM,EAAE,WAAW;QACnB,OAAO,EAAE,mCAAmC;QAC5C,MAAM,EAAE,g8KAAg8K;KACz8K;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,kBAAkB;QAC3B,MAAM,EAAE,yvJAAyvJ;KAClwJ;CACF,CAAA"}
+{"version":3,"file":"helpCorpus.generated.js","sourceRoot":"","sources":["../../src/resources/helpCorpus.generated.ts"],"names":[],"mappings":"AAAA,qDAAqD;AACrD,EAAE;AACF,kGAAkG;AAClG,oGAAoG;AAIpG,MAAM,CAAC,MAAM,WAAW,GAAgB;IACtC;QACE,MAAM,EAAE,iBAAiB;QACzB,OAAO,EAAE,0CAA0C;QACnD,MAAM,EAAE,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,y7vBAAy7vB;KACl8vB;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,kCAAkC;QAC3C,MAAM,EAAE,06nBAA06nB;KACn7nB;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,0BAA0B;QACnC,MAAM,EAAE,6oLAA6oL;KACtpL;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,gCAAgC;QACzC,MAAM,EAAE,2zqBAA2zqB;KACp0qB;IACD;QACE,MAAM,EAAE,sBAAsB;QAC9B,OAAO,EAAE,sBAAsB;QAC/B,MAAM,EAAE,k/qBAAk/qB;KAC3/qB;IACD;QACE,MAAM,EAAE,eAAe;QACvB,OAAO,EAAE,qCAAqC;QAC9C,MAAM,EAAE,q3FAAq3F;KAC93F;IACD;QACE,MAAM,EAAE,yBAAyB;QACjC,OAAO,EAAE,4BAA4B;QACrC,MAAM,EAAE,2jRAA2jR;KACpkR;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,mBAAmB;QAC5B,MAAM,EAAE,44MAA44M;KACr5M;IACD;QACE,MAAM,EAAE,iBAAiB;QACzB,OAAO,EAAE,4CAA4C;QACrD,MAAM,EAAE,22GAA22G;KACp3G;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,UAAU;QACnB,MAAM,EAAE,moQAAmoQ;KAC5oQ;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,oBAAoB;QAC7B,MAAM,EAAE,+9XAA+9X;KACx+X;IACD;QACE,MAAM,EAAE,WAAW;QACnB,OAAO,EAAE,iCAAiC;QAC1C,MAAM,EAAE,46lBAA46lB;KACr7lB;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,MAAM;QACd,OAAO,EAAE,MAAM;QACf,MAAM,EAAE,y9FAAy9F;KACl+F;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,mBAAmB;QAC5B,MAAM,EAAE,upIAAupI;KAChqI;IACD;QACE,MAAM,EAAE,iBAAiB;QACzB,OAAO,EAAE,iBAAiB;QAC1B,MAAM,EAAE,ugNAAugN;KAChhN;IACD;QACE,MAAM,EAAE,WAAW;QACnB,OAAO,EAAE,WAAW;QACpB,MAAM,EAAE,kvQAAkvQ;KAC3vQ;IACD;QACE,MAAM,EAAE,YAAY;QACpB,OAAO,EAAE,oBAAoB;QAC7B,MAAM,EAAE,i4YAAi4Y;KAC14Y;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,+BAA+B;QACxC,MAAM,EAAE,g2EAAg2E;KACz2E;IACD;QACE,MAAM,EAAE,OAAO;QACf,OAAO,EAAE,OAAO;QAChB,MAAM,EAAE,i7FAAi7F;KAC17F;IACD;QACE,MAAM,EAAE,WAAW;QACnB,OAAO,EAAE,mCAAmC;QAC5C,MAAM,EAAE,g8KAAg8K;KACz8K;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,kBAAkB;QAC3B,MAAM,EAAE,yvJAAyvJ;KAClwJ;CACF,CAAA"}

package/package.json

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