Compile-Time Safety¶

Deepstaging ships 69 diagnostics across every module. These aren't suggestions — they're a compile-time safety net that catches structural mistakes, contract violations, and missing configuration before your code ever runs.

Every diagnostic listed here fires during dotnet build. Most errors block compilation. Warnings and info-level hints surface in the IDE and build output so nothing slips through quietly.

Structural Correctness¶

Source generators emit partial members on your types. If a type isn't declared correctly, the generator can't attach — and you'd get confusing errors downstream instead of a clear message upfront.

These checks enforce the modifiers that source generation requires:

Most of these have automated code fixes — your IDE will offer a one-click "Add partial modifier" or "Add sealed modifier" action.

Signature Contracts¶

Handlers must follow exact signatures so the generated dispatch, serialization, and DI wiring work correctly. These checks catch signature mismatches at compile time instead of letting them fail silently at runtime:

| HTTP verb method | Path must not be empty | DSHTTP04 | Error |

Referential Integrity¶

When one type references another — a foreign key pointing at an entity, a [Uses] targeting a module, a [ForeignKey<T>] referencing a stored entity — these checks verify the target actually exists and is the right kind:

Bounded Context Boundaries¶

Each assembly represents a bounded context. These checks enforce that boundary at the container level:

If you need multiple data stores or event stores, split them into separate projects. This isn't a limitation — it enforces the DDD principle that each bounded context owns its own persistence.

Secret Safety¶

Configuration properties that look like they hold secrets are flagged automatically, and the toolchain ensures user secrets infrastructure is in place:

Configuration Completeness¶

These checks ensure your configuration layer is fully wired — no orphaned types, no empty sections, no inferrable-name mistakes:

The info-level diagnostics act as discoverability hints — when you add a NuGet package that ships config sections (e.g., Deepstaging.EventStore.Marten), the analyzer tells you the section is available and offers a code fix to wire it in.

Infrastructure Compatibility¶

When you choose a persistence backend, additional analyzers activate to enforce backend-specific requirements:

PostgreSQL / EF Core¶

Without the EF Core value converter, Entity Framework can't map your strongly-typed ID to a database column. This check fires the moment you add a [TypedId] property to a [StoredEntity], and the code fix adds the converter for you.

Marten (Event Store)¶

Marten's default stream identity is Guid. If you use a String-backed [StreamId], Marten requires explicit StreamIdentity.AsString configuration. This warning reminds you to either switch to Guid or add the configuration.

Azure Table Storage¶

Azure Table Storage requires explicit partition and row keys. DSAT04 is informational — it lets you know when a property of a complex type will be automatically serialized to JSON, since Azure Table Storage only natively supports primitives.

Orphan Detection¶

These info-level diagnostics catch declarations that are structurally valid but disconnected — things that compile fine but won't actually do anything:

These won't block your build, but they surface work that's half-done — an entity without a store, an aggregate without an event store, a module that nothing uses.

Abstractions Purity¶

The Deepstaging.Abstractions package (what consumers add to their .csproj) contains only marker attributes and marker interfaces — zero behavior, zero logic, zero reflection. All 89+ files are either:

• Marker attributes with configuration properties (get/init only, no methods)
• Marker interfaces (ICommand, IQuery, ISoftDeletable, etc.)
• Support types (enums like BackingType, records like CursorResult)

All attribute interpretation lives in Deepstaging.Projection (compile-time only, not shipped to consumers). This deliberate split means:

• The consumer-facing NuGet package is tiny and has no transitive dependencies beyond .NET
• Attributes never break at runtime because they contain no behavior to break
• Changing how an attribute is interpreted (in Projection) doesn't require consumers to update their package reference

Summary¶