create-dwy 0.19.1 → 0.20.0

package/templates/ai-tools/skills//345/217/221/345/270/203/345/217/221/347/211/210/dwy-publish/references/changelog.md

@@ -1,25 +1,41 @@
-# CHANGELOG 按平台子目录各写一份
+# 发版时按项目写 CHANGELOG
 
-monorepo 下一个仓库可能同时含 android / ios / harmony / frontend / backend 多平台。**每个平台维护自己的 CHANGELOG，不写全局单份**。发哪个平台，只写哪个平台那份。
+只在发版写。不发版不写、不升版本。
 
-## 各平台 CHANGELOG 位置
+工厂是这次发版的 git 仓库根。工厂下可以有多个项目。每个项目可以各自有前端和后端。changelog 写在那一端自己的目录里。
 
-- `android/CHANGELOG.md`
-- `ios/CHANGELOG.md`
-- `harmony/CHANGELOG.md`
-- `frontend/CHANGELOG.md`
-- `backend/CHANGELOG.md`
+## 先列出要写的端
 
-子目录名按仓库实际结构定（先在第 0 步识别平台目录）。单包仓库可在根目录一份；monorepo 按包目录（如 `dwy-cli/CHANGELOG.md`、`frontend/eui/CHANGELOG.md`）。
+1. 找出项目。一个项目是含有可独立发版的前端和/或后端的目录。常见是 `<项目>/frontend` 与 `<项目>/backend`。仓库根下直接就是这两端时，根就是这一个项目。目录名按仓库实际结构认，不套死 `frontend` / `backend` 这两个词。
+2. 一端算存在：该目录有自己的版本来源（前端看 `package.json` 的 `version`，后端看 `pyproject.toml` 的 `version`），或有该端的应用入口。没有这一端就不写。
+3. 决定哪些端要写：
+   - 用户点名了项目或端：只写点名的。
+   - 没点名：该端目录自上次 release tag 以来有提交才写。没有上次 tag 时，看这次准备发布的提交是否改过该目录。
+
+```bash
+git log <该端上次 tag>..HEAD --oneline -- <项目>/<端>/
+```
+
+4. 没有提交的端不写、不升版本、不打 tag。
+5. 写之前先列出清单：项目、端、changelog 路径、有没有变更。清单里该写的还没写完，不进入 tag。
+
+该项目下若还有 android / ios / harmony，同样各算一端，不写进前后端的 changelog。
+
+## 落点
+
+- `<项目>/frontend/CHANGELOG.md`
+- `<项目>/backend/CHANGELOG.md`
+
+只有一端的项目只写存在的那一端。不要在工厂根再写一份总表。
 
 ## 版本标题格式（与 git tag 对齐）
 
-新版本必须用二级标题，版本串单独成标题，供第 6 步打 tag 原样取用：
+新版本必须用二级标题，版本串单独成标题，供打 tag 原样取用：
 
 ```markdown
-# <包标识>          ← monorepo 建议有 H1，作为 tag 的包前缀（如 create-dwy、@dwydev/eui）
+# <包标识>          ← 作为 tag 的包前缀（如 shop-frontend、@acme/api）
 
-## 0.16.1           ← 新版本标题；tag 版本串必须与此完全一致
+## 0.16.1           ← 新版本标题；这一份 changelog 的 tag 版本串必须与此完全一致
 
 ### Patch Changes
 
@@ -28,30 +44,32 @@ monorepo 下一个仓库可能同时含 android / ios / harmony / frontend / bac
 
 约束：
 
-- 标题里只写 SemVer 版本串（可含预发布，如 `1.0.0-rc.1`），不要写 `v0.16.1`、日期或其它后缀
-- 该版本串 = 版本来源文件里的 version = 即将打的 tag 中的版本部分（见 `git-tag.md`）
+- 标题里只写 SemVer 版本串，不要写 `v0.16.1`、日期或其它后缀
+- 从 `develop` 发：标题是 `x.y.z-beta.N` 或 `x.y.z-rc.N`。从 `preview` 发正式版：标题是 `x.y.z`，不带预发布
+- 该版本串 = 这一端版本来源文件里的 version = 这一份 changelog 即将打的 tag 中的版本部分（见 `git-tag.md`）
+- 各端版本号各自维护。前端升了，不表示后端也要升
 
 ## 写法
 
-1. 找该平台上一个 release tag
-2. 按平台子目录过滤 commit：
-
-```bash
-git log <last-tag>..HEAD --oneline -- <平台子目录>/
-```
-
+1. 找这一端的上一个 release tag
+2. 只取这一端目录里的 commit（命令见上）
 3. 按 `feat` / `fix` / `refactor` / `chore` 分组
-4. 写入该平台 `CHANGELOG.md`，用 `## <新版本号>` 标注（格式见上）
+4. 写入这一端的 `CHANGELOG.md`，用 `## <新版本号>` 标注
+
+仓库已有自动生成命令（changelogen 等）时优先使用。仍然只覆盖这一端的目录，版本标题仍要满足上面的格式。
 
-如果仓库已有自动生成命令（changelogen 等），优先使用，但仍按平台目录过滤范围，且产出的版本标题须满足上述格式。
+写了几份 changelog，就按 `git-tag.md` 各打一个 tag。不要合成一个工厂级 tag。
 
 ## 自动执行
 
-changelog 由 AI 自动生成并写入，不强制逐步确认。仅当 commit 历史无法清晰归类、或平台目录边界不明时才停下问用户。
+changelog 由 AI 生成并写入，不逐步确认。只有 commit 无法归类，或分不清项目边界时才问用户。
 
 ## 禁止
 
-- 禁止写一份全局 CHANGELOG 混入多平台变更
+- 禁止在工厂根写一份总 CHANGELOG，把多个项目或前端后端混在一起
+- 禁止只写了其中一个项目就进入 tag
+- 禁止把 A 项目的 commit 写进 B 项目
+- 禁止把前端的 commit 写进后端，或反过来
+- 禁止给没有变更的端写一份空版本
 - 禁止 changelog 未写完就进入 tag / 部署
-- 禁止把其他平台的 commit 写进当前平台 CHANGELOG（必须按目录过滤）
-- 禁止版本标题写成与即将打的 tag 版本串不一致的形式
+- 禁止版本标题与这一份即将打的 tag 版本串不一致

package/templates/ai-tools/skills//345/217/221/345/270/203/345/217/221/347/211/210/dwy-publish/references/frontend-deploy.md

@@ -19,6 +19,6 @@
 
 ## changelog / tag / 监控
 
-- changelog → `changelog.md`（写 `frontend/CHANGELOG.md`）
+- changelog → `changelog.md`（写该项目的 `frontend/CHANGELOG.md`；工厂里多个项目时每个项目各一份）
 - tag → `git-tag.md`（每次 bump 必打；版本串与 changelog `##` 标题一致）
 - 监控 + verify → `monitor-notify.md`（前端信号：页面访问 / 版本接口 / 产物 hash / CDN 刷新）

package/templates/ai-tools/skills//345/217/221/345/270/203/345/217/221/347/211/210/dwy-publish/references/generic-release.md

@@ -22,7 +22,7 @@
 
 ## changelog / tag / 安全检查 / 监控
 
-- changelog → `changelog.md`（单包仓库根目录一份；monorepo 按包目录过滤）
+- changelog → `changelog.md`（单包仓库根目录一份；应用工厂按每个项目的前端/后端分写）
 - tag → `git-tag.md`（每次 bump 必打；版本串与 changelog `##` 标题一致；monorepo 例：`@dwydev/eui@2.2.3`、`create-dwy@0.16.1`）
 - 安全检查 → `../dwy-sdk-spec`（对外包必查泄露/产物）
 - 监控 + verify → `monitor-notify.md`（包仓库版本查询 / GitHub Release）

package/templates/ai-tools/skills//345/217/221/345/270/203/345/217/221/347/211/210/dwy-publish/references/git-tag.md

@@ -19,7 +19,7 @@ git push origin <tag>
 
 ## tag 与 changelog 版本对齐（硬规则）
 
-tag 中的**版本串**必须与本次 CHANGELOG **新版本标题**完全一致，禁止改写。
+tag 中的**版本串**必须与这一份 CHANGELOG **新版本标题**完全一致，禁止改写。第 4 步写了几份，就各打一个 tag，版本串对应该份标题。
 
 | CHANGELOG 写法 | 取出的版本串 |
 |----------------|-------------|

package/templates/ai-tools/skills//345/217/221/345/270/203/345/217/221/347/211/210/dwy-publish/references/harmony.md

@@ -20,7 +20,7 @@
 
 ## changelog / tag / 安全检查 / 监控
 
-- changelog → `changelog.md`（写 `harmony/CHANGELOG.md`）
+- changelog → `changelog.md`（写该项目的 `harmony/CHANGELOG.md`；工厂里多个项目时每个项目各一份）
 - tag → `git-tag.md`（每次 bump 必打；版本串与 changelog `##` 标题一致）
 - 安全检查 → `../dwy-sdk-spec`
 - 监控 + 结果 → `monitor-notify.md`

package/templates/ai-tools/skills//345/217/221/345/270/203/345/217/221/347/211/210/dwy-publish/references/ios.md

@@ -27,7 +27,7 @@
 
 ## changelog / tag / 安全检查 / 监控
 
-- changelog → `changelog.md`（写 `ios/CHANGELOG.md`）
+- changelog → `changelog.md`（写该项目的 `ios/CHANGELOG.md`；工厂里多个项目时每个项目各一份）
 - tag → `git-tag.md`（每次 bump 必打；版本串与 changelog `##` 标题一致）
 - 安全检查 → `../dwy-sdk-spec`（SDK 发布尤其要查泄露）
 - 监控 + 结果 → `monitor-notify.md`

package/templates/ai-tools/skills//345/217/221/345/270/203/345/217/221/347/211/210/dwy-semver/SKILL.md

@@ -87,6 +87,14 @@ description: "语义化版本号（SemVer 2.0.0）决策助手。涉及以下任
 
 预发布优先级排序、版本比较 11 条规则等细节见 [references/semver-spec.md](references/semver-spec.md)。
 
+## 分支上用哪个号
+
+只认两条长期分支，和 `rules/开发流程/dwy-prod-branch.md` 同一条。不在发版时不要为了这条去改版本号。
+
+- 在 `develop` 发：必须带 `-beta` 或 `-rc`。还在改用 `beta`，准备进 `preview` 用 `rc`。
+- 在 `preview` 发正式版：不带预发布。`rc` 收成正式号时用 `bump.py` 转到正式版。
+- 仓库没有这两条分支：先告诉用户，不要改用 `main` 充当正式分支。
+
 ## 算出具体版本号
 
 `scripts/bump.py` 按 SemVer 归零规则与 node-semver 预发布语义计算，避免手算出错：

package/templates/ai-tools/skills//345/256/211/345/205/250/dwy-deploy-audit/SKILL.md

@@ -278,9 +278,9 @@ bash {scripts}/check_db.sh <target> [ssh_opts...]
 
 ### 4.10 硬件识别与资源推荐 — `{scripts}/check_capacity.sh`
 
-输出宿主硬件规格 + 当前容器 mem_limit + Postgres/Redis 启动参数 + compose 资源声明；主 Claude 对照分级表生成"推荐 vs 当前"对比报告。
+输出宿主硬件、容器硬限、`docker stats` 单帧、Postgres/Redis 参数、compose 声明。报告写「本次实测 vs 当前硬限」。冷启动先验表只在没有占用和日志增量时使用。
 
-→ 容器资源推荐分级表、配比原则、对比报告格式、严重等级标记与日志大小推荐分级表见 `references/checks-runtime.md` §「4.10 硬件识别与资源推荐」
+→ 判定见 `references/checks-runtime.md` §「4.10 硬件识别与资源」
 
 ### 4.11 凭证强度审计 — `{scripts}/check_secrets.sh`
 
@@ -392,8 +392,8 @@ bash {scripts}/check_db.sh <target> [ssh_opts...]
 ### 4.9 日志大小与防爆检查 (7/9 ✅)
 [...]
 
-### 4.10 硬件识别与资源推荐 (容器资源 5/7 + 日志推荐 4/5)
-**包含"推荐 vs 当前"对比表(见 references/checks-runtime.md §4.10),保留原对比格式**
+### 4.10 硬件识别与资源 (容器资源 + 日志轮转)
+**写「本次实测 vs 当前硬限」。没有实测才注明用了冷启动先验。不要因为没贴近先验表判失败。**
 
 ### 4.11 凭证强度审计 (12/15 ✅)
 
@@ -464,9 +464,9 @@ bash {scripts}/check_db.sh <target> [ssh_opts...]
 
 根据本次失败项归纳的可执行后续动作:
 
-- 镜像版本不固定 (4.6) → 跑 `/dwy-docker` 选 N-1 minor
-- daemon 未配 registry-mirrors (4.6) → 跑 `/dwy-mirror-source` 写国内源
-- 容器资源偏离推荐 (4.10) → 改 `docker-compose.prod.yml` 的 mem_limit/maxmemory
+- 镜像版本不固定 (4.6) → 跑 `/dwy-docker`，按当次 tag 列表固定；N-1 只是偏好
+- daemon 未配 registry-mirrors，或只是名单里有某个国内域名 (4.6) → 跑 `/dwy-mirror-source`。名单里有源不算通过。当次测延迟和内容。私有库不参加公网竞速
+- 容器无内存硬限，或硬限低于实测占用 (4.10) → 按这次的 `docker stats` 和日志增速改 `mem_limit` / `maxmemory` / `log-opts`，不套用先验表数字
 - ...
 
 ---

package/templates/ai-tools/skills//345/256/211/345/205/250/dwy-deploy-audit/references/checks-runtime.md

@@ -2,7 +2,7 @@
 
 > **何时读这份：** 当 AI 即将运行 4.6 / 4.8 / 4.9 / 4.10 类检查或解读其输出时读取本文件。
 
-本文件聚焦"运行时与韧性"维度的检查规则、严重度判定与输出格式。涵盖 Docker 安全、自愈与资源耗尽防护、日志大小与防爆、硬件识别与资源推荐。
+本文件聚焦"运行时与韧性"维度的检查规则、严重度判定与输出格式。涵盖 Docker 安全、自愈与资源耗尽防护、日志大小与防爆、硬件与容器资源。内存和日志的具体数字是冷启动先验，有实测就不用表。
 
 脚本目录简称 `{scripts}` = `../scripts/`。
 
@@ -11,8 +11,8 @@
 ## 4.6 Docker 安全 — `{scripts}/check_docker.sh`
 
 > **跨 skill 联动**:本节发现的镜像版本/镜像源问题,只**报告**不修复。具体修复路径:
-> - 镜像 tag 不固定 / `:latest` / 浮动 tag → 引导用户跑 `/dwy-docker`(走 query_dockerhub.py 选 N-1 minor)
-> - daemon 未配 registry-mirrors / 容器用境外 registry → 引导用户跑 `/dwy-mirror-source`(写阿里云/中科大/daocloud)
+> - 镜像 tag 不固定 / `:latest` / 浮动 tag → 引导用户跑 `/dwy-docker`（当次列出 tag 再固定，N-1 只是偏好）
+> - daemon 未配 registry-mirrors / 容器用境外 registry → 引导用户跑 `/dwy-mirror-source`（当次探测后取延迟最低的源）
 
 | 检查项 | 期望值 | 严重级 |
 |--------|--------|--------|
@@ -30,9 +30,9 @@
 | 容器 `RestartPolicy` | `always` 或 `unless-stopped`（**服务器重启后自动起来**） | **critical** |
 | 容器 `RestartPolicy=no` 但正在 running | 不允许（重启会丢） | **critical** |
 | 容器 `RestartPolicy=on-failure` | 不推荐（手动 stop / OOM 后不会重启） | high |
-| daemon 日志驱动 `log-opts.max-size` | 已配置（≤ 100m，防容器日志写满磁盘） | high |
-| **daemon `registry-mirrors`**(时区在 PRC 时) | 至少 1 个国内源(daocloud / aliyun / ustc / tsinghua) | high(PRC 无配置)/ info(境外) |
-| **运行容器使用境外 registry**(`gcr.io` `ghcr.io` `k8s.gcr.io` `quay.io` `mcr.microsoft.com` `nvcr.io` `docker.elastic.co`)且时区在 PRC | 改用 `<registry>.m.daocloud.io` 前缀(`registry-mirrors` **不**对它们生效) | high |
+| daemon 日志驱动 `log-opts.max-size` | 已配置上限。数字按实测日志增速，不要求 ≤ 100m | high（未配置） |
+| **daemon `registry-mirrors`** | 名单里有 daocloud / aliyun / ustc 不算通过。合格看当次对 Registry API 的延迟和内容。未配置时提示去探测，不因为没写某个国内源判失败。私有库或用户指定源不参加公网竞速 | info |
+| **运行容器使用境外 registry**(`gcr.io` `ghcr.io` `k8s.gcr.io` `quay.io` `mcr.microsoft.com` `nvcr.io` `docker.elastic.co`)且时区在 PRC | 改用当次探测选出的国内前缀（`registry-mirrors` **不**对它们生效）。DaoCloud 前缀只是当前候选。私有库不改前缀 | high |
 
 **Docker 版本与暴露面判定补充：**
 
@@ -93,23 +93,40 @@
 |--------|--------|--------|
 | Docker 单容器 `*-json.log` 大小 | < 500 MB（daemon 配 log-opts max-size 时自动控） | high(>500 MB) / critical(>1 GB 且 daemon 无 log-opts) |
 | 容器自身 `LogConfig.Config` 覆盖 | 至少有 `max-size`，否则继承 daemon | high（容器 + daemon 都没配） |
-| Docker daemon `log-opts.max-size` | 已配置 ≤ 100m | high（同 check_docker.sh，本节关联展开） |
+| Docker daemon `log-opts.max-size` | 已配置上限。数字按本节实测增速，不要求 ≤ 100m | high（未配置） |
 | Nginx access.log / error.log 单文件 | < 500 MB | high |
 | `/etc/logrotate.d/nginx` | 存在 | high |
 | `journalctl --disk-usage` | < 2 GB | medium / high(≥ 2 GB 且 SystemMaxUse 未配) |
 | `/etc/systemd/journald.conf` `SystemMaxUse` | 已显式配置 | low |
 | 应用日志目录（`/var/log/<svc>` / `/opt/*/logs` / `/home/*/logs` / `/srv/*/logs`） | 列出 Top 10 供人工核对 | info |
-| 日志按当前 docker 容器存活时长粗估的撑天数 | > 90 天 | high(<90) / critical(<30) |
+| 日志按当前 docker 容器存活时长粗估的撑天数 | 按实测增速，写满根盘前有人处理。30 / 90 天是告警线，不是要配成的保留天数 | high(<90) / critical(<30) |
 
 **输出规约：** 脚本会汇总 `Docker json-log + Nginx + journal + 应用日志` 总占用，对照根盘可用空间，给出"按 docker 当前增速预计可撑 N 天"的粗估。粗估只算 docker json-log 增量，不含数据库/应用日志业务增量，因此**结论偏乐观**，作为下限警示使用。
 
 ---
 
-## 4.10 硬件识别与资源推荐 — `{scripts}/check_capacity.sh`
+## 4.10 硬件识别与资源 — `{scripts}/check_capacity.sh`
 
-> 脚本只输出 raw（硬件规格 + 当前容器 mem_limit + Postgres/Redis 启动参数 + compose 资源声明）；主 Claude 用下表生成 "推荐 vs 当前" 对比报告。详细推荐规则与配比公式参考 `dwy-docker` skill 第二部分。
+脚本输出宿主规格、容器硬限、`docker stats` 单帧占用、Postgres/Redis 参数、compose 声明、日志日增量能对上的根盘剩余。报告写「本次实测 vs 当前硬限」。**禁止**把下面的数字写成应改成的配额。
 
-**容器资源推荐分级表（按宿主总内存）**
+必须成立的只有这些：
+
+- 每个容器有内存硬限。关键服务（redis / postgres / mysql / mongo / clickhouse / elasticsearch）没有就是 high
+- Redis 设了 `maxmemory`，且容器 `mem_limit` 大于它。未设或为 0 是 **critical**
+- Postgres `shared_buffers` 不超过宿主总内存的 50%。这是 OOM 天花板，不是目标比例
+- 容器硬限合计不超过宿主总内存的 75%。超过则 OS 没有余量，是 high。不要求贴近 65%
+- 日志有 `max-size` 和 `max-file`。两边都没有是 **critical**
+- 按 `check_logs.sh` 的实测日增量，根盘会在短时间内写满，才收紧轮转。30 天 critical，90 天 high。这是告警线
+
+有 `docker stats` 或日志日增量时，用实测：
+
+- 内存硬限低于这一帧占用（或已有的监控峰值）才要加。单帧不是峰值，报告里写明
+- 硬限远高于占用，不是问题，不要为了贴近下表去改小
+- 日志配额按日增量和根盘剩余算。`max-size × max-file × 容器数` 本身就能占掉根盘约 5% 以上，说明天花板太高，是 high。5% 是安全天花板，不是目标占用
+
+没有占用、也没有日志增量（服务刚起）时，才用下面的冷启动先验。服务跑起来之后以实测替换，不把先验写回本文件。
+
+**冷启动先验：内存（没有实测时才用）**
 
 | 宿主总内存 | Backend mem_limit | Postgres mem_limit / shm_size / shared_buffers / effective_cache_size | Redis mem_limit / maxmemory |
 |-----------|-------------------|--------------------------------------------------------------------|----------------------------|
@@ -118,83 +135,70 @@
 | 8 GB | 2g | 2g / 512m / 512MB / 1536MB | 768m / 512mb |
 | 16 GB | 4g | 4g / 1g / 1GB / 3GB | 1g / 700mb |
 
-**配比原则**
+比例只解释这张先验怎么来的：硬限合计大约留出 OS 余量；Postgres `shared_buffers` 约容器硬限的 25%，`effective_cache_size` 约 75%；Redis `maxmemory` 约容器硬限的 70%，其余给 fork 时的写时复制。实测对不上就丢掉整行。
 
-- 容器 `mem_limit` 合计 ≤ 宿主总内存的 **65%**（预留 OS / 全局 nginx / 监控 agent / frpc 等）
-- Postgres `shared_buffers` = 容器 `mem_limit` 的 **25%**
-- Postgres `effective_cache_size` = 容器 `mem_limit` 的 **75%**
-- Redis `maxmemory` = 容器 `mem_limit` 的 **70%**（剩 30% 给 RDB/AOF fork 时 COW 留 buffer）
-- Redis `mem_limit` = `maxmemory ÷ 0.7` 向上取整
-
-**对比报告格式（主 Claude 在报告里生成）**
+**对比报告格式**
 
 ```
-| 服务 | 配置项 | 推荐(基于 X GB 宿主) | 当前 | 状态 |
-|------|--------|--------------------|------|------|
-| backend | mem_limit | 1g | 无 | ❌ 缺失 |
-| db | mem_limit | 1g | 1g | ✅ |
-| db | shared_buffers | 256MB | 128MB(默认) | ⚠️ 偏低 |
-| db | shm_size | 256m | 64m(默认) | ⚠️ 偏低 |
-| redis | maxmemory | 256mb | 256mb | ✅ |
-| redis | mem_limit | 384m | 384m | ✅ |
-| redis | appendonly | yes | no | ⚠️ 重启丢数据 |
+| 服务 | 配置项 | 本次实测 | 当前硬限 | 状态 |
+|------|--------|----------|----------|------|
+| backend | mem | stats 420MiB（单帧） | 无 | 缺上限 |
+| db | mem | stats 300MiB（单帧） | 1g | 硬限高于实测 |
+| db | shared_buffers | — | 超过宿主 50% | 撞上天花板 |
+| redis | maxmemory | 当前占用 | 0 | 未设 |
 ```
 
-**严重等级标记规则**
+没有实测的新机器，在「本次实测」列写「无，用冷启动先验 &lt;数字&gt;」，并注明服务跑起来后要重测。
+
+**严重等级**
 
 | 检查项 | 期望值 | 严重级 |
 |--------|--------|--------|
-| 关键服务（redis / postgres / mysql / mongo / clickhouse / elasticsearch）容器无 `mem_limit` | 已设置 | high |
-| Redis `--maxmemory` 未设置或 `0` | 已设置 | **critical** |
-| Postgres `shared_buffers` > 宿主总内存 50% | ≤ 宿主总内存 50% | high |
-| Postgres `shm_size` < 128m | ≥ 256m | medium |
-| Redis 未启用 AOF（`--appendonly yes`） | yes | medium |
-| 容器 `mem_limit` 合计 > 宿主总内存 75% | ≤ 65% | high |
-| `mem_limit` 偏离推荐表 ±50% 以上（主 Claude 判定） | 在分级表区间内 | medium |
+| 关键服务容器无 `mem_limit` | 已设置 | high |
+| 硬限低于本次 `docker stats` 占用 | 硬限高于实测 | high |
+| Redis `--maxmemory` 未设置或 `0` | 已设置，且小于容器 `mem_limit` | **critical** |
+| Postgres `shared_buffers` > 宿主总内存 50% | 不超过 | high |
+| Redis 未启用 AOF（`--appendonly yes`） | 按持久化需求，不是配额 | medium |
+| 容器 `mem_limit` 合计 > 宿主总内存 75% | 不超过。低于 75% 不要求再贴近某个比例 | high |
+
+偏离冷启动先验表 **不是** 违规。
 
 ---
 
-### 日志大小推荐分级表（防容器日志无限增长撑爆磁盘）
+### 日志轮转
 
-依据是 `<根盘容量>` × `<容器规模>`,**单容器最大日志占用 = `max-size` × `max-file`**;所有容器日志合计应 ≤ 根盘可用空间的 **5%**(留磁盘给数据/swap/OS)。
+有日增量时用增速和根盘剩余决定 `max-size` / `max-file`。没有增量时才看冷启动先验。
 
-**daemon 兜底配置(`/etc/docker/daemon.json` `log-opts`)**
+**冷启动先验：daemon `log-opts`（没有日志增量时才用）**
 
 | 宿主规格 | 根盘 | 容器数(估) | `max-size` | `max-file` | 单容器 quota | 备注 |
 |---------|------|-----------|------------|-----------|-------------|------|
-| 入门 | < 50 GB | 任意 | `10m` | `3` | ~30 MB | 2-4 GB VM 入门款,日志少留磁盘 |
-| 标准 | 50-150 GB | ≤ 5 | `50m` | `5` | ~250 MB | 4-8 GB VM 通用 |
-| 标准 | 50-150 GB | > 5 | `20m` | `5` | ~100 MB | 容器多则降单容器 quota |
-| 大型 | > 150 GB | 任意 | `100m` | `5` | ~500 MB | 16+ GB 服务器,空间充裕 |
-
-**容器级覆盖(compose `logging.options`,优先于 daemon)**
+| 入门 | < 50 GB | 任意 | `10m` | `3` | ~30 MB | 盘小，先验从紧 |
+| 标准 | 50-150 GB | ≤ 5 | `50m` | `5` | ~250 MB | 无增速时的起点 |
+| 标准 | 50-150 GB | > 5 | `20m` | `5` | ~100 MB | 容器多，先验收紧 |
+| 大型 | > 150 GB | 任意 | `100m` | `5` | ~500 MB | 无增速时的起点 |
 
-| 容器类型 | `max-size` | `max-file` | 理由 |
-|---------|-----------|-----------|------|
-| 数据库 (postgres / mysql / mongo) | `20m` | `10` | 慢查询日志价值高,保留更多滚动 |
-| Web 反代 (nginx access log 走 stdout) | `50m` | `5` | 写入量大,单文件可放宽 |
-| 应用后端 (FastAPI / Node 等) | `10m` | `5` | 通用 |
-| Redis / 缓存类 | `10m` | `3` | 写入少,保留少 |
+容器级 `logging.options` 盖过 daemon。库、反代、应用的保留条数不一样，同样只在没有该容器增速时参考，不作为合格线。
 
-**daemon.json 模板**
+字段写法示例（数字不是目标配额）：
 
 ```json
 {
   "log-driver": "json-file",
   "log-opts": {
-    "max-size": "50m",
-    "max-file": "5",
+    "max-size": "<当次算出的大小>",
+    "max-file": "<当次算出的个数>",
     "compress": "true"
   }
 }
 ```
 
-**严重等级标记(脚本侧 + 主 Claude 对照表)**
+**严重等级**
 
 | 判定 | 严重级 |
 |------|--------|
 | daemon 无 `log-opts.max-size` 且容器也无 `LogConfig.Config` | **critical** |
-| daemon `max-size` > 推荐档 50% 以上(如根盘 < 50 GB 用 100m) | high |
-| 容器无 `LogConfig.Config` 但 daemon 有兜底 | OK(走 daemon) |
-| 容器 `LogConfig.Config` 设了但 max-size 偏离推荐档 ±50% | medium |
-| 估算所有容器日志合计 > 根盘可用 5% | high |
+| 容器无单独 `LogConfig.Config`，daemon 已有上限 | 通过（走 daemon） |
+| `max-size × max-file × 容器数` > 根盘约 5% | high（配额天花板太高） |
+| 按实测日增量，不足 90 天写满根盘 | high；不足 30 天为 **critical** |
+| 当前 `max-size` 与冷启动先验不同 | 不是问题 |

package/templates/ai-tools/skills//345/256/211/345/205/250/dwy-deploy-audit/scripts/check_base.sh

@@ -30,7 +30,16 @@ for cmd in nginx postgres psql redis-cli docker openssl ufw firewall-cmd iptable
 done
 
 echo "--- PUBLIC IP (best effort) ---"
-curl -fsS --max-time 5 https://api.ipify.org 2>/dev/null || hostname -I | awk '{print $1}'
+# 回显地址是先验。一个失败换下一个。全部失败印 unknown。禁止用 hostname -I 的内网地址冒充公网 IP。
+PUB_IP=""
+for url in https://api.ipify.org https://ifconfig.me/ip https://icanhazip.com; do
+  PUB_IP=$(curl -fsS --max-time 5 "$url" 2>/dev/null | tr -d '[:space:]')
+  if printf '%s' "$PUB_IP" | grep -Eq '^[0-9]{1,3}(\.[0-9]{1,3}){3}$'; then
+    break
+  fi
+  PUB_IP=""
+done
+echo "${PUB_IP:-unknown}"
 echo
 
 echo "--- USER & SUDO ---"

package/templates/ai-tools/skills//345/256/211/345/205/250/dwy-deploy-audit/scripts/check_capacity.sh

@@ -1,8 +1,9 @@
 #!/usr/bin/env bash
 # 硬件规格识别 + 当前服务资源配置盘点 (只读)
 #
-# 输出 raw data, 由主 Claude 对照 SKILL.md 4.10 的推荐分级表生成
-# "推荐 vs 当前" 对比报告。
+# 输出实测：硬件、硬限、docker stats 单帧、日志配额。
+# 分级数字只是没有实测时的冷启动先验，见 checks-runtime.md 4.10。
+# 不要因为当前值没贴近先验就判失败。
 #
 # 检查范围:
 #   - 宿主硬件: CPU 核数 / 总内存 / 根盘容量 / swap
@@ -26,7 +27,7 @@ MEM_TOTAL_MB=$(( ${MEM_TOTAL_KB:-0} / 1024 ))
 MEM_AVAIL_MB=$(( ${MEM_AVAIL_KB:-0} / 1024 ))
 SWAP_TOTAL_MB=$(( ${SWAP_TOTAL_KB:-0} / 1024 ))
 
-# 推荐分档(对齐 SKILL.md 4.10 的 2/4/8/16 GB 表)
+# 冷启动分档。有 docker stats 时不用这档决定 mem_limit。
 if   [[ $MEM_TOTAL_MB -ge 14000 ]]; then TIER="16GB"
 elif [[ $MEM_TOTAL_MB -ge 7000  ]]; then TIER="8GB"
 elif [[ $MEM_TOTAL_MB -ge 3500  ]]; then TIER="4GB"
@@ -39,7 +40,7 @@ echo "CPU 型号: ${CPU_MODEL:-unknown}"
 echo "总内存:   ${MEM_TOTAL_MB} MB"
 echo "可用内存: ${MEM_AVAIL_MB} MB"
 echo "Swap:     ${SWAP_TOTAL_MB} MB"
-echo "推荐分档: ${TIER} (主 Claude 据此查推荐表)"
+echo "冷启动分档: ${TIER} (没有占用数据时才参考先验表)"
 
 echo ""
 echo "--- 根盘容量 ---"
@@ -90,6 +91,8 @@ echo "--- 容器实际内存占用 (docker stats 单帧) ---"
 timeout 8 docker stats --no-stream --format \
   'table {{.Name}}\t{{.MemUsage}}\t{{.MemPerc}}\t{{.CPUPerc}}' 2>/dev/null \
   || echo "[i] docker stats 超时或不可用"
+# 单帧不是峰值。硬限低于这一帧才算不够；远高于这一帧不必改到先验表。
+echo "[i] 单帧采样不是峰值。有监控历史用峰值。没有数据时才用冷启动先验，不要为贴近先验表改硬限。"
 
 echo ""
 echo "--- Postgres 启动参数 (从 docker inspect Args 提取) ---"
@@ -116,10 +119,10 @@ for c in $(docker ps -q 2>/dev/null); do
     # 从 docker inspect 取 shm_size (Postgres 关键)
     shm=$(docker inspect -f '{{.HostConfig.ShmSize}}' "$c" 2>/dev/null)
     shm_mb=$(( shm / 1024 / 1024 ))
-    if [[ "$shm_mb" -lt 128 ]]; then
-      echo "  [!] MEDIUM: shm_size=${shm_mb}m 偏低 (大查询可能 'no space left on /dev/shm', 推荐 >=256m)"
-    else
-      echo "  [OK] shm_size=${shm_mb}m"
+    # 64m 是 Docker 默认。没有 /dev/shm 写满的证据时，不把 256m 当合格线。
+    echo "  shm_size=${shm_mb}m"
+    if [[ "$shm_mb" -lt 64 ]]; then
+      echo "  [i] shm_size 低于 Docker 默认 64m。仅当日志出现 no space left on /dev/shm 时再加大，不预设 256m"
     fi
 
     # 校验 shared_buffers 是否过大
@@ -200,14 +203,14 @@ for f in $COMPOSE_FILES; do
 done
 
 echo ""
-echo "--- 日志兜底推荐档 (基于根盘 + 容器规模, 对照 SKILL.md 4.10) ---"
+echo "--- 日志上限 (冷启动先验，不是目标配额) ---"
 ROOT_TOTAL_MB=$(df -BM --output=size / 2>/dev/null | tail -1 | tr -d ' M')
 ROOT_TOTAL_GB=$(( ${ROOT_TOTAL_MB:-0} / 1024 ))
 RUNNING_COUNT=$(docker ps -q 2>/dev/null | wc -l | tr -d ' ')
 echo "根盘容量: ${ROOT_TOTAL_GB} GB"
 echo "运行容器数: ${RUNNING_COUNT}"
 
-# 推荐档分级
+# 没有日志日增量时的起点。有 check_logs 的增速就用增速，不要改成跟这里一致。
 if   [[ $ROOT_TOTAL_GB -lt 50 ]];   then REC_TIER="入门"; REC_SIZE="10m"; REC_FILE="3"
 elif [[ $ROOT_TOTAL_GB -lt 150 ]]; then
   REC_TIER="标准"
@@ -215,8 +218,7 @@ elif [[ $ROOT_TOTAL_GB -lt 150 ]]; then
   else                                REC_SIZE="50m"; REC_FILE="5"; fi
 else REC_TIER="大型"; REC_SIZE="100m"; REC_FILE="5"
 fi
-echo "推荐档: ${REC_TIER}"
-echo "推荐 daemon log-opts: max-size=${REC_SIZE}, max-file=${REC_FILE}, compress=true"
+echo "冷启动先验档: ${REC_TIER} (无日志增量时才参考 max-size=${REC_SIZE}, max-file=${REC_FILE})"
 
 # 拿当前 daemon.json log-opts (复用 check_docker.sh 的逻辑)
 DAEMON_JSON=$(sudo -n cat /etc/docker/daemon.json 2>/dev/null \
@@ -227,13 +229,11 @@ CUR_FILE=$(echo "$DAEMON_JSON" | grep -oE '"max-file"[[:space:]]*:[[:space:]]*"[
             | head -1 | grep -oE '"[^"]+"$' | tr -d '"')
 echo "当前 daemon.json: max-size=${CUR_SIZE:-(未配置)}, max-file=${CUR_FILE:-(未配置)}"
 
-# 简单对比标记
+# 缺上限才是问题。和先验档相同或不同都不表示配额正确。
 if [[ -z "$CUR_SIZE" ]]; then
   echo "[!!!] CRITICAL: daemon 无 log-opts.max-size, 长跑容器日志会无限增长"
-elif [[ "$CUR_SIZE" == "$REC_SIZE" ]]; then
-  echo "[OK] max-size 与推荐档一致"
 else
-  echo "[i] 当前 max-size=${CUR_SIZE} 与推荐档 ${REC_SIZE} 不同 (主 Claude 据 SKILL.md 4.10 判定是否偏离 50%)"
+  echo "[i] 已有 max-size=${CUR_SIZE} max-file=${CUR_FILE:-(未配置)}。与冷启动先验不同不是问题，按日志增速判断。"
 fi
 
 # 估算所有容器日志合计 quota = max-size × max-file × 容器数, 看占根盘比
@@ -250,15 +250,15 @@ if [[ -n "$CUR_SIZE" ]]; then
   total_quota_mb=$(( ${size_mb:-0} * file_n * RUNNING_COUNT ))
   if [[ "$ROOT_TOTAL_MB" -gt 0 ]]; then
     pct=$(( total_quota_mb * 100 / ROOT_TOTAL_MB ))
-    echo "所有容器最大日志 quota 合计: ${total_quota_mb} MB (占根盘 ${pct}%, 期望 < 5%)"
+    echo "所有容器最大日志 quota 合计: ${total_quota_mb} MB (占根盘 ${pct}%)"
     if [[ "$pct" -gt 5 ]]; then
-      echo "[!!] HIGH: 日志 quota 合计 ${pct}% 已超根盘 5% 上限"
+      echo "[!!] HIGH: 配额天花板占根盘 ${pct}%。5% 是安全上限，超过说明 max-size/max-file 过大，不是叫你改成先验档的 10m/50m"
     fi
   fi
 fi
 
 echo ""
-echo "--- 资源占比汇总 (供 Claude 校验 65% 上限规则) ---"
+echo "--- 内存硬限占宿主比 (75% 是安全天花板，不是目标利用率) ---"
 echo "宿主总内存: ${MEM_TOTAL_MB} MB"
 TOTAL_LIMIT_MB=$(docker ps -q 2>/dev/null \
   | xargs -I{} docker inspect -f '{{.HostConfig.Memory}}' {} 2>/dev/null \
@@ -268,11 +268,9 @@ if [[ "$MEM_TOTAL_MB" -gt 0 ]]; then
   pct=$(( TOTAL_LIMIT_MB * 100 / MEM_TOTAL_MB ))
   echo "占宿主总内存: ${pct}%"
   if [[ "$pct" -gt 75 ]]; then
-    echo "[!!] HIGH: 容器硬限合计 > 75% 宿主内存, OS/nginx/监控 留 buffer 不足"
-  elif [[ "$pct" -lt 30 ]]; then
-    echo "[i] INFO: 容器硬限合计 < 30%, 可能资源利用不足"
+    echo "[!!] HIGH: 容器硬限合计 > 75% 宿主内存, OS 没有余量"
   else
-    echo "[OK] 容器硬限合计在 30%-75% 区间"
+    echo "[i] 硬限合计 ${pct}%。不要求贴近 65%。硬限低于上面的 docker stats 才要加"
   fi
 fi
 REMOTE

package/templates/ai-tools/skills//345/256/211/345/205/250/dwy-deploy-audit/scripts/check_db.sh

@@ -139,7 +139,15 @@ fi
 
 echo ""
 echo "########## 公网可达性自测 ##########"
-PUB_IP=$(curl -fsS --max-time 5 https://api.ipify.org 2>/dev/null)
+# 与 check_base.sh 同一原则：回显地址是先验，失败换下一个，禁止用内网地址顶上。
+PUB_IP=""
+for url in https://api.ipify.org https://ifconfig.me/ip https://icanhazip.com; do
+  PUB_IP=$(curl -fsS --max-time 5 "$url" 2>/dev/null | tr -d '[:space:]')
+  if printf '%s' "$PUB_IP" | grep -Eq '^[0-9]{1,3}(\.[0-9]{1,3}){3}$'; then
+    break
+  fi
+  PUB_IP=""
+done
 echo "公网 IP (best effort): ${PUB_IP:-unknown}"
 if [[ -n "$PUB_IP" ]]; then
   echo "[i] 注意: 真实公网可达性需从外网测试,此处仅本机视角"