DLM 版本主控器 7 便携版
目的
对 .NET 仓库变更进行版本控制、验证、提交和推送，使用仓库自有基础设施，不假设产品名称或目录布局。此个人技能提供通用工作流；每个仓库通过其契约声明项目、发布入口、模块映射、输出路径和提交策略。
结果治理门控
在版本状态变更、发布构建、工件验证、暂存、提交或推送之前，阅读并应用共享的 DLM 结果治理。
- 建立一个冻结的发布/版本基线，包括授权范围、所需模块/输出、内部版本决策、与声明匹配的证据以及停止线。直接调用
dlm-version-master授权内部版本评估、必需的构建/验证、精确范围的 Git 提交和推送到远程分支；它不授权工件复制、发布、打标签、部署或现场发布。 - 源哈希支持模块变更/版本决策声明；输出哈希在配置文件中使用时支持字节一致性。两者均不能冻结基线，也不能证明运行时、协调、部署或现场状态。
- 仅运行配置文件必需的或实质性风险的检查。绿色元数据不能替代行为证据，不相关的管理故障也不能悄然成为发布标准。
- 在变更前执行一次组合的身份/范围/预暂存安全检查，然后推进最短的发布路径。在没有实际消费者或新的实质性不确定性时，不添加收据、重复摘要或重复的全面验证。
权限与组成
- 每次直接调用
dlm-version-master均携带用户授权，允许：- 通过内部规则自主决定是否升级版本（
无vs.补丁/次要/主要），除非用户在提示中明确指定升级策略； - 在模块版本或与构建相关的源输入发生变化时，运行所需的发布构建和二进制元数据验证；
- 暂存精确的允许列表路径，运行所需的提交前审查（
ponytail-review），提交到 Git 并附带详细的结构化提交信息，涵盖 修改范围 (Scope)、对应版本 (Version)、怎么改的 (How) 和为什么改的 (Why)，然后推送到远程仓库分支（git push）。
- 通过内部规则自主决定是否升级版本（
- 仅当用户在当前轮次中明确指示不提交/推送，或具体的安全/验证门控阻止时（必需的构建/测试/审查失败、目标文件中存在混合无关变更、远程缺失/歧义或远程分支已分歧），才跳过提交或推送。
- 远程仓库创建、强制推送、打标签、部署、发布和工件复制仍为单独的权限。
- 在
dlm-close-release组合模式中，执行发现、内部版本决策、构建、变更日志和元数据验证，然后返回精确的变更路径，不进行暂存、提交或推送，除非拥有编排器明确委托共享的 Git 阶段。 - 不要将此个人技能复制到仓库中，也不要从项目上下文清单中引用它。
- 保持工程、发布证据、DLM 协调、Git、部署和现场验收为独立状态。
启动上下文
- 解析一个 Git 根目录并读取其
AGENTS.md。 - 如果仓库使用 DLM，加载
doc_llm/dlm.json和当前活跃的发布任务。 - 读取
references/versioned-build-contract.md和references/git-sync.md。 - 在编辑前检查现有的
.sln、.slnx、可执行文件/库/插件的.csproj、Directory.Build.*、仓库版本脚本、CI/发布定义以及版本状态。 - 优先使用仓库自有的版本基础设施。仅在用户要求建立版本化且不存在兼容机制时，才创建
build/versioning/。
解析仓库配置文件
使用以下顺序：
- 在
doc_llm/dlm.json或仓库文档中声明的发布/版本配置文件； - 现有的版本/构建脚本和版本状态；
- 用户指定的项目/解决方案；
- 明确的可执行启动项目或主解决方案；
- 如果仍然歧义，则报告候选方案并在版本变更前询问。
不要将已知产品的路径嵌入到个人技能中。特定于项目的行为属于仓库契约或其脚本。
基于源哈希的版本决策（自主内部规则）
是否升级版本以及应用哪个升级级别由内部规则自动决定（除非用户在提示中明确覆盖级别）。哈希项目自有的源输入，而不是输出二进制文件。
酌情包括：
.cs、.fs、.vb、.xaml、.axaml；.csproj、.fsproj、.vbproj、.props、.targets；- 项目自有的资源、清单、包/项目引用以及代码生成输入。
排除：
bin/、obj/、out/、publish/、artifacts/、暂存目录和复制的运行时输出；- 生成的版本属性文件、变更日志和发布说明；
- 计算模块源哈希时的版本状态本身；
.pdb、.deps.json、生成的 DLL/EXE/包输出。
内部决策表：
- 不升级 (
无): 未更改的模块源输入哈希永远不会触发升级。如果仅非模块文件（例如文档、DLM 记录或模块哈希输入之外的仓库脚本）发生更改，或者自记录哈希以来没有模块源输入发生更改，则不升级版本，也不创建空版本变更；直接对范围内实际的允许列表更改执行 Git 提交和远程推送阶段。 - 模块源输入哈希更改时自动升级: 检查模块差异的语义影响和仓库规则，自动选择级别，无需停止询问：
主要/A: 破坏性公共 API、持久化格式、插件发现、执行、授权或部署契约；次要/B: 向后兼容的功能、新模块/插件/工具或能力添加；补丁/C: 向后兼容的错误修复、布局/可访问性/本地化修正、重构、性能调优、日志记录或内部维护；自动: 配置时使用仓库声明的默认值，否则根据上述主要/次要/补丁规则评估（默认为补丁）。
二进制元数据
对于 SDK 风格的项目，确保公开版本值流入生成的输出：
<Version>1.2.3</Version>
<AssemblyVersion>1.2.3.0</AssemblyVersion>
<FileVersion>1.2.3.0</FileVersion>
<InformationalVersion>1.2.3</InformationalVersion>
<IncludeSourceRevisionInInformationalVersion>false</IncludeSourceRevisionInInformationalVersion>
不要将分支、提交 SHA、远程 URL、作者/电子邮件、提交消息、机器路径或仓库路径放置在公共二进制版本字段中。Git 溯源属于 Git/CI/发布日志。
构建与验证
当内部规则升级一个或多个模块时（或当与构建相关的模块输入发生更改时），如果存在仓库脚本则使用它；否则按顺序构建所选范围：
dotnet build <project-or-solution> -c Release -m:1
不要强制删除锁定输出。报告锁定进程并停止，除非用户授权安全进程关闭。
构建后，仅验证冻结发布基线和仓库配置文件所需的声明：
- 运行受影响的测试和仓库发布检查；
- 验证每个已更改公共模块至少有一个输出；
- 通过适当的工具读取文件/产品/程序集/信息版本；
- 验证预期的输出路径，并在需要时验证 SHA-256/包元数据；
- 确保未更改的模块未被升级；
- 当发布配置文件或实际的发布/决策消费者要求时，生成仓库的简洁变更日志/发布摘要。
如果无法验证所需的元数据、测试、哈希或输出标识，则相应的发布声明不完整，并会阻止 Git 提交/推送阶段。单独报告不相关的预先存在或管理性故障；除非证明有实质性影响，否则它们不会使合规输出无效。
强制 Git 提交和远程推送阶段
每次直接调用 dlm-version-master 时，遵循 Git 同步（除非用户明确禁止，或作为未获得 Git 委托的组合子项运行）：
- 执行内部版本决策 -> 验证构建（当已升级或构建相关输入更改时）-> 提交前审查（
ponytail-review和仓库钩子）-> 精确范围git commit->git push到远程分支。 dlm-version-master创建的每个提交必须使用基于实际git diff --cached和版本转换的详细结构化多行提交信息（绝不是一行摘要或含糊的“升级版本”/“更新文件”）。它必须明确包含所有四个必需部分：- 修改范围 (Scope): 已更改的模块/项目/子系统以及关键的允许列表文件或边界；
- 对应版本 (Version): 升级级别（
无/补丁/次要/主要）以及每个受影响的模块的旧 -> 新版本转换（或当没有模块升级时，当前版本加上无（源哈希未更改））； - 怎么改的 (How): 源自暂存差异的具体技术实现（入口点、数据/控制流、算法/UI/配置/构建调整）；
- 为什么改的 (Why): 根本原因、需求/任务驱动因素、缺陷触发器或代码更改和版本决策的架构/兼容性原因。
- 当内部规则决定不升级版本时（未更改的模块源哈希），跳过版本变更，不创建空版本提交；仍然暂存、审查、提交（使用相同的四部分结构化提交信息）并推送任何范围内预期的允许列表仓库更改，或推送当前分支上现有的未推送已验证提交。
输出
报告仓库配置文件来源、冻结发布基线/停止线、内部版本决策（无 / 补丁 / 次要 / 主要）及其理由、构建范围和命令（如果执行）、模块哈希/版本转换、未更改的模块、与声明匹配的测试、验证的输出元数据/哈希、变更日志消费者/路径、已更改文件允许列表、完整结构化提交信息（修改范围 / 对应版本 / 怎么改的 / 为什么改的）、提交哈希、已验证的远程分支推送结果以及阻塞性与建议性差距。保持更高级别的证据与构建和 Git 同步成功状态的区分。