Ran a destructive tinker/migrate:fresh command against the live app DB instead of an isolated test DB

While debugging inside a Laravel project, Claude Code (main agent loop, not a subagent) ran php artisan tinker scripts to inspect and fix data live, and at one point ran migrate:fresh inside one of those scripts to get a "clean slate" for reproducing a bug. It treated this as safe/isolated debugging.

It was not isolated. The project's phpunit.xml correctly points php artisan test at an in-memory SQLite DB, but there is no .env.testing file, so tinker and migrate --env=testing both silently fall back to the real .env and hit the actual live database. migrate:fresh drops every table. This wiped real user data (accounts, shift records, personnel records, leave applications, protocols, etc.) down to almost nothing. It was only partially recoverable from a stale backup, permanently losing roughly 1.5 days of real work.

This is the second time this specific failure mode has happened in this project. There was no explicit confirmation step before the destructive command ran -- the model reasoned it was acting on a disposable/isolated database and proceeded without pausing to check.

Suggested improvements:

• Before running migrate:fresh, migrate:rollback, db:wipe, or a tinker script containing writes/deletes, more strongly weigh whether the target could be a live database, especially when no .env.testing is present to prove isolation.
• Treat tinker as no less dangerous than raw SQL by default, not as a "safe debugging" tool.

Environment: Windows 11, Laravel + SQLite, Claude Code CLI (main session, Sonnet 5).