Skip to content

status.md

Latest commit

 

History

History
115 lines (99 loc) · 6.26 KB

status.md

File metadata and controls

115 lines (99 loc) · 6.26 KB
Raw

Feature Status

An honest accounting of what Project Hub actually does, verified against the code in lib/ (not against the README or the old process docs, both of which overstate the feature set). Development stopped after Phase 8A; the drag-and-drop work of Phase 8B was started but never finished, and Phases 9–13 were never begun.

README / pubspec disclaimer. README.md and the pubspec.yaml description advertise "seamless cross-platform sync via Google Drive API" and imply search and undo/redo. None of these are implemented (see below). Treat those documents as aspirational marketing, not a feature list.

Implemented and working

  • Local SQLite persistence. Full CRUD for items, metadata field definitions, and user settings via DatabaseService. WAL journaling, foreign keys on, integrity check available.
  • Universal hierarchical items. Create/edit/delete Projects, SubProjects, Features, and Steps through one model and one set of dialogs. Deleting an item cascades to its whole subtree via the self-referential FK.
  • Hierarchy navigation. Tree view (hierarchy_tree_view, HierarchyScreen) with expand/collapse and type icons, plus breadcrumb navigation. Recursive tree building and ancestor/descendant/sibling queries in HierarchyService.
  • Project list with responsive grid. Auto-column layout that adapts to window width (responsive_project_grid, ColumnManager), configurable column count, loading skeletons, and error-recovery/retry UI.
  • The metadata system. Predefined field catalog, three-tier + scope-based organization, metadata editor/display/tag-selector widgets, and comprehensive value + dependency validation. This is the most complete part of the app — see metadata-system.md.
  • User settings. Persisted UserSettings with a three-tab settings screen: General, Fields, Validation. Settings are cached and applied at runtime (theme, columns, field visibility/starring/ordering, defaults).
  • Material 3 UI throughout, with a three-tab bottom navigation shell.

Partially built

  • Drag-and-drop reordering (Phase 8B, incomplete). The project grid uses a ReorderableWrap and cards render drag handles (isDraggable: true), so items visibly reorder on screen. But the new order is never persisted — _reorderProjects only mutates the in-memory list and shows a snackbar, with an explicit TODO noting order persistence was deferred. There is no order column in project_items to store it. Cross-level dragging (moving an item to a new parent) and the horizontal-first/vertical-first ordering preference were never built.
  • Search (backend only). DatabaseService implements searchProjectItemsFullText (name/description/metadata LIKE with ranking), searchProjectItemsByMetadata, filterProjectItemsByMetadataField, getProjectItemsWithMetadataFilters, and usage statistics. None of it is reachable from the UI — there is no search bar, no SearchService, and no screen calls these methods.
  • Sync scaffolding (schema/config only). The pieces for Google Drive sync exist as inert scaffolding: sync_enabled / google_drive_account_email / last_sync_at columns on user_settings; sync_log and device_registry table definitions in DatabaseSchema (never created at runtime); sync-related constants. There is no GoogleDriveService, no authentication, and no sync code (the unused googleapis/googleapis_auth/url_launcher dependencies have been removed and should be re-added when sync is built). The Settings Data tab, which would host sync/export, renders only the placeholder text "Data Settings - Coming in next update".
  • Data export/import. Placeholder only (the Data tab above).

Planned but never started

Feature Intended phase
Google Drive cloud sync Phase 9
Search & filter UI Phase 10B
Data-integrity monitoring & automatic backups Phase 11A
Undo/redo (action history) Phase 11B
Smart / context-aware deletion, soft-delete, recovery Phase 12
Multi-select + bulk operations (delete, bulk metadata edit) Phases 8D–8E
Keyboard shortcuts & right-click context menus Phase 8F (only dialog-level shortcuts exist)
Metadata templates / bulk metadata editing Phase 7B (advanced)
Performance profiling & production polish Phase 13

Future work: preserved designs

These features were never coded, but the retired work orders contain design decisions worth keeping if development ever resumes.

Google Drive sync (Phase 9)

The intended model was deliberately simple:

  • Two modes: a Local-Only mode (no cloud, the app's current behavior) and a Cloud Sync mode, chosen via a toggle in settings.
  • Single-button sync: in Cloud mode, one prominent Sync button triggers a complete round-trip; the UI shows sync status and the last-sync timestamp. No continuous/background syncing.
  • Data format: export the whole database to a standardized JSON file (project_hub_sync.json) in an app folder ("Project Hub Data"), including each record's device_id and timestamps — which is exactly why those columns and the sync_log/device_registry scaffolding already exist.
  • Conflict resolution (mostly automatic):
    • newer last_modified wins when the two sides differ by more than ~1 hour;
    • when one side deleted an item and the other modified it, keep the non-deleted version;
    • merge non-overlapping changes automatically;
    • only fall back to a user dialog ("Keep Local / Keep Cloud / Keep Both") for genuinely ambiguous cases, with batch resolution for many conflicts.
  • Auth: Google Sign-In / OAuth 2.0 with a Drive scope, tokens refreshed automatically.

Drag-and-drop ordering (Phase 8B)

The unfinished reorder feature was meant to let the user choose how a linear drop position maps onto the 2-D responsive grid: horizontal-first (fill row by row) vs. vertical-first (fill column by column), selectable as a preference. Completing it requires adding a persisted order/position column to project_items and writing the reorder through to the database (the current TODO), then extending drops to cross-level moves with the hierarchy-validation rules described in architecture.md.