用途：该技能对 Mushi Mushi 流水线做端到端冒烟测试，可在完成配置、部署后，或需要证明整条闭环可用时运行。
前置条件：mushi doctor 全部通过（不确定时先运行 mushi-health）；anthropic 与 firecrawl 至少各有一个 BYOK 密钥处于激活状态；准备好要映射故事的应用 URL。
主要阶段与用法：
- 缺陷捕获：运行 mushi test，预期返回 Test report submitted — id: rep_...；可在数据库 reports 表确认 status = classified 且 severity 非空（约 30 秒内）。超过 60 秒仍为 pending，说明 classify-report 边缘函数失败，可用 get_logs(service: 'api') 排查。
- AI 分类：运行 mushi reports list --limit 1，输出应含 severity、category、blast_radius；也可用 MCP 的 get_report_detail(reportId) 确认 classification.severity 与 classification.category 已设置。
- 故事映射：运行 mushi stories map --url https://your-app.com --wait，--wait 会轮询至爬取完成（通常 30–90 秒）；预期输出爬取页数、Claude 起草的用户故事数与提案 prop_...。可在 inventory_proposals 表确认 source = 'live_crawl'、status = 'pending_review'，然后在控制台 Inventory → Discovery → Past proposals 接受提案。
- TDD 测试生成：用 mushi tdd pending 列出已接受清单中的故事，再用 mushi tdd gen <story-id> --mode review 生成测试（进入审批队列），预期生成 qa_... 并打开草稿 PR；可在 qa_stories 表确认 source = 'test_gen_from_story'、approval_status = 'pending_review'，或用 MCP 的 list_pending_review_stories(projectId)。
- 审批与执行：运行 mushi tdd approve <qa-story-id>，再运行 mushi tdd run <qa-story-id>；在 qa_story_runs 表确认 status = 'completed'（失败也可接受，说明测试确实运行并发现真实摩擦），或用 MCP 的 run_qa_story(projectId, qaStoryId)。
- PDCA 改进循环：若第 5 阶段失败，运行 mushi tdd improve，Claude 会分析失败、编写改进测试并排队待审；在 qa_stories 中确认存在 source = 'pdca' 且 parent_story_id 指向原故事的记录。
- 演进循环（可选）：通过 MCP 资源 project://dashboard 查看 judge_scores 上升、recurrence_rate 下降、fix_attempts 中 completed 多于 failed。
适用场景：配置或部署后的整体验证；也可只跑第 1–2 阶段做约 60 秒的快速冒烟，只跑第 3 阶段验证故事映射，或只跑第 4–6 阶段验证 TDD 相关函数。
限制：需要有效的 BYOK 密钥与可访问的应用 URL；第 5 阶段默认使用 firecrawl_actions，若要测试 Browserbase，需先在控制台把 QA 故事的 provider 设为 'browserbase'。任一阶段失败说明对应边缘函数出错，可用 mushi-debug 做针对性诊断。