EAC.Plugin.Outbox 2.3.0

EAC.Plugin.Outbox

First-party EAC plugin for metadata-first, target-agnostic Outbox diagnostics.

The initial rule family is EAOB and covers detection taxonomy, operational state, idempotency, persistence boundaries, recovery, observability, and framework registration mismatches.

The plugin owns recipes for all EAOB diagnostics. Recipes classify findings as mechanical, review-required, or advisory and populate review metadata so EAC remediation and review flows can route outbox findings without assuming a message broker, database target, or relational CRUD remediation path.

With trusted host compilation facts, immutable payloads passed to the framework's OutboxEnvelope.Create<TEvent> and passive KeyedRelationalDomainEvent records are excluded from work-item diagnostics. The exclusion requires resolved framework metadata and checks every partial declaration. Envelope uses are matched by type identity across all available host compilations, so a payload declared in a contracts project is recognized when another project passes it to the envelope. Envelope uses in test sources (tests/ paths, .Tests/ directories, *Tests.cs files) and in assemblies whose name ends in Tests (any case) do not count, so a work item passed to the envelope only by a test fixture stays diagnosed. Mutable delivery state, state/status/retry/attempt/lease members (including qualified names such as DeliveryStatus), custom accessors, executable initializers (including literals that invoke a user-defined implicit conversion, or [] of a collection outside the BCL allow-list of arrays, List<T>, HashSet<T>, Dictionary<K,V>, ImmutableArray<T> and their interfaces), GetKey accessors whose returned property needs a user-defined conversion to the key type, methods, and interfaces with default or static behavior remain eligible for diagnostics. Payload types are correlated by full assembly identity, and a source file linked into several projects is exempt only when every compilation sees a passive type, and its declarations are inspected in every owning compilation, so a type that some projects omit through conditional compilation keeps its diagnostics. Only workspace source payloads reached through a project reference are correlated; a binary sharing a source type's identity may be stale and does not exempt it. Only sealed payload types are exempt: an unsealed or abstract payload can be enqueued as a derived type, possibly from another assembly, that this inspection never visits, so declare passive payload records sealed (records are not sealed by default). Virtual or overridable members are never exempt. Files with conditional compilation request host facts because the baseline parse sees no project symbols. Behavior-free marker interfaces do not prevent the exclusion. Snapshot fields such as processing timestamps or failure descriptions do not imply ownership of the envelope's delivery lifecycle. Missing host facts and source-defined framework lookalikes retain conservative classification.