Kortix Release

How a clean, accurate production release happens. Two halves: what version (the bump philosophy) and how (notes derived from the real git log, then promote → deploy → verify). The release notes you write become the GitHub Release, which is exactly what the public /changelog page renders — so they must reflect what actually shipped, nothing invented, nothing missed.

Pairs with kortix-voice (how the notes read). The version source of truth is the root VERSION file; vX.Y.Z tags are immutable and map 1:1 to a commit + image.

0. Golden rule — prod ships ONLY via main → promote

The only way to change prod is: land it on main first, then run the Promote workflow (main → review-gated release PR → prod). Never git push …:prod, never open a manual PR into prod, never cherry-pick onto prod. prod must always be a strict subset of main — a direct-to-prod change makes them diverge (the fix lives in prod but not the trunk). This holds even for urgent outage hotfixes: commit the fix to main, then promote.