# Seat Domain

负责座椅单领域能力。通风和加热基于根目录 `座椅部分功能CAN矩阵表.xlsx` 建立可审计的归一化矩阵；位置电机使用单独的虚构矩阵，仅验证模型理解、配置生成、CAN 编译和反馈闭环。

## 首个交付目标

- 支持显式指令以及“主驾有点热，有点闷”等舒适反馈。
- GPT 在同一 `conversation_id` 下获取当前虚拟执行状态和前序成功动作，自行解析跟进、因果和作用域。
- GPT 返回领域无关的通用能力请求；座椅适配器只校验并转换已注册能力，不用本地舒适或位置词条覆盖模型结果。
- 主副驾分别支持水平、高度、坐垫俯仰、靠背、腿托升降和腿托伸缩六个虚构电机轴，会话状态保留每轴的 `0-100%` 绝对位置。
- 混合请求中可执行的座椅动作独立 dry-run，未接入的其他域保留为 `deferred_requests`，不会阻断座椅子请求。
- 生成只含 `domain: seat` 的 `FunctionConfig`。
- 1–3 档目标进入 `FunctionConfig` 和会话状态；`0x42A` 仍只编译开关，档位由 `0x4FA` dry-run 模拟。
- 使用模拟 CAN Gateway 测试正常执行、冲突、缺失能力和回读不一致。

## 待负责人补齐

- 0x42A 的正式报文名称、发送节点、周期、DLC、字节序、counter/checksum 和总线所有权。
- 档位控制信号；当前“设置三档”只是认知目标和虚拟回读，不得视为已产生实车档位命令。
- 行车状态、乘员状态和防夹等安全互锁。
- DBC message/signal 以及命令保持、释放和真实回读策略。

`can/seat-thermal-matrix.yaml` 和 `can/seat-motion-virtual-matrix.yaml` 中 `hardware_execution_allowed: false` 是强制边界。后者的帧号、信号布局、时序和反馈行为全部为虚构，当前闭环只能 dry-run。

真实 T2G 台架使用独立的 `signal-mapping.hardware.yaml`、`seat-thermal-hardware-matrix.yaml` 和 `seat-motion-hardware-matrix.yaml`，不会解除上述虚拟矩阵的边界。仓库内 `firmware/t2g/Seat_Controller_demo` 是唯一硬件固件接口，真实路径只接受它的 `combined` profile。当前主驾与副驾都是 `t2g_primary_seat` 的逻辑别名：两种指令使用同一组实体电机、加热和通风，成功反馈会同步到两侧会话状态。完整接线、自动烧录、授权和反馈要求见 [T2G 座椅真实硬件台架接入](../../docs/workflows/t2g-seat-hardware-bench.md)。