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>
