@ebitex/content-mcp 1.0.226 → 1.0.242

package/dist/resources/helpCorpus.generated.js

@@ -96,7 +96,7 @@ export const HELP_TOPICS = [
     {
         "slug": "locale-addressing",
         "title": "Locale addressing",
-        "body": "# Locale addressing\n\nIf your site is published in more than one language, locale addressing decides how a page's\naddress says which language it is in. You choose it once per site, and every address the site\nreceives from Content follows it: links inside your content, navigation, the sitemap, and the\naddress of the page itself.\n\nA site that only has one language doesn't need to change anything here.\n\n## Where to find it\n\nOpen **Sites** (under **Settings**) and click a site's name. The **Locale addressing** section sits\nabove the host mapping. You need the same permission that lets you edit a site's hosts.\n\nIf your authoring environment publishes to more than one delivery environment, pick the one you\nwant first with the **Delivery environment** selector at the top. Each delivery environment has its\nown setting, so you can try a change on Staging before Production.\n\n## Choosing a strategy\n\n- **Invariant** — addresses carry no language. `/about` is `/about` whatever language the visitor\n  reads it in, and the site chooses the language some other way. This is how every site works until\n  you change it.\n- **Path prefix** — the language is the first part of the address: `/fr/cafes` is the French\n  café page. Pages in your organization's default language have no prefix (`/about`) unless you\n  turn on **Prefix the default locale too**, in which case they live at `/en/about` as well.\n  Whichever you choose, the other spelling redirects, so every page has exactly one address.\n- **Locale host** — each language has its own host. That can be a subdomain (`fr.example.com`) or\n  a completely separate domain (`example.fr`); both work the same way.\n\n## Per-locale hosts\n\nWith **Locale host** selected, the host mapping becomes a table: one row per host, with the\nlanguage that host serves beside it. Every language your organization has — the default one\nincluded — needs a host, and each language can have only one. If one is missing, the page tells\nyou which, and saving is refused until it has one.\n\nIf you add a new language to your organization later, it won't have a host until you add one here;\nuntil then, links to that language use the site's first host.\n\n## Host order\n\nThe first host in the list is the site's main one. When a page on another of your sites links to\nthis one, the link is written with that host (under **Locale host**, with the host for the language\nbeing linked to). Reorder the lines, or use the arrows in the table, to change which host is first.\n\n## Saving\n\nChanging the strategy is saved with the **Save locale addressing** button, which saves the host\nmapping at the same time — switching to **Locale host** needs its languages in the same save, and\nswitching away from it clears them. While a strategy change is unsaved, **Save hosts** waits for it.\n\n## What changes for your site\n\nOnce saved, every address the site receives is already written the new way: a French page's links\narrive as `/fr/…` (or `https://fr.example.com/…`), and the site just uses them as they are. A link\nto another of your sites always follows *that* site's strategy, and is written with its host.\n\nThis is a change to every address the site receives, so coordinate it with whoever builds the site\nbefore you save it on a live delivery environment. The site needs a version of the Content SDK that\nunderstands locale addressing, and it must stop adding language prefixes of its own — otherwise\nlinks come out doubled, like `/fr/fr/cafes`.\n\nLive preview in the Composer writes links the same way, using the delivery environment of the host\nit is showing.\n\n## A one-time \"Not found\" that isn't an addressing problem\n\nThe first time a language gets a translated slug — say, the first page you give a French address —\nevery page given a French address in that same publish stops answering at its old French address,\nand that old address shows **Not found** instead of redirecting. It happens once per language (and\nagain for the first Spanish slug, and so on).\n\nIt happens under every strategy, because it's about when a language's addresses first come into\nexistence, not about how addresses are written. Changing strategy won't prevent it or fix it.\n"
+        "body": "# Locale addressing\n\nIf your site is published in more than one language, locale addressing decides how a page's\naddress says which language it is in. You choose it once per site, and every address the site\nreceives from Content follows it: links inside your content, navigation, the sitemap, and the\naddress of the page itself.\n\nA site that only has one language doesn't need to change anything here.\n\n## Where to find it\n\nOpen **Sites** (under **Settings**) and click a site's name. The **Locale addressing** section sits\nabove the host mapping. You need the same permission that lets you edit a site's hosts.\n\nIf your authoring environment publishes to more than one delivery environment, pick the one you\nwant first with the **Delivery environment** selector at the top. Each delivery environment has its\nown setting, so you can try a change on Staging before Production.\n\n## Which languages a site serves\n\nBefore you choose how addresses show the language, choose which languages the site serves. In the\nsame drill-in, the **Languages** section sits above **Locale addressing**.\n\n- **Follows the organization.** This is how every site starts. The site serves every language your\n  organization has enabled, and a language the organization adds or removes changes the site at once.\n- **Customized.** Select **Customize languages** and the site starts from a copy of your organization's\n  languages as they are arranged today. From then on it is its own: tick the languages it serves, and for\n  each one choose the language it falls back to, the default or another one the site serves. A site can\n  serve only the default language, which is useful for a site that isn't translated.\n\nA customized site always has your organization's default language. A request for a language the site\ndoesn't serve is refused rather than answered with the wrong language, so make sure the site's\ndevelopers have a recent version of the Content SDK before you customize it.\n\n**Use the organization's languages** puts a customized site back to following the organization. It\n*adds* languages rather than removing them, and the languages you picked for the site are discarded,\nso it asks before it does it.\n\nIf a **Locale host** site maps a host to a language, you can't stop serving that language until you change\nthe host first. Your organization's page under **Organizations**, **Localization** lists which sites follow\nits languages and which have their own, and it won't remove a language a customized site still serves.\n\nTranslators are offered the languages the sites that content reaches serve. A shared environment is offered\nwhat the sites in the environments built on it serve. It is an offer: nothing is marked as missing.\n\n## Choosing a strategy\n\n- **Invariant** — addresses carry no language. `/about` is `/about` whatever language the visitor\n  reads it in, and the site chooses the language some other way. This is how every site works until\n  you change it.\n- **Path prefix** — the language is the first part of the address: `/fr/cafes` is the French\n  café page. Pages in your organization's default language have no prefix (`/about`) unless you\n  turn on **Prefix the default locale too**, in which case they live at `/en/about` as well.\n  Whichever you choose, the other spelling redirects, so every page has exactly one address.\n- **Locale host** — each language has its own host. That can be a subdomain (`fr.example.com`) or\n  a completely separate domain (`example.fr`); both work the same way.\n\n## Per-locale hosts\n\nWith **Locale host** selected, the host mapping becomes a table: one row per host, with the\nlanguage that host serves beside it. Every language your organization has — the default one\nincluded — needs a host, and each language can have only one. If one is missing, the page tells\nyou which, and saving is refused until it has one.\n\nIf you add a new language to your organization later, it won't have a host until you add one here;\nuntil then, links to that language use the site's first host.\n\n## Host order\n\nThe first host in the list is the site's main one. When a page on another of your sites links to\nthis one, the link is written with that host (under **Locale host**, with the host for the language\nbeing linked to). Reorder the lines, or use the arrows in the table, to change which host is first.\n\n## Saving\n\nChanging the strategy is saved with the **Save locale addressing** button, which saves the host\nmapping at the same time — switching to **Locale host** needs its languages in the same save, and\nswitching away from it clears them. While a strategy change is unsaved, **Save hosts** waits for it.\n\n## What changes for your site\n\nOnce saved, every address the site receives is already written the new way: a French page's links\narrive as `/fr/…` (or `https://fr.example.com/…`), and the site just uses them as they are. A link\nto another of your sites always follows *that* site's strategy, and is written with its host.\n\nThis is a change to every address the site receives, so coordinate it with whoever builds the site\nbefore you save it on a live delivery environment. The site needs a version of the Content SDK that\nunderstands locale addressing, and it must stop adding language prefixes of its own — otherwise\nlinks come out doubled, like `/fr/fr/cafes`.\n\nLive preview in the Composer writes links the same way, using the delivery environment of the host\nit is showing.\n\n## A one-time \"Not found\" that isn't an addressing problem\n\nThe first time a language gets a translated slug — say, the first page you give a French address —\nevery page given a French address in that same publish stops answering at its old French address,\nand that old address shows **Not found** instead of redirecting. It happens once per language (and\nagain for the first Spanish slug, and so on).\n\nIt happens under every strategy, because it's about when a language's addresses first come into\nexistence, not about how addresses are written. Changing strategy won't prevent it or fix it.\n"
     },
     {
         "slug": "management-keys",
@@ -141,7 +141,7 @@ export const HELP_TOPICS = [
     {
         "slug": "visitor-access",
         "title": "Members-only pages (visitor access)",
-        "body": "# Members-only pages (visitor access)\n\nYou can keep a whole site, a section or a single page for the members of an **audience**. Everyone else is served an **unlock page** instead, and the restricted page's content, title and address are not sent to them at all. The restriction is enforced by the server, not by the page, so it holds whatever your website does.\n\nThis is different from [personalization](content-personalization.md), which changes what a page *says* for a visitor. A personalized page is still sent to everyone; a restricted page is not.\n\nThe **Visitor access** card appears only when your organization has visitor access turned on. If you do not see it, ask an organization Owner. Changing a rule needs the **Manage visitor access** permission; anyone who can see a page can read who may see it.\n\n## Setting a rule\n\nOpen a page, a section or the site's top page in **Composer** and find the **Visitor access** card. Choose one of three:\n\n- **Follow the parent.** The page is restricted if the closest page above it with a rule is. On the site's top page this reads **Follow the default** and means public.\n- **Open to everyone.** Overrides a restriction above, so one page in a members-only section can be public.\n- **Restrict to an audience.** Choose the audience. Only its members are served the page, and everything under it that follows it.\n\nThe card also says, in a sentence, who can see the page now, and where the rule comes from when it is inherited. Click the name to go there.\n\nA rule is saved at once, but, like any other change to a page, it reaches your website only when the page is **published**. Publishing a restricted page also publishes its unlock page and any restricted section above it that is not yet published, so a restriction is never missing from the live site.\n\n### Who can see this page\n\nThe table at the bottom of the card shows what happens to each kind of visitor, so you can check a rule without trying it:\n\n| Visitor | What happens |\n|---|---|\n| Not a member | Gets the unlock page |\n| Member, email not verified | Opens the page, or is asked to confirm their email, depending on the audience (below) |\n| Member, verified | Opens the page |\n\n### Which audiences you can choose\n\nOnly an audience with **stored members** can be chosen: one whose rule is about a person, such as \"has bought twice\". An audience that reads something about the visit, such as the language of the page, is worked out for each request, and a request can claim anything, so it cannot grant access.\n\nEach audience carries its own setting for how strict its access is (see [Audiences and lifecycle](../audience/lifecycle-and-audiences.md#visitor-access)):\n\n- **Open membership.** Being a member is enough. The audience can name a form that makes someone a member, and the unlock page offers it. Anyone can type anyone else's email into a form, so this suits pages where that does not matter, such as a whitepaper.\n- **Verified access.** A member must also prove they hold their email address, by following a link emailed to it. The unlock page offers a sign-in. Use this for anything that matters.\n\nThe card says which of the two the chosen audience uses, and that it is set in the Audience app, not on the page.\n\n## The unlock page\n\nThe unlock page is an **Experience** like any other, built on the **Unlock page** platform Contract. It has a heading, a message, an optional teaser, and the label of the button that opens the way in. It is always public, even when it sits inside a restricted section.\n\nChoose it in the **Unlock page** line of the card:\n\n- **A page of its own.** Pick any Experience that qualifies. For a restricted placement you can also override the heading, message, teaser and button label **per language**, so one unlock page serves many places with the right words for each.\n- **The site default.** If a placement chooses none, visitors see the site's default unlock page. Set it from **Edit site default** on the card, or from the **Default unlock page** card on the site's top page.\n- **The plain built-in message.** If nothing is chosen anywhere, or the chosen page is not published, visitors see \"Members only\" and a short message in English. They always get an answer.\n\nTo make an Experience that can be chosen, base its Contract on the **Unlock page** platform Contract: in the Contract builder, choose it under **Based on a platform Contract**. Its four fields then appear at the top of the Contract, read-only. A Template that supports that Contract can then render an Experience of it. The card warns you if a page you chose no longer qualifies.\n\nA restricted page depends on its unlock page: publishing, promoting and exporting the page carry the unlock page along, and an unlock page that a rule uses cannot be deleted while it is in use.\n\n## In the page tree\n\nRestricted pages carry a badge in the tree: the audience's name where the rule is set, and **inherited** below it. An unlock page is marked **Unlock page**.\n\n**Preview as** above the tree strikes through the pages a kind of visitor would not be served: **Not a member**, **Member, email not verified** or **Member, verified**. **Editor** clears it. It draws what the rules say; it does not sign you in as anyone.\n\n## Things worth knowing\n\n- A restricted page never appears in the sitemap or in navigation for a visitor who may not read it.\n- Removing someone from an audience takes effect within minutes: a visitor's access is re-checked every few minutes while they browse.\n- Switching visitor access off for your organization stops editing, but any rule already set keeps being enforced. To open a page, change its rule.\n- Deleting an audience that a rule uses is refused until the rule is changed; the refusal lists where it is used.\n- A restriction protects the **page**, not the things it points at. Content written directly in a restricted page is protected with it, but a shared Component that the page *references*, or a file in Assets, can still be reached by someone who already knows its address. Keep anything that must stay private written directly in the page.\n"
+        "body": "# Members-only pages (visitor access)\n\nYou can keep a whole site, a section or a single page for the members of an **audience**. Everyone else is served an **unlock page** instead, and the restricted page's content, title and address are not sent to them at all. The restriction is enforced by the server, not by the page, so it holds whatever your website does.\n\nThis is different from [personalization](content-personalization.md), which changes what a page *says* for a visitor. A personalized page is still sent to everyone; a restricted page is not.\n\nThe **Visitor access** card appears only when your organization has visitor access turned on. If you do not see it, ask an organization Owner. Changing a rule needs the **Manage visitor access** permission; anyone who can see a page can read who may see it.\n\n## Setting a rule\n\nOpen a page, a section or the site's top page in **Composer** and find the **Visitor access** card. Choose one of three:\n\n- **Follow the parent.** The page is restricted if the closest page above it with a rule is. On the site's top page this reads **Follow the default** and means public.\n- **Open to everyone.** Overrides a restriction above, so one page in a members-only section can be public.\n- **Restrict to an audience.** Choose the audience. Only its members are served the page, and everything under it that follows it.\n\nThe card also says, in a sentence, who can see the page now, and where the rule comes from when it is inherited. Click the name to go there.\n\nA rule is saved at once, but, like any other change to a page, it reaches your website only when the page is **published**. Publishing a restricted page also publishes its unlock page and any restricted section above it that is not yet published, so a restriction is never missing from the live site.\n\n### Who can see this page\n\nThe table at the bottom of the card shows what happens to each kind of visitor, so you can check a rule without trying it:\n\n| Visitor | What happens |\n|---|---|\n| Not a member | Gets the unlock page |\n| Member, email not verified | Opens the page, or is asked to confirm their email, depending on the audience (below) |\n| Member, verified | Opens the page |\n\n### Which audiences you can choose\n\nOnly an audience with **stored members** can be chosen: one whose rule is about a person, such as \"has bought twice\". An audience that reads something about the visit, such as the language of the page, is worked out for each request, and a request can claim anything, so it cannot grant access.\n\nEach audience carries its own setting for how strict its access is (see [Audiences and lifecycle](../audience/lifecycle-and-audiences.md#visitor-access)):\n\n- **Open membership.** Being a member is enough. The audience can name a form that makes someone a member, and the unlock page offers it. Anyone can type anyone else's email into a form, so this suits pages where that does not matter, such as a whitepaper.\n- **Verified access.** A member must also prove they hold their email address, by following a link emailed to it. The unlock page offers a sign-in. Use this for anything that matters.\n\nThe card says which of the two the chosen audience uses, and that it is set in the Audience app, not on the page.\n\n## The unlock page\n\nThe unlock page is an **Experience** like any other, built on the **Unlock page** platform Contract. It has a heading, a message, an optional teaser, and the label of the button that opens the way in. It is always public, even when it sits inside a restricted section.\n\nChoose it in the **Unlock page** line of the card:\n\n- **A page of its own.** Pick any Experience that qualifies. For a restricted placement you can also override the heading, message, teaser and button label **per language**, so one unlock page serves many places with the right words for each.\n- **The site default.** If a placement chooses none, visitors see the site's default unlock page. Set it from **Edit site default** on the card, or from the **Default unlock page** card on the site's top page.\n- **The plain built-in message.** If nothing is chosen anywhere, or the chosen page is not published, visitors see \"Members only\" and a short message in English. They always get an answer.\n\nTo make an Experience that can be chosen, base its Contract on the **Unlock page** platform Contract: in the Contract builder, choose it under **Based on a platform Contract**. Its four fields then appear at the top of the Contract, read-only. A Template that supports that Contract can then render an Experience of it. The card warns you if a page you chose no longer qualifies.\n\nA restricted page depends on its unlock page: publishing, promoting and exporting the page carry the unlock page along, and an unlock page that a rule uses cannot be deleted while it is in use.\n\n## In the page tree\n\nRestricted pages carry a badge in the tree: the audience's name where the rule is set, and **inherited** below it. An unlock page is marked **Unlock page**.\n\n**Preview as** above the tree strikes through the pages a kind of visitor would not be served: **Not a member**, **Member, email not verified** or **Member, verified**. **Editor** clears it. It draws what the rules say; it does not sign you in as anyone.\n\n## Things worth knowing\n\n- A restricted page never appears in the sitemap or in navigation for a visitor who may not read it.\n- Removing someone from an audience takes effect within minutes: a visitor's access is re-checked every few minutes while they browse.\n- Switching visitor access off for your organization stops editing, but any rule already set keeps being enforced. To open a page, change its rule.\n- Deleting an audience that a rule uses is refused until the rule is changed; the refusal lists where it is used.\n- A restriction protects the **page**, not the things it points at. Content written directly in a restricted page is protected with it, but a shared Component that the page *references*, can still be reached by someone who already knows its address. A file in Assets is different: you can limit a private file to an audience in Assets (see *Limiting a private file to an audience*), and then it has no link at all for anyone else, wherever a page shows it. Keep anything else that must stay private written directly in the page.\n\n## Gate a download behind a form\n\nA public page can hold back a report until a visitor asks for it. This is how ebitex.io's own whitepaper works, built only from ordinary pieces:\n\n1. **A private file in Assets**, limited to an audience (see *Limiting a private file to an audience* in the Assets guide).\n2. **An audience that stores its members**, for example \"Whitepaper readers\", with rule \"submitted the whitepaper form\". Turn on **verified access** in Audience if a member must also prove their email.\n3. **A form in Forms** with the ebitex Audience destination, so a submission adds the person to the audience.\n4. **A page with a personalizable Presentation field.** Its **default** is the teaser everyone gets: what is inside, the form, and a way to ask for a sign-in link. Add a **variant** on the audience: the card with the download. Anyone who is not a member never receives the variant, so the file link is not in the page they load.\n5. **Share the page.** A visitor submits the form, follows the emailed link if the audience asks for verified email, and the same page now shows the download.\n\nThe visitor's device is recognised for the visit without storing anything. Remembering them on later visits needs their consent, which your site asks for itself. Give people who decline a way to ask again: the sign-in link does that.\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,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"}
+{"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,o+LAAo+L;KAC7+L;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,qiPAAqiP;KAC9iP;CACF,CAAA"}

package/package.json

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