Finalize the v0.2.0 implementation plan

docs/roadmap/v0.2.0.md

@@ -1,10 +1,10 @@
 # ReleaseKit v0.2.0 roadmap
 
-Status: Draft scope for the next release.
+Status: Agreed feature scope; implementation planning is recorded separately.
 
 This roadmap catalogs improvements to ReleaseKit v0.1.0. Each item records its
-rationale, target state, and scope of work. A staged implementation plan will
+rationale, target state, and relevant scope decisions. The
-follow once the release scope is finalized.
+[implementation plan](implementation.md) owns the staged work.
 
 The priorities in [ADR 0002](../adr/0002-routine-releases.md) guide this work:
 minimize application-owned release code, duplicated mechanics, and routine
@@ -14,9 +14,11 @@ developer decisions through a standard, minimal API.
 
 ### Rationale and current baseline
 
-ReleaseKit has a shared candidate workflow and a product-specific additional
+The shared validation foundation and its remediation are complete. ReleaseKit
-check extension point. The optional validation capabilities planned for v0.2.0
+has common candidate execution, facade-owned diagnostics, committed-file
-need a coherent selection and diagnostic model across the Go API and profile.
+inspection, and a product-specific additional-check extension point. The
+optional v0.2.0 capabilities still need their functioning API/profile selections
+and checker implementations.
 
 The [validation-model roadmap](model.md) records this enabling work and its
 rationale. A common model lets consumers declare choices once and receive
@@ -30,17 +32,8 @@ 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
+Completion should provide equivalent Go and profile declarations for the
-
+validation capabilities below through the existing shared foundation.
-- 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
 
@@ -76,21 +69,7 @@ validation and builds. Source publication and hosted delivery retain separate
 outcomes. ReleaseKit's own source bootstrap and consumers using a separately
 installed tool remain supported use cases.
 
-### Work needed
+Audita adopts the module-based integration as the first consumer migration.
-
-- Revise the maintained CI template to establish the tagged checkout before
-  selecting and building the module's ReleaseKit command. Remove the separate
-  version setting from this module-based integration and keep bootstrap logic
-  small and reusable.
-- Update adoption and upgrade guidance to explain module-based selection,
-  compatible Go environments, dependency preparation, and migration from the
-  existing workflow pin. Explain the applicable bootstrap for consumers that
-  use a separately installed tool.
-- Adapt workflow verification to exercise tool selection from the tagged
-  module configuration, including a dependency-version change, while preserving
-  tag/commit checks and existing source-only and binary delivery behavior.
-- Apply the revised integration to Audita as the first consumer migration and
-  confirm that its local wrapper and CI use the same module-selected tool.
 
 Completion should leave downstream maintainers with one ReleaseKit dependency
 update for this integration and a maintained template they can adopt directly.
@@ -120,15 +99,6 @@ scope, offline execution, ordering, and failure reporting. Additional product
 checks remain available after shared validation. Selecting race testing reports
 unavailable prerequisites clearly and preserves the selected validation.
 
-### Work needed
-
-- Add compact validation options to the facade and profile, and carry them
-  through both candidate-check and publication paths.
-- Extend shared Go invocation handling to apply race selection to the base
-  suite while preserving its offline environment and native test behavior.
-- Update consumer guidance and verify default behavior, one selected suite run,
-  consistent API/CLI behavior, and propagation of validation failures.
-
 Completion should let ConfigKit and PromptKit select a race-enabled suite once
 and remove the corresponding consumer-owned test invocation.
 
@@ -151,14 +121,6 @@ with failures reported through the ordinary check and publication flow.
 The option preserves current defaults for consumers that leave it unset.
 ReleaseKit owns the offline command and its coordination with base testing.
 
-### Work needed
-
-- Add the full-vet selection to shared validation configuration and execution.
-- Coordinate the base test invocation with the separate pass so consumers
-  express the desired coverage once.
-- 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 and PromptKit's separate vet commands and
 manual test-time vet settings with one declarative choice.
 
@@ -186,16 +148,6 @@ require no binary name, version smoke command, or artifact manifest. Successful
 compilation establishes build compatibility; execution on a target remains a
 separate concern. Consumers select targets for their support commitments.
 
-### Work needed
-
-- Add a package-compilation target declaration to validation configuration,
-  distinct from the existing artifact build specification.
-- Reuse internal Go environment and target handling for offline compilation,
-  replacing consumer-owned loops and preserving one base test execution.
-- Document the distinction between compatibility checks and deliverables, and
-  verify selected-target compilation, failure reporting, and unchanged
-  source-only delivery behavior.
-
 Completion should let ConfigKit declare its two Linux targets and remove its
 release-specific compilation loop.
 
@@ -221,15 +173,6 @@ The expectation applies to the publication destination. Fetch configuration
 retains its existing semantics, and `Check` retains its local-only behavior.
 Consumers that omit the expectation keep the current remote-selection model.
 
-### Work needed
-
-- Add the optional expectation to the facade and profile and compare it at
-  the existing publication endpoint-resolution boundary.
-- Reuse captured-endpoint handling and define the destination-comparison
-  semantics in GoDoc and consumer guidance.
-- Verify matching, mismatching, and omitted expectations, including resolved
-  Git URL behavior, while preserving existing recheck and recovery coverage.
-
 Completion should let consumers declare the intended push destination without
 maintaining their own publication preflight logic.
 
@@ -253,15 +196,6 @@ 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.
 
@@ -298,20 +232,6 @@ 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
-
-- 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.
-- 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 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.
 
@@ -340,16 +260,6 @@ 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.
 
@@ -376,14 +286,5 @@ 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.