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: Hybrid architecture reintroduces the code-path divergence RFC 0058 was built to eliminate] RFC 0058's entire raison d'etre is "the code you test is the code you ship" -- one storage engine, configuration-only differences between local and prod. A hybrid PostgreSQL+DynamoDB architecture means two query languages, two consistency models, two failure modes, and an implicit decision about which entities live where. Every "which backend handles this query?" branch is a code path that diverges between local Docker Compose (where latency and failure characteristics differ) and production. The user explicitly rejected tiered architectures for exactly this reason; a hybrid is a tiered architecture wearing a different hat.
[PERSPECTIVE P02: Local-prod parity for PostgreSQL is actually harder than for DynamoDB] DynamoDB Local is a single Docker image with identical API surface to production. PostgreSQL local-prod parity requires matching extensions (pg_cron, pgvector if added later), version-pinned images, connection pooling behavior (PgBouncer vs serverless proxies like Neon's), and replication-lag-sensitive read patterns. Adding PostgreSQL to achieve "better relational modeling" trades one parity problem (DynamoDB's awkward graph queries) for a much larger surface area of local-prod drift.
[TENSION T01: RFC 0051's relational schema genuinely strains single-table DynamoDB design] The 14-entity typed directed graph with M:N cross-references and recursive dependency chains is a legitimate mismatch for DynamoDB's access-pattern-first model, and ignoring this tension weakens the case for keeping RFC 0058 as-is.