# Release Notes Template

Use this template for The Gateway public releases.

## Release

- Version:
- Date:
- Commit:
- Release type:

## Summary

What changed?

## Supported Deployment Modes

- Primary gateway:
- Embedded router:
- Portable node:
- Appliance candidate:
- Relay or bridge:
- VPS node:

## Evidence Links

- Install transcript:
- Route/DNS checks:
- Fallback checks:
- Recovery drill:
- Privacy posture check:
- Hardware reports:
- Screenshot surface reviewed:
- Screenshot decision/result:
- Screenshot unchanged rationale:
- Screenshot redaction or unchanged note:
- Production domain status:

If screenshots were not refreshed, the `Screenshot surface reviewed` field should name the exact public surface and the `Screenshot unchanged rationale` field should explain why the existing assets still covered the change. If screenshots were refreshed, still name the reviewed surface, note the redaction approach, and record the claim each image supports so the audit trail stays specific either way.

## Pre-release Checks

- `npm audit --audit-level=high` result:
- No high-severity advisories blocked release:
- Build artifact hygiene: `npm run build` leaves `_site` free of workspace metadata, hidden workspace directories, dependency directories, and repository internals such as `AGENTS.md`, `SOUL.md`, `USER.md`, `MEMORY.md`, `node_modules`, and `.git`.

## Public Copy Hygiene

- No internal development terms, tooling names, workspace paths, or versioned deployment URLs appear in visitor-facing release notes.
- Keep any release-host URL, root alias URL, or provider-specific endpoint in audit notes only; do not repeat those release-host details in visitor-facing text.
- Exact alias labels and `Location` headers stay in audit notes only; visitor-facing summaries should describe the result without reproducing provider-specific release URLs.
- Public release copy should name the canonical production domain and the `www` alias outcome, then leave the versioned release alias URL and label out of the public summary.
- If screenshots were refreshed, note the asset set and claim each image supports; if they were unchanged, say which public surface was reviewed and why the existing set remained sufficient.

## Deployment Verification

- Canonical host checked: `https://thegateway.pro/`
- `www` alias checked: HTTP 200
- `www` alias result: HTTP 200
- `www` alias label used for host verification:
- `www` alias `Location` header:
- Canonical host result: HTTP 200
- Verification order: canonical host first, `www` alias second, Pages root alias third, release host last
- Cloudflare Pages root alias root URL used for verification:
- Release host root URL used for verification (no path, query, or fragment):
- Cloudflare Pages root alias checked: HTTP 301 back to `https://thegateway.pro/`
- Cloudflare Pages root alias result: HTTP 301
- Cloudflare Pages root alias `Location` header:
- Cloudflare Pages root alias label used for host verification:
- Release host label used for host verification:
- Release host checked: HTTP 301 back to `https://thegateway.pro/`
- Release host result: HTTP 301 back to `https://thegateway.pro/`
- Release host `Location` header:
- Release-host verifier result:

Record the exact alias labels and status-code outcomes here so the deploy can be audited later without exposing versioned deployment URLs in visitor-facing copy.

## Known Limitations

List limitations that remain after this release.

## Upgrade Notes

What should existing operators do before upgrading?

## Rollback Notes

How can operators return to the previous known-good state?

## Security And Support

- Security contact:
- Support intake:
- Redaction rules: