wtclaude
06917d43e2
Turns the design doc into an ordered, dependency-correct build plan (phases 0-9) with an exit criterion per phase, and records the twelve architectural decisions it rests on as ADRs. Decisions: single Rust binary with routed compose services; Streamable HTTP only; per-agent bearer tokens with clientInfo as a display hint only; SQLite; get_rules delivered via session gating; full-document rule delivery; project_id from day one; enforcement tier scoped to Bridle-mediated actions; stable tool list on upstream failure; OpenAI-compatible embeddings with model/dim guarding; pattern RAG gated behind a spike; CLAUDE.md + AGENTS.md as v1 renderer targets. Deviates from the design doc's original 1-8 ordering by moving the audit log and multi-project schema into phase 1, building the admin API incrementally rather than all at the Web Panel phase, downgrading vendor guardrail sourcing to manual-first, and gating the pattern-example RAG behind a validation spike. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019RZerbsHGF9Ka3bKhCjJ9m
30 lines
1.3 KiB
Markdown
30 lines
1.3 KiB
Markdown
# ADR-0004: SQLite as the primary datastore
|
|
|
|
**Status:** Accepted (2026-08-08)
|
|
|
|
## Context
|
|
|
|
The design doc specified no storage backend for the canonical rules document, permissions, audit
|
|
log, sessions, secret metadata, or the approval queue. Options considered were SQLite, a bundled
|
|
Postgres, and git-backed YAML in a Gitea repository with a database for everything else.
|
|
|
|
The git-backed option was genuinely attractive in a Gitea shop — free versioning, diffs, and
|
|
PR-based review of guardrail changes. It was rejected because Web Panel edits and direct git edits
|
|
create two write paths to the same canonical data that must then be reconciled.
|
|
|
|
## Decision
|
|
|
|
**SQLite**, one file (`bridle.db`), holding `projects`, `agents`, `tokens`, `permissions`,
|
|
`audit_log`, `rules_documents` (JSON plus `schema_version`), `guardrails` with provenance, and
|
|
`approval_queue`.
|
|
|
|
## Consequences
|
|
|
|
- Zero operational overhead; backup is copying one file.
|
|
- Correct default for the single-host, single-user target.
|
|
- Rules versioning must be built explicitly (document history in-table) rather than inherited from
|
|
git.
|
|
- Migration to Postgres remains straightforward if multi-host or a multi-user panel ever
|
|
materializes. Keep SQL portable and avoid SQLite-specific constructs where a standard equivalent
|
|
exists.
|