sillyspec 3.26.8 → 3.26.10

package/src/stages/plan-postcheck.js

@@ -14,7 +14,7 @@ import { existsSync, readFileSync as _readFileSync, readdirSync, mkdtempSync, wr
 // frontmatter/字段正则（`^---\n`、`allowed_paths:\s*\n…`、`^goal:` 等）失配，报「缺 frontmatter
 // /缺字段」假错误（见缺陷 windows-python-crlf-taskcard）。读取时统一转 LF，一处覆盖全部正则。
 const readFileSync = (filePath, encoding) => _readFileSync(filePath, encoding).replace(/\r\n/g, '\n')
-import { join as pJoin } from 'path'
+import { join as pJoin, basename } from 'path'
 import { tmpdir } from 'os'
 import jsYaml from 'js-yaml'
 import { parseFileChangeList, pathMatches } from '../change-list.js'
@@ -1178,6 +1178,27 @@ export async function executePlanPostcheck(context) {
     console.log(`  ✅ design.md ${coverage.designFiles.length} 个文件全部被 task allowed_paths 覆盖`)
   }
 
+  // ── 1e. 阶段完成产物校验（plan stage contract）──
+  // plan 完成 gate 还会跑 stage-contract.validatePlanOutputs；为免「postcheck 通过 →
+  // stage gate 又报 module-impact 缺失/entry-point-wiring 未覆盖」的修一层撞一层，
+  // 在此把 stage contract 的 error/warning 也聚合进本轮输出。
+  const { validatePlanOutputs } = await import('../stage-contract.js')
+  if (typeof validatePlanOutputs === 'function') {
+    const contract = validatePlanOutputs(context.cwd, basename(changeDir), { specRoot })
+    if (contract.errors.length > 0) {
+      failures.push({
+        name: 'plan 阶段产物契约校验（stage-contract validatePlanOutputs）',
+        errors: contract.errors,
+        hint: '修复方式：补缺失产物（如 module-impact.md）、在 design.md 明示不改理由、或修正 task allowed_paths 覆盖 design.md 提及的入口文件。',
+      })
+    }
+    if (contract.warnings.length > 0) {
+      for (const w of contract.warnings) {
+        console.warn(`\n  ⚠️  ${w}`)
+      }
+    }
+  }
+
   // ── 聚合输出：一轮 --done 暴露全部失败项（坑6③）──
   if (failures.length > 0) {
     console.error(`\n❌ plan postcheck 失败（${failures.length} 类问题，已全部列出——一次修复后重跑，无需逐个迭代）：`)

package/src/stages/plan.js

@@ -113,6 +113,9 @@ needs_human_review: true | false
 
 然后列出已加载的文件清单（含 decisions.md 当前版本/未决项状态、模块文档 + 模块依赖关系摘要）。
 
+### 落盘锚点（必须执行）
+把 plan_level 写进 plan.md frontmatter（\`plan_level: <none|light|full>\`）——上一步分类结果在本步落盘为持久锚点，后续步骤（及 context 压缩后的恢复）一律读 plan.md frontmatter，不依赖对话记忆传递。
+
 分类完成后，继续进入下一步。`,
   outputHint: '复杂度分类结果 + 文件清单',
   optional: false
@@ -125,13 +128,13 @@ needs_human_review: true | false
 const stepGeneratePlan = {
   id: 'generate_plan',
   name: '生成分级计划',
-  prompt: `根据上一步的 plan_level 结果，按对应级别生成计划。
+  prompt: `根据 plan.md frontmatter 的 plan_level 结果，按对应级别生成计划。
 
 ### 操作
-1. 读取上一步输出的 plan_level 分类结果
+1. 读取 plan.md frontmatter 的 \`plan_level:\` 字段（上一步已落盘为持久锚点；文件不存在或无该字段时回退读上一步输出的分类结果）
 2. 读取 tasks.md 和 design.md 了解需求范围
 3. 按 plan_level 选择对应模板输出
-4. 保存 plan.md（审查在下一步"审查计划"独立进行，不在本步自审——避免生成与自审同一次输出）
+4. 保存 plan.md（审查在下一步"审查计划"独立进行，不在本步自审——避免生成与自审同一次输出）；frontmatter 保留 plan_level 字段不删
 
 ---
 
@@ -283,7 +286,7 @@ full 计划的约束：
 ### 通用操作（所有级别）
 1. 读取 tasks.md 获取任务列表
 2. 读取 design.md 获取文件变更清单
-3. 读取上一步的 plan_level 分类结果
+3. 读取 plan.md frontmatter 的 \`plan_level:\` 字段（持久锚点；缺失时回退上一步输出）
 4. 按对应级别模板生成内容
 5. 保存到变更目录下的 plan.md（路径格式：\`{SPEC_ROOT}/changes/<change-name>/plan.md\`，其中 <change-name> 是变更目录名，直接使用，不加子目录。正确路径示例：\`{SPEC_ROOT}/changes/2026-05-28-agent-log-streaming/plan.md\`）
 **plan_level 为 none 时生成最小 plan.md（占位），不生成完整蓝图。**
@@ -346,15 +349,25 @@ tier: {REVIEW_TIER}（{REVIEW_TIER_REASON}）
 ### 生成 module-impact.md 首版（scale≠small 时）
 计划审查通过后，顺带生成 module-impact.md 首版（本次变更的模块影响分析，供 execute/verify 阶段更新、archive 阶段终审）。scale=small 不生成（small 走 quick，module-impact 对 quick 无用）。
 
-输入（此时 TaskCard/allowed_paths 尚未生成——在下一步 generate_blueprints，故用以下两项作输入，粒度与 archive 现状一致）：
+输入（此时 TaskCard/allowed_paths 尚未生成——在下一步「生成 TaskCard」才产出，故用以下两项作输入，粒度与 archive 现状一致）：
 - design.md 的「文件变更清单」（本次计划改哪些源码文件）
 - plan.md 的任务列表（每个 task 改的范围）
 
-步骤（复用 archive extract-module-impact 的核心指引，同源——改 archive step2 prompt 时保持一致）：
+步骤（module-impact 的生成口径与 archive 终审一致）：
 1. 读 {SPEC_ROOT}/docs/<project>/modules/_module-map.yaml（模块→文件路径映射）。**不存在 → 降级**：生成只含 unmapped 部分的 module-impact.md + 提示「建议运行 scan 生成模块映射」，不阻断
 2. 对照 design 文件变更清单 + plan 任务列表，逐文件匹配所属模块（命中的归 mapped，未命中的归 unmapped）
 3. 生成模块影响矩阵（模块 × 影响类型[新增/修改/删除/依赖变更] × 说明），落盘 {SPEC_ROOT}/changes/<change>/module-impact.md
 4. 首行标题必须用中文：# 模块影响分析（Module Impact）— <变更简述>
+5. **必须含「更新结果」表骨架**（本表是 verify/archive 死信门控的收口目标——CLI 硬校验表内无 pending/待办行，漏写此表则 agent 只能从 gate 报错反推格式）：
+   \`\`\`markdown
+   ## 更新结果
+
+   | 目标 | 操作 | 状态 |
+   |------|------|------|
+   | \`modules/<id>.md\` | 更新<模块名>模块卡（本次变更涉及） | pending |
+   | \`_module-map.yaml\` | 无变化（未增删模块） | skipped |
+   \`\`\`
+   规则：每个受影响模块文档一行，状态列初始化 pending；无变化的行直接写 skipped。execute/verify 完成文档同步后把对应行回填 done；确定不同步的行改 skipped 并在操作列写明原因。**末列是状态列**（done/skipped/pending），不要在表尾追加其他列。
 
 execute/verify 阶段会按实际代码变更更新此文档；archive 阶段会最终确认它。
 
@@ -371,8 +384,10 @@ execute/verify 阶段会按实际代码变更更新此文档；archive 阶段会
 // ═══════════════════════════════════════════════════════════════
 
 /**
- * 构建紧凑 TaskCard 协调器步骤（单步，子代理并行写卡片）
+ * 构建紧凑 TaskCard 协调器步骤（单步，子代理按 batch 并行写卡片）
  * 每个 task 生成 20~40 行紧凑可执行卡片
+ * 允许把多个相关 task 合并为一个 batch，由单个子代理一次生成多张卡片，
+ * 在保留 plan 任务拆分完整性的同时减少子代理调用数量。
  */
 export function buildCoordinatorStep(changeDir, taskNames) {
   const taskList = taskNames.map(t => {
@@ -380,23 +395,9 @@ export function buildCoordinatorStep(changeDir, taskNames) {
     return `- task-${num}: ${t.name}`
   }).join('\n')
 
-  const subagentPrompts = taskNames.map(t => {
-    const num = t.num
-    return `\`\`\`
-任务编号：task-${num}
-任务名称：${t.name}
-文件路径：${changeDir}/tasks/task-${num}.md
-当前时间：<now-datetime>（frontmatter 的 created_at 使用此值）
-当前用户：<git-user>（frontmatter 的 author 使用此值）
-
-操作：
-1. 读取 ${changeDir}/design.md 和 ${changeDir}/plan.md 了解上下文
-2. 读取相关源文件了解现有代码
-3. 生成紧凑 TaskCard（20~40 行），格式如下：
-
----
-id: task-${num}
-title: ${t.name}
+  const taskcardTemplate = `---
+id: <task-id>
+title: <task-name>
 title_zh: <任务中文标题>
 author: <git-user>
 created_at: <now-datetime>
@@ -434,10 +435,7 @@ related_tests:                           # 可选。当本 task 改动会导致
     reason: 旧断言假设单例，改归属键后需同步
 ---
 
-{{include: taskcard-rules}}
-\`\`\``
-  }).join('\n\n')
-
+{{include: taskcard-rules}}`
 
   const prompt = `为 plan.md 中的每个任务生成紧凑 TaskCard。
 
@@ -455,22 +453,58 @@ ${taskList}
 
 ## 执行方式（必须严格遵守）
 
-**你必须使用 Agent tool 启动子代理来写每个卡片，不要自己写。**
+**你必须使用 Agent tool 启动子代理来写卡片，不要自己写。**
 
 1. 确认 \`${changeDir}/tasks/\` 目录存在（不存在则创建）
-2. 为每个任务启动一个独立子代理（Agent tool），可并行启动多个
-3. 每个子代理使用对应的 prompt（见下方模板）
-4. 等待所有子代理完成
-5. 验证每个 task-N.md 文件已生成且非空
-
-### 子代理 prompt 模板
-为每个任务使用以下 prompt 启动子代理：
-
-${subagentPrompts}
+2. **按 batch 分派子代理（减少总子代理数量，而不是一个 task 一个子代理）：**
+   - 把任务按「同一 Wave + 同一模块/相近能力 + 无跨 batch 强依赖」原则分组
+   - **每个 batch 包含 2~4 个 task**；Wave 内任务数 ≤4 时整个 Wave 可作为一个 batch
+   - 有提供/消费契约的 task 尽量放到同一 batch（子代理能同时看到 consumer 与 provider，避免契约字段漏配）
+   - 跨 Wave 依赖的 task 不要放在同一 batch（子代理只需读 plan.md，但 batch 内 task 的 allowed_paths 不应互相阻塞）
+3. 为每个 batch 启动一个独立子代理（Agent tool），可并行启动多个 batch
+4. 每个子代理使用下方「批量 TaskCard 子代理 prompt」，一次生成该 batch 的全部 task-N.md
+5. 等待所有 batch 子代理完成
+6. 验证每个 task-N.md 文件已生成且非空
+
+> 设计意图：plan.md 里 task 数可以较多（能力拆分完整），但 TaskCard 生成阶段要合理合并，避免子代理数量随 task 数线性爆炸。一个子代理生成 2~4 张卡片与生成 1 张卡片的 token/时间成本接近，却能显著减少协调开销。
+
+### 批量 TaskCard 子代理 prompt
+\`\`\`
+你是一个专注的 TaskCard 生成器。你的任务是为指定 batch 生成全部 TaskCard。
+
+## 输入
+- 变更目录：${changeDir}
+- 当前时间：<now-datetime>（frontmatter 的 created_at 使用此值）
+- 当前用户：<git-user>（frontmatter 的 author 使用此值）
+- 本 batch 任务列表：
+  <由主 agent 注入：task-01: 名称 / task-02: 名称 / ...>
+
+## 操作
+1. 读取 ${changeDir}/design.md 和 ${changeDir}/plan.md 了解整体上下文
+2. 读取本 batch 涉及的相关源文件
+3. 为 batch 中的**每一个 task 独立生成**一个 task-N.md 文件
+4. 每个文件使用如下模板（把 <task-id> / <task-name> 替换为具体编号和名称）：
+
+${taskcardTemplate}
+
+## 约束
+- 每个 task 20~40 行；禁止在 TaskCard 里写实现细节之外的冗长设计
+- 同 batch 内 task 的 allowed_paths 不要互相冲突
+- 若 task 之间有 provides/expects_from 契约，同 batch 生成时必须字段对齐
+- 只生成本 batch 声明的任务，不要多写或少写
+- 不要在 TaskCard 里泄露 plan.md 中未出现的实现假设
+
+## 完成标志
+- 本 batch 的每个 task-N.md 都已写入 ${changeDir}/tasks/
+- 每个文件非空且 frontmatter 完整
+\`\`\`
 
 ## 验收（生成后自查，不另开步骤）
 - 每个 task-N.md 文件存在且非空
-- frontmatter 包含：id、title、author、created_at、priority、depends_on、blocks、allowed_paths、goal、implementation、acceptance、verify、constraints
+- 所有 task 都被某个 batch 覆盖、无遗漏、无重复
+- frontmatter 字段分两组对照（与 plan-postcheck / taskcard-rules.md 同源，三处清单以此为准）：
+  - **硬校验 9 字段**（缺失 plan-postcheck 直接报错阻断）：id、title、title_zh、allowed_paths、goal、implementation、acceptance、verify、constraints
+  - **规范约定 5 字段**（应填但缺失只影响规范性，不阻断）：author、created_at、priority、depends_on、blocks
 - 每个 task 总长度 20~40 行
 - **一致性自查**：
   - allowed_paths 有无冲突
@@ -481,7 +515,7 @@ ${subagentPrompts}
 
   return {
     id: 'generate_blueprints',
-    name: '生成 TaskCard（子代理并行）',
+    name: '生成 TaskCard（子代理按 batch 并行）',
     prompt,
     outputHint: 'TaskCard 生成结果',
     optional: false

package/src/stages/quick.js

@@ -12,6 +12,12 @@ export const definition = {
 - CLI 是短进程，run 与 done 是独立进程，sessionId 靠 --change 跨进程传递
 - **完成每个 step 必须带 --change <quick-session-id>**（命令由 CLI 在下方注入）；多会话并发时不带会命中他者会话状态
 
+### ⚠️ 危险文件预声明（预判要改 src 核心时看一眼）
+step 3 --done 审计会把 src 核心文件（CLI / 状态机 / 注入框架等危险清单）、新增文件、删除文件判为危险变更并拦截。若你**预判**本 quick 的修复目标本身就是这类文件，重新启动 quick 时带上 --force-baseline（受保护/危险文件）/ --allow-new（新增文件）/ --allow-delete（删除文件）预声明——flag 会持久化进会话守卫，后续 --done 直接生效，省一轮拦截重跑。不预带也可：step 3 拦截后按提示带 flag 重跑 --done 同样解锁。
+
+### 🧭 文件预声明（多 agent 并发仓库推荐）
+--done 审计按「时间窗 diff」归属文件：quick 窗口内**并行会话**改的文件也会被算进本会话的 QUICKLOG「文件：」行。多个 agent 同时操作本仓库时，启动 quick 建议带 \`--files <a.js,b.js>\` 声明预计要改的文件——声明即归属：文件行只落声明命中的文件，窗口内未声明脏文件以「审计：」行落盘追溯（不混入、不静默丢）。不预判也行：--done 后按 QUICKLOG 核对说明手动精修文件行兜底。
+
 ### 操作
 1. 检查关联变更（\`<linked-changes>\`，逗号分隔的变更名列表；显示「（无）」= 不关联变更），确定记录方式
 2. 理解任务：模糊则问一个问题确认
@@ -33,7 +39,7 @@ export const definition = {
 
 **你不要创建或修改任何 QUICKLOG 的条目骨架 / tasks.md 记录**——ql-ID 分配、「进行中」条目、状态翻转、task 勾选、轮转全由 CLI 接管，你无需手写。<quicklog-id> 可用于 design.md / plan.md / archive / 模块变更索引引用。
 
-> ℹ️ step 3 --done 时，CLI 已落盘结构化 QUICKLOG 条目（标题从「需求：」提取、正文四字段分行、文件行可用 --file-notes 写多行括注）。事后只需按需核对，详见 step 3「QUICKLOG 正文核对」。
+> ℹ️ step 3 --done 时，CLI 已落盘结构化 QUICKLOG 条目（标题从「需求：」提取——届时写一句语义化短标题，规则见 step3 结果摘要模板；正文四字段分行、文件行可用 --file-notes 写多行括注）。事后只需按需核对，详见 step 3「QUICKLOG 正文核对」。
 
 ### 输出
 任务理解 + 上下文摘要`,
@@ -76,12 +82,14 @@ export const definition = {
 \`--output\` 是 QUICKLOG「结果：」归档的唯一来源，**必须按此结构给全四项**（逐项一句话，不可用「见前述」替代）：
 
 \`\`\`
-需求：用户/任务要什么
+需求：一句话语义化短标题（写「改了什么」）
 根因：为什么这样改（若纯新增/配置/样式无根因，写「无，纯新增/纯样式」）
 方案：怎么改的
 结果：验证情况（测试数 / lint / typecheck / 部署状态）
 \`\`\`
 
+⚠️ **「需求：」就是 QUICKLOG 条目标题**——CLI 提取该字段、截到首个标点（，。；,;）、超 80 字再截断。写成完整需求长句会被截成语义不完整的状语前半段（如「在 X 时，…」标题只剩「在 X 时」），事后还得手改。一句话说清改了什么（如「登录限流修复——INCR 计数误清」），需求背景放「根因：/方案：」字段。
+
 缺任一项，\`--done\` 会被拒并提示缺失字段，补全后重跑即可（不丢进度）。
 
 ### 📎 文件括注 --file-notes（可选，省事后手改文件行）
@@ -97,7 +105,7 @@ sillyspec run quick --done --change <id> --output "需求：… 根因：… 方
 
 ### 收尾推荐顺序（模块文档在 --done 前，QUICKLOG 在 --done 后，别记混）
 1. 【--done 前】命中模块 → 改模块文档 → \`git add -- <模块文档>\`（见下方「模块文档同步」）
-2. 【--done】\`sillyspec run quick --done --change <id> --output "四字段" [--file-notes "..."]\`（CLI 自动翻完成 + 勾 task + 落盘 QUICKLOG 标题/文件/正文）
+2. 【--done】\`sillyspec run quick --done --change <id> --output "四字段" [--file-notes "..."]\`（CLI 自动翻完成 + 勾 task + 落盘 QUICKLOG 标题/文件/正文；若关联变更的 tasks.md 已全部勾选，CLI 还会自动归档该关联变更到 \`changes/archive/\`，无需手动跑 archive 阶段）
 3. 【--done 后】核对 QUICKLOG 标题（CLI 已从「需求：」自动提取，仅弱标题才手改）→ 若改了再 \`git add\`
 
 ### 操作
@@ -126,7 +134,7 @@ sillyspec run quick --done --change <id> --output "需求：… 根因：… 方
 ### 📝 QUICKLOG 正文核对（--done 之后，按需；多数无需手改）
 CLI 落盘的条目已是结构化产物（非简版骨架）：标题从「需求：」自动提取、正文四字段自动分行、文件行用 --file-notes 时为多行括注。--done 后只需核对，多数情况无需手改：
 
-1. 标题：CLI 已从「需求：」提取摘要刷新标题；仅当需求写得太弱（占位/笼统）才手改为真实需求摘要。
+1. 标题：CLI 已从「需求：」提取（截到首个标点、超 80 字截断）；按 step3 模板写成一句语义化短标题则无需手改，写成长句被截断时才手改。
 2. 文件：用了 --file-notes 已是多行括注；没传则回填审计到的实际文件单行，可事后补括注（示例见下）。
 3. 正文：四字段已分行落盘，按需扩写充实（不允许只留一段「结果：」）。
 
@@ -135,7 +143,7 @@ CLI 落盘的条目已是结构化产物（非简版骨架）：标题从「需
    - backend/app/modules/auth/router.py（登录端点串 check_rate_limit→assert_captcha_if_needed）
    - backend/app/modules/auth/captcha_service.py（新建：限流 INCR + 失败计数 + Pillow 滑块生成/校验）
 
-一条 quick = 一条独立 ql 条目；核对只动本次 <quicklog-id> 条目，不追加到旧条目。QUICKLOG 在 .sillyspec/（gitignore），核对不影响 --done 已通过的边界审计。`,
+一条 quick = 一条独立 ql 条目；核对只动本次 <quicklog-id> 条目，不追加到旧条目。QUICKLOG 在 .sillyspec/quicklog/（git 跟踪，--done 后需提交），核对不影响 --done 已通过的边界审计。`,
       outputHint: '暂存和记录确认',
       optional: false
     }

package/src/stages/scan.js

@@ -138,7 +138,7 @@ export const definition = {
    e. 等待该项目所有子代理完成后，验证文件是否生成且非空
    f. 该项目完成后，继续下一个项目
 3. 所有项目完成后，运行以下命令检查产物：
-   \`node -e "import('./src/workflow.js').then(w => { const r = w.runPostCheck(w.loadWorkflow('.', 'scan-docs'), '.', '<project>'); console.log(w.formatCheckReport(r)) })\`
+   \`sillyspec workflow check scan-docs --project <project>\`（CLI 子命令，任意项目根可用）
    对每个项目分别执行（将 \`<project>\` 替换为实际项目名）
 4. 如果检查报告有失败项，按报告中的角色和文件重试失败的部分
 
@@ -165,7 +165,7 @@ export const definition = {
 - 断点续扫步骤列出的缺失文档列表
 - 环境探测结果摘要（如有 _env-detect.md，直接贴入）
 - **⚠️ 必须强调：子代理必须用 write 工具将文件写入磁盘**
-- **文件标题用中文**（sillyhub 平台解析识别用）：frontmatter 必须在文件最前（第 1 行 --- 起），frontmatter 结束的 --- 之后空一行，再写 # 中文名（English）作为标题。严禁把 # 标题放到 frontmatter 之前（否则 frontmatter 不在头部、Step11 检查项9 会报缺 author/created_at）。各文档标准标题格式：
+- **文件标题用中文**（sillyhub 平台解析识别用）：frontmatter 必须在文件最前（第 1 行 --- 起），frontmatter 结束的 --- 之后空一行，再写 # 中文名（English）作为标题。严禁把 # 标题放到 frontmatter 之前（否则 frontmatter 不在头部、「检查产物完整性」步的 frontmatter 检查会报缺 author/created_at）。各文档标准标题格式：
   - STRUCTURE.md = # 目录结构（Structure）
   - CONVENTIONS.md = # 代码约定（Conventions）
   - ARCHITECTURE.md = # 架构（Architecture）
@@ -415,7 +415,7 @@ doc_type: module-card
 module_id: <module-id>
 ---
 
-# <module-id>
+# <中文名>（<module-id>）
 
 ## 定位
 （负责什么，不负责什么 — 明确边界）
@@ -437,6 +437,7 @@ module_id: <module-id>
 
 规则：
 - 不要编造接口或依赖，只写 grep/rg 能搜到的
+- 一级标题格式 \`# <中文名>（<module-id>）\`：中文名从模块职责提炼 2-8 字（如 认证与令牌、变更中心），括号内保留 module-id 原样——sillyhub 平台解析识别用
 - 目标长度：500-1000 字 / 80-150 行
 - 如果模块特别复杂（状态机、多角色交互、复杂领域规则），可以在 modules/details/ 下生成扩展文档（如 details/<module-id>-flow.md），agent 默认不读
 - 不要重复 _module-map.yaml 中的索引信息

package/src/stages/verify.js

@@ -75,7 +75,7 @@ export const definition = {
 ### Execute Evidence 传递检查
 7. 检查 verify-required-evidence.json 是否存在（由 execute 阶段 Task Review Gate 写入）
    - 路径：变更目录下的 verify-required-evidence.json
-   - 文件 schema：\`{ items: [{ task, verdict, evidence: string[] }] }\`——顶层是 \`items\`，每项的 \`evidence\` 是字符串数组（**不是** \`requiredEvidence\` 键；旧 prompt 写 requiredEvidence 是字段名错配，照读必落空）
+   - 文件 schema：\`{ items: [{ task, verdict, evidence: string[] }] }\`——顶层是 \`items\`，每项的 \`evidence\` 是字符串数组（不是 \`requiredEvidence\` 键）
    - 如果存在 → 逐项读取 \`items\`，对每个 cannot_verify 任务逐条核对其 \`evidence\` 数组是否已满足
    - 每条 evidence 必须在 verify-result.md 中给出明确结论（satisfied / missing / partial）
    - 如果有任何 evidence 为 missing → verify 结论不能为 PASS
@@ -88,8 +88,11 @@ export const definition = {
 10. 读取匹配到的 \`.sillyspec/docs/<project>/modules/<module>.md\`
 11. **检查模块索引可信度**：如果相关模块的 needs_review 为 true，提示"该模块索引可能不可信，需要回看模块卡片或源码"
 
+### worktree 基线锚点（CLI 注入）
+{WORKTREE_BASELINE_INFO}
+
 ### 输出
-文件加载确认清单（含 decisions.md 当前版本/未决项状态、模块文档 + 索引可信度）`,
+文件加载确认清单（含 decisions.md 当前版本/未决项状态、模块文档 + 索引可信度、worktree 基线锚点）`,
       outputHint: '文件确认清单',
       optional: false
     },
@@ -149,9 +152,8 @@ export const definition = {
 ### 操作
 1. 检查变更目录下 tasks/ 是否存在
 2. 如果存在：
-   - 逐个读取 tasks/task-NN.md
-   - 检查每个文件的「验收标准」checkbox 是否全部勾选
-   - 未勾选的项列为不通过
+   - 逐个读取 tasks/task-NN.md，对照 frontmatter 的 \`acceptance:\` 列表逐条核验（TaskCard 协议的验收标准在 frontmatter YAML，正文无 checkbox）
+   - 每条 acceptance 对照实际实现/测试结果判定满足与否，未满足的项列为不通过
 3. 如果不存在：跳过此步骤
 
 ### 输出
@@ -235,13 +237,13 @@ PASS / PASS WITH NOTES / FAIL
 （自动检测的 change_risk_profile: doc-only / unit-sufficient / contract-required / integration-critical / deployment-critical；若 design.md frontmatter 有 risk_level 显式声明，以声明为准并在此注明「显式声明 = <等级>」+ 理由）
 
 ## Runtime Evidence（integration-critical / deployment-critical 必填；自报告，CLI 仅校验字面存在、不独立核验，须真实执行过）
-- daemon 启动命令：
-- backend 地址：
-- 创建 session / 调用核心 API 的请求：
-- daemon 日志关键片段（不能出现 session_control_no_manager / fallback to task_runner / submitMessages agent_run_id empty / 422）：
-- backend 状态（AgentRun running -> completed/failed）：
-- session / lease end 状态：
-- 失败模式排除：
+按本次变更实际触碰的运行时组件填写（模板是通用形态——长驻进程 / 服务端点 / 生命周期状态机的证据结构；未涉及的行写「不涉及」并注明原因，勿堆砌无关关键词）：
+- 长驻进程/服务 启动命令：
+- 服务地址（本变更触碰的端点）：
+- 触发核心路径的请求/命令（附关键响应）：
+- 进程日志关键片段（证明走了新路径、无降级/回退分支）：
+- 生命周期终态断言（本变更涉及的状态机：初始态 → 运行态 → 终态，逐个确认到达）：
+- 失败模式排除（针对本变更声明的风险，逐条说明为何未触发）：
 
 ## 代码审查
 （问题列表 + 总体评价）

package/src/sync.js

@@ -13,6 +13,7 @@ import { join } from 'path';
 import { resolvePlatformSpecDir } from './progress.js';
 import { safeGit } from './git-helper.js';
 import { PLATFORM_MANAGED_FILENAME } from './run/shared.js';
+import { syncSpecTree } from './spec-sync.js';
 
 // sync 是 best-effort（网络失败只 warn）：平台指针失效时不抛，跳过平台、回退本地。
 function safePlatformSpecDir(cwd) {
@@ -452,6 +453,27 @@ export class SyncManager {
     }
 
     console.log(`[sync] 已同步变更: ${changeName}`);
+
+    // 2026-08-16-auto-sync-from-repo：进度上行成功后顺带推四件套文档（best-effort）。
+    // 根因：run 流程此前只推进度不推文档（本文件头注释），本地直跑 sillyspec 的产出
+    // 文档永远不自动到平台（变更中心"进度到了文档没到"）。生产者直连，不依赖 daemon
+    // 缓存链路。失败仅 debugLog——文档同步失败不得影响进度上行的返回值与流程；
+    // 四件套全缺失时 syncDocuments 内部已有跳过（syncedCount===0 提前返回，不调端点）。
+    try {
+      await this.syncDocuments(changeName);
+    } catch (err) {
+      debugLog(`[sync] 文档同步失败（不影响进度）: ${changeName}: ${err.message}`);
+    }
+
+    // 2026-08-17-spec-file-incremental-sync：进度上行+文档直推成功后顺带推整个 spec 树
+    // （plan.md、tasks/、module-impact.md 等），让变更中心文件树自动更新。
+    // 无 daemon 时 CLI 短进程无本地清单缓存，以服务器清单为锚做增量 diff。
+    try {
+      await syncSpecTree(join(this.cwd, '.sillyspec'), this._getPlatform(), changeName);
+    } catch (err) {
+      debugLog(`[sync] spec 树增量同步失败（不影响进度）: ${changeName}: ${err.message}`);
+    }
+
     return { synced: 1, errors: [] };
   }
 

package/src/task-review.js

@@ -30,9 +30,9 @@ import { resolveRuntimeRoot } from './run/shared.js'
 // 跨仓 task 写 review.json 可用 v2 带 repo 字段，单仓/旧 change 仍用 v1。后续可拆分 stage-review 专用
 // 常量，本期遵循 allowed_paths 约束不扩散到 stage-review.js。
 export const REVIEW_SCHEMA_VERSION = 1
-export const REVIEW_SCHEMA_VERSIONS_ACCEPTED = [1, 2]
+const REVIEW_SCHEMA_VERSIONS_ACCEPTED = [1, 2]
 // repo 缺省值（review.repo / task 卡 repo 缺省时统一按 'main' 处理）。design §7.2 / §7.4。
-export const DEFAULT_REPO_KEY = 'main'
+const DEFAULT_REPO_KEY = 'main'
 
 /**
  * 规范化 review.repo / task 卡 repo 字段为有效 repoKey。
@@ -53,7 +53,7 @@ export const VALID_VERDICTS = ['pass', 'fail', 'cannot_verify']
  * @param {string} planContent - plan.md 文件内容
  * @returns {string[]} task id 列表，如 ['task-01', 'task-02']
  */
-export function parseTaskIdsFromPlan(planContent) {
+function parseTaskIdsFromPlan(planContent) {
   if (!planContent) return []
   const ids = new Set()
   const re = /^\s*[-*]\s*\[[ x]\]\s*task-(\d+)/gim
@@ -792,7 +792,15 @@ export async function generateTaskReviewDrafts({ changeName, cwd, platformOpts =
   } catch {}
   if (!executeRunId) {
     executeRunId = generateExecuteRunId()
-    try { mkdirSync(runtimeRoot, { recursive: true }); writeFileSync(runIdFile, executeRunId + '\n') } catch {}
+    // D-001#1 fallback 写入点：mkdir execute-runs/<runId>/tasks 先于 marker（不变量：marker 在则目录在）。
+    // 保留 fail-open 契约（调用方 catch 降级）——只去静默：失败 console.error 留痕，不 throw
+    //（草稿兜底缺了也只是退回 gate 报缺 review.json，不比修复前差）。
+    try {
+      mkdirSync(join(runtimeRoot, 'execute-runs', executeRunId, 'tasks'), { recursive: true })
+      writeFileSync(runIdFile, executeRunId + '\n')
+    } catch (e) {
+      console.error(`[sillyspec] execute run marker/目录写入失败（降级继续，草稿落盘仍尝试）: ${e.message}`)
+    }
   }
 
   // base..head diff 文件集（worktree-aware；null=git 不可用，[]=无 commit diff）