libre-study/docs/project-state-2026-07-15.md

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:

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.