收尾两批并行开发的文档回写与任务包

- Sprint 执行计划 v1.1：§1.1 补第一批交付实据；T9 SPIKE 结论回写 Sprint 1 表
  （T-P0-16 通过 2.8ms；T-P0-12 有条件；T-P0-10 原型 6/6 + 真实照片重验前置）；
  Sprint 2 表标注 T-P2-01~06 交付；新增 §9 两批交付记录
- 开发任务拆解 v1.5：交付回写 + 新风险登记（RTMPose 域差异、BiRefNet 异步化）
- 新增 开发任务包/：三批多 agent 并行的协作规程与 14 份任务契约
- 新增 前置开通清单-云资源与资质.md
- 清理已用毕的评审报告（文档评审 2026-08-13、项目整体评审 2026-08-14），
  README 中相应引用改为留痕表述

docs/鸿蒙美搭-智能穿搭美学助手-产品方案.md

@@ -1538,7 +1538,7 @@ V1 不接入支付，因此**本节对 V1 不产生任何影响**。但 V2 定
 **作者**：产品团队
 **状态**：待评审
 **变更说明**：
-- v6.1（2026-08-13）：文档一致性评审修订（见《文档评审报告-2026-08-13》）
+- v6.1（2026-08-13）：文档一致性评审修订（2026-08-13）
   - **§5.2.1 / §5.3.1 成本口径彻底重写，并推翻一个错误论证**。原文称「月度成本上限 = MAU × 单用户配额成本上限，是可事前算准的确定值」，有两个漏洞：① 数字算不平（15 万 × ¥8 = ¥120 万 ≠ ¥12 万）；② **更根本的是，按人头发配额封不住总成本** —— 配额约束单用户，而总成本 = MAU × 人均，MAU 无上限。现改为：单用户成本分**物理上限 ¥236 / 重度 ¥150 / 人均预期 ¥0.8** 三档；总成本 ¥7~12 万定性为**预期值（含使用率假设）而非硬上限**，并给出可复算的算式；**新增「全局日成本熔断」为唯一真正的封顶机制**（`NFR-COST-02`，四档自动降级，非仅告警）
   - **§8.3.1 性能指标改为引用 `NFR-PERF-*`**，不再自成一套。连带修正四处：初级报告 60s→90s、全面报告 5min→180s、换装改「现状基线 → 目标值」两段式、**可用性 99.9%→99.5%**（V1 单可用区无冗余，99.9% 在架构上无法兑现）
   - **§8.3.3 诊断准确率拆为「Phase 0 验证门槛 / 上线质量门槛」两档**，此前两套数值冲突的根源就是没区分这两档（两者的失败后果完全不同：前者触发换方案，后者触发维度降级）