Say v1.0.0 is released

README.md

@@ -15,7 +15,8 @@
 # openpreflight docs
 
 The documentation site, published at **https://docs.openpreflight.xyz**.
-Astro + Starlight + Tailwind v4.
+Astro + Starlight + Tailwind v4. It describes **v1.0.0**
+([GitHub Release](https://github.com/openpreflight/openpreflight/releases/tag/v1.0.0)).
 
 This repository is the source of truth for the documentation. The markdown
 under `src/content/docs/` is hand-authored and committed. Nothing is

src/content/docs/index.mdx

@@ -16,6 +16,12 @@ hero:
 
 import { Card, CardGrid } from '@astrojs/starlight/components';
 
+**v1.0.0** is out (29 August 2026). Linux binaries are on the
+[GitHub Release](https://github.com/openpreflight/openpreflight/releases/tag/v1.0.0).
+What shipped is in the
+[changelog](https://github.com/openpreflight/openpreflight/blob/v1.0.0/CHANGELOG.md);
+what v1 still does not include is in the [FAQ](/start/faq/).
+
 <CardGrid>
   <Card title="Start here" icon="rocket">
     [Quickstart](/start/quickstart/) gets the binary running and through the

src/content/docs/start/faq.md

@@ -1,6 +1,6 @@
 ---
 title: "FAQ"
-description: "Short answers on GitHub Apps, Coolify, check-suite gating, GitHub Enterprise, monorepos, dogfooding, and what v1 leaves out."
+description: "Short answers on the v1.0.0 release, GitHub Apps, Coolify, check-suite gating, GitHub Enterprise, monorepos, dogfooding, and what v1 leaves out."
 sidebar:
   order: 4
 ---
@@ -9,6 +9,14 @@ Positioning questions the homepage raises, and the ones people ask before
 installing. Each answer links the page or ADR that argues it in full. For how
 this sits against other CI, see [Comparison](/start/comparison/).
 
+## Is v1 released?
+
+Yes. [v1.0.0](https://github.com/openpreflight/openpreflight/releases/tag/v1.0.0)
+was tagged 29 August 2026. The
+[changelog](https://github.com/openpreflight/openpreflight/blob/v1.0.0/CHANGELOG.md)
+is the feature list. [What is deliberately not in v1](#what-is-deliberately-not-in-v1)
+is still the product boundary — those things are out of scope, not unfinished.
+
 ## Why a GitHub App and not OAuth?
 
 Only a GitHub App can create Check Runs. User and OAuth tokens are refused.
@@ -81,11 +89,11 @@ monorepo is the case this is worst at. Do the path filtering inside your own
 No. `openpreflight/openpreflight` runs GitHub Actions — `ci.yml` for vet, test,
 and a Docker build, and `release.yml` on a `v*` tag.
 
-Two reasons, both honest. Dogfooding needs a permanently reachable HTTPS
-instance and a GitHub App registered against the org, which is infrastructure
-the project does not run yet. And releases have to build multi-arch images and
-attach binaries, which is not something this tool does at all — it reports a
-check, it does not publish artifacts.
+A public demo instance at [ci.openpreflight.xyz](https://ci.openpreflight.xyz)
+runs Check Runs for [`openpreflight/demo`](https://github.com/openpreflight/demo).
+That is proof the binary works, not CI for this repository. Releases have to
+build multi-arch images and attach binaries, which this tool does not do — it
+reports a check, it does not publish artifacts.
 
 Nothing stops it from checking a public repo, incidentally. The repository's
 visibility is read from the webhook payload but never gates anything; "private

src/content/docs/start/quickstart.md

@@ -36,7 +36,9 @@ without it. Keep it forever. Losing it makes stored PEMs and tokens unreadable.
 Everything else either has a default or is asked for in the wizard. See
 [Configuration](/start/configuration/) for the full env table and key rotation.
 
-Pin a version with `OPENPREFLIGHT_VERSION=1.0.0` rather than editing the file.
+**v1.0.0** is the tagged v1 release. Linux binaries are on the
+[GitHub Release](https://github.com/openpreflight/openpreflight/releases/tag/v1.0.0).
+Pin the image with `OPENPREFLIGHT_VERSION=1.0.0` rather than editing the file.
 
 To build from source instead — this is the contributor path, and `compose.yaml`
 is `build: .`, so it needs the checkout: