# 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.