Release operator manual

One safe path from fix to fleet

Current inventory: Engine 2.1.13, Protocol 1.3.3, source b839b57. Private signing keys remain offline and installed sites remain independent of Studio.

Start in Studio

Create a release workspace from the approved system revision. Download its canary recipe; do not invent version or release identifiers.

Prepare offline

Run ./suds release prepare <recipe.json>. It clean-checks, double-builds, tests, packages, signs, independently verifies, and emits one release-bundle.zip.

Register and publish canary

Upload the one bundle, type the explicit confirmation, then publish only to canary. A Git merge by itself never produces a WordPress update.

Verify one controlled site

Check, download, prove invariance and tamper rejection, install, run compatibility and QA, rollback, reinstall, and confirm the audit evidence.

Promote exact bytes

Download the stable recipe and run ./suds release promote <recipe.json>. It emits only a signed stable manifest/signature; Studio copies the exact registered canary ZIP bytes server-side and refuses any digest, size, filename, or artifact-ID change.

Publish and close

Publish stable first, then revoke the superseded canary, close the run, and verify stable-entitled sites discover the update on their next explicit check.

Non-negotiable boundaries

Merge is not release. Studio is not a kill switch.

Never distribute rebuilt bytes under an existing version. Never upload private-key material, database secrets, enrollment codes, or site credentials. A control-plane outage may block discovery and downloads, but must never stop a completed WordPress site from rendering.