learning_ai_notes/docs/roadmaps/04_MOBILE_ROADMAP.md
2026-03-10 10:21:05 -07:00

4.2 KiB

Mobile Roadmap

Status: Draft Parent: docs/ROADMAP.md Stack: React Native + Expo + TypeScript

Phase M0 — Scaffold

  • Create Expo app structure
  • Wire @bytelyst/react-native-platform-sdk
  • Wire @bytelyst/api-client
  • Wire @bytelyst/platform-client
  • Wire @bytelyst/offline-queue
  • Import generated RN tokens
  • Create navigation shell
  • Define screen map

Phase M1 — Core MVP

  • Auth flow
  • Home / recent notes screen
  • Note detail screen
  • Quick capture flow
  • Search screen
  • Notifications/inbox placeholder if needed
  • Connect notes/workspaces APIs

Phase M2 — Product Utility

  • Lightweight editing
  • Notification handling
  • Offline queue / sync polish
  • Approvals inbox if in MVP scope
  • Basic artifact metadata viewing if in MVP scope

Phase M3 — Agent / Approval Utility

  • Approval/reject actions
  • Lightweight agent activity feed
  • Mobile-friendly review surfaces for simple actions

Phase M4 — Hardening

  • Smoke tests
  • Error-state polish
  • Build/compile verification
  • Token compliance review
  • Offline behavior review

High-Collision Areas

  • root navigation setup
  • auth bootstrap files
  • token/theme entrypoints
  • shared API client wrappers

Done When

  • Mobile is useful for capture and retrieval
  • Mobile supports lightweight editing and approvals for MVP
  • Mobile does not try to duplicate dense web-only workflows

Progress Notes

  • 2026-03-10 — Mobile workstream moved from draft-only planning into initial implementation.
  • learning_ai_notes/mobile/ was scaffolded from scratch with Expo + TypeScript.
  • Root app config now exists: package.json, app.json, tsconfig.json, index.ts, babel.config.js.
  • Expo Router shell now exists with auth entry, tab layout, home/recent notes, search, quick capture, inbox, and note detail routes.
  • Shared mobile bootstrap files now exist for:
    • @bytelyst/auth-client
    • @bytelyst/platform-client
    • @bytelyst/offline-queue
    • token-based theme wiring via @bytelyst/design-tokens/tokens.json
  • Zustand-backed auth, notes, and workspace stores were added for first-pass mobile state management.
  • Home/search/capture now use active workspace context for more useful mobile browsing.
  • Home now includes a workspace retrieval summary block to make the mobile surface more useful at a glance.
  • Note detail now supports lightweight local editing plus basic artifact metadata viewing.
  • Note detail now exposes first-pass loading-state polish.
  • Inbox now supports simple approval/reject flows and a lightweight activity feed.
  • Capture now surfaces offline queue readiness details for the current mobile scaffold.
  • Home and search now expose first-pass loading and empty-state polish.
  • Mobile dependency install now succeeds, and npm run typecheck, npm run lint, and npm test pass in mobile/.
  • Mobile now uses token-backed placeholder and border colors instead of raw hardcoded fallbacks.
  • Expo now boots locally, and tsconfig.json was aligned to extend expo/tsconfig.base.
  • Mobile core Expo package versions were aligned to the SDK 55 expectations surfaced during runtime startup.
  • Mobile currently uses provisional product config and fallback note/workspace data until product identity and backend contract details are finalized.

Open Questions

  • Should the current provisional bootstrap values (productId: bytelyst-notes, backend port 4016) now be treated as final?
  • What are the final iOS bundle identifier, Android package name, and URL scheme/domain values?
  • Should mobile notes access go directly to the product backend for note CRUD while auth remains on platform-service?
  • Should the current local approval/activity model map directly to backend note-agent-actions, or stay as a mobile-specific condensed surface?

Blockers

  • @bytelyst/react-native-platform-sdk is referenced as a planned shared dependency, but the current workspace package does not appear ready for direct runtime consumption in this new app yet.
  • Product identity and backend contract details remain provisional in the planning docs, so mobile config values are placeholders.

Deferred

  • Real notification handling
  • Offline queue flush/retry integration against live APIs