autonomous-self-improvement-loop-safetylisted

# Automation That Changes Itself Needs an Adversary, a Disposable Workspace, and a Human on the Merge When a loop generates changes to its own codebase, the ordinary gate is necessary but not sufficient: it edits the thing that edits, so a bug compounds and a confused or compromised worker can rewrite its own guards. Contain each cycle in a throwaway workspace, decide success by mechanism rather than the worker's word, bind what you tested to what you ship, keep an adversary looking for what the gate cannot see, and keep a human on the irreversible step. ## When to use Reach for this whenever automation acts on its own substrate: an agent that proposes edits to the repository it runs from, a self-updating deployment, a code-generation worker whose output is committed, any loop where the output modifies the next run's behavior. Red-flag thoughts — if you catch yourself thinking any of these, STOP and apply this skill: - "The worker said it made the change, so it did." - "The gate is green, so the change is correct." - "It edits the repo in place — cloning fresh each time is wasteful." - "We tested the branch; deploying from the cache is the same bytes." - "The prompt tells the worker not to touch the guards, so it won't." - "It can open the merge itself — a human reviewing every one is slow." - "I can edit the guard or hook that mediates this very cycle." (isolation must be enforcement-scoped, not merely workspace-scoped) ## The rule 1. **Run each cycle in a disposable,