DLM 加载 7 便携版是做什么的？

目的

锁定一个仓库并加载其自身的合同、约束、活动任务、清单文件和源锚点。此个人技能定义了加载方法；仓库状态完全归仓库所有。

结果治理门

应用共享的 DLM 结果治理。在 load-and-continue 之前、将上下文缺口视为阻塞之前、或每当加载行为服务于正式审查、委派、发布或其他外部状态决策时，请先阅读该文档。

将加载视为一次组合的身份/作用域安全检查，随后提供下一项实质性决策所需的最少事实。
当仓库/任务身份已稳定时，不要重复会话初始化、重新冻结权限或生成控制平面工件。
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/子任务和所需的清单条目。仅为了发现所有权、解决依赖关系或在已授权的队列中选择工作而读取待办事项/索引。临时诊断或问题不授权选择或执行无关的后备项。

当任务选择是用户请求或已授权队列的一部分时，按确定性顺序选择：

用户指定的 Epic/子任务；
当前对话中已锁定且仍活动的任务；
按仓库的待办事项/优先级/ID 规则排序的进行中任务；
使用相同顺序的依赖就绪的计划任务；
被阻塞的任务将连同其释放条件一起报告，不作为可执行任务处理。

如果在应用仓库规则后候选任务仍然并列，则显示最小的有用候选集，而不是通过文件时间戳或读取每个历史任务来猜测。

当前身份与恢复

当用户提供的项目没有 Git 元数据时，锁定其显式目录及其自身的 DLM 合同。将 Git 状态报告为不可用；永远不要采用父仓库或相邻仓库来制造身份。
使用 Epic/子任务 作为规范的任务身份。先在其所属 Epic 内解析旧的短依赖项，然后仅在全局唯一时进行解析。被多个 Epics 共享的裸 ID 需要消歧；不得静默选择第一个匹配。
当前的领先元表（或显式 ## 元 部分）是权威的。历史日志、存档计划和旧的冻结条目不会覆盖当前状态或验收。仅当下一项决策需要时，才读取历史证据。
当现有仓库拥有的 next / context 命令提供身份、依赖关系、阻塞项和读取顺序时，优先使用它。不要仅仅为了加载上下文而安装新命令，也不要将其输出视为变更权限。

任务深度挖掘

读取任务并定位 <context_manifest>。
对于 schema 2，要求匹配的 project、仓库相对 / 路径，以及每个条目对应的具体文件。
每个 <file> 都有 path、intent 和 required；section 和 defer 是可选的。
拒绝将绝对路径、..、目录、兄弟仓库、个人技能根目录和 .agents/skills 工作流文件作为任务上下文。
当前任务合同要求的缺失文件会阻塞受影响的深度挖掘/声明。缺失的可选文件，或没有当前消费者的无关管理记录，将变为警告。
defer="true" 仅在 required="false" 时有效；仅当当前决策需要时才加载它。
在有用的情况下并行读取独立文件。通过精确加载相关部分来遵守 section。

对于遗留清单，须遵循仓库的兼容性规则并报告差距。不要在加载时静默迁移。

以决策为中心的上下文与恢复

在必需的输入之后，围绕下一个实质性问题组织进一步阅读：适用的约束、证据与反证、缺失的事实以及下一个源条目。相关性本身并不构成充分性。在真正的恢复中，保留最后适用的证据和排除的失败路径；刷新已更改的依赖关系，而不是重复会话初始化。

对于证据重用、L2 知识变更或重复失败，请阅读证据与决策的相关部分。对于一组有用的明确标识的变更，scripts/dlm_impact.py --repo-root <仓库根目录> --changed-file <仓库相对路径的文件> --json 可以返回只读的 L2 审查候选，包括可选的 depends_on 传播。它不证明知识有效性，也不取代必需的清单输入。不要为每次常规读取都运行它。

源锚定

使用 rg、符号导航、项目文件、测试、日志和生成的证据来定位实现事实。
从狭窄的源读取开始。当生命周期、序列化、状态机或跨成员行为使局部摘录不安全时，读取完整文件。
区分文档声明、源事实、运行时证据和未解决的推理。
如果 DLM 与源不一致，报告不匹配，并从当前源/证据继续，除非任务明确以文档优先。

临时加载

在执行过程中，通过全局 L1/领域 L1 路由到最小的相关 L2 和源锚点。当仅一个领域决策需要更多上下文时，不要重复整个会话初始化。

验证与输出

当合同/清单的完整性对下一项决策很重要，或者用户请求了 DLM 验证时，运行仓库健康检查。将通用医生作为支持性的合同证据使用，而不是作为例行公事：

python -B -X utf8 <技能目录>/scripts/dlm_doctor.py --repo-root <仓库根目录> --require-contract

根据当前目标和合同对失败进行分类。相关的合同/路径失败可能会阻止受影响的 DLM 操作；无关的预先存在的或管理性警告不能使原本足够的工程上下文失效。

报告仓库/项目身份、所选任务及选择依据、已加载的约束和源锚点、缺失或过时的上下文、任何阻塞性差距的实质影响，以及原始任务是否将继续。一旦下一项决策拥有足够的上下文，停止加载并将精力返回到该工作上。

可选的 v2 账本简报（`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 加载 7 便携版