FeathersJS Knex migration down function safety after schema changes

Goal

To guarantee that rolling back a FeathersJS migration will not leave orphaned columns, indexes, or corrupted data when a schema change is applied.

Constraints & Uncertainty

Knex migrations require manual down functions; FeathersJS does not enforce any checks that the down logic fully reverses the up logic. This can lead to incomplete rollbacks, especially after data‑transforming operations or type changes. The current documentation lacks a built‑in helper to validate that a down script restores the original schema state and preserves unrelated data.

Specific Questions

• What mechanisms can be introduced in FeathersJS to automatically verify that a down migration restores the exact pre‑migration schema and data state?
• Is there a recommended pattern to capture and restore data that is modified or added during an up migration when performing a rollback?
• Could a FeathersJS configuration flag enforce that all migrations include a corresponding down function that passes a safety audit before deployment?