合并受阻
开始进行AI检视！
AI review has been started, please wait...
| check type | result | report |
|---|---|---|
| start ai_review | pass | - |
感谢提交 Pull Requests！如果您提交的PR已经开发完毕，请评论 "start build" 触发门禁，更多交互操作，请访问OpenHarmony社区支持命令清单。如果需要调整订阅PR、Issue的变更状态，请访问订阅链接。
Thanks for submitting the pull request. If your Pull Request has already been developed, you can leave a "start build" comment to trigger the gated system. For more commands, please visit OpenHarmony Command List. If you need to change the subscription of a Pull Request or Issue, please visit the link.
⚠️ 🤖 AI 代码检视报告 ⚠️
总体评估: NEEDS_ATTENTION
问题统计:
- 总问题数: 3
- 严重问题: 0
- 高危问题: 1
摘要:
本PR为ROM优化SDD文档基线，设计思路清晰且考虑了GN循环依赖规避，但在execution-plan.md和design.md中存在与v2.1载体修正不一致的严重路径错误和自相矛盾，需修正以避免实施阶段引入反向依赖。
📊 详细报告
查看完整的审查详情，包括具体的问题描述、建议和代码位置：
🔗 查看详细报告
此评论由 OpenHarmony Insight 代码审查系统自动生成
🤖 AI 代码检视意见（回复本评论可解决检视意见，点击被检视代码行左侧的小头像可收起检视意见）
🟠 TASK-3 新建文件路径与 v2.1 载体修正矛盾，将引入反向依赖
位置: L278-L280 | 严重程度: High
❓ 问题描述
在 execution-plan.md 的 TASK-3 中，新建 15 个 *_json.cpp 文件的路径被指定为 services/infrastructure/src/json/，而 frameworks/ans 下的 34 个原文件将被删除 ToJson/FromJson 函数族。这直接违背了 design.md ADR-2 中 v2.1 载体修正的决定（将实现收拢到 frameworks/ans）。如果在 services/infrastructure 下新建 JSON 实现文件，将导致 frameworks/ans 反向依赖 services/infrastructure（由于 Parcelable 声明在 inner_api/interfaces 下，实现在 frameworks/ans，若实现移到 services，则 frameworks 必须依赖 services 才能链接通过），这构成了严重的 GN 循环依赖。
💡 修复建议
修改建议：将 TASK-3 中所有新建 *_json.cpp 文件的路径从 services/infrastructure/src/json/ 统一修正为 frameworks/ans/src/json/，与 TASK-2 及 design.md ADR-2 保持一致。
278: | Create | frameworks/ans/src/json/ 其余 15 个 *_json.cpp（request ~950 行/content ~600/capsule ~350/conversational ~400/live_view ~500/misc ~800 等，annex §8.7 全量） | 实现迁入 |
279: | Modify | frameworks/ans/src/notification_*.cpp 34 文件 | ToJson/FromJson 族删除（Marshalling 保留） |
280: | Modify | frameworks/ans/BUILD.gn | sources 重组（src/json 源组；v2.1 无新增 deps） |
🤖 AI 代码检视意见（回复本评论可解决检视意见，点击被检视代码行左侧的小头像可收起检视意见）
🟡 AnsJson 头文件路径在 API 表中与 ADR-2 矛盾
位置: L176-L178 | 严重程度: Medium
❓ 问题描述
在 design.md 的 ADR-2 中明确指出：AnsJson PIMPL 封装的头文件应置于 frameworks/ans/src/json/ 经 public_configs 导出。然而在「API 签名、Kit 与权限」的「新增 API」表中，AnsJson 的 d.ts 位置（C++ inner_api 路径）却写为 services/infrastructure/interfaces/ans_json.h。这种文档内部的不一致会给后续 TASK-2 的执行者带来混淆，且 services/infrastructure 路径在 ADR-2 中已被否决。
💡 修复建议
修改建议：将新增 API 表中 AnsJson 的路径修正为 frameworks/ans/src/json/ans_json.h，与 ADR-2 的设计决策对齐。
176: | API 签名 | 类型 | Kit | d.ts 位置 | 权限要求 | SysCap |
177: |----------|------|-----|-----------|----------|--------|
178: | class AnsJson（PIMPL；Parse/Accept/Dump/IsXxx/At/GetXxx/Set/Append/Size/ForEachObject 等，annex §8.5.1 完整签名） | InnerApi | Notification Kit（内部） | N/A（C++ inner_api 路径：frameworks/ans/src/json/ans_json.h） | - | - |
🤖 AI 代码检视意见（回复本评论可解决检视意见，点击被检视代码行左侧的小头像可收起检视意见）
🟡 AnsJson::Dump 默认行为与异常安全（-fno-exceptions）的潜在冲突
位置: L832-L834 | 严重程度: Medium
❓ 问题描述
在启用 -fno-exceptions（P2/A8）后，若 AnsJson::Dump() 默认调用 nlohmann::json::dump() 而未显式传入 error_handler_t::replace，当序列化包含非法 UTF-8 的字符串时，nlohmann 内部会抛出 type_error 异常。在禁用异常的环境下，此异常将直接导致进程 abort()。文档中虽然在其他处提及了 replace 锚点，但 AnsJson 接口的 Dump() 签名声明为 std::string Dump() const; 和 std::string Dump(int indent) const;，未在接口契约层面强制使用 replace 策略，存在运行时崩溃风险。
💡 修复建议
修改建议：在 AnsJson::Dump 实现中强制内部使用 nlohmann::json::error_handler_t::replace，并在接口注释中明确此安全语义。
832: // 序列化（内部强制 error_handler_t::replace 以保证 -fno-exceptions 下的异常安全）
833: std::string Dump() const;
834: std::string Dump(int indent) const;
您好， @cheerful_ricky 该PR需要您响应，已过去25天未响应，请根据检视意见进行修改，如5天内未响应检视意见，此PR会被自动关闭。关闭后的PR，如有需要，您可以自行打开该PR。
概述
新增通知子系统 ROM 优化的 SDD（Spec-Driven Development）文档基线（v2.2），将根目录
proposal.md（2026-07-28 评审通过）与 PR #4940 扩展分析整合为结构化交付件链：proposal → spec → design → execution-plan → review，机器一致性校验全过（ohos-sdd validate --level all：33 checks / 0 broken / 0 warn）。变更内容
目标：ROM 7,963KB → ≤6,769KB（-1,194KB / 15%，合同底线）；可实施潜力 3,287-7,129KB（41.2%-89.5%）。
交付件（
.codespec/changes/draft-20260828-rom-optimization/）proposal.mdToJson→ToJsonString，PR #4940 用户决策已接受）；16 项代码级核验修订；范围暂缓决策spec.mdToJson().dump()逐字节等价、IPC Parcelable 零变化三重兼容守护design.mdans_base → ans_innerkits依赖构成 GN 循环，已修正execution-plan.mdreview.mdannex/extended-optimization-design.PR4940.md关键决策记录
说明
.codespec/），零生产代码变更Co-Authored-By: Agent