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.1 KiB
1.1 KiB
ADR-0006: Full-document rule delivery, no dynamic subsetting
Status: Accepted (2026-08-08) — carried forward from the original design doc
Context
An obvious token-saving optimization is to send an agent only the slice of the ruleset relevant to its current task or file path. This was considered and rejected during design.
Decision
The rendered rules document is always sent in full. No path-based or task-based filtering of what an agent receives.
How much leash a given model needs to reliably stay on task is a per-model concern handled by the renderer (ADR-0012), not a universal token-saving optimization applied to everyone. Some models need a fuller, more complete document than others.
Consequences
- Predictable behavior: an agent's context either contains the whole policy or the session is gated (ADR-0005).
- Higher token cost per session, accepted deliberately.
- Renderer verbosity becomes the tuning knob for per-model needs.
- Note that this reasoning applies to rules, not to tools. Tool schemas are a separate context budget and are filtered per agent, driven by the permissions table (see phase 3).