create-dwy 0.20.0 → 0.22.0

package/templates/ai-tools/skills/Vue/dwy-eui/shared/form.md

@@ -4,3 +4,13 @@
 - `ESelect` 的 `option.value` **不能是 `''`**，reka-ui 不支持。筛选项用哨兵（如 `'all'`），请求时再转 `undefined`。
 - 校验优先 zod schema 交给 `EForm` 的 `rules`。
 - `useFormField` 只在 `EFormItem` 内有值；表单外返回 `null`，不要当 vee-validate `<FormField>` 用。
+
+## 表单对话框（EUI ≥2.7.0）
+
+- `EForm :id="formId"` 与 `EFormDialog :form="formId"` 配对；`formId` 在页面内唯一，可用 Vue `useId()`。`id` 透传到 `EForm` 根 `<form>`，不是新 prop。
+- 保存函数只绑定 `EForm @submit`：默认确认按钮通过原生 submit 进入 vee-validate 校验，通过后才触发 `submit`。不要同时绑定 `EFormDialog @confirm` 保存；关联 `form` 时不派发 `confirm`。
+- `confirm-disabled` 只禁用默认确认按钮；`description` 提供可访问说明；`#footer-leading` 在默认按钮前追加操作，追加按钮显式设 `type="button"`。
+- `loading` 阻止默认取消、确认、X、Esc、遮罩关闭；父组件仍可 `open=false`。业务提交函数仍需检查 loading，覆盖键盘或程序提交防重入。
+- `#footer` 整体覆盖默认 footer 与 `#footer-leading`，自定义按钮行为由调用方负责。
+- 旧项目不传 `form` 时保留 `@confirm`，默认确认为普通按钮；可继续手动 `validate()`。迁移时改为 `EForm @submit` 单入口。
+- 程序提交使用 `requestSubmit()`；原生 `form.submit()` 会绕过 submit 事件与校验。完整 Vue 示例见仓库 `frontend/eui/README.md`。

package/templates/ai-tools/skills/Vue/dwy-eui/v2/index.md

@@ -37,6 +37,11 @@
 
 ## 2.x 陷阱
 
+### EFormDialog（≥2.7.0）
+
+- 新增原生表单关联：`EForm :id="formId"` + `EFormDialog :form="formId"` + `EForm @submit`；关联后不再派发 `confirm`。未传 `form` 的旧 `@confirm` 用法保持兼容。
+- `confirm-disabled`、`description` 与 `#footer-leading` 用法和 loading 关闭边界见 `../shared/form.md`；精确签名仍按安装版本查询。
+
 ### 汉堡 / 抽屉
 
 - `ESheet` / `EAdminLayout` 的 Boolean `open` / `mobileOpen` **缺省必须是 `undefined`**，不能是 `false`。`false` 会让非受控开关永远打不开（≥2.4.0）。

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

@@ -19,7 +19,7 @@ description: "【dwy·TDD开发阶段】产品 0 到 1 的第四阶段编排。
 调度前**必须先分析每个任务的前后 block 关系**（由任务 Interfaces 推出：`Consumes`=被谁 block、`Produces`=block 谁）。判定铁律：
 - **无 block 的任务 → 多 Agent 并行**
 - **有 block 的任务 → 串行**，被 block 的下游必须等其所有前置 block 任务 done 才能启动
-- 与 `ai-tools/CLAUDE.md`「任务执行前必须先分析 block；无 block 的任务用多 Agent 并行」一致
+- 与 `ai-tools/AGENTS.md`「任务执行前必须先分析 block；无 block 的任务用多 Agent 并行」一致
 
 ### 第二步·agent 池调度
 - 按 block 分析结果建 **ready 队列**（所有前置 block 已 done 的任务，即当前无 block 的）

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

@@ -1,35 +1,28 @@
 ---
 name: dwy-publish
-description: "发版/部署编排器。触发条件：用户说\"发版\"\"部署\"\"发布上线\"\"release\"\"publish\"\"走发版流程\"时。按应用目录确认发布方式并缓存，串起定版本→changelog→安全检查→打 tag→build/发布→监控→通知。工厂里有多个项目时，先查出哪些项目的前端或后端有变更，再分别写 changelog。每次更新版本必须打 git tag，tag 版本串与该份 changelog 新版本标题完全一致。版本号决策单独走 dwy-semver，GA 打包走 dwy-github-action-publish，发布前安全检查走 dwy-sdk-spec——本 skill 负责编排，按路径主动调它们。"
+description: "Use when 用户要求整理工程版本、更新 changelog、打版本 tag、发版、发布或部署上线。"
 ---
 
-# 发版编排器
+# 工程版本管理与发布编排
 
-一条发版链的编排执行。进入前测试已完成。
+先识别工程及变更，再为需要更新的工程维护版本、changelog 和 tag；是否发布及发布方式按用户意图和项目上下文判断。
 
-**先**读仓库上下文，判目标平台（前端/后端/Android/iOS/鸿蒙/通用）+ 定位应用目录（相对项目根的相对路径）。**再**按下表执行 9 步。
+## 流程
 
-| # | 步骤 | 类型 | 调用 |
-|---|------|------|------|
-| 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` |
-| 5 | 安全检查（闸门，未过不发） | 通用步 | `../dwy-sdk-spec` |
-| 6 | commit 版本变更 + 打 tag 并推送 | 通用步 | `references/git-tag.md` |
-| 7 | build + 触发发布 | 项目步 | `references/<平台>.md`；走 GA 引 `../dwy-github-action-publish` |
-| 8 | 监控发布进程 | 项目步 | `references/monitor-notify.md` |
-| 9 | 通知结果（输出结果文本） | — | `references/monitor-notify.md` |
+1. 读取仓库指令、结构、构建配置、版本来源、changelog、Git 状态和历史 tag，识别独立工程及共享版本边界。依据实际依赖判断共享代码影响；不要把每个子目录当成独立工程。优先遵循用户指定范围，分不清边界时询问。
+2. 逐工程列出变更、版本来源、changelog 路径、tag 命名、版本类型、是否需要发布和 tag 触发器。检查上次对应 tag 后的提交及本次相关的未提交变更；不要把不属于本次的改动纳入提交。
+3. 对本次需要更新的工程，按 `../dwy-semver` 确定版本级别、beta/rc 或正式版，按 `references/version-sync.md` 同步版本；按 `references/changelog.md` 更新该工程 changelog，每个版本条目必须包含明确版本号和日期，禁止使用 `Unreleased` 或“未发布”等占位标题，与是否发布无关；再按 `references/git-tag.md` 提交和打 tag。无变更工程不创建空版本。已覆盖本次代码的现有版本可复用，不重复升版或打 tag。
+4. 确定是否发布：仅版本管理时结束；需要发布或部署时，读取项目约定及现有 CI、构建和部署配置，判断渠道和命令。遵守仓库的发布和授权规则，不套用固定发布方式；证据不足时询问。不根据分支判断版本类型或发布流程。
+5. **部署上线闸门**：有新代码要上线，AI 自动检查并补齐对应工程的版本更新、changelog 和 tag，不逐项要求用户确认。自动校验 tag 指向包含全部拟部署代码、版本和 changelog 的提交，构建或部署使用该提交或其已验证产物。补齐并校验通过后继续部署；无法补齐或校验失败时停止部署并说明原因，不能以赶时间或已有构建替代。先完成项目要求的测试和适用的安全检查；SDK 对外发布前读取 `../dwy-sdk-spec`。
+6. 推送 tag 前检查远端工作流及其他自动触发器：若推送会发布，先完成所有发布闸门并确认本次已获发布授权。仅要求版本管理而推送会触发未经授权的发布时，保留本地 tag 并报告，不能推送或擅自更改 workflow。
+7. 已获授权且满足闸门时，按项目实际配置执行发布；需要 GitHub Actions 打包时读取 `../dwy-github-action-publish` 和相应平台参考文件。按 `references/monitor-notify.md` 监控并验证实际结果。
 
-平台流程文件：`frontend-deploy.md` / `backend-deploy.md` / `ios.md` / `android.md` / `harmony.md` / `generic-release.md`。
+仅重发、重跑或回滚**完全相同的已记录版本和产物**，可复用对应 changelog、版本及 tag；必须核实代码和产物身份。有新代码则不是重发，必须完成新版本的全部闸门。仅环境配置变更按项目约定记录和验证，不得借此夹带新代码。
 
-## 编排约束
+## 参考文件
 
-- **通用步固化**（定版本/changelog/安全检查/打 tag 跨项目一致，走子 skill/脚本）；**项目步读上下文+缓存**（build/deploy/监控命令因项目而异，**绝不写死**，探测不到问用户后缓存）。
-- 安全检查（第 5 步）是闸门，未过不进 tag / 发布。
-- **每次更新版本必须打 tag**（第 6 步）：tag 版本串与本次 changelog 新版本标题（`## x.y.z`）完全一致；细则见 `references/git-tag.md`。无 bump 的纯重发可不打新 tag。
-- 若 GA workflow 由 tag 触发，第 6 步 push tag 即触发第 7 步发布。
-- **正式环境分支**：只有 `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`。
+- 版本和记录：`references/version-sync.md`、`references/changelog.md`、`references/git-tag.md`。
+- 发布配置：仅需要发布时读取 `references/publish-config.md`，必要时使用 `bash scripts/release_config.sh`。
+- 平台：`references/frontend-deploy.md`、`references/backend-deploy.md`、`references/ios.md`、`references/android.md`、`references/harmony.md`、`references/generic-release.md`。
+
+版本、tag 或发布目标存在歧义时先核实；不可识别时询问。删除或覆盖远端 tag / release 前必须获得用户明确授权。输出各工程的版本、changelog、tag、是否推送和实际发布验证结果。

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

@@ -10,7 +10,7 @@
 ## 版本（通用步，固化）
 
 - `versionName` = 语义版本号，走 `../dwy-semver` 决策 + bump.py。
-- `versionCode` = 单调递增整数，每次发布 +1。
+- 新上传构建的 `versionCode` 遵循渠道及项目的递增要求。
 - 多文件同步见 `version-sync.md`。
 
 ## build / publish（项目步，不写死命令）
@@ -26,7 +26,7 @@
 
 ## changelog / tag / 安全检查 / 监控
 
-- changelog → `changelog.md`（写该项目的 `android/CHANGELOG.md`；工厂里多个项目时每个项目各一份）
-- tag → `git-tag.md`（每次 bump 必打；版本串与 changelog `##` 标题一致）
+- changelog → `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

@@ -4,8 +4,8 @@
 
 ## 版本（通用步，固化）
 
-- 走 `../dwy-semver` 决策 + bump.py；多文件同步见 `version-sync.md`（Python 须同步 `pyproject.toml` 的 `version` 和包 `__init__.py` 的 `__version__`）。
-- 纯重发、仅重跑 workflow、仅补环境配置、仅回滚已有构建时可不 bump。
+- 走 `../dwy-semver` 决策 + bump.py；按 `version-sync.md` 同步工程实际维护的版本来源。
+- 部署新代码必须先完成入口规定的版本、changelog 和 tag 闸门；仅重发或回滚相同已记录产物可复用原版本。
 
 ## build / deploy（项目步，不写死命令）
 
@@ -19,6 +19,6 @@
 
 ## changelog / tag / 监控
 
-- changelog → `changelog.md`（写该项目的 `backend/CHANGELOG.md`；工厂里多个项目时每个项目各一份）
-- tag → `git-tag.md`（每次 bump 必打；版本串与 changelog `##` 标题一致）
+- changelog → `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,75 +1,11 @@
-# 发版时按项目写 CHANGELOG
+# 按工程维护 CHANGELOG
 
-只在发版写。不发版不写、不升版本。
+先识别版本边界：根据构建配置、版本来源、已有 changelog、tag 和项目约定确定独立工程；共享版本的模块遵循仓库既有规则。用户指定范围优先，不将无关改动纳入本次版本。
 
-工厂是这次发版的 git 仓库根。工厂下可以有多个项目。每个项目可以各自有前端和后端。changelog 写在那一端自己的目录里。
+逐工程检查上次对应 tag 后的提交和本次相关未提交变更，分析共享代码对各工程的影响。列出工程、变更、版本来源、changelog 路径、tag 和是否发布。无变更的工程不写空版本；已记录的内容不要重复添加。
 
-## 先列出要写的端
+需要更新的工程各自维护 changelog：优先使用现有路径、分类和语言；没有时在工程目录创建 `CHANGELOG.md`，遵循仓库约定。记录该工程本次实际变更，不混入其他工程。用户要求仅管理版本时也要记录，不以是否发布为条件。
 
-1. 找出项目。一个项目是含有可独立发版的前端和/或后端的目录。常见是 `<项目>/frontend` 与 `<项目>/backend`。仓库根下直接就是这两端时，根就是这一个项目。目录名按仓库实际结构认，不套死 `frontend` / `backend` 这两个词。
-2. 一端算存在：该目录有自己的版本来源（前端看 `package.json` 的 `version`，后端看 `pyproject.toml` 的 `version`），或有该端的应用入口。没有这一端就不写。
-3. 决定哪些端要写：
-   - 用户点名了项目或端：只写点名的。
-   - 没点名：该端目录自上次 release tag 以来有提交才写。没有上次 tag 时，看这次准备发布的提交是否改过该目录。
+每个版本条目的标题必须同时包含明确版本号和 `YYYY-MM-DD` 日期，例如 `## [1.2.3] - 2026-11-02`；版本串与该工程版本来源及 tag 中的版本串一致。日期表示本次版本记录日期，不以实际发布为前提，也不等到发布时再补。禁止使用 `Unreleased`、`[Unreleased]` 或“未发布”等占位标题；即使仓库原格式缺少版本号或日期，本次新增或更新的条目也必须补齐。已有占位条目中属于本次的变更，归入明确版本号和日期的条目，不继续保留为占位记录。按现有分类和语言写清用户可理解的变更；仓库已有可靠生成工具时可复用并检查结果。
 
-```bash
-git log <该端上次 tag>..HEAD --oneline -- <项目>/<端>/
-```
-
-4. 没有提交的端不写、不升版本、不打 tag。
-5. 写之前先列出清单：项目、端、changelog 路径、有没有变更。清单里该写的还没写完，不进入 tag。
-
-该项目下若还有 android / ios / harmony，同样各算一端，不写进前后端的 changelog。
-
-## 落点
-
-- `<项目>/frontend/CHANGELOG.md`
-- `<项目>/backend/CHANGELOG.md`
-
-只有一端的项目只写存在的那一端。不要在工厂根再写一份总表。
-
-## 版本标题格式（与 git tag 对齐）
-
-新版本必须用二级标题，版本串单独成标题，供打 tag 原样取用：
-
-```markdown
-# <包标识>          ← 作为 tag 的包前缀（如 shop-frontend、@acme/api）
-
-## 0.16.1           ← 新版本标题；这一份 changelog 的 tag 版本串必须与此完全一致
-
-### Patch Changes
-
-- ...
-```
-
-约束：
-
-- 标题里只写 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（命令见上）
-3. 按 `feat` / `fix` / `refactor` / `chore` 分组
-4. 写入这一端的 `CHANGELOG.md`，用 `## <新版本号>` 标注
-
-仓库已有自动生成命令（changelogen 等）时优先使用。仍然只覆盖这一端的目录，版本标题仍要满足上面的格式。
-
-写了几份 changelog，就按 `git-tag.md` 各打一个 tag。不要合成一个工厂级 tag。
-
-## 自动执行
-
-changelog 由 AI 生成并写入，不逐步确认。只有 commit 无法归类，或分不清项目边界时才问用户。
-
-## 禁止
-
-- 禁止在工厂根写一份总 CHANGELOG，把多个项目或前端后端混在一起
-- 禁止只写了其中一个项目就进入 tag
-- 禁止把 A 项目的 commit 写进 B 项目
-- 禁止把前端的 commit 写进后端，或反过来
-- 禁止给没有变更的端写一份空版本
-- 禁止 changelog 未写完就进入 tag / 部署
-- 禁止版本标题与这一份即将打的 tag 版本串不一致
+部署新代码前 AI 自动检查目标工程的 changelog 是否覆盖拟部署变更，并与版本和 tag 指向的提交一致；缺失时自动补齐，不逐项要求用户确认。补齐和校验完成前禁止部署。

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

@@ -5,7 +5,7 @@
 ## 版本（通用步，固化）
 
 - 走 `../dwy-semver` 决策 + bump.py；多文件同步见 `version-sync.md`（前端改 `package.json` 的 `version`）。
-- 纯重发、仅重跑 workflow、仅回滚已有构建时可不 bump。
+- 部署新代码必须先完成入口规定的版本、changelog 和 tag 闸门；仅重发或回滚相同已记录产物可复用原版本。
 
 ## build / deploy（项目步，不写死命令）
 
@@ -19,6 +19,6 @@
 
 ## changelog / tag / 监控
 
-- changelog → `changelog.md`（写该项目的 `frontend/CHANGELOG.md`；工厂里多个项目时每个项目各一份）
-- tag → `git-tag.md`（每次 bump 必打；版本串与 changelog `##` 标题一致）
+- changelog → `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

@@ -4,8 +4,8 @@
 
 ## 版本（通用步，固化）
 
-- 走 `../dwy-semver` 决策 + bump.py；多文件同步见 `version-sync.md`（Python 同步 `pyproject.toml` + `__init__.py`，Node 同步 `package.json`）。
-- 纯重发、仅重跑 workflow、仅回滚已有构建时可不 bump。
+- 走 `../dwy-semver` 决策 + bump.py；按 `version-sync.md` 同步工程实际维护的版本来源。
+- 发布新代码必须先完成入口规定的版本、changelog 和 tag 闸门；仅重发或回滚相同已记录产物可复用原版本。
 
 ## build / publish（项目步，不写死命令）
 
@@ -16,13 +16,13 @@
 按缓存 method 分流：
 - `github-action-oidc` → **PyPI/npm 首选**，引 `../dwy-github-action-publish`（OIDC + Trusted Publisher）
 - `github-action` → Cython wheel / Electron / 镜像，引 `../dwy-github-action-publish`
-- `local` → 缓存的本地发包命令（`uv publish` / `pnpm publish` 等）
+- 其他渠道 → 遵循项目已有发布配置和授权；PyPI / npm 发布必须走 GitHub Actions OIDC。
 
 **PyPI/npm 未配置 GA 时按 `publish-config.md` 主动推荐 OIDC。**
 
 ## changelog / tag / 安全检查 / 监控
 
-- changelog → `changelog.md`（单包仓库根目录一份；应用工厂按每个项目的前端/后端分写）
-- tag → `git-tag.md`（每次 bump 必打；版本串与 changelog `##` 标题一致；monorepo 例：`@dwydev/eui@2.2.3`、`create-dwy@0.16.1`）
+- 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

@@ -1,82 +1,7 @@
-# 发版 git tag（强制）
+# 版本 tag
 
-**每次更新版本号都必须打 tag 并推远端。** 无版本 bump 的纯重发 / 仅重跑 workflow / 仅回滚，不打新 tag。
+每个需要更新版本的工程，在版本来源和 changelog 完成后提交对应变更并打 tag。tag 的版本串必须与版本来源和 changelog 标题一致；tag 指向包含本次完整代码、版本和 changelog 的提交。遵循仓库既有命名，多个独立工程使用各自不冲突的 tag，已有约定优先。
 
-## 时机
+打 tag 和推送前检查 tag 是否已存在、指向是否正确，以及推送是否触发 CI、发布或部署。推送由用户授权范围和项目要求决定；推送可能触发发布时，先完成测试、适用的安全检查及部署闸门，且仅在发布已获授权时推送。仅版本管理且推送会触发未经授权发布时，保留本地 tag 并报告。
 
-在第 3 步版本同步 + 第 4 步 changelog 写完、第 5 步安全检查通过之后：
-
-1. 将版本来源文件 + CHANGELOG 一并 commit（若尚未提交）
-2. 按下方规则算出 tag 名
-3. 本地打 tag → push tag 到 origin
-4. 再进入 build / 发布（若 workflow 由 tag 触发，push tag 即触发发布）
-
-```bash
-# 版本与 changelog 已落盘并 commit 后
-git tag <tag>
-git push origin <tag>
-```
-
-## tag 与 changelog 版本对齐（硬规则）
-
-tag 中的**版本串**必须与这一份 CHANGELOG **新版本标题**完全一致，禁止改写。第 4 步写了几份，就各打一个 tag，版本串对应该份标题。
-
-| CHANGELOG 写法 | 取出的版本串 |
-|----------------|-------------|
-| `## 0.16.1` | `0.16.1` |
-| `## 2.2.3` | `2.2.3` |
-| `## 1.0.0-rc.1` | `1.0.0-rc.1` |
-
-禁止：
-
-- changelog 写 `## 0.16.1`，tag 打成 `v0.16.1` / `0.16.1.0` / `0.16`（格式不一致）
-- tag 版本与 `package.json` / `pyproject.toml` 等来源文件不一致
-- 未写 changelog 新版本标题就打 tag
-
-## tag 全名拼法
-
-先取 changelog 版本串 `VER`，再按仓库惯例拼全名：
-
-| 场景 | 规则 | 例 |
-|------|------|-----|
-| monorepo 多包 / 多平台 | `{包标识}@{VER}`；包标识优先取该 CHANGELOG 顶部 H1（去掉 `# `），否则取 `package.json` 的 `name` | CHANGELOG H1 `# create-dwy` + `## 0.16.1` → `create-dwy@0.16.1`；H1 `# @dwydev/eui` + `## 2.2.3` → `@dwydev/eui@2.2.3` |
-| 单包仓库且历史 tag 已有固定前缀 | 沿用历史前缀 + `VER`（仅当前缀不篡改 VER 本身时） | 历史 `v1.2.0` 且 changelog 为 `## 1.3.0` 时，若项目约定 `v` 前缀且 VER 仍完整出现 → 须在本仓库已有 tag 惯例中确认；**优先保证 VER 与 changelog 一致** |
-| 单包仓库无历史惯例 | 直接用 `VER` | changelog `## 1.0.0` → tag `1.0.0` |
-
-**冲突裁决**：若「历史 `v` 前缀」与「changelog 无 `v`」冲突，以 **changelog 标题里的版本串** 为准拼 tag（monorepo 用 `包@VER`，单包用 `VER`），不要为了凑 `v` 前缀改掉 VER。仓库若已有 workflow 写死 `v*` 触发，同步改 workflow 或 changelog 标题约定，二者必须一致。
-
-打 tag 前自检：
-
-```bash
-# VER 必须等于 changelog 最新 ## 标题
-# 包来源文件 version 字段必须等于 VER
-git tag -l | head   # 对照历史命名是否 monorepo 包前缀
-```
-
-## 推送与触发
-
-- 必须 `git push origin <tag>`，只打本地 tag 不算完成
-- method 为 `github-action` / `github-action-oidc` 且 workflow `on.push.tags` 时：push tag 即触发 CI，不必再另起发布命令
-- method 为 local / testflight / maven 等：先 push tag，再跑缓存的 `publish_cmd`（或按项目既有顺序，但 tag 不可省）
-
-## 重发 / 删 tag
-
-远端已有错误 tag 需要覆盖时：
-
-1. **先确认用户允许**删除远端 tag / release
-2. 再删远端 + 本地，重打同名 tag 推送
-
-```bash
-git push origin :refs/tags/<tag>
-git tag -d <tag>
-git tag <tag>
-git push origin <tag>
-```
-
-## 禁止
-
-- 禁止版本号已 bump 却不打 tag
-- 禁止 tag 版本串与 changelog 新版本标题不一致
-- 禁止 tag 与版本来源文件不一致
-- 禁止未 push 远端就当发版完成
-- 禁止未确认用户就删除远端已有 tag / release
+部署新代码必须使用包含该代码的版本 tag 对应提交或其已验证产物；不能用旧 tag 掩盖新增代码。重发或回滚完全相同的已记录版本和产物，可复用原 tag，无须重复打 tag。不得未经用户明确授权删除或覆盖远端 tag / release。

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`；工厂里多个项目时每个项目各一份）
-- tag → `git-tag.md`（每次 bump 必打；版本串与 changelog `##` 标题一致）
+- changelog → `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

@@ -10,7 +10,7 @@
 ## 版本（通用步，固化）
 
 - 语义版本号 `CFBundleShortVersionString`，走 `../dwy-semver` 决策 + bump.py。
-- **build 号 `CFBundleVersion` = 时间戳 `yyyyMMddHHmm` 12 位**（如 `202606231430`，`date +%Y%m%d%H%M`），每次发布重新生成，单调递增。app 和 SDK 都适用。
+- 构建号 `CFBundleVersion` 遵循项目及发布渠道约定；重新上传构建时满足渠道的递增要求。
 - 多文件同步见 `version-sync.md`。
 
 ## build / publish（项目步，不写死命令）
@@ -27,7 +27,7 @@
 
 ## changelog / tag / 安全检查 / 监控
 
-- changelog → `changelog.md`（写该项目的 `ios/CHANGELOG.md`；工厂里多个项目时每个项目各一份）
-- tag → `git-tag.md`（每次 bump 必打；版本串与 changelog `##` 标题一致）
+- changelog → `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-publish/references/publish-config.md

@@ -1,6 +1,6 @@
 # 发布方式缓存 + 命令探测
 
-发布方式与 build/publish 命令**因项目而异，不写死**。按应用目录探测 → 问 → 缓存复用。
+仅在需要发布时探测项目已有发布方式和 build/publish 命令；根据项目上下文及授权判断，存在歧义时询问。缓存仅作为线索，执行前核实现有配置和权限。
 
 ## 缓存机制
 
@@ -17,7 +17,7 @@
    - 未命中（首次进入该目录）→ 走第 3 步
 3. 首次配置：
    - 探测真实命令（见下方探测线索）
-   - AskUserQuestion 问发布方式（见下方各平台候选）
+   - 按项目现有配置判断发布方式；无法确定时询问
    - 检查对应配置就绪（GA workflow 是否存在 / TestFlight 凭据线索 / maven·pod publish 配置）
    - `release_config.sh set <root> <rel_dir> <platform> <method> <channel> <configured> [build_cmd] [publish_cmd] [verify_cmd] [cmd_source]`
    - 提醒把 `.dwy/` 加进 `.gitignore`
@@ -51,7 +51,7 @@
 | harmony（har / har app） | `ohpm`(推荐) / `github-action` / `local` |
 | frontend | `github-action`(CI，推荐 OIDC) / `local` |
 | backend | `github-action`(CI，推荐 OIDC) / `local` |
-| generic — PyPI/npm | `github-action-oidc`(**推荐**，无静态凭据、符合团队准则) / `local` |
+| generic — PyPI/npm | `github-action-oidc`（必须，无长期静态发布凭据） |
 | generic — Cython wheel | `github-action`(cibuildwheel) / `local` |
 | generic — Electron | `github-action`(多平台 runner) / `local` |
 | generic — Docker/二进制 | `github-action` / `local` |
@@ -62,4 +62,4 @@ PyPI / npm 且未配置 GA 时，**主动推荐 `github-action-oidc`**（OIDC Tr
 
 - 给 workflow 模板：见 `../dwy-github-action-publish`（Python wheel / 纯包 OIDC）。
 - 给 Trusted Publisher 网页配置步骤：PyPI/npmjs 后台绑定 repo + workflow 文件名 + environment。
-- 用户仍可选 `local`（`uv publish` / `pnpm publish` 等），按其选择缓存。
+- 按仓库要求通过 GitHub Actions OIDC 发布，不使用本地命令或长期静态发布凭据。

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

@@ -1,6 +1,6 @@
 # 版本号多文件同步
 
-版本号定好后，**同一次发布的所有版本来源文件必须改到完全一致**。一个技术栈往往有多处版本声明，漏改一处就会导致包内版本不一致、构建产物版本错乱。
+版本号定好后，**同一工程中代表该版本的来源文件必须一致**；不同工程的独立版本不要求相同。先核对项目实际版本来源，不假设所有技术栈都存在表中全部文件。
 
 ## 各技术栈版本来源清单
 
@@ -9,14 +9,14 @@
 | Python | `pyproject.toml` + 包 `__init__.py` | `version` / `__version__` |
 | Node/Vue | `package.json` | `version` |
 | Android | `build.gradle(.kts)` | `versionName`（语义号）+ `versionCode`（整数，每次发布递增） |
-| iOS | `Info.plist` 或 `project.pbxproj` | `CFBundleShortVersionString`（语义号）+ `CFBundleVersion`（build 号，见 `sdk-ios.md`） |
+| iOS | `Info.plist` 或 `project.pbxproj` | `CFBundleShortVersionString`（语义号）+ `CFBundleVersion`（build 号，见 `ios.md`） |
 | 鸿蒙 | `oh-package.json5` | `version` |
 
 ## 规则
 
-- **Python**：`pyproject.toml` 的 `version` 与包 `__init__.py` 的 `__version__` 两处必须一致。
-- **Android**：`versionName` 用语义版本号；`versionCode` 是单调递增整数，与语义号无关，每次发布 +1。
-- **iOS**：`CFBundleShortVersionString` 用语义版本号；`CFBundleVersion`（build 号）用时间戳，规则见 `sdk-ios.md`。
+- **Python**：项目同时维护 `pyproject.toml` 的 `version` 与包 `__init__.py` 的 `__version__` 时，两处必须一致。
+- **Android**：`versionName` 用语义版本号；新上传构建的 `versionCode` 遵循渠道及项目的递增要求。
+- **iOS**：`CFBundleShortVersionString` 用语义版本号；`CFBundleVersion`（build 号）规则见 `ios.md`。
 - 改完后用 grep 全仓库扫一遍旧版本号，确认无遗漏：
 
 ```bash
@@ -25,6 +25,6 @@ grep -rn "<旧版本号>" --include=pyproject.toml --include=package.json --incl
 
 ## 禁止
 
-- 禁止只改一处版本来源就发布（如只改 `pyproject.toml` 漏改 `__init__.py`）
+- 禁止漏改项目实际维护的版本来源（如已有的 `__init__.py` 版本）
 - 禁止用会自动 commit 的版本命令（`npm version` / `bumpversion` 等），直接编辑文件，保持提交边界可控
-- 禁止 `versionCode` / `CFBundleVersion` 不递增就重发（应用商店会拒）
+- 重新上传构建时遵循对应应用商店的构建号要求；直接重部署已记录的相同产物可复用原构建号。

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

@@ -87,13 +87,9 @@ 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` 充当正式分支。
+按用户意图和目标仓库的版本及发布约定判断正式版或预发布版，不根据分支判断。测试版本按项目惯例使用 `beta`、`rc` 等标识，正式版本不带预发布标识。判断不明确时询问用户。
 
 ## 算出具体版本号
 
@@ -128,7 +124,7 @@ python3 scripts/bump.py 2.0.0-rc.1 major             # -> 2.0.0  (预发布转
 ## 与 dwy-publish 的边界
 
 - **dwy-semver**（本 skill）：只回答"该升哪一位、新号是多少"
-- **dwy-publish**：拿到版本号后执行发版流程（测试 → bump 版本文件 → changelog → 安全检查 → **打 tag（版本串与 changelog 标题一致）** → build → publish）
+- **dwy-publish**：管理工程版本、changelog 和 tag；是否构建和发布按项目上下文及用户授权判断。
 
 发版时若不确定版本号，先用本 skill 决策，再交给 dwy-publish 落地。
 

package/templates/ai-tools/skills//351/200/232/347/224/250/dwy-development-review/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: dwy-development-review
+description: Use when starting or completing code development, implementing features, fixing bugs, refactoring, or preparing a code delivery; also when architecture review, module boundaries, or reusable capability extraction is requested. 每次代码开发、修复、重构和交付前均适用；纯咨询、翻译和文案修改不触发。
+---
+
+# 开发、审查与复用闭环
+
+每次代码开发开始时加载，以功能成功交付为首要目标，自主完成开发、验证、审查与必要修复，再集中输出结果和确实需要用户确认的事项。识别架构、规范和模块边界问题，积累有证据的复用能力；允许结论为「无需抽取」。
+
+本 Skill 只定义通用流程，不依赖特定 CLI、模型、语言、框架或其他 Skill。自动加载取决于宿主的技能发现能力；本文件本身不是强制执行器，也不授予额外权限。
+
+## 入口与决策
+
+- **开发任务**：从第 1 步走完整闭环，不把计划、候选方案或测试通过当作最终交付。
+- **单独审查**：确认范围后直接进入第 4 步，不要求先开发或测试全绿。只读审查已有实现，说明验证缺口；用户未要求修复时不改代码。
+- 根据需求、项目约定、已有实现及实际运行环境，自行决定常规实现、检查与排障方式。环境问题先检查现有工具、配置和可用替代，不将能自行解决的问题交还用户。
+- 目标含部署时，核实已授权的目标环境、运行版本和部署条件，完成必要部署及运行时验收。持有凭据或发现可用服务器不等于获得部署授权；本地测试不能替代目标环境的功能成功。
+- 已有授权覆盖的下一步直接执行，不重复询问。遇到无法安全推断的关键条件或确需额外授权的动作，先完成其余可独立交付的工作，再只询问该具体阻断；不能先执行越权动作再补确认。
+
+## 1. 确定范围
+
+- 读取当前项目规则、需求和验收条件，确认工作目录、分支与已有改动。纯分析请求只输出分析，不进入开发。
+- 列出本次涉及的实现、调用方、测试、配置、迁移、导出和文档；无关文件保留原样。发现需求或授权边界不清时先解决该问题。
+- 定义可验证的成功标准与简短步骤，先分析依赖和共享资源，再选择直接执行、工具批处理、串行派发或并行子代理；只有实际收益超过派发、通信、集成和返工成本时才拆分。
+- 确认任务代码基线。有 Git 时核对基准提交及任务路径的现有差异，无 Git 时核对任务文件；后续新增、删除和未跟踪文件也计入范围。按审查指南决定记录粒度，不为小改动机械生成全套摘要。
+
+多步骤任务有派发收益，或长任务需要阶段续接时，读取 [references/delegation-guide.md](references/delegation-guide.md)。主代理保留目标、接口决策、用户交互、集成及最终验收责任；子代理承担边界明确的执行工作。默认只传必要上下文、只回收摘要和证据；宿主支持且确需历史决策时才继承会话，后续变化另行同步。
+
+## 2. 查找与开发
+
+- 先检索项目已有实现、能力目录及复用候选，再查标准库、平台能力、已安装依赖及匹配工具；跨项目只检索已授权的仓库或目录，不扫描无关位置。核实候选的实际实现与版本，不能把待抽取建议当作现成能力。
+- 按项目规则核实新工具的来源、权限、数据去向和维护成本；不因本 Skill 自动安装依赖、连接账户或上传代码。
+- 按项目测试约定开发；缺陷修复先建立重现证据，非平凡行为补充有意义的测试。只实现本次需求，不为未来复用提前扩展接口。
+
+## 3. 验证当前实现
+
+执行项目要求的测试、类型检查、静态检查与构建；按影响范围选择检查，项目明确要求的检查不得省略。记录命令、结果、跳过原因及对应的任务代码快照。
+
+检查后代码、测试或配置发生变化，相关旧结果失效。无法运行、超时和环境故障均记录为「未完成」，不能当作通过；区分源码、单测、真实设备、外部服务与部署验收。
+
+## 4. 执行审查
+
+读取 [references/review-guide.md](references/review-guide.md)，按其中的审查维度与输出契约执行。开发任务通常先完成必需检查；环境阻断验证时，仍完成可执行的审查，并将受影响验收项标为未完成，不伪造整体通过。
+
+有可用且获授权的独立审查能力时，给审查者需求、规则、变更快照和检查证据，让其自行读取实现及影响范围，不传开发者的自我评价。否则重新读取最终代码进行自审，并注明自审。审查只读，不修改当前工作树、索引、分支或 HEAD；审查者不再递归启动审查者。
+
+## 5. 修复与复审
+
+- 主执行者先复核问题证据；已授权范围内的明确缺陷直接做最小修复。存在分歧时核对调用链或测试，不盲目接受建议。
+- 修复后重跑受影响检查并复审变更及其影响范围。测试通过不能替代架构审查，架构建议也不能替代测试。
+- 不按固定轮数停工；只要有明确可执行的下一步且持续取得进展，就自主修复、复测和复审直到满足验收。相同失败反复出现时根据证据调整方案，不重复无效尝试；只有排查后仍无法自行解除的外部阻断、额外授权或用户停止要求才中止相应工作，并报告真实状态。
+
+## 6. 沉淀与交付
+
+- 记录粒度按审查指南选择，优先使用项目既有位置。需要完整报告且没有约定时，写入 `.dwy/reviews/<task-id>/review.md`；有复用候选时更新 `.dwy/reuse-candidates.md`。`<task-id>` 使用本任务稳定的短标识，续跑复用原记录，不覆盖其他任务。
+- 记录只绑定任务代码、测试和配置；更新审查记录本身不会使验收失效。无文件写权限时返回同样内容并注明尚未落盘，不宣称已沉淀。
+- 候选先查重，保留来源与证据；迁移落地后更新能力目录的实际入口、调用方和验证结果，让后续任务能够检索使用。非本轮必需的抽取记录为后续候选，不阻塞功能交付。沉淀规则遵循项目现有约定，不擅自修改全局配置、个人记忆或无关项目。
+- 只有当前任务快照的必需检查、审查及需求包含的目标环境验收通过，才报告功能交付成功。先完成已授权的实施与验证，再输出结果、环境证据、剩余限制，以及集中列出的交付验收确认或可选后续决策；能自行决定的事项不列为待确认，没有则写「无需额外确认」。

package/templates/ai-tools/skills//351/200/232/347/224/250/dwy-development-review/references/delegation-guide.md

@@ -0,0 +1,46 @@
+# 子代理派发与长任务续接
+
+## 先判断收益和依赖
+
+复用宿主已有的子代理、消息和状态能力，不引入新调度框架。工具未提供这些能力时由主代理执行，不假装已派发。简单任务直接完成；独立查询先考虑工具批处理；独立且工作量足够的任务再派发。并发数服从宿主实际容量和资源条件，不为占满名额而派发。
+
+| 工作 | 并行条件 |
+| --- | --- |
+| 独立文档调研、调用链追踪、不同根因的日志分析 | 各自可独立产出，范围明确；没有共享写入。 |
+| 不同模块开发 | 接口和行为契约已确定，文件归属清楚，配置、锁文件、数据库及构建资源不会互相干扰。 |
+| 测试与验证 | 测试数据、端口、设备、缓存及构建目录可独立使用；争用可写资源时串行或使用项目已有隔离方式。 |
+| 独立审查 | 被审查快照稳定，只读且上下文独立；审查时仍被修改的范围必须在集成后重新审查。 |
+| 契约设计、公共配置、依赖锁、数据库迁移、集成与部署 | 先明确责任人与顺序；不能因文件不同就默认可并行。共享工作区的 Git 写操作由主代理统一执行。 |
+
+先解决依赖链上的前置任务，再派发后续实现。没有接口契约时，可以并行调研，不能让各模块自行猜接口。遵守项目分支和工作目录规则，不为并行擅自另建分支或 worktree。主代理可同时推进独立工作，不重复子代理正在做的同一任务。
+
+## 派发最小上下文
+
+每个子任务说明以下内容，缺少的信息由主代理先查证或明确为待调查项：
+
+- **目标与验收**：本任务需要交付的具体行为与检查，关联总目标的哪一部分。
+- **范围与归属**：准确的仓库和工作目录、可改文件、只读范围、已有改动；不得覆盖其他人的修改。
+- **输入与契约**：相关需求、项目规则、入口位置、接口约定、当前快照和已确认事实；使用路径和定向摘录，不倾倒完整日志与历史。
+- **依赖与资源**：前置任务、共享资源及其责任人，是否需要等待；涉及环境时写明实际目标，不由子代理自行切换环境。
+- **执行边界**：允许读写、可执行的检查及原任务授权范围；子代理不因收到任务而获得额外外部操作权限，也不自行递归派发。
+- **返回内容**：结论、实际改动路径、检查命令与结果、阻断或待决策项；较长产物放文件并返回路径，原始日志只保留定位问题所需片段。
+
+默认新建独立上下文并传上述信息。只有任务确实依赖难以准确摘取的历史决策、且宿主支持时才继承必要历史；继承的是启动时的上下文，不代表后续自动同步。它不会删除主代理已有上下文，也不保证降低总 token 消耗；节省来自把后续探索和执行细节留在子代理侧。
+
+审查任务传需求、规则、代码快照与验证证据，不传开发者自我评价。主代理接收摘要后按风险核实关键代码、接口和证据；不能仅凭子代理说「通过」就判定整体成功，也不必重复读取全部日志。
+
+## 协调与集成
+
+- 用户的新要求由主代理解释并检查影响，尽快通知受影响的子代理；接口或范围改变时让旧任务暂停相应修改，更新契约后再继续。旧契约下的产物不能直接合入。
+- 子代理发现需要修改其他责任人的文件、公共接口或共享配置时，报告具体依赖，由主代理协调归属与顺序；可独立完成的部分继续，不私自扩大修改范围。
+- 共享工作区的修改即时可见，不能把“完成”消息当作代码才开始出现的时间。集成前核对在途任务和实际差异，避免测试读到尚未完成的修改。
+- 子任务完成后按依赖顺序集成，检查冲突及调用方，再验证最终组合的代码。子任务测试通过不能替代集成验收；沿用主 Skill 的持续修复和交付标准。
+- 主代理持续处理交互。用户询问状态时简要回答后继续；纠正和约束同步到相关任务，只有明确取消或替换目标时才放弃原目标。
+
+## 长任务的最小状态记录
+
+多阶段、可能跨会话或有较长等待的任务，复用项目已有计划或任务记录；没有约定时写入 `.dwy/tasks/<task-id>/progress.md`。短任务不额外建状态文件。
+
+只记录可恢复执行所需的信息：目标与验收条件、最新接口决策、子任务状态和责任范围、产物路径及对应快照、已执行检查和结果、当前阻断与下一步。代理标识或后台进程只作为定位线索，不记录凭据或整段会话。
+
+在阶段完成、接口或需求变更、出现阻断以及交接时更新记录。恢复时先读记录，再核对实际工作目录、代码、环境、代理与后台任务状态，确认哪些产物和检查仍有效；已经完成且仍有效的工作不重复做，失效部分重新验证。不假设宿主会在会话结束后继续运行代理、自动唤醒或自动恢复；不具备持续运行能力时留下明确的下一步并如实说明。