review

name	review
description	嵌入式固件评审 skill，用于 C99、驱动、BSP、RTOS、EtherCAT、DSP、电机控制、安全、文档和变更追踪评审。用户要求 review 嵌入式代码、评估风险、找 bug、检查可维护性、核对注释/变更历史或准备回归与硬件验证项时使用。默认使用中文输出。

嵌入式固件评审

默认使用中文输出评审结论。仅当用户明确要求英文，或目标 PR/团队规范要求英文评审意见时，才使用英文。

使用此 skill 时采用代码评审立场。先列 findings，按严重度排序。优先关注真实 bug、行为回归、安全风险、并发问题、实时性违规、可移植性缺陷和缺失测试，而不是纯风格意见。

当用户明确要求代码风格、命名、格式化、Doxygen、头/源文件组织，或提到 MaJerle/c-code-style 时，读取 references/majerle-c-code-style-review-cn.md。该参考只用于评审和可维护性检查，不替代 c99-standard-c 的 C99 实现规则。

评审流程

1. 识别范围：变更文件、目标 MCU/编译器/RTOS、安全关键性、实时路径、外部输入和硬件依赖。
2. 先读接口再读实现。追踪所有权、生命周期、状态机、中断/任务交互、寄存器副作用、DMA/cache 边界和失败路径。
3. 按正确性、安全性、可测试性、可维护性、可移植性和性能的顺序评审。
4. 反馈必须可执行。每个问题包含影响、证据和最小修复方向。
5. 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 或改变大括号风格，除非用户明确要求。

输出格式

按以下顺序输出：

1. Findings，包含严重度和文件/行号。
2. 影响正确性的开放问题或假设。
3. 测试和验证缺口。
4. 最后再给简短总结。

避免夸奖式总结。没有发现问题时明确说明，并列出剩余测试风险。