create-dwy 0.21.0 → 0.23.0

package/src/sync.js

@@ -3,6 +3,7 @@ import path from 'path'
 import { isCancel } from '@clack/prompts'
 import { tabMultiselect } from './tab-multiselect.js'
 import { chalk, PACKAGE_ROOT } from './utils.js'
+import { linkSkill, ensureSharedSkills, removeSkillEntry } from './skill-store.js'
 
 const CATEGORIES = [
   { key: 'skills', label: 'Skills' },
@@ -194,8 +195,9 @@ export function buildCategoryTabs(items, type) {
     if (!groups.has(category)) groups.set(category, [])
     groups.get(category).push({
       value: item.name,
-      label: item.name,
+      label: item.label || item.name,
       description: item.description,
+      disabled: item.disabled,
       type,
     })
   }
@@ -209,21 +211,21 @@ export function buildCategoryTabs(items, type) {
 }
 
 /**
- * 顺序选择 Skills、Rules；Enter 进入下一类，不再提供回退或重选菜单。
- * 完整同步默认启用全部模板 Hooks；仅 Skills 模式不得写入其他配置。
+ * 只展开调用方点名的内容，Enter 进入下一类，不提供回退菜单。
  * 取消返回 null，调用方必须终止同步。
  *
  * @param {object} scans
  * @param {{ skills: Iterable<string>, rules: Iterable<string> }} existing
- * @param {{ skillsOnly?: boolean }} [opts]
+ * @param {{ skillsOnly?: boolean, types?: string[] }} [opts]
  */
-export async function interactiveSelect(scans, existing, { skillsOnly = false } = {}) {
-  const selected = { skills: [], rules: [], commands: [], hooks: skillsOnly ? [] : scans.hooks }
-  for (const { key, label } of skillsOnly ? CATEGORIES.slice(0, 1) : CATEGORIES) {
+export async function interactiveSelect(scans, existing, { skillsOnly = false, types } = {}) {
+  const activeTypes = types || (skillsOnly ? ['skills'] : ['skills', 'rules', 'hooks'])
+  const selected = { skills: [], rules: [], commands: [], hooks: activeTypes.includes('hooks') ? scans.hooks : [] }
+  for (const { key, label } of CATEGORIES.filter(item => activeTypes.includes(item.key))) {
     const tabs = buildCategoryTabs(scans[key], key)
-    const availableNames = new Set(scans[key].map(item => item.name))
+    const availableNames = new Set(scans[key].filter(item => !item.disabled).map(item => item.name))
     const names = await tabMultiselect({
-      message: `选择 ${label}`,
+      message: `选择 ${label}（取消已有勾选将移除当前范围的托管项）`,
       tabs,
       initialValues: [...existing[key]].filter(name => availableNames.has(name)),
       required: false,
@@ -243,8 +245,7 @@ export function logAction(label, color = 'green', prefix = '✓') {
 async function copyItems(items, targetDir) {
   for (const item of items) {
     const dest = path.join(targetDir, item.type + 's', item.name)
-    await fs.ensureDir(path.dirname(dest))
-    await fs.copy(item.sourcePath, dest, { overwrite: true, filter: copyFilter(item.sourcePath) })
+    await linkSkill({ skill: item, dest, backupRoot: path.join(targetDir, '..', '.dwy', 'skill-backups') })
     logAction(`${item.type}s/${item.name}`)
   }
   return items.length
@@ -278,7 +279,11 @@ async function removeUnselected(typePlural, existingNames, selectedNames, templa
     // 项目独有(模板未提供过)的条目永不删除,保留用户自定义
     if (!templateNames.has(name)) continue
     const target = path.join(targetDir, typePlural, name)
-    await fs.remove(target)
+    if (typePlural === 'skills') {
+      await removeSkillEntry({ dest: target, backupRoot: path.join(targetDir, '..', '.dwy', 'skill-backups') })
+    } else {
+      await fs.remove(target)
+    }
     logAction(`${typePlural}/${name}`, 'red', '×')
     count++
   }
@@ -400,6 +405,9 @@ export async function syncClaude({
   projectDir,
   global = false,
   selected,
+  homeDir,
+  sharedSkills,
+  syncTypes = ['skills', 'rules', 'hooks'],
   staleRemovals = {},
 } = {}) {
   const sourceDir = sourceDirOverride || await resolveSourceDir()
@@ -455,16 +463,23 @@ export async function syncClaude({
   let syncedCount = 0
   let removedCount = 0
 
-  syncedCount += await copyItems(syncedSelection.skills, projectTargetDir)
-  syncedCount += await syncSettings(sourceDir, projectTargetDir, selectedHookNames, global)
-  syncedCount += await copyHooks(syncedSelection.hooks, projectTargetDir)
+  if (syncTypes.includes('skills')) {
+    const skills = sharedSkills
+      ? sharedSkills.filter(skill => selectedNames('skills').has(skill.name))
+      : await ensureSharedSkills({ skills: syncedSelection.skills, homeDir })
+    syncedCount += await copyItems(skills, projectTargetDir)
+  }
+  if (syncTypes.includes('hooks')) {
+    syncedCount += await syncSettings(sourceDir, projectTargetDir, selectedHookNames, global)
+    syncedCount += await copyHooks(syncedSelection.hooks, projectTargetDir)
+  }
 
   const skillTemplateNames = new Set([...scans.skills.map(s => s.name), ...approvedStaleSkills])
   const ruleTemplateNames = new Set([...scans.rules.map(r => r.name), ...approvedStaleRules])
   const hookTemplateNames = new Set([...scans.hooks.map(h => h.name), ...approvedStaleHooks])
-  removedCount += await removeUnselected('skills', existing.skills, new Set(syncedSelection.skills.map(s => s.name)), skillTemplateNames, projectTargetDir)
-  removedCount += await removeUnselected('rules', existing.rules, new Set(), ruleTemplateNames, projectTargetDir)
-  removedCount += await removeUnselected('hooks', existing.hooks, selectedHookNames, hookTemplateNames, projectTargetDir)
+  if (syncTypes.includes('skills')) removedCount += await removeUnselected('skills', existing.skills, new Set(syncedSelection.skills.map(s => s.name)), skillTemplateNames, projectTargetDir)
+  if (syncTypes.includes('rules')) removedCount += await removeUnselected('rules', existing.rules, new Set(), ruleTemplateNames, projectTargetDir)
+  if (syncTypes.includes('hooks')) removedCount += await removeUnselected('hooks', existing.hooks, selectedHookNames, hookTemplateNames, projectTargetDir)
 
   console.log(chalk.blue(`\nDone! ${syncedCount} synced${removedCount > 0 ? `, ${removedCount} removed` : ''}.`))
   console.log(chalk.gray(`  Project config → ${projectTargetDir}`))

package/src/tab-multiselect.js

@@ -72,8 +72,8 @@ function symbol(state) {
  */
 export function tabSelectionStats(tab, selectedValues) {
   const set = selectedValues instanceof Set ? selectedValues : new Set(selectedValues)
-  const total = tab.options.length
-  const selected = tab.options.filter(option => set.has(option.value)).length
+  const total = tab.options.filter(option => !option.disabled).length
+  const selected = tab.options.filter(option => !option.disabled && set.has(option.value)).length
   return { selected, total }
 }
 
@@ -211,7 +211,8 @@ class TabMultiSelectPrompt extends Prompt {
   constructor(opts) {
     super(opts, false)
     this.tabs = opts.tabs
-    this.value = [...(opts.initialValues ?? [])]
+    const selectable = new Set(this.tabs.flatMap(tab => tab.options.filter(option => !option.disabled).map(option => option.value)))
+    this.value = (opts.initialValues ?? []).filter(value => selectable.has(value))
     this.cursors = this.tabs.map(() => 0)
     this.tabIndex = firstTabWithSelection(this.tabs, this.value)
     this.on('cursor', (action) => this.#onCursor(action))
@@ -248,7 +249,7 @@ class TabMultiSelectPrompt extends Prompt {
   /** Space：只动光标那一条。 */
   toggleValue() {
     const option = this.currentOptions[this.cursor]
-    if (!option) return
+    if (!option || option.disabled) return
     const selected = this.value.includes(option.value)
     this.value = selected
       ? this.value.filter(value => value !== option.value)
@@ -257,7 +258,7 @@ class TabMultiSelectPrompt extends Prompt {
 
   /** a：当前 Tab 全选或全不选。 */
   toggleAllCurrentTab() {
-    const tabValues = this.currentOptions.map(option => option.value)
+    const tabValues = this.currentOptions.filter(option => !option.disabled).map(option => option.value)
     this.value = toggleTabValues(this.value, tabValues)
   }
 }
@@ -384,6 +385,7 @@ export function tabMultiselect(opts) {
             label: opt.label ?? String(opt.value ?? ''),
             selected: selected.includes(opt.value),
             active,
+            disabled: opt.disabled,
           }),
         })
 

package/templates/ai-tools/AGENTS.md

@@ -2,7 +2,7 @@
 
 ## 输出完整性要求
 
-- **文件路径**：写出从仓库根开始的完整相对路径（如 `frontend/eui/src/components/input/EInput.vue`）。不要只写文件名。不要把本机绝对路径写进规则、代码、文档或提交说明。
+- **文件路径**：对话回复中使用完整绝对路径，并提供可点击的文件链接；不要只写文件名或相对路径。写入仓库的规则、代码、文档和提交说明仍使用从仓库根开始的完整相对路径，不写本机绝对路径。
 - **服务地址**：写出完整 URL，包含协议、主机、端口和路径（如 `http://localhost:8000/api/users`）。
 - **数据库连接串**：说明它来自哪个环境变量或配置项。回复、日志、示例里不写密码和 token。需要示意时用占位符，如 `postgresql+asyncpg://USER:PASSWORD@localhost:5432/DBNAME`。
 

package/templates/ai-tools/CHANGELOG.md

@@ -52,6 +52,12 @@
 
 ---
 
+## 0.32.0 — 2026-10-29
+
+### Changed
+- `skills/发布发版/dwy-publish`：按工程识别变更并维护版本、changelog 和 tag；部署新代码前自动补齐并校验三者与部署提交，按项目上下文判断发布方式。
+- `skills/发布发版/dwy-semver`：按版本和发布用途判断正式版或预发布版，不根据分支判断。
+
 ## 0.31.0 — 2026-10-10
 
 ### Changed

package/templates/ai-tools/VERSION

@@ -1 +1 @@
-0.31.0
+0.32.0

package/templates/ai-tools/skills/DolphinDB/dwy-dolphindb/references/official/progr/sql/createExternalTable.md

@@ -108,8 +108,8 @@ select t.name from t where t.id > 200 limit 50
 
 ```dolphindb
 loadPlugin("aws")
-aws_cfg = dict(["filePath", "region", "bucket", "accessId", "secretKey"], ["demo.csv.gz", 'cn-north-1', 'tests3func', 'AKIAXTOOQXTLU44HF75E', 
-'S0OzvoQnlmFRSn1RzhK5b0yY4IpbrvYTyF5bwtyw'])
+aws_cfg = dict(["filePath", "region", "bucket", "accessId", "secretKey"], ["demo.csv.gz", 'cn-north-1', 'tests3func', 'YOUR_AWS_ACCESS_KEY_ID',
+'YOUR_AWS_SECRET_ACCESS_KEY'])
 t = createExternalTable("test","s3", aws_cfg,`Open`High`OpenInt, [DOUBLE, DOUBLE, INT]);
 select count(*) from t where Open > 0.5 and High < 0.6 limit 1;
 ```

package/templates/ai-tools/skills/DolphinDB/dwy-dolphindb/references/official/tools/superset.md

@@ -60,7 +60,7 @@ Superset 进行可视化数据分析。
 `rand(33..126, 32).concat("").base64Encode()`。
 
 ```dolphindb
-echo "SECRET_KEY = 'cIgiAjJyZoxb4FfPzxQ8CdLJa+afcA5m+r3ezwe7XGzJ/Qj1VQWnGHRU'" > superset_config.py
+echo "SECRET_KEY = 'YOUR_RANDOM_SUPERSET_SECRET_KEY'" > superset_config.py
 ```
 
 配置环境变量并初始化 Superset。

package/templates/ai-tools/skills/DolphinDB/dwy-dolphindb/references/official/tutorials/Migrate_data_from_InfluxDB_to_DolphinDB.md

@@ -111,7 +111,7 @@ InfluxDB 2.0 中存储时间类型数据，采用的是带有时区信息的 RFC
               "org": "zhiyu"
             }
           ],
-          "token": "GLiPjQFQIxzVO0-atASJHH4b075sTlyEZGrqW20XURkelUT5pOlfhi_Yuo2fjcSKVZvyuO00kdXunWPrpJd_kg==",
+          "token": "YOUR_INFLUXDB_TOKEN",
           "range": [
             "2007-08-09"
           ]

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 发布，不使用本地命令或长期静态发布凭据。