# LibreBible Roadmap

LibreBible is the public Bible and study-resource data project behind Libre Study, GracePress Bible Tooltip, and future ChristIT Bible tools.

Working names:

- Project/catalog name: LibreBible
- Technical repository: `libre-bible-data`
- App consumer: Libre Study
- Public catalog home: ChristIT.com
- Git host/source backup: `https://git.christit.com/libre-study/libre-bible-data`

## Guiding Shape

Keep one canonical data repo for now. Do not split each Bible translation into its own repo until a resource becomes large, independently maintained, or operationally painful inside the shared repository.

Use stable resource ids, manifests, package folders, and generated docs to give each Bible/resource its own identity without creating unnecessary repositories.

Preferred structure:

```text
sources/
  kjv-eng-kjv2006.json
  future-resource.json

resources/
  notes/
  commentaries/
  maps/
  lexicons/

packages/
  json/
    catalog.json
    kjv-eng-kjv2006/
      catalog.json
      verses.jsonl
      strongs-links.jsonl

docs/
  resources/
  resource-manifest.md
```

## Phase 1: Catalog Metadata Foundation

Goal: make every resource self-describing enough for humans, apps, and public catalog pages.

Tasks:

- Expand source manifests with fields for translation date, source tradition/text basis, publisher/creator, upstream maintainer, copyright holder, license details, jurisdiction notes, and citation text.
- Add attachment metadata that can describe Strong's links, morphology, lemmas, study notes, cross-references, maps, commentaries, lexicons, dictionaries, timelines, and media.
- Add `resource_type` values such as `translation`, `study_notes`, `commentary`, `map`, `lexicon`, `dictionary`, `cross_reference`, and `timeline`.
- Add relationship fields so one resource can attach to a Bible translation, book, chapter, verse, verse range, word/token, Strong's number, lemma, topic, place, or timeline event.
- Generate `RESOURCE_INDEX.md` from structured metadata.
- Generate one human-readable Markdown detail page per resource under `docs/resources/`.

Definition of done:

- The public Gitea repo README clearly links to a generated resource index.
- KJV has a complete enough human-facing detail page to answer: what is it, where did it come from, who produced it, what is its license, what features does it include, and what package files are available.

## Phase 2: LibreBible Public Catalog on ChristIT.com

Goal: make ChristIT.com the useful public face of LibreBible.

Tasks:

- Choose a public path such as `https://christit.com/librebible/`.
- Build a PHP or similarly simple dynamic overlay that reads committed catalog JSON from a local checkout, a synced artifact folder, or stable Gitea raw/release URLs.
- Render a Bible/resource browser from `packages/json/catalog.json` and per-resource `catalog.json` files.
- Display title, abbreviation, language, translation date, creator/publisher, source, license, redistribution status, jurisdiction notes, features, counts, checksums, package files, and last upstream check.
- Provide stable download URLs for generated packages.
- Link back to the Gitea repo, source manifest, upstream source page, and generated resource detail page.
- Avoid scraping README prose. Structured JSON is the machine truth; Markdown is for human explanation.

Definition of done:

- A normal visitor can answer which Bibles are available and whether each has Strong's, notes, commentaries, maps, or other attachments.
- Libre Study and GracePress Bible Tooltip can use the same catalog information for package discovery.

## Phase 3: More Bible Sources

Goal: grow beyond KJV while keeping license discipline.

Priority sources:

- eBible.org freely redistributable translations.
- unfoldingWord/Door43 resources where licenses permit redistribution.
- Open English Bible.
- World English Bible.
- Other public-domain or permissively licensed translations.

Tasks:

- Add source manifests before adding generated text.
- Record upstream license, redistribution, and attribution details before import.
- Add importer support for additional formats as needed: USFM zip, OSIS, plain text, TSV/CSV, JSON, XML, image files, or geospatial data.
- Normalize all imported translations into shared package shapes.
- Keep questionable resources as source metadata only until redistribution is clear.

Definition of done:

- At least three redistributable translations appear in the catalog with generated packages and clear license/source metadata.

## Phase 4: Attachments and Study Resources

Goal: make LibreBible useful as a study ecosystem, not just a text repository.

Priority attachments:

- Strong's/concordance links.
- Morphology and lemma data.
- Study notes tied to verses or sections.
- Cross-references.
- Lexicons and dictionaries tied to Strong's numbers and lemmas.
- Commentaries tied to verse ranges or scriptural sections.
- Maps tied to places, events, books, chapters, and passages.
- Timelines tied to events and passages.

Tasks:

- Define attachment package schemas.
- Add package examples for each attachment type before bulk import.
- Add relationship indexes so apps can ask: what attaches to this verse, range, word, Strong's number, lemma, place, or topic?
- Preserve source attribution per attachment, not just per translation.
- Add generated docs and catalog display for attachments.

Definition of done:

- The catalog can show a Bible translation and list its available attachments.
- The catalog can also show an attachment and list which translations/passages it applies to.

## Phase 5: App and Plugin Consumption

Goal: make LibreBible packages directly useful to Libre Study and GracePress.

Tasks:

- Define stable package URLs and version/checksum metadata for apps.
- Add SQLite-ready package output for Libre Study.
- Add WordPress/plugin-ready package output for GracePress Bible Tooltip.
- Teach Libre Study to import from the public catalog, not just a sibling local repo.
- Teach GracePress Bible Tooltip to discover/download supported translations from the catalog.
- Keep app/user data separate from public Bible resource data.

Definition of done:

- Libre Study can install/update a Bible package from the public catalog.
- GracePress Bible Tooltip can consume the same resource metadata and package outputs.

## Phase 6: Updates, Releases, and Automation

Goal: keep upstream scanning and package publishing repeatable.

Tasks:

- Add scheduled update checks for source manifests.
- Produce a report when an upstream checksum changes.
- Require human review before accepting changed upstream text or license metadata.
- Generate package checksums and release notes from structured data.
- Tag stable resource package releases in Gitea.
- Publish public catalog updates only from pushed commits.

Definition of done:

- A resource update can be checked, reviewed, regenerated, committed, pushed, and published without manual file hunting.

## Phase 7: Public Site Polish

Goal: make the public LibreBible catalog feel like a real product.

Tasks:

- Add filters by language, license, feature, source, testament/canon, and attachment type.
- Add detail pages for translations and attachments.
- Add copyable package URLs for app/plugin integration.
- Add provenance and license panels that are clear to normal users.
- Add download buttons for supported package formats.
- Add "used by" links for Libre Study, GracePress Bible Tooltip, and future tools.

Definition of done:

- The ChristIT.com LibreBible section is useful without opening Gitea.

## Open Decisions

- Whether the public path should be `christit.com/librebible/`, another ChristIT path, or a dedicated domain/subdomain later.
- Whether large generated packages should remain committed directly, move to Gitea releases, or be mirrored to a static download path.
- Whether to eventually split especially large or independently maintained translations/resources into separate repos.
- Which public package format should become the preferred app install format: JSONL bundle, SQLite bundle, zip package, or another signed manifest format.
- How much Gitea itself should be customized after the ChristIT.com catalog proves the model.
