LoadConfig() tried to create directories and write opal.yml as a side
effect of loading config. On the server (where /etc/opal is in systemd
ReadOnlyPaths), this failed, returning nil. All internal GetConfig()
callers discarded the error, passing nil to BuildUrgencyCoefficients()
which panicked on nil dereference.
Redesign the config system with layered, read-only loading:
- Defaults (always present) → YAML file (if exists) → OPAL_ env vars
- LoadConfig never writes to the filesystem or returns nil
- File creation moved to explicit InitConfig() for CLI first-run/setup
- SaveConfig uses yaml.Marshal instead of manual field-by-field Viper
calls, eliminating the three-place maintenance burden
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Replace cobra.OnInitialize with PersistentPreRun pattern to fix initialization
issues with setup and server commands. This follows Cobra best practices and
allows subcommands to properly override initialization behavior.
Problem:
- OnInitialize runs globally before command parsing
- os.Args check for 'setup' was fragile and broke with flags
- Setup wizard failed on server: 'unable to open database file: no such file
or directory'
Solution:
- Use rootCmd.PersistentPreRun for initialization (inherited by all commands)
- setup and server commands override with their own PersistentPreRun
- Directory overrides still applied correctly in all cases
- Removes fragile os.Args parsing
Benefits:
- Works regardless of flag order
- Follows Cobra's intended design patterns
- Only 3 files modified (root.go, setup.go, server.go)
- Commands that need custom init (setup/server) simply override
- All other commands get automatic initialization
- Cleaner, more maintainable code
Testing:
- ✓ opal setup works without initialization errors
- ✓ opal list initializes database correctly
- ✓ First-run detection still works
- ✓ Directory overrides work with flags in any position
- ✓ Server command handles its own initialization
Display the default config and data directories before prompting
the user if they want to customize them. This gives better context
for the decision.
Before: Only showed directories if user chose not to customize
After: Shows directories first, then asks if user wants to change them
Implement a comprehensive setup wizard to improve onboarding and
configuration experience for both personal and server deployments.
Key features:
- Interactive wizard with profile selection (personal/server/custom)
- Quick setup mode with sensible defaults
- First-run detection with helpful welcome message
- Directory configuration with validation
- Server OAuth/JWT configuration with auto-generation
- Environment file creation for server deployments
- Template generators for systemd service and env files
New commands:
- opal setup # Interactive wizard
- opal setup --quick # Quick setup with defaults
- opal setup --profile # Use specific profile
- opal setup --show-systemd # Show systemd template
- opal setup --show-env # Show environment file template
Implementation:
- internal/wizard/prompts.go: Reusable prompt utilities
- internal/wizard/profiles.go: Profile definitions and templates
- cmd/setup.go: Main setup command implementation
- cmd/root.go: First-run detection and welcome message
- internal/engine/config.go: ConfigExists() and IsFirstRun() helpers
User experience:
- On first run, shows welcome message suggesting 'opal setup'
- Non-intrusive - creates defaults automatically if skipped
- Wizard guides through all configuration options
- Server setup includes OAuth/JWT configuration
- Environment file created with proper permissions (0600)
- Clear next steps displayed after completion
joakim