dotnet-architecturelisted

# .NET Architecture Preserve useful dependency boundaries while minimizing ceremony. Treat architecture as a set of testable ownership and dependency decisions, not a required folder diagram or package list. ## Establish The Existing Contract 1. Read repository instructions, architecture decisions, solution/project files, shared MSBuild configuration, composition roots, representative features, and tests. 2. Map project references and important package dependencies. Identify which code owns business policy, application orchestration, delivery contracts, persistence, and external integrations. 3. Trace one comparable feature end to end before proposing a new pattern. 4. State whether the task preserves the existing architecture, repairs a violation, or deliberately changes the model. Do not smuggle an architectural migration into an ordinary feature. For an architecture assessment or redesign, read [references/architecture-selection.md](references/architecture-selection.md). For an implementation or review that crosses boundaries, read [references/feature-change-map.md](references/feature-change-map.md). For dependency and test enforcement, read [references/architecture-enforcement.md](references/architecture-enforcement.md). ## Choose The Smallest Honest Boundary Model - Keep a single project with feature folders when compile-time separation would cost more than it protects. Use projects or modules when independent compilation, dependency enforcement, ownersh