sillyspec 3.20.0 → 3.20.2

package/src/stages/brainstorm-auto.js

@@ -0,0 +1,229 @@
+/**
+ * brainstorm-auto.js — auto/full 模式使用的 brainstorm 步骤定义
+ *
+ * 与 brainstorm.js 的区别：
+ * 1. artifact-first：直接写文件，对话只输出摘要
+ * 2. 自动决策：基于 AC-001~AC-010 checklist，不频繁请示
+ * 3. next-action.json：结构化产物，驱动下游推进
+ * 4. 只有 blocking questions 才 wait 用户
+ * 5. 步骤从 ~13 步精简为 4 步
+ */
+
+export const definition = {
+  name: 'brainstorm',
+  title: '头脑风暴（自动模式）',
+  description: '探索需求、分析技术方案、识别风险 — artifact-first，自动决策优先',
+
+  steps: [
+    {
+      name: '状态检查与上下文加载',
+      prompt: `检查状态、加载项目上下文、匹配模块。
+
+### 操作
+1. 运行 \`sillyspec progress show\`，确认 currentStage 为 "brainstorm"
+2. 如果未初始化，提示先运行 sillyspec init
+3. **检查变更名称**：如果当前变更名是自动生成的（如 \`2026-06-02-new-change\`），直接重命名为有意义名称，然后运行 \`sillyspec change-rename <旧名> <新名>\`
+
+### 加载上下文
+4. 读取 CODEBASE-OVERVIEW.md + 共享规范 + 子项目上下文
+5. 加载项目信息：\`cat .sillyspec/projects/*.yaml 2>/dev/null\`
+6. 加载本地配置：\`cat .sillyspec/local.yaml 2>/dev/null\`
+7. 棕地项目：读取 scan 下的 STRUCTURE.md、CONVENTIONS.md、ARCHITECTURE.md
+8. 加载模块索引：读取 \`.sillyspec/docs/<project>/modules/_module-map.yaml\`（如存在）
+9. 查看进行中的变更：\`ls .sillyspec/changes/ | grep -v archive\`
+10. 检查同名变更或可复用模板
+
+### 模块匹配
+根据用户描述的需求关键词，匹配相关模块（用 _module-map.yaml 的 tags/aliases/paths）。
+
+### 子项目判定
+- 单项目：直接确认
+- 多项目且用户已指定：直接确认
+- 多项目且用户未指定：列出项目列表，需要用户确认
+
+### 如果有用户提供的原型/截图
+分析提取：页面结构、表单字段、交互流程、业务规则。
+
+### 输出
+状态摘要 + 项目现状理解（3-5 句）+ 涉及模块列表 + 子项目 + 原型分析（如有）
+
+### 注意
+- 以 CLI 返回为准，不要自行推断阶段
+- 不要用 mv 命令重命名变更目录，必须用 \`sillyspec change-rename\``,
+      outputHint: '状态摘要 + 上下文 + 模块匹配',
+      optional: false
+    },
+    {
+      name: '需求分析与方案设计',
+      requiresWait: true,
+      repeatableWait: true,
+      maxWaitRounds: 5,
+      waitReason: '等待用户回答需求问题',
+      waitOptions: ['回答见--answer', '信息够了，进入设计'],
+      prompt: `分析需求，必要时追问，然后设计方案。
+
+### 操作
+
+#### A. 需求评估
+1. 汇总上一步加载的上下文和用户需求
+2. 判断需求是否清晰：
+   - 目标明确、范围清楚、无歧义 → 跳过追问，直接进入方案设计
+   - 有歧义或不清楚 → 挑**一个最关键的**问题追问
+
+#### B. 追问规则（只在需要时）
+- 一次只问一个问题，不要一次性列出多个问题
+- 能从代码/文档确认的不要问用户
+- 多选题优于开放式问题
+- YAGNI — 砍掉不需要的功能
+- 2-3 轮问答就应进入方案设计
+- 优先追问影响架构/数据/接口的问题，实现细节不要问
+
+**如果需要追问：**调用 \`sillyspec run brainstorm --wait --reason "等待用户回答需求问题" --options "回答见--answer,信息够了,进入设计" --output "你的单个问题"\`
+
+#### C. 复杂度评估（追问结束后或不需要追问时）
+1. 判断是否需要拆分或走批量模式：
+   - 3+ 个可独立交付的功能模块 → 建议拆分
+   - 任务 > 10 且有重复模式 → 建议批量模式
+   - 简单 CRUD → 不拆
+2. 如果需要拆分/批量模式：暂停等用户确认
+   - 调用：\`sillyspec run brainstorm --wait --reason "等待用户确认拆分方案" --options "同意拆分,不需要拆分,走批量模式" --output "拆分方案摘要"\`
+3. 不需要拆分 → 继续
+
+#### D. 方案设计（自动决策优先）
+1. 基于需求理解和上下文，提出 1-3 种实现方案
+2. **使用自动决策 checklist（AC-001~AC-010）判断是否需要用户选择：**
+
+\`\`\`
+AC-001: 未修改公共 API
+AC-002: 未修改数据库 schema
+AC-003: 未涉及鉴权/权限
+AC-004: 未扩大 allowed_paths
+AC-005: 未引入新外部依赖
+AC-006: 未修改核心模块（workflow/daemon/session/lifecycle）
+AC-007: 已有项目约定可复用
+AC-008: 不影响向后兼容
+AC-009: 不涉及数据迁移
+AC-010: 单模块范围内可完成
+\`\`\`
+
+3. **自动决策判定：**
+   - 只有一个明显合理方案 + checklist 全部 ✅ → **自动选择，标记 AUTO_DECIDED**
+   - 有多个方案但影响不大（checklist 全部 ✅）→ **自动选推荐方案，标记 AUTO_DECIDED**
+   - 有多个方案且 checklist 有 ❌（影响架构/数据/接口/权限/兼容性）→ **只有这一种情况才暂停等用户选择**
+
+4. 如果需要用户选择方案：
+   - 调用：\`sillyspec run brainstorm --wait --reason "等待用户选择方案" --options "方案A,方案B,方案C" --output "方案对比摘要"\`
+
+#### E. Design Grill（轻量交叉审查）
+对方案做快速交叉审查：
+- 检查方案与 ARCHITECTURE.md / CONVENTIONS.md 的一致性
+- 检查是否有术语歧义、边界遗漏
+- 能自动解决的直接修正，只有需要业务判断的才问用户
+- 跳过条件：单模块、无状态流转、< 3 个文件变更
+
+### 输出
+需求理解摘要 + 复杂度评估 + 方案决策（AUTO_DECIDED 或用户选择）
+
+### 注意
+- **不要自问自答。** 不要在自己输出中模拟用户回答然后说"需求已明确"
+- checklist 判定结果必须在 decisions.md 中记录依据`,
+      outputHint: '需求理解 + 方案决策',
+      optional: false
+    },
+    {
+      name: '生成设计产物',
+      prompt: `将设计方案写入文件（artifact-first），不回显正文。
+
+### 操作
+1. 确保变更目录存在：\`mkdir -p .sillyspec/changes/<change-name>/brainstorm\`
+2. **直接将设计方案写入文件，不要先在对话中输出完整内容再写文件。**
+
+### 产物文件
+
+#### design.md（必填，写入 \`brainstorm/design.md\`）
+包含：背景、设计目标、非目标、总体方案、文件变更清单、接口定义、数据模型（如涉及）、兼容策略（brownfield）、风险登记、决策追踪。
+
+#### decisions.md（必填，写入 \`brainstorm/decisions.md\`）
+记录所有决策：
+\`\`\`markdown
+## D-001@v1: 决策短标题
+- type: architecture | boundary | compatibility | ...
+- priority: P0 | P1 | P2
+- status: AUTO_DECIDED | NEEDS_REVIEW | USER_DECIDED
+- source: user | code | docs
+- question: 被解决的问题
+- answer: 选择或结论
+- checklist: AC-001 ✅, AC-007 ✅（AUTO_DECIDED 时必须列出）
+- normalized_requirement: 可测试约束
+- impacts: [FR-01, task-01]
+- evidence: 代码/文档路径或用户回答轮次
+\`\`\`
+
+#### gaps.md（必填，写入 \`brainstorm/gaps.md\`）
+记录已识别的缺口。status=BLOCKER 的缺口会在 plan-postcheck 中触发回退。
+
+#### assumptions.md（必填，写入 \`brainstorm/assumptions.md\`）
+记录隐含假设和验证方法。
+
+#### next-action.json（必填，写入 \`brainstorm/next-action.json\`）
+\`\`\`json
+{
+  "status": "ready_for_plan" | "waiting_for_user",
+  "decision_level": "high" | "medium" | "low",
+  "has_blocking_questions": true | false,
+  "blocking_reasons": [],
+  "questions": [],
+  "auto_decisions": [
+    { "id": "D-001", "decision": "方案描述", "reason": "AC-007 ✅" }
+  ]
+}
+\`\`\`
+
+### 自审
+对 design.md 执行自审（需求覆盖、文件变更清单具体性、验收标准可测试、非目标清晰、兼容策略）。发现问题直接修改文件。
+
+### 如果有 blocking questions
+将问题写入 next-action.json.questions，在对话中输出问题列表和推荐选项，然后 --wait。
+
+### 输出（artifact-first）
+只输出摘要：
+\`\`\`
+已生成设计产物（5 个文件）：
+- brainstorm/design.md — 采用 xxx 方案，涉及 N 个文件变更
+- brainstorm/decisions.md — M 个决策，K 个 AUTO_DECIDED
+- brainstorm/gaps.md — J 个缺口，0 个 BLOCKER
+- brainstorm/assumptions.md — L 个假设
+- brainstorm/next-action.json — ready_for_plan / waiting_for_user
+\`\`\``,
+      outputHint: '产物摘要',
+      optional: false
+    },
+    {
+      name: '生成规范文件',
+      requiresWait: true,
+      waitReason: '等待用户最终确认',
+      waitOptions: ['确认', '需要修改', '推翻重来'],
+      prompt: `生成 proposal.md / requirements.md / tasks.md，让用户确认。
+
+### 操作
+1. 基于 brainstorm/ 下的设计产物，生成规范文件（直接写文件）：
+   - **proposal.md**：动机、关键问题、变更范围、不在范围内、成功标准
+   - **requirements.md**：角色表 + FR 编号需求 + Given/When/Then + 非功能需求
+   - **tasks.md**：任务列表（只列名称，细节在 plan 阶段展开）
+2. 如果 brainstorm/decisions.md 有 AUTO_DECIDED 决策，在变更根目录也写一份 decisions.md
+3. 所有规范文件头部包含 YAML frontmatter
+4. \`git add .sillyspec/\` — 暂存规范文件（不要 commit）
+
+### 输出（摘要）
+规范文件路径列表（各一句话说明）
+
+### 铁律
+- **直接写文件，不在对话中输出完整内容**
+- 暂停等待用户确认：\`sillyspec run brainstorm --wait --reason "等待用户最终确认" --options "确认,需要修改,推翻重来" --output "规范文件摘要"\`
+- 禁止自动 commit
+- 禁止在确认前推进到后续阶段`,
+      outputHint: '规范文件摘要',
+      optional: false
+    }
+  ]
+}

package/src/stages/scan.js

@@ -62,9 +62,26 @@ export const definition = {
 - 最终确定的项目列表将用于后续所有步骤
 - **后续每个需要生成文档的步骤，都必须对列表中的每个项目分别执行**
 
-### 输出
-确认后的扫描项目列表（项目名 + 扫描策略）`,
-      outputHint: '扫描项目列表',
+### 输出格式规范
+--output 必须使用以下结构化格式之一（CLI 只解析这些格式，**不要输出自由文本列表**）：
+
+**格式 A：scan_projects YAML block**
+在 --output 中输出：
+    scan_projects:
+      - id: backend
+      - id: frontend
+      - id: daemon
+
+**格式 B：BEGIN_PROJECT_LIST 标记块**
+在 --output 中输出：
+    BEGIN_PROJECT_LIST
+    - backend
+    - frontend
+    - daemon
+    END_PROJECT_LIST
+
+如果不需要解析项目列表（如单项目已明确），--output 写普通摘要即可。`,
+      outputHint: '结构化项目列表（YAML block 或 BEGIN_PROJECT_LIST）',
       optional: false
     },
     {

package/test/run-scan-project-parse.test.mjs

@@ -1,13 +1,13 @@
 /**
- * task-09 集成：编号正则收紧 + sanitize 联动
+ * scan step 2 项目列表解析 — 强契约测试
  *
- * 模拟 run.js:2176 处的解析逻辑（正则 + raw 处理 + sanitizeProjectName + filter(Boolean)）
- * 验证：
- * - "1. frontend\n2. 0\n3. 7\n4. order-service" → ['frontend', 'order-service']（"0"/"7" 被拒）
- * - 步骤说明"1. 执行 init"不进 projectNames（中文不匹配 [a-zA-Z] 开头）
- * - 兜底分支不被污染（outputText 为空 → 走兜底）
+ * 解析只接受两种结构化格式：
+ *   A) YAML block: scan_projects:\n  - id: name
+ *   B) BEGIN_PROJECT_LIST ... END_PROJECT_LIST
+ *
+ * 自由文本列表不再解析，防止误识别垃圾项目名。
  */
-import { sanitizeProjectName } from '../src/run.js'
+import { sanitizeProjectName, validateParsedProjects } from '../src/run.js'
 
 let passed = 0
 let failed = 0
@@ -17,60 +17,183 @@ function assertDeepEqual (actual, expected, msg) {
   if (a === e) { console.log(`✅ PASS: ${msg}`); passed++ }
   else { console.error(`❌ FAIL: ${msg}\n   expected: ${e}\n   actual:   ${a}`); failed++ }
 }
+function assertEqual (actual, expected, msg) {
+  if (actual === expected) { console.log(`✅ PASS: ${msg}`); passed++ }
+  else { console.error(`❌ FAIL: ${msg}\n   expected: ${expected}\n   actual:   ${actual}`); failed++ }
+}
+function assertIncludes (str, sub, msg) {
+  if (str.includes(sub)) { console.log(`✅ PASS: ${msg}`); passed++ }
+  else { console.error(`❌ FAIL: ${msg}\n   expected to include: ${sub}\n   actual: ${str}`); failed++ }
+}
 
-// 复刻 run.js:2175-2179 的解析链路
-// task-05 B2 延伸修正：编号解析链 .replace 只针对中文长破折号 `—`，
-// 不再误伤 ASCII `-`（否则 order-service 会被切成 order）。
-function parseNumberedList(outputText) {
-  if (!outputText) return []
-  const numbered = outputText.match(/^\s*\d+\.\s+([a-zA-Z][\w\-.]*)/gm)
-  if (!numbered) return []
-  const raw = numbered.map(m => m.replace(/^\s*\d+\.\s+/, '').replace(/—.*$/, '').trim())
-  return raw.map(sanitizeProjectName).filter(Boolean)
+// ---- 复刻 run.js 中新的解析逻辑 ----
+function parseProjectListFromOutput(outputText) {
+  let parsedProjects = [] // Array<{id, path?}>
+  let parsedFromStructuredOutput = false
+  if (outputText) {
+    // 格式 A: YAML block
+    const yamlBlock = outputText.match(/scan_projects:\s*\n([\s\S]+?)(?=$|\n[^\s])/)
+    if (yamlBlock) {
+      const entries = [...yamlBlock[1].matchAll(/-\s+id:\s*(\S+)(?:[\s\S]*?)(?=\n\s+-\s+id:|$)/g)]
+      for (const m of entries) {
+        const id = sanitizeProjectName(m[1])
+        if (!id) continue
+        const pathMatch = m[0].match(/path:\s*(\S+)/)
+        const entry = pathMatch ? { id, path: pathMatch[1].trim() } : { id }
+        parsedProjects.push(entry)
+      }
+      parsedFromStructuredOutput = parsedProjects.length > 0
+    }
+    // 格式 B: BEGIN_PROJECT_LIST
+    if (!parsedFromStructuredOutput) {
+      const blockMatch = outputText.match(/BEGIN_PROJECT_LIST\s*\n([\s\S]*?)\n*END_PROJECT_LIST/)
+      if (blockMatch) {
+        const raw = [...blockMatch[1].matchAll(/^-\s+(\S+)/gm)].map(m => m[1])
+        parsedProjects = raw.map(s => sanitizeProjectName(s)).filter(Boolean).map(id => ({ id }))
+        parsedFromStructuredOutput = parsedProjects.length > 0
+      }
+    }
+  }
+  return { parsedProjects, parsedFromStructuredOutput }
 }
 
-// 用例 1：脏数据列表（task-09 核心场景）+ ASCII 连字符保留（task-05 B2 延伸修正）
+// ======== 解析测试 ========
+
+// 1. YAML block 正常解析
 assertDeepEqual(
-  parseNumberedList('扫描项目列表：\n1. frontend\n2. 0\n3. 7\n4. order-service\n'),
-  ['frontend', 'order-service'],
-  '脏数据列表：纯数字被拒（task-09）；order-service 完整保留（ASCII - 不再被误切）'
+  parseProjectListFromOutput(`scan_projects:
+  - id: backend
+  - id: frontend
+  - id: daemon
+`).parsedProjects,
+  [{ id: 'backend' }, { id: 'frontend' }, { id: 'daemon' }],
+  'YAML block 正常解析 3 个项目'
 )
 
-// 用例 2：步骤说明干扰（方案 A 边界）
+// 2. YAML block 带 path 字段（多行属性）
+const r2 = parseProjectListFromOutput(`scan_projects:
+  - id: api
+    path: backend/
+  - id: web
+    path: frontend/
+`).parsedProjects
+assertDeepEqual(r2, [{ id: 'api', path: 'backend/' }, { id: 'web', path: 'frontend/' }],
+  'YAML block 带 path 字段正常解析')
+
+// 3. BEGIN_PROJECT_LIST 正常解析
 assertDeepEqual(
-  parseNumberedList('以下是步骤：\n1. 执行 init\n2. 启动 scan\n3. frontend\n'),
-  ['frontend'],
-  '步骤说明中"1. 执行 init"中文不匹配，仅"3. frontend"入选'
+  parseProjectListFromOutput(`BEGIN_PROJECT_LIST
+- backend
+- frontend
+- daemon
+END_PROJECT_LIST`).parsedProjects,
+  [{ id: 'backend' }, { id: 'frontend' }, { id: 'daemon' }],
+  'BEGIN_PROJECT_LIST 标记块正常解析'
 )
 
-// 用例 3：英文步骤说明干扰（方案 A 已知边界，task-09 §TDD 第 5 步）
-// 注：英文"1. Run scan"会匹配到 "Run"，经 sanitize 通过。这是方案 A 的已知边界，
-// task-09 §实现要求 2 选 A 的前提是"sanitizeProjectName 字母校验双保险"——
-// 纯数字场景已解决（本任务目标），英文步骤误匹配留待 execute 发现再切方案 B。
-const r3 = parseNumberedList('Steps:\n1. Run scan first\n2. backend\n')
+// 4. 自由文本编号列表 → 不解析
+const { parsedProjects: fn, parsedFromStructuredOutput: fnParsed } =
+  parseProjectListFromOutput('扫描项目列表：\n1. scan1backendmulti-agent-platform-api FastAPI Python\n2. frontendmulti-agent-platform-web Next.js TS\n3. sillyhub-daemon Node.js TS')
+assertEqual(fnParsed, false, '自由文本编号列表不触发解析')
+assertDeepEqual(fn, [], '自由文本编号列表不产生任何项目名')
+
+// 5. 自由文本括号枚举 → 不解析
+const { parsedProjects: fn2, parsedFromStructuredOutput: fn2Parsed } =
+  parseProjectListFromOutput('子项目: backend / frontend / user-service')
+assertEqual(fn2Parsed, false, '自由文本括号枚举不触发解析')
+assertDeepEqual(fn2, [], '自由文本括号枚举不产生任何项目名')
+
+// 6. 空 outputText → 不解析
+const { parsedFromStructuredOutput: emptyParsed } = parseProjectListFromOutput('')
+assertEqual(emptyParsed, false, '空 outputText 不触发解析')
+
+// 7. 普通摘要文本 → 不解析
+const { parsedProjects: summary, parsedFromStructuredOutput: summaryParsed } =
+  parseProjectListFromOutput('确认扫描 3 个子项目：backend、frontend、daemon，全部重新扫描')
+assertEqual(summaryParsed, false, '普通摘要文本不触发解析')
+assertDeepEqual(summary, [], '普通摘要文本不产生任何项目名')
+
+// ======== validateParsedProjects — 基础校验 ========
+
+// 8. 正常列表（无 path）
 assertDeepEqual(
-  r3,
-  ['Run', 'backend'],
-  '英文步骤会误匹配（方案 A 已知边界，纯数字目标已达成）'
+  validateParsedProjects([{ id: 'backend' }, { id: 'frontend' }, { id: 'daemon' }], '/tmp/proj'),
+  { ok: true, errors: [] },
+  '正常列表校验通过（无 path）'
 )
 
-// 用例 4：空 outputText
-assertDeepEqual(parseNumberedList(''), [], '空 outputText 返回空列表')
-
-// 用例 5：含下划线/点的项目名（避开既有 -replace bug，专测 sanitize）
+// 9. 正常列表（有合法 path）——需要用真实路径
+import { mkdtempSync, mkdirSync, writeFileSync, rmSync } from 'fs'
+import { join } from 'path'
+import os from 'os'
+const tmpDir = mkdtempSync(join(os.tmpdir(), 'sillyspec-test-'))
+mkdirSync(join(tmpDir, 'backend'))
+mkdirSync(join(tmpDir, 'frontend'))
 assertDeepEqual(
-  parseNumberedList('1. app.v2\n2. web_api\n'),
-  ['app.v2', 'web_api'],
-  '合法项目名（点/下划线）保留'
+  validateParsedProjects([
+    { id: 'backend', path: 'backend' },
+    { id: 'frontend', path: 'frontend' }
+  ], tmpDir),
+  { ok: true, errors: [] },
+  '合法 path 校验通过'
 )
 
-// 用例 6：0/7 这种斜杠分隔的会被单条编号捕获再 sanitize 拒绝
+// 10. path 不存在 → 失败
+const v10 = validateParsedProjects([{ id: 'backend', path: 'nonexistent' }], tmpDir)
+assertEqual(v10.ok, false, 'path 不存在校验失败')
+assertIncludes(v10.errors[0], '不存在', '错误提示包含"不存在"')
+
+// 11. path 含 .. 越界 → 失败
+const v11 = validateParsedProjects([{ id: 'backend', path: '../etc/passwd' }], tmpDir)
+assertEqual(v11.ok, false, 'path 包含 .. 校验失败')
+assertIncludes(v11.errors[0], '..', '错误提示包含 ..')
+
+// 12. path 解析后超出 source_root → 失败
+const v12 = validateParsedProjects([{ id: 'backend', path: '/etc/passwd' }], tmpDir)
+assertEqual(v12.ok, false, '绝对路径超出 source_root 校验失败')
+assertIncludes(v12.errors[0], '超出', '错误提示包含"超出"')
+
+// 13. 超过 10 个项目 → 失败
+const many = Array.from({ length: 11 }, (_, i) => ({ id: `project${i}` }))
+const v13 = validateParsedProjects(many, tmpDir)
+assertEqual(v13.ok, false, '超过 10 个项目校验失败')
+assertIncludes(v13.errors[0], '超过上限', '错误提示包含"超过上限"')
+
+// 14. 重复项目名 → 失败
+const v14 = validateParsedProjects([{ id: 'backend' }, { id: 'frontend' }, { id: 'backend' }], tmpDir)
+assertEqual(v14.ok, false, '重复项目名校验失败')
+assertIncludes(v14.errors[0], '重复', '错误提示包含"重复"')
+
+// 15. 非法 slug（中文）→ 失败
+const v15 = validateParsedProjects([{ id: 'backend' }, { id: '前端服务' }], tmpDir)
+assertEqual(v15.ok, false, '非法 slug 校验失败')
+
+// 16. 空列表 → 失败
+const v16 = validateParsedProjects([], tmpDir)
+assertEqual(v16.ok, false, '空列表校验失败')
+
+// 17. null 列表 → 失败
+const v17 = validateParsedProjects(null, tmpDir)
+assertEqual(v17.ok, false, 'null 列表校验失败')
+
+// 18. 单字符 → 失败
+const v18 = validateParsedProjects([{ id: 'a' }], tmpDir)
+assertEqual(v18.ok, false, '单字符项目名校验失败')
+
+// 19. 纯数字 → 失败
+const v19 = validateParsedProjects([{ id: '123' }], tmpDir)
+assertEqual(v19.ok, false, '纯数字项目名校验失败')
+
+// 20. 兼容旧 API（纯字符串数组）
 assertDeepEqual(
-  parseNumberedList('1. 0/7\n2. frontend\n'),
-  ['frontend'],
-  '"0/7" 单条：正则匹配失败（首字符 0 非字母）→ 整条丢弃'
+  validateParsedProjects(['backend', 'frontend'], tmpDir),
+  { ok: true, errors: [] },
+  '旧 API 兼容：纯字符串数组仍通过'
 )
 
+// 清理
+rmSync(tmpDir, { recursive: true, force: true })
+
 console.log(`\n${'='.repeat(50)}`)
 console.log(`✅ 通过: ${passed}  ❌ 失败: ${failed}`)
 console.log(`${'='.repeat(50)}`)

package/test/scan-postcheck.test.mjs

@@ -106,11 +106,10 @@ console.log('\n=== Test 4: local.yaml 命令不存在 → completed_with_warning
 }
 
 // ── 5-8: AI 输出错误标记 → warnings ──
+// 注意：tool_use_error 和 fallback 已移除（agent 描述性文本正常提及不应触发）
 const errorCases = [
-  { id: 'e5', name: 'tool_use_error', output: 'tool_use_error: file not found' },
-  { id: 'e6', name: 'API Error 529', output: 'API Error 529 server overloaded' },
-  { id: 'e7', name: 'rate_limit', output: 'rate limit exhausted' },
-  { id: 'e8', name: 'fallback', output: 'fallback to default, skipped validation' },
+  { id: 'e6', name: 'API Error 529', output: 'API Error 529 server overloaded. API Error 529 retry failed' },
+  { id: 'e7', name: 'rate_limit', output: 'rate limit exhausted, rate limit exhausted again' },
 ]
 for (const ec of errorCases) {
   console.log(`\n=== Test: ${ec.name} → completed_with_warnings ===`)
@@ -121,6 +120,21 @@ for (const ec of errorCases) {
   clean(cwd, spec)
 }
 
+// ── tool_use_error / fallback 不再触发 warning（描述性文本正常提及） ──
+const noWarnCases = [
+  { id: 'e5', name: 'tool_use_error', output: 'tool_use_error: file not found' },
+  { id: 'e8', name: 'fallback', output: '作为 fallback 方案，跳过了这个步骤' },
+]
+for (const ec of noWarnCases) {
+  console.log(`\n=== Test: ${ec.name} → 不触发 warning ===`)
+  const cwd = setup(ec.id), spec = specSetup(ec.id)
+  writeFull(cwd, spec)
+  const r = runScanPostCheck({ cwd, specDir: spec, outputText: ec.output })
+  assert(!r.checks.some(c => c.name === 'tool_use_error' || c.name === 'fallback_or_skip'),
+    `${ec.name}: 不应有 tool_use_error/fallback_or_skip warning`)
+  clean(cwd, spec)
+}
+
 // ── 9: 文档缺 header → warnings ──
 console.log('\n=== Test 9: 文档缺 header → completed_with_warnings ===')
 {

package/.npmrc-tmp

@@ -1 +0,0 @@
-//registry.npmjs.org/:_authToken=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