Add agreed PromptKit features to the v0.2.0 roadmap

docs/roadmap/v0.2.0.md

@@ -69,6 +69,8 @@ update for this integration and a maintained template they can adopt directly.
 
 ReleaseKit always runs its standard offline Go suite before additional product
 checks. ConfigKit selects race-enabled testing for its release validation.
+PromptKit requests the same capability for its concurrent execution and
+backend-capacity management.
 Expressing that selection as an additional check would execute the suite twice
 and leave the application coordinating shared validation mechanics.
 
@@ -95,16 +97,17 @@ unavailable prerequisites clearly and preserves the selected validation.
 - Update consumer guidance and verify default behavior, one selected suite run,
   consistent API/CLI behavior, and propagation of validation failures.
 
-Completion should let ConfigKit select its race-enabled suite once and remove
+Completion should let ConfigKit and PromptKit select a race-enabled suite once
-the corresponding consumer-owned test invocation.
+and remove the corresponding consumer-owned test invocation.
 
 ## 3. Offer a separate full vet pass
 
 ### Rationale and current baseline
 
-ConfigKit selects a full `go vet` pass in addition to its test suite. ReleaseKit
+ConfigKit and PromptKit currently run a full `go vet` pass in addition to their
-currently relies on test-time vet unless a consumer supplies an additional
+test suites. ReleaseKit relies on test-time vet unless a consumer supplies an
-command. That leaves consumers coordinating vet coverage and repeated work.
+additional command. That leaves consumers coordinating vet coverage and
+repeated work.
 
 ### Target end state
 
@@ -124,8 +127,8 @@ ReleaseKit owns the offline command and its coordination with base testing.
 - Document the selection and verify ordering, test-time vet omission, failure
   handling, and unchanged default behavior through the shared validation path.
 
-Completion should replace ConfigKit's separate vet command and manual
+Completion should replace ConfigKit's and PromptKit's separate vet commands and
-test-time vet setting with one declarative choice.
+manual test-time vet settings with one declarative choice.
 
 ## 4. Verify package compilation for selected targets
 
@@ -194,3 +197,79 @@ 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
+
+### Rationale and current baseline
+
+PromptKit maintains a shell loop that enumerates tracked Go files and checks
+their formatting. ReleaseKit currently leaves this generic mechanism to
+consumer-owned additional checks. Shared support would remove that script
+fragment and provide consistent diagnostics across applications.
+
+### Target end state
+
+An optional public API and profile selection enables formatting validation for
+tracked Go source using ordinary `gofmt` conventions. `Check` and `Publish`,
+including their CLI forms, apply the same check within candidate validation.
+The check runs offline, reports affected paths, and leaves files unchanged.
+
+Consumers select the capability once and rely on ReleaseKit for enumeration,
+format checking, and failure reporting. Existing validation defaults remain
+unchanged when the option is unset.
+
+### Work needed
+
+- Add formatting selection and shared inspection of tracked Go source to the
+  candidate-validation API, profile, and execution path.
+- Provide actionable diagnostics for formatting differences and inspection
+  failures while preserving source files.
+- Document the formatting convention and verify formatted and unformatted
+  inputs, consistent API/CLI behavior, and unchanged default validation.
+
+Completion should let PromptKit remove its local formatting loop and select
+the shared check through its release profile.
+
+## 7. Offer offline Markdown-link validation
+
+### Rationale and current baseline
+
+PromptKit's largest generic validation block is a local Markdown-link checker.
+It owns parsing, destination resolution, heading anchors, and diagnostics.
+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.
+
+### Target end state
+
+An optional public API and profile selection checks tracked Markdown documents
+for local destinations and supported heading fragments within the checkout.
+`Check` and `Publish`, including their CLI forms, use the same offline,
+read-only validation and report the source file, location, and target of each
+problem.
+
+ReleaseKit owns a documented link and heading-anchor convention that consumers
+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.
+Existing validation defaults remain unchanged when the option is unset.
+
+### Work needed
+
+- Define the supported Markdown link forms and heading-anchor convention,
+  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.
+- Document supported behavior and verify valid and broken links, heading
+  fragments, representative Markdown syntax, and handling of code examples
+  and links outside the checkout.
+- 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.