DLM 版本管理大師 7 可攜版 是做什麼的？
目的
針對 .NET 儲存庫，進行版本管理、驗證、提交與推送，並使用儲存庫自身擁有的基礎架構，不預設產品名稱或目錄結構。此個人技能提供通用工作流程；每個儲存庫需自行宣告其專案、發布入口點、模組對應、輸出路徑與提交策略。
結果治理關卡
在執行版本狀態變更、Release 建置、成品驗證、暫存、提交或推送之前，請閱讀並套用共享的 DLM 結果治理。
- 建立一個「凍結的」發布/版本基準線，其中包含授權範圍、所需模組/輸出、內部版本決策、符合主張的證據以及停止線。直接調用
dlm-version-master即授權內部版本評估、必要的建置/驗證、精確範圍的 Git 提交，以及推送至遠端分支；不授權成品複製、發布、標記、部署或現場發佈。 - 原始碼雜湊支援模組變更/版本決策的主張；輸出雜湊則在設定檔使用時支援位元組身份。這兩者都不能凍結基準線，也無法證明執行時期、協調、部署或現場狀態。
- 僅執行設定檔要求或重大風險的檢查。綠色的中繼資料不能取代行為證據，不相關的管理失敗也不能無聲地成為發布標準。
- 在變更之前，執行一次結合身份/範圍/預先準備的安全檢查，然後推進最短的發布路徑。除非有真正的使用者或新的重大不確定性，否則不要添加收據、重複摘要或重複完整驗證。
權限與組成
- 每次直接調用
dlm-version-master都帶有使用者授權，可以：- 除非使用者在提示中明確指定升級策略，否則根據內部規則自主決定是否升級版本（
無升級vs.補丁/次要/主要）； - 在模組版本或與建置相關的原始碼輸入有變更時，執行必要的 Release 建置和二進位中繼資料驗證；
- 暫存精確的允許清單路徑，執行必要的提交前審查 (
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和版本過渡的詳細結構化多行提交訊息（絕不能是一行摘要或模糊的「升級版本」/「更新檔案」）。它必須明確包含所有四個必要部分：- 修改範圍: 變更的模組/專案/子系統以及主要的允許清單檔案或邊界；
- 對應版本: 升級級別 (
無升級/補丁/次要/主要)，以及每個受影響模組的舊版 -> 新版版本過渡（如果沒有模組升級，則為當前版本加上無升級 (sourceHash 未變更)）； - 怎麼改的: 從暫存的差異中得出的具體技術實作（入口點、資料/控制流程、演算法/UI/設定/建置調整）；
- 為什麼改的: 程式碼變更和版本決策的根本原因、需求/任務驅動因素、缺陷觸發因素或架構/相容性原因。
- 當內部規則決定不升級版本時（模組原始碼雜湊未變更），跳過版本變更且不要建立空的版本提交；仍然暫存、審查、提交（使用相同的四部分結構化提交訊息）並推送範圍內的任何預期允許清單儲存庫變更，或推送目前分支上現有未推送的已驗證提交。
輸出
回報儲存庫設定檔來源、凍結發布基準線/停止線、內部版本決策 (無升級 / 補丁 / 次要 / 主要) 及其理由、建置範圍和命令（如果已執行）、模組雜湊/版本過渡、未變更的模組、符合主張的測試、已驗證的輸出中繼資料/雜湊、變更日誌使用者/路徑、變更檔案允許清單、完整的結構化提交訊息 (修改範圍 / 對應版本 / 怎麼改的 / 為什麼改的)、提交雜湊、已驗證的遠端分支推送結果，以及阻擋性與建議性差距。請將更高層級的證據水準與建置和 Git 同步成功與否明確區分開來。