Mediator behavior order

Question and use cases

The fourteen registered behaviors execute in this exact composition-root order.

Use this diagram when a request appears to skip, duplicate, or reorder a cross-cutting policy.

Use the diagram during design review, incident diagnosis, code walkthroughs, and onboarding. It intentionally omits classes and projects unrelated to the focused question, so read it together with the source entry point and related topic pages.

This page covers only the named responsibilities and relationships; consult the relevant module documentation for capabilities not shown here.

Reading path

1. Step 1: Read the fourteen behaviors in registration order, not alphabetical order.
2. Step 2: Runtime license and authorization gate before validation, idempotency, and transaction.
3. Step 3: Separate pre-transaction gates from transactional work and post-transaction effects.
4. Step 4: Check marker contracts before assuming every behavior performs work for every request.

Do not skip arrow direction, numbering, or group titles: they express dependency or time direction, execution order, and responsibility boundaries. If the diagram differs from current source or accepted architecture decisions, correct the generated catalog immediately.

Legend and notation

This is a PIPELINE diagram. Use that form to understand the layout, then test your interpretation against the source facts below.

Key relationships and design meaning

Relationship 1

Source fact: The generated projection registers exactly fourteen request behaviors in the order shown (DelegatedSessionRestriction sits between Authorization and Validation; ReadModelDisplay runs last), plus a three-behavior stream pipeline (LoggingStream → RuntimeLicenseStream → AuthorizationStream).

Architectural meaning: The exact order is part of request semantics; a registration move can change what is authorized, persisted, retried, or audited.

Review action: Does the license gate run before authorization, validation, and persistence?

Relationship 2

Source fact: Runtime license gates (fail-closed) run after logging and before authorization, validation, and the transaction boundary.

Architectural meaning: Placing the runtime license gate before authorization and the transaction ensures no unlicensed work reaches the database or the handler.

Review action: Does authorization fail before validation, idempotency, and persistence work?

Relationship 3

Source fact: Authorization and validation run before idempotency and the transaction boundary.

Architectural meaning: Rejecting unauthorized or invalid work early avoids creating idempotency records or transactions for work that must not run.

Review action: Which behavior owns the concern instead of the handler?

Relationship 4

Source fact: Domain events dispatch after transactional work and before post-processing and activity audit.

Architectural meaning: Post-transaction event and audit placement determines whether downstream effects observe committed state and how failures are recorded.

Review action: Would moving the behavior change transaction or audit semantics?

Design review questions

Answer each question when reviewing or implementing a related change. If code, tests, or an ADR cannot support the answer, do not decide from the diagram alone.

• Does the license gate run before authorization, validation, and persistence?
• Does authorization fail before validation, idempotency, and persistence work?
• Which behavior owns the concern instead of the handler?
• Would moving the behavior change transaction or audit semantics?

How to use the answers

1. Identify the single owner of the capability or rule.
2. Confirm that dependency, call, or event direction does not reverse ownership.
3. Capture the conclusion with an automated test or repeatable command.

Boundaries and common mistakes

Boundary 1

Stream denials throw an exception mapped to 403 before the handler enumerates, unlike request denials which return a typed Result.

• Do not infer: A connector in the diagram does not mean every implementation uses synchronous calls, a shared transaction, or shared data ownership.
• Review requirement: Does authorization fail before validation, idempotency, and persistence work?

Boundary 2

A behavior can skip work when a request does not implement its marker contract; the registration order does not change.

• Do not infer: A connector in the diagram does not mean every implementation uses synchronous calls, a shared transaction, or shared data ownership.
• Review requirement: Which behavior owns the concern instead of the handler?

Boundary 3

Do not recreate license, authorization, idempotency, or audit logic inside individual handlers.

• Do not infer: A connector in the diagram does not mean every implementation uses synchronous calls, a shared transaction, or shared data ownership.
• Review requirement: Would moving the behavior change transaction or audit semantics?

Source verification and regeneration

The primary verification entry point is src/Hosts/BitzOrcas.Api/Composition/Generated/PipelineCapabilityProjection.g.cs. Inspect it and its direct references before regenerating diagram assets and pages.

# Regenerate bilingual SVG, standalone HTML, and documentation pages
npm run diagrams

# Check locale pairs, references, safety attributes, accessibility, and canvas bounds
npm run verify:diagrams

# Confirm that generation changed only the intended diagrams and pages
git diff -- scripts/diagrams diagram-sources public/diagrams src/content/docs

# Verify internal links, MDX structure, and professional depth gates
npm run verify:docs
npm run audit:docs-depth

Change-completion checklist

• Responsibilities, order, states, and relationships match current source.
• Every new element helps answer this page’s question instead of turning the diagram into an inventory.
• Arrows have explicit direction and semantics without implying nonexistent synchronous or transactional guarantees.
• Chinese and English titles, labels, facts, and boundaries remain semantically equivalent.
• The diagram remains readable on narrow screens, in fullscreen, and while zoomed, with no overlap or overflow.
• Relevant architecture tests, integration tests, or verification commands have run.
• If a long-lived constraint changed, its ADR or architecture documentation is updated.

Continue reading

• Architecture overview
• All architecture diagrams
• Platform modules