AI Prompt: Forma3D.Connect — EventCatalog Architecture Documentation¶

Purpose: Set up EventCatalog (community edition) to document the microservice architecture's domains, services, events, commands, queries, and schemas — providing a browsable, searchable, AI-queryable catalog of the system's architecture
Estimated Effort: 16–24 hours (setup + content migration + CI/CD integration + deployment)
Prerequisites: Microservice architecture implemented per docs/_internal/prompts/todo/prompt-gridflock-stl-generation-service.md (Gateway, Order Service, Print Service, Shipping Service, GridFlock Service running with BullMQ event queues)
Output: A self-hosted EventCatalog instance documenting all domains, services, BullMQ events, HTTP commands/queries, and TypeScript event schemas — deployed as a static site via the existing CI/CD pipeline, with an MCP server for AI tool integration (Cursor)
Status: ✅ DONE

🎯 Mission¶

Set up EventCatalog (open-source community edition) as the single source of truth for architectural documentation of the Forma3D.Connect microservice platform. This catalog complements the existing C4 model diagrams (which remain the primary structural documentation) by adding a browsable, searchable, AI-queryable layer focused on domains, services, events, and their relationships.

What this delivers:

1. EventCatalog instance — Markdown-based, Git-stored, self-hosted static site
2. Domain documentation — Orders, Printing, Shipping, GridFlock domains with ownership and descriptions
3. Service documentation — All 6 services (Gateway, Order, Print, Shipping, GridFlock, Slicer) with endpoints, dependencies, and ownership
4. Event documentation — All BullMQ event types with typed schemas, publishers, subscribers, and flow diagrams
5. Command & Query documentation — 8 HTTP inter-service commands (sync) and 7 inter-service queries
6. Schema documentation — TypeScript event interfaces and DTOs, versioned
7. Visualizations — Auto-generated service dependency graphs and message flow diagrams (complements, does not replace, C4 diagrams)
8. MCP Server — EventCatalog's built-in MCP server for AI tools (Cursor) to query architecture
9. CI/CD integration — Catalog rebuilds on every push that touches architecture docs
10. Deployment — Static site served via Traefik on staging-connect-eventcatalog.forma3d.be

What this does NOT replace:

• C4 model diagrams (PlantUML) — These remain the primary structural documentation for context, container, component, code, and deployment views. EventCatalog focuses on the runtime interactions (events, commands, queries) rather than the structural decomposition.
• ADR records — Architecture Decision Records stay in docs/03-architecture/adr/ADR.md
• State machine diagrams — These stay in docs/03-architecture/state-machines/
• Deployment guides — These stay in docs/05-deployment/

Why EventCatalog:

• The system now has 5+ services publishing/consuming 10+ BullMQ event types — manual markdown doesn't scale
• EventCatalog auto-generates service dependency visualizations from event/service definitions
• The MCP server lets Cursor answer questions like "what services consume gridflock.mapping-ready?" from the catalog
• Markdown-based and Git-stored — fits the existing workflow and .cursorrules philosophy
• Self-hosted and free (community edition) — no vendor lock-in, data stays in the repo
• Generates llms.txt automatically so AI tools always have up-to-date architectural context

📐 Architecture¶

Location & Nx Exclusion¶

The EventCatalog source lives under docs/03-architecture/eventcatalog/ — colocated with the rest of the architectural documentation. Since EventCatalog has its own build toolchain (Astro-based, not NestJS/TypeScript), it is excluded from the Nx project graph via .nxignore. Building and deploying is handled via npm scripts in its own package.json, not Nx targets.

Catalog Structure¶

docs/03-architecture/eventcatalog/
├── README.md                       # Links to hosted instance + setup instructions
├── eventcatalog.config.js          # EventCatalog configuration
├── package.json                    # Dependencies (@eventcatalog/core)
├── Dockerfile                      # Static site build for deployment
├── domains/
│   ├── Orders/
│   │   └── index.md                # Orders domain overview + subdomains
│   ├── Printing/
│   │   └── index.md                # Printing domain overview + subdomains
│   ├── Shipping/
│   │   └── index.md                # Shipping domain overview + subdomains
│   ├── GridFlock/
│   │   └── index.md                # GridFlock domain overview + subdomains
│   └── Platform/
│       └── index.md                # Platform (cross-cutting) domain overview
├── services/
│   ├── Gateway/
│   │   └── index.md                # API Gateway service
│   ├── OrderService/
│   │   └── index.md                # Order Service
│   ├── PrintService/
│   │   └── index.md                # Print Service
│   ├── ShippingService/
│   │   └── index.md                # Shipping Service
│   ├── GridflockService/
│   │   └── index.md                # GridFlock Service
│   └── SlicerContainer/
│       └── index.md                # Slicer Container (BambuStudio CLI)
├── events/
│   ├── OrderCreated/
│   │   ├── index.md                # Event documentation
│   │   └── schema.ts               # TypeScript schema
│   ├── OrderReadyForFulfillment/
│   │   ├── index.md
│   │   └── schema.ts
│   ├── OrderCancelled/
│   │   ├── index.md
│   │   └── schema.ts
│   ├── PrintJobCompleted/
│   │   ├── index.md
│   │   └── schema.ts
│   ├── PrintJobFailed/
│   │   ├── index.md
│   │   └── schema.ts
│   ├── PrintJobStatusChanged/
│   │   ├── index.md
│   │   └── schema.ts
│   ├── PrintJobCancelled/
│   │   ├── index.md
│   │   └── schema.ts
│   ├── ShipmentCreated/
│   │   ├── index.md
│   │   └── schema.ts
│   ├── ShipmentStatusChanged/
│   │   ├── index.md
│   │   └── schema.ts
│   ├── GridflockMappingReady/
│   │   ├── index.md
│   │   └── schema.ts
│   └── GridflockPipelineFailed/
│       ├── index.md
│       └── schema.ts
├── commands/
│   ├── CreatePrintJobs/
│   │   └── index.md                # Order → Print Service (HTTP POST)
│   ├── CancelJobsForOrder/
│   │   └── index.md                # Order → Print Service (HTTP POST)
│   ├── CreateShipment/
│   │   └── index.md                # Order → Shipping Service (HTTP POST)
│   ├── CancelShipment/
│   │   └── index.md                # Order → Shipping Service (HTTP POST)
│   ├── GenerateForOrder/
│   │   └── index.md                # Order → GridFlock Service (HTTP POST)
│   ├── UpdateTracking/
│   │   └── index.md                # Shipping → Order Service (HTTP PATCH)
│   ├── UploadToSimplyPrint/
│   │   └── index.md                # GridFlock → Print Service (HTTP POST)
│   └── SliceSTL/
│       └── index.md                # GridFlock → Slicer (HTTP POST)
├── queries/
│   ├── GetJobsByOrderId/
│   │   └── index.md                # Print Service query
│   ├── GetJobStatusSummary/
│   │   └── index.md                # Print Service query
│   ├── GetShipmentsByOrderId/
│   │   └── index.md                # Shipping Service query
│   ├── GetOrderDetails/
│   │   └── index.md                # Order Service query
│   ├── GetOrderLineItems/
│   │   └── index.md                # Order Service query
│   ├── GetOrderByShopifyId/
│   │   └── index.md                # Order Service query
│   └── GetMappingStatus/
│       └── index.md                # GridFlock Service query
└── channels/
    ├── BullMQEventBus/
    │   └── index.md                # BullMQ event queue channel
    └── InternalHTTP/
        └── index.md                # Internal HTTP channel (service-to-service)

Relationship to Existing Documentation¶

┌─────────────────────────────────────────────────────────────────┐
│                    Architecture Documentation                    │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│  C4 Model (PlantUML) ◄──── KEEP ──── Structural views           │
│  ├── Level 1: System Context                                     │
│  ├── Level 2: Container (services topology)                      │
│  ├── Level 3: Component (internal modules)                       │
│  ├── Level 4: Code (domain model, DTOs)                          │
│  └── Deployment (infrastructure)                                 │
│                                                                  │
│  EventCatalog ◄──── NEW ──── Runtime interaction views           │
│  ├── Domains (business boundaries)                               │
│  ├── Services (with endpoints, dependencies)                     │
│  ├── Events (BullMQ: schemas, publishers, subscribers)           │
│  ├── Commands (sync HTTP calls between services)                 │
│  ├── Queries (sync HTTP reads between services)                  │
│  ├── Channels (BullMQ queues, internal HTTP)                     │
│  └── Auto-generated visualizations                               │
│                                                                  │
│  ADRs, State Machines, Deployment Guides ◄──── KEEP             │
│                                                                  │
│  docs/03-architecture/events/README.md ◄──── SUPERSEDED          │
│  (EventCatalog replaces the manual event catalog)                │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

Important: docs/03-architecture/events/README.md is the manual event catalog that EventCatalog supersedes. After EventCatalog is set up, add a deprecation notice to README.md pointing to the EventCatalog instance. Do NOT delete it — it serves as a reference for the migration.

📋 Content Specification¶

Domains¶

The domain model is defined in the GridFlock prompt (docs/_internal/prompts/todo/prompt-gridflock-stl-generation-service.md, section "Domain Model — Why These Services?"). EventCatalog documents these same domains with their subdomains:

Services¶

Events (BullMQ)¶

All events use BullMQ queues via libs/service-common BullMQEventBus. Each event type is a queue name. Document each with:

• Description of when and why the event is published
• TypeScript schema (from libs/service-common/src/lib/events/event-types.ts)
• Publisher service
• Subscriber service(s)
• Channel: BullMQ Event Bus
• Example payload

Event Schemas¶

Migrate from libs/service-common/src/lib/events/event-types.ts. Each event extends ServiceEvent:

// Base event interface — all events carry tenant context.
// Fields inspired by CloudEvents but tailored for internal BullMQ transport.
// See: docs/03-architecture/research/cloudevents-evaluation.md
interface ServiceEvent {
  eventId: string;           // UUID v4 — unique event identifier for idempotency
  eventType: string;         // Queue name (e.g. 'order.created')
  source: string;            // Source service (e.g. 'order-service')
  tenantId: string;          // Tenant identifier for multi-tenancy
  timestamp: string;         // ISO 8601
  correlationId?: string;    // For distributed tracing
}

Commands (Synchronous HTTP — Service-to-Service)¶

Queries (Synchronous HTTP — Service-to-Service)¶

Channels¶

🔧 Implementation¶

Phase 1: Setup & Configuration (2–3 hours)¶

1. Create EventCatalog project inside the architecture docs folder:

npx @eventcatalog/create-eventcatalog@latest docs/03-architecture/eventcatalog

1. Exclude from Nx — add docs/03-architecture/eventcatalog to .nxignore in the monorepo root:

# EventCatalog has its own build toolchain (Astro-based), not part of the Nx project graph
docs/03-architecture/eventcatalog

Why .nxignore? EventCatalog uses Astro under the hood with its own package.json and build scripts. Adding it to the Nx project graph would cause plugin auto-detection conflicts (Vite plugin, ESLint plugin, etc.). Excluding it keeps the Nx workspace clean and avoids false positive lint/build targets.

1. Exclude from Zensical — add exclude_docs to the existing [project] section in zensical.toml so the docs site generator does not process the EventCatalog directory:

# Add this key to the existing [project] section in zensical.toml:
# (path is relative to docs_dir, uses gitignore pattern format)
exclude_docs = """
03-architecture/eventcatalog/
"""

Why exclude from Zensical? The EventCatalog directory contains its own package.json, node_modules/, eventcatalog.config.js, a Dockerfile, and markdown files with EventCatalog-specific frontmatter. Zensical would try to process all of these, causing build errors and polluting the docs site with unrelated content. Excluding it ensures the docs site only serves the link to the EventCatalog container via docs/03-architecture/README.md, while the full catalog lives at staging-connect-eventcatalog.forma3d.be.

1. Configure docs/03-architecture/eventcatalog/eventcatalog.config.js:

export default {
  title: 'Forma3D.Connect',
  tagline: 'Architecture catalog for the Forma3D.Connect microservice platform',
  organizationName: 'DevGem',
  homepageLink: 'https://staging-connect.forma3d.be',
  editUrl: 'https://dev.azure.com/devgem/forma-3d-connect/_git/forma-3d-connect?path=docs/03-architecture/eventcatalog',
  logo: {
    alt: 'Forma3D Logo',
    src: '/logo.svg',
  },
  docs: {
    sidebar: {
      showPageHeadings: true,
    },
  },
};

1. Configure docs/03-architecture/eventcatalog/package.json with npm scripts (NOT Nx targets):

{
  "name": "@forma3d/eventcatalog",
  "private": true,
  "scripts": {
    "dev": "npx @eventcatalog/core dev",
    "build": "npx @eventcatalog/core build",
    "preview": "npx @eventcatalog/core preview"
  }
}

Note: Do NOT add this directory to pnpm-workspace.yaml or create a project.json. The EventCatalog is intentionally outside the Nx/pnpm workspace — it manages its own dependencies via npm ci inside the Dockerfile during build.

1. Create docs/03-architecture/eventcatalog/README.md:

# EventCatalog — Forma3D.Connect

Browsable architecture catalog documenting domains, services, events, commands, and queries
for the Forma3D.Connect microservice platform.

## Live Instance

**Staging:** https://staging-connect-eventcatalog.forma3d.be

## Local Development

```bash
cd docs/03-architecture/eventcatalog
npm install
npm run dev

Opens at http://localhost:3000

Relationship to Other Docs¶

• C4 Model (../c4-model/) — Structural views (context, container, component, code, deployment). EventCatalog cross-references these but does not duplicate them.
• ADRs (../adr/) — Architecture Decision Records. Remain separate.
• Sequences (../sequences/) — Detailed PlantUML sequence diagrams. EventCatalog links to these.
• State Machines (../state-machines/) — State machine diagrams. Remain separate.
• Events README (../events/README.md) — Legacy manual event catalog, superseded by this EventCatalog.

AI Integration (MCP Server)¶

EventCatalog includes a built-in MCP server for AI tools (Cursor). See docs/04-development/environment-setup.md for connection instructions.

### Phase 2: Domain & Service Documentation (4–6 hours)

7. Create domain markdown files for Orders, Printing, Shipping, GridFlock, Platform (including subdomains per domain — see domain model in `prompt-gridflock-stl-generation-service.md`)
8. Create service markdown files for all 6 services with:
   - Description and responsibility
   - Domain ownership
   - Technology stack (NestJS, BambuStudio CLI, etc.)
   - Internal port and container name
   - Health endpoint
   - Publishes/subscribes metadata (EventCatalog frontmatter)
   - Links to C4 component diagrams (cross-reference, not duplicate)
9. Create channel documentation for BullMQ Event Bus and Internal HTTP

### Phase 3: Event Documentation (4–6 hours)

10. Create markdown + schema files for all 11 BullMQ events
11. Migrate event schemas from `libs/service-common/src/lib/events/event-types.ts`
12. For each event, document:
    - Description (when/why published)
    - TypeScript schema (versioned)
    - Publisher service
    - Subscriber service(s)
    - Channel (BullMQ Event Bus)
    - Example payload with realistic data
    - Related events (e.g., `print-job.completed` relates to `order.ready-for-fulfillment`)
13. Migrate existing event documentation from `docs/03-architecture/events/README.md`
14. Add deprecation notice to `docs/03-architecture/events/README.md`:
    ```markdown
    > **⚠️ DEPRECATED:** This manual event catalog has been superseded by EventCatalog.
    > View the live catalog at: https://staging-connect-eventcatalog.forma3d.be
    > Source: `docs/03-architecture/eventcatalog/`
    ```

### Phase 4: Command & Query Documentation (2–3 hours)

15. Create command documentation for all 8 inter-service HTTP commands
16. Create query documentation for all 7 inter-service HTTP queries
17. For each command/query, document:
    - Description
    - HTTP method and route
    - Request/response DTOs
    - Caller and handler services
    - Channel (Internal HTTP)
    - Authentication (INTERNAL_API_KEY)

### Phase 5: Mermaid Flow Diagrams (2–3 hours)

18. Add Mermaid sequence diagram to the GridFlock pipeline event flow:
    - Shopify webhook → Order Service → GridFlock Service → Slicer → Print Service (SimplyPrint upload) → Order Service → Event Bus
19. Add Mermaid sequence diagram for the standard order lifecycle:
    - Order created → Print jobs created → Jobs complete → Fulfillment → Shipment
20. Add Mermaid sequence diagram for error/retry flows
21. Cross-reference C4 sequence diagrams where they provide more detail:
    - Link to `docs/03-architecture/sequences/C4_Seq_10_GridFlockPipeline.puml` etc.
    - EventCatalog diagrams show *event flow*, C4 diagrams show *detailed sequences*

### Phase 6: Deployment & CI/CD (2–3 hours)

22. Add `docs/03-architecture/eventcatalog/Dockerfile` for static site build:

```dockerfile
FROM node:20-alpine AS builder
WORKDIR /app
COPY . .
RUN npm ci && npx @eventcatalog/core build

FROM nginx:alpine
COPY --from=builder /app/out /usr/share/nginx/html
EXPOSE 80
HEALTHCHECK CMD wget -q --spider http://localhost/ || exit 1

Docker build context is docs/03-architecture/eventcatalog/ — the COPY . . copies only the EventCatalog source, not the full monorepo.

1. Add EventCatalog container to deployment/staging/docker-compose.yml:

eventcatalog:
  image: registry.digitalocean.com/devgem/forma3d-connect-eventcatalog:${EVENTCATALOG_IMAGE_TAG}
  container_name: forma3d-eventcatalog
  restart: unless-stopped
  labels:
    - "traefik.enable=true"
    - "traefik.http.routers.eventcatalog.rule=Host(`staging-connect-eventcatalog.forma3d.be`)"
    - "traefik.http.routers.eventcatalog.entrypoints=websecure"
    - "traefik.http.routers.eventcatalog.tls.certresolver=letsencrypt"
    - "traefik.http.services.eventcatalog.loadbalancer.server.port=80"
  networks:
    - forma3d-network

1. Add PackageEventCatalog job to Azure DevOps pipeline:

   • Detect changes in docs/03-architecture/eventcatalog/ directory
   • Build Docker image with context docs/03-architecture/eventcatalog/
   • Push to DigitalOcean Container Registry
   • Deploy on staging

2. Add DNS record for staging-connect-eventcatalog.forma3d.be

3. Add EventCatalog to Uptime Kuma monitoring

Phase 7: MCP Server Setup (1–2 hours)¶

1. Enable EventCatalog's built-in MCP server
2. Document how to connect Cursor to the EventCatalog MCP server
3. Add connection instructions to docs/04-development/environment-setup.md
4. Test example queries:
   • "What services consume the gridflock.mapping-ready event?"
   • "What events does the Order Service publish?"
   • "How does the GridFlock pipeline work?"
   • "What is the schema for print-job.completed?"

✅ Validation Checklist¶

Catalog Content¶

• All 5 domains documented (Orders, Printing, Shipping, GridFlock, Platform)
• All 6 services documented (Gateway, Order, Print, Shipping, GridFlock, Slicer)
• All 11 BullMQ events documented with TypeScript schemas
• All 8 commands documented (inter-service HTTP POST/PATCH)
• All 7 queries documented (inter-service HTTP GET)
• Both channels documented (BullMQ Event Bus, Internal HTTP)
• Each event has: description, schema, publisher, subscriber(s), channel, example payload
• Each service has: description, domain, technology, publishes/subscribes metadata
• Mermaid flow diagrams render correctly

Build & Deploy¶

• cd docs/03-architecture/eventcatalog && npm run build completes successfully
• cd docs/03-architecture/eventcatalog && npm run dev starts local dev server
• EventCatalog directory is excluded from Nx project graph (.nxignore entry exists)
• pnpm nx show projects does NOT list eventcatalog
• EventCatalog Docker image builds successfully (context: docs/03-architecture/eventcatalog/)
• Static site serves correctly via Traefik at staging-connect-eventcatalog.forma3d.be
• Azure DevOps pipeline detects docs/03-architecture/eventcatalog/ changes and builds/deploys
• Uptime Kuma monitors EventCatalog and reports healthy

Visualizations¶

• Auto-generated service dependency graph shows all services and their connections
• Event flow visualizations correctly show publisher → subscriber relationships
• Mermaid diagrams render in the catalog
• Cross-references to C4 diagrams link correctly

AI Integration¶

• EventCatalog MCP server starts and is accessible
• Cursor can connect to the MCP server
• Queries like "what events does Order Service publish?" return correct results
• llms.txt is generated during build and accessible at the catalog root

Documentation Consistency¶

• docs/03-architecture/eventcatalog/README.md exists with link to hosted instance and local dev instructions
• docs/03-architecture/events/README.md has deprecation notice pointing to EventCatalog
• docs/04-development/environment-setup.md includes MCP server connection instructions
• docs/03-architecture/README.md links to the EventCatalog directory and hosted instance
• .nxignore contains docs/03-architecture/eventcatalog entry
• zensical.toml contains exclude_docs entry for 03-architecture/eventcatalog/
• zensical build completes without processing EventCatalog files
• C4 model diagrams are NOT duplicated — EventCatalog links to them
• Event schemas in EventCatalog match libs/service-common/src/lib/events/event-types.ts

🚫 Constraints and Rules¶

MUST DO¶

• Keep all existing C4 model documentation (PlantUML) — EventCatalog complements, does not replace
• Keep all existing ADR records, state machine diagrams, and deployment guides
• Use EventCatalog community edition (free, open-source, self-hosted)
• Store all catalog content in docs/03-architecture/eventcatalog/ — colocated with other architecture docs
• Exclude docs/03-architecture/eventcatalog from Nx via .nxignore — do NOT create a project.json or add to pnpm-workspace.yaml
• Exclude docs/03-architecture/eventcatalog/ from Zensical via exclude_docs in zensical.toml — the docs site must not process EventCatalog files
• Add a README.md inside docs/03-architecture/eventcatalog/ linking to the hosted instance
• Version catalog content in Git alongside the code
• Event schemas must match the TypeScript interfaces in libs/service-common
• Cross-reference C4 diagrams from EventCatalog service/event docs (link, don't duplicate)
• Add deprecation notice to docs/03-architecture/events/README.md
• Deploy as a static site (no runtime dependencies beyond nginx)
• Add to Uptime Kuma monitoring

MUST NOT¶

• Remove or modify C4 model PlantUML files
• Remove or modify ADR records
• Remove or modify state machine diagrams
• Remove docs/03-architecture/events/README.md (add deprecation notice only)
• Duplicate C4 diagrams inside EventCatalog (link to them instead)
• Add EventCatalog to the Nx project graph — it must stay in .nxignore
• Add EventCatalog to pnpm-workspace.yaml — it manages its own dependencies
• Create a project.json inside docs/03-architecture/eventcatalog/
• Let Zensical process EventCatalog files — it must be excluded via exclude_docs
• Use EventCatalog's paid features — community edition only
• Hard-code any environment-specific URLs in the catalog content
• Use any, ts-ignore, or eslint-disable

SHOULD DO (Nice to Have)¶

• Add workflow documentation for common operations (order processing, GridFlock pipeline)
• Add ubiquitous language / glossary (Tenant, ProductMapping, PlateSet, etc.)
• Configure EventCatalog's search to index event schemas
• Add team/ownership badges to services
• Add version history for event schema changes
• Create a "Getting Started" page for new developers explaining the architecture via the catalog
• Explore EventCatalog's AsyncAPI integration for potential future use with BullMQ event definitions

📚 Key References¶

EventCatalog: - EventCatalog documentation: https://www.eventcatalog.dev/docs/ - EventCatalog GitHub: https://github.com/event-catalog/eventcatalog - EventCatalog MCP Server: https://www.eventcatalog.dev/docs/development/mcp (AI tool integration) - EventCatalog SDK: https://www.eventcatalog.dev/docs/sdk (programmatic catalog generation)

Existing Documentation (to migrate/cross-reference): - Current event catalog (to migrate): docs/03-architecture/events/README.md - BullMQ event definitions: libs/service-common/src/lib/events/event-types.ts - C4 model diagrams (to cross-reference): docs/03-architecture/c4-model/ - Sequence diagrams (to cross-reference): docs/03-architecture/sequences/ - Architecture README (to update): docs/03-architecture/README.md

Project: - Microservice architecture prompt: docs/_internal/prompts/todo/prompt-gridflock-stl-generation-service.md - Staging deployment guide: docs/05-deployment/staging-deployment-guide.md - Azure DevOps pipeline: azure-pipelines.yml - Nx ignore file (to create): .nxignore - Zensical config (to update): zensical.toml

END OF PROMPT

This prompt sets up EventCatalog (community edition) as an architecture catalog for the Forma3D.Connect microservice platform. The catalog source lives at docs/03-architecture/eventcatalog/, colocated with other architecture docs, excluded from the Nx project graph via .nxignore, and excluded from the Zensical docs build via exclude_docs in zensical.toml. It documents 5 domains (with subdomains), 6 services, 11 BullMQ events, 8 HTTP commands, and 7 HTTP queries — all with TypeScript schemas, publisher/subscriber relationships, and Mermaid flow diagrams. EventCatalog complements the existing C4 model (PlantUML) documentation by adding a browsable, searchable, AI-queryable layer focused on runtime interactions between services. The catalog is deployed as a static site via Docker/Traefik at staging-connect-eventcatalog.forma3d.be and includes an MCP server for Cursor integration. A README in the EventCatalog directory links to the hosted instance. The manual event catalog (docs/03-architecture/events/README.md) is superseded but not deleted.