Expand optional candidate checks for v0.2.0

docs/roadmap/model.md

@@ -19,8 +19,8 @@ commands to the additional-check callback.
 
 This provides a common procedure and a product-specific extension point. The
 request and profile currently have no structured selection for shared optional
-validation. Race testing, full vet, package compilation, formatting, and
-Markdown checks need a coherent home as they are added.
+validation. Race testing, full vet, package compilation, formatting, Markdown,
+module-distribution, and file-size checks need a coherent home as they are added.
 
 The model should let consumers declare their choices once while ReleaseKit owns
 execution and coordination. This follows [ADR 0002](../adr/0002-routine-releases.md):
@@ -28,6 +28,10 @@ shared capabilities should reduce application code and routine developer
 decisions. The facade boundaries in [ADR 0001](../adr/0001-public-facade.md)
 provide the existing architectural foundation.
 
+Optional capabilities can serve a small subset of consumers when they remove
+application-owned release mechanics and have clear scope, compact configuration,
+and proportionate maintenance costs.
+
 ## Target end state
 
 ### One validation specification
@@ -37,10 +41,11 @@ Add a facade-owned `ValidationSpec` to `ReleaseRequest`, with a corresponding
 JSON settings to express the same supported selections. Group related choices,
 including base-test and vet settings, so their relationship is clear.
 
-The specification accommodates the agreed race, full-vet, package-compilation,
-Go-formatting, and Markdown-link capabilities. Its zero value and an omitted
-profile object preserve current default validation. Consumers enable optional
-checks according to their product needs.
+The specification accommodates the agreed capabilities in the
+[release roadmap](v0.2.0.md), including optional Markdown boundary enforcement,
+independent module-distribution rules, and file-size settings. Its zero value
+and an omitted profile object preserve current default validation. Consumers
+enable optional checks according to their product needs.
 
 Go callers and CLI users receive equivalent validation behavior. The CLI owns
 profile parsing and presentation; the facade owns the public types and contracts;
@@ -64,11 +69,25 @@ the selected capabilities. The public model expresses validation choices;
 ReleaseKit maintains their execution procedure. Existing candidate rechecks,
 offline validation, and source-publication outcomes retain their meaning.
 
+### Candidate-content inspection
+
+File-oriented checks share candidate-file enumeration and inspection where
+useful. Their scope is the captured candidate, and inspection remains offline
+and read-only. Module-distribution rules inspect the files being released
+independently of the environment used to run Go commands. Markdown boundary
+validation operates independently of neighboring checkout contents.
+
+Keep each check's settings together: Markdown validation owns its optional
+boundary rule; module-distribution validation owns its independent rule
+selections; file-size validation owns its limit and path exclusions. The
+[release roadmap](v0.2.0.md) defines the scope and defaults of each capability.
+
 ### Clear responsibility boundaries
 
 | Concern | Model owner |
 | --- | --- |
-| Base tests, full vet, package compilation, formatting, and Markdown links | Shared validation specification |
+| Base tests, full vet, and package compilation | Shared validation specification |
+| Formatting, Markdown links, module distribution, and file size | Shared validation specification |
 | Product-specific assertions and example checks | Existing `AdditionalChecks` callback and profile `checks` |
 | Expected authoritative push destination | Publication settings and endpoint handling |
 | Executable package, binary name, and artifact targets | Build declaration |
@@ -87,8 +106,9 @@ remain separate from offline candidate validation.
 
 Shared validation failures identify the check and expose useful details to Go
 callers. File-oriented checks provide source locations and actionable findings
-where applicable. The CLI presents those details consistently through the
-ordinary candidate-check and publication commands.
+where applicable, including relevant paths, directives, and measured values.
+The CLI presents those details consistently through the ordinary candidate-check
+and publication commands.
 
 Use a small facade-owned error model with stable check identity and support for
 underlying error causes and cancellation. Preserve `errors.Is` and `errors.As`
@@ -107,6 +127,8 @@ failure-stopping behavior of the candidate workflow.
   covering defaults, related selections, and their mapping to shared execution.
 - Consolidate request conversion and validation coordination where needed so
   `Check`, `Publish`, and their CLI forms use the same decisions.
+- Define shared candidate-file inspection and compact settings for related
+  rules, limits, and exclusions, preserving each capability's declared scope.
 - Define check identity, useful diagnostic detail, error wrapping, and CLI
   presentation as one small model for the accepted capabilities.
 - Preserve the additional-check extension point and the separate publication,