@ebitex/content-mcp 1.1.247 → 1.1.251

package/dist/resources/helpCorpus.generated.js

@@ -116,12 +116,12 @@ export const HELP_TOPICS = [
     {
         "slug": "realms",
         "title": "Realms",
-        "body": "# Realms\n\nIf your organization runs one brand, one site or one team, you will never need this page: Content has a single realm, nothing about it shows, and everything works as it always has. Realms are for organizations that publish several brands or sites which should **share some content and keep the rest apart**: shared design-system blocks, legal text and media Contracts that every brand uses, with each brand's own pages kept to itself.\n\n## What a realm is\n\nA realm is a place in a tree. Your organization has one **root** realm (named *Default* until you rename it), and you can create realms below it: *Shared* at the top, *Brand A* and *Brand B* underneath, and so on.\n\n- A realm sees what it owns **and** what every realm above it owns. Brand A sees Shared's Contracts, Templates, folders and Components without copying anything and without a sync step, so nothing can be out of date.\n- A realm changes only what it owns. Brand A cannot see Brand B, and Shared cannot see inside Brand A.\n- Realms are not environments. An environment is a stage a piece of content passes through (Staging, then Live). A realm is *whose* content it is. Every realm exists in every environment, so \"Live · Brand A\" and \"Staging · Brand A\" are two views of the same brand.\n\n## Switching realm\n\nWhen your organization has more than one realm, a **realm switcher** appears in the header beside the environment switcher, and the page title shows the current cell, for example \"Live · Brand A\". You only see the realms you are allowed to enter (see **Who can do what** below). Search results, My tasks and the review queue show items from every realm you can enter and open the right one when you select a result.\n\n## Owned and inherited items\n\nIn lists, folder trees and pickers, an item that another realm owns is drawn dimmer with a dotted outline and an **Owned by {realm}** chip. A legend under the list explains it, and a filter lets you show **All**, **Owned here** or **Inherited**. Whether an item is inherited depends only on which realm you are in; nothing is stored on the item.\n\nThings you can do with an inherited item:\n\n- **Use it.** Reference an inherited Contract from a Component, put an inherited Component in a page, choose an inherited Template. This is what inheriting is for.\n- **Create under it.** You can create items inside an inherited folder. They belong to your realm and sit in the shared folder, and the folder's own access rules and Allowed contracts still apply. You cannot add to the folder itself; make a subfolder of your own for that.\n- **Edit it.** Saving a change to an inherited Component, Contract, Template, Adapter or Stream is written in the realm that owns it. Before you save, the editor says so (\"Owned by Shared. Saving here changes it for every realm that reads Shared.\") and asks you to confirm. You need permission to edit in your realm **and** in the owning realm; if you lack the second you are told which realm to ask.\n- **Not from here.** Deleting, moving, restoring an older version and changing taxonomy vocabulary are refused on an inherited item, and the message names the owner. Do those in the owning realm.\n\n## Managing realms\n\nOpen **Realms** under **Configure** (requires the \"Manage Content realms\" permission, and realms must be switched on for your organization). The page shows the tree.\n\n- **Create** a realm under any other. The name is what people see in the switcher. Your plan limits how many realms you can have; Subscriptions & Billing shows the number you use. Only creating is refused when you reach the limit: nothing you already have is locked.\n- **Rename** a realm at any time. Its key, which tools use, does not change.\n- **Re-order** realms among their siblings, or **move a realm under another realm**. Moving is refused, with a list, if content in the realm or below it uses something from a realm the new position would not see.\n- **Delete** a realm that has no realms below it. This permanently deletes everything the realm owns in **every** environment and cannot be undone; you type the realm's key to confirm. It is refused while anything still points at the realm (a key, a member's access, an environment owned by it, anything published).\n\n### Move to realm, and duplicate into this realm\n\nFrom an item's row actions:\n\n- **Move to realm…** changes which realm owns an item (or a folder with everything inside it). It is refused, with the list of what would break, when moving would leave something unable to see an item it uses: for instance moving a Contract into Brand A while Brand B's Components use it.\n- **Duplicate into this realm…** makes a copy of an inherited item in your realm, with new ids, so you can change it without changing it for everyone. References between the copied items are re-pointed to the copies; references to anything else are kept.\n\n### When something is still in use below you\n\nDeleting or narrowing something that realms below yours depend on is refused with a count per realm, such as \"used by 3 items in Brand A\". You are never shown their content, only how many items and which realm. Change those items from inside that realm, or ask someone who can, then try again.\n\n### Environments owned by a realm\n\nAn authoring environment can be shared (the default) or **owned by one realm**, in which case it is listed and usable only inside that realm and the realms below it. Choose **Realm…** in the environment's row menu on the Environments page; it is offered once your organization has more than one realm. Your default authoring and delivery environments are always shared.\n\n## Who can do what\n\n- **Members.** On the Environments page, **Members** tab, a person's role in an environment can be limited to one realm. Someone bound to Brand A in Live can enter Brand A and the realms below it, cannot see Brand B, and cannot edit Shared unless they are also bound there. A binding with no realm applies to every realm.\n- **API keys.** A **Management** or **deployment** key acts in exactly one realm, chosen when you create it. A **delivery** key can serve every realm or be limited to one realm and the realms below it, so Brand A's key cannot be used to read Brand B's site. Keys created before realms act in the root realm.\n\n## Publishing and promoting across realms\n\n- **Publishing** a page publishes everything it needs, including items its realm inherits, once. You cannot unpublish an item that a published page still references.\n- **Promoting** works for the realm you are in. If the content needs items a realm above yours owns that the target environment lacks or has behind, promotion stops and lists them by realm. Where you are allowed to promote in that realm, choose **Include {realm}** and they go first. **Promote everything** walks the realms from the top down.\n- **Environment refresh** is not available while either environment holds content in a realm other than the root; use promotion instead.\n\n## Related\n\nSee [content-environments.md](content-environments.md) for environments and promotion, [management-keys.md](management-keys.md) and [deployment-keys.md](deployment-keys.md) for keys, and [export-import.md](export-import.md) for moving content between organizations.\n"
+        "body": "# Realms\n\nIf your organization runs one brand, one site or one team, you will never need this page: Content has a single realm, nothing about it shows, and everything works as it always has. Realms are for organizations that publish several brands or sites which should **share some content and keep the rest apart**: shared design-system blocks, legal text and media Contracts that every brand uses, with each brand's own pages kept to itself.\n\n## What a realm is\n\nA realm is a place in a tree. Your organization has one **root** realm (named *Default* until you rename it), and you can create realms below it: *Shared* at the top, *Brand A* and *Brand B* underneath, and so on.\n\n- A realm sees what it owns **and** what every realm above it owns. Brand A sees Shared's Contracts, Templates, folders and Components without copying anything and without a sync step, so nothing can be out of date.\n- A realm changes only what it owns. Brand A cannot see Brand B, and Shared cannot see inside Brand A.\n- Realms are not environments. An environment is a stage a piece of content passes through (Staging, then Live). A realm is *whose* content it is. Every realm exists in every environment, so \"Live · Brand A\" and \"Staging · Brand A\" are two views of the same brand.\n\n## Switching realm\n\nWhen your organization has more than one realm, a **realm switcher** appears in the header beside the environment switcher, and the page title shows the current cell, for example \"Live · Brand A\". You only see the realms you are allowed to enter (see **Who can do what** below). Search results, My tasks and the review queue show items from every realm you can enter and open the right one when you select a result.\n\n## Owned and inherited items\n\nIn lists, folder trees and pickers, an item that another realm owns is drawn dimmer with a dotted outline and an **Owned by {realm}** chip. A legend under the list explains it, and a filter lets you show **All**, **Owned here** or **Inherited**. Whether an item is inherited depends only on which realm you are in; nothing is stored on the item.\n\nThings you can do with an inherited item:\n\n- **Use it.** Reference an inherited Contract from a Component, put an inherited Component in a page, choose an inherited Template. This is what inheriting is for.\n- **Create under it.** You can create items inside an inherited folder. They belong to your realm and sit in the shared folder, and the folder's own access rules and Allowed contracts still apply. You cannot add to the folder itself; make a subfolder of your own for that.\n- **Edit it.** Saving a change to an inherited Component, Contract, Template, Adapter or Stream is written in the realm that owns it. Before you save, the editor says so (\"Owned by Shared. Saving here changes it for every realm that reads Shared.\") and asks you to confirm. You need permission to edit in your realm **and** in the owning realm; if you lack the second you are told which realm to ask.\n- **Not from here.** Deleting, moving, restoring an older version and changing taxonomy vocabulary are refused on an inherited item, and the message names the owner. Do those in the owning realm.\n\n## Managing realms\n\nOpen **Realms** under **Configure** (requires the \"Manage Content realms\" permission, and realms must be switched on for your organization). The page shows the tree.\n\n- **Create** a realm under any other. The name is what people see in the switcher. Your plan limits how many realms you can have; Subscriptions & Billing shows the number you use. Only creating is refused when you reach the limit: nothing you already have is locked.\n- **Rename** a realm at any time. Its key, which tools use, does not change.\n- **Re-order** realms among their siblings, or **move a realm under another realm**. Moving is refused, with a list, if content in the realm or below it uses something from a realm the new position would not see.\n- **Delete** a realm that has no realms below it. This permanently deletes everything the realm owns in **every** environment and cannot be undone; you type the realm's key to confirm. It is refused while anything still points at the realm (a key, a member's access, an environment owned by it, anything published).\n\n### Move to realm, and duplicate into this realm\n\nFrom an item's row actions:\n\n- **Move to realm…** changes which realm owns an item (or a folder with everything inside it, or a site with all its pages). It is refused, with the list of what would break, when moving would leave something unable to see an item it uses: for instance moving a Contract into Brand A while Brand B's Components use it.\n- **Duplicate into this realm…** makes a copy of an inherited item in your realm, with new ids, so you can change it without changing it for everyone. References between the copied items are re-pointed to the copies; references to anything else are kept.\n\n### When something is still in use below you\n\nDeleting or narrowing something that realms below yours depend on is refused with a count per realm, such as \"used by 3 items in Brand A\". You are never shown their content, only how many items and which realm. Change those items from inside that realm, or ask someone who can, then try again.\n\n### Environments owned by a realm\n\nAn authoring environment can be shared (the default) or **owned by one realm**, in which case it is listed and usable only inside that realm and the realms below it. Choose **Realm…** in the environment's row menu on the Environments page; it is offered once your organization has more than one realm. Your default authoring and delivery environments are always shared.\n\n## Who can do what\n\n- **Members.** On the Environments page, **Members** tab, a person's role in an environment can be limited to one realm. Someone bound to Brand A in Live can enter Brand A and the realms below it, cannot see Brand B, and cannot edit Shared unless they are also bound there. A binding with no realm applies to every realm.\n- **API keys.** A **Management** or **deployment** key acts in exactly one realm, chosen when you create it. A **delivery** key can serve every realm or be limited to one realm and the realms below it, so Brand A's key cannot be used to read Brand B's site. Keys created before realms act in the root realm.\n\n## Publishing and promoting across realms\n\n- **Publishing** a page publishes everything it needs, including items its realm inherits, once. You cannot unpublish an item that a published page still references.\n- **Promoting** works for the realm you are in. If the content needs items a realm above yours owns that the target environment lacks or has behind, promotion stops and lists them by realm. Where you are allowed to promote in that realm, choose **Include {realm}** and they go first. **Promote everything** walks the realms from the top down.\n- **Environment refresh** is not available while either environment holds content in a realm other than the root; use promotion instead.\n\n## Related\n\nSee [content-environments.md](content-environments.md) for environments and promotion, [management-keys.md](management-keys.md) and [deployment-keys.md](deployment-keys.md) for keys, and [export-import.md](export-import.md) for moving content between organizations.\n"
     },
     {
         "slug": "rendering-your-site",
         "title": "Rendering your site",
-        "body": "# Rendering your site\n\nRead this before you write any code that fetches published content. Content is published to the\n**Content Delivery API**, and ebitex ships a client for it: **`@ebitex/content-sdk`** on npm (and\n`Ebitex.Content.Delivery` on NuGet for a .NET server). Use it unless you have a reason not to. The\nreasons are below, because a hand-written client looks easy on the day it is written and costs the\nmost later.\n\nThis page is for the person or agent building the site that shows the content. Building the content\nmodel itself is [Building a content model through the API](agent-authoring.md).\n\n## Start from the SDK\n\n```sh\nnpm install @ebitex/content-sdk\n```\n\n- **A Vite and React site** that renders in the browser: `createContentClient` and the components in\n  `@ebitex/content-sdk/react`.\n- **A Next.js (or other server-rendered) site**: the same package, with the key kept on the server.\n  The guide is *Render content on a server* at developers.ebitex.io.\n- **A .NET server**: `Ebitex.Content.Delivery`.\n\nGuides, the API reference and the SDK reference are all at **developers.ebitex.io**. For the exact\nshape of a request or a response, read the OpenAPI document at `https://api.ebitex.io/openapi/public.json`\nrather than inferring it from a few responses you have seen.\n\n## What you stop maintaining\n\nA site that calls the Delivery API with its own `fetch` code owns all of this, and none of it shows\nup until something breaks:\n\n- **Path resolution, components, streams and facets, media and response parsing.** The SDK has one\n  method per endpoint and is updated when the API is. A client written against the responses seen on\n  one day is wrong the first day the API adds a member or a mode.\n- **The sitemap.** `buildSitemapDocuments` (in `@ebitex/content-sdk/sitemap`) splits at the protocol\n  limits, writes the index, and emits `hreflang` alternates when given a `localeUrl`. A hand-built\n  sitemap usually has none of these, and joining URLs by string concatenation produces addresses\n  like `//sitemap.xml`.\n- **Live preview and click-to-edit.** `@ebitex/content-sdk/preview` needs the annotated responses\n  of a preview session. A client that parses only the fields it renders discards the annotations,\n  so the editor cannot point at anything on the page. This is the feature a hand-written client\n  most often loses without anyone noticing.\n- **Locale addressing.** Under the *path prefix* and *locale host* strategies every address the API\n  returns already carries its language (see [Locale addressing](locale-addressing.md)). A client\n  that adds its own `/${locale}` prefix doubles it (`/fr/fr/cafes`), and one that assumes a prefix\n  where the site has none links its home page to a 404.\n- **Caching and invalidation.** What may be cached, for how long, under which key, and what a\n  publish should purge.\n- **References that need expanding.** A delivered Presentation is usually a reference. A renderer\n  that does not ask the API to resolve it renders a hollow page and nothing reports it.\n\nIf you do write your own client, treat that list as the checklist of what you are taking on.\n\n## Moving a hand-written client to the SDK\n\nYou can move in steps and keep your own renderers and parsers:\n\n1. Install the package and create a client with the same key you use now.\n2. Replace the fetch calls with the client's methods, one endpoint at a time. The responses are the\n   API's own, so the code that reads them keeps working.\n3. Remove any locale prefix your code adds, if the site's locale addressing is not *invariant*.\n4. Replace the sitemap and `robots` code with `buildSitemapDocuments`.\n5. Add the preview bridge from `@ebitex/content-sdk/preview`, and have your preview route call the\n   preview endpoints so the responses carry their annotations.\n6. Delete the hand-written client and its tests.\n\n## Related\n\n- [Building a content model through the API](agent-authoring.md): the model, before the site\n- [Locale addressing](locale-addressing.md): how addresses carry a language\n- [Publishing content](publishing.md): what the Delivery API serves, and when\n- [Management keys](management-keys.md) and [Deployment keys](deployment-keys.md): the two kinds of key\n"
+        "body": "# Rendering your site\n\nRead this before you write any code that fetches published content. Content is published to the\n**Content Delivery API**, and ebitex ships a client for it: **`@ebitex/content-sdk`** on npm (and\n`Ebitex.Content.Delivery` on NuGet for a .NET server). Use it unless you have a reason not to. The\nreasons are below, because a hand-written client looks easy on the day it is written and costs the\nmost later.\n\nThis page is for the person or agent building the site that shows the content. Building the content\nmodel itself is [Building a content model through the API](agent-authoring.md).\n\n## Start from the SDK\n\n```sh\nnpm install @ebitex/content-sdk\n```\n\n- **A Vite and React site** that renders in the browser: `createContentClient` and the components in\n  `@ebitex/content-sdk/react`.\n- **A Next.js (or other server-rendered) site**: the same package, with the key kept on the server.\n  The guide is *Render content on a server* at developers.ebitex.io.\n- **A .NET server**: `Ebitex.Content.Delivery`.\n\nGuides, the API reference and the SDK reference are all at **developers.ebitex.io**. For the exact\nshape of a request or a response, read the OpenAPI document at `https://api.ebitex.io/openapi/public.json`\nrather than inferring it from a few responses you have seen.\n\n## What you stop maintaining\n\nA site that calls the Delivery API with its own `fetch` code owns all of this, and none of it shows\nup until something breaks:\n\n- **Path resolution, components, streams and facets, media and response parsing.** The SDK has one\n  method per endpoint and is updated when the API is. A client written against the responses seen on\n  one day is wrong the first day the API adds a member or a mode.\n- **The sitemap.** `buildSitemapDocuments` (in `@ebitex/content-sdk/sitemap`) splits at the protocol\n  limits, writes the index, and emits `hreflang` alternates when given a `localeUrl`. A hand-built\n  sitemap usually has none of these, and joining URLs by string concatenation produces addresses\n  like `//sitemap.xml`.\n- **Live preview and click-to-edit.** `@ebitex/content-sdk/preview` needs the annotated responses\n  of a preview session. A client that parses only the fields it renders discards the annotations,\n  so the editor cannot point at anything on the page. This is the feature a hand-written client\n  most often loses without anyone noticing.\n- **Locale addressing.** Under the *path prefix* and *locale host* strategies every address the API\n  returns already carries its language (see [Locale addressing](locale-addressing.md)). A client\n  that adds its own `/${locale}` prefix doubles it (`/fr/fr/cafes`), and one that assumes a prefix\n  where the site has none links its home page to a 404.\n- **Caching and invalidation.** What may be cached, for how long, under which key, and what a\n  publish should purge.\n- **References that need expanding.** A delivered Presentation is usually a reference. A renderer\n  that does not ask the API to resolve it renders a hollow page and nothing reports it.\n\nIf you do write your own client, treat that list as the checklist of what you are taking on.\n\n## Building in a sandbox\n\nAn organization an agency is building for a client is a **sandbox**. Every Delivery API response from it carries an `X-Ebitex-Sandbox` header and `X-Robots-Tag: noindex`, so a site rendered from it is not indexed by search engines. The SDK reads the header: the client's `sandbox` property says whether the content came from a sandbox, `buildSitemapDocuments` answers a `robots` document that disallows everything while it does, and `onSandbox` lets your renderer add a visible marker. When the sandbox goes live the header disappears and the same code serves a normal site, with nothing to change. See [Agencies and sandboxes](../hub/agencies.md).\n\n## Moving a hand-written client to the SDK\n\nYou can move in steps and keep your own renderers and parsers:\n\n1. Install the package and create a client with the same key you use now.\n2. Replace the fetch calls with the client's methods, one endpoint at a time. The responses are the\n   API's own, so the code that reads them keeps working.\n3. Remove any locale prefix your code adds, if the site's locale addressing is not *invariant*.\n4. Replace the sitemap and `robots` code with `buildSitemapDocuments`.\n5. Add the preview bridge from `@ebitex/content-sdk/preview`, and have your preview route call the\n   preview endpoints so the responses carry their annotations.\n6. Delete the hand-written client and its tests.\n\n## Related\n\n- [Building a content model through the API](agent-authoring.md): the model, before the site\n- [Locale addressing](locale-addressing.md): how addresses carry a language\n- [Publishing content](publishing.md): what the Delivery API serves, and when\n- [Management keys](management-keys.md) and [Deployment keys](deployment-keys.md): the two kinds of key\n"
     },
     {
         "slug": "sample-references",

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,2yZAA2yZ;KACpzZ;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,4s0BAA4s0B;KACrt0B;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,o9lBAAo9lB;KAC79lB;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,iqQAAiqQ;KAC1qQ;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,g6HAAg6H;KACz6H;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,o+LAAo+L;KAC7+L;IACD;QACE,MAAM,EAAE,iBAAiB;QACzB,OAAO,EAAE,iBAAiB;QAC1B,MAAM,EAAE,6uNAA6uN;KACtvN;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,QAAQ;QAChB,OAAO,EAAE,QAAQ;QACjB,MAAM,EAAE,wnOAAwnO;KACjoO;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,qiPAAqiP;KAC9iP;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,2yZAA2yZ;KACpzZ;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,4s0BAA4s0B;KACrt0B;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,o9lBAAo9lB;KAC79lB;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,iqQAAiqQ;KAC1qQ;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,g6HAAg6H;KACz6H;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,o+LAAo+L;KAC7+L;IACD;QACE,MAAM,EAAE,iBAAiB;QACzB,OAAO,EAAE,iBAAiB;QAC1B,MAAM,EAAE,6uNAA6uN;KACtvN;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,QAAQ;QAChB,OAAO,EAAE,QAAQ;QACjB,MAAM,EAAE,spOAAspO;KAC/pO;IACD;QACE,MAAM,EAAE,qBAAqB;QAC7B,OAAO,EAAE,qBAAqB;QAC9B,MAAM,EAAE,i2JAAi2J;KAC12J;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,qiPAAqiP;KAC9iP;CACF,CAAA"}

package/package.json

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