docs: ensure newline before lists across docs for MkDocs rendering

docs/content/adr/0002-go-version.md

@@ -5,6 +5,7 @@ Superseded by [ADR-0034: Go Version Upgrade to 1.25.3](./0034-go-version-upgrade
 
 ## Context
 Go releases new versions regularly with new features, performance improvements, and security fixes. We need to choose a Go version that:
+
 - Provides necessary features for the platform
 - Has good ecosystem support
 - Is stable and production-ready

docs/content/adr/0013-database-orm.md

@@ -5,6 +5,7 @@ Accepted
 
 ## Context
 The platform follows a microservices architecture where each service has its own database connection. The ORM/library must:
+
 - Support PostgreSQL (primary database)
 - Provide type-safe query building
 - Support code generation (reduces boilerplate)

docs/content/adr/0029-microservices-architecture.md

@@ -10,6 +10,7 @@ The platform needs to scale independently, support team autonomy, and enable fle
 Design the platform as **microservices architecture from day one**:
 
 1. **Core Services**: Core business services are separate microservices:
+
    - **Auth Service** (`cmd/auth-service/`): JWT token generation/validation
    - **Identity Service** (`cmd/identity-service/`): User CRUD, password management
    - **Authz Service** (`cmd/authz-service/`): Permission resolution, authorization

docs/content/adr/0030-service-communication-strategy.md

@@ -66,6 +66,7 @@ All communication goes through service clients - no direct in-process calls even
 
 ## Development Mode
 For local development, services run in the same repository but as separate processes:
+
 - Each service has its own entry point (`cmd/{service}/`)
 - Services communicate via service clients (gRPC or HTTP) - no direct in-process calls
 - Docker Compose orchestrates all services

docs/content/adr/0031-service-repository-structure.md

@@ -10,6 +10,7 @@ The platform follows a microservices architecture where each service (Auth, Iden
 - **Option 2**: Separate repositories (each service in its own repository)
 
 The decision affects:
+
 - Code sharing and dependencies
 - Development workflow
 - CI/CD complexity

docs/content/adr/0032-api-gateway-strategy.md

@@ -5,6 +5,7 @@ Accepted
 
 ## Context
 The platform follows a microservices architecture where each service is independently deployable. We need a central entry point that handles:
+
 - Request routing to backend services
 - Authentication and authorization at the edge
 - Rate limiting and throttling

docs/content/adr/0033-service-discovery-implementation.md

@@ -5,6 +5,7 @@ Accepted
 
 ## Context
 The platform follows a microservices architecture where services need to discover and communicate with each other. We need a service discovery mechanism that:
+
 - Enables services to find each other dynamically
 - Supports health checking and automatic deregistration
 - Works in both development (Docker Compose) and production (Kubernetes) environments

docs/content/adr/0034-go-version-upgrade.md

@@ -5,6 +5,7 @@ Accepted
 
 ## Context
 ADR-0002 established Go 1.24.3 as the minimum required version. Since then:
+
 - Go 1.25.3 has been released with new features, performance improvements, and security fixes
 - The project requires access to newer language features and tooling improvements
 - Dependencies may benefit from Go 1.25.3 optimizations

docs/content/adr/README.md

@@ -5,6 +5,7 @@ This directory contains Architecture Decision Records (ADRs) for the Go Platform
 ## What are ADRs?
 
 ADRs document important architectural decisions made during the project. They help:
+
 - Track why decisions were made
 - Understand the context and constraints
 - Review decisions when requirements change
@@ -13,6 +14,7 @@ ADRs document important architectural decisions made during the project. They he
 ## ADR Format
 
 Each ADR follows this structure:
+
 - **Status**: Proposed | Accepted | Rejected | Superseded
 - **Context**: The situation that led to the decision
 - **Decision**: What was decided

docs/content/architecture/architecture.md

@@ -14,6 +14,7 @@ This document provides a comprehensive overview of the Go Platform architecture,
 ## High-Level Architecture
 
 The Go Platform follows a **microservices architecture** where each service is independently deployable from day one:
+
 - **Core Kernel**: Infrastructure only (config, logger, DI, health, metrics, observability) - no business logic
 - **Core Services**: Auth Service, Identity Service, Authz Service, Audit Service - separate microservices
 - **API Gateway**: Single entry point for all external traffic, handles routing and authentication

docs/content/index.md

@@ -36,6 +36,7 @@ Go Platform is a microservices platform designed to support multiple business do
 
 ### Architecture Decision Records (ADRs)
 All architectural decisions are documented in [ADR records](adr/README.md), organized by implementation epic:  
+
 - **Epic 0**: Project Setup & Foundation
 - **Epic 1**: Core Kernel & Infrastructure
 - **Epic 2**: Authentication & Authorization
@@ -46,6 +47,7 @@ All architectural decisions are documented in [ADR records](adr/README.md), orga
 
 ### Implementation Tasks
 Detailed task definitions for each epic are available in the [Stories section](stories/README.md):
+
 - **[Epic 0: Project Setup & Foundation](stories/epic0/README.md)** - [Implementation Summary](stories/epic0/SUMMARY.md)
 - **[Epic 1: Core Kernel & Infrastructure](stories/epic1/README.md)** - [Implementation Summary](stories/epic1/SUMMARY.md)
 - Epic 2: Authentication & Authorization

docs/content/playbook.md

@@ -49,6 +49,7 @@ Core business services are implemented as separate, independently deployable ser
 | **API Gateway** | `cmd/api-gateway/` | Request routing, authentication, rate limiting, CORS | N/A (entry point) |
 
 Each service:
+
 - Has its own `go.mod` (or shared workspace)
 - Manages its own database connection pool and schema
 - Exposes gRPC server (and optional HTTP)

docs/content/requirements.md

@@ -244,6 +244,7 @@ func main() {
 ```
 
 Services communicate via service clients:
+
 - All inter-service communication uses gRPC (primary) or HTTP (fallback)
 - Service discovery via service registry
 - Each service manages its own database connection

docs/content/stories/COMPLETE_TASK_LIST.md

@@ -85,6 +85,7 @@ Tasks are organized by epic and section. Each task file follows the naming conve
 ## Task Status Tracking
 
 To track task completion:
+
 1. Update the Status field in each task file
 2. Update checkboxes in the main plan.md
 3. Reference task IDs in commit messages: `[0.1.1] Initialize Go module`

docs/content/stories/README.md

@@ -36,6 +36,7 @@ Tasks are organized by epic, with each major task section having its own detaile
 ## Task Status
 
 Each task file includes:
+
 - **Task ID**: Unique identifier (e.g., `0.1.1`)
 - **Title**: Descriptive task name
 - **Epic**: Implementation epic
@@ -50,6 +51,7 @@ Each task file includes:
 ## Task Tracking
 
 Tasks can be tracked using:
+
 - GitHub Issues (linked from tasks)
 - Project boards
 - Task management tools

docs/content/stories/epic0/0.3-structured-logging-system.md

@@ -19,6 +19,7 @@ This story implements a complete logging system using Zap that provides structur
 
 ### 1. Logger Interface (`pkg/logger/logger.go`)
 Define `Logger` interface with:
+
 - `Debug(msg string, fields ...Field)` - Debug level logging
 - `Info(msg string, fields ...Field)` - Info level logging
 - `Warn(msg string, fields ...Field)` - Warning level logging
@@ -30,6 +31,7 @@ Define `Logger` interface with:
 
 ### 2. Zap Implementation (`internal/logger/zap_logger.go`)
 Implement `Logger` interface using Zap:
+
 - Structured JSON logging for production mode
 - Human-readable console logging for development mode
 - Configurable log levels (debug, info, warn, error)
@@ -40,6 +42,7 @@ Implement `Logger` interface using Zap:
 
 ### 3. Request ID Middleware (`internal/logger/middleware.go`)
 Gin middleware for request correlation:
+
 - Generate unique request ID per HTTP request
 - Add request ID to request context
 - Add request ID to all logs within request context

docs/content/stories/epic0/0.4-cicd-pipeline.md

@@ -19,6 +19,7 @@ This story sets up the complete CI/CD pipeline using GitHub Actions and provides
 
 ### 1. GitHub Actions Workflow (`.github/workflows/ci.yml`)
 Complete CI pipeline with:
+
 - Go 1.24 setup
 - Go module caching for faster builds
 - Linting with golangci-lint or staticcheck
@@ -30,6 +31,7 @@ Complete CI pipeline with:
 
 ### 2. Comprehensive Makefile
 Developer-friendly Makefile with commands:
+
 - `make test` - Run all tests
 - `make test-coverage` - Run tests with coverage report
 - `make lint` - Run linters

docs/content/stories/epic0/0.5-di-and-bootstrap.md

@@ -19,6 +19,7 @@ This story implements the dependency injection system using Uber FX and creates
 
 ### 1. DI Container (`internal/di/container.go`)
 FX-based dependency injection container:
+
 - Initialize FX container
 - Register Config and Logger providers
 - Basic lifecycle hooks (OnStart, OnStop)
@@ -27,12 +28,14 @@ FX-based dependency injection container:
 
 ### 2. DI Providers (`internal/di/providers.go`)
 Provider functions for core services:
+
 - `ProvideConfig() fx.Option` - Configuration provider
 - `ProvideLogger() fx.Option` - Logger provider
 - Provider functions return FX options for easy composition
 
 ### 3. Application Entry Point (`cmd/platform/main.go`)
 Main application bootstrap:
+
 - Load configuration
 - Initialize DI container with core services
 - Set up basic application lifecycle

docs/content/stories/epic1/1.1-enhanced-di-container.md

@@ -28,6 +28,7 @@ This story extends the basic DI container to support core kernel services only:
 
 ### 2. Provider Functions (`internal/di/providers.go`)
 Complete provider functions for core kernel services only:
+
 - `ProvideConfig() fx.Option` - Configuration provider
 - `ProvideLogger() fx.Option` - Logger provider
 - `ProvideHealthCheckers() fx.Option` - Health check registry provider

docs/content/stories/epic1/1.2-database-layer.md

@@ -114,6 +114,7 @@ go run cmd/platform/main.go
 - `config/default.yaml` - Add database config with schema isolation settings
 
 **Note:** Entity schemas are created in Epic 2:
+
 - `services/identity/ent/schema/user.go` - User entity (Identity Service)
 - `services/authz/ent/schema/role.go` - Role entity (Authz Service)
 - `services/authz/ent/schema/permission.go` - Permission entity (Authz Service)

docs/content/stories/epic1/1.7-service-client-interfaces.md

@@ -19,6 +19,7 @@ This story defines service client interfaces for all core services (Auth, Identi
 
 ### 1. Service Client Interfaces (`pkg/services/`)
 Define interfaces for all core services:
+
 - `AuthServiceClient` in `pkg/services/auth.go`:
   - `Login(ctx, email, password) (*TokenResponse, error)`
   - `RefreshToken(ctx, refreshToken) (*TokenResponse, error)`

docs/content/stories/epic2/2.4-role-management.md

@@ -19,6 +19,7 @@ This story extends the Authz Service (implemented in Story 2.3) with role manage
 
 ### 1. gRPC Service Extensions (`api/proto/authz.proto`)
 Extend Authz Service proto with role management RPCs:
+
 - `CreateRoleRequest` / `CreateRoleResponse` - Create new role
 - `GetRoleRequest` / `GetRoleResponse` - Get role details
 - `ListRolesRequest` / `ListRolesResponse` - List all roles (with pagination)

docs/content/stories/epic2/2.7-service-abstraction-layer.md

@@ -19,6 +19,7 @@ This story implements the foundation for microservices architecture by creating
 
 ### 1. Service Client Interfaces (`pkg/services/`)
 Define service client interfaces for all core services:
+
 - `IdentityServiceClient` - User and identity operations
 - `AuthServiceClient` - Authentication operations
 - `AuthzServiceClient` - Authorization operations
@@ -29,6 +30,7 @@ Define service client interfaces for all core services:
 
 ### 2. Service Client Factory (`internal/services/factory.go`)
 Factory pattern for creating service clients:
+
 - Create gRPC clients (primary)
 - Create HTTP clients (fallback)
 - Support service registry integration