@ebitex/content-mcp 0.5.104 → 0.5.106

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\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## 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## 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",
@@ -91,12 +91,12 @@ export const HELP_TOPICS = [
     {
         "slug": "management-keys",
         "title": "Management keys",
-        "body": "# Management keys\n\nA **management key** lets a script, a build pipeline, or another system create and publish content in\nContent — the things you would otherwise do by hand in the app.\n\nThey're for automation. If you're editing content yourself, you don't need one.\n\n> Management keys need the **Pro** plan or above. A trial counts, so you can use them straight away.\n\n## What a key can do\n\nTwo things decide that, and you choose both when you create the key.\n\n**Its role** decides *which content* the key can touch. A key acts exactly as the role you give it —\nthe same folder permissions, the same approval workflows, the same limits. A key bound to a role that\ncan't edit a folder can't edit that folder, and a page waiting for approval can't be published by a\nscript any more than by a person.\n\n**Its permissions** decide *what kind of thing* the key can do:\n\n| Permission | Lets the key |\n|---|---|\n| **Read** | Look at what's there, and preview what a change would do |\n| **Write** | Apply a whole bundle of changes at once, and upload files |\n| **Publish** | Make content live |\n| **Authoring** | Create, edit and **delete** individual items — a Contract, a Component, a page |\n\nThey combine. A key with Read only is genuinely safe to use in a check that comments on a pull\nrequest: it can report exactly what *would* change and is incapable of changing it.\n\n**Authoring is the only one that can delete anything**, which is why it is separate from Write rather\nthan part of it. Write applies a bundle, and a bundle only ever adds or updates — it never removes a\nContract, a Component or a page. So a key that has always worked fine for your pipeline keeps doing\nexactly what it did; nothing widens on its own. Add Authoring when you want a script or a tool to\nbuild a model item by item, and leave it off when you do not.\n\n**Its environment.** A key works in one authoring environment and no other. To run a pipeline against\nstaging and production, create two keys. That's deliberate — it means a staging pipeline cannot\ntouch production even by mistake.\n\n## Creating a key\n\n1. Go to **Settings → API Keys**, and find **Management keys**.\n2. Check the **environment** shown in the switcher at the top of the page. The key is bound to\n   whichever authoring environment you are currently in, so switch first if that is not the one you\n   want.\n3. Choose a **name** you'll recognize later — \"Marketing site CI\", not \"key 2\".\n4. Choose the **role** it acts as. Pick the least powerful role that can do the job.\n5. Tick the **permissions** it needs. If in doubt, start with Read and add more when something fails.\n6. Choose when it **expires** — 30 days, 90 days, a year, or never. New keys default to 90 days.\n7. Optionally, restrict it to **IP ranges** — if your build server has a fixed address, this is worth\n   doing.\n\n**The key is shown once.** Copy it into your secret store before closing the dialog; it can't be\nshown again. If you lose it, revoke it and create another.\n\n> You can't create a key more powerful than you are. If you don't hold a permission yourself, you\n> can't give it to a key.\n\n## Keeping a key safe\n\nA management key can change your content. Treat it like a password.\n\n- **Never put one in a browser, a web page, or a front-end bundle.** It won't work there — we\n  deliberately prevent it — but the attempt means the key has been somewhere it shouldn't.\n- Store it in your CI system's secret store, never in a repository or a command you type.\n- Give it the narrowest role and fewest permissions that work.\n- Set an expiry if the key is for something temporary.\n- Restrict it to your build server's IP range where you can.\n\n## Revoking a key\n\n**Settings → API Keys → Management keys → Revoke.** It stops working immediately.\n\nThe record stays — who created it, when, and when it was last used — because that history is exactly\nwhat you need after a key has leaked.\n\nDeleting the **role** a key is bound to also stops that key working, immediately and permanently.\nThat's intentional: taking away a role takes away everything acting on its behalf.\n\n## Seeing what a key did\n\nEvery change a key makes is recorded in your organization's activity log under the key's name rather\nthan a person's, so you can always tell an automated change from someone's edit.\n\n## Troubleshooting\n\n| What you see | What it means |\n|---|---|\n| \"Invalid API key\" | Revoked, expired, mistyped — or the role it was bound to was deleted. The key list shows an **Expired** badge, so check there first |\n| \"Scope denied\" | The key lacks that permission. It names which one |\n| \"Tier required\" | Your plan doesn't include management keys. Pro or above is needed |\n| \"IP denied\" | The key is restricted to IP ranges and the caller isn't in one |\n| \"Confirm overwrite required\" | Something changed in Content since your script last looked. Review before overwriting |\n| \"Unknown property\" | Your request had a field we don't recognize — usually a typo. It names the field |\n| \"Quota exceeded\" | Too many requests for your plan. It names the limit |\n\n## Related\n\n- [Building a content model through the API](agent-authoring.md) — the model in API terms\n- [Getting help](../general/getting-help.md)\n- For developers: the [Content Management API guide](https://developers.ebitex.io/getting-started/content-as-code/) and its\n  [reference](https://developers.ebitex.io/api/),\n  and the [Content MCP server](https://developers.ebitex.io/getting-started/content-as-code/#ai-agents-ebitexcontent-mcp), which lets an AI agent build a content\n  model using a key you mint. Mint it against a **non-production** authoring environment, and leave\n  the authoring scope off unless the agent needs to write.\n"
+        "body": "# Management keys\n\nA **management key** lets a script, a build pipeline, or another system create and publish content in\nContent — the things you would otherwise do by hand in the app.\n\nThey're for automation. If you're editing content yourself, you don't need one.\n\n> Management keys need the **Pro** plan or above. A trial counts, so you can use them straight away.\n\n## What a key can do\n\nTwo things decide that, and you choose both when you create the key.\n\n**Its role** decides *which content* the key can touch. A key acts exactly as the role you give it —\nthe same folder permissions, the same approval workflows, the same limits. A key bound to a role that\ncan't edit a folder can't edit that folder, and a page waiting for approval can't be published by a\nscript any more than by a person.\n\n**Its permissions** decide *what kind of thing* the key can do:\n\n| Permission | Lets the key |\n|---|---|\n| **Read** | Look at what's there, and preview what a change would do |\n| **Write** | Apply a whole bundle of changes at once, and upload files |\n| **Publish** | Make content live |\n| **Authoring** | Create, edit and **delete** individual items — a Contract, a Component, a page |\n| **Proposals** | Offer content for review — and nothing else at all |\n\nThey combine. A key with Read only is genuinely safe to use in a check that comments on a pull\nrequest: it can report exactly what *would* change and is incapable of changing it.\n\n**Authoring is the only one that can delete anything**, which is why it is separate from Write rather\nthan part of it. Write applies a bundle, and a bundle only ever adds or updates — it never removes a\nContract, a Component or a page. So a key that has always worked fine for your pipeline keeps doing\nexactly what it did; nothing widens on its own. Add Authoring when you want a script or a tool to\nbuild a model item by item, and leave it off when you do not.\n\n**Proposals is the one permission that grants no access to your content.** A key holding only it\ncan offer something for review and can do nothing else — it cannot read a single Component and\ncannot write one. That is the point: an outside system offering content should not be able to look\nat what is already there. See [Proposals](proposals.md).\n\n**Its environment.** A key works in one authoring environment and no other. To run a pipeline against\nstaging and production, create two keys. That's deliberate — it means a staging pipeline cannot\ntouch production even by mistake.\n\n## Creating a key\n\n1. Go to **Settings → API Keys**, and find **Management keys**.\n2. Check the **environment** shown in the switcher at the top of the page. The key is bound to\n   whichever authoring environment you are currently in, so switch first if that is not the one you\n   want.\n3. Choose a **name** you'll recognize later — \"Marketing site CI\", not \"key 2\".\n4. Choose the **role** it acts as. Pick the least powerful role that can do the job.\n5. Tick the **permissions** it needs. If in doubt, start with Read and add more when something fails.\n6. Choose when it **expires** — 30 days, 90 days, a year, or never. New keys default to 90 days.\n7. Optionally, restrict it to **IP ranges** — if your build server has a fixed address, this is worth\n   doing.\n\n**The key is shown once.** Copy it into your secret store before closing the dialog; it can't be\nshown again. If you lose it, revoke it and create another.\n\n> You can't create a key more powerful than you are. If you don't hold a permission yourself, you\n> can't give it to a key.\n\n## Keeping a key safe\n\nA management key can change your content. Treat it like a password.\n\n- **Never put one in a browser, a web page, or a front-end bundle.** It won't work there — we\n  deliberately prevent it — but the attempt means the key has been somewhere it shouldn't.\n- Store it in your CI system's secret store, never in a repository or a command you type.\n- Give it the narrowest role and fewest permissions that work.\n- Set an expiry if the key is for something temporary.\n- Restrict it to your build server's IP range where you can.\n\n## Revoking a key\n\n**Settings → API Keys → Management keys → Revoke.** It stops working immediately.\n\nThe record stays — who created it, when, and when it was last used — because that history is exactly\nwhat you need after a key has leaked.\n\nDeleting the **role** a key is bound to also stops that key working, immediately and permanently.\nThat's intentional: taking away a role takes away everything acting on its behalf.\n\n## Seeing what a key did\n\nEvery change a key makes is recorded in your organization's activity log under the key's name rather\nthan a person's, so you can always tell an automated change from someone's edit.\n\n## Troubleshooting\n\n| What you see | What it means |\n|---|---|\n| \"Invalid API key\" | Revoked, expired, mistyped — or the role it was bound to was deleted. The key list shows an **Expired** badge, so check there first |\n| \"Scope denied\" | The key lacks that permission. It names which one |\n| \"Tier required\" | Your plan doesn't include management keys. Pro or above is needed |\n| \"IP denied\" | The key is restricted to IP ranges and the caller isn't in one |\n| \"Confirm overwrite required\" | Something changed in Content since your script last looked. Review before overwriting |\n| \"Unknown property\" | Your request had a field we don't recognize — usually a typo. It names the field |\n| \"Quota exceeded\" | Too many requests for your plan. It names the limit |\n\n## Related\n\n- [Building a content model through the API](agent-authoring.md) — the model in API terms\n- [Getting help](../general/getting-help.md)\n- For developers: the [Content Management API guide](https://developers.ebitex.io/getting-started/content-as-code/) and its\n  [reference](https://developers.ebitex.io/api/),\n  and the [Content MCP server](https://developers.ebitex.io/getting-started/content-as-code/#ai-agents-ebitexcontent-mcp), which lets an AI agent build a content\n  model using a key you mint. Mint it against a **non-production** authoring environment, and leave\n  the authoring scope off unless the agent needs to write.\n"
     },
     {
         "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**Some things are deliberately left blank.** A sent value is plain text; a field that holds a list, a\nlink to another item, an image, or personalised variants needs more than plain text to be filled in\nsafely. Rather than guess, Content leaves those to you — the sent value is still on the left, so\nnothing is lost.\n\nFinish the form, then choose one of the actions at the bottom. Those buttons are the transitions your\nworkflow allows your role to fire, so they carry your own wording, not ours.\n\n## What approving and rejecting do\n\n**Approve** creates a Component, as a **Draft**, in the folder the proposal was offered for. It does\nnot publish it — publishing is the same step it is for anything else. The proposal is kept, and\nrecords which Component it became.\n\n**Reject** creates nothing and deletes nothing. The proposal and everything sent with it stay, so you\ncan look back at what was offered and declined.\n\nEither way, whatever record the sender's own system keeps is untouched.\n\n## Setting it up\n\nTwo things have to exist before anything can be offered.\n\n**A proposal workflow, assigned to the destination folder.** Create one under **Workflows**, choosing\nthe **Proposal review** kind, then assign it to the folder (or any folder above it) on that folder's\nown access and workflow settings.\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**Some things are deliberately left blank.** A sent value is plain text; a field that holds a list, a\nlink to another item, an image, or personalised variants needs more than plain text to be filled in\nsafely. Rather than guess, Content leaves those to you — the sent value is still on the left, so\nnothing is lost.\n\nFinish the form, then choose one of the actions at the bottom. Those buttons are the transitions your\nworkflow allows your role to fire, so they carry your own wording, not ours.\n\n## What approving and rejecting do\n\n**Approve** creates a Component, as a **Draft**, in the folder the proposal was offered for. It does\nnot publish it — publishing is the same step it is for anything else. The proposal is kept, and\nrecords which Component it became.\n\n**Reject** creates nothing and deletes nothing. The proposal and everything sent with it stay, so you\ncan look back at what was offered and declined.\n\nEither way, whatever record the sender's own system keeps is untouched.\n\n## Setting it up\n\nTwo things have to exist before anything can be offered.\n\n**A proposal workflow, assigned to the destination folder.** Create one under **Workflows**, choosing\nthe **Proposal review** kind, then assign it to the folder (or any folder above it) on that folder's\nown access and workflow settings, where it appears as a **Proposal review** picker.\n\nCreate the workflow first: that picker only appears once at least one Proposal review workflow\nexists, since until then there would be nothing for it to offer. A folder with none assigned says so\nplainly, and says what it means — offers to that folder will be refused.\n\nThis is required, not optional. Without it there would be nobody to review what arrives, so Content\nrefuses the offer outright and tells the sender why — rather than accepting content nobody will\never look at.\n\n**A key that can only propose.** Under **API keys**, create one whose only scope is\n*content.management.proposals*. A key holding just that can offer proposals and can do nothing\nelse — it cannot read your content and cannot write any. Give it to whoever is sending.\n\n## Where proposals come from\n\nContent does not care what sent a proposal. It records three things about the sender — a kind, a\nreference, and a label — stores them exactly as given, and never contacts the sender again. Anything\nthat can make an HTTP request with the key above can offer content: a partner's own server, a\nscheduled job, a script.\n\n**An ebitex form is the ready-made option.** If the thing you want reviewed is something people fill\nin, build a form in Forms and connect it — no code, and no field mapping, because Content matches\nwhat the form sent against your Contract's fields by name. See\n[Offering submissions to Content](../forms/forms.md) for the three setup steps.\n\nWhat the reviewer sees is the same either way: the same page, the same two panels, the same\napprove-or-reject. A form-sent proposal is labelled with the form's name; another system's is\nlabelled with whatever it chose to send.\n\n## Why something might not appear\n\n**It was refused at the door.** The sender gets a clear reason: an unknown Contract, an unknown\nfolder, or no proposal workflow on that folder.\n\n**The same thing was sent twice.** Offers are identified by the sender's own reference, so re-sending\nthe same one returns the original rather than filing a duplicate. That makes it safe for a sender to\nretry after a failure.\n\n**It is for a folder you cannot see.** Proposals for branches outside your access are not listed at\nall.\n\n**You are in a different environment.** Proposals belong to the environment their key is bound to.\n\n## Related\n\n- [Tasks](tasks.md) — everything waiting on you, across every kind of review\n- [Workflows](content-workflow.md) — designing the review itself\n- [Forms](../forms/forms.md) — building a form and connecting it as a source of proposals\n"
     },
     {
         "slug": "publishing",
@@ -121,7 +121,7 @@ export const HELP_TOPICS = [
     {
         "slug": "translation-jobs",
         "title": "Translation jobs",
-        "body": "# Translation jobs\n\nTranslate a Component's text into another locale automatically, then review the result before it\nlands in your content — or skip the review entirely if you'd rather it apply right away.\n\n## Kicking off a translation\n\nOpen a Component and choose **Translate…** in its header. Pick one or more target locales (only\nlocales your organization has configured beyond the default show up here — add one in Settings\nfirst if you don't see the one you need), pick a translator if your organization has more than one\nactivated, and confirm. One job starts per locale you selected.\n\nOnly certain fields are ever translated: plain text and rich text fields marked as localizable,\nand only their default (root-locale) value — fields that hold a list of values, or that vary by\naudience, aren't picked up by this pass. A field whose target locale already has a value is left\nalone unless you check **Retranslate fields that already have a value in the target locale**.\n\n## What \"review\" means\n\nWhether a job needs your approval before it takes effect depends on whether the folder the\nComponent lives in has a **translation workflow** assigned (see\n[Editorial workflow](content-workflow.md)) — the same governance mechanism that gates publishing,\napplied here to translated text instead:\n\n- **No translation workflow assigned**: the job applies immediately — the proposed translations are\n  written straight into the Component, no review step in between.\n- **A translation workflow is assigned**: the job's proposed values sit in **awaiting review** until\n  someone acts on them. Depending on how the workflow was built, that might mean an automatic\n  decision (for example, routing certain locales straight through with no human step at all) or a\n  real review step where a person has to look at it.\n\nEither way, once a job applies, the translated text is simply part of the Component from then on —\nthere's nothing left to indicate it arrived via a translation job.\n\n## Reviewing proposed translations\n\nOpen the **Translations** panel on a Component (or click through from wherever the job is listed)\nto see each job's status and, for a job awaiting review, every proposed value side by side with the\noriginal: the source text above, an editable text box below holding the machine translation. Edit\nthe proposed text directly if it needs a tweak, then mark each item **Accept** or **Reject** —\naccepting is also the default if you don't touch an item at all, since a translated value with no\nobjection raised is assumed good.\n\nOnce every item you care about has been handled, use the workflow's own transition buttons (for\nexample **Approve**) to move the job forward. Depending on how many review steps the workflow\ndefines, approving might finish the job right away or hand it to a second reviewer — the panel\nalways shows what happens next.\n\nRejecting sends the job to its own end state without writing anything into the Component — nothing\nis applied, and the proposed translations are discarded.\n\n## What \"stale\" means\n\nIf someone edits the Component's own text while a translation job is sitting in review, the job\nnotices at the moment it's finally approved: any item whose original source text has since changed\nis marked **stale** rather than applied, since the translation was proposed against text that no\nlonger exists. A stale item doesn't block the rest of the job — every other item still applies\nnormally — but the stale field itself is left untouched, and translating it again (a fresh job) is\nthe way to pick up the new wording.\n\n## Deleting a Component with translation history\n\nA Component that still has a translation job **in progress** (queued, translating, or awaiting\nreview) can't be deleted until that job finishes one way or another — finish the review, or reject\nit, then delete. A Component whose translation jobs have all already finished (applied, discarded,\nor failed) has no such restriction — deleting the Component removes that history along with it.\n\n## Permissions\n\nKicking off a translation job requires edit access to the Component. Acting on a job under review\nfollows the same rules as any other workflow transition — see\n[Editorial workflow](content-workflow.md#permissions).\n"
+        "body": "# Translation jobs\n\nTranslate a Component's text into another locale automatically, then review the result before it\nlands in your content — or skip the review entirely if you'd rather it apply right away.\n\n## Kicking off a translation\n\nOpen a Component and choose **Translate…** in its header. Pick one or more target locales (only\nlocales your organization has configured beyond the default show up here — add one in Settings\nfirst if you don't see the one you need), pick a translator if your organization has more than one\nactivated, and confirm. One job starts per locale you selected.\n\nOnly certain fields are ever translated: plain text and rich text fields marked as localizable,\nand only their default (root-locale) value — fields that hold a list of values, or that vary by\naudience, aren't picked up by this pass. A field whose target locale already has a value is left\nalone unless you check **Retranslate fields that already have a value in the target locale**.\n\n## What \"review\" means\n\nWhether a job needs your approval before it takes effect depends on whether the folder the\nComponent lives in has a **translation workflow** assigned (see\n[Editorial workflow](content-workflow.md)) — the same governance mechanism that gates publishing,\napplied here to translated text instead:\n\n- **No translation workflow assigned**: the job applies immediately — the proposed translations are\n  written straight into the Component, no review step in between.\n- **A translation workflow is assigned**: the job's proposed values sit in **awaiting review** until\n  someone acts on them. Depending on how the workflow was built, that might mean an automatic\n  decision (for example, routing certain locales straight through with no human step at all) or a\n  real review step where a person has to look at it.\n\nTo assign one, create a **Translation workflow** under **Workflow**, then open the folder's\ngovernance panel and pick it under **Translation review**. That picker appears once at least one\ntranslation workflow exists; before then, the folder simply has no translation section, which is\nthe \"applies immediately\" case above.\n\nEither way, once a job applies, the translated text is simply part of the Component from then on —\nthere's nothing left to indicate it arrived via a translation job.\n\n## Reviewing proposed translations\n\nOpen the **Translations** panel on a Component (or click through from wherever the job is listed)\nto see each job's status and, for a job awaiting review, every proposed value side by side with the\noriginal: the source text above, an editable text box below holding the machine translation. Edit\nthe proposed text directly if it needs a tweak, then mark each item **Accept** or **Reject** —\naccepting is also the default if you don't touch an item at all, since a translated value with no\nobjection raised is assumed good.\n\nOnce every item you care about has been handled, use the workflow's own transition buttons (for\nexample **Approve**) to move the job forward. Depending on how many review steps the workflow\ndefines, approving might finish the job right away or hand it to a second reviewer — the panel\nalways shows what happens next.\n\nRejecting sends the job to its own end state without writing anything into the Component — nothing\nis applied, and the proposed translations are discarded.\n\n## What \"stale\" means\n\nIf someone edits the Component's own text while a translation job is sitting in review, the job\nnotices at the moment it's finally approved: any item whose original source text has since changed\nis marked **stale** rather than applied, since the translation was proposed against text that no\nlonger exists. A stale item doesn't block the rest of the job — every other item still applies\nnormally — but the stale field itself is left untouched, and translating it again (a fresh job) is\nthe way to pick up the new wording.\n\n## Deleting a Component with translation history\n\nA Component that still has a translation job **in progress** (queued, translating, or awaiting\nreview) can't be deleted until that job finishes one way or another — finish the review, or reject\nit, then delete. A Component whose translation jobs have all already finished (applied, discarded,\nor failed) has no such restriction — deleting the Component removes that history along with it.\n\n## Permissions\n\nKicking off a translation job requires edit access to the Component. Acting on a job under review\nfollows the same rules as any other workflow transition — see\n[Editorial workflow](content-workflow.md#permissions).\n"
     }
 ];
 //# sourceMappingURL=helpCorpus.generated.js.map

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,4mPAA4mP;KACrnP;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,2rLAA2rL;KACpsL;IACD;QACE,MAAM,EAAE,WAAW;QACnB,OAAO,EAAE,WAAW;QACpB,MAAM,EAAE,+mKAA+mK;KACxnK;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,itIAAitI;KAC1tI;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,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"}

package/package.json

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