@geeseeker/easyai-dev 3.0.3 → 3.0.5

package/skeleton/.agents/skills/pm-framework-evolve/resources/changelog-entry-template.md

@@ -0,0 +1,43 @@
+# 迭代记录模板
+
+> 使用本模板为每次框架迭代生成标准化记录。
+
+## 基本信息
+
+- **日期**：{YYYY-MM-DD}
+- **类型**：{新增 / 优化 / 修复 / 修改 / 魔改 / 实验性}
+- **摘要**：{一句话描述本次变更}
+
+## 涉及文件
+
+| 文件 | 变更类型 | 说明 |
+|------|----------|------|
+| {文件路径} | {新建/修改/删除} | {变更摘要} |
+
+## 变更说明
+
+{详细描述本次变更的目的、实现方式和关键决策}
+
+## 关键 Diff
+
+```diff
+{粘贴关键代码变更的 diff}
+```
+
+## 影响范围
+
+- **关联角色**：{PM / Worker / 无}
+- **关联 Skills**：{受影响的 Skills}
+- **风险等级**：{低 / 中 / 高}
+
+## 回滚步骤
+
+{如果需要撤销本次变更，按以下步骤操作：}
+
+1. {步骤 1}
+2. {步骤 2}
+
+## 兼容性声明
+
+- [ ] 兼容框架源版本（未改变框架契约）
+- [ ] **不兼容**框架源版本（已改变框架契约，属于"魔改"级别）

package/skeleton/.agents/skills/pm-task-review/SKILL.md

@@ -1,9 +1,9 @@
 ---
 name: pm-task-review
-description: PM 任务验收 — 双阶段验收流程（Stage 1 Spec 合规 → Stage 2 代码质量）。PM 审查执行者完成的任务时激活。
+description: PM 任务验收 — 三阶段验收流程（Stage 1 Spec 合规 → Stage 2 代码质量 → Stage 3 Artifacts 沉淀）。PM 审查执行者完成的任务时激活。
 ---
 
-# PM 任务验收（双阶段）
+# PM 任务验收（三阶段）
 
 ## 适用场景
 
@@ -11,7 +11,7 @@ PM 审查执行者提交验收的任务时，**必须**激活本 Skill。
 
 ## 验收原则
 
-- **双阶段不可颠倒**：必须先 Spec 合规，再代码质量
+- **三阶段不可颠倒**：必须先 Spec 合规，再代码质量，最后 Artifacts 沉淀
 - **Stage 1 不过不进 Stage 2**：节省审查时间，避免在不合规产出上花费精力
 - **公正客观**：基于证据而非印象
 
@@ -81,8 +81,7 @@ PM 审查执行者提交验收的任务时，**必须**激活本 Skill。
 
 ### Stage 2 判定
 
-- **全部通过** → 验收通过
-  - 调用 `task_transition({ task_id, new_status: "completed", role: "pm" })`
+- **全部通过** → 进入 Stage 3（Artifacts 沉淀）
 - **存在问题** → 打回并附带具体改进建议
   - 问题分级：Critical（必须修复）/ Important（建议修复）/ Minor（可后续优化）
   - 调用 `task_transition({ task_id, new_status: "rejected", role: "pm" })`
@@ -100,6 +99,44 @@ PM 审查执行者提交验收的任务时，**必须**激活本 Skill。
 2. 如审查者正确 → 接受建议并修改
 3. 如坚持原方案 → 提供完整技术论证（非"我觉得没问题"）
 
+## Stage 3：Artifacts 沉淀
+
+> 本质：PM 作为"策展人"，将 Worker 会话产生的面向用户的 Artifacts 沉淀到 `.docs/`（持久文档空间）。
+
+### 执行步骤
+
+1. **扫描 Worker Artifacts**
+   - 检查 Worker 会话产生的 Artifacts（特别是 `walkthrough.md`）
+   - 识别面向用户的内容（排除 `task.md` 等过程性文件）
+
+2. **判断沉淀价值**
+   - 内容是否对用户有持续参考价值？
+   - 沉淀目标判断：
+
+   | Artifacts 类型 | 沉淀目标 | 判断依据 |
+   |----------------|----------|----------|
+   | `walkthrough.md` | `.docs/notes/`（临时参考）或 `.docs/guides/`（永久指南） | 是否有长期复用价值 |
+   | `other`（分析报告等） | `.docs/notes/` 或 `.docs/design/` | 内容属于设计还是参考 |
+   | `task.md` | 不沉淀 | `.trellis/tasks/` 已持久化 |
+   | `implementation_plan.md` | 不沉淀 | `pm-brainstorm` Step 6 已负责 |
+
+3. **向用户确认**
+   - 列出候选沉淀内容，说明建议的目标路径
+   - **用户确认后**才执行沉淀（不自动沉淀）
+
+4. **执行沉淀**
+   - 提炼内容（去除过程性细节，保留用户关心的结论和指导）
+   - 写入目标路径
+   - 向用户说明沉淀了什么、沉淀到了哪里
+
+5. **标记任务完成**
+   - 调用 `task_transition({ task_id, new_status: "completed", role: "pm" })`
+
+### Stage 3 判定
+
+- **有内容沉淀** → 确认沉淀完成后标记 `completed`
+- **无需沉淀** → 直接标记 `completed`
+
 ## 验收结果输出
 
 ```markdown
@@ -119,6 +156,10 @@ PM 审查执行者提交验收的任务时，**必须**激活本 Skill。
 
 {审查发现}
 
+### Stage 3: Artifacts 沉淀 — {已沉淀/无需沉淀}
+
+{沉淀内容及目标路径，或无需沉淀的原因}
+
 ### 最终判定：{通过 / 打回}
 
 {如果打回，列出具体修改要求}
@@ -129,10 +170,11 @@ PM 审查执行者提交验收的任务时，**必须**激活本 Skill。
 ```markdown
 ### 下一步行动
 
-1. [ ] 如果通过 → 调用 `task_transition({ task_id, new_status: "completed", role: "pm" })` 标记完成
-2. [ ] 如果通过 → 确认是否需要归档（`task_transition({ task_id, new_status: "archived", role: "pm" })`）
-3. [ ] 如果打回 → 在 task.md 追加打回原因和修复建议
-4. [ ] 如果打回 → 通知用户开新会话执行 `/worker {task_id}` 继续修复
+1. [ ] 如果通过 → 确认 Artifacts 是否需要沉淀到 `.docs/`
+2. [ ] 如果通过 → 调用 `task_transition({ task_id, new_status: "completed", role: "pm" })` 标记完成
+3. [ ] 如果通过 → 确认是否需要归档（`task_transition({ task_id, new_status: "archived", role: "pm" })`）
+4. [ ] 如果打回 → 在 task.md 追加打回原因和修复建议
+5. [ ] 如果打回 → 通知用户开新会话执行 `/worker {task_id}` 继续修复
 
 ### 状态快照
 
@@ -140,5 +182,6 @@ PM 审查执行者提交验收的任务时，**必须**激活本 Skill。
 - 当前阶段：REVIEW
 - Stage 1: {PASS/FAIL}
 - Stage 2: {PASS/FAIL/未进入}
+- Stage 3: {已沉淀/无需沉淀/未进入}
 - 最终判定：{通过/打回/审查中}
 ```

package/skeleton/.docs/README.md

@@ -10,7 +10,7 @@
 | `design/` | AI ↔ 用户 | 架构设计、技术方案 |
 | `guides/` | AI → 用户 | 使用指南、部署文档 |
 | `notes/` | 用户 ↔ AI | 临时文档（使用后归档） |
-| `archive/` | 归档 | 已完成/不再需要的文档 |
+| `archive/` | 归档 | 各文件夹中作废、迭代后不再适配的历史文档 |
 
 ## 信息流
 

package/skeleton/.agents/skills/common-framework-evolve/SKILL.md

@@ -1,105 +0,0 @@
----
-name: common-framework-evolve
-description: 框架自迭代 — 安全地修改 .agents/ 和 .trellis/spec/ 下的框架文件，包含影响范围分析、变更清单、用户确认门。修改框架核心文件时由 AI 自主激活。
----
-
-# 框架自迭代
-
-## 适用场景
-
-当需要修改以下 **框架核心目录** 时，必须通过本 Skill 执行：
-
-- `.agents/rules/` — 规则文件
-- `.agents/workflows/` — 角色入口
-- `.agents/skills/` — 能力模块
-- `.trellis/spec/` — 项目规范（此部分也可通过 `common-spec-update` Skill 处理）
-- `.trellis/config/` — 框架配置
-
-> **注意**：`.trellis/tasks/` 和 `.trellis/workspace/` 属于运行时数据，不受本 Skill 管控。
-
-## 执行步骤
-
-### 1. 变更清单
-
-列出所有将要修改的文件及变更类型：
-
-```markdown
-## 框架变更清单
-
-| 文件                        | 变更类型 | 变更摘要      |
-| --------------------------- | -------- | ------------- |
-| .agents/rules/xxx.md        | 修改     | 增加 xxx 约束 |
-| .agents/skills/yyy/SKILL.md | 新建     | yyy 能力模块  |
-```
-
-### 2. 影响范围分析
-
-分析变更的影响链：
-
-```markdown
-## 影响范围报告
-
-### 直接影响
-
-- 变更文件数：{n} 个
-- 变更类型：新建 / 修改 / 删除
-
-### 间接影响
-
-- 关联角色：{受影响的 PM / Worker 角色行为变更}
-- 关联 Skills：{依赖受影响文件的其他 Skills}
-- 约束层级：{是否影响约束优先级体系}
-
-### 风险等级
-
-- 低：仅新增能力，不影响现有行为
-- 中：修改已有文件，可能影响角色行为
-- 高：修改 Rules 或核心 Workflow，影响所有会话
-```
-
-### 3. 用户确认门
-
-将变更清单和影响范围报告呈现给用户，**等待明确确认后才执行写入**。
-
-**用户确认后**：
-
-1. 逐步执行变更
-2. 每步完成后验证文件完整性
-3. 通过 `journal_append()` 记录变更日志
-
-**用户拒绝**：
-
-- 放弃全部变更，保持原文件不动
-- 记录拒绝原因到 journal
-
-### 4. 变更后验证
-
-- 检查修改后的文件是否格式完整、语法正确
-- 如涉及 MCP Server 代码，确保 `npm run build` 通过
-
-## PATEOAS 输出
-
-每次框架变更完成后，必须输出：
-
-```markdown
-### PATEOAS 导航
-
-#### 下一步行动
-
-1. [ ] 运行 `npm run build` 验证 MCP Server 构建通过（如涉及代码变更）
-2. [ ] 使用 `/pm` 或 `/worker {task_id}` 继续后续任务
-
-#### 状态快照
-
-- 当前阶段：FRAMEWORK_EVOLVE
-- 变更状态：已应用 / 已拒绝
-- 变更文件数：{n} 个
-- 风险等级：{低/中/高}
-- 需要验证：{是/否}
-```
-
-## 硬约束
-
-- **必须经用户确认门**：禁止绕过确认直接修改框架文件
-- **必须留 journal 记录**：每次框架变更（成功或拒绝）都必须记录
-- **不可批量盲改**：每个文件的变更理由必须明确，禁止"顺便改一下"