Finalize ConfigKit design and implementation plan

docs/policy/release.md

@@ -2,30 +2,7 @@
 
 **Base Policy Version:** 0.1.0
 
-**Last Updated**: 2026-09-06
-
-## Base Policy Template
-
-This document is the base template for the canonical release policy.
-Repositories that implement this policy should:
-
-1. Retain the substantive requirements of this policy unless a documented
-   repository constraint requires an exception;
-2. Define the repository-specific release procedure, validation commands,
-   supported deliverables, and verification commands in `docs/release.md`;
-3. Ensure that every document and script required by the adopted policy and
-   procedure is present on the filesystem;
-4. Add stricter repository-specific requirements where the product, delivery
-   channels, or threat model require them;
-5. Record every exception under `Policy Exceptions`, including its rationale
-   and compensating controls;
-6. Update the `Last Updated` field to the current date; and
-7. Remove this heading (`Base Policy Template`) and the associated text.
-
-The base policy is a standard, not a collection of optional recommendations.
-An implementing repository should customize its release mechanics without
-silently weakening the common integrity, validation, documentation,
-verification, or immutability guarantees below.
+**Last Updated:** 2026-09-06
 
 ## Purpose
 
@@ -38,6 +15,26 @@ The repository-specific commands that implement these requirements belong in
 `docs/release.md`. Historical release summaries belong in `docs/releases/`.
 Neither document may weaken this policy.
 
+## ConfigKit applicability
+
+ConfigKit adopts a source-only Go module release model. The source tag and
+version-matched release note are the declared deliverables. Standalone binaries,
+container images, and separate binary/package-registry publication are not
+required. This does not waive source compilation, module hygiene, testing, or
+consumer-facing module retrieval and build verification.
+
+The release procedure must define the module path, authoritative remote,
+supported Go versions and operating-system/architecture targets, prerequisite
+dependency acquisition, and the exact verification commands once established.
+The default tests themselves remain deterministic and offline. Additional
+publication channels require documented deliverables and verification before use.
+
+The Go API, documented YAML/resolution semantics, and structured diagnostic
+contracts all participate in compatibility review. A signature-preserving change
+can still break consumers. Human diagnostic wording is stable only where a
+contract expressly promises it. Minimum Go version and platform support changes
+also require an explicit compatibility assessment.
+
 ## Release Model
 
 A release consists of:
@@ -111,7 +108,7 @@ This release ...
 ## Changes
 ```
 
-Use an explicit statement such as "No action required" when a section has no 
+Use an explicit statement such as "No action required" when a section has no
 substantive content.
 
 Release notes are immutable historical summaries. They should link to current
@@ -138,7 +135,7 @@ The required gates are:
 - validation of maintained examples, configuration, schemas, generated
   sources, and documentation commands where applicable;
 - review of changed local documentation links;
-- removal of obsolute roadmap documents under `docs/roadmap/` that describe
+- removal of obsolete roadmap documents under `docs/roadmap/` that describe
   completed work included in the release;
 - review for unintended files, generated output, credentials, private data,
   and unrelated changes; and
@@ -220,3 +217,22 @@ name the primary branch, authoritative remote, tag form, published
 deliverables, supported build targets, release automation responsibilities,
 and consumer verification path. It must link to this policy instead of
 restating or redefining its requirements.
+
+## Policy Exceptions
+
+### Temporary bootstrap deferral
+
+The release procedure (`docs/release.md`) and complete release-check command are
+not yet present because ConfigKit has no Go module or implementation to validate.
+Their creation is temporarily deferred during initial development. This exception
+permits implementation work; it does not permit publishing a release without
+any gate required above.
+
+Compensating controls: no release may be published until the
+[release-readiness gaps](../roadmap/release-readiness.md) are closed, the runbook
+and checker exist, and the exact candidate passes all applicable gates. The
+maintainer preparing the first release owns closure. Remove this temporary
+exception when readiness is verified. Any other exception requires a documented repository constraint, rationale,
+compensating controls, scope, and closure condition here; none is currently
+adopted. Do not silently weaken the base integrity, validation, documentation,
+verification, or immutability guarantees.