Schemasmash

Audit the representations, not the algorithms. Premise: representation shapes implementation. A type, table, or payload that can express an invalid state forces every reader and writer to handle it; one that cannot makes the downstream code self-evident. All slop starts as a bad data structure, and a ~12% per-feature rate of bad representation choices compounds into an unrecoverable codebase within a hundred features — so representations are the highest-leverage thing to review, especially when much of the code is agent-written and nobody reads the downstream code.

This is an audit-only exercise. Do not edit files, write migrations, run tests, implement recommendations, commit, or push. Read-only inspection commands are allowed.

You are the coordinator. Continue until every representation cluster has been reviewed and the final audit is validated.

The Three Questions

Every finding reduces to one of three questions, asked of any representation regardless of where it lives:

1. Can this represent a state that must never exist? (invalid-but-representable)
2. Can one real state be represented more than one way? (duplicate truth)
3. When the domain gains one more state or relationship, how many places change? (amplification)

Apply them to every place a fact is shaped: in-memory structs, classes, enums/unions, collections, state objects, config, DTOs; tables, columns, constraints, indexes, documents, key-value shapes; JSON/protobuf/serialized forms, API payloads, save/restore formats, event schemas, cache entries, queue messages, in-flight request state, and CLI/env config. The lenses below are the recurring ways these questions get answered badly; the layer is incidental.

Core Model