# Release Checklist

The Gateway should not cut a broad public release until the repository, website, and operator evidence tell the same story.

## Required Gates

- License is selected and committed.
- `README.md` states pre-launch scope and current install expectations.
- `SECURITY.md`, `CONTRIBUTING.md`, and `SUPPORT.md` are present.
- Issue templates and PR template are present.
- Security reports are routed through contact links, not public vulnerability issues.
- Install guide is tested on a fresh machine.
- Rollback and recovery guide exists.
- Hardware matrix lists supported, partially supported, and untested modes.
- Public evidence page links to demo, screenshots, install transcript, route/DNS checks, fallback checks, and recovery drill.
- Screenshot handling is explicit: if assets were refreshed, they use redacted synthetic values and note the claim each image supports; if they were not refreshed, the release notes explain which public surface was reviewed, the screenshot decision/result, and why the current set stayed sufficient.
- Support intake explains redaction, access, and retention boundaries.
- Privacy posture checklist exists.
- Support bundle redaction guide exists.
- Contact and intake privacy notes exist.
- `npm audit --audit-level=high` reports no high-severity advisories before broad release.
- Canonical host routing is confirmed: check the production domain, canonical metadata, the canonical host, and the `www` host before broad launch, then confirm the Cloudflare Pages root alias and the release host redirect back to `https://thegateway.pro/`. Pass the root URL of the release host to the verifier without a path, query, or fragment. Record the exact release-host label, observed status codes, and `Location` headers in release notes, and keep provider-specific deployment endpoints out of public product copy.
- Known limitations are public.
- Release notes template exists.

## Copy Gates

- No internal development terms, tooling names, workspace paths, versioned deployment URLs, provider-specific deployment endpoints, internal helper names, or external skill-marketplace names in public product copy.
- No internal launch targets, private channel plans, or exact price ranges in public repo docs.
- No claims that The Gateway guarantees anonymity by itself.
- No mature proof wording unless the evidence page links to actual proof.
- No unsupported hardware or install claims.
- Build output stays clean: `npm run build` keeps `_site` free of workspace metadata, hidden workspace directories, dependency directories, and repository internals such as `AGENTS.md`, `SOUL.md`, `USER.md`, `node_modules`, and `.git`.

## Operator Evidence Gates

- Route ownership behavior documented.
- DNS ownership behavior documented.
- Fallback behavior documented.
- Recovery path documented.
- Privacy posture check documented.
- Known failure modes documented.
- Redacted example support bundle documented.

## Release Notes Should Include

- Current supported deployment modes.
- Known limitations.
- Evidence links.
- Upgrade or rollback notes.
- Security/support contact path.
- Any breaking changes.

## Next Action

- Open [repository readiness](./repository-readiness.md).
- Open [evidence checklist](./evidence.html).
- Open [publication review](./site-qa.html).
- Open [production checklist](./production-checklist.html).
- Review [redaction guide](./support-bundle-redaction.html) before any proof bundle leaves the machine.
- Check [launch status](./launch-status.html) so the public summary stays aligned with the maintainer release gate.
- After deploy, rerun the host verifier against the root URL of the release host that shipped, without a path, query, or fragment, record the exact label plus observed status codes in release notes, and confirm the Cloudflare Pages root alias also redirects to `https://thegateway.pro/` before treating the site as public.