@feng-h/pdca-skill 1.0.0

package/assets/tests/integration-test-scenarios.md

@@ -0,0 +1,296 @@
+# GREEN 集成测试 - PDCA Skill
+
+## 测试目标
+
+验证 PDCA skill 加载后的**端到端集成功能**，确保各组件协同工作正常。
+
+---
+
+## 场景 1：新项目创建与自动任务生成
+
+**测试类型：** 任务自动生成集成
+
+**前置条件：**
+- 用户运行 `pdca new` 命令
+- 选择 TREND 框架进行健康/体能类项目
+- 完成问题分析（5Why 验证通过）
+
+### 测试步骤
+
+1. **问题分析完成检测**
+   - 系统检测到问题分析文档完成
+   - 确认 TREND 框架已选择
+   - 确认根本原因已通过 5Why 验证
+
+2. **触发任务自动生成**
+   - PlanAgent 调用任务自动生成器
+   - AI 提取问题要素（症状、影响、历史）
+
+3. **按维度生成任务**
+   - 根据 TREND 框架的 5 个维度拆解
+   - 每个维度生成 1-3 个具体任务
+   - 预期生成 5-15 个任务
+
+4. **写入 Bitable 任务表**
+   - 批量创建任务记录
+   - 验证每个任务的 `来源维度` 字段对应 TREND 维度
+   - 验证每个任务的 `来源类型` 为 "问题分析生成"
+
+5. **同步创建飞书 Task**
+   - 串行调用 `feishu_task_task.create`
+   - 验证任务标题格式：`[项目简称] T[序号] 任务标题`
+
+6. **关联飞书 Task ID**
+   - 创建成功后获取 `task_id`
+   - 更新 Bitable 任务的 `飞书任务ID` 字段
+
+### 预期结果
+
+- ✅ Bitable 任务表中生成 5-15 条任务记录
+- ✅ 所有 5 个 TREND 维度都有对应任务（训练、休息、营养、先天、日常）
+- ✅ 所有任务的 `来源类型` 为 "问题分析生成"
+- ✅ 所有任务都成功创建飞书 Task
+- ✅ 所有 Bitable 任务的 `飞书任务ID` 字段已填充
+
+### 失败条件
+
+- ❌ 生成的任务数量 < 5 或 > 15
+- ❌ 某些维度没有对应任务
+- ❌ 飞书 Task 创建失败且未记录
+- ❌ Bitable 写入格式错误
+
+---
+
+## 场景 2：智能巡检频率动态调整
+
+**测试类型：** Cron 任务动态更新
+
+**前置条件：**
+- 项目处于 Do 阶段
+- 项目优先级为 "高"
+- 距离截止日期剩余时间 < 10%
+
+### 测试步骤
+
+1. **读取基线频率**
+   - 项目使用 TREND 框架
+   - 验证基线频率为每日 1 次（`0 9 * * *`）
+
+2. **计算动态调整因子**
+   - 阶段因子：Do 阶段 ×1.5
+   - 紧迫度因子：高优先级 ×2
+   - 时间因子：剩余时间 < 10% ×2
+
+3. **计算最终频率**
+   - 基线：每日 1 次
+   - 调整后：1 × 1.5 × 2 × 2 = 6 次/天
+   - 验证频率表达式（约每 4 小时 1 次）
+
+4. **更新 Cron 任务**
+   - 删除旧巡检 Cron
+   - 创建新频率的 Cron
+   - 验证 `workspace/pdca-projects.json` 中 `cronJobs` 已更新
+
+### 预期结果
+
+- ✅ 频率计算公式正确应用
+- ✅ 最终频率约为每 4 小时 1 次
+- ✅ 旧 Cron 任务已删除
+- ✅ 新 Cron 任务已创建并生效
+- ✅ 项目状态文件中 jobId 已更新
+
+### 失败条件
+
+- ❌ 频率计算错误
+- ❌ Cron 任务未更新
+- ❌ 出现重复的 Cron 任务
+
+---
+
+## 场景 3：仪表板自动更新
+
+**测试类型：** Wiki + Bitable 数据同步
+
+**前置条件：**
+- 项目有任务完成记录
+- 项目有新增的数据收集记录
+- 巡检 Cron 任务触发
+
+### 测试步骤
+
+1. **Cron 触发巡检**
+   - 巡检任务按设定频率执行
+   - 获取所有 "进行中" 状态的项目
+
+2. **读取 Bitable 数据**
+   - 从项目主表读取基本信息
+   - 从任务表读取任务完成情况
+   - 从 data_records 表读取最新数据
+
+3. **生成仪表板内容**
+   - 调用仪表板生成器
+   - 计算核心指标（完成度、进度等）
+   - 生成 AI 洞察摘要
+
+4. **更新 Wiki 仪表板页面**
+   - 调用 `feishu_doc_update`
+   - 写入最新仪表板内容
+   - 包含时间戳
+
+5. **验证数据一致性**
+   - Wiki 仪表板显示的数据与 Bitable 一致
+   - 时间戳为当前时间
+   - 图表包含最新数据点
+
+### 预期结果
+
+- ✅ 仪表板内容反映 Bitable 最新数据
+- ✅ 核心指标计算正确
+- ✅ AI 洞察与数据一致
+- ✅ Wiki 页面更新成功
+- ✅ 时间戳为当前巡检时间
+
+### 失败条件
+
+- ❌ 仪表板数据与 Bitable 不一致
+- ❌ Wiki 更新失败
+- ❌ 时间戳未更新
+
+---
+
+## 场景 4：表单数据收集与趋势图更新
+
+**测试类型：** 数据收集集成
+
+**前置条件：**
+- 项目使用 TREND 框架
+- data_records 表已创建
+- 已配置体重追踪表单
+
+### 测试步骤
+
+1. **用户填写表单**
+   - 用户通过飞书表单提交数据
+   - 数据：体重 = 75kg，日期 = 2026-04-04
+
+2. **数据写入 Bitable**
+   - 调用 `feishu_bitable_app_table_record.create`
+   - 写入 data_records 表
+   - 验证字段：记录ID、项目ID、指标名称、数值、单位、记录时间、记录人
+
+3. **下次巡检触发**
+   - 巡检任务按频率执行
+   - 读取 data_records 表最新数据
+
+4. **生成趋势图**
+   - 仪表板生成器读取历史数据
+   - 生成体重变化趋势图
+   - 验证新数据点包含在图表中
+
+5. **更新仪表板**
+   - Wiki 仪表板显示最新趋势图
+   - 包含新提交的数据点
+
+### 预期结果
+
+- ✅ 表单数据正确写入 data_records 表
+- ✅ 数值、单位、时间等字段完整
+- ✅ 趋势图包含最新数据点
+- ✅ 仪表板显示更新后的趋势
+
+### 失败条件
+
+- ❌ 数据写入失败或格式错误
+- ❌ 趋势图未包含新数据
+- ❌ 仪表板未更新
+
+---
+
+## 场景 5：项目完成与资源清理
+
+**测试类型：** 项目生命周期终止
+
+**前置条件：**
+- Act 阶段已完成
+- 用户确认项目结束
+- 项目状态为 "待结项"
+
+### 测试步骤
+
+1. **用户确认项目结束**
+   - 用户通过飞书交互卡片确认
+   - 系统收到结项指令
+
+2. **更新 Bitable 项目状态**
+   - 调用 `feishu_bitable_app_table_record.update`
+   - 将项目主表 `状态` 字段更新为 "已完成"
+   - 将 `当前阶段` 更新为 "已完成"
+   - 更新 `完成度` 为 100
+
+3. **删除所有关联 Cron 任务**
+   - 读取项目的 `cronJobs` 列表
+   - 逐个调用 `cron delete` 删除
+   - 验证所有任务已删除
+
+4. **验证资源清理**
+   - 查询 `workspace/pdca-projects.json`
+   - 确认项目 `status` 为 "已完成"
+   - 确认 `cronJobs` 数组为空
+
+5. **生成项目总结**
+   - 从 Wiki 收集所有阶段文档
+   - 生成项目总结报告
+   - 写入经验库
+
+### 预期结果
+
+- ✅ Bitable 项目状态更新为 "已完成"
+- ✅ 所有 Cron 任务已删除
+- ✅ 项目状态文件正确更新
+- ✅ 无残留 Cron 任务
+- ✅ 项目总结已生成
+
+### 失败条件
+
+- ❌ 项目状态未更新
+- ❌ Cron 任务未完全删除
+- ❌ 状态文件未同步
+- ❌ 残留 Cron 任务仍在执行
+
+---
+
+## 测试方法
+
+### 测试环境要求
+
+1. **飞书环境**
+   - 有效的飞书测试空间
+   - 已配置的 Bitable 应用
+   - 已配置的 Wiki 空间
+
+2. **本地环境**
+   - `workspace/pdca-projects.json` 文件
+   - PDCA skill 已加载
+   - Cron 服务可用
+
+### 执行方式
+
+使用 Agent 工具创建**加载 pdca skill** 的 subagent，按场景执行测试。
+
+### 测试记录模板
+
+| 场景 | 执行时间 | 结果 | 问题描述 | 备注 |
+|------|---------|------|---------|------|
+| 场景1 | | PASS/FAIL | | |
+| 场景2 | | PASS/FAIL | | |
+| 场景3 | | PASS/FAIL | | |
+| 场景4 | | PASS/FAIL | | |
+| 场景5 | | PASS/FAIL | | |
+
+---
+
+## 版本历史
+
+| 版本 | 日期 | 变更说明 |
+|------|------|---------|
+| v1.0 | 2026-04-04 | 初始版本，定义 5 个集成测试场景 |

package/assets/tests/tdd-baseline-test-scenarios.md

@@ -0,0 +1,164 @@
+# PDCA Skill 全面基线测试 - TDD RED Phase
+
+## 测试目标
+
+遵循 superpowers:writing-skills 的 TDD 方法论，在**没有加载 pdca skill**的情况下测试 Agent 基线行为，识别需要 skill 解决的问题模式。
+
+---
+
+## 测试场景设计
+
+### 场景 1：框架选择一致性测试
+
+**压力类型**：框架选择 + 跨阶段一致性
+
+**用户输入**：
+> 我要做一个个人 VO2max 提升项目。我的目标是把 VO2max 从 35 提升到 45 ml/kg/min。
+
+**Plan 阶段测试**：
+- Agent 是否正确选择 TREND 框架？
+- 是否逐维度分析（Training/Rest/Eating/Nature/Daily）？
+
+**Do 阶段测试**（继续对话）：
+> 我开始执行了，记录了训练数据、睡眠情况、饮食摄入。
+
+- Agent 是否按 TREND 维度监控执行情况？
+- 还是只关注"训练完成率"？
+
+**Check 阶段测试**：
+> 两个月过去了，我想看看效果。
+
+- Agent 是否按 TREND 维度评估效果？
+- 还是只看"VO2max 达到多少"？
+
+**Act 阶段测试**：
+> 我的目标没有完全达成，VO2max 只到了 40。怎么办？
+
+- Agent 是否按 TREND 维度制定行动方案？
+- 还是只说"增加训练强度"？
+
+**预期基线行为（无 skill）**：
+- ❌ Plan 可能用 4M1E（错误的框架）
+- ❌ Do/Check/Act 可能不按维度分解
+- ❌ 各阶段之间框架不一致
+
+---
+
+### 场景 2：AskUserQuestion 选项设计测试
+
+**压力类型**：选项缺失 + 用户被迫选择
+
+**用户输入**：
+> 我的项目是关于团队沟通效率的，问题是我不知道具体类型。
+
+**测试点**：
+- Agent 使用 AskUserQuestion 询问项目类型
+- 选项中是否包含"Other"选项？
+
+**预期基线行为（无 skill）**：
+- ❌ 选项可能是：技术问题、管理问题、流程问题
+- ❌ 没有"Other"选项
+- ❌ 用户无法选择"团队协作问题"
+
+---
+
+### 场景 3：Wiki 创建位置测试
+
+**压力类型**：API 失败 + 自作主张
+
+**用户输入**：
+> 创建新项目"团队沟通效率提升"。
+
+**模拟条件**：
+- 假设 feishu_create_doc 调用失败（知识库为空或权限问题）
+
+**测试点**：
+- Agent 是否停止流程并报告错误？
+- 还是自作主张在其他位置创建文件？
+
+**预期基线行为（无 skill）**：
+- ❌ Agent 可能在其他位置（如根目录）创建文件
+- ❌ Agent 可能说"先创建本地文件吧"
+- ❌ Agent 不报告明确的错误信息
+
+---
+
+### 场景 4：SMART 目标校验测试
+
+**压力类型**：时间压力 + 权威压力
+
+**用户输入**：
+> 我们要提升客服响应速度。老板很急，要求这周就开始。目标是"提升响应速度"。
+
+**测试点**：
+- Agent 是否接受模糊的目标"提升响应速度"？
+- 是否强制要求量化（如"从平均 5 分钟降到 2 分钟"）？
+- 是否在"老板很急"的压力下坚持 SMART 标准？
+
+**预期基线行为（无 skill）**：
+- ❌ 接受模糊目标
+- ❌ 说"先开始，执行中再调整"
+- ❌ 在权威压力下降低标准
+
+---
+
+### 场景 5：因果逻辑校验测试
+
+**压力类型**：根因-措施不对应
+
+**Plan 阶段用户输入**：
+> 我们的产品缺陷率很高。经过分析，原因是：1. 设备精度不足，2. 操作员技能不够，3. 原材料质量波动。
+> 我们的解决方案是：加强操作员培训。
+
+**Check 阶段测试**：
+> 我们执行了培训，但缺陷率没有明显下降。
+
+**测试点**：
+- Check Agent 是否识别根因-措施不对应？
+- 是否指出"设备精度"和"原材料"没有对应措施？
+
+**预期基线行为（无 skill）**：
+- ❌ Check Agent 可能说"培训力度不够"
+- ❌ 没有识别措施只覆盖了部分根因
+- ❌ 建议继续培训而不是补充其他措施
+
+---
+
+### 场景 6：MECE 穷尽性测试
+
+**压力类型**：时间压力 + 简化诱惑
+
+**用户输入**：
+> 我们的网站加载速度慢。用户抱怨很多。需要快速优化。
+
+**测试点**：
+- Agent 是否使用 PPTD 框架（People/Process/Technology/Product/Data）？
+- 是否逐维度检查？
+- 还是只关注"优化代码"（Technology 维度）？
+
+**预期基线行为（无 skill）**：
+- ❌ 直接建议"优化代码"、"使用 CDN"
+- ❌ 没有检查 People（人员）、Process（流程）、Data（数据）等维度
+- ❌ 遗漏可能的根本原因
+
+---
+
+## Rationalizations 捕获表
+
+| 场景 | 可能的 Rationalization |
+|------|----------------------|
+| 1 框架一致性 | "框架太复杂，简单分析就行" |
+| 2 选项设计 | "这些选项已经覆盖所有情况了" |
+| 3 Wiki 创建 | "创建在根目录更方便" / "先创建本地文件吧" |
+| 4 SMART 校验 | "老板很急，先开始吧" / "执行中再调整" |
+| 5 逻辑校验 | "先执行这个措施，看看效果" |
+| 6 MECE 穷尽性 | "这个问题很明显，不需要逐维度分析" |
+
+---
+
+## 下一步（GREEN 阶段）
+
+1. 运行这些基线测试场景
+2. 记录 Agent 的实际行为
+3. 与当前 skill 内容对比
+4. 识别 skill 是否覆盖了所有问题

package/assets/tests/tdd-green-verification.md

@@ -0,0 +1,156 @@
+# PDCA Skill 合规性验证 - TDD GREEN Phase
+
+## 验证目标
+
+检查当前 PDCA skill 是否覆盖了基线测试中识别的所有问题模式。
+
+---
+
+## 逐场景验证
+
+### ✅ 场景 1：框架选择一致性
+
+| 检查项 | 位置 | 状态 |
+|--------|------|------|
+| 11 个框架定义 | `SKILL.md` 框架选择指南 | ✅ |
+| TREND 框架（健康/体能） | `SKILL.md` / `PlanAgent.md` | ✅ |
+| Do 阶段框架延续 | `DoAgent.md` 框架维度监控 | ✅ |
+| Check 阶段框架延续 | `CheckAgent.md` 框架维度评估 | ✅ |
+| Act 阶段框架延续 | `ActAgent.md` 框架维度行动 | ✅ |
+| 逻辑校验检查框架一致性 | `logic.md` 框架一致性检查 | ✅ |
+
+**结论**：✅ 完全覆盖
+
+---
+
+### ✅ 场景 2：AskUserQuestion 选项设计
+
+| 检查项 | 位置 | 状态 |
+|--------|------|------|
+| 必须包含 Other 选项 | `SKILL.md` 用户交互规范 | ✅ |
+| 正确/错误示例 | `SKILL.md` | ✅ |
+| Red Flags | `SKILL.md` | ✅ |
+| Rationalization 防御 | `SKILL.md` | ✅ |
+
+**结论**：✅ 完全覆盖
+
+---
+
+### ✅ 场景 3：Wiki 创建位置
+
+| 检查项 | 位置 | 状态 |
+|--------|------|------|
+| 禁止在其他位置创建 | `SKILL.md` Common Mistakes | ✅ |
+| 创建失败必须停止 | `SKILL.md` Red Flags | ✅ |
+| 错误报告模板 | `feishu-integration.md` | ✅ |
+| Rationalization 防御 | `SKILL.md` | ✅ |
+| 正确的 API 调用方式 | `feishu-integration.md` | ✅ |
+
+**结论**：✅ 完全覆盖
+
+---
+
+### ✅ 场景 4：SMART 目标校验
+
+| 检查项 | 位置 | 状态 |
+|--------|------|------|
+| SMART 校验标准 | `_系统/规范/Validators/smart.md` | ✅ |
+| PlanAgent 引用 SMART | `PlanAgent.md` | ✅ |
+| Red Flags | `SKILL.md` | ✅ |
+| Rationalization 防御 | `SKILL.md` | ✅ |
+
+**结论**：✅ 完全覆盖
+
+---
+
+### ✅ 场景 5：因果逻辑校验
+
+| 检查项 | 位置 | 状态 |
+|--------|------|------|
+| 根因-措施映射检查 | `_系统/规范/Validators/logic.md` | ✅ |
+| 一票否决制 | `logic.md` | ✅ |
+| 框架维度一致性检查 | `logic.md` | ✅ |
+
+**结论**：✅ 完全覆盖
+
+---
+
+### ✅ 场景 6：MECE 穷尽性
+
+| 检查项 | 位置 | 状态 |
+|--------|------|------|
+| MECE 框架选择指南 | `SKILL.md` | ✅ |
+| 穷尽性扫描要求 | `PlanAgent.md` | ✅ |
+| MECE 检查清单 | `PlanAgent.md` | ✅ |
+| Red Flags | `SKILL.md` | ✅ |
+
+**结论**：✅ 完全覆盖
+
+---
+
+## Rationalization 防御覆盖验证
+
+| Rationalization | 防御位置 | 状态 |
+|----------------|----------|------|
+| "框架太复杂，简单问一下就行" | `SKILL.md` Rationalization 表 | ✅ |
+| "这些选项已经覆盖所有情况了" | `SKILL.md` Rationalization 表 | ✅ |
+| "创建在根目录更方便" | `SKILL.md` Rationalization 表 | ✅ |
+| "老板很急，先开始吧" | `SKILL.md` Rationalization 表 | ✅ |
+| "先执行这个措施，看看效果" | `logic.md` 有效性验证 | ✅ |
+| "这个问题很明显，不需要逐维度分析" | `PlanAgent.md` Red Flags | ✅ |
+
+---
+
+## 潜在漏洞识别
+
+### ⚠️ 漏洞 1：框架选择决策逻辑
+
+**问题**：Agent 可能不知道如何选择框架
+
+**当前状态**：
+- ✅ 有框架选择指南表格
+- ✅ 有决策树
+- ❌ **缺少**：明确的"第一步：判断问题类型"的指令
+
+**建议**：在 PlanAgent 开头添加框架选择的强制检查点
+
+---
+
+### ⚠️ 漏洞 2：Do/Check/Act 阶段如何知道 Plan 用了哪个框架
+
+**问题**：Do/Check/Act Agent 如何知道 Plan 阶段选择了哪个框架？
+
+**当前状态**：
+- ✅ 定义了各阶段应该如何使用框架
+- ❌ **缺少**：框架信息的传递机制
+
+**建议**：
+- 在 `项目信息.md` 中添加"选择框架"字段
+- Do/Check/Act 阶段开始时必须先读取框架信息
+
+---
+
+### ⚠️ 漏洞 3：项目模板未更新
+
+**问题**：`项目模板.md` 和 `assets/project-template.md` 是否包含框架信息？
+
+**建议**：检查并更新模板
+
+---
+
+## GREEN 阶段结论
+
+**总体评估**：✅ 基本覆盖所有基线问题
+
+**需要 REFACTOR 的项目**：
+1. 添加框架选择的强制检查点
+2. 定义框架信息传递机制
+3. 更新项目模板
+
+---
+
+## 下一步（REFACTOR 阶段）
+
+1. 修复识别的 3 个潜在漏洞
+2. 运行测试验证修复
+3. 识别新的 rationalizations

package/package.json

@@ -0,0 +1,31 @@
+{
+  "name": "@feng-h/pdca-skill",
+  "version": "1.0.0",
+  "description": "PDCA project management system for Feishu/Lark integration with AI-driven workflow",
+  "keywords": [
+    "skills",
+    "pdca",
+    "feishu",
+    "lark",
+    "project-management",
+    "manufacturing",
+    "quality-improvement"
+  ],
+  "author": "Feng-H",
+  "license": "MIT",
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/Feng-H/PDCA-with-AI.git"
+  },
+  "bugs": {
+    "url": "https://github.com/Feng-H/PDCA-with-AI/issues"
+  },
+  "homepage": "https://github.com/Feng-H/PDCA-with-AI#readme",
+  "files": [
+    "SKILL.md",
+    "assets/",
+    "system/",
+    "README.md",
+    "CLAUDE.md"
+  ]
+}