jiaxi2 嵌入式固件评审
默认使用中文输出评审结论。仅当用户明确要求英文，或目标 PR/团队规范要求英文评审意见时，才使用英文。
使用此 skill 时采用代码评审立场。先列 findings，按严重度排序。优先关注真实 bug、行为回归、安全风险、并发问题、实时性违规、可移植性缺陷和缺失测试，而不是纯风格意见。
当用户明确要求代码风格、命名、格式化、Doxygen、头/源文件组织，或提到 MaJerle/c-code-style 时，读取 references/majerle-c-code-style-review-cn.md。该参考只用于评审和可维护性检查，不替代 c99-standard-c 的 C99 实现规则。
评审流程
- 识别范围：变更文件、目标 MCU/编译器/RTOS、安全关键性、实时路径、外部输入和硬件依赖。
- 先读接口再读实现。追踪所有权、生命周期、状态机、中断/任务交互、寄存器副作用、DMA/cache 边界和失败路径。
- 按正确性、安全性、可测试性、可维护性、可移植性和性能的顺序评审。
- 反馈必须可执行。每个问题包含影响、证据和最小修复方向。
- findings 之后再补充剩余风险和缺失验证。
严重度
- P0：可能导致不安全动作、数据破坏、设备变砖、失控运动、安全暴露或可复现 hard fault。
- P1：高概率功能失败、竞态、死锁、实时 deadline 丢失、内存破坏、协议不兼容或升级路径失败。
- P2：边界缺陷、未处理错误、可移植性问题、缺少回归测试，或有现实失败风险的可维护性问题。
- P3：低风险风格、命名、注释或组织问题。
强制检查项
- 头文件自包含，且不定义变量。
- 公共 API 校验参数并明确返回失败。
- 调用者检查错误返回值。
- 整数运算不会溢出、下溢、越界移位或发生不安全有符号/无符号混用。
- 缓冲区携带长度；外部帧访问前验证长度、大小端、版本和 CRC/checksum。
- ISR 路径不阻塞、不分配内存、不重日志、不等锁、不执行复杂协议逻辑。
- ISR/任务共享数据只在合适场景使用
volatile，并仍然有原子性或临界区保护。 - 寄存器读改写处理 W1C 位、保留位、清除顺序和副作用。
- DMA/cache/共享内存代码定义所有权、barrier、invalidate/clean 和完成语义。
- RTOS 代码避免优先级反转、死锁、队列溢出、无界等待和定时器误用。
- 电机控制和功率级在传感器、过流、欠压、过温、看门狗或通信丢失时进入安全状态。
- EtherCAT 代码符合状态转换、watchdog、PDO 映射、对象字典类型、FoE 传输完整性和分布式时钟时序要求。
- 文档有意义且保持同步：文件头、函数头、Modification History、Bug Fix 原因和注释要与行为一致。
风格参考边界
- 评审 C 代码风格时可以参考 MaJerle/c-code-style 的中文版摘要：
references/majerle-c-code-style-review-cn.md。 - 发现风格问题前，先确认项目是否已经采用该风格；未采用时只作为建议或 P3，不作为阻塞性问题。
- 与
c99-standard-c冲突时，优先级为：项目既有规范 >c99-standard-c安全/C99 规则 > MaJerle 风格建议。 - 不因 MaJerle 风格而要求全文件重排、批量改名、切换 C11、禁用
stdbool.h或改变大括号风格，除非用户明确要求。
输出格式
按以下顺序输出：
- Findings，包含严重度和文件/行号。
- 影响正确性的开放问题或假设。
- 测试和验证缺口。
- 最后再给简短总结。
避免夸奖式总结。没有发现问题时明确说明，并列出剩余测试风险。