feat: 实现本地角色动态发现机制 - 双重角色发现机制：同时支持npm仓库角色和本地项目角色 - 智能环境检测：自动适配开发、npx、全局、本地、monorepo等部署环境 - 安全机制完善：路径验证、权限检查、多层容错处理 - 向后兼容保证，不影响现有功能
This commit is contained in:
Cen-Yaozu
@ -0,0 +1,127 @@
|
||||
<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>
|
||||
Reference in New Issue
Block a user