| name | automotive-development |
| description | 在车载软件工作项（ECU、域控、车载服务、整车平台）的规格、设计、实现或评审中使用，涉及功能安全/ASIL、车载 SOA 服务、DTC/诊断、整车启动/休眠/唤醒、SELinux 或跨 ECU 协同时。只承载车载专属约束；内存/实时性、通用服务接口或其他相邻领域规则由命中 description 的领域技能叠加，语言级规则见适用 `<language>-coding-standards`。 |
Automotive Development
总览
车载约束的共同点：很多决策不属于本组件，而属于整车级角色（功能安全负责人、模块架构师、系统工程师）。所以本技能的核心纪律有两条：一是把车载维度前置到规格和设计；二是识别哪些决策必须上抛——agent 不替功能安全和整车架构拍板。本技能只承载车载专属维度；通用内存、中断、实时性、服务接口等约束由命中 description 的相应领域技能叠加。
决策归属：先判定再动手
动笔前先对工作项涉及的每个车载维度做归属判定——这一步决定哪些能自己实现、哪些必须上抛：
变更涉及车载维度
│
├─ 安全相关行为？（喂狗时机/安全状态/监控阈值）──► 上抛功能安全负责人，ASIL/safety goal 确认前 blocking
├─ 跨组件/跨 ECU 可观察契约？（service/DTC/信号）──► 走 devflow-specify modify + 列消费者 + owner 协调
├─ 整车规范派生约束？（电源/网络管理/休眠唤醒）──► 引用规范章节为 Source，不凭记忆
└─ 组件内部实现细节 ──► 可自行实现，仍遵守下列各维度红线
拿不准归属时按"上抛"处理，记为 Open Question，而不是默默实现。
功能安全 / ASIL
- 规格阶段：确认工作项涉及的 safety goal 与 ASIL 等级（来源：安全分析文档/功能安全负责人，不自行判断）；ASIL 不明 = blocking Open Question。
- 设计阶段：安全机制（监控、冗余、降级到安全状态）是设计输入；fail-safe / fail-operational 策略与降级路径显式写出；安全相关与 QM 代码的隔离边界清楚。
- 红线：不悄悄改变安全相关行为（看门狗喂狗时机、安全状态进入条件、监控阈值）；这些全是
modify + 上抛确认。
- feed_watchdog_every(50 );
+ feed_watchdog_every(200 );
整车生命周期
组件必须显式回答四个状态的行为，缺一即设计缺口：
| 状态 | 必答问题 |
|---|
| 启动 | 依赖服务还没起来时怎么办（等待/降级/重试）；启动顺序依赖是否有环 |
| 正常退出 | 收到退出信号后多久内完成清理；未完成的写入怎么处理 |
| 休眠 | 哪些状态要持久化；唤醒后怎么恢复 |
| 异常恢复 | 进程被重启后与外界状态的一致性 |
- 设计评审检查点：启动顺序依赖有无环、有无对"某服务一定已就绪"的隐式假设；休眠/唤醒路径有无测试。
- 电源状态与网络管理状态的转换约束来自整车规范，引用具体章节作为 Source，不凭记忆编写。
车载 SOA 服务
- 通用服务契约纪律（接口语义/错误码/版本策略/列消费者/超时重试降级/幂等）由适用的服务端/API 领域技能承载，本节只承载车载专属约束：
- 服务接口（service/method/event/field）变更走
devflow-specify 的 IFR + 基线纪律；车载语境下消费者常跨 ECU，兼容窗口受整车版本管理约束（不假设对端同步升级）
- 事件丢失/重复/乱序的语义按车载通信中间件（如 SOME/IP、DDS）的真实保证写清，不凭记忆假设可靠投递
- 大载荷的所有权与拷贝策略受 ECU 内存预算约束；内存预算与实时性证据按适用的资源受限/嵌入式领域技能执行
- 红线：不绕过 SOA 接口直接访问其他组件的内部状态；不引入未声明的跨组件/跨 ECU 依赖。
诊断 / DTC
- 哪些故障要报 DTC、故障码定义、成熟度策略（确认/恢复条件）是领域决策：规格阶段确认，缺失时上抛 owner，不自行发明故障码。
- 设计阶段：故障检测点、上报路径、恢复路径显式；可观测性（关键状态转换有诊断日志/事件）作为设计输出。
- 红线：吞掉本应上报 DTC 的故障（"打个日志就行"）；诊断日志中暴露敏感数据。
SELinux / 权限
- 涉及新进程、新文件路径、新 socket/binder 访问时：列出主体、客体、所需操作，对照现有策略评估是否需要新规则；策略变更有 owner 审批。
- 红线：用放宽策略（permissive、宽 allow 规则）代替最小权限分析；"先 allow 跑通再说"。
跨 ECU / 跨域协同
- 影响其他 ECU/域控的变更（信号矩阵、网络负载、时序假设）：列出下游 owner 与协调状态，纳入规格的接口候选契约。
- 不假设对端版本同步升级：版本共存窗口内的兼容行为写进设计。
测试与证据策略
- 车载维度的用例落在 SIL/HIL/整车测试层级；测试设计中写明每个车载风险维度的覆盖层级或 N/A 理由。
- mock 整车环境（电源状态、网络管理、诊断栈）时，mock 行为必须与整车规范一致——用错误的整车状态模型测试比不测更危险。
- 评审时（
devflow-review）：本文件各节红线即检查项；安全相关行为变更无上抛记录 → critical。
合理化反驳
| 话术 | 现实 |
|---|
| 「功能很小，ASIL 应该不涉及」 | safety 适用性由功能安全负责人确认，不由功能大小推断 |
| 「改个错误码，下游应该没人依赖」 | 车载接口的可观察语义都有消费者；列出消费者和兼容策略 |
| 「休眠唤醒场景后面再补」 | 生命周期行为是设计输入；后补通常意味着重新设计持久化 |
| 「SELinux 先放宽，量产前收紧」 | "临时"宽策略会跟着发布走；最小权限从第一天开始 |
| 「诊断日志够了，不用报 DTC」 | DTC 策略是领域决策；缺失时上抛，不自行降级 |
自检清单
