Defrag
整理一个机制、概念或职责，使它的实现、说明和目录归属重新清楚。目标是降低理解、查找和
修改成本，保留仍有效的行为、设计意图和必要依据；删除数量或目录整齐度不是目标。
主要产物是清楚的维护归属与闭合的入口、引用和实现关系。整理可能暴露设计问题，但
不能用合并文件、删除名称或移动目录代替决定一份责任是否仍然需要。
主流程
- 界定问题。 从用户请求中确定一个待回答的问题、范围、必须保留的行为和交付结果。
大范围工作先选一个能独立闭合的局部；不要为了开始而建立全仓地图。
- 恢复关系。 找到实际入口、消费者、维护位置、注册或动态加载、构建发布和相关说明。
先读能改变当前判断的片段；区分当前实现、目标设计、派生视图、生成物和历史依据。
- 判断碎片。 用来源证据判断对象是残留、重复、分散还是错位，同时记录最有力的保留
理由、影响和未知。没有引用、很久未改或文件很短都不足以证明失效。
- 处置并收束。 用户只要求 review 时交付发现和建议；要求整理时执行最小的完整修改，
补齐入口、引用、构建和测试关系。沿同一个问题复查，说明已确认、未确认和验证边界。
按需读取
只在当前问题需要时读取 supporting docs：
这些资料是本技能的操作参考，不是调研记录或第二份项目权威文档。项目级约定仍以当前仓库
的 AGENTS.md、模块 README 和实际源码为准；不要为了使用本技能加载与问题无关的整套文档。
不变量
- 保留他人的未完成改动；修改前后检查工作区状态和差异。
- 不删除用户数据、未确认失效的入口或仍承担回归价值的测试。
- 实现证明当前行为，设计说明目标；两者冲突时核对迁移状态，不能用其中一方替代另一方。
- 机械检查、运行时观察和用户验收分别报告；没有证据就保留未知，不把推测写成结论。
- 用户已经授权的局部整理直接推进；只有超出范围、改变公开契约或涉及不可逆动作时才停在
边界说明。
完成条件
当原问题可以回到负责位置、相关引用已经闭合、必要修改和验证完成，并且未决依赖与重开
条件已写清时，结束本次局部整理。发现新的产品需求或更大范围争议时记录关联，不在本轮
偷偷扩张范围。
若清理前尚需决定各单元承担什么、怎样组合或拆分，按需使用
architecture，提供当前消费者、有效承诺与冲突。
若既有机制的必要性或核心选择被反例击穿，使用 design-forge；
不要先清理掉它再论证合理性。若争议是重复校验究竟保护不同边界还是误阻工作，使用
assurance-review。回到整理时沿用已核实的决定与证据，
不从头审查；链接不要求每次清理都加载相邻方法。
Defrag change and verify
用户要求实际整理时使用这份参考。它约束修改的完整性，不规定固定命令或固定测试数量。
修改前
- 检查
git status --short 和相关 git diff，识别并保留他人的未完成改动。
- 先确认对象身份、消费者、权威来源、公开契约和失败处理；不因为删除方便而改变它们。
- 选择一个能暴露错误整理的行为基线。无法取得基线时记录限制，不假装完成。
修改时
- 优先合并重复规则、修正归属、补齐引用和入口；只有负担确实降低时才移动或拆分文件。
- 同一语义变化一起修正调用方、构建配置、测试、文档链接和注册入口。
- 已确认失效的内容才删除；仍有决策价值的历史依据退出当前指导入口但保留可回查位置。
- 不把可疑对象全部移入 archive 来制造“完成”，不新建第二份权威文档或永久台账。
- 用户授权范围内直接推进；发现新产品需求、更大设计争议或不可逆风险时记录并收窄本轮。
修改后
- 沿修改前的问题重新定位入口、规则、例外和依据；确认维护责任没有变得更分散。
- 做一次有边界的关系回看：确认合并后谁维护规则、其他消费者是否仍保有需要的区别、
仍有效的迁移计划是否被错误宣布结束。只扩展到能改变当前判断的关系，不建立全仓图。
- 运行与语义变化相称的定向检查。优先验证能暴露错误删除、错误路由、链接断裂、构建
入口丢失和运行时行为回归的检查。
- 选择一个原本容易误判的真实问题，检查整理后能否从入口找到负责位置、规则与依据，
并完成原来的判断。没有前后对照时只报告这次观察，不宣称理解成本已被证明降低。
- 区分格式/类型/测试通过、运行时观察和用户验收；未验证内容保留为未知。
- 最后再次检查
git status --short 和相关差异，交付修改、保留理由、验证结果和未决项。
Defrag evidence
用这份参考判断一个对象是否应该保留、合并、移动或退出当前维护入口。它只规定调查时需要
回答的问题，不要求为每个任务生成完整调用图。
先形成一个问题
写出当前要回答的一个问题，例如：
- 这份设计是否仍对应当前实现？
- 这条规则是否由多个位置独立维护？
- 这个入口是否仍有消费者，还是已经被另一条路径替代？
- 目录和名称是否把维护责任指向了错误的位置？
每次展开前说明新材料可能改变哪个判断。找到足以支持结论的证据后停止扩展；上下文压力
不是删除依据，缺少关键证据时保留对象并标记未知。
恢复最小关系
按需要核对：
- 实际入口和直接消费者；
- 规则、事实或状态的维护位置；
- 注册、动态加载、构建、发布、配置和持久化入口；
- 当前实现与设计目标的关系；
- 测试、运行时观察和仍有效的失败教训。
目录位置只是线索。代码导入、HTTP/运行时调用、进程入口和交付单元要分别确认；文件出现
在某个目录不等于它属于该目录的独立职责。
先区分独立维护的重复规则与面向不同受众、目的、行动或媒介的同源视图。后者可以保留，
但应能找到来源和更新关系；不要因为事实相同或文本相似就强行合并。也先判断载体是否合适，
再判断目录是否合适：设计解释、实施计划、操作方法和状态记录不必共用一种文件形式。
四类判断
- 残留： 已被替代或放弃，但仍占据当前入口的实现、配置或说明。确认替代路径和仍可能
依赖它的外部入口后，才建议删除或退出维护路径。
- 重复： 同一事实或规则在多个位置独立维护，可能产生分歧。先确认它们是否服务不同
使用场景；不同受众的表达可以保留，但应有一个权威来源。
- 分散： 完成一项职责必须跨多个不合理位置拼接。优先收回规则和维护责任，只有实际
降低查找或同步成本时才移动文件。
- 错位： 名称、目录、说明和实际职责不一致，或目标与现状没有被区分。修正入口、链接
和表述，不把未来目标改写成当前事实。
删除与迁移的反事实检查
准备删除、压缩或迁移一段内容时，问：去掉它后，下一个使用者是否会改变判断或行动，或者
失去解释当前约束、例外、反例、失败处理或替代原因的依据？若会，保留内容或保留能回到
原依据的路径。判断“死”之前分开当前指导、未来目标和历史依据；旧方案可能退出当前入口，
但仍是解释迁移决定的必要依据，不必统一搬进 archive。
结论记录
每个重要发现至少保留：对象和位置、观察依据、判断类型、实际负担、建议动作、最强保留
理由、证据强度和未知依赖。没有引用、很久未改、文件很短或文本相似，单独都不足以证明
失效或同责。
Defrag report
报告服务于当前任务，不创建永久台账，也不复制源文件。按需要保留以下部分。
Review
范围：<本次检查的机制、概念或职责>
问题：<需要回答的问题>
已确认
- <对象>：<证据位置>；<残留/重复/分散/错位>；<实际负担>；<建议>
保留理由与未知
- 保留：<仍有效的消费者、行为或决策依据>
- 未知：<尚未确认的入口、外部依赖或运行时行为>
未决与重开条件
- <什么新证据会改变判断>
Change
在 review 内容后补充：
实际修改
- <文件或符号>：<语义变化和归属变化>
验证
- 机械：<格式、类型、静态检查或定向测试>
- 运行时：<实际打开、执行或观察到的行为>
- 用户验收：<已确认或尚未确认的使用结果>
只写本轮真实完成的内容。没有运行时或用户证据时明确说出，不用“测试通过”代替全部验收。