create-dwy 0.14.1 → 0.14.3

package/templates/ai-tools/skills//345/256/211/345/205/250/dwy-deploy-audit/references/security-doc-search.md

@@ -0,0 +1,179 @@
+## 权威安全文档检索
+
+当 `references/checks-*.md` 无法覆盖以下场景时，先查权威文档，再下结论：
+
+- 目标版本是否存在已知高危 CVE
+- 某个配置项语义不确定
+- audit 输出与经验规则冲突
+- 用户要求“按官方安全文档”解释
+- 需要把新发现沉淀回本 skill
+
+---
+
+## 检索优先级
+
+1. **官方产品文档 / 官方安全页**
+2. **官方维护的版本公告 / 安全公告 / release notes**
+3. **CISA KEV / NVD / CVE 记录**
+4. **OWASP Cheat Sheet**
+
+禁止把论坛、博客、聚合站当一手依据。
+
+---
+
+## 固定检索策略
+
+### 1. 先查“配置语义”
+
+按产品名 + 配置项名搜索，优先官方文档：
+
+- `OpenSSH sshd_config PermitRootLogin PasswordAuthentication official`
+- `nginx ssl_protocols ssl_stapling add_header official`
+- `PostgreSQL listen_addresses ssl official`
+- `Redis protected mode bind requirepass official`
+- `Docker daemon remote access docker.sock log-driver official`
+
+目标：确认该配置项的**官方含义、默认值、启用条件、版本约束**。
+
+### 2. 再查“版本安全”
+
+当 audit 输出包含版本号时，按 `产品 + 版本 + CVE` 搜：
+
+- `nginx 1.24.0 CVE`
+- `postgresql 15.6 CVE`
+- `redis 7.2.4 CVE`
+- `docker engine 26.1.4 CVE`
+
+目标：确认是否存在：
+
+- 高危未修复漏洞
+- 该版本已被官方宣布 EOL
+- 配置项依赖的最小版本门槛
+
+### 3. 最后查“硬化基线”
+
+当官方文档只解释语义、不直接给安全基线时，补查：
+
+- `OWASP Docker Security Cheat Sheet`
+- `CISA Known Exploited Vulnerabilities`
+- 产品官方 security / advisories 页面
+
+目标：把“语义”转成“审计期望值”。
+
+---
+
+## 推荐来源清单
+
+### SSH / OpenSSH
+
+- OpenSSH `sshd_config` 手册：`https://man.openbsd.org/sshd_config`
+
+重点看：
+
+- `PermitRootLogin`
+- `PasswordAuthentication`
+- `PermitEmptyPasswords`
+- `AllowUsers` / `AllowGroups`
+
+### Nginx / HTTPS
+
+- Nginx headers 模块：`https://nginx.org/en/docs/http/ngx_http_headers_module.html`
+- Nginx SSL 模块：`https://nginx.org/en/docs/http/ngx_http_ssl_module.html`
+
+重点看：
+
+- `add_header ... always`
+- `ssl_protocols`
+- `ssl_stapling`
+- `ssl_stapling_verify`
+
+### PostgreSQL
+
+- 连接与认证：`https://www.postgresql.org/docs/current/runtime-config-connection.html`
+
+重点看：
+
+- `listen_addresses`
+- `port`
+- `ssl`
+
+### Redis
+
+- Redis Security：`https://redis.io/docs/latest/operate/oss_and_stack/management/security/`
+
+重点看：
+
+- `bind`
+- `protected mode`
+- 外网暴露风险
+
+### Docker
+
+- Docker Engine security：`https://docs.docker.com/engine/security/`
+- Docker daemon remote access：`https://docs.docker.com/engine/daemon/remote-access/`
+- Docker logging drivers：`https://docs.docker.com/engine/logging/configure/`
+- OWASP Docker Security Cheat Sheet：`https://cheatsheetseries.owasp.org/cheatsheets/Docker_Security_Cheat_Sheet.html`
+
+重点看：
+
+- daemon attack surface
+- `docker.sock`
+- TCP remote API
+- capabilities / privileged
+- `log-driver`
+
+### CVE / 漏洞情报
+
+- CISA KEV：`https://www.cisa.gov/known-exploited-vulnerabilities-catalog`
+- NVD：`https://nvd.nist.gov/`
+
+用途：
+
+- 判断某版本是否已有**被在野利用**漏洞
+- 给 critical / high 分级补外部依据
+
+---
+
+## 审计时何时必须检索
+
+以下情况不得只靠本地规则：
+
+1. `references/checks-*.md` 写着“非已知 CVE 版本”，但当前没附具体依据
+2. audit 输出出现明确版本号，且版本看起来偏旧
+3. 某项默认值与当前发行版可能有漂移
+4. 需要判断某项该算 `critical` 还是 `high`
+5. 用户要求“给官方文档链接”
+
+---
+
+## 沉淀规则
+
+如果检索得到**稳定、可复用、非一次性**的信息，必须回写：
+
+- 配置语义类 → 更新对应 `references/checks-network.md` / `references/checks-data.md` / `references/checks-runtime.md`
+- 检索方法类 → 更新本文件
+- 仅某产品某版本临时漏洞 → 不写入长期规则，只在本次报告引用
+
+判断“适合沉淀”的标准：
+
+- 下次审计大概率还会遇到
+- 不是某个用户私有环境特例
+- 可以转化为明确检查项、期望值或检索模板
+
+---
+
+## 输出要求
+
+当使用了外部文档，报告里的失败项详情至少补 1 个权威链接：
+
+- 官方文档优先
+- 漏洞项可追加 CISA KEV 或 NVD
+- 不引用二手博客作唯一依据
+
+格式建议：
+
+```markdown
+- 参考:
+  - https://www.postgresql.org/docs/current/runtime-config-connection.html
+  - https://nvd.nist.gov/
+```

package/templates/ai-tools/skills//{350/277/220/347/273/264/345/217/221/345/270/203 → 345/256/211/345/205/250}/dwy-deploy-audit/scripts/check_db.sh

@@ -42,7 +42,19 @@ else
 
   echo ""
   echo "--- PG 版本 & 数据库列表 ---"
-  sudo -n -u postgres psql -tAc "SELECT version()" 2>/dev/null | head -1 || echo "[i] 无法连接 PG"
+  PG_VERSION_RAW=$(sudo -n -u postgres psql -tAc "SELECT version()" 2>/dev/null | head -1 || true)
+  if [[ -n "$PG_VERSION_RAW" ]]; then
+    echo "$PG_VERSION_RAW"
+    PG_VERSION=$(echo "$PG_VERSION_RAW" | grep -oE 'PostgreSQL[[:space:]]+[0-9]+(\.[0-9]+){0,2}' | awk '{print $2}' | head -1)
+    echo "postgresql_version_normalized=${PG_VERSION:-unknown}"
+    echo "official_doc_pg_runtime=https://www.postgresql.org/docs/current/runtime-config-connection.html"
+    if [[ -n "$PG_VERSION" ]]; then
+      echo "search_hint_1=postgresql ${PG_VERSION} CVE"
+      echo "search_hint_2=postgresql ${PG_VERSION} security advisory"
+    fi
+  else
+    echo "[i] 无法连接 PG"
+  fi
   sudo -n -u postgres psql -tAc "SELECT datname FROM pg_database WHERE datistemplate=false" 2>/dev/null || true
 fi
 
@@ -109,7 +121,20 @@ else
 
   echo ""
   echo "--- Redis INFO server (需 auth, 跳过若失败) ---"
-  timeout 3 redis-cli -h 127.0.0.1 INFO server 2>/dev/null | grep -E "redis_version|os|arch_bits" | head -5 || echo "[i] 需要密码或无法连接"
+  REDIS_INFO=$(timeout 3 redis-cli -h 127.0.0.1 INFO server 2>/dev/null || true)
+  if [[ -n "$REDIS_INFO" ]]; then
+    echo "$REDIS_INFO" | grep -E "redis_version|os|arch_bits" | head -5
+    REDIS_VERSION=$(echo "$REDIS_INFO" | sed -n 's/^redis_version://p' | head -1)
+    echo "redis_version_normalized=${REDIS_VERSION:-unknown}"
+    echo "official_doc_redis_security=https://redis.io/docs/latest/operate/oss_and_stack/management/security/"
+    if [[ -n "$REDIS_VERSION" ]]; then
+      echo "search_hint_redis_1=redis ${REDIS_VERSION} CVE"
+      echo "search_hint_redis_2=redis ${REDIS_VERSION} security advisory"
+    fi
+  else
+    echo "[i] 需要密码或无法连接"
+    echo "official_doc_redis_security=https://redis.io/docs/latest/operate/oss_and_stack/management/security/"
+  fi
 fi
 
 echo ""

package/templates/ai-tools/skills//{350/277/220/347/273/264/345/217/221/345/270/203 → 345/256/211/345/205/250}/dwy-deploy-audit/scripts/check_docker.sh

@@ -11,6 +11,16 @@ fi
 
 echo "--- docker version ---"
 docker version --format '{{.Server.Version}} (client: {{.Client.Version}})' 2>/dev/null || docker --version
+DOCKER_SERVER_VERSION=$(docker version --format '{{.Server.Version}}' 2>/dev/null || docker --version | grep -oE '[0-9]+(\.[0-9]+){1,3}' | head -1)
+echo "docker_server_version_normalized=${DOCKER_SERVER_VERSION:-unknown}"
+echo "official_doc_docker_security=https://docs.docker.com/engine/security/"
+echo "official_doc_docker_remote_access=https://docs.docker.com/engine/daemon/remote-access/"
+echo "official_doc_docker_logging=https://docs.docker.com/engine/logging/configure/"
+echo "official_doc_docker_owasp=https://cheatsheetseries.owasp.org/cheatsheets/Docker_Security_Cheat_Sheet.html"
+if [[ -n "$DOCKER_SERVER_VERSION" ]]; then
+  echo "search_hint_1=docker engine ${DOCKER_SERVER_VERSION} CVE"
+  echo "search_hint_2=docker ${DOCKER_SERVER_VERSION} security advisory"
+fi
 
 echo ""
 echo "--- docker daemon 监听 ---"

package/templates/ai-tools/skills//{350/277/220/347/273/264/345/217/221/345/270/203 → 345/256/211/345/205/250}/dwy-deploy-audit/scripts/check_nginx.sh

@@ -11,6 +11,14 @@ fi
 
 echo "--- nginx version ---"
 nginx -v 2>&1
+NGINX_VERSION=$(nginx -v 2>&1 | sed -n 's#.*nginx/\([^ ]*\).*#\1#p' | head -1)
+echo "nginx_version_normalized=${NGINX_VERSION:-unknown}"
+echo "official_doc_headers=https://nginx.org/en/docs/http/ngx_http_headers_module.html"
+echo "official_doc_ssl=https://nginx.org/en/docs/http/ngx_http_ssl_module.html"
+if [[ -n "$NGINX_VERSION" ]]; then
+  echo "search_hint_1=nginx ${NGINX_VERSION} security advisory"
+  echo "search_hint_2=nginx ${NGINX_VERSION} CVE"
+fi
 
 echo ""
 echo "--- nginx 进程运行用户 ---"

package/templates/ai-tools/skills//345/274/200/345/217/221/346/265/201/347/250/213/dwy-0to1/SKILL.md

@@ -58,7 +58,7 @@ description: 端到端「0→1 产品孵化」编排器。用户丢一个产品
 
 **Step 5/6 同一个 skill 两道门**：`dwy-prototype` 在低保真（`phase=lowfi`）、高保真（`phase=hifi`）各调一次、各卡一道门，目的不同（验流程 vs 做底稿），别合并。
 
-**Step 9 循环**：对 STATE「选定版本」里的每个版本依次调 `dwy-tdd-dev` 走完，编排器更新「版本开发进度」表；全部版本完，Step 9 标 `done`，给交付报告。每版完成的 commit 由 `dwy-tdd-dev` 走 `dwy-git-commit` 规范（敏感扫描 + 格式 + 禁 AI 署名），不裸 commit。
+**Step 9 循环**：对 STATE「选定版本」里的每个版本依次调 `dwy-tdd-dev` 走完，编排器更新「版本开发进度」表；全部版本完，Step 9 标 `done`，给交付报告。每版完成的 commit 由 `dwy-tdd-dev` 按 Git 提交规范执行（敏感扫描 + 格式 + 禁 AI 署名），不裸 commit。
 
 ## 产物目录（项目内 docs/0to1/）
 

package/templates/ai-tools/skills//345/274/200/345/217/221/346/265/201/347/250/213/dwy-publish/SKILL.md

@@ -0,0 +1,50 @@
+---
+name: dwy-publish
+description: "部署应用、发布版本、发布 SDK 的通用发版入口。触发条件：用户说“部署”“发版”“发布”“release”“publish”“bump version”时。先根据仓库上下文判断目标是应用部署还是 SDK 发版，再分别读取对应流程文件执行。"
+---
+
+# 发布入口
+
+通用发布 skill。默认进入本 skill 前，测试已经完成。
+
+## 第 0 步：读取仓库发布上下文
+
+执行前先从仓库里定位发布相关信息。
+
+优先查看这些信息源：
+
+- `package.json`、`pyproject.toml`、`Cargo.toml`、`Makefile`、发布脚本
+- `.github/workflows/`、CI 配置、Docker 构建文件
+- `README.md`、发布文档、变更日志
+- 现有 tag 格式、历史 release commit、历史 workflow 运行方式
+
+如果仍然无法判断发布方式或版本来源，停止并要求用户明确，不猜命令。
+
+## 第 1 步：先判断发布类型
+
+先确认：
+
+1. 发布哪个应用或包
+2. 目标是应用部署还是 SDK 发版
+3. 目标版本号是什么；如果用户没给，判断是 `major` / `minor` / `patch`
+
+归类规则：
+
+- **应用部署**：目标是某个服务、站点、容器、镜像、二进制或线上环境
+- **SDK 发版**：目标是 npm、PyPI、私有包仓库或对外库版本
+
+多包场景按仓库已有依赖关系、workspace 拓扑、历史发布顺序执行，不自定顺序。
+
+## 第 2 步：读取对应流程文件
+
+- **应用部署**：读取 `references/application-release.md`
+- **SDK 发版**：读取 `references/sdk-release.md`
+
+不要把两条流程混在一起执行。先判类型，再只读对应流程文件。
+
+## 通用约束
+
+- 禁止在未读清仓库发布上下文时猜发布命令
+- 禁止测试未完成就进入本发布流程
+- 禁止构建失败后继续发布
+- 禁止发布失败后对当前状态含糊表述

package/templates/ai-tools/skills//345/274/200/345/217/221/346/265/201/347/250/213/dwy-publish/references/application-release.md

@@ -0,0 +1,106 @@
+# 应用部署流程
+
+适用：发布目标是某个服务、站点、容器、镜像、二进制或线上环境。
+
+## 主流程
+
+流程骨架：
+
+1. `bump`
+2. `CHANGELOG`
+3. `build`
+4. `deploy`
+5. `verify env`
+
+## 1. 判断是否需要 bump
+
+不要一上来改版本号。先判断这次部署是否需要 bump：
+
+- **需要 bump**：带显式版本号的应用发布、镜像 tag 升级、二进制版本升级、对外可见版本变化
+- **可不 bump**：纯重发、仅重跑 workflow、仅补环境配置、仅回滚到已有构建
+- **拿不准**：调用 `dwy-semver` 决定升级位和新版本号
+
+如果需要 bump：
+
+1. 读取当前版本
+2. 算出新版本号
+3. 修改版本文件、镜像 tag 或其他版本来源
+
+不要用会自动 commit 的版本命令。直接编辑版本来源，保持提交边界可控。
+
+## 2. 写 CHANGELOG
+
+判断完 bump 后，再处理 `CHANGELOG`。
+
+- **需要正式版本发布**：必须写
+- **仅部署且无版本变化**：按项目约定决定是否跳过
+
+处理顺序：
+
+1. 找上一个 release tag
+2. 查看 `git log <last-tag>..HEAD --oneline`
+3. 按 `feat` / `fix` / `refactor` / `chore` 分组
+4. 写入 `CHANGELOG.md` 或项目指定的 release notes 文件
+
+如果仓库已有自动生成命令，优先使用；没有再手写。
+
+`CHANGELOG` 未完成，不继续。
+
+## 3. 确认测试已完成并执行 build
+
+本流程不重复跑测试，只确认当前变更已经过项目要求的测试。
+
+然后执行 build，确保发布产物可生成。
+
+构建失败则停止。
+
+## 4. 决定 deploy 入口
+
+不要把 deploy 写死成某种命令。根据仓库上下文自行判断：
+
+- 是推镜像、发二进制、跑部署脚本，还是触发 CI/CD
+- 是 GitHub Actions、其他 CI，还是本地脚本
+- 是否需要先 commit、tag、push 才能触发部署
+
+判断标准示例：
+
+- 存在明确 workflow、触发方式、部署 job，且部署由 CI 完成 → 走 CI
+- 仓库里有明确部署脚本、命令或运维入口 → 走本地部署流程
+
+## 5. 执行 deploy
+
+如果是 CI 驱动：
+
+1. 提交 release 相关文件
+2. 按项目规则创建 tag；如果不是 tag 触发，则按配置触发 workflow
+3. 推送分支和 tag
+4. 观察部署运行状态直到成功或失败
+
+如果是本地驱动：
+
+1. 提交 release 相关文件
+2. 按项目规则创建 tag
+3. 推送分支和 tag
+4. 执行本地部署命令
+
+失败则停止，并给出失败阶段和关键报错。
+
+## 6. verify env
+
+部署完成后，按仓库约定验证环境已生效。可用信号包括：
+
+- 健康检查
+- 版本接口
+- 页面访问
+- 运行日志
+- 镜像 tag
+- 发布平台状态
+- 其他项目约定信号
+
+验证失败，部署不算完成。
+
+## 禁止事项
+
+- 禁止跳过“是否需要 bump”的判断
+- 禁止先部署后补 `CHANGELOG`
+- 禁止把环境验证替换成包仓库验证

package/templates/ai-tools/skills//345/274/200/345/217/221/346/265/201/347/250/213/dwy-publish/references/sdk-release.md

@@ -0,0 +1,93 @@
+# SDK 发版流程
+
+适用：发布目标是 npm、PyPI、私有包仓库或对外库版本。
+
+## 主流程
+
+流程骨架：
+
+1. `bump`
+2. `CHANGELOG`
+3. `build`
+4. `publish package`
+5. `verify registry`
+
+## 1. 判断是否需要 bump
+
+SDK 发版默认需要判断版本升级。
+
+- **需要 bump**：正式发布新版本、预发布版本、修复发布产物并重发
+- **拿不准**：调用 `dwy-semver` 决定升级位和新版本号
+
+执行顺序：
+
+1. 读取当前版本
+2. 算出新版本号
+3. 修改版本文件
+
+不要用会自动 commit 的版本命令。直接编辑版本文件。
+
+## 2. 写 CHANGELOG
+
+SDK 发版必须写 `CHANGELOG`。
+
+处理顺序：
+
+1. 找上一个 release tag
+2. 查看 `git log <last-tag>..HEAD --oneline`
+3. 按 `feat` / `fix` / `refactor` / `chore` 分组
+4. 写入 `CHANGELOG.md` 或项目指定的 release notes 文件
+
+如果仓库已有自动生成命令，优先使用；没有再手写。
+
+`CHANGELOG` 未完成，不继续。
+
+## 3. 确认测试已完成并执行 build
+
+本流程不重复跑测试，只确认当前变更已经过项目要求的测试。
+
+然后执行 build，确保包产物可生成。
+
+构建失败则停止。
+
+## 4. 决定 publish 入口
+
+根据仓库上下文判断：
+
+- **CI 发布**：workflow、release job、tag push、workflow_dispatch、release please、cibuildwheel
+- **本地发布**：`pnpm publish`、`uv publish`、`twine upload` 或其他本地发包命令
+
+## 5. 执行 publish package
+
+如果是 CI 驱动：
+
+1. 提交 release 相关文件
+2. 按项目规则创建 tag；如果不是 tag 触发，则按配置触发 workflow
+3. 推送分支和 tag
+4. 观察发布运行状态直到成功或失败
+
+如果是本地驱动：
+
+1. 提交 release 相关文件
+2. 按项目规则创建 tag
+3. 推送分支和 tag
+4. 执行本地发包命令
+
+失败则停止，并给出失败阶段和关键报错。
+
+## 6. verify registry
+
+发布完成后，确认目标仓库中的新版本已可见。验证方式包括：
+
+- npm：`npm view <pkg> version`
+- PyPI：`pip index versions <pkg>` 或项目定义的检查命令
+- 私有仓库：项目约定的版本查询方式
+- GitHub Release：确认 release/tag 已生成
+
+验证失败，发版不算完成。
+
+## 禁止事项
+
+- 禁止跳过版本升级判断
+- 禁止先发包后补 `CHANGELOG`
+- 禁止把包仓库验证替换成环境健康检查

package/templates/ai-tools/skills//345/274/200/345/217/221/346/265/201/347/250/213/dwy-tdd-dev/SKILL.md

@@ -52,7 +52,7 @@ description: 按 TDD 把一个版本/功能落地成代码：写实施计划（b
     2. 运行看到失败（给确切命令 + 预期失败输出）
     3. 最小实现（贴实际实现代码）
     4. 运行看到通过（给确切命令 + 预期 PASS）
-    5. commit（优先走 `dwy-git-commit`：敏感扫描 + 规范 message + 禁 AI 署名；该 skill 不在则至少做敏感扫描 + 规范 message，给确切命令）
+    5. commit（按 Git 提交规范：敏感扫描 + 规范 message + 禁 AI 署名；该规范未生效时至少做敏感扫描 + 规范 message，给确切命令）
 
 **禁止占位符**——以下都是计划失败，绝不允许：
 
@@ -140,7 +140,7 @@ version: vN
 | `BLOCKED` | 卡住做不下去 → 补上下文 / 换更强模型 / 拆小 Task / 升级给用户，**别让它原样重试** |
 | `NEEDS_CONTEXT` | 缺信息 → 补齐缺的上下文再继续 |
 
-**两道审查全 ✅、Critical/Important 全修完、且本 Task 已 commit（步骤 5，走 dwy-git-commit），这个 Task 才算完成，进下一个 Task。** commit 是 Task 的硬收尾——别把多个 Task 攒着不提交，漏 commit 等于 Task 没完成。
+**两道审查全 ✅、Critical/Important 全修完、且本 Task 已 commit（按 Git 提交规范），这个 Task 才算完成，进下一个 Task。** commit 是 Task 的硬收尾——别把多个 Task 攒着不提交，漏 commit 等于 Task 没完成。
 
 > **自包含 + 可增强**：上面这套 spec / code 审查逻辑已内嵌，能独立跑。如果检测到项目里有 `/code-review` 命令或 `dwy-dev-qa` skill，Task 级或下面版本级的 code-review 可委托给它们做增强（更全面），没有就用内嵌逻辑。
 
@@ -205,7 +205,7 @@ git diff --stat $BASE_SHA..$HEAD_SHA
 - **禁止没有失败测试就写生产代码**——红-绿-重构铁律，违反就删掉重来。
 - **禁止跳审查**——spec 和 code 两道都要，且 spec 在前 code 在后，顺序不能反。
 - **禁止带未修的 Critical / Important 进下一个 Task 或下一个版本。**
-- **禁止 Task 未 commit 就开下一个 Task**——红-绿-审查全过后必须当场 commit（走 dwy-git-commit），不许把多个 Task 的改动攒到最后一次性提交。
+- **禁止 Task 未 commit 就开下一个 Task**——红-绿-审查全过后必须当场 commit（按 Git 提交规范），不许把多个 Task 的改动攒到最后一次性提交。
 - **禁止没跑验证就声称完成**——「应该过了」不算证据，必须有刚跑的命令输出。
 - **禁止实施计划留占位符**（TODO / 待补充 / 类似 Task N）——每步给实际代码 + 确切命令。
 - **禁止把代码写进 `docs/0to1/`**——只有实施计划进 `plans/`，代码进项目源码。

package/templates/ai-tools/skills//345/274/200/345/217/221/346/265/201/347/250/213/dwy-tdd-dev/templates/impl-plan.md

@@ -67,7 +67,7 @@ export function validateNoteBody(body: string): { ok: boolean; error?: string }
 Run: `pnpm vitest run tests/validators/note.test.ts`
 Expected: PASS（2 passed），其它测试不受影响
 
-- [ ] **步骤 5：commit（走 `dwy-git-commit`：敏感扫描 + 规范 message + 禁 AI 署名）**
+- [ ] **步骤 5：commit（按 Git 提交规范：敏感扫描 + 规范 message + 禁 AI 署名）**
 
 ```bash
 git add src/validators/note.ts tests/validators/note.test.ts
@@ -107,7 +107,7 @@ Expected: FAIL — <预期失败原因，必须是「功能没实现」>
 Run: `<确切测试命令>`
 Expected: PASS，其它测试不挂、输出无 warning
 
-- [ ] **步骤 5：commit（走 `dwy-git-commit`：敏感扫描 + 规范 message + 禁 AI 署名）**
+- [ ] **步骤 5：commit（按 Git 提交规范：敏感扫描 + 规范 message + 禁 AI 署名）**
 
 ```bash
 git add <文件>

package/templates/ai-tools/rules//345/274/200/345/217/221/346/265/201/347/250/213/dwy-git-commit-safe.md

@@ -1,66 +0,0 @@
----
-description: git commit message 安全写法(防反引号被 shell 命令替换误执行)
----
-
-# git commit 安全写法
-
-## 核心风险
-
-AI 生成的 commit message 爱用 Markdown 风格反引号包代码标识符。经 shell 执行 `git commit -m "..."` 时，**双引号内**的反引号会被当成命令替换实际执行：
-
-```bash
-# 危险：`bun install` 被 shell 当成 $(bun install) 执行
-git commit -m "fix: support `bun install` on windows"
-```
-
-shell 实际跑了 `bun install`，把输出塞进 message，甚至误执行破坏性命令导致丢代码。`$(...)` 同理。
-
-## 强制规则
-
-commit message 含反引号 `` ` `` / `$(...)` / 多行 / emoji 等特殊字符时，**禁止** `git commit -m "..."`，必须走以下安全写法：
-
-### 1. 文件提交（首选，多行 / 特殊字符一律用它）
-
-```bash
-git commit -F <msg-file>
-
-# 或 stdin
-printf '%s\n' "$MSG" | git commit --file=-
-
-# 或 heredoc 写文件再提交
-cat > /tmp/commit-msg.txt <<'EOF'
-feat(agent): add `runConcurrent`
-
-- support drain-all-before-throw
-EOF
-git commit -F /tmp/commit-msg.txt
-```
-
-### 2. 单引号包裹（单行、无单引号时可用）
-
-```bash
-# 单引号内所有字符字面，反引号原样保留
-git commit -m 'fix: support `bun install` on windows'
-```
-
-### 3. 转义反引号（不推荐，易漏）
-
-```bash
-git commit -m "fix: support \`bun install\` on windows"
-```
-
-## 安全速查
-
-| 方式 | 反引号风险 |
-|---|---|
-| `git commit -m "...`...`..."` | 危险（双引号内被求值） |
-| `git commit -m '...`...`...'` | 安全（单引号不展开） |
-| `git commit -F <file>` | 安全（Git 直读文件，不过 shell） |
-| `git commit --file=-` | 安全 |
-
-## 禁止
-
-- **禁止**把含反引号 / `$(...)` 的 message 拼进 `git commit -m "..."` 双引号
-- **禁止**为图省事忽略此约束 —— 误执行后果是丢代码，不可逆
-
-> PreToolUse hook `pre-git-commit-backtick-check.sh` 会在双引号 message 含未转义反引号 / `$(...)` 时硬拦截（exit 2），但 hook 是兜底，写法本身就该走安全方式。