create-dwy 0.19.0 → 0.20.0

package/templates/ai-tools/skills/Vue/dwy-eui/versions.yml

@@ -0,0 +1,12 @@
+# @dwydev/eui 安装版本 → 文档线。匹配从上到下第一条。
+# 大版本破坏才新开 vN/；2.x 内部 breaking 写 v2/breaking.md，细节 clone 对应 tag。
+repo: https://github.com/danweiyuancircle/dwy-ai-experience.git
+tag_prefix: "@dwydev/eui@"
+sparse:
+  - frontend/eui/src
+  - frontend/eui/package.json
+lines:
+  - match: ">=2.0.0"
+    dir: v2
+  - match: ">=1.0.0"
+    dir: v1

package/templates/ai-tools/skills//344/272/247/345/223/2010/345/210/2601/dwy-architecture/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: dwy-architecture
-description: "【dwy·技术架构】产品 0 到 1 设计与架构阶段。触发场景：用户说『设计架构 / 出技术方案 / 设计库表 / 定接口契约 / 技术架构 / architecture』，要在开发前定下技术架构、数据库设计和接口契约时。按四层架构（Assembly/Features/BizFoundation/Foundation）+ 统一选型（Python+FastAPI、Vue+Vite）产出。"
+description: "【dwy·技术架构】产品 0 到 1 设计与架构阶段。触发场景：用户说『设计架构 / 出技术方案 / 设计库表 / 定接口契约 / 技术架构 / architecture』，要在开发前定下技术架构、数据库设计和接口契约时。按对应栈 dwy-*-layering（四层 + 单向依赖）+ 统一选型（Python+FastAPI、Vue+Vite）产出。"
 ---
 
 ## 职责（单一）
@@ -37,24 +37,21 @@ description: "【dwy·技术架构】产品 0 到 1 设计与架构阶段。触
 - **CI/CD 走 GitHub Actions + OIDC**（发布鉴权用 OIDC，禁长期静态凭据）
 - **基线不适用就先确认**：任一项基线与上下文冲突（如纯前端无需 Docker/DB、要换其他 DB/MQ/中间件、不能用某项）→ 先 `AskUserQuestion` 跟用户确认，确认后在架构文档写明偏离基线的理由
 
-### 四层架构（依赖严格单向向下：Assembly → Features → BizFoundation → Foundation）
+### 四层架构
 
-| 层 | 职责 | 后端示例 | 前端示例 |
-|---|---|---|---|
-| **装配层 (Assembly)** | 实例化 / 依赖注入 / 路由挂载 / 生命周期，**零业务逻辑** | `src/app/`（main.py 装 Provider/Hook、factories） | `apps/web`（路由、stores、main.ts） |
-| **Features (业务功能层)** | 各业务域领域逻辑，域内 router+service+schema+model **聚在同一目录** | `<域>/`（如 `factor/`、`plan/`、`quota/`） | `features/*`（如 auth、settings） |
-| **业务基础层 (BizFoundation)** | 业务相关但跨业务域复用：鉴权、领域协议/Provider、领域设施 | `auth`、各包 `protocols.py`/`providers` | 跨域复用的业务 composable/store |
-| **业务无关层 (Foundation)** | 与业务完全无关的 kernel | `shared`（DB/Redis/签名/中间件） | `core`（httpClient/格式化/常量） |
+层名、依赖边、分包树以对应栈的 layering rule 为准，本 skill **不另定义目录**：
 
-### 三条铁律
-- **依赖单向向下，绝不反向**：下层禁止 import 上层；Foundation 禁止 import 任何业务包；跨业务域**不直接互 import**，靠装配层用 Protocol/Hook 桥接。
-- **业务内聚**：一个业务域 = 一个目录，域内 router/service/schema/model 聚在一起。✅ `factor/`（含 router+service+validators）；❌ 顶层 `routers/`+`services/`+`models/` 三个大锅各塞所有域。
-- **装配层是唯一能 import 具体实现的地方**：业务代码只通过 `get_xxx_provider()` 取实例，换实现不改业务代码。
+- Python → `dwy-python-layering`
+- Vue → `dwy-vue-layering`
+- Android → `dwy-android-layering`
+- iOS / macOS → `dwy-apple-layering`
+
+铁律（细节与正反例见上列 rule）：依赖只许向下；`features/*` 互不依赖；具体实现只在 Assembly 注入；第三方版本只写在仓库根 catalog。
 
 ## 实现
 [自写型]
 1. 读项目 `.claude/rules/`，结合上方架构约束产出架构（项目 rules 优先，本约束兜底）
-2. 技术架构：**先按四层归位模块、按业务域聚目录**，再写分层/模块边界/选型理由；选型不确定处走 `AskUserQuestion`
+2. 技术架构：**先读对应栈 `dwy-*-layering` 按四层归位模块、按业务域聚目录**，再写分层/模块边界/选型理由；选型不确定处走 `AskUserQuestion`
 3. **判有无后端**（读选型/PRD：有 API / 持久化 / 账户体系 → 有后端）：
    - **有后端** → 必出数据库设计，且**建模到位**：库表清单 / 字段(类型·约束·默认·可空) / 主外键关系 / 索引 / 必要的范式或反范式说明，与接口契约 schema 对齐
    - **纯前端**（无后端）→ 跳过数据库设计，在 `技术架构.md` 注明「无后端，不涉及库表」
@@ -64,7 +61,7 @@ description: "【dwy·技术架构】产品 0 到 1 设计与架构阶段。触
 ## 产出契约（硬约束）
 - 落到：`.dwy/prod/[项目]/04-架构设计/技术架构.md`、`接口契约.md`，**有后端时**加 `数据库设计.md`
 - 固定章节：
-  - 技术架构.md：**四层划分 + 各业务域目录结构** / 模块边界 / 技术选型（按缺省基线写明 Python+FastAPI+uv+Alembic+pydantic-settings+JWT、前端 Vue+Vite+TS+Tailwind+pnpm+Pinia+axios+Playwright、CI/CD GitHub Actions OIDC；有 DB 写明 PostgreSQL+Redis+Docker+Nginx；偏离基线处写明原因）/ 选型不明或偏离基线处的 AskUserQuestion 确认记录 / 有无后端结论
+  - 技术架构.md：**按对应 `dwy-*-layering` 写四层划分 + 各业务域目录结构** / 模块边界 / 技术选型（按缺省基线写明 Python+FastAPI+uv+Alembic+pydantic-settings+JWT、前端 Vue+Vite+TS+Tailwind+pnpm+Pinia+axios+Playwright、CI/CD GitHub Actions OIDC；有 DB 写明 PostgreSQL+Redis+Docker+Nginx；偏离基线处写明原因）/ 选型不明或偏离基线处的 AskUserQuestion 确认记录 / 有无后端结论
   - 数据库设计.md（**有后端必出**）：库表清单 / 字段定义(类型·约束·默认·可空) / 主外键关系与索引 / 与接口契约对齐
   - 接口契约.md：接口清单 / 请求响应 schema / 错误码
 - 回写 state.json：`confirmed.architecture`

package/templates/ai-tools/skills//344/272/247/345/223/2010/345/210/2601/dwy-product-launcher/references/state-and-contract.md

@@ -106,7 +106,7 @@
 
 - 每个外部 skill 是**整个目录**（含 scripts/ 与配套 .md，不止 SKILL.md）
 - 由 `dwy` 选「刷新全局外部 skill」安装/更新（clone 两仓库的指定 stable tag → 搬整目录 + LICENSE → 写 `VERSIONS.json`）
-- `dwy claude sync` 自检：`~/.dwy/skills/` 缺失时自动装一次
+- `dwy` 日常同步自检：`~/.dwy/skills/` 缺失时自动装一次
 - 当前 stable：pm-skills **v2.0.0** | superpowers **v6.0.3**（升级改 cli 的 `skills-install.js` 清单 tag）
 - 原子 skill 运行时**只读** `~/.dwy/skills/<name>/`，缺失则提示用户先跑 `dwy`，选「刷新全局外部 skill」，不自己拉、不降级
 

package/templates/ai-tools/skills//344/272/247/345/223/2010/345/210/2601/dwy-prototype/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: dwy-prototype
-description: "【dwy·UI原型】产品 0 到 1 设计与架构阶段。触发场景：用户说『画原型 / 出原型 / 做 UI 原型 / 把页面画出来 / prototype』，要在写 UI 代码前把页面画成静态原型图时。两轮串行门控：先低保真线框初稿，用户讨论通过后再做高保真平面图，过了才进架构。"
+description: "【dwy·UI原型】产品 0 到 1 的静态原型。触发场景：用户说『产品流程出原型 / 线框初稿 / 高保真平面图 / 0到1 原型』。两轮串行门控：先低保真线框，用户通过后再做高保真平面图。可交互白板、状态跳转连线不走本 skill，走 dwy-whiteboard-prototype。"
 ---
 
 ## 职责（单一）

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

@@ -56,13 +56,26 @@ gh run view <run-id> --json jobs,conclusion
 - PyPI Trusted Publisher 需要 `permissions: id-token: write`，并绑定 workflow 和 environment。
 - artifact 名称必须包含平台和架构，避免多个 matrix 上传时互相覆盖。
 
+## 模板里的 tag、runner、依赖下限是先验
+
+`references/*.yml` 里的 `actions/*@v4`、`pypa/cibuildwheel@v3.4`、`ubuntu-24.04-arm`、`macos-15-intel`、`macos-14`、`manylinux_2_28`、`musllinux_1_2`、`setuptools>=77`、`packaging>=24.2`、`Cython>=3.0.10`、`node-version: 20` 是写作时能用的起点。
+
+复制前核对：
+
+- `uses:` 的 tag 在该 action 仓库里真实存在。没有 major alias（例如曾经的 `cibuildwheel@v3`）就换本次查到的 minor 或精确 tag。
+- runner label 在 `actions/runner-images` 当前 supported 列表里。已知退役：`macos-13` / `macos-12` / `macos-11` / `ubuntu-20.04`。新退役的同样不能用。表里没写但还在支持的不要判死。
+- manylinux / musllinux 按这次要装的 wheel 实际 platform tag 选。旧镜像装不上就换，不要把 `_2_28` 当成永远唯一。
+- `setuptools` / `packaging` / `Cython` 的下限来自 PEP 639 把旧 packaging 打爆那次。license expression 仍缺 `packaging.licenses` 时，按这几个包当前 release 的依赖说明抬下限。数字对不上就换，不要把 77 / 24.2 写成唯一修复。
+
+当次选出的 tag 和 label 不要写回本 skill 或模板，当成新的永远默认。
+
 ---
 
 ## 场景 1：Python Cython wheel + PyPI OIDC
 
 适用：含 Cython 编译扩展的 Python 包、跨平台 wheel 分发（linux x86_64/aarch64 + macOS x86_64/arm64 + Windows AMD64）、GitHub Actions + cibuildwheel + PyPI Trusted Publisher OIDC 发版。
 
-模板：复制 `./references/release-workflow-template.yml` 到目标项目 `.github/workflows/release.yml`，只改：
+模板：复制 `./references/release-workflow-template.yml` 到目标项目 `.github/workflows/release.yml`。action tag、runner label、manylinux 镜像先按上一节核对，再改：
 
 1. `package-dir: <PACKAGE_DIR>`：实际 SDK 子目录；单包仓库填 `.` 或省略。
 2. `CIBW_BUILD`：按需调整 Python 版本枚举。
@@ -75,13 +88,13 @@ rg -n "Cython|ext_modules|Extension|cibuildwheel|pypa/gh-action-pypi-publish|lic
 
 检查点：
 
-- `[build-system].requires` 含 `setuptools>=77`、`packaging>=24.2`、`wheel`、`Cython>=3.0.10`。
-- `pypa/cibuildwheel` 用 minor tag 或精确 tag，例如 `pypa/cibuildwheel@v3.4`，不要写 `@v3`。
+- `[build-system].requires` 要能通过当前的 license expression 检查。当时踩坑的下限是 `setuptools>=77`、`packaging>=24.2`、`wheel`、`Cython>=3.0.10`，以这几个包当前 release 说明为准。
+- `pypa/cibuildwheel` 用仓库里真实存在的 minor tag 或精确 tag。`@v3.4` 是当时的例子，不要写不存在的 `@v3`。复制前再查一次 tag。
 - monorepo 用 `with.package-dir`，测试命令使用 `{package}`，不要用 `{project}/tests`。
 - 跨平台 shell 参数用外单内双：`'pytest {package}/tests -v -k "not requires_server"'`。
-- Linux 依赖 pyarrow / pandas / numpy / scipy / lxml 时，manylinux 镜像用 `manylinux_2_28`。
+- Linux 依赖 pyarrow / pandas / numpy / scipy / lxml 时，manylinux 镜像按这些 wheel 当前的 platform tag 选。当时需要 `manylinux_2_28`。
 - test 阶段大依赖用 binary-only 预装：`CIBW_BEFORE_TEST: "pip install --only-binary=:all: pyarrow pandas"`。
-- macOS x86_64 用 `macos-15-intel`，不要用 `macos-13`。
+- macOS x86_64 用当次 supported 的 intel label。写作时是 `macos-15-intel`。不要用已退役的 `macos-13`。
 - 默认只发布 wheel。不要发布 sdist，避免 Cython 编译模块源码随 sdist 泄漏。
 
 ### Python 8 个高频坑
@@ -164,7 +177,9 @@ CIBW_TEST_COMMAND: "pytest {package}/tests -v -k 'not requires_server'"
 CIBW_TEST_COMMAND: 'pytest {package}/tests -v -k "not requires_server"'
 ```
 
-#### 坑 6：manylinux 镜像必须升到 `_2_28`
+#### 坑 6：manylinux 镜像低于 wheel 要求的 platform tag
+
+当时 pyarrow 等需要 `manylinux_2_28`。以这次要装的 wheel 为准，不要把 `_2_28` 当成永远唯一。
 
 ```yaml
 env:
@@ -181,7 +196,9 @@ env:
   CIBW_TEST_COMMAND: 'pytest {package}/tests -v -k "not requires_server"'
 ```
 
-#### 坑 8：macos-13 runner 已退休
+#### 坑 8：退役 runner
+
+`macos-13` 当时已退休。下面这组 label 是当时的 supported 先验，写之前再查 `actions/runner-images`。
 
 ```yaml
 matrix:
@@ -212,17 +229,17 @@ rg -n "electron|electron-builder|electron-forge|pack|dist|dmg|AppImage|nsis|appx
 检查点：
 
 - `package.json` 明确 `electron` 和打包工具版本，例如 `electron-builder`。
-- workflow 用 `actions/checkout@v4`，项目依赖 submodule 时必须 `submodules: true`。
-- Node 版本固定，例如 `actions/setup-node@v4` + `node-version: 20`。
+- workflow 用当前仍存在的 checkout tag（写作时常见 `actions/checkout@v4`）。项目依赖 submodule 时必须 `submodules: true`。tag 404 或已废弃就换本次查到的 tag。
+- Node 版本按项目引擎固定到具体版本。`actions/setup-node@v4` + `node-version: 20` 只是当时的例子，不是唯一合法版本。
 - 使用锁文件安装：npm 项目用 `npm ci`，pnpm 项目用 `pnpm install --frozen-lockfile`。
 - 每个平台在对应 runner 上打包，不要指望一个 Linux runner 交叉产出 macOS / Windows 完整安装包。
-- macOS x64 和 arm64 分开：x64 用 `macos-15-intel`，arm64 用 `macos-latest` / `macos-14`。
+- macOS x64 和 arm64 分开。写作时 x64 是 `macos-15-intel`，arm64 是 `macos-latest` / `macos-14`。写之前再查 supported labels。
 - Linux AppImage 需要系统依赖，常见为 `icnsutils graphicsmagick xz-utils`。
 - Linux runner 上 `apt-get update` 前可移除易失效的 Microsoft / Azure apt source，避免第三方源拖死打包。
 - 未配置证书但要产出 unsigned 包时，设置 `CSC_IDENTITY_AUTO_DISCOVERY: false`，避免 electron-builder 自动找证书导致 macOS job 失败。
 - 产物命名必须包含 `${version}`、`${os}`、`${arch}`，避免 Release asset 覆盖。
 - upload-artifact 只上传最终安装包：`*.dmg`、`*.exe`、`*.AppImage`；不要上传 `win-unpacked/`。
-- GitHub Release job 需要 `permissions: contents: write`，用 `actions/download-artifact@v4` + `merge-multiple: true` 汇总产物。
+- GitHub Release job 需要 `permissions: contents: write`。汇总产物用当前仍存在的 `actions/download-artifact` tag（写作时常见 `@v4`）+ `merge-multiple: true`。
 
 ### Electron 推荐 workflow 形态
 
@@ -232,7 +249,7 @@ rg -n "electron|electron-builder|electron-forge|pack|dist|dmg|AppImage|nsis|appx
 
 #### 坑 1：macOS x64 / arm64 不能混跑
 
-macOS x64 用 `macos-15-intel`。macOS arm64 用 `macos-latest` / `macos-14`。不要用已退役的 `macos-13`。
+macOS x64 用当次 supported 的 intel label（写作时是 `macos-15-intel`）。macOS arm64 用当次 arm label（写作时是 `macos-latest` / `macos-14`）。不要用已退役的 `macos-13`。
 
 #### 坑 2：Linux 打 AppImage 缺系统依赖
 
@@ -353,12 +370,12 @@ git push origin v1.2.3
 |---|---|---|
 | YAML 解析 | env / run 含 `:` 未加引号，run 几秒 fail 且 jobs 为空 | 致命 |
 | action tag | `pypa/cibuildwheel@v3` 等不存在 alias | 致命 |
-| runner | `macos-13` / `macos-12` / `ubuntu-20.04` | 致命 |
+| runner | 不在当次 supported 列表里。已知退役：`macos-13` / `macos-12` / `ubuntu-20.04` | 致命 |
 | artifact | matrix 上传同名产物或未带平台架构 | 高 |
-| Python build-system | PEP 639 license 但缺 `packaging>=24.2` | 致命 |
+| Python build-system | license expression 但构建环境缺 `packaging.licenses`（当时的下限是 `packaging>=24.2`） | 致命 |
 | Python test path | monorepo 子目录用 `{project}/tests` | 高 |
 | Python shell 引号 | Windows 跨平台命令里用单引号包参数 | 高 |
-| Python manylinux | 大型 C 库依赖仍用 manylinux2014 | 高 |
+| Python manylinux | 镜像低于这次 wheel 要求的 platform tag（当时常见仍停在 manylinux2014） | 高 |
 | Electron macOS | x64 / arm64 未拆 runner | 高 |
 | Electron Linux | AppImage 缺 `icnsutils graphicsmagick xz-utils` | 高 |
 | Electron 签名 | unsigned 构建未设 `CSC_IDENTITY_AUTO_DISCOVERY: false` | 中 |

package/templates/ai-tools/skills//345/217/221/345/270/203/345/217/221/347/211/210/dwy-github-action-publish/references/electron-release-workflow-template.yml

@@ -3,12 +3,14 @@
 # 来源参考: 某 Electron 桌面应用多平台打包实战 (release.yml + pack.mjs)
 #
 # 使用前按项目实际情况替换:
-#   1. node-version
+#   1. node-version（模板里的 20 只是当时的例子）
 #   2. 包管理器安装命令(npm ci / pnpm install --frozen-lockfile)
 #   3. build / pack 命令
 #   4. Linux 系统依赖
 #   5. 签名 / 公证 secrets
 #   6. artifact path 和文件命名
+#   7. uses: 的 action tag 和 runs-on label。对照该 action 仓库的 tag 和 runner-images。
+#      模板里的 @v4 / @v2、macos-14、ubuntu-latest 只是起点，不是必须版本。
 
 name: Build and Release
 

package/templates/ai-tools/skills//345/217/221/345/270/203/345/217/221/347/211/210/dwy-github-action-publish/references/release-workflow-template.yml

@@ -1,13 +1,16 @@
 # Python Cython SDK 跨平台 wheel + PyPI Trusted Publisher 发版 workflow 模板
 #
-# 已内置 dwy-github-action-publish skill Python wheel 场景 8 个避坑修复，开箱即用。
-# 复制到项目 .github/workflows/release.yml，只改两处：
+# action tag、runner label、manylinux 镜像、setuptools/packaging/Cython 下限都是写作时的先验。
+# 复制前对照 action 仓库的 tag 和 actions/runner-images 的 supported labels。
+# tag 404、label 退役、wheel 的 platform tag 对不上，就换这次查到的值。不要把新值写回本模板。
+#
+# 复制到项目 .github/workflows/release.yml 后还要改：
 #   1. package-dir: <PACKAGE_DIR>      —— 实际 SDK 子目录（monorepo 必填，单包仓库填 . 或省略）
 #   2. CIBW_BUILD                      —— 按需调整 Python 版本枚举
 #
-# 配套要求（缺一不可）：
-#   1. <PACKAGE_DIR>/pyproject.toml 的 [build-system].requires 含:
-#        "setuptools>=77", "packaging>=24.2", "wheel", "Cython>=3.0.10"
+# 配套：
+#   1. license expression 仍缺 packaging.licenses 时，按当前 release 说明抬 setuptools/packaging 下限。
+#      当时踩坑的起点是 "setuptools>=77", "packaging>=24.2", "wheel", "Cython>=3.0.10"
 #   2. PyPI Trusted Publisher 已配（owner/repo/workflow=release.yml/environment=pypi）
 #   3. GitHub Settings → Environments 存在名为 "pypi" 的 environment
 

package/templates/ai-tools/skills//345/217/221/345/270/203/345/217/221/347/211/210/dwy-ios-app-store-release/SKILL.md

@@ -34,7 +34,7 @@ description: "Use when 用户要上架、发 iOS/macOS 版本、填 App Store Co
 
 ## 每版本处理
 
-1. **推广文本不向用户询问**。现网有内容则原样拷进 `promotional_text`。与本版卖点明显不符时自行改写，改前可上网核对卖点是否仍准确；双语各 ≤170 字。首次无现网则按名称/副标题/描述生成。细则见 [aso.md](references/aso.md)。
+1. **推广文本不向用户询问**。现网有内容则原样拷进 `promotional_text`。与本版卖点明显不符时自行改写，改前可上网核对卖点是否仍准确。双语各不超过 [aso.md](references/aso.md) 的推广文本上限（当前先验 170）。Connect 拒收后改用当前字段限制。首次无现网则按名称/副标题/描述生成。
 2. **更新说明**：后续版本 `whats_new` 双语必填。给用户看的概览，写「新增某某功能」这类句子，机制细节不写，可用「等等」。禁止把 `dwy-publish` 的 git `CHANGELOG` 或实现细节贴进商店。首次上架可空。
 3. **截图**：默认 `screenshots.update=false`，拷上一版本，不问。出现任一情况必须更新：新主界面、新核心能力、旧图已不能代表产品、**What's New 写了的能力在现网截图里看不到**。按 [screenshot-specs.yaml](references/screenshot-specs.yaml) 处理；已送审版本改图见 [screenshot-workflow.md](references/screenshot-workflow.md)「送审后锁死」。
 4. **发布策略**：向用户确认二选一——过审即发（`AFTER_APPROVAL`），或过审后几天再发（`SCHEDULED` + `delay_days`）。选几天则再问天数。未选不得提交。

package/templates/ai-tools/skills//345/217/221/345/270/203/345/217/221/347/211/210/dwy-ios-app-store-release/assets/appstore-submission.yaml

@@ -52,7 +52,7 @@ localizations:
 screenshots:
   ios: { zh-Hans: [], en-US: [] }
   macos: { zh-Hans: [], en-US: [] }
-# 每个内购条目必须带 `review_screenshot`，尺寸固定为 1280x800 像素。
+# 每个内购条目必须带 `review_screenshot`。像素只读 references/screenshot-specs.yaml 的 macos_iap_review，不要在这里另写尺寸。
 in_app_purchases: []
 subscriptions: []
 review:

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

@@ -4,6 +4,8 @@
 
 ## 字数（按字符计，含中文一字）
 
+这些上限是 App Store Connect 的当前先验。提交若被拒说超长，以 Connect 当前字段限制改文案。不要用本表旧数字硬裁，也不要把新上限写回本文件。
+
 | 字段 | 上限 | 每版本 |
 |------|------|--------|
 | 名称 | 30 | 继承后可优化 |

package/templates/ai-tools/skills//345/217/221/345/270/203/345/217/221/347/211/210/dwy-ios-app-store-release/references/in-app-purchase-review.md

@@ -7,7 +7,7 @@
 ## 采集与上传
 
 1. 使用审核账号或 StoreKit 测试环境进入目标商品购买页。
-2. 在 macOS 16:10 画布导出 `1280 × 800` PNG 或 JPG，移除用户身份、支付凭据和生产数据。
+2. 按 [screenshot-specs.yaml](screenshot-specs.yaml) 的 `macos_iap_review.preferred` 导出 PNG 或 JPG，移除用户身份、支付凭据和生产数据。该条目当前先验是 `1280 × 800`。被拒后改那份规格，不要在这里另写像素。
 3. 上传前校验精确像素、RGB、无透明通道和单张文件约束。
 4. 通过 `inAppPurchaseAppStoreReviewScreenshots` 的预留、上传、提交流程写入对应内购；上传后读取资源状态确认成功。
 

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

@@ -1,6 +1,6 @@
 ---
 name: dwy-publish
-description: "发版/部署编排器。触发条件：用户说\"发版\"\"部署\"\"发布上线\"\"release\"\"publish\"\"走发版流程\"时。按应用目录确认发布方式并缓存，串起定版本→changelog→安全检查→打 tag→build/发布→监控→通知。每次更新版本必须打 git tag，tag 版本串与 changelog 新版本标题完全一致。版本号决策单独走 dwy-semver，GA 打包走 dwy-github-action-publish，发布前安全检查走 dwy-sdk-spec——本 skill 负责编排，按路径主动调它们。"
+description: "发版/部署编排器。触发条件：用户说\"发版\"\"部署\"\"发布上线\"\"release\"\"publish\"\"走发版流程\"时。按应用目录确认发布方式并缓存，串起定版本→changelog→安全检查→打 tag→build/发布→监控→通知。工厂里有多个项目时，先查出哪些项目的前端或后端有变更，再分别写 changelog。每次更新版本必须打 git tag，tag 版本串与该份 changelog 新版本标题完全一致。版本号决策单独走 dwy-semver，GA 打包走 dwy-github-action-publish，发布前安全检查走 dwy-sdk-spec——本 skill 负责编排，按路径主动调它们。"
 ---
 
 # 发版编排器
@@ -14,7 +14,7 @@ description: "发版/部署编排器。触发条件：用户说\"发版\"\"部
 | 1 | 确认发布方式 + 探测 build/publish 命令 | 项目步 | `scripts/release_config.sh` + `references/publish-config.md` |
 | 2 | 写/校验发布配置（GA workflow / TestFlight 就绪） | 项目步 | `references/publish-config.md` |
 | 3 | 定版本号 + 多文件同步 | 通用步 | `../dwy-semver` + `references/version-sync.md` |
-| 4 | 写 changelog（按平台子目录） | 通用步 | `references/changelog.md` |
+| 4 | 写 changelog（先扫工厂内要发的项目，再按每个项目的前端/后端分别写） | 通用步 | `references/changelog.md` |
 | 5 | 安全检查（闸门，未过不发） | 通用步 | `../dwy-sdk-spec` |
 | 6 | commit 版本变更 + 打 tag 并推送 | 通用步 | `references/git-tag.md` |
 | 7 | build + 触发发布 | 项目步 | `references/<平台>.md`；走 GA 引 `../dwy-github-action-publish` |
@@ -29,6 +29,7 @@ description: "发版/部署编排器。触发条件：用户说\"发版\"\"部
 - 安全检查（第 5 步）是闸门，未过不进 tag / 发布。
 - **每次更新版本必须打 tag**（第 6 步）：tag 版本串与本次 changelog 新版本标题（`## x.y.z`）完全一致；细则见 `references/git-tag.md`。无 bump 的纯重发可不打新 tag。
 - 若 GA workflow 由 tag 触发，第 6 步 push tag 即触发第 7 步发布。
-- 全程 AI 自动判断、自动跑，仅搞不定时才问用户（版本级别拿不准、命令探测不到、配置缺失、构建/发布失败、需删远端 tag）。
+- **正式环境分支**：只有 `develop` 和 `preview`。`develop` 发测试环境，版本只能是 `beta` 或 `rc`。正式版只从 `preview` 发。仓库没有这两条分支就先提醒，不自行建分支。用 `develop` 发正式版时，先按 `rules/开发流程/dwy-prod-branch.md` 问用户，未确认不发。
+- 全程 AI 自动判断、自动跑，仅搞不定时才问用户（版本级别拿不准、命令探测不到、配置缺失、构建/发布失败、需删远端 tag）。用 `develop` 部署正式环境时除外，须先问用户。
 - 编排时按文件路径主动加载子 skill（`../dwy-semver`、`../dwy-sdk-spec`、`../dwy-github-action-publish`）；这些 skill 也可被用户独立触发。
 - `.dwy/` 缓存提醒用户加进 `.gitignore`。

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

@@ -26,7 +26,7 @@
 
 ## changelog / tag / 安全检查 / 监控
 
-- changelog → `changelog.md`（写 `android/CHANGELOG.md`）
+- changelog → `changelog.md`（写该项目的 `android/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/backend-deploy.md

@@ -19,6 +19,6 @@
 
 ## changelog / tag / 监控
 
-- changelog → `changelog.md`（写 `backend/CHANGELOG.md`）
+- changelog → `changelog.md`（写该项目的 `backend/CHANGELOG.md`；工厂里多个项目时每个项目各一份）
 - tag → `git-tag.md`（每次 bump 必打；版本串与 changelog `##` 标题一致）
 - 监控 + verify → `monitor-notify.md`（后端信号：健康检查 / 版本接口 / 运行日志 / 镜像 tag）

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`，不套用先验表数字
 - ...
 
 ---