sillyspec 3.27.12 → 3.28.0

package/.worktrees/2c37b1d7/templates/claude-instruction.md

@@ -1,23 +0,0 @@
-# Claude Code 指引
-
-## 项目说明
-本项目使用 **SillySpec** 管理变更，采用文档驱动开发。SillySpec 是给 Agent 调用的 CLI 流程控制器，不是给人类直接使用的产品，也不是处理业务逻辑的工具——你（Agent）通过 CLI 告诉它"我在哪"，它告诉你"下一步做什么"；你执行步骤，它校验产出、推进状态，人类只在关键决策点介入审批。要考虑多 agent 同时操作代码，代码随时可能变化。所有变更以稳定、可用、可维护为目标，按生产级标准处理。
-
-## 核心规则
-1. **禁止绕过本文件规则和 SillySpec 流程**。所有变更走 sillyspec 流程，不裸改裸提交。
-2. **改代码前必须先说明依据**——依据的文档路径（design.md / 模块文档 / file-lifecycle.md）或现有代码依据，无依据不改。
-3. **新功能 / 大改动走完整流程**：`brainstorm → plan → execute → verify → archive`。
-4. **小修复 / 小调整走 quick**：`sillyspec run quick`。
-5. **执行顺序**：文档 → 读代码 → 写测试 → 写实现 → 跑测试 → 验收 → 更新文档。
-6. **判规模选档**：≤3 文件、范围明确走 `quick`；多阶段 / 架构级走完整流程。
-7. **代码先行不补流程（倒推 B 模式）**：代码若已先写好，**不回头补 brainstorm/plan 装样子**——用 `quick --done` 收尾 + 补 quicklog 条目，把已落盘改动如实登记进进度库。
-8. **实证核验再 `--done`**：`quick --done` 前，触及 `src`/`test` 的改动先 `npm test` + `npm run lint`；纯 doc/配置改动可跳过（lint 不扫 docs/，空转无信息），以落盘文件与测试结果为准，不信口头"已完成"。
-9. **中途停下不靠额外命令存进度**——进度已由上一次 `--done` 自动落盘；恢复时用 `sillyspec progress show` 查看进度，再用 `sillyspec run <stage>` 续跑，不直接 commit 半成品。
-10. **实现完成后对照文档验收**（design.md / 模块文档），并检查是否影响已有测试。
-11. **非测试逻辑本身有误时，禁止改测试来"通过"**——修逻辑，不修测试。
-12. **hook 拦截提交时禁止跳过**（`.husky/pre-push`），修复问题后再提交。
-13. **代码必须兼容 Windows / Linux / macOS**（路径 / 换行 / 并发都要顾）。
-14. **任务记录隔离**：永不重置 / reset / 清零已存在的 change；多个活跃 change 各自 `--change <名>` 隔离不重叠；quick 同一 QUICKLOG 按 ql-ID 条目追加，不冲突。
-15. **quicklog 结构化落盘**：末步 `--done` 用四参数 `--req/--cause/--solution/--result`（CLI 合成结构化 output 并自动提取标题/四段分行）；文件括注用 `--file-notes "path::注 || path2"`。骨架由 CLI 接管，`--done` 后按需核对即可，勿手拼模板。
-16. **代码可能随时在修改**（多 agent 并行），Edit 前重跑 + 查最新态；破坏性 git op 前先备份。
-17. **不奉承用户**，禁止"你说得对"类话术，直接给结论、依据、方案。

package/.worktrees/2c37b1d7/templates/prompts/taskcard-rules.md

@@ -1,29 +0,0 @@
-TaskCard 格式规则（必须严格遵守）：
-- 总长度 20~40 行，不要写成长文档
-- frontmatter 只含必要字段，不加 estimated_hours
-- title 用英文短语（kebab 风格动词短语，如 "Add readonly auxiliary constant"），title_zh 用对应中文标题——两字段是同一任务的双语表示，非不同信息；归档产物与 sillyhub 平台解析各取所需（title_zh 为中文展示首选）
-- goal: 一句话，用 > 多行字符串
-- implementation: 列表，每条一个具体步骤
-- acceptance: 列表，每条可独立验证（不是表格）
-- verify: 列表，实际可执行的命令
-- constraints: 列表，明确边界（含 brownfield 兼容、异常处理）
-- 不需要：修改文件章节、覆盖来源章节、接口定义章节、TDD 步骤章节、参考章节
-- frontmatter 必须以三减号结尾闭合（开头和结尾各一行 ---）。缺结尾会让 postcheck 提取不到 frontmatter，误报「字段缺失 / allowed_paths 为空」
-- allowed_paths 用块式写法（键名换行后每项一行「  - 路径」），不要用流式方括号 [path]——块式与所有校验器一致最稳
-- implementation / acceptance / constraints / verify 的每条列表项是 YAML plain scalar，避免以下特殊字符触发 ScannerError：
-  - 冒号+空格（如代码签名 provider_id:str、queryUsage(id:string)）会被当映射键报 mapping values are not allowed here——去掉冒号后空格或改成中文描述
-  - 花括号且内部含冒号或引号（如 JS 对象、JS 模板字面量）会报 expected block end——改用不含这些字符的中文描述
-  - 引号不成对会报扫描错误
-  - 注：goal 用 > 折叠标量可容忍花括号，goal 里写占位符不炸；只有上述 plain scalar 列表项需注意
-- provides / expects_from 是可选字段：仅当跨 task 契约（一个 task 的接口/DTO/响应被另一个 task 消费）时才填，单 task 或无对外接口场景留空即可
-- 填写后 plan-postcheck 会做硬对账：consumer 的每个 expects_from[provider].needs 字段必须在对应 provider 的 provides.fields 里，否则 plan 阶段阻断（不进入 execute）
-- 不要把内部实现字段塞进 provides；只暴露给其他 task 的对外契约形状
-- related_tests 是可选字段：当本 task 改动会导致既有测试断言失效时填（判据 = 是否有既有测试因本次改动而失败，而非源文件是否共享——覆盖改共享/被多 task 依赖源文件、改被测试精确匹配的值如 UI 文案/按钮文本/错误信息/常量/枚举字面量、改函数签名或返回结构等单文件场景），列出失效测试文件 + 为何失效。关键：这些测试路径必须同时写进本 task 的 allowed_paths（否则子代理被 allowed_paths 铁律锁死、改不了测试 → 退化成主代理事后兜底）；若测试由独立的测试 task 负责，则在该测试 task 的 allowed_paths 覆盖、本字段留空
-- 如果存在 decisions.md，无法覆盖的 D-xxx@vN 在 constraints 中标注
-- **保存前格式自检**（plan-postcheck 会硬校验，不通过到 Step 4 会批量报错，先在这里逐条自查）：
-  - **硬校验字段**（缺失 plan-postcheck 直接报错阻断，必须齐全）：id、title、title_zh、allowed_paths、goal、implementation、acceptance、verify、constraints
-  - **占位符硬拦**（未替换视同缺字段，plan --done 直接报错阻断）：FR-XX（requirement_ids）、D-XXX（decision_ids）、src/example/file.ts（allowed_paths）、一句话说明这个 task（goal）、具体步骤 1（implementation）、可验证的验收条件 1（acceptance）、边界约束 1（constraints）——骨架带出来的占位值必须逐个替换成真实内容
-  - **规范约定字段**（应填但不硬校验，缺失不阻断完成、只影响规范性）：author、created_at、priority、depends_on、blocks
-  - allowed_paths 非空（至少一个真实源文件路径；回归类 task 无源码改动时填被验证的关键入口文件）
-  - acceptance 与 verify 都在 frontmatter 内（漏写会被 plan-postcheck 报「缺少验收标准」/「缺少验证步骤」）
-- **生成方式**：由主 agent 一次性 `sillyspec taskcard <change-name> --all` 预生成全部安全骨架（LF 行尾 + frontmatter 必闭合 + 九个硬校验字段齐全 + author/created_at 自动填；幂等，已存在跳过）。**子代理不要并行跑 taskcard CLI**（2026-08-25 实证撞进度库 SQLite 锁），只往骨架里填语义内容（LF 行尾 + frontmatter 必闭合 + 九个硬校验字段齐全 + author/created_at 自动填），再往骨架里填语义内容——**勿用 Write tool 整文件手写**（CRLF / 漏闭合 `---` / 漏字段的根源，postcheck 报错大多由此来）；已存在的卡命令会跳过不覆盖，局部修改用 Edit 定点改

package/.worktrees/2c37b1d7/templates/prompts/testcase-design.md

@@ -1,12 +0,0 @@
-### 测试用例设计（写测试时按此检查）
-
-写测试是为了拦住回归，不是"有测试文件"。
-**基础习惯照做、不展开**：FIRST（快/独立/可重复/自校验/及时）、金字塔分层（单元为主/集成少量/E2E 只冒烟）、AAA 结构、测试名描述场景、测试数据轻量构造（Object Mother/Builder）、覆盖率不追数字。
-
-逐条对照检查：
-1. **覆盖**：正常路径 + 边界 + 异常/非法输入，不只写业务正例；单测全绿 ≠ 集成正确。
-2. **断言**：断言真实输出/副作用，禁止只"不抛错"的空断言；不 mock 被测方法自身。
-3. **行为 vs 实现**：走公开 API 测行为；重构后功能不变，测试不应失败。
-4. **契约与回归**：覆盖本次改动会破坏的既有行为与相邻模块接口；改公共签名/文案/常量时同步修复受影响既有测试并跑全量，禁止删断言凑绿。
-5. **时间敏感分支**：超时/重试/并发分支别真等——超时参数做成可注入，测试传毫秒级极小值或注入可控时钟推进，再断言超时后的行为（走哪个分支/返回什么/资源是否回收）。
-6. **隔离确定性**：独立 fixture、可重复跑，不依赖共享状态/执行顺序。

package/.worktrees/2c37b1d7/templates/prompts/verify-probes.md

@@ -1,32 +0,0 @@
-### 自动探针（必须先执行）
-
-> 🔧 **先跑 CLI 机械探针（一条命令）**：`sillyspec verify-probes --change <change-name> [--init]`
-> 输出已包含四个纯机械探针的结果（可直接进验证报告）：**探针 1** 未实现标记扫描（design 清单文件逐行 TODO/FIXME 命中 + 行号）、**探针 3** 测试文件递归查找（含 co-located tests/，逐 task 覆盖）、**探针 5** API 契约对账表（endpoints.json × 前端调用 diff）、**探针 6** 删除对账三态（git 事实 × design 声明）。`--init` 顺带生成 verify-result.md 九章节骨架（探针结果已预填，`<!--TODO-->` 占位替换即可）。
->
-> 下列条目中，只有**半语义部分**需要你执行：探针 2（关键词提取）、探针 3.4 集成盲区标注、探针 3.5 断言有效性抽查、探针 4（决策追踪闭环判定）。CLI 已跑的部分勿重复手跑——对 CLI 输出的 warning 项做语义复核即可。
-
-**探针 2：设计关键词覆盖探针（你执行——关键词提取是语义）**
-1. 读取 design.md，从中提取所有能力关键词（如"登录"、"导出"、"批量"、"删除"、"搜索"等动作词）
-2. 对每个关键词，在源码目录中 grep 确认是否有对应的实现代码：
-```bash
-grep -rl "<关键词>" <源码目录>/ --include="*.java" --include="*.js" --include="*.ts" --include="*.jsx" --include="*.tsx" --include="*.py"
-```
-3. 如果某个关键词在源码中完全没有匹配，标记为 ⚠️ 可能未实现
-
-**探针 3 补充（CLI 已查存在性，你补语义）**
-- **集成盲区提示**：测试文件存在 ≠ 集成正确——路由/layout 守卫重定向、跨模块装配这类集成 bug 组件单测覆盖不到，只有集成/冒烟/E2E 才暴露。对路由/layout/跨进程装配敏感的 task，额外检查是否有集成冒烟覆盖；无则标 ⚠️ 集成层未验证（需人工或部署确认）
-- **断言有效性抽查（与 execute「测试用例设计」闭环）**：测试文件存在 ≠ 测试有效。对最能代表本次变更行为的 2-3 个核心测试做抽查：① 断言验证真实输出/副作用，不是只"不抛错"的空断言、只测 getter/setter；② 覆盖边界/异常分支，不只业务正例；③ 走公开 API 测行为，不测实现细节（重构后功能不变测试不应失败）。不达标标 ⚠️ 断言薄弱或无效（advisory：CLI 不阻断，是否 FAIL 由你诚实判定；execute 已按「测试用例设计」写的，这里只抽查核验，不重审全量）
-
-**探针 4：决策追踪覆盖探针（如存在 decisions.md——闭环图机械，证据真伪是语义）**
-1. 从 decisions.md 提取所有当前版本 D-xxx@vN
-2. 检查 requirements.md 是否引用每个 D-xxx@vN，并映射到 FR-xxx
-3. 检查 plan.md 或 tasks/task-NN.md 是否引用每个 FR-xxx/D-xxx@vN
-4. 检查本步骤收集的实现证据是否能回指到对应 D-xxx@vN/FR-xxx
-5. 任意 D-xxx@vN 无下游覆盖时标记为 ⚠️ 决策未闭环
-6. 任意 P0/P1 unresolved/blocking 决策标记为 FAIL blocker
-
-**探针 5 补充（CLI 已出对账表，你做诚实判定）**
-CLI 的 missing backend endpoint 是 advisory（不硬阻断归档）——但 contract gap 是真实集成缺陷，应诚实标 FAIL 并回 execute 补端点，勿因 CLI 不拦而放行。后端 router 的端点清单可用 `sillyspec endpoints extract --change <变更名> --task <task-NN>` 重新静态提取（勿手扫装饰器）。
-
-**探针 6 补充（CLI 已出三态判定，你做终审）**
-以 git 事实为准（真实 > 声明）；CLI 的三态（合规/高风险/未声明）是机械判定，是否构成 FAIL blocker 由你诚实判定，务必如实记录——静默删除代码是 verify 的最大盲区。

package/.worktrees/2c37b1d7/templates/workflows/archive-impact.yaml

@@ -1,79 +0,0 @@
-name: archive-impact
-description: 分析变更影响的模块并同步模块文档
-spec_version: 1
-
-roles:
-  - id: impact-analyzer
-    name: "影响分析"
-    task: "分析 git diff，提取变更影响模块"
-    inputs:
-      paths: [".sillyspec/changes/", ".sillyspec/docs/*/modules/"]
-      hints:
-        grep_patterns: ["_module-map", "module-impact", "git diff"]
-    outputs:
-      - path: ".sillyspec/changes/<change-name>/module-impact.md"
-        required: true
-        checks:
-          - type: file_exists
-          - type: min_lines
-            min: 20
-          - type: contains_sections
-            sections: ["模块影响矩阵", "未匹配文件"]
-    constraints:
-      - "以 git diff 为准（真实 > 声明）"
-      - "影响类型：逻辑变更/数据结构变更/接口变更/调用关系变更/配置变更/新增"
-      - "需要 review 标记不确定的影响"
-
-  - id: doc-syncer
-    name: "文档同步"
-    task: "根据 module-impact.md 同步更新模块索引和卡片"
-    depends_on:
-      - impact-analyzer
-    inputs:
-      from_role: impact-analyzer
-      output: module-impact
-      output_description: "变更影响分析结果，包含模块影响矩阵"
-      paths: [".sillyspec/docs/*/modules/"]
-      hints:
-        grep_patterns: ["_module-map", "module-impact"]
-    outputs:
-      - path: ".sillyspec/docs/sillyspec/modules/_module-map.yaml"
-        required: false
-        checks:
-          - type: file_exists
-      - path: ".sillyspec/docs/sillyspec/modules/<module-id>.md"
-        required: false
-        # checks 跳过：路径含动态 <module-id> 占位符，不适合静态检查
-    constraints:
-      - "结构化事实改 _module-map.yaml，语义解释改模块卡片"
-      - "人工备注区域永远保护，不覆盖"
-      - "更新前展示 diff 摘要，请用户确认"
-
-orchestration:
-  mode: sequential
-  timeout_per_role: 180
-
-checks:
-  role_level:
-    - type: file_exists
-    - type: min_lines
-      min: 10
-  workflow_level:
-    - type: file_exists
-      path: ".sillyspec/changes/<change-name>/module-impact.md"
-
-retry:
-  max_attempts: 1
-  include_failure_context: true
-  retry_scope: failed_role_only
-
-on_check_failure: prompt_retry
-
-permissions:
-  write_mode: patch_only
-  write_scope:
-    - ".sillyspec/docs/"
-    - ".sillyspec/changes/<change-name>/"
-  allow_shell: true
-  allow_network: false
-  allow_git: true

package/.worktrees/2c37b1d7/templates/workflows/scan-docs.yaml

@@ -1,132 +0,0 @@
-name: scan-docs
-description: 并行生成项目的扫描文档（7份）
-spec_version: 1
-
-roles:
-  - id: arch
-    name: "技术架构"
-    task: "生成 ARCHITECTURE.md"
-    inputs:
-      paths:
-        - "src/*.js"
-        - "package.json"
-      hints:
-        grep_patterns: ["class ", "export ", "import ", "schema", "CREATE TABLE"]
-    outputs:
-      - path: "{SPEC_ROOT}/docs/<project>/scan/ARCHITECTURE.md"
-        required: true
-        checks:
-          - type: file_exists
-          - type: min_lines
-            min: 20
-          - type: contains_sections
-            sections: ["技术栈", "架构概览"]
-    constraints:
-      - "禁止读源码全文，只用 grep/rg 搜索"
-      - "Schema 只记表名+说明+字段数"
-
-  - id: conventions
-    name: "代码约定"
-    task: "生成 CONVENTIONS.md"
-    inputs:
-      paths: ["src/"]
-      hints:
-        grep_patterns: ["function ", "const ", "async ", "try ", "catch "]
-    outputs:
-      - path: "{SPEC_ROOT}/docs/<project>/scan/CONVENTIONS.md"
-        required: true
-        checks:
-          - type: file_exists
-          - type: min_lines
-            min: 15
-          - type: contains_sections
-            sections: ["框架隐形规则", "代码风格"]
-    constraints:
-      - "禁止读源码全文"
-      - "提取 3-5 个典型模式"
-
-  - id: structure
-    name: "目录结构+外部集成"
-    task: "生成 STRUCTURE.md 和 INTEGRATIONS.md"
-    inputs:
-      paths: ["./"]
-      hints:
-        grep_patterns: ["fetch", "http", "WebSocket", "ws", "chokidar"]
-    outputs:
-      - path: "{SPEC_ROOT}/docs/<project>/scan/STRUCTURE.md"
-        required: true
-        checks:
-          - type: file_exists
-          - type: min_lines
-            min: 15
-      - path: "{SPEC_ROOT}/docs/<project>/scan/INTEGRATIONS.md"
-        required: true
-        checks:
-          - type: file_exists
-          - type: min_lines
-            min: 15
-    constraints:
-      - "STRUCTURE: 目录树+模块说明"
-      - "INTEGRATIONS: 按类型分组外部依赖"
-
-  - id: quality
-    name: "测试+债务+概览"
-    task: "生成 TESTING.md、CONCERNS.md、PROJECT.md"
-    inputs:
-      paths: ["src/", "packages/"]
-      hints:
-        grep_patterns: ["TODO", "FIXME", "deprecated", "test", "describe"]
-    outputs:
-      - path: "{SPEC_ROOT}/docs/<project>/scan/TESTING.md"
-        required: true
-        checks:
-          - type: file_exists
-          - type: min_lines
-            min: 10
-          - type: no_placeholder
-      - path: "{SPEC_ROOT}/docs/<project>/scan/CONCERNS.md"
-        required: true
-        checks:
-          - type: file_exists
-          - type: min_lines
-            min: 10
-          - type: contains_sections
-            sections: ["代码质量", "依赖风险"]
-      - path: "{SPEC_ROOT}/docs/<project>/scan/PROJECT.md"
-        required: true
-        checks:
-          - type: file_exists
-          - type: min_lines
-            min: 15
-          - type: contains_sections
-            sections: ["项目简介", "技术栈"]
-    constraints:
-      - "CONCERNS 按严重程度分组（🔴/🟡/🟢）"
-      - "不编造不存在的测试"
-
-orchestration:
-  mode: parallel
-  max_concurrent: 4
-  timeout_per_role: 120
-
-checks:
-  workflow_level:
-    - type: file_count
-      path: "scan/"
-      min: 7
-    - type: no_empty_files
-
-retry:
-  max_attempts: 1
-  include_failure_context: true
-  retry_scope: failed_role_only
-
-on_check_failure: prompt_retry
-
-permissions:
-  write_mode: direct
-  write_scope:
-    - "{SPEC_ROOT}/docs/<project>/scan/"
-  allow_shell: true
-  allow_network: false
-  allow_git: false

package/.worktrees/542c4415/.claude/skills/sillyspec-archive/SKILL.md

@@ -1,87 +0,0 @@
----
-name: sillyspec:archive
-description: 用于归档已验证完成的变更。适合用户说"归档、archive、收尾这个变更"。执行模块影响分析 + 同步模块文档 + 移动到 archive 目录 + 更新 ROADMAP。
----
-
-## 何时使用
-
-- 用户说"归档、archive、收尾这个变更"
-- verify 已通过，把变更包归档沉淀
-- 5 步：任务完成度检查 → 模块影响分析 → 同步模块文档 → 确认归档 → 更新路线图
-
-> 🔧 模块影响分析步：先跑 `sillyspec module-impact --change <变更名>` 生成 module-impact.md 骨架——文件×模块归属按 `_module-map.yaml` paths 前缀匹配预填 + 未匹配文件清单，你只需逐行填「影响类型」与 review 标记（以 git diff 为准，真实 > 声明）；已存在不覆盖。
-
-## 多变更说明
-
-项目有多个活跃变更（`.sillyspec/changes/` 下有多个目录）时，所有 `sillyspec run` 命令需加 `--change <变更名>` 指定操作目标；只有一个变更时可省略（CLI 自动检测）。
-
-## 步骤生命周期（所有阶段通用）
-
-> `sillyspec archive` 是 `sillyspec run archive` 的顶层别名，两者等价。
-
-```bash
-sillyspec run archive                          # 输出当前步骤 prompt
-sillyspec run archive --done --output "摘要"   # 完成当前步骤
-sillyspec run archive --status                 # 查看阶段进度
-sillyspec run archive --skip                   # 跳过可选步骤
-sillyspec run archive --reset                  # 重置阶段（从头开始）
-sillyspec run archive --reopen --from-step N   # 重新打开已完成阶段修订（N=序号或名称）
-```
-
-## 通用参数（所有阶段适用）
-
-| 参数 | 说明 |
-|---|---|
-| `--change <名>` | 指定变更名（多活跃变更必填，单变更可省略自动检测） |
-| `--spec-dir <path>` | 指定规范目录（默认 `<项目>/.sillyspec`） |
-| `--non-interactive` | CI/脚本下禁用交互式 prompt |
-| `--skip-approval` | 跳过阶段转换/审批检查（不能跳产物校验 gate——review.json/文档产物硬校验仍在） |
-
-## archive 特有
-
-### `--confirm`（确认归档步骤必填）
-
-第 4 步「确认归档」由 CLI 执行目录移动，**必须带 `--confirm`**：
-
-```bash
-sillyspec run archive --done --confirm --output "确认归档"
-```
-
-不带 `--confirm` 时 CLI 回退步骤为 pending 并提示，不会误归档。
-
-### 归档前硬校验
-
-CLI 移动目录前会校验 `plan.md` 存在——缺失则 `exit(1)` 阻断（目录尚未移动，可补全后重试）。移动后校验 `design.md` / `module-impact.md`（缺失只告警，因目录已移动）。
-
-### 模块文档同步（第 3 步）
-
-第 3 步「sync-module-docs」会更新 `_module-map.yaml` + 模块卡片，**必须暂停等用户确认**：
-
-```bash
-sillyspec run archive --wait --reason "等待用户确认模块文档同步" --options "确认写入,跳过同步" --output "diff 摘要"
-sillyspec run archive --continue --answer "确认写入"
-```
-
-只有用户 `--continue --answer "确认写入"` 后才写入文件。
-
-### 归档结果
-
-归档后变更目录从 `changes/<名>/` 移到 `changes/archive/<名>/`，并从活跃列表注销。后续用 `/sillyspec:commit` 提交。
-
-## 阶段流转
-
-```
-verify → archive → git commit
-```
-
-archive 完成后，运行 `/sillyspec:commit` 提交归档结果（`git add .sillyspec/changes/`）。
-
-## 铁律
-
-- **必须用 exec 工具（shell）执行 CLI，不要自己编造流程**
-- 不要用 `mv`/`rename` 重命名变更目录，必须由 CLI 的「确认归档」步骤移动
-- 归档不可逆——确认前核对变更名、文件列表、module-impact.md
-- 完成后立即 `--done`，不跳过
-
-## 用户指令
-$ARGUMENTS

package/.worktrees/542c4415/.claude/skills/sillyspec-auto/SKILL.md

@@ -1,93 +0,0 @@
----
-name: sillyspec:auto
-description: 自动模式 — 全流程自动推进（通用版）
-argument-hint: "<需求描述>"
----
-
-## 交互规范
-
-**当需要用户从多个选项中做出选择时，必须使用 Claude Code 内置的 AskUserQuestion 工具，将选项以参数传入。** 不要用编号列表让用户手动输入数字。
-
-## 用法
-
-- `/sillyspec:auto 实现用户登录功能`
-- `/sillyspec:auto 修复搜索结果的排序问题`
-
-## 任务
-$ARGUMENTS
-
----
-
-## 执行流程
-
-你是全流程编排器，按 brainstorm → plan → execute → verify 顺序自动推进。
-
-### 启动
-
-```bash
-sillyspec run auto --input "<用户需求>" [--mode <模式>]
-```
-
-2. 读取 CLI 输出的 step prompt（含角色描述）
-3. 执行 prompt 中的操作
-4. **记录 CLI 输出中显示的 Change 名称**（如 `Change: 2026-06-02-xxx`）
-
-### 步骤循环
-
-重复以下循环直到 CLI 输出"全部流程已完成"：
-
-1. **读取 CLI 输出的 step prompt**
-2. **判断是否需要用户确认：**
-   - prompt 含"请用户选择 / 等待用户回答 / 展示给用户 / 用户确认" → **暂停，等用户回复**
-   - 纯内部操作 → **直接执行**
-3. **执行 prompt 要求的操作**
-4. **完成后运行：**
-   ```bash
-   sillyspec run auto --done --change <变更名> --output "<你的摘要>"
-   ```
-   - ⚠️ **必须携带 `--change <变更名>`**，变更名来自启动时 CLI 输出的 `Change:` 字段
-   - **绝不使用 `--change default`**，除非 CLI 启动时明确显示的 Change 名称就是 `default`
-5. **读取 CLI 输出的下一步 prompt**，回到步骤 1
-
-### auto 参数
-
-| 参数 | 说明 |
-|---|---|
-| `--input "<需求>"` | 启动时传入用户需求 |
-| `--mode <模式>` | 显式指定流程模式（默认按复杂度自动分类） |
-| `--done --change <名> --output "..."` | 完成当前步骤（必带 --change） |
-| `--spec-dir <path>` | 指定规范目录 |
-| `--non-interactive` | CI/脚本下禁用交互 |
-
-## 阶段审核门控（Stage Review Gate）
-
-审核发生在 brainstorm / plan / execute 各阶段的 review 步骤，**分级由 CLI 按变更规模自动判定**（不是 agent 凭关键词或复杂度启发式判断）：
-
-- **tier=self**（变更 ≤3 文件）：当前 agent 自审，直接产 review.json。
-- **tier=independent**（变更 >3 文件）：必须派发**独立 QA 子代理**（独立上下文，不共享实现者分析）产 review.json。
-
-CLI 会在 review 步骤注入：完整 JSON schema 表 + 示例 + docHash 算法 + 自动决策 checklist（AC-001 起，逐条核验公共 API / schema / 鉴权 / 文件边界 / 依赖 / 核心模块 / 兼容性 / 业务等维度）。你按**实际注入的契约与 tier 指令**执行：
-
-- checklist 全 ✅ 且方案唯一合理 → AUTO_DECIDED，推进下一阶段
-- checklist 有 ❌（影响架构/数据/接口/权限/兼容性/业务）→ 暂停，用 AskUserQuestion 让用户选择
-
-**不要**自行编造"简单/中等/复杂 → N 个审核子代理"规则——审核子代理数量由 tier 决定（self=0 额外子代理，independent=1 个独立 QA），不是复杂度启发式；以 CLI 实际注入的 tier 与 checklist 为准。
-
-## 关键规则
-
-- 不要跳过任何步骤
-- 不要手动修改进度数据（SQLite 数据库）
-- 不要自动 commit，只 `git add`
-- 不要使用 npx
-- 不要编造不存在的 CLI 子命令
-- 遇到命令报错 → 展示错误，暂停等用户介入
-- **每次 `sillyspec run auto --done` 都必须携带 `--change <变更名>`**（= CLI 首次输出的 Change 名）
-
-## 异常处理
-
-- 命令执行失败 → 展示错误信息，暂停等待用户指示
-- 用户说"停止"/"暂停" → 立即停止，报告当前进度
-
-## 完成条件
-
-CLI 输出"全部流程已完成"后，输出完整流程总结，提示用户提交改动（`/sillyspec:commit`）。

package/.worktrees/542c4415/.claude/skills/sillyspec-brainstorm/SKILL.md

@@ -1,114 +0,0 @@
----
-name: sillyspec:brainstorm
-description: 用于正式开始开发前的需求澄清和技术方案设计。适合用户提出新功能、新模块、架构调整、复杂改造，或说"先做需求分析、输出技术方案、创建变更前先梳理、帮我设计下"。产出结构化方案（design/proposal/requirements/tasks 四件套），但不直接写代码。
----
-
-## 交互规范
-
-**当需要用户从多个选项中做出选择时，必须使用 Claude Code 内置的 AskUserQuestion 工具，将选项以参数传入。** 不要用编号列表让用户手动输入数字。
-
-## 何时使用
-
-- 用户提出新功能、新模块、架构调整、复杂改造
-- 用户说"先做需求分析、输出技术方案、创建变更前先梳理、帮我设计下"
-- 产出：`design.md` + `proposal.md` + `requirements.md` + `tasks.md`（四件套），不写代码
-
-## 多变更说明
-
-项目有多个活跃变更（`.sillyspec/changes/` 下有多个目录）时，所有 `sillyspec run` 命令需加 `--change <变更名>` 指定操作目标；只有一个变更时可省略（CLI 自动检测）。建议变更名格式：`YYYY-MM-DD-<简短描述>`。
-
-## 步骤生命周期（所有阶段通用）
-
-> `sillyspec brainstorm` 是 `sillyspec run brainstorm` 的顶层别名，两者等价。
-
-```bash
-sillyspec run brainstorm                       # 输出当前步骤 prompt
-sillyspec run brainstorm --done --output "摘要"     # 完成当前步骤（--input "用户原话" 记录输入）
-sillyspec run brainstorm --status              # 查看阶段进度
-sillyspec run brainstorm --skip                # 跳过可选步骤
-sillyspec run brainstorm --reset               # 重置阶段（从头开始）
-sillyspec run brainstorm --reopen --from-step N     # 重新打开已完成阶段修订（N=序号或名称）
-sillyspec run brainstorm --wait --reason "..." --options "A,B"   # 暂停等用户决策
-sillyspec run brainstorm --continue --answer "..."               # 恢复等待中的步骤
-sillyspec run brainstorm --done --answer "..." --output "..."    # 一步完成 wait+done
-```
-
-## 通用参数（所有阶段适用）
-
-| 参数 | 说明 |
-|---|---|
-| `--change <名>` | 指定变更名（多活跃变更必填，单变更可省略自动检测） |
-| `--spec-dir <path>` | 指定规范目录（默认 `<项目>/.sillyspec`） |
-| `--non-interactive` | CI/脚本下禁用交互式 prompt |
-| `--interactive` | 强制交互（即便 stdin 非 TTY） |
-| `--skip-approval` | 跳过阶段转换/审批检查（不能跳产物校验 gate——review.json/文档产物硬校验仍在） |
-
-## brainstorm 特有：requiresWait 步骤
-
-某些步骤（如"对话式探索与需求澄清"）需要用户输入。两种方式：
-
-> 自动去重：若前置 step 已对同一问题（waitReason 归一化后相同）确认过，后续重复 wait 会自动跳过，无需再 `--wait`。
-
-- **方式一（推荐）**：分步——先 `--wait` 记录等待，让用户亲眼看到 CLI 打出的选项再作答，再 `--continue --answer`，最后 `--done`：
-  ```bash
-  sillyspec run brainstorm --wait --change <名> --reason "等待用户回答" --output "探索问题"
-  sillyspec run brainstorm --continue --answer "用户回答" --change <名>
-  sillyspec run brainstorm --done --change <名> --output "需求已澄清"
-  ```
-- **方式二**：AI 自行与用户交互后，一步完成（仅在用户已在对话中明确给出答案、无需再走 CLI 等待展示时用）：
-  ```bash
-  sillyspec run brainstorm --done --change <名> --answer "用户回答" --output "需求已澄清"
-  ```
-
-> ⚠️ 两种方式都要求 `--answer` 是**用户真实的回答**，不是你替用户编的回答。`requiresWait` 门只校验 `--answer` 非空，挡不住「AI 伪造用户回答」——所以对方案选择/设计确认这类关键决策，优先用方式一让用户亲手作答，而不是 AI 中继一句话带过。
-
-## 阶段流转
-
-```
-                ┌─ scale=large → plan（四件套齐）
-scan → brainstorm ┤
-                └─ scale=small → quick --linked-changes（仅 design.md）
-```
-
-brainstorm 完成时按 design.md frontmatter 的 `scale` 分叉：
-- **large**（多文件/跨模块/有状态机或 schema 变更）：四件套齐 + Design Grill 审查通过（tier=independent 时由独立审查子代理产出 stage review.json）→ `sillyspec run plan --change <变更名>`
-- **small**（≤2 文件、单模块、无跨模块依赖）：仅生成 design.md → `sillyspec run quick --linked-changes <变更名>`
-
-> 规模由 AI 在 brainstorm 最后一步评估并写入 design.md frontmatter。判错可手动改 `scale` 后再跑相应阶段。
-
-### Stage Review Gate（brainstorm 末尾的 design review.json）
-
-brainstorm 在 `tier=independent` 规模下除 design.md 等四件套外，还需产出一个 stage 级 `review.json`，CLI `Stage Review Gate` 硬校验其 schema 与 `docHash` 真实性。
-
-- 路径：`.sillyspec/.runtime/stage-reviews/brainstorm-review-<stage-review-run-id>/review.json`（目录可能不存在需手建；run-id 由该步 `--done` prompt 输出指定）。marker 文件 `.runtime/current-stage-review-run-id-brainstorm-<变更名>`。
-- **run-id / marker 由 CLI 自动生成注入**（review step prompt 渲染时 echo 完整目录路径 + 写 marker；撞 gate 报缺 review.json 时 gate 也 echo 完整路径 + 写 marker）。直接用 CLI 给的路径写 review.json，**勿手算 run-id（必须 `review-` 前缀）、勿手写 marker**。卡住时用 `sillyspec register-stage-review --change <名> --stage brainstorm` 一步生成。
-- 字段（`schemaVersion:1`，`reviewType=design` —— 区别于 execute 的 `acceptance`）：
-
-  ```json
-  {
-    "schemaVersion": 1,
-    "reviewType": "design",
-    "reviewedFiles": ["changes/<变更名>/design.md"],   // [0] 为主文档
-    "docHash": "<sha256(reviewedFiles[0] 文件内容，hex)>",
-    "specVerdict": "pass",       // pass | fail | cannot_verify
-    "qualityVerdict": "pass",    // pass | fail | cannot_verify
-    "checklist": [               // 扁平数组，逐条对照 design 章节核验
-      { "item": "背景与目标", "result": "pass", "note": "..." }   // result: pass | gap | fail
-    ],
-    "requiredEvidence": [],      // cannot_verify 时必填非空
-    "reviewerNotes": "..."
-  }
-  ```
-
-- `docHash` = `sha256(主审查文档内容)`（hex）—— brainstorm 主文档是 `design.md`（即 `reviewedFiles[0]`）。CLI 重算 sha256 比对，不符判伪造（fail-closed）。docHash 可先占位（如 "TODO"）；改 design.md 后勿手算 sha256——跑 `sillyspec register-stage-review --change <变更名> --stage brainstorm --refresh-hash` 一键重算代填（verdict 保留；design 改版多阶段联动加 --all）。`tier=self`（≤3 文件）降级为当前 agent 自审，不强制独立子代理。
-- 运行时 CLI 会把精确 schema 表 + 完整 JSON 示例 + docHash 算法注入到该步 prompt，以你实际收到的注入版契约为权威逐字模板。
-
-## 铁律
-
-- **必须用 exec 工具（shell）执行 CLI，不要自己编造流程**
-- 只做当前步骤 prompt 描述的操作，不跳过、不自行扩展
-- 产物写入 CLI 输出的 `changeDir` 目录（如 `<changeDir>/design.md`），不要自己拼路径
-- 完成后立即 `--done`，不跳过
-
-## 用户指令
-$ARGUMENTS