@ebitex/content-mcp 1.0.220 → 1.0.226

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** — tell people in the app. Choose **In-app**, then who to tell: the person who took the\n  move, or any role or member (`role:<id>` or `user:<id>`). Content items have no owner, so **The\n  owner** skips them. They get a notification on the bell in the top bar, and the attempt is recorded\n  (see Activity Log below). Email is not available yet: a Notify set to email is kept and sends\n  nothing. See [Notifications](../hub/notifications.md).\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. You can also set a **signing secret**, so the system receiving the request can prove it\n  came from us — see **Making sure a webhook really came from us**, below.\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 two places: its event type is `content.workflow.runStarted` rather than\n`content.workflow.transitioned`, and `\"runStarted\": true` appears in the payload — because there was\nno transition and no previous state to name.\n\n## Making sure a webhook really came from us\n\nA webhook is an ordinary `POST` to a URL you chose, so anyone who learns that URL could send one.\nSetting a **signing secret** on the Webhook node closes that: we sign every request with it, and your\nsystem can check the signature before trusting anything in the body.\n\nLeave the secret blank and requests are sent unsigned, exactly as before — nothing you have already\nset up changes.\n\nThe secret is write-only. Once saved, the node shows **Configured** rather than the value, and we\nnever send it back to your browser. To change it, select **Replace** and enter a new one; to stop\nsigning, select **Replace** and save with the field empty. Editing anything else about the workflow\nleaves the secret alone.\n\nChanging the destination URL does **not** carry the secret over, deliberately — a different URL is a\ndifferent system, and it should get its own secret rather than inheriting one silently.\n\nEvery request carries two headers:\n\n```\nX-Ebitex-Signature: v1,t=1790000591,s=<signature>\nX-Ebitex-Delivery: whd_0123456789abcdef0123456789abcdef\n```\n\nYour system should recompute the signature over the exact bytes it received and compare. The full\nrecipe, with a worked example, is on our developer site — see\n[developers.ebitex.io](https://developers.ebitex.io). Two things that catch people out: sign the raw\nbody you received rather than re-encoding it first, and compare using a constant-time comparison\nrather than `==`.\n\n`X-Ebitex-Delivery` identifies one delivery. If we retry after a failure, the retry carries the same\nid, so your system can recognise it as a repeat rather than a second event. Use it to ignore\nduplicates.\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 or an Experience node under a governed branch and you'll see its current state. In the\nComponent editor it is in the status strip under the name, on the **Content** tab. If it's still in a\nnon-publishable state the strip reads **Can't be published yet** and offers the next step right there.\n**Publish…** stays available, because the publish panel explains the block and still lets the rest of what you are\npublishing go out, but it is no longer the highlighted button and its tooltip gives the reason. The full panel,\nwith its comment box and **Cancel run**, is on the **Settings** tab.\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## Saving and deleting a workflow\n\nThe bar at the foot of the editor lists what you changed; **Save** applies it and **Discard** drops it.\nMoving a node around does not count as a change. Leaving with unsaved changes asks first. **Delete**\nasks you to confirm: Components already running keep their current review, and no new review can start.\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 shows how many people it told\n(\"delivered to 2 recipients\") and who it skipped, or \"not delivered\" with the reason.\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** — tell people in the app, by email, or both. Choose **In-app**, **Email** or **In-app and email**, then who to tell: the person who took the\n  move, or any role or member (`role:<id>` or `user:<id>`). Content items have no owner, so **The\n  owner** skips them. They get a notification on the bell in the top bar. The attempt is recorded (see Activity Log below), and each member chooses how they are emailed. See [Notifications](../hub/notifications.md).\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. You can also set a **signing secret**, so the system receiving the request can prove it\n  came from us — see **Making sure a webhook really came from us**, below.\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 two places: its event type is `content.workflow.runStarted` rather than\n`content.workflow.transitioned`, and `\"runStarted\": true` appears in the payload — because there was\nno transition and no previous state to name.\n\n## Making sure a webhook really came from us\n\nA webhook is an ordinary `POST` to a URL you chose, so anyone who learns that URL could send one.\nSetting a **signing secret** on the Webhook node closes that: we sign every request with it, and your\nsystem can check the signature before trusting anything in the body.\n\nLeave the secret blank and requests are sent unsigned, exactly as before — nothing you have already\nset up changes.\n\nThe secret is write-only. Once saved, the node shows **Configured** rather than the value, and we\nnever send it back to your browser. To change it, select **Replace** and enter a new one; to stop\nsigning, select **Replace** and save with the field empty. Editing anything else about the workflow\nleaves the secret alone.\n\nChanging the destination URL does **not** carry the secret over, deliberately — a different URL is a\ndifferent system, and it should get its own secret rather than inheriting one silently.\n\nEvery request carries two headers:\n\n```\nX-Ebitex-Signature: v1,t=1790000591,s=<signature>\nX-Ebitex-Delivery: whd_0123456789abcdef0123456789abcdef\n```\n\nYour system should recompute the signature over the exact bytes it received and compare. The full\nrecipe, with a worked example, is on our developer site — see\n[developers.ebitex.io](https://developers.ebitex.io). Two things that catch people out: sign the raw\nbody you received rather than re-encoding it first, and compare using a constant-time comparison\nrather than `==`.\n\n`X-Ebitex-Delivery` identifies one delivery. If we retry after a failure, the retry carries the same\nid, so your system can recognise it as a repeat rather than a second event. Use it to ignore\nduplicates.\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 or an Experience node under a governed branch and you'll see its current state. In the\nComponent editor it is in the status strip under the name, on the **Content** tab. If it's still in a\nnon-publishable state the strip reads **Can't be published yet** and offers the next step right there.\n**Publish…** stays available, because the publish panel explains the block and still lets the rest of what you are\npublishing go out, but it is no longer the highlighted button and its tooltip gives the reason. The full panel,\nwith its comment box and **Cancel run**, is on the **Settings** tab.\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## Saving and deleting a workflow\n\nThe bar at the foot of the editor lists what you changed; **Save** applies it and **Discard** drops it.\nMoving a node around does not count as a change. Leaving with unsaved changes asks first. **Delete**\nasks you to confirm: Components already running keep their current review, and no new review can start.\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 shows how many people it told\n(\"delivered to 2 recipients\") and who it skipped, or \"not delivered\" with the reason.\n"
     },
     {
         "slug": "contracts",

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,yzZAAyzZ;KACl0Z;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,6p0BAA6p0B;KACtq0B;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,kCAAkC;QAC3C,MAAM,EAAE,06nBAA06nB;KACn7nB;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,0BAA0B;QACnC,MAAM,EAAE,i9OAAi9O;KAC19O;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,gCAAgC;QACzC,MAAM,EAAE,60sBAA60sB;KACt1sB;IACD;QACE,MAAM,EAAE,sBAAsB;QAC9B,OAAO,EAAE,sBAAsB;QAC/B,MAAM,EAAE,o1qBAAo1qB;KAC71qB;IACD;QACE,MAAM,EAAE,eAAe;QACvB,OAAO,EAAE,qCAAqC;QAC9C,MAAM,EAAE,q3FAAq3F;KAC93F;IACD;QACE,MAAM,EAAE,yBAAyB;QACjC,OAAO,EAAE,4BAA4B;QACrC,MAAM,EAAE,ksRAAksR;KAC3sR;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,mBAAmB;QAC5B,MAAM,EAAE,w8PAAw8P;KACj9P;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,izQAAizQ;KAC1zQ;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,oBAAoB;QAC7B,MAAM,EAAE,ujYAAujY;KAChkY;IACD;QACE,MAAM,EAAE,WAAW;QACnB,OAAO,EAAE,iCAAiC;QAC1C,MAAM,EAAE,8xqBAA8xqB;KACvyqB;IACD;QACE,MAAM,EAAE,iBAAiB;QACzB,OAAO,EAAE,iBAAiB;QAC1B,MAAM,EAAE,0uHAA0uH;KACnvH;IACD;QACE,MAAM,EAAE,qBAAqB;QAC7B,OAAO,EAAE,qBAAqB;QAC9B,MAAM,EAAE,+iFAA+iF;KACxjF;IACD;QACE,MAAM,EAAE,eAAe;QACvB,OAAO,EAAE,mBAAmB;QAC5B,MAAM,EAAE,u9JAAu9J;KACh+J;IACD;QACE,MAAM,EAAE,MAAM;QACd,OAAO,EAAE,MAAM;QACf,MAAM,EAAE,y9FAAy9F;KACl+F;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,mBAAmB;QAC5B,MAAM,EAAE,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,0oSAA0oS;KACnpS;IACD;QACE,MAAM,EAAE,YAAY;QACpB,OAAO,EAAE,oBAAoB;QAC7B,MAAM,EAAE,y5YAAy5Y;KACl6Y;IACD;QACE,MAAM,EAAE,qBAAqB;QAC7B,OAAO,EAAE,qBAAqB;QAC9B,MAAM,EAAE,yrIAAyrI;KAClsI;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,69KAA69K;KACt+K;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,kBAAkB;QAC3B,MAAM,EAAE,yvJAAyvJ;KAClwJ;IACD;QACE,MAAM,EAAE,gBAAgB;QACxB,OAAO,EAAE,qCAAqC;QAC9C,MAAM,EAAE,0hMAA0hM;KACniM;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,yzZAAyzZ;KACl0Z;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,6p0BAA6p0B;KACtq0B;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,kCAAkC;QAC3C,MAAM,EAAE,06nBAA06nB;KACn7nB;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,0BAA0B;QACnC,MAAM,EAAE,i9OAAi9O;KAC19O;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,gCAAgC;QACzC,MAAM,EAAE,60sBAA60sB;KACt1sB;IACD;QACE,MAAM,EAAE,sBAAsB;QAC9B,OAAO,EAAE,sBAAsB;QAC/B,MAAM,EAAE,o1qBAAo1qB;KAC71qB;IACD;QACE,MAAM,EAAE,eAAe;QACvB,OAAO,EAAE,qCAAqC;QAC9C,MAAM,EAAE,q3FAAq3F;KAC93F;IACD;QACE,MAAM,EAAE,yBAAyB;QACjC,OAAO,EAAE,4BAA4B;QACrC,MAAM,EAAE,ksRAAksR;KAC3sR;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,mBAAmB;QAC5B,MAAM,EAAE,w8PAAw8P;KACj9P;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,izQAAizQ;KAC1zQ;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,oBAAoB;QAC7B,MAAM,EAAE,okYAAokY;KAC7kY;IACD;QACE,MAAM,EAAE,WAAW;QACnB,OAAO,EAAE,iCAAiC;QAC1C,MAAM,EAAE,8xqBAA8xqB;KACvyqB;IACD;QACE,MAAM,EAAE,iBAAiB;QACzB,OAAO,EAAE,iBAAiB;QAC1B,MAAM,EAAE,0uHAA0uH;KACnvH;IACD;QACE,MAAM,EAAE,qBAAqB;QAC7B,OAAO,EAAE,qBAAqB;QAC9B,MAAM,EAAE,+iFAA+iF;KACxjF;IACD;QACE,MAAM,EAAE,eAAe;QACvB,OAAO,EAAE,mBAAmB;QAC5B,MAAM,EAAE,u9JAAu9J;KACh+J;IACD;QACE,MAAM,EAAE,MAAM;QACd,OAAO,EAAE,MAAM;QACf,MAAM,EAAE,y9FAAy9F;KACl+F;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,OAAO,EAAE,mBAAmB;QAC5B,MAAM,EAAE,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,0oSAA0oS;KACnpS;IACD;QACE,MAAM,EAAE,YAAY;QACpB,OAAO,EAAE,oBAAoB;QAC7B,MAAM,EAAE,y5YAAy5Y;KACl6Y;IACD;QACE,MAAM,EAAE,qBAAqB;QAC7B,OAAO,EAAE,qBAAqB;QAC9B,MAAM,EAAE,yrIAAyrI;KAClsI;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,69KAA69K;KACt+K;IACD;QACE,MAAM,EAAE,kBAAkB;QAC1B,OAAO,EAAE,kBAAkB;QAC3B,MAAM,EAAE,yvJAAyvJ;KAClwJ;IACD;QACE,MAAM,EAAE,gBAAgB;QACxB,OAAO,EAAE,qCAAqC;QAC9C,MAAM,EAAE,0hMAA0hM;KACniM;CACF,CAAA"}

package/package.json

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