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
- Implement BuildWorkingSet() to create ephemeral display ID mappings
- Implement LoadWorkingSet() to restore from database
- Add GetTaskByDisplayID() for ID resolution
- Add GetTasks() and Size() helper methods
- Persist working set to SQLite working_set table
- Add comprehensive tests (5 tests, all passing)
- Support filtered working sets
joakim