Core release checklist

The canonical execution lane is Local Core Verification, with the regression contract in VALIDATION.md. GitHub Actions definitions are retired; existing CI results remain exact historical evidence.

Run before any release:

go test -count=1 ./...
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 --browser-smoke --require-browser --json

release-check owns the aggregate Core, fixture, documentation, workflow policy, 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.

The aggregate above requires actual native browser execution. Record its measured keyboard/browser profile, and complete the fresh Chromium and compile-only Go portability proof described in the local guide. An unavailable native lane is blocked; a local pass does not fix an earlier failing environment.

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 local 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. Run the full local checklist against the exact frozen release tree and confirm tracked source and active build inputs are unchanged.
6. Record native execution, compile-only portability and historical reused evidence separately. Compare exact inputs before reuse; unexecuted foreign tests and the unresolved hosted traversal failure remain explicit limits.
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.

Documentation release handoff

A Core tag does not update online documentation. For every production release, record its user-visible changes, compatibility/adoption steps and disabled or experimental scope in the owning release notes. Coordinate a new immutable Distribution manifest and the portal renderer pin; preserve historical manifests and docset locks.

In the documentation portal, account for every newly published Core and Control tag in catalog/release-coverage.yaml, regenerate its public release history with go run ./cmd/foundry-docs coverage --write, then run the coverage gate, projection generation, tests and both profile builds. Refresh authenticated source tags before the offline gate. Public deployment validates this ledger again; hosted periodic detection is not configured. Source/tag status, portal deployment, managed feature activation and consumer adoption stay separate.

After public deployment verify current stable, immutable release routes, relevant guides, search and public/internal isolation over HTTPS. Link that actual docs release evidence from the component release. A tag with a pending documentation handoff must be reported as such, never as an already refreshed portal.