Add guarded single-command release publication

docs/policy/release.md

@@ -6,10 +6,8 @@
 
 **Upstream Source:** [Standard Repository Policies](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/release.md)
 
-ConfigKit retains its separately invoked checker and guarded
-[release procedure](../release.md). A single publication command and review of
-the current gates are future work under the
-[release-workflow roadmap](../roadmap/release.md).
+ConfigKit's [release procedure](../release.md) uses one publication command
+with the selected local checker and explicit main-then-tag pushes.
 
 ## Purpose
 
@@ -73,6 +71,10 @@ check consumer installation or Go module availability as completion gates.
 Optional remote tag read-back and fresh consumer retrieval do not delay release
 completion.
 
+A failed or ambiguous push requires resolving the authoritative remote state
+before declaring success or retrying; successful pushes do not require a
+separate remote read-back gate.
+
 ConfigKit publishes source only. If additional deliverables are deliberately
 adopted, they must be traceable to the tagged source, identify the same version,
 and have documented publication responsibilities and verification.
@@ -85,8 +87,9 @@ release in place.
 ## Versioning And Compatibility
 
 Stable releases use Semantic Versioning in the form `vMAJOR.MINOR.PATCH`, with
-no leading zeroes. Each version must be unused locally and in every configured
-remote or publication channel before publication begins.
+no leading zeroes. The selected version must be unused locally and on the
+authoritative remote. A version known to have been published elsewhere must
+not be reused.
 
 Unless an adopted policy explicitly supports and defines prereleases,
 prerelease versions are not permitted.
@@ -114,24 +117,9 @@ Every release made under this policy must include
 the complete version tag, and the document must begin with a title containing
 the product name and that exact version.
 
-Every new release note must contain these sections:
-
-```markdown
-# <Product> vMAJOR.MINOR.PATCH
-
-This release ...
-
-## Summary
-
-## Compatibility
-
-## Upgrade
-
-## Changes
-```
-
-Use an explicit statement such as "No action required" when a section has no
-substantive content.
+Include a short summary and any relevant compatibility impact or upgrade
+instructions. Choose sections suited to the release and keep the note
+proportionate to the change. The annotated tag's message is the checked-in note.
 
 Release notes are immutable historical summaries. They should link to current
 canonical documentation for exact behavior. Every affected canonical document
@@ -146,10 +134,11 @@ gate; historical release notes are unchanged.
 
 ## Candidate Preparation And Validation
 
-ConfigKit provides one local release checker. Run it once against the final
-committed candidate using one maintained patch of the minimum supported Go line
-on Linux. It runs one full offline race suite, one full vet pass, and CGO-disabled
-Linux amd64/arm64 builds. The race suite protects library behavior, ownership,
+The publication command validates the final committed candidate once with
+ConfigKit's local release checker, using one maintained patch of the minimum
+supported Go line on Linux. The checker runs one full offline race suite, one
+full vet pass, and CGO-disabled Linux amd64/arm64 builds. The race suite
+protects library behavior, ownership,
 and concurrent use; it includes examples, documentation links, consumer fixtures,
 and package boundaries without separate runs. Full vet checks more than the
 subset normally run by tests, so test-time vet is disabled. The two cross-builds
@@ -160,9 +149,9 @@ All Go checks use readonly module mode and an offline dependency cache.
 Formatting and whitespace remain ordinary development checks. Review module
 tidiness when dependencies change, rather than auditing it on every release.
 
-Commit the release note and associated changes before release validation. Record
-the exact validated commit; revalidate if the candidate changes. Do not require
-both pre-commit and post-commit full checker runs for unchanged content.
+Commit the release note and associated changes before release validation. The
+publication command captures the exact candidate and rechecks it after the
+validator. A changed candidate requires a fresh invocation and validation.
 Do not publish uncommitted or unvalidated content. Local check failures still
 block publication. Skipped test cases are reported, not separate human sign-off
 requirements.
@@ -177,25 +166,25 @@ research belongs to maintenance or relevant changes, not every release.
 
 ## Publication Guards
 
-Immediately before publication, the maintainer or release automation must
-fetch the current primary branch and tags from the authoritative remote and
-verify all of the following:
+Publication requires authorization before invoking the command. The command
+must verify all of the following:
 
-- the version has the required format and is not already published;
-- the current branch is the primary release branch;
-- the worktree and index are clean;
-- the current commit is the recorded, validated candidate;
-- the authoritative remote branch points to that same commit;
-- the matching release note exists in that commit and has the required title
-  and sections;
-- release publication is authorized and the local automated gates succeeded for
-  that commit; and
-- no local or remote tag already uses the selected version.
+- the stable version has the required format and is unused locally and on the
+  authoritative remote;
+- the current branch is `main`, and the worktree and index are clean;
+- the committed source and matching release note identify the exact validated
+  candidate;
+- the authoritative remote main can advance to that candidate without
+  discarding history;
+- the local automated gates succeeded for that commit; and
+- the annotated tag identifies that candidate and only the intended refs are
+  published.
 
-Create the version tag against the guarded commit and verify its target before
-publishing it. Publish only the exact intended ref and deliverables. Broad
-operations such as `git push --tags` are discouraged because they can publish
-unreviewed refs unrelated to the release.
+Push the exact candidate to authoritative main, then create and verify the
+annotated tag before pushing only its ref. Do not use `git push --tags` or
+implicit follow-tags publication. A failed or ambiguous push receives one
+authoritative-state check before success, rejection, or unknown status is
+reported.
 
 The repository-specific procedure must make these guards executable or give
 copyable commands for performing them.
@@ -207,10 +196,13 @@ overwrite, recreate, or delete a published tag, or replace a published artifact,
 checksum, signature, provenance statement, or release note under that version.
 The checked-in note at the immutable tag is that release's historical record.
 
-If validation fails before publication, correct the candidate, rerun the
-complete gates, and repeat the publication guards. An unpublished local tag
-may be removed after confirming that it was never published or used by a
-release channel.
+If validation fails before publication, correct and commit the candidate and
+rerun the publication command. If a push fails or its outcome is ambiguous,
+inspect the authoritative remote before retrying. Remove an unpublished local
+tag only after confirming it was never published or used by a release channel.
+An unavailable remote leaves publication status unknown; do not overwrite a tag
+to resolve uncertainty. A transient transport failure alone does not require
+a new version.
 
 If publication or post-publication verification reveals a defect, leave the
 published release intact. Correct the defect on the primary branch, choose a
@@ -223,25 +215,11 @@ release's contents or reuse its version.
 
 ## Repository Release Procedure
 
-Every adopting repository must maintain `docs/release.md` as the canonical
-maintainer runbook for implementing this policy. It must define, in execution
-order:
-
-1. maintainer prerequisites and required access;
-2. version selection and compatibility review;
-3. release-note creation;
-4. candidate preparation and commit;
-5. one local validation pass, exact candidate recording, and push;
-6. publication guards;
-7. exact tag and deliverable publication commands;
-8. completion on successful tag push and optional post-publication checks; and
-9. failure handling and correction.
-
-The procedure should use copyable, fail-fast commands where practical. It must
-name the primary branch, authoritative remote, tag form, published
-deliverables, supported build targets, release automation responsibilities,
-and optional consumer verification path. It must link to this policy instead of
-restating or redefining its requirements.
+Maintain `docs/release.md` as the executable maintainer runbook. It identifies
+prerequisites, version and note preparation, the single publication command,
+declared deliverables and build targets, successful-tag-push completion, and
+partial or unknown-state recovery. Keep optional diagnostics and consumer
+verification clearly optional. The procedure must agree with this policy.
 
 ## Policy Exceptions