docs: publish release support policy

README.md

@@ -651,6 +651,8 @@ GitHub Actions workflows live under `.github/workflows/`:
 - `release.yml` builds release archives for Linux, macOS, and Windows, includes
   README/docs/license files, smoke-tests the packaged binary from the archive,
   uploads artifacts, and publishes them on `v*` tags or manual dispatch.
+- `docs/release-support-policy.md` defines supported platforms, compatibility
+  expectations, security update handling, and the user-level service boundary.
 - `.github/dependabot.yml` opens weekly Cargo and GitHub Actions update PRs.
 
 Local equivalents remain:

docs/production-readiness-roadmap.md

@@ -311,12 +311,12 @@ Goal: make first deployment the start of a controlled compatibility story.
     metadata, and peer cards.
   - `[ ]` Rollback expectations are documented.
 
-- `[ ]` Publish release and support policy.
+- `[x]` Publish release and support policy.
   Acceptance criteria:
-  - `[ ]` Supported platforms are listed.
+  - `[x]` Supported platforms are listed.
-  - `[ ]` Breaking-change policy is documented.
+  - `[x]` Breaking-change policy is documented.
-  - `[ ]` Security update expectations are documented.
+  - `[x]` Security update expectations are documented.
-  - `[ ]` User-service installation remains user-level only.
+  - `[x]` User-service installation remains user-level only.
 
 ## Phase 10: Pre-Deployment Dogfood Gate
 

docs/release-support-policy.md

@@ -0,0 +1,57 @@
+# Release And Support Policy
+
+`geth` is pre-deployment software. Until the first deployment tag, releases are
+pre-releases intended for dogfood and controlled automation only.
+
+## Supported Platforms
+
+Release archives are built for:
+
+- Linux x86_64
+- macOS
+- Windows x86_64
+
+The daemon and control CLI are supported as a single `geth` executable on those
+platforms. Service installation remains user-level only: systemd user units on
+Linux, launchd user agents on macOS, and per-user scheduled tasks on Windows.
+`geth` does not install or require system services.
+
+Overlay interface activation is platform-dependent and may require local host
+entitlements such as Linux `CAP_NET_ADMIN`, macOS network-extension approval, or
+Windows Wintun setup. See `docs/overlay-platforms.md`.
+
+## Compatibility
+
+Before the first deployment tag, breaking changes are allowed when they reduce
+long-term risk and are reflected in `docs/production-readiness-roadmap.md`.
+After the first deployment tag:
+
+- Stable commands and `--json` fields follow `docs/compatibility.md`.
+- Experimental commands may change with a release note and migration path.
+- Prototype commands may change, be replaced, or be removed before a stable
+  guarantee is made.
+- Local SQLite schema changes require ordered migrations and upgrade tests.
+- Signed operation formats must not be changed without a new version or
+  explicit migration behavior.
+
+## Security Updates
+
+Security fixes should be released as soon as practical after validation. The
+project runs CI, RustSec audit, CodeQL, dependency review, and Dependabot, but
+those checks do not replace manual review of Iroh transport, authorization,
+host-opening, and cryptographic boundaries.
+
+Bearer tokens, private SSH keys, and resource secrets must not be copied into
+release artifacts, logs, examples, or support bundles. SSH keys remain local
+admin trust anchors and are never a geth transport fallback.
+
+## Release Checklist
+
+For a tagged release:
+
+- CI must pass formatting, check, tests, and clippy.
+- Security workflows must pass or have an explicit documented exception.
+- Release archives must be built by `.github/workflows/release.yml`.
+- Packaged archives must include README, docs, and license files.
+- Packaged binaries must be smoke-tested from the archive.
+- Any breaking changes must be called out in release notes.