fix (opt-in writer)

disable-model-invocation: true means the model can never trigger this on its own — only the user running /claude-db:fix. Writes happen only through the db-migration-writer subagent (the one agent with Write/Edit) and only after explicit confirmation. Default is dry-run.

Fixability classes (from each finding's fixable field — see schema/finding.schema.json)

• AUTO — deterministic, additive, reversible, machine-verifiable, low-semantic-risk. May be written (with diff + confirmation), expressed as an expand-contract migration where the change is online-safe: add a missing non-unique index / FK-supporting index; add a NOT NULL/CHECK/UNIQUE constraint via NOT VALID then VALIDATE; add a missing FK as NOT VALID then validate; add a default or generated column additively; widen an undersized integer key. Each ships with a clean down-migration.
• PROPOSED — changes data, semantics, or shape; generate a draft migration and require per-item accept: type changes that coerce/rewrite data (e.g. float→numeric money), backfills, denormalization/normalization moves, renames, enum mutations, soft-delete/temporal columns.
• ADVISORY — never written by the tool: engine choice (M0), sharding/partitioning topology, RLS/security policy design, capacity/scaling decisions, anything requiring real production data or a judgment call about intent.

Workflow

1. Take the findings (from the last audit or a fresh one / a findings JSON). Filter to fixable: auto (+ proposed if the user opts in). Honor --category to scope.
2. For each, build the exact migration (expand-contract steps where rewrite/lock risk exists), with a plain-language line before each diff explaining what it does and why — then the unified diff / migration file content. Resolve any required real inputs (backfill values, enum target set, FK target) by asking the user — never invent them.
3. Dry-run (default): print every plain-language line + diff grouped by file/step. Write nothing. Summarize what fix (without --dry-run) would change, including lock level and reversibility per step.
4. On explicit confirmation (and only then): delegate to db-migration-writer to apply. Per-change or batch confirmation is the user's choice.