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>
16 lines
2.9 KiB
Markdown
16 lines
2.9 KiB
Markdown
[PERSPECTIVE P01: RFC 0053's trait boundary does not resolve the supersession question -- it encodes the question into a deferred decision with higher switching cost]
|
|
Croissant and Cannoli both argue that the `DialogueStore` trait makes the backend a pluggable detail, so we should build DynamoDB now and swap later. But this assumes the trait surface will remain backend-neutral over 9 weeks of DynamoDB-only development. In practice, every workaround for DynamoDB's graph traversal weakness -- the denormalized verdict fields, the write-time materialized views Macaron defends, the 3-5 future GSIs Cupcake anticipates -- will calcify into the trait's implicit contract. A `DialogueStore` trait shaped by DynamoDB workarounds is not a neutral abstraction; it is a DynamoDB-flavored interface that a future PostgreSQL implementation would have to honor even where it would naturally do something simpler. The trait does not defer the decision; it silently makes it.
|
|
|
|
[PERSPECTIVE P02: The event-sourcing reframe survives scrutiny but needs scoping -- the refs table is the only entity that genuinely requires redesign]
|
|
My Round 0 claim that the entire schema should be event-sourced was too broad. Most RFC 0051 entities (dialogues, experts, rounds, perspectives, tensions) map cleanly to DynamoDB's partition-scoped item model. The actual pain point is singular: the `refs` table encodes a typed directed graph that both Muffin and Eclair correctly identify as the source of all multi-hop traversal problems. Rather than redesigning the whole schema or introducing a second database, the targeted fix is to replace refs with per-entity adjacency lists stored as denormalized JSON arrays within each entity's encrypted payload -- which DynamoDB handles natively and which eliminates the need for the refs table entirely, at the cost of write-amplification that is bounded by dialogue size (typically under 200 entities).
|
|
|
|
[TENSION T01: Trait-shaped-by-workarounds vs. trait-shaped-by-domain]
|
|
The panel has not addressed whether the `DialogueStore` trait should be designed from domain access patterns (which are backend-neutral) or from the DynamoDB implementation experience (which will inevitably leak GSI-shaped query methods into the trait surface).
|
|
|
|
[REFINEMENT: Scoping the event-sourcing claim (STRUDEL-T01)]
|
|
I concede that full event-sourcing redesign is disproportionate to the problem. The refs table is the specific schema element that creates the storage engine mismatch; the other 13 entity types fit DynamoDB's model well enough. This narrows the fix from "redesign everything" to "redesign one table."
|
|
|
|
[CONCESSION: Encryption layer parity gap is real but orthogonal]
|
|
Brioche and Cannoli's operational arguments convinced me that the KeyProvider parity gap I raised in Round 0, while genuine, does not change the storage engine decision -- it is an independent problem that persists regardless of whether the backend is DynamoDB, PostgreSQL, or both.
|
|
|
|
---
|