DLM 關閉與發布流程 7 (可攜版)

目的

在不混淆任務完成、知識沉澱、發布產出、版本控制、Git 提交或部署的前提下，關閉一個已驗證的工程範圍。此個人技能負責編排生命週期；倉庫合約與子技能則保留其各自的技術規則。

成果治理關卡

在進行任何關閉寫入、發布/版本變更、正式稽核、暫存或提交前，請先閱讀並套用共享的 DLM 成果治理。

保持工程目標狀態、證據狀態、DLM 協調狀態、發布狀態、Git 狀態、部署狀態與現場驗收狀態彼此分離。推進其中一項不代表其他項也隨之推進。
為授權模式解析一個驗收基準線。在關閉寫入或發布/Git 變更前，基準線擁有者應一次性凍結其目標、非目標、授權範圍、所需證據、條件及停止線。雜湊值、BOM/EOL、簽出表示法與收據不會凍結或使其失效。
僅在被相應合約/決策要求或使用時，關閉/沉澱/發布記錄才算目標工作。純粹的管理變更不會重新開啟不相關的建置/測試/稽核。
對於穩定的目標狀態，最多只使用一次正式完整稽核，且僅在用戶、已接受的合約或重大風險證明其必要性時進行。修復後，僅重新驗證失敗的條件及直接相關的回歸問題。

選擇最狹義的授權模式

模式	允許的操作	典型意圖
`close-only`	關閉審查、沉澱、DLM 驗證	“關閉任務”“完成沉澱”
`release-verify`	close-only 加上倉庫發布/版本建置及工件元數據驗證	“準備發布”“驗證發布版本”
`release-commit`	release-verify 加上精確路徑暫存與提交	“更新版本並提交 Git”

預設為 close-only。提交請求不代表授權推送、標籤、部署、發布或工件複製。每項操作皆需獨立授權。若措辭不足以區分 Git/版本變更，請在動作前停止並詢問。

倉庫與合約鎖定

解析一個 Git 根目錄並閱讀其 AGENTS.md 與 DLM 合約。
執行任務與發布設定檔所需的最小 dlm-load。
請勿將此個人技能複製到倉庫中或將其加入上下文清單。
使用倉庫聲明的發布設定檔：
- none：僅限關閉，除非用戶提供程序；
- dotnet：以組合模式使用 dlm-version-master；
- custom：使用倉庫自有的版本/建置/驗證合約。
在多倉庫或子模組工作中，每個 Git 根目錄使用獨立的白名單、驗證結果與提交。請勿聲稱跨倉庫的原子性。

階段 0 — 範圍快照

在進行任何寫入前，執行此合併的寫入者/範圍安全快照一次：

git status --short
git diff --name-status
git diff --cached --name-status
git ls-files --others --exclude-standard

為任務擁有的候選項目、預先存在的無關變更、以及預先暫存的檔案建立精確集合。若無法從用戶意圖、凍結的授權範圍、任務文件與差異分析中確立所有權，請在修改前停止。請勿為了製造授權證據而重複執行快照。切勿使用 git add . 或 git add -A。

階段 1 — 關閉審查

針對凍結的條件與符合聲稱的證據執行目標性關閉審查。使用 dlm-reflect；除非用戶要求、已接受的合約要求，或有重大風險證明其必要性，否則正式獨立審查為選項。當聲稱的完成等級獲得證實時繼續，或將重大的剩餘差距作為當前範圍工作/阻礙處理。僅建置成功不能代替行為、UI、硬體、遷移、安全或現場證據；同樣地，過時的管理索引也無法否定已證實的行為。

階段 2 — 沉澱

當用戶要求沉澱、已接受的倉庫/任務合約要求沉澱，或實際的載入/發布/決策消費者需要同步時，以組合模式執行 dlm-sediment 一次。僅寫入已確認的任務/領域知識與狀態。BRIEF/L0 核准關卡仍為啟用狀態。子技能必須回傳確切的變更路徑，且不得暫存或提交。若無此觸發條件，則記錄 sediment: not required 並保留已驗證的工程結論。

為實際的任務/知識消費者同步一次，並重複使用現有證據。請勿因為僅更新了協調記錄，就建立同義的收據或重新執行不相關的工程驗證。

對於 close-only 模式，僅在授權的關閉包含 DLM 狀態，或現行合約/消費者聲稱依賴於此類檢查時，才執行 DLM 健康檢查，然後在關閉報告後停止。跳過不適用的檢查不算是失敗。

階段 3 — 發布驗證

僅限於發布模式：

解析倉庫發布設定檔與確切產出範圍。
確定版本意圖。主版本/次版本需要明確意圖。僅在發布意圖存在且倉庫合約聲明該預設值時，才允許修補程式/自動版本。
序列執行倉庫版本/建置流程，除非其合約另行指定。
執行測試，並驗證凍結的發布標準/設定檔所要求的公開二進位/套件元數據與雜湊值；請勿將審查者偏好檢查新增為新的發布條件。
僅將有意的版本狀態、變更日誌、發布基礎設施與任務擁有的原始檔新增至候選白名單。

當建置、測試、雜湊或元數據檢查為凍結的發布基準線、倉庫設定檔，或已證明的具體產出風險所需時，該類失敗會阻止提交/發布聲稱。不相關的預先存在或管理失敗應分開報告，且不會無聲地擴大發布標準。

階段 4 — 精確暫存集關卡

僅限於 release-commit 模式：

將白名單正規化為相對於倉庫根目錄的精確路徑。
比較當前的暫存檔案與預先暫存的快照。
請勿取消暫存用戶的工作。如果預先暫存的檔案不在白名單內，請停止並回報。
如果白名單上的檔案混合了無法安全分割的、無關的既有變更，請停止並詢問。
排除機密、機器本機設定、bin/、obj/、out/、日誌、擷取內容、發布/暫存輸出及暫存性工件，除非明確要求且合適。
執行倉庫要求的空白字元/編碼檢查。

階段 5 — 暫存與提交

git add -- <exact-paths>
git diff --cached --name-status
git diff --cached --stat
git diff --cached --check
git status --short

要求暫存路徑與已核准的白名單完全相等。在提交前，根據此確切暫存差異，執行全域 AGENTS.md（ponytail-review 關卡及其守衛標記）與倉庫所要求的所有提交前審查；按照這些規則的要求解決或明確保留每個發現。如果所需的審查技能或掛鉤不可用，請在提交前停止並報告此差距，而非繞過它。每個 Git 根目錄使用倉庫慣例提交一次。除非被要求，否則請勿修改提交。提交後，檢查 git show --stat --oneline HEAD 以及剩餘的工作目錄。

失敗規則

僅當子命令的失敗違反了當前的凍結標準、適用合約、受影響工件的完整性檢查，或重大的安全/發布邊界時，非零的退出碼才會阻止後續階段。不相關的預先存在與管理失敗會被報告，但不會成為新的關卡。
被阻止的任務不會被關閉；應持續記錄其原因、負責人、嘗試次數及發布條件。
已取消的工作可以保留取消狀態，但不得假裝成功發布。
輸出鎖應被報告，而非強制刪除。
不相關的工作保持不變。
基準線失效 僅保留給新的單一事實來源衝突、虛假前提、安全或資料遺失風險。EOL/BOM、clean/smudge、時間戳、顯示順序或僅收據變更不會使完整的驗證失效或重新開啟。

最終報告

報告模式、倉庫/專案識別碼、驗收基準線狀態/擁有者/停止線、關閉審查類型/裁決、沉澱消費者/路徑、DLM 檢查、發布設定檔與版本變更、符合聲稱的已驗證工件、暫存白名單、提交雜湊值（如有）、阻塞性與建議性差距，以及刻意未觸及的不相關檔案。明確說明哪些操作（提交/推送/標籤/部署/工件複製）未被執行。在授權模式的邊界處停止；請勿自動啟動下一個子任務、工作項目、待辦發現、推送、標籤或部署。

DLM 關閉與發布流程