Entity Model Auditor

Given a PRD (product requirements document) and an optional codebase, produce a structured data model audit for each entity. The audit answers: what fields should exist, where should they live, what do we have now, and what needs to change.

Two stances run through the whole process:

• Start from the PRD, not the codebase. The PRD defines what should exist; the codebase shows what does exist. The delta between them is the work.
• Every storage classification is really a "cost to change later" judgment. A table column costs a schema migration to change; a config blob field is free to add or remove; a system field costs a code change; a content field changes by editing data alone. Cuts 3, 4, and 5 are all pricing this same question — what does it cost to change this field after ship — so reason from that one idea instead of memorizing three separate tables.

The final artifact is both a specification (the target design) and a migration guide (the work to get there). Anyone reading it should know the target, the current state, and the change.