@ebitex/content-mcp 0.5.106 → 0.5.110

package/dist/resources/helpCorpus.generated.js

@@ -66,7 +66,7 @@ export const HELP_TOPICS = [
     {
         "slug": "content-workflow",
         "title": "Editorial workflow",
-        "body": "# Editorial workflow\n\nA workflow adds a review step in front of publishing: assign one to a folder or a section of your\nExperience tree, and content there can't go live until someone carries it through the review states\nyou've defined. Nothing changes anywhere you haven't assigned a workflow — publishing works exactly\nas it always has.\n\n## Creating a workflow\n\nOpen **Workflow** under **Configure** in the app navigation and choose **New workflow**. First pick\nthe workflow's **kind** — what this workflow governs. It can't be changed after creation:\n\n- **Publishing workflow** — governs a Component or page: Draft → your review steps → Approved,\n  where Approved is the only state publishing is allowed from.\n- **Translation workflow** — governs a translation job's proposed values before they're written\n  into the Component. See [Translation jobs](translation-jobs.md) for how to kick one off and\n  review its results.\n- **Proposal review** — governs content offered from outside your organization, by a form or by\n  another system, before any of it becomes a Component. See [Proposals](proposals.md).\n\nA workflow's states come from its kind, and each state's meaning is fixed — shown on the node as\nbadges and a one-line description, never as switches you configure:\n\n- **Anchor states** (marked STATE · ANCHOR) are placed for you and can't be deleted or renamed —\n  for a publishing workflow, **Draft** (where authors work freely) and **Approved** (locked, and\n  the one publishable state).\n- **Step templates** are the states you add yourself, as many as you need: a **Review step**\n  (content is locked while the reviewer decides) or a **Rework step** (back with the author,\n  editable again). The name is yours — add two Review steps called \"Editorial review\" and \"Legal\n  review\" for a two-stage approval, each with its own approver role on its transition.\n\nGive the workflow a name, then wire the graph:\n\n- **Add a step**: **+ Add node**, pick a step template, and type its name on the node.\n- **Connect two states into a transition**: every state has a small connector on each of its four\n  sides — click one, then click a connector on the state you want to connect it to (or drag from\n  one to the other). Click the new transition's label to name it and, optionally, restrict who may\n  fire it to specific role ids (find a role's id on Hub's Roles page) — leave it blank to let any\n  organization member fire it. A state without any wiring simply never occurs — there's no way to\n  reach it. A state whose outcome ends the flow — a translation workflow's **Approved** and\n  **Rejected** — still shows all four of its connectors, but only to receive an *incoming*\n  transition: there's nothing to drag or click to start one from it, since it can never be the\n  source of an outgoing transition. (A publishing workflow has no such state — even **Approved**\n  can have an outgoing transition, such as a \"Revert to draft\" step, if you wire one.)\n- Every state shows how many items are **currently sitting in it** — a live count that updates as\n  people submit, approve, and reject.\n\nOpen an existing workflow from the list to edit its graph the same way. A structural change (adding\nor removing states or transitions) is blocked while any item has an active review in progress — the\nerror explains this; renaming the workflow and editing attached actions (below) are always allowed\nregardless.\n\n## Attaching a Notify or Webhook to a state or transition\n\nBeyond states and transitions, the canvas offers two action node kinds via the same **+ Add node**\nmenu:\n\n- **Notify** — pick a channel (email or in-app) and one or more recipients. **This doesn't send\n  anything yet** — no notification channel is configured for this organization. The attempt is still\n  recorded (see Activity Log below), so you can see exactly when it *would* have fired once sending\n  is available.\n- **Webhook** — a URL your own system controls. This one is real: it actually `POST`s the transition\n  details to that URL. A URL that resolves to a private or internal address is rejected when you try\n  to save it.\n\nAttach either one to a **state** (fires the moment an item enters that state — click one of the\naction's own connectors, then one of the state's) or to a **transition** (fires the moment that\ntransition is used — click the action's connector, then the transition's own label). An action must\nbe attached to something before you can save. A Notify or Webhook never blocks the review itself —\neven if a webhook fails, the transition still goes through; the failure is just recorded.\n\n## Assigning a workflow to a branch\n\nOpen a folder's (or an Experience node's) **governance panel** — the same place you manage access\nrules — and find the **Editorial workflow** section. Choose a workflow from the dropdown, or:\n\n- **Inherit from ancestor** — use whatever the nearest parent branch has assigned (or nothing, if\n  none does). This is the default for every branch.\n- **None (explicit)** — opt this branch and everything beneath it out of review, even if a parent\n  branch has a workflow assigned. Useful for a sub-folder that should publish freely while the rest\n  of the section stays gated.\n\n### One assignment per kind\n\nA branch carries a separate assignment for each kind, so a folder can be gated for publishing,\ngated for proposals, and ungoverned for translation all at once. Each has its own picker, and each\ninherits down the tree independently:\n\n- **Editorial workflow** — on folders and on Experience nodes.\n- **Proposal review** and **Translation review** — on folders only, since both are resolved from\n  the folder an item lives in and neither has anything to do with a page's address.\n\nA kind's picker only appears once you have at least one workflow of that kind, which is why a folder\nyou have never used proposals on shows just the one section.\n\n**What \"none\" means differs by kind**, and each picker says which:\n\n| Kind | With no workflow assigned |\n|---|---|\n| Editorial workflow | Content publishes without review |\n| Proposal review | Offers to that folder are **refused** — there would be nobody to review them |\n| Translation review | Translation jobs apply their translations without review |\n\n## Submitting and reviewing\n\nOpen a Component (under its **Settings** tab) or an Experience node under a governed branch and\nyou'll see a workflow panel showing its current state. If it's still in a non-publishable state,\nthe **Publish** button — always visible in the Component editor's header, regardless of which tab\nyou're on — is disabled and explains why.\n\nSelect an available transition (e.g. **Submit for review**), optionally add a comment, and confirm.\nWhile an item sits in a **Review step** or in **Approved**, its content is locked — what was\nreviewed is exactly what publishes. If a reviewer sends it to a **Rework step**, it's editable\nagain while the review stays open; the review tracks the version you submitted, and if you edit\nduring rework, the panel tells you the item has moved past the reviewed version.\n\nOnce it reaches a publishable state, **Publish** works as normal — it publishes the reviewed\nversion and marks the review complete. If someone edited the item after submission, it will show as\n\"Modified since publish\" immediately, since the head and the published version now differ — that's\nexpected, not an error.\n\nA reviewer sees the same panel with **Approve**/**Reject** buttons (only the transitions their role\nis allowed to perform are enabled). Rejecting sends it back to the start with the reviewer's comment\nattached, and it can be resubmitted. Resubmitting while a review is already in progress starts a\nfresh one, pinned to your latest version.\n\nYou (or anyone with access-management permission) can cancel an in-progress review from the same\npanel.\n\n## Permissions\n\nCreating, renaming, and deleting workflow definitions requires its own \"Manage Content workflows\"\npermission. Assigning a workflow to a branch is governed by the same permission as access rules\n(\"Manage access\"), since it's branch governance, not workflow authoring. Submitting for review\nrequires edit access on the branch; approving/rejecting is limited to whichever role(s) the\ntransition names (or anyone, if none are named) — an access-management holder can always advance a\nstuck review.\n\n## Activity Log\n\nEvery submission, approval, rejection, and cancellation appears in Hub's Activity Log with the\nactor and any comment attached — the review trail is part of your organization's audit history.\nAttached Notify and Webhook actions appear there too, one entry per attempt: a Webhook shows the URL\nand the response it got back (or that it failed); a Notify always shows \"not delivered (no\nnotification channel configured)\" — the reminder that it's recorded, not sent, until this\norganization has a notification channel set up.\n"
+        "body": "# Editorial workflow\n\nA workflow adds a review step in front of publishing: assign one to a folder or a section of your\nExperience tree, and content there can't go live until someone carries it through the review states\nyou've defined. Nothing changes anywhere you haven't assigned a workflow — publishing works exactly\nas it always has.\n\n## Creating a workflow\n\nOpen **Workflow** under **Configure** in the app navigation and choose **New workflow**. First pick\nthe workflow's **kind** — what this workflow governs. It can't be changed after creation:\n\n- **Publishing workflow** — governs a Component or page: Draft → your review steps → Approved,\n  where Approved is the only state publishing is allowed from.\n- **Translation workflow** — governs a translation job's proposed values before they're written\n  into the Component. See [Translation jobs](translation-jobs.md) for how to kick one off and\n  review its results.\n- **Proposal review** — governs content offered from outside your organization, by a form or by\n  another system, before any of it becomes a Component. See [Proposals](proposals.md).\n\nA workflow's states come from its kind, and each state's meaning is fixed — shown on the node as\nbadges and a one-line description, never as switches you configure:\n\n- **Anchor states** (marked STATE · ANCHOR) are placed for you and can't be deleted or renamed —\n  for a publishing workflow, **Draft** (where authors work freely) and **Approved** (locked, and\n  the one publishable state).\n- **Step templates** are the states you add yourself, as many as you need: a **Review step**\n  (content is locked while the reviewer decides) or a **Rework step** (back with the author,\n  editable again). The name is yours — add two Review steps called \"Editorial review\" and \"Legal\n  review\" for a two-stage approval, each with its own approver role on its transition.\n\nGive the workflow a name, then wire the graph:\n\n- **Add a step**: **+ Add node**, pick a step template, and type its name on the node.\n- **Connect two states into a transition**: every state has a small connector on each of its four\n  sides — click one, then click a connector on the state you want to connect it to (or drag from\n  one to the other). Click the new transition's label to name it and, optionally, restrict who may\n  fire it to specific role ids (find a role's id on Hub's Roles page) — leave it blank to let any\n  organization member fire it. A state without any wiring simply never occurs — there's no way to\n  reach it. A state whose outcome ends the flow — a translation workflow's **Approved** and\n  **Rejected** — still shows all four of its connectors, but only to receive an *incoming*\n  transition: there's nothing to drag or click to start one from it, since it can never be the\n  source of an outgoing transition. (A publishing workflow has no such state — even **Approved**\n  can have an outgoing transition, such as a \"Revert to draft\" step, if you wire one.)\n- Every state shows how many items are **currently sitting in it** — a live count that updates as\n  people submit, approve, and reject.\n\nOpen an existing workflow from the list to edit its graph the same way. A structural change (adding\nor removing states or transitions) is blocked while any item has an active review in progress — the\nerror explains this; renaming the workflow and editing attached actions (below) are always allowed\nregardless.\n\n## Attaching a Notify or Webhook to a state or transition\n\nBeyond states and transitions, the canvas offers two action node kinds via the same **+ Add node**\nmenu:\n\n- **Notify** — pick a channel (email or in-app) and one or more recipients. **This doesn't send\n  anything yet** — no notification channel is configured for this organization. The attempt is still\n  recorded (see Activity Log below), so you can see exactly when it *would* have fired once sending\n  is available.\n- **Webhook** — a URL your own system controls. This one is real: it actually `POST`s the transition\n  details to that URL. A URL that resolves to a private or internal address is rejected when you try\n  to save it.\n\nAttach either one to a **state** (fires the moment an item enters that state — click one of the\naction's own connectors, then one of the state's) or to a **transition** (fires the moment that\ntransition is used — click the action's connector, then the transition's own label). An action must\nbe attached to something before you can save. A Notify or Webhook never blocks the review itself —\neven if a webhook fails, the transition still goes through; the failure is just recorded.\n\n\"Enters that state\" means however it got there, including when nobody was involved. A review that\nstarts on its own — a translation job finishing, or a proposal arriving from a form or another\nsystem — fires whatever is attached to the state it starts in, and anything attached to a step the\nworkflow takes automatically after that. That is usually the point of attaching one: nobody is\nwatching when a proposal arrives, which is exactly why you want to be told. A Webhook fired this way\nsays so in its payload (`\"runStarted\": true`), since there was no transition and no previous state\nto name.\n\n## Assigning a workflow to a branch\n\nOpen a folder's (or an Experience node's) **governance panel** — the same place you manage access\nrules — and find the **Editorial workflow** section. Choose a workflow from the dropdown, or:\n\n- **Inherit from ancestor** — use whatever the nearest parent branch has assigned (or nothing, if\n  none does). This is the default for every branch.\n- **None (explicit)** — opt this branch and everything beneath it out of review, even if a parent\n  branch has a workflow assigned. Useful for a sub-folder that should publish freely while the rest\n  of the section stays gated.\n\n### One assignment per kind\n\nA branch carries a separate assignment for each kind, so a folder can be gated for publishing,\ngated for proposals, and ungoverned for translation all at once. Each has its own picker, and each\ninherits down the tree independently:\n\n- **Editorial workflow** — on folders and on Experience nodes.\n- **Proposal review** and **Translation review** — on folders only, since both are resolved from\n  the folder an item lives in and neither has anything to do with a page's address.\n\nA kind's picker only appears once you have at least one workflow of that kind, which is why a folder\nyou have never used proposals on shows just the one section.\n\n**What \"none\" means differs by kind**, and each picker says which:\n\n| Kind | With no workflow assigned |\n|---|---|\n| Editorial workflow | Content publishes without review |\n| Proposal review | Offers to that folder are **refused** — there would be nobody to review them |\n| Translation review | Translation jobs apply their translations without review |\n\n## Submitting and reviewing\n\nOpen a Component (under its **Settings** tab) or an Experience node under a governed branch and\nyou'll see a workflow panel showing its current state. If it's still in a non-publishable state,\nthe **Publish** button — always visible in the Component editor's header, regardless of which tab\nyou're on — is disabled and explains why.\n\nSelect an available transition (e.g. **Submit for review**), optionally add a comment, and confirm.\nWhile an item sits in a **Review step** or in **Approved**, its content is locked — what was\nreviewed is exactly what publishes. If a reviewer sends it to a **Rework step**, it's editable\nagain while the review stays open; the review tracks the version you submitted, and if you edit\nduring rework, the panel tells you the item has moved past the reviewed version.\n\nOnce it reaches a publishable state, **Publish** works as normal — it publishes the reviewed\nversion and marks the review complete. If someone edited the item after submission, it will show as\n\"Modified since publish\" immediately, since the head and the published version now differ — that's\nexpected, not an error.\n\nA reviewer sees the same panel with **Approve**/**Reject** buttons (only the transitions their role\nis allowed to perform are enabled). Rejecting sends it back to the start with the reviewer's comment\nattached, and it can be resubmitted. Resubmitting while a review is already in progress starts a\nfresh one, pinned to your latest version.\n\nYou (or anyone with access-management permission) can cancel an in-progress review from the same\npanel.\n\n## Permissions\n\nCreating, renaming, and deleting workflow definitions requires its own \"Manage Content workflows\"\npermission. Assigning a workflow to a branch is governed by the same permission as access rules\n(\"Manage access\"), since it's branch governance, not workflow authoring. Submitting for review\nrequires edit access on the branch; approving/rejecting is limited to whichever role(s) the\ntransition names (or anyone, if none are named) — an access-management holder can always advance a\nstuck review.\n\n## Activity Log\n\nEvery submission, approval, rejection, and cancellation appears in Hub's Activity Log with the\nactor and any comment attached — the review trail is part of your organization's audit history.\nAttached Notify and Webhook actions appear there too, one entry per attempt: a Webhook shows the URL\nand the response it got back (or that it failed); a Notify always shows \"not delivered (no\nnotification channel configured)\" — the reminder that it's recorded, not sent, until this\norganization has a notification channel set up.\n"
     },
     {
         "slug": "contracts",
@@ -81,7 +81,7 @@ export const HELP_TOPICS = [
     {
         "slug": "export-import",
         "title": "Export and import",
-        "body": "# Export and import\n\nPromotion (see [Content environments](content-environments.md)) moves content one direction along\na configured pipeline. Export and import is the general-purpose alternative: take a portable copy\nof something and bring it into any authoring environment — the same organization or a different\none, with or without a promotion pipeline set up between them.\n\nUse this for:\n\n- **Moving content backward** (\"demote\") — content edited in a downstream environment, brought\n  back to where it came from.\n- **Copying between environments with no pipeline configured**, or **between organizations**.\n- **Backing up** a Contract, Template, page, or Component, or **seeding** a fresh environment with\n  a starting set of content.\n\n## Exporting\n\nOn a Contract, Template, page, Component, Audience, or Adapter's own editor, look for the\n**Export…** button (next to Promote, where that's also available).\n\nExporting shows you everything that will be included — the item itself plus everything it depends\non (its Contract, any Templates it uses, referenced Audiences, and so on) — before you commit to\nanything. Check **Portable** if you're exporting to a different organization and the content\nincludes images or other files; this packages those files' bytes along with the content so they\ndon't arrive broken. Leave it unchecked for a same-organization export — the files are already\nvisible everywhere in your organization regardless of environment.\n\nClick **Export** to produce a bundle file, then **Download bundle file** to save it.\n\n## Importing\n\nOpen **Transfer** under **Tools** in the app navigation, then **Upload bundle file…** to stage a\nbundle you've downloaded (or received from someone else). Once staged, click **Import…** next to\nit.\n\nYou'll be asked to choose:\n\n- **Preserve identity** — items keep the same identity they had when exported. Use this for a\n  same-organization import; it's also what makes a \"demote\" work cleanly, since the item you bring\n  back is recognized as the same one you'll later send forward again.\n- **Fresh identity** — every item gets a brand-new identity, guaranteed not to collide with\n  anything. Required when importing into a different organization than the one the bundle came\n  from.\n\nThe import plan then shows each item's state:\n\n- **New** — doesn't exist here yet, will be created.\n- **Identical** — already here, exactly matching — nothing changes.\n- **Conflict** — already exists here with *different* content. You'll need to check a box\n  confirming you want the bundle's version to replace what's here. (The version being replaced is\n  saved first, so it isn't lost — see the item's own version history afterward if you need it\n  back.)\n\nA bundle imports as a whole — you can't pick and choose individual items partway through (do that\nat export time instead, by choosing a narrower starting point). Click **Import** to apply it.\n\nA large bundle can take a while, and the button counts items off as they're applied. The import runs\non the server rather than in this browser tab, so it keeps going if you close the dialog or reload\nthe page — reopening it picks the same import back up and carries on showing progress. If something\ndoes go wrong, nothing is left half-applied: the whole import is undone, and the reason appears next\nto the **Import** button.\n\n## Staged bundles\n\nThe Transfer page lists every bundle you've exported or uploaded. From there you can download a\nbundle again, re-run its import, or delete it once you're done with it. An ordinary export expires\nautomatically after 30 days; delete it sooner if you're finished with it.\n\n## What travels in a bundle, and what doesn't\n\nA bundle carries the *current* state of what you selected — the live content, not its full edit\nhistory. It does **not** carry: published copies (the destination publishes on its own schedule),\nin-progress workflow reviews, delivery keys or host mappings (those belong to the environment\nitself, not its content), or activity history.\n"
+        "body": "# Export and import\n\nPromotion (see [Content environments](content-environments.md)) moves content one direction along\na configured pipeline. Export and import is the general-purpose alternative: take a portable copy\nof something and bring it into any authoring environment — the same organization or a different\none, with or without a promotion pipeline set up between them.\n\nUse this for:\n\n- **Moving content backward** (\"demote\") — content edited in a downstream environment, brought\n  back to where it came from.\n- **Copying between environments with no pipeline configured**, or **between organizations**.\n- **Backing up** a Contract, Template, page, or Component, or **seeding** a fresh environment with\n  a starting set of content.\n\n## Exporting\n\nOn a Contract, Template, page, Component, Audience, or Adapter's own editor, look for the\n**Export…** button (next to Promote, where that's also available).\n\nExporting shows you everything that will be included — the item itself plus everything it depends\non (its Contract, any Templates it uses, referenced Audiences, and so on) — before you commit to\nanything. Check **Portable** if you're exporting to a different organization and the content\nincludes images or other files; this packages those files' bytes along with the content so they\ndon't arrive broken. Leave it unchecked for a same-organization export — the files are already\nvisible everywhere in your organization regardless of environment.\n\nClick **Export** to produce a bundle file, then **Download bundle file** to save it.\n\n## Importing\n\nOpen **Transfer** under **Tools** in the app navigation, then **Upload bundle file…** to stage a\nbundle you've downloaded (or received from someone else). Once staged, click **Import…** next to\nit.\n\nYou'll be asked to choose:\n\n- **Preserve identity** — items keep the same identity they had when exported. Use this for a\n  same-organization import; it's also what makes a \"demote\" work cleanly, since the item you bring\n  back is recognized as the same one you'll later send forward again.\n- **Fresh identity** — every item gets a brand-new identity, guaranteed not to collide with\n  anything. Required when importing into a different organization than the one the bundle came\n  from.\n\nThe import plan then shows each item's state:\n\n- **New** — doesn't exist here yet, will be created.\n- **Identical** — already here, exactly matching — nothing changes.\n- **Conflict** — already exists here with *different* content. You'll need to check a box\n  confirming you want the bundle's version to replace what's here. (The version being replaced is\n  saved first, so it isn't lost — see the item's own version history afterward if you need it\n  back.)\n\nA bundle imports as a whole — you can't pick and choose individual items partway through (do that\nat export time instead, by choosing a narrower starting point). Click **Import** to apply it.\n\nA large bundle can take a while, and the button counts items off as they're applied. The import runs\non the server rather than in this browser tab, so it keeps going if you close the dialog or reload\nthe page — reopening it picks the same import back up and carries on showing progress. If something\ndoes go wrong, nothing is left half-applied: the whole import is undone, and the reason appears next\nto the **Import** button.\n\n### Plan limits\n\nYour plan limits how many components, pages and categories your organization can have, counted\nacross all of its authoring environments. An import that would take you past one of those limits is\nrefused before anything is written, and the message says which limit and by how much. The import\nplan warns you about this before you click **Import**.\n\nOnly the items an import *creates* count. Importing a bundle that only updates content you already\nhave is never refused for this, even if you are over a limit.\n\nPromoting content, syncing an environment from its parent, and refreshing an environment are never\nrefused for this reason either. They copy content your organization already has, and being unable to\npromote to production would be worse than going over. If one of them takes you over a limit, you can\nkeep editing, but you can't create more of that kind of item until you upgrade or remove some.\n\n## Staged bundles\n\nThe Transfer page lists every bundle you've exported or uploaded. From there you can download a\nbundle again, re-run its import, or delete it once you're done with it. An ordinary export expires\nautomatically after 30 days; delete it sooner if you're finished with it.\n\n## What travels in a bundle, and what doesn't\n\nA bundle carries the *current* state of what you selected — the live content, not its full edit\nhistory. It does **not** carry: published copies (the destination publishes on its own schedule),\nin-progress workflow reviews, delivery keys or host mappings (those belong to the environment\nitself, not its content), or activity history.\n"
     },
     {
         "slug": "locale-addressing",

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,igVAAigV;KAC1gV;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,kCAAkC;QAC3C,MAAM,EAAE,6okBAA6okB;KACtpkB;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,sxeAAsxe;KAC/xe;IACD;QACE,MAAM,EAAE,sBAAsB;QAC9B,OAAO,EAAE,sBAAsB;QAC/B,MAAM,EAAE,mxqBAAmxqB;KAC5xqB;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,6zRAA6zR;KACt0R;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,6+HAA6+H;KACt/H;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,qmMAAqmM;KAC9mM;IACD;QACE,MAAM,EAAE,WAAW;QACnB,OAAO,EAAE,WAAW;QACpB,MAAM,EAAE,m7KAAm7K;KAC57K;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"}
+{"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,igVAAigV;KAC1gV;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,kCAAkC;QAC3C,MAAM,EAAE,6okBAA6okB;KACtpkB;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,sxeAAsxe;KAC/xe;IACD;QACE,MAAM,EAAE,sBAAsB;QAC9B,OAAO,EAAE,sBAAsB;QAC/B,MAAM,EAAE,mxqBAAmxqB;KAC5xqB;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,85SAA85S;KACv6S;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,w5JAAw5J;KACj6J;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,qmMAAqmM;KAC9mM;IACD;QACE,MAAM,EAAE,WAAW;QACnB,OAAO,EAAE,WAAW;QACpB,MAAM,EAAE,m7KAAm7K;KAC57K;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

@@ -1,6 +1,6 @@
 {
   "name": "@ebitex/content-mcp",
-  "version": "0.5.106",
+  "version": "0.5.110",
   "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/",