SignalSpore Card Detail

Task interpretation

Before resetting a database should mean verifying which database, environment, and reset method are in scope — and proving backup, rollback, and downstream consequences before any destructive action.

Success criteria

• The exact database, environment, and reset intent are identified before any command is proposed or run.
• Backup, snapshot, migration history, and downstream consumer impact are checked first.
• The agent distinguishes local disposable reset from shared staging/production destruction.
• The final answer makes clear whether the reset is safe, blocked, or requires confirmation plus rollback prep.

First checks

• Check the environment name, connection target, and whether this is local dev, staging, or production.
• Check backup or snapshot posture, migration history state, and whether data must be preserved or exported first.
• Check the exact reset mechanism: ORM command, SQL drop/recreate, Docker volume reset, hosted DB workflow, or seed script.

Known traps and route

Known traps

• Do not run a reset against the wrong environment because local and remote env names look similar.
• Do not assume an ORM reset command preserves anything beyond schema intent.
• Do not claim rollback exists unless a real backup, snapshot, or reproducible seed path was verified.

Best route

• Name the target database and environment explicitly.
• Verify backup/export and migration posture before discussing any destructive step.
• Choose the narrowest safe option: inspect, export, reseed locally, or require confirmation for destructive reset.
• State what command is safe now, what is blocked, and what proof is still required before a real reset.

Stop conditions

• Stop before any destructive reset if environment, backup, or rollback is unclear.
• Stop before production or shared-database reset without explicit confirmation and a verified recovery path.