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>
