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.4 KiB
[PERSPECTIVE P01: RFC 0051 refs table is a typed directed graph that DynamoDB single-table design cannot query natively]
The refs table defines 8 semantic edge types (support, oppose, refine, address, resolve, reopen, question, depend) across 5 entity types, creating a typed directed graph with up to 25 distinct edge-pair combinations. DynamoDB's single-table design encodes each ref as ref#{source_id}#{ref_type}#{target_id}, which supports forward traversal (given a source, find its targets) but makes reverse traversal ("what supports P0001?") require a GSI or full-partition scan. In a relational database, SELECT * FROM refs WHERE target_id = 'P0001' AND ref_type = 'support' is a single indexed query; in DynamoDB, answering "show me the full dependency chain from verdict V01 back through its adopted recommendations, the tensions they address, and the perspectives those tensions depend on" requires multiple sequential round-trips with application-level graph assembly. This is not a theoretical concern -- it is the exact query pattern the verdict entity's tensions_resolved, key_evidence, and key_claims fields exist to serve, and denormalizing those chains into the verdict record is an admission that the graph cannot be traversed at query time.
[PERSPECTIVE P02: PostgreSQL achieves true local-prod parity without Docker overhead via embedded options] RFC 0058's strongest argument is local-prod parity, but PostgreSQL achieves identical parity through embedded Postgres (pgtemp, pg_embed) or Neon's serverless driver, both running the same wire protocol and query planner as production. The Docker-for-DynamoDB-Local requirement actually introduces a parity gap: DynamoDB Local is a Java-based simulator with documented behavioral divergences (no IAM, no capacity limits, different error codes for throttling), whereas a local PostgreSQL instance runs the identical engine as production.
[TENSION T01: Denormalized verdict fields prove the graph is too expensive to traverse in DynamoDB at query time]
The verdict entity pre-computes tensions_resolved, recommendations_adopted, key_evidence, and key_claims as JSON arrays because reconstructing these relationships from the refs table in DynamoDB would require unbounded sequential reads -- but this denormalization creates a write-amplification and consistency problem that a relational JOIN solves at read time with zero duplication.