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.5 KiB
[PERSPECTIVE P01: DynamoDB + materialized projections inside the partition solve the graph traversal problem without a second database]
Muffin and Eclair's multi-hop traversal concern is valid but bounded: RFC 0051 dialogues have at most ~10 rounds, ~10 experts, and ~50-100 entities per dialogue, meaning the entire entity graph fits within a single DynamoDB partition retrievable in one Query (PK = dialogue#{id}, no SK filter, typical response < 100 items). A "full graph load" into an in-memory adjacency map -- then traverse locally -- costs a single read request and ~10KB of bandwidth, making client-side graph assembly trivially cheap at actual data volumes. The verdict denormalization is not an admission of failure; it is a deliberate write-time projection that trades one extra write per verdict for zero read-time fan-out, which is the standard DynamoDB pattern and not an argument for adding PostgreSQL.
[PERSPECTIVE P02: Strudel's event-sourced redesign is the right long-term frame but the wrong near-term action] Strudel correctly identifies RFC 0051's relational DNA as the root mismatch, but redesigning the schema now invalidates two shipped RFCs (0051 and 0058), resets the 9-week implementation clock, and defers the encryption story indefinitely. The pragmatic path is: ship RFC 0058 behind RFC 0053's trait boundary, accumulate real production query patterns, and let those patterns -- not theoretical graph-traversal cost -- drive whether an event-sourced redesign or a backend swap is warranted. This is not sunk-cost fallacy; it is the difference between speculative architecture and evidence-driven iteration.
[REFINEMENT: CANNOLI-T01 partially answered by deployment context in RFC 0058] RFC 0058's architecture (connectionless DynamoDB, stateless encryption in the compute layer, Lambda-compatible cold-start profile) implicitly targets serverless deployment. The panel should treat serverless as the baseline constraint, which tilts the calculus decisively against introducing connection-managed PostgreSQL as a production dependency.
[CONCESSION: Eclair's reverse-ref query gap is real but solvable with one GSI]
Eclair is right that ref#{source}#{type}#{target} only supports forward traversal; reverse lookups ("what references target P0001?") need a GSI with PK = ref_target#{target_id} and SK = ref_type#{source_id}. This is a missing GSI in RFC 0058, not a missing database. I concede the gap exists but reject the conclusion that it justifies a relational engine.