dpml-prompt/prompt/domain/role-designer/execution/component-management.execution.md

DPML-powered AI prompt framework - Revolutionary AI-First CLI system based on Deepractice Prompt Markup Language. Build sophisticated AI agents with structured prompts, memory systems, and execution frameworks.

<execution domain="component-management">
  <constraint>
    ## 组件管理约束
    
    ### 组件复用约束
    - **依赖限制**：组件依赖链不得超过3层，避免过度复杂化
    - **版本兼容**：新组件必须向后兼容，不得破坏existing系统
    - **资源消耗**：单个组件的资源消耗必须控制在合理范围内
    
    ### 组件设计约束
    - **单一职责**：每个组件必须有明确单一的功能职责
    - **接口标准**：组件接口必须符合DPML协议规范
    - **测试覆盖**：新组件必须有完整的测试覆盖和验证机制
    
    ### 生态兼容约束
    - **命名冲突**：新组件名称不得与existing组件重复
    - **功能重叠**：避免创建与existing组件功能重叠的组件
    - **引用路径**：组件引用路径必须遵循PromptX标准规范
  </constraint>
  
  <rule>
    ## 组件管理强制规则
    
    ### 组件创建规则
    1. **创建前评估**：创建新组件前必须评估是否可复用existing组件
    2. **标准模板使用**：必须使用标准模板创建新组件
    3. **命名规范遵循**：组件命名必须遵循既定的命名规范
    4. **文档同步更新**：创建组件后必须同步更新相关文档
    
    ### 组件复用规则
    1. **优先级顺序**：复用existing组件 > 扩展组件 > 创建新组件
    2. **引用语法正确**：必须使用正确的@引用语法
    3. **依赖关系明确**：组件间依赖关系必须明确标注
    4. **版本管理**：对组件版本变更必须进行适当管理
    
    ### 组件维护规则
    1. **定期review**：定期检查组件使用情况和性能表现
    2. **废弃管理**：对不再使用的组件要有明确的废弃流程
    3. **安全更新**：发现安全问题时必须及时更新修复
    4. **用户通知**：重大变更必须及时通知相关用户
  </rule>
  
  <guideline>
    ## 组件管理指导原则
    
    ### 组件设计建议
    - **模块化设计**：建议将大型功能拆分为小型、独立的组件
    - **接口简洁**：推荐设计简洁明确的组件接口
    - **文档完备**：建议为每个组件提供完整的使用文档
    - **示例丰富**：推荐提供多种使用场景的示例
    
    ### 复用策略建议
    - **分析existing组件**：建议深入分析现有组件的功能和特点
    - **评估适配成本**：推荐评估复用vs新建的成本效益
    - **渐进式集成**：建议采用渐进式方式集成复杂组件
    - **性能监控**：推荐监控组件复用后的性能影响
    
    ### 维护优化建议
    - **使用统计收集**：建议收集组件使用统计数据
    - **反馈机制建立**：推荐建立用户反馈收集机制
    - **持续改进**：建议基于使用反馈持续改进组件
    - **社区协作**：推荐与社区协作共同维护组件生态
  </guideline>
  
  <process>
    ## 组件管理流程
    
    ```mermaid
    flowchart TD
      A[需求分析] --> B[existing组件评估]
      B --> C{是否有适合组件?}
      C -->|是| D[评估复用可行性]
      C -->|否| E[设计新组件方案]
      D --> F{复用成本合理?}
      F -->|是| G[配置复用组件]
      F -->|否| E
      E --> H[创建组件模板]
      H --> I[实现组件功能]
      I --> J[编写组件文档]
      J --> K[创建使用示例]
      K --> L[组件测试验证]
      L --> M{测试通过?}
      M -->|否| N[修复组件问题]
      N --> L
      M -->|是| O[注册组件到生态]
      G --> P[集成到角色设计]
      O --> P
      P --> Q[功能验证测试]
      Q --> R[性能影响评估]
      R --> S[用户使用培训]
      S --> T[收集使用反馈]
      T --> U[组件优化迭代]
    ```
    
    ### 关键决策点
    1. **复用vs新建决策**：基于功能匹配度、修改成本、维护复杂度决策
    2. **组件粒度决策**：平衡组件的独立性和复用性
    3. **接口设计决策**：在简洁性和扩展性间找到平衡
    4. **废弃时机决策**：基于使用量、维护成本、替代方案决策
  </process>
  
  <criteria>
    ## 组件管理评价标准
    
    | 管理维度 | 优秀标准 | 良好标准 | 合格标准 | 需要改进 |
    |---------|---------|---------|---------|---------|
    | **复用率** | 新角色80%以上使用existing组件 | 60-80%使用existing组件 | 40-60%使用existing组件 | <40%使用existing组件 |
    | **组件质量** | 组件无bug，性能优秀 | 组件稳定，性能良好 | 组件基本可用 | 组件存在明显问题 |
    | **文档完整度** | 文档完整详细，示例丰富 | 文档基本完整，有示例 | 文档简单但可用 | 文档缺失或不准确 |
    | **维护及时性** | 问题24小时内响应处理 | 48小时内响应处理 | 1周内响应处理 | 响应缓慢或无响应 |
    | **生态和谐度** | 组件完美融入生态 | 组件良好集成 | 组件基本兼容 | 存在兼容性问题 |
    | **用户满意度** | 用户评价≥4.5/5.0 | 用户评价4.0-4.5/5.0 | 用户评价3.5-4.0/5.0 | 用户评价<3.5/5.0 |
    
    ### 组件健康度指标
    - **可用性**：组件正常运行时间≥99.9%
    - **性能**：组件响应时间在合理范围内
    - **安全性**：无已知安全漏洞
    - **兼容性**：与主流环境兼容性≥95%
    - **更新频率**：根据需要及时更新维护
    
    ### 生态贡献指标
    - **复用价值**：被其他角色复用的次数和频率
    - **创新价值**：引入的新功能和改进点
    - **稳定价值**：为系统稳定性做出的贡献
    - **社区价值**：对社区发展的促进作用
  </criteria>
</execution>