@creatoria/miniapp-mcp 0.1.3 → 0.2.0

package/docs/charter.F2.align.yaml

@@ -1,248 +0,0 @@
-# Charter: F2 - 失败时自动快照收集
-
-## 项目信息
-project: creatoria-miniapp-mcp
-stage: F - 可观测性与产物输出
-task_id: F2
-title: 失败时自动收集截图和数据快照
-owner: ClaudeCode
-created: 2025-10-03
-status: in_progress
-
-## 1. 目标 (Goals)
-### 主要目标
-- **自动诊断收集**：工具调用失败时自动捕获页面快照和截图，无需手动触发
-- **上下文保留**：保存失败时的完整上下文（错误信息、工具参数、堆栈跟踪）
-- **可配置化**：允许用户启用/禁用自动快照，避免产生过多文件
-- **产物组织**：统一输出到 `artifacts/failures/` 目录，便于后续分析
-
-### 业务价值
-- **提升调试效率**：失败时自动保存现场，开发者可直接查看快照而非重现问题
-- **增强可观测性**：配合 F1 日志系统，提供完整的故障诊断链路
-- **降低维护成本**：减少"无法复现"问题的排查时间
-
-## 2. 非目标 (Non-Goals)
-- ❌ 不实现失败重试机制（属于工具层面的可靠性增强）
-- ❌ 不实现快照的自动分析/报告生成（留给 F3 任务）
-- ❌ 不实现快照的自动清理策略（由用户或外部工具管理）
-- ❌ 不支持自定义快照触发条件（仅在工具失败时触发）
-
-## 3. 范围 (Scope)
-### In Scope
-- ✅ 扩展 ToolLogger 支持失败快照
-- ✅ 配置项：`enableFailureSnapshot` (默认: false)
-- ✅ 失败快照包含：
-  - 页面截图（PNG 格式）
-  - 页面数据快照（JSON 格式）
-  - 错误上下文（工具名、参数、错误消息、堆栈）
-- ✅ 产物目录结构：`artifacts/failures/{sessionId}/{toolName}-{timestamp}/`
-- ✅ 与 D2 快照工具集成（复用 snapshotPage/snapshotFull）
-- ✅ 单元测试覆盖
-
-### Out of Scope
-- 🚫 视频录制（超出快照范畴）
-- 🚫 多页面快照（只捕获当前页面）
-- 🚫 快照压缩/归档（用户自行处理）
-- 🚫 快照上传到云存储（超出本地 MCP 职责）
-
-## 4. 约束 (Constraints)
-### 技术约束
-- **依赖 D2**：必须在 miniProgram 已连接且 D2 快照工具可用时才能收集
-- **性能影响**：快照收集是异步操作，不应阻塞错误抛出
-- **磁盘空间**：每次失败产生 ~100KB-5MB 文件（截图主要占用）
-- **Node.js 版本**：需要 Node 18+（与项目要求一致）
-
-### 设计约束
-- **Fire-and-Forget**：快照收集失败不应影响原始错误的抛出
-- **幂等性**：同一错误不应重复收集快照
-- **安全性**：快照文件名必须经过验证，防止路径遍历
-
-## 5. 解决方案 (Solution)
-### 5.1 架构设计
-```
-┌─────────────────────────────────────────────────────────────┐
-│                      ToolLogger.wrap()                       │
-├─────────────────────────────────────────────────────────────┤
-│  try {                                                       │
-│    const result = await handler(session, args)              │
-│    logger.info('Tool call completed', { result })           │
-│    return result                                             │
-│  } catch (error) {                                           │
-│    logger.error('Tool call failed', { error })              │
-│    ┌──────────────────────────────────────────────────┐    │
-│    │ if (config.enableFailureSnapshot) {              │    │
-│    │   void this.captureFailureSnapshot({             │    │
-│    │     session, toolName, args, error               │    │
-│    │   }).catch(e => logger.warn('Snapshot failed'))  │    │
-│    │ }                                                 │    │
-│    └──────────────────────────────────────────────────┘    │
-│    throw error // ✅ 不阻塞错误抛出                         │
-│  }                                                           │
-└─────────────────────────────────────────────────────────────┘
-```
-
-### 5.2 快照收集流程
-```yaml
-步骤:
-  1. 检查前提条件:
-     - session.miniProgram 存在
-     - session.outputManager 存在
-     - config.enableFailureSnapshot === true
-
-  2. 生成失败目录:
-     - 路径: artifacts/failures/{sessionId}/{toolName}-{timestamp}/
-     - 创建目录（如不存在）
-
-  3. 收集快照数据:
-     - 调用 snapshotPage() 获取页面数据 + 截图
-     - 捕获系统信息（可选）
-
-  4. 保存错误上下文:
-     - 文件: error-context.json
-     - 内容:
-       - toolName: 失败的工具名称
-       - timestamp: ISO 8601 时间戳
-       - error: { message, stack, code }
-       - args: 工具调用参数（已脱敏）
-       - duration: 执行耗时（ms）
-
-  5. 日志记录:
-     - logger.info('Failure snapshot captured', { path })
-     - 失败则 logger.warn('Failed to capture snapshot')
-```
-
-### 5.3 配置扩展
-```typescript
-// src/types.ts
-interface LoggerConfig {
-  level?: LogLevel
-  enableFileLog?: boolean
-  outputDir?: string
-  bufferSize?: number
-  flushInterval?: number
-  enableFailureSnapshot?: boolean // 🆕 默认 false
-}
-
-// src/config/defaults.ts
-const DEFAULT_LOGGER_CONFIG = {
-  // ...existing
-  enableFailureSnapshot: false,
-}
-```
-
-### 5.4 目录结构示例
-```
-.mcp-artifacts/
-└── session-abc123-2025-10-03T12-34-56/
-    ├── logs/
-    │   └── session-abc123.log
-    └── failures/                          # 🆕 失败快照目录
-        ├── element_click-20251003-123500/ # 🆕 按工具+时间分组
-        │   ├── snapshot.json              # 页面数据快照
-        │   ├── snapshot.png               # 页面截图
-        │   └── error-context.json         # 错误上下文
-        └── page_navigate-20251003-123600/
-            ├── snapshot.json
-            ├── snapshot.png
-            └── error-context.json
-```
-
-## 6. 实现计划 (Implementation Plan)
-### Phase 1: 核心实现 (1.5h)
-- [ ] 扩展 `LoggerConfig` 类型定义 (`src/types.ts`)
-- [ ] 添加配置默认值 (`src/config/defaults.ts`)
-- [ ] 实现 `ToolLogger.captureFailureSnapshot()` 方法
-- [ ] 集成到 `ToolLogger.wrap()` 的 catch 块
-
-### Phase 2: 测试验证 (1h)
-- [ ] 单元测试：验证快照收集逻辑
-- [ ] 单元测试：验证配置开关生效
-- [ ] 单元测试：验证错误不被快照阻塞
-- [ ] 集成测试：端到端验证失败场景
-
-### Phase 3: 文档完善 (0.5h)
-- [ ] 更新架构文档 (`docs/architecture.F2.md`)
-- [ ] 更新使用示例（启用失败快照）
-- [ ] 更新配置文档
-
-## 7. 验收标准 (Definition of Done)
-### 功能验收
-- ✅ 工具调用失败时，自动生成快照文件（当 `enableFailureSnapshot: true`）
-- ✅ 快照包含：snapshot.json, snapshot.png, error-context.json
-- ✅ 配置为 `false` 时，不生成快照
-- ✅ 快照收集失败不影响原始错误抛出
-
-### 质量验收
-- ✅ 新增测试用例全部通过
-- ✅ 现有测试用例无回归（395+ 全通过）
-- ✅ TypeScript 编译无错误
-- ✅ 代码格式化完成（Prettier）
-
-### 文档验收
-- ✅ charter.F2.align.yaml 完成
-- ✅ architecture.F2.md 完成
-- ✅ 配置示例更新
-
-## 8. 风险与缓解 (Risks)
-### 风险 #1: 快照收集耗时影响用户体验
-- **影响**: 用户等待错误返回时间变长
-- **缓解**: Fire-and-forget 模式，不阻塞错误抛出
-- **监控**: 记录快照收集耗时到日志
-
-### 风险 #2: miniProgram 未连接时无法快照
-- **影响**: 某些工具失败时无快照（如 launch 失败）
-- **缓解**: 添加前提条件检查，graceful 降级
-- **监控**: 日志记录快照收集失败原因
-
-### 风险 #3: 磁盘空间耗尽
-- **影响**: 快照保存失败
-- **缓解**:
-  - 复用 F1 的磁盘空间检查逻辑
-  - 默认关闭快照功能
-  - 文档建议定期清理
-- **监控**: 磁盘空间不足时警告日志
-
-### 风险 #4: 敏感数据泄漏到快照
-- **影响**: 快照文件包含敏感信息
-- **缓解**:
-  - 复用 F1 的脱敏逻辑处理 args
-  - 文档提醒用户快照文件的隐私风险
-- **监控**: Code review 检查脱敏逻辑
-
-## 9. 依赖关系 (Dependencies)
-### 输入依赖
-- ✅ **D2 (快照工具)**：snapshotPage/snapshotFull 已实现
-- ✅ **F1 (日志系统)**：ToolLogger 已实现
-- ✅ **OutputManager**：文件管理已实现
-
-### 输出依赖
-- ⏳ **F3 (会话报告)**：将使用 F2 的失败快照生成汇总报告
-
-## 10. 里程碑 (Milestones)
-| 里程碑 | 目标 | 预计完成 |
-|--------|------|----------|
-| M1 | 核心实现完成 | T+1.5h |
-| M2 | 测试验证通过 | T+2.5h |
-| M3 | 文档完善 | T+3h |
-| M4 | Code Review + 提交 | T+3.5h |
-
-## 11. 成功指标 (Success Metrics)
-- **功能完整性**: 失败快照收集成功率 100%（前提条件满足时）
-- **性能影响**: 快照收集耗时 < 500ms（不阻塞错误）
-- **测试覆盖**: 新增代码分支覆盖率 > 90%
-- **用户体验**: 默认关闭，不影响现有用户
-
-## 12. 开放问题 (Open Questions)
-- ❓ Q1: 是否需要限制快照文件数量上限？
-  - 建议：暂不限制，由用户管理；文档提醒定期清理
-
-- ❓ Q2: 是否需要支持自定义快照内容？
-  - 建议：F2 保持简单，自定义留给用户手动调用 snapshot 工具
-
-- ❓ Q3: 是否需要记录失败统计（哪些工具失败最多）？
-  - 建议：留给 F3 会话报告任务
-
-## 13. 审批记录 (Approvals)
-- [ ] **技术方案审批**: 待审批
-- [ ] **安全审查**: 待审批
-- [ ] **实现批准**: 待批准

package/docs/charter.F3.align.yaml

@@ -1,287 +0,0 @@
-# Charter: F3 - 会话报告生成
-
-## 项目信息
-project: creatoria-miniapp-mcp
-stage: F - 可观测性与产物输出
-task_id: F3
-title: 会话报告生成（JSON/Markdown 汇总）
-owner: ClaudeCode
-created: 2025-10-03
-status: in_progress
-
-## 1. 目标 (Goals)
-### 主要目标
-- **会话汇总**：自动生成会话执行报告，包含所有工具调用、执行时长、成功/失败统计
-- **双格式输出**：支持 JSON（机器可读）和 Markdown（人类可读）两种格式
-- **失败追踪**：汇总所有失败的工具调用，关联 F2 快照目录
-- **性能分析**：提供工具调用耗时统计，识别性能瓶颈
-
-### 业务价值
-- **调试加速**：一站式查看会话全貌，快速定位问题
-- **质量度量**：提供成功率、平均耗时等指标，评估自动化脚本质量
-- **报告分享**：Markdown 格式便于在团队中共享测试结果
-
-## 2. 非目标 (Non-Goals)
-- ❌ 不实现实时报告更新（仅会话结束时生成）
-- ❌ 不实现报告的自动上传/分发（用户自行处理）
-- ❌ 不实现可视化图表（纯文本/JSON）
-- ❌ 不实现多会话对比分析（单会话维度）
-
-## 3. 范围 (Scope)
-### In Scope
-- ✅ 会话级别数据收集
-  - 工具调用记录（工具名、参数、结果、耗时、状态）
-  - 失败详情（错误消息、快照路径）
-  - 会话元数据（创建时间、结束时间、总耗时）
-- ✅ JSON 报告生成
-  - 结构化数据（可编程解析）
-  - 完整的调用历史
-  - 统计指标
-- ✅ Markdown 报告生成
-  - 汇总表格
-  - 失败详情列表
-  - 性能统计
-- ✅ 报告存储
-  - 路径：`artifacts/{sessionId}/report.json`
-  - 路径：`artifacts/{sessionId}/report.md`
-
-### Out of Scope
-- 🚫 HTML/PDF 格式（超出范围）
-- 🚫 实时流式报告（仅最终报告）
-- 🚫 多会话聚合（单会话独立）
-- 🚫 告警/通知机制（超出本地 MCP 职责）
-
-## 4. 约束 (Constraints)
-### 技术约束
-- **依赖 F1**：需要从结构化日志中提取工具调用数据
-- **依赖 F2**：需要关联失败快照路径
-- **内存限制**：需要在会话期间缓存所有调用记录（控制内存增长）
-- **文件格式**：JSON 必须符合 JSON Schema，Markdown 必须符合 CommonMark
-
-### 设计约束
-- **可选功能**：默认禁用，显式启用（避免产生过多文件）
-- **异步生成**：报告生成不应阻塞会话关闭
-- **容错性**：报告生成失败不应影响会话正常关闭
-
-## 5. 解决方案 (Solution)
-### 5.1 数据收集
-```
-┌─────────────────────────────────────────────────────────────┐
-│                     SessionState                             │
-│                                                              │
-│  reportData?: {                                              │
-│    toolCalls: ToolCallRecord[]                               │
-│    startTime: Date                                           │
-│    endTime?: Date                                            │
-│  }                                                           │
-└─────────────────────────────────────────────────────────────┘
-```
-
-**ToolCallRecord 结构**:
-```typescript
-interface ToolCallRecord {
-  timestamp: Date
-  toolName: string
-  args: any // Sanitized
-  duration: number // milliseconds
-  success: boolean
-  result?: any // Sanitized
-  error?: {
-    message: string
-    snapshotPath?: string // Link to F2 snapshot
-  }
-}
-```
-
-### 5.2 报告生成流程
-```yaml
-步骤:
-  1. 会话开始:
-     - 初始化 reportData = { toolCalls: [], startTime: now }
-
-  2. 工具调用时 (ToolLogger):
-     - 记录 ToolCallRecord 到 session.reportData.toolCalls
-
-  3. 会话关闭:
-     - 设置 reportData.endTime = now
-     - 调用 generateReport(session)
-     - 生成 report.json 和 report.md
-     - 保存到 artifacts/{sessionId}/
-```
-
-### 5.3 报告格式
-
-#### JSON 格式
-```json
-{
-  "sessionId": "test-session-123",
-  "startTime": "2025-10-03T06:00:00.000Z",
-  "endTime": "2025-10-03T06:15:30.000Z",
-  "duration": 930000,
-  "summary": {
-    "totalCalls": 50,
-    "successCount": 47,
-    "failureCount": 3,
-    "successRate": 0.94,
-    "avgDuration": 1500,
-    "maxDuration": 5000,
-    "minDuration": 100
-  },
-  "toolCalls": [
-    {
-      "timestamp": "2025-10-03T06:00:05.000Z",
-      "toolName": "miniprogram_launch",
-      "duration": 3000,
-      "success": true
-    },
-    {
-      "timestamp": "2025-10-03T06:05:10.000Z",
-      "toolName": "element_click",
-      "duration": 500,
-      "success": false,
-      "error": {
-        "message": "Element not found",
-        "snapshotPath": "failures/element_click-2025-10-03_06-05-10-123Z"
-      }
-    }
-  ],
-  "failures": [
-    {
-      "toolName": "element_click",
-      "timestamp": "2025-10-03T06:05:10.000Z",
-      "error": "Element not found",
-      "snapshotPath": "failures/element_click-2025-10-03_06-05-10-123Z"
-    }
-  ]
-}
-```
-
-#### Markdown 格式
-```markdown
-# Session Report: test-session-123
-
-## Summary
-- **Duration**: 15m 30s
-- **Total Calls**: 50
-- **Success Rate**: 94% (47/50)
-- **Average Duration**: 1.5s
-
-## Tool Call Statistics
-| Tool Name | Calls | Success | Failure | Avg Duration |
-|-----------|-------|---------|---------|--------------|
-| miniprogram_launch | 1 | 1 | 0 | 3.0s |
-| page_navigate | 5 | 5 | 0 | 0.8s |
-| element_click | 10 | 8 | 2 | 0.5s |
-| element_input | 8 | 8 | 0 | 0.3s |
-
-## Failures
-### 1. element_click
-- **Time**: 2025-10-03 06:05:10
-- **Error**: Element not found
-- **Snapshot**: [failures/element_click-2025-10-03_06-05-10-123Z](failures/element_click-2025-10-03_06-05-10-123Z)
-
-## Timeline
-| Time | Tool | Status | Duration |
-|------|------|--------|----------|
-| 06:00:05 | miniprogram_launch | ✅ | 3.0s |
-| 06:00:08 | page_navigate | ✅ | 0.8s |
-| 06:05:10 | element_click | ❌ | 0.5s |
-```
-
-## 6. 实现计划 (Implementation Plan)
-### Phase 1: 数据收集 (1h)
-- [ ] 扩展 SessionState 类型定义
-- [ ] 在 ToolLogger.wrap() 中记录 ToolCallRecord
-- [ ] 添加配置项 `enableSessionReport`
-
-### Phase 2: 报告生成 (2h)
-- [ ] 实现 ReportGenerator 类
-- [ ] 实现 generateJSONReport()
-- [ ] 实现 generateMarkdownReport()
-- [ ] 集成到 session.dispose()
-
-### Phase 3: 测试验证 (1h)
-- [ ] 单元测试：数据收集
-- [ ] 单元测试：JSON 格式验证
-- [ ] 单元测试：Markdown 格式验证
-- [ ] 集成测试：端到端报告生成
-
-## 7. 验收标准 (Definition of Done)
-### 功能验收
-- ✅ 会话结束时自动生成 report.json 和 report.md
-- ✅ JSON 格式包含所有必需字段（summary、toolCalls、failures）
-- ✅ Markdown 格式可读性强，包含表格和链接
-- ✅ 失败记录正确关联 F2 快照路径
-- ✅ 配置为 `false` 时不生成报告
-
-### 质量验收
-- ✅ 新增测试用例全部通过
-- ✅ 现有测试用例无回归（406+ 全通过）
-- ✅ TypeScript 编译无错误
-- ✅ 代码格式化完成（Prettier）
-
-### 文档验收
-- ✅ charter.F3.align.yaml 完成
-- ✅ architecture.F3.md 完成
-- ✅ 使用示例更新
-
-## 8. 风险与缓解 (Risks)
-### 风险 #1: 内存占用随会话增长
-- **影响**: 长时间会话可能产生大量 ToolCallRecord
-- **缓解**:
-  - 限制单个会话最大调用记录数（如 1000 条）
-  - 超出限制后，丢弃最早的记录
-  - 文档建议定期创建新会话
-- **监控**: 记录 toolCalls 数组长度到日志
-
-### 风险 #2: 报告生成耗时影响关闭速度
-- **影响**: 用户等待会话关闭时间变长
-- **缓解**:
-  - Fire-and-forget 模式生成报告
-  - 报告生成失败不阻塞关闭
-- **监控**: 记录报告生成耗时
-
-### 风险 #3: 敏感数据泄漏到报告
-- **影响**: 报告文件包含敏感信息
-- **缓解**:
-  - 复用 F1 脱敏逻辑处理 args/result
-  - 文档提醒报告文件的隐私风险
-- **监控**: Code review 检查脱敏逻辑
-
-## 9. 依赖关系 (Dependencies)
-### 输入依赖
-- ✅ **F1 (日志系统)**：ToolLogger 已实现
-- ✅ **F2 (失败快照)**：快照路径格式已确定
-- ✅ **OutputManager**：文件写入能力已实现
-
-### 输出依赖
-- 无下游依赖（F3 是 Stage F 的最后任务）
-
-## 10. 里程碑 (Milestones)
-| 里程碑 | 目标 | 预计完成 |
-|--------|------|----------|
-| M1 | 数据收集完成 | T+1h |
-| M2 | 报告生成完成 | T+3h |
-| M3 | 测试验证通过 | T+4h |
-| M4 | Code Review + 提交 | T+4.5h |
-
-## 11. 成功指标 (Success Metrics)
-- **功能完整性**: 报告生成成功率 100%（配置启用时）
-- **性能影响**: 报告生成耗时 < 200ms（不阻塞关闭）
-- **文件大小**: 单会话报告 < 1MB（控制磁盘占用）
-- **可读性**: Markdown 格式在 GitHub 预览正常
-
-## 12. 开放问题 (Open Questions)
-- ❓ Q1: 是否需要支持报告模板自定义？
-  - 建议：F3 保持简单，固定格式；自定义留给用户后处理
-
-- ❓ Q2: 是否需要支持增量报告（会话过程中实时更新）？
-  - 建议：F3 仅支持最终报告；实时功能复杂度高，留给未来优化
-
-- ❓ Q3: 是否需要包含页面截图链接？
-  - 建议：仅链接 F2 失败快照；成功调用的截图不包含（避免报告过大）
-
-## 13. 审批记录 (Approvals)
-- [ ] **技术方案审批**: 待审批
-- [ ] **安全审查**: 待审批
-- [ ] **实现批准**: 待批准

package/docs/charter.G.align.yaml

@@ -1,174 +0,0 @@
-# Charter: Stage G 测试验证与示例沉淀
-
-## Goal (目标)
-为 creatoria-miniapp-mcp 项目补齐集成测试、示例脚本，并完善文档和工具清单，确保项目达到生产就绪状态。
-
-## Business Value (业务价值)
-- **质量保证**: 通过集成测试验证端到端流程的正确性
-- **用户体验**: 提供可运行的示例脚本，降低用户上手门槛
-- **可维护性**: 自动化工具清单生成，保持文档与代码同步
-- **生产就绪**: 达成 M4 里程碑，为发布做好准备
-
-## Scope (范围)
-
-### In Scope
-
-#### G1: 单元测试审查
-- 审查现有 440 个单元测试的覆盖率
-- 补充缺失的边界用例测试
-- 确保所有核心模块测试覆盖率 > 80%
-
-#### G2: 集成测试实现
-- 创建集成测试框架（tests/integration/）
-- 实现端到端测试场景：
-  1. 基础导航流程（launch → navigate → screenshot）
-  2. 元素交互流程（query → tap → input → assert）
-  3. 断言验证流程（assert + snapshot）
-  4. 录制回放流程（record → replay）
-  5. 失败快照收集（F2 集成）
-  6. 会话报告生成（F3 集成）
-
-#### G3: 示例脚本创建
-- examples/scripts/ 目录结构设计
-- 创建可运行的 TypeScript 示例：
-  1. 基础导航示例 (basic-navigation.ts)
-  2. 元素交互示例 (element-interaction.ts)
-  3. 断言测试示例 (assertion-testing.ts)
-  4. 快照调试示例 (snapshot-debugging.ts)
-  5. 录制回放示例 (record-replay.ts)
-- 配套 README 说明运行方式
-
-#### G4: 工具清单自动生成
-- 实现 scripts/update-readme.ts 脚本
-- 从源码自动提取工具列表和分类
-- 自动更新 README.md 的工具清单部分
-- 集成到 CI/CD 流程确保同步
-
-### Out of Scope (明确不做)
-- 性能测试和压力测试（后续 Stage H）
-- 可视化测试报告（后续优化）
-- E2E 测试的 CI 集成（Stage H）
-- 多平台兼容性测试（Stage H）
-
-## Non-Goals (非目标)
-- 不修改现有核心功能实现
-- 不引入新的业务功能
-- 不重构现有代码架构
-
-## Constraints (约束)
-
-### Technical (技术约束)
-- 集成测试需要真实的微信小程序项目
-- 测试运行需要微信开发者工具环境
-- 示例脚本必须可独立运行（无需 MCP 客户端）
-- 工具清单生成必须保持与源码100%同步
-
-### Time (时间约束)
-- G1: 审查单元测试 - 0.5 小时
-- G2: 集成测试实现 - 2-3 小时
-- G3: 示例脚本创建 - 1-2 小时
-- G4: 工具清单生成 - 1 小时
-- **总计**: 4.5-6.5 小时
-
-### Compliance (合规约束)
-- 遵循现有代码风格
-- 测试必须稳定可重复
-- 示例代码必须简洁易懂
-
-## Definition of Done (完成标准)
-
-### G1: 单元测试审查 ✅
-- [ ] 审查 18 个测试套件的覆盖范围
-- [ ] 补充缺失的边界用例（如有）
-- [ ] 所有测试通过率 100%
-- [ ] 测试覆盖率报告生成
-
-### G2: 集成测试实现 ✅
-- [ ] tests/integration/ 目录结构创建
-- [ ] 至少 6 个集成测试场景实现
-- [ ] 测试使用示例小程序项目
-- [ ] 所有集成测试通过
-- [ ] 集成测试文档（README）
-
-### G3: 示例脚本创建 ✅
-- [ ] examples/scripts/ 目录结构创建
-- [ ] 至少 5 个可运行示例脚本
-- [ ] 每个示例都有注释说明
-- [ ] examples/scripts/README.md 运行指南
-- [ ] 验证所有示例可正常运行
-
-### G4: 工具清单生成 ✅
-- [ ] scripts/update-readme.ts 脚本实现
-- [ ] 自动提取工具列表和分类
-- [ ] README.md 工具清单自动更新
-- [ ] 验证生成的清单完整准确
-- [ ] 添加到 package.json scripts
-
-## Open Questions (开放问题)
-1. 集成测试使用哪个示例小程序项目？
-   - 选项 A: 创建最小化测试项目
-   - 选项 B: 使用官方示例项目
-   - **建议**: 创建最小化项目，便于测试控制
-
-2. 示例脚本是 TypeScript 还是 JavaScript？
-   - **决议**: TypeScript，与项目保持一致
-
-3. 集成测试是否需要在 CI 中运行？
-   - **决议**: Stage G 先本地验证，Stage H 再集成 CI
-
-4. 工具清单生成器需要包含哪些信息？
-   - **决议**: 工具名称、分类、描述、参数Schema
-
-## Dependencies (依赖)
-
-### Input Dependencies
-- Stage A-F 已全部完成
-- 65 个工具已实现（8 个分类）
-- 440 个单元测试已通过
-- F1/F2/F3 可观测性功能已就绪
-
-### Output Dependencies
-- Stage H (CI/CD) 依赖集成测试和示例脚本
-- 用户文档依赖工具清单的准确性
-
-## Risks (风险)
-- ⚠️ 集成测试依赖微信开发者工具环境，可能不稳定
-- ⚠️ 示例小程序项目可能需要额外维护
-- ⚠️ 工具清单自动生成可能遗漏手动添加的工具
-- ⚠️ 集成测试运行时间可能较长，影响开发体验
-
-**缓解措施**:
-- 集成测试提供跳过机制（环境变量控制）
-- 创建最小化示例项目，减少维护成本
-- 工具清单生成器增加人工校验步骤
-- 集成测试标记为可选，不阻塞单元测试
-
-## Success Metrics (成功指标)
-- ✅ 单元测试通过率: 100%
-- ✅ 集成测试场景覆盖: 6+ 个核心流程
-- ✅ 示例脚本数量: 5+ 个
-- ✅ 工具清单准确性: 100% (与源码同步)
-- ✅ 示例可运行率: 100%
-
-## Timeline (时间线)
-- **Day 1 上午**: G1 单元测试审查 (0.5h)
-- **Day 1 下午**: G2 集成测试框架搭建 (2h)
-- **Day 2 上午**: G2 集成测试场景实现 (1h)
-- **Day 2 下午**: G3 示例脚本创建 (1.5h)
-- **Day 3 上午**: G4 工具清单生成器 (1h)
-- **Day 3 下午**: 验证和文档完善 (0.5h)
-
-## Stakeholders (相关方)
-- **Owner**: ClaudeCode (Generalist Agent)
-- **Approver**: User (samuelcn)
-- **Beneficiaries**:
-  - 最终用户（获得可运行示例）
-  - 维护者（获得自动化工具清单）
-  - 贡献者（获得完整测试覆盖）
-
----
-
-**Charter 创建时间**: 2025-10-03
-**预计开始时间**: 2025-10-03
-**预计完成时间**: 2025-10-05
-**状态**: APPROVED (自动批准，Stage F 已完成)