orin
50 lines
2.5 KiB
Markdown
Executable File
50 lines
2.5 KiB
Markdown
Executable File
# 领域交付流程
|
|
|
|
## 首次领取
|
|
|
|
每位成员复制 `domains/_template/` 为自己的 ASCII 领域名。首批成员已经分配：
|
|
|
|
| 人员角色 | 唯一主目录 | 领域标识 |
|
|
| --- | --- | --- |
|
|
| 座椅负责人 | `domains/seat/` | `seat` |
|
|
| 空调负责人 | `domains/climate/` | `climate` |
|
|
| 氛围灯负责人 | `domains/ambient_light/` | `ambient_light` |
|
|
| 天幕负责人 | `domains/roof/` | `roof` |
|
|
|
|
成员不得把本领域代码放入中央 `src/cognitive_agent/`，也不得在其他领域目录建立调用关系。
|
|
|
|
## 开发顺序
|
|
|
|
1. 在 `manifest.yaml` 登记插件入口、Schema、能力清单和信号映射路径。
|
|
2. 在 `config/capabilities.yaml` 定义稳定的语义能力名称、参数和目标类型。
|
|
3. 在 `schemas/function-parameters.schema.json` 定义参数类型、单位、必填项和结构约束。
|
|
4. 在 `config/presets/` 定义经产品/控制工程确认的模式默认值。
|
|
5. 在 `can/signal-mapping.yaml` 把能力参数映射到中央 DBC 的 message/signal 名称。
|
|
6. 实现 Generator、Validator、Compiler 和 Telemetry Decoder。
|
|
7. 完成 unit、contract、integration 测试；硬件测试需使用 `hardware` marker。
|
|
|
|
## 插件职责
|
|
|
|
- Generator：把已经路由到本领域的 `IntentIR` 转成 `FunctionConfig`，不得产生其他领域操作。
|
|
- Validator：执行超出 JSON Schema 的业务约束，例如参数组合、执行器互锁和模式可用条件。
|
|
- Compiler：使用车型标定把语义目标确定性转换为 `CommandPlan`，不得直接发帧。
|
|
- Telemetry Decoder：把回读信号转成领域状态，供完成条件和前端状态使用。
|
|
- Tests：提供 golden 配置、golden 命令计划、错误用例和模拟总线用例。
|
|
|
|
## Definition of Done
|
|
|
|
- 所有能力都有明确参数、单位、范围来源和目标执行器。
|
|
- 每个 preset 均可展开为合法 `FunctionConfig`，且没有隐藏硬编码。
|
|
- 编译结果只引用中央 DBC 中存在的 message/signal。
|
|
- 相同输入重复编译结果一致。
|
|
- 缺字段、错误单位、越界、互锁冲突、超时、回读不一致均有测试。
|
|
- `README.md` 记录未决标定项、HIL/实车前置条件和已知限制。
|
|
|
|
## 集成提交流程
|
|
|
|
1. 领域成员提交本领域 PR，并附至少一个自然语言到 dry-run 的演示用例。
|
|
2. CI 运行公共契约测试和该领域测试。
|
|
3. 集成人员审查公共能力命名、平台映射和安全边界。
|
|
4. 合并后运行全部领域回归；第二阶段再把该能力加入跨域场景测试。
|
|
|