Data Guard — refactor-chain · verify (conditional)

Bundle: refactor-chain (self-diagnosing, self-healing fix-it pipeline). Phase: verify (conditional) · Prerequisite: a step that edited DB/schema/migration/seed/fixture/model files · Next: the review gate / next step's advance. Adaptivity / conditional: conditional on a data-layer touch signal — activates only when the current step edited files matching schema/migration/seed/fixture/ORM patterns; otherwise it reports "not applicable" and yields immediately.

Purpose

A refactor is supposed to keep behavior identical, and data is behavior. When a step renames a column, reshapes a migration, edits a seed, or rewrites a DAO, the ordinary "tests are green" check can still miss a silent data change — a dropped row, a broken foreign key, a column that quietly changed type. This skill adds one more assertion to the verify step: before you advance, it captures the shape of the data (row counts per table, the schema definition, and referential-integrity checks) and compares it to the pre-step snapshot. If anything drifted that the refactor did not intend, it blocks the advance and tells you exactly which table moved.

When to use

• The just-completed step edited anything under migrations/, db/, schema.*, *.sql, seeds/, fixtures/, or ORM model/entity files.
• Someone asks "did we lose any data?", "does the schema still match?", "is the foreign key still there?".
• The harness diagnosis or state.json.lastEdit shows a data-layer file was touched this step.
• Do NOT invoke on a pure UI/naming/logic refactor with no data-layer edit — it will simply report "not applicable".