anti-entropy-governance

# Anti-Entropy

## Overview

Use this skill when the task is not merely "change code" but "remove old paths
safely without growing entropy".

This skill chooses between:

- `delete-first` for internal code retirement
- `compat-exception` for proven external dependency boundaries
- `confirmation-first` for irreversible state or an external contract whose
  distributed consumers cannot be observed

It does not replace `brainstorming`, `writing-plans`,
`systematic-debugging`, or `verification-before-completion`. It is a narrow
governance owner for retirement, fallback collapse, duplicate-owner cleanup,
and deletion safety.

## When to Use

Use when any of these are true:

- old logic, duplicate owners, or stale fallbacks should be retired
- a candidate fix is "delete old path" vs "add another fallback"
- internal keyword / phrase / trigger logic is being replaced by structured logic
- a new canonical owner exists and the old owner may still carry real behavior
- a cleanup, migration, or deprecation task touches schema, persistence,
  source-of-truth, or external compatibility boundaries
- the task risks confusing code retirement with live data deletion

Do not use for:

- pure additive feature work with no retirement decision
- tiny wording edits
- simple status or read-only Q&A
- normal bug fixes that do not involve owner collapse, fallback cleanup, or
  deletion choice

## Auto-Compose Boundary

This skill should be composed by other owners. It should not become a new
global hot-path entry.

Prefer composition from:

- `brainstorming` for approach selection involving retirement or persistence risk
- `writing-plans` for plans that delete old paths or touch schema / migration /
  persistence
- `systematic-debugging` when the tempting fix is fallback growth or
  delete-vs-retain
- `verification-before-completion` for cleanup / retirement / compatibility /
  migration closeout

Load automatically when the task touches owner collapse, fallback removal, or schema/persistence/source-of-truth boundaries. Automatic loading identifies and advises only; destructive execution still requires explicit scoped user confirmation.

## Core Principle

Default to reducing internal entropy, not preserving internal history.

Retirement is responsibility-scoped before it is carrier-scoped. Name the
obsolete or duplicated authority first. If the same carrier has a separately
evidenced legitimate role, remove the invalid responsibility and keep only
that role-scoped capability; this is not a compatibility exception. Apply
`delete-first` to the carrier once no legitimate responsibility remains.
Unknown consumers alone still do not justify retaining an internal carrier.

Use this rule:

- internal code retirement -> `delete-first`
- external compatibility boundary -> `compat-exception` with active dependency
  evidence; `confirmation-first` when distribution is proven but consumers
  cannot be observed
- persistent-state or irreversible source-of-truth object ->
  `confirmation-first`

Unknown alone neither proves an external dependency nor blocks internal
`delete-first`. Once distribution is proven, unobservable consumers also do not
prove deletion safe: inspect read-only and require scoped post-disclosure
confirmation before editing.

Mentioning, loading, or discussing destructive-action rules never authorizes
destructive execution. Without explicit scoped user confirmation:

- no irreversible deletion is executed
- no destructive tool call is made
- no runnable destructive command is emitted as the next action
- no broad assent is reinterpreted as deletion approval

## Deletion Classes

Classify the deletion target first:

- `code-retirement`
  - source code
  - internal triggers
  - duplicate owners
  - stale fallback branches
  - compat-only carriers
  - dead tests/config tied to removed internal behavior

- `contract-carrying code`
  - schema definition files
  - migration files
  - public API contract code
  - host install/discovery code
  - persistence read/write logic

- `live-state mutation surface`
  - code or commands that would mutate live databases, object stores, queues,
    or other persistent state

- `derived-state`
  - rebuildable caches
  - generated indexes
  - temporary exports
  - recomputable artifacts

- `persistent-state`
  - live database tables / columns / rows
  - source-of-truth object storage files
  - user records
  - permission / identity / membership records
  - audit / billing / irreversible business records
  - non-rebuildable queue or event contents

## Default Path By Class

- `code-retirement` -> `delete-first`
- `contract-carrying code` -> classify by the Core Principle; internal-only
  retirement uses `delete-first` with high-risk verification
- `live-state mutation surface` -> inspect and classify; destructive execution
  still requires confirmation when it reaches persistent-state
- `derived-state` -> verify rebuildability first, then decide
- `persistent-state` -> `confirmation-first`

## Hard Stops

If the target is `persistent-state` or another irreversible source-of-truth
object:

- do not execute deletion automatically
- do not emit a runnable destructive command as the next action
- do not call a destructive tool
- do not interpret generic agreement as confirmation
- ask for explicit scoped user confirmation
- request backup / rollback / migration note when relevant

Examples that require confirmation:

- `DROP TABLE`
- `DROP COLUMN`
- `TRUNCATE`
- bulk delete of real business data
- deleting source-of-truth uploaded files
- deleting permission, identity, audit, billing, or membership records
- purging non-rebuildable queues or event streams

## Data Destruction Guard

When `confirmation-first` protects persistent-state or an irreversible
source-of-truth object, stop normal retirement flow and emit:

```text
Data Destruction Guard:
- Target Class:
- Exact Target(s):
- Environment:
- Why Irreversible:
- Backup / Rollback Note:
- Allowed Read-Only Next Steps:
- Blocke