<execution domain="product-management">
  <process>
    # 工作项标题命名流程
    
    ```mermaid
    flowchart TD
      A[确定工作项层级] --> B[选择命名模式]
      B --> C[应用命名规则]
      C --> D[检查命名质量]
      D --> E{质量检查}
      E -->|通过| F[标题确认]
      E -->|不通过| G[优化调整]
      G --> C
      
      A --> A1[Epic层级]
      A --> A2[Feature层级]
      A --> A3[Story层级]
      A --> A4[Task层级]
    ```
    
    ## 分层命名体系
    
    ```mermaid
    mindmap
      root((工作项命名))
        Epic命名
          "Epic X: 主题名称"
          功能域描述
          价值主题表达
        Feature命名
          "Feature X.Y: 功能模块"
          能力描述
          模块边界
        Story命名
          "Story X.Y.Z: 用户能够..."
          用户视角
          具体行为
        Task命名
          "Task X.Y.Z.N: 实现..."
          技术视角
          具体实现
    ```
  </process>
  
  <guideline>
    ### 层级编号规则
    
    - **Epic层级**: `Epic X: 主题名称`
      - X为数字序号（1,2,3...）
      - 主题名称简洁概括核心价值域
      - 示例：`Epic 1: 核心工作区`、`Epic 2: 文件系统`
    
    - **Feature层级**: `Feature X.Y: 功能模块名`
      - X为所属Epic编号，Y为Feature序号
      - 功能模块名描述具体能力边界
      - 示例：`Feature 1.1: 全局结构`、`Feature 1.2: 内容预览区`
    
    - **Story层级**: `Story X.Y.Z: 角色+能够+动作+对象`
      - X.Y为所属Feature编号，Z为Story序号
      - 严格按照用户故事格式："XXX能够..."
      - 示例：`Story 1.1.1: 教师能够查看和管理试题结构`
    
    - **Task层级**: `Task X.Y.Z.N: 实现/开发/设计+具体内容`
      - X.Y.Z为所属Story编号，N为Task序号
      - 技术实现视角，动词+具体任务
      - 示例：`Task 1.1.1.1: 实现试题结构树组件`
    
    ### 命名语言规范
    
    - **动词选择精准**：避免模糊动词，使用具体行为词
      - ✅ 查看、编辑、创建、删除、导出
      - ❌ 处理、操作、管理（过于宽泛）
    
    - **对象描述具体**：明确操作对象和范围
      - ✅ 试题结构、用户权限、数据报表
      - ❌ 内容、信息、数据（过于抽象）
    
    - **角色明确标识**：Story必须明确用户角色
      - ✅ 教师能够、学生能够、管理员能够
      - ❌ 用户能够（角色不明确）
    
    ### 特殊情况处理
    
    - **跨Feature Story**: 使用主Feature编号，标注依赖
    - **技术性Story**: 标注"系统能够"而非用户角色
    - **Bug修复Task**: 使用"修复+具体问题"格式
    - **重构Task**: 使用"重构+模块名+原因"格式
  </guideline>
  
  <rule>
    1. **编号连续性强制**
       - 同层级编号必须连续，不允许跳号
       - 删除工作项时编号不重用，保持历史追溯
       - 新增工作项使用下一个可用编号
    
    2. **命名格式强制**
       - Epic/Feature/Story/Task前缀必须使用
       - 编号格式严格按照X.Y.Z.N模式
       - Story必须包含"能够"关键词
       - Task必须包含动作动词
    
    3. **长度限制规则**
       - Epic标题不超过20个字符
       - Feature标题不超过30个字符
       - Story标题不超过50个字符
       - Task标题不超过40个字符
    
    4. **语义一致性规则**
       - 同Epic下Feature语义边界清晰不重叠
       - 同Feature下Story粒度一致
       - 标题与工作项实际内容保持一致
  </rule>
  
  <constraint>
    1. **工具平台限制**
       - 不同项目管理工具对标题长度有限制
       - 某些平台不支持特殊字符或表情符号
       - 编号格式需兼容排序和筛选功能
    
    2. **团队认知限制**
       - 新成员对编号体系的学习成本
       - 跨团队协作时的理解一致性
       - 国际化团队的语言统一性
    
    3. **历史遗留约束**
       - 已有项目的编号体系兼容性
       - 迁移过程中的重复编号处理
       - 历史数据的追溯完整性
  </constraint>
  
  <criteria>
    | 评价维度 | 优秀标准 | 合格标准 | 不合格标准 |
    |---------|---------|---------|-----------|
    | 编号规范性 | 完全符合X.Y.Z.N格式，无跳号 | 基本符合格式，偶有不规范 | 编号混乱或格式错误 |
    | 语义清晰度 | 标题一目了然，无歧义 | 标题基本清楚，少量模糊 | 标题含糊或表达不准确 |
    | 层级一致性 | 同层级粒度和表达方式统一 | 基本一致，个别项例外 | 层级混乱或不一致 |
    | 用户视角 | Story严格按用户故事格式 | Story基本符合用户视角 | Story缺少用户视角 |
    | 可搜索性 | 关键词明确，便于搜索筛选 | 关键词基本明确 | 关键词缺失或不明确 |
    | 长度适当性 | 符合长度限制且信息充分 | 长度可控，信息基本充分 | 过长或过短影响理解 |
  </criteria>
</execution>