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: Macaron's reverse-ref GSI does not solve the actual graph traversal problem]
|
|
Macaron proposes a GSI on `ref#{target_id}#{ref_type}#{source_id}` to handle reverse lookups, but the verdict assembly query is not a single reverse hop -- it is a transitive closure: verdict -> adopted recommendations -> addressed tensions -> originating perspectives -> supporting evidence, with each step requiring a separate Query call because DynamoDB GSIs return items, not joined result sets. Adding GSIs solves one-hop fan-out; it does not collapse a 4-hop traversal into a single round-trip. The denormalization in the verdict entity is not a "materialized view optimization" -- it is an acknowledgment that the traversal cannot be performed at read time at all, and each new entity type added to the chain requires updating the denormalization logic and re-validating consistency invariants that a recursive CTE enforces structurally.
|
|
|
|
[PERSPECTIVE P02: Strudel's event-sourcing reframe is correct but strengthens the relational case]
|
|
Strudel argued the schema is the real problem and proposed event streams as the fix. I concede the schema critique is sharp -- but event-sourced architectures with materialized views are exactly where relational databases excel, because the materialization step (folding events into queryable state) is a SQL view or trigger, not a custom application-layer projection that must be maintained in Rust. Redesigning around events without a relational projection layer just moves the complexity from the refs table into a bespoke event-fold engine.
|
|
|
|
[REFINEMENT: Narrowing my Round 0 parity claim after Scone and Cannoli's deployment argument]
|
|
I concede that my Round 0 embedded-Postgres parity argument (P02) underweighted the serverless deployment constraint Cannoli raised: DynamoDB's connectionless model genuinely simplifies Lambda/edge deployments in ways PostgreSQL cannot match today. My claim narrows: if the deployment target is containerized (ECS/Fargate), the parity advantage disappears; if serverless, DynamoDB's operational model wins on deployment even as it loses on query expressiveness.
|
|
|
|
[CONCESSION: Brioche is right that adding a second database for speculative analytics violates YAGNI]
|
|
Brioche's tension (operational simplicity vs. analytical query flexibility) is well-placed. I withdraw the cross-dialogue analytics argument as justification for hybrid today -- that query pattern is not yet load-bearing and should not drive architecture.
|
|
|
|
[TENSION T01: Verdict denormalization consistency is a correctness risk, not just an optimization tradeoff]
|
|
If a recommendation is adopted by a verdict and later a new tension is linked to that recommendation via a ref, the verdict's pre-computed `tensions_resolved` array is stale until a background consistency job or write-time cascade updates it -- and RFC 0058 specifies no such mechanism, meaning the denormalized fields silently drift from the refs graph.
|
|
|
|
---
|