- Add GPL-3.0 LICENSE file
- Update README with current project status (all 3 phases), fix structure
- Update PLAN.md Phase 2 API signatures to match actual implementation
- Add WebDAV & Sync section to docs/API.md
- Update docs/DEVELOPMENT.md with Tauri app structure and setup
- Add metadata (description, license, repository) to all Cargo.toml files
- Update .gitignore with node_modules, .env, dist, build entries
- Remove stale Cargo.lock from .gitignore (apps should track it)
- Update example dates from 2025 to 2026 across all docs
- Update CLAUDE.md date to 2026-03-30
- Remove Flutter app and egui placeholder crate, commit to Tauri as sole GUI
- Update PLAN.md to replace egui with Tauri across all phases (v4.0)
- Redesign task screen: sliding drawer for list picker, floating FAB for new tasks,
bottom sheet toast for task creation with title + description fields
- Add description support to create_task Tauri command
- Lighten dark theme to GNOME-style neutral grays, shift primary to cyan-blue
- Fix Wayland compatibility (dev port change)
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Add 'list create' command to features and CLI examples
- Clarify that task titles exclude .md extension in filenames
- Change deliverables from ✅ to - [ ] for consistency with feature checklists
Changes task ordering model:
- Remove SortOrder enum (Manual/ByDueDate)
- Replace with simple group_by_due_date boolean
- Tasks always use manual ordering via task_order array
- Grouping by due date is optional view toggle
Data model changes:
- TaskList.sort_order → TaskList.group_by_due_date: bool
- .listdata.json: "sort_order" → "group_by_due_date": false
- API: set_sort_order() → set_group_by_due_date()
- CLI: sort command → group enable/disable command
Benefits:
- Simpler mental model: always manual order, optional grouping
- Less complex to implement and reason about
- User always has ordering control via task_order
- Grouping is just a view option
Add workspace path management:
- workspace retarget: Update path in config (files already moved)
Use when files moved externally or different mount point
- workspace migrate: Move files AND update config
Use to relocate workspace to new folder
Clarify edit command behavior:
- Added note that edit is CLI-only (not mobile/GUI)
- Explains: creates temp file, opens $EDITOR, blocks, parses
- GUI/mobile use get_task() + update_task() directly
workspace remove behavior:
- Only removes from config, files remain on disk
- User responsible for deleting files if desired
Updates the project plan to support multiple independent task
workspaces, allowing users to maintain separate task folders for
different contexts (e.g., personal vs shared/collaborative).
Key changes:
Data Model:
- AppConfig now contains HashMap of named WorkspaceConfig
- WorkspaceConfig holds path and WebDAV settings per workspace
- current_workspace field tracks active workspace
CLI Features:
- `init` command now creates named workspace
- New workspace management commands:
- workspace add: Add additional workspaces
- workspace list: View all workspaces
- workspace switch: Change current workspace
- workspace remove: Delete workspace
- All commands support --workspace flag for explicit targeting
- Commands use current workspace by default
Phase 2 (WebDAV):
- Per-workspace WebDAV configuration
- Each workspace can sync to different WebDAV server
- Sync commands are workspace-aware
- Status command shows per-workspace or all workspaces
Phase 3 (GUI):
- Workspace selector dropdown in toolbar
- Quick-switch between workspaces UI
- Workspace setup dialog on first launch
- Settings panel for workspace management
- Per-workspace last opened list tracking
Benefits:
- Separate personal and shared/collaborative task folders
- Different sync configurations per workspace
- Better organization for different contexts
- Flexible folder locations (local, Dropbox, etc.)
Enhanced CLI Usage Examples in Phase 1 and Phase 2 with realistic
output examples showing:
Phase 1 (Core & CLI):
- Init command with success messages
- Add tasks with UUID confirmation and due date display
- List command showing task status, counts, and due dates
- Complete/edit/delete with confirmation messages
- Config and sort commands with feedback
Phase 2 (WebDAV Sync):
- Interactive setup with prompts and keychain confirmation
- Push/pull with file upload/download progress
- Automatic two-way sync with change indicators
- Status command showing connection, last sync, and pending changes
All examples now show:
- Command prompts ($)
- Realistic UUIDs
- Success indicators (✓)
- Progress/status information
- Colored output representation (checkmarks, arrows)
- Helpful feedback messages
Makes it much clearer what users can expect from the CLI.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
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>
Tristan Michael
