Outline the shared validation model for v0.2.0

docs/roadmap/v0.2.0.md

@@ -10,7 +10,39 @@ The priorities in [ADR 0002](../adr/0002-routine-releases.md) guide this work:
 minimize application-owned release code, duplicated mechanics, and routine
 developer decisions through a standard, minimal API.
 
-## 1. Use the application's module-selected ReleaseKit version in CI
+## 1. Establish the shared validation API and profile model
+
+### Rationale and current baseline
+
+ReleaseKit has a shared candidate workflow and a product-specific additional
+check extension point. The optional validation capabilities planned for v0.2.0
+need a coherent selection and diagnostic model across the Go API and profile.
+
+The [validation-model roadmap](model.md) records this enabling work and its
+rationale. A common model lets consumers declare choices once and receive
+ReleaseKit's shared execution and coordination.
+
+### Target end state
+
+A facade-owned validation specification and corresponding profile object
+express the agreed optional checks with consistent defaults and behavior.
+ReleaseKit owns coordination and diagnostics through the existing `Check` and
+`Publish` operations. Product-specific checks, publication expectations,
+artifact builds, and delivery retain their distinct responsibilities.
+
+### Work needed
+
+- Design and integrate the shared specification, profile mapping, execution,
+  and error model described in [model.md](model.md).
+- Preserve existing default behavior and additional-check support, and align
+  GoDoc, profile guidance, and CLI reporting as the model lands.
+- Evaluate the model against Audita, ConfigKit, and PromptKit before finalizing
+  the interfaces used by the individual validation features.
+
+Completion should provide a common foundation for the validation capabilities
+below, with small consumer declarations and reusable execution.
+
+## 2. Use the application's module-selected ReleaseKit version in CI
 
 ### Rationale and current baseline
 
@@ -63,7 +95,7 @@ installed tool remain supported use cases.
 Completion should leave downstream maintainers with one ReleaseKit dependency
 update for this integration and a maintained template they can adopt directly.
 
-## 2. Select one base test invocation, including race testing
+## 3. Select one base test invocation, including race testing
 
 ### Rationale and current baseline
 
@@ -100,7 +132,7 @@ unavailable prerequisites clearly and preserves the selected validation.
 Completion should let ConfigKit and PromptKit select a race-enabled suite once
 and remove the corresponding consumer-owned test invocation.
 
-## 3. Offer a separate full vet pass
+## 4. Offer a separate full vet pass
 
 ### Rationale and current baseline
 
@@ -130,7 +162,7 @@ ReleaseKit owns the offline command and its coordination with base testing.
 Completion should replace ConfigKit's and PromptKit's separate vet commands and
 manual test-time vet settings with one declarative choice.
 
-## 4. Verify package compilation for selected targets
+## 5. Verify package compilation for selected targets
 
 ### Rationale and current baseline
 
@@ -165,7 +197,7 @@ separate concern. Consumers select targets for their support commitments.
 Completion should let ConfigKit declare its two Linux targets and remove its
 release-specific compilation loop.
 
-## 5. Check an optional expected publication endpoint
+## 6. Check an optional expected publication endpoint
 
 ### Rationale and current baseline
 
@@ -198,7 +230,7 @@ Consumers that omit the expectation keep the current remote-selection model.
 Completion should let consumers declare the intended push destination without
 maintaining their own publication preflight logic.
 
-## 6. Offer Go formatting validation
+## 7. Offer Go formatting validation
 
 ### Rationale and current baseline
 
@@ -230,7 +262,7 @@ unchanged when the option is unset.
 Completion should let PromptKit remove its local formatting loop and select
 the shared check through its release profile.
 
-## 7. Offer offline Markdown-link validation
+## 8. Offer offline Markdown-link validation
 
 ### Rationale and current baseline