Validation

Tooling Direction

The canonical product tooling path is the Go foundry CLI. foundry check is the fast routine lane, and release-check is the portable Core release lane. Core does not use Node or package-manager tooling in either lane or in its explicit browser and evidence work.

See CLI Reference for every command, flag group, safety mode, and task report chain, and Tooling Policy for the enforced Go/Hugo-only boundary.

The repository also has a focused documentation contract gate:

foundry validate documentation

It keeps the canonical mission and seven top goals visible from human and agent entry points, verifies active-plan routing and historical-plan labels, and prevents current Core tag/install language from falling back to stale release candidate claims.

Current Go CLI surfaces:

go run ./cmd/foundry check
go run ./cmd/foundry check --json
go run ./cmd/foundry check --site /absolute/path/to/site
go run ./cmd/foundry doctor
go run ./cmd/foundry doctor --json
go run ./cmd/foundry doctor --site /absolute/path/to/site --json
go run ./cmd/foundry static-origin /absolute/path/to/site
go run ./cmd/foundry release-check --json
go run ./cmd/foundry release-check --site /absolute/path/to/site --json
go run ./cmd/foundry inspect --json
go run ./cmd/foundry inspect blocks --json
go run ./cmd/foundry inspect blueprints --json
go run ./cmd/foundry inspect scaffolds --json
go run ./cmd/foundry inspect discovery --json
go run ./cmd/foundry inspect motion --json
go run ./cmd/foundry inspect theme-tokens --json
go run ./cmd/foundry inspect crawler-policy --json
go run ./cmd/foundry inspect static-origin --json
go run ./cmd/foundry inspect link-opportunities --rendered-root public --json
go run ./cmd/foundry inspect --site /absolute/path/to/site --json
go run ./cmd/foundry inspect --site /absolute/path/to/site /route/ --json
go run ./cmd/foundry authoring-contract --site /absolute/path/to/site --json
go run ./cmd/foundry new-page --brief /absolute/path/to/brief.md --site /absolute/path/to/site --dry-run --json
go run ./cmd/foundry new-page --blueprint creative-work-detail --prompt --dry-run --json
go run ./cmd/foundry new-page --blueprint creative-work-detail --slug sample-work --title "Sample Work" --description "Project summary" --work-intro "Opening text" --artist-name "Artist" --primary-cta-url /contact/ --dry-run --json
go run ./cmd/foundry new-page --blueprint creative-work-detail --site /absolute/path/to/site --slug sample-work --title "Sample Work" --description "Project summary" --work-intro "Opening text" --artist-name "Artist" --primary-cta-url /contact/ --write --json
go run ./cmd/foundry scaffold creative-route-floor --site /absolute/path/to/site --artist-name "Creative Studio" --artist-role "Photographer" --primary-email hello@example.com --dry-run --json
go run ./cmd/foundry scaffold local-service-route-floor --site /absolute/path/to/site --business-name "Local Business" --service-name "Primary Service" --city-name "Sample City" --region-name "Region" --primary-phone "(555) 555-0100" --dry-run --json
go run ./cmd/foundry validate runtime
go run ./cmd/foundry validate runtime --json
go run ./cmd/foundry validate math --site /absolute/path/to/site
go run ./cmd/foundry validate math --site /absolute/path/to/site --json
go run ./cmd/foundry validate crawler-policy
go run ./cmd/foundry validate crawler-policy --json
go run ./cmd/foundry validate static-origin
go run ./cmd/foundry validate static-origin --site /absolute/path/to/site --json
go run ./cmd/foundry validate discoverability --rendered-root public
go run ./cmd/foundry validate discoverability --rendered-root public --strict --json
go run ./cmd/foundry search build --rendered-root public --pagefind /path/to/pagefind --json
go run ./cmd/foundry validate search-index --rendered-root public --json
go run ./cmd/foundry discovery-changes --before-rendered-root previous-public --after-rendered-root public --json
go run ./cmd/foundry validate motion
go run ./cmd/foundry validate motion --json
go run ./cmd/foundry validate quality
go run ./cmd/foundry validate quality --json
go run ./cmd/foundry validate scaffolds
go run ./cmd/foundry validate scaffolds --json
go run ./cmd/foundry validate tasks
go run ./cmd/foundry validate tasks --json
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 task improve-page --dry-run --site fixtures/compatibility/utility-service-theme-proof --path content/_index.md --json
go run ./cmd/foundry task validate-improve-page-report --report <saved-improve-page-report.json> --json

Critical Verification Path

The Go CLI owns the public human/JSON surface for Core validation, inspection, page generation, scaffold preflight, report contracts, and narrow add-only task apply behavior:

go run ./cmd/foundry check
go run ./cmd/foundry check --json
go run ./cmd/foundry check --site /absolute/path/to/site
go run ./cmd/foundry doctor
go run ./cmd/foundry doctor --json
go run ./cmd/foundry doctor --site /absolute/path/to/site --json
go run ./cmd/foundry release-check --site /absolute/path/to/site --json
go run ./cmd/foundry inspect --json
go run ./cmd/foundry inspect scaffolds --json
go run ./cmd/foundry inspect --site /absolute/path/to/site --json
go run ./cmd/foundry authoring-contract --site /absolute/path/to/site --json
go run ./cmd/foundry new-page --brief /absolute/path/to/brief.md --site /absolute/path/to/site --dry-run --json
go run ./cmd/foundry new-page --blueprint creative-work-detail --prompt --dry-run --json
go run ./cmd/foundry new-page --blueprint creative-work-detail --slug sample-work --title "Sample Work" --description "Project summary" --work-intro "Opening text" --artist-name "Artist" --primary-cta-url /contact/ --dry-run --json
go run ./cmd/foundry scaffold creative-route-floor --site /absolute/path/to/site --artist-name "Creative Studio" --artist-role "Photographer" --primary-email hello@example.com --dry-run --json
go run ./cmd/foundry scaffold local-service-route-floor --site /absolute/path/to/site --business-name "Local Business" --service-name "Primary Service" --city-name "Sample City" --region-name "Region" --primary-phone "(555) 555-0100" --dry-run --json
go run ./cmd/foundry validate runtime
go run ./cmd/foundry validate math --site /absolute/path/to/site --json
go run ./cmd/foundry validate crawler-policy
go run ./cmd/foundry validate static-origin
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

Use --dry-run --json for preflight and diagnostics. foundry new-page accepts direct fields, --brief <path> using Markdown/YAML/JSON input, or --prompt/--interactive for missing required fields. Prompt mode defaults to dry-run; add --write --site <path> when prompted values should create files. Write mode creates the rendered page under --site, refuses existing files by default, and only overwrites when --force is provided.

foundry scaffold creative-route-floor preflights all seven Creative v1 route pages before writing any files, so an existing route-floor file fails the whole scaffold unless --force is provided.

foundry scaffold local-service-route-floor preflights all nine Local Service v1 route pages before writing any files, so an existing route-floor file fails the whole scaffold unless --force is provided.

foundry validate scaffolds is the Go-native scaffold/page contract gate. It checks content kit starter renders, page type and composition references, allowed/required block compatibility, blueprint output templates and paths, and the Creative and Local Service route-floor dry-run smoke paths.

foundry validate motion is the Go-native Motion Kit contract gate. It checks the motion manifest header, required profiles/capabilities/display patterns, normalized authoring fields, safety rules, source-file hooks, reduced-motion support, and block/profile/capability references. It also enforces the governed Motion Kit budgets: profile limit keys, capability allowances against those limits, parallax and pinned-parallax speed ranges, required safety-rule contracts, and primitive normalized-field ownership.

foundry validate crawler-policy is the Go-native crawler-purpose and robots-policy gate. It checks the versioned schema and registry, required profiles and vendor tokens, crawler purpose and robots applicability, official source URLs, review dates, profile references, user-fetch safety boundaries, and the shared robots renderer/docs source contract.

foundry validate static-origin is the Go-native portable direct-origin gate. It validates cache classes, security-header policy, staged CSP requirements, the same-filesystem atomic release and rollback shape, schemas, public source files, and an optional site’s small repo-visible declaration. Humans normally use foundry static-origin [site-path]; the lower-level validator exists for CI, AI tools, and integrations. Both commands are read-only and never require a CDN or Foundry Control. See Static Origin.

foundry validate discoverability is the rendered-page discovery and agent-readiness contract. It checks canonical and index controls, JSON-LD identity, breadcrumb, article, and visible-content agreement, advertised RSS/Atom feeds, internal-link targets, visible review/freshness evidence, accessible link/button names, and form names and labels. Its stable JSON includes page-level facts, feed counts, and source-locatable finding codes. Warnings remain advisory by default and become errors with --strict. The compatibility fixture harness runs it after every rendered quality gate.

foundry inspect link-opportunities reads an already-rendered tree and emits the stable foundry.internal-link-opportunities.v1 report. It ranks unlinked page pairs by shared Pagefind discovery metadata, reports the lower-inbound target, and never edits content. The minimum score excludes relationships based only on a shared content kind.

foundry search build runs the standalone Pagefind binary and records a deterministic foundry.search-index.v1 freshness manifest. foundry validate search-index recomputes both rendered and index digests so a Hugo rebuild after Pagefind cannot ship a stale index.

foundry discovery-changes is a read-only comparison of two rendered trees. It reports canonical additions, removals, and changes for human review or a Foundry Control provider handoff; it performs no external provider operation.

foundry authoring-contract derives and validates the portable V1 family, block, section-control, block-control, menu, typed-field, blueprint, global, site-identity, and preview-mapping report. It is read-only. Go tests protect the public JSON shape and golden fixture; release validation also generates a contract from the Core checkout so template, manifest, schema, and CLI integration cannot drift independently.

Every typed field must include a generated, section-scoped preview selector. The focused authoring-contract tests also scan each golden block renderer and fail when an advertised field has no matching data-foundry-field-path anchor. See Portable Authoring Contract.

foundry validate math is the focused equation gate. It proves the effective site advertises the exact Core Math Notation V1 configuration, scans Markdown for unclosed or mismatched supported delimiters while ignoring inline and fenced code, then performs one strict Hugo build in a temporary destination. The destination is deleted and the site repository is not changed. Its foundry.math-validation.v1 JSON report provides safe site-relative source locations and distinguishes capability, syntax, renderer, Hugo availability, and unrelated build failures. Foundry Control and other managed products should consume this report rather than raw Hugo logs. See Math Notation.

foundry validate quality is the Go-native quality-gates contract. It checks the first enforceable accessibility, SEO, and performance floor: shared template image attributes, button types, SEO/head hook presence, fixture viewport/main landmark coverage, image decoding, and image loading/fetchpriority hints. With --rendered-root, it also validates an already-rendered HTML tree for content-page head/landmark contracts, rendered image/button attributes, and unresolved template markers. The compatibility fixture harness runs that rendered mode after each Hugo fixture build.

foundry validate tasks is the Go-native task/report contract gate. It checks data/foundry/task-contract-manifest.json for required safety modes, current implemented task kinds, source files, write policies, idempotency expectations, and forbidden overwrite/delete/provider/sync behavior. Run it whenever task docs, task manifests, import/apply behavior, or improve-page report fields change.

foundry validate block-contracts, block-governance, content-kits, creative-lane, compatibility-fixtures, feature-flags, shell, and section-families are also Go-native release gates. compatibility-fixtures materializes representative downstream sites, runs site doctor checks, renders the fixture HTML, applies rendered quality and discoverability gates, and can run browser smoke with --browser-smoke.

The Go doctor supports:

• core validation summary
• site bootstrap checks
• site block usage validation
• allowlist-aware drift audits
• Hugo render smoke
• delimiter-safe math source validation and normalized strict math build failures, reusing the Hugo smoke render rather than adding a second build
• --include-drift-audits
• --skip-core
• --skip-hugo
• --strict-warnings
• --browser-smoke
• --require-browser

foundry check is the common Core/site readiness lane. It runs native Go contract checks, omits the compatibility fixture fleet and evidence backstops, emits progressive human output, and uses the stable foundry.check.v1 JSON report. Default foundry doctor is now a compatibility route to those same Go-native checks while retaining its historical command identity. Browser flags preserve the legacy full doctor lane. foundry build is a deprecated no-write compatibility identity over routine checks; it never produces Hugo output. foundry release-check remains the full release lane, defaults to strict Hugo warning handling, and enables site drift audits when a site is provided.

The Go release-check path is canonical for portable Core release decisions. foundry validate tooling rejects package manifests, package-manager locks, Node scripts, and Node workflow commands. Focused Go validators provide diagnostics directly.

Theme and Brand System resolution is explicit and machine-readable: Core owns structure and safe fallbacks, then the ordered public-token layers apply as core-fallback → theme-family → brand-system → declared-site-extension; later layers win only for public tokens. Shared proof fixtures declare route identities, and independent change contracts name the gates that enforce them. Theme Families also publish machine-readable tags for every visual signature and avoidance statement. “Hidden state” has one shared definition: essential content or an actionable control is hidden when it is available only through client-side state, CSS-only disclosure, hover, or an unannounced visual layer instead of normal source order and an accessible interaction. The DC-02 Section catalog is enforced by the canonical Go path:

foundry validate section-catalog --json
foundry inspect section-catalog --json
foundry doctor --json

The validator requires a disposition for every registered renderer, exact renderer-family and chooser-family agreement, a unique canonical renderer for each public Section Type, explicit compatibility targets, and rollback. It does not authorize a migration or rewrite site source.

DC02-S2 also proves the executable Type identity through:

foundry inspect --site /path/to/site --json
foundry validate site-blocks --site /path/to/site --json
go test ./internal/foundry/sectioncatalog -run SectionTypeRuntime -count=1

The runtime fixture compares public Type output with the canonical legacy block output and requires unknown or dual identity to fail the Hugo build. Site inspection and source mapping report the authored identity separately from the resolved renderer; neither command rewrites source.

DC02-S3 proves that compatibility suggestions cannot become silent rewrites:

foundry task section-migration-preview --dry-run --site /path/to/site --json
foundry task section-migration-preview --dry-run --render \
  --site /path/to/site --json
go test ./internal/foundry/tasks -run SectionMigration -count=1

The fixture preserves YAML, TOML, and JSON bytes outside the exact identity, proves exact rollback and repeated-report idempotency, compares real Hugo route output from temporary site copies, rejects unsafe symlinks, and requires every proposal to stay blocked until Section Style is executable.

For Git sites, migration discovery and proof clones use tracked and unignored files only, then walk Hugo’s effective content mounts. This includes mounted source with build.list: never and excludes inactive content trees. Tests also require ignored local artifacts to stay outside the proof, macOS cloud placeholders to fail with a path instead of hanging, and each isolated render to stop at its bounded timeout. Draft-only, build.render: never, and routes omitted by both successful proof variants remain fully source-validated but render not-applicable; a route omitted on only one side fails. Proof builds strip ambient secrets, deny network and writes, and render with Hugo and Go module replacements only. They never bind or execute a consumer dependency tree or package toolchain.

foundry validate quality is the Go CLI surface for the first enforceable framework-level quality gate. The compatibility fixture harness renders the committed fixture set and calls foundry validate quality --rendered-root so generated HTML keeps the same objective accessibility, SEO, performance, and anti-template-leak floor. See Quality Gates.

Portable layout quality is proved by rendered fixture assertions, the declared viewport matrix, browser evidence, and human review. Foundry no longer carries a separate CSS-token heuristic or risk-budget artifact; it duplicated those stronger checks and created a maintenance gate without proving the experience.

For a local browser pass over the compatibility fixtures, run:

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

The Go compatibility fixture harness uses Safari WebDriver on macOS plus a lightweight mock Pagefind index to check the highest-risk interactive fixture flows. If Safari WebDriver is unavailable, the lane reports a non-failing skip unless --require-browser is provided. Every scenario resets through a blank document, applies its requested window rectangle before and after target navigation, and releases a maximized automation window before retrying the rectangle. This prevents a declared mobile scenario from silently executing at desktop width.

Fixture browser contracts may use assert_rect_relation with selector, target_selector, and one of same_left, same_right, same_top, horizontal_gap, vertical_gap, left_of, horizontal_overlap, or contained_by. Edge and containment relations accept tolerance; gap, ordering, and overlap relations accept min_gap. contained_by compares all four child edges with the target container, so it catches internal card escape that does not create document-level horizontal overflow. Use assert_color_contrast with an optional target_selector background and a WCAG ratio in min (4.5 by default). The Go harness owns these action names and fields. The portable-block-layout-proof fixture uses these actions for container parity, action separation, card alignment, credit columns, and dark text.

The generated Creative route-floor fixture also uses this browser lane as a visual/computed-style gate. It checks all seven Creative routes at desktop and mobile viewports for page preset/profile tokens, motion-profile durations, shell/search/accessibility fallback styling, hero CTA/media rhythm, chapter navigation presence, story-reel presence, route-floor token surfaces (page-list, timeline, contact-split, rich-text, cta, and table-of-contents), Creative block preset surfaces, non-empty journal feed content, work-detail caption/credit surfaces, and horizontal overflow.

The Go scaffold/page validator also checks Creative content-model contracts: work metadata, journal-entry metadata, exhibition event metadata, fixture content, and profile/inquiry data. Use this when page manifests, blueprints, content kits, or Creative starter templates change:

go run ./cmd/foundry validate scaffolds

foundry inspect scaffolds --json is the matching discovery surface. The Creative scaffold profile exposes content_models with generation policy, required fields, recommended fields, recommended nested media/credit/event structures, and explicit foundry new-page commands for detail pages. The scaffold/page validator validates those discovered contracts against registered manifests, starter templates, generated new-page renders, and governed fixture content so discovery cannot drift ahead of implementation.

When the browser environment must be present rather than skipped, require it explicitly:

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

The compatibility fixture step materializes representative downstream consumers inside /tmp, runs Foundry Doctor in site mode against each one, and then performs rendered-output assertions against the built HTML for each fixture:

• current-site-baseline
• older-site-baseline
• search-heavy-site
• article-heavy-site
• property-retreat-site
• creative-route-floor-site
• cinematic-campaign-theme-proof
• utility-service-theme-proof
• form-heavy-theme-proof
• managed-form-availability-proof
• quiet-editorial-theme-proof
• immersive-product-story-theme-proof
• gallery-property-destination-theme-proof

Those assertions deliberately check for shared runtime markers such as shell chrome, search UI mounts, language alternates, article-shell markup, property-media tab/lightbox scaffolding, reference-theme proof surfaces, and the absence of templating leaks like ZgotmplZ. The generated Creative route-floor fixture also asserts on the scaffolded source files so normalized Motion Kit fields and route-floor content contracts stay present before Hugo rendering, then uses the browser lane to catch visual drift that string assertions cannot see, including token-scoped panel, list, timeline, contact, rich-text, CTA, and chapter-navigation surfaces. It also asserts the Creative-safe preset names used by the route floor so starter source cannot silently drift back to generic neutral variants. The Creative fixture includes governed sample content for journal entries, work metadata, media captions/credits, exhibition metadata, and profile/inquiry data so source and render assertions prove the content model, not just route shells.

The browser lane requires:

• macOS with Safari available
• Enable Remote Automation turned on in Safari’s Develop menu, or safaridriver --enable run once by the local user
• a local environment allowed to talk to localhost, since Safari WebDriver and the fixture file server both run locally

If Safari repeatedly reports a fullscreen automation rectangle on a local Mac, the JavaScript compatibility runner has an opt-in recovery mode that asks Safari to restore its active automation window before retrying the requested viewport:

FOUNDRY_SAFARI_WINDOW_RECOVERY=1 \
  go run ./cmd/foundry validate compatibility-fixtures --browser-smoke --require-browser

This requires the terminal or Codex process to have macOS Automation access to Safari. The default lane does not resize an unrelated Safari window.

When a change also affects a consuming site, run the routine site check first:

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

That adds:

• site block-usage validation
• go.mod bootstrap check for a valid local site bootstrap mode:
  • locked-materialized site mode via ./.foundry/modules/...
  • live sibling-repo framework-dev mode
• hugo --renderToMemory smoke build

For proof consumers or sites with reviewed local framework shadows, include the drift audits:

go run ./cmd/foundry check \
  --site /absolute/path/to/site \
  --include-drift-audits \
  --json

If the site already has allowlists in .planning/, doctor picks them up automatically. Use --strict-warnings when Hugo warnings should fail the run.

Regression Review Checklist

Use this checklist before treating framework work as complete.

For planning cycles that affect productization, discovery, or proof-site upstreaming, also confirm the decision path in Foundry Productization Plan and the ownership model in Builder Guidance And Discovery.

Any Core Contract Change

• Run go run ./cmd/foundry inspect --json
• Run go run ./cmd/foundry validate runtime
• Run go run ./cmd/foundry validate math --root . --site . --json when the change affects math config, render hooks, CSS, schemas, authoring capabilities, or validation
• Run go run ./cmd/foundry validate crawler-policy
• Run go run ./cmd/foundry validate motion
• Run go run ./cmd/foundry validate quality
• Run go run ./cmd/foundry validate discoverability --rendered-root <public> after producing a rendered tree; compatibility fixtures cover this for Core
• Run go run ./cmd/foundry validate scaffolds
• Run go run ./cmd/foundry validate tasks when task/report contracts or docs changed
• Run go run ./cmd/foundry validate block-contracts
• Run go run ./cmd/foundry validate block-governance
• Run go run ./cmd/foundry validate content-kits
• Run go run ./cmd/foundry validate compatibility-fixtures
• Run go run ./cmd/foundry validate feature-flags
• Run go run ./cmd/foundry validate shell
• Run go run ./cmd/foundry validate section-families
• Run go run ./cmd/foundry validate documentation when mission, planning, release, installation, or active-index documentation changes
• Confirm the changed docs still describe the current contract surface
• If manifests or starter templates changed, confirm content-kit render smoke is still green

Block, Template, Or Schema Change

• Run core doctor
• Run go run ./cmd/foundry inspect field-contracts --root . --json; the complete 18-family field matrix and governed public-literal classifications must report zero errors and zero warnings
• Run go run ./cmd/foundry inspect blocks --json
• If typed editor fields or preview anchors changed, run go run ./cmd/foundry authoring-contract --site . --core-version dev --site-key foundry-core-dev --commit-sha dev --json
• If the change adds, removes, renames, or reclassifies a block, confirm the family assignment and any justified proof-gap entries in data/foundry/block-family-manifest.json and data/foundry/block-governance.json
• Run doctor against at least one representative consuming site
• Apply Consumer Integration Quality Gate: verify exact asset identity, native control states, intrinsic geometry, and rollback evidence in the consumer browser.
• Confirm field names match across:
  • block template expectations
  • schema/docs
  • starter content-kit templates

Flow System, Theme Interaction, Or CSS Token Change

• Run core doctor
• Run doctor against a Shield-based consumer site
• For any downstream site, run the consumer integration gate against the exact built release; a Core-only screenshot does not prove asset parity or control resilience.
• Review SITE-BOOTSTRAP.md rules for:
  • dark-section text contrast
  • alternating-row overrides
  • CSS load order
  • stats counter constraints

Shell Contract Or Shared Chrome Change

• Run core doctor
• Run doctor with --include-drift-audits against the proof consumer or any downstream repo with reviewed shell overrides
• Confirm allowlists still match reality before accepting new shadows

Pack, Page Type, Composition, Content Kit, Or Scaffold Change

• Run core doctor
• Run go run ./cmd/foundry validate scaffolds
• Run go run ./cmd/foundry inspect scaffolds --json
• Run go run ./cmd/foundry inspect blueprints --json when the change affects blueprint inventory
• Run go run ./cmd/foundry inspect --site /absolute/path/to/site --json when the change affects downstream page ownership, routes, or block usage
• Render or scaffold at least one affected starter path
• Run doctor against a consuming site if the change is already adopted downstream

Task Or Report Contract Change

• Run go run ./cmd/foundry validate tasks
• Run go run ./cmd/foundry validate tasks --json when the JSON summary is part of the review evidence
• Run the affected foundry task ... --dry-run --json command against a compatibility fixture when the change affects report output
• For improve-page, run go run ./cmd/foundry task improve-page --dry-run --site fixtures/compatibility/utility-service-theme-proof --path content/_index.md --json
• For saved improve-page payload compatibility, run go run ./cmd/foundry task validate-improve-page-report --report <saved-improve-page-report.json> --json
• Confirm Core still refuses approval persistence, final copy generation, provider fetches, hidden service state, overwrite, delete, sync, rollback, and managed publish behavior

Math Notation Change

• Run go test ./internal/foundry/authoringcontract ./internal/foundry/mathvalidation ./internal/foundry/compatfixtures ./internal/foundry/doctor ./cmd/foundry -count=1
• Run go run ./cmd/foundry validate math --root . --site . --json
• Run go run ./cmd/foundry validate compatibility-fixtures article-heavy-site --json
• Prove one invalid expression fails with invalid_math_notation and a safe repo-relative location.
• Prove unclosed and mismatched delimiters fail before the temporary build.
• Review the article-heavy page at desktop and mobile widths; a wide display equation must scroll within itself without page-level overflow.
• Confirm rendered output contains MathML and no MathJax/KaTeX script or remote math stylesheet.
• Confirm the effective authoring contract omits the capability when Core config or the render hook is unavailable, misconfigured, or overridden.

Motion, Parallax, Or Authored-Feel Change

• Run core doctor
• Run go run ./cmd/foundry validate motion
• Run go run ./cmd/foundry inspect motion --json
• Confirm field names are documented in data/foundry/block-options.yaml and block docs
• Confirm any display-pattern change has canonical blocks, supported capabilities, reduced-motion behavior, an ownership boundary, and anti-drift notes in data/foundry/motion-manifest.json
• Confirm reduced-motion behavior is preserved
• Review Foundry Motion Kit Plan for profile, parallax, and blueprint expectations
• Run doctor against a representative consumer when the change affects service, Creative, or property storytelling surfaces
• Use --include-drift-audits for downstream review when copied local motion runtime, block shadows, or framework shadows are suspected; use --strict-warnings once a migration path has been reviewed

Local Release Safety Bar And Dormant CI

GitHub Actions is disabled in the repository settings as of 2026-07-30. No automatic or manually dispatched workflow can start while that setting remains off. The canonical production gate is the complete local Release Checklist run against the exact release tree, with any unavailable platform or browser evidence recorded explicitly.

The retained validate.yml definition is dormant. If Actions is deliberately re-enabled later, its Ubuntu job runs each proof lane once:

go test ./...
go run ./cmd/foundry authoring-contract --site . --core-version ci --site-key foundry-core-ci --commit-sha ci
go run ./cmd/foundry release-check --json

release-check owns the focused Go validators, compatibility fixture fleet, documentation and workflow policy, report-contract checks, and Core evidence-contract gates. Best Framework promotion evidence and browser/preview evidence remain explicit, scoped work. The workflow deliberately does not rerun validators individually or through the compatibility doctor command.

The workflow-contract validator protects the dormant definitions: every workflow with a pull_request or push trigger allocates only ubuntu-latest, command parity and minimal permissions remain intact, and the manual release definition retains its runner contract. It does not inspect or change the repository-level Actions setting.

The retained Foundry Cross-Platform Validation definition has only a workflow_dispatch trigger. While Actions is disabled it cannot run, so macOS, Windows, and Safari runner verification is deferred and must not be reported as executed evidence. If Actions is deliberately re-enabled, the definition runs go test ./... and the Go-native foundry check --json aggregate on macOS and Windows, plus required Safari browser evidence on macOS:

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

Keeping the definitions in the repository makes a future re-enable explicit and reviewable without treating dormant workflows as current release evidence. Safari availability remains a real requirement whenever the manual macOS lane is restored.

Best Framework WCAG And Performance Evidence

The retained BF1/BF2 packets are measurement baselines, not active build tools. Validate their promoted visual-example and quality-receipt bindings through the Go contracts:

go run ./cmd/foundry validate visual-examples --json
go run ./cmd/foundry validate quality --json
go run ./cmd/foundry release-check --json

New WCAG, browser, and lab Web Vitals measurements must record exact Core and Distribution identities, tool versions, raw artifacts, limitations, and human or assistive-technology states. Add the reviewed receipt and artifacts to the repo-visible evidence contract; do not add a package manager or executable Node harness to Core.

The matrix is valid evidence even when its measured result is a WCAG or lab failure. A missing or manipulated report is invalid evidence and fails the gate; a measured defect remains truthful remediation input.

Because doctor now renders real Hugo fixture sites and the browser lane uses Safari WebDriver, the manual workflow also needs:

• Go 1.27 or later for Hugo module resolution
• Hugo Extended 0.165.0 or later
• a macOS runner with Safari available
• safaridriver --enable before the browser parity step