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.6 KiB
[PERSPECTIVE P01: The refs-table-only redesign is already half-implemented -- the codebase dual-stores refs and should drop the separate table]
The codebase already stores references as inline Option<Vec<Reference>> JSON arrays on every entity (perspectives, tensions, recommendations, evidence, claims) AND separately in the alignment_refs table. This is accidental dual-write: every entity carries its outbound edges as {type, target} pairs inside the entity payload, while alignment_refs redundantly stores the same edges as relational rows. Eliminating the alignment_refs table and relying solely on the per-entity inline refs is not a redesign -- it is removing the redundant copy. DynamoDB's partition-load-then-traverse pattern (Cannoli P01) works precisely because the inline refs already exist; the separate refs table is a SQLite artifact that DynamoDB does not need and that RFC 0058's ref#{source_id}#{ref_type}#{target_id} SK pattern merely re-encodes as DynamoDB items for no additional query benefit.
[PERSPECTIVE P02: Dropping the refs table simultaneously resolves MUFFIN R1-T01 and ECLAIR R1-T01]
If refs live only as inline arrays within their source entities (already encrypted inside the entity payload), then verdict denormalization of tensions_resolved and recommendations_adopted becomes unnecessary -- the in-memory graph assembly Cannoli described can reconstruct these from the partition load without pre-computing them at write time. This eliminates the consistency risk (MUFFIN R1-T01: stale denormalized arrays) and the domain-model leakage (ECLAIR R1-T01: DynamoDB-shaped fields surviving a backend swap) in a single move, because the denormalized verdict fields exist only to compensate for the cost of traversing a separate refs table that should not exist.
[TENSION T01: Inline-refs-only design requires the trait to expose graph assembly as a library, not a query method]
If the trait exposes fn get_verdict_with_context(...) that returns pre-assembled verdict graphs, every backend must implement the assembly logic independently. If instead the trait returns raw entities and a shared library assembles the graph in-memory, the trait stays thin and backend-neutral -- but no RFC specifies which layer owns graph assembly.
[RESOLVED: STRUDEL R1-T01 (trait shaped by workarounds vs domain)] The inline-refs-only design resolves this: when refs are embedded in entities and graph assembly is a shared library function operating on domain structs (not a trait method), the trait surface contains only partition-scoped CRUD -- naturally implementable by any backend -- and the DynamoDB-vs-relational question cannot leak into the trait shape.