Battery management

Battery management 表示仓库主要处理充电、监测、保护或电池状态管理相关 IC/固件边界，并把这些语义当成长期维护契约，而不是普通传感器读写。这里的主语是电池系统安全和电源行为，不只是某个 I2C 设备。

这个 Topic 的关键是把“配置一个寄存器”与“改变充放电/保护语义”区分开。它通常会和 Async embedded、Embedded Rust、I2C 一起出现，但不替代这些 Topic：Battery management 解释的是 charger / battery monitor / protection 语义，其他 Topic 解释并发模型、驱动生态或总线接口（projects/bq25730-rs.md、projects/bq769x0-async-rs.md）。

当 README、crate 描述、project snapshot 或文档明确表明仓库围绕 charger IC、battery monitor、protection thresholds、cell telemetry 或充电策略维护代码时使用。若它只是普通 PMIC/ADC 驱动的一部分、没有电池语义，不应直接命中。

如果一个改动会影响充电参数、过压/过流/欠压阈值、电池状态读取、cell balancing、fault/status 解释、或驱动 API 如何暴露这些电池语义，就应该命中 Battery management。若改动只是在 generic I2C 辅助层或 runtime feature 开关，而不触碰电池逻辑，则应回到相邻 Topic。

• 驱动默认围绕寄存器语义和安全参数建模，而不是只暴露裸读写；这样下游 firmware 更容易看出哪些设置会改变设备行为（projects/bq25730-rs.md、projects/bq769x0-async-rs.md）。
• async support 适合作为 feature-gated 扩展，而不是复制两套电池管理逻辑；电池语义应只有一份真相源。
• 对电池管理代码，默认要把 status/fault 位解释清楚。只会读寄存器值、不解释保护和状态含义，会让后续维护者不知道哪些变化是危险的。
• 回答此 Topic 时，应明确是 charger、monitor 还是 protection IC。三者都可能叫“battery management”，但审查重点不同：充电器更关心限流/限压，监测器更关心 cell telemetry 和故障状态，保护链路更关心阈值与 fail-safe。
• 测试通常以寄存器协议、typed configuration 和错误状态解码为主；真正的 pack 行为和热/安全耦合仍需下游系统验证。

• projects/bq25730-rs.md：更偏 charger/management driver，适合说明“配置一个寄存器”在这个主题里其实等于修改充电电流、限压或运行模式等电池语义，因此 API 不应只停留在裸总线读写。
• projects/bq769x0-async-rs.md：更偏 battery monitor/management family driver，适合说明状态位、cell telemetry、fault 解释和 async support 如何共存，也能提醒维护者 charger 语义与 monitor 语义并不相同。

• 只因为是“电源相关芯片”就打 Battery management，会把 generic PMIC 和真正的 battery logic 混在一起。
• 把 Battery management 当成整个仓库的总括标签，忽略 Async embedded、Embedded Rust、I2C 等相邻 Topic，会让后续 Agent 无法判断真正要验证的是电池语义、总线行为还是运行时模型。
• 只暴露原始寄存器，不保留配置/状态语义，会让维护者在最危险的地方靠猜。
• 把 battery monitor 和 charger 的审查逻辑混用，也会让 Topic 失焦；前者更偏状态解释，后者更偏控制参数和保护边界。

• projects/bq25730-rs.md
• projects/bq769x0-async-rs.md
• skills/style-playbook/references/data/topics/battery-management.json