Separate configuration from data storage and make paths configurable
via environment variables and command-line flags. This improves
Unix/Linux compliance and supports both development and production
deployments.
Key changes:
- Separate config dir (opal.yml) from data dir (database, logs)
- Support XDG Base Directory specification
- Add --config-dir and --data-dir flags
- Environment variables: OPAL_CONFIG_DIR, OPAL_DATA_DIR, OPAL_DB_PATH
- Smart fallback: /etc/opal, /var/lib/opal -> ~/.config/opal, ~/.local/share/opal
- Server mode validates required OAuth/JWT environment variables
- Update naming from 'jade' to 'opal' throughout
- Update systemd service name to 'opal.service'
- Add migration guide in README
Default paths:
- Config: /etc/opal (fallback: ~/.config/opal)
- Data: /var/lib/opal (fallback: ~/.local/share/opal)
Files modified:
- internal/engine/config.go: New directory resolution logic
- internal/engine/database.go: Auto-create data directory
- cmd/root.go: Add global flags for directory overrides
- cmd/server.go: Add configuration validation
- cmd/sync.go, internal/sync/*: Use new path helper functions
- tests: Update to use directory overrides
- docs: Update deployment guide and README
BREAKING CHANGE: BuildWorkingSet() now accepts []*Task instead of *Filter
Problem:
- Working set IDs were assigned based on database query order (unsorted)
- Reports displayed tasks in sorted order (by urgency)
- Result: IDs didn't match displayed task positions (ID 1 wasn't first task)
Solution:
- Changed BuildWorkingSet() to accept pre-sorted task slice
- Reports now pass sorted tasks to BuildWorkingSet()
- IDs are assigned sequentially to match display order (1, 2, 3...)
Behavior:
- Reports rebuild working set on every execution with fresh IDs
- Task operations (done, modify, info) use saved working set IDs
- After completing a task, re-running report renumbers remaining tasks
Example:
Before: opal list shows ID 1 = low urgency task (wrong)
After: opal list shows ID 1 = highest urgency task (correct)
Tested scenarios:
✓ List report: IDs 1-N match urgency order
✓ Next report: IDs 1-5 match top urgent tasks
✓ Task completion: IDs renumber correctly after removal
✓ Multiple operations: Use saved working set (correct behavior)
✓ Different reports: Each builds own sequential IDs
- Fix template task filtering bug: templates now hidden from all reports
except 'template' and 'all' reports, even when using custom filters
- Add support for status:template filter to explicitly show templates
- Implement comprehensive report system with 12 predefined reports:
* active - Started tasks
* all - All tasks including templates
* completed - Completed tasks
* list - Pending tasks (default)
* minimal - Pending tasks in minimal format
* newest - Most recent pending tasks
* oldest - Oldest pending tasks
* overdue - Overdue tasks
* ready - Tasks ready to work on
* recurring - Pending recurring instances
* template - Recurring template tasks
* waiting - Hidden/waiting tasks
- Replace list command with report-based architecture
- Add configurable default_report option (defaults to 'list')
- Add minimal display format (ID + description only)
- Support flexible syntax: 'opal <report> [filters]' or 'opal [filters] <report>'
- Add 'opal reports' command to list all available reports
joakim