Hard-won rules, generalized from production runs. The loop appends to this list itself — that is what "self-improving" means in practice.
A build/transform step can fail silently — a port conflict, a race, a half-written file — and leave an empty or partial artifact while still printing a success line. If you deploy on the strength of the log, you ship the broken thing.
Rule: before any deploy, assert a concrete property of the real output (non-empty, contains the expected content, correct size). The check is three seconds; the silent regression is hours.
Finding one odd-looking match (a stray word, an unexpected value) is not a mandate to run a sitewide find-and-replace. The match may be intentional; the context may matter.
Rule: before scaling a fix, check intent — read the surrounding comments, the constraints, the history. If the change touches prices, legal, or brand, it's an owner decision, not an autonomous one.
A task arrives with a premise ("this is a small, bounded fix"). Sometimes the premise is wrong — the "small fix" turns out to be a load-bearing rewrite, or touches far more than described.
Rule: when the goal contradicts what you actually find, surface it instead of blindly executing the larger change. Do the safe, in-scope part; flag the rest. Blind execution of an under-scoped task is how autonomous systems do real damage.
Some checks (audits, crawlers, end-to-end tests) assume a server is already running. If it isn't, every target fails with connection-refused — which looks like "everything is broken" but means "nothing is listening."
Rule: bring the server up, wait until it actually answers, then run the check. And never run a broad "kill all" cleanup in parallel with a step that started its own server — you'll kill its legs out from under it and misdiagnose the corpse as a bug.