release-pluginlisted

# 发布 DooTask 单插件 DooTask 插件靠 **推送 tag** 触发 `.github/workflows/release.yml`：（多架构）构建镜像推 Docker Hub + 打包发布到 DooTask 应用商店。常规 push / PR 不发布，光 `git tag` 不 push 也不会。 单插件仓库**有两种版本目录约定**，套错会踩 CI 打包 / 重命名的坑（最典型：对占位目录型仓库按版本号新建目录，会让 runner 里的 `mv` 直接失败）。所以**发布前第一步必须判定本仓库属于哪种**。 ## 第一步：判定仓库属于哪种结构 在仓库根执行 `ls`，按下表判定（互斥）： | 仓库根看到 | 模型 | tag 形式 | 详细流程 | |---|---|---|---| | 有 `dootask-plugin/` 目录，其下是固定占位目录 `version/` + `config.yml`（根目录是应用源码工程，发布载荷隔离在 `dootask-plugin/`） | **B 占位目录型（工程仓库型）** | 纯数字 `0.2.0` | [references/type-B-placeholder.md](references/type-B-placeholder.md) | | 根直接有 `config.yml` + **数字命名的真实版本目录**（`0.1.0/`）+ `src/`，无 `dootask-plugin/` | **A 真实版本目录型（扁平型）** | 纯数字 `0.2.0` | [references/type-A-flat.md](references/type-A-flat.md) | > 已知归类：**A** = crm（也是 `dootask:create-plugin` 脚手架生成新插件的标准布局）；**B** = kpi、asset-hub、memos、mcp。遇到新仓库按上表**现场判定**，别套用这条记忆。 > > 例外：若仓库根**并列多个插件目录**（monorepo，如 `system-plugins` 的 office/drawio/…，tag 形如 `<插件>/<版本>`），**不属本技能**，用该仓库 `.claude/skills/` 里自带的 release 技能。 **判定后读对应 references 文件，按其分步流程执行。** 下面是两型共有的铁律与规范。 ## 共有铁律 1. **Tag 不带 `v` 前缀。** workflow 监听 `tags: '*'`，带 `v` 也会触发，但 Docker 镜像 tag 由 `type=ref,event=tag` 取原始 ref 名——推 `v0.2.0` 会得到镜像 tag `v0.2.0`，破坏排序、且和 AppStore / compose 的版本对不上。 2. **只有推送 tag 才触发发布。** 普通 push / PR 不跑发布 workflow；光 `git tag` 不 push 也不会。 3. **AppStore 版本号只增不重复。** 重发只能递增（`0.1.9` → `0.1.10`）。误推的 tag 删了也撤不回已发布的 AppStore 版本。 4. **发布公开且不可逆。** 推 tag 前**必须和用户确认版本号与 CHANGELOG**；常规 git 操作（提交、推分支）可自行判断。 5. **依赖 Repository Secrets**（仓库 Set