sillyspec 3.29.4 → 3.30.0

package/src/spec-sync.js

@@ -617,10 +617,48 @@ export async function syncSpecTree(specRoot, platform, changeName, opts = {}) {
       // 服务器、不进冲突文件；服务器「冲突 op 跳过、其余照常 apply」语义下本会话真改动
       // 已落——follower 清空即视为本轮同步成功（写基线，下次起 pre-POST 即拦）。
       const serverVersions = body.server_versions || {};
+      // 墓碑拒收通道（runbook spec-push-conflict-recovery 待修①，2026-09-25 实证）：平台
+      // apply_ops 对带 platform_deleted 墓碑的路径**无条件拒收**（与版本无关，update 的
+      // base=version 完全匹配仍拒）。此前 CLI 只消费 server_versions → 墓碑拒收被译成
+      // 「又有更新/版本冲突」，resolve --keep-local 重推永远无效（转圈）。墓碑路径从版本
+      // 冲突叙事中分离：恢复走平台 manifest-heal 通道（2026-09-26-manifest-heal-endpoint）。
+      const tombstoned = Array.isArray(body.platform_deleted)
+        ? body.platform_deleted.filter((p) => typeof p === 'string')
+        : [];
+      const tombSet = new Set(tombstoned);
       const { followers, real } = opts.forcePush
         ? { followers: [], real: serverVersions }
         : partitionConflictPaths(serverVersions, localFiles, baseHashes, lastSyncTs);
-      const realPaths = Object.keys(real);
+      const realPaths = Object.keys(real).filter((p) => !tombSet.has(p));
+
+      // 纯墓碑形态：版本冲突面为空、拒收全是墓碑 → 不写/不清通用冲突标记（clear 会把
+      // 状态洗成「已消解」误导 status），单独落冲突文件 + 正确恢复指引。
+      if (realPaths.length === 0 && tombstoned.length > 0) {
+        let tombConflictPath = null;
+        try {
+          const runtimeDir = join(specRoot, '.runtime');
+          mkdirSync(runtimeDir, { recursive: true });
+          tombConflictPath = join(runtimeDir, `spec-sync-conflict-${changeName}.json`);
+          writeFileSync(tombConflictPath, JSON.stringify({
+            change: changeName,
+            kind: 'spec-tree',
+            created_at: new Date().toISOString(),
+            server_versions: {},
+            conflicting_paths: [],
+            platform_deleted: tombstoned,
+            note: '路径被平台删除墓碑拒收（非版本冲突，resolve 重推无效）。恢复通道：平台 manifest-heal 清墓碑后重推，或联系管理员确认删除是否有意。',
+          }, null, 2) + '\n', 'utf8');
+        } catch (e) {
+          console.warn(`[spec-sync] 墓碑冲突文件写入失败（信息仅打印）: ${e.message}`);
+        }
+        console.warn('');
+        console.warn(`⚠️ [spec-sync] ${tombstoned.length} 个路径被平台删除墓碑拒收（非版本冲突，resolve --keep-local 重推无效）: ${tombstoned.slice(0, 5).join(', ')}${tombstoned.length > 5 ? ' 等' : ''}`);
+        console.warn(`⚠️ 恢复通道：平台 manifest-heal（清墓碑后重推即闭环）；详情: ${tombConflictPath || '(写入失败)'}`);
+        return { synced: 0, conflict: true, serverVersions: {}, tombstoned, conflictPath: tombConflictPath };
+      }
+      const tombNote = tombstoned.length > 0
+        ? `\n⚠️ 另有 ${tombstoned.length} 个路径被平台删除墓碑拒收（非版本冲突，resolve 无效；恢复走平台 manifest-heal）: ${tombstoned.slice(0, 5).join(', ')}${tombstoned.length > 5 ? ' 等' : ''}`
+        : '';
 
       // 冲突横幅降噪（坑 spec-sync-conflict-banner-spam，与 sync() 进度侧 2026-08-23 修法同族）：
       // 未决 spec 树冲突存在期间，每步自动同步都会对同一批真冲突路径再撞一次——此前每轮
@@ -658,6 +696,7 @@ export async function syncSpecTree(specRoot, platform, changeName, opts = {}) {
           created_at: new Date().toISOString(),
           server_versions: real,
           conflicting_paths: realPaths,
+          ...(tombstoned.length > 0 ? { platform_deleted: tombstoned } : {}),
           auto_followed: followers,
           note: 'spec 树文件冲突（仅列本地真改动文件；本地未改动文件已自动跟随服务器）。resolve --keep-local 以本地为准重推；--take-platform 拉平台 bundle 覆盖冲突文件（接受服务器版本，2026-09-03 起支持）',
         }, null, 2) + '\n', 'utf8');
@@ -669,6 +708,7 @@ export async function syncSpecTree(specRoot, platform, changeName, opts = {}) {
       const shownPaths = realPaths.slice(0, 5).join(', ') + (realPaths.length > 5 ? ' 等' : '');
       console.warn('');
       console.warn(`⚠️ [spec-sync] 检测到 spec 树冲突（${realPaths.length} 个文件: ${shownPaths}；逐文件服务器版本见冲突详情文件）`);
+      if (tombNote) console.warn(`⚠️ [spec-sync]${tombNote.trim()}`);
       console.warn(`⚠️ 处置：sillyspec platform resolve ${changeName} --keep-local | --take-platform | --abort（冲突详情: ${conflictPath || '(写入失败)'}）`);
       return { synced: 0, conflict: true, serverVersions: real, autoResolved: followers.length, conflictPath };
     }

package/src/stage-contract.js

@@ -21,7 +21,7 @@ import { backfillFrontmatter } from './scan-postcheck.js'
 import { parseAllowedPaths } from './stages/plan-postcheck.js'
 // FR 索引消费（2026-09-18-fr-index-l1 L1）：重复嫌疑软门（advisory）——fr-index 是纯 fs+decision-distill
 // 叶子链，静态引入无环；knowledge-hits 同为叶子。
-import { parseChangeRequirements, resolveTouchedDomains, readActiveFrDigest, frTitleOverlap } from './fr-index.js'
+import { parseChangeRequirements, resolveTouchedDomains, readActiveFrDigest, frTitleOverlap, FR_TITLE_OVERLAP_THRESHOLD } from './fr-index.js'
 import { discoverModuleIndex } from './decision-distill.js'
 import { appendKnowledgeHit } from './knowledge-hits.js'
 // design.md 文件清单解析（2026-09-17-pass-cap-semantics task-02 事实③）：change-list 是纯 fs
@@ -360,7 +360,7 @@ function validateBrainstormOutputs(cwd, changeName, context = {}) {
             const o = frTitleOverlap(fr.title, a.title)
             if (!hit || o > hit.o) hit = { a, o }
           }
-          if (hit && hit.o >= 0.6) {
+          if (hit && hit.o >= FR_TITLE_OVERLAP_THRESHOLD) {
             warnings.push(`疑似重复 FR：新「${fr.local} ${fr.title}」与现行 ${hit.a.id}「${hit.a.title}」标题重叠度 ${(hit.o * 100).toFixed(0)}%——若为改写/取代请在该 FR 块加承接行 \`承接: ${hit.a.id}\`，若为不同需求请改标题区分（advisory，L1 观察指标）`)
             try {
               appendKnowledgeHit(join(specRoot || join(cwd, '.sillyspec'), '.runtime'), {
@@ -1201,12 +1201,21 @@ export function judgeApiCoverageMatrix(args) {
       const key = `${m[1]} ${m[2]}`
       if (!parseSet.has(key)) anchorViolations.push(`${rowLabel(r)}：design接口表#${key} 未命中 design 接口段解析面（空指）`)
     }
-    if (!apiEvidenceHasAnchorForm(e)) anchorViolations.push(`${rowLabel(r)}：证据缺用例依据锚点（五形态之一）`)
+    if (!apiEvidenceHasAnchorForm(e)) {
+      // 分诊（2026-09-23 执行会话实证：design接口表# 字样在场但 # 后非 METHOD /path 形态时，
+      // 泛化「缺五形态之一」让人无法区分「形态没写对」与「写了没算数」——三轮试错后 agent 被逼
+      // 换更弱的 DDL@ 形态过门，fail-closed 反而促成了更泛的锚点。定向报出该形态的命中条件。）
+      API_ANCHOR_DESIGN_API_RE.lastIndex = 0
+      const bareDesignAnchor = /design接口表#/.test(e) && !API_ANCHOR_DESIGN_API_RE.test(e)
+      anchorViolations.push(bareDesignAnchor
+        ? `${rowLabel(r)}：证据含 design接口表# 但 # 后未提取到 METHOD /path——该形态仅 \`design接口表#POST /api/xx\` 形态计命中（仅写表名/行号/散文描述不计）`
+        : `${rowLabel(r)}：证据缺用例依据锚点（五形态之一）`)
+    }
   }
   if (anchorViolations.length > 0) {
     errors.push(
       `接口验证覆盖矩阵有 ${anchorViolations.length} 项证据锚点缺失/空指` +
-      `（covered/partial 证据须含锚点五形态之一：design接口表#METHOD /path（须命中 design 接口段解析面）/ 权限矩阵[角色×动作] / 契约表@行标识 / DDL@列名 / 载荷@构造点路径；covered-service 证据须含测试锚点三形态之一：\`.test.\` 文件名 / file:line / 反引号包裹的测试名）：${anchorViolations.join('；')}。` +
+      `（covered/partial 证据须含锚点五形态之一，可复制样例：design接口表#POST /api/xx（# 后必须 METHOD /path 且命中 design 接口段解析面，仅表名/行号不计）/ 权限矩阵[admin×读] / 契约表@任务卡字段清单 / DDL@users.id / 载荷@e2e_body.json；covered-service 证据须含测试锚点三形态之一：\`.test.\` 文件名 / file:line / 反引号包裹的测试名）：${anchorViolations.join('；')}。` +
       `修复：在证据列补真实锚点（design接口表# 锚点须与 design.md 接口段端点一致，防编造端点）。`
     )
   }
@@ -1945,6 +1954,14 @@ export function checkTransition(fromStage, toStage, options = {}) {
     return { allowed: false, reason: `未知阶段: ${toStage}` }
   }
 
+  // 出生未入门态（2026-09-27-change-birth-stage-brainstorm）：出生阶段自 'scan'（auxiliary）改
+  // 'brainstorm' 后，「辅助→主流程任意放行」不再天然覆盖出生态——但 thin/quick、backfill、
+  // complete-step 等大量路径从出生态直接 run 目标阶段（旧 scan 出生全都放行）。等价语义：
+  // brainstorm 仍 pending/无 stages 行（从未真正进入主流程）视同辅助态；真在 brainstorm 中
+  // （in-progress/completed）仍受主流程守卫约束。
+  const fromBirthUntouched = fromStage === 'brainstorm'
+    && (!fromStageData || !fromStageData.status || fromStageData.status === 'pending')
+
   // 辅助阶段随时可执行（archive 除外：从主流程进入 archive 需要校验）
   if (AUXILIARY_STAGES.includes(toStage) && toStage !== 'archive') {
     return { allowed: true }
@@ -1971,15 +1988,16 @@ export function checkTransition(fromStage, toStage, options = {}) {
     if (fromStage === 'verify') {
       return { allowed: true }
     }
-    // 独立运行 archive（无前置）也允许
-    if (!fromStage || AUXILIARY_STAGES.includes(fromStage)) {
+    // 独立运行 archive（无前置）也允许；出生未入门态同放行（旧 scan 出生态等价——
+    // thin/quick 从未进主流程的变更直接归档走此路）
+    if (!fromStage || AUXILIARY_STAGES.includes(fromStage) || fromBirthUntouched) {
       return { allowed: true }
     }
     return { allowed: false, reason: 'archive 的前置阶段是 verify，不能从 ' + fromStage + ' 跳转' }
   }
 
-  // 从辅助阶段进入主流程：允许
-  if (AUXILIARY_STAGES.includes(fromStage)) {
+  // 从辅助阶段进入主流程：允许（出生未入门态同——见函数头注释）
+  if (AUXILIARY_STAGES.includes(fromStage) || fromBirthUntouched) {
     return { allowed: true }
   }
 

package/src/stage-review-checklist.js

@@ -29,6 +29,8 @@ export const REVIEW_CHECKLISTS = {
     'scan/module docs 或源码中的真实约束与 design.md 假设',
     '涉及角色/权限/字典类数据时，实证不能只看静态定义：须以生产查询口径可解析到目标结果——用真实租户/库下可执行的查询（如按 enname+tenant 查询）确认返回非空，仅 enname 存在不算通过',
     '涉及新页面/前端路由时，用户入口 × 菜单/注册 DML 对账：入口路由与菜单表、角色-权限注册 DML 逐一对账——能点到的入口必有对应菜单与授权注册行，菜单/注册 SQL 必须出现在交付清单（design.md 文件变更清单或 db/ 脚本）',
+    '**承诺可兑现性**：design 的每个可测承诺（如 at-least-once / 不重不漏 / 恒定窗口）逐条过最坏输入四维——乱序到达、并发写、会话或变更切换、多工作区作用域——实现能否兑现？不能兑现则降级承诺文案或改取简方案（如全量重拉结构性消灭整类时序缺陷），禁止立兑现不了的承诺（R14/R15 对撞 5 个 P1 全落此维，pytest 覆盖不到）',
+    '**三方对齐**：spec 文本、design、实现三者的取舍矛盾必须二选一对齐——不许"实现跟 design、spec 跟 design"各说各话（增量 vs 全量、有上限 vs 无上限是归档审计翻出的主型）；design 拒绝备选方案的理由不得同样适用于自选方案（自我论证矛盾）',
   ],
   plan: [
     'task 编号与 Wave checkbox 格式正确，execute 依赖此格式解析任务',

package/src/stage-review.js

@@ -20,7 +20,7 @@ import { createHash } from 'crypto'
 import jsYaml from 'js-yaml'
 import { VALID_VERDICTS, REVIEW_SCHEMA_VERSION } from './task-review.js'
 import { detectSpecDirTypo } from './spec-dir-typo.js'
-import { resolveRuntimeRoot } from './run/shared.js'
+import { resolveRuntimeRoot, resolveSpecDir } from './run/shared.js'
 
 // 文档型 stage review 的合法 reviewType
 const STAGE_REVIEW_TYPES = ['design', 'plan', 'proposal', 'code', 'acceptance']
@@ -825,7 +825,12 @@ export function registerStageReview({ changeName, stage, fromFile, cwd, platform
     throw new Error(`register-stage-review: stage 无效 "${stage}"（应为 brainstorm|plan|execute）`)
   }
 
-  const specBase = platformOpts.specRoot || join(cwd, '.sillyspec')
+  // specBase 回退走 resolveSpecDir 向上找根（坑 register-stage-review-cwd-pollution-no-hint，
+  // 2026-09-25 实证：bash cd 持久化停在 changes/<变更>/tasks/ 时 join(cwd,'.sillyspec') 拼出
+  // cwd 相对的事务性错误路径，报「主审查文档不存在」且无 cwd 提示）。与 run/gate 同源
+  // （run/shared.js resolveSpecDir 单一真相源，含 home/tmpdir 拒绝守卫），平台模式 specRoot
+  // 仍优先——与 shared.js:2123 规范写法 platformOpts?.specRoot || resolveSpecDir(cwd) 一致。
+  const specBase = platformOpts.specRoot || resolveSpecDir(cwd)
   const runtimeRoot = resolveRuntimeRoot(platformOpts, specBase)
   const changeDir = join(specBase, 'changes', changeName)
   const reviewType = STAGE_REVIEW_TYPE[stage]

package/src/stage-templates.js

@@ -0,0 +1,157 @@
+/**
+ * stage-templates.js — 阶段产物模板出上下文（R16 减负批次，2026-09-24）
+ *
+ * 背景：brainstorm「生成规范文件」步内嵌 proposal/requirements/tasks/decisions 四份完整落盘
+ * 模板（~100 行）——说明书每轮全量回放（R15 实测 burst 单次载荷 1581 行/45K token，59 轮
+ * brainstorm 等于把说明书交了 59 遍钱），而模板只在真写产物的轮才需要。M1 指纹缓存只省
+ * 「复入重发」不省「每轮回放」，模板出上下文是唯一能把回放面砍掉的手段。
+ *
+ * 机制：模板单一源在本文件 → materializeStageTemplates 在 outputStep 渲染期幂等落盘
+ * `<specBase>/.runtime/templates/<name>.md` → 步骤 prompt 只留要点 + 文件路径 +「写该产物前
+ * Read 一次」。产物格式漂移由 --done 门禁兜底（brainstorm.design.* / four-piece 规则逐条
+ * 点名——模板没读会撞门禁，重读即修复，闭环在既有机制上）。
+ *
+ * 只收纯格式骨架；行为纪律（NEW: 前缀铁律/数据流标注/FR 承接纪律等）留在 prompt——规则
+ * 是判断依据须常驻，模板是抄写目标按需读。
+ */
+import { existsSync, mkdirSync, readFileSync, writeFileSync } from 'fs'
+import { join } from 'path'
+
+/** brainstorm 四件套产物格式模板（自 stages/brainstorm.js「生成规范文件」步逐字迁移——
+ *  与 prompt 指针版本同源；decisions 九字段与可选字段说明一并迁入）。 */
+export const BRAINSTORM_ARTIFACT_TEMPLATES_MD = `# brainstorm 规范文件产物模板（proposal / requirements / tasks / decisions）
+
+> 写对应产物前读本文件一次，严格按模板结构与 frontmatter 产出；缺章节/缺 frontmatter 会被
+> 「生成规范文件」步 --done 门禁逐条点名（brainstorm.design.* / four-piece 规则）。
+
+## proposal.md 格式要求
+\`\`\`markdown
+---
+author: <git-user>
+created_at: <now-datetime>
+---
+# 提案书（Proposal）
+
+## 动机
+为什么做、解决什么核心问题
+
+## 关键问题
+为什么现有方案不够（展开 2-3 个具体痛点）
+
+## 变更范围
+本次做什么
+
+## 不在范围内（显式清单）
+- 不做 X
+- 不做 Y
+
+## 成功标准（可验证）
+- 旧配置默认行为不变
+- 新功能在配置后可用
+- ...
+\`\`\`
+
+## requirements.md 格式要求
+\`\`\`markdown
+---
+author: <git-user>
+created_at: <now-datetime>
+---
+# 需求规格（Requirements）
+
+## 角色
+| 角色 | 说明 |
+|---|---|
+| 开发者 | ... |
+
+## 功能需求
+
+### FR-01: 需求名称
+覆盖决策：D-001@v1, D-002@v1（如适用）
+承接: FR-<域>-NNN（如适用——改写/取代注入清单中的已有行为时必填，全新行为省略本行）
+Given 前提条件
+When 触发动作
+Then 期望结果
+
+（每个边界条件独立 GWT 块；场景名行 \`#### 场景：X\` 会被归档索引用作摘要，建议保留）
+（约束强度标注——RFC 2119 约定：FR 正文与非功能需求里的约束必须用固定词标硬度：MUST/必须=硬性要求（违反即缺陷）；MUST NOT/禁止=红线（绝对不允许，如「平台 MUST NOT 基于 provisional 事件内容做流程判定」）；SHOULD/应当=强烈建议（偏离须注明理由）；MAY/可以=可选。禁止裸写无强度词的约束句（「不做 X」读不出是描述还是禁令）。fr/ 归档索引逐字透传，强度词随知识注入带给后续变更——这是规范语言的全链路载体）
+
+## 非功能需求
+- 兼容性：...
+- 可回退：...
+- 可测试：...
+
+## 决策覆盖矩阵（如存在 decisions.md）
+| 决策 ID | 覆盖的 FR | 说明 |
+|---|---|---|
+| D-001@v1 | FR-01 | ... |
+\`\`\`
+
+## tasks.md 格式要求（scale=large 时生成骨架；任务清单唯一真相——plan 阶段展开细节并写回本文件）
+\`\`\`markdown
+---
+author: <git-user>
+created_at: <now-datetime>
+---
+# 任务清单（Tasks）
+
+- [ ] task-01: <任务名>
+- [ ] task-02: <任务名>
+\`\`\`
+> 骨架只列任务名。plan 阶段会把展开后的清单**写回本文件**（checkbox 行带一句话名，可附 [model:xxx]/(depends_on: …) 标注；保留 frontmatter/标题/ql-xxx 等非 task-XX 行）；execute 勾选与 verify 对照都在本文件。
+
+## decisions.md 格式要求（前序步骤已增量创建时对账即可；无决策的变更不生成）
+\`\`\`markdown
+---
+author: <git-user>
+created_at: <now-datetime>
+---
+
+# 决策记录（Decisions）
+
+## D-001@v1: 决策短标题
+- type: definition | consistency | feasibility | term | boundary | premise | architecture | compatibility | risk
+- priority: P0 | P1 | P2
+- status: accepted | unresolved | rejected | superseded
+- supersedes:
+- source: user | code | docs
+- question: 被解决的问题
+- answer: 用户确认或代码查证结果
+- normalized_requirement: 可测试的约束
+- impacts: [FR-01, task-01, verify-01]
+- evidence: 用户回答轮次或代码/文档路径
+\`\`\`
+
+> 可选字段（按需另加，旧格式决策缺这些字段不受影响）：**锚点**（决策落点主文件，\`<src 路径>:<行号或符号>\`；status=confirmed 时必填）；**模块域**（决策涉及的模块 ID，可多个逗号分隔——合法 id 只取**当前变更所属项目**的 \`{SPEC_ROOT}/docs/<project>/modules/_module-map.yaml\`，多项目仓勿读其他子项目的 map（核验不认，报错会点名归属）；规划中的新模块用 \`NEW:<名>\` 前缀声明，冒号后不加空格：\`NEW:foo\` 合法、\`NEW: foo\` 属书写错误。「生成规范文件」步 --done 的模块域核验对不认识的 id 直接阻断）；**否决理由**（status=rejected 时必填）；**复潮条件**（status=rejected 时必填）；**故障面**（本决策引入的新失败模式——新机制落地时留痕它引入什么失败模式；type=architecture 时建议填写，可选）；**退役判据**（出现什么信号时简化或删除本机制——信号出现就该简化它；type=architecture 时建议填写，可选）。
+`
+
+/** 模板清单（name → 内容）。新模板入册即自动被 materialize 落盘。 */
+const STAGE_TEMPLATE_FILES = {
+  'brainstorm-artifact-templates.md': BRAINSTORM_ARTIFACT_TEMPLATES_MD,
+}
+
+/**
+ * 幂等落盘全部阶段模板到 `<specBase>/.runtime/templates/`（内容有变才写，原子性靠短文件
+ * best-effort——模板只读消费，半写窗口下一次渲染会补齐）。
+ * @returns {string|null} 模板目录绝对路径（异常 → null，调用方 fail-soft）
+ */
+export function materializeStageTemplates(specBase) {
+  try {
+    if (!specBase) return null
+    // 只在已存在的 specBase 内落盘（坑：凭空新建 <cwd>/.sillyspec 会污染 spec-dir 向上
+    // 搜索语义——渲染测试曾在 test/ 目录下落出 test/.sillyspec，spec-dir-home-guard 向上
+    // 命中即断言失败）。specBase 不存在 = 本目录不是变更根，零动作。
+    if (!existsSync(specBase)) return null
+    const dir = join(specBase, '.runtime', 'templates')
+    mkdirSync(dir, { recursive: true })
+    for (const [name, content] of Object.entries(STAGE_TEMPLATE_FILES)) {
+      const p = join(dir, name)
+      let cur = null
+      try { cur = readFileSync(p, 'utf8') } catch { /* 首次 */ }
+      if (cur !== content) writeFileSync(p, content, 'utf8')
+    }
+    return dir
+  } catch {
+    return null
+  }
+}

package/src/stages/archive.js

@@ -87,6 +87,8 @@ export const definition = {
    \`sillyspec run archive --done --confirm --output "确认归档"\`
 8. CLI 会创建 \`.sillyspec/changes/archive/\`，并将变更目录移动到 \`.sillyspec/changes/archive/<原变更名>/\`
 
+9. **收口输出转达义务**（知识可见性契约，2026-09-23）：--confirm 收口输出里若出现「📚/⚠️ 知识收件箱」横幅（uncategorized 待审知识标题清单），必须在最终回复中**原文转达用户**——CLI 输出用户不可见，你的转述是用户看到它的唯一通道；未出现则不提及（不得编造）。
+
 ### 输出
 归档完成 + archive 目录路径`,
       outputHint: '归档确认',

package/src/stages/brainstorm.js

@@ -53,10 +53,10 @@ export const definition = {
 - 多项目且用户已指定：直接确认，不需要等待
 - 多项目且用户未指定：列出项目列表，需要用户确认本次需求属于哪个子项目
 
-### 早期规模筛查（判断是否该走 quick）
+### 早期规模筛查（判断是否该走轻量变更）
 加载上下文后，用需求描述 + 模块上下文**粗判**本次变更规模：
-- **明显 small**（满足：预计改动 ≤ 2 个文件、单模块、无 schema/API/状态机/权限变更；或属于改文案/修 bug/样式调整/配置微调等纯执行类）→ 输出：「此变更规模较小，建议直接走 quick 流程」+ 一句依据，给出建议命令 \`sillyspec run quick "<需求>"\`。用户同意则本阶段可在此收尾（\`--done\` 并提示转 quick），不必继续走完整设计流程。
-- **拿不准或明显 large**（涉及多模块、schema、状态流转、新架构等）→ 不要提示 quick，继续进入下一步「对话式探索与需求澄清」。
+- **明显 small**（满足：预计改动 ≤ 2 个文件、单模块、无 schema/API/状态机/权限变更；或属于改文案/修 bug/样式调整/配置微调等纯执行类）→ 输出：「此变更规模较小，建议直接走轻量变更」+ 一句依据，给出建议命令 \`sillyspec flow start --change <名> --input "<需求>"\`（2 调用协议收口）。用户同意则本阶段可在此收尾（\`--done\` 并提示转轻量变更），不必继续走完整设计流程。
+- **拿不准或明显 large**（涉及多模块、schema、状态流转、新架构等）→ 不要提示轻量变更，继续进入下一步「对话式探索与需求澄清」。
 - 这是**粗判**，只为让明显的小变更免走完整设计流程；不确定就继续，后续「生成规范文件」步骤会基于 design.md 文件清单做精判兜底。
 
 ### 输出
@@ -76,8 +76,8 @@ export const definition = {
       maxWaitRounds: 8,
       waitReason: '等待用户回答需求问题或澄清',
       waitOptions: ['回答见--answer', '信息够了，进入方案讨论'],
-      prompt: `### ⚡ 薄跑判定（P0-3，2026-09-20 对撞实验驱动——需求已收敛来源走全仪探索是纯税）
-**需求来源已收敛**（满足任一：--input 显式声明承接/已澄清/方案已定；fork 或关联会话已多轮澄清过本需求，你已能不问自答全部 P0 歧义；任务书/评审结论直接给定方案与边界）→ 本步可**薄跑**：A-D 节按已收敛事实直书结论（歧义零清单、范围直裁、决策若已有则引用源会话不重问），一次性完成不再多轮追问。薄跑不降质量底线：范围结论与决策落盘照常，仅省「明知故问」的交互轮。Grill（Step 7）与规范文件（Step 8）**不适用薄跑、永不省**。
+      prompt: `### ⚡ 轻量跑判定（P0-3，2026-09-20 对撞实验驱动——需求已收敛来源走全仪探索是纯税）
+**需求来源已收敛**（满足任一：--input 显式声明承接/已澄清/方案已定；fork 或关联会话已多轮澄清过本需求，你已能不问自答全部 P0 歧义；任务书/评审结论直接给定方案与边界）→ 本步可**轻量跑**：A-D 节按已收敛事实直书结论（歧义零清单、范围直裁、决策若已有则引用源会话不重问），一次性完成不再多轮追问。轻量跑不降质量底线：范围结论与决策落盘照常，仅省「明知故问」的交互轮。Grill（Step 7）与规范文件（Step 8）**不适用轻量跑、永不省**。
 
 通过对话探索需求细节、分析原型（如有）、判断拆分/批量、并对歧义点做需求澄清 Grill。本步骤合并了原有的对话探索、原型分析、需求范围评估、需求澄清 Grill 四个环节——按下方 A→D 顺序按需执行。提问遵守「一次只问一个」（见 D 节追问策略）：必须问的问题逐个问，能查代码/文档解决的不问；不要把多个歧义打包成一屏清单一次抛给用户（用户记不住、答不全，反而漏掉关键约束）；也不要为凑数把单个问题拖成多轮。
 
@@ -345,10 +345,21 @@ design.md 第一行标题必须用中文：# 设计文档（Design）— <变更
 |---|---|---|---|
 | R-01 | ... | P0/P1/P2 | ... |
 
+10b. **非功能生命周期**（进程/资源/清理面——2026-09-22 R7 dogfood 复盘新增，41 孤儿 watcher
+泄漏实证：设计审查惯于覆盖 API/通道/语义面，「死亡面」无人审）：
+   - 本变更是否引入长驻进程/后台任务/持有外部资源（文件锁/监听句柄/子进程）？
+   - 引入 → 逐项写自灭条件（谁负责杀、何时死、父环境消失后靠什么死——不得只依赖 spawn 侧
+     环境变量；参考三闸模式：首拍终态即退/外部资源蒸发连续 N 拍退/硬寿命帽）
+   - 不涉及 → 风险登记表加一行「无长驻进程/外部资源，生命周期面不适用」显式留痕
+
 11. **决策追踪**（如存在 Grill/重大决策）：
    - 列出当前版本 D-xxx@vN 决策 ID
    - 说明每个 D-xxx@vN 被哪些 FR-xxx / 设计章节覆盖
    - 标注仍未解决的 D-xxx@vN 或剩余风险
+   - **多裁定组合推演**（2026-09-22 R7 dogfood 复盘新增：升厚×断点续两裁定各自正确、组合
+     出归档死锁的实证）：≥2 条相互约束的裁定（状态升降/回退路径/失败语义类）时，自审必须
+     做组合状态表推演——各裁定的状态叉乘 × 关键子步（如归档/重入）逐格过一遍，死锁格写
+     进风险登记与调和方案；无组合面（裁定互不作用）显式记「无组合约束」一行
 12. **自审**（AI 对自身设计的校验）
 
 ### 操作
@@ -392,8 +403,8 @@ design.md 文件路径 + 自审结果
 ### 审查执行方式（CLI 按 ceremony_tier 风险定价，占位符由 run.js 注入）
 tier: {REVIEW_TIER}（{REVIEW_TIER_REASON}）
 - tier=self（ceremony 档 S0/S1）：当前 agent 按「仪式档位菜单」执行对应档轻仪交叉审查（S0=CLI 清单核验 / S1=CLI 清单核验+定向探针抽查）——轻仪是风险定价的正常形态而非降级，清单机械项一条不省
+> 🚪 **评审豁免（2026-09-26-review-unsupervised-exit）**：若本会话环境**无嵌套派发能力**（无 Agent/Task 类子代理工具）——不产 review.json、**不做自审表演**；改为在变更目录写一行声明文件 review-unsupervised.md（内容含 unsupervised 字样+时间+一句环境说明），Stage Review 门见声明即放行并留痕（声明随归档；Task Review 层已退役 2026-09-26-task-review-retire）。有派发能力时本豁免不适用（真独立评审仍优待）。
 - tier=independent（ceremony 档 S2/S3）：必须用 Agent tool 启动一个独立的设计审查子代理（独立上下文，不共享你的分析与倾向），子代理按下方"交叉审查模型"审查 design.md 并输出 review.json——S2=独立评审×1；S3=两轮独立评审（两轮独立子代理交叉，第二轮聚焦首轮未决项与新增面）。review.json 产物契约（CLI Stage Review Gate 将硬校验，schema + 完整示例 + docHash 算法如下，照抄改值）:
-  宿主环境无 Agent tool 可用（调用报 Unknown agent / Available agents: none）→ 不卡死（降级兜底，仅评审通道全不可用时）：主代理切换为审查者角色自审替代，reviewerNotes 首行记录「降级：环境无子代理可用」，逐条结论附源码锚点（file:line 或 grep/read 证据）补偿独立性。
 {PRIOR_REVIEW_FACTS}
 {REVIEW_JSON_CONTRACT}
   子代理只产出 review + Unresolved Blockers，**是否调用 sillyspec run brainstorm --wait 仍由你（主 agent）根据其 verdict 决定**（子代理不直接操作 CLI 状态机）。
@@ -412,7 +423,7 @@ tier: {REVIEW_TIER}（{REVIEW_TIER_REASON}）
 - S1：CLI 清单核验 + 定向探针抽查——机械项全查之外，对最高风险的 1-2 个交叉点做定向源码探针（读相关实现验证设计假设），无需独立子代理
 - S2：独立评审×1——一个独立审查子代理完整执行下方交叉审查模型并产出 review.json
 - S3：两轮独立评审 + Grill 深查——两个独立审查子代理分别审查（视角互补：一个查结构性矛盾/一致性，一个查可行性与外部约束），首轮未决项进第二轮复核；对 P0 歧义逐一压力测试（Grill 深查）
-当前档以注入的 ceremony_tier 行为准（run.js 注入 {REVIEW_TIER} 时随附菜单并标注）；档位由 blast/span/friction 三轴客观计算，agent 自报只可升不可降——按当前档如实执行，不自行升仪或降仪。S2/S3 评审通道全不可用时按上方降级兜底执行并留 degraded 痕（reviewerNotes「降级：环境无子代理可用」）；S0/S1 的 self 是档位定价的正常形态，不是降级。
+当前档以注入的 ceremony_tier 行为准（run.js 注入 {REVIEW_TIER} 时随附菜单并标注）；档位由 blast/span/friction 三轴客观计算，agent 自报只可升不可降——按当前档如实执行，不自行升仪或降仪。S2/S3 评审通道全不可用时按上方评审豁免处理（写 review-unsupervised.md 声明，不自审表演）；S0/S1 的 self 是档位定价的正常形态，不是降级。
 
 ### 默认行为
 1. 默认必须执行一次交叉审查；不要让用户凭主观判断决定"要不要 Grill"。
@@ -513,7 +524,7 @@ status: passed | needs-user-input | blocked | skipped
 ### 操作
 1. **按规模生成规范文件**：
    - **scale=large**：在 \`{SPEC_ROOT}/changes/<change-name>/\` 下生成完整四件套（design.md / decisions.md 可选 / proposal.md / requirements.md / tasks.md），实现路径 → \`sillyspec run plan --change <变更名>\`
-   - **scale=small**：只生成/补全 design.md（proposal/requirements/tasks 对 quick 无用，不生成），实现路径 → \`sillyspec run quick --linked-changes <变更名>\`
+   - **scale=small**：只生成/补全 design.md（proposal/requirements/tasks 由轻量变更机器稿补齐），实现路径 → \`sillyspec flow start --change <变更名>\`（轻量变更收编头脑风暴产物，2 调用收口）
    - 两种规模都执行 \`git add {SPEC_ROOT}/changes/<change-name>/\` — 暂存本变更的规范文件（精确到变更目录，勿用 .sillyspec/ 整目录——会裹挟其他活跃变更；不要 commit，由用户通过统一提交工具处理）。**平台模式跳过 git add**（specRoot 不在 sourceRoot 的 git repo 内）
 
 2. 生成完成后展示 design.md 摘要 + **规模评估结果（small/large + 一句依据）** + 实现路径建议，告知用户“如有异议直接说，可修改文件、改 scale 或 --reopen 回退”（不暂停，展示完直接 --done）
@@ -526,109 +537,16 @@ created_at: <now-datetime>
 ---
 \`\`\`
 
-### proposal.md 格式要求
-\`\`\`markdown
----
-author: <git-user>
-created_at: <now-datetime>
----
-# 提案书（Proposal）
-
-## 动机
-为什么做、解决什么核心问题
-
-## 关键问题
-为什么现有方案不够（展开 2-3 个具体痛点）
-
-## 变更范围
-本次做什么
-
-## 不在范围内（显式清单）
-- 不做 X
-- 不做 Y
-
-## 成功标准（可验证）
-- 旧配置默认行为不变
-- 新功能在配置后可用
-- ...
-\`\`\`
+### 产物格式模板（出上下文——R16 减负批次 2026-09-24）
+proposal.md / requirements.md / tasks.md / decisions.md 四份产物的完整格式模板**不再内嵌本说明书**（每轮全量回放是 brainstorm 段 token 膨胀主源），已由 CLI 落盘：
+\`{SPEC_ROOT}/.runtime/templates/brainstorm-artifact-templates.md\`
+**生成任一规范文件前先 Read 该模板文件一次**，严格按模板结构与 frontmatter 产出——缺章节/缺 frontmatter 会被本步 --done 门禁逐条点名（brainstorm.design.* / four-piece 规则），届时重读模板修复即可。
+模板要点速览（细则以模板文件为准）：proposal=动机/关键问题/变更范围/不在范围内/成功标准；requirements=角色表 + FR-XX GWT 块（含覆盖决策行与承接行）+ 非功能需求 + 决策覆盖矩阵；tasks=task-NN checkbox 骨架（只列任务名，plan 阶段展开写回）；decisions=D-xxx@vN 九字段 + 可选字段（锚点/模块域/否决理由/复潮条件/故障面/退役判据）。
 
 ### 触达域现行 FR（FR 索引注入，2026-09-18-fr-index-l1）
 {FR_INDEX_DIGEST}
 写作纪律（防重复 FR——L1 索引实验的承接数据源）：改写/取代上列已有行为 → 对应新 FR 块**必须加承接行**引用全局 id（如 \`承接: FR-core-engine-003\`，多个逗号分隔）；全新行为 → 新 FR 块不加承接。承接行在归档时由 CLI 翻旧条目 superseded 并建取代链。
 
-### requirements.md 格式要求
-\`\`\`markdown
----
-author: <git-user>
-created_at: <now-datetime>
----
-# 需求规格（Requirements）
-
-## 角色
-| 角色 | 说明 |
-|---|---|
-| 开发者 | ... |
-
-## 功能需求
-
-### FR-01: 需求名称
-覆盖决策：D-001@v1, D-002@v1（如适用）
-承接: FR-<域>-NNN（如适用——改写/取代上列注入清单中的已有行为时必填，全新行为省略本行）
-Given 前提条件
-When 触发动作
-Then 期望结果
-
-（每个边界条件独立 GWT 块；场景名行 \`#### 场景：X\` 会被归档索引用作摘要，建议保留）
-
-## 非功能需求
-- 兼容性：...
-- 可回退：...
-- 可测试：...
-
-## 决策覆盖矩阵（如存在 decisions.md）
-| 决策 ID | 覆盖的 FR | 说明 |
-|---|---|---|
-| D-001@v1 | FR-01 | ... |
-\`\`\`
-
-### tasks.md 格式要求（scale=large 时生成骨架；任务清单唯一真相——plan 阶段展开细节并写回本文件）
-\`\`\`markdown
----
-author: <git-user>
-created_at: <now-datetime>
----
-# 任务清单（Tasks）
-
-- [ ] task-01: <任务名>
-- [ ] task-02: <任务名>
-\`\`\`
-> 骨架只列任务名。plan 阶段会把展开后的清单**写回本文件**（checkbox 行带一句话名，可附 [model:xxx]/(depends_on: …) 标注；保留 frontmatter/标题/ql-xxx 等非 task-XX 行）；execute 勾选与 verify 对照都在本文件。
-
-### decisions.md 格式要求（前序步骤已增量创建时对账即可；无决策的变更不生成）
-\`\`\`markdown
----
-author: <git-user>
-created_at: <now-datetime>
----
-
-# 决策记录（Decisions）
-
-## D-001@v1: 决策短标题
-- type: definition | consistency | feasibility | term | boundary | premise | architecture | compatibility | risk
-- priority: P0 | P1 | P2
-- status: accepted | unresolved | rejected | superseded
-- supersedes:
-- source: user | code | docs
-- question: 被解决的问题
-- answer: 用户确认或代码查证结果
-- normalized_requirement: 可测试的约束
-- impacts: [FR-01, task-01, verify-01]
-- evidence: 用户回答轮次或代码/文档路径
-\`\`\`
-
-> 可选字段（按需另加，旧格式决策缺这些字段不受影响）：**锚点**（决策落点主文件，\`<src 路径>:<行号或符号>\`；status=confirmed 时必填）；**模块域**（决策涉及的模块 ID，可多个逗号分隔——合法 id 只取**当前变更所属项目**的 \`{SPEC_ROOT}/docs/<project>/modules/_module-map.yaml\`，多项目仓勿读其他子项目的 map（核验不认，报错会点名归属）；规划中的新模块用 \`NEW:<名>\` 前缀声明，冒号后不加空格：\`NEW:foo\` 合法、\`NEW: foo\` 属书写错误。本步 --done 的模块域核验对不认识的 id 直接阻断）；**否决理由**（status=rejected 时必填）；**复潮条件**（status=rejected 时必填）；**故障面**（本决策引入的新失败模式——新机制落地时留痕它引入什么失败模式；type=architecture 时建议填写，可选）；**退役判据**（出现什么信号时简化或删除本机制——信号出现就该简化它；type=architecture 时建议填写，可选）。
-
 ### 后续变更包处理
 如果 MASTER.md 中规划了后续变更包（拆分后的子阶段），**必须同时为每个后续包创建独立变更目录**：
 1. 读取 MASTER.md 中的变更包列表（包名 + 边界描述）