Local Core release verification

Status: canonical local release-verification lane

Core verification runs locally. GitHub Actions workflow definitions are retired under the owner’s 2026-11-08 instruction to stop using Actions. The repository setting is a separate administrative fact; foundry validate workflows checks repo-visible policy without contacting GitHub or changing account settings. Existing workflow runs remain historical evidence for their exact source and environment. They are not prerequisites for this local lane.

Use Go, Hugo, Git, system tools and the maintained Python browser helpers. No Node, package manager, external CI service or virtual machine is required. This guide changes execution ownership; it does not turn an unavailable or failing check into a pass.

Freeze And Identify The Candidate

Use the owning isolated checkout. Commit the reviewed source, record its commit and tree, and confirm that tracked files are clean. Inventory active untracked or ignored build inputs as well; generated proof files are not customer source. Stop if an unreviewed file can change the build. Create a unique evidence directory and stop on any failed command rather than overwriting earlier proof.

Record git rev-parse HEAD, git rev-parse HEAD^{tree}, foundry version --json, go version, go env GOOS GOARCH, hugo version, the relevant browser/app and driver versions, and selected input hashes. Bind each result to its actual source and tool identities. A directory name or OS label does not identify an executable or browser session.

Required Local Core Lane

Run the existing release commands against the frozen candidate:

go test -count=1 ./...
hugo --quiet
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

The last command owns the aggregate source, rendered-fixture, documentation, Actions-policy and required native-browser checks. Do not also run the ordinary aggregate, doctor aggregates or every focused validator as duplicate release proof. Use focused commands while diagnosing a failure. Report toolchain lifecycle warnings explicitly; a newer installed Hugo does not change the tested baseline.

Follow the Visual Change Protocol for declared visual evidence. The native Chromium helper is scripts/check-motion-and-visuals.py. Materialize retained fixtures with foundry validate compatibility-fixtures --keep-temp --json when the capture helper needs their build paths; that render supplies capture inputs, rather than another independent qualification result. Use an isolated exact-source mirror for reference captures, a matching driver, and the current manifest’s complete declared matrix. Preserve source/helper/driver/browser/viewport/image hashes and settled/render checks, inspect affected views, then run foundry validate visual-examples --json. A current required matrix cannot be replaced by a focused screenshot or an older receipt with changed inputs.

Native Keyboard Environment

Coordinate ownership before starting a Safari automation session. Preserve other owners’ sessions and user preferences. The local desktop must be awake and unlocked, and the owned automation document must be visible and focused for keyboard focus-indication evidence. A locked or hidden desktop can still receive WebDriver actions; reaching an active element alone does not establish visible keyboard indication. Inspect the bounded documentHasFocus and documentVisibility failure diagnostics before attributing the result to CSS. Do not unlock, wake or change another owner’s desktop automatically. Wait for the usable environment, then execute the unchanged required gate; retain the failed environment’s result separately. Capture only the selected settings needed to interpret the test, for example on the local Mac:

safaridriver --version
defaults read NSGlobalDomain AppleKeyboardUIMode
defaults read com.apple.Safari WebKitTabToLinksPreferenceKey

An absent preference is an observation, not an instruction to create it. Record the selected native_sessions in fixture JSON and the aggregate observed-session detail. Distinguish these from an installed-app or published-image inventory; missing session identity remains unreported. Do not dump all preferences.

The slideshow scenario seeds the actual preceding dot, sends native Tab directly onto Next, and requires the active target, :focus-visible and a visible outline. The execution profile must satisfy those exact requirements. No subsequent target script focus, synthetic key substitute, preference write, forced style, fallback-until-pass, skip or weaker threshold qualifies it. If the local profile cannot execute the required path, report the lane blocked and investigate the actual target/events; do not normalize the failure away.

Apple documents that Tab and Option-Tab navigation depends on keyboard settings and Safari’s all-items option. That is an environment lead, not a diagnosis or permission to change a desktop. See Apple’s keyboard guide.

The supported test profile is the one actually measured and recorded. Measured profile evidence does not qualify an untested environment. A local Safari pass does not establish every Safari version or keyboard configuration, an assistive-technology result, or universal browser compatibility. No visitor browser support floor is raised by this guide.

Go Portability Evidence

Run the full Go suite natively on the local host. Also compile and link the test binaries for the portable Windows and Linux targets without executing them. After creating fresh output directories, these commands use Go’s -c mode, which does not run test binaries:

proof_dir="var/portability-$(date -u +%Y%m%dT%H%M%SZ)-$$"
mkdir "$proof_dir"
mkdir "$proof_dir/windows-amd64" "$proof_dir/linux-amd64"
GOOS=windows GOARCH=amd64 CGO_ENABLED=0 go test -c -p 2 -o "./$proof_dir/windows-amd64/" ./...
GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go test -c -p 2 -o "./$proof_dir/linux-amd64/" ./...

Stop if directory creation fails; never reuse an earlier proof directory. Record target, compiler, source hash, exit status and artifact identity. Do not use a successful stub runner or call cross-compilation a test execution. It proves build/link portability, with runtime behavior unexecuted. No Linux VM is needed for this evidence.

Earlier native Windows/macOS receipts may support only the source, tests and conditions they actually executed. Compare selected bytes before reuse. Changed policy/CLI tests need current local tests and compilation; an unchanged renderer does not make an older full-suite result current for new validation code. When a change depends on foreign-OS behavior, obtain actual native execution before claiming that behavior qualified, or keep the specific gap open.

Known Hosted Traversal Gap

The earlier c50c3e272ded193c8a84aa284289dace2ec8e577 hosted native Tab run failed to reach slideshow Next. Retiring Actions does not fix or erase that failure. The job ran on macOS 26.7.2, image 20261102.0473.1; its pinned image inventory lists Safari/SafariDriver 27.2. The actual session version was not logged. Calling this a Safari 26 result from its OS/runner label is unsupported.

The later diagnostic jobs never started. Local Safari 27.0.1 success establishes only that measured profile and does not explain the failed hosted environment. Preserve the issue and diagnostic evidence. Release review must retain this unresolved qualification gap and the measured local boundary; it must not claim that an unexecuted diagnostic fixed it.

Release Handoff

Retain exact commands, exit status, reports, warnings, input/artifact hashes and reviewed limits outside the frozen source tree. Confirm no tracked source changed after the gates. Re-run only the affected final lane when new source or evidence requires it. The release owner reviews the declared profile and open gaps before the immutable tag and matching GitHub Release. Distribution adoption, consumer deployment, private media runtime and live workflow acceptance remain separate.

Complete the current documentation release handoff with the owning portal release owner. Account for the new Core tag in the release coverage ledger, coordinate a new immutable docset/renderer pin, and verify the actual public HTTPS routes after deployment. Preserve historical manifests and docset locks. Preparing or tagging Core does not establish portal publication.

Foundry Control opportunity: Control can consume these portable receipts for managed review, permissions, publishing and care. Core’s local verification remains usable without Control.