@eventcatalog/core 4.1.2 → 4.1.4

package/dist/docs/development/01-getting-started/configuration-overview.md

@@ -11,84 +11,10 @@ import AddedIn from '@site/src/components/MDX/AddedIn';
 
 Most new EventCatalog projects are ready to run as soon as they are created. You only need to change configuration when you want to adjust how the catalog behaves, where it builds, or which features are enabled.
 
-Configuration lives in `eventcatalog.config.js` at the root of your project.
-
-Use this file for catalog-level settings, such as the catalog title, organization name, build output, deployment path, and integrations.
-
-## Start with the generated config
-
-When you create a new EventCatalog project, the starter creates an `eventcatalog.config.js` file for you. For many catalogs, you can leave this file alone while you create your first domains, services, and messages.
-
-Your config may look something like this:
-
-```js title="eventcatalog.config.js"
-module.exports = {
-  cId: '107fdebb-7c68-42cc-975d-413b1d30d758',
-  title: 'EventCatalog',
-  organizationName: 'Your Company',
-};
-```
-
-- `cId` is generated for your catalog. Keep the generated value.
-- `title` is the name shown in your catalog.
-- `organizationName` identifies the team or company that owns the catalog.
-
-## Common changes
-
-You do not need to learn every configuration option up front. These are the settings most teams change first:
-
-The examples below show only the option being changed. Keep the other values that already exist in your config.
-
-### Change the catalog name
-
-```js title="eventcatalog.config.js"
-module.exports = {
-  title: 'Acme Architecture Catalog',
-  organizationName: 'Acme',
-};
-```
-
-### Change the build output
-
-By default, EventCatalog builds a static website that can be hosted almost anywhere.
-
-Some features require EventCatalog to run as a server. You can switch the build output with the `output` option.
-
-```js title="eventcatalog.config.js"
-module.exports = {
-  output: 'server',
-};
-```
-
-Learn more about build output in the [configuration API](/docs/api/config#output).
-
-### Configure a deployment base path
-
-If your catalog is hosted under a sub-path, configure `base`.
-
-```js title="eventcatalog.config.js"
-module.exports = {
-  base: '/architecture/',
-};
-```
-
-For a catalog hosted at the root of a domain, keep the default `/`.
-
-## Full configuration reference
-
-This page only covers the basics. When you need the complete list of options, use the [eventcatalog.config.js API reference](/docs/api/config).
-
-Configuration guides for specific features live near the feature they configure. For example:
-
-- [Adding Analytics](/docs/development/guides/adding-analytics)
-- [RSS feeds](/docs/api/config#rss)
-- [Authentication](/docs/development/authentication/introduction)
-- [Deployment](/docs/development/deployment/build-and-deploy)
+Configuration lives in `eventcatalog.config.js` at the root of your project. You can read the [full reference documentation](/docs/api/config) to learn what can be changed.
 
 ## Configuring environment variables {#configuring-environment-variables}
 
-<AddedIn version="2.35.4" />
-
 Some features need values that should not live directly in `eventcatalog.config.js`, such as license keys or provider credentials.
 
 Put those values in a `.env` file in the root of your catalog. EventCatalog loads `.env` when it runs locally and when it builds.
@@ -104,21 +30,3 @@ Do not commit real secrets to source control.
 EventCatalog has a linter that can be used to validate your EventCatalog documentation.
 
 You can read more about the EventCatalog Linter in the [EventCatalog Linter documentation](/docs/development/developer-tools/eventcatalog-linter).
-
-### Advanced: disable channel migration
-
-On startup, EventCatalog automatically migrates legacy `channels` definitions on messages to the service-level channels shape.
-
-Most new catalogs do not need to change this behavior. If you are working with an older catalog and want to leave legacy channel definitions untouched, set `EVENTCATALOG_DISABLE_CHANNEL_MIGRATION`.
-
-**Accepted values:** `true`, `1`, or `yes` (case-insensitive). Any other value, or leaving the variable unset, keeps the default behavior: the migration runs as normal.
-
-```bash
-EVENTCATALOG_DISABLE_CHANNEL_MIGRATION=true npx @eventcatalog/core dev
-```
-
-You can also set it in your `.env` file:
-
-```bash title=".env"
-EVENTCATALOG_DISABLE_CHANNEL_MIGRATION=true
-```

package/dist/docs/development/01-getting-started/develop-and-build.md

@@ -66,6 +66,7 @@ Success! You are now ready to start building with EventCatalog! 🥳
 
 Here are a few things that we recommend exploring next. You can read them in any order. You can even leave our documentation for a bit and go play in your new EventCatalog project codebase, coming back here whenever you run into trouble or have a question.
 
-- [Create your first domain](/docs/development/guides/domains/creating-domains/adding-domains)
-- [Create your first service](/docs/development/guides/services/adding-services)
-- [Create your first message](/docs/messages)
+- [Create your first domain](/docs/development/guides/domains/create-domain)
+- [Create your first system](/docs/development/guides/systems/create-system)
+- [Create your first service](/docs/development/guides/resources/services/create-service)
+- [Create your first message](/docs/development/guides/resources/messages/what-are-messages)

package/dist/docs/development/01-getting-started/installation.md

@@ -106,6 +106,6 @@ To use the editor, you need Git installed and editor access through [EventCatalo
 
 - [Understand the project structure](/docs/development/getting-started/project-structure)
 - [Develop and build your catalog](/docs/development/getting-started/develop-and-build)
-- [Create your first domain](/docs/development/guides/domains/creating-domains/adding-domains)
-- [Create your first service](/docs/development/guides/services/adding-services)
-- [Document your first message](/docs/development/guides/messages/overview)
+- [Create your first domain](/docs/development/guides/domains/create-domain)
+- [Create your first service](/docs/development/guides/resources/services/create-service)
+- [Document your first message](/docs/development/guides/resources/messages/what-are-messages)

package/dist/docs/development/01-getting-started/project-structure.md

@@ -13,22 +13,25 @@ An EventCatalog project is a folder of Markdown files that describe and model yo
 
 You can edit these files directly, or use the optional [EventCatalog Editor](/docs/editor/overview) to create, preview, review, and commit catalog content through a visual workflow.
 
-Each resource in your catalog, such as a domain, service, event, command, query, team, or diagram, is represented by a file or folder in your project. EventCatalog reads those files and turns them into a catalog.
+Each resource type in your catalog (e.g domain, system, message) is represented by a file or folder in your project. EventCatalog reads those files and turns them into a catalog.
 
-You can also bring your own documentation into EventCatalog, such as architecture decision records, guides, onboarding material, or runbooks. Learn more about [bringing your own documentation](/docs/development/bring-your-own-documentation/introduction).
+You can also bring your own documentation into EventCatalog, such as guides, onboarding material, or runbooks. Learn more about [bringing your own documentation](/docs/development/bring-your-own-documentation/introduction).
 
 All resource types are optional. You decide what you want to document, and you can add more resource types later as your catalog becomes more useful to your teams.
 
 ## Directories and files
 
-Every EventCatalog project has a few core files used to run and configure the catalog. The resource folders, such as `domains/`, `services/`, `channels/`, and `diagrams/`, are optional and depend on what you want to document.
+Every EventCatalog project has a few core files used to run and configure the catalog. 
 
-EventCatalog creates resources from folders that contain an `index.mdx` file. For example, `domains/Orders/index.mdx` creates an `Orders` domain, and `domains/Orders/services/OrderService/index.mdx` creates an `OrderService` service inside that domain.
+Architecture resources exist in folders such as `domains/`, `systems/`, `services/`, and `events/`. All resources in EventCatalog are optional, it's up to you how you want to model and document your architecture.
+
+EventCatalog creates resources from folders that contain an `index.mdx` file. For example, `domains/Orders/index.mdx` creates an `Orders` domain, `domains/Orders/systems/order-management-system/index.mdx` creates an `order-management-system` system inside that domain, and `domains/Orders/systems/order-management-system/services/OrderService/index.mdx` creates an `OrderService` service inside that system.
 
 - `eventcatalog.config.js` - Configures your catalog.
 - `package.json` - Defines scripts and dependencies.
 - `public/` - Stores static assets that should be served directly.
 - `domains/` - Documents business domains and bounded contexts.
+- `systems/` - Documents groups of resources that work together to provide a capability.
 - `services/` - Documents services, APIs, applications, external systems, jobs, and workers.
 - `events/`, `commands/`, `queries/` - Documents messages.
 - `channels/` - Documents topics, queues, streams, webhooks, or other communication paths.
@@ -46,62 +49,101 @@ A common EventCatalog project directory might look like this:
     {
       name: 'domains',
       type: 'folder',
-      defaultOpen: true,
+      defaultOpen: false,
       children: [
         {
           name: 'Orders',
           type: 'folder',
-          defaultOpen: true,
+          defaultOpen: false,
           children: [
             { name: 'index.mdx', highlight: true },
             {
-              name: 'services',
+              name: 'systems',
               type: 'folder',
-              defaultOpen: true,
+              defaultOpen: false,
               children: [
                 {
-                  name: 'OrderService',
+                  name: 'order-management-system',
                   type: 'folder',
-                  defaultOpen: true,
+                  defaultOpen: false,
                   children: [
-                    { name: 'index.mdx' },
-                    { name: 'openapi.yaml' },
-                    { name: 'asyncapi.yaml' },
+                    { name: 'index.mdx', highlight: true },
                     {
-                      name: 'events',
+                      name: 'services',
                       type: 'folder',
-                      defaultOpen: true,
+                      defaultOpen: false,
                       children: [
                         {
-                          name: 'OrderPlaced',
+                          name: 'OrderService',
                           type: 'folder',
-                          defaultOpen: true,
+                          defaultOpen: false,
                           children: [
                             { name: 'index.mdx' },
-                            { name: 'schema.avsc' },
+                            { name: 'openapi.yaml' },
+                            { name: 'asyncapi.yaml' },
+                            {
+                              name: 'events',
+                              type: 'folder',
+                              defaultOpen: false,
+                              children: [
+                                {
+                                  name: 'OrderPlaced',
+                                  type: 'folder',
+                                  defaultOpen: false,
+                                  children: [
+                                    { name: 'index.mdx' },
+                                    { name: 'schema.avsc' },
+                                  ],
+                                },
+                              ],
+                            },
+                            {
+                              name: 'commands',
+                              type: 'folder',
+                              defaultOpen: false,
+                              children: [
+                                {
+                                  name: 'CancelOrder',
+                                  type: 'folder',
+                                  children: [{ name: 'index.mdx' }],
+                                },
+                              ],
+                            },
+                            {
+                              name: 'queries',
+                              type: 'folder',
+                              defaultOpen: false,
+                              children: [
+                                {
+                                  name: 'GetOrder',
+                                  type: 'folder',
+                                  children: [{ name: 'index.mdx' }],
+                                },
+                              ],
+                            },
                           ],
                         },
                       ],
                     },
                     {
-                      name: 'commands',
+                      name: 'containers',
                       type: 'folder',
                       defaultOpen: false,
                       children: [
                         {
-                          name: 'CancelOrder',
+                          name: 'orders-db',
                           type: 'folder',
                           children: [{ name: 'index.mdx' }],
                         },
                       ],
                     },
                     {
-                      name: 'queries',
+                      name: 'flows',
                       type: 'folder',
                       defaultOpen: false,
                       children: [
                         {
-                          name: 'GetOrder',
+                          name: 'order-fulfilment',
                           type: 'folder',
                           children: [{ name: 'index.mdx' }],
                         },
@@ -115,30 +157,6 @@ A common EventCatalog project directory might look like this:
         },
       ],
     },
-    {
-      name: 'channels',
-      type: 'folder',
-      defaultOpen: false,
-      children: [
-        {
-          name: 'orders.events',
-          type: 'folder',
-          children: [{ name: 'index.mdx' }],
-        },
-      ],
-    },
-    {
-      name: 'diagrams',
-      type: 'folder',
-      defaultOpen: false,
-      children: [
-        {
-          name: 'system-context',
-          type: 'folder',
-          children: [{ name: 'index.mdx' }],
-        },
-      ],
-    },
     {
       name: 'teams',
       type: 'folder',
@@ -168,104 +186,19 @@ A common EventCatalog project directory might look like this:
 
 You do not need every folder on day one. Start with the resources you know about, then add more as your catalog grows.
 
-### `domains/`
-
-The `domains/` folder documents the business areas or bounded contexts in your architecture, such as `Orders`, `Payments`, or `Shipping`.
-
-Domains can contain their own documentation, services, messages, diagrams, and other resources. This is the most common way to structure larger catalogs because related architecture stays close together.
-
-Learn more in the [domains guide](/docs/development/guides/domains/introduction).
-
-### `services/`
-
-The `services/` folder documents services, APIs, applications, external systems, jobs, and workers.
-
-Services can live inside a domain, such as `domains/Orders/services/OrderService/`, or at the root of your catalog, such as `services/OrderService/`.
-
-Services often contain OpenAPI, AsyncAPI, or GraphQL specifications and the messages they own.
-
-Learn more in the [services guide](/docs/development/guides/services/introduction).
-
-### `events/`, `commands/`, and `queries/`
-
-The `events/`, `commands/`, and `queries/` folders document messages exchanged between services.
-
-These folders can live inside a service when that service owns the message, or elsewhere in your catalog if you prefer a flatter structure.
-
-Message folders can also contain schemas, examples, and version history.
-
-Learn more in the [messages guide](/docs/development/guides/messages/overview).
-
-### `channels/`
-
-The `channels/` folder documents where messages flow, such as Kafka topics, queues, streams, webhooks, or other integration points.
-
-Use channels when you want to explain the transport layer of your architecture, not just the messages themselves.
-
-Learn more in the [channels guide](/docs/development/guides/channels/introduction).
-
-### `diagrams/`
-
-The `diagrams/` folder documents architecture diagrams, flows, and visual explanations.
-
-Diagrams can live at the root of your catalog or inside another resource, such as a domain or service.
-
-Learn more in the [diagrams guide](/docs/development/guides/diagrams/introduction).
-
-### `teams/` and `users/`
-
-The `teams/` and `users/` folders document ownership metadata.
-
-Teams and users are usually represented as files directly inside their folder:
-
-```bash
-teams/
-└── mobile-team.mdx
-
-users/
-└── dboyne.mdx
-```
-
-Use these when you want ownership to be visible across domains, services, messages, schemas, and other resources.
-
-Learn more in the [teams guide](/docs/development/guides/owners/teams/introduction) and [users guide](/docs/development/guides/owners/users/introduction).
-
-### `public/`
-
-The `public/` folder stores static assets that should be served directly, such as icons, images, and files.
-
-For example, if a service icon lives at `public/icons/orders.svg`, you can reference it from your resource metadata using `/icons/orders.svg`.
-
-### `eventcatalog.config.js`
-
-The `eventcatalog.config.js` file configures your catalog, including title, output mode, integrations, and feature settings.
-
-See the [configuration API](/docs/api/config).
-
-### `package.json`
-
-The `package.json` file defines the scripts and dependencies used to run, build, and preview your catalog.
-
-Most EventCatalog projects include scripts such as `npm run dev` and `npm run build`.
-
 ## What should I create first?
 
-If you are starting from an empty catalog, create resources in this order:
+If you want to create your first few resources you can follow our [Learning EventCatalog Guide](/learn).
 
-1. Add a domain for a business area, such as `Orders`.
-2. Add one service inside that domain.
-3. Add one event, command, or query owned by that service.
-4. Add a team that owns the service.
-5. Add channels or diagrams once you want to explain how things connect.
+## Next Steps
 
-That gives you a useful catalog quickly without needing to model everything up front.
+Now you know some of the ways EventCatalog work, you can start to document some of your architecture resources.
+Here are some links below to help depending on what you want to document.
 
-## Learn more
+:::tip Using AI to help
+AI is great at helping you document and get going with EventCatalog. You can install our [EventCatalog Skills](https://github.com/event-catalog/eventcatalog-skills) to teach your LLM about EventCatalog, and then ask your LLM to help you get going.
+:::
 
-- [Domains](/docs/development/guides/domains/introduction)
-- [Services](/docs/development/guides/services/introduction)
-- [Messages](/docs/development/guides/messages/overview)
-- [Channels](/docs/development/guides/channels/introduction)
-- [Diagrams](/docs/development/guides/diagrams/introduction)
-- [Teams](/docs/development/guides/owners/teams/introduction)
-- [Users](/docs/development/guides/owners/users/introduction)
+- [Start documenting a business domain](/docs/development/guides/domains/introduction)
+- [Start documenting a system](/docs/development/guides/systems/create-system)
+- [Start documenting producers and consumers of a service](/docs/development/guides/resources/services/introduction)

package/dist/docs/development/ask-your-architecture/01-intro.md

@@ -1,5 +1,5 @@
 ---
-sidebar_position: 2
+sidebar_position: 1
 keywords:
 - components
 sidebar_label: Using AI with EventCatalog
@@ -9,81 +9,13 @@ description: Architecture documentation for humans and AI
 
 import AddedIn from '@site/src/components/MDX/AddedIn';
 
-EventCatalog helps you document your architecture for both teams and your AI tools. Your team gets a visual catalog to explore your system. Your AI tools get structured access to query and reason about your architecture.
-
-You can disable the AI chat feature at any time by setting `chat.enabled: false` in your `eventcatalog.config.js`. This hides the chat UI and stops chat requests even when all other prerequisites (plan, server mode, config file) are met.
-
-## AI integrations
+EventCatalog creates an internal graph of your architecture. Perfect for AI and LLMs.
 
 EventCatalog supports five ways to use AI with your catalog:
 
-- [EventCatalog Assistant](/docs/development/ask-your-architecture/eventcatalog-assistant/what-is-eventcatalog-assistant)
-  - Bring your own model to EventCatalog itself, and ask questions about your documentation directly in the browser.
-- [EventCatalog MCP Server](/docs/development/ask-your-architecture/mcp-server/introduction)
-  - Connect your MCP clients (e.g Cursor, Windsurf, Claude Desktop) to EventCatalog.
-- [Slack Integration](/docs/development/ask-your-architecture/slack-integration/introduction)
-  - Query your architecture directly from Slack using the EventCatalog Slack Bot.
-- [AI Skills](/docs/development/ask-your-architecture/skills/introduction)
-  - Pre-built skills that teach AI coding agents how to generate correct EventCatalog documentation.
-- [Bundled docs for coding agents](#bundled-docs-for-coding-agents)
-  - Version-matched docs bundled inside `@eventcatalog/core` so agents always reference accurate APIs, not stale training data.
-
-## Bundled docs for coding agents
-
-<AddedIn version="3.35.1" />
-
-AI coding agents (Claude Code, Cursor, Copilot, and others) are trained on a snapshot of the web. EventCatalog's API, frontmatter conventions, and folder structure evolve with each release, so an agent relying on training data alone may generate outdated or incorrect files.
-
-Starting in `3.35.1`, `@eventcatalog/core` bundles the full documentation inside the package itself. After installing EventCatalog, the docs are available at:
-
-```
-node_modules/@eventcatalog/core/dist/docs/
-```
-
-No extra install or network request is needed. The bundled docs mirror the structure of the EventCatalog website (api, cli, development, plugins, and more) and are always version-matched to the package you have installed.
-
-### Use with new projects
-
-Projects scaffolded with `npx create-eventcatalog@latest` automatically receive two files in the project root:
-
-- `AGENTS.md` — read by most coding agents before they act. It tells the agent to find and read the relevant doc in `node_modules/@eventcatalog/core/dist/docs/` before doing any EventCatalog work.
-- `CLAUDE.md` — a single `@AGENTS.md` line that re-exports the rules for Claude Code without duplicating content.
-
-No manual setup is required for new projects.
-
-### Use with existing projects
-
-Add the two files to the root of your EventCatalog project:
-
-**`AGENTS.md`**
-
-```markdown
-<!-- BEGIN:eventcatalog-agent-rules -->
-# EventCatalog: ALWAYS read docs before coding
-
-Before any EventCatalog work, find and read the relevant doc in `node_modules/@eventcatalog/core/dist/docs/`. Your training data may be outdated. The bundled docs are the source of truth.
-
-<!-- END:eventcatalog-agent-rules -->
-```
-
-**`CLAUDE.md`**
-
-```
-@AGENTS.md
-```
-
-The `BEGIN` / `END` markers in `AGENTS.md` let you add your own project-specific instructions outside the managed block. EventCatalog will only update content inside those markers in future releases.
-
-### Understand the docs layout
-
-The bundled docs follow the same structure as the EventCatalog website:
-
-```
-node_modules/@eventcatalog/core/dist/docs/
-├── api/          # Frontmatter reference for all resource types
-├── cli/          # CLI commands
-├── development/  # Getting started, guides, customization
-└── plugins/      # Generator and plugin documentation
-```
-
-Point your agent at a specific subdirectory when you want it to focus. For example, to document a new service, read `dist/docs/api/04-service-api.md` and `dist/docs/development/guides/services/`.
+- [llms.txt](/docs/development/ask-your-architecture/llms.txt) - Give AI tools a machine-readable index of your catalog.
+- [schemas.txt](/docs/development/ask-your-architecture/schemas.txt) - Give AI tools access to your schemas and specifications.
+- [EventCatalog Assistant](/docs/development/ask-your-architecture/eventcatalog-assistant/what-is-eventcatalog-assistant) - AI Chat in your Catalog.
+- [EventCatalog MCP Server](/docs/development/ask-your-architecture/mcp-server/introduction) - Connect EventCatalog to Agents through MCP
+- [EventCatalog Agent](/docs/development/ask-your-architecture/agents/overview) - CI/CD Agent for breaking changes and doc updates
+- [AI Skills](/docs/development/ask-your-architecture/skills/introduction) - Install our Skills to help you manage your catalog

package/dist/docs/development/ask-your-architecture/02-eventcatalog-assistant/01-what-is-eventcatalog-assistant.md

@@ -8,15 +8,16 @@ description: Learn how EventCatalog Assistant helps users explore documentation
 ---
 
 import AddedIn from '@site/src/components/MDX/AddedIn';
-import EventCatalogPro from '@site/src/components/MDX/EventCatalogPro';
 
 import PlanBanner from '@site/src/components/MDX/PlanBanner';
 
 <PlanBanner plan="Scale" />
 
-EventCatalog Assistant allows users to ask questions about your documentation using natural language. It is embedded directly into your documentation site, enabling users to quickly find answers, understand your system, and succeed without manually searching through pages.
+EventCatalog Assistant brings AI chat to your catalog.
 
-**You can bring your own model to EventCatalog and your data is owned by you and never shared.**
+It is embedded directly into your documentation site, enabling users to quickly find answers, understand your system, and succeed without manually searching through pages.
+
+**You bring your own model to EventCatalog and your data is owned by you and never shared.**
 
 The assistant integrates with your preferred AI models using the [AI SDK](https://ai-sdk.dev/), giving you full control over which models power the experience.
 

package/dist/docs/development/ask-your-architecture/02-eventcatalog-assistant/02-configuration.md

@@ -7,6 +7,7 @@ title: Configuration
 description: Configure EventCatalog Assistant
 ---
 
+import AddedIn from '@site/src/components/MDX/AddedIn';
 import PlanBanner from '@site/src/components/MDX/PlanBanner';
 
 <PlanBanner plan="Scale" />
@@ -69,4 +70,4 @@ export const configuration = {
 }
 ```
 
-Once you have enabled the feature and configured your model, restart EventCatalog and you can start asking questions about your architecture.
+Once you have enabled the feature and configured your model, restart EventCatalog and you can start asking questions about your architecture.

package/dist/docs/development/ask-your-architecture/02-eventcatalog-assistant/03-bring-your-own-tools.md

@@ -6,7 +6,7 @@ keywords:
 - AI Tools
 - Runtime Data
 - Metrics
-sidebar_label: Custom Tools
+sidebar_label: Configure your own tools
 title: Custom Tools
 description: Extend EventCatalog Assistant with custom tools to bring real-time data, metrics, and integrations into your architecture conversations
 ---
@@ -14,8 +14,6 @@ description: Extend EventCatalog Assistant with custom tools to bring real-time
 import PlanBanner from '@site/src/components/MDX/PlanBanner';
 import AddedIn from '@site/src/components/MDX/AddedIn';
 
-<AddedIn version="3.2.0" />
-
 <PlanBanner plan="Scale" />
 
 EventCatalog Assistant comes with built-in tools that allow the AI to search and understand your architecture documentation. But what if you could go beyond static documentation and bring **real-time data** directly into your conversations?

package/dist/docs/development/ask-your-architecture/02-eventcatalog-assistant/_category_.json

@@ -1,6 +1,6 @@
 {
   "label": "EventCatalog Assistant",
-  "position": 2,
+  "position": 4,
   "collapsible": true,
   "collapsed": true,
   "link": {
@@ -8,4 +8,4 @@
     "slug": "/development/guides/eventcatalog-assistant",
     "description": "EventCatalog Assistant"
   }
-}
+}

package/dist/docs/development/{developer-tools/llms.txt.md → ask-your-architecture/02-llms.txt.md}

@@ -1,5 +1,5 @@
 ---
-sidebar_position: 3
+sidebar_position: 2
 keywords:
 - llms.txt
 - AI
@@ -63,4 +63,3 @@ Once you deploy your EventCatalog you can use your tools to ask questions about
 
 
 
-

package/dist/docs/development/ask-your-architecture/03-mcp-server/_category_.json

@@ -1,6 +1,6 @@
 {
   "label": "EventCatalog MCP Server",
-  "position": 2,
+  "position": 5,
   "collapsible": true,
   "collapsed": true,
   "link": {
@@ -9,4 +9,4 @@
     "title": "MCP Server",
     "description": "This section contains tutorials for the EventCatalog MCP Server."
   }
-}
+}

package/dist/docs/development/ask-your-architecture/03-mcp-server/getting-started.md

@@ -15,7 +15,7 @@ import PlanBanner from '@site/src/components/MDX/PlanBanner';
 ### Prerequisites
 
 1. **SSR mode** - EventCatalog must run in [server mode](/docs/development/deployment/build-ssr-mode#building-your-eventcatalog-ssr) (not static)
-2. **Scale license** - You can get a 14 day free trial at [eventcatalog.cloud](https://eventcatalog.cloud)
+2. **Scale license** - You can get a 30-day free trial at [eventcatalog.cloud](https://eventcatalog.cloud)
 
 ### Quick start
 
@@ -240,7 +240,7 @@ For catalogs without SSR mode, use the standalone `@eventcatalog/mcp-server` pac
 For local development and testing, you can use the MCP Server on stdio. This is useful for single-client, low-latency tools.
 
 **Prerequisites:**
-- EventCatalog configured with the [`LLMS.txt` feature](/docs/development/developer-tools/llms.txt)
+- EventCatalog configured with the [`LLMS.txt` feature](/docs/development/ask-your-architecture/llms.txt)
 - EventCatalog Scale license
 - MCP client installed