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.7 KiB
Markdown
16 lines
2.7 KiB
Markdown
[PERSPECTIVE P01: RFC 0053's trait boundary is necessary but not sufficient -- it defers the decision without reducing the decision's cost]
|
|
Croissant argues the trait makes the backend "a pluggable detail," but swapping a DynamoDB implementation for PostgreSQL behind `DialogueStore` is not a config change -- it is a new 9-week implementation with different transaction semantics, different consistency guarantees, and different encryption integration (DynamoDB's item-level client-side AES-GCM vs PostgreSQL's column-level or TDE story). The trait boundary reduces application-layer coupling but does not reduce the total cost of building, testing, and operating a second backend. Treating the trait as a solved escape hatch creates false confidence that a future swap is cheap; the honest framing is that the trait buys you the option, but exercising that option still costs as much as the original RFC 0058 implementation.
|
|
|
|
[PERSPECTIVE P02: Strudel's event-sourced redesign is the intellectually honest answer but the operationally wrong one right now]
|
|
Strudel is correct that RFC 0051's relational DNA is the root cause of every tension in this dialogue -- the schema was designed for SQLite JOINs and then shoved into DynamoDB. But redesigning around append-only events invalidates two shipped RFCs (0051 and 0058), resets the 9-week clock to zero, and produces no shippable artifact sooner than the current plan. The pragmatic path is to ship RFC 0058 with its known denormalization costs, instrument the actual query pain points in production, and let the data -- not the architecture astronauts -- tell us whether event-sourcing or a relational swap is warranted.
|
|
|
|
[REFINEMENT: Rollback plan (MACARON-T01) can be concretely scoped via RFC 0053's trait boundary]
|
|
My Round 0 tension about missing rollback plans is partially addressed by Croissant's trait argument: if RFC 0053's `DialogueStore` is implemented first, and DynamoDB is built behind it, the rollback from a failed DynamoDB migration is simply "revert the config to SQLite" -- no data split-brain, because the trait enforces a single active backend at any given time, not a hybrid dual-write.
|
|
|
|
[RESOLVED T01: MACARON-T01 (no rollback plan)]
|
|
RFC 0053's single-active-backend factory pattern provides the rollback mechanism: revert the config, keep SQLite as the fallback implementation, no partial-data-in-two-backends scenario arises.
|
|
|
|
[TENSION T01: Denormalization cost is real but unmeasured]
|
|
Muffin's write-amplification concern on verdict denormalization is valid in theory, but nobody has measured the actual write cost: with at most ~10-20 verdicts per dialogue, the amplification is bounded and small -- the panel should quantify this before treating it as an architecture-forcing constraint.
|
|
|
|
---
|