refactor!: VelaShell.PluginSdk.Build 搬去 velashell-plugin-sdk,本仓库只发 vela-plugin

.github/workflows/ci.yml

@@ -1,7 +1,11 @@
-# vela-plugin 与 VelaShell.PluginSdk.Build 的日常验证。
+# vela-plugin 的日常验证。
 # 发布不走这里(见 release.yml),但**发布会做的事这里全都做一遍** ——
 # 唯一差别是不推 nuget.org。
 #
+# 本仓库自 2026-09-11 起只产出一个包:VelaShell.PluginSdk.Build 搬去了
+# VelaShellLabs/velashell-plugin-sdk(它与契约同版本发布才对),端到端冒烟随它一起搬走,
+# 打包器也在那边自带(VelaShell.PluginSdk.Packer)。本仓库因此不再有任何下游。
+#
 # 注意本仓库**不需要任何机密**:程序集不做强名称签名(那只开在 velashell-plugin-sdk
 # 那一支),推送用 OIDC。于是 fork PR 与主分支跑的是完全同一条路径,没有"拿不到密钥
 # 就降级"的分支要维护。
@@ -49,9 +53,6 @@ jobs:
           # 那时它是 $null —— 而 `$null -ne 0` 为真,会把一次成功判成失败。
           if ($LASTEXITCODE) { exit $LASTEXITCODE }
 
-      # 跨仓库的 Avalonia 版本锁核对(VELA1005 / VELA1006)就在这一步的构建里发生:
-      # VelaShell.PluginSdk 包把权威版本导出成 $(VelaSdkPinnedAvaloniaVersion),
-      # VelaShell.PluginSdk.Build 的 VerifyAvaloniaVersionPin 拿它跟本仓库的副本比。
       - name: Test
         shell: pwsh
         run: |
@@ -63,30 +64,13 @@ jobs:
         run: |
           $version = '${{ steps.version.outputs.version }}'
           New-Item -ItemType Directory -Force artifacts/nuget | Out-Null
-          # 顺序不能反:VelaShell.PluginSdk.Build 的 AddVelaCliToPackage 要去
-          # src/VelaShell.Plugin.Cli/bin/Release/ 收打包器的产物。
-          $projects = @(
-            'src/VelaShell.Plugin.Cli/VelaShell.Plugin.Cli.csproj',
-            'src/VelaShell.PluginSdk.Build/VelaShell.PluginSdk.Build.csproj'
-          )
-          foreach ($project in $projects) {
-            dotnet pack $project -c Release -o artifacts/nuget -p:VelaToolsVersion=$version --nologo
-            if ($LASTEXITCODE -ne 0) { exit 1 }
-          }
+          dotnet pack src/VelaShell.Plugin.Cli/VelaShell.Plugin.Cli.csproj -c Release -o artifacts/nuget -p:VelaToolsVersion=$version --nologo
+          if ($LASTEXITCODE -ne 0) { exit 1 }
           Get-ChildItem artifacts/nuget | Select-Object -ExpandProperty Name
 
-      # 端到端冒烟:拿刚打出的包,站在插件作者的位置上走一遍
-      # (最小插件工程 → 还原 → 构建 → 出 .vpx → 读回容器 → 查共享程序集有没有漏)。
-      # 夹具在 tests/smoke/,细节见 scripts/Invoke-Smoke.ps1 的注释。
-      # 这一步不是形式:插件工程是**仓库外环境**,仓库内的 Directory.Build.props 一条也
-      # 吃不到,而历史上两个最难查的坑(CA2252 全线报错、AXAML 编译器到不了插件工程)
-      # 都只有在这个前提下才会显形。
-      - name: Smoke test (plugin project -> build -> .vpx)
-        shell: pwsh
-        run: |
-          & ./scripts/Invoke-Smoke.ps1 -Feed ./artifacts/nuget -Version '${{ steps.version.outputs.version }}'
-          if ($LASTEXITCODE) { exit $LASTEXITCODE }
-
+      # 注:插件工程的端到端冒烟(最小插件工程 → 构建 → 出 .vpx)不在这里跑了 ——
+      # 它验的是 VelaShell.PluginSdk.Build,那个包 2026-09-11 搬去了 velashell-plugin-sdk,
+      # 冒烟连同 tests/smoke/ 夹具一起跟了过去,那边也自带打包器。本仓库与它再无构建期关系。
       - uses: actions/upload-artifact@v7
         with:
           name: nuget-packages

.github/workflows/release.yml

@@ -1,17 +1,20 @@
-# 插件工具链(CLI + 构建支持包)的发布流水线:在 GitHub 页面**发布 Release** 时自动触发。
+# vela-plugin 的发布流水线:在 GitHub 页面**发布 Release** 时自动触发。
 #
-# 一次发布产出两个 NuGet 包,共用 Release 标签里的那个版本号:
+# 一次发布产出一个 NuGet 包,版本号取自 Release 标签:
 #
 #      VelaShell.Plugin.Cli          dotnet tool `vela-plugin`
-#      VelaShell.PluginSdk.Build     插件工程引用的那一个包(targets + 打包器 + 依赖锁)
 #
-# 这两个**必须同版本发**:.Build 把 vela-plugin 的构建产物收进包的 tools/,它的 targets
-# 直接调那个打包器的命令面(`validate` / `pack`)。命令行参数改了而 targets 没跟上,
-# 现象是插件作者构建到一半 Exec 失败 —— 所以它俩是一个发布单元,拆库时刻意留在同仓库。
+# 2026-09-11 起 **VelaShell.PluginSdk.Build 不在本仓库发**:它搬去了
+# VelaShellLabs/velashell-plugin-sdk,在那边与契约包同版本、同一次发布。插件工程用的打包器
+# 也在那边自带(VelaShell.PluginSdk.Packer,与契约同仓库、同一次构建)。
 #
-# **另外三个包不在这里发**(2026-08-27 拆库起):
-#      VelaShell.PluginSdk / .Testing …… VelaShellLabs/velashell-plugin-sdk
-#      VelaShell.Plugin.Templates ……… VelaShellLabs/velashell-plugin-templates
+# 于是本仓库**没有任何下游**:vela-plugin 是面向人的工具(商店、开发内环、签名、体检),
+# 发不发版与插件作者能不能 `dotnet build -t:PackVpx` 出包毫无关系。两边都过同一个
+# VpxContainer(在 VelaShell.PluginSdk 里),包格式的一致性由类型保证,不靠版本号约定。
+#
+# **其余的包不在这里发**:
+#      VelaShell.PluginSdk / .Testing / .Build …… VelaShellLabs/velashell-plugin-sdk
+#      VelaShell.Plugin.Templates ………………… VelaShellLabs/velashell-plugin-templates
 # 三个仓库各有各的版本号。本仓库发 1.5.3 不代表契约动了,也不要求模板跟着发。
 #
 # 📌 版本号:**发版前在本地落好、随功能改动一起合进 main**。
@@ -23,14 +26,11 @@
 #    下面的 Stamp 步骤只改 runner 上的工作区,**不回写仓库**:产物版本号因此永远等于
 #    Release 标签,与仓库里当时提交了什么无关。忘了第 ① 步的兜底是 CI 的版本同步体检。
 #
-# ⚠️ 想让插件作者吃到**新契约**,得另外抬两个 csproj 里 VelaShell.PluginSdk 的
-#    PackageReference 版本(Set-Version.ps1 刻意不碰它;Dependabot 会替你提 PR)——
-#    那是一次独立的决定,不该被"发个补丁版"顺手带上。抬完 VerifyAvaloniaVersionPin
-#    会在构建期核对 Avalonia 版本锁是否也要跟着动(VELA1006)。
-#
-# ⚠️ 发完新版 .Build 之后,若希望 `dotnet new velaplugin` 生成的工程指向它,
-#    要去 velashell-plugin-templates 抬 VelaBuildPackageVersion 再发一版模板。
-#    不做也不会坏 —— 新建的工程只是继续引用上一版 .Build 包,那是完全可用的。
+# ⚠️ 想让 vela-plugin 吃到**新契约**,得另外抬 src/VelaShell.Plugin.Cli 里
+#    VelaShell.PluginSdk 的 PackageReference 版本(Set-Version.ps1 刻意不碰它;
+#    Dependabot 会替你提 PR)—— 那是一次独立的决定,不该被"发个补丁版"顺手带上。
+#    注意它管的只是**打包器自己**读清单与 .vpx 容器用的那份契约;插件作者的编译目标契约
+#    由 velashell-plugin-sdk 的 .Build 决定,与本仓库无关。
 #
 # 推送用 **NuGet Trusted Publishing(OIDC)**,不存 API Key:
 #   NuGet/login 拿本次运行的 GitHub OIDC 令牌去 nuget.org 换一把**短时效**的推送密钥,
@@ -57,7 +57,7 @@ on:
         required: true
         type: string
       dryRun:
-        description: '只打包与冒烟,不推送 nuget.org'
+        description: '只打包,不推送 nuget.org'
         required: false
         default: false
         type: boolean
@@ -105,7 +105,6 @@ jobs:
           if ($LASTEXITCODE) { exit $LASTEXITCODE }
           git --no-pager diff --stat
 
-      # 跨仓库的 Avalonia 版本锁核对(VELA1005 / VELA1006)就在这一步的构建里发生。
       - name: Test
         shell: pwsh
         run: |
@@ -117,26 +116,12 @@ jobs:
         run: |
           $version = '${{ steps.version.outputs.version }}'
           New-Item -ItemType Directory -Force artifacts/nuget | Out-Null
-          # 顺序不能反:VelaShell.PluginSdk.Build 的 AddVelaCliToPackage 要去
-          # src/VelaShell.Plugin.Cli/bin/Release/ 收打包器的产物。
-          $projects = @(
-            'src/VelaShell.Plugin.Cli/VelaShell.Plugin.Cli.csproj',
-            'src/VelaShell.PluginSdk.Build/VelaShell.PluginSdk.Build.csproj'
-          )
-          foreach ($project in $projects) {
-            dotnet pack $project -c Release -o artifacts/nuget -p:VelaToolsVersion=$version --nologo
-            if ($LASTEXITCODE -ne 0) { exit 1 }
-          }
+          dotnet pack src/VelaShell.Plugin.Cli/VelaShell.Plugin.Cli.csproj -c Release -o artifacts/nuget -p:VelaToolsVersion=$version --nologo
+          if ($LASTEXITCODE -ne 0) { exit 1 }
           Get-ChildItem artifacts/nuget | Select-Object -ExpandProperty Name
 
-      # 端到端冒烟:完全站在插件作者的位置上 —— 从刚打出的包还原、构建、出 .vpx,
-      # 最后确认包能被容器读回来、共享程序集没漏进插件输出目录。任何一步失败都不该发出去。
-      - name: Smoke test (plugin project -> build -> .vpx)
-        shell: pwsh
-        run: |
-          & ./scripts/Invoke-Smoke.ps1 -Feed ./artifacts/nuget -Version '${{ steps.version.outputs.version }}'
-          if ($LASTEXITCODE) { exit $LASTEXITCODE }
-
+      # 注:插件工程的端到端冒烟随 VelaShell.PluginSdk.Build 搬去了 velashell-plugin-sdk,
+      # 那边自带打包器,与本仓库无关。
       - uses: actions/upload-artifact@v7
         with:
           name: nuget-packages

AGENTS.md

@@ -37,38 +37,42 @@ VelaShell 生态的**全部文档**集中在一个仓库:
 - **例外**:留在代码仓库里的少数几份文件不适用上述规则,因为它们服务的是「在这个仓库里写代码」
   这件事,搬走只会离使用场景更远。各仓库的例外清单见下面第三节。
 
-## 三、本仓库:velashell-plugin-cli(命令行与构建支持包)
+## 三、本仓库:velashell-plugin-cli(插件命令行工具)
 
-产出 `VelaShell.Plugin.Cli`(dotnet tool `vela-plugin`)与 `VelaShell.PluginSdk.Build`
-(插件工程**只需引用这一个包**)。两者**始终同版本发**:`.Build` 把 `vela-plugin` 的构建产物
-收进包的 `tools/`,它的 targets 直接调那个打包器的命令面,参数改了而 targets 没跟上,
-现象是插件作者构建到一半 `Exec` 失败。
+产出**一个**包:`VelaShell.Plugin.Cli`(dotnet tool `vela-plugin`)。
+
+`VelaShell.PluginSdk.Build` 已于 2026-09-11 搬去 `VelaShellLabs/velashell-plugin-sdk`
+—— 它决定的是插件作者**编译时看到的那份契约**,所以属于契约仓库,在那边与契约同版本发布。
+端到端冒烟(`scripts/Invoke-Smoke.ps1` + `tests/smoke/`)随它一起搬走了。
+
+### 本仓库没有下游
+
+插件工程 `dotnet build -t:PackVpx` 用的**不是**这个工具:`.Build` 自带一个三条命令的打包器
+(那边的 `VelaShell.PluginSdk.Packer`)。两边都走 `VelaShell.PluginSdk` 里的同一个
+`VpxContainer`,包格式一致由类型保证,不靠版本号约定 —— 所以改 `vela-plugin` 的命令面
+不会波及任何别的仓库,也没有跨仓库的后续动作要做。
+
+`vela-plugin` 自己的定位:面向人的完整工具(商店、开发内环、签名、体检)。
 
 ### 构建与测试
 
 ```bash
 dotnet build VelaShell.Plugin.Cli.slnx
 dotnet test  VelaShell.Plugin.Cli.slnx -c Debug
-
-# 端到端冒烟:拿刚打出的包当插件作者走一遍
-dotnet pack src/VelaShell.Plugin.Cli/VelaShell.Plugin.Cli.csproj -c Release -o artifacts/nuget
-dotnet pack src/VelaShell.PluginSdk.Build/VelaShell.PluginSdk.Build.csproj -c Release -o artifacts/nuget
-pwsh scripts/Invoke-Smoke.ps1 -Feed ./artifacts/nuget -Version <版本>
+dotnet pack  src/VelaShell.Plugin.Cli/VelaShell.Plugin.Cli.csproj -c Release -o artifacts/nuget
 ```
 
-冒烟夹具在 `tests/smoke/`:一个手写的最小插件工程,刻意带两个空的
-`Directory.Build.props`/`.targets` 来切断向上查找 —— **插件工程是仓库外环境,仓库内的构建约定
-一条也吃不到**,冒烟的全部价值就在这里。改打包器或 targets 后必须跑它。
-
-### 两个跨仓库旋钮(都不由 Set-Version.ps1 管)
+### 唯一的跨仓库旋钮(不由 Set-Version.ps1 管)
 
 | 旋钮 | 在哪 | 抬它意味着 |
 | --- | --- | --- |
-| `VelaShell.PluginSdk` 的 `PackageReference` | 两个 csproj,**必须同版本** | 插件作者的编译目标契约变新。只改了输出格式的补丁版不该顺手带上 |
-| `VelaAvaloniaVersion` | `Directory.Build.props` | 权威在 sdk 仓库,这里只是副本。漂了报 `VELA1006` |
+| `VelaShell.PluginSdk` 的 `PackageReference` | `src/VelaShell.Plugin.Cli` 的 csproj | **打包器自己**读清单与 `.vpx` 容器用的那份契约变新。只改了输出格式的补丁版不该顺手带上 |
+
+版本刻意写成**字面量**、不抽成 MSBuild 属性:`Version="$(...)"` 会让 Dependabot 与
+`dotnet add package` 认不出这条依赖。
 
-契约 SDK 的版本刻意写成**字面量**、不抽成 MSBuild 属性:`Version="$(...)"` 会让
-Dependabot 与 `dotnet add package` 认不出这条依赖。
+Avalonia 版本锁与它的构建期核对(`VELA1000` / `VELA1006`)在本仓库已不存在 ——
+随 `.Build` 搬去了 sdk 仓库,权威值本来就在那里。
 
 ### 发版脚本会写 velashell-docs
 

Directory.Build.props

@@ -14,17 +14,22 @@
 
   <PropertyGroup>
     <!--
-      本仓库产出两个包,共用这个版本号:
+      本仓库产出**一个**包:
           VelaShell.Plugin.Cli          dotnet tool `vela-plugin`
-          VelaShell.PluginSdk.Build     插件工程引用的那一个包(targets + 打包器 + 依赖锁)
 
-      这两个**必须同版本发**:.Build 把 vela-plugin 的构建产物收进包的 tools/,
-      它的 targets 直接调那个打包器的命令面(`validate` / `pack`)。命令行参数改了而
-      targets 没跟上,现象是插件作者构建到一半 Exec 失败 —— 所以它俩是一个发布单元。
+      属性名仍叫 VelaToolsVersion(没跟着改成 VelaCliVersion):CI、Set-Version.ps1 与
+      velashell-docs 的发版流程都按这个名字对接,改名只是让几处一起动一遍,换不来什么。
+
+      **VelaShell.PluginSdk.Build 不再在本仓库**(2026-09-11 起):它搬去了
+      VelaShellLabs/velashell-plugin-sdk,在那边与契约包同版本、同一次发布 —— 它发给插件
+      工程的那份契约就是那个仓库当时那一版,这正是搬过去的理由。
+      那边的 .Build 自带打包器(VelaShell.PluginSdk.Packer,同仓库的一个小工程,走同一个
+      VpxContainer),**不引用本仓库的任何东西**。所以两边没有任何耦合可言:本仓库只是
+      vela-plugin 这一个面向人的工具,发不发版与插件工程能不能出包毫无关系。
 
       **与契约 SDK 解耦**(2026-08-27 拆库起):VelaShell.PluginSdk 在
       VelaShellLabs/velashell-plugin-sdk,有自己的版本号。SDK 发 1.6.0 不要求本仓库跟着发;
-      本仓库发 1.5.3 也不代表契约动了。想吃到新契约时,直接把两个 csproj 里
+      本仓库发 1.5.3 也不代表契约动了。想吃到新契约时,直接把 src/VelaShell.Plugin.Cli 里
       VelaShell.PluginSdk 的 PackageReference 版本抬上来再发一版即可 —— 走 NuGet
       (或合掉 Dependabot 的 PR)更新,**不要**抽成 MSBuild 属性:Version="$(...)"
       会让 Dependabot 与 `dotnet add package` 认不出这条依赖。
@@ -44,11 +49,9 @@
   </PropertyGroup>
 
   <!--
-    ⚠️ 插件生态的 Avalonia 版本**不在这里定义**。它是一条普通的 NuGet 依赖,版本写在
-    src/VelaShell.PluginSdk.Build/VelaShell.PluginSdk.Build.csproj 那条 PackageReference
-    的精确区间 [x.y.z] 上(以及包里发给插件工程的 build/VelaShell.PluginSdk.Build.props),
-    用 VS 的 NuGet 包管理器直接升即可。权威值在 velashell-plugin-sdk,由该包导出的
-    $(VelaSdkPinnedAvaloniaVersion) 在构建期核对(VELA1000 / VELA1006)。
+    ⚠️ 本仓库与 Avalonia 再无关系(2026-09-11 起)。vela-plugin 是纯命令行工具,不引用
+    Avalonia;插件生态那个 Avalonia 版本锁的副本与它的构建期核对(VELA1000 / VELA1006)
+    随 VelaShell.PluginSdk.Build 一起搬去了 velashell-plugin-sdk —— 权威值本来就在那里。
   -->
 
   <PropertyGroup>