mirror of
https://github.com/Heretek-AI/Prog-Prober.git
synced 2026-10-12 02:03:08 +00:00
BillyOutlast
a197e50988
- docs/architecture.md: full architecture spec (safety contract, topology, Tool API, data model, phasing). - docs/adr/0001-0011: decision records for the grilling outcomes. - Repo skeleton: Cargo workspace (crates/core), pnpm workspace (apps/desktop, packages/ui), Python workers package, OCI runtime placeholder, graph JSON Schema. - AGENTS.md, CONTEXT.md, THIRD_PARTY.md, README.md, LICENSE (AGPL-3.0). - GitHub issues #1-#14: phase epics plus Phase 1 tickets.
1.4 KiB
1.4 KiB
ADR-0007: SQLite + LadybugDB storage split
- Status: accepted
- Date: 2026-09-19
Context
The case needs relational metadata (samples, cache keys, job history), a graph for nodes/edges, and a vector index for the RAG corpus. The project chose a polyglot store. KuzuDB — the obvious embedded graph choice — was archived in October 2025 after Apple acqui-hired its team.
Decision
- SQLite: case metadata, sample index, cache keys, job history.
- LadybugDB (the actively maintained Kuzu successor, MIT): nodes, edges, native vector index, and full-text index.
- graphology in memory for the renderer working set.
- DuckDB omitted until an analytics query actually requires it.
Consequences
- Kuzu's Cypher dialect and schema carry over to LadybugDB;
cargo add lbuggives the Rust core an embedded binding. - LadybugDB's built-in vector index removes the need for a separate vector store (no LanceDB in v1).
- Risk: LadybugDB is young. Mitigation: it is a graph projection, not the only copy of data — the canonical parse output can be re-projected, and SQLite remains the metadata source of truth. Revisit if the project stalls.
Alternatives considered
- SQLite adjacency tables only — simplest and zero risk, but forfeits Cypher, vector, and FTS.
- Vela-Engineering/kuzu fork — multi-writer focus we don't need.
- Keep LanceDB for vectors — redundant given LadybugDB's native index.