comprehensive-change-guard

综合变更协调守门规则（comprehensive-change-guard）

根因：AI 的触发词扫描（A1）在多层变更场景下只命中最显眼的单角色， 导致其他层次被跳过，关卡A/B/C被绕过。 本 Rule 在 A1 之后补充「多层检测」步骤，强制按序执行对应角色。

证据来源：产品开发域 75 个沙盘 Phase 2 验证（PD-016~PD-075）根因一「缺编排层」

• domain-optimizer-产品开发-20260323.md P0-5

---

触发条件（A1 触发词扫描之后执行）

消息语义同时命中以下 ≥ 2 个层次，且动作类型为「变更实施/方案设计」（而非纯问答/分析）：

□ 产品层：「功能」「用户流」「产品方案」「闭环」「需求」「产品设计」
□ 架构层：「技术框架」「接口」「数据模型」「架构」「技术方案」「技术设计」
□ UI层：「界面」「交互」「设计稿」「视觉」「组件设计」
□ 代码层：「实现」「写代码」「前端开发」「后端开发」「AI工程」「代码细节」

排除场景（不触发）：

• 纯问答/分析：「这个设计合理吗？」「怎么看这个技术选型？」
• 单层变更：「帮我写用户注册接口」（只有代码层）
• 已在单角色 Skill 执行流程中的中间步骤（防止嵌套触发）

---

触发后立即执行

Step 1  声明多层变更检测（必须在第一句输出，不可省略）：
        「⚠️ [多层变更检测] 本任务涉及 [X层 + Y层（+ Z层）]，
        需按以下顺序执行，不可跳过关卡：」

Step 2  输出本次实际涉及层次的执行序列（只列实际涉及的层，不列不相关的）：
        
        有产品层变更 →  ① PM-IN（role-产品经理）    → 关卡A（role-审核者-用户模拟）
        有架构层变更 →  ② ARCH（role-技术架构师）    → 关卡B（role-审核者-系统破坏）
        有UI层变更   →  ③ UI（role-UI设计师）        [在关卡B通过后执行]
        有代码层变更 →  ④ FE/BE/AI-ENG 对应角色    → 关卡C（role-测试工程师）
        
        示例输出：
        「执行顺序：
          ① role-产品经理 → 关卡A
          ② role-技术架构师 → 关卡B
          ③ role-后端开发 → 关卡C
         现在开始第①步，请确认后触发 role-产品经理。」

Step 3  等待用户触发第①步角色（不允许自动跳到后面的层次）

Step 4  每完成一层、走完对应关卡后，提示下一层：
        「✅ [层次名]已完成并通过关卡[X]。下一步：[下一层角色]」

---

禁止行为（硬性约束）

❌ 禁止：一次性输出跨越多个层次的综合方案（无论看起来多「完整」）
❌ 禁止：以「改动很小」为由跳过关卡直接进代码
❌ 禁止：在产品层变更未经关卡A时进行架构设计
❌ 禁止：在架构层变更未经关卡B时开始代码实现
❌ 禁止：将「技术性很强」作为跳过产品层的理由

---

与已有规则的关系

相关规则/Skill	关系
session-bootstrap.mdc A1	接续：本 Rule 在 A1 触发词扫描之后执行（A1.10），不替代 A1
role-menu.mdc 规则 2-4（关卡序列）	强化：本 Rule 在「多层场景」中强制执行这些规则，不冲突
cognitive-ask	互补：用户若先说「基于我的文档」，则先触发 cognitive-ask 读文档，再触发本 Rule 做变更编排
frontend-brand-guard.mdc	同级：同为 alwaysApply 守门 Rule，本 Rule 守「变更编排」，对方守「品牌规范」

---

认知根

本 Rule 的认知根：

• L1 文档：AI时代产品问题全景框架.md（§产品开发流程的完整性原则）
• L1.5 原则：P12「最小必要限制」（每个关卡只守自己的门，但都必须守）
• 沙盘证据：PD-016~PD-075（75 个沙盘，根因一：缺编排层）

---

变更记录

v1.0 — 2026-03-23 — 初始创建