Genesis Deslop
审查并简化选定的更改，不改变产品行为。Deslop 是显式的：永远不要仅仅因为实现完成就运行它。
在执行第一个 Genesis 操作之前，先解析调用方式。不要使用 Genesis 操作或 genesis --version 作为可用性探测。
- 读取仓库根目录的
package.json。仅当该清单的name为genesis-compiler，或其dependencies、devDependencies或optionalDependencies包含确切的genesis-compiler键时，才将 Genesis 视为项目锁定。 - 对于项目锁定的仓库，使用
npm exec --no -- genesis <参数>调用每个 Genesis CLI 操作。这样运行不会获取另一个包。如果声明的包未安装，报告项目的依赖尚未准备就绪；不要回退到其他 Genesis 版本。 - 否则，不要尝试
npm exec。运行command -v genesis（或当前 shell 的等效PATH查找）。当解析到可执行文件时，直接调用genesis <参数>。 - 当两个来源都不可用时，停止并报告 Genesis 不可用。切勿仅仅为了满足工作流指令而安装或更新 Genesis。
成功解析调用是常规操作。不要叙述 Genesis 是项目锁定还是位于 PATH 上，也永远不要将直接使用 PATH 描述为回退。仅在解析失败或用户明确询问时，才提及调用方式是如何选择的。
遵循配置的协作方法进行面向用户的更新，包括其技术深度和响应长度。报告具体的进展、发现或障碍；不要宣布你正在遵循指导。
加载一次有效项目指令
Deslop 请求可以是以完整的 Genesis 生成的提示形式到达，也可以是代理会话中的直接请求，例如 Deslop。
如果当前任务已包含 GENESIS CONTEXT 且其任务为 deslop，则直接继续使用它。不要生成另一个提示。
否则，在解析 Git 范围之前，使用上面的调用规则运行一次 Genesis prompt --task deslop 操作。对于纯粹的 Deslop 请求，不要传递请求参数。当用户命名了一个计数、提交或范围时，将该确切请求作为一个安全引用的参数传递。将打印的提示视为同一轮次的指令；不要分派给另一个智能体，也不要再次生成它。此步骤将所选技术栈的特定于技术的 Deslop 指导以及任何项目定制与下面的可移植合约组合在一起。
解析清理范围
在编辑之前检查 git status --short 以及暂存和非暂存的差异。工作目录脏是允许的；不需要先前的提交。保留现有的索引和不相关的工作。不要将暂存、储藏、提交或丢弃更改作为清理的前提条件或一部分。
按如下方式解析用户的范围：
- 没有明确范围时，仅选择您自己当前任务的更改，包括前面的轮次。这可以包括暂存和非暂存的编辑、新的未跟踪文件以及已经提交的任务更改。根据任务和编辑历史识别所有权，然后对照当前源代码和 Git 差异确认这些更改。整个脏差异、最新提交或 Git 作者身份都不能证明所有权。
- 保留用户或其他智能体所做的更改，包括同一文件中的编辑。如果无法确定所有权，询问要精简哪些更改。如果没有自己在此任务中的更改，报告没有需要精简的内容；不要静默选择最新提交或他人的工作。
- 显式的提交、first-parent 计数或范围优先于默认值，无论这些更改的作者是谁。
- “最后一个提交”表示
HEAD相对于其 first-parent。 - “最后 N 个提交”表示从这些 N 个提交之前的 first-parent 到
HEAD的净保留更改。 - 命名的提交表示该提交相对于其 first-parent。
- 显式的提交范围恰好是该范围。
- 根提交使用 Git 的根差异形式，因为它没有父提交。
检查已解析的更改和路径，以及在适用时检查提交身份。审查它们的差异、当前源代码、直接调用点、相关测试，以及受影响的 Program 和 Stack 上下文。对于显式的已提交范围，不要用普通的工作树差异替换选定的已提交差异。将清理应用于当前源代码，同时保留范围之外的编辑。如果重叠的编辑无法安全分离，询问该重叠问题，而不是仅仅因为仓库脏就阻止。
应用清理合约
应用随任务提供的工程方法。如果此技能被直接调用，请阅读 genesis/engineering.md 以及相关的项目上下文。清理必须减少或保持复杂性，绝不要引入所选配置文件或具体需求不需要的未经批准的机制。
在引入或整合抽象之前，查阅 .genesis/machine-city.json 或运行 Genesis index <名称或路径> 操作以查找现有的公共和内部函数。确认源代码及其调用点中的每个明显重复。
在所选更改的预期行为和范围内，不留任何重复的辅助函数、不清晰或难以推理的代码，以及与代码库既定模式相悖的代码。移除不必要的封装、废弃的脚手架、并行的框架管道和投机性抽象。在只有一个清晰模块就足够的地方整合所有权。不要为了小文件或间接层而优化；要为一个初级程序员都能理解的简洁、明晰的设计而优化。
清理不是第二次实现过程。所选更改限制了清理可能发生的位置；共享文件不会将不相关的编辑带入范围或授权该文件中的不同行为。Deslop 可以重新组织已经存在的行为；它不能完成、纠正或扩展行为。如果审查发现一个缺陷、缺失的行为、合约不匹配或测试缺口，将其报告为一个后续发现并保持原样，即使它在被更改的路径内或看起来与之前的实现相关。不要在 Deslop 期间实现该发现或更改测试以适应它。
应用由所选 Stack 提供的每个特定于技术的 Deslop 指令，并加载适用于框架和语言上下文的官方技术技能。Stack 指导丰富了此合约；它不能减弱行为保持的边界、更改所选范围或授权不相关的实现。
您可以编辑或删除实现和测试文件，如果这是最清晰的行为保持清理。如果移动或重命名所选源代码使得受影响的 Program 引用过时，则仅更新该引用或信息性的 Implementation 映射。不要更改 Blueprint 或 Program 的公共合约来为清理行为找借口。不要编辑 .genesis/、Git 元数据、依赖目录、生成的构建输出、保留的迁移历史或外部资源。不要削弱测试、公共行为或数据保证。不要创建第二个架构或执行不相关的重写。
将清理结果作为普通的未提交工作进行审查和后续的正常提交。永远不要修改或重写选定的提交。在有用时运行聚焦的检查。最终的声明检查仍可通过 Genesis verify 操作使用。总结已解析的范围和任何选定的提交身份、哪些内容变得更简单、更改了哪些文件、实际运行了哪些检查，以及保持不变的后续发现。