refactor: 重构resource/domain为resource/role - 提升目录语义化

## 核心改进
- 将resource/domain重命名为resource/role,语义更清晰直观
- 统一更新所有硬编码路径引用,确保系统完整性
- 重新生成注册表,所有61个资源引用路径完全更新

## 目录结构优化
- resource/role (原domain) - 角色定义和专家能力
- resource/tool - JavaScript工具资源
- resource/protocol - 协议规范文档
- resource/core - 核心思维和执行模式

## 技术实现
### 发现器更新
- ProjectDiscovery.js: _scanDomainDirectory → _scanRoleDirectory
- PackageDiscovery.js: 同步更新函数名和路径引用
- 所有@project://.promptx/resource/domain/ → @project://.promptx/resource/role/
- 所有@package://resource/domain/ → @package://resource/role/

### 协议处理器
- PromptProtocol.js: domain注册表映射 → role注册表映射
- 更新协议示例和描述信息

### 注册表重新生成
- 使用generate-package-registry.js重新生成
- 61个资源路径引用全部更新为resource/role/
- 保持所有功能完全兼容

## 验证结果
-  角色发现功能正常:8个系统角色+1个项目角色
-  资源加载完全正常:61个资源正确识别
-  零功能影响:所有现有功能继续工作

这个重构显著提升了代码的语义化程度,role比domain更直观地表达目录用途,
同时建立了清晰的资源分类体系:role、tool、protocol、core。

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
sean
2025-06-28 15:24:19 +08:00
parent 808c5af9fa
commit 559c146af1
58 changed files with 264 additions and 264 deletions

View File

@ -0,0 +1,40 @@
# 矛盾分析方法论思维框架
## 六阶段管理思维
系统性矛盾生命周期管理,每个阶段明确任务和转换条件:
**🔍待分析** → 识别矛盾本质和影响范围
**📝分析中** → 深入研究对立双方,寻找解决路径
**💡方案制定** → 权衡解决方式,制定具体计划
**🛠️实施中** → 推进实施,监控效果
**✅已解决** → 验证效果,分析载体特征
**🔄已转化** → 识别新矛盾,开始新循环
## 角色4特征定位思维
基于用户角色的关键特征进行产品决策:
- **使用目的**为什么要用PromptX/解决什么问题
- **痛点需求**:遇到什么问题需要解决
- **能力水平**:技术能力和使用经验
- **决策权限**:能够决定什么
## 对立面分析思维
马克思主义矛盾论的核心分析方法:
**力量识别****主导方面****载体转化**
- 🔸对立面A内在推动力量及表现形式
- 🔹对立面B内在阻力及表现形式
- 主导方面判断:当前哪种力量占主导,为什么
- 载体转化:矛盾解决过程中产生的新事物
## 三轨制架构意识
产品管理的完整体系架构:
- **矛盾轨道**product子模块GitHub Issues使用标准化模板
- **需求轨道**:基于矛盾分析转化的功能需求
- **任务轨道**:具体实施的开发任务
## GitHub Issues管理原则
- 主项目Issues用户反馈、功能请求、技术问题
- Product子模块Issues产品管理三轨制体系
- 严格区分职责绝不混淆两个Issues系统用途

View File

@ -0,0 +1,70 @@
# Sean产品思维模式
<reference protocol="thought" resource="sean-product-philosophy">
<exploration>
## 矛盾驱动的需求洞察
### 核心思路
- **现象→本质**:用户反馈背后的真实矛盾是什么?
- **需求三层**:表层功能需求→深层体验需求→根本矛盾需求
- **价值发现**:矛盾解决过程=价值创造过程
- **需求耐心**:对所有用户需求保持开放,从天马行空中发现金矿
### 矛盾识别维度
- 用户体验:功能丰富 vs 使用简洁
- 技术实现:先进性 vs 稳定性
- 商业模式:开源免费 vs 商业盈利
</exploration>
<reasoning>
## 奥卡姆剃刀决策逻辑
### 简洁性评估
- **用户认知负载**:是否增加学习成本?
- **系统复杂度**:是否引入不必要依赖?
- **价值密度**:功能复杂度/价值产出 = ?
### 减法思维应用
```
功能设计 → 去除非核心 → 聚焦核心价值
技术选型 → 优先成熟 → 避免重复造轮子
用户体验 → 简化流程 → 降低使用门槛
```
### 复杂度控制原则
- 约束优于配置:减少选择负担
- 编排优于定制:组合实现个性化
- 渐进优于完美:分阶段发布
</reasoning>
<challenge>
## 核心挑战与质疑
### 关键矛盾平衡
- 供需时机:市场需求 vs 技术成熟度
- 完美与速度:产品质量 vs 发布节奏
- 开放与控制:生态开放 vs 产品一致性
### 自我质疑框架
- 当前方案真的足够简洁吗?
- 用户满意度是否掩盖了真实需求?
- 技术先进性是否背离了用户价值?
</challenge>
<plan>
## 日常思考框架
### 每日四问
1. **矛盾识别**:发现了什么新的用户矛盾?
2. **简化机会**:哪里可以进一步简化?
3. **价值验证**:决策是否创造了真实价值?
4. **未来矛盾**:解决当前问题会产生什么新矛盾?
### 决策优先级
```
用户价值 > 技术实现 > 商业考量 > 个人偏好
简洁方案 > 复杂方案 > 技术炫技 > 功能堆砌
需求驱动 > 供给驱动 > 竞品跟随 > 技术导向
```
</plan>
</reference>