## 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>
228 lines
7.3 KiB
Markdown
228 lines
7.3 KiB
Markdown
# 15. CLI Subcommands and Flag Management with Cobra
|
|
|
|
**Date:** 2026-04-05
|
|
**Status:** Implemented
|
|
**Authors:** Arcodange Team
|
|
**Decision Date:** 2026-04-05
|
|
**Implementation Status:** Phase 1 Complete
|
|
|
|
## Context
|
|
|
|
As dance-lessons-coach grows, we need a more robust and maintainable CLI structure. Currently, we use simple flag parsing (`--version`), but this approach has limitations:
|
|
|
|
1. **Limited scalability**: Adding more commands/flags becomes messy
|
|
2. **Poor user experience**: No built-in help, completion, or validation
|
|
3. **Hard to maintain**: Manual flag parsing is error-prone
|
|
4. **No subcommands**: Can't easily add commands like `server start`, `server stop`, etc.
|
|
|
|
## Decision Drivers
|
|
|
|
* **Scalability**: Support growing CLI needs as project expands
|
|
* **User Experience**: Provide professional CLI with help, completion, validation
|
|
* **Maintainability**: Easy to add/remove commands and flags
|
|
* **Standards**: Follow industry best practices for CLI tools
|
|
* **Extensibility**: Support future commands (migrate, seed, etc.)
|
|
* **Integration**: Work well with existing config system
|
|
|
|
## Decision
|
|
|
|
We will adopt **Cobra** as our CLI framework. Cobra is a mature, widely-used library for building modern CLI applications in Go.
|
|
|
|
### Selected Solution: Cobra CLI Framework
|
|
|
|
**Repository**: https://github.com/spf13/cobra
|
|
**Version**: v1.8.0 (or latest stable)
|
|
|
|
### Key Features
|
|
|
|
1. **Subcommands**: `server start`, `server stop`, `migrate`, etc.
|
|
2. **Flags**: `--config`, `--env`, `--verbose`, etc.
|
|
3. **Help System**: Automatic `--help` generation
|
|
4. **Shell Completion**: Built-in support
|
|
5. **Validation**: Type-safe flag parsing
|
|
6. **Middleware**: Pre/post command hooks
|
|
|
|
### Implementation Plan
|
|
|
|
#### Phase 1: Basic Integration (✅ COMPLETED)
|
|
|
|
**Implemented in:** `cmd/cli/main.go`
|
|
|
|
```go
|
|
var rootCmd = &cobra.Command{
|
|
Use: "dance-lessons-coach",
|
|
Short: "dance-lessons-coach - API server and CLI tools",
|
|
Long: `dance-lessons-coach provides greeting services and API management.
|
|
|
|
To begin working with dance-lessons-coach, run:
|
|
dance-lessons-coach server --help`,
|
|
SilenceUsage: true,
|
|
}
|
|
|
|
var versionCmd = &cobra.Command{
|
|
Use: "version",
|
|
Short: "Print version information",
|
|
Run: func(cmd *cobra.Command, args []string) {
|
|
fmt.Println(version.Full())
|
|
},
|
|
}
|
|
|
|
var serverCmd = &cobra.Command{
|
|
Use: "server",
|
|
Short: "Start the dance-lessons-coach server",
|
|
Run: func(cmd *cobra.Command, args []string) {
|
|
// Load config and start server
|
|
cfg, err := config.LoadConfig()
|
|
if err != nil {
|
|
log.Fatal().Err(err).Msg("Failed to load configuration")
|
|
}
|
|
server := server.NewServer(cfg, context.Background())
|
|
if err := server.Run(); err != nil {
|
|
log.Fatal().Err(err).Msg("Server failed")
|
|
}
|
|
},
|
|
}
|
|
|
|
var greetCmd = &cobra.Command{
|
|
Use: "greet [name]",
|
|
Short: "Greet someone by name",
|
|
Args: cobra.MaximumNArgs(1),
|
|
Run: func(cmd *cobra.Command, args []string) {
|
|
name := ""
|
|
if len(args) > 0 {
|
|
name = args[0]
|
|
}
|
|
fmt.Printf("Hello %s!\n", name)
|
|
},
|
|
}
|
|
|
|
func init() {
|
|
rootCmd.AddCommand(versionCmd)
|
|
rootCmd.AddCommand(serverCmd)
|
|
rootCmd.AddCommand(greetCmd)
|
|
|
|
// Add flags to server command
|
|
serverCmd.Flags().String("config", "", "Config file path")
|
|
serverCmd.Flags().String("env", "", "Environment (dev, staging, prod)")
|
|
serverCmd.Flags().Bool("debug", false, "Enable debug logging")
|
|
}
|
|
|
|
func main() {
|
|
if err := rootCmd.Execute(); err != nil {
|
|
log.Fatal().Err(err).Msg("CLI execution failed")
|
|
}
|
|
}
|
|
```
|
|
|
|
**Current Commands:**
|
|
- `version`: Print version information
|
|
- `server`: Start the dance-lessons-coach server
|
|
- `greet [name]`: Greet someone by name
|
|
- `help`: Built-in help system
|
|
- `completion`: Shell completion scripts (automatic)
|
|
|
|
**Current Flags:**
|
|
- `--config`: Config file path (server command)
|
|
- `--env`: Environment (dev, staging, prod) (server command)
|
|
- `--debug`: Enable debug logging (server command)
|
|
- `--help`: Help for any command (built-in)
|
|
|
|
#### Phase 2: Advanced Features (Future)
|
|
- **Subcommand groups**: `server`, `db`, `migrate`, `tools`
|
|
- **Persistent flags**: Global flags like `--config`, `--env`
|
|
- **Command aliases**: Shorter command names
|
|
- **Custom help templates**: Branded help output
|
|
- **Shell completion scripts**: Generate completion for bash/zsh/fish
|
|
|
|
#### Phase 3: Migration (Ongoing)
|
|
- Migrate existing flags to Cobra
|
|
- Deprecate old flag parsing
|
|
- Update documentation
|
|
- Add new commands as needed
|
|
|
|
### Migration Strategy
|
|
|
|
1. **Incremental adoption**: Start with version command, then server command
|
|
2. **Backward compatibility**: Support old flags during transition
|
|
3. **Documentation**: Update README with new CLI usage
|
|
4. **Testing**: Ensure all existing functionality works
|
|
|
|
### Command Structure Proposal
|
|
|
|
```bash
|
|
# Main commands
|
|
dance-lessons-coach server # Start the server
|
|
dance-lessons-coach version # Show version
|
|
dance-lessons-coach migrate # Database migrations
|
|
dance-lessons-coach config # Config management
|
|
|
|
# Server subcommands
|
|
dance-lessons-coach server start # Start server
|
|
dance-lessons-coach server stop # Stop server
|
|
dance-lessons-coach server restart # Restart server
|
|
dance-lessons-coach server status # Server status
|
|
|
|
# Global flags
|
|
dance-lessons-coach --help # Show help
|
|
dance-lessons-coach --version # Show version (shortcut)
|
|
dance-lessons-coach --config /path/to/config.yaml
|
|
|
|
# Example usage
|
|
dance-lessons-coach server start --env production --debug
|
|
dance-lessons-coach migrate up
|
|
dance-lessons-coach config validate
|
|
```
|
|
|
|
### Pros and Cons of Cobra
|
|
|
|
#### ✅ Advantages
|
|
1. **Industry Standard**: Used by Kubernetes, Hugo, etcd, and many others
|
|
2. **Mature Ecosystem**: Well-documented, widely adopted
|
|
3. **Feature Rich**: Help, completion, validation built-in
|
|
4. **Extensible**: Easy to add new commands
|
|
5. **Go Idiomatic**: Fits well with Go patterns
|
|
6. **Good Documentation**: Excellent docs and examples
|
|
|
|
#### ❌ Disadvantages
|
|
1. **Learning Curve**: New patterns to learn
|
|
2. **Migration Effort**: Need to refactor existing code
|
|
3. **Slight Overhead**: More complex than simple flag parsing
|
|
4. **Dependency**: Adds cobra to project
|
|
|
|
### Validation
|
|
|
|
**Does this meet our requirements?**
|
|
- ✅ **Scalability**: Easy to add new commands
|
|
- ✅ **User Experience**: Professional CLI with help/completion
|
|
- ✅ **Maintainability**: Clean, structured code
|
|
- ✅ **Standards**: Follows industry best practices
|
|
- ✅ **Extensibility**: Supports future growth
|
|
- ✅ **Integration**: Works with existing config system
|
|
|
|
**What's still needed?**
|
|
- ✅ **Implementation**: Actual cobra integration (Phase 1 complete)
|
|
- ❌ **Migration**: Move existing flags to cobra (Phase 2)
|
|
- ❌ **Documentation**: Update docs with new CLI (Phase 2)
|
|
- ❌ **Testing**: Ensure all functionality works (Phase 2)
|
|
|
|
### Future Enhancements
|
|
|
|
1. **Add more commands**: `migrate`, `config`, `db`, etc.
|
|
2. **Improve help**: Custom templates, examples
|
|
3. **Add completion**: Shell completion scripts
|
|
4. **Enhance validation**: Better error messages
|
|
5. **Add aliases**: Shorter command names
|
|
|
|
### References
|
|
|
|
- [Cobra GitHub](https://github.com/spf13/cobra)
|
|
- [Cobra Documentation](https://cobra.dev/)
|
|
- [CLI Guidelines](https://clig.dev/)
|
|
- [Go CLI Best Practices](https://github.com/clig-dev/clig)
|
|
|
|
---
|
|
|
|
**Status:** Proposed
|
|
**Next Review:** 2026-04-12
|
|
**Implementation Owner:** Arcodange Team
|
|
**Approvers Needed:** @gabrielradureau |