@eventcatalog/core 4.1.3 → 4.1.4

package/dist/docs/development/guides/flows/05-adding-flows-to-domains.md

@@ -1,43 +0,0 @@
----
-keywords:
-- EventCatalog flows
-sidebar_label: Adding flows to domains
-title: Adding flows to domains
-description: Associate flows with domains in EventCatalog
----
-
-Adding [flows](/docs/development/guides/flows/introduction) to your domains helps document which business processes or workflows belong to a particular domain.
-
-When adding flows to your domain EventCatalog will:
-
-- Show the flows in the domain sidebar
-- Create clear relationships between domains and the processes they contain
-
-You can also place flow files directly inside a domain directory. EventCatalog discovers any `index.mdx` inside a `flows` folder at any depth, so `/domains/Orders/flows/ProcessOrder/index.mdx` is a valid location.
-
-## Add flows using frontmatter
-
-To add flows to a domain you need to add them to the `flows` array within your domain frontmatter API.
-
-```md title="/domains/Orders/index.mdx (example)"
----
-id: OrdersDomain
-... # other domain frontmatter
-flows:
-    # id of the flow you want to add
-    - id: OrderProcessing
-    # (optional) The version of the flow you want to add.
-      version: 1.0.0
-
-    # Note: version is optional. If no version is given the latest version of the flow will be used.
-    - id: PaymentFlow
----
-
-<!-- Markdown content... -->
-
-```
-
-The `flows` frontmatter in your domain tells EventCatalog that these documented flows belong to this domain.
-
-In the example above we can see that the flows `OrderProcessing` and `PaymentFlow` belong to the `OrdersDomain`.
-

package/dist/docs/development/guides/flows/06-versioning.md

@@ -1,27 +0,0 @@
----
-sidebar_position: 6
-keywords:
-- versioning
-- services
-sidebar_label: Versioning
-title: Versioning
-description: Learn how to version flows
----
-
-
-All content in EventCatalog can be versioned. This allows you to keep historic versions of content which can give context to users why things are changing.
-
-## How to version a flow
-
-1. Create a `/versioned` directory inside the `/flows` folder if one is not created already.
-1. Create a new folder with the version number inside the folder.
-    - Example: `/flows/ProcessingPayments/versioned/0.0.1`
-1. Copy contents into the new folder, it at least needs your index.mdx file.
-    - Example: `/flows/ProcessingPayments/versioned/0.0.1/index.mdx`
-    - Note: the version inside this index.mdx file would be `0.0.1`
-1. Bump the version of the `index.mdx` file in the route of the domain.
-    - Example `/flows/ProcessingPayments/index.mdx`, change the `version` to `0.0.2`
-
-## How to navigate to versions
-
-EventCatalog will automatically create links for you within your latest version of your document. Users will also be able to navigate to any version by adding the version in the url (e.g /docs/flows/ProcessingPayments/1.0.2 would load the 1.0.2 version of this flow).

package/dist/docs/development/guides/flows/07-create-flow-with-ai.md

@@ -1,171 +0,0 @@
----
-sidebar_position: 2
-keywords:
-- EventCatalog flows
-- AI flow wizard
-- flow documentation
-- AI skills
-sidebar_label: Creating a flow (with AI)
-title: Creating a flow (with AI)
-description: Interactively document business flows using an AI agent skill.
----
-
-The [`flow-wizard` skill](/docs/development/ask-your-architecture/skills/introduction#available-skills) guides your AI agent through documenting a business flow step by step. Instead of writing the YAML frontmatter by hand, you have a conversation with your agent describing what happens in each stage and the skill builds the flow for you.
-
-The skill also cross-references your existing catalog resources (services, events, commands, queries) and links them into the flow automatically when it finds a match.
-
-## Prerequisites
-
-- An AI coding agent that supports the skills format (e.g. [Claude Code](https://claude.ai/code))
-- The `flow-wizard` skill installed in your project (see [installation](/docs/development/ask-your-architecture/skills/installation))
-- Optionally, an EventCatalog MCP server connection so the agent can query your catalog directly
-
-## Install the skill
-
-```bash
-# Install all EventCatalog skills
-npx skills add event-catalog/skills
-
-# Install only the flow-wizard skill
-npx skills add event-catalog/skills --skill flow-wizard
-```
-
-This copies the skill into `.claude/skills/flow-wizard/` where your agent can access it.
-
-## Start a session
-
-Open your AI agent and ask it to document a flow using natural language. The skill activates on phrases like:
-
-- "document a flow"
-- "map a business process"
-- "create a flow diagram"
-- "walk through a process"
-- "document an end-to-end flow"
-- "map out how something works in my architecture"
-
-**Example prompt:**
-
-> "Use the flow-wizard skill to help me document our checkout flow."
-
-## How a session works
-
-The wizard runs through a structured conversation. You describe your flow in plain language -- the agent handles the formatting.
-
-### Locate your catalog
-
-The agent first asks whether you have an EventCatalog project and where it lives. It scans your `services/`, `events/`, `commands/`, `queries/`, `domains/`, and `flows/` directories to build an inventory of existing resources.
-
-If you have the EventCatalog MCP server connected, the agent uses `getResources` to query the catalog directly. If you don't have a catalog yet, the agent documents steps as plain descriptions and you can add resource links later.
-
-### Describe the flow
-
-You describe the end-to-end process in your own words:
-
-> "A user places an order, payment is processed, inventory is reserved, and a confirmation email is sent."
-
-The agent breaks this into sections and presents them back for your confirmation before continuing.
-
-### Walk through each section
-
-The agent takes you through each section one at a time, asking what happens, who or what is involved, and what comes next.
-
-For each step it asks about, the agent:
-
-1. Determines the step type -- `actor`, `service`, `message`, or `externalSystem`
-2. Searches your catalog for a matching resource
-3. Presents any matches and asks you to confirm before linking them
-
-If a resource exists in your catalog, the agent uses its exact `id` and `version`. If nothing matches, it creates a placeholder and notes that you can document it fully later.
-
-### Handle branching
-
-When you describe a decision point ("if payment succeeds we continue, otherwise we notify the user"), the agent asks you to confirm the paths and documents them as `next_steps` branches.
-
-```yaml
-next_steps:
-  - id: "reserve_inventory"
-    label: "Payment succeeded"
-  - id: "notify_failure"
-    label: "Payment failed"
-```
-
-### Review and confirm
-
-Before writing any file, the agent shows a complete summary of every step, which resources were matched from your catalog, and which are new placeholders. You can request changes before the file is generated.
-
-### Generated output
-
-The agent writes an `index.mdx` file to your catalog. It asks where to save it if the location is ambiguous -- either `flows/{FlowName}/index.mdx` or `domains/{Domain}/flows/{FlowName}/index.mdx`.
-
-_PLACE_HOLDER_IMAGE_
-
-A generated flow might look like this:
-
-```md title="flows/CheckoutFlow/index.mdx (example)"
----
-id: "CheckoutFlow"
-name: "Checkout Flow"
-version: "0.0.1"
-summary: "End-to-end flow from cart submission through payment to order confirmation"
-steps:
-  - id: "customer_submits_order"
-    title: "Customer Submits Order"
-    actor:
-      name: "Customer"
-    next_step:
-      id: "place_order_command"
-      label: "Submit order"
-
-  - id: "place_order_command"
-    title: "Place Order"
-    message:
-      id: "PlaceOrder"
-      version: "1.0.0"
-    next_step:
-      id: "orders_service"
-      label: "Send to Orders Service"
-
-  - id: "orders_service"
-    title: "Orders Service"
-    service:
-      id: "OrdersService"
-      version: "2.1.0"
-    next_steps:
-      - id: "payment_gateway"
-        label: "Process payment"
-      - id: "order_rejected"
-        label: "Reject order"
-
-  - id: "payment_gateway"
-    title: "Stripe"
-    externalSystem:
-      name: "Stripe"
-      summary: "Third-party payment processor"
-      url: "https://stripe.com"
-    next_step:
-      id: "order_confirmed"
-      label: "Payment complete"
-
-  - id: "order_confirmed"
-    title: "Order Confirmed"
-    message:
-      id: "OrderConfirmed"
-      version: "1.0.0"
-
-  - id: "order_rejected"
-    title: "Order Rejected"
-    message:
-      id: "OrderRejected"
-      version: "1.0.0"
----
-
-<NodeGraph />
-```
-
-Once saved, the flow appears in your EventCatalog at `http://localhost:3000/visualiser/flows/CheckoutFlow/0.0.1`.
-
-## Next steps
-
-- Resources the agent could not match are noted in the session summary. Use the `catalog-documentation-creator` skill to document those resources.
-- See [flow nodes](/docs/development/guides/flows/flow-nodes) for the full list of step types you can use to extend the generated flow.
-- See [adding flows to domains](/docs/development/guides/flows/adding-flows-to-domains) if you want to move the flow under a domain.

package/dist/docs/development/guides/messages/01-overview.md

@@ -1,57 +0,0 @@
----
-sidebar_position: 1
-keywords:
-- EventCatalog queries
-- Queries
-sidebar_label: Overview
-title: Overview
-description: What are messags in EventCatalog?
----
-
-EventCatalog supports different types of messages ([commands](/docs/development/guides/messages/commands/introduction), [events](/docs/development/guides/messages/events/introduction) and [queries](/docs/development/guides/messages/queries/introduction)).
-
-- **Commands**
-    - Commands are messages that represent intent, commands can be rejected in distributed systems.
-- **Events**
-    - Events are a type of message that represent immutable facts.
-- **Queries**
-    - Queries are a type of message that represent requests for information.
-
-
-### Linking messages to services, domains and channels
-
-- Messages can be sent (producer) or received (consumer) by [services](/docs/development/guides/services/introduction), [domains](/docs/development/guides/domains/creating-domains/adding-messages-to-domains) or be totally independent.
-- You can also route messages through one or more [channels](/docs/development/guides/channels/adding-messages-to-services).
-
-### Where do messages live?
-
-Messages can live anywhere in your catalog, at the service level or domain level.
-
-**Example of a message living at the service level**
-
-Here we have the `OrderPlaced` message living at the service level.
-
-```md
-services/
-  Orders/
-    events/
-      OrderPlaced/
-        index.mdx
-```
-
-**Example of a message living at the domain level**
-
-Here we have the `OrderPlaced` message living at the domain level.
-
-```md
-domains/
-  Orders/
-    events/
-      OrderPlaced/
-        index.mdx
-```
-
-:::tip You can reference messages from anywhere in your catalog
-It does not matter where you store your messages, you can reference them from anywhere in your catalog.
-Your domains and services will reference them by their `id` and optionally the `version`. EventCatalog will resolve the message.
-:::

package/dist/docs/development/guides/messages/_category_.json

@@ -1,11 +0,0 @@
-{
-  "label": "Messages",
-  "position": 3,
-  "collapsible": true,
-  "collapsed": true,
-  "link": {
-    "type": "generated-index",
-    "slug": "/messages",
-    "description": "A collection of guides to help you understand commands and how they work with EventCatalog."
-  }
-}

package/dist/docs/development/guides/messages/commands/02-adding-commands.md

@@ -1,131 +0,0 @@
----
-sidebar_position: 2
-keywords:
-- EventCatalog commands
-sidebar_label: Creating a command
-title: Creating commands
-description: Creating and managing commands within EventCatalog.
----
-
-import AddedIn from '@site/src/components/MDX/AddedIn';
-
-Commands live in a `/commands` folder. This folder can be placed:
-
-- At the root of your catalog, or
-  - `/commands/{Command Name}/index.mdx` 
-- Inside a specific service folder.
-  - `/services/{Service Name}/commands/{Command Name}/index.mdx` 
-
-The contents are split into two sections, **frontmatter** and the **markdown content**.
-
-_Here is an example of what a command markdown file may look like._
-
-```md title="/commands/UpdateInventory/index.mdx (example)"
----
-# id of your command, used for slugs and references in EventCatalog.
-id: UpdateInventory
-
-# Display name of the command, rendered in EventCatalog
-name: Update Inventory
-
-# Version of the command
-version: 0.0.3
-
-# Short summary of your command
-summary: |
-  Command with the intent to update the inventory
-
-# Optional owners, references teams or users
-owners:
-    - dboyne
-
-# Optional badges, rendered to UI by EventCatalog
-badges:
-    - content: New service
-      backgroundColor: blue
-      textColor: blue
----
-
-## Overview
-
-The `Update Inventory` command represents intent to update the inventory of a given item over HTTP.
-
-<NodeGraph />
-
-```
-
-Once this file is added, the command will automatically appear across EventCatalog.
-
-## Writing command content
-
-You can write any Markdown inside a command. 
-
-Each command gets its own page, so use this space to fully explain how it works.
-
-You can also use [interactive components](/docs/development/components/using-components) to enrich your documentation.
-
-## Assign services to your commands
-
-To add services that invoke or accept your command you can read the [guide on adding messages to services](/docs/development/guides/messages/common/map-to-producers-and-consumers).
-
-You can also assign your command to one or more [channels](/docs/development/guides/channels/adding-messages-to-services) (e.g HTTP, GraphQL, etc).
-
-<AddedIn version="3.18.0" />
-
-## Document an HTTP operation
-
-If your command maps to an HTTP endpoint, use the `operation` field to document the method, path, and expected status codes.
-
-```md title="/commands/UpdateInventory/index.mdx (example)"
----
-id: UpdateInventory
-# ...
-operation:
-  method: PUT
-  path: /inventory/{id}
-  statusCodes:
-    - "200"
-    - "400"
-    - "404"
----
-```
-
-When defined, the visualiser shows an HTTP method badge, the API path, and colored status code pills on the command node. See the [command API reference](/docs/api/command-api#operation) for all available options.
-
-## Adding schemas to your command
-
-You can add any schema format to your command, you can read the [guide on adding schemas to messages](/docs/development/guides/messages/common/adding-schemas).
-
-## What should I document?
-
-There’s no strict structure, but consider including:
-
-- Purpose – What does this command do and why does it exist?
-- How to trigger it – APIs, SDKs, or UI actions
-- Schema – Payload structure and validation rules
-- Ownership – Who maintains this command?
-- Contributing – How others can propose changes
-
-## Custom icon
-
-<AddedIn version="3.28.1" />
-
-Set `styles.icon` in your frontmatter to display a custom icon on the command. The icon appears in the visualiser node, sidebar navigation, page header, and search results.
-
-```md title="/commands/UpdateInventory/index.mdx (example)"
----
-id: UpdateInventory
-name: Update Inventory
-version: 0.0.3
-styles:
-  icon: /icons/messaging/sns.svg
----
-```
-
-The value can be a path to a file in your catalog's `public/` folder (e.g. `/icons/messaging/sns.svg`) or an absolute URL (e.g. `https://cdn.simpleicons.org/amazonsqs`).
-
-## How do commands appear in EventCatalog?
-
-![Example](../../img/commands/example.png)
-
-

package/dist/docs/development/guides/messages/commands/_category_.json

@@ -1,11 +0,0 @@
-{
-  "label": "Commands",
-  "position": 3,
-  "collapsible": true,
-  "collapsed": true,
-  "link": {
-    "type": "generated-index",
-    "slug": "/commands",
-    "description": "A collection of guides to help you understand commands and how they work with EventCatalog."
-  }
-}

package/dist/docs/development/guides/messages/common/01-map-to-producers-and-consumers.md

@@ -1,37 +0,0 @@
----
-keywords:
-- EventCatalog commands
-sidebar_label: Map to producers and consumers
-title: Assigning events to services
-description: Understanding how to link events to services
-sidebar_position: 1
----
-
-[Services](/docs/development/guides/services/introduction) can either **send** or **receive** events, commands and queries. 
-
-To add messages to services you need to reference them within your service itself by adding the `id`. The `version` is optional and if not provided the latest version will be used.
-
-```md title="/services/Orders/index.mdx (example)"
----
-id: OrderService
-... # other service frontmatter
-receives:
-    # id of the message this service receives
-    - id: OrderPlaced
-    # (optional) The version of the message you want to add
-      version: 0.0.1
-sends:  
-    # id of the message this service sends
-    - id: PaymentProcessed
----
-
-<!-- Markdown contents... -->
-```
-
-### Versioning
-
-When you reference a message in your service you can specify the version of the message.
-
-This allows you to document which versions of messages your service interacts with.
-
-If you don't specify a version the latest version will be used.

package/dist/docs/development/guides/messages/common/02-adding-schemas.md

@@ -1,58 +0,0 @@
----
-keywords:
-- EventCatalog commands
-sidebar_label: Adding schemas to messages
-title: Adding schemas to messages
-description: Understand how to add schemas to your messages.
-sidebar_position: 2
----
-
-EventCatalog allows you to attach schemas to any message. 
-
-**EventCatalog supports any schema format. (e.g Avro, Protobuf, JSON etc)**
-
-![Example](../../img/commands/schemas.png)
-
-Schemas are very useful for users that want to understand the properties of your message and the context behind them.
-
-### Adding schemas to your messages
-
-To add a schema to your message you need to add the `schemaPath` value in your message frontmatter and drop the schema file into your message folder.
-
-```md title="/{events|commands|queries}/InventoryAdjusted/index.mdx (example)"
----
-id: InventoryAdjusted
-version: 0.0.4
-# relative path to the schema file
-schemaPath: schema.avro
----
-```
-
-Folder structure:
-```md
-/commands (or /events or /queries)
-  /InventoryAdjusted
-    index.mdx
-    schema.avro
-```
-
-#### Schema Components
-
-EventCatalog supports two components to render schemas into your message page.
-
-1. `<Schema/>` - Renders the schema into your message page as a JSON code block
-2. `<SchemaViewer/>` - Renders the schema into your message page using a nice Schema component (JSON and Avro supported)
-
-```md title="/{events|commands|queries}/InventoryAdjusted/index.mdx (example)"
-<!-- Renders the given schema into the page, as a JSON code block -->
-<Schema file="schema.avro" />
-
-<!-- Renders the given schema into the page using a nice Schema component -->
-<SchemaViewer file="schema.avro" />
-```
-
-#### Adding example usage for your message
-
-Once you document your schema, you can also add `Usage Examples` for your schemas to help your teams understand how they schemas are used in a list of different ways.
-
-You can read more about in the [usage example documentation](/docs/development/guides/messages/common/examples).

package/dist/docs/development/guides/messages/common/03-owners.md

@@ -1,40 +0,0 @@
----
-keywords:
-- EventCatalog
-- events 
-- owners
-sidebar_label: Assigning Owners
-title: Adding event owners
-description: Adding owners to events with EventCatalog.
----
-
-Owners in EventCatalog are either **users** or **teams** and are **optional**.
-
-To add an owner or a team, you need to add the user or team to the owners field of the event.
-
-## Adding owners using frontmatter
-
-To add owners within an event you need to add them to the `owners` array within your event frontmatter API.
-
-You need to add the `id` of the owner.
-
-```md title="/events/InventoryOutOfStock/index.mdx (example)"
----
-id: AdjustInventory
-... # other event frontmatter
-owners:
-    - dboyne # represents a user
-    - webTeam # represents a team
----
-
-<!-- Markdown contents... -->
-
-```
-
-Assigning owners to your events can provide others with context of who owns this event and how to contact them.
-
-:::tip Creating users and teams
-    EventCatalog gives you the ability to create users and teams. You can read the documentation to get started.
-:::
-
-

package/dist/docs/development/guides/messages/common/07-components.md

@@ -1,12 +0,0 @@
----
-keywords:
-    - components 
-    - domains
-sidebar_label: Components
-title: Components
-description: Component list for domains 
----
-
-You can add custom EventCatalog components to your commands.
-
-[See the list of components and how to use them](/docs/development/components/using-components).

package/dist/docs/development/guides/messages/common/08-shared-messages-across-boundaries.md

@@ -1,70 +0,0 @@
----
-keywords:
-- EventCatalog commands
-sidebar_label: Patterns for shared messages
-title: Patterns for shared messages
-description: Understand the patterns for shared messages in EventCatalog.
----
-
-You can store your events, commands and queries in any folder in your EventCatalog.
-
-Here are some common usecases:
-
-- [Messages defined by the service](/docs/development/guides/messages/common/shared-messages-across-boundaries#messages-defined-by-the-service)
-- [Messages defined at a domain level](/docs/development/guides/messages/common/shared-messages-across-boundaries#define-messages-at-a-domain-level)
-- [Messages defined at a system level](/docs/development/guides/messages/common/shared-messages-across-boundaries#define-messages-at-a-system-level)
-
-### Messages defined by the service
-
-If you want to keep your message definition close to the service that producers or consumes it you can store them in the `/services` folder.
-
-In the example below the `OrderPlaced` event, `AddOrder` command and `GetOrder` query are defined in the `/services/Orders` folder.
-
-```md
-services/
-  Orders/
-    events/
-      OrderPlaced/
-        index.mdx
-    commands/
-      AddOrder/
-        index.mdx
-    queries/
-      GetOrder/
-        index.mdx
-```
-
-### Define messages at a domain level
-
-If you want to share messages across multiple services you can define them in the `/domains` folder.
-
-In the example below the `OrderPlaced` event, `AddOrder` command and `GetOrder` query are defined in the `/domains/Orders` folder.
-
-```md
-domains/
-  Orders/
-     <!-- The domain documentation -->
-    index.mdx
-    <!-- Here we store our /events, /commands and /queries -->
-    events/
-      OrderPlaced/
-        index.mdx
-```
-
-### Define messages at a system level
-
-If you want to share messages across all your domains you can define them in the root of your catalog.
-
-In the example below the `OrderPlaced` event, `AddOrder` command and `GetOrder` query are defined in the root of your catalog.
-
-```md
-events/
-  OrderPlaced/
-    index.mdx
-commands/
-  AddOrder/
-    index.mdx
-queries/
-  GetOrder/
-    index.mdx
-```

package/dist/docs/development/guides/messages/common/_category_.json

@@ -1,11 +0,0 @@
-{
-  "label": "Common to all messages",
-  "position": 20,
-  "collapsible": true,
-  "collapsed": true,
-  "link": {
-    "type": "generated-index",
-    "slug": "/messages/common",
-    "description": "A collection of guides to help you understand queries and how they work with EventCatalog."
-  }
-}