Eternet.Analyzers.Mediator 1.0.27

Eternet.Analyzers.Mediator

Roslyn analyzers for Eternet.Mediator step-boundary rules.

Current diagnostics:

• EAMS001: mediator Handle mixes distinct responsibility groups and should be split into explicit steps or boundaries
• EAMS002: mediator Handle mixes manual side effects with other responsibilities
• EAMS003: mediator Handle mixes background trigger work with other responsibilities
• EAMS004: step delegates workflow to a feature-local service boundary instead of owning the step logic directly
• EAMS005: step name intent does not match the observed responsibility; rename-dominant cases expose a safe rename code fix
• EAMS006: step mixes async lookup with business validation and should split lookup and validation before naming cleanup
• EAMS007: nested mediator dispatch depth exceeds the default threshold and should be flattened into fewer internal boundaries
• EAMS008: a loop repeatedly dispatches the same mediator request type and should move to a generated branch, batch lane, or explicit loop-aware boundary
• EAMS013: a stateful pipeline step uses a replay-unsafe re-execution policy for stale reads or duplicate side effects
• EAMS014: retry, branch, or other control-flow-critical metadata is hidden from the public graph surface
• EAMS015: a step takes the whole request even though it only reads a narrow subset of request members
  • Code fix: for the deterministic single-member case, rewrite Handle(Request request) to consume that request member directly, for example Handle(int nodeTypeId), and replace request.NodeTypeId reads. The fix is not registered when source call sites already invoke the step Handle(...) method directly.
• EAMS016: manual if/switch branch dispatch should become a generated mediator branch
• EAMS017: a pause-capable stateful pipeline is missing the request contract required to resume safely
• EAMS018: a generated pipeline handler uses a local request whose request declaration or required containing type is not partial
  • Code fix: add partial only to the missing local request and containing type declarations in the editable document.
• EAMR001: step handles framework-eligible retry patterns manually
• EAMR002: step exposes retry-policy provider behavior without an active mediator retry policy
• EAMR003: retry scope wraps side-effecting work without idempotency evidence
• EANM001: mutating step resolves related state from a scalar *Id parameter inside Handle
• EANM002: mutating step uses throwing selectors such as Single or First to model expected domain absence inside Handle
• EANM003: mutating step dereferences nullable scalar *.Value to model expected presence inside Handle
• EANM004: mutating step passes a scalar *Id parameter directly into an aggregate mutator instead of passing an already-resolved value
• EANM005: mutating step forces FirstOrDefault/SingleOrDefault to exist with ! or ?? throw instead of handling expected absence explicitly
• EANM006: step-like class injects another step-like class and manually calls its Handle(...) instead of sequencing both through the mediator pipeline
• EANM007: step-like class is registered manually in DI even though generated mediator pipelines register steps automatically
  • Code fix: remove the standalone AddScoped/AddTransient/AddSingleton statement that manually registers the step-like type.
• EANM010: mutating step can deterministically convert throwing expected-absence selectors into explicit invalid-state guards
  • Code fix: change eligible Single/First local lookups to SingleOrDefault/FirstOrDefault, insert an InvalidStateError(...)/InvalidState(...) guard, and add BaseHandlerResponses only when no existing base class would be replaced.
• EANM011: generated pipeline step lives outside the deterministic owner Steps folder or nearest common SharedSteps folder
  • Code fix: move or split the step type into the computed deterministic file path.
• EANM012: generated pipeline entry point lives outside its deterministic owner layout
  • Code fix: move or split the pipeline type to the analyzer TargetPath. When the source already lives under an action-scoped role folder such as Single/Create/Commands/CreateFoo.cs, the command stays flat and owned steps target Single/Create/Commands/Steps. Broader role folders such as Commands/CreateFoo.cs still use the owner-folder layout Commands/CreateFoo/CreateFoo.cs. Relational companion pipelines named <Owner>Relational are owned by the <Owner> layout and can live beside the public command.
  • Metadata: LayoutKind=ActionScopedFlat means the path already scopes the action by token match, for example RegisterApprovedByVendor/Commands/RegisterPortabilityApprovedByVendor.cs; LayoutKind=OwnerFolder means the role folder is broad and needs an owner subfolder.
• EANM013: a generated pipeline step only projects a public request property into a renamed keyed result
  • Code fix: remove the projection step, remove its GenerateExecutePipeline registration, and rebind downstream consumers to the request property keyed input by scalar parameter name. Shared consumers are cloned owner-local instead of being mutated globally.
• EANM014: a step Handle method has a redundant [KeyedResult("T")] attribute when the non-nullable result type is already T
  • Code fix: remove the redundant [KeyedResult] attribute while preserving other attributes on the method. Supports Fix All for document, project, and solution through Roslyn's batch fixer.
• EANM015: a step Handle parameter has a redundant [KeyedParameter("x")] attribute when the key already matches the parameter name case-insensitively
  • Code fix: remove the redundant [KeyedParameter] attribute while preserving other attributes on the parameter. Supports Fix All for document, project, and solution through Roslyn's batch fixer.
• EANM016: a step Handle parameter uses [KeyedParameter("X")] even though the key can become a collision-free implicit parameter name
  • Code fix: rename the parameter to the lower-camel key name and remove [KeyedParameter]. The diagnostic is not reported for non-identifier keys, all-caps acronym keys, parameter collisions, or local-name collisions.
• EAR001: generated mediator pipeline writes through EF Core directly instead of using a relational lane; disabled by default and intended for diff-scoped review runs
• EAR002: generated handler/step injects ISender or IMediator instead of using explicit pipeline steps or an explicit boundary
• EAR003: generated pipeline only wraps handler-like step(s) and has no meaningful validation/load/check/mutation step
• EAR004: mediator handlers or generated-pipeline steps call manual SaveChangesAsync after multiple EF write units or entity types and should be modeled as EntityChangesCommand
• EAR005: store-like infrastructure hides ExecuteUpdateAsync or ExecuteDeleteAsync without explicit relational/bulk/custom/runtime classification; disabled by default
• EAR006: homogeneous bulk workflow is modeled as EntityChangesCommand instead of the matching relational bulk lane
• EAR007: relational business handler performs loading, validation, querying, or persistence inside Handle
• EAR008: relational write uses manual outbox staging instead of domain-event emission plus relational projectors
• EAR009: opt-in test-project diagnostic that flags relational command tests still using legacy PipelineTest-style bases instead of the generated *RequestPipelineTestBase
• EAR010: opt-in test-project diagnostic that flags relational command tests whose pre-send SaveChanges setup can be replaced by generated step overrides
• EAR011: opt-in test-project diagnostic that flags relational command tests which only re-prove generic framework persistence instead of feature-owned behavior
• EAR012: opt-in test-project diagnostic that flags test projects targeting handlers with [GeneratePipelineTestBase] support but without an available generated test base
• EAT001: opt-in test-project diagnostic for SaveChanges() or SaveChangesAsync(...) calls that do not use TestContext.Current.CancellationToken; helper methods are marked review-required when a signature cascade may be needed
• EAT002: opt-in validator registration inventory for AddValidatorsFromAssembly* boundaries in API, contracts, and test fixtures
• EAT003: opt-in detection for local ClearDatabase* helper clones; the recommended action is to use shared cleanup helper packages, not to generate deletion logic here

Inventory diagnostics EMI001, EMI002, EMI003, and EMI004 are metadata-only signals for EAC/review tooling. They are disabled by default and only emit when analyzer config sets eternet_mediator_inventory_enabled = true.

The relational command test modernization family (EAR009-EAR012) is also disabled by default. It only emits for test projects when analyzer config sets eternet_relational_command_test_modernization_enabled = true and the diagnostics are enabled through analyzer severity.

The Mobile test automation family (EAT001-EAT003) is disabled by default. It only emits when analyzer config sets eternet_mobile_test_automation_patterns_enabled = true and the diagnostics are enabled through analyzer severity. FluentAssertions-to-AwesomeAssertions package migration is intentionally not modeled as a semantic analyzer; EAC should own that migration as a transformer plus postflight package/namespace scan.

Mediator pipeline exposure SARIF property catalog

Mediator inventory and quality metadata is emitted as diagnostic properties and flows into SARIF under runs[].results[].properties.customProperties.

Inventory diagnostics

Quality diagnostics

Ownership boundaries

• Eternet.Analyzers.Mediator owns mediator inventory and quality evidence that can be proven from source and analyzer semantics. That includes graph metadata, branch metadata, retry/resume risk metadata, pause-contract metadata, and step-shape quality metadata.
• AlwaysReExecute + StepHasCache remains a companion Eternet.Mediator.Generator.Analyzers ownership boundary in Eternet.AspNetCore. This package intentionally exposes the raw ReExecutionPolicy and StepHasCache inventory properties, but it does not add a duplicate contradiction diagnostic here.
• ParallelFanOutEvidence, NestedDispatchScopeIsolationEvidence, and ChunkShape stay attached to the existing inventory or relational diagnostics that already own the behavior. The package does not mint duplicate diagnostics just to surface those facts.