Um relato de bug de filtro que virou três issues separadas
O filtro relatado funcionava bem - o problema real era outro filtro, deliberadamente independente, e o fix certo foi uma terceira opção nunca cogitada.
O filtro relatado funcionava bem - o problema real era outro filtro, deliberadamente independente, e o fix certo foi uma terceira opção nunca cogitada.
Um gate de três vitórias, uma chamada a requestReview(), e uma crença recebida sobre o comportamento do simulador que se provou errada quando eu realmente testei.
O bug que registrei era uma proteção para algo impossível. A solução real foi uma exclusão em tempo de leitura, que quebrou outros quatro testes.
Um artefato de renomeação, uma API sem campo de autor, e um teste em dispositivo real provando que o bug já tinha se corrigido sozinho, fechado como está.
Não existe flag isEssential - Essentials é só uma playlist. featuredAlbums é o sinal real, e um fixture mudado expôs um teste que ninguém rodou de novo.
Um método de protocolo, um enum de estado reaproveitado, uma convenção de roteamento que se manteve, e um orçamento de lint que forçou uma divisão que valia a pena fazer de qualquer forma.
Medir no dispositivo encontrou um scan da biblioteca inteira rodando em cada lote do Discover - e uma armadilha de medição de 16x onde o cache HTTP favoreceu o caminho errado.
Um try? ?? [] fazia uma falha de rede parecer indistinguível de "sem lançamentos", o que deixou uma interrupção guardar em cache um feed vazio por cima de dados bons durante 24 horas.
Um filtro só era aplicado ao reabrir o app, porque uma TabView mantém os view models vivos e seu estado semeado fica congelado. A correção apagou um conceito.
CLAUDE.md serve para convenções estáveis, não para pegadinhas e lições aprendidas. Isso precisa de um cofre compartilhado único, não uma cópia por repo.
Página 1 de 4