6e8f0db6c0
- Add dialogue prompt file writing for audit/debugging - Update README install instructions - Add new RFCs (0053, 0055-0059, 0062) - Add recorded dialogues and expert pools - Add ADR 0018 dynamodb-portable-schema - Update TODO with hook configuration notes Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
1.8 KiB
[PERSPECTIVE P01: RFC 0053's trait abstraction makes the backend choice a configuration decision, not an architectural one]
RFC 0053 already defines DialogueStore as a trait with SqliteDialogueStore and DynamoDialogueStore as interchangeable implementations behind a factory pattern. If the trait boundary is correct -- and it is, because every method maps to a bounded access pattern (get dialogue, register perspective, export) -- then "hybrid relational + DynamoDB" is just adding a third impl DialogueStore for PostgresStore. The supersession question is therefore premature: build the trait, ship DynamoDB as RFC 0058 specifies, and if relational queries prove necessary, add a backend without touching application code. The trait boundary is the architecture; the storage engine is a pluggable detail.
[PERSPECTIVE P02: Hybrid architectures fracture the EncryptedStore generic parameter space]
RFC 0058's EncryptedStore<S, K> is generic over both storage and key provider, giving compile-time proof that encryption wraps all storage operations uniformly. A hybrid architecture that splits writes across DynamoDB (for hot-path reads) and PostgreSQL (for ad-hoc queries) would either require EncryptedStore<(Dynamo, Postgres), K> -- collapsing the clean generic into a coordination layer -- or two separate EncryptedStore instances with split-brain risks on which backend is authoritative for a given entity.
[TENSION T01: Trait completeness vs. leaky abstraction risk]
The DialogueStore trait in RFC 0053 scopes to known access patterns, but if relational-only capabilities (JOINs, window functions, recursive CTEs for transitive closure on refs) leak into the trait surface, the abstraction becomes a lowest-common-denominator facade that makes DynamoDB callers pay for capabilities they cannot efficiently provide.