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
1.3 KiB
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.