新产品三大闭环兼容性验证（product-launch-validator）

关系类型：validates → 三大闭环架构蓝图（在立项时验证 Loop 1/2/3 的兼容性） 触发时机：role-产品经理 激活之前（可选但推荐） 设计依据：三大闭环架构蓝图 §差距清单「新产品/场景加入时兼容性检查：❌缺失」

---

使用场景

何时触发：

• 启动一个全新的产品项目（而非现有产品的迭代）
• 在现有生态中添加新的独立场景或子系统
• 不确定「这个新产品和我们现有的 Skill 体系/认知结构/部署架构是否兼容」

不应触发：

• 现有产品的功能迭代（走 role-产品经理 迭代模式即可）
• 纯 Skill 或 Rule 的新建（走 skill-designer）

---

激活后立即执行

Step 1  收集新产品基本信息
        询问用户（如果上下文不明确）：
        「请描述新产品的：
           1. 核心功能一句话描述
           2. 主要用户群体
           3. 依赖的技术栈（前端框架/后端语言/AI能力）
           4. 与现有产品的关系（完全独立/共享账号/共享数据库）」
        
        确认后继续。

Step 2  Loop 1 检查：Skill 体系兼容性
        Read: .cursor/skills/skill-index/SKILL-INDEX.md（快速扫描，了解已有能力覆盖）
        
        检查三项：
        ① 新产品的开发流程（PM→架构→前后端→测试→部署）是否有现有 Skill 完整覆盖？
           → 对每个阶段：现有 Skill 是否支持新产品的特殊需求（如新技术栈/新部署模式）
        ② 新产品涉及的领域（如：学术画像/科研工具/AI编辑器），是否有对应的域节点
           在 DOMAIN-REGISTRY 中已定义？
           → 若无 → 标记「需要在 DOMAIN-REGISTRY 新增工作域」
        ③ 新产品是否引入了新的技术边界（如：新AI模型/新第三方服务/新部署架构）
           需要新建 Skill 或 Rule 才能安全执行？

Step 3  Loop 2 检查：认知根对齐
        Read: _内部总控/认知结构/L0_大脑总地图.md
        Read: _内部总控/认知结构/L1.5_底层原则层/底层原则库.md（候选原则部分）
        
        检查两项：
        ① 新产品的核心价值主张，在现有 L1 系统性文档中是否有对应的认知根？
           → 具体：L1 的哪篇文档支撑了「为什么要做这个产品」的判断？
           → 若无 → 标记「产品认知根缺失：建议先用 cognitive-capture-fragment 
             记录洞见，再用 cognitive-update-knowledge 补充 L1」
        ② 新产品的设计假设，是否与已确认的 L1.5 原则（P1/P2/...）兼容？
           → 扫描候选原则，识别可能与新产品设计有张力的原则

Step 4  Loop 3 检查：场景投射兼容性
        Read: _内部总控/skill-system-design/DOMAIN-REGISTRY.md（快速了解已有工作域）
        Read: _内部总控/开发规范/AI调用服务器助手接口规范.md（如有，了解技术约束）
        
        检查两项：
        ① 新产品的工作域（工作任务/工作产物/项目结构）是否已在 DOMAIN-REGISTRY 的
           五域定义之内？
           → 若无 → 标记「需要在 DOMAIN-REGISTRY 中新增节点」并给出建议定义
        ② 新产品的技术架构（账号体系/数据库/部署位置）是否与现有服务兼容？
           → 特别检查：是否重用现有账号体系？是否加入 tashan-shared 网络？

Step 5  输出兼容性报告
        
        「━━ 立项兼容性检查报告 ━━
          新产品：[名称]
          
          Loop 1 Skill 体系：
          ✅ 已覆盖：[列举]
          ⚠️ 需补充：[列举缺口 + 建议行动]
          
          Loop 2 认知根：
          ✅ 有认知根：[L1 文档名]
          ⚠️ 认知根缺失：[建议：先记录 L2 碎片或更新 L1]
          
          Loop 3 工作域：
          ✅ 现有域覆盖：[域名]
          ⚠️ 需要新增域节点：[建议定义]
          
          技术兼容性：[兼容 / 需要新建 Rule：前端品牌守门/API兼容检查/...]
          ─────────────────────────────
          
          综合判断：
          ✅ 完全兼容 → 可直接触发 role-产品经理
          ⚠️ 有缺口但可并行补齐 → 建议按「建议行动」顺序处理后再启动开发
          ❌ 结构性不兼容 → 必须先解决阻塞项才能立项
          
          [立即触发 role-产品经理] [先处理缺口]」

---

注意事项

• 本 Skill 不替代 role-产品经理：它是立项前的「可选预检」，不阻断开发流程
• 报告是行动建议，不是判决：用户可选择「带着已知缺口立项」并在后续补齐
• 认知根缺失不是 Blocker：新产品可以先立项，同时触发认知碎片捕捉建立认知根
• 最小化原则：只检查「与体系兼容性相关」的维度，不做产品设计本身的评判

---

与现有 Skill 的关系

Skill	关系
role-产品经理	本 Skill 是其前置可选检查，通过后直接触发 PM
cross-project-coordinator	若新产品与现有产品存在 API 依赖 → 同时触发协调框架
cognitive-work-alignment-check	Loop 2 检查中若发现认知根缺失，建议触发该 Skill
DOMAIN-REGISTRY	Loop 3 检查中若需要新增工作域节点，更新该文档

---

变更记录

v1.0 — 2026-03-21 — 初始创建（PD1 Gap 修复）

根因：三大闭环架构蓝图 §差距清单「新产品/场景加入时兼容性检查：❌缺失」。每次启动新项目都直接触发 PM，没有检查「这个新产品是否与现有认知体系/Skill体系/工作域架构兼容」，导致：①产品认知根缺失（漂浮任务）②工作域未注册（传播完备性缺口）③技术栈不兼容（如 openclaw/opencode 问题）被遗留到开发后期才发现。

验证结果：

• 正向验证：立项新产品时触发，输出包含 Loop 1/2/3 三层检查报告（待真实场景验证）
• 负向验证：现有产品功能迭代不触发本 Skill