Core release checklist

The canonical release verification path is in VALIDATION.md.

Run before any release:

go test ./...
go run ./cmd/foundry version --json
go run ./cmd/foundry authoring-contract --site . --core-version release-candidate --site-key foundry-core-release --commit-sha release-candidate
go run ./cmd/foundry preview-build-manifest --site . --site-key foundry-core-release --route / --json
go run ./cmd/foundry validate tooling
go run ./cmd/foundry release-check --json

release-check owns the aggregate Core, fixture, documentation, dormant workflow, report-contract, and Core evidence-contract checks. Do not precede it with the focused validators or either doctor aggregate; those commands are diagnostics and compatibility surfaces, not additional release proof. Use foundry validate documentation or foundry validate workflows only to diagnose a focused policy failure.

Best Framework promotion evidence is intentionally separate: it is run only when changing or promoting the measured subject, using the stable-promotion checklist in VALIDATION.md. It is not a general site-release dependency.

The compatibility fixture gate renders every fixture and runs both quality and discoverability validation over the resulting HTML. For a separately rendered site, also run go run ./cmd/foundry validate discoverability --rendered-root public --strict --json before release.

For browser parity:

go run ./cmd/foundry release-check --browser-smoke --require-browser --json

If the embedded Foundry preview integration changed, exercise its selection, keyboard, focus, and message behavior in the Go-driven browser lane and retain the exact browser receipt. Preview behavior never adds a package-manager dependency to Core.

For downstream consumer validation:

go run ./cmd/foundry release-check --site /absolute/path/to/site --json

See VALIDATION.md for the full regression review checklist and CI safety bar.

Current Release Surface

The release-facing CLI includes version identity, build, release check, doctor, inspection, page inventory and creation, portable authoring contracts, Creative and Local Service scaffolds, Local Service route/quality floors, bounded task reports and add-only applies, upgrade and drift reports, and focused validators. Keep CLI Reference, Features And Families, generated help, manifests, and tests aligned whenever that surface changes.

Subjective Lighthouse/content-quality checks and unimplemented extension or capability-pack behavior remain outside the current release gate unless a specific release promotes them into a documented, deterministic contract.

Administrative release steps

1. Confirm the Go test suite, tooling contract, and Go release-check pass clean. When preview integration changed, also run the explicit browser interaction evidence. Run a focused validator only to diagnose an aggregate failure.
2. Confirm the changed block, family, page, CLI, shell, flow, theme, motion, or SEO docs still match the current manifests and behavior.
3. If new blocks were added, confirm the block registry and block-family-manifest are updated.
4. Add or update the release notes and current installation pins.
5. While GitHub Actions is disabled in the repository settings, run the full checklist locally against the exact release tree and confirm the working tree is clean.
6. Record macOS, Windows, and Safari runner verification as deferred until GitHub Actions is deliberately re-enabled. Do not describe the dormant workflow definitions as executed release evidence.
7. Tag the approved release without moving an existing immutable tag, publish the matching GitHub Release, and record any temporarily incomplete administrative step explicitly.
8. Update pins in downstream sites only when approved through the bundle process.