Change review · Offline analysis

When a field is about to disappear, ask who still relies on it.

The product team wants to remove an old field and the migration does not exist yet. “Nobody seems to use it” is weak evidence. Start by collecting what local evidence can show—and clearly name what it cannot.

The review: Before writing DDL for a field removal, type change, or relationship change, the reviewer wants to see which contracts, saved-query names, and verification records may be related to the current schema or ORM definition.

An impact report that does not pretend to know everything

Choose the one present-day shape to compare against

Use the schema cache for the known database shape, or an explicit ORM artifact for the application model. The assessment chooses exactly one baseline so the report says what it compared.

dbcli impact assess --design ./dbcli.design.json --against-cache --output ./impact.json --format json --fail-on warn

Bring declared workload evidence only when available

An explicit local events file can add recent, redaction-first table metadata. It remains optional evidence; missing, stale, malformed, unreadable, or redacted workload data stays visible as a coverage gap.

dbcli impact assess --design ./dbcli.design.json --against-orm ./prisma/schema.prisma --events ./.dbcli/proxy/events.jsonl --output ./impact.md --format markdown --fail-on never

Review findings and gaps together

Use the report in migration review alongside the design change. Semantic contracts, saved-query names, verification metadata, and reviewed data-access metadata can enrich known dependencies, but gaps remain part of the result.