# The Gateway Public Launch Readiness

The Gateway should launch publicly only when the open-source story, install path, trust boundaries, and evidence are aligned.

The project is pre-launch. This document is intentionally public-safe: it describes release gates and operator evidence, not private channel plans, internal targets, or unreleased commitments.

## Public Goal

Publish The Gateway as an open-source, local-first privacy overlay for operators who want inspectable control over:

- Route ownership.
- DNS ownership.
- Identity separation.
- Fallback behavior.
- Bridge and relay paths.
- Recovery procedures.
- Privacy posture verification.
- Assistant-guided operator runbooks.

The Gateway should be presented as an inspectable control layer, not as a one-click anonymity product or a generic VPN replacement.

## Public Positioning

Primary message:

> Build a private overlay over the internet.

Supporting narrative:

- The public internet is mediated by opaque platforms, ISP behavior, app telemetry, cloud defaults, and fragile local networks.
- The Gateway gives operators an explicit model for where traffic goes, what resolves, what fails over, which identity context applies, and what evidence proves the state.
- The open-source core creates trust because traffic-control infrastructure should be inspectable.
- Paid operations fund reliability, documentation, support, appliances, and long-term stewardship.

## Claims To Keep Bounded

- Do not promise anonymity by default.
- Do not imply The Gateway can make logged-in accounts, payments, endpoint compromise, or browser fingerprints private.
- Do not imply support needs credential custody or default traffic inspection.
- Do not present unsupported hardware, install paths, or bridge behavior as complete.
- Do not frame the project as only a VPN/router.
- Keep public-facing launch copy free of internal development terms, tooling names, workspace paths, versioned deployment URLs, and provider-specific deployment endpoints.
- Keep build output free of workspace metadata, hidden workspace directories, dependency directories, and repository internals such as `AGENTS.md`, `SOUL.md`, `USER.md`, `node_modules`, and `.git`.
- If screenshots are part of launch evidence, refresh them only with redacted synthetic values and note the claim each image supports; if they are unchanged, record the reviewed public surface and why the current set still covered the change.

## Public Launch Gates

Before broad public promotion:

- License selected and committed.
- Public repository published with README, security policy, contribution guide, support policy, and issue templates.
- Fresh-machine install path tested and documented.
- Rollback and recovery path documented.
- Supported hardware matrix published.
- Production domain and hosting verified, with canonical metadata, sitemap, the canonical host, and the `www` host checked before broad launch, then the Cloudflare Pages release-host redirects confirmed to point back to the canonical site.
- The release-host verifier is run against the root URL of the release host, without a path, query, or fragment, and the exact label plus observed status codes are recorded in release notes.
- `npm audit --audit-level=high` reports no high-severity advisories before broad launch.
- Public evidence checklist populated with screenshots, demo, install transcript, test summary, and recovery drill.
- Support intake and redaction rules published.
- Support boundaries published and linked from the launch plan.
- Security reporting path tested.
- Sponsor/support/appliance/MSP paths point to real contact endpoints.

## Public Assets

- Product website.
- Public repository.
- Install readiness page.
- Trust and security boundaries page.
- Support boundaries page.
- Support intake page.
- Sponsor path.
- Appliance waitlist.
- MSP pilot intake.
- Evidence checklist.
- First operator runbook.

## Soft Launch Criteria

A limited technical preview is appropriate when:

- A technical operator can understand the install path without a private call.
- The project clearly says what is experimental.
- Support scope is bounded.
- Logs and support bundles have redaction guidance.
- Issues and PRs have templates that prevent accidental publication of secrets, private topology, or traffic captures.
- Privacy posture claims are tied to concrete route, DNS, fallback, and leak checks.

## Public Launch Criteria

Broad public launch is appropriate when:

- The install path works on at least one documented fresh-machine environment.
- Recovery has been tested.
- Public docs explain common failure cases.
- Evidence artifacts are available.
- Security and support contact paths work.
- A maintainer can triage issues without relying on private context.

## Definition Of Done

- The website clearly explains what The Gateway is, who it is for, what it controls, and how it is funded.
- Public docs let a technical user evaluate and attempt the install path.
- Donation, sponsor, support, appliance, and MSP paths are visible without overpromising.
- Operator runbooks show how sensitive changes are reviewed before they are applied.
- Privacy and anonymity limitations are explicit.