Hosted Release Verification
Hosted release verification compares a deployed VyDex site with the matching committed release. It remains available for explicit diagnostics and rollback rehearsal, but it is not part of push validation or routine deployment.
Purpose And Ownership
The verifier answers one question: does this hosted surface expose the complete static release described by the repository?
It checks:
- Public routes, redirects, canonical URLs, and genuine not-found responses.
- Immutable Dataset and Schema bytes, media types, cache policies, counts, and relationships.
- Sitemap availability and manifest-backed public files.
- Core Entry content and the Homepage's release-derived latest Entry container.
- Playwright and Axe journeys against an explicit hosted origin.
It does not upload files, select a release, create commits, or repair production. Those responsibilities remain separate.
Why It Is Not A Deployment Gate
Hosted checks depend on live network state, Pages propagation, and exact expectations about the deployed release. Combining them with every push made source validation, release selection, Cloudflare publication, and recovery fail as one unit.
The application now uses a smaller boundary:
- Pushes and pull requests prove that the source builds and passes local browser checks.
- A successful push validation on
mainstarts production deployment for that exact commit; manual redeployment remains available. - Hosted verification is run separately when release-level evidence is needed.
A hosted diagnostic can therefore fail without creating commits, changing the public site, or making an otherwise successful Git push appear unsuccessful.
Stable Homepage Verification
The verifier does not compare the Homepage against an exact slogan or marketing headline. Copy and visual structure may change without changing release identity.
Instead, it requires the semantic data-homepage-latest container and verifies that the current release's latest Entry title appears inside that container. Entry routes still require their canonical Entry titles and record content.
Running The Diagnostic
Use the matching repository commit and provide the approved Pages environment values. To verify a particular production deployment, set VYDEX_EXPECTED_DEPLOYMENT_ID before running:
$env:PUBLIC_SITE_ORIGIN = "https://vydex.pages.dev"
$env:VYDEX_EXPECTED_DEPLOYMENT_ID = "replace-with-production-deployment-id"
npm run verify:hosted-stage-1
The command may retry a complete verification pass while Pages edges converge. Reports, screenshots, traces, and logs remain under ignored runtime directories.
Rollback Rehearsal
The protected rehearsal workflow can still use hosted verification around a deliberate rollback and restoration. That workflow is manual, requires the exact confirmation phrase, and shares the exclusive production concurrency group.
Rehearsal behavior does not apply to routine deployment. A routine deployment never chooses a fallback or performs automatic rollback.
Failure Behavior
- The verifier records each failed check and exits non-zero.
- It does not mutate Cloudflare or repository state.
- A failed marketing-copy comparison cannot block deployment because no such comparison exists.
- Network or propagation failures remain diagnostic failures rather than automatic recovery triggers.
- Manual recovery must use an identified successful production deployment, never a preview deployment.
Invariants
- The canonical origin remains
https://vydex.pages.dev. - Hosted verification never creates or rotates release identity.
- Semantic release markers are checked instead of exact presentational copy.
- Reports and browser output remain ignored operational evidence.
- Credentials and authorization headers never enter reports or logs.
- The deployment workflow does not invoke the hosted verifier.
- Rollback and restoration remain explicit maintainer operations.
Implementation Landmarks
src/release/stage-one-hosted-verification/— HTTP checks and structured reports.scripts/deployment/hosted-verification-support.ts— release loading, browser execution, retries, and report persistence.scripts/deployment/verify-hosted-stage-one.ts— explicit diagnostic command.playwright.hosted.config.ts— hosted browser configuration.runtime/hosted-verification/— ignored diagnostic output.tests/features/stage-one-hosted-verification.test.ts— hosted HTTP contract coverage.
Related Pages
- Cloudflare Pages Deployment
- Repeatable Release Publication
- How To Restore A Production Deployment
- How To Rehearse The Production Rollback