diff --git a/.cursor/rules/golang.md b/.cursor/rules/golang.md
deleted file mode 100644
index c4be26e..0000000
--- a/.cursor/rules/golang.md
+++ /dev/null
@@ -1,95 +0,0 @@
-You are an expert in Go, microservices architecture, and clean backend development practices. Your role is to ensure code is idiomatic, modular, testable, and aligned with modern best practices and design patterns.
-
-### General Responsibilities:
-- Guide the development of idiomatic, maintainable, and high-performance Go code.
-- Enforce modular design and separation of concerns through Clean Architecture.
-- Promote test-driven development, robust observability, and scalable patterns across services.
-
-### Architecture Patterns:
-- Apply **Clean Architecture** by structuring code into handlers/controllers, services/use cases, repositories/data access, and domain models.
-- Use **domain-driven design** principles where applicable.
-- Prioritize **interface-driven development** with explicit dependency injection.
-- Prefer **composition over inheritance**; favor small, purpose-specific interfaces.
-- Ensure that all public functions interact with interfaces, not concrete types, to enhance flexibility and testability.
-
-### Project Structure Guidelines:
-- Use a consistent project layout:
-  - cmd/: application entrypoints
-  - internal/: core application logic (not exposed externally)
-  - pkg/: shared utilities and packages
-  - api/: gRPC/REST transport definitions and handlers
-  - configs/: configuration schemas and loading
-  - test/: test utilities, mocks, and integration tests
-- Group code by feature when it improves clarity and cohesion.
-- Keep logic decoupled from framework-specific code.
-
-### Development Best Practices:
-- Write **short, focused functions** with a single responsibility.
-- Always **check and handle errors explicitly**, using wrapped errors for traceability ('fmt.Errorf("context: %w", err)').
-- Avoid **global state**; use constructor functions to inject dependencies.
-- Leverage **Go's context propagation** for request-scoped values, deadlines, and cancellations.
-- Use **goroutines safely**; guard shared state with channels or sync primitives.
-- **Defer closing resources** and handle them carefully to avoid leaks.
-
-### Security and Resilience:
-- Apply **input validation and sanitization** rigorously, especially on inputs from external sources.
-- Use secure defaults for **JWT, cookies**, and configuration settings.
-- Isolate sensitive operations with clear **permission boundaries**.
-- Implement **retries, exponential backoff, and timeouts** on all external calls.
-- Use **circuit breakers and rate limiting** for service protection.
-- Consider implementing **distributed rate-limiting** to prevent abuse across services (e.g., using Redis).
-
-### Testing:
-- Write **unit tests** using table-driven patterns and parallel execution.
-- **Mock external interfaces** cleanly using generated or handwritten mocks.
-- Separate **fast unit tests** from slower integration and E2E tests.
-- Ensure **test coverage** for every exported function, with behavioral checks.
-- Use tools like 'go test -cover' to ensure adequate test coverage.
-
-### Documentation and Standards:
-- Document public functions and packages with **GoDoc-style comments**.
-- Provide concise **READMEs** for services and libraries.
-- Maintain a 'CONTRIBUTING.md' and 'ARCHITECTURE.md' to guide team practices.
-- Enforce naming consistency and formatting with 'go fmt', 'goimports', and 'golangci-lint'.
-
-### Observability with OpenTelemetry:
-- Use **OpenTelemetry** for distributed tracing, metrics, and structured logging.
-- Start and propagate tracing **spans** across all service boundaries (HTTP, gRPC, DB, external APIs).
-- Always attach 'context.Context' to spans, logs, and metric exports.
-- Use **otel.Tracer** for creating spans and **otel.Meter** for collecting metrics.
-- Record important attributes like request parameters, user ID, and error messages in spans.
-- Use **log correlation** by injecting trace IDs into structured logs.
-- Export data to **OpenTelemetry Collector**, **Jaeger**, or **Prometheus**.
-
-### Tracing and Monitoring Best Practices:
-- Trace all **incoming requests** and propagate context through internal and external calls.
-- Use **middleware** to instrument HTTP and gRPC endpoints automatically.
-- Annotate slow, critical, or error-prone paths with **custom spans**.
-- Monitor application health via key metrics: **request latency, throughput, error rate, resource usage**.
-- Define **SLIs** (e.g., request latency < 300ms) and track them with **Prometheus/Grafana** dashboards.
-- Alert on key conditions (e.g., high 5xx rates, DB errors, Redis timeouts) using a robust alerting pipeline.
-- Avoid excessive **cardinality** in labels and traces; keep observability overhead minimal.
-- Use **log levels** appropriately (info, warn, error) and emit **JSON-formatted logs** for ingestion by observability tools.
-- Include unique **request IDs** and trace context in all logs for correlation.
-
-### Performance:
-- Use **benchmarks** to track performance regressions and identify bottlenecks.
-- Minimize **allocations** and avoid premature optimization; profile before tuning.
-- Instrument key areas (DB, external calls, heavy computation) to monitor runtime behavior.
-
-### Concurrency and Goroutines:
-- Ensure safe use of **goroutines**, and guard shared state with channels or sync primitives.
-- Implement **goroutine cancellation** using context propagation to avoid leaks and deadlocks.
-
-### Tooling and Dependencies:
-- Rely on **stable, minimal third-party libraries**; prefer the standard library where feasible.
-- Use **Go modules** for dependency management and reproducibility.
-- Version-lock dependencies for deterministic builds.
-- Integrate **linting, testing, and security checks** in CI pipelines.
-
-### Key Conventions:
-1. Prioritize **readability, simplicity, and maintainability**.
-2. Design for **change**: isolate business logic and minimize framework lock-in.
-3. Emphasize clear **boundaries** and **dependency inversion**.
-4. Ensure all behavior is **observable, testable, and documented**.
-5. **Automate workflows** for testing, building, and deployment.
\ No newline at end of file
diff --git a/.cursor/rules/golang.mdc b/.cursor/rules/golang.mdc
new file mode 100644
index 0000000..d53aeac
--- /dev/null
+++ b/.cursor/rules/golang.mdc
@@ -0,0 +1,209 @@
+---
+alwaysApply: true
+---
+# Go Development Rules for Cursor AI
+
+You are an expert in Go, microservices architecture, and clean backend development practices. When working with Go code in this project, you MUST follow these rules strictly.
+
+## Architecture Patterns
+
+- **ALWAYS** apply Clean Architecture by structuring code into handlers/controllers, services/use cases, repositories/data access, and domain models
+- **ALWAYS** use domain-driven design principles where applicable
+- **ALWAYS** prioritize interface-driven development with explicit dependency injection
+- **ALWAYS** prefer composition over inheritance; favor small, purpose-specific interfaces
+- **ALWAYS** ensure that all public functions interact with interfaces, not concrete types, to enhance flexibility and testability
+
+## Project Structure
+
+When organizing code, you MUST follow this structure:
+- `cmd/`: application entrypoints
+- `internal/`: core application logic (not exposed externally)
+- `pkg/`: shared utilities and packages
+- `api/`: gRPC/REST transport definitions and handlers
+- `configs/`: configuration schemas and loading
+- `test/`: test utilities, mocks, and integration tests
+
+Group code by feature when it improves clarity and cohesion. Keep logic decoupled from framework-specific code.
+
+## Code Quality Requirements
+
+- **ALWAYS** write short, focused functions with a single responsibility
+- **ALWAYS** check and handle errors explicitly, using wrapped errors for traceability: `fmt.Errorf("context: %w", err)`
+- **NEVER** use global state; use constructor functions to inject dependencies
+- **ALWAYS** leverage Go's context propagation for request-scoped values, deadlines, and cancellations
+- **ALWAYS** use goroutines safely; guard shared state with channels or sync primitives
+- **ALWAYS** defer closing resources and handle them carefully to avoid leaks
+
+## Security and Resilience
+
+- **ALWAYS** apply input validation and sanitization rigorously, especially on inputs from external sources
+- **ALWAYS** use secure defaults for JWT, cookies, and configuration settings
+- **ALWAYS** isolate sensitive operations with clear permission boundaries
+- **ALWAYS** implement retries, exponential backoff, and timeouts on all external calls
+- **ALWAYS** use circuit breakers and rate limiting for service protection
+- Consider implementing distributed rate-limiting to prevent abuse across services (e.g., using Redis)
+
+## Testing Requirements
+
+- **ALWAYS** write unit tests using table-driven patterns and parallel execution
+- **ALWAYS** mock external interfaces cleanly using generated or handwritten mocks
+- **ALWAYS** separate fast unit tests from slower integration and E2E tests
+- **ALWAYS** ensure test coverage for every exported function, with behavioral checks
+- Use tools like `go test -cover` to ensure adequate test coverage
+
+## Documentation Standards
+
+- **ALWAYS** document public functions and packages with GoDoc-style comments
+- **ALWAYS** provide concise READMEs for services and libraries
+- **ALWAYS** enforce naming consistency and formatting with `go fmt`, `goimports`, and `golangci-lint`
+
+## Observability with OpenTelemetry
+
+- **ALWAYS** use OpenTelemetry for distributed tracing, metrics, and structured logging
+- **ALWAYS** start and propagate tracing spans across all service boundaries (HTTP, gRPC, DB, external APIs)
+- **ALWAYS** attach `context.Context` to spans, logs, and metric exports
+- **ALWAYS** use `otel.Tracer` for creating spans and `otel.Meter` for collecting metrics
+- **ALWAYS** record important attributes like request parameters, user ID, and error messages in spans
+- **ALWAYS** use log correlation by injecting trace IDs into structured logs
+- Export data to OpenTelemetry Collector, Jaeger, or Prometheus
+
+## Tracing and Monitoring
+
+- **ALWAYS** trace all incoming requests and propagate context through internal and external calls
+- **ALWAYS** use middleware to instrument HTTP and gRPC endpoints automatically
+- **ALWAYS** annotate slow, critical, or error-prone paths with custom spans
+- Monitor application health via key metrics: request latency, throughput, error rate, resource usage
+- Define SLIs (e.g., request latency < 300ms) and track them with Prometheus/Grafana dashboards
+- Alert on key conditions (e.g., high 5xx rates, DB errors, Redis timeouts) using a robust alerting pipeline
+- **NEVER** create excessive cardinality in labels and traces; keep observability overhead minimal
+- **ALWAYS** use log levels appropriately (info, warn, error) and emit JSON-formatted logs for ingestion by observability tools
+- **ALWAYS** include unique request IDs and trace context in all logs for correlation
+
+## Performance
+
+- Use benchmarks to track performance regressions and identify bottlenecks
+- Minimize allocations and avoid premature optimization; profile before tuning
+- Instrument key areas (DB, external calls, heavy computation) to monitor runtime behavior
+
+## Concurrency and Goroutines
+
+- **ALWAYS** ensure safe use of goroutines, and guard shared state with channels or sync primitives
+- **ALWAYS** implement goroutine cancellation using context propagation to avoid leaks and deadlocks
+
+## Tooling and Dependencies
+
+- **ALWAYS** rely on stable, minimal third-party libraries; prefer the standard library where feasible
+- **ALWAYS** use Go modules for dependency management and reproducibility
+- **ALWAYS** version-lock dependencies for deterministic builds
+- **ALWAYS** integrate linting, testing, and security checks in CI pipelines
+
+## Key Conventions
+
+1. **ALWAYS** prioritize readability, simplicity, and maintainability
+2. **ALWAYS** design for change: isolate business logic and minimize framework lock-in
+3. **ALWAYS** emphasize clear boundaries and dependency inversion
+4. **ALWAYS** ensure all behavior is observable, testable, and documented
+5. **ALWAYS** automate workflows for testing, building, and deployment
+# Go Development Rules for Cursor AI
+
+You are an expert in Go, microservices architecture, and clean backend development practices. When working with Go code in this project, you MUST follow these rules strictly.
+
+## Architecture Patterns
+
+- **ALWAYS** apply Clean Architecture by structuring code into handlers/controllers, services/use cases, repositories/data access, and domain models
+- **ALWAYS** use domain-driven design principles where applicable
+- **ALWAYS** prioritize interface-driven development with explicit dependency injection
+- **ALWAYS** prefer composition over inheritance; favor small, purpose-specific interfaces
+- **ALWAYS** ensure that all public functions interact with interfaces, not concrete types, to enhance flexibility and testability
+
+## Project Structure
+
+When organizing code, you MUST follow this structure:
+- `cmd/`: application entrypoints
+- `internal/`: core application logic (not exposed externally)
+- `pkg/`: shared utilities and packages
+- `api/`: gRPC/REST transport definitions and handlers
+- `configs/`: configuration schemas and loading
+- `test/`: test utilities, mocks, and integration tests
+
+Group code by feature when it improves clarity and cohesion. Keep logic decoupled from framework-specific code.
+
+## Code Quality Requirements
+
+- **ALWAYS** write short, focused functions with a single responsibility
+- **ALWAYS** check and handle errors explicitly, using wrapped errors for traceability: `fmt.Errorf("context: %w", err)`
+- **NEVER** use global state; use constructor functions to inject dependencies
+- **ALWAYS** leverage Go's context propagation for request-scoped values, deadlines, and cancellations
+- **ALWAYS** use goroutines safely; guard shared state with channels or sync primitives
+- **ALWAYS** defer closing resources and handle them carefully to avoid leaks
+
+## Security and Resilience
+
+- **ALWAYS** apply input validation and sanitization rigorously, especially on inputs from external sources
+- **ALWAYS** use secure defaults for JWT, cookies, and configuration settings
+- **ALWAYS** isolate sensitive operations with clear permission boundaries
+- **ALWAYS** implement retries, exponential backoff, and timeouts on all external calls
+- **ALWAYS** use circuit breakers and rate limiting for service protection
+- Consider implementing distributed rate-limiting to prevent abuse across services (e.g., using Redis)
+
+## Testing Requirements
+
+- **ALWAYS** write unit tests using table-driven patterns and parallel execution
+- **ALWAYS** mock external interfaces cleanly using generated or handwritten mocks
+- **ALWAYS** separate fast unit tests from slower integration and E2E tests
+- **ALWAYS** ensure test coverage for every exported function, with behavioral checks
+- Use tools like `go test -cover` to ensure adequate test coverage
+
+## Documentation Standards
+
+- **ALWAYS** document public functions and packages with GoDoc-style comments
+- **ALWAYS** provide concise READMEs for services and libraries
+- **ALWAYS** enforce naming consistency and formatting with `go fmt`, `goimports`, and `golangci-lint`
+
+## Observability with OpenTelemetry
+
+- **ALWAYS** use OpenTelemetry for distributed tracing, metrics, and structured logging
+- **ALWAYS** start and propagate tracing spans across all service boundaries (HTTP, gRPC, DB, external APIs)
+- **ALWAYS** attach `context.Context` to spans, logs, and metric exports
+- **ALWAYS** use `otel.Tracer` for creating spans and `otel.Meter` for collecting metrics
+- **ALWAYS** record important attributes like request parameters, user ID, and error messages in spans
+- **ALWAYS** use log correlation by injecting trace IDs into structured logs
+- Export data to OpenTelemetry Collector, Jaeger, or Prometheus
+
+## Tracing and Monitoring
+
+- **ALWAYS** trace all incoming requests and propagate context through internal and external calls
+- **ALWAYS** use middleware to instrument HTTP and gRPC endpoints automatically
+- **ALWAYS** annotate slow, critical, or error-prone paths with custom spans
+- Monitor application health via key metrics: request latency, throughput, error rate, resource usage
+- Define SLIs (e.g., request latency < 300ms) and track them with Prometheus/Grafana dashboards
+- Alert on key conditions (e.g., high 5xx rates, DB errors, Redis timeouts) using a robust alerting pipeline
+- **NEVER** create excessive cardinality in labels and traces; keep observability overhead minimal
+- **ALWAYS** use log levels appropriately (info, warn, error) and emit JSON-formatted logs for ingestion by observability tools
+- **ALWAYS** include unique request IDs and trace context in all logs for correlation
+
+## Performance
+
+- Use benchmarks to track performance regressions and identify bottlenecks
+- Minimize allocations and avoid premature optimization; profile before tuning
+- Instrument key areas (DB, external calls, heavy computation) to monitor runtime behavior
+
+## Concurrency and Goroutines
+
+- **ALWAYS** ensure safe use of goroutines, and guard shared state with channels or sync primitives
+- **ALWAYS** implement goroutine cancellation using context propagation to avoid leaks and deadlocks
+
+## Tooling and Dependencies
+
+- **ALWAYS** rely on stable, minimal third-party libraries; prefer the standard library where feasible
+- **ALWAYS** use Go modules for dependency management and reproducibility
+- **ALWAYS** version-lock dependencies for deterministic builds
+- **ALWAYS** integrate linting, testing, and security checks in CI pipelines
+
+## Key Conventions
+
+1. **ALWAYS** prioritize readability, simplicity, and maintainability
+2. **ALWAYS** design for change: isolate business logic and minimize framework lock-in
+3. **ALWAYS** emphasize clear boundaries and dependency inversion
+4. **ALWAYS** ensure all behavior is observable, testable, and documented
+5. **ALWAYS** automate workflows for testing, building, and deployment
diff --git a/AGENTS.md b/AGENTS.md
new file mode 100644
index 0000000..c90347e
--- /dev/null
+++ b/AGENTS.md
@@ -0,0 +1,308 @@
+# Agent Instructions for Go Platform Project
+
+This document provides essential guidance for AI agents and developers working on the Go Platform project. **Always consult the documentation before making changes or implementing features.**
+
+## 🚨 Critical Requirement
+
+**BEFORE making any code changes, architectural decisions, or implementing features, you MUST:**
+
+1. ✅ Review relevant **documentation** files
+2. ✅ Check applicable **architecture** documents
+3. ✅ Consult relevant **Architecture Decision Records (ADRs)**
+4. ✅ Review the **stories** (epic-based implementation tasks)
+
+Failure to follow these guidelines may result in code that doesn't align with the project's architecture, principles, or implementation plan.
+
+---
+
+## 📚 Documentation Structure
+
+All documentation is located in `/goplt/docs/content/`. The project follows a structured documentation approach:
+
+### Core Documentation (`/goplt/docs/content/`)
+
+- **`index.md`**: Main documentation index and navigation
+- **`requirements.md`**: High-level architectural principles and requirements
+- **`plan.md`**: Epic-based implementation plan with timelines and acceptance criteria
+- **`playbook.md`**: Detailed implementation guide, best practices, and technical specifications
+
+### Architecture Documentation (`/goplt/docs/content/architecture/`)
+
+- **`architecture.md`**: System architecture overview with diagrams
+- **`architecture-modules.md`**: Module system design and integration patterns
+- **`module-requirements.md`**: Detailed requirements for each module
+- **`component-relationships.md`**: Component interactions and dependencies
+- **`system-behavior.md`**: System behavior overview end-to-end
+- **`service-orchestration.md`**: How services work together
+- **`module-integration-patterns.md`**: How modules integrate with the platform
+- **`operational-scenarios.md`**: Common operational flows and use cases
+- **`data-flow-patterns.md`**: How data flows through the system
+
+### Architecture Decision Records (`/goplt/docs/content/adr/`)
+
+All architectural decisions are documented in ADR files (ADR-0001 through ADR-0030+). These records explain:
+- The context that led to the decision
+- The decision itself
+- The rationale and consequences
+- Implementation notes
+
+**Key ADRs to review:**
+- ADR-0001: Go Module Path
+- ADR-0003: Dependency Injection Framework
+- ADR-0004: Configuration Management
+- ADR-0005: Logging Framework
+- ADR-0006: HTTP Framework
+- ADR-0007: Project Directory Structure
+- ADR-0008: Error Handling Strategy
+- ADR-0013: Database ORM
+- ADR-0016: OpenTelemetry Observability
+- ADR-0017: JWT Token Strategy
+- ADR-0021: Module Loading Strategy
+- ADR-0022: Cache Implementation
+- ADR-0023: Event Bus Implementation
+- ADR-0025: Multitenancy Model
+- ADR-0027: Rate Limiting Strategy
+- ADR-0028: Testing Strategy
+- ADR-0029: Microservices Architecture
+- ADR-0030: Service Communication Strategy
+
+**Always check ADRs before making architectural decisions!**
+
+### Implementation Stories (`/goplt/docs/content/stories/`)
+
+The project is organized into **8 epics**, each containing specific implementation stories:
+
+- **Epic 0**: Project Setup & Foundation (`epic0/`)
+  - 0.1: Project Initialization
+  - 0.2: Configuration Management System
+  - 0.3: Structured Logging System
+  - 0.4: CI/CD Pipeline
+  - 0.5: Dependency Injection and Bootstrap
+
+- **Epic 1**: Core Kernel & Infrastructure (`epic1/`)
+  - 1.1: Enhanced DI Container
+  - 1.2: Database Layer
+  - 1.3: Health & Metrics System
+  - 1.4: Error Handling
+  - 1.5: HTTP Server
+  - 1.6: OpenTelemetry
+  - 1.7: Service Abstraction Layer
+
+- **Epic 2**: Authentication & Authorization (`epic2/`)
+  - 2.1: JWT Authentication
+  - 2.2: Identity Management
+  - 2.3: RBAC System
+  - 2.4: Role Management
+  - 2.5: Audit Logging
+  - 2.6: Database Seeding
+
+- **Epic 3**: Module Framework (`epic3/`)
+  - 3.1: Module System Interface
+  - 3.2: Permission Code Generation
+  - 3.3: Module Loader
+  - 3.4: Module CLI
+  - 3.5: Service Registry
+
+- **Epic 4**: Sample Feature Module (`epic4/`)
+  - 4.1: Blog Module
+
+- **Epic 5**: Infrastructure Adapters (`epic5/`)
+  - 5.1: Cache System
+  - 5.2: Event Bus
+  - 5.3: Blob Storage
+  - 5.4: Email Notification
+  - 5.5: Scheduler Jobs
+  - 5.6: Secret Store
+  - 5.7: gRPC Services
+
+- **Epic 6**: Observability & Production Readiness (`epic6/`)
+  - 6.1: Enhanced Observability
+  - 6.2: Error Reporting
+  - 6.3: Grafana Dashboards
+  - 6.4: Rate Limiting
+  - 6.5: Security Hardening
+  - 6.6: Performance Optimization
+
+- **Epic 7**: Testing, Documentation & CI/CD (`epic7/`)
+  - 7.1: Testing Suite
+  - 7.2: Documentation
+  - 7.3: CI/CD Enhancement
+  - 7.4: Docker Deployment
+
+- **Epic 8**: Advanced Features & Polish (`epic8/`)
+
+Each story file contains:
+- **Goal**: What needs to be accomplished
+- **Deliverables**: Specific items to be created
+- **Acceptance Criteria**: How to verify completion
+- **Implementation Notes**: Technical guidance
+
+**Always review the relevant story before implementing a feature!**
+
+---
+
+## 🔍 Workflow for Agents
+
+When working on this project, follow this workflow:
+
+### 0. Git Workflow (MANDATORY)
+- **ALWAYS create a new branch** when working on a new feature, bug fix, or enhancement
+  - Use descriptive branch names (e.g., `feature/epic1-http-server`, `bugfix/auth-token-expiry`, `enhancement/rate-limiting`)
+  - Branch names should follow the pattern: `{type}/{epic}-{short-description}` or `{type}/{story-id}-{short-description}`
+- **ALWAYS create a commit** after successfully implementing a feature that:
+  - ✅ Builds successfully (`go build` passes)
+  - ✅ Tests pass (`go test` passes)
+  - ✅ Meets all acceptance criteria from the story
+- Commit messages should be clear and descriptive, referencing the story/epic when applicable
+- Never commit directly to `main` branch
+
+### 1. Understand the Task
+- Read the user's request carefully
+- Identify which epic/story the task relates to
+- Determine if it's a new feature, bug fix, or enhancement
+
+### 2. Consult Documentation (MANDATORY)
+- **Start with `index.md`** to get oriented
+- **Read the relevant story** from `/goplt/docs/content/stories/epicX/`
+- **Review architecture documents** that relate to the feature
+- **Check ADRs** for any architectural decisions that apply
+- **Review `playbook.md`** for implementation patterns and best practices
+
+### 3. Understand the Architecture
+- Review the **architecture overview** (`architecture/architecture.md`)
+- Check **component relationships** if integrating with existing systems
+- Review **module integration patterns** if working on modules
+- Understand **data flow patterns** if working on data processing
+
+### 4. Check ADRs
+- Search for ADRs related to your task
+- Ensure your implementation aligns with documented decisions
+- If you need to make a new architectural decision, document it in a new ADR
+
+### 5. Implement According to Stories
+- Follow the deliverables specified in the story
+- Meet the acceptance criteria
+- Use the implementation notes as guidance
+- Follow the patterns established in `playbook.md`
+
+### 6. Verify Alignment
+- Ensure code follows Clean/Hexagonal Architecture principles
+- Verify it aligns with microservices architecture
+- Check that it follows plugin-first design
+- Confirm security-by-design principles are followed
+- Validate observability is properly implemented
+
+### 7. Commit Changes
+- **ALWAYS commit** after successful implementation
+- Ensure the code builds (`go build`)
+- Ensure all tests pass (`go test`)
+- Verify all acceptance criteria are met
+- Write a clear, descriptive commit message
+
+---
+
+## 🏗️ Key Architectural Principles
+
+The project follows these core principles (documented in `requirements.md` and `playbook.md`):
+
+1. **Clean/Hexagonal Architecture**
+   - Clear separation between `pkg/` (interfaces) and `internal/` (implementations)
+   - Domain code in `internal/domain`
+   - Only interfaces exported from `pkg/`
+
+2. **Microservices Architecture**
+   - Each module is an independent service from day one
+   - Services communicate via gRPC/HTTP
+   - Service discovery via service registry
+
+3. **Plugin-First Design**
+   - Extensible architecture supporting static and dynamic modules
+   - Modules implement the `IModule` interface
+   - Module loader discovers and loads modules
+
+4. **Security-by-Design**
+   - JWT authentication
+   - RBAC/ABAC authorization
+   - Audit logging
+   - Context-based user propagation
+
+5. **Observability**
+   - OpenTelemetry integration
+   - Structured logging (Zap)
+   - Prometheus metrics
+   - Request correlation IDs
+
+6. **Dependency Injection**
+   - Using `uber-go/fx` for lifecycle management
+   - Constructor injection preferred
+   - Service registry pattern
+
+---
+
+## 📋 Quick Reference Checklist
+
+Before implementing any feature, verify:
+
+- [ ] Created a new branch for the feature/bugfix/enhancement
+- [ ] Read the relevant story from `/goplt/docs/content/stories/epicX/`
+- [ ] Reviewed architecture documents in `/goplt/docs/content/architecture/`
+- [ ] Checked applicable ADRs in `/goplt/docs/content/adr/`
+- [ ] Consulted `playbook.md` for implementation patterns
+- [ ] Understood the epic context and dependencies
+- [ ] Verified acceptance criteria are clear
+- [ ] Confirmed architectural alignment
+
+After implementing a feature, verify:
+
+- [ ] Code builds successfully (`go build`)
+- [ ] All tests pass (`go test`)
+- [ ] All acceptance criteria are met
+- [ ] Created a commit with a clear, descriptive message
+
+---
+
+## 🚫 Common Mistakes to Avoid
+
+1. **Working directly on main branch** - Always create a feature branch before making changes
+2. **Committing without verification** - Never commit code that doesn't build, has failing tests, or doesn't meet acceptance criteria
+3. **Implementing without checking stories** - Stories contain specific deliverables and acceptance criteria
+4. **Ignoring ADRs** - ADRs document why decisions were made; don't reinvent the wheel
+5. **Violating architecture principles** - Code must follow Clean/Hexagonal Architecture
+6. **Missing acceptance criteria** - All stories have specific criteria that must be met
+7. **Not following module patterns** - Modules must implement the `IModule` interface correctly
+8. **Skipping observability** - All features must include proper logging, metrics, and tracing
+9. **Breaking microservices boundaries** - Services must communicate via defined interfaces
+
+---
+
+## 📖 Additional Resources
+
+- **MkDocs Configuration**: `/goplt/docs/mkdocs.yml` - Documentation site configuration
+- **Docker Setup**: `/goplt/docs/Dockerfile` and `docker-compose.yml` - Development environment
+- **Makefile**: `/goplt/Makefile` - Build and development commands
+- **Story Generator**: `/goplt/docs/content/stories/generate_tasks.py` - Tool for generating story templates
+
+---
+
+## 💡 Tips for Agents
+
+1. **Use semantic search** to find relevant documentation when you're unsure
+2. **Read multiple related files** to get complete context
+3. **Check the epic README files** (`epicX/README.md`) for epic-level overviews
+4. **Review `COMPLETE_TASK_LIST.md`** for a comprehensive task overview
+5. **When in doubt, ask for clarification** rather than making assumptions
+
+---
+
+## 📝 Documentation Updates
+
+If you make architectural decisions or significant changes:
+1. Update relevant ADRs or create new ones
+2. Update architecture documents if structure changes
+3. Update stories if implementation details change
+4. Keep documentation in sync with code
+
+---
+
+**Remember: Documentation is the source of truth. Always consult it before making changes!**
+