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 governance gate is an ADR with a compile-time marker trait, not a review checklist]
The Judge asks what the governance gate concretely looks like. A review checklist is unenforceable; an RFC is too heavyweight for individual methods. The answer is an ADR (extending ADR-0018) that establishes two rules: (1) every DialogueStore method must accept a dialogue_id as its partition key and return results scoped to that partition -- methods like get_cross_dialogue_stats and find_similar_dialogues (which today scan all tables without a partition key) are excluded from DialogueStore and placed on a separate AnalyticsStore trait with no DynamoDB implementation requirement; (2) the Rust type system enforces this via a marker trait PartitionScoped on all return types, so a method returning Vec<(String, String, i32)> from a cross-table JOIN cannot satisfy the bound without explicit opt-in. I audited alignment_db.rs: of its 34 public functions, exactly 3 (get_cross_dialogue_stats, find_similar_dialogues, get_scoreboard with its cross-dialogue expert ranking) violate the partition-scoped rule. The other 31 already take dialogue_id as their first parameter and return partition-scoped results. The gate is not a burden on 91% of the existing surface -- it is a fence around the 9% that would silently break DynamoDB.
[PERSPECTIVE P02: Eclair's denormalization leakage (ECLAIR R1-T01) is resolved by the same trait split]
Eclair correctly identified that DynamoDB-specific denormalized fields leak into the domain model. But if the DialogueStore trait returns domain types (not storage types), and the DynamoDialogueStore impl performs denormalization internally at write time and reassembly at read time, the domain model never sees tensions_resolved arrays. The denormalization is an implementation detail of DynamoDialogueStore, not a trait contract. Strudel's concern about trait-shaped-by-workarounds (STRUDEL R1-T01) is also addressed: the trait is shaped by domain access patterns (partition-scoped entity CRUD), and the DynamoDB workarounds live behind impl DialogueStore for DynamoDialogueStore where they belong.
[REFINEMENT: Sharpening CROISSANT R1-T01 into a concrete proposal]
My Round 1 tension identified the governance gap abstractly. The concrete resolution is: an ADR mandating that DialogueStore methods must be partition-scoped (accept dialogue_id, return results within that partition), enforced by a PartitionScoped marker trait on return types, with cross-partition queries segregated to a separate AnalyticsStore trait that backends may optionally implement.
[RESOLVED STRUDEL R1-T01]
The trait-shaped-by-workarounds tension dissolves if the trait surface is defined by domain access patterns (partition-scoped entity CRUD) and the DynamoDB-specific denormalization logic lives entirely within the DynamoDialogueStore implementation, invisible to the trait contract.