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>
1.6 KiB
[PERSPECTIVE P01: Single-table design already handles the RFC 0051 graph]
The RFC 0051 schema's 14 entity types, cross-references, and lifecycle tracking are well within single-table design's proven envelope. The ref#{source}#{type}#{target} sort key pattern encodes directed edges natively, GSI-2 enables cross-dialogue tension queries, and every hot-path query is scoped to a single partition key (dialogue#{id}), which is exactly the access pattern DynamoDB optimizes for. Adding a relational database does not simplify these queries -- it adds a second operational surface, a second failure mode, and a second consistency boundary that must be kept in sync.
[PERSPECTIVE P02: The "graph complexity" argument conflates schema complexity with query complexity] M:N cross-references and recursive dependency chains sound relational, but the actual access patterns in RFC 0051 are hierarchical reads within a dialogue partition plus three GSI-backed cross-partition lookups. No query traverses more than two hops. DynamoDB single-table design was purpose-built for exactly this: known access patterns with bounded fan-out. A relational database would only be justified if ad-hoc multi-hop graph traversals were a hot-path requirement, and nothing in the current system demands that.
[TENSION T01: Unbounded future query patterns vs. locked access patterns] If cross-dialogue analytics (e.g., "find all tensions influenced by perspectives from expert X across 50 dialogues") becomes a production hot path, single-table design would require new GSIs or a read replica strategy, while a relational backend could answer ad-hoc queries natively.