anti-entropy-governance

反熵

概述

当任务不只是“修改代码”，而是“在不增加熵的前提下安全移除旧路径”时，使用此技能。

此技能在以下选项中做出选择：

• 内部代码退役采用 delete-first
• 对有证据支持的外部依赖边界采用 compat-exception
• 对不可逆状态，或无法观察其分布式使用方的外部契约，采用 confirmation-first

此技能不能替代 brainstorming、writing-plans、systematic-debugging 或 verification-before-completion。它是一个范围狭窄的治理技能，负责退役、回退路径收敛、重复责任方清理和删除安全。

适用情形

符合以下任一情况时使用：

• 应退役旧逻辑、重复责任方或过时的回退路径
• 候选修复方案是在“删除旧路径”和“再增加一个回退路径”之间选择
• 内部关键词／短语／触发器逻辑正被结构化逻辑取代
• 已有新的规范责任方，而旧责任方可能仍承载实际行为
• 清理、迁移或弃用任务涉及架构、持久化、事实来源或外部兼容边界
• 任务可能混淆代码退役与实时数据删除

以下情况不要使用：

• 无需决定是否退役的纯增量功能开发
• 微小的措辞修改
• 简单的状态查询或只读问答
• 不涉及责任方收敛、回退路径清理或删除选择的常规 Bug 修复

自动组合边界

此技能应由其他责任方组合调用，不应成为新的全局热路径入口。

优先由以下技能组合调用：

• brainstorming：涉及退役或持久化风险的方案选择
• writing-plans：会删除旧路径或涉及架构／迁移／持久化的计划
• systematic-debugging：诱人的修复方案是增加回退路径，或在删除与保留之间选择时
• verification-before-completion：清理／退役／兼容性／迁移收尾

当任务涉及责任方收敛、回退路径移除或架构／持久化／事实来源边界时，自动加载。自动加载仅用于识别和提供建议；破坏性执行仍需用户明确授权具体范围。

核心原则

默认减少内部熵，而不是保留内部历史。

退役应先界定责任，再界定承载者。先指出已过时或重复的责任主体。如果同一承载者还有独立证据支持的正当职责，就移除无效职责，只保留该职责范围内的能力；这不属于兼容性例外。若承载者不再承担任何正当职责，则对其采用 delete-first。仅仅存在未知使用方，并不足以成为保留内部承载者的理由。

按以下规则处理：

• 内部代码退役 → delete-first
• 外部兼容边界 → 有活跃依赖证据时采用 compat-exception；已证实存在分发但无法观察使用方时采用 confirmation-first
• 持久化状态或不可逆的事实来源对象 → confirmation-first

仅仅未知，既不能证明存在外部依赖，也不能阻止内部采用 delete-first。一旦已证实存在分发，无法观察的使用方也不能证明删除安全：应进行只读检查。编辑之前，必须要求用户亲自提供范围明确的授权，并明确接受具体的外部风险。知情指令可能已经提供了此类授权；否则，应披露风险并请求范围明确的确认。

提及、加载或讨论破坏性操作规则，都不构成破坏性执行的授权。若用户未明确确认具体范围：

• 不执行任何不可逆删除
• 不调用任何破坏性工具
• 不将可执行的破坏性命令作为下一步操作给出
• 不将笼统的同意曲解为删除批准

删除类别

首先对删除目标进行分类：

• code-retirement

  • 源代码
  • 内部触发器
  • 重复的所有者
  • 过时的回退分支
  • 仅用于兼容的载体
  • 与已移除的内部行为相关的废弃测试／配置

• contract-carrying code

  • 架构定义文件
  • 迁移文件
  • 公共 API 契约代码
  • 宿主安装／发现代码
  • 持久化读写逻辑

• live-state mutation surface

  • 会修改实时数据库、对象存储、队列或其他持久状态的代码或命令

• derived-state

  • 可重建的缓存
  • 生成的索引
  • 临时导出文件
  • 可重新计算的产物

• persistent-state

  • 实时数据库表／列／行
  • 作为事实来源的对象存储文件
  • 用户记录
  • 权限／身份／成员资格记录
  • 审计／计费／不可逆业务记录
  • 不可重建的队列或事件内容

各类别的默认处理路径

• code-retirement -> delete-first
• contract-carrying code -> 根据核心原则进行分类；仅涉及内部行为的退役使用 delete-first，并进行高风险验证
• live-state mutation surface -> 检查并分类；如果会影响持久状态，破坏性执行仍需确认
• derived-state -> 先验证是否可重建，再作决定
• persistent-state -> confirmation-first

硬性停止条件

如果目标属于 persistent-state 或其他不可逆的事实来源对象：

• 不要自动执行删除
• 不要将可直接运行的破坏性命令作为下一步操作输出
• 不要调用破坏性工具
• 不要将笼统的同意视为确认
• 要求用户明确确认具体范围
• 相关情况下要求提供备份／回滚／迁移说明

需要确认的示例：

• DROP TABLE
• DROP COLUMN
• TRUNCATE
• 批量删除真实业务数据
• 删除作为事实来源的已上传文件
• 删除权限、身份、审计、计费或成员资格记录
• 清除不可重建的队列或事件流

数据销毁防护

当 confirmation-first 用于保护持久状态或不可逆的事实来源对象时，停止正常的退役流程并输出：

Data Destruction Guard:
- Target Class:
- Exact Target(s):
- Environment:
- Why Irreversible:
- Backup / Rollback Note:
- Allowed Read-Only Next Steps:
- Blocked Destructive Steps:
- Confirmation Required: yes
- Status: awaiting scoped confirmation

只有用户明确确认具体范围后才能继续。笼统同意，例如“OK”、“继续”或“听起来不错”，均不足以构成确认。只要范围发生任何变化，之前的确认即失效，必须重新确认。

反熵声明

删除前，声明：

Anti-Entropy Declaration:
- Deletion Class:
- Old Path/Object:
- Invalid Responsibility / Authority:
- Legitimate Capability Remaining on Carrier:
- New Canonical Owner:
- Expected Preserved Behavior:
- Expected Retired Behavior:
- External Boundary Touched: no | yes
- Source-of-Truth Data Risk: none | possible | confirmed
- User Confirmation Required: no | yes

对于外部依赖未知的代码，除非用户自己的指令已明确指出具体的外部风险、接受可能造成的破坏并授权确切的退役范围，或用户在你披露风险后另行给出具体范围的确认，否则将 User Confirmation Required 填为 yes。笼统的原始删除请求不能满足此项要求。不要仅凭用户知晓存在外部使用，或凭你自己的风险摘要，就推断用户已接受风险。

如果 User Confirmation Required: yes，则停止正常的 delete-first 流程。持久状态或不可逆目标进入 Data Destruction Guard；外部依赖未知的代码则停留在下方的 Retirement Decision 流程中。

退役决策

仅选择一种路径：

Retirement Decision:
- Path: delete-first | compat-exception | confirmation-first
- Why:
- Non-edits:

规则：

• 对内部退役选择 delete-first，除非有更严格的边界阻止
• 只有在外部依赖已得到证实时才选择 compat-exception
• 对不可逆目标，或对已证实存在分发但无法观察其使用方的目标，选择 confirmation-first

如果 Path = confirmation-first，在获得具体范围的确认之前，不得进行任何破坏性执行。对于外部依赖未知的代码，之前笼统的删除指令不算数。用户充分知情且范围明确的指令，可以在你披露风险前构成确认；否则，应披露风险，并直接要求用户在编辑前确认确切的退役范围。不要只说明需要确认，也不要照抄所需的确认措辞。

验证计划

不要只通过“测试全部通过”来验证。要确认旧逻辑确实已失效，而新归属方确实承接了该行为。

Verification Plan:
- Main-path check:
- Lingering-reference check:
- Negative check:
- Boundary check:

含义：

• 主路径检查：新的规范归属方仍满足预期行为
• 遗留引用检查：已退役的职责不再生效；如果其承载方已删除，则主路径上不再引用旧路径
• 负向检查：已退役的触发条件／路径确实不再起作用
• 边界检查：宿主／API／架构／持久化边界未遭意外破坏

缺口分类

删除后如出现缺口，修复前先对其分类：

• 预期退役
• 归属方逻辑缺失
• 内部消费者过时
• 基线缺口
• 外部兼容性
• 持久化状态风险

持久化状态风险是停止条件，不是常规修复分支。

缺口闭环

修复顺序：

• 预期退役
  • 更新测试、文档或调用方预期
• 归属方逻辑缺失
  • 修复新的规范归属方
• 内部消费者过时
  • 迁移内部消费者
• 基线缺口
  • 先修正需求／规范／基线
• 外部兼容性
  • 仅在存在当前有效的外部依赖证据时允许保留兼容性
• 持久化状态风险
  • 停止并请求用户确认

使用此约定：

Gap Closure:
- Gap Found:
- Gap Type:
- Repair Action:
- Reintroduced Compat: no | yes
- If yes, External Dependency Evidence:
- Retirement Trigger:

如果 Gap Type = persistent-state-risk，请停止并返回确认关卡。不要擅自进行破坏性修复。

兼容性例外关卡

仅当以下条件全部满足时，才允许保留：

• 涉及外部边界
• 存在当前有效的依赖证据
• 删除会破坏已发布或有文档记录的约定
• 当前工作切片无法完成归属方修复或消费者迁移
• 存在观测指标
• 存在退役触发条件

若不满足这些条件，则不要保留兼容性。

完成语义

完成声明必须反映实际结果：

• 内部退役但保留旧兼容逻辑 -> 有限缓解或延期债务，而非彻底退役
• 有充分证据支持保留外部兼容性 -> 有限兼容性例外
• 未经范围明确的确认就删除持久化状态 -> 尚未完成

常见错误

不要：

• 把未知依赖当作存在依赖的证据
• 把缺少有效依赖证据当作已证明的外部边界上可安全删除的证据
• 为了“安全”而让两个归属方同时生效
• 在确认缺口是否应由新归属方处理之前就添加回退逻辑
• 混淆删除迁移文件与删除线上数据库
• 把清理事实来源数据当作普通代码退役
• 旧逻辑仍承载主路径行为时，声称任务已“清理完毕”
• 仅因某个载体上的一项权威依据无效就删除该载体，而其上仍有另一个有独立证据支持的合理角色
• 把警告或防护卡片当作破坏性操作授权

最简报告格式

此格式是反熵工作流的决策界面，不是单独的最终完成报告。如果反熵流程对已完成任务有实质影响，应将其保留／退役的行为、删除类别、保留的边界、验证计划和剩余风险纳入 verification-before-completion 的统一 Aegis 影响／安全回执。

Aegis Visibility:
Anti-Entropy Declaration:
Retirement Decision:
Verification Plan:
Gap Closure:

默认使用精简格式。仅在任务风险需要时展开。