方向冻结
确定范围、边界、体验原则和 KPI，避免后面高频回退。
把“嵌入式 / App / 云平台”三线扩成能真正收口结果的多 Agent 交付系统
这一页聚焦项目推进方式。第二轮之后，重点已经从“多加几个角色”升级为“范围怎么收口、接口怎么冻结、谁来签署、什么才算能放行”。
这页现在新增了什么
交付层已经从“组织建议”进入“执行门禁”。最重要的新增不在角色数量，而在放行条件。
Wave 1 收口
首发能力正式从完整 MVP 中剥离出来，不再和 Wave 1.1 混推。
Freeze Pack
绑定、latest truth、围栏、告警、命令等关键契约有了冻结包和门禁。
角色签署
产品、设计、项目、技术、QA、Ops 不再默认认可，而要按清单签署。
Companion Proof
`nRF52840` companion 被前移到 `M1`，不再拖到联调末期才暴露。
为什么三线拆分还不够
如果只有嵌入式、App、云平台三条线，最常缺的不是“执行人”，而是横向收口的人。
缺范围收敛
没有人持续判断哪些能力真的服务核心旅程，需求会自然膨胀。
缺体验一致性
文案、状态语义、页面回跳路径容易在多端实现中逐步漂移。
缺契约治理
字段、错误码、示例和回退语义没人统一守，联调会变贵。
缺联调与准出
每条线都“完成”了，但整条用户旅程未必真的可用。
推荐 Agent 结构
你现有的三条交付线保留，但增加五个横切角色，形成 3 + 5 的执行结构。
A0 Program Orchestrator
项目经理 + 总控。负责里程碑、依赖、风险、准出，不直接写业务实现，但能阻止“假完成”。
A1 Product Scope
负责范围、优先级、需求变更、KPI 和价值判断。
A2 UX Research & Design
负责 IA、状态设计、文案、无障碍、UI 交付稿。
A3 Contracts
负责 OpenAPI、事件 schema、BLE 契约、breaking change 风险。
A4 App Delivery
负责客户端实现，重点守住状态机、回跳、Widget 和交互一致性。
A5 Cloud Delivery
负责鉴权、接入、聚合、规则、通知、命令、OTA 和最新位置语义。
A6 Embedded Delivery
负责采样、上报、功耗状态机、命令执行、OTA 和设备可靠性。
A7 QA & Journey Validation
负责按旅程做测试，不只是按模块测功能。
A8 Release & Observability
负责 telemetry、看板、发布清单、回滚预案。Beta 前必须独立出来。
最小可行编组
如果前期不想一次性并发太多 agent，至少应保留 Program / Product / UX / Contracts / App / Cloud / Embedded / QA 这 8 类角色中的前 8 个，Release 前再把 Observability 单独拉出来。
里程碑
里程碑不是技术阶段，而是围绕用户旅程闭环和 release gate 来定义。
执行收口
锁定 `Wave 1 / Wave 1.1`、裁剪顺序和高风险前置验证计划，避免“大而全并行”。
契约与架构冻结
先把绑定、最新位置、告警、Widget 的关键字段和错误码钉住，并启动 companion proof。
首日可用闭环
登录、绑定、宠物建档、首页首屏必须走通。
日常确认闭环
Home、Map、Widget 达到 5 秒判断是否安全的目标。
告警与行动闭环
告警、地图聚焦、找寻模式、低电动作化全部串起来。
维护与发布准备
OTA、设备信息、看板、风险与回滚预案全部就位。
工作包拆分
后面无论是人类团队还是 agent 团队，都建议按工作包组织，而不是按仓库目录组织。
Workstream 1 · First Day Success
登录与会话、BLE 绑定、宠物建档、首页首屏。
Workstream 2 · Daily Confidence
Home 总览、多宠地图、单宠聚焦、Widget。
Workstream 3 · Action Under Stress
告警中心、告警详情、寻找模式、低电解释。
Workstream 4 · Trust & Maintenance
设备信息、OTA 可见性、监控与回滚、风险闭环。
Wave 1 范围与 Freeze Pack
真正能控制返工的不是“大家都知道重要”，而是把首发能力和关键接口明确钉住。
Wave 1 必达能力
- 登录与单移动端会话
- BLE 绑定与失败恢复
- 宠物建档与设备归属
- Home 首屏摘要与单宠地图
- 矩形围栏、告警动作化、寻找模式
- 最小单宠 widget 与低电解释
关键 Freeze Pack
- `FP-01` 绑定激活
- `FP-02` latest truth 与设备摘要
- `FP-03` 事件壳层与补传语义
- `FP-04` 围栏资源
- `FP-05` 告警与 deep link
- `FP-06` 命令与 ACK
协同节奏与准出规则
真正节约成本的不是减少同步，而是让同步有固定目的。
每周三次固定同步
- Scope Sync：范围变化、优先级、是否偏离 P0 旅程。
- Interface Sync：契约、字段、错误码、依赖阻塞。
- Journey Sync：按绑定 / 日常查看 / 告警找回三条旅程联调。
工作包完成前必须同时满足
- PRD / Feature Spec / Contract 已同步。
- UX 状态矩阵覆盖完成。
- Telemetry 已定义。
- QA 场景已跑通。
- 依赖阻塞已清空或被明确记录。
你当前最值得采纳的变更
保留 Embedded / App / Cloud 三个交付 agent，但务必新增 Program Orchestrator、Product Scope、UX Research & Design、Contracts、QA & Journey Validation 这五个横切角色。同时，把范围收口、Freeze Pack 和签署门槛作为同等级的 release gate。
角色签署与硬件红线
现在的交付层已经明确了一个现实原则：不是所有文档都写完了就算通过，而是关键角色要基于证据签字。
必须签署的角色
- Product Manager
- UI/UX Design Lead
- Project Manager
- Tech Lead
- App / Cloud / Embedded / Contracts Lead
- QA Lead 与 Ops Lead
不能碰的红线
- companion proof 未完成就进入大规模联调
- 关键冻结包未冻结就进入最终 handoff
- 原型验证未通过却直接上线
- 已知 High 风险没有 owner
重并行 vs 轻并行
这不是抽象管理术语，而是决定你现在应该怎么组织 agent 的执行方式。
轻并行
先把范围、体验和契约收敛，再往 App / Cloud / Embedded 下游推进。
- 优点：返工少，边界稳，适合需求还在变化时。
- 缺点：前期看起来节奏偏慢。
重并行
多条工作流同时推进，通过 Orchestrator 和 Contracts 强行收口。
- 优点：节奏快，能更早暴露真实联调问题。
- 缺点：如果契约没稳，返工会被放大。
对这个项目的建议
采用 前轻后重。`M0-M1` 用轻并行收敛范围和接口，`M2-M4` 再切到重并行，`M5` 回到受控并行做稳定和准出。
Roadmap 调整方向
基于竞品和市场样本，路线不是大改，而是更坚定地守住主叙事，并提前布局未来分支。
MVP 继续锁定
绑定、地图、告警、widget、可信度和低电解释继续保持最高优先级。
GA 提前布局
轻量形态、小型宠物版本、商业模式预案、健康深化能力可以进入 GA planning。
不要提前膨胀
复杂训练体系、重 AI 健康承诺、复杂社交和高级围栏管理暂不前提。