happier-release

# Happier Release Keep release policy simple: test source once, admit the operation cheaply, build immutable candidates once, verify once per trust boundary, promote independent products in parallel where the workflow permits, and recover without rebuilding valid work. ## Resolve authority first Inspect the public machine-readable contract with: ```bash node scripts/pipeline/run.mjs release-contract ``` Then resolve the private release authority for the absolute checkout: ```bash hmaint release bootstrap --repo <absolute checkout> --json ``` Use the returned private skill and its instructions as authoritative. The public contract defines targets, profiles, and compatibility intent; private operating procedure stays outside this repository. Do not publish from a dirty or protocol-incompatible maintainer-tools checkout. Bootstrap/preflight must bind the maintainer-tools commit and return structured admission failures before any release mutation. Do not modify or clean that checkout as an implicit part of releasing. ## Admit without repeating CI Before expensive candidate work, run the repository's cheap, non-mutating release preflight. It validates operation-specific inputs such as source/channel identity, version and notes projection, maintainer protocol compatibility, tools, credentials, external configuration, and selected runner/platform prerequisites. It must call canonical owners and must not repeat unit, typecheck, integration, or E2E work from source CI. Cons...