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>
3.3 KiB
[PERSPECTIVE P01: The migration itself is the risk nobody is costing -- any supersession creates a window where two systems hold partial truth, and RFC 0058's encryption envelope makes that window uniquely dangerous] Macaron's MACARON-T01 identifies the missing rollback plan, but understates the severity: RFC 0058's client-side encryption means data is opaque blobs outside the application layer, so a stalled hybrid migration cannot be recovered by pointing a second database at the same bytes -- you must decrypt, re-encrypt with the new backend's envelope, and re-verify the audit hash chain for every migrated entity. A partial migration where some dialogues live in DynamoDB (encrypted, hash-chained) and others in PostgreSQL (with different encryption semantics) produces a split-brain state that is not just operationally painful but cryptographically unverifiable: the audit chain breaks at the migration boundary. Zero-downtime migration between encrypted stores requires a dual-write period with identical encryption envelopes on both sides, which neither RFC 0053 nor RFC 0058 specifies. Before debating which engine wins, the panel must answer: what is the concrete data migration protocol that preserves the hash chain across backend boundaries?
[PERSPECTIVE P02: RFC 0053's trait boundary is necessary but insufficient -- it abstracts queries, not migration]
Croissant and Cannoli correctly identify RFC 0053's DialogueStore trait as the escape hatch, but a trait that abstracts read/write operations does not address the three hardest migration problems: backfilling existing data into a new backend, maintaining write consistency during the cutover window, and verifying referential integrity post-migration. The trait gives you the ability to swap backends for new writes; it gives you nothing for the terabytes (or even megabytes) of encrypted, hash-chained history that must come with them. A migration-aware abstraction would need a MigrationStore trait with export_encrypted_batch, import_encrypted_batch, and verify_chain_continuity -- and designing that trait now, before the first byte is written to DynamoDB, is orders of magnitude cheaper than retrofitting it after RFC 0058 ships.
[TENSION T01: Encryption envelope portability is unspecified]
Neither RFC 0053 nor RFC 0058 defines whether the AES-256-GCM envelope format, AAD binding (which includes pk||sk), and hash chain structure are backend-portable or implicitly coupled to DynamoDB's key structure -- making any future backend swap a cryptographic re-engineering project rather than a configuration change.
[REFINEMENT: Strudel's schema-is-the-problem reframing applies doubly to migration] Strudel is right that the relational DNA of RFC 0051 is the root cause, but even an event-sourced redesign must answer the migration question: how do you move existing dialogue history from the old schema to the new one without breaking the audit chain? The schema debate and the migration protocol are the same problem viewed from different angles.
[CONCESSION: Donut's scale threshold argument is correct for the query cost debate] At sub-10K dialogues the DynamoDB query cost premium is negligible, and the hybrid's operational overhead is unjustified on pure cost grounds -- the migration risk I identify above is the stronger reason to avoid premature supersession.