# 集成路线

## M0：公共契约冻结

整体开发负责人完成：

- 确认四个领域标识、目标 zone/instance 命名和首个 reference platform。
- 评审 `IntentIR`、`FunctionConfig`、`FunctionPreset`、`CommandPlan` 和错误模型。
- 发布 SDK v0.1、虚拟 CAN Gateway 和契约测试基线。
- 把 `contracts/`、`platforms/` 和中央 `src/` 设置为受保护路径。

准入条件：四位领域负责人能够只在自己的目录中完成一个静态 preset 的公共 Schema 校验。

## M1：单领域闭环（并行开发）

每个领域独立交付：

```text
一句话 -> IntentIR -> Domain Generator -> FunctionConfig
       -> Domain Validator -> Compiler -> CommandPlan
       -> Virtual CAN -> Telemetry -> ExecutionReport
```

中央团队同期交付 Registry、公共 Runtime、artifact writer、事件流和 API 的 dry-run 接口。领域成员不各自实现 Agent 服务、HTTP 服务或 CAN sender。

合入门槛：

- 至少 1 个 preset 和 3 个自然语言自定义参数用例。
- 合法、边界、非法、歧义、超时、回读错误用例齐全。
- 领域配置不能包含其他领域 capability。
- golden `CommandPlan` 稳定，虚拟 CAN 测试可重复。
- 映射和标定只有达到相应验证状态后才能进入 HIL/实车环境。

## M1.5：单领域总线集成

集成人员逐个接入真实 DBC 和 HIL，顺序执行而非一次接入全部领域。每接入一个领域：

1. 锁定 DBC hash 和平台标定版本。
2. 检查 command rate、counter/checksum、session/enable 信号和完成回读。
3. 验证急停、超时、进程重启、总线断开和 ECU 拒绝。
4. 将映射状态从 `draft` 提升为 `hil_verified`；实车验证后再提升为 `vehicle_verified`。

准入条件：四个领域均能经同一个 Runtime 和 CAN Gateway 独立 dry-run；需要进入场景的领域至少达到 HIL 可用状态。

## M2：跨域场景编排

整体开发负责人实现：

- 多领域 Router 和 Scene Planner。
- `SceneConfig` 引用解析、DAG 校验、资源锁和跨域策略。
- parallel/sequential/DAG 调度、失败传播、取消和补偿。
- 场景级 artifact、trace 和 ExecutionReport 汇总。

领域插件不增加场景特有代码。一个场景中的四份 `FunctionConfig` 必须仍可脱离场景单独执行。

首批集成场景建议只覆盖：

- 两领域并行且都成功。
- 一个领域失败导致全场景终止。
- 非关键领域失败后继续。
- 有依赖和时间偏移的 DAG。
- 两个 operation 竞争同一物理资源时拒绝执行。

## M3：一句话 Web 闭环

API/Web 团队实现请求输入、结构化事件流、配置查看、歧义确认、dry-run 和执行报告。页面只展示可审计的事实与决策摘要：识别的领域、采用的能力、默认值来源、验证结论、安全门禁和执行回读。

准入条件：用户可以在一个 request id 下追踪从文本到配置再到 dry-run/执行报告的完整记录；任何硬件执行都需要明确环境标识和二次确认。

## 推荐合入节奏

1. 先合公共契约和虚拟 Runtime 基线。
2. 四个领域以独立 PR 并行合入，不等待其他领域。
3. 每次公共契约调整触发四领域契约回归。
4. M1 完成后冻结 FunctionConfig v1，再开始 SceneConfig 运行时开发。
5. Web 先消费 mock `TraceEvent`，待 API 稳定后切换真实事件流。