I reached for a migration to delete rows — stale API tokens — because the change
needed to apply to every client. That is the wrong test, and the rule it violated
was written down nowhere.

The deciding question is structure or records, never reach. Schema belongs in a
migration because it is structure. Rows belong in the client's own database
because they are that client's data, even when several clients need the same
correction. A migration that edits rows edits them on every tenant at once, with
no review and no way to do it for one client only — and this product is one
install per client, each running the same software over their own records.

Also states plainly that we do not deploy: code is committed and pushed, and the
platform ships it. Nothing here triggers a CapRover build.

Records the code cannot run without — a permission it checks, a default setting
it reads — are genuinely ambiguous, and the repo has precedent both ways. Noted
as a grey area to ask about rather than pretending the line is clean.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>