chore(docs): apply Codacy markdownlint fixes

.claude/commands/requirements-current.md

@@ -19,6 +19,7 @@ Display detailed information about the active requirement.
    - Indicate current phase and next steps
 
 ## File Structure:
+
 - 00-initial-request.md - Original user request
 - 01-discovery-questions.md - Context discovery questions
 - 02-discovery-answers.md - User's answers
@@ -28,6 +29,7 @@ Display detailed information about the active requirement.
 - 06-requirements-spec.md - Final requirements document
 
 ## Display Format:
+
 ```
 📋 Current Requirement: [name]
 ⏱️  Duration: [time since start]
@@ -67,6 +69,7 @@ Q3: Add new API endpoint to routes/api/v1? [PENDING]
 ```
 
 ## Important:
+
 - This is view-only (doesn't continue gathering)
 - Shows complete history and context
-- Use /requirements-status to continue
+- Use /requirements-status to continue

.claude/commands/requirements-end.md

@@ -23,24 +23,28 @@ Finalize the current requirement gathering session.
 4. Based on choice:
 
 ### Option 1: Generate Spec
+
 - Create 06-requirements-spec.md
 - Include all answered questions
 - Add defaults for unanswered with "ASSUMED:" prefix
 - Generate implementation hints
 - Update metadata status to "complete"
 
 ### Option 2: Mark Incomplete
+
 - Update metadata status to "incomplete"
 - Add "lastUpdated" timestamp
 - Create summary of progress
 - Note what's still needed
 
 ### Option 3: Cancel
+
 - Confirm deletion
 - Remove requirement folder
 - Clear .current-requirement
 
 ## Final Spec Format:
+
 ```markdown
 # Requirements Specification: [Name]
 

.claude/commands/requirements-list.md

@@ -17,6 +17,7 @@ Display all requirements with their status and summaries.
    - Then by date (newest first)
 
 ## Display Format:
+
 ```
 📚 Requirements Documentation
 

.claude/commands/requirements-remind.md

@@ -3,6 +3,7 @@
 Quick correction when deviating from requirements gathering rules.
 
 ## Aliases:
+
 - /requirements-remind
 - /remind  
 - /r
@@ -62,18 +63,23 @@ Please continue with the current question or read the next one from the file.
 ## Common Correction Scenarios:
 
 ### Open-ended question asked:
+
 "Let me rephrase as a yes/no question..."
 
 ### Multiple questions asked:
+
 "Let me ask one question at a time..."
 
 ### Implementation started:
+
 "I apologize. Let me continue with requirements gathering..."
 
 ### No default provided:
+
 "Let me add a default for that question..."
 
 ## Auto-trigger Patterns:
+
 - Detect code blocks → remind no implementation
 - Multiple "?" in response → remind one question
 - Response > 100 words → remind to be concise

.claude/commands/requirements-start.md

@@ -2,9 +2,10 @@
 
 Begin gathering requirements for: $ARGUMENTS
 
-## Full Workflow:
+## Full Workflow
 
 ### Phase 1: Initial Setup & Codebase Analysis
+
 1. Create timestamp-based folder: requirements/YYYY-MM-DD-HHMM-[slug]
 2. Extract slug from $ARGUMENTS (e.g., "add user profile" → "user-profile")
 3. Create initial files:
@@ -18,6 +19,7 @@ Begin gathering requirements for: $ARGUMENTS
    - Note patterns and conventions
 
 ### Phase 2: Context Discovery Questions
+
 6. Generate the five most important yes/no questions to understand the problem space:
    - Questions informed by codebase structure
    - Questions about user interactions and workflows
@@ -30,6 +32,7 @@ Begin gathering requirements for: $ARGUMENTS
    - Only after all questions are asked, record answers in 02-discovery-answers.md as received and update metadata.json. Not before.
 
 ### Phase 3: Targeted Context Gathering (Autonomous)
+
 7. After all discovery questions answered:
    - Use mcp__RepoPrompt__search (if available) to find specific files based on discovery answers
    - Use mcp__RepoPrompt__set_selection and read_selected_files (if available) to batch read relevant code
@@ -44,6 +47,7 @@ Begin gathering requirements for: $ARGUMENTS
      - Integration points identified
 
 ### Phase 4: Expert Requirements Questions
+
 8. Now ask questions like a senior developer who knows the codebase:
    - Write the top 5 most pressing unanswered detailed yes/no questions to 04-detail-questions.md
    - Questions should be as if you were speaking to the product manager who knows nothing of the code
@@ -53,6 +57,7 @@ Begin gathering requirements for: $ARGUMENTS
    - Only after all questions are asked, record answers in 05-detail-answers.md as received
 
 ### Phase 5: Requirements Documentation
+
 9. Generate comprehensive requirements spec in 06-requirements-spec.md:
    - Problem statement and solution overview
    - Functional requirements based on all answers
@@ -61,9 +66,10 @@ Begin gathering requirements for: $ARGUMENTS
    - Acceptance criteria
    - Assumptions for any unanswered questions
 
-## Question Formats:
+## Question Formats
+
+### Discovery Questions (Phase 2)
 
-### Discovery Questions (Phase 2):
 ```
 ## Q1: Will users interact with this feature through a visual interface?
 **Default if unknown:** Yes (most features have some UI component)
@@ -81,7 +87,8 @@ Begin gathering requirements for: $ARGUMENTS
 **Default if unknown:** No (most features require connectivity)
 ```
 
-### Expert Questions (Phase 4):
+### Expert Questions (Phase 4)
+
 ```
 ## Q7: Should we extend the existing UserService at services/UserService.ts?
 **Default if unknown:** Yes (maintains architectural consistency)
@@ -90,7 +97,8 @@ Begin gathering requirements for: $ARGUMENTS
 **Default if unknown:** No (based on similar features not requiring schema changes)
 ```
 
-## Important Rules:
+## Important Rules
+
 - ONLY yes/no questions with smart defaults
 - ONE question at a time
 - Write ALL questions to file BEFORE asking any
@@ -99,7 +107,7 @@ Begin gathering requirements for: $ARGUMENTS
 - Document WHY each default makes sense
 - Use tools available if recommended ones aren't installed or available
 
-## Metadata Structure:
+## Metadata Structure
 ```json
 {
   "id": "feature-slug",
@@ -116,7 +124,8 @@ Begin gathering requirements for: $ARGUMENTS
 }
 ```
 
-## Phase Transitions:
+## Phase Transitions
+
 - After each phase, announce: "Phase complete. Starting [next phase]..."
 - Save all work before moving to next phase
 - User can check progress anytime with /requirements-status

.claude/commands/requirements-status.md

@@ -17,6 +17,7 @@ Show current requirement gathering progress and continue.
    - Continue from last unanswered question
 
 ## Status Display Format:
+
 ```
 📋 Active Requirement: [name]
 Started: [time ago]
@@ -30,6 +31,7 @@ Next Question:
 ```
 
 ## Continuation Flow:
+
 1. Read next unanswered question from file
 2. Present to user with default
 3. Accept yes/no/idk response
@@ -38,5 +40,6 @@ Next Question:
 6. Move to next question or phase
 
 ## Phase Transitions:
+
 - Discovery complete → Run context gathering → Generate detail questions
-- Detail complete → Generate final requirements spec
+- Detail complete → Generate final requirements spec

.claude/docs/project-structure.md

@@ -79,11 +79,13 @@
 ## Roslyn Version Projects
 
 Multi-targeting for Roslyn API compatibility:
+
 - `*.Roslyn414`, `*.Roslyn44`, `*.Roslyn47`
 
 ## Dual-Mode Architecture
 
 Changes to core engine metadata collection must work in both modes:
+
 - **Source-gen**: `TUnit.Core.SourceGenerator` → compile-time
 - **Reflection**: `TUnit.Engine` → runtime
 

.claude/docs/troubleshooting.md

@@ -13,6 +13,7 @@ If changes are unintentional, investigate what modified the source generator out
 ## Tests Pass Locally, Fail in CI
 
 **Common Causes**:
+
 1. Forgot to commit `.verified.txt` files
 2. Line ending differences (CRLF vs LF)
 3. Race conditions in parallel tests
@@ -35,6 +36,7 @@ obj/Debug/net9.0/generated/TUnit.Core.SourceGenerator/
 ```
 
 **Common Issues**:
+
 - Attribute not checked in reflection path
 - Different data expansion logic
 - Missing hook invocation in one mode
@@ -46,6 +48,7 @@ obj/Debug/net9.0/generated/TUnit.Core.SourceGenerator/
 See `mandatory-rules.md` for annotation patterns.
 
 **Common Causes**:
+
 - Reflection without `[DynamicallyAccessedMembers]`
 - Dynamic code generation
 
@@ -60,6 +63,7 @@ dotnet run -c Release
 ```
 
 **Common Causes**:
+
 - Missing reflection cache
 - Allocations in hot paths
 - Blocking on async

.claude/docs/workflows.md

@@ -54,6 +54,7 @@ dotnet run -c Release
 ```
 
 **When to run**:
+
 - Before/after changes to test discovery
 - Before/after changes to test execution
 - Before/after changes to argument expansion

.github/CONTRIBUTING.md

@@ -5,6 +5,7 @@ First off, thanks for taking the time to contribute! ❤️
 All types of contributions are encouraged and valued. See the [Table of Contents](#table-of-contents) for different ways to help and details about how this project handles them. Please make sure to read the relevant section before making your contribution. It will make it a lot easier for us maintainers and smooth out the experience for all involved. The community looks forward to your contributions. 🎉
 
 > And if you like the project, but just don't have time to contribute, that's fine. There are other easy ways to support the project and show your appreciation, which we would also be very happy about:
+>
 > - Star the project
 > - Tweet about it
 > - Refer this project in your project's readme
@@ -96,6 +97,7 @@ Enhancement suggestions are tracked as [GitHub issues](https://github.com/thomhu
 - **Explain why this enhancement would be useful** to most TUnit users. You may also want to point out the other projects that solved it better and which could serve as inspiration.
 
 ### Improving The Documentation
+
 If you think the documentation could be improved, feel free to add to and tweak the docs!
 
 The documentation is generated from files within this repository, so you can fork, clone and create a PR to update the documentation.
@@ -141,25 +143,32 @@ dotnet build -p:EmitCompilerGeneratedFiles=true
 When contributing code to TUnit, please keep these important requirements in mind:
 
 #### Dual-Mode Implementation
+
 TUnit supports both source-generated and reflection-based test discovery. **All changes that affect test discovery or execution must work identically in both modes:**
+
 - Source Generator path: `TUnit.Core.SourceGenerator`
 - Reflection path: `TUnit.Engine`
 
 #### Snapshot Testing
+
 If your changes affect the source generator output or public APIs:
+
 1. Run the relevant tests: `dotnet test TUnit.Core.SourceGenerator.Tests` or `dotnet test TUnit.PublicAPI`
 2. Review any `.received.txt` files generated
 3. If the changes are intentional, rename them to `.verified.txt`
 4. Commit the `.verified.txt` files with your changes
 
 #### Performance Considerations
+
 TUnit is designed to handle millions of tests. When contributing:
+
 - Minimize allocations in hot paths (test discovery, execution)
 - Avoid LINQ in performance-critical code
 - Cache reflection results
 - Use `ValueTask` for potentially-sync operations
 
 #### AOT Compatibility
+
 All code must work with Native AOT and IL trimming. Add appropriate `[DynamicallyAccessedMembers]` annotations when using reflection.
 
 For detailed development guidelines, see the [CLAUDE.md](https://github.com/thomhurst/TUnit/blob/main/CLAUDE.md) file in the repository root.