Thanks @rawfan. I'll try to explain how I see the issue:
The reason I wanted to change its behaviour is that I feel it doesn't do its job well enough.
As a business owner who runs his own website, I feel very, very nervous about destructive Artisan commands in production. ConfirmableTrait is much better than nothing, but it is prone to failure.
It's all too easy to accidentally press "enter" twice and "confirm" the command. That's because "enter" is the last key you pressed. It's also easy to dismiss prompts without really reading them sometimes. Maybe you were in a rush; maybe you were expecting a different prompt and just "okayed" on through.
I wanted something safer, that would not be too much hassle either. The system I designed works like this:
In production, migrations/seeding are disabled; attempting to run them produces an error, not a prompt. You must unlock Artisan first: php artisan db:unlock. There is no way anyone would accidentally do this -- it's matching the command to the user's intent.
After Artisan is unlocked, these commands can be run. You can then re-lock Artisan using php artisan db:lock. You can also configure a cron job to run this command if Artisan has been unlocked for more than (say) 5 minutes.
I have it configured so that the default state is unlocked, and then the cron job (a Dispatcher scheduled command) is applied to whatever environments I want. This is more flexible than hard-coding the feature for production only; you might have other environments that you want protected.
However, as an alternative solution, I think ConfirmableTrait would be okay if "enter" did not confirm it.
