claude-coder 1.8.0 → 1.8.2

package/templates/test_rule.md

@@ -1,195 +1,195 @@
-# Playwright 自动化测试通用规则 v0.0.1
-
-## 一、四条铁律
-
-1. **真实操作** — 必须通过 Playwright MCP 产生浏览器交互，代码审查不等于测试
-2. **测试业务** — 断言基于用户可见结果（页面文本、按钮状态），非内部变量
-3. **独立可重复** — 每个场景不依赖其他测试结果
-4. **先调查再修复** — 失败先分析根因，不要修改测试让它通过
-
-## 二、三步测试方法论
-
-任何 Web 项目的端到端测试遵循三步走：
-
-### Step 1: 功能验证（Happy Path）
-
-核心用户流程能走通，每个步骤对应一个 Playwright MCP 工具调用：
-
-```
-1. browser_navigate → [页面URL]
-2. browser_snapshot → 确认页面加载，定位关键元素 ref
-3. browser_fill_form / browser_type → 输入测试数据
-4. browser_click → 提交操作
-5. browser_wait_for → 等待结果出现
-6. browser_snapshot → 验证预期结果
-```
-
-### Step 2: 错误场景（Unhappy Path）
-
-| 类别 | 典型场景 |
-|------|---------|
-| 输入验证 | 空提交、超长输入、特殊字符、非法格式 |
-| 认证权限 | 未登录访问、过期凭证、无效 API Key |
-| 网络服务 | 后端宕机、慢响应、API 500 |
-| 状态边界 | 空数据、大数据量、重复提交、浏览器后退 |
-
-### Step 3: 探索性测试
-
-以目标用户角色自由使用系统，关注可发现性、可理解性、响应速度、错误恢复、视觉一致性。
-
-## 三、Playwright MCP 工具速查
-
-### 导航与观察
-
-| 工具 | 用途 | 关键参数 |
-|------|------|---------|
-| `browser_navigate` | 打开页面 | `url` |
-| `browser_snapshot` | 获取页面可访问性快照 | 无 |
-| `browser_console_messages` | 检查控制台 | `level` |
-| `browser_network_requests` | 网络请求日志 | 无 |
-
-### 交互操作
-
-| 工具 | 用途 | 关键参数 |
-|------|------|---------|
-| `browser_click` | 点击元素 | `ref`, `element` |
-| `browser_type` | 逐字符输入 | `ref`, `text`, `submit` |
-| `browser_fill_form` | 批量填写表单 | `fields[]` |
-| `browser_select_option` | 选择下拉项 | `ref`, `values[]` |
-| `browser_press_key` | 按键 | `key` |
-| `browser_file_upload` | 上传文件 | `paths[]` |
-| `browser_handle_dialog` | 处理弹窗 | `accept` |
-
-### 等待与控制
-
-| 工具 | 用途 | 关键参数 |
-|------|------|---------|
-| `browser_wait_for` | 等待元素/文本出现 | `text`, `ref`, `timeout` |
-| `browser_evaluate` | 执行 JS | `function` |
-| `browser_close` | 关闭页面 | 无 |
-
-## 四、Smart Snapshot 策略（节省 40-60% Token）
-
-每次 `browser_snapshot` 消耗 3,000-8,000 tokens。分级控制：
-
-| 级别 | 何时 snapshot | 示例 |
-|------|-------------|------|
-| **必须** | 首次加载页面 | navigate 后确认页面正确 |
-| **必须** | 关键断言点 | 验证操作结果出现 |
-| **必须** | 操作失败时 | 调查页面状态 |
-| **可选** | 中间操作后 | fill 后确认文字填入 |
-| **跳过** | 连续同类操作间 | 连续选择多个下拉框 |
-| **跳过** | 等待循环中 | 改用 `browser_wait_for` |
-
-**高效模式**：navigate → snapshot → fill → select → click → wait_for → snapshot（**2 次**）
-**低效模式**：navigate → snapshot → fill → snapshot → select → snapshot → click → snapshot（**4 次**）
-
-## 五、等待策略
-
-### 按操作类型选择
-
-| 操作类型 | 策略 | Token 消耗 |
-|---------|------|-----------|
-| 瞬时（导航、点击） | 直接操作，不等待 | 极低 |
-| 短等（表单提交） | `browser_wait_for text="成功" timeout=10000` | ~5K |
-| 长等（AI 生成、文件处理） | `browser_wait_for` + 合理 timeout | ~5K |
-| 超长等（批量处理） | Shell 端 API 检查 + 最终 1 次 snapshot | ~5.5K |
-
-### SSE / 流式生成任务的等待策略
-
-当操作涉及 AI 生成、文件转换、SSE 流式处理等需要较长时间的场景时，优先使用 `browser_wait_for` 而非轮询 snapshot：
-
-| 步骤 | 工具 | 说明 |
-|------|------|------|
-| 触发操作 | `browser_click` | 点击"生成"/"提交"按钮 |
-| 等待完成 | `browser_wait_for` | 等待完成标志文本出现，设置合理 timeout |
-| 验证结果 | `browser_snapshot` | 确认结果/下载链接出现 |
-
-**`browser_wait_for` 参数**：
-- `text`：完成标志文本（如"下载"、"完成"、"预览"）
-- `timeout`：根据操作实际预估耗时设置（如表单提交 10s、AI 生成 60-180s、批量处理更长）
-- 相比轮询 snapshot，Token 消耗从 ~60K+ 降至 ~5K
-
-### 常见反模式
-
-- 每步 snapshot → 合并 2-3 操作后再 snapshot
-- 轮询 snapshot 等待长操作 → 改用 `browser_wait_for`
-- MCP 做 20+ 步 → 长流程用 Playwright CLI
-- 反复 navigate 同一页面 → 在同一页面完成
-- 失败后盲目重试 → 先 `browser_console_messages` 分析
-
-### 优先级映射
-
-P0（核心流程）必测 → P1（错误处理）必测 → P2（次要功能）按需 → P3 低优先
-
-预算 >200K: P0+P1+P2 | 100-200K: P0+P1 | <100K: 仅 P0
-
-## 六、凭证管理
-
-`.mcp.json` 由 `claude-coder auth` 自动生成，根据配置模式使用不同参数：
-- persistent（默认）：`--user-data-dir=<path>`，登录态自动保持
-- isolated：`--isolated --storage-state=<path>`，每次从快照加载
-- extension：`--extension`，连接真实浏览器
-
-凭证失效时：不修改 auth 文件，报告中标注，提示用户运行 `claude-coder auth [URL]`。
-
-## 七、失败处理
-
-**阻断性**（立即停止）: 服务未启动、500 错误、凭证缺失、页面空白
-
-**非阻断性**（记录继续）: 样式异常、console warning、慢响应
-
-失败时: snapshot（记录状态）→ console_messages（错误日志）→ 停止该场景 → 继续下一个
-
-## 八、tasks.json 测试步骤模板
-
-推荐使用结构化标签前缀（`【规则】【环境】【P0】` 等）组织步骤。研究表明，结构化标记可提升 LLM 的指令遵循度和步骤完成率，帮助 Agent 理解每步的目的和优先级。
-
-### 基础模板
-
-```json
-{
-  "steps": [
-    "【规则】阅读 .claude-coder/test_rule.md",
-    "【环境】curl [后端]/health && curl [前端]（失败则停止）",
-    "【P0】Playwright MCP 执行核心 Happy Path（Smart Snapshot）",
-    "【P1】错误场景：空输入、无效凭证",
-    "【记录】结果写入 record/",
-    "【预算】消耗 >80% 时跳过低优先级，记录 session_result.json"
-  ]
-}
-```
-
-### 含长等待操作的模板（SSE / AI 生成 / 文件转换）
-
-```json
-{
-  "steps": [
-    "【规则】阅读 .claude-coder/test_rule.md",
-    "【环境】curl http://localhost:8000/health 确认后端服务正常",
-    "【P0】Playwright MCP 访问目标页面，snapshot 确认页面加载",
-    "【P0】填写表单数据，snapshot 确认输入成功",
-    "【P0】点击提交，使用 browser_wait_for 等待结果出现（根据操作耗时设置合理 timeout）",
-    "【P0】验证结果正确（下载链接有效 / 预览内容匹配）",
-    "【记录】测试结果写入 record/（使用 test_rule.md 报告模板）",
-    "【预算】Smart Snapshot 策略：导航→填写→点击→等待→验证，共 3-4 次 snapshot"
-  ]
-}
-```
-
-## 九、测试报告格式
-
-```markdown
-# E2E 测试报告
-**日期**: YYYY-MM-DD | **环境**: 前端 [URL] / 后端 [URL]
-
-| 场景 | 结果 | 备注 |
-|------|------|------|
-| [名称] | PASS/FAIL | [简要] |
-
-## 发现的问题
-### [P0/P1/P2] 标题
-- **复现**: [Playwright 动作序列]
-- **预期/实际**: ...
-- **根因**: [代码分析]
+# Playwright 自动化测试通用规则 v0.0.1
+
+## 一、四条铁律
+
+1. **真实操作** — 必须通过 Playwright MCP 产生浏览器交互，代码审查不等于测试
+2. **测试业务** — 断言基于用户可见结果（页面文本、按钮状态），非内部变量
+3. **独立可重复** — 每个场景不依赖其他测试结果
+4. **先调查再修复** — 失败先分析根因，不要修改测试让它通过
+
+## 二、三步测试方法论
+
+任何 Web 项目的端到端测试遵循三步走：
+
+### Step 1: 功能验证（Happy Path）
+
+核心用户流程能走通，每个步骤对应一个 Playwright MCP 工具调用：
+
+```
+1. browser_navigate → [页面URL]
+2. browser_snapshot → 确认页面加载，定位关键元素 ref
+3. browser_fill_form / browser_type → 输入测试数据
+4. browser_click → 提交操作
+5. browser_wait_for → 等待结果出现
+6. browser_snapshot → 验证预期结果
+```
+
+### Step 2: 错误场景（Unhappy Path）
+
+| 类别 | 典型场景 |
+|------|---------|
+| 输入验证 | 空提交、超长输入、特殊字符、非法格式 |
+| 认证权限 | 未登录访问、过期凭证、无效 API Key |
+| 网络服务 | 后端宕机、慢响应、API 500 |
+| 状态边界 | 空数据、大数据量、重复提交、浏览器后退 |
+
+### Step 3: 探索性测试
+
+以目标用户角色自由使用系统，关注可发现性、可理解性、响应速度、错误恢复、视觉一致性。
+
+## 三、Playwright MCP 工具速查
+
+### 导航与观察
+
+| 工具 | 用途 | 关键参数 |
+|------|------|---------|
+| `browser_navigate` | 打开页面 | `url` |
+| `browser_snapshot` | 获取页面可访问性快照 | 无 |
+| `browser_console_messages` | 检查控制台 | `level` |
+| `browser_network_requests` | 网络请求日志 | 无 |
+
+### 交互操作
+
+| 工具 | 用途 | 关键参数 |
+|------|------|---------|
+| `browser_click` | 点击元素 | `ref`, `element` |
+| `browser_type` | 逐字符输入 | `ref`, `text`, `submit` |
+| `browser_fill_form` | 批量填写表单 | `fields[]` |
+| `browser_select_option` | 选择下拉项 | `ref`, `values[]` |
+| `browser_press_key` | 按键 | `key` |
+| `browser_file_upload` | 上传文件 | `paths[]` |
+| `browser_handle_dialog` | 处理弹窗 | `accept` |
+
+### 等待与控制
+
+| 工具 | 用途 | 关键参数 |
+|------|------|---------|
+| `browser_wait_for` | 等待元素/文本出现 | `text`, `ref`, `timeout` |
+| `browser_evaluate` | 执行 JS | `function` |
+| `browser_close` | 关闭页面 | 无 |
+
+## 四、Smart Snapshot 策略（节省 40-60% Token）
+
+每次 `browser_snapshot` 消耗 3,000-8,000 tokens。分级控制：
+
+| 级别 | 何时 snapshot | 示例 |
+|------|-------------|------|
+| **必须** | 首次加载页面 | navigate 后确认页面正确 |
+| **必须** | 关键断言点 | 验证操作结果出现 |
+| **必须** | 操作失败时 | 调查页面状态 |
+| **可选** | 中间操作后 | fill 后确认文字填入 |
+| **跳过** | 连续同类操作间 | 连续选择多个下拉框 |
+| **跳过** | 等待循环中 | 改用 `browser_wait_for` |
+
+**高效模式**：navigate → snapshot → fill → select → click → wait_for → snapshot（**2 次**）
+**低效模式**：navigate → snapshot → fill → snapshot → select → snapshot → click → snapshot（**4 次**）
+
+## 五、等待策略
+
+### 按操作类型选择
+
+| 操作类型 | 策略 | Token 消耗 |
+|---------|------|-----------|
+| 瞬时（导航、点击） | 直接操作，不等待 | 极低 |
+| 短等（表单提交） | `browser_wait_for text="成功" timeout=10000` | ~5K |
+| 长等（AI 生成、文件处理） | `browser_wait_for` + 合理 timeout | ~5K |
+| 超长等（批量处理） | Shell 端 API 检查 + 最终 1 次 snapshot | ~5.5K |
+
+### SSE / 流式生成任务的等待策略
+
+当操作涉及 AI 生成、文件转换、SSE 流式处理等需要较长时间的场景时，优先使用 `browser_wait_for` 而非轮询 snapshot：
+
+| 步骤 | 工具 | 说明 |
+|------|------|------|
+| 触发操作 | `browser_click` | 点击"生成"/"提交"按钮 |
+| 等待完成 | `browser_wait_for` | 等待完成标志文本出现，设置合理 timeout |
+| 验证结果 | `browser_snapshot` | 确认结果/下载链接出现 |
+
+**`browser_wait_for` 参数**：
+- `text`：完成标志文本（如"下载"、"完成"、"预览"）
+- `timeout`：根据操作实际预估耗时设置（如表单提交 10s、AI 生成 60-180s、批量处理更长）
+- 相比轮询 snapshot，Token 消耗从 ~60K+ 降至 ~5K
+
+### 常见反模式
+
+- 每步 snapshot → 合并 2-3 操作后再 snapshot
+- 轮询 snapshot 等待长操作 → 改用 `browser_wait_for`
+- MCP 做 20+ 步 → 长流程用 Playwright CLI
+- 反复 navigate 同一页面 → 在同一页面完成
+- 失败后盲目重试 → 先 `browser_console_messages` 分析
+
+### 优先级映射
+
+P0（核心流程）必测 → P1（错误处理）必测 → P2（次要功能）按需 → P3 低优先
+
+预算 >200K: P0+P1+P2 | 100-200K: P0+P1 | <100K: 仅 P0
+
+## 六、凭证管理
+
+`.mcp.json` 由 `claude-coder auth` 自动生成，根据配置模式使用不同参数：
+- persistent（默认）：`--user-data-dir=<path>`，登录态自动保持
+- isolated：`--isolated --storage-state=<path>`，每次从快照加载
+- extension：`--extension`，连接真实浏览器
+
+凭证失效时：不修改 auth 文件，报告中标注，提示用户运行 `claude-coder auth [URL]`。
+
+## 七、失败处理
+
+**阻断性**（立即停止）: 服务未启动、500 错误、凭证缺失、页面空白
+
+**非阻断性**（记录继续）: 样式异常、console warning、慢响应
+
+失败时: snapshot（记录状态）→ console_messages（错误日志）→ 停止该场景 → 继续下一个
+
+## 八、tasks.json 测试步骤模板
+
+推荐使用结构化标签前缀（`【规则】【环境】【P0】` 等）组织步骤。研究表明，结构化标记可提升 LLM 的指令遵循度和步骤完成率，帮助 Agent 理解每步的目的和优先级。
+
+### 基础模板
+
+```json
+{
+  "steps": [
+    "【规则】阅读 .claude-coder/test_rule.md",
+    "【环境】curl [后端]/health && curl [前端]（失败则停止）",
+    "【P0】Playwright MCP 执行核心 Happy Path（Smart Snapshot）",
+    "【P1】错误场景：空输入、无效凭证",
+    "【记录】结果写入 record/",
+    "【预算】消耗 >80% 时跳过低优先级，记录 session_result.json"
+  ]
+}
+```
+
+### 含长等待操作的模板（SSE / AI 生成 / 文件转换）
+
+```json
+{
+  "steps": [
+    "【规则】阅读 .claude-coder/test_rule.md",
+    "【环境】curl http://localhost:8000/health 确认后端服务正常",
+    "【P0】Playwright MCP 访问目标页面，snapshot 确认页面加载",
+    "【P0】填写表单数据，snapshot 确认输入成功",
+    "【P0】点击提交，使用 browser_wait_for 等待结果出现（根据操作耗时设置合理 timeout）",
+    "【P0】验证结果正确（下载链接有效 / 预览内容匹配）",
+    "【记录】测试结果写入 record/（使用 test_rule.md 报告模板）",
+    "【预算】Smart Snapshot 策略：导航→填写→点击→等待→验证，共 3-4 次 snapshot"
+  ]
+}
+```
+
+## 九、测试报告格式
+
+```markdown
+# E2E 测试报告
+**日期**: YYYY-MM-DD | **环境**: 前端 [URL] / 后端 [URL]
+
+| 场景 | 结果 | 备注 |
+|------|------|------|
+| [名称] | PASS/FAIL | [简要] |
+
+## 发现的问题
+### [P0/P1/P2] 标题
+- **复现**: [Playwright 动作序列]
+- **预期/实际**: ...
+- **根因**: [代码分析]
 ```

package/src/core/validator.js

@@ -1,138 +0,0 @@
-'use strict';
-
-const { execSync } = require('child_process');
-const { log } = require('../common/config');
-const { getGitHead } = require('../common/utils');
-const { assets } = require('../common/assets');
-const { TASK_STATUSES } = require('../common/constants');
-const { loadTasks, getFeatures } = require('../common/tasks');
-
-function inferFromTasks(taskId) {
-  if (!taskId) return null;
-  const data = loadTasks();
-  if (!data) return null;
-  const task = getFeatures(data).find(f => f.id === taskId);
-  return task ? task.status : null;
-}
-
-function validateSessionResult() {
-  if (!assets.exists('sessionResult')) {
-    log('error', 'Agent 未生成 session_result.json');
-    return { valid: false, fatal: true, recoverable: false, reason: 'session_result.json 不存在' };
-  }
-
-  const data = assets.readJson('sessionResult', null);
-  if (data === null) {
-    log('warn', 'session_result.json 解析失败');
-    return { valid: false, fatal: false, recoverable: true, reason: 'JSON 解析失败' };
-  }
-
-  const sessionData = data.current && typeof data.current === 'object' ? data.current : data;
-
-  const required = ['session_result', 'status_after'];
-  const missing = required.filter(k => !(k in sessionData));
-  if (missing.length > 0) {
-    log('warn', `session_result.json 缺少字段: ${missing.join(', ')}`);
-    return { valid: false, fatal: false, recoverable: true, reason: `缺少字段: ${missing.join(', ')}` };
-  }
-
-  if (!['success', 'failed'].includes(sessionData.session_result)) {
-    log('warn', `session_result 必须是 success 或 failed，实际是: ${sessionData.session_result}`);
-    return { valid: false, fatal: false, recoverable: true, reason: `无效 session_result: ${sessionData.session_result}`, data: sessionData };
-  }
-
-  if (!TASK_STATUSES.includes(sessionData.status_after)) {
-    log('warn', `status_after 不合法: ${sessionData.status_after}`);
-    return { valid: false, fatal: false, recoverable: true, reason: `无效 status_after: ${sessionData.status_after}`, data: sessionData };
-  }
-
-  if (sessionData.session_result === 'success') {
-    log('ok', 'session_result.json 合法 (success)');
-  } else {
-    log('warn', 'session_result.json 合法，但 Agent 报告失败 (failed)');
-  }
-
-  return { valid: true, fatal: false, recoverable: false, data: sessionData };
-}
-
-function checkGitProgress(headBefore) {
-  if (!headBefore) {
-    log('info', '未提供 head_before，跳过 git 检查');
-    return { hasCommit: false, warning: false };
-  }
-
-  const projectRoot = assets.projectRoot;
-  const headAfter = getGitHead(projectRoot);
-
-  if (headBefore === headAfter) {
-    log('warn', '本次会话没有新的 git 提交');
-    return { hasCommit: false, warning: true };
-  }
-
-  try {
-    const msg = execSync('git log --oneline -1', { cwd: projectRoot, encoding: 'utf8' }).trim();
-    log('ok', `检测到新提交: ${msg}`);
-  } catch { /* ignore */ }
-
-  return { hasCommit: true, warning: false };
-}
-
-function checkTestCoverage(taskId, statusAfter) {
-  if (statusAfter !== 'done' || !taskId) return;
-  if (!assets.exists('tests')) return;
-
-  const tests = assets.readJson('tests', null);
-  if (!tests) return;
-  const testCases = tests.test_cases || [];
-  const taskTests = testCases.filter(t => t.feature_id === taskId);
-  if (taskTests.length > 0) {
-    const failed = taskTests.filter(t => t.last_result === 'fail');
-    if (failed.length > 0) {
-      log('warn', `tests.json 中有失败的验证记录: ${failed.map(t => t.id).join(', ')}`);
-    } else {
-      log('ok', `${taskTests.length} 条验证记录覆盖任务 ${taskId}`);
-    }
-  }
-}
-
-function validate(headBefore, taskId) {
-  log('info', '========== 开始校验 ==========');
-
-  const srResult = validateSessionResult();
-  const gitResult = checkGitProgress(headBefore);
-
-  let fatal = false;
-  let hasWarnings = false;
-
-  if (srResult.valid) {
-    hasWarnings = gitResult.warning;
-  } else {
-    if (gitResult.hasCommit) {
-      const taskStatus = inferFromTasks(taskId);
-      if (taskStatus === 'done' || taskStatus === 'testing') {
-        log('warn', `session_result.json 异常，但 tasks.json 显示 ${taskId} 已 ${taskStatus}，且有新提交，降级为警告`);
-      } else {
-        log('warn', 'session_result.json 异常，但有新提交，降级为警告（不回滚代码）');
-      }
-      hasWarnings = true;
-    } else {
-      log('error', '无新提交且 session_result.json 异常，视为致命');
-      fatal = true;
-    }
-  }
-
-  const statusAfter = srResult.data?.status_after || inferFromTasks(taskId) || null;
-  checkTestCoverage(taskId, statusAfter);
-
-  if (fatal) {
-    log('error', '========== 校验失败 (致命) ==========');
-  } else if (hasWarnings) {
-    log('warn', '========== 校验通过 (有警告) ==========');
-  } else {
-    log('ok', '========== 校验全部通过 ==========');
-  }
-
-  return { fatal, hasWarnings, sessionData: srResult.data };
-}
-
-module.exports = { validate, validateSessionResult, checkGitProgress };

package/templates/addGuide.md

@@ -1,98 +0,0 @@
-# 任务分解指南
-
-> 本文档是 `claude-coder add` 指令的参考文档。
-> ADD Agent 的唯一职责：分解需求为结构化任务，追加到 tasks.json。不实现任何代码。
-
----
-
-## tasks.json 格式
-
-```json
-{
-  "project": "项目名称",
-  "created_at": "2026-02-13",
-  "features": [
-    {
-      "id": "feat-001",
-      "category": "backend | frontend | fullstack | infra",
-      "priority": 1,
-      "description": "功能的简要描述（40字内）",
-      "steps": [
-        "具体步骤 1",
-        "具体步骤 2",
-        "端到端测试：验证方法"
-      ],
-      "status": "pending",
-      "depends_on": []
-    }
-  ]
-}
-```
-
-### 字段规范
-
-| 字段 | 规则 |
-|------|------|
-| `id` | 格式 `feat-NNN`，从已有最大值递增 |
-| `category` | `backend` / `frontend` / `fullstack` / `infra`，准确归类 |
-| `priority` | 数字越小越优先，从已有最大值递增 |
-| `description` | 简明扼要，40 字内，说明"做什么"而非"怎么做" |
-| `steps` | 具体可操作步骤，最后一步必须是可验证的测试命令，单任务不超过 5 步 |
-| `status` | 新增任务一律 `"pending"` |
-| `depends_on` | 引用前置任务的 `id`，形成 DAG（有向无环图），不得循环依赖 |
-
----
-
-## 任务分解规则
-
-### 粒度控制
-
-- 每个任务是独立可测试的功能单元，1-3 session 可完成，新增不超 500 行
-- 单任务 steps 不超过 5 步，超过则拆分为多个任务
-- 第一个任务从第一个有业务逻辑的功能开始，不重复脚手架内容
-- 新项目：infra 任务合并为尽量少的条目，不拆碎
-
-### 验证命令模板
-
-steps 的最后一步必须包含可执行的验证命令：
-
-```
-API:   curl -s -o /dev/null -w "%{http_code}" http://localhost:PORT/path → 200
-文件:  grep -q "关键内容" path/to/file && echo "pass"
-构建:  npm run build 2>&1 | tail -1 → 无 error
-页面:  Playwright MCP snapshot 验证关键元素存在
-```
-
-### 反面案例（禁止出现）
-
-- `"实现用户功能"` → 太模糊，应拆为具体接口
-- `"编写测试"` → 测试应内嵌在 steps 末尾，不是独立任务
-- steps 只有 `"实现xxx"` 没有验证步骤
-
----
-
-## requirements.md 处理原则
-
-`requirements.md` 是用户的需求输入，**绝对不能修改它**。但"不能改"不等于"必须盲从"。遇到以下情况时，在 `session_result.json` 的 `notes` 中记录问题，按最合理的方式继续分解：
-
-| 场景 | 处理方式 |
-|------|----------|
-| 需求自相矛盾 | 记录矛盾，按技术可行的方案分解，说明选择理由 |
-| 需求与已有代码冲突 | 记录冲突，说明重构成本，按现有架构分解，建议用户确认 |
-| 需求太模糊无法执行 | 自行做出合理决策，在 notes 中记录选择，供用户确认 |
-| 需求中途变更 | 记录变更影响，基于最新需求分解 |
-| 需求引用了不可访问的资源 | 记录问题，根据文字描述尽力分解 |
-| 需求指定了不存在的依赖 | 记录问题，使用最接近的可用版本 |
-
-**核心原则：不停工、不擅改、留记录。**
-
----
-
-## Playwright MCP 测试任务
-
-当任务涉及前端或全栈端到端测试，且项目已配置 Playwright MCP 时，测试步骤的详细规范（结构化标签、Smart Snapshot 策略、SSE 等待模式、步骤模板等）统一参见 `.claude-coder/test_rule.md` 第五节（等待策略）和第八节（步骤模板）。
-
-此处只列关键原则：
-- steps 首步加入 `【规则】阅读 .claude-coder/test_rule.md`
-- 使用 `【P0】【P1】【P2】` 标记优先级，预算不足时可按优先级裁剪
-- 长等待操作使用 `browser_wait_for` 而非轮询 snapshot

package/templates/addUser.md

@@ -1,26 +0,0 @@
-你是资深需求分析师，擅长将模糊需求分解为可执行的原子任务。
-这是任务追加 session，不是编码 session。你只分解任务，不实现代码。
-
-{{profileContext}}
-{{taskContext}}
-{{recentExamples}}
-项目绝对路径: {{projectRoot}}
-
-【方案文件】
-{{planPath}}
-
-执行步骤（按顺序，不可跳过）：
-1. 读取方案文件（{{planPath}}），理解技术方案和任务规划
-2. 读取 .claude-coder/tasks.json 和 .claude-coder/project_profile.json，了解项目现状
-3. 分析方案中的任务列表：识别核心功能点，判断是单任务还是需要拆分为多任务
-4. 检查重复：对比已有任务，避免功能重叠
-5. 确定依赖：新任务的 depends_on 引用已有或新增任务的 id，形成 DAG
-6. 分解任务：按下方任务分解指南的规则，每个任务独立可测试
-7. 追加到 tasks.json，id 和 priority 从已有最大值递增，status: pending
-8. git add -A && git commit -m "chore: add new tasks"
-9. 写入 session_result.json（格式：{ "session_result": "success", "status_before": "N/A", "status_after": "N/A", "notes": "追加了 N 个任务：简述" }）
-
-{{addGuide}}
-
-{{testRuleHint}}
-不修改已有任务，不实现代码。