sillyspec 3.26.10 → 3.26.13

package/.claude/skills/sillyspec-verify/SKILL.md

@@ -1,83 +1,83 @@
----
-name: sillyspec:verify
-description: 用于验证代码实现是否符合 design 和模块文档。适合用户说"验证下、检查下、跑 verify"。对照 design.md + 模块文档检查任务完成度、设计一致性、运行测试。
----
-
-## 何时使用
-
-- 用户说"验证下、检查下、跑 verify"
-- 对照 design.md + 模块文档检查任务完成度
-- 设计一致性检查 + 运行测试套件
-- 产出 `verify-result.md`（PASS / PASS WITH NOTES / FAIL）
-
-## 多变更说明
-
-项目有多个活跃变更（`.sillyspec/changes/` 下有多个目录）时，所有 `sillyspec run` 命令需加 `--change <变更名>` 指定操作目标；只有一个变更时可省略（CLI 自动检测）。
-
-## 步骤生命周期（所有阶段通用）
-
-> `sillyspec verify` 是 `sillyspec run verify` 的顶层别名，两者等价。
-
-```bash
-sillyspec run verify                           # 输出当前步骤 prompt
-sillyspec run verify --done --output "摘要"    # 完成当前步骤（--input "用户原话" 记录输入）
-sillyspec run verify --status                  # 查看阶段进度
-sillyspec run verify --skip                    # 跳过可选步骤
-sillyspec run verify --reset                   # 重置阶段（从头开始）
-sillyspec run verify --reopen --from-step N    # 重新打开已完成阶段修订（N=序号或名称）
-```
-
-## 通用参数（所有阶段适用）
-
-| 参数 | 说明 |
-|---|---|
-| `--change <名>` | 指定变更名（多活跃变更必填，单变更可省略自动检测） |
-| `--spec-dir <path>` | 指定规范目录（默认 `<项目>/.sillyspec`） |
-| `--non-interactive` | CI/脚本下禁用交互式 prompt |
-| `--skip-approval` | 跳过阶段转换/审批检查（不能跳产物校验 gate——review.json/文档产物硬校验仍在） |
-
-## verify 特有：完成门控（重要）
-
-verify 是只读阶段（**禁止改代码/改 git 状态**，只检查 + 写报告）。
-
-**diff 对账基点**：本变更走 worktree 时，「加载规范并锚定」步骤会注入 worktree 基线锚点（分支名 + `git merge-base` 真实基点）——对照设计做 diff 对账时以它为基点，**不要拿主仓当前 HEAD 当基点**（主仓在 execute 期间可能被并行推进，用错基点会把别人的演进误判为本变更越权改动）。task review 的 base/head 引用分支上的 commit，逐 task 核验用 `git diff <base>..<head>`。完成时有硬校验：
-
-- **必须产出 `verify-result.md`**——不存在则阻断完成（不能跳过报告直接 `--done`）
-- **结论为 `FAIL` 则阻断完成**——不能带着 FAIL 标记 verify 完成
-- **`integration-critical` / `deployment-critical` 变更**（design/plan 含 daemon/session/lease/lifecycle 等关键词）：结论 PASS WITH NOTES 降级为 FAIL，必须有真实集成证据（Runtime Evidence section）——该证据为 Agent 自报告，CLI 仅校验其字面存在、不独立运行时核验，须真实执行过
-- `verify-required-evidence.json`（execute 写入，schema `{items:[{task,verdict,evidence:[]}]}`）中 cannot_verify 任务未在 verify-result.md 体现 → **advisory warn（不阻断归档）**；evidence 是否真满足（satisfied/missing/partial）由 agent 在 verify-result.md 自报告，CLI 只查任务被提及、不替你语义判定。结论能否 PASS 由你诚实判定（有 missing evidence 不应 PASS）。
-
-被阻断时 CLI 打印 ❌ 校验失败，不会提示"验证通过"。修复 `verify-result.md` 后重新 `--done`。
-
-## verify-result.md 格式
-
-```markdown
-# 验证报告
-## 结论
-PASS / PASS WITH NOTES / FAIL      ← 必须有结论章节（标题含"结论/Conclusion/Result/结果"即可，不限于确切"## 结论"），FAIL 会阻断 verify 完成
-## 任务完成度
-## 设计一致性
-## 探针结果
-## 测试结果
-## 变更风险等级
-## Runtime Evidence（integration/deployment-critical 必填；自报告，CLI 仅字面校验、不独立核验）
-```
-
-## 阶段流转
-
-```
-execute → verify → archive
-```
-
-verify 通过（PASS）后，运行 `sillyspec run archive --change <变更名>` 归档。FAIL 则修复后重跑 `sillyspec run verify`。
-
-## 铁律
-
-- **必须用 exec 工具（shell）执行 CLI，不要自己编造流程**
-- verify 阶段**绝对禁止** git checkout/restore/reset、删除/覆盖源码文件——只检查 + 报告
-- 发现问题只报告，不尝试修复（修复回 execute）
-- `verify-result.md` 结论必须基于证据，不写"看起来没问题"
-- 完成后立即 `--done`，不跳过
-
-## 用户指令
-$ARGUMENTS
+---
+name: sillyspec:verify
+description: 用于验证代码实现是否符合 design 和模块文档。适合用户说"验证下、检查下、跑 verify"。对照 design.md + 模块文档检查任务完成度、设计一致性、运行测试。
+---
+
+## 何时使用
+
+- 用户说"验证下、检查下、跑 verify"
+- 对照 design.md + 模块文档检查任务完成度
+- 设计一致性检查 + 运行测试套件
+- 产出 `verify-result.md`（PASS / PASS WITH NOTES / FAIL）
+
+## 多变更说明
+
+项目有多个活跃变更（`.sillyspec/changes/` 下有多个目录）时，所有 `sillyspec run` 命令需加 `--change <变更名>` 指定操作目标；只有一个变更时可省略（CLI 自动检测）。
+
+## 步骤生命周期（所有阶段通用）
+
+> `sillyspec verify` 是 `sillyspec run verify` 的顶层别名，两者等价。
+
+```bash
+sillyspec run verify                           # 输出当前步骤 prompt
+sillyspec run verify --done --output "摘要"    # 完成当前步骤（--input "用户原话" 记录输入）
+sillyspec run verify --status                  # 查看阶段进度
+sillyspec run verify --skip                    # 跳过可选步骤
+sillyspec run verify --reset                   # 重置阶段（从头开始）
+sillyspec run verify --reopen --from-step N    # 重新打开已完成阶段修订（N=序号或名称）
+```
+
+## 通用参数（所有阶段适用）
+
+| 参数 | 说明 |
+|---|---|
+| `--change <名>` | 指定变更名（多活跃变更必填，单变更可省略自动检测） |
+| `--spec-dir <path>` | 指定规范目录（默认 `<项目>/.sillyspec`） |
+| `--non-interactive` | CI/脚本下禁用交互式 prompt |
+| `--skip-approval` | 跳过阶段转换/审批检查（不能跳产物校验 gate——review.json/文档产物硬校验仍在） |
+
+## verify 特有：完成门控（重要）
+
+verify 是只读阶段（**禁止改代码/改 git 状态**，只检查 + 写报告）。
+
+**diff 对账基点**：本变更走 worktree 时，「加载规范并锚定」步骤会注入 worktree 基线锚点（分支名 + `git merge-base` 真实基点）——对照设计做 diff 对账时以它为基点，**不要拿主仓当前 HEAD 当基点**（主仓在 execute 期间可能被并行推进，用错基点会把别人的演进误判为本变更越权改动）。task review 的 base/head 引用分支上的 commit，逐 task 核验用 `git diff <base>..<head>`。完成时有硬校验：
+
+- **必须产出 `verify-result.md`**——不存在则阻断完成（不能跳过报告直接 `--done`）
+- **结论为 `FAIL` 则阻断完成**——不能带着 FAIL 标记 verify 完成
+- **`integration-critical` / `deployment-critical` 变更**（design/plan 含 daemon/session/lease/lifecycle 等关键词）：结论 PASS WITH NOTES 降级为 FAIL，必须有真实集成证据（Runtime Evidence section）——该证据为 Agent 自报告，CLI 仅校验其字面存在、不独立运行时核验，须真实执行过
+- `verify-required-evidence.json`（execute 写入，schema `{items:[{task,verdict,evidence:[]}]}`）中 cannot_verify 任务未在 verify-result.md 体现 → **advisory warn（不阻断归档）**；evidence 是否真满足（satisfied/missing/partial）由 agent 在 verify-result.md 自报告，CLI 只查任务被提及、不替你语义判定。结论能否 PASS 由你诚实判定（有 missing evidence 不应 PASS）。
+
+被阻断时 CLI 打印 ❌ 校验失败，不会提示"验证通过"。修复 `verify-result.md` 后重新 `--done`。
+
+## verify-result.md 格式
+
+```markdown
+# 验证报告
+## 结论
+PASS / PASS WITH NOTES / FAIL      ← 必须有结论章节（标题含"结论/Conclusion/Result/结果"即可，不限于确切"## 结论"），FAIL 会阻断 verify 完成
+## 任务完成度
+## 设计一致性
+## 探针结果
+## 测试结果
+## 变更风险等级
+## Runtime Evidence（integration/deployment-critical 必填；自报告，CLI 仅字面校验、不独立核验）
+```
+
+## 阶段流转
+
+```
+execute → verify → archive
+```
+
+verify 通过（PASS）后，运行 `sillyspec run archive --change <变更名>` 归档。FAIL 则修复后重跑 `sillyspec run verify`。
+
+## 铁律
+
+- **必须用 exec 工具（shell）执行 CLI，不要自己编造流程**
+- verify 阶段**绝对禁止** git checkout/restore/reset、删除/覆盖源码文件——只检查 + 报告
+- 发现问题只报告，不尝试修复（修复回 execute）
+- `verify-result.md` 结论必须基于证据，不写"看起来没问题"
+- 完成后立即 `--done`，不跳过
+
+## 用户指令
+$ARGUMENTS

package/.claude/skills/sillyspec-workspace/SKILL.md

@@ -1,169 +1,169 @@
----
-name: sillyspec:workspace
-description: 工作区管理 — 初始化、管理多项目工作区，查看子项目状态
----
-
-## 交互规范
-
-**当需要用户从多个选项中做出选择时，必须使用 Claude Code 内置的 AskUserQuestion 工具，将选项以参数传入。**
-
-不要用编号列表让用户手动输入数字。
-如果需要自由输入，在 AskUserQuestion 的选项中加入"Other（自定义输入）"。
-
----
-
-## CLI 边界（重要）
-
-sillyspec CLI **没有 `workspace` 顶层命令**。本 skill 通过直接读写 `.sillyspec/projects/*.yaml` 管理工作区，配套用 `sillyspec scan` 扫描子项目、`sillyspec init` 安装命令模板。**不要编造 `sillyspec workspace ...` 子命令。**
-
-## 相关 CLI 命令
-
-```bash
-sillyspec scan                       # 扫描子项目生成文档
-sillyspec init [--tool <名>]         # 安装命令模板
-sillyspec progress show              # 查看进度
-```
-
-你现在是 SillySpec 的工作区管理器。
-
-## 用户指令
-$ARGUMENTS
-
-## 核心流程
-
-### Step 1: 检查工作区配置
-
-```bash
-ls .sillyspec/projects/*.yaml 2>/dev/null | grep -q .
-```
-
-如果不存在 → 这是一个尚未配置工作区的项目。询问用户：
-   1. 初始化工作区
-   2. 跳过
-
-### Step 2: 解析指令
-
-根据 `$ARGUMENTS` 或默认行为：
-
-- **无参数 / `status`** → 显示工作区状态
-- **`add`** → 添加子项目
-- **`remove`** → 移除子项目
-- **`info`** → 显示某个子项目详情
-- 无参数且 projects/*.yaml 不存在 → 初始化工作区
-
-### Step 3: 执行对应操作
-
-#### 3a. 初始化工作区（projects/ 不存在时）
-
-1. 询问工作区名称（默认用当前目录名）
-2. 逐个添加子项目：
-   - 询问子项目名称（如 `frontend`、`backend`）
-   - 询问子项目路径（相对于工作区根目录，如 `./frontend`）
-   - 询问子项目角色描述（如 `前端 - Vue3 + TypeScript`）
-   - 询问仓库地址（可选）
-   - 验证路径存在
-   添加完后询问：
-   > 1. 继续添加子项目
-   > 2. 完成，配置共享规范
-3. 询问共享规范文件
-4. 为每个子项目创建 `.sillyspec/projects/<name>.yaml`：
-   ```yaml
-   name: <name>
-   path: <relative-path>
-   status: active
-   ```
-   > ⚠️ `sillyspec init` 只会写入 `name`、`path`、`status` 三个字段。
-   > `role` 和 `repo` 由 `/sillyspec:workspace add` 追加。
-5. 创建 `.sillyspec/shared/` 目录
-
-#### 3b. 添加子项目（`add`）
-
-1. 询问名称、路径、角色
-2. 验证路径存在
-3. 创建/更新 `.sillyspec/projects/<name>.yaml`
-4. Git 提交
-
-#### 3c. 移除子项目（`remove`）
-
-1. 显示当前所有子项目列表
-2. 询问要移除哪个：
-   > 1. （列出子项目名称）
-   > 2. 取消
-3. 删除 `.sillyspec/projects/<name>.yaml`
-4. Git 提交
-
-#### 3d. 工作区状态（`status`，默认）
-
-读取所有 `projects/*.yaml`，对每个子项目检查：
-
-```bash
-# 读取子项目列表
-for f in .sillyspec/projects/*.yaml; do
-  [ -f "$f" ] || continue
-  proj_name=$(basename "$f" .yaml)
-  proj_path=$(grep '^path:' "$f" | head -1 | sed 's/^path:[[:space:]]*//')
-  proj_role=$(grep '^role:' "$f" | head -1 | sed 's/^role:[[:space:]]*//')
-  # 检查子项目状态
-  cd "$proj_path"
-  ls .sillyspec/ 2>/dev/null
-  cat .sillyspec/PROJECT.md 2>/dev/null
-  ls .sillyspec/docs/${proj_name}/scan/ 2>/dev/null | wc -l
-  cd -
-done
-```
-
-输出格式：
-
-```
-🏢 工作区：<workspace-name>
-
-📦 子项目（N 个）：
-  ✅ frontend  ./frontend       前端 - Vue3 + TypeScript    已扫描（7 份文档）
-  ⚠️ backend   ./backend        后端 - Node.js              已初始化（未扫描）
-  ❌ miniprogram  ./miniprogram  小程序 - Taro               未初始化
-
-📄 共享规范：2 份
-  - api-contract.md
-  - data-models.md
-
-💡 操作：
-  /sillyspec:workspace add        — 添加子项目
-  /sillyspec:workspace remove     — 移除子项目
-  /sillyspec:init                 — 初始化子项目
-  /sillyspec:scan                 — 扫描子项目
-```
-
-#### 3e. 子项目详情（`info <name>`）
-
-显示指定子项目的详细信息，包括 PROJECT.md、REQUIREMENTS.md 内容摘要、扫描文档列表。
-
-### Step 4: projects/*.yaml 格式
-
-每个子项目对应 `.sillyspec/projects/<name>.yaml`：
-
-**sillyspec init 创建的格式（3 字段）：**
-```yaml
-name: frontend
-path: ./frontend
-status: active
-```
-
-**workspace add 扩展的格式（最多 5 字段）：**
-```yaml
-name: frontend
-path: ./frontend
-status: active
-role: 前端 - Vue3 + TypeScript
-repo: https://github.com/xxx/frontend.git  # 可选
-```
-
-### 最后说：
-
-> 工作区已更新。
-> 下一步：对子项目运行 `/sillyspec:init` 或 `/sillyspec:scan`。
-
-## 绝对规则
-- 不修改子项目目录下的任何文件
-- projects/*.yaml 必须是合法 YAML
-- 子项目路径必须是相对于工作区根目录的相对路径
-- 路径必须验证存在性
+---
+name: sillyspec:workspace
+description: 工作区管理 — 初始化、管理多项目工作区，查看子项目状态
+---
+
+## 交互规范
+
+**当需要用户从多个选项中做出选择时，必须使用 Claude Code 内置的 AskUserQuestion 工具，将选项以参数传入。**
+
+不要用编号列表让用户手动输入数字。
+如果需要自由输入，在 AskUserQuestion 的选项中加入"Other（自定义输入）"。
+
+---
+
+## CLI 边界（重要）
+
+sillyspec CLI **没有 `workspace` 顶层命令**。本 skill 通过直接读写 `.sillyspec/projects/*.yaml` 管理工作区，配套用 `sillyspec scan` 扫描子项目、`sillyspec init` 安装命令模板。**不要编造 `sillyspec workspace ...` 子命令。**
+
+## 相关 CLI 命令
+
+```bash
+sillyspec scan                       # 扫描子项目生成文档
+sillyspec init [--tool <名>]         # 安装命令模板
+sillyspec progress show              # 查看进度
+```
+
+你现在是 SillySpec 的工作区管理器。
+
+## 用户指令
+$ARGUMENTS
+
+## 核心流程
+
+### Step 1: 检查工作区配置
+
+```bash
+ls .sillyspec/projects/*.yaml 2>/dev/null | grep -q .
+```
+
+如果不存在 → 这是一个尚未配置工作区的项目。询问用户：
+   1. 初始化工作区
+   2. 跳过
+
+### Step 2: 解析指令
+
+根据 `$ARGUMENTS` 或默认行为：
+
+- **无参数 / `status`** → 显示工作区状态
+- **`add`** → 添加子项目
+- **`remove`** → 移除子项目
+- **`info`** → 显示某个子项目详情
+- 无参数且 projects/*.yaml 不存在 → 初始化工作区
+
+### Step 3: 执行对应操作
+
+#### 3a. 初始化工作区（projects/ 不存在时）
+
+1. 询问工作区名称（默认用当前目录名）
+2. 逐个添加子项目：
+   - 询问子项目名称（如 `frontend`、`backend`）
+   - 询问子项目路径（相对于工作区根目录，如 `./frontend`）
+   - 询问子项目角色描述（如 `前端 - Vue3 + TypeScript`）
+   - 询问仓库地址（可选）
+   - 验证路径存在
+   添加完后询问：
+   > 1. 继续添加子项目
+   > 2. 完成，配置共享规范
+3. 询问共享规范文件
+4. 为每个子项目创建 `.sillyspec/projects/<name>.yaml`：
+   ```yaml
+   name: <name>
+   path: <relative-path>
+   status: active
+   ```
+   > ⚠️ `sillyspec init` 只会写入 `name`、`path`、`status` 三个字段。
+   > `role` 和 `repo` 由 `/sillyspec:workspace add` 追加。
+5. 创建 `.sillyspec/shared/` 目录
+
+#### 3b. 添加子项目（`add`）
+
+1. 询问名称、路径、角色
+2. 验证路径存在
+3. 创建/更新 `.sillyspec/projects/<name>.yaml`
+4. Git 提交
+
+#### 3c. 移除子项目（`remove`）
+
+1. 显示当前所有子项目列表
+2. 询问要移除哪个：
+   > 1. （列出子项目名称）
+   > 2. 取消
+3. 删除 `.sillyspec/projects/<name>.yaml`
+4. Git 提交
+
+#### 3d. 工作区状态（`status`，默认）
+
+读取所有 `projects/*.yaml`，对每个子项目检查：
+
+```bash
+# 读取子项目列表
+for f in .sillyspec/projects/*.yaml; do
+  [ -f "$f" ] || continue
+  proj_name=$(basename "$f" .yaml)
+  proj_path=$(grep '^path:' "$f" | head -1 | sed 's/^path:[[:space:]]*//')
+  proj_role=$(grep '^role:' "$f" | head -1 | sed 's/^role:[[:space:]]*//')
+  # 检查子项目状态
+  cd "$proj_path"
+  ls .sillyspec/ 2>/dev/null
+  cat .sillyspec/PROJECT.md 2>/dev/null
+  ls .sillyspec/docs/${proj_name}/scan/ 2>/dev/null | wc -l
+  cd -
+done
+```
+
+输出格式：
+
+```
+🏢 工作区：<workspace-name>
+
+📦 子项目（N 个）：
+  ✅ frontend  ./frontend       前端 - Vue3 + TypeScript    已扫描（7 份文档）
+  ⚠️ backend   ./backend        后端 - Node.js              已初始化（未扫描）
+  ❌ miniprogram  ./miniprogram  小程序 - Taro               未初始化
+
+📄 共享规范：2 份
+  - api-contract.md
+  - data-models.md
+
+💡 操作：
+  /sillyspec:workspace add        — 添加子项目
+  /sillyspec:workspace remove     — 移除子项目
+  /sillyspec:init                 — 初始化子项目
+  /sillyspec:scan                 — 扫描子项目
+```
+
+#### 3e. 子项目详情（`info <name>`）
+
+显示指定子项目的详细信息，包括 PROJECT.md、REQUIREMENTS.md 内容摘要、扫描文档列表。
+
+### Step 4: projects/*.yaml 格式
+
+每个子项目对应 `.sillyspec/projects/<name>.yaml`：
+
+**sillyspec init 创建的格式（3 字段）：**
+```yaml
+name: frontend
+path: ./frontend
+status: active
+```
+
+**workspace add 扩展的格式（最多 5 字段）：**
+```yaml
+name: frontend
+path: ./frontend
+status: active
+role: 前端 - Vue3 + TypeScript
+repo: https://github.com/xxx/frontend.git  # 可选
+```
+
+### 最后说：
+
+> 工作区已更新。
+> 下一步：对子项目运行 `/sillyspec:init` 或 `/sillyspec:scan`。
+
+## 绝对规则
+- 不修改子项目目录下的任何文件
+- projects/*.yaml 必须是合法 YAML
+- 子项目路径必须是相对于工作区根目录的相对路径
+- 路径必须验证存在性

package/.gitattributes

@@ -0,0 +1,2 @@
+# 强制所有被识别为文本的文件使用 LF 换行符
+* text=auto eol=lf

package/.husky/pre-push

@@ -1,20 +1,20 @@
-#!/bin/sh
-echo "🔧 pre-push: running lint + test + docs gate..."
-npm run lint --silent 2>&1
-if [ $? -ne 0 ]; then
-  echo "❌ pre-push: lint failed, aborting push"
-  exit 1
-fi
-npm test --silent 2>&1
-if [ $? -ne 0 ]; then
-  echo "❌ pre-push: test failed, aborting push"
-  exit 1
-fi
-# docs gate ratchet（doc-consistency-debt 第七节）：docs check 失效数 ≤ 基线放行。
-# 基线 .sillyspec/docs-check-baseline 缺失/损坏时 fail-closed exit 2 拦截。
-node bin/sillyspec.js docs gate 2>&1
-if [ $? -ne 0 ]; then
-  echo "❌ pre-push: docs gate failed, aborting push"
-  exit 1
-fi
-echo "✅ pre-push: lint + test + docs gate passed"
+#!/bin/sh
+echo "🔧 pre-push: running lint + test + docs gate..."
+npm run lint --silent 2>&1
+if [ $? -ne 0 ]; then
+  echo "❌ pre-push: lint failed, aborting push"
+  exit 1
+fi
+npm test --silent 2>&1
+if [ $? -ne 0 ]; then
+  echo "❌ pre-push: test failed, aborting push"
+  exit 1
+fi
+# docs gate ratchet（doc-consistency-debt 第七节）：docs check 失效数 ≤ 基线放行。
+# 基线 .sillyspec/docs-check-baseline 缺失/损坏时 fail-closed exit 2 拦截。
+node bin/sillyspec.js docs gate 2>&1
+if [ $? -ne 0 ]; then
+  echo "❌ pre-push: docs gate failed, aborting push"
+  exit 1
+fi
+echo "✅ pre-push: lint + test + docs gate passed"