Add desktop web roadmap

ROADMAP.md

@@ -0,0 +1,189 @@
+# Libre Study Roadmap
+
+Libre Study is the study workspace that consumes LibreBible packages. The current build is desktop-first, but the interface is already a React/Vite web app that can run in a browser. Tauri is the desktop shell and native storage layer, not a reason to fork the user interface.
+
+## Current Code Baseline
+
+- UI: React and TypeScript, served by Vite in browser development mode and wrapped by Tauri for desktop builds.
+- Desktop shell: Tauri 2 with Rust commands and a local SQLite database at the app data path.
+- Browser development data: static LibreBible JSON/JSONL packages loaded from a sibling `libre-bible-data` checkout.
+- Current resource behavior: KJV and NET text, Strong's links, Strong's lexicon entries, KJV/NET footnotes and study notes, Matthew Henry Concise commentary, and Easton/Smith dictionary entries.
+- Current user workspace behavior: browser sessions, settings, notes, exported session JSON, note drawer, and session timeline are stored in `localStorage`.
+- Current gap: browser mode has the richer study-resource behavior, while Tauri SQLite import currently covers a smaller resource set. A shared service boundary is needed before public web hosting or desktop hardening.
+
+## Architecture Rule
+
+Keep one application, not separate apps. Split the code by adapters:
+
+- Shared core: resource catalog reading, Bible page model, search model, session model, note/timeline model, and study-resource rendering rules.
+- Browser/web adapter: server API, account session, remote persistence, static resource package URLs, and optional collaboration services.
+- Desktop adapter: Tauri commands, local SQLite, local resource packages, offline cache, import/update manager, and no required account.
+
+The web version may add login and collaboration. The desktop version must remain usable without accounts.
+
+## Phase 1: Current Baseline And Roadmap
+
+Goal: write down what the code already does and define the web/desktop direction before more feature drift.
+
+Tasks:
+
+- Record that Libre Study can become a website because the primary UI is already React/Vite.
+- Record that Tauri is the desktop wrapper and native storage path.
+- Record that accounts are web-only and should not be required for local desktop use.
+- Record maps, audio Bible, pronunciation audio, Nextcloud notes, collaboration, and database strategy in the roadmap.
+- Keep LibreBible resource data separate from user workspace data.
+
+Definition of done:
+
+- This roadmap exists in the app repo.
+- LibreBible's roadmap also names maps, audio, pronunciation, and web-consumption package needs.
+
+## Phase 2: Shared App Core And Data Boundary
+
+Goal: stop treating browser mode and Tauri mode as separate realities.
+
+Tasks:
+
+- Extract a client/service interface for translations, pages, Strong's links, notes, commentaries, dictionaries, maps, audio, sessions, settings, and timelines.
+- Keep UI components pointed at that interface instead of hardcoding browser static paths or direct Tauri commands.
+- Add a clear resource catalog configuration path for browser, desktop, and future hosted web modes.
+- Define the session schema once: active translation, page anchor, selected verse, enabled resources, visual settings, notes, timeline, and exports.
+- Add a migration path from `localStorage` sessions to SQLite/server persistence.
+
+Definition of done:
+
+- The same UI can run against a browser static adapter, a Tauri SQLite adapter, or a future web API adapter.
+
+## Phase 3: Storage And Search Foundation
+
+Goal: make hundreds of thousands or millions of entries feel normal.
+
+Tasks:
+
+- Keep SQLite for desktop and single-user/local workflows.
+- Add proper indexes for translation id, book/chapter/verse, Strong's number, lemma, resource id, and attachment relationships.
+- Add full-text search through SQLite FTS5 or a compatible indexed search layer.
+- Avoid loading entire large resources into the browser when a chapter, page, verse, Strong's entry, or search result can be loaded on demand.
+- Define when public web hosting should move from SQLite to Postgres or another server database.
+
+Definition of done:
+
+- Search, page loads, note loads, and Strong's lookups use indexed or sharded access instead of whole-library reloads.
+
+## Phase 4: Private Web Alpha On Christ Unscripted
+
+Goal: get a private hosted version usable by Forrest without changing the desktop-first promise.
+
+Tasks:
+
+- Build the Vite app as a static web frontend.
+- Add a minimal server API for login, sessions, notes, settings, timeline, and resource catalog URLs.
+- Start with manually created accounts or a very small invite-only account flow.
+- Store only the minimum account data needed: username or email, password hash, sessions, notes, and timestamps.
+- Add a plain privacy note before opening this beyond private use.
+- Serve LibreBible packages as static files or through stable catalog URLs.
+
+Definition of done:
+
+- Forrest can log in on Christ Unscripted, open the study workspace, save a session, reload, and continue from the saved state.
+
+## Phase 5: Notes, Exports, And Nextcloud
+
+Goal: make study work portable without making Nextcloud the primary database.
+
+Tasks:
+
+- Save notes as structured session data first.
+- Add export formats: JSON session, Markdown notes, HTML notes, and later sermon/study document formats.
+- Add Nextcloud integration through WebDAV as an optional sync/export target.
+- Support one-way export first, then explicit import, then optional sync.
+- Keep Nextcloud credentials out of public resource packages and out of desktop builds unless the user configures them locally.
+
+Definition of done:
+
+- A session's notes can be exported and optionally synced to a Nextcloud folder without breaking normal local or web persistence.
+
+## Phase 6: Study Resource Depth
+
+Goal: continue turning the page into a complete study workspace.
+
+Tasks:
+
+- Add map support from LibreBible place/gazetteer packages.
+- Show map availability when a visible verse mentions a known place.
+- Add audio Bible support at chapter granularity first, then verse granularity when sources provide timestamps or verse files.
+- Add pronunciation audio tied to English terms, Strong's numbers, lemmas, Greek, and Hebrew where licensing permits.
+- Add more commentaries, dictionaries, lexicons, cross-references, and study-note packages.
+- Keep every resource optional, collapsible, session-aware, and license-attributed.
+
+Definition of done:
+
+- The study margin can show relevant maps, audio controls, pronunciations, notes, dictionary entries, lexicons, and commentaries dynamically for the selected verse or page.
+
+## Phase 7: Collaboration
+
+Goal: add shared Bible study without turning the basic app into a social network.
+
+Tasks:
+
+- Start with shareable read-only session exports or links.
+- Add shared sessions with explicit owners and invited participants.
+- Add collaborative notes before collaborative whiteboards.
+- Record session timeline events per participant when timeline recording is enabled.
+- Consider WebSockets and a conflict-safe document model only after single-user web persistence works.
+
+Definition of done:
+
+- Two logged-in users can study the same passage and contribute to a shared note surface without losing individual session state.
+
+## Phase 8: Desktop Hardening
+
+Goal: bring the installable app up to the same capability as the web study surface.
+
+Tasks:
+
+- Move desktop persistence from prototype imports to the shared session/resource schema.
+- Add resource package install/update management.
+- Add offline package support for translations, notes, commentaries, dictionaries, maps, and audio where storage size allows.
+- Keep account features optional and web-only unless a user explicitly signs into a sync service.
+- Package signed Windows installers from clean, pushed release commits.
+
+Definition of done:
+
+- The Windows app can run offline with installed resources and preserve sessions locally.
+
+## Phase 9: Public Web Release
+
+Goal: open the hosted app responsibly after private use proves the model.
+
+Tasks:
+
+- Add account creation, password reset, rate limiting, backups, and basic abuse protection.
+- Add clear privacy, terms, license, and attribution pages.
+- Separate public resource data from private user notes and collaboration data.
+- Add admin controls for disabling accounts and reviewing operational health.
+- Add monitoring for failed logins, storage growth, and resource loading failures.
+
+Definition of done:
+
+- The hosted app can accept public users without guessing about data responsibility or resource licensing.
+
+## Phase 10: Mobile And Future Platforms
+
+Goal: adapt only after the desktop/web study model is proven.
+
+Tasks:
+
+- Evaluate responsive web and PWA behavior first.
+- Consider mobile Tauri or native shells only if the PWA is insufficient.
+- Preserve the page-first study model while changing layout for smaller screens.
+
+Definition of done:
+
+- Mobile use is designed from the proven study workflow instead of forcing the desktop interface onto a phone.
+
+## Database Decision
+
+SQLite remains appropriate for the desktop app and for private/single-user testing. Hundreds of thousands of rows are not a problem when tables are indexed and large resources are loaded by chapter, verse, Strong's number, or search query.
+
+For a public multi-user website, use SQLite only for a private alpha or low-concurrency service. Plan for Postgres or another server database once accounts, collaboration, and public user data become real.