mpaulosky · mpaulosky · Jul 5, 2026 · Jul 5, 2026 · Jul 5, 2026 · Jul 5, 2026
diff --git a/.config/dotnet-tools.json b/.config/dotnet-tools.json
@@ -3,7 +3,7 @@
   "isRoot": true,
   "tools": {
     "gitversion.tool": {
-      "version": "6.7.0",
+      "version": "6.8.1",
       "commands": [
         "dotnet-gitversion"
       ]

diff --git a/.github/dependabot.yml b/.github/dependabot.yml
@@ -6,7 +6,7 @@
 
 version: 2
 updates:
-  
+
   # Maintain dependencies for GitHub Actions
   - package-ecosystem: "github-actions"
     directory: "/"
@@ -23,7 +23,7 @@
      - "mpaulosky"
    groups:
      all-actions:
        patterns: [ "*" ]

  # Maintain dependencies for nuget
  - package-ecosystem: "nuget"
@@ -45,7 +45,7 @@
        versions: ["[4,)"]
    groups:
      all-actions:
        patterns: [ "*" ]

  # Maintain DotNet Sdk
  - package-ecosystem: "dotnet-sdk"
@@ -63,4 +63,4 @@
      - "mpaulosky"
    groups:
      all-actions:
        patterns: [ "*" ]
@@ -36,9 +36,11 @@ These instructions define the required coding, architecture, and project rules f
 - **Use .editorconfig:** `true`
 - **Preferred Modifier Order:** `public`, `private`, `protected`, `internal`, `static`, `readonly`, `const`
   - _Example:_
+
     ```csharp
     public static readonly int MY_CONST = 42;
     ```
+
 - **Use Explicit Type:** `true` (except where `var` improves clarity)
 - **Use Var:** `true` (when the type is obvious)
 - **Prefer Null Check:**

@@ -6,7 +6,7 @@ This document defines the required conventions and best practices for writing Gi
 
 All commit messages **must** follow this structure:
 
-```
+```text
 <type>(<scope>): <short summary>
 
 <body>
@@ -46,21 +46,21 @@ The scope should be the name of the affected project, folder, or feature (e.g.,
 
 ## Examples
 
-```
+```text
 feat(Web): add user authentication with Auth0
 
 Implements login and logout functionality using Auth0.
 Updates navigation bar to show user info when authenticated.
 Fixes #42
 ```
 
-```
+```text
 fix(Mongo): handle null reference in BlogRepository
 
 Adds null checks to prevent exceptions when querying missing documents.
 ```
 
-```
+```text
 docs(CONTRIBUTING): update testing section for Playwright
 
 Adds Playwright usage instructions and links to documentation.
@@ -71,4 +71,4 @@ Adds Playwright usage instructions and links to documentation.
 - Group related changes in a single commit.
 - Separate unrelated changes into different commits.
 - Use English for all commit messages.
-- Reference issues and pull requests when relevant.
+- Reference issues and pull requests when relevant.
@@ -23,7 +23,7 @@ Follow these guidelines for formatting and structuring your markdown content:
 
 - **Headings**: Use `##` for H2 and `###` for H3. Ensure that headings are used in a hierarchical manner. Recommend restructuring if content includes H4, and more strongly recommend for H5.
 - **Lists**: Use `-` for bullet points and `1.` for numbered lists. Indent nested lists with two spaces.
-- **Code Blocks**: Use triple backticks (`) to create fenced code blocks. Specify the language after the opening backticks for syntax highlighting (e.g., `csharp).
+- **Code Blocks**: Use triple backticks (`) to create fenced code blocks. Specify the language after the opening backticks for syntax highlighting (e.g.,`csharp).
 - **Links**: Use `[link text](URL)` for links. Ensure that the link text is descriptive and the URL is valid.
 - **Images**: Use `![alt text](image URL)` for images. Include a brief description of the image in the alt text.
 - **Tables**: Use `|` to create tables. Ensure that columns are properly aligned and headers are included.

@@ -6,9 +6,11 @@ description: 'Instructions for customizing GitHub Copilot behavior for MONGODB D
 # MongoDB DBA Chat Mode Instructions
 
 ## Purpose
+
 These instructions guide GitHub Copilot to provide expert assistance for MongoDB Database Administrator (DBA) tasks when the mongodb-dba.agent.md chat mode is active.
 
 ## Guidelines
+
 - Always recommend installing and enabling the MongoDB for VS Code extension for full database management capabilities.
 - Focus on database administration tasks: Cluster and Replica Set Management, Database and Collection Creation, Backup/Restore (mongodump/mongorestore), Performance Tuning (indexes, profiling), Security (authentication, roles, TLS), Upgrades and Compatibility with MongoDB 7.x+
 - Use official MongoDB documentation links for reference and troubleshooting.
@@ -17,9 +19,11 @@ These instructions guide GitHub Copilot to provide expert assistance for MongoDB
 - Encourage secure, auditable, and performance-oriented solutions (e.g., enable auditing, use SCRAM-SHA authentication).
 
 ## Example Behaviors
+
 - When asked about connecting to a MongoDB cluster, provide steps using the recommended VS Code extension or MongoDB Compass.
 - For performance or security questions, reference official MongoDB best practices (e.g., index strategies, role-based access control).
 - If a feature is deprecated in MongoDB 7.x+, warn the user and suggest alternatives (e.g., ensureIndex → createIndexes).
 
 ## Testing
+
 - Test this chat mode with Copilot to ensure responses align with these instructions and provide actionable, accurate MongoDB DBA guidance.
@@ -10,39 +10,45 @@ agent: agent
 ## Instructions
 
 1. **Locate Solution File**
-  - Check for `*.slnx` file in current directory
-  - If found, continue to next step
-  - If not found, run: `cd ..` and check again
-  - Repeat until `*.slnx` file is found
-
-2. **Restore Dependencies**
-  - Run: `dotnet restore`
-
-3. **Build Solution**
-  - Run: `dotnet build --no-restore`
-  - Capture all build output, including errors and warnings.
-
-4. **Error & Warning Resolution**
-  - For each error or warning in the build output:
-    - Identify the affected file and line number.
-    - Research the error/warning code and message.
-    - Apply the recommended fix to the codebase.
-    - Rebuild the solution to verify the fix.
-    - Repeat until the build completes with zero errors and warnings.
-
-5. **Verification**
-  - Ensure the final build output shows “Build succeeded” and no warnings.
-  - Document any changes made to resolve issues.
-
-6. **Testing**
-  - Run unit tests to ensure the solution works as expected.
-  - If tests fail, identify and fix the issues in the codebase.
-  - Rebuild and retest until all tests pass.  
-
-7. **Documentation**
-  - Create a `build-log.txt` file in the solution directory.
-  - Log all build outputs, error resolutions, and changes made.
 
+- Check for `*.slnx` file in current directory
+- If found, continue to next step
+- If not found, run: `cd ..` and check again
+- Repeat until `*.slnx` file is found
+
+1. **Restore Dependencies**
+
+- Run: `dotnet restore`
+
+1. **Build Solution**
+
+- Run: `dotnet build --no-restore`
+- Capture all build output, including errors and warnings.
+
+1. **Error & Warning Resolution**
+
+- For each error or warning in the build output:
+  - Identify the affected file and line number.
+  - Research the error/warning code and message.
+  - Apply the recommended fix to the codebase.
+  - Rebuild the solution to verify the fix.
+  - Repeat until the build completes with zero errors and warnings.
+
+1. **Verification**
+
+- Ensure the final build output shows “Build succeeded” and no warnings.
+- Document any changes made to resolve issues.
+
+1. **Testing**
+
+- Run unit tests to ensure the solution works as expected.
+- If tests fail, identify and fix the issues in the codebase.
+- Rebuild and retest until all tests pass.  
+
+1. **Documentation**
+
+- Create a `build-log.txt` file in the solution directory.
+- Log all build outputs, error resolutions, and changes made.
 
 ## Notes
 

@@ -28,7 +28,6 @@ This plan details how to review and update copyright headers in C# files, suppor
 
 ```
 
-
 **Steps:**
 
 1. Identify all target `.cs` files, excluding those in `bin/` and `obj/` folders.

@@ -13,13 +13,15 @@ README files you write are appealing, informative, and easy to read.
 1. Take a deep breath, and review the entire project and workspace, then create a comprehensive and well-structured
    README.md file for the project.
 2. Take inspiration from these readme files for the structure, tone and content:
-  - https://raw.githubusercontent.com/Azure-Samples/serverless-chat-langchainjs/refs/heads/main/README.md
-  - https://raw.githubusercontent.com/Azure-Samples/serverless-recipes-javascript/refs/heads/main/README.md
-  - https://raw.githubusercontent.com/sinedied/run-on-output/refs/heads/main/README.md
-  - https://raw.githubusercontent.com/sinedied/smoke/refs/heads/main/README.md
-3. Do not overuse emojis, and keep the readme concise and to the point.
-4. Do not include sections like "LICENSE", "CONTRIBUTING", "CHANGELOG", etc. There are dedicated files for those
+
+- https://raw.githubusercontent.com/Azure-Samples/serverless-chat-langchainjs/refs/heads/main/README.md
+- https://raw.githubusercontent.com/Azure-Samples/serverless-recipes-javascript/refs/heads/main/README.md
+- https://raw.githubusercontent.com/sinedied/run-on-output/refs/heads/main/README.md
+- https://raw.githubusercontent.com/sinedied/smoke/refs/heads/main/README.md
+
+1. Do not overuse emojis, and keep the readme concise and to the point.
+2. Do not include sections like "LICENSE", "CONTRIBUTING", "CHANGELOG", etc. There are dedicated files for those
    sections.
-5. Use GFM (GitHub Flavored Markdown) for formatting, and GitHub admonition
+3. Use GFM (GitHub Flavored Markdown) for formatting, and GitHub admonition
    syntax (https://github.com/orgs/community/discussions/16925) where appropriate.
-6. If you find a logo or icon for the project, use it in the readme's header.
+4. If you find a logo or icon for the project, use it in the readme's header.
@@ -6,7 +6,8 @@ mode: 'agent'
 
 ## 📜 MISSION
 
-You are an **EditorConfig Expert**. Your mission is to create a robust, comprehensive, and best-practice-oriented `.editorconfig` file. You will analyze the user's project structure and explicit requirements to generate a configuration that ensures consistent coding styles across different editors and IDEs. You must operate with absolute precision and provide clear, rule-by-rule explanations for your configuration choices.
+You are an **EditorConfig Expert**. Your mission is to create a robust, comprehensive, and best-practice-oriented `.editorconfig` file. You will analyze the user's project structure and explicit requirements to generate a configuration that ensures consistent coding styles across different editors and IDEs. You must operate with absolute precision and provide clear, rule-by-rule explanations for
+your configuration choices.
 
 ## 📝 DIRECTIVES
 
@@ -28,7 +29,7 @@ You are an **EditorConfig Expert**. Your mission is to create a robust, comprehe
 
 Begin by acknowledging the user's preferences. Then, proceed directly to generating the `.editorconfig` file and the detailed explanation as per the specified output format.
 
-### Example Output Structure:
+### Example Output Structure
 
 Here is the `.editorconfig` file tailored to your project:
 
@@ -61,4 +62,4 @@ trim_trailing_whitespace = false
 - `trim_trailing_whitespace = true`: This automatically removes any whitespace characters at the end of lines, which keeps the code clean and avoids unnecessary diffs in version control.
 - `insert_final_newline = true`: This ensures that every file ends with a single newline character, a POSIX standard that prevents certain scripting and concatenation issues.
 - `[*.md]`: This glob pattern applies specific rules only to Markdown files.
-- `trim_trailing_whitespace = false`: This overrides the universal setting for Markdown files. It's disabled because trailing whitespace can be significant in Markdown (e.g., for creating hard line breaks).
+- `trim_trailing_whitespace = false`: This overrides the universal setting for Markdown files. It's disabled because trailing whitespace can be significant in Markdown (e.g., for creating hard line breaks).
@@ -8,6 +8,7 @@ agent: agent
 You are a PR implementation plan generator that creates complete, copy-paste ready implementation documentation.
 
 Your SOLE responsibility is to:
+
 1. Accept a complete PR plan (plan.md in plans/{feature-name}/)
 2. Extract all implementation steps from the plan
 3. Generate comprehensive step documentation with complete code
@@ -31,6 +32,7 @@ Follow the <workflow> below to generate and save implementation files for each s
 Output the plan as a COMPLETE markdown document using the <plan_template>, ready to be saved as a `.md` file.
 
 The plan MUST include:
+
 - Complete, copy-paste ready code blocks with ZERO modifications needed
 - Exact file paths appropriate to the project structure
 - Markdown checkboxes for EVERY action item
@@ -77,18 +79,22 @@ Return a comprehensive research package covering the entire project context.
 </research_task>
 
 <plan_template>
+
 # {FEATURE_NAME}
 
 ## Goal
+
 {One sentence describing exactly what this implementation accomplishes}
 
 ## Prerequisites
+
 Make sure that the use is currently on the `{feature-name}` branch before beginning implementation.
 If not, move them to the correct branch. If the branch does not exist, create it from main.
 
 ### Step-by-Step Instructions
 
 #### Step 1: {Action}
+
 - [ ] {Specific instruction 1}
 - [ ] Copy and paste code below into `{file}`:
 
@@ -104,13 +110,16 @@ If not, move them to the correct branch. If the branch does not exist, create it
 ```
 
 ##### Step 1 Verification Checklist
+
 - [ ] No build errors
 - [ ] Specific instructions for UI verification (if applicable)
 
 #### Step 1 STOP & COMMIT
+
 **STOP & COMMIT:** Agent must stop here and wait for the user to test, stage, and commit the change.
 
 #### Step 2: {Action}
+
 - [ ] {Specific Instruction 1}
 - [ ] Copy and paste code below into `{file}`:
 
@@ -119,9 +128,11 @@ If not, move them to the correct branch. If the branch does not exist, create it
 ```
 
 ##### Step 2 Verification Checklist
+
 - [ ] No build errors
 - [ ] Specific instructions for UI verification (if applicable)
 
 #### Step 2 STOP & COMMIT
+
 **STOP & COMMIT:** Agent must stop here and wait for the user to test, stage, and commit the change.
 </plan_template>
@@ -32,9 +32,9 @@ Analyze the user's request and break it down into commits:
 
 1. Generate draft plan using <output_template> with `[NEEDS CLARIFICATION]` markers where the user's input is needed.
 2. Save the plan to "plans/{feature-name}/plan.md"
-4. Ask clarifying questions for any `[NEEDS CLARIFICATION]` sections
-5. MANDATORY: Pause for feedback
-6. If feedback received, revise plan and go back to Step 1 for any research needed
+3. Ask clarifying questions for any `[NEEDS CLARIFICATION]` sections
+4. MANDATORY: Pause for feedback
+5. If feedback received, revise plan and go back to Step 1 for any research needed
 
 </workflow>
 
@@ -65,6 +65,7 @@ Analyze the user's request and break it down into commits:
 ### Step 3: {Step Name}
 ...
 ```
+
 </output_template>
 
 <research_guide>

@@ -20,7 +20,7 @@ Structured Autonomy is a three-phase workflow designed to maximize the value you
 
 ### The Workflow
 
-```
+```text
 ┌─────────────────┐     ┌─────────────────┐     ┌─────────────────┐
 │    sa-plan      │ ──▶ │   sa-generate   │ ──▶ │   sa-implement  │
 │  (1 request)    │     │   (1 request)   │     │  (many requests)│
@@ -30,20 +30,19 @@ Structured Autonomy is a three-phase workflow designed to maximize the value you
 
 **Phase 1: Plan** — You describe what you want to build. The planning agent researches your codebase, reads documentation, and breaks your feature into logical commits. Output: `plans/{feature-name}/plan.md`
 
-
-```
+```text
 /plan Add a user profile page to this application that allows the user to view and edit their profile information. 
 ```
 
 **Phase 2: Generate** — The generator takes your plan and produces complete, copy-paste ready implementation instructions with full code blocks. No placeholders, no TODOs—just working code based on your actual codebase patterns. Output: `plans/{feature-name}/implementation.md`
 
-```
+```text
 /generate #plan.md
 ```
 
 **Phase 3: Implement** — The implementation agent follows the generated instructions step-by-step, checking off items as it goes and stopping at defined commit boundaries for you to verify and commit.
 
-```
+```text
 /implement #implementation.md
 ```
 
@@ -66,5 +65,3 @@ Each workflow operates on a single feature branch targeting a single pull reques
 **Developer Engagement** — The step-by-step implementation with manual commit points keeps you in the loop. You're reviewing and testing real changes at each step, not staring at a massive diff at the end wondering what happened.
 
 **Familiar Workflow** — This isn't a new way of working—it's your existing git workflow with AI assistance. Feature branches, incremental commits, PR reviews. The AI handles the tedious parts while you stay in control of the process.
-
-
@@ -28,6 +28,7 @@ idiomatic patterns, and reusable fixtures.
 
 - Use the .NET SDK test project format and target the same framework as the main app (e.g., `net7.0`).
 - Recommended package references:
+
   ```xml
   <ItemGroup>
     <PackageReference Include="Microsoft.AspNetCore.Mvc.Testing" Version="*" />
@@ -305,12 +306,14 @@ Project setup (packages & templates)
 - Use DotNet.Testcontainers to run a real Postgres (or other) container per suite and a unique database name per
   factory/test to isolate state.
 
+``````yaml
 name: Integration Tests
 
 on:
 workflow_dispatch:
 push:
 paths:
+
 - 'tests/Web.Tests.Integration/**'
 - '.github/workflows/integration-tests.yml'
 
@@ -320,6 +323,7 @@ runs-on: ubuntu-latest
 env:
 DOTNET_CLI_TELEMETRY_OPTOUT: '1'
 steps:
+
 - name: Checkout repo
 uses: actions/checkout@v4
Original file line number	Diff line number	Diff line change
Expand Up		@@ -28,7 +28,6 @@ This plan details how to review and update copyright headers in C# files, suppor

		```


		Steps:

		1. Identify all target `.cs` files, excluding those in `bin/` and `obj/` folders.
Expand Down