@eventcatalog/core 4.10.13 → 4.10.14

package/dist/docs/development/developer-tools/eventcatalog-linter/reference/_category_.json

@@ -0,0 +1,12 @@
+{
+  "label": "Reference",
+  "position": 4,
+  "collapsible": true,
+  "collapsed": true,
+  "link": {
+    "type": "generated-index",
+    "slug": "development/developer-tools/eventcatalog-linter/reference",
+    "title": "Linter reference",
+    "description": "Lookup information for the CLI, the configuration file, every rule, version formats, and the files the linter scans."
+  }
+}

package/dist/docs/development/guides/97-architecture-graph.md

@@ -0,0 +1,78 @@
+---
+sidebar_position: 97
+keywords:
+- EventCatalog architecture graph
+- Force-directed graph
+- Architecture visualizer
+sidebar_label: Architecture Graph
+title: Architecture graph
+description: Explore your whole catalog as one force-directed graph.
+---
+
+import AddedIn from '@site/src/components/MDX/AddedIn';
+
+<AddedIn version="4.5.0" />
+
+The architecture graph is a force-directed view of every resource in your catalog and the relationships between them. Unlike the [system context map](/docs/development/guides/systems/system-context-maps), which needs systems to exist, the architecture graph works for any catalog.
+
+Use this view when you want to answer questions like:
+
+- How does everything in the catalog connect, at a glance?
+- What does a domain, system, or team's footprint look like across the architecture?
+- How do messages flow between services and agents?
+
+![Architecture graph with the Domains lens, showing every domain in the catalog and the resources grouped inside it](./img/architecture-graph-domain-view.png)
+
+## Turn on the graph
+
+The architecture graph is opt-in. Enable it with `visualiser.architectureGraph.enabled` in your `eventcatalog.config.js` file.
+
+```js title="eventcatalog.config.js"
+module.exports = {
+  visualiser: {
+    architectureGraph: {
+      enabled: true,
+    },
+  },
+};
+```
+
+Once enabled, an **Architecture Graph** link appears in the **Top level diagrams** navigation group, and the graph is available at:
+
+```txt
+/visualiser/graph
+```
+
+:::info Opt-in while in beta
+Building a graph of the whole catalog is unproven on very large catalogs, so it stays off until you turn it on.
+:::
+
+## Change how you look at it
+
+The **Lens** picker switches the graph between focused views: domains, systems, services, teams, and message flow, alongside the default view of every resource and relationship.
+
+Each lens promotes a different resource to the centre of the picture. The domain lens above clusters everything by domain, while the service lens puts each service at the middle of the messages it sends and receives.
+
+![Architecture graph with the Services lens, showing each service surrounded by the messages it publishes and subscribes to](./img/architecture-graph-service-view.png)
+
+The **Detail** slider next to the lens controls how far out from those hubs the graph reaches. Keep it low for a readable overview, or raise it to `All` to pull in everything the lens can show.
+
+## Focus on one part of the architecture
+
+Search for a resource to focus its neighbourhood, or click any node to do the same. Double-click a node to open its documentation.
+
+![Architecture graph focused on the Review API service, showing its commands, events, queries, and data stores](./img/architecture-graph-focus.png)
+
+Focusing hides the rest of the catalog so you can read one resource's immediate connections. The **Depth** slider on the focus chip widens the neighbourhood a step at a time, and the **You are here** breadcrumb shows where the focused resource sits in the hierarchy. Clear the focus with the `×` on the chip.
+
+## Share a view
+
+Your lens, focus, and filters are written to the URL as you interact with the graph, so you can copy the link and send teammates directly to the same view.
+
+## Embed the graph in your documentation
+
+Use the [`<ArchitectureGraph/>` component](/docs/development/components/components/architecture-graph) to embed the graph into any resource or custom documentation page, focused on that page's resource:
+
+```jsx /domains/Orders/index.mdx
+<ArchitectureGraph />
+```

package/dist/docs/development/guides/domains/02-create-domain.md

@@ -40,7 +40,7 @@ To add a new domain create a new folder within the `/domains` folder with an `in
 - `/domains/{Domain Name}/index.mdx` 
   - (example `/domains/Orders/index.mdx`)
 
-The `index.mdx` contents are split into two sections, [**frontmatter**](/docs/development/guides/domains/reference) and the [**markdown content**](#adding-content).
+The `index.mdx` contents are split into two sections, [**frontmatter**](/docs/development/guides/domains/reference) and the [**markdown content**](#adding-content-to-your-domain).
 
 _Here is an example of what a domain markdown file may look like._
 

package/dist/docs/development/guides/domains/03-ownership-and-language/02-adding-ubiquitous-language.md

@@ -23,6 +23,8 @@ The contents of the file should be a list of terms used in your domain.
 
 Each term should have a name, summary, description and icon. The icon is optional and can be used to visually represent the term. You can find a list of icons [here](https://lucide.dev/). Use the PascalCase React component name for Lucide icons, for example `file-text` should be configured as `FileText`.
 
+You can optionally set [`editUrl`](#editUrl) on the dictionary file or on an individual term.
+
 ```md title="/domains/Orders/ubiquitous-language.md"
 ---
 dictionary:
@@ -58,6 +60,33 @@ dictionary:
 
 ```
 
+### `editUrl` {#editUrl}
+
+<AddedIn version="4.8.2" />
+
+Override the default edit URL for a ubiquitous language term page. This is used to navigate the user to the edit page, for example GitHub or GitLab.
+
+Set `editUrl` on the dictionary file, on an individual term, or both. This is useful when dictionary content is generated from an external source (for example a custom generator plugin) so **Edit this page** on `/docs/domains/{id}/language/{termId}` points at the real source file, not the generated MDX.
+
+```md title="/domains/Orders/ubiquitous-language.md"
+---
+editUrl: https://github.com/your-org/glossary/edit/main/domains/Orders/ubiquitous-language.md
+dictionary:
+  - id: Purchase Order
+    name: Purchase Order
+    summary: "A mystical document issued by a buyer to a seller."
+    editUrl: https://github.com/your-org/glossary/edit/main/terms/purchase-order.md
+---
+```
+
+EventCatalog resolves the link in this order:
+
+1. Per-term `editUrl` on a dictionary item
+2. File-level `editUrl` on `ubiquitous-language.mdx`
+3. Fallback to the site-wide [`editUrl`](/docs/api/config#editUrl) in `eventcatalog.config.js` plus the dictionary file path
+
+Per-term `editUrl` takes precedence over the file-level value.
+
 ### Viewing the ubiquitous language in EventCatalog
 
 When you add a ubiquitous language dictionary to your domain, it will automatically appear in the sidebar of the domain.

package/dist/docs/development/guides/domains/09-reference.md

@@ -26,11 +26,19 @@ Subdomains can be created inside a domain:
 /domains/{Domain Name}/subdomains/{Subdomain Name}/index.mdx
 ```
 
+Ubiquitous language for a domain is documented in a sidecar file:
+
+```txt
+/domains/{Domain Name}/ubiquitous-language.mdx
+```
+
 ## Routes
 
 | Route | Description |
 |-------|-------------|
 | `/docs/domains/{domain-id}/{version}` | Domain documentation page. |
+| `/docs/domains/{domain-id}/language` | Ubiquitous language dictionary. |
+| `/docs/domains/{domain-id}/language/{term-id}` | Ubiquitous language term page. |
 | `/visualiser/domains/{domain-id}/{version}` | Domain resource diagram. |
 | `/visualiser/domains/{domain-id}/{version}/systems-context` | System context map for systems inside a domain. |
 | `/visualiser/domains/{domain-id}/{version}/entity-map` | Entity map for entities inside a domain. |
@@ -488,6 +496,8 @@ editUrl: https://github.com/event-catalog/eventcatalog/edit/main/domains/Orders/
 ---
 ```
 
+Ubiquitous language dictionaries also support `editUrl` on the file and on each term. See [ubiquitous language `editUrl`](/docs/development/guides/domains/ownership-and-language/adding-ubiquitous-language#editUrl).
+
 ### `attachments` {#attachments}
 
 <AddedIn version="2.57.2" />

package/dist/docs/development/guides/resources/messages/04-message-channels/02-adding-channels.md

@@ -184,7 +184,7 @@ id: inventory.{env}.events
 # rest of channel markdown...
 
 # You can define one or many protocols
-# list of protocols: https://eventcatalog.dev/docs/development/guides/resources/messages/message-channels/introduction#protocols
+# list of protocols: https://eventcatalog.dev/docs/development/guides/resources/messages/message-channels/introduction#supported-channel-protocols
 protocols:
   - http
   - kafka
@@ -194,7 +194,7 @@ protocols:
 
 These protocols will be displayed on your channel page and the visualizer.
 
-You can get [the list of protocols here](/docs/development/guides/resources/messages/message-channels/introduction#protocols).
+You can get [the list of protocols here](/docs/development/guides/resources/messages/message-channels/introduction#supported-channel-protocols).
 
 ### Setting a delivery guarantee
 

package/dist/docs/development/guides/resources/messages/04-message-channels/04-adding-messages-to-services.md

@@ -184,6 +184,14 @@ routes:
 ---
 ```
 
+Finally, we create the `payment.queue`.
+
+```md title="/channels/payment.queue/index.mdx (example)"
+---
+id: payment.queue
+---
+```
+
 EventCatalog will understand the channel routes and relationships and create a visual representation of the channels and their relationships.
 
 ![Example](../../../img/channels/channel-chains.png)

package/dist/docs/development/guides/resources/schemas/03-add-specifications-to-services/01-add-openapi-specifications.md

@@ -17,8 +17,8 @@ Services in EventCatalog allow you to attach one or more OpenAPI specifications
 
 You have two options for adding OpenAPI specifications to your service:
 
-- [Adding OpenAPI files to EventCatalog](#adding-openapi-specifications-to-eventcatalog)
-- [Reference the OpenAPI file from a remote URL](#reference-the-openapi-file-from-a-remote-url)
+- [Adding OpenAPI files to EventCatalog](#adding-openapi-files-to-eventcatalog)
+- [Reference the OpenAPI file from a remote URL](#remote-openapi-files)
 
 :::tip Why not automate your EventCatalog from your OpenAPI files?
   Did you know you can automate your documentation, visualizations and owners using your OpenAPI Files?

package/dist/docs/development/guides/resources/schemas/03-add-specifications-to-services/02-add-asyncapi-specifications.md

@@ -17,8 +17,8 @@ Services in EventCatalog allow you to attach one or more AsyncAPI specifications
 
 You have two options for adding AsyncAPI specifications to your service:
 
-- [Adding AsyncAPI files to EventCatalog](#adding-asyncapi-specifications-to-eventcatalog)
-- [Reference the AsyncAPI file from a remote URL](#reference-the-asyncapi-file-from-a-remote-url)
+- [Adding AsyncAPI files to EventCatalog](#adding-asyncapi-files-to-eventcatalog)
+- [Reference the AsyncAPI file from a remote URL](#remote-asyncapi-files)
 
 :::tip Why not automate your EventCatalog from your AsyncAPI files?
   Did you know you can automate your documentation, visualizations and owners using your AsyncAPI Files?
@@ -66,7 +66,7 @@ Then you need to reference the file in the service frontmatter.
 ---
 ```  
 
-### Remove AsyncAPI file
+### Remote AsyncAPI files
 
 This can be useful if you want to keep your AsyncAPI files in a remote repository and render them in EventCatalog.
 

package/dist/docs/development/guides/systems/05-system-context-maps.md

@@ -65,3 +65,5 @@ The goal of systems is to let users move through your architecture at the right
 - Drill into the resources inside that system to inspect APIs, messages, services, data stores, and flows.
 
 This gives teams a path from architecture overview to implementation detail without forcing every user to start at the lowest level.
+
+Want every resource in one graph instead, including catalogs without systems? See the [architecture graph](/docs/development/guides/architecture-graph).

package/dist/docs/development/license-keys/license-validation.md

@@ -9,7 +9,7 @@ title: How license validation works
 description: How EventCatalog validates your license keys online and offline.
 ---
 
-Once you have a license key from [EventCatalog Cloud](https://eventcatalog.cloud) (see [Overview](/docs/development/license-keys/overview) if you don't yet), EventCatalog validates it every time you build or serve your catalog. There are two modes: online and offline.
+EventCatalog validates commercial features using online license keys or offline license files. Scale and integration keys use online validation by default. Enterprise features, including Federation, require an offline license file.
 
 ## Online validation (default)
 
@@ -21,13 +21,17 @@ This is the recommended mode — it requires no extra setup and your keys stay i
 
 If you're behind a firewall or otherwise can't reach the EventCatalog API at build time, you can validate your keys offline.
 
+EventCatalog Federation always uses this offline validation flow and requires an Enterprise license.
+
 To set up offline validation:
 
-1. Email us at `hello@eventcatalog.dev` to request an offline license file (`license.jwt`).
+1. Email [hello@eventcatalog.dev](mailto:hello@eventcatalog.dev?subject=EventCatalog%20Federation%20Trial) to request an offline license file (`license.jwt`). Tell us if you want to try Federation and we will send you an Enterprise trial key.
 2. Place the `license.jwt` file in the root of your catalog directory.
 3. EventCatalog will validate against the local file instead of calling our API.
 
-Offline license files expire one year from purchase. You'll need to request a new file each year.
+You can commit `license.jwt` with your catalog so it is available locally and in CI/CD. If your organization prefers not to commit it, write the file during the CI/CD job instead. Set `EC_LICENSE` to the file path only when it is stored outside the catalog root.
+
+Offline license files include an expiry date. Email `hello@eventcatalog.dev` when you need a trial, renewal, or replacement file.
 
 ## Managing your keys
 

package/dist/docs/development/license-keys/overview.md

@@ -15,14 +15,18 @@ If you are using the community edition, you don't need a license key and can ski
 
 ## Where license keys come from
 
-All license keys are managed in [EventCatalog Cloud](https://eventcatalog.cloud). You sign up for an account, activate the plan or integration you want to use, and your license keys appear on your dashboard.
+Scale and integration license keys are managed in [EventCatalog Cloud](https://eventcatalog.cloud). You sign up for an account, activate the plan or integration you want to use, and your license keys appear on your dashboard.
 
 You can then add those keys to your `.env` file (or set them as environment variables) and EventCatalog will unlock the corresponding features.
 
+Enterprise features, including [EventCatalog Federation](/federation), use an offline license file. Email [hello@eventcatalog.dev](mailto:hello@eventcatalog.dev?subject=EventCatalog%20Enterprise%20Trial) to request an offline Enterprise trial key.
+
 ## Free trials
 
-:::tip 30-day free trials
-Every plan and every integration comes with a **30-day free trial**. No payment is required to start one — just sign in to [EventCatalog Cloud](https://eventcatalog.cloud) and activate what you want to try.
+:::tip Free trials
+Scale and every integration come with a **30-day free trial**. No payment is required to start one. Sign in to [EventCatalog Cloud](https://eventcatalog.cloud) and activate what you want to try.
+
+Want to try Enterprise or Federation? Email us at `hello@eventcatalog.dev` and we will send you an offline trial key.
 
 Need longer to evaluate? Email us at `hello@eventcatalog.dev` and we'll happily extend your trial.
 :::

package/dist/docs/development/upgrading/upgrading.md

@@ -82,8 +82,8 @@ EventCatalog v2 has been rewritten from the ground up. The easiest way to migrat
 1. [Create a new Catalog](/docs/development/getting-started/installation)
 1. Delete the `domains`, `services`, `commands` and `events` folder.
 1. Copy your `eventcatalog.config.js` and `domains`, `services`, `events` folders into the new catalog.
-1. Add `ids` to all your resources ([read more](/docs/starting-a-new-project/getting-started#resources-now-require-ids))
-1. If your resource are in a nested structure [you need to flatten these out](/docs/starting-a-new-project/getting-started#resources-require-a-flat-structure).
+1. Add `ids` to all your resources ([read more](/docs/development/upgrading/v2#resources-now-require-ids))
+1. If your resource are in a nested structure [you need to flatten these out](/docs/development/upgrading/v2#resources-require-a-flat-structure).
 
 :::tip Having problems?
 If you are still having issues upgrading your catalog, [then please raise an issue on our GitHub repo.](https://github.com/event-catalog/eventcatalog/issues).
@@ -136,7 +136,7 @@ Components from v1 has not yet been implemented.
 
 ## Any other issues?
 
-If you have any issues or questions please [feel free to reach us on Discord](https://discord.com/invite/3rjaZMmrAm).
+If you have any issues or questions please [feel free to reach us on Discord](https://eventcatalog.dev/discord).
 
 </details>
 

package/dist/docs/development/upgrading/v2.md

@@ -28,8 +28,8 @@ EventCatalog v2 has been rewritten from the ground up. The easiest way to migrat
 1. [Create a new Catalog](/docs/development/getting-started/installation)
 1. Delete the `domains`, `services`, `commands` and `events` folder.
 1. Copy your `eventcatalog.config.js` and `domains`, `services`, `events` folders into the new catalog.
-1. Add `ids` to all your resources ([read more](/docs/starting-a-new-project/getting-started#resources-now-require-ids))
-1. If your resource are in a nested structure [you need to flatten these out](/docs/starting-a-new-project/getting-started#resources-require-a-flat-structure).
+1. Add `ids` to all your resources ([read more](/docs/development/upgrading/v2#resources-now-require-ids))
+1. If your resource are in a nested structure [you need to flatten these out](/docs/development/upgrading/v2#resources-require-a-flat-structure).
 
 :::tip Having problems?
 If you are still having issues upgrading your catalog, [then please raise an issue on our GitHub repo.](https://github.com/event-catalog/eventcatalog/issues).
@@ -65,4 +65,4 @@ The build output has changed from v1 from being `out` directory to `dist` direct
 
 ## Any other issues?
 
-If you have any issues or questions please [feel free to reach us on Discord](https://discord.com/invite/3rjaZMmrAm).
+If you have any issues or questions please [feel free to reach us on Discord](https://eventcatalog.dev/discord).

package/dist/docs/federation/00-overview.md

@@ -0,0 +1,158 @@
+---
+sidebar_position: 1
+sidebar_label: Overview
+title: EventCatalog Federation
+description: Combine independently owned EventCatalogs into one validated organization-wide catalog.
+---
+
+import EventCatalogEnterprise from '@site/src/components/MDX/EventCatalogEnterprise';
+
+<EventCatalogEnterprise />
+
+EventCatalog Federation is a solution for distributed documentation across your organization. Teams document and own their services, domains, messages, ADRs, specifications, schemas, diagrams, and everything else EventCatalog supports in their own catalogs, while Federation combines them into one organization-wide view.
+
+Each team keeps its documentation, ownership, and review workflow in its own EventCatalog project. A central catalog selects those catalogs, validates them together, and materializes their resources as one connected catalog.
+
+<div className="federation-mermaid">
+
+```mermaid
+flowchart LR
+  subgraph TEAMS["Team-owned catalogs"]
+    direction TB
+    PAY["`**Payments team**
+    Services · APIs · events
+    ADRs · docs`"]
+    ORD["`**Orders team**
+    Services · commands · flows
+    ADRs · docs`"]
+    FUL["`**Fulfillment team**
+    Services · events · diagrams
+    ADRs · docs`"]
+  end
+
+  PAY --> FED["`**eventcatalog federate**
+  Merge · resolve · validate`"]
+  ORD --> FED
+  FUL --> FED
+  FED --> ORG["`**Organization catalog**
+  One connected view`"]
+
+  classDef team fill:#eef2ff,stroke:#6366f1,color:#1e1b4b
+  classDef federation fill:#f5f3ff,stroke:#8b5cf6,color:#2e1065
+  classDef central fill:#ecfdf5,stroke:#10b981,color:#064e3b
+  class PAY,ORD,FUL team
+  class FED federation
+  class ORG central
+  style TEAMS fill:#f8fafc,stroke:#cbd5e1,stroke-dasharray:5 5,color:#475569
+```
+
+</div>
+
+Federation is useful when one catalog repository or one documentation team would become a bottleneck. Each team can document its part of the architecture close to the people and code that own it, while the organization still gets one place to discover resources and follow relationships.
+
+## What Federation gives you
+
+Use Federation to:
+
+- Combine resources from multiple EventCatalog projects
+- Resolve relationships between catalogs
+- Validate organization-wide ownership and resource types
+- Include schemas, specifications, sidecar documentation, public assets, and custom components
+- Test federation against local catalogs before using remote sources
+- Fetch public or private catalogs from GitHub
+- Treat selected diagnostics as warnings, errors, or disabled rules
+- Keep the previous generated output when an update fails
+
+## The central catalog is still an EventCatalog
+
+The central catalog can own organization-wide documentation of its own, such as cross-domain flows, shared architecture decisions, or enterprise domains. Its local resources participate in the same ownership validation as federated resources.
+
+<div className="federation-mermaid">
+
+```mermaid
+flowchart LR
+  subgraph TEAMS["Team-owned catalogs"]
+    direction TB
+    ORD["`**Orders team**
+    Services · commands · docs`"]
+    PAY["`**Payments team**
+    Services · APIs · events`"]
+    FUL["`**Fulfillment team**
+    Services · events · diagrams`"]
+  end
+
+  FED["`**eventcatalog federate**
+  Hydrate · resolve · validate`"]
+
+  subgraph CENTRAL["Central catalog"]
+    direction TB
+    LOCAL["`**Central-owned documentation**
+    Organization flows · ADRs · domains`"]
+    REMOTE["`**Federated resources**
+    Generated into federated/`"]
+    VIEW["`**Organization catalog**
+    One connected view`"]
+
+    LOCAL --> VIEW
+    REMOTE --> VIEW
+  end
+
+  ORD --> FED
+  PAY --> FED
+  FUL --> FED
+  FED --> REMOTE
+
+  classDef team fill:#eef2ff,stroke:#6366f1,color:#1e1b4b
+  classDef federation fill:#f5f3ff,stroke:#8b5cf6,color:#2e1065
+  classDef central fill:#ecfdf5,stroke:#10b981,color:#064e3b
+  class ORD,PAY,FUL team
+  class FED federation
+  class LOCAL,REMOTE central
+  class VIEW central
+  style TEAMS fill:#f8fafc,stroke:#cbd5e1,stroke-dasharray:5 5,color:#475569
+  style CENTRAL fill:#f8fafc,stroke:#cbd5e1,stroke-dasharray:5 5,color:#475569
+```
+
+</div>
+
+The generated content is written to `federated/`. The normal EventCatalog development server or build then reads the local and federated resources together.
+
+## Federation is explicit
+
+The current workflow has two separate commands:
+
+```bash
+npx eventcatalog federate
+npm run build
+```
+
+`eventcatalog federate` fetches, validates, and materializes the configured sources. `npm run build` renders the resulting catalog. Federation does not run automatically before `dev`, `build`, or `generate`.
+
+:::info Enterprise feature
+
+EventCatalog Federation requires an EventCatalog Enterprise offline license. To try it, email [hello@eventcatalog.dev](mailto:hello@eventcatalog.dev?subject=EventCatalog%20Federation%20Trial) and we will send you an offline trial key. Save the `license.jwt` file in the root of your central catalog before running Federation.
+
+Learn more about [offline license validation](/docs/development/license-keys/license-validation#offline-validation).
+
+:::
+
+## Built-in Federation and the Federation generator
+
+These docs describe the built-in `eventcatalog federate` workflow. It uses catalog indexes, graph validation, content hashes, and generated federation output.
+
+It is different from the older `@eventcatalog/generator-federation` integration, which clones repositories and copies configured directories through the generator pipeline.
+
+## Current release status
+
+Federation is being released as an initial working version for feedback. The core composition and validation workflow is ready to use, while operational features such as automatic build integration, source management commands, frozen lockfile installs, and local file watching may evolve from user feedback.
+
+Read [MVP status and feedback](/docs/federation/explanation/mvp-status-and-feedback) for the current boundaries.
+
+## Next steps
+
+- Follow the [first federation tutorial](/docs/federation/first-federation).
+- Learn [how Federation works](/docs/federation/explanation/how-it-works).
+- [Configure GitHub sources](/docs/federation/how-to/configure-github-sources).
+- [Use local catalogs during development](/docs/federation/how-to/use-local-sources).
+- Look up the complete [configuration reference](/docs/federation/reference/configuration).
+- Review the [diagnostic rule reference](/docs/federation/reference/diagnostic-rules).