[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.

---