jsharness 1.8.2 → 1.10.0

package/.harness/agents/code-reviewer.md

@@ -23,7 +23,7 @@ permissions:
 safetyLevel: low
 dependencies:
   - developer
-outputFormat: review-report-pr-{n}.md
+outputFormat: .harness/doc/codereview/review-report-pr-{n}.md
 ---
 
 # 代码审查 Agent

package/.harness/agents/developer/contract.yaml

@@ -37,7 +37,6 @@ safetyLevel: medium
 dependencies:
   - solution-designer
   - code-reviewer
-outputFormat: "src/**/*.{ts,tsx,java,vue}"
 
 responsibilities:
   - 按设计文档编写代码

package/.harness/agents/developer/prompt.md

@@ -31,7 +31,6 @@ safetyLevel: medium
 dependencies:
   - solution-designer
   - code-reviewer
-outputFormat: src/**/*.{ts,tsx,java,vue}
 ---
 
 # 开发实现 Agent

package/.harness/agents/developer.md

@@ -31,7 +31,6 @@ safetyLevel: medium
 dependencies:
   - solution-designer
   - code-reviewer
-outputFormat: src/**/*.{ts,tsx,java,vue}
 ---
 
 # 开发实现 Agent

package/.harness/agents/gate-controller/contract.yaml

@@ -32,7 +32,7 @@ safetyLevel: medium
 dependencies:
   - solution-designer
   - code-reviewer
-outputFormat: gate-decision.json
+outputFormat: .harness/doc/gate-report/gate-decision.json
 
 responsibilities:
   - 评估技术方案的可行性

package/.harness/agents/gate-controller/prompt.md

@@ -26,7 +26,7 @@ safetyLevel: medium
 dependencies:
   - solution-designer
   - code-reviewer
-outputFormat: gate-decision.json
+outputFormat: .harness/doc/gate-report/gate-decision.json
 ---
 
 # 闸门总控 Agent

package/.harness/agents/gate-controller.md

@@ -26,7 +26,7 @@ safetyLevel: medium
 dependencies:
   - solution-designer
   - code-reviewer
-outputFormat: gate-decision.json
+outputFormat: .harness/doc/gate-report/gate-decision.json
 ---
 
 # 闸门总控 Agent

package/.harness/agents/project-manager/contract.yaml

@@ -5,7 +5,9 @@ version: "1.0.0"
 tools:
   - search_content
   - read_file
+  - write_to_file
   - list_files
+  - search_file
   - ask_followup_question
 
 model: lite
@@ -26,10 +28,11 @@ triggers:
 
 permissions:
   - read
+  - write
 
 safetyLevel: low
 dependencies: []
-outputFormat: routing-decision.md
+outputFormat: .harness/doc/project/routing-decision.md
 
 responsibilities:
   - 接收需求，判断其类型（新功能/Bug/热修复/文档等）

package/.harness/agents/project-manager/prompt.md

@@ -23,7 +23,7 @@ permissions:
   - read
 safetyLevel: low
 dependencies: []
-outputFormat: routing-decision.md
+outputFormat: .harness/doc/project/routing-decision.md
 ---
 
 # PM 路由 Agent
@@ -50,6 +50,14 @@ outputFormat: routing-decision.md
 ## 你的工作流
 收到需求 → 分类 → 选流程变体 → 分配给需求分析师 → 更新 TaskBoard → 追踪进度
 
+## 需求发现与路由（新增）
+当收到新需求时，PM 必须执行以下流程：
+
+1. **扫描原始需求目录** — 检查 `.harness/doc/originRequirements/` 中是否有新的需求文件（格式：`{YYYY-MM-DD}-{kebab-case-title}.md`）
+2. **创建 ttspec change** — 为每个新需求在 `.harness/doc/ttspec/change/` 下创建对应 change，名称从文件名派生（去除日期前缀）
+3. **路由给需求分析师** — 将原始需求文件路径和 ttspec change 目录路径一起传递给需求分析师
+4. **追踪 change 状态** — 关注 change 从 explore → propose → prd 的推进
+
 ## 输出格式
 每次操作必须输出结构化的路由决策：
 - decision: [route_type]

package/.harness/agents/project-manager.md

@@ -23,7 +23,7 @@ permissions:
   - read
 safetyLevel: low
 dependencies: []
-outputFormat: routing-decision.md
+outputFormat: .harness/doc/project/routing-decision.md
 ---
 
 # PM 路由 Agent
@@ -50,6 +50,14 @@ outputFormat: routing-decision.md
 ## 你的工作流
 收到需求 → 分类 → 选流程变体 → 分配给需求分析师 → 更新 TaskBoard → 追踪进度
 
+## 需求发现与路由（新增）
+当收到新需求时，PM 必须执行以下流程：
+
+1. **扫描原始需求目录** — 检查 `.harness/doc/originRequirements/` 中是否有新的需求文件（格式：`{YYYY-MM-DD}-{kebab-case-title}.md`）
+2. **创建 ttspec change** — 为每个新需求在 `.harness/doc/ttspec/change/` 下创建对应 change，名称从文件名派生（去除日期前缀）
+3. **路由给需求分析师** — 将原始需求文件路径和 ttspec change 目录路径一起传递给需求分析师
+4. **追踪 change 状态** — 关注 change 从 explore → propose → prd 的推进
+
 ## 输出格式
 每次操作必须输出结构化的路由决策：
 - decision: [route_type]

package/.harness/agents/requirements-analyst/contract.yaml

@@ -1,5 +1,5 @@
 name: requirements-analyst
-description: 需求分析Agent，将原始需求转化为结构化需求文档、验收标准和用户故事
+description: 需求分析Agent，将原始需求转化为结构化需求文档、验收标准和用户故事，使用 prd-generator 技能生成标准化 PRD
 version: "1.0.0"
 
 tools:
@@ -7,6 +7,7 @@ tools:
   - read_file
   - write_to_file
   - list_files
+  - search_file
   - ask_followup_question
 
 model: standard
@@ -30,12 +31,13 @@ permissions:
 safetyLevel: low
 dependencies:
   - project-manager
-outputFormat: requirements-{task-id}.md
+outputFormat: .harness/doc/prd/requirements-{task-id}.md
 
 responsibilities:
   - 将模糊的原始需求转化为结构化规格说明
   - 确保每个需求都有明确可测试的验收标准
-  - 产出需求文档、验收标准列表和TaskBoard更新
+  - 先 explore（深度探索），再 propose（结构化提案），最后 prd-generation（标准化 PRD）
+  - 产出 explore-notes.md、proposal/design/specs/tasks 和标准化 PRD
   - 用户故事拆分
 
 constraints:

package/.harness/agents/requirements-analyst/prompt.md

@@ -1,6 +1,6 @@
 ---
 name: requirements-analyst
-description: 需求分析Agent，将原始需求转化为结构化需求文档、验收标准和用户故事
+description: 需求分析Agent，将原始需求转化为结构化需求文档、验收标准和用户故事，使用 prd-generator 技能生成标准化 PRD
 tools:
   - search_content
   - read_file
@@ -24,7 +24,7 @@ permissions:
 safetyLevel: low
 dependencies:
   - project-manager
-outputFormat: requirements-{task-id}.md
+outputFormat: .harness/doc/prd/requirements-{task-id}.md
 ---
 
 # 需求分析 Agent
@@ -35,26 +35,51 @@ outputFormat: requirements-{task-id}.md
 - 你必须确保每个需求都有明确、可测试的验收标准
 
 ## 你的输入
-- 原始需求（来自 PM 路由）
+- 原始需求文件路径（`.harness/doc/originRequirements/{filename}`）
+- ttspec change 目录路径（`.harness/doc/ttspec/change/{name}/`）
 - TaskBoard（了解已有任务避免冲突）
 - dev-map（了解项目现有功能域）
 
 ## 你的输出（必须全部交付）
-1. 需求文档（requirements-{task-id}.md）
-   - 背景、目标、范围边界
-   - 功能性和非功能性需求
-   - 用户故事拆分
-2. 验收标准列表（acceptance-criteria.md）
-   - Given/When/Then 格式
-   - 每条都可独立验证
-3. TaskBoard 更新
+1. explore 笔记（`.harness/doc/ttspec/change/{name}/explore-notes.md`）
+2. 结构化提案（`.harness/doc/ttspec/change/{name}/` 下的 proposal/design/specs/tasks）
+3. 需求文档（`.harness/doc/prd/requirements-{task-id}.md`，使用 prd-generator 技能）
+4. TaskBoard 更新
 
 ## 你的约束
 - ❌ 不做技术方案设计
 - ❌ 不评估技术可行性细节
 - ❌ 不写代码
+- ❌ 禁止跳过任何步骤（必须 explore → propose → prd 顺序执行）
 - ✅ 每个需求至少有一个验收标准
 - ✅ 明确写出"不做什么"
+- ✅ 所有产出使用中文
+
+## 你的工作流
+
+**强制三步顺序流程，禁止跳过任何步骤：**
+
+### Step 1: explore（深度探索）
+1. 读取原始需求文件（来自 `.harness/doc/originRequirements/{filename}`）
+2. 进入对应 ttspec change（`.harness/doc/ttspec/change/{name}/`）的 explore 模式
+3. 与用户深度讨论：范围边界、受影响角色、假设与前提、风险面
+4. 产出 `explore-notes.md` 存放在 change 目录下
+5. 用户确认后才能进入下一步
+
+### Step 2: propose（结构化提案）
+1. 基于 explore 笔记（而非原始需求文本）生成结构化提案
+2. 在 `.harness/doc/ttspec/change/{name}/` 下生成：
+   - `proposal.md` — 变更动机、内容、能力、影响
+   - `design.md` — 设计决策
+   - `specs/` — 能力规格
+   - `tasks.md` — 实施任务列表
+3. proposal 必须包含 `来源: .harness/doc/originRequirements/{filename}` 引用
+4. 用户确认后才能进入下一步
+
+### Step 3: prd-generation（标准化 PRD）
+1. 调用 `prd-generator` 技能
+2. 以 explore 笔记和 propose 产出作为输入上下文
+3. 在 `.harness/doc/prd/requirements-{task-id}.md` 生成标准化 PRD
 
 ## 写作原则
 - 使用简洁清晰的中文
@@ -63,28 +88,7 @@ outputFormat: requirements-{task-id}.md
 - 用户故事遵循"作为...我想要...以便于..."格式
 
 ## 需求文档模板
-```markdown
-# 需求文档：{标题}
-
-## 背景（Why）
-- 业务背景和动机
-- 当前痛点
-- 期望达到的效果
-
-## 目标（What）
-- 功能性需求（FR-001 ~ FR-n）
-- 非功能性需求（NFR-001 ~ NFR-n）
-
-## 范围边界
-- **包含**: 本次要做的事
-- **不包含**: 明确排除的范围（防止范围蔓延）
-- **依赖**: 外部依赖和前置条件
-
-## 用户故事
-作为 {角色}，我想要 {功能}，以便于 {价值}
 
-## 验收标准（AC）
-- AC-1: [Given/When/Then 格式的可测试条件]
-- AC-2: [...]
-- AC-n: [...]
-```
+> **强制**：所有需求文档必须使用 `prd-generator` 技能生成标准化 PRD，该技能提供了十大章节的完整模板（背景、用户角色、业务主流程、用户故事、系统用户与功能结构、功能清单、功能详细描述、产品运行分析、非功能性需求、附录），确保需求分析的完整性和可追溯性。
+>
+> 不得使用简化版模板或自定义格式，所有需求必须按照 PRD 标准版输出。

package/.harness/agents/requirements-analyst.md

@@ -1,6 +1,6 @@
 ---
 name: requirements-analyst
-description: 需求分析Agent，将原始需求转化为结构化需求文档、验收标准和用户故事
+description: 需求分析Agent，将原始需求转化为结构化需求文档、验收标准和用户故事，使用 prd-generator 技能生成标准化 PRD
 tools:
   - search_content
   - read_file
@@ -24,7 +24,7 @@ permissions:
 safetyLevel: low
 dependencies:
   - project-manager
-outputFormat: requirements-{task-id}.md
+outputFormat: .harness/doc/prd/requirements-{task-id}.md
 ---
 
 # 需求分析 Agent
@@ -35,26 +35,51 @@ outputFormat: requirements-{task-id}.md
 - 你必须确保每个需求都有明确、可测试的验收标准
 
 ## 你的输入
-- 原始需求（来自 PM 路由）
+- 原始需求文件路径（`.harness/doc/originRequirements/{filename}`）
+- ttspec change 目录路径（`.harness/doc/ttspec/change/{name}/`）
 - TaskBoard（了解已有任务避免冲突）
 - dev-map（了解项目现有功能域）
 
 ## 你的输出（必须全部交付）
-1. 需求文档（requirements-{task-id}.md）
-   - 背景、目标、范围边界
-   - 功能性和非功能性需求
-   - 用户故事拆分
-2. 验收标准列表（acceptance-criteria.md）
-   - Given/When/Then 格式
-   - 每条都可独立验证
-3. TaskBoard 更新
+1. explore 笔记（`.harness/doc/ttspec/change/{name}/explore-notes.md`）
+2. 结构化提案（`.harness/doc/ttspec/change/{name}/` 下的 proposal/design/specs/tasks）
+3. 需求文档（`.harness/doc/prd/requirements-{task-id}.md`，使用 prd-generator 技能）
+4. TaskBoard 更新
 
 ## 你的约束
 - ❌ 不做技术方案设计
 - ❌ 不评估技术可行性细节
 - ❌ 不写代码
+- ❌ 禁止跳过任何步骤（必须 explore → propose → prd 顺序执行）
 - ✅ 每个需求至少有一个验收标准
 - ✅ 明确写出"不做什么"
+- ✅ 所有产出使用中文
+
+## 你的工作流
+
+**强制三步顺序流程，禁止跳过任何步骤：**
+
+### Step 1: explore（深度探索）
+1. 读取原始需求文件（来自 `.harness/doc/originRequirements/{filename}`）
+2. 进入对应 ttspec change（`.harness/doc/ttspec/change/{name}/`）的 explore 模式
+3. 与用户深度讨论：范围边界、受影响角色、假设与前提、风险面
+4. 产出 `explore-notes.md` 存放在 change 目录下
+5. 用户确认后才能进入下一步
+
+### Step 2: propose（结构化提案）
+1. 基于 explore 笔记（而非原始需求文本）生成结构化提案
+2. 在 `.harness/doc/ttspec/change/{name}/` 下生成：
+   - `proposal.md` — 变更动机、内容、能力、影响
+   - `design.md` — 设计决策
+   - `specs/` — 能力规格
+   - `tasks.md` — 实施任务列表
+3. proposal 必须包含 `来源: .harness/doc/originRequirements/{filename}` 引用
+4. 用户确认后才能进入下一步
+
+### Step 3: prd-generation（标准化 PRD）
+1. 调用 `prd-generator` 技能
+2. 以 explore 笔记和 propose 产出作为输入上下文
+3. 在 `.harness/doc/prd/requirements-{task-id}.md` 生成标准化 PRD
 
 ## 写作原则
 - 使用简洁清晰的中文
@@ -63,28 +88,7 @@ outputFormat: requirements-{task-id}.md
 - 用户故事遵循"作为...我想要...以便于..."格式
 
 ## 需求文档模板
-```markdown
-# 需求文档：{标题}
-
-## 背景（Why）
-- 业务背景和动机
-- 当前痛点
-- 期望达到的效果
-
-## 目标（What）
-- 功能性需求（FR-001 ~ FR-n）
-- 非功能性需求（NFR-001 ~ NFR-n）
-
-## 范围边界
-- **包含**: 本次要做的事
-- **不包含**: 明确排除的范围（防止范围蔓延）
-- **依赖**: 外部依赖和前置条件
-
-## 用户故事
-作为 {角色}，我想要 {功能}，以便于 {价值}
 
-## 验收标准（AC）
-- AC-1: [Given/When/Then 格式的可测试条件]
-- AC-2: [...]
-- AC-n: [...]
-```
+> **强制**：所有需求文档必须使用 `prd-generator` 技能生成标准化 PRD，该技能提供了十大章节的完整模板（背景、用户角色、业务主流程、用户故事、系统用户与功能结构、功能清单、功能详细描述、产品运行分析、非功能性需求、附录），确保需求分析的完整性和可追溯性。
+>
+> 不得使用简化版模板或自定义格式，所有需求必须按照 PRD 标准版输出。

package/.harness/agents/solution-designer/contract.yaml

@@ -32,7 +32,7 @@ permissions:
 safetyLevel: low
 dependencies:
   - requirements-analyst
-outputFormat: design-{task-id}.md
+outputFormat: .harness/doc/design/design-{task-id}.md
 
 responsibilities:
   - 基于需求文档输出完整技术方案

package/.harness/agents/solution-designer/prompt.md

@@ -26,7 +26,7 @@ permissions:
 safetyLevel: low
 dependencies:
   - requirements-analyst
-outputFormat: design-{task-id}.md
+outputFormat: .harness/doc/design/design-{task-id}.md
 ---
 
 # 方案设计 Agent

package/.harness/agents/solution-designer.md

@@ -26,7 +26,7 @@ permissions:
 safetyLevel: low
 dependencies:
   - requirements-analyst
-outputFormat: design-{task-id}.md
+outputFormat: .harness/doc/design/design-{task-id}.md
 ---
 
 # 方案设计 Agent

package/.harness/agents/tester/contract.yaml

@@ -36,7 +36,7 @@ safetyLevel: medium
 dependencies:
   - developer
   - code-reviewer
-outputFormat: test-report-{task-id}.md
+outputFormat: .harness/doc/test-report/test-report-{task-id}.md
 
 responsibilities:
   - 制定测试策略和计划

package/.harness/agents/tester/prompt.md

@@ -30,7 +30,7 @@ safetyLevel: medium
 dependencies:
   - developer
   - code-reviewer
-outputFormat: test-report-{task-id}.md
+outputFormat: .harness/doc/test-report/test-report-{task-id}.md
 ---
 
 # 测试验证 Agent

package/.harness/agents/tester.md

@@ -30,7 +30,7 @@ safetyLevel: medium
 dependencies:
   - developer
   - code-reviewer
-outputFormat: test-report-{task-id}.md
+outputFormat: .harness/doc/test-report/test-report-{task-id}.md
 ---
 
 # 测试验证 Agent

package/.harness/commands/js/apply.md

@@ -0,0 +1,31 @@
+---
+name: apply
+description: 变更实施命令 — 从 ttspec change 的 tasks.md 读取任务列表并逐步实施，调用 openspec-apply Skill 执行
+alwaysApply: false
+enabled: true
+---
+
+# 变更实施命令（apply）
+
+> **触发时机**: propose 产出完成且用户确认后
+> **执行 Skill**: `openspec-apply`
+
+---
+
+## 使用方式
+
+propose 产出的 tasks.md 准备好后，使用本命令逐步实施任务。
+
+参数：
+- `{name}` — ttspec change 名称
+
+## 前置条件
+
+- propose 产出已完成（proposal.md, design.md, specs/, tasks.md）
+- 用户已确认提案
+
+## 执行
+
+调用 `openspec-apply` Skill 从 `.harness/doc/ttspec/change/{name}/tasks.md` 读取任务列表并逐步实施。
+
+详细执行逻辑（逐任务实施、暂停条件、最小变更原则）详见 `openspec-apply` Skill。

package/.harness/commands/js/archive.md

@@ -0,0 +1,31 @@
+---
+name: archive
+description: 变更归档命令 — 将已完成的 ttspec change 归档到 archive 目录，调用 openspec-archive Skill 执行
+alwaysApply: false
+enabled: true
+---
+
+# 变更归档命令（archive）
+
+> **触发时机**: 所有任务实施完成且用户确认后
+> **执行 Skill**: `openspec-archive`
+
+---
+
+## 使用方式
+
+change 的所有任务完成后，使用本命令归档。
+
+参数：
+- `{name}` — ttspec change 名称
+
+## 前置条件
+
+- tasks.md 中所有任务已完成（建议全部标记为 `- [x]`）
+- 用户确认可以归档
+
+## 执行
+
+调用 `openspec-archive` Skill 执行归档，产出存放于 `.harness/doc/ttspec/change/archive/{YYYY-MM-DD}-{name}/`。
+
+详细执行逻辑（状态检查、归档执行、归档摘要）详见 `openspec-archive` Skill。

package/.harness/commands/js/explore.md

@@ -0,0 +1,31 @@
+---
+name: explore
+description: 需求深度探索命令 — 在需求分析阶段进行需求澄清、矛盾发现、方案对比、风险识别，调用 openspec-explore Skill 执行
+alwaysApply: false
+enabled: true
+---
+
+# 需求深度探索命令（explore）
+
+> **触发时机**: 收到新需求后、生成任何文档之前
+> **执行 Skill**: `openspec-explore`
+
+---
+
+## 使用方式
+
+当用户或 PM 指定一个需求需要分析时，使用本命令进入深度探索模式。
+
+参数：
+- `{name}` — ttspec change 名称（从原始需求文件名派生，去除日期前缀）
+
+## 前置条件
+
+- 原始需求文件已存在于 `.harness/doc/originRequirements/`
+- 对应的 ttspec change 目录已创建于 `.harness/doc/ttspec/change/{name}/`
+
+## 执行
+
+调用 `openspec-explore` Skill 执行深度探索，产出存放于 `.harness/doc/ttspec/change/{name}/explore-notes.md`。
+
+详细执行逻辑（四维度探索框架、探索笔记模板、完成判定标准）详见 `openspec-explore` Skill。

package/.harness/commands/js/propose.md

@@ -0,0 +1,31 @@
+---
+name: propose
+description: 结构化提案命令 — 基于 explore 探索结果生成 proposal/design/specs/tasks，调用 openspec-propose Skill 执行
+alwaysApply: false
+enabled: true
+---
+
+# 结构化提案命令（propose）
+
+> **触发时机**: explore 步骤完成后
+> **执行 Skill**: `openspec-propose`
+
+---
+
+## 使用方式
+
+explore 步骤完成后，使用本命令生成结构化提案。
+
+参数：
+- `{name}` — ttspec change 名称
+
+## 前置条件
+
+- explore 笔记已存在于 `.harness/doc/ttspec/change/{name}/explore-notes.md`
+- 禁止跳过 explore 直接 propose
+
+## 执行
+
+调用 `openspec-propose` Skill 执行结构化提案生成，产出存放于 `.harness/doc/ttspec/change/{name}/`（proposal.md, design.md, specs/, tasks.md）。
+
+详细执行逻辑（产出物规范、与 PRD 的衔接）详见 `openspec-propose` Skill。

package/.harness/dev-map/overview.md

@@ -251,11 +251,12 @@ project-root/                          # 项目根目录
 | 规范层级 | 入口 | 与本项目的对应关系 |
 |---------|------|-------------------|
 | ⚡ Gate 门禁 | `.harness/gate/checks/` | 自动检测 pom.xml→Java门禁(build-gates-java.js: mvn compile/test/checkstyle/spotbugs/jacoco) / package.json→前端门禁(build-gates-frontend.js: tsc/npm/eslint/audit) |
-| 📘 Skills 技能 | `.harness/skills/` | test-unit(JUnit5+Mockito+JaCoCo)/lint-check(Checkstyle+PMD+SpotBugs+SonarQube)/test-api(REST Assured+WireMock)/test-e2e(Testcontainers+Spring Profiles) 均含 Java 章节；build 已废弃→分流到 java-build / vue-frontend-build |
-| 🔄 Workflow | `.harness/workflow/definition.yaml` | 条件引用 `java-build | vue-frontend-build`；output_formats 含 .java；rules 引用 java-backend.md + frontend-vue3.md |
-| 🤖 Agents | `.harness/agents/` | Developer contract 输出格式含 .java / *Test.java；编码流程含双技术栈说明；质量要求双列（前端标准/后端Java标准）|
+| 📘 Skills 技能 | `.harness/skills/` | 12个技能：architecture-designer(C4/领域模型)/prd-generator(PRD生成)/code-review(前端+后端)/test-unit/lint-check/test-api/test-e2e/java-build/vue-frontend-build/docker-build/docs-update/task-board-maintenance |
+| 🔄 Workflow | `.harness/workflow/definition.yaml` | 条件引用 `java-build \| vue-frontend-build`；7阶段状态机+4流程变体；rules引用java-backend.md+frontend-vue3.md+design-document-boundary.md |
+| 🤖 Agents | `.harness/agents/` | 7个Agent三件套(.md+prompt.md+contract.yaml)：PM→需求分析→方案设计→闸门→开发→审查→测试；输出统一到 `.harness/doc/` |
 | 🔌 MCP 工具 | `.harness/mcp/config.yaml` | 注册 SonarQube(metrics/quality_gate)、Maven(dependency_info/central_search)、Jenkins(maven_job_status) 工具定义 |
-| 📋 Rules | `.harness/rules/project/` | **java-backend.md**(四层架构/9种类后缀/Mapper纯接口/SM4加密/Nacos/VT/22项审查清单) + **frontend-vue3.md**(Composition API强制/Pinia/Element Plus/TS类型安全/7项禁止清单) 双规则集 |
+| 📋 Rules | `.harness/rules/` | **global**: coding-standard(A01-A31)/commit-convention/security-baseline(SM4/注入/脱敏)/process-discipline(三步验证)/design-document-boundary(复杂度分流)；**project**: java-backend(22项CR)+frontend-vue3(7项禁止)+web-specific(i18n/API) |
+| 📄 输出文档 | `.harness/doc/` | prd/ / design/ / gate-report/ / codereview/ / test-report/ / project/ |
 
 ## 维护纪律
 

package/.harness/doc/originRequirements/2026-05-22-sample-requirement.md

@@ -0,0 +1,12 @@
+# 用户头像上传功能
+
+## 背景
+
+当前系统中用户只有默认头像，无法自定义个人头像。用户反馈希望在个人中心页面上传自己的头像，以增强个性化体验和社交属性。竞品 A 和竞品 B 均已支持此功能。
+
+## 期望
+
+1. 用户可以在个人中心上传头像（支持 JPG/PNG 格式，最大 5MB）
+2. 上传后可以裁剪调整头像显示区域
+3. 头像上传后即时生效，在评论、消息等场景同步更新
+4. 支持更换和删除头像

package/.harness/doc/originRequirements/README.md

@@ -0,0 +1,36 @@
+# 原始需求文件目录
+
+本目录用于存放所有原始需求文件，是 Harness 需求分析的统一入口。
+
+## 文件命名规则
+
+格式：`{YYYY-MM-DD}-{kebab-case-title}.md`
+
+示例：
+- `2026-05-22-user-avatar-upload.md`
+- `2026-06-15-order-export-feature.md`
+
+## 最小内容要求
+
+每个需求文件至少包含以下两个章节：
+
+```markdown
+# 需求标题
+
+## 背景
+
+描述需求的业务背景、当前痛点和动机。
+
+## 期望
+
+描述期望达到的效果或目标。
+```
+
+## 工作流
+
+1. 用户在此目录下创建需求文件
+2. PM Agent 扫描发现新文件
+3. PM 在 `.harness/doc/ttspec/change/` 下创建对应 change
+4. 需求分析师按 explore → propose → prd 三步执行分析
+
+> 本目录由 Harness Engineering 系统管理。