Record the priorities for routine releases

docs/adr/0002-routine-releases.md

@@ -0,0 +1,63 @@
+# ADR 0002: Make routine releases a shared responsibility
+
+## Status
+
+Accepted.
+
+## Date
+
+2026-10-06
+
+## Context
+
+Applications in the suite repeat release code and require developers to manage
+similar release decisions. ReleaseKit centralizes this work. Its value depends
+on reducing application maintenance and the time developers spend on releases.
+
+Build specialization, environment standardization, and detailed inspection can
+serve particular consumers. Supporting them can also expand the API,
+configuration, and release knowledge each application must maintain. ReleaseKit
+needs a clear priority for evaluating these tradeoffs.
+
+## Decision
+
+ReleaseKit provides a standard, minimal API for routine releases. It minimizes
+application-owned release code, duplication across applications, and the
+decisions application developers must make.
+
+ReleaseKit owns the common release procedure and sensible defaults. Applications
+supply product facts, compatibility requirements, and product-specific checks.
+
+Hardware-specific build options, strict build reproducibility, extensive build
+inspection, and comparable specialization are non-goals to the extent that
+supporting them conflicts with these primary goals.
+
+Evaluate proposed capabilities by their effect on ordinary application
+integration: the code applications maintain, the configuration they supply, and
+the release decisions developers make. A demonstrated consumer need informs
+that assessment; the selected approach must preserve the routine release model.
+
+## Alternatives considered
+
+- A broadly configurable release toolkit gives applications control over build
+  and release mechanics. Applications then own more composition code and
+  configuration decisions.
+- A tightly standardized build environment prioritizes reproducibility and
+  detailed build records. It adds environment maintenance and coordination
+  responsibilities across applications.
+
+The selected approach evaluates those capabilities by the application work and
+developer effort they save.
+
+## Consequences
+
+Common release operations belong behind reusable orchestration. Shared defaults
+reduce configuration and routine decisions. ReleaseKit can absorb internal
+complexity when doing so keeps application integration small and maintainable.
+
+New options carry implementation, maintenance, and decision costs. Consumer
+needs justify evaluating an option; its adoption must support the primary goals.
+
+The [architecture policy](../policy/architecture.md) owns current architectural
+constraints. [ADR 0001](0001-public-facade.md) records the facade boundaries.
+GoDoc owns exact API contracts.

docs/development.md

@@ -12,6 +12,9 @@ The [architecture policy](policy/architecture.md) governs development boundaries
 [documentation policy](policy/documentation.md#canonical-ownership) owns the
 documentation topic map.
 
+[ADR 0002](adr/0002-routine-releases.md) records the priorities and non-goals
+behind ReleaseKit's standard, minimal API for routine releases.
+
 ## Policy Reading Guide
 
 | Policy | Read before… |