核心修复: - 修复PackageDiscovery._isValidDevelopmentRoot()检查resource目录而非prompt - 更新package.json files字段从prompt/改为resource/ - 修复RegisterCommand.js中的资源路径引用 - 更新WelcomeCommand.js中的@package://prompt/为@package://resource/ - 修复PromptProtocol.js中所有@package://prompt/路径引用 - 更新PackageProtocol.js示例路径 - 批量更新docs/目录下26个文档的路径引用 技术价值: - 解决PackageDiscovery无法加载系统级角色的问题 - 消除PackageProtocol的Access denied错误 - 实现prompt→resource语义重构的100%完整性 - 确保所有8个系统级角色正常加载和激活 验证结果: - ✅ 61个系统级资源正常加载 - ✅ 8个角色完全可用(assistant,frontend-developer,java-backend-developer,noface,nuwa,sean,xiaohongshu-marketer,product-manager) - ✅ welcome和action命令完全正常工作 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
465 lines
12 KiB
Markdown
465 lines
12 KiB
Markdown
# 用户资源发现系统设计
|
||
|
||
## 📋 概述
|
||
|
||
基于ResourceManager的用户资源发现机制,支持用户创建自定义角色、执行流程、思维模式等资源,实现即创即用的体验。
|
||
|
||
## 🎯 核心问题
|
||
|
||
**现状分析**:
|
||
- 系统资源已在 `src/resource.registry.json` 静态注册
|
||
- 当前 `HelloCommand.discoverLocalRoles()` 错误扫描系统路径,造成重复处理
|
||
- 用户需要在项目级别创建和管理自定义资源
|
||
|
||
**解决目标**:
|
||
- 仅发现用户资源,不重复处理系统资源
|
||
- 支持多种资源类型:角色、执行流程、思维模式
|
||
- 实现用户资源覆盖系统资源的能力
|
||
|
||
## 🏗️ 架构设计
|
||
|
||
### 资源分层
|
||
|
||
```
|
||
系统资源 (静态注册)
|
||
├── src/resource.registry.json # 系统资源注册表
|
||
└── resource/domain/{role}/ # 系统资源文件
|
||
|
||
用户资源 (动态发现)
|
||
└── .promptx/resource/domain/{role}/ # 用户资源文件
|
||
```
|
||
|
||
### 目录结构规范
|
||
|
||
#### 用户资源目录
|
||
```
|
||
.promptx/
|
||
├── resource/
|
||
│ └── domain/
|
||
│ └── {role-id}/
|
||
│ ├── {role-id}.role.md
|
||
│ ├── thought/
|
||
│ │ └── {name}.thought.md
|
||
│ └── execution/
|
||
│ └── {name}.execution.md
|
||
└── memory/ # 现有目录
|
||
```
|
||
|
||
**设计原则**:
|
||
- **镜像结构**:用户目录结构镜像系统结构,降低认知负载
|
||
- **资源聚合**:角色相关资源统一管理在角色目录下
|
||
- **类型支持**:支持 role、thought、execution 等多种资源类型
|
||
|
||
### 发现机制重构
|
||
|
||
#### ResourceManager 扩展
|
||
```javascript
|
||
// src/lib/core/resource/resourceManager.js
|
||
class ResourceManager {
|
||
async discoverUserResources() {
|
||
const userResourcePath = path.join(packageRoot, '.promptx', 'resource', 'domain')
|
||
return await this.scanResourceDirectory(userResourcePath)
|
||
}
|
||
|
||
async scanResourceDirectory(basePath) {
|
||
// 使用 Node.js 原生 API,移除 glob 依赖
|
||
// 支持 role、thought、execution 等多种资源类型
|
||
}
|
||
|
||
async loadUnifiedRegistry() {
|
||
const systemResources = await this.loadSystemRegistry()
|
||
const userResources = await this.discoverUserResources()
|
||
|
||
// 用户资源覆盖系统资源
|
||
return { ...systemResources, ...userResources }
|
||
}
|
||
}
|
||
```
|
||
|
||
#### HelloCommand 简化
|
||
```javascript
|
||
// src/lib/core/pouch/commands/HelloCommand.js
|
||
class HelloCommand {
|
||
async loadRoleRegistry() {
|
||
// 移除错误的本地发现逻辑
|
||
// 直接从 ResourceManager 获取统一注册表
|
||
return await this.resourceManager.loadUnifiedRegistry()
|
||
}
|
||
}
|
||
```
|
||
|
||
## 🤖 nuwa 角色设计
|
||
|
||
### 核心职责
|
||
- **需求理解**:通过自然对话收集用户场景需求
|
||
- **资源生成**:基于 DPML 协议生成角色文件
|
||
- **文件管理**:将生成内容保存到正确的用户资源路径
|
||
|
||
### 对话策略
|
||
```
|
||
收集目标信息:
|
||
├── scenario: 用户工作场景
|
||
├── painPoint: 主要痛点
|
||
└── expectation: 期望结果
|
||
|
||
生成时机:三项信息齐全即可生成
|
||
```
|
||
|
||
### 生成模板
|
||
```xml
|
||
<role>
|
||
<personality>
|
||
[基于场景的思维模式]
|
||
</personality>
|
||
|
||
<principle>
|
||
[基于痛点的行为原则]
|
||
</principle>
|
||
|
||
<knowledge>
|
||
[基于期望的知识体系]
|
||
</knowledge>
|
||
</role>
|
||
```
|
||
|
||
## 🔧 技术实现
|
||
|
||
### 实现优先级
|
||
|
||
#### Phase 1: 核心功能
|
||
1. **ResourceManager 扩展**
|
||
- 实现 `discoverUserResources()` 方法
|
||
- 使用 Node.js 原生 API 替代 glob
|
||
- 支持多种资源类型扫描
|
||
|
||
2. **HelloCommand 重构**
|
||
- 移除错误的系统路径扫描
|
||
- 集成 ResourceManager 统一注册表
|
||
|
||
3. **nuwa 角色实现**
|
||
- DPML 协议掌握和文件生成
|
||
- 用户资源路径文件保存
|
||
|
||
#### Phase 2: 完善功能
|
||
1. **错误处理**:跨平台兼容性和容错机制
|
||
2. **性能优化**:资源发现缓存机制
|
||
3. **用户体验**:更智能的对话策略
|
||
|
||
### 关键技术要点
|
||
|
||
#### 1. 跨平台路径处理
|
||
```javascript
|
||
// 使用 Node.js 原生 API,避免 glob 兼容性问题
|
||
const fs = require('fs-extra')
|
||
const path = require('path')
|
||
|
||
async function discoverUserResources() {
|
||
const userResourcePath = path.join(
|
||
await packageProtocol.getPackageRoot(),
|
||
'.promptx', 'resource', 'domain'
|
||
)
|
||
|
||
if (!await fs.pathExists(userResourcePath)) {
|
||
return {}
|
||
}
|
||
|
||
// 使用原生 readdir 和 stat 扫描
|
||
}
|
||
```
|
||
|
||
#### 2. 资源覆盖机制
|
||
```javascript
|
||
// 用户资源优先级高于系统资源
|
||
const unifiedRegistry = {
|
||
...systemResources, // 系统资源作为基础
|
||
...userResources // 用户资源覆盖同名项
|
||
}
|
||
```
|
||
|
||
#### 3. DPML 元数据提取
|
||
```javascript
|
||
function extractRoleMetadata(content, roleId) {
|
||
// 从 DPML 标签中提取角色元信息
|
||
// 用于角色发现和展示
|
||
}
|
||
```
|
||
|
||
## 🧪 测试策略与设计
|
||
|
||
### 测试架构分层
|
||
|
||
```
|
||
单元测试层 (Unit Tests)
|
||
├── ResourceManager.unit.test.js # 资源管理器核心逻辑测试
|
||
├── HelloCommand.unit.test.js # 命令行接口测试
|
||
├── UserResourceDiscovery.unit.test.js # 用户资源发现测试
|
||
└── DPMLParser.unit.test.js # DPML格式解析测试
|
||
|
||
集成测试层 (Integration Tests)
|
||
├── ResourceDiscovery.integration.test.js # 资源发现完整流程测试
|
||
├── NuwaRoleGeneration.integration.test.js # nuwa角色生成端到端测试
|
||
└── CrossPlatform.integration.test.js # 跨平台兼容性测试
|
||
|
||
端到端测试层 (E2E Tests)
|
||
└── UserWorkflow.e2e.test.js # 完整用户工作流程测试
|
||
```
|
||
|
||
### 核心测试组件
|
||
|
||
#### 1. ResourceManager 单元测试
|
||
```javascript
|
||
// src/tests/core/resource/ResourceManager.unit.test.js
|
||
describe('ResourceManager', () => {
|
||
describe('discoverUserResources', () => {
|
||
it('应该正确扫描用户资源目录', async () => {
|
||
// 模拟用户资源文件结构
|
||
// 验证发现结果的正确性
|
||
})
|
||
|
||
it('应该支持多种资源类型', async () => {
|
||
// 测试 role、thought、execution 类型
|
||
})
|
||
|
||
it('应该处理不存在的目录', async () => {
|
||
// 测试容错机制
|
||
})
|
||
})
|
||
|
||
describe('loadUnifiedRegistry', () => {
|
||
it('应该正确合并系统和用户资源', async () => {
|
||
// 验证用户资源覆盖系统资源
|
||
})
|
||
})
|
||
})
|
||
```
|
||
|
||
#### 2. HelloCommand 重构测试
|
||
```javascript
|
||
// src/tests/commands/HelloCommand.unit.test.js
|
||
describe('HelloCommand - 重构后', () => {
|
||
it('应该移除错误的系统路径扫描', async () => {
|
||
// 验证不再扫描 resource/domain/ 路径
|
||
})
|
||
|
||
it('应该集成ResourceManager统一注册表', async () => {
|
||
// 验证使用ResourceManager.loadUnifiedRegistry()
|
||
})
|
||
|
||
it('应该正确显示用户自定义角色', async () => {
|
||
// 验证用户角色在hello命令中的展示
|
||
})
|
||
})
|
||
```
|
||
|
||
#### 3. 用户资源发现集成测试
|
||
```javascript
|
||
// src/tests/integration/UserResourceDiscovery.integration.test.js
|
||
describe('用户资源发现机制', () => {
|
||
beforeEach(async () => {
|
||
// 创建测试用的用户资源结构
|
||
await createTestUserResourceStructure()
|
||
})
|
||
|
||
it('应该发现用户创建的角色', async () => {
|
||
// 创建测试角色文件
|
||
// 验证ResourceManager能正确发现
|
||
})
|
||
|
||
it('应该支持资源类型扩展', async () => {
|
||
// 测试thought、execution文件的发现
|
||
})
|
||
|
||
it('应该处理DPML格式验证', async () => {
|
||
// 测试格式错误的文件处理
|
||
})
|
||
})
|
||
```
|
||
|
||
#### 4. nuwa 角色生成端到端测试
|
||
```javascript
|
||
// src/tests/integration/NuwaRoleGeneration.integration.test.js
|
||
describe('nuwa 角色生成完整流程', () => {
|
||
it('应该根据用户需求生成角色文件', async () => {
|
||
// 模拟用户输入
|
||
// 验证生成的文件内容和位置
|
||
})
|
||
|
||
it('应该生成符合DPML规范的角色', async () => {
|
||
// 验证生成文件的DPML格式正确性
|
||
})
|
||
|
||
it('应该创建正确的目录结构', async () => {
|
||
// 验证镜像系统结构的目录创建
|
||
})
|
||
})
|
||
```
|
||
|
||
#### 5. 跨平台兼容性测试
|
||
```javascript
|
||
// src/tests/integration/CrossPlatform.integration.test.js
|
||
describe('跨平台兼容性', () => {
|
||
it('应该在Windows上正确处理路径', () => {
|
||
// 模拟Windows路径分隔符
|
||
// 验证路径处理的正确性
|
||
})
|
||
|
||
it('应该在macOS/Linux上正确处理路径', () => {
|
||
// 验证Unix风格路径处理
|
||
})
|
||
|
||
it('应该使用Node.js原生API替代glob', () => {
|
||
// 验证不使用glob库的实现
|
||
})
|
||
})
|
||
```
|
||
|
||
### 测试数据和环境
|
||
|
||
#### 测试数据结构
|
||
```
|
||
src/tests/fixtures/
|
||
├── user-resources/
|
||
│ └── domain/
|
||
│ ├── test-role/
|
||
│ │ ├── test-role.role.md # 标准DPML格式
|
||
│ │ ├── thought/
|
||
│ │ │ └── test.thought.md
|
||
│ │ └── execution/
|
||
│ │ └── test.execution.md
|
||
│ ├── invalid-role/
|
||
│ │ └── invalid.role.md # 格式错误的文件
|
||
│ └── sales-analyst/
|
||
│ └── sales-analyst.role.md # nuwa生成测试样例
|
||
├── system-resources/
|
||
│ └── mock-registry.json # 模拟系统注册表
|
||
└── dpml-samples/
|
||
├── valid-role.md # 有效DPML样例
|
||
└── invalid-role.md # 无效DPML样例
|
||
```
|
||
|
||
#### 测试环境配置
|
||
```javascript
|
||
// src/tests/setup/testEnvironment.js
|
||
export class TestEnvironment {
|
||
async setup() {
|
||
// 创建临时测试目录
|
||
this.testDir = await createTempTestDirectory()
|
||
|
||
// 模拟 .promptx 结构
|
||
await this.createMockUserResourceStructure()
|
||
|
||
// 设置环境变量
|
||
process.env.PROMPTX_TEST_MODE = 'true'
|
||
}
|
||
|
||
async teardown() {
|
||
// 清理测试文件
|
||
await fs.remove(this.testDir)
|
||
}
|
||
}
|
||
```
|
||
|
||
### 测试覆盖率要求
|
||
|
||
#### 覆盖率目标
|
||
- **整体代码覆盖率**: ≥ 85%
|
||
- **ResourceManager核心逻辑**: ≥ 95%
|
||
- **HelloCommand重构部分**: ≥ 90%
|
||
- **DPML解析逻辑**: ≥ 95%
|
||
- **跨平台路径处理**: 100%
|
||
|
||
#### 关键测试场景
|
||
```
|
||
✅ 用户资源发现功能
|
||
✅ 系统资源静态加载
|
||
✅ 资源覆盖机制
|
||
✅ DPML格式验证
|
||
✅ 跨平台路径处理
|
||
✅ 错误处理和容错
|
||
✅ nuwa角色生成流程
|
||
✅ 文件系统操作安全性
|
||
✅ 缓存机制有效性
|
||
✅ CLI集成正确性
|
||
```
|
||
|
||
### 测试执行策略
|
||
|
||
#### 测试运行配置
|
||
```json
|
||
// package.json scripts
|
||
{
|
||
"test": "jest",
|
||
"test:unit": "jest --testPathPattern=unit",
|
||
"test:integration": "jest --testPathPattern=integration",
|
||
"test:e2e": "jest --testPathPattern=e2e",
|
||
"test:coverage": "jest --coverage",
|
||
"test:watch": "jest --watch"
|
||
}
|
||
```
|
||
|
||
#### CI/CD 集成
|
||
```yaml
|
||
# .github/workflows/test.yml
|
||
name: Test Suite
|
||
on: [push, pull_request]
|
||
jobs:
|
||
test:
|
||
strategy:
|
||
matrix:
|
||
os: [ubuntu-latest, windows-latest, macos-latest]
|
||
node: [16, 18, 20]
|
||
steps:
|
||
- name: Run Unit Tests
|
||
run: npm run test:unit
|
||
- name: Run Integration Tests
|
||
run: npm run test:integration
|
||
- name: Check Coverage
|
||
run: npm run test:coverage
|
||
```
|
||
|
||
## 📊 用户体验流程
|
||
|
||
```bash
|
||
# 1. 创建角色
|
||
npx promptx action nuwa
|
||
# 对话生成: .promptx/resource/domain/sales-analyst/sales-analyst.role.md
|
||
|
||
# 2. 立即可用(自动发现)
|
||
npx promptx hello
|
||
# 显示新角色: sales-analyst
|
||
|
||
# 3. 直接使用
|
||
npx promptx action sales-analyst
|
||
```
|
||
|
||
## 🔄 设计决策
|
||
|
||
### 为什么选择 .promptx/resource/domain 结构?
|
||
- **镜像一致性**:与系统 `resource/domain` 结构保持一致
|
||
- **类型扩展性**:未来可支持 thought、execution 等资源类型
|
||
- **认知简单性**:用户理解成本最低
|
||
|
||
### 为什么移除 HelloCommand 的发现逻辑?
|
||
- **职责单一**:ResourceManager 专门负责资源管理
|
||
- **避免重复**:系统资源已静态注册,无需重复发现
|
||
- **架构清晰**:分层明确,便于维护
|
||
|
||
### 为什么使用 Node.js 原生 API?
|
||
- **兼容性**:完全跨平台,无第三方库依赖问题
|
||
- **性能**:原生 API 性能更优
|
||
- **维护性**:减少依赖复杂度
|
||
|
||
## 📚 相关文档
|
||
|
||
- [DPML协议](../resource/protocol/dpml.protocol.md)
|
||
- [ResourceManager 架构](../src/lib/core/resource/)
|
||
- [角色标签规范](../resource/protocol/tag/role.tag.md)
|
||
|
||
---
|
||
|
||
**实现要点**:
|
||
1. ResourceManager 统一资源发现
|
||
2. 用户资源镜像系统结构
|
||
3. nuwa 基于 DPML 生成角色
|
||
4. 即创即用的无缝体验
|
||
5. 完整测试覆盖和质量保证 |