LiteBus Capability Catalog

This document is the root index for LiteBus capabilities across all feature axes. It consolidates the per-axis catalogs under docs/catalog/ without duplicating their full content. Use it for expansion planning, gap analysis, test coverage review, and discovering which packages and docs apply to a use case.

Total capabilities indexed: 158 across 10 axes (15 analyzers, 16 dispatch, 20 durable core, 16 hosting, 14 ingress, 12 mediator, 18 runtime, 11 saga, 21 storage, 15 transport).

Purpose

LiteBus ships as granular NuGet packages along concern boundaries. The capability catalog names each shipped (or explicitly planned) behavior with a stable ID, maturity tier, package mapping, and link to a deep doc page.

Use this catalog when you need to:

• Compare what LiteBus covers today versus what your application must build
• Plan a new adapter, analyzer rule, or axis extension without re-reading every feature guide
• Trace dependencies between axes (for example ingress requires transport and durable storage)
• Prioritize roadmap work from documented coverage gaps

Each axis maintains its own folder with standalone capability files and a README index. Test coverage (covered, untested, and out-of-scope use cases) lives in each capability file. This root page synthesizes those folders; detail lives in the linked axis pages.

How to Read

Capability ID Schema

Every capability has an ID of the form axis.slug:

Storage role capabilities use dotted slugs (storage.role.append). Broker adapters often suffix -adapter (transport.amqp-adapter). Dispatch inbox/outbox pairs share broker names (dispatch.inbox.amqp, dispatch.outbox.amqp).

Maturity Legend

When a capability spans tiers (for example AMQP ingress GA, Kafka ingress Beta), the master table notes the split.

Deep Docs

Each capability links to a file under docs/catalog/<axis>/. Axis README pages list the same IDs with local context. Broader narrative guides remain in docs/ (Architecture, Inbox, Outbox, transport guides, and similar).

Capability Map

LiteBus capability axes
|
+-- Platform foundation
|     runtime (module graph, registry, mediator engine, contracts, serialization)
|     analyzers (compile-time LB1001-LB1017 rules)
|
+-- In-process mediation
|     mediator (commands, queries, events, pipeline, registration)
|
+-- Durable messaging
|     durable-core (accept/enqueue, processors, semantics, operations)
|     storage (store roles, PostgreSQL/EF/InMemory adapters)
|     dispatch (in-process and broker dispatchers)
|     ingress (broker intake into inbox)
|     saga (correlated inbox state; Extension tier)
|
+-- Integration and operations
      transport (broker-neutral publish/consume)
      hosting (AddLiteBus, manifest, health, management, OpenTelemetry)

flowchart TB
  subgraph foundation["Platform foundation"]
    RT[runtime]
    AN[analyzers]
  end
  subgraph mediation["In-process mediation"]
    ME[mediator]
  end
  subgraph durable["Durable messaging"]
    DC[durable-core]
    ST[storage]
    DI[dispatch]
    IN[ingress]
    SG[saga Extension]
  end
  subgraph integration["Integration and operations"]
    TR[transport]
    HO[hosting]
  end
  RT --> ME
  RT --> DC
  ME --> DC
  DC --> ST
  DC --> DI
  DC --> IN
  DC --> SG
  DI --> TR
  IN --> TR
  HO --> RT
  AN -.-> ME
  AN -.-> DC
  AN -.-> DI

Master Capability Table

One row per capability. Packages list primary install targets; transitive abstractions omitted unless they are the main surface.

Analyzers (15)

Dispatch (16)

Durable Core (20)

Hosting (16)

Ingress (14)

Mediator (12)

Runtime (18)

Saga (11)

Storage (21)

Transport (15)

Axis Index

Analyzers (15 capabilities)

Compile-time Roslyn rules (LB1001 through LB1017) that guard handler registration, durable contracts, inbox accept semantics, EF transactional wiring, and processor/dispatcher coupling. No runtime dependency on LiteBus libraries.

Key requires: application projects reference LiteBus.Analyzers; protected axes (mediator, durable core, dispatch, storage) must be composed for rules to apply meaningfully.

Dispatch (16 capabilities)

Turns leased durable envelopes into side effects through in-process mediators or broker transports. Exactly one dispatcher per inbox or outbox module.

Key requires: durable-core.inbox-processor or durable-core.outbox-processor, matching storage adapter, and for broker paths transport.* plus ingress on consuming services.

Durable Core (20 capabilities)

Accept/enqueue, processors, lease/retry/dead-letter, idempotency, transactional writes, operations, and semantic guarantees for reliable messaging.

Key requires: runtime.contract-registry, runtime.message-serialization, storage adapter (via storage.*), dispatch adapter (via dispatch.*), optional ingress.* for broker intake.

Hosting (16 capabilities)

AddLiteBus, module registry, manifest model, generic host orchestration, ASP.NET health and management, OpenTelemetry registration bridges.

Key requires: runtime.modules, runtime.litebus-builder; consumes manifest entries registered by durable, ingress, and storage modules.

Ingress (14 capabilities)

Broker intake into inbox accept. Commands only; pairs with transport consume and inbox storage.

Key requires: LiteBus.Inbox.Ingress, matching LiteBus.Transport.*, inbox storage, durable-core.inbox-acceptance.

Mediator (12 capabilities)

In-process commands, queries, and events with shared pipeline, priority, filtering, and registration.

Key requires: runtime.message-module, runtime.message-mediator; semantic packages (LiteBus.Commands, LiteBus.Queries, LiteBus.Events).

Runtime (18 capabilities)

Module graph, message registry, contract registry, core mediator engine, serialization, and trace metadata. Foundation for all other axes.

Key requires: none beyond platform contracts; hosting bridges consume its output.

Saga (11 capabilities)

Extension-tier correlated state around inbox command dispatch. Not a full workflow engine.

Key requires: durable-core.inbox-processor, durable-core.processor-hooks, inbox in-process or remote dispatch with shared store for multi-step workflows.

Storage (21 capabilities)

Store roles, PostgreSQL/EF/InMemory adapters, schema management, transactional bindings, work signals.

Key requires: durable-core.durable-storage; registered inside AddInbox / AddOutbox builders.

Transport (15 capabilities)

Broker-neutral publish and consume platform. One broker adapter per process.

Key requires: runtime.message-serialization, runtime.contract-registry for wire contract headers; consumed by dispatch.* and ingress.*.

Capability Page Template

Each standalone file under docs/catalog/<axis>/ follows this layout. Axis folders contain only capability pages and README.md (no axis-level test or scenario files).

Public Surface Subsections

Use only subsections that apply:

Observability

When instruments exist, document each with: name (public constant when shipped), kind (counter, gauge, histogram, Activity, log EventId), when emitted, tags, how to enable (package or AddOpenTelemetry extension), and operational note (what to alert on). When none exist, state that explicitly and name practical alternatives (application logging, cross-axis meters, analyzers).

Test Coverage Model

Each capability file ends with Test coverage:

Covered use case block (one per test method):

#### `ClassName.MethodName`

- **Use case**: plain-English situation (DDD term)
- **Test kind**: Unit | Integration | Component | Analyzer | Manual/CI-only
- **Description**: fixture and setup
- **Behavior**: action under test
- **Expected outcome**: assertion target
- **Remarks**: project path, inherited contract suite, CI fixture notes

Test Kind Vocabulary

Axis Test Coverage Pointers

Cross-Axis Gaps

Synthesis from per-capability Untested use cases and Out-of-scope use cases sections. "Expansion candidate" indicates whether a first-class LiteBus capability is a natural fit (Yes), partial or roadmap (Partial), or intentional non-goal (No).

Expansion Guide

To add a new LiteBus capability:

1. Choose the axis. Match dependency role rules in Dependency graph. New broker glue belongs in transport plus dispatch and/or ingress, not in durable core.

2. Add catalog files under docs/catalog/<axis>/.

   • One standalone capability markdown file using the capability page template (axis.slug, maturity, summary, Public surface, packages, requires, invariants, non-goals, Observability, Test coverage with one block per covered test method).
   • Update the axis README.md capability table only.
   • Add or extend tests; add one covered use case block per new test method.

3. Update this root catalog. Add a row to the master capability table, adjust axis counts, and revisit cross-axis gaps if the new capability closes a documented gap.

4. Update sibling docs when shipping code:

   • Architecture.md for invariants and feature sections
   • Dependency-Graph.md for new packages and dependency-role placement
   • Roadmap.md when moving from Planned to GA or closing deferred items
   • Feature guides (Inbox.md, transport guides, and similar) for narrative registration recipes
   • Analyzers.md and LiteBus.Analyzers tests if compile-time rules apply
   • v6-Feature-Index.md when the capability is v6-shipped (optional cross-link)

5. Preserve granular packaging. Do not merge orthogonal adapters into kitchen-sink packages unless an explicit breaking packaging change is approved.

Related Documentation

• Architecture
• Dependency graph
• Extensibility
• Roadmap
• Glossary
• Per-axis catalogs: analyzers, dispatch, durable-core, hosting, ingress, mediator, runtime, saga, storage, transport