Happier Release Validation

Happier Release Validation

This is the repository-owned entrypoint for the public release contract's manual-only deep profile. It does not publish, promote, deploy, submit stores, or create a release operation.

Start from the target contract

From the explicit release checkout, inspect the target-owned profile and its executable suite inventory:

node scripts/pipeline/run.mjs release-contract
node scripts/pipeline/run.mjs release-validate --profile deep --dry-run

deep is not part of normal release dispatch. This skill is its manual entrypoint; the registry does not pretend that semantic compatibility or human QA can be decided by a script.

For general release preparation or approval, first use the installed private maintainer authority:

hmaint release bootstrap --repo <absolute checkout> --json

Read and follow the returned private skill for general release preparation or approval. This repository skill remains the target-owned deep-certification entrypoint only.

If hmaint is unavailable, stop and obtain the approved maintainer-tool installation; do not substitute a copied release workflow or arbitrary shell commands.

Manual certification

1. Record the release source SHA and every independently versioned component changed by that source. Resolve supported stable/preview baselines to immutable tags/artifacts; a rolling tag is discovery only.
2. Read docs/compatibility.md, map only reachable old/new directions, and perform the target-owned suite commands for affected automatic-capable surfaces. Record unrun or unavailable proof as such.
3. Use the non-mutating deep profile in tests-dispatch.yml for complete in-repository source certification. Run credentialed live-provider scenarios separately through their explicit provider-contract entrypoint when the affected surface requires them. Native/store publication is release work, not certification, and must not be invoked from this skill. Keep editorial judgement, release-note wording, and subjective compatibility assessment human-reviewed; do not encode them as prose/style tests.
4. For every manual scenario, preserve practical evidence: source/baseline identity, command or observed user flow, result, and recovery/failure state. Use an existing release record when one exists; do not create a parallel ledger, lifecycle state, or certification authority.
5. Report passed, failed, skipped, and blocked checks to the maintainer. A manual certification is evidence for human approval, never the approval itself.

Boundaries

• Use the canonical scripts/pipeline/release-validation/validate-release.mjs path through scripts/pipeline/run.mjs; do not copy its suite selection into this skill.
• Manual deep certification validates the release source and the existing loaded stack. It does not create or install local release archives; publication automation owns the outputs it publishes.
• Run only discriminating compatibility vectors or live flows for affected, reachable directions. Do not manufacture a component or platform matrix.
• Keep certification evidence in the existing release record or final handoff. Do not create per-run plan, tracking, ledger, lane, or workspace machinery.
• Do not write release notes, tags, GitHub releases, credentials, deploy branches, or store submissions from this skill.