154 lines
7.2 KiB
Markdown
154 lines
7.2 KiB
Markdown
# Libre Study Roadmap
|
|
|
|
Libre Study is the study workspace that consumes LibreBible packages. The goal is a full-featured Bible study program that is open-source and free to use where licensing permits, with one shared app core and platform adapters for HotView/browser, hosted web, Tauri desktop, and later PWA/mobile surfaces.
|
|
|
|
LibreBible owns public Bible and study-resource packages. Libre Study owns the user workspace: sessions, notes, settings, timeline, tags, exports, and future collaboration state.
|
|
|
|
## Current Code Baseline
|
|
|
|
- UI: React and TypeScript, served by Vite in browser development mode and wrapped by Tauri for desktop builds.
|
|
- Active workflow: HotView/hot reload on the private Tailscale/local intranet.
|
|
- HotView URL: `http://desktop:5174/` from connected machines.
|
|
- Browser development data: static LibreBible JSON/JSONL packages loaded from sibling repo `W:\libre-bible-data`.
|
|
- Desktop shell: Tauri 2 with Rust commands and a local SQLite database path.
|
|
- Current resource behavior: KJV and NET text, Strong's links, Strong's lexicon entries, KJV/NET footnotes and study notes, Matthew Henry Concise commentary, Easton/Smith dictionary entries, contextual maps/routes, and KJV audio controls.
|
|
- Current user workspace behavior: sessions, settings, structured notes, exported session JSON, note drawer, and session timeline are stored in the versioned local workspace snapshot.
|
|
|
|
## Workflow Rule
|
|
|
|
While the app is being shaped interactively, use HotView as the primary test loop. Do not spend cycles on web builds, local builds, installer builds, or hosted deployments unless the user explicitly asks for a release/deploy pass.
|
|
|
|
Keep the durable release workflow simple when it is time to publish:
|
|
|
|
1. Develop locally in `W:\libre-study` and `W:\libre-bible-data`.
|
|
2. Commit locally.
|
|
3. Push to Christ Unscripted Gitea.
|
|
4. Deploy the pushed state to the live/private web app only when explicitly requested.
|
|
5. Later, build signed desktop installers only from clean pushed release commits.
|
|
|
|
## Architecture Rule
|
|
|
|
Keep one application, not separate apps. Split the code by adapters:
|
|
|
|
- Shared app core: resource/query contracts, Bible page model, search model, session model, note/timeline model, and study-resource rendering rules.
|
|
- Local browser adapter: fast Vite preview, static package loading, and local workspace snapshot during development.
|
|
- Hosted web adapter: server API, login session, remote persistence, stable 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.
|
|
|
|
Detailed architecture notes: [App Architecture Boundaries](docs/app-architecture-boundaries.md).
|
|
|
|
## Phase Discipline
|
|
|
|
Work one phase at a time. A helper, spike, or supporting infrastructure task for a later area does not make that later phase active or half-complete. A phase is complete only when its definition of done is met in the active HotView workflow and the work is committed and pushed.
|
|
|
|
## Foundation Phase Archive
|
|
|
|
The first seven phases established the working foundation:
|
|
|
|
- Phase 1: App foundation and Bible page reader. Complete.
|
|
- Phase 2: LibreBible resource consumption. Complete.
|
|
- Phase 3: HotView development loop and Gitea sync discipline. Complete.
|
|
- Phase 4: Shared app core. Complete.
|
|
- Phase 5: Storage and search foundation. Complete.
|
|
- Phase 6: Notes, exports, and optional Nextcloud export/import. Complete.
|
|
- Phase 7: Study resource depth and polish. Complete for currently packaged LibreBible resources.
|
|
|
|
Current project-state snapshot: [Project State - 2026-07-15](docs/project-state-2026-07-15.md).
|
|
|
|
## Phase 8: Consolidation And Product Tracks
|
|
|
|
Status: complete.
|
|
|
|
Goal: convert the completed foundation phases into durable product tracks so future work does not sprawl.
|
|
|
|
Current result: the roadmap now tracks long-term work by product area instead of treating every future task as another foundation phase. Product-track details live in [Product Tracks](docs/product-tracks.md).
|
|
|
|
Definition of done:
|
|
|
|
- Completed foundation phases are preserved as an archive.
|
|
- Current app-core boundaries are documented.
|
|
- HotView/local, hosted web, Tauri desktop, and future PWA/mobile lanes are separated.
|
|
- Resource-data and user-data ownership are documented.
|
|
- Feature backlog is reorganized by product track.
|
|
- Work is committed and pushed.
|
|
|
|
## Active Product Tracks
|
|
|
|
Use these tracks for future planning. Pick one active implementation phase at a time from these tracks.
|
|
|
|
### Study Experience
|
|
|
|
Goal: make the reader, study margin, notes, search, and resource layout feel like a serious Bible study workspace.
|
|
|
|
Current milestone:
|
|
|
|
- Phase 9: Bible desk layout and verse-anchored notes. Complete.
|
|
|
|
Near candidates:
|
|
|
|
- Improve search result navigation and saved searches.
|
|
- Add cross-reference display once a LibreBible package exists.
|
|
- Improve note clipping, highlights, tags, and sermon/study workflows.
|
|
- Polish page layout, responsive behavior, and accessibility.
|
|
|
|
### Resource Ecosystem
|
|
|
|
Goal: make LibreBible resources easy to add, attribute, query, and eventually install/update offline.
|
|
|
|
Near candidates:
|
|
|
|
- Add cross-reference packages.
|
|
- Add more commentaries, dictionaries, lexicons, and atlas/media packages.
|
|
- Add licensed pronunciation-audio packages when available.
|
|
- Define package install/update metadata for desktop and hosted lanes.
|
|
|
|
### Persistence And Sync
|
|
|
|
Goal: keep study work portable without making any single sync backend mandatory.
|
|
|
|
Near candidates:
|
|
|
|
- Strengthen local workspace migrations.
|
|
- Improve import/export validation.
|
|
- Keep Nextcloud as explicit one-way export until a safe sync model exists.
|
|
- Resume hosted persistence only when a release/deploy pass is requested.
|
|
|
|
### Platform Adapters
|
|
|
|
Goal: preserve one shared app core while letting each platform do the right local thing.
|
|
|
|
Near candidates:
|
|
|
|
- Keep HotView as the lead development loop.
|
|
- Harden hosted web only after private deployment is explicitly resumed.
|
|
- Harden Tauri desktop after the browser study model stabilizes.
|
|
- Evaluate PWA/mobile after responsive behavior is proven.
|
|
|
|
### Public Responsibility
|
|
|
|
Goal: prepare for public use without guessing about data responsibility, licensing, privacy, or abuse controls.
|
|
|
|
Near candidates:
|
|
|
|
- License and attribution pages.
|
|
- Privacy and terms pages.
|
|
- Account lifecycle, password reset, backups, and monitoring before public signup.
|
|
- Clear split between public resource data and private user workspace data.
|
|
|
|
### Collaboration
|
|
|
|
Goal: add shared Bible study without turning the basic app into a social network.
|
|
|
|
Near candidates:
|
|
|
|
- Start with shareable read-only session exports or links.
|
|
- Add shared sessions with explicit owners and invited participants.
|
|
- Add collaborative notes before collaborative whiteboards.
|
|
- Consider WebSockets and conflict-safe document models only after single-user persistence works.
|
|
|
|
## Database Decision
|
|
|
|
SQLite remains appropriate for desktop, local, and private/single-user workflows. 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.
|