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