Status
Accepted (Revised v2, 2026-06-29).
Context
Native AOT delivers fast startup, low memory, and small size, but under .NET 10 it was unproven whether SqlSugar, CAP, Quartz, JsonPatch, and SignalR were fully AOT-safe. Forcing full-service Native AOT in v1 was risky and could force replacing chosen technology.
Decision
Position Native AOT as a design constraint and a phased verification target, not a v1 hard publish gate. Design: prefer source generation, explicit DI registration, minimal reflection; ban startup full-assembly scans and heavy runtime reflection. Core libraries enable IsAotCompatible; the API reaches PublishTrimmed without critical warnings.
The v2 revision escalates trim publish to a hard gate: dotnet publish -p:PublishTrimmed=true is a verify-all step. The SqlSugar adapter, Application, and Domain must produce zero unregistered IL warnings; new reflection code is a P0 merge block. Native AOT full publish remains an independent optional profile, but all new code must be AOT-compatible. Runtime reflection APIs (MakeGenericType, GetMethod, Activator.CreateInstance, Assembly.GetTypes) are forbidden in framework default paths; required reflection (e.g. EF Core model building) must be annotated // AOT-EXEMPT: <reason> with a unit test and registered in the trim-publish-status ledger.
Consequences
The design is pragmatic — not held hostage by unverified AOT assumptions, with no forced replacement of SqlSugar/CAP — while still converging toward AOT. The risk is reflection/dynamic code leaking back in if vigilance relaxes; the AOT/Trim verification checklist and the REQ-GATE-001 reflection scan mitigate this.