/compliance-review

name: compliance-review
description: 合规性评审 — 按 compliance-path.md 引用的合规规则,逐条评估设计。涉及 GSP / HIPAA / SOX / GDPR 等强合规场景时调用。
disable-model-invocation: true
version: 4.0.0
requires: [context-pointer, stage-gate]

Compliance-Review — 合规评审

Contract

• 输入: 已签字的 `01-业务需求文档 BRD.md` 与 `compliance-path.md`
• 输出: `04-合规评审.md`
• 门控: 所有适用合规条款均已判定;严重缺陷已修复或显式接受;用户 + 合规方签字
• Required rules: `stage-gate`, `context-pointer`
• Required paths: `compliance-path`, `doc-naming-path`
• 下一步: `/test-case-design`

适用场景

| 需求类型 | 是否需要 | |---|---| | 涉及个人健康信息(PHI) | ✅ 必须 | | 涉及支付/金融 | ✅ 必须 | | 涉及个人身份信息(PII) | ✅ 必须 | | 涉及医药追溯(GSP) | ✅ 必须 | | 纯内部工具 | ⚠️ 按团队规范 |

流程步骤

1. 加载合规规则

• 读项目根 `compliance-path.md`
• 加载其引用的合规规则文件(`config/compliance/<行业>.md` 或 skill 级 fallback)
• 列出所有适用条款

2. 逐条评估 BRD

对每条合规条款,按以下格式输出:

| 条款编号 | 缺陷等级 | 检查要点 | 合规设计 | 证据位置 | 状态 | |---|---|---|---|---|---| | **{条款编号} | {严重/主要/一般} | {检查要点} | {合规设计摘要} | FSD §{章节号} | ✅/⚠️/🔄 |

**判定标准**:

• ✅ 符合:完全满足
• ⚠️ 不符合:存在合规缺口
• 🔄 不适用:条款不适用本功能

3. 写评审结论

按条款输出后,给出整体结论:

• ✅ 全部通过 → 进入下一阶段
• ⚠️ 带条件通过(列出条件)
• ❌ 不通过(回 BRD 修复)

输出

• `04-合规评审.md`

调用的 rule

• `rules/context-pointer` — 三层合规规则加载(项目级 > skill 级 > 默认)
• `rules/stage-gate` — 阶段 4 门控

结束条件

• [ ] 所有适用条款已评审(无遗漏)
• [ ] 每条都有 ✅/⚠️/🔄 判定
• [ ] 整体结论签字(用户 + 合规方)
• [ ] 缺陷等级为"严重"的条款全部 ✅

反模式

• ❌ 留 {待评估}/{TBD}/{N/A} — `compliance-check.py` 视为未判定,直接 fail;必须给 ✅/⚠️/🔄
• ❌ 严重条款状态为 ⚠️ — 必须修复或豁免到 ✅/🔄 后才能签字
• ❌ 跳过 evidence(证据位置)列 — 每条必须标具体位置(FSD §X / PRD §Y / 设计回测报告)
• ❌ 不分缺陷等级(严重/主要/一般) — 必须分级,否则整改建议无法排序
• ❌ 条款数量 ≠ `compliance-path.md` 引用的合规清单 — 必须 1:1 全覆盖
• ❌ 仅做技术合规(代码层面)忽略业务流程合规 — 两者必须都覆盖