skill-closure-verifier-meta

元级闭环验证编排器（skill-closure-verifier-meta）

关系类型：triggers（触发 skill-domain-health-check + skill-domain-self-optimizer） 关系类型：depends-on（依赖 DOMAIN-REGISTRY + NODE-IO-CONTRACTS + 沙盘库） 强绑定 Rule：R2 NO_FABRICATION / R3 READ_FIRST / R6 ARTIFACT_FIRST / R1 EVIDENCE_FIRST

核心设计原则

两阶段分离：Phase 1（预想）必须在不参考现有 Skill 实现细节的情况下完成。这防止了「验证者被被验证的系统污染」的自我确认偏误。

证据链完整：每个 Gap 必须有具体的证据（文件路径 + 步骤描述），不允许模糊归因。

可重复运行：每次运行产出独立的报告文件（含日期），不覆盖旧报告，支持对比演进。

激活后立即执行

Step 1  前置检查（硬性门槛）
        检查以下文件是否存在：
        - _内部总控/skill-system-design/DOMAIN-REGISTRY.md
        - _内部总控/skill-system-design/NODE-IO-CONTRACTS.md
        - _内部总控/skill-system-design/SANDBOX-FORMAT.md
        
        若任一文件不存在：
        → 停止执行，明确告知「元验证所需的形式化描述文档缺失」
        → 说明哪个文件缺失，以及如何创建它
        → 不允许「跳过缺失文件继续执行」
        
        若文件存在但有明显过期迹象（最后修改时间 > 30天）：
        → 告知用户「形式化文档可能需要更新」，询问是否继续

Step 2  读取系统全景（R3 READ_FIRST 强制）
        用 explore 子智能体并行完成以下读取：
        
        组A（必须完成后才能进入 Phase 1）：
        - DOMAIN-REGISTRY.md：读取五域节点图和终态定义
        - NODE-IO-CONTRACTS.md：读取所有节点的I/O契约
        - .cursor/skills/skill-index/SKILL-INDEX.md：读取现有37个Skill的状态
        
        组B（为 Phase 2 准备）：
        - _内部总控/skill-system-design/sandboxes/ 所有子目录中的文件列表
        - .cursor/rules/role-menu.mdc：触发词路由规则

Step 3  Phase 1：预想验证（两阶段的第一阶段）
        
        ⚠️ 重要约束：此阶段不允许打开任何 SKILL.md 文件。
        Phase 1 的标准是「理想系统」，与现有实现无关。
        
        对每个域（5个域），执行以下操作：
        
        3.1 读取该域在 DOMAIN-REGISTRY 中的节点图和终态定义
        3.2 读取该域所有入口节点的 I/O 契约（从 NODE-IO-CONTRACTS）
        3.3 预想：若系统完美，从每个入口节点输入后，应该发生什么？
            - 预想触发链路：[入口] → [中间节点...] → [终态]
            - 预想终态输出：应该产出哪些文档/状态/产物
            - 预想自洽检查点：哪些文档应该相互一致
        3.4 将预想结果记录为「Phase 1 预想记录」（暂存在工作内存，不写文件）
        
        本步骤预计输出：5域 × N个入口节点 × 预想链路记录

Step 4  Phase 2：实际验证（两阶段的第二阶段）
        
        ⚠️ 注意：此阶段需要读取实际的 SKILL.md 文件，与 Phase 1 的预想对比。
        
        对每个域的每个沙盘文件（sandboxes/[域]/*.md）：
        
        4.1 读取沙盘的「Phase 2 实际验证」部分
            - 若状态为 "validated"（无Gap）：记录为通过，无需额外验证
            - 若状态为 "gap-found"：提取Gap列表
            - 若状态为 "draft"（Phase 2未完成）：对该沙盘执行实际验证
        
        4.2 对 "draft" 状态的沙盘，补全 Phase 2：
            读取该沙盘中涉及的每个节点的 SKILL.md（此时才读Skill文件）
            逐节点验证：触发了吗 / 输出了吗 / 触发下游了吗
            更新沙盘文件状态（draft → validated 或 gap-found）
        
        4.3 对照 Phase 1 预想：
            Phase 1 预想链路 vs Phase 2 实际链路 → 差异 = Gap 候选
            仅保留有沙盘证据支持的 Gap（无证据的不记录）

Step 5  Gap 汇总与分级
        汇总所有域的 Gap：
        
        5.1 合并来源：沙盘 Gap + Phase 1 vs Phase 2 对比差异
        
        5.2 为每个 Gap 分级：
            P0：传播完全断裂 / 缺失关键节点（Skill文件不存在）/ 系统无法自洽
            P1：触发条件缺失 / I/O不匹配 / 部分传播路径断裂
            P2：边界盲区 / 体验优化项（闭环完整但不够流畅）
        
        5.3 去重：相同根因的 Gap 合并为一条
        
        5.4 为每条 Gap 确认证据：
            - 沙盘文件路径（sandbox-ID + Gap行号）
            - 相关 Skill 文件路径
            - 具体说明（R2 NO_FABRICATION：无法找到具体证据的Gap不记录）

Step 6  调用 skill-domain-health-check（各域）
        对每个域调用 skill-domain-health-check，传入域名：
        
        → 等待各域健康报告生成
        → 将传播完备性检查结果纳入总报告
        
        若某域的健康报告已存在且日期为今天，跳过重复生成。

Step 7  调用 skill-domain-self-optimizer（有Gap的域）
        对 Step 5 中识别出有 P0 或 P1 Gap 的域：
        
        → 调用 skill-domain-self-optimizer，传入域名
        → 等待优化建议报告生成
        → 将行动建议纳入总报告的「整改计划」部分

Step 8  输出总验证报告（R6：必须写文件）
        写入：_内部总控/skill-system-design/validation-report-YYYYMMDD.md
        
        格式（见下方「总报告格式」）

Step 9  呈现摘要与下一步建议
        在对话中输出：
        - 验证覆盖范围（几个域/几个沙盘/几个节点）
        - 发现的总 Gap 数（P0: x, P1: y, P2: z）
        - 最高优先级的行动建议（P0项）
        - 是否建议立即执行修复