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 关闭发布 7 便携版