veeSeat Domain
负责座椅单领域能力。通风和加热基于根目录 座椅部分功能CAN矩阵表.xlsx 建立可审计的归一化矩阵；位置电机使用单独的虚构矩阵，仅验证模型理解、配置生成、CAN 编译和反馈闭环。
首个交付目标
- 支持显式指令以及“主驾有点热，有点闷”等舒适反馈。
- GPT 在同一
conversation_id下获取当前虚拟执行状态和前序成功动作，自行解析跟进、因果和作用域。 - GPT 返回领域无关的通用能力请求；座椅适配器只校验并转换已注册能力，不用本地舒适或位置词条覆盖模型结果。
- 主副驾分别支持水平、高度、坐垫俯仰、靠背、腿托升降和腿托伸缩六个虚构电机轴，会话状态保留每轴的
0-100%绝对位置。 - 混合请求中可执行的座椅动作独立 dry-run，未接入的其他域保留为
deferred_requests，不会阻断座椅子请求。 - 生成只含
domain: seat的FunctionConfig。 - 1–3 档目标进入
FunctionConfig和会话状态；0x42A仍只编译开关，档位由0x4FAdry-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 座椅真实硬件台架接入。