fix: resolve all markdown lint errors and enforce strict linting

- Fix MD032 (blanks around lists) in all files
- Fix MD040 (code block language) - add 'text' to plain text blocks
- Fix MD060 (table separator spacing) in README.md
- Fix MD036 (emphasis as heading) in CLAUDE.md
- Remove continue-on-error from docs-validation.yml to enforce linting

Author: jeremyeder

.github/workflows/docs-validation.yml

@@ -42,4 +42,3 @@ jobs:
         with:
           globs: "**/*.md"
           config: ".markdownlint.json"
-        continue-on-error: true

CLAUDE.md

@@ -24,6 +24,7 @@
 This is a **GitHub template repository** demonstrating AI-assisted development best practices. It's a **documentation-only** reference using the "standalone patterns approach" - concepts are standalone and independently adoptable.
 
 **Key Principles**:
+
 - ✅ **Standalone patterns approach** - Patterns are standalone and independently adoptable
 - ✅ **Documentation-focused** - Pure reference material, no working application
 - ✅ **Succinct content** - No AI slop, get to the point
@@ -34,17 +35,20 @@ This is a **GitHub template repository** demonstrating AI-assisted development b
 ### What This Repository Contains
 
 **Documentation** (`docs/`):
+
 - Quickstart guides for AI-assisted development
 - Architecture pattern references
 - Tutorial outlines for implementing agentic workflows
 - API design patterns
 
 **Codebase Agent Configuration** (`.claude/`):
+
 - Agent definitions and capabilities
 - Context files for modular memory system
 - Example commands and skills
 
 **CI/CD** (`.github/workflows/`):
+
 - Documentation validation workflows
 - Markdown linting
 - Mermaid diagram validation
@@ -61,6 +65,7 @@ For a **working FastAPI application** demonstrating these patterns in practice,
 ### Python Version Support
 
 For any code examples in documentation:
+
 - Python 3.11 (primary)
 - Python 3.12 (tested in CI matrix)
 
@@ -125,6 +130,7 @@ markdownlint docs/**/*.md README.md CLAUDE.md --fix
 ### Documentation Structure
 
 **Core docs** (`docs/`):
+
 1. `quickstart.md` - 5-minute introduction to AI-assisted development
 2. `architecture.md` - Common architecture patterns for agentic workflows
 3. `tutorial.md` - Step-by-step guide for implementing patterns
@@ -143,6 +149,7 @@ markdownlint docs/**/*.md README.md CLAUDE.md --fix
 **CI enforcement**: Blocks merge if diagrams invalid
 
 **Example validation script**:
+
 ```bash
 #!/bin/bash
 # Validate all Mermaid diagrams
@@ -154,6 +161,7 @@ find docs/ -name "*.mmd" -exec mmdc -i {} -o /dev/null \;
 **Location**: `docs/adr/`
 
 **Scaffolding only** - NO actual content:
+
 - `README.md` - Explains ADR purpose and format
 - `template.md` - Shows format (YYYYMMDD-title.md)
 
@@ -174,6 +182,7 @@ find docs/ -name "*.mmd" -exec mmdc -i {} -o /dev/null \;
 **Location**: `.claude/context/`
 
 **Modular context files**:
+
 - `architecture.md` - Architecture patterns and conventions
 - `security-standards.md` - Security best practices
 - `testing-patterns.md` - Testing strategies and patterns
@@ -183,6 +192,7 @@ find docs/ -name "*.mmd" -exec mmdc -i {} -o /dev/null \;
 ### Agent Capability Patterns
 
 **Common patterns to document**:
+
 1. **Issue-to-PR Automation** - Converting well-defined issues into PRs
 2. **Code Reviews** - Providing actionable feedback
 3. **Proactive Maintenance** - Dependency updates, linting, docs
@@ -191,6 +201,7 @@ find docs/ -name "*.mmd" -exec mmdc -i {} -o /dev/null \;
 ### Autonomy Levels (Example Pattern)
 
 Document autonomy levels teams might implement:
+
 - **Level 1 (Conservative)**: PR creation only - WAIT for human approval
 - **Level 2 (Moderate)**: Auto-merge for low-risk changes (docs, deps)
 - **Level 3 (Aggressive)**: Auto-deploy after tests pass
@@ -214,13 +225,15 @@ git checkout -b feature/descriptive-name
 ### Commit Workflow
 
 **Pre-commit checklist**:
+
 1. Lint markdown: `markdownlint docs/**/*.md --fix`
 2. Validate diagrams: `./scripts/validate-mermaid.sh`
 3. Check git status: `git status`
 4. Review changes: `git diff`
 
 **Commit message style**:
-```
+
+```text
 Add documentation for X pattern
 
 - Explain Y concept
@@ -232,12 +245,14 @@ Focus on "why" rather than "what".
 ### Pull Request Workflow
 
 **Before creating PR**:
+
 1. `git status` - check untracked files
 2. `git diff` - review all changes
 3. `git log` - review commit history
 4. Ensure CI passes (markdown linting, diagram validation)
 
 **PR requirements**:
+
 - [ ] Markdown linting passes
 - [ ] Mermaid diagrams validated
 - [ ] No broken links
@@ -246,6 +261,7 @@ Focus on "why" rather than "what".
 ### Git Safety
 
 **NEVER**:
+
 - Update git config without permission
 - Run destructive commands (hard reset, force push) without explicit request
 - Skip hooks (--no-verify)
@@ -276,13 +292,15 @@ Focus on "why" rather than "what".
 **File**: `.github/dependabot.yml`
 
 **Configuration**:
+
 - **Schedule**: Weekly
 - **Auto-label**: "dependencies"
 - **Package ecosystem**: pip (for doc tooling)
 
 ### Documentation Deployment (Optional)
 
 Teams can extend with:
+
 - GitHub Pages deployment
 - MkDocs builds
 - Static site generation
@@ -338,7 +356,7 @@ gh pr create --title "docs: Add X" --body "Documentation for X pattern"
 
 Common pattern for AI-assisted applications:
 
-```
+```text
 API Layer (Routes/Endpoints)
     ↓ Handles HTTP, validation, serialization
 Service Layer (Business logic)
@@ -352,24 +370,28 @@ Core Layer (Config, utilities)
 ### Component Responsibility Patterns
 
 **API Layer**:
+
 - Route handlers
 - Request/response validation
 - HTTP status codes
 - Error responses
 - API documentation
 
 **Service Layer**:
+
 - Business logic
 - Data manipulation
 - Transaction coordination
 - No transport concerns
 
 **Model Layer**:
+
 - Data validation
 - Type annotations
 - Serialization rules
 
 **Core Layer**:
+
 - Configuration management
 - Security utilities
 - Logging configuration
@@ -382,13 +404,15 @@ Core Layer (Config, utilities)
 ### Input Validation Pattern
 
 **Validate at boundaries only**:
+
 - Validate all external input (user requests, API calls)
 - Trust internal code between layers
 - Use schema validation libraries
 
 ### Sanitization Pattern
 
 Common sanitization functions to implement:
+
 - `sanitize_string()` - Remove dangerous characters
 - `validate_slug()` - Ensure URL-safe identifiers
 - `sanitize_path()` - Prevent path traversal
@@ -405,6 +429,7 @@ Common sanitization functions to implement:
 ## Anti-Requirements
 
 **NEVER include**:
+
 - ❌ Red Hat branding or references
 - ❌ "Amber" terminology (use "Codebase Agent" or "CBA")
 - ❌ Sequenced/linear adoption path (standalone patterns approach only)
@@ -418,6 +443,6 @@ Common sanitization functions to implement:
 
 ---
 
-**End of Configuration**
+## End of Configuration
 
 This CLAUDE.md file is the source of truth for all AI-assisted development in this repository. Follow these standards strictly.

README.md

@@ -36,7 +36,7 @@ This repository provides documentation and patterns for:
 Pick what you need. Each pattern works independently:
 
 | Pattern | Description | How to Adopt |
-|---------|-------------|--------------|
+| ------- | ----------- | ------------ |
 | **Codebase Agent** | AI agent configuration patterns | Copy `.claude/` structure |
 | **Architecture** | Layered architecture patterns | Reference `docs/architecture.md` |
 | **Security** | Security best practices | Reference `.claude/context/security-standards.md` |
@@ -46,7 +46,7 @@ Pick what you need. Each pattern works independently:
 
 ## Repository Structure
 
-```
+```text
 ambient-code-reference/
 ├── .claude/               # Codebase Agent patterns
 │   ├── agents/           # CBA agent definition patterns
@@ -68,6 +68,7 @@ Want to see these patterns in a working FastAPI application?
 **→ [demo-fastapi](https://github.com/jeremyeder/demo-fastapi)** - Toy application demonstrating CBA patterns in practice
 
 The demo repository includes:
+
 - Working FastAPI service with CRUD endpoints
 - CBA agent configuration
 - Full test suite (unit, integration, E2E)

docs/adr/README.md

@@ -5,6 +5,7 @@ This directory contains Architecture Decision Records for significant architectu
 ## What is an ADR?
 
 An ADR documents:
+
 - **Context**: The situation requiring a decision
 - **Decision**: The choice made
 - **Consequences**: The results, both positive and negative
@@ -13,7 +14,7 @@ An ADR documents:
 
 ADRs follow this naming convention:
 
-```
+```text
 YYYYMMDD-title.md
 ```
 
@@ -33,6 +34,7 @@ See `template.md` for the ADR format.
 ## Status
 
 ADRs can have these statuses:
+
 - **Proposed**: Under discussion
 - **Accepted**: Decision made
 - **Deprecated**: No longer recommended
@@ -43,6 +45,7 @@ ADRs can have these statuses:
 This repository currently has no ADRs (scaffolding only).
 
 When you make architectural decisions, create ADRs for:
+
 - Technology choices (FastAPI, Pydantic, etc.)
 - Architecture patterns (layered architecture)
 - Security approaches (input validation strategy)

docs/adr/template.md

@@ -7,13 +7,15 @@
 ## Context
 
 Describe the situation and forces at play:
+
 - What problem are we trying to solve?
 - What constraints exist?
 - What alternatives were considered?
 
 ## Decision
 
 State the decision clearly:
+
 - What did we decide?
 - Why this approach?
 - What are the key factors?
@@ -23,16 +25,19 @@ State the decision clearly:
 Document the results:
 
 ### Positive
+
 - What benefits does this bring?
 - What problems does it solve?
 - What opportunities does it create?
 
 ### Negative
+
 - What drawbacks exist?
 - What complexities does it introduce?
 - What risks remain?
 
 ### Neutral
+
 - What else changes as a result?
 
 ## References