Updated terminology to use standard "recurring tasks" instead of
"repeating tasks". Also updated frontmatter fields:
- repeat -> recurs
- repeat_until -> recurs_until
"Recurring" is the more common and standard term in task management.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Added detailed repeating tasks functionality to Advanced Features:
How it works:
- When a repeating task is completed, it automatically:
1. Returns to backlog status
2. Updates due date by specified interval
Supported intervals:
- daily, weekly, monthly, yearly
- Custom intervals (e.g., "every 3 days")
- Optional end date or repetition limit
Frontmatter fields:
- repeat: "daily" | "weekly" | "monthly" | "yearly" | "every N days/weeks/months"
- repeat_until: (optional) end date for repetitions
Example use cases:
- Daily standup notes
- Weekly review tasks
- Monthly bill payments
- Quarterly reports
This is a Phase 7 feature as it requires background processing
to check completed tasks and reset them based on intervals.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Clean up data model and remove unnecessary notes:
1. Simplified TaskStatus:
- Only two states: Backlog and Completed
- Removed in-progress, not-started complexity
- Clearer, simpler model
2. Removed unnecessary comments:
- "Note: position stored in .listdata.json" (obvious from context)
- "Note: theme and UI preferences added in Phase 3" (unnecessary)
3. Removed subtask folder example:
- Already have parent_id for subtask relationships
- No need to show nested folder structure
- Keeps file structure example simple
4. Simplified AppConfig in Phase 1:
- Just local_path, no extra comments
Changes keep the plan focused and remove noise.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Enhanced task ordering with two sort options:
1. Manual Ordering (default):
- User can drag/drop to reorder tasks
- Order stored in task_order array in .listdata.json
- Only manual changes update the file
2. By Due Date:
- Tasks automatically sorted by due_date field
- Tasks without due dates appear at end
- task_order array ignored when in this mode
Changes:
- Added sort_order field to .listdata.json ("manual" or "by_due_date")
- Added SortOrder enum to TaskList model
- Clarified that Vec<Task> order depends on sort preference
- Added set_sort_order() and get_sort_order() to repository API
- Added CLI sort command to switch between modes
- Removed confusing comment about .listdata.json being "in-memory"
Example .listdata.json:
{
"sort_order": "manual",
"task_order": ["uuid-1", "uuid-2", "uuid-3"]
}
CLI usage:
bevy-tasks sort manual --list "Work"
bevy-tasks sort by-due-date --list "Personal"
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Cleaned up data model and configuration scope:
REMOVED:
- Tags field from Task model (out of scope, may never be needed)
- Tags from frontmatter example
- Tags from Phase 7 features
- Theme from Phase 1 AppConfig (not needed until GUI)
MOVED:
- Theme configuration to Phase 3 (when GUI is introduced)
- Added updated AppConfig in Phase 3 showing theme, window_size, last_opened_list
Phase 1 now focuses on core essentials:
- Task CRUD operations
- Markdown file I/O
- Basic data model (id, status, due_date, parent_id)
- CLI functionality
Benefits:
- Simpler Phase 1 implementation
- Less upfront complexity
- Theme configuration appears when it's actually used (GUI)
- Tags can be added later if needed (or never)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Changed metadata structure for better organization:
OLD:
~/Tasks/.bevy-tasks/metadata.json (global)
~/Tasks/My Tasks/ (no list metadata)
NEW:
~/Tasks/.metadata.json (global: list order, last opened)
~/Tasks/My Tasks/.listdata.json (per-list: task order, id, timestamps)
Key improvements:
1. Task ordering in .listdata.json - reordering only updates one file
2. Removed position field from task frontmatter
3. List metadata stays with the list (portable)
4. Cleaner naming: .metadata.json and .listdata.json
5. No nested hidden folders
Updated:
- File system structure diagram
- Data models (removed position from Task and TaskList)
- Added note about position being in .listdata.json
- Added reorder_task() and get_task_order() to API
- Updated AppConfig comment
Benefits:
- Reordering tasks = single file update
- Moving/copying lists preserves metadata
- WebDAV sync naturally groups data
- Cleaner file structure
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
The project will be licensed under GNU General Public License v3.0.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Reorganized document structure:
Before:
1. Vision
2. Phase 1-7
3. Development Guidelines
4. Resources
After:
1. Vision
2. Development Guidelines
3. Resources
4. Phase 1-7
Benefits:
- Guidelines available as reference from the start
- Performance budgets visible before implementation
- Testing strategy known upfront
- Resources accessible throughout all phases
- More logical flow for developers starting the project
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Complete restructure of the plan document:
NEW STRUCTURE:
1. Vision (brief high-level overview at top)
2. Phase 1-7 (each phase is self-contained)
Each phase now includes:
- Goal and rationale
- Architecture decisions relevant to THAT phase
- Dependencies for THAT phase only
- Features checklist
- Usage examples
- Deliverables
MOVED CONTENT:
- Data model → Phase 1 (when it's needed)
- Workspace structure → Phase 1
- Storage strategy → Phase 1
- Core library API → Phase 1
- WebDAV architecture → Phase 2 (when it's implemented)
- Frontend framework decision → Phase 3 (when it matters)
- Mobile architecture → Phase 4 (when it's built)
- Performance strategy → Phase 3 (with GUI)
REMOVED:
- Upfront architectural details that weren't immediately relevant
- Repetitive explanations scattered throughout
- "Questions & Decisions" section (decisions now inline with phases)
- "Technical Challenges" section (addressed in relevant phases)
BENEFITS:
- Much easier to read and follow
- Focus on immediate next steps (Phase 1)
- Architecture details appear when they're actually needed
- Each phase is actionable and self-contained
- Reduced cognitive load
- Clear progression path
Document is now 750 lines (down from 900+) and much more focused.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Major roadmap changes:
1. Mobile Support Moved Up (Phase 4 instead of Phase 5):
- Get iOS/Android builds working early, even with simple test UI
- Validates cross-platform architecture ASAP
- Foundation for future mobile polish
- egui supports mobile, so we can test early
New Phase Structure:
- Phase 1: Core Library & CLI MVP
- Phase 2: WebDAV Sync (Backend + CLI)
- Phase 3: GUI MVP (Desktop)
- Phase 4: Mobile Basic Support (NEW - prioritized)
- Phase 5: GUI Advanced Features (Desktop + Mobile)
- Phase 6: Mobile Polish & Platform Features
- Phase 7: Advanced Features & Imports
2. Google Tasks Importer Added (Phase 7):
- Migrate users from Google Tasks
- Import tasks, lists, due dates, notes
- Easy onboarding for existing Google Tasks users
3. Additional Phase 7 Features:
- Tags and custom fields
- Bulk operations
- Calendar integration
- Email to task
- Voice input
- Collaboration features
Benefits of early mobile:
- De-risk mobile builds early in development
- Test cross-platform code paths sooner
- Allows for mobile-specific feedback early
- Can dogfood on mobile while building desktop features
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Changed from opaque platform-specific defaults to user-controlled storage:
Before:
- Default to hidden platform directories (%APPDATA%, ~/.local/share, etc.)
- User could optionally select custom folder
After:
- User MUST select folder on first run (no hidden defaults)
- Full transparency and control over data location
- Examples: ~/Documents/Tasks, ~/Dropbox/Tasks, etc.
Key changes:
- CLI init requires folder path argument
- GUI shows folder picker on first launch
- Mobile prompts for folder location with suggestions
- App config (theme, window size) still in platform-specific location
- Task data always in user-visible, user-controlled folder
Benefits:
- Users can easily find and backup their data
- Works seamlessly with cloud sync (Dropbox, iCloud, OneDrive)
- Can use with other tools (Obsidian, VS Code)
- Git-friendly for version control
- Multiple task vaults possible (work/personal)
- No lock-in, no hidden data
Updated:
- Storage strategy section
- AppConfig model (local_path is required, not optional)
- CLI examples (init requires path)
- First run experience description
- Repository API (takes tasks_folder directly)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Removed exploratory framework comparison details and consolidated
the decision to use the hybrid approach:
- Phase 3-5: egui for fast MVP development
- Phase 6: Optional migration to Bevy for game-like polish
- Backend (bevy-tasks-core) stays framework-agnostic
Key changes:
- Replaced 8-framework detailed comparison with concise decision
- Updated GUI Cargo.toml to use egui (eframe + egui)
- Simplified "Questions & Decisions" section (removed UI framework question)
- Updated performance strategy for egui instead of Bevy
- Updated startup sequence to reflect egui (< 200ms target)
- Cleaned up Challenge 1 to be egui-specific
The plan is now focused and ready for implementation.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Major architectural changes:
- Reorganized as Cargo workspace with 3 crates:
- bevy-tasks-core: Pure Rust library (no UI dependencies)
- bevy-tasks-cli: Command-line interface
- bevy-tasks-gui: Graphical frontend (framework TBD)
CLI-First Development Strategy:
- Phase 1: Build core library + CLI MVP (validate backend)
- Phase 2: Add WebDAV sync to backend + CLI
- Phase 3: Build GUI MVP using chosen framework
- Phases 4-6: Mobile, polish, and advanced features
Comprehensive Frontend Framework Comparison:
Added detailed analysis of 8 frontend options:
1. Bevy (game engine) - best for polish, harder for standard UI
2. egui (immediate mode) - RECOMMENDED for MVP (fast, simple)
3. Iced (Elm-inspired) - good for desktop, mobile experimental
4. Dioxus (React-like) - web-friendly, mobile uses webview
5. Tauri (web + Rust) - uses system webview, slower startup
6. Slint (declarative) - clean but smaller community
7. Flutter (Dart) - best mobile but not Rust
8. Native UIs - best native feel but 5x development effort
Recommendation: Start with egui for Phase 3 MVP, optionally migrate
to Bevy in Phase 6 for game-like polish. Backend separation makes
this possible without rewriting business logic.
Benefits of this approach:
- Test backend thoroughly before GUI complexity
- CLI useful for power users and automation
- Clean API boundaries
- Easy to swap frontend frameworks
- Parallel development possible after Phase 2
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Key changes:
- Changed data format to Markdown files with YAML frontmatter (Obsidian-compatible)
- Removed timeline estimates from all phases
- Added comprehensive UI framework analysis (bevy_ui vs bevy_egui)
- Added detailed authentication options for WebDAV (keychain recommended)
- Expanded distribution strategy to include all app stores (F-Droid, Flathub, etc.)
- Clarified backup strategy as user-managed via external tools
- Removed success metrics section
- Added markdown benefits: human-readable, git-friendly, tool-compatible
Decisions made:
- Recommend pure bevy_ui for performance and future game-like polish
- Use platform keychain (keyring crate) for WebDAV credentials
- Users handle backups via git, cloud storage, or other external tools
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
This plan outlines the development of a local-first, cross-platform tasks
application inspired by Google Tasks. Key features:
- Cross-platform support (Windows, Linux, macOS, iOS, Android)
- Fast startup time (< 500ms target)
- Local file storage with optional WebDAV sync
- Built with Bevy for future game-like UX polish
- Phased development roadmap from MVP to advanced features
The plan includes architecture design, technology stack, performance
strategies, and detailed feature roadmap across 5 development phases.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
SteelDynamite
