chore(template): sync with dailydevops/template-dotnet [skip ci]

Author: samtrion

decisions/2025-07-10-centralized-package-version-management.md

@@ -69,7 +69,8 @@ This approach ensures that all projects in the solution use consistent package v
 
 **Description**: Allow each project to manage its own package versions independently.
 
-**Why Not Chosen**: 
+**Why Not Chosen**:
+
 - Leads to version inconsistencies across the solution
 - Increases maintenance overhead
 - Higher risk of dependency conflicts
@@ -80,6 +81,7 @@ This approach ensures that all projects in the solution use consistent package v
 **Description**: Use shared `.props` files to define common package versions but still reference versions in individual projects.
 
 **Why Not Chosen**:
+
 - Still requires version references in each project file
 - More complex to implement and maintain
 - Doesn't leverage MSBuild's built-in central package management features
@@ -90,6 +92,7 @@ This approach ensures that all projects in the solution use consistent package v
 **Description**: Define package versions as MSBuild properties and reference them in individual projects.
 
 **Why Not Chosen**:
+
 - Verbose syntax in project files
 - No built-in tooling support
 - More error-prone than the centralized approach

decisions/2025-07-10-conventional-commits.md

@@ -37,7 +37,8 @@ The project already uses GitVersion (as evidenced by `GitVersion.MsBuild` in `Di
 We will adopt the [Conventional Commits 1.0.0 specification](https://www.conventionalcommits.org/en/v1.0.0/) for all commit messages in this project.
 
 **Commit Message Structure:**
-```
+
+```txt
 <type>[optional scope]: <description>
 
 [optional body]
@@ -46,11 +47,13 @@ We will adopt the [Conventional Commits 1.0.0 specification](https://www.convent
 ```
 
 **Required Types:**
+
 - `feat`: A new feature (correlates with MINOR in Semantic Versioning)
 - `fix`: A bug fix (correlates with PATCH in Semantic Versioning)
 - `BREAKING CHANGE`: Breaking API changes (correlates with MAJOR in Semantic Versioning)
 
 **Recommended Additional Types:**
+
 - `build`: Changes to build system or external dependencies
 - `chore`: Maintenance tasks that don't modify src or test files
 - `ci`: Changes to CI configuration files and scripts
@@ -61,6 +64,7 @@ We will adopt the [Conventional Commits 1.0.0 specification](https://www.convent
 - `test`: Adding or modifying tests
 
 **Implementation Guidelines:**
+
 - Commits MUST be prefixed with a type followed by an optional scope, optional `!`, and required terminal colon and space
 - Breaking changes MUST be indicated either by `!` after the type/scope or by including `BREAKING CHANGE:` in the footer
 - Scope MAY be provided to give additional context (e.g., `feat(api):`, `fix(parser):`)
@@ -70,6 +74,7 @@ We will adopt the [Conventional Commits 1.0.0 specification](https://www.convent
 ## Consequences
 
 **Positive Consequences:**
+
 1. **Automated versioning**: GitVersion and other tools can automatically determine semantic version bumps based on commit types
 2. **Automated changelog generation**: Tools can automatically generate changelogs and release notes from structured commit messages
 3. **Improved communication**: Clear, structured commit messages help team members and stakeholders understand the nature and impact of changes
@@ -78,12 +83,14 @@ We will adopt the [Conventional Commits 1.0.0 specification](https://www.convent
 6. **Enhanced collaboration**: New contributors can quickly understand the commit convention and follow established patterns
 
 **Potential Challenges:**
+
 1. **Learning curve**: Team members need to learn and remember the conventional commit format
 2. **Enforcement overhead**: Initial effort required to establish tooling and processes to enforce the convention
 3. **Commit message length**: Some developers may need to adjust to writing more descriptive commit messages
 4. **Retroactive application**: Existing commit history will not follow the convention, creating inconsistency in historical data
 
 **Risk Mitigation:**
+
 - Implement commit message linting tools to validate format automatically
 - Provide training and documentation for team members
 - Use commit message templates in development environments

decisions/2025-07-10-decision-assets.md

@@ -31,20 +31,23 @@ The current project structure includes a `decisions/` folder for storing archite
 
 All decision-related assets MUST be stored in the `decisions/assets/` folder and MUST be directly linked within decision documents using relative paths.
 
-### Storage Requirements:
+### Storage Requirements
+
 - All assets supporting architectural decisions (diagrams, images, PDFs, etc.) MUST be placed in `decisions/assets/`
 - Asset filenames SHOULD use their original names without requiring any specific naming convention
 - Assets MAY be organized into subdirectories within `decisions/assets/` if needed for better organization
 
-### Linking Requirements:
+### Linking Requirements
+
 - All assets MUST be referenced using relative paths from the decision document
 - Links MUST use the format: `[Asset Description](assets/filename.extension)` for files in the root assets folder
 - For assets in subdirectories, use: `[Asset Description](assets/subdirectory/filename.extension)`
 - Assets MUST be directly embedded or linked within the relevant decision document
 - No external hosting or cloud storage links are permitted for decision assets
 
-### Example Structure:
-```
+### Example Structure
+
+```txt
 decisions/
 ├── 2025-07-10-decision-assets.md
 ├── 2025-07-10-database-architecture.md
@@ -53,7 +56,8 @@ decisions/
     ├── performance-analysis.pdf
 ```
 
-### Example Linking:
+### Example Linking
+
 ```markdown
 The proposed database schema is illustrated in the following diagram:
 
@@ -64,14 +68,16 @@ For detailed performance analysis, refer to the [Performance Analysis Report](as
 
 ## Consequences
 
-### Positive Consequences:
+### Positive Consequences
+
 - **Centralized Asset Management**: All decision-related assets are stored in a single, predictable location
 - **Version Control**: Assets are version-controlled alongside the decision documents
 - **Accessibility**: Assets remain accessible even when working offline or in different environments
 - **Maintenance**: Easier to maintain and update assets as they're co-located with decisions
 - **Documentation Integrity**: Direct linking ensures assets and decisions remain connected
 
-### Potential Risks:
+### Potential Risks
+
 - **Repository Size**: Large assets may increase repository size, though this is manageable with proper asset optimization
 - **Binary File Management**: Git may not handle large binary files efficiently, but this can be mitigated with Git LFS if needed
 - **Asset Duplication**: Same assets might be referenced by multiple decisions, though this ensures each decision remains self-contained

decisions/2025-07-10-dependabot-automated-dependency-updates.md

@@ -91,7 +91,8 @@ We have implemented Dependabot with the following configuration:
 
 **Description**: Manually monitor and update dependencies on a periodic basis.
 
-**Why Not Chosen**: 
+**Why Not Chosen**:
+
 - Time-consuming and error-prone
 - Inconsistent update frequency
 - Higher risk of missing critical security updates
@@ -102,6 +103,7 @@ We have implemented Dependabot with the following configuration:
 **Description**: Use tools that scan for vulnerabilities but don't automatically create updates.
 
 **Why Not Chosen**:
+
 - Provides visibility but still requires manual update process
 - Doesn't address the maintenance overhead of dependency updates
 - May lead to delayed responses to security issues
@@ -111,6 +113,7 @@ We have implemented Dependabot with the following configuration:
 **Description**: Configure Dependabot to run less frequently.
 
 **Why Not Chosen**:
+
 - Slower response to security vulnerabilities
 - Larger batch updates are more complex to review
 - May accumulate breaking changes over time
@@ -120,6 +123,7 @@ We have implemented Dependabot with the following configuration:
 **Description**: Use tools like WhiteSource, or Snyk for dependency management.
 
 **Why Not Chosen**:
+
 - Dependabot is native to GitHub and integrates seamlessly
 - No additional third-party service dependencies
 - Simpler configuration and maintenance

decisions/2025-07-10-folder-structure-and-naming-conventions.md

@@ -23,13 +23,15 @@ This decision establishes the standard folder structure for .NET projects and de
 ## Context
 
 As .NET projects grow in complexity, maintaining a clear and consistent folder structure becomes crucial for:
+
 - Developer onboarding and navigation
 - Build automation and CI/CD pipelines
 - Separation of concerns between production and test code
 - Test categorization and execution strategies
 - IDE and tooling support
 
 Without standardized conventions, teams may adopt inconsistent patterns that lead to:
+
 - Confusion about where to place new code
 - Difficulty in setting up automated test execution
 - Unclear distinction between different types of tests
@@ -40,7 +42,8 @@ Without standardized conventions, teams may adopt inconsistent patterns that lea
 We will adopt the following folder structure and naming conventions:
 
 ### Root Folder Structure
-```
+
+```txt
 /
 ├── src/           # All production source code
 ├── tests/         # All test projects
@@ -50,26 +53,32 @@ We will adopt the following folder structure and naming conventions:
 ```
 
 ### Source Code Organization
+
 - All production code MUST be placed under the `src/` folder
 - Project folders under `src/` MUST follow the namespace hierarchy
 - Each project MUST have its own folder directly under `src/`
 - The `SpixSpreed.` prefix is automatically applied to all projects through build automation in `Directory.Build.targets`
 
 ### Test Project Naming Conventions
+
 Test projects MUST follow this naming pattern:
+
 - **Unit Tests**: `{ProjectName}.Tests.Unit`
 - **Integration Tests**: `{ProjectName}.Tests.Integration`
 
 Where `{ProjectName}` is the name of the production project being tested (the build system will automatically apply the `SpixSpreed.` prefix).
 
 ### Project Naming Convention
+
 Project folder names follow a simple `{ComponentName}` pattern, where:
+
 - `{ComponentName}` describes the functional area or component (e.g., Core, Data, Api, Web)
 - The `SpixSpreed.` prefix is automatically applied by the build system through `Directory.Build.targets`
 - This ensures consistent assembly names, namespaces, and package IDs without manual prefixing
 
 ### Examples
-```
+
+```txt
 src/
 ├── Api/                     # Web API controllers, middleware, and HTTP-related logic
 ├── Core/                    # Domain models, business logic, interfaces, and shared utilities
@@ -87,6 +96,7 @@ tests/
 ## Consequences
 
 ### Positive Consequences
+
 - **Clear Separation**: Distinct separation between production and test code prevents accidental inclusion of test code in production builds
 - **Consistent Navigation**: Developers can quickly locate source code and corresponding tests
 - **Test Categorization**: Clear distinction between unit and integration tests enables selective test execution
@@ -95,6 +105,7 @@ tests/
 - **Scalability**: Structure scales well as projects grow in size and complexity
 
 ### Potential Drawbacks
+
 - **Initial Setup**: Requires discipline to maintain the structure, especially in the early stages of a project
 - **Migration Effort**: Existing projects may need restructuring to adopt these conventions
 - **Tool Configuration**: Some tools may need configuration updates to work with the new structure
@@ -103,7 +114,7 @@ tests/
 
 ### Alternative 1: Flat Structure
 
-```
+```txt
 /
 ├── ProjectA/
 ├── ProjectA.Tests/
@@ -115,7 +126,7 @@ tests/
 
 ### Alternative 2: Tests Alongside Source
 
-```
+```txt
 src/
 ├── ProjectA/
 │   ├── ProjectA.csproj

decisions/2025-07-10-gitversion-automated-semantic-versioning.md

@@ -37,6 +37,7 @@ The project currently uses .NET 10 with centralized package management and follo
 We will use **GitVersion** as the primary tool for automated semantic versioning with the following configuration:
 
 **GitVersion Configuration (`GitVersion.yml`):**
+
 ```yaml
 mode: ManualDeployment
 major-version-bump-message: "^(build|chore|ci|docs|feat|fix|perf|refactor|revert|style|test)(\\([\\w\\s-,/\\\\]*\\))?(!:|:.*\\n\\n((.+\\n)+\\n)?BREAKING CHANGE:\\s.+)"
@@ -46,25 +47,29 @@ workflow: TrunkBased/preview1
 ```
 
 **Implementation Details:**
+
 - **Mode**: `ManualDeployment` - Provides full control over when versions are incremented and tagged
 - **Workflow**: `TrunkBased/preview1` - Optimized for trunk-based development with feature previews
 - **MSBuild Integration**: `GitVersion.MsBuild` package automatically injects version information into all projects during build
 - **Conventional Commits Integration**: Version bump rules are configured to parse conventional commit messages and determine appropriate semantic version increments
 - **Target Framework Workaround**: Temporary configuration to use `net9.0` for GitVersion processing until full .NET 10 support is available
 
 **Version Increment Rules:**
+
 - **Major Version**: Triggered by breaking changes (commits with `!` or `BREAKING CHANGE:` footer)
 - **Minor Version**: Triggered by `feat:` commits (new features)
 - **Patch Version**: Triggered by `fix:`, `build:`, `chore:`, `ci:`, `docs:`, `perf:`, `refactor:`, `revert:`, `style:`, `test:` commits
 
 **MSBuild Integration:**
+
 - GitVersion.MsBuild automatically provides version properties to all projects
 - Version information is embedded in assemblies, packages, and other artifacts
 - No manual version management required in project files
 
 ## Consequences
 
 **Positive Consequences:**
+
 1. **Automated version calculation**: Version numbers are automatically calculated from git history and conventional commit messages, eliminating manual version management
 2. **Consistent versioning**: All project artifacts automatically use the same calculated version, ensuring consistency across builds and deployments
 3. **CI/CD integration**: Build pipelines can reliably access version information for package creation, tagging, and deployment processes
@@ -74,13 +79,15 @@ workflow: TrunkBased/preview1
 7. **Audit trail**: Version increments are directly traceable to specific commits and their semantic meaning
 
 **Potential Challenges:**
+
 1. **Learning curve**: Developers need to understand how conventional commits impact version calculation
 2. **Commit message discipline**: Incorrect commit message formats can lead to inappropriate version increments
 3. **Build complexity**: Additional dependency in the build process that requires understanding for troubleshooting
 4. **Preview versions**: Pre-release and preview version handling requires careful configuration and understanding
 5. **Rollback scenarios**: Complex version rollback situations may require manual intervention
 
 **Risk Mitigation:**
+
 - Implement commit message validation to ensure proper conventional commit format
 - Provide clear documentation and training on conventional commits and their version impact
 - Configure appropriate branch and tag patterns for different deployment scenarios