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>
2.9 KiB
[PERSPECTIVE P01: The trait boundary resolves supersession only if the trait never acquires graph-traversal methods]
The Judge asks whether RFC 0053's trait boundary "fully resolves or merely defers" the supersession question. I examined the actual codebase: alignment_db.rs contains zero recursive graph traversals -- every query is a single-table scan scoped by dialogue_id plus flat lookups by entity type. The DialogueStore trait in RFC 0053 mirrors these bounded patterns exactly. The trait resolves the question today because the application code does not need graph traversals today. But the resolution is conditional: the moment someone adds fn transitive_refs(&self, id: &str) -> Vec<Ref> to the trait, DynamoDB becomes the bottleneck and the abstraction leaks. The discipline is not "pick the right backend" but "keep the trait surface bounded to what both backends can serve in O(1) partition reads."
[PERSPECTIVE P02: Strudel's event-sourcing reframe is correct in diagnosis but wrong in prescription]
Strudel identified that RFC 0051's relational DNA is the root cause of the storage mismatch, and the codebase confirms it -- the schema was designed as SQLite tables first. But redesigning around append-only events would invalidate two shipped RFCs and restart the 9-week implementation clock. The cheaper fix is Macaron's materialized-view pattern applied at the trait boundary: keep the relational schema as the logical model, materialize the DynamoDB-friendly projections at write time via the EncryptedStore<S, K> wrapper, and let the trait hide whether the backend JOINs or denormalizes. This preserves both RFCs and acknowledges the mismatch without rewiring the foundation.
[TENSION T01: Trait method additions are the real governance gap]
No RFC or ADR currently governs what methods may be added to DialogueStore. Without a review gate that requires each new trait method to demonstrate O(1)-partition-read implementability on DynamoDB, the trait will accumulate relational-only methods over time and silently make the DynamoDB backend unviable, turning the "pluggable backend" promise into dead code.
[REFINEMENT: Sharpening CROISSANT-T01 from Round 0] My original tension about "leaky abstraction risk" was abstract; the concrete version is that the trait is safe exactly as long as trait method additions are governed by an access-pattern review gate, which does not yet exist in the RFC 0053 or RFC 0058 process.
[CONCESSION: Eclair's reverse-traversal concern is real but not yet load-bearing]
Eclair correctly showed that reverse ref lookups require a GSI or full-partition scan in DynamoDB. However, grep -r across the entire Rust codebase reveals zero call sites performing reverse or transitive ref traversals. The concern is architecturally valid but not yet a production requirement, which means it belongs in the trait governance gate, not in a supersession decision.