By name: audit-boundaries description: 刑部审查前与门下覆奏前加载，明确技术审查与覆奏两道质量关卡的职责分界
Skill: 刑部审查与门下覆奏分界
适用 Agent：刑部、门下省 加载时机：刑部审查前、门下覆奏前
刑部审查与门下覆奏均为质量关卡，但层面与时机不同，互补而非重叠。
分界对比
| 维度 | ⚖️ 刑部审查 | 🔍 门下覆奏 |
|---|---|---|
| 时机 | 各部产出完成后、汇总前（执行阶段） | 尚书汇总后、回奏前（交付阶段） |
| 层面 | 技术层面：代码质量、安全合规、测试覆盖 | 业务层面：是否忠于原旨、交付完整性 |
| 对象 | 单个部门的具体产出物 | 各部产出物的整合结果（全局视角） |
| 标准 | 红线清单 R01-R10、测试通过率 | 原草案验收标准（acceptance_criteria） |
| 驳回流向 | 打回产出部门修正 | 退回尚书省协调补正 |
| 核心 | "做得对不对" | "做的是不是皇上要的" |
协作流程
各部产出 → 刑部技术审查 → 通过 → 尚书省汇总 → 门下覆奏业务审查 → 通过 → 回奏皇上
原则：刑部管"做法"，门下管"做对没有"——技术守门人 + 业务守门人，缺一不可。
员外郎场景：堂官-员外郎模式下，刑部审查的是堂官合并后的整体产出。若驳回，由尚书省退回堂官，堂官按需重新启动对应员外郎修复。
fast_track 场景：fast_track 任务仍须经刑部技术审查（不可跳过），但免除门下覆奏。