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 runtime
go run ./cmd/foundry validate crawler-policy
go run ./cmd/foundry validate motion
go run ./cmd/foundry validate quality
go run ./cmd/foundry validate scaffolds
go run ./cmd/foundry validate tasks
go run ./cmd/foundry validate block-contracts
go run ./cmd/foundry validate block-governance
go run ./cmd/foundry validate content-kits
go run ./cmd/foundry validate creative-lane
go run ./cmd/foundry validate compatibility-fixtures
go run ./cmd/foundry validate feature-flags
go run ./cmd/foundry validate shell
go run ./cmd/foundry validate section-families
go run ./cmd/foundry doctor --json
go run ./cmd/foundry release-check --json
node scripts/foundry-doctor.js
node scripts/validate-preview-runtime.js
node scripts/validate-workflow-contract.js

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 doctor --browser-smoke --require-browser --json

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 validators, Go doctor, Go release-check, and node scripts/foundry-doctor.js backstop pass clean.
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 release (current target: v0.1.51).
8. Update pins in downstream sites only when approved through the bundle process.