[RELEASE] Sprint 19 — Polish, Markdown Editor & Categories

.copilot/mcp-config.json

@@ -4,7 +4,7 @@
       "command": "npx",
       "args": [
         "-y",
-        "@anthropic/github-mcp-server"
+        "@modelcontextprotocol/server-github"
       ],
       "env": {
         "GITHUB_TOKEN": "${GITHUB_TOKEN}"

.editorconfig

@@ -401,4 +401,11 @@ dotnet_naming_style.camelcase.capitalization = camel_case
 dotnet_naming_style.s_camelcase.required_prefix = s_
 dotnet_naming_style.s_camelcase.required_suffix =
 dotnet_naming_style.s_camelcase.word_separator =
-dotnet_naming_style.s_camelcase.capitalization = camel_case
+dotnet_naming_style.s_camelcase.capitalization = camel_case
+
+[tests/**/*.cs]
+# Tests intentionally use xUnit-style method names with underscores.
+dotnet_diagnostic.CA1707.severity = none
+# Test code deliberately exercises sync validators and uses xUnit-created fixtures.
+dotnet_diagnostic.CA1849.severity = none
+dotnet_diagnostic.CA1515.severity = none

.gitattributes

@@ -3,3 +3,9 @@
 .squad/agents/*/history.md merge=union
 .squad/log/** merge=union
 .squad/orchestration-log/** merge=union
+
+# Line ending normalization — keep LF everywhere to match dotnet format expectations
+* text=auto eol=lf
+*.sh text eol=lf
+.github/hooks/* text eol=lf
+*.cs text eol=lf

.github/copilot-instructions.md

@@ -1,52 +1,94 @@
-# Copilot Coding Agent — Squad Instructions
+# Copilot Coding Agent Instructions
 
-You are working on a project that uses **Squad**, an AI team framework. When picking up issues autonomously, follow these guidelines.
+This repository uses **Squad** for orchestration and follows project-level .NET conventions.
 
-## Team Context
+## Squad Workflow (Required)
 
 Before starting work on any issue:
 
-1. Read `.squad/team.md` for the team roster, member roles, and your capability profile.
-2. Read `.squad/routing.md` for work routing rules.
-3. If the issue has a `squad:{member}` label, read that member's charter at `.squad/agents/{member}/charter.md` to understand their domain expertise and coding style — work in their voice.
+1. Read `.squad/team.md` for the roster, roles, and capability profile.
+2. Read `.squad/routing.md` for routing rules.
+3. If the issue has a `squad:{member}` label, read `.squad/agents/{member}/charter.md` and work in that role's style.
 
-## Capability Self-Check
+### Capability Self-Check
 
-Before starting work, check your capability profile in `.squad/team.md` under the **Coding Agent → Capabilities** section.
+Check `.squad/team.md` under **Coding Agent → Capabilities**:
 
 - **🟢 Good fit** — proceed autonomously.
-- **🟡 Needs review** — proceed, but note in the PR description that a squad member should review.
-- **🔴 Not suitable** — do NOT start work. Instead, comment on the issue:
+- **🟡 Needs review** — proceed, and add reviewer guidance in the PR body.
+- **🔴 Not suitable** — do not implement; comment on the issue:
 
   ```
   🤖 This issue doesn't match my capability profile (reason: {why}). Suggesting reassignment to a squad member.
   ```
 
-## Branch Naming
+### Branch Naming
 
-Use the squad branch convention:
+Use:
 
 ```
 squad/{issue-number}-{kebab-case-slug}
 ```
 
 Example: `squad/42-fix-login-validation`
 
-## PR Guidelines
-
-When opening a PR:
+### Pull Request Requirements
 
 - Reference the issue: `Closes #{issue-number}`
-- If the issue had a `squad:{member}` label, mention the member: `Working as {member} ({role})`
-- If this is a 🟡 needs-review task, add to the PR description: `⚠️ This task was flagged as "needs review" — please have a squad member review before merging.`
-- Follow any project conventions in `.squad/decisions.md`
+- If labeled `squad:{member}`, include: `Working as {member} ({role})`
+- For 🟡 tasks, include: `⚠️ This task was flagged as "needs review" — please have a squad member review before merging.`
+- Follow decisions in `.squad/decisions.md`
 
-## Decisions
+### Team Decision Drop Box
 
-If you make a decision that affects other team members, write it to:
+If your work introduces a team-relevant decision, write it to:
 
 ```
 .squad/decisions/inbox/copilot-{brief-slug}.md
 ```
 
-The Scribe will merge it into the shared decisions file.
+Scribe will merge inbox entries into `.squad/decisions.md`.
+
+## Project Engineering Conventions
+
+### Platform
+
+- Target .NET 10 (`net10.0`) and latest stable patch SDK/runtime
+- Use C# 14 language features where they improve clarity
+
+### C# and Solution Style
+
+- Respect `.editorconfig` and existing repository formatting
+- Use explicit types when helpful; use `var` when type is obvious
+- Prefer null checks with `is null` / `is not null`
+- Use file-scoped namespaces, nullable reference types, and pattern matching
+- Keep naming conventions consistent (`I*` interfaces, `Async` suffix, `_privateField`)
+
+### Architecture
+
+- Keep dependency injection and strongly typed options/configuration
+- Prefer async/await end-to-end in app code and tests
+- Maintain vertical-slice/CQRS patterns where they already exist
+- Keep package versions centralized in `Directory.Packages.props`
+
+### Security and Middleware
+
+- Keep HTTPS, authentication, authorization, antiforgery, and secure headers enabled
+- Preserve global exception handling and request logging patterns
+
+### Blazor and Web UI
+
+- Maintain existing component lifecycle/state-management patterns
+- Keep interactive rendering strategy and shared component conventions
+- Preserve error boundary patterns and existing UI composition style
+
+### Data and Testing
+
+- Keep MongoDB + EF Core integration patterns used in this repo
+- Prefer async data access
+- Keep unit, integration, architecture, and UI tests current with behavior changes
+
+### Documentation
+
+- Keep README/CONTRIBUTING and inline documentation aligned with behavioral changes
+- Use OpenAPI + Scalar conventions for HTTP API documentation where applicable

.github/dependabot.yml

@@ -6,7 +6,7 @@
 
 version: 2
 updates:
-  
+
   # Maintain dependencies for GitHub Actions
   - package-ecosystem: "github-actions"
     directory: "/"

.github/hooks/pre-push

@@ -1,7 +1,9 @@
 #!/usr/bin/env bash
 # Pre-push gate: mirrors CI checks to catch failures before they reach GitHub
-# Runs: branch protection → untracked-file check → Release build → unit/architecture tests → integration tests
+# Runs: branch protection → untracked-file check → markdownlint → dotnet format → Release build → unit/architecture tests → integration tests
 # NOTE: git provides refspecs on stdin; interactive prompts must use /dev/tty.
+# ⚠️  BYPASS POLICY: git push --no-verify is PROHIBITED without prior written
+# approval from Ralph + Aragorn documented in a GitHub issue comment.
 set -uo pipefail
 
 ROOT="$(git rev-parse --show-toplevel)"
@@ -49,7 +51,61 @@ if [[ -n "$UNTRACKED_SRC" ]]; then
   fi
 fi
 
-# ── Gate 2: Release build (mirrors CI exactly) ─────────────────────────────
+# ── Gate 2: markdownlint check ─────────────────────────────────────────────
+echo -e "\n${CYAN}📝 Checking Markdown lint (markdownlint-cli2)...${RESET}"
+if [[ -x "$ROOT/node_modules/.bin/markdownlint-cli2" ]]; then
+  "$ROOT/node_modules/.bin/markdownlint-cli2" "**/*.md" \
+    "!**/node_modules/**" \
+    "!**/bin/**" \
+    "!**/obj/**" \
+    "!.squad/**" \
+    "!.copilot/**" \
+    "!.github/agents/**" \
+    "!.github/skills/**" \
+    "!.github/copilot-instructions.md" \
+    --config "$ROOT/.markdownlint.json"
+  MD_EXIT=$?
+else
+  echo -e "${YELLOW}⚠️  markdownlint-cli2 not found at node_modules/.bin — run 'npm install'.${RESET}"
+  exit 1
+fi
+
+if [[ $MD_EXIT -ne 0 ]]; then
+  echo -e "${RED}❌  Markdownlint violations detected.${RESET}"
+  echo -e "${YELLOW}    Fix:  npx markdownlint-cli2 \"**/*.md\"${RESET}"
+  echo -e "${YELLOW}    Then: git add -u && git commit (or --amend), then re-push.${RESET}"
+  exit 1
+fi
+echo -e "${GREEN}✅  Markdown lint OK.${RESET}"
+
+# ── Gate 3: dotnet format check ────────────────────────────────────────────
+echo -e "\n${CYAN}🎨 Checking code formatting (dotnet format --verify-no-changes)...${RESET}"
+dotnet format MyBlog.slnx --verify-no-changes 2>&1
+FORMAT_EXIT=$?
+
+if [[ $FORMAT_EXIT -ne 0 ]]; then
+  echo -e "${RED}❌  Formatting issues detected — one or more files require formatting changes.${RESET}"
+  echo -e "${YELLOW}    Fix:  dotnet format MyBlog.slnx${RESET}"
+  echo -e "${YELLOW}    Then: git add -u && git commit (or --amend), then re-push.${RESET}"
+  echo ""
+  printf "Auto-fix formatting now? Modified files must be staged and committed before re-pushing. [y/N] " >/dev/tty
+  read -r FORMAT_FIX </dev/tty
+  if [[ "$FORMAT_FIX" == "y" || "$FORMAT_FIX" == "Y" ]]; then
+    echo -e "${CYAN}  🔧 Running dotnet format MyBlog.slnx...${RESET}"
+    dotnet format MyBlog.slnx
+    if [[ $? -ne 0 ]]; then
+      echo -e "${RED}❌  dotnet format encountered errors. Fix manually and re-push.${RESET}"
+      exit 1
+    fi
+    echo -e "${YELLOW}  ⚠️  Formatting applied to working tree. Stage changes: git add -u${RESET}"
+    echo -e "${YELLOW}       Then commit and re-push.${RESET}"
+  fi
+  echo -e "${RED}Push blocked: commit the formatting changes and re-push.${RESET}"
+  exit 1
+fi
+echo -e "${GREEN}✅  Formatting OK.${RESET}"
+
+# ── Gate 4: Release build (mirrors CI exactly) ─────────────────────────────
 MAX_ATTEMPTS=3
 BUILD_ATTEMPT=0
 BUILD_OK=false
@@ -85,7 +141,7 @@ if [[ "$BUILD_OK" != true ]]; then
   exit 1
 fi
 
-# ── Gate 3: Unit + Architecture tests ──────────────────────────────────────
+# ── Gate 5: Unit + Architecture tests ──────────────────────────────────────
 TEST_PROJECTS=(
   "tests/Architecture.Tests/Architecture.Tests.csproj"
   "tests/Domain.Tests/Domain.Tests.csproj"
@@ -121,10 +177,11 @@ if [[ "$TESTS_OK" != true ]]; then
   exit 1
 fi
 
-# ── Gate 4: Docker-backed integration tests ────────────────────────────────
+# ── Gate 6: Docker-backed integration tests ────────────────────────────────
 # Requires Docker daemon for Testcontainers-backed dependencies.
 INTEGRATION_PROJECTS=(
   "tests/Web.Tests.Integration/Web.Tests.Integration.csproj"
+  "tests/AppHost.Tests/AppHost.Tests.csproj"
 )
 
 echo -e "\n${CYAN}🐋 Checking Docker availability for integration tests...${RESET}"

.github/prompts/copyright-header-update-prompt.md

@@ -12,7 +12,7 @@ README files you write are appealing, informative, and easy to read.
 
 ## Plan
 
-This plan details how to review and update copyright headers in C# files, supporting both single-file and solution-wide operations. It ensures every file has the correct header, updating or inserting as needed.
+This plan details how to review and update copyright headers in C# files, supporting both single-file and solution-wide operations. It ensures every file has the correct header, preserves the original/earliest existing copyright year when normalizing an existing header, and collapses duplicate header blocks into one canonical header.
 
 **Header Example (as required):**
 
@@ -31,14 +31,14 @@ 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.
-2. For each file, check for an existing header at the very first line.
-3. If a header exists, update it with the correct format and metadata, ensuring every line starts with `//`.
-4. If no header exists, insert the new header at the very first line of the file, with every line C# line commented (start with `//`).
-5. Validate that the header is present, correctly formatted, and at the top of each file after editing.
+2. For each file, check for one or more existing header-like comment blocks at the very first line.
+3. If one or more header blocks exist, treat the entire leading header region as a single unit: preserve the original/earliest copyright year already present, normalize the metadata to the canonical format, and replace the region with exactly one header block.
+4. If no header exists, insert the new header at the very first line of the file, with every line C# line commented (start with `//`). When there is no existing year to preserve, use the file's creation year.
+5. Validate that exactly one canonical header is present, correctly formatted, and at the top of each file after editing.
 6. Output a summary of the files reviewed and the files changed.
 
 **Open Questions:**
 
 1. Should the header update logic support additional file types, or strictly `.cs` files?
-2. Is there a preferred way to determine the file's creation year if metadata is unavailable?
+2. If metadata is unavailable and no existing header year is present, is there a preferred fallback year source?
 3. Should the solution/project name be parsed from the `.sln`/`.csproj` files or hardcoded?