build-release-mindsetlisted

## The rule Build and release code has a different discipline than feature code: it must be reproducible, abortable, and reversible. A build that depends on whatever the last run left behind is unreliable by definition. Before you change a build step, ask what happens if it crashes halfway, and whether you could undo the release after it ships. ## Fires when Editing a build script, a release or packaging step, a publish flow, or CI config. ## How to apply - Start from a guaranteed clean state: remove stale artifacts and intermediates, restore any patched config, before you begin. - Smoke-test the smallest case first and abort fast if it fails; don't run the full matrix on a setup you haven't proven. - Version artifacts into timestamped outputs instead of overwriting, so rollback is trivial. - Validate outputs, not just inputs. A silently-empty artifact, or a "0 tests passed" nobody asserted on, is the worst failure mode and the easiest to miss. - Protect any global state you patch-and-restore with a lock, so a half-finished run doesn't leave the machine broken. - Know the rollback before you ship. ## Worked example A release script builds against eight SDK versions over an hour, then you discover the first one was broken from the start — the whole hour is wasted. A canary fixes it: build the smallest target first, and abort the run if it fails, so a broken setup costs two minutes instead of sixty. The same instinct catches a "0 tests passed" that would otherwise ship g