Harden first-release validation and dependency hygiene

docs/releasing.md

@@ -0,0 +1,37 @@
+# Release checklist
+
+This checklist does not publish packages or images automatically. Keep
+`publish = false` unless a separate crates.io publication decision is made.
+
+## Before the first public release
+
+- Confirm rights to publish all project code and preserve upstream attribution.
+- Establish the official public repository and enable and test GitHub Private
+  Vulnerability Reporting. Update [SECURITY.md](../SECURITY.md) with the real link.
+- Require CI checks on the protected main branch. Verify an actual successful
+  run on the hosting platform; local tests do not prove hosted CI is enabled.
+- Run the [development checks](development.md), dependency audit, license checks,
+  and coverage measurement from a clean candidate checkout. The line-coverage
+  target is 90%; record any shortfall as an unresolved release item, without
+  excluding production files to improve the number.
+- Review every security advisory. Fix affected dependencies with minimal
+  compatible changes, or block release. Do not silently suppress advisories.
+- Confirm no credentials, production inputs, repository state or internal
+  verification data are tracked. Check documentation commands and links.
+
+## Tag and artifacts
+
+After the checks pass, replace `Unreleased` with the release date, review the
+version and known limitations, and tag the exact tested commit. Rebuild source,
+binary and container artifacts from that commit. Publish SHA-256 checksums,
+build/toolchain details, dependency inventory (SBOM), and source revision with
+the artifacts. Include project and third-party licenses in binary distributions.
+
+Only Linux x86-64 has been validated for this candidate. Do not label other
+architectures or operating systems supported without testing them. Pin and
+record container base-image digests for the release build; mutable tags alone
+are not sufficient to reproduce an image.
+
+If runtime code or dependencies change, repeat end-to-end snapshot/delta and
+artifact verification. Documentation-only changes do not establish new runtime
+performance measurements; retain the revision associated with earlier results.