100 lines
4.5 KiB
Markdown
100 lines
4.5 KiB
Markdown
# Project State - 2026-07-15
|
|
|
|
## Eventual Goal
|
|
|
|
Libre Study should become a full-featured Bible study program built around open-source code and freely usable resources wherever licensing permits. It should stay platform-agnostic: one shared app core, with adapters for browser/HotView, hosted web, Tauri desktop, and later PWA/mobile surfaces.
|
|
|
|
LibreBible remains the public resource package lane. Libre Study remains the study workspace and user-data lane.
|
|
|
|
## Where We Started
|
|
|
|
The project began as a local Bible reader and Tauri/React shell. The early questions were whether it could consume real Bible data, whether the app could stay independent from a single platform, whether HotView could be the primary development loop, and whether the study surface would be useful enough to guide the architecture.
|
|
|
|
## Where We Are Now
|
|
|
|
The project has moved from prototype into early product architecture.
|
|
|
|
Working HotView behavior includes:
|
|
|
|
- KJV and NET Bible text.
|
|
- Strong's links and lexicon definitions.
|
|
- Strong's pronunciation text when the package provides it.
|
|
- KJV and NET footnotes and study notes.
|
|
- Matthew Henry Concise commentary.
|
|
- Easton and Smith dictionary entries.
|
|
- OpenBible place context and UBS route labels.
|
|
- KJV audio controls from the packaged Eliran Wong source.
|
|
- Session-aware resource toggles.
|
|
- Notes, timeline, imports, exports, and one-way Nextcloud WebDAV export.
|
|
|
|
Architecture now includes:
|
|
|
|
- `src/studyDataClient.ts` as the resource/query contract.
|
|
- `src/studyClient.ts` as the browser/Tauri adapter router.
|
|
- `src/workspace.ts` as the workspace/auth/session persistence contract.
|
|
- Browser/HotView JSON package loading from sibling `W:\libre-bible-data`.
|
|
- A Tauri/Rust/SQLite lane that exists but is not currently the lead development lane.
|
|
- Hosted login/persistence infrastructure that exists but is parked until explicitly resumed.
|
|
|
|
## Current Development Loop
|
|
|
|
HotView is the active loop. Do not run web builds, local builds, installer builds, or hosted deployments unless explicitly requested.
|
|
|
|
The private intranet/Tailscale target is:
|
|
|
|
```text
|
|
http://desktop:5174/
|
|
```
|
|
|
|
Vite HMR detects the machine's Tailscale IPv4 address when available. `VITE_HMR_HOST` can override that if a device needs a different private address. This is a private development path, not a public internet deployment.
|
|
|
|
## What We Learned
|
|
|
|
- Phase completion should mean: source updated, docs/changelog updated, validation run, committed, and pushed to Gitea.
|
|
- Current repo state is more authoritative than memory or phase labels.
|
|
- KeePass should own project credentials and operating notes where practical.
|
|
- Passwords generated for project services should be around 16-20 characters, using uppercase, lowercase, and numbers, without special characters unless a service requires them.
|
|
- Nextcloud export is one-way WebDAV export for now, not a primary database or full sync system.
|
|
- Browser/HotView currently has the richest resource behavior; desktop hardening comes later.
|
|
- Public resource data belongs to LibreBible. User workspace data belongs to Libre Study.
|
|
- Do not show fake pronunciation playback controls until licensed pronunciation audio packages exist.
|
|
- `desktop` resolves to multiple local addresses on this machine; the Tailscale IPv4 path is the reliable HMR target.
|
|
|
|
## Where We Are Not Yet
|
|
|
|
Libre Study is not yet a mature public Bible study application.
|
|
|
|
Missing or immature areas include:
|
|
|
|
- Cross-references.
|
|
- More commentaries, lexicons, dictionaries, atlas images, and audio packages.
|
|
- Licensed pronunciation audio packages.
|
|
- Resource install/update/offline package management.
|
|
- Mature hosted persistence and account lifecycle.
|
|
- Desktop offline hardening and signed installers.
|
|
- PWA/mobile adaptation.
|
|
- Collaboration.
|
|
- Public web release readiness: privacy, terms, license pages, abuse protection, backups, and monitoring.
|
|
|
|
## Recommended Next Step
|
|
|
|
The next phase should be consolidation, not another feature sprint.
|
|
|
|
Consolidation should turn the completed Phase 1-7 foundation into durable product tracks:
|
|
|
|
- Study experience.
|
|
- Resource ecosystem.
|
|
- Persistence and sync.
|
|
- Platform adapters.
|
|
- Public responsibility.
|
|
- Collaboration.
|
|
|
|
The goal is to preserve the platform-agnostic architecture before adding more features.
|
|
|
|
## Phase 8 Result
|
|
|
|
Phase 8 completed the consolidation pass. The roadmap now keeps completed foundation phases as an archive and organizes future work by product tracks. The supporting references are:
|
|
|
|
- [Product Tracks](product-tracks.md)
|
|
- [App Architecture Boundaries](app-architecture-boundaries.md)
|