Você apagou app/code/Vendor/Modulo pra limpar o projeto e agora qualquer comando morre com Unknown module(s) 'Vendor_Modulo' in the enabled modules list. Please check your configuration. Não é cache nem permissão: a lista de módulos habilitados vive em app/etc/config.php e continua citando um código que não existe mais no disco.
Tire a linha do array em app/etc/config.php
Ache a chave, apague a linha inteira e normalize o arquivo em seguida:
cp app/etc/config.php app/etc/config.php.bak
grep -n "Vendor_Modulo" app/etc/config.php
'modules' => [
'Magento_Store' => 1,
'Vendor_Modulo' => 1, // essa linha sai
'Magento_Directory' => 1,
]
bin/magento setup:upgrade
bin/magento cache:flushEsse arquivo é a fonte da verdade sobre quem está ligado. No bootstrap o Magento cruza a lista com os módulos que se registraram de fato pelo ComponentRegistrar, em app/code, em vendor e em setup. Sobrando nome sem código correspondente, ele para de propósito: carregar metade de um módulo, com schema declarado e sem as classes, deixaria a loja num estado imprevisível.
Se o pacote veio do Composer, a ordem é outra
Com os arquivos ainda no lugar, não edite o config.php na mão. O module:uninstall precisa do código presente pra rodar os scripts de desinstalação, e ele mesmo tira a entrada do config.php e chama o composer remove no fim. Faça o dump do banco antes: o --remove-data derruba as tabelas do módulo e não tem desfazer.
mysqldump -u usuario -p nome_do_banco > backup-antes-do-uninstall.sql
bin/magento maintenance:enable
bin/magento module:uninstall Vendor_Modulo --remove-data
bin/magento maintenance:disableEle só enxerga módulo que é pacote Composer. Pra código solto em app/code existe a flag --non-composer, que limpa o registro e os dados mas não apaga os arquivos — esses saem na mão mesmo. Antes de subir, olhe o git diff app/etc/config.php: o setup:upgrade costuma ligar módulos novos na mesma passada e isso vai junto no commit sem você perceber.