cli-audit-hanoi

Hanoi Audit

Audit the order of operations, not the operations themselves. The same steps, intelligently stacked, produce something concise, clean, and fast; badly stacked, they produce rebuild storms, restart loops, and bloat.

Model: a Tower of Hanoi. Each step is a disk. Disk size = stability × redo cost. Touching a disk forces every disk above it to be redone. And in a multi-techno stack, the towers themselves stack: code → build → image → orchestrator → config management. A move skipped in a lower tower reappears in every tower above it.

Read ../gotchas.md before producing output — the conservation law applies doubly here: a reorder is only justified by measured rework, never by aesthetics.

The Three Laws

1. Big disk first (stability ordering). Order steps by change frequency and redo cost: stable and expensive at the bottom, volatile and cheap on top. Every inversion — a frequently-edited step sitting below a costly stable one — taxes each edit with the full stack above.
2. No move before its prerequisite (topological legality). A step never executes before what it depends on. Crashloop-until-ready and "run it twice" are retry-based ordering: a Law 2 violation with a costume on.
3. Count the moves (economy). Hanoi has a known minimum (2^n - 1). Code has one too: one change should redo only itself and what truly depends on it. Every extra restart, cache invalidation, re-download, or recompile is a wasted move.
4. Conservation of responsibility (multi-techno displacement). A capability the code does not provide does not disappear — it is compensated above, per tool and per environment, with weaker guarantees: shell instead of types, retries instead of contracts. No config reload in the app → checksum rollouts in kube and restart handlers in Ansible. No dependency retry in the app → wait-for-it in the entrypoint, an initContainer, and an Ansible until loop: the same missing move, paid three times.