📝 docs(restructure): split AGENTS.md (1296 → 130 lines) + 9 focused guides #17
@@ -4,6 +4,8 @@
|
||||
* Deciders: Gabriel Radureau, AI Agent
|
||||
* Date: 2026-04-05
|
||||
|
||||
> **⚠️ Structure superseded by ADR-0024.** The framework decision (Godog, in-process test server) remains valid. However, the flat `features/` layout and single `steps.go` file described here were replaced by a modular per-domain structure. See ADR-0024 for the current organisation: `features/{auth,greet,health,jwt,config}/` with domain-specific step files and per-domain `*_test.go` runners. The `cd features && godog` execution pattern is also outdated — each domain now uses `go test`.
|
||||
|
||||
## Context and Problem Statement
|
||||
|
||||
We needed to add behavioral testing to dance-lessons-coach that provides:
|
||||
|
||||
@@ -1,10 +1,11 @@
|
||||
# Combine BDD and Swagger-based testing
|
||||
# BDD Testing with OpenAPI Documentation
|
||||
|
||||
* Status: ✅ Partially Implemented (BDD + Documentation only)
|
||||
* Status: Accepted
|
||||
* Deciders: Gabriel Radureau, AI Agent
|
||||
* Date: 2026-04-05
|
||||
* Last Updated: 2026-04-05
|
||||
* Implementation Status: BDD testing and OpenAPI documentation completed, SDK generation deferred
|
||||
* Last Updated: 2026-04-12
|
||||
|
||||
> **⚠️ Title corrected.** This ADR was originally named "Combine BDD and Swagger-based testing" with the intent of eventually adding SDK-generated BDD tests as a second layer ("hybrid"). That second layer was deferred and has no concrete plan. The actual architecture is **BDD direct-HTTP testing + OpenAPI documentation via swaggo** — calling it "hybrid" is misleading. SDK generation remains a possible future enhancement but is not tracked by any open issue.
|
||||
|
||||
## Context and Problem Statement
|
||||
|
||||
|
||||
@@ -378,68 +378,6 @@ Added to `.gitea/workflows/go-ci-cd.yaml` lint-format job:
|
||||
# Format swagger comments manually
|
||||
swag fmt
|
||||
|
||||
# Format is automatically run in:
|
||||
# - pre-commit hook
|
||||
# - CI/CD lint-format job
|
||||
```
|
||||
=======
|
||||
### Final Implementation
|
||||
|
||||
```bash
|
||||
# 1. Install swaggo
|
||||
go install github.com/swaggo/swag/cmd/swag@latest
|
||||
|
||||
# 2. Add swagger metadata to main.go
|
||||
// @title dance-lessons-coach API
|
||||
// @version 1.0
|
||||
// @description API for dance-lessons-coach service
|
||||
// @host localhost:8080
|
||||
// @BasePath /api
|
||||
package main
|
||||
```
|
||||
|
||||
### Swag Formatting Integration
|
||||
|
||||
To ensure consistent swagger comment formatting, we've integrated `swag fmt` into our workflow:
|
||||
|
||||
#### Git Hooks
|
||||
Added to `.git/hooks/pre-commit`:
|
||||
```bash
|
||||
# Run swag fmt to format swagger comments
|
||||
echo "Running swag fmt..."
|
||||
if command -v swag >/dev/null 2>&1; then
|
||||
swag fmt
|
||||
if [ $? -ne 0 ]; then
|
||||
echo "ERROR: swag fmt failed"
|
||||
exit 1
|
||||
fi
|
||||
else
|
||||
echo "swag not installed, skipping swag fmt"
|
||||
fi
|
||||
```
|
||||
|
||||
#### CI/CD Integration
|
||||
Added to `.gitea/workflows/go-ci-cd.yaml` lint-format job:
|
||||
```yaml
|
||||
- name: Install swag
|
||||
run: go install github.com/swaggo/swag/cmd/swag@latest
|
||||
|
||||
- name: Run swag fmt
|
||||
run: swag fmt
|
||||
```
|
||||
|
||||
#### Benefits
|
||||
- **Consistent Formatting**: Automatic formatting of swagger comments
|
||||
- **Pre-Commit Validation**: Catches issues before commit
|
||||
- **CI/CD Enforcement**: Ensures formatting in all pull requests
|
||||
- **Team Consistency**: Everyone follows the same rules
|
||||
- **Automatic Fixes**: Issues are fixed automatically
|
||||
|
||||
#### Usage
|
||||
```bash
|
||||
# Format swagger comments manually
|
||||
swag fmt
|
||||
|
||||
# Format is automatically run in:
|
||||
# - pre-commit hook
|
||||
# - CI/CD lint-format job
|
||||
|
||||
@@ -222,7 +222,7 @@ dance-lessons-coach config validate
|
||||
|
||||
---
|
||||
|
||||
**Status:** Proposed
|
||||
**Next Review:** 2026-04-12
|
||||
**Status:** Accepted
|
||||
**Implementation Date:** 2026-04-05
|
||||
**Implementation Owner:** Arcodange Team
|
||||
**Approvers Needed:** @gabrielradureau
|
||||
**Approved by:** @gabrielradureau
|
||||
@@ -1,7 +1,8 @@
|
||||
# 18. User Management and Authentication System
|
||||
|
||||
**Date:** 2024-04-06
|
||||
**Status:** Proposed
|
||||
**Status:** Accepted
|
||||
**Implementation Date:** 2026-04-08
|
||||
**Authors:** Product Owner
|
||||
**Decision Drivers:** Security, User Personalization, Admin Functionality
|
||||
|
||||
|
||||
@@ -1,10 +1,13 @@
|
||||
# 19. PostgreSQL Database Integration
|
||||
|
||||
**Date:** 2024-04-07
|
||||
**Status:** Proposed
|
||||
**Status:** Accepted (Partial)
|
||||
**Implementation Date:** 2026-04-08
|
||||
**Authors:** Product Owner
|
||||
**Decision Drivers:** Data Persistence, Scalability, Production Readiness
|
||||
|
||||
> **⚠️ Pending cleanup:** `pkg/user/sqlite_repository.go` and `gorm.io/driver/sqlite` still present in the codebase. The ADR requires their removal, but no Gitea issue tracks this yet. The PostgreSQL implementation (`pkg/user/postgres_repository.go`) is complete and in use.
|
||||
|
||||
## Context
|
||||
|
||||
The dance-lessons-coach application currently uses SQLite with GORM for the user management system (ADR 0018), but since there are no existing users or production data, we can implement PostgreSQL directly as our primary database without migration concerns.
|
||||
|
||||
@@ -1,11 +1,13 @@
|
||||
# 10. JWT Secret Retention Policy
|
||||
# 21. JWT Secret Retention Policy
|
||||
|
||||
## Status
|
||||
**Proposed** 🟡
|
||||
|
||||
> **Note:** Basic JWT multi-secret support and graceful rotation are implemented in `pkg/jwt/jwt_secret_manager.go`. The retention cleanup policy (background job, configurable TTL factor) proposed in this ADR is **not yet implemented**.
|
||||
|
||||
## Context
|
||||
|
||||
The dance-lessons-coach application requires a robust JWT secret management system that balances security and user experience. As implemented in [ADR-0009](0009-hybrid-testing-approach.md), the system supports multiple JWT secrets for graceful rotation. However, the current implementation lacks a clear policy for secret retention and cleanup.
|
||||
The dance-lessons-coach application requires a robust JWT secret management system that balances security and user experience. The system supports multiple JWT secrets for graceful rotation. However, the current implementation lacks a clear policy for secret retention and cleanup.
|
||||
|
||||
### Current State
|
||||
|
||||
@@ -386,8 +388,8 @@ func maskSecret(secret string) string {
|
||||
|
||||
## References
|
||||
|
||||
- [ADR-0009: Hybrid Testing Approach](0009-hybrid-testing-approach.md)
|
||||
- [ADR-0008: BDD Testing](0008-bdd-testing.md)
|
||||
- [ADR-0018: User Management and Auth System](0018-user-management-auth-system.md)
|
||||
- [RFC 7519: JSON Web Tokens](https://tools.ietf.org/html/rfc7519)
|
||||
- [OWASP Key Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Key_Management_Cheat_Sheet.html)
|
||||
|
||||
|
||||
@@ -3,6 +3,8 @@
|
||||
## Status
|
||||
**Proposed** 🟡
|
||||
|
||||
> **⚠️ Not yet implemented.** Gitea issue #13 ("feat: Implement Rate Limiting and Caching Strategy") is open and tracks this work. `go-cache`, `redis`, and `ulule/limiter` are absent from `go.mod`. The phase checkboxes below are corrected to reflect actual status.
|
||||
|
||||
## Context
|
||||
|
||||
As the dance-lessons-coach application grows and potentially serves multiple users simultaneously, we need to implement rate limiting to:
|
||||
@@ -284,38 +286,38 @@ func GetCacheKey(prefix, entityType, entityID string) string {
|
||||
## Implementation Phases
|
||||
|
||||
### Phase 1: In-Memory Cache (Current Sprint)
|
||||
- ✅ Research and select in-memory cache library
|
||||
- ✅ Implement cache interface and in-memory service
|
||||
- ✅ Add cache configuration to config package
|
||||
- ✅ Implement basic cache operations (set, get, delete)
|
||||
- ✅ Add TTL support and automatic cleanup
|
||||
- ✅ Cache JWT validation results
|
||||
- ✅ Add cache metrics and monitoring
|
||||
- ❌ Research and select in-memory cache library
|
||||
- ❌ Implement cache interface and in-memory service
|
||||
- ❌ Add cache configuration to config package
|
||||
- ❌ Implement basic cache operations (set, get, delete)
|
||||
- ❌ Add TTL support and automatic cleanup
|
||||
- ❌ Cache JWT validation results
|
||||
- ❌ Add cache metrics and monitoring
|
||||
|
||||
### Phase 2: Redis-Compatible Cache (Next Sprint)
|
||||
- ✅ Set up Dragonfly/KeyDB in development environment
|
||||
- ✅ Implement Redis cache service
|
||||
- ✅ Add configuration for Redis connection
|
||||
- ✅ Implement cache fallback strategy (Redis → in-memory)
|
||||
- ✅ Add health checks for Redis connection
|
||||
- ✅ Implement distributed cache invalidation
|
||||
- ❌ Set up Dragonfly/KeyDB in development environment
|
||||
- ❌ Implement Redis cache service
|
||||
- ❌ Add configuration for Redis connection
|
||||
- ❌ Implement cache fallback strategy (Redis → in-memory)
|
||||
- ❌ Add health checks for Redis connection
|
||||
- ❌ Implement distributed cache invalidation
|
||||
|
||||
### Phase 3: Rate Limiting (Following Sprint)
|
||||
- ✅ Research and select rate limiting library
|
||||
- ✅ Implement rate limiter service
|
||||
- ✅ Add rate limit configuration
|
||||
- ✅ Implement Chi middleware for rate limiting
|
||||
- ✅ Add rate limit headers to responses
|
||||
- ✅ Implement IP whitelisting
|
||||
- ✅ Add endpoint-specific rate limits
|
||||
- ❌ Research and select rate limiting library
|
||||
- ❌ Implement rate limiter service
|
||||
- ❌ Add rate limit configuration
|
||||
- ❌ Implement Chi middleware for rate limiting
|
||||
- ❌ Add rate limit headers to responses
|
||||
- ❌ Implement IP whitelisting
|
||||
- ❌ Add endpoint-specific rate limits
|
||||
|
||||
### Phase 4: Advanced Features (Future)
|
||||
- ✅ Cache warming for critical data
|
||||
- ✅ Two-level caching (Redis + in-memory)
|
||||
- ✅ Cache compression for large objects
|
||||
- ✅ Rate limit exemptions for admin users
|
||||
- ✅ Dynamic rate limit adjustment
|
||||
- ✅ Cache analytics and usage patterns
|
||||
- ❌ Cache warming for critical data
|
||||
- ❌ Two-level caching (Redis + in-memory)
|
||||
- ❌ Cache compression for large objects
|
||||
- ❌ Rate limit exemptions for admin users
|
||||
- ❌ Dynamic rate limit adjustment
|
||||
- ❌ Cache analytics and usage patterns
|
||||
|
||||
## Configuration
|
||||
|
||||
|
||||
@@ -4,6 +4,8 @@
|
||||
* Deciders: Gabriel Radureau, AI Agent
|
||||
* Date: 2026-04-05
|
||||
|
||||
> **⚠️ Not yet implemented.** No `ConfigManager` exists in `pkg/config/` and Viper's `WatchConfig()` is not wired up. However, `features/config/config_hot_reloading.feature` has been written — BDD scenarios exist for a feature that is not yet built. Those tests are expected to fail until implementation begins.
|
||||
|
||||
## Context and Problem Statement
|
||||
|
||||
The dance-lessons-coach application currently loads configuration once at startup using Viper, which supports file-based configuration, environment variables, and defaults. However, the current implementation does not support runtime configuration changes without restarting the application.
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
# ADR 0024: BDD Test Organization and Isolation Strategy
|
||||
|
||||
## Status
|
||||
**Proposed** 🟡
|
||||
**Accepted** ✅
|
||||
|
||||
## Context
|
||||
|
||||
|
||||
@@ -1,7 +1,10 @@
|
||||
# ADR 0025: BDD Scenario Isolation Strategies
|
||||
|
||||
## Status
|
||||
**Proposed** 🟡
|
||||
**Accepted (Partial)** 🟡
|
||||
|
||||
Phase 1 (schema-per-scenario DB isolation + `ScenarioState` manager in `pkg/bdd/steps/scenario_state.go`) is implemented.
|
||||
Phase 2 (cache key prefix strategy, in-memory store `Reset()` methods) is pending — blocked on ADR-0022 (rate limiting/cache) not yet implemented.
|
||||
|
||||
## Context
|
||||
|
||||
|
||||
@@ -13,24 +13,24 @@ This directory contains Architecture Decision Records (ADRs) for the dance-lesso
|
||||
| 0005 | Graceful Shutdown | ✅ Accepted |
|
||||
| 0006 | Configuration Management | ✅ Accepted |
|
||||
| 0007 | OpenTelemetry Integration | ✅ Accepted |
|
||||
| 0008 | BDD Testing | ✅ Accepted |
|
||||
| 0009 | Hybrid Testing Approach | ✅ Accepted |
|
||||
| 0010 | CI/CD Pipeline Design | ✅ Accepted |
|
||||
| 0011 | Trunk-Based Development | ✅ Accepted |
|
||||
| 0012 | Commit Message Conventions | ✅ Accepted |
|
||||
| 0013 | Version Management Lifecycle | ✅ Accepted |
|
||||
| 0014 | Swagger Documentation | ✅ Accepted |
|
||||
| 0015 | Rate Limiting Strategy | ✅ Accepted |
|
||||
| 0016 | Cache Invalidation Strategy | ✅ Accepted |
|
||||
| 0017 | JWT Secret Rotation | ✅ Accepted |
|
||||
| 0018 | Configuration Hot Reloading | ✅ Accepted |
|
||||
| 0019 | BDD Feature Structure | ✅ Accepted |
|
||||
| 0020 | Database Migration Strategy | ✅ Accepted |
|
||||
| 0021 | API Versioning Strategy | ✅ Accepted |
|
||||
| 0022 | Rate Limiting and Cache Strategy | ✅ Accepted |
|
||||
| 0023 | Config Hot Reloading | 🟡 Proposed |
|
||||
| 0024 | BDD Test Organization and Isolation | 🟡 Proposed |
|
||||
| 0025 | BDD Scenario Isolation Strategies | 🟡 Proposed |
|
||||
| 0008 | BDD Testing with Godog | ✅ Accepted (structure superseded by 0024) |
|
||||
| 0009 | BDD Testing with OpenAPI Documentation | ✅ Accepted |
|
||||
| 0010 | API v2 Feature Flag | ✅ Accepted |
|
||||
| 0011 | Validation Library (go-playground/validator) | ✅ Accepted |
|
||||
| 0012 | Git Hooks: Staged-Only Formatting | ✅ Accepted |
|
||||
| 0013 | OpenAPI/Swagger Toolchain (swaggo/swag) | ✅ Accepted |
|
||||
| 0014 | gRPC Adoption Strategy | ❌ Rejected / Deferred |
|
||||
| 0015 | CLI Subcommands with Cobra | ✅ Accepted |
|
||||
| 0016 | CI/CD Pipeline Design | ✅ Accepted |
|
||||
| 0017 | Trunk-Based Development Workflow | ✅ Accepted |
|
||||
| 0018 | User Management and Auth System | ✅ Accepted |
|
||||
| 0019 | PostgreSQL Integration | ✅ Accepted (SQLite cleanup pending) |
|
||||
| 0020 | Docker Build Strategy | ✅ Accepted |
|
||||
| 0021 | JWT Secret Retention Policy | 🟡 Proposed (base JWT done; cleanup job not implemented) |
|
||||
| 0022 | Rate Limiting and Cache Strategy | 🟡 Proposed (not implemented — Gitea issue #13) |
|
||||
| 0023 | Config Hot Reloading | 🟡 Proposed (not implemented) |
|
||||
| 0024 | BDD Test Organization and Isolation | ✅ Accepted |
|
||||
| 0025 | BDD Scenario Isolation Strategies | ✅ Accepted (Partial — Phase 2 pending ADR-0022) |
|
||||
|
||||
## What is an ADR?
|
||||
|
||||
@@ -96,23 +96,24 @@ Chosen option: "[Option 1]" because [justification]
|
||||
* [0005-graceful-shutdown.md](0005-graceful-shutdown.md) - Implement graceful shutdown with readiness endpoints
|
||||
* [0006-configuration-management.md](0006-configuration-management.md) - Use Viper for configuration management
|
||||
* [0007-opentelemetry-integration.md](0007-opentelemetry-integration.md) - Integrate OpenTelemetry for distributed tracing
|
||||
* [0008-bdd-testing.md](0008-bdd-testing.md) - Adopt BDD with Godog for behavioral testing
|
||||
* [0009-hybrid-testing-approach.md](0009-hybrid-testing-approach.md) - Combine BDD and Swagger-based testing
|
||||
* [0008-bdd-testing.md](0008-bdd-testing.md) - Adopt BDD with Godog for behavioral testing (structure superseded by 0024)
|
||||
* [0009-hybrid-testing-approach.md](0009-hybrid-testing-approach.md) - BDD testing with OpenAPI documentation (SDK layer deferred)
|
||||
* [0010-api-v2-feature-flag.md](0010-api-v2-feature-flag.md) - API v2 implementation with feature flag control
|
||||
* [0011-validation-library-selection.md](0011-validation-library-selection.md) - Selection of go-playground/validator for input validation
|
||||
* [0012-git-hooks-staged-only-formatting.md](0012-git-hooks-staged-only-formatting.md) - Git hooks format only staged Go files
|
||||
* [0013-openapi-swagger-toolchain.md](0013-openapi-swagger-toolchain.md) - ✅ OpenAPI/Swagger documentation with swaggo/swag (Implemented)
|
||||
* [0014-grpc-adoption-strategy.md](0014-grpc-adoption-strategy.md) - Hybrid REST/gRPC adoption strategy
|
||||
* [0013-openapi-swagger-toolchain.md](0013-openapi-swagger-toolchain.md) - OpenAPI/Swagger documentation with swaggo/swag
|
||||
* [0014-grpc-adoption-strategy.md](0014-grpc-adoption-strategy.md) - gRPC adoption strategy (rejected/deferred)
|
||||
* [0015-cli-subcommands-cobra.md](0015-cli-subcommands-cobra.md) - Cobra CLI framework adoption
|
||||
* [0016-ci-cd-pipeline-design.md](0016-ci-cd-pipeline-design.md) - CI/CD pipeline architecture
|
||||
* [0017-trunk-based-development-workflow.md](0017-trunk-based-development-workflow.md) - Trunk-based development workflow
|
||||
* [0018-user-management-auth-system.md](0018-user-management-auth-system.md) - User management and authentication system
|
||||
* [0019-postgresql-integration.md](0019-postgresql-integration.md) - PostgreSQL database integration
|
||||
* [0020-docker-build-strategy.md](0020-docker-build-strategy.md) - Docker Build Strategy: Traditional vs Buildx
|
||||
* [0021-jwt-secret-retention-policy.md](0021-jwt-secret-retention-policy.md) - JWT Secret Retention Policy with Configurable TTL and Retention
|
||||
* [0022-rate-limiting-cache-strategy.md](0022-rate-limiting-cache-strategy.md) - Rate Limiting and Cache Strategy with Multi-Phase Implementation
|
||||
* [0023-config-hot-reloading.md](0023-config-hot-reloading.md) - Config Hot Reloading Strategy
|
||||
* [0025-bdd-scenario-isolation-strategies.md](0025-bdd-scenario-isolation-strategies.md) - Schema-per-scenario isolation for BDD tests
|
||||
* [0021-jwt-secret-retention-policy.md](0021-jwt-secret-retention-policy.md) - JWT Secret Retention Policy (base JWT done; cleanup job proposed)
|
||||
* [0022-rate-limiting-cache-strategy.md](0022-rate-limiting-cache-strategy.md) - Rate Limiting and Cache Strategy (not yet implemented — issue #13)
|
||||
* [0023-config-hot-reloading.md](0023-config-hot-reloading.md) - Config Hot Reloading Strategy (not yet implemented)
|
||||
* [0024-bdd-test-organization-and-isolation.md](0024-bdd-test-organization-and-isolation.md) - BDD test modular organisation by domain
|
||||
* [0025-bdd-scenario-isolation-strategies.md](0025-bdd-scenario-isolation-strategies.md) - Schema-per-scenario isolation for BDD tests (partial)
|
||||
|
||||
## How to Add a New ADR
|
||||
|
||||
|
||||
Reference in New Issue
Block a user