Expand optional candidate checks for v0.2.0

docs/roadmap/v0.2.0.md

@@ -272,6 +272,8 @@ ReleaseKit currently leaves these mechanics to consumer-owned additional checks.
 
 Sharing the check would remove a locally maintained parser and give consumers
 one documented convention for validating navigation within their documentation.
+Consumers that require documentation to remain within the checkout also need
+a shared option to enforce that boundary.
 
 ### Target end state
 
@@ -286,9 +288,10 @@ can follow. The supported behavior accounts for common inline and reference
 links, code examples, escaped destinations, and duplicate headings. External
 website availability is outside the check's scope.
 
-Links outside the checkout are classified and reported as outside the shared
-check's scope. Validation remains independent of neighboring checkouts;
-consumer-specific restrictions on those links remain additional product checks.
+By default, links outside the checkout are classified and reported as outside
+the shared check's scope. An optional setting makes local destinations outside
+the checkout a validation failure, using the same parser and diagnostics.
+Boundary validation remains independent of neighboring checkout contents.
 Existing validation defaults remain unchanged when the option is unset.
 
 ### Work needed
@@ -297,11 +300,86 @@ Existing validation defaults remain unchanged when the option is unset.
   including destination resolution and diagnostics for out-of-scope links.
 - Add shared parsing and local destination/fragment validation behind the
   public validation API and profile selection.
+- Add the optional checkout-boundary rule to the shared Markdown settings,
+  with diagnostics that identify the source location and destination.
 - Document supported behavior and verify valid and broken links, heading
   fragments, representative Markdown syntax, and handling of code examples
-  and links outside the checkout.
+  and links outside the checkout with the boundary rule enabled and disabled.
 - Verify that checking is offline, preserves files, and behaves consistently
   through candidate checking and publication.
 
 Completion should let PromptKit replace its local Markdown checker with a
 profile selection and rely on shared parsing rules and diagnostics.
+
+## 9. Offer module-distribution checks
+
+### Rationale and current baseline
+
+PromptKit checks that released source is independent of neighboring checkouts
+by excluding committed workspace files and local filesystem module replacements.
+ReleaseKit's offline Go environment controls validation execution; inspecting
+the distributed candidate requires separate checks that consumers currently own.
+
+Shared inspection would remove these local checks and provide consistent
+diagnostics for consumers with the same distribution requirements.
+
+### Target end state
+
+The public API and profile offer independently selectable rules for committed
+workspace files (`go.work` and `go.work.sum`) and local filesystem replacements
+in committed module declarations. Each selected rule reports offending paths
+and, where applicable, module directives through shared candidate validation.
+
+The replacement rule permits versioned module replacements. Workspace use and
+vendoring retain their existing behavior unless affected by a selected rule.
+The checks inspect candidate contents independently of the Go test environment.
+`Check` and `Publish`, including their CLI forms, apply the same offline,
+read-only checks. Omitted selections preserve current defaults.
+
+### Work needed
+
+- Add independent distribution-rule selections to the validation API and profile.
+- Implement shared candidate-file inspection and module-declaration parsing,
+  distinguishing local filesystem replacements from versioned replacements.
+- Document the inspection scope and diagnostics, and verify workspace files,
+  local and versioned replacements, and independent rule selection.
+- Verify equivalent API/CLI behavior, unchanged defaults, and inspection of
+  distributed files regardless of workspace discovery settings during testing.
+
+Completion should let PromptKit declare its distribution requirements and
+remove the corresponding consumer-owned checks.
+
+## 10. Offer an individual-file-size check
+
+### Rationale and current baseline
+
+Unintentionally committed binaries and large assets can increase the size of
+released source. ReleaseKit currently leaves file-size inspection to consumers.
+A shared check would catch oversized files while allowing each consumer to
+declare its intended size limit and exceptions.
+
+### Target end state
+
+An optional public API and profile selection checks individual tracked files
+in the current candidate. When enabled, the default limit is 1 MB (1,000,000
+bytes); consumers can configure the limit and explicit repository-relative
+path exclusions for intentional large files. A file exceeding the limit fails
+validation with its path, observed size, and configured limit.
+
+The check measures file size. Small binaries remain subject to ordinary review.
+Its scope is the current candidate's files; historical objects and aggregate
+repository size remain separate concerns. `Check` and `Publish`, including
+their CLI forms, use the same offline, read-only inspection. The check is
+disabled by default.
+
+### Work needed
+
+- Add file-size selection, a configurable byte limit, and path exclusions to
+  the shared validation API and profile.
+- Implement candidate-file size inspection with actionable diagnostics.
+- Document units, threshold behavior, exclusions, and the scope of inspection.
+- Verify files below, at, and above the limit; configured limits and exclusions;
+  and equivalent API/CLI behavior with the check enabled and disabled.
+
+Completion should let consumers catch oversized candidate files through a
+small declaration and remove any corresponding local inspection code.