Cognitive_Agent/docs/workflows/can-semantic-protocol.md

CAN0/CAN1 共享语义协议清单

CAN 语义控制的单一来源是：

• config/can_protocol/semantic_protocol.json

该清单同时定义 CAN0/CAN1 的语义语法、能力映射、帧 ID、经典 CAN/CAN FD、BRS、DLC、基础帧模板、固定或动态重复策略、周期和反馈 ID。需要实时状态参与的窗口位置、遮阳帘位置、座椅相对移动和记忆位置仍由命名的 special_handler 执行闭环算法；这些算法不得另行定义帧 ID、重复节拍或反馈来源。

生成物

不要直接修改以下文件：

• src/cognitive_agent/generated/can_semantic_protocol.py
• tools/can_read_trans/generated/can_semantic_protocol.hpp

更新清单后执行：

make can-protocol-generate

只检查生成物是否同步：

make can-protocol-check

make validate、make test 和 make can-read-trans-test 都会检查或重新生成协议视图。生成内容携带规范化源文件的 SHA-256，便于确认 Python 与 C++ 来自同一版本。

运行时接入

• Python CAN1 NativeCanRuntime 从生成模块取得支持能力、帧格式、帧 ID、重复策略和反馈 ID。
• Python CAN0 T2GSeatCompiler 在每个物理命令中附带生成的协议契约；HardwareSeatExecutor 会在发送前校验矩阵编码的 ID、DLC 和格式，并使用契约中的反馈 ID。
• C++ can_read_trans 使用生成头文件匹配 CAN0/CAN1 白名单、打印帮助、取得 CAN0 传输元数据和 CAN1 单风口精确 payload。其自检还会将生成模板与已验证的状态闭环编码器交叉比对。

修改规则

1. 仅在协议证据明确时修改帧模板、重复次数或反馈 ID。
2. 新增命令时必须同时填写 patterns、frames、repeat 和 feedback_ids。
3. 有状态序列使用 special_handler，但传输元数据仍放在共享清单中。
4. 先执行离线生成和测试；真实总线验证必须另外明确授权，且分别记录 SDK 提交、CAN ACK、应用反馈和实体动作。