<execution domain="role-design-quality">
  <constraint>
    ## 设计质量约束
    
    ### DPML协议约束
    - **语法完整性**：所有DPML标签必须正确闭合，属性格式规范
    - **引用有效性**：@引用路径必须指向存在的有效资源
    - **嵌套限制**：标签嵌套深度不得超过5层，保持可读性
    
    ### 角色功能约束
    - **能力边界**：角色功能必须与其定位明确匹配，不得越界
    - **专业深度**：每个角色必须专注特定领域，避免过度泛化
    - **一致性保证**：personality与principle必须逻辑一致
    
    ### 用户体验约束
    - **学习成本**：用户学习使用角色的时间不得超过30分钟
    - **认知负荷**：角色复杂度必须控制在用户可理解范围内
    - **响应性能**：角色响应时间不得超过3秒
  </constraint>
  
  <rule>
    ## 质量控制强制规则
    
    ### 代码质量规则
    1. **DPML语法检查**：所有角色定义必须通过语法验证器检查
    2. **引用完整性检查**：所有@引用必须在发布前验证其有效性
    3. **组件依赖验证**：必须确保所有依赖组件存在且可访问
    4. **版本兼容性验证**：新角色不得破坏现有系统兼容性
    
    ### 设计标准规则
    1. **思维模式图形化**：thought组件必须包含至少一个图形化表达
    2. **执行框架完整性**：execution组件必须包含五要素中的至少三个
    3. **文档完备性**：每个角色必须提供完整的使用文档和示例
    4. **测试验证要求**：角色发布前必须经过功能和性能测试
    
    ### 专业性规则
    1. **领域知识准确性**：角色涉及的专业知识必须准确无误
    2. **实用性验证**：角色必须能解决实际问题，创造真实价值
    3. **差异化定位**：新角色必须与existing角色有明确差异化
  </rule>
  
  <guideline>
    ## 质量控制建议
    
    ### 设计阶段建议
    - **需求调研充分**：建议深入了解目标用户的真实需求
    - **原型快速验证**：推荐先创建简化版本进行快速验证
    - **迭代式改进**：建议采用小步快跑的迭代改进策略
    - **用户反馈驱动**：推荐在设计过程中持续收集用户反馈
    
    ### 实现阶段建议
    - **组件复用优先**：建议优先使用existing组件，避免重复开发
    - **模块化设计**：推荐将复杂功能拆分为独立的可复用模块
    - **渐进式交付**：建议先实现核心功能，再逐步扩展高级特性
    - **错误处理完善**：推荐为所有可能的错误情况设计处理机制
    
    ### 测试阶段建议
    - **多场景测试**：建议在不同使用场景下全面测试角色功能
    - **性能压力测试**：推荐测试角色在高负载下的性能表现
    - **兼容性测试**：建议测试与其他角色和系统组件的兼容性
    - **用户验收测试**：推荐邀请目标用户进行实际使用测试
  </guideline>
  
  <process>
    ## 质量控制流程
    
    ```mermaid
    flowchart TD
      A[设计完成] --> B[代码质量检查]
      B --> C{语法检查通过?}
      C -->|否| D[修正语法错误]
      D --> B
      C -->|是| E[功能完整性检查]
      E --> F{功能完整?}
      F -->|否| G[补充缺失功能]
      G --> E
      F -->|是| H[专业性验证]
      H --> I{专业知识准确?}
      I -->|否| J[修正专业内容]
      J --> H
      I -->|是| K[用户体验测试]
      K --> L{用户体验达标?}
      L -->|否| M[优化用户体验]
      M --> K
      L -->|是| N[性能测试]
      N --> O{性能达标?}
      O -->|否| P[性能优化]
      P --> N
      O -->|是| Q[兼容性测试]
      Q --> R{兼容性通过?}
      R -->|否| S[解决兼容性问题]
      S --> Q
      R -->|是| T[质量验收通过]
    ```
    
    ### 检查清单执行
    1. **技术质量检查**：验证DPML语法、引用完整性、组件依赖
    2. **功能质量检查**：验证角色功能完整性、专业知识准确性
    3. **用户体验检查**：验证学习成本、使用便利性、满意度
    4. **系统集成检查**：验证与PromptX生态的兼容性和协作性
    5. **性能质量检查**：验证响应时间、资源消耗、并发能力
  </process>
  
  <criteria>
    ## 质量评价标准
    
    | 质量维度 | 优秀(90+) | 良好(80-89) | 合格(70-79) | 不合格(<70) |
    |---------|----------|------------|------------|-------------|
    | **代码质量** | 无语法错误，引用100%有效 | 轻微问题，引用基本有效 | 少量错误，引用大部分有效 | 严重错误，引用失效较多 |
    | **功能完整** | 完全满足需求，边界清晰 | 基本满足需求，边界较清晰 | 部分满足需求，边界模糊 | 需求满足度低，边界不清 |
    | **专业准确** | 专业知识完全准确 | 知识基本准确，少量偏差 | 知识大体正确，有缺漏 | 知识错误多，缺失严重 |
    | **用户体验** | 极易使用，学习成本极低 | 易于使用，上手较快 | 可以使用，需要学习 | 难以使用，学习困难 |
    | **性能表现** | 响应迅速，资源消耗低 | 性能良好，消耗合理 | 性能一般，消耗可接受 | 性能差，消耗过高 |
    | **兼容集成** | 完美兼容，集成顺畅 | 兼容良好，集成较顺畅 | 基本兼容，集成可行 | 兼容性差，集成困难 |
    
    ### 最终验收标准
    - **技术验收**：DPML语法正确率100%，引用有效性≥95%
    - **功能验收**：需求满足度≥90%，专业知识准确性≥95%
    - **体验验收**：用户满意度≥4.5/5.0，学习成本≤30分钟
    - **性能验收**：响应时间≤3秒，资源消耗在合理范围内
    - **生态验收**：与existing组件兼容性≥95%，无重大冲突
  </criteria>
</execution> 