## Summary Homogenize all 23 ADRs to a single canonical header format, and rewrite `adr/README.md` to match the actual state of the corpus. This is **Tâche 7** of the ARCODANGE Phase 1 migration (Claude Code → Mistral Vibe). Independent from PR #17 (Tâche 6 — restructure AGENTS.md) — both can merge in any order. No code changes; only documentation. ## Changes ### 1. Homogenize 21 ADR headers (commit `db09d0a`) The audit (Tâche 6 Phase A, Mistral intent-router agent, 2026-05-02) had identified **3 inconsistent header formats** : - **F1** — list bullets (`* Status:` / `* Date:` / `* Deciders:`) : 11 ADRs (0001-0008, 0011, 0014, 0023) - **F2** — bold fields (`**Status:**` / `**Date:**` / `**Authors:**`) : 9 ADRs (0009, 0010, 0012, 0013, 0015, 0016, 0017, 0018, 0019) - **F3** — dedicated section (`## Status\n**Value** ✅`) : 5 ADRs (0020, 0021, 0022, 0024, 0025) Plus mixed metadata names (Authors / Deciders / Decision Date / Implementation Date / Implementation Status / Last Updated) and decorative emojis on status values made the corpus hard to scan or template against. **Canonical format adopted** (see `adr/README.md` for full template) : ```markdown # NN. Title **Status:** <Proposed | Accepted | Implemented | Partially Implemented | Approved | Rejected | Deferred | Deprecated | Superseded by ADR-NNNN> **Date:** YYYY-MM-DD **Authors:** Name(s) [optional **Field:** ... lines] ## Context... ``` **Transformations applied** (via `/tmp/homogenize-adrs.py` script, 23 files scanned, 21 modified — 0010 and 0012 were already conform) : - F1 list bullets → bold fields - F2 cleanup : `**Deciders:**` → `**Authors:**`, strip status emojis - F3 sections : `## Status\n**Value** ✅` → `**Status:** Value` (single line) - Strip decorative emojis from `**Status:**` and `**Implementation Status:**` - Convert `* Last Updated:` / `* Implementation Status:` / `* Decision Drivers:` / `* Decision Date:` to bold - Date typo fix : `2024-04-XX` → `2026-04-XX` for ADRs 0018, 0019 (off-by-2-years in original) - Normalize multiple blank lines after header (max 1) **ADR body content is preserved unchanged.** Only headers transformed. ### 2. Rewrite `adr/README.md` (commit `d64ab02`) Previous README had multiple inconsistencies : - Index table listed wrong titles for ADRs 0010-0021 (looked like an aspirational forecast that never matched reality — e.g. "0011 = Trunk-Based Development" but real 0011 is absent and Trunk-Based Development is actually 0017) - Listed entries for ADRs 0011 (validation library) and 0014 (gRPC) but **these files do not exist** in the repo - 0024 (BDD Test Organization) was missing from the detail list - Template still showed the obsolete F1 format (`* Status:`) - Decorative emojis on every status entry Rewrite : - Index table **regenerated from actual file contents** (title from H1, status from `**Status:**` line) — emoji-free, accurate - Notes that 0011 / 0014 are not currently in use (reserved) - Updated template block matches the canonical format - Status Legend extended with `Approved`, `Partially Implemented`, `Deferred` - Added note that 0026 is the next free number for new ADRs ## Test plan - [x] All 23 ADRs follow `**Status:**` / `**Date:**` / `**Authors:**` (verified via grep) - [x] No more occurrences of `* Status:` (F1) or `## Status` (F3) in any ADR header - [x] No more emojis on `**Status:**` lines - [x] `adr/README.md` index links resolve to existing files (no more 0011 / 0014 dead links) - [x] Pre-commit hooks pass (`go mod tidy`, `go fmt`, `swag fmt`) ## Migration context Part of Phase 1 of the ARCODANGE migration from Claude Code to Mistral Vibe. Tâche 7 of the curriculum. Independent from PR #17 (which restructures `AGENTS.md`). The two PRs touch disjoint files — no merge conflict expected when both are merged. 🤖 Generated with [Claude Code](https://claude.com/claude-code) (Opus 4.7, 1M context). Mistral Vibe (intent-router agent / mistral-medium-3.5) did the original audit identifying the 3 formats during Tâche 6 Phase A. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Co-Authored-By: Mistral Vibe (devstral-2 / mistral-medium-3.5) Reviewed-on: #18 Co-authored-by: Gabriel Radureau <arcodange@gmail.com> Co-committed-by: Gabriel Radureau <arcodange@gmail.com>
3.8 KiB
3.8 KiB
Use Viper for configuration management
Status: Accepted Authors: Gabriel Radureau, AI Agent Date: 2026-04-03
Context and Problem Statement
We needed a configuration management solution for dance-lessons-coach that provides:
- Support for multiple configuration sources (files, environment variables, defaults)
- Configuration validation
- Type-safe configuration loading
- Hot reloading capabilities
- Good error handling and reporting
Decision Drivers
- Need for flexible configuration from multiple sources
- Desire for configuration validation
- Requirement for type-safe access to configuration
- Need for environment-specific configurations
- Desire for good error messages
Considered Options
- Viper - Popular configuration library with many features
- Koanf - Lightweight but powerful
- envconfig - Simple environment variable loading
- Custom solution - Build our own configuration loader
Decision Outcome
Chosen option: "Viper" because it provides comprehensive configuration management with support for multiple sources, good validation capabilities, type-safe loading, and is widely used in the Go ecosystem.
Pros and Cons of the Options
Viper
- Good, because supports multiple configuration sources
- Good, because good validation capabilities
- Good, because type-safe configuration loading
- Good, because widely used and well-documented
- Good, because supports hot reloading
- Bad, because slightly heavier than alternatives
- Bad, because more complex API
Koanf
- Good, because lightweight
- Good, because good performance
- Good, because simple API
- Bad, because less feature-rich than Viper
- Bad, because smaller community
envconfig
- Good, because very simple
- Good, because good for environment variables
- Bad, because limited to environment variables
- Bad, because no file support
Custom solution
- Good, because tailored to our needs
- Good, because no external dependencies
- Bad, because time-consuming to develop
- Bad, because need to maintain ourselves
- Bad, because likely less feature-rich
Implementation Example
// Configuration structure
type Config struct {
Server ServerConfig `mapstructure:"server"`
Shutdown ShutdownConfig `mapstructure:"shutdown"`
Logging LoggingConfig `mapstructure:"logging"`
}
// Loading configuration
func LoadConfig() (*Config, error) {
v := viper.New()
// Set defaults
v.SetDefault("server.host", "0.0.0.0")
v.SetDefault("server.port", 8080)
// Read config file
v.SetConfigName("config")
v.SetConfigType("yaml")
v.AddConfigPath(".")
if err := v.ReadInConfig(); err != nil {
if _, ok := err.(viper.ConfigFileNotFoundError); !ok {
return nil, err
}
}
// Bind environment variables
v.AutomaticEnv()
v.SetEnvPrefix("DLC")
// Unmarshal into struct
var config Config
if err := v.Unmarshal(&config); err != nil {
return nil, err
}
return &config, nil
}
Configuration Priority
The implementation follows this priority order:
- Config file (highest priority)
- Environment variables (override defaults)
- Default values (lowest priority)
Links
Configuration File Example
# config.yaml
server:
host: "0.0.0.0"
port: 8080
shutdown:
timeout: 30s
logging:
json: false
level: "trace"
Environment Variables
# Set configuration via environment variables
export DLC_SERVER_HOST="0.0.0.0"
export DLC_SERVER_PORT=8080
export DLC_SHUTDOWN_TIMEOUT=30s
export DLC_LOGGING_JSON=false