@ebitex/content-mcp 1.1.268 → 1.1.269

package/dist/resources/helpCorpus.generated.js

@@ -46,7 +46,7 @@ export const HELP_TOPICS = [
     {
         "slug": "content-modelling",
         "title": "Modelling your content: best practices",
-        "body": "# Modelling your content: best practices\n\nHow to shape Contracts, Templates and Components so a site is easy to build, easy to change and hard to break. It applies whether you model in Content, through the API, or as code, and it is the model the starter kit follows. Read it before you create anything, and read [Building a content model through the API](agent-authoring.md) for the mechanics.\n\n## The one idea\n\n**A Contract holds what is said. A Template holds how it is shown.**\n\n- A **Contract** has editorial fields only: a heading, a body, an image, a link, a label. Nothing about width, colour, columns, emphasis or order of appearance.\n- A **Template** says how a Contract is drawn, and owns a **settings Contract** for every choice that belongs to a *place*: width, background, appearance, layout, a card's emphasis, a banner's tone, a grid's columns, how an accordion opens.\n- A **presentation** is the pair in use: a Template, its settings, and a Component. The same Component can appear on many pages, each with its own settings, so it looks or behaves differently in each, and the words live in one place.\n\nIf you catch yourself adding \"layout\", \"width\" or \"variant\" to a content Contract, it belongs in a Template's settings.\n\n## Choose the right kind of field\n\n| You want | Use | Why |\n|---|---|---|\n| A hero or a list of sections on a page | A **presentation** field, with the Templates it accepts | An editor picks how it is drawn, sets the choices for that place, and supplies the content |\n| A part with no life of its own (a button inside a hero, a tab's label) | An **inline** component | Nothing else can point at it, and it is deleted with what holds it |\n| A thing reused across pages (a testimonial, a venue) | A **reference** to a Component | One edit changes it everywhere |\n| One of a closed set of choices (a theme, a tone) | A **category** from a group | A renderer maps the key; an organization can rename or extend the values |\n| Media | A reference to an **Assets** item | The media library owns files, not Content |\n\nPrefer a presentation field over a component field whenever the thing is *drawn* on a page. A component field gives the editor no place to say how.\n\n## Templates and Contracts\n\n- **One Template per Contract by default.** A Template may also support a Contract another Template supports. That is the right tool when the *same* content needs two genuinely different presentations (a statement and a feature over the same heading, body, media and links): keep the Contract generic and add a Template, instead of copying the Contract.\n- A Template can list several supported Contracts, so a generic abstract parent (\"heading, body, media, links\") can serve one Template for every Contract beneath it.\n- **A renderer is chosen by Template, never by Contract.** That is what makes the many-to-one case work, and what makes a container reusable: it hands each item to the same dispatch the page uses.\n- **A Contract has one parent.** Shared settings are therefore a chain, not a mix: a base for sections (width, background, appearance, anchor), a base for grid cells that extends it (adds span), then each Template's own. Model the chain you need; you cannot inherit two bases.\n- Make a shared base **abstract** so it is never placed on its own.\n\n## Containers are components, not special cases\n\nTabs, accordions, carousels and grids hold *other presentations*. Model them as higher-order components:\n\n- The container has an **inline list of item Contracts**. An item is a **label** (content, localizable) plus an **enumerable presentation field** limited to the Templates suitable inside it.\n- A whole FAQ is then one Component you can reuse on every page that needs it.\n- **How a container behaves** (one drawer open at a time or independent, which start open, how many columns) is a **setting of its Template**, not content. The same Component can behave differently wherever it is used.\n- A container accepts **leaf Templates only**. Never let a container accept itself or another container: Contracts and Templates would depend on each other in a loop and cannot be installed in order.\n\n## Allow-lists\n\n- A presentation field names the Templates it accepts (`allowedTemplateIds`); a component field names its Contracts and modes. **Unset means anything. An empty list means nothing.** Say which you mean, and give an editor a clear control to switch.\n- Prefer an **explicit list** for a field with a clear purpose (a hero accepts the Hero Template only; sections never accept the Hero or the page itself). The cost is that a Template you add later is not offered until you add it to the list, which is a deliberate step, not a surprise.\n- Leave a field **open** only when anything really is valid.\n\n## Settings and vocabularies\n\n- Put every closed choice in a **category group**, never free text, so a renderer can map a key and an organization can edit the values. A category key is what a renderer maps, so **never rename a key**.\n- A category field takes **no default**: an unset choice means \"the renderer's default\". When a nested part should follow its parent, add an explicit **inherit** value to the group and treat it, and an unset value, as \"the parent's\". A renderer can then cascade it (an appearance on a section reaches everything inside it, and a nested part that chooses its own overrides it).\n- Keep a theme or any page-wide look in the **page Template's settings**, so the same page Component can be drawn differently.\n- Keep identifiers and settings **non-localizable**; make prose (headings, body, labels) **localizable**.\n\n## Naming\n\n- Field ids are **kebab-case** (`primary-action`, `meta-title`). A field id is a property name in every delivered document, a path in filters and ordering, and a key in queries, and those accept kebab-case only. A model that ships camelCase ids is uneditable later.\n- Give everything you ship a **prefix** so a customer's own keys can never collide with it. Do not shadow keys that other apps own (the Assets Contracts).\n- Name an editor-built page an **experience**, and avoid the word \"page\" in keys: the same content can be a page, a section of one, or an email.\n\n## Building a renderer\n\n- Register one renderer per **Template** in the SDK's renderer map: `{ ...kitRenderers, 'my-template': MyRenderer }`. A Template with no renderer shows the host's fallback and never breaks the page.\n- A renderer receives the Template, its **settings** and the Component's **content**. Draw inside the shared frame so the Template's width, background, anchor and appearance apply, and so your Template joins the appearance cascade.\n- Read a category by its **key**, with a fallback for a key you do not know, so a value an organization adds degrades to the default rather than breaking the page.\n- Test against a **real delivery response** (install the model, publish, read it back), not one you wrote by hand: a hand-written fixture can pass while the real server sends something else.\n\n## Shipping a model to others\n\nIf you distribute a model (a starter kit, a template for clients), treat it like an API:\n\n- **Semver.** A change to a shipped Contract or Template's shape is a **major** version. Within a major version, mark things deprecated and leave them in place.\n- **Never mix a new major version into an older install.** Give each major version a **marker** Contract that exists only in it. An environment that holds some of the model but not the marker holds an earlier version: refuse the install, write nothing, and leave the existing copy exactly as it is.\n- Install the model into **two organizations in one database** in a test: ids that the model carries must be rewritten per organization.\n- **Save every Contract unchanged** through the real save rules after installing it. An import writes without asking those rules, so a model can install cleanly and still be impossible to edit.\n- Give people a **migration note** with every breaking release, even if the answer is \"install into a new environment\".\n\n## A checklist\n\n1. Does every Contract hold only editorial content?\n2. Is every placement, appearance or behaviour choice a setting of a Template?\n3. Is every closed choice a category with no default, and every nested follow-the-parent choice an `inherit`?\n4. Does every presentation field name the Templates it accepts, and do containers accept leaf Templates only?\n5. Are all field ids kebab-case and all prose localizable?\n6. Is there a renderer for every Template, registered by Template?\n7. If you ship it: is there a major-version marker, a changelog, and a test that installs it twice and saves every Contract?\n"
+        "body": "# Modelling your content: best practices\n\nHow to shape Contracts, Templates and Components so a site is easy to build, easy to change and hard to break. It applies whether you model in Content, through the API, or as code, and it is the model the starter kit follows. Read it before you create anything, and read [Building a content model through the API](agent-authoring.md) for the mechanics.\n\n## The one idea\n\n**A Contract holds what is said. A Template holds how it is shown.**\n\n- A **Contract** has editorial fields only: a heading, a body, an image, a link, a label. Nothing about width, colour, columns, emphasis or order of appearance.\n- A **Template** says how a Contract is drawn, and owns a **settings Contract** for every choice that belongs to a *place*: width, background, appearance, layout, a card's emphasis, a banner's tone, a grid's columns, how an accordion opens.\n- A **presentation** is the pair in use: a Template, its settings, and a Component. The same Component can appear on many pages, each with its own settings, so it looks or behaves differently in each, and the words live in one place.\n\nIf you catch yourself adding \"layout\", \"width\" or \"variant\" to a content Contract, it belongs in a Template's settings.\n\n## Choose the right kind of field\n\n| You want | Use | Why |\n|---|---|---|\n| A hero or a list of sections on a page | A **presentation** field, with the Templates it accepts | An editor picks how it is drawn, sets the choices for that place, and supplies the content |\n| A part with no life of its own (a button inside a hero, a tab's label) | An **inline** component | Nothing else can point at it, and it is deleted with what holds it |\n| A thing reused across pages (a testimonial, a venue) | A **reference** to a Component | One edit changes it everywhere |\n| One of a closed set of choices (a theme, a tone) | A **category** from a group | A renderer maps the key; an organization can rename or extend the values |\n| Media | A reference to an **Assets** item | The media library owns files, not Content |\n\nPrefer a presentation field over a component field whenever the thing is *drawn* on a page. A component field gives the editor no place to say how.\n\n## Templates and Contracts\n\n- **One Template per Contract by default.** A Template may also support a Contract another Template supports. That is the right tool when the *same* content needs two genuinely different presentations (a statement and a feature over the same heading, body, media and links): keep the Contract generic and add a Template, instead of copying the Contract.\n- A Template can list several supported Contracts, so a generic abstract parent (\"heading, body, media, links\") can serve one Template for every Contract beneath it.\n- **A renderer is chosen by Template, never by Contract.** That is what makes the many-to-one case work, and what makes a container reusable: it hands each item to the same dispatch the page uses.\n- **A Contract has one parent.** Shared settings are therefore a chain, not a mix: a base for sections (width, background, appearance, anchor), a base for grid cells that extends it (adds span), then each Template's own. Model the chain you need; you cannot inherit two bases.\n- Make a shared base **abstract** so it is never placed on its own.\n\n## Containers are components, not special cases\n\nTabs, accordions, carousels and grids hold *other presentations*. Model them as higher-order components:\n\n- The container has an **inline list of item Contracts**. An item is a **label** (content, localizable) plus an **enumerable presentation field** limited to the Templates suitable inside it.\n- A whole FAQ is then one Component you can reuse on every page that needs it.\n- **How a container behaves** (one drawer open at a time or independent, which start open, how many columns) is a **setting of its Template**, not content. The same Component can behave differently wherever it is used.\n- A container accepts **leaf Templates only**. Never let a container accept itself or another container: Contracts and Templates would depend on each other in a loop and cannot be installed in order.\n- The one exception is a **grouping** container, a heading over a list of presentations (the kit's Group). It may hold the other containers (a heading over a grid, over an accordion), and it must never hold itself, so there is still no loop. Give it its own settings for width, background, appearance, spacing and alignment, so one appearance and one spacing govern a heading and what it introduces, and a presentation inside can still choose its own appearance.\n\n## Site-wide presentations: a header and a footer\n\nA presentation can be delivered only as a page at a path or as a **field of another document**, never alone by id. So something every page shares (a header, a footer) is a presentation held by a small **standalone Component** with a fixed external id. The app fetches that Component by its id, once per session, and draws the two presentations through the same renderers as everything else, so each still has a Template and its own settings and a host can replace either by registering its own renderer. Do not make them page nodes: a node is a public route, appears in the site tree and in its navigation, and needs excluding from search. Publish the holder as its own root, because no page refers to it, and let a half that is not published draw nothing so a site without one is unchanged.\n\n## Allow-lists\n\n- A presentation field names the Templates it accepts (`allowedTemplateIds`); a component field names its Contracts and modes. **Unset means anything. An empty list means nothing.** Say which you mean, and give an editor a clear control to switch.\n- Prefer an **explicit list** for a field with a clear purpose (a hero accepts the Hero Template only; sections never accept the Hero or the page itself). The cost is that a Template you add later is not offered until you add it to the list, which is a deliberate step, not a surprise.\n- Leave a field **open** only when anything really is valid.\n\n## Settings and vocabularies\n\n- Put every closed choice in a **category group**, never free text, so a renderer can map a key and an organization can edit the values. A category key is what a renderer maps, so **never rename a key**.\n- A category field takes **no default**: an unset choice means \"the renderer's default\". When a nested part should follow its parent, add an explicit **inherit** value to the group and treat it, and an unset value, as \"the parent's\". A renderer can then cascade it (an appearance on a section reaches everything inside it, and a nested part that chooses its own overrides it).\n- Keep a theme or any page-wide look in the **page Template's settings**, so the same page Component can be drawn differently.\n- Keep identifiers and settings **non-localizable**; make prose (headings, body, labels) **localizable**.\n\n## Naming\n\n- Field ids are **kebab-case** (`primary-action`, `meta-title`). A field id is a property name in every delivered document, a path in filters and ordering, and a key in queries, and those accept kebab-case only. A model that ships camelCase ids is uneditable later.\n- Give everything you ship a **prefix** so a customer's own keys can never collide with it. Do not shadow keys that other apps own (the Assets Contracts).\n- Name an editor-built page an **experience**, and avoid the word \"page\" in keys: the same content can be a page, a section of one, or an email.\n\n## Building a renderer\n\n- Register one renderer per **Template** in the SDK's renderer map: `{ ...kitRenderers, 'my-template': MyRenderer }`. A Template with no renderer shows the host's fallback and never breaks the page.\n- A renderer receives the Template, its **settings** and the Component's **content**. Draw inside the shared frame so the Template's width, background, anchor and appearance apply, and so your Template joins the appearance cascade.\n- Read a category by its **key**, with a fallback for a key you do not know, so a value an organization adds degrades to the default rather than breaking the page.\n- Test against a **real delivery response** (install the model, publish, read it back), not one you wrote by hand: a hand-written fixture can pass while the real server sends something else.\n\n## Shipping a model to others\n\nIf you distribute a model (a starter kit, a template for clients), treat it like an API:\n\n- **Semver.** A change to a shipped Contract or Template's shape is a **major** version. Within a major version, mark things deprecated and leave them in place.\n- **Never mix a new major version into an older install.** Give each major version a **marker** Contract that exists only in it. An environment that holds some of the model but not the marker holds an earlier version: refuse the install, write nothing, and leave the existing copy exactly as it is.\n- Install the model into **two organizations in one database** in a test: ids that the model carries must be rewritten per organization.\n- **Save every Contract unchanged** through the real save rules after installing it. An import writes without asking those rules, so a model can install cleanly and still be impossible to edit.\n- Give people a **migration note** with every breaking release, even if the answer is \"install into a new environment\".\n\n## A checklist\n\n1. Does every Contract hold only editorial content?\n2. Is every placement, appearance or behaviour choice a setting of a Template?\n3. Is every closed choice a category with no default, and every nested follow-the-parent choice an `inherit`?\n4. Does every presentation field name the Templates it accepts, and do containers accept leaf Templates only?\n5. Are all field ids kebab-case and all prose localizable?\n6. Is there a renderer for every Template, registered by Template?\n7. If you ship it: is there a major-version marker, a changelog, and a test that installs it twice and saves every Contract?\n"
     },
     {
         "slug": "content-personalization",
@@ -136,7 +136,7 @@ export const HELP_TOPICS = [
     {
         "slug": "starter-kit",
         "title": "Starter kits",
-        "body": "# Starter kits\n\nA **starter kit** gives you a working set of Contracts, Templates, categories and a demo experience, so you start from something instead of nothing. Install it once, then change anything you like: it becomes your own content and never updates by itself.\n\n## Adding a starter kit\n\nOpen **Starter kits** under **Tools**.\n\n1. Read what the kit will add and what you already have, and any permission you are missing. The page tells you before you start, not after.\n2. If Assets is not connected, connect it from the same page first. The kit's media fields choose from your Assets library.\n3. Leave **Include the demo experience** on if you want a finished example to learn from, or clear it to add only the building blocks. The demo's items are all named \"Demo\".\n4. Select **Install the kit**.\n\nWhen it finishes the page tells you the kit is installed, and links to your Contracts and Templates.\n\n## What is safe\n\n- Nothing you already have is changed. If an item with the same name exists, it is left exactly as it is and the preview tells you.\n- Running it again adds only what is missing.\n- If anything goes wrong, nothing from that attempt is kept.\n\n## How the kit is built\n\nThe kit separates **what a section says** from **how it is shown**.\n\n- A **Contract** holds only the content: a hero's heading and lead, a card's title and summary, a tab's label.\n- A **Template** says how a Contract is drawn, and has its own **settings** for the choices that belong to a place: width, background, appearance, a card's emphasis, a banner's tone, a grid's columns, how an accordion behaves.\n- An experience's **Hero** and **Sections** are *presentations*: you choose a Template, set its settings, and give it a Component. The same Component can be used on many pages, each with its own settings, so it looks or behaves differently in each.\n- **Tabs** and **Accordion** hold their own items. Each item is a label and the presentations inside it, so a whole FAQ is one Component you can reuse on every page that needs it.\n- Two Templates can present the same Contract in different ways. Make a second Template over a Contract when the same words need a different look, rather than copying the Contract.\n\n## After you install\n\nEverything is yours. Edit a Contract, rename a category, restyle a theme, or delete what you do not need. Nothing is linked back to the kit, and a newer version of the kit never changes what you have. Installing again adds only what is missing.\n\nA new **major** version of the kit is not mixed into an earlier one, because its Templates would sit beside Contracts of the old shape. If your environment holds an earlier version, the install tells you so and changes nothing; your copy is left exactly as it is. To use the new version, install it into a new environment or organization.\n\nTo use your own Template in an experience's **Sections**, open the experience's Contract and add your Template to the Sections field's allowed Templates. The kit lists the Templates it accepts, so Hero and the experience itself can never be placed as a section.\n\n## Themes and appearances\n\nAn experience has a **theme**, which sets its colours, type and spacing, chosen in the experience Template's settings; leave it empty for the default. A section can have an **appearance** that adjusts the theme for that section and everything nested inside it; leave it on **Inherit** to take the parent's. Themes and appearances are categories, so you edit them under **Categories**.\n\n## Pictures and video\n\nMedia fields use the Assets app, so Assets has to be connected to Content before the kit can be installed. The Starter kits page offers the one-step **Connect Assets** card when it is not.\n"
+        "body": "# Starter kits\n\nA **starter kit** gives you a working set of Contracts, Templates, categories and a demo experience, so you start from something instead of nothing. Install it once, then change anything you like: it becomes your own content and never updates by itself.\n\n## Adding a starter kit\n\nOpen **Starter kits** under **Tools**.\n\n1. Read what the kit will add and what you already have, and any permission you are missing. The page tells you before you start, not after.\n2. If Assets is not connected, connect it from the same page first. The kit's media fields choose from your Assets library.\n3. Leave **Include the demo experience** on if you want a finished example to learn from, or clear it to add only the building blocks. The demo's items are all named \"Demo\".\n4. Select **Install the kit**.\n\nWhen it finishes the page tells you the kit is installed, and links to your Contracts and Templates.\n\n## What is safe\n\n- Nothing you already have is changed. If an item with the same name exists, it is left exactly as it is and the preview tells you.\n- Running it again adds only what is missing.\n- If anything goes wrong, nothing from that attempt is kept.\n\n## How the kit is built\n\nThe kit separates **what a section says** from **how it is shown**.\n\n- A **Contract** holds only the content: a hero's heading and lead, a card's title and summary, a tab's label.\n- A **Template** says how a Contract is drawn, and has its own **settings** for the choices that belong to a place: width, background, appearance, a card's emphasis, a banner's tone, a grid's columns, how an accordion behaves.\n- An experience's **Hero** and **Sections** are *presentations*: you choose a Template, set its settings, and give it a Component. The same Component can be used on many pages, each with its own settings, so it looks or behaves differently in each.\n- **Tabs** and **Accordion** hold their own items. Each item is a label and the presentations inside it, so a whole FAQ is one Component you can reuse on every page that needs it.\n- Two Templates can present the same Contract in different ways. Make a second Template over a Contract when the same words need a different look, rather than copying the Contract.\n\n## A header and footer for the whole site\n\nThe kit has a **Site chrome** Component with a **Header** and a **Footer**. The header holds the logo, the site name, a few links and one button; the footer holds the logo, a line of text, links and a copyright line. Pick the logo from Assets.\n\n1. Open the **Site chrome** Component in **Authoring** and change the header and footer. The header's Template settings say whether it stays on screen as the page scrolls, how large the logo is and its appearance; the footer's say its appearance.\n2. **Publish the Site chrome Component itself.** It is not part of any page, so publishing a page does not publish it, and the installer never publishes anything.\n3. Your site fetches it by its id, so every page gets the same header and footer, and a change to it is live everywhere after you publish.\n\nIf it is not published, the pages are drawn without a header and footer and nothing breaks.\n\n## Groups: a heading over what belongs together\n\nA **Group** is a section with an optional eyebrow (a small label) and heading, and any number of presentations inside it: a heading over three cards, a heading over a list of questions. Its Template's settings give the whole group its width, background, appearance and anchor, and **Spacing** (compact, standard, spacious) and **Align** (the heading at the start or centred). Set an appearance on the Group and everything inside takes it; a presentation inside can choose its own.\n\nIf you installed an earlier version of the kit, add **Group** to your experience Contract's **Sections** allowed Templates, as you would for any Template of your own.\n\n## Icons on features\n\nA Feature's **Icon** can be the name of one of the kit's line icons (`billiards`, `target`, `beer`, `bolt`, `puzzle`, `palette`, `star`, `check`, `heart`, `clock`, `pin`, `phone`, `mail`, `shield`, `users`, `trophy`), drawn in your accent colour, or any other text such as an emoji, which is drawn as written.\n\n## After you install\n\nEverything is yours. Edit a Contract, rename a category, restyle a theme, or delete what you do not need. Nothing is linked back to the kit, and a newer version of the kit never changes what you have. Installing again adds only what is missing.\n\nA new **major** version of the kit is not mixed into an earlier one, because its Templates would sit beside Contracts of the old shape. If your environment holds an earlier version, the install tells you so and changes nothing; your copy is left exactly as it is. To use the new version, install it into a new environment or organization.\n\nTo use your own Template in an experience's **Sections**, open the experience's Contract and add your Template to the Sections field's allowed Templates. The kit lists the Templates it accepts, so Hero and the experience itself can never be placed as a section.\n\n## Themes and appearances\n\nAn experience has a **theme**, which sets its colours, type and spacing, chosen in the experience Template's settings; leave it empty for the default. A section can have an **appearance** that adjusts the theme for that section and everything nested inside it; leave it on **Inherit** to take the parent's. Themes and appearances are categories, so you edit them under **Categories**.\n\n## Pictures and video\n\nMedia fields use the Assets app, so Assets has to be connected to Content before the kit can be installed. The Starter kits page offers the one-step **Connect Assets** card when it is not.\n"
     },
     {
         "slug": "tasks",

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,sqaAAsqa;KAC/qa;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,870BAA870B;KACv80B;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,mBAAmB;QAC3B,OAAO,EAAE,wCAAwC;QACjD,MAAM,EAAE,miRAAmiR;KAC5iR;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,oxRAAoxR;KAC7xR;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,ousBAAousB;KAC7usB;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,aAAa;QACrB,OAAO,EAAE,cAAc;QACvB,MAAM,EAAE,2qHAA2qH;KACprH;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,sqaAAsqa;KAC/qa;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,870BAA870B;KACv80B;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,mBAAmB;QAC3B,OAAO,EAAE,wCAAwC;QACjD,MAAM,EAAE,m0TAAm0T;KAC50T;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,oxRAAoxR;KAC7xR;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,ousBAAousB;KAC7usB;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,aAAa;QACrB,OAAO,EAAE,cAAc;QACvB,MAAM,EAAE,0mLAA0mL;KACnnL;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.268",
+  "version": "1.1.269",
   "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/",