From d2d03e02c7b8d982e29de0846726d9b7ee9c82d9 Mon Sep 17 00:00:00 2001
From: 1 <wentingyear@gmail.com>
Date: Fri, 26 Jun 2026 21:02:57 +0800
Subject: [PATCH] docs: clarify audit scope for enabled systems

---
 common/pro-doc/需求审核规范.md |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git "a/common/pro-doc/\351\234\200\346\261\202\345\256\241\346\240\270\350\247\204\350\214\203.md" "b/common/pro-doc/\351\234\200\346\261\202\345\256\241\346\240\270\350\247\204\350\214\203.md"
index 943ff03..248e8c5 100644
--- "a/common/pro-doc/\351\234\200\346\261\202\345\256\241\346\240\270\350\247\204\350\214\203.md"
+++ "b/common/pro-doc/\351\234\200\346\261\202\345\256\241\346\240\270\350\247\204\350\214\203.md"
@@ -16,6 +16,12 @@
 
 审核员不应为了形式完美而层层加码。只阻断会影响目标、边界、实现、验证或结论的问题。
 
+需求审核员还必须检查需求事项是否符合自身适用规范文档。适用范围包括 common 全局规范、全局项目规范、common 需求规范、项目本地需求规范，以及该需求直接声明采用的需求方案、架构、模块说明、核心流程、执行和审核规则。
+
+如果需求设计或产物违反规范中的硬约束，例如跳过必要审核、未记录来源聊天或上游依据、越权改写正式产物、需求边界与规范冲突、结论或交付状态超出证据范围，必须反馈为审计问题。
+
+如果只是命名、格式、表达方式等不影响目标、边界、实现、验收和下游使用的轻微差异，不应作为阻断问题。若规范之间冲突或规范本身不清楚，应标记为规范问题，不得强行按审核员个人理解加规则。
+
 ## 2. 设计审核
 
 设计审核发生在正式执行或交给下游前。

--
Gitblit v1.9.3