DLM Load 7 Portable 是做什麼的？

目的

鎖定一個儲存庫，並載入其自身的合約、限制、活躍任務、manifest 檔案以及原始碼錨點。此個人技能定義了載入方法；儲存庫狀態完全由儲存庫本身所擁有。

結果治理閘道

套用共用的 DLM Outcome Governance。在執行 load-and-continue 之前、在將上下文缺口視為阻斷因素之前，或每當載入行為會影響正式審查、委派、發布或其他外部狀態決策時，請先閱讀此文件。

將載入視為一次結合身份/範圍安全檢查與下一個實質決策所需的最低限度事實的動作。
當儲存庫/任務身份已穩定時，不要重複執行 Session Init、重新凍結權威或產生控制平面工件。
load-and-continue 並不能繞過治理閘道：在第一次實質寫入、可執行委派、外部行動或狀態/資源變更之前，請確認適用的驗收基準線已由其擁有者凍結，或等效的明確會話授權提供了相同的目標、標準、授權範圍、證據和停止線。
只有當適用的合約將其標記為必要，且其缺失實質上阻礙了當前的聲明或安全行動時，上下文缺口才會構成阻斷。不相關的行政資訊過時問題，應回報給消費者以進行關閉，不得因此延遲目標工作。
文件、原始碼、執行期證據和協調狀態應保持獨立；載入適合該決策的層級，而不是用一個層級作為另一個層級的代理。

儲存庫解析

優先使用使用者明確提供的儲存庫根目錄。
否則，使用包含相關 doc_llm 的最近 Git 根目錄。
在單一儲存庫或多重簽出造成歧義的情況下，檢查候選的 doc_llm/dlm.json 身份，並僅在仍無法安全確定目標時提出詢問。
在解釋路徑或狀態之前，先讀取適用的 AGENTS.md、doc_llm/dlm.json 和 doc_llm/README.md。
切勿因為記憶或先前的對話而載入相鄰專案的 DLM。

如果專案有合約，則其中宣告的 repository_root、doc_llm_root、project_id、狀態和相容性規則具有權威性。個人技能路徑絕非專案上下文檔案。

意圖模式

load-only：使用者僅要求檢視、摘要或評估上下文。維持唯讀狀態，並在產生上下文報告後停止。
load-and-continue：使用者已要求規劃、實作、審查或診斷。先載入，然後繼續已授權的任務，無需要求重複確認。

載入是一個工作流程階段，而非平台模式，也不代表變更的權限。

工作階段初始化

首次進入時，讀取合約/README 及適用的 BRIEF/L0 限制；只要儲存庫身份和相關限制保持穩定，即可重複使用它們。對於已命名或已鎖定的任務，直接前往其 Epic/Subtask 和所需的 manifest 條目。僅在需要發現所有權、解決依賴關係或在已授權的佇列中選擇工作時，才讀取待辦事項/索引。臨時診斷或問題不得授權選擇或執行不相關的待辦事項。

當任務選擇是使用者請求或已授權佇列的一部分時，按以下順序確定性地選擇：

使用者指定的 Epic/Subtask；
已在當前對話中鎖定且仍處於活躍狀態的任務；
按儲存庫待辦事項/優先級/ID 規則排序的進行中任務；
使用相同順序的、依賴項已就緒的已規劃任務；
受阻的任務需回報其解除條件，不視為可執行。

如果在套用儲存庫規則後候選項目仍然並列，則顯示最小的有用候選集合，而不是根據檔案時間戳或讀取每個歷史任務來猜測。

當前身份與恢復

當使用者提供的專案沒有 Git 元資料時，鎖定其明確的目錄及其自身的 DLM 合約。將 Git 狀態回報為不可用；切勿採用父儲存庫或相鄰儲存庫來製造身份。
使用 Epic/Subtask 作為規範的任務身份。首先在其所屬 Epic 中解析舊的短依賴項，然後僅在該依賴項全域唯一時才使用它。一個由數個 Epic 共用的裸 ID 需要消除歧義；不得靜默地選取第一個匹配項。
當前的領先 Meta 表格（或明確的 ## Meta 區段）具有權威性。歷史日誌、已歸檔的計劃和舊的凍結條目不會覆蓋當前的狀態或驗收。僅當下一個決策需要時才讀取歷史證據。
優先使用儲存庫擁有的現有 next / context 命令（若其能提供身份、依賴項、阻斷因素和讀取順序）。不要為了載入上下文而安裝新命令，也不要將其輸出視為變更權限。

任務深度探索

讀取任務並找到 <context_manifest>。
對於 schema 2，要求匹配的 project、儲存庫相對路徑 / 以及每個條目對應的具體檔案。
每個 <file> 都有 path、intent 和 required；section 和 defer 是可選的。
拒絕將絕對路徑、..、目錄、兄弟儲存庫、個人技能根目錄和 .agents/skills 工作流程檔案作為任務上下文。
當前任務合約所需的遺失檔案會阻斷受影響的深度探索/聲明。遺失的可選檔案，或沒有當前消費者的不相關行政記錄，則會變成警告。
defer="true" 僅在 required="false" 時有效；僅在當前決策需要時才載入它。
在有用時平行讀取獨立檔案。透過精確載入相關區段來遵循 section。

對於舊版 manifest，請遵循儲存庫的相容性規則並回報差距。請勿在載入時靜默地進行遷移。

以決策為中心的上下文與恢復

在必要的輸入之後，圍繞下一個實質問題組織進一步的閱讀：適用的限制、證據與反證、缺失的事實以及下一個來源條目。僅相關性並不足以建立充分性。在真正的恢復中，保留最後適用的證據和已排除的失敗路徑；重新整理已變更的依賴項，而不是重複 Session Init。

對於證據重用、變更 L2 知識或重複失敗，請閱讀 Evidence and decisions 的相關區段。如需一組明確識別的變更，scripts/dlm_impact.py --repo-root <repo> --changed-file <repo-relative-file> --json 可以傳回唯讀的 L2 審查候選項目，包括可選的 depends_on 傳播。它不能證明知識的有效性，也不能取代必要的 manifest 輸入。請勿為每次常規讀取都執行它。

原始碼錨定

使用 rg、符號導航、專案檔案、測試、日誌和產生的證據來定位實作真相。
從狹義的原始碼讀取開始。當生命週期、序列化、狀態機或跨成員行為使得局部摘錄不安全時，則讀取完整檔案。
區分文件聲明、原始碼事實、執行期證據和未解決的推論。
如果 DLM 和原始碼不一致，請回報不相符之處，並根據當前原始碼/證據繼續，除非任務明確規定以文件優先。

臨時載入

在執行期間，透過全域 L1/領域 L1 路由到最小的相關 L2 和原始碼錨點。當僅有一個領域決策需要更多上下文時，不要重複整個 Session Init。

驗證與輸出

當合約/manifest 完整性對下一個決策至關重要，或使用者要求 DLM 驗證時，執行儲存庫健康檢查。將通用檢查工具作為支援合約的證據，而非例行公事：

python -B -X utf8 <skill-dir>/scripts/dlm_doctor.py --repo-root <repo> --require-contract

根據當前目標和合約對失敗進行分類。相關的合約/路徑失敗可能會阻斷受影響的 DLM 動作；不相關的既有問題或行政性警告不能使其他方面足夠的工程上下文失效。

回報儲存庫/專案身份、選定的任務及其選擇依據、已載入的限制與原始碼錨點、缺失或過時的上下文、任何阻斷性差距的實質影響，以及原始任務是否會繼續。一旦下一個決策擁有足夠的上下文，停止載入並將精力回歸到該工作上。

可選的 v2 Ledger 簡報 (`scripts/dlm.py brief`)

在載入使用 ledger.json 的 Epic 時，執行 python -X utf8 <skill-dir>/scripts/dlm.py brief <E> <S>（或 dlm.py status）以呈現任務簡報、活躍義務、未解決的假設以及先前的檢查點狀態，並搭配 dlm_impact.py 的輸出。

DLM Load 7 Portable