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>
10 lines
2.4 KiB
Markdown
10 lines
2.4 KiB
Markdown
[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.
|
|
|
|
---
|