Run the release gate

Start from the behavior you can observe. The gate refuses dirty files, stale build output, failing tests, an already-used version, or unexpected tarball contents.

A release should be the output of repeatable checks, not a manual command run from an uncertain working tree. The useful target is not encyclopedic coverage. Make one deliberate choice, observe its consequences, and know which requirement would make you revise it.

It is tempting to publish first and plan to repair the package if consumers report a problem. That trades a clear decision for an assumption you will eventually have to debug. The stronger move is to run one release command that performs clean install, tests, build, pack inspection, consumer verification, and metadata checks. Make the boundary explicit in code and in the project notes.

Tie the decision back to the larger job: Publish an intentional immutable artifact with strong account controls and a release record you can verify. Record enough evidence that another developer can repeat the result without relying on your memory.

Start from a dirty tree and a stale dist file, then prove the release gate catches both before any network write. Repeat it once with an invalid or hostile condition and write down the boundary the failure revealed.