Complete the v0.2.0 implementation audit

README.md

@@ -26,7 +26,8 @@ go run ./cmd/releasekit version
 ```
 
 The local candidate check validates a committed release note, runs the standard
-offline Go test suite, and then runs any configured additional checks:
+offline Go suite with any selected shared validation checks, and then runs
+configured product checks:
 
 ```sh
 go run ./cmd/releasekit check v1.2.3

docs/internal/overview.md

@@ -79,6 +79,7 @@ not a separate release matrix:
 | --- | --- | --- |
 | Runtime version lookup and injected application version | `buildinfo`, `internal/runtimeinfo`, `internal/versioncontract`, `internal/build` | `TestVersionInConsumerExecutable`, `TestVersion` |
 | Candidate capture, shared validation, public diagnostics, additional checks, and rechecks | `releasekit.Check`, `releasekit.Publish`, `internal/candidate`, `internal/validation`, `cmd/releasekit/internal/cli` | `TestRunUsesOneSuiteWithSelectedRaceSetting`, `TestRunReportsRacePrerequisiteFailureWithoutFallback`, `TestRunExecutesRaceEnabledSuiteOnHost`, `TestRunCompilesTargetsAfterTestAndVetInSelectionOrder`, `TestRunAttributesTargetCompileFailureAndStops`, `TestRunCompilesSourceOnlyAndExecutablePackagesWithoutArtifacts`, `TestCandidateRequestMapsGoValidation`, `TestCandidateRequestPreservesMarkdownObjectSelection`, `TestLoadSettingsReadsGoValidation`, `TestLoadSettingsPreservesMarkdownObjectSelection`, `TestCheckUsesSelectedRaceSuiteBeforeAdditionalChecks`, `TestCheckCapturesCandidateAndCallsAdditionalChecksOnce`, `TestCheckReturnsPublicValidationError`, `TestMarkdownValidationRunsThroughCheckAndPublish`, `TestCheckStopsBeforeProductAndBuildCallbacksWhenMarkdownBoundaryFails`, `TestCheckCommandBindsConfiguredChecksToCapturedCandidate`, `TestPublishCommandPublishesConfiguredCandidate`, `TestCandidateCommandsPresentValidationDiagnosticsOnce`, `TestDeliverPageOnlyCreatesAndReusesRelease` |
+| Committed-file validation: formatting, workspace files, local replacements, and file size | `internal/validation`, `internal/candidate`, `releasekit.Check`, `releasekit.Publish`, CLI profile conversion | `TestCheckGoFormatUsesCapturedRegularGoBlobs`, `TestCheckWorkspaceFilesReportsCommittedBlobNames`, `TestCheckLocalReplacementsParsesCommittedModuleDeclarations`, `TestCheckLocalReplacementsFollowsCommittedModuleSymlinks`, `TestCheckFileSizeUsesStrictLimitsAndDefault`, `TestCheckFileSizeAppliesLiteralPathExclusions`, `TestCheckFileSizeUsesCommittedBlobSizes`, `TestCheckFileSizeUsesOnlyCandidateFilesIndividually` |
 | Internal Markdown parsing, committed destinations, fragments, boundary observations, and public selection | `releasekit.Check`, `releasekit.Publish`, `internal/candidate`, `internal/validation`, `cmd/releasekit/internal/cli` | `TestParseMarkdownLinksAndSourceLocations`, `TestParseMarkdownDecodesEntitiesInDestinations`, `TestParseMarkdownHeadingAnchors`, `TestMarkdownCacheKeepsParsedDocumentsPerCandidatePath`, `TestCheckMarkdownLinksResolvesCommittedDestinationsAndFragments`, `TestCheckMarkdownLinksReportsMissingPathsAnchorsAndCycles`, `TestCheckMarkdownLinksUsesResolvedMarkdownIdentity`, `TestCheckMarkdownLinksReportsBoundaryAndSubmoduleObservations`, `TestCheckMarkdownLinksPreservesResolverCauseAndCancellation`, `TestCheckMarkdownLinksPreservesAnchorReadCause`, `TestRunSelectsMarkdownWithCombinedGoChecksAndReportsOutOfScopeLinks`, `TestMarkdownValidationRunsThroughCheckAndPublish`, `TestLoadSettingsPreservesMarkdownObjectSelection`, `TestValidationSpecPreservesMarkdownObjectSelection` |
 | Shared Go settings for validation and builds | `internal/gotool`, `internal/process`, `internal/candidate`, `internal/build` | `TestDefaultValidationDoesNotInheritGOFLAGSRunFilter`, `TestNativeAndStaticCommandsUseOwnedBaseline`, `TestPersistentSettingsPreserveCachesAndNativeCTools`, `TestBuildIgnoresAmbientAndPersistentArchitectureTuning` |
 | Authoritative endpoint and exact annotated tag publication | `releasekit.Publish`, `internal/publish`, `internal/git` | `TestPublishPushesOnlyTheCapturedAnnotatedTag`, `TestPublishRejectsUnexpectedPushURLBeforeValidation`, `TestPublishComparesExpectedURLWithResolvedInsteadOfDestination`, `TestPublishExpectedPushURLUsesPushURLWhenFetchAndPushDiffer`, `TestCheckIgnoresExpectedPushURL`, `TestResolveUsesPushURLAndQueriesWithoutMutation` |
@@ -87,7 +88,7 @@ not a separate release matrix:
 | Page-only and managed or prebuilt binary delivery | `releasekit.Deliver`, `internal/delivery`, `internal/gitea`, CLI | `TestDeliverPageOnlySkipsBuildAndHostedAssets`, `TestDeliverManagedBuildUploadsArtifactsAndCleansTemporaryOutput`, `TestDeliverBinaryConsumerWithBuildinfoAndSelectedTargets`, `TestDeliverPrebuiltArtifactsRemainCallerOwned`, `TestDeliverManagedBuildFailureCleansTemporaryOutputBeforeHostedWrites`, `TestDeliverManagedBuildCancellationCleansTemporaryOutput`, `TestDeliverBuildsTaggedArtifactsAndReusesAssets`, `TestDeliverRejectsTamperedAssetsAndStaleReceiptBeforeRemoteWrites` |
 | Tagged checkout and build dependency preparation | `releasekit.PrepareTaggedCheckout`, `releasekit.PrepareBuildDependencies`, `internal/preparation`, `internal/git`, `internal/gotool` | `TestPrepareTaggedCheckoutFetchesExpectedCommitAndDetaches`, `TestPrepareTaggedCheckoutRejectsWrongCommitBeforeCheckout`, `TestPrepareTaggedCheckoutReportsLocalCheckoutConflict`, `TestPrepareTaggedCheckoutReportsConflictingLocalTag`, `TestPrepareBuildDependenciesPreservesPreparationEnvironment`, `TestPrepareBuildDependenciesPropagatesCommandFailure`, `TestPrepareBuildDependenciesPropagatesCancellation` |
 | Page, manifest, asset comparison, and additive retry outcomes | `internal/gitea` | `TestEnsureReleaseCreatesMissingPageFromCommittedNote`, `TestInspectAssetsDetectsSameNameAndSizeWithDifferentBytes`, `TestUploadMissingPartialFailureThenRerunOnlyMissingAssets` |
-| CLI profiles and prepared Woodpecker sequences | `cmd/releasekit`, `cmd/releasekit/internal/cli`, `examples/woodpecker/` | `TestLoadSettingsRejectsInvalidProfiles`, `TestWoodpeckerTagDeliveryTemplate`, `TestReleaseKitSourceDeliveryWorkflowFromTaggedCheckout` |
+| CLI profiles and prepared Woodpecker sequences | `cmd/releasekit`, `cmd/releasekit/internal/cli`, `examples/woodpecker/` | `TestLoadSettingsRejectsInvalidProfiles`, `TestWoodpeckerTagDeliveryTemplate`, `TestWoodpeckerTagDeliveryUsesTaggedModuleVersion`, `TestWoodpeckerSourceDeliveryTemplateSelfBootstraps`, `TestReleaseKitSourceDeliveryWorkflowFromTaggedCheckout` |
 
 Run the complete suite with `go test ./...`. The public API and import boundary
 check is `go run ./internal/apicheck`. Local HTTP and Git fixtures exercise
@@ -101,5 +102,5 @@ are prepared integrations; their YAML is not active in this repository, and no
 live Woodpecker runner, configured secret, or hosted delivery has been used.
 A read-only PromptKit and Narratio migration review and projected deletion
 estimates are recorded in the [product roadmap](../roadmap/releasekit.md);
-actual consumer migrations and measurement of realized savings remain future
+broader migrations beyond Audita and measurement of realized savings remain
-adoption work.
+future adoption work.

docs/roadmap/implementation.md

@@ -1,6 +1,6 @@
 # ReleaseKit v0.2.0 implementation plan
 
-Status: Agreed stages for the remaining v0.2.0 work.
+Status: Complete. Stages 1–15 are implemented and locally verified.
 
 This plan replaces the completed foundation sequence. It implements the target
 state in [v0.2.0.md](v0.2.0.md), using the shared design in [model.md](model.md),
@@ -10,22 +10,21 @@ execute one numbered stage per prompt, in order.
 
 ## Current baseline and completion scope
 
-At `3974a46`, the foundation and all six [remediation findings](remediation.md)
+At baseline commit `3974a46`, the foundation and all six
-are complete. `Check` and `Publish` share candidate-request conversion and validation.
+[remediation findings](remediation.md) were complete. `Check` and `Publish`
+shared candidate-request conversion and validation.
 `internal/validation` runs the default offline suite and owns diagnostics and
 candidate-tree access. Committed-file readers are offline; destination resolution
 handles symlinks, parent traversal, cancellation, and absolute in-checkout paths.
 The root error types and CLI presentation preserve findings and cause context.
 `buildinfo` retains its independent runtime dependency graph.
 
-The shared validation specification and profile settings are implemented
+The stages in this plan complete the remaining v0.2.0 validation selections,
-incrementally with each capability; remaining selections are not yet
+module-selected CI bootstrap, and Audita migration. Audita's migration is
-implemented. The consumer CI template still selects an independent tool
+recorded in commit `17421bc`. The final local audit covers the full Go suite,
-version. This sequence completes every remaining release-roadmap capability and
+compiled API/dependency boundaries, maintained examples, documentation, and
-Audita's CI migration.
+dependency notices. Architecture review, hosted deployment, release tagging,
-It ends with local verification and committed changes. Architecture review,
+and decisions about further testing follow this implementation.
-hosted deployment, release tagging, and decisions about further testing follow
-this implementation.
 
 | Release-roadmap item | Implementation stages |
 | --- | --- |
@@ -621,6 +620,19 @@ or live Woodpecker/Gitea run to complete the stage.
 
 ## Stage 15: Audit the completed v0.2.0 implementation
 
+**Completion:** Complete. All ten release-roadmap items map to implemented API,
+profile, execution, diagnostics, canonical documentation, and focused behavioral
+evidence. The audit confirms default zero-value behavior, independent
+module-distribution selections, one coordinated Go suite, source-only
+compilation/delivery, and expected-push preflight. Review found no unintended
+defaults, restrictions, or stronger guarantees. Audita's migration is recorded
+at `17421bc`.
+
+**Verification:** `go test ./...` and `go run ./internal/apicheck` passed.
+Local Markdown destinations and fragments resolved across the documentation;
+dependency versions, source revisions, attribution entries, and license texts
+were checked. Maintained Woodpecker examples passed their offline fixtures.
+
 **Outcome:** The entire scoped feature set is implemented and locally verified.
 
 1. Match every row in the roadmap/stage table to implemented settings, execution,

docs/roadmap/model.md

@@ -1,7 +1,8 @@
 # Validation API and profile model
 
-Status: Shared validation foundation, Go race selection, and separate full vet
+Status: Complete for the agreed v0.2.0 shared validation model. Every selection
-implemented; remaining v0.2.0 capabilities and their settings are future work.
+and execution path described here is implemented and locally verified; broader
+consumer adoption remains in the product roadmap.
 
 This roadmap describes the shared model that enables the optional validation
 capabilities in the [v0.2.0 roadmap](v0.2.0.md). It owns their common API,
@@ -9,7 +10,7 @@ configuration, execution, and diagnostic design. The release roadmap owns each
 capability's purpose and scope. The [implementation plan](implementation.md)
 owns the stages and the agreed API rollout.
 
-## Rationale and current baseline
+## Rationale and v0.1.0 baseline
 
 ReleaseKit v0.1.0 exposes `Check` and `Publish` through the root facade. Both
 accept `ReleaseRequest` and use shared candidate-validation machinery. Validation
@@ -18,11 +19,11 @@ Selected executable builds follow validation. The CLI maps profile `checks`
 commands to the additional-check callback.
 
 This provides a common procedure and a product-specific extension point. The
-request and profile have structured selections for race testing and a separate
+request and profile have structured selections for race testing, separate full
-full vet pass. Package compilation, formatting, Markdown, module-distribution,
+vet, package compilation, formatting, Markdown, module distribution, and file
-and file-size checks will use the same model as their capabilities are added.
+size. Publication also supports an expected push endpoint.
 
-The model should let consumers declare their choices once while ReleaseKit owns
+The model lets consumers declare their choices once while ReleaseKit owns
 execution and coordination. This follows [ADR 0002](../adr/0002-routine-releases.md):
 shared capabilities should reduce application code and routine developer
 decisions. The facade boundaries in [ADR 0001](../adr/0001-public-facade.md)
@@ -36,12 +37,12 @@ and proportionate maintenance costs.
 
 ### One validation specification
 
-Add a facade-owned `ValidationSpec` to `ReleaseRequest`, with a corresponding
+The facade-owned `ValidationSpec` on `ReleaseRequest` has a corresponding
-`validation` object in the release profile. Use typed Go fields and ordinary
+`validation` object in the release profile. Typed Go fields and ordinary JSON
-JSON settings to express the same supported selections. Group related choices,
+settings express the same supported selections. Related choices, including
-including base-test and vet settings, so their relationship is clear.
+base-test and vet settings, are grouped so their relationship is clear.
 
-The specification accommodates the agreed capabilities in the
+The specification includes 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
@@ -50,7 +51,7 @@ 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;
 internal implementation owns execution. The [implementation plan](implementation.md)
-records the proposed field names, representations, and rollout.
+records the selected field names, representations, and completed rollout.
 
 ### Shared coordination
 
@@ -124,28 +125,25 @@ failure-stopping behavior of the candidate workflow.
 
 ## Implementation
 
-The [implementation plan](implementation.md) records the completed foundation
+The [implementation plan](implementation.md) records the completed rollout and
-and current rollout. The facade exposes `ReleaseRequest.Validation.Go.Race` and
+verification. The facade and CLI profile expose equivalent selections for the
-`FullVet`, and profiles accept `validation.go.race` and
+single test suite, separate full vet, package compilation, formatting, Markdown,
-`validation.go.full_vet`. Race selection adds `-race` to the one base Go suite.
+module distribution, file size, and the expected publication endpoint. Shared
-Full-vet selection disables test-time vet and runs native
+execution, ordering, diagnostics, cancellation, and failure stopping are
-`go vet -mod=readonly ./...` after successful tests. Each remaining setting
+implemented by the owners described above. The maintained Woodpecker template
-will be introduced with its first working capability. Individual checkers,
+and Audita's local wrapper use the module-selected ReleaseKit version; see the
-module-selected CI tooling, and the publication endpoint expectation remain
+[v0.2.0 roadmap](v0.2.0.md) and [delivery guide](../consumers/delivery.md).
-future work in the [v0.2.0 roadmap](v0.2.0.md).
-
-The target state above describes the complete model across those capabilities.
-The rollout establishes shared owners and conversion boundaries incrementally;
-not all optional checks are implemented, and v0.2.0 is not complete.
 
 ## Adoption evidence
 
-Evaluate the design against all three known consumer shapes: Audita's default
+Self-contained integration fixtures evaluate all three known consumer shapes:
-validation and executable builds; ConfigKit's selected test, vet, and library
+Audita's default validation and executable builds; ConfigKit's selected test,
-compilation checks; and PromptKit's shared validation plus substantive example
+vet, and library compilation checks; and PromptKit's shared validation plus
-assertions.
+substantive example assertions. Audita's module-selected CI migration is
+committed at `17421bc`; the other consumer migrations remain separate adoption
+work.
 
-Completion should give each consumer a small declaration and the same routine
+The model gives each adopting consumer a small declaration and the same routine
-release operation. The model should support the agreed v0.2.0 capabilities with
+release operation. Shared execution and diagnostics cover the agreed v0.2.0
-shared execution and clear diagnostics while keeping product-specific work in
+capabilities while product-specific work remains in the existing extension
-the existing extension point.
+point.

docs/roadmap/releasekit.md

@@ -1,7 +1,8 @@
 # ReleaseKit: shared release process
 
-Status: Initial implementation, policy adoption, and architecture remediation
+Status: The v0.2.0 implementation, policy adoption, and architecture
-are complete. Consumer adoption and live CI integration work remain.
+remediation are complete. Audita's module-selected local and CI integration is
+committed at `17421bc`; broader consumer adoption and live deployment remain.
 
 This roadmap records the shared release-process opportunity identified in
 PromptKit, ConfigKit, Audita, Notarius, Narratio, and Scriptorium on 2026-09-29,
@@ -9,8 +10,9 @@ and the remaining adoption goals. The [internal package inventory](../internal/o
 records implemented capability owners and behavioral evidence. The
 [architecture policy](../policy/architecture.md) and
 [ADR 0001](../adr/0001-public-facade.md) own the facade boundaries and rationale.
-The completed implementation, policy adoption, and remediation plans are
+The initial foundation, policy adoption, and remediation plans are preserved
-preserved in Git history.
+in Git history; the current v0.2.0 completion evidence is in the
+[implementation plan](implementation.md).
 
 ## Opportunity
 
@@ -212,7 +214,7 @@ These are migration assessments, not changes to either consumer.
 
 | Consumer | Retain in its profile and product checks | Adaptation and procedure changes |
 | --- | --- | --- |
-| PromptKit, source-only | Product identity; its `Summary`, `Compatibility`, `Upgrade`, and `Changes` release-note sections; checks that exercise the three maintained Go examples and their product outputs. No runtime `buildinfo` import or binary targets are needed. | Its current release scripts total 209 lines. The projected deletion is about 120–160 lines of shared publication and generic validation machinery; retain the note-content rule and product-example checks as a configured additional check plus a small wiring test. PromptKit already pushes `main` before publication and creates annotated tags. Its release policy and procedure still need to add the hosted note page, delivery credentials, versioned CI invocation, and separate delivery status and recovery. |
+| PromptKit, source-only | Product identity; its `Summary`, `Compatibility`, `Upgrade`, and `Changes` release-note sections; checks that exercise the three maintained Go examples and their product outputs. No runtime `buildinfo` import or binary targets are needed. | Its current release scripts total 209 lines. The projected deletion is about 120–160 lines of shared publication and generic validation machinery; retain the note-content rule and product-example checks as a configured additional check plus a small wiring test. PromptKit already pushes `main` before publication and creates annotated tags. Its release policy and procedure still need to add the hosted note page, delivery credentials, module-selected CI invocation, and separate delivery status and recovery. |
 | Narratio, binary | Product/module identity, the `./cmd/narratio` main package, `narratio` executable name, Linux amd64, Linux arm64, and macOS arm64 targets, and the `narratio <version>` command. Keep the module-graph check (`go mod tidy -diff`) if it remains useful as a product-specific candidate check. | Its release, check, asset-builder, and helper scripts total 304 lines; two dedicated release test files total 741 lines. Projected deletions are about 220–280 shell lines and 450–650 repeated test lines, leaving a small consumer wiring test and any retained module/note checks. Replace the private linker-version variable with `buildinfo.Version()` while preserving the current command output. Its policy and procedure need to change lightweight tags to annotated tags, state that a successful tag push completes source publication, and move plugin-based page/assets delivery to the shared versioned CI command with content-aware retries and separately provisioned delivery credentials. |
 
 The deletion figures are estimates from the reviewed files, not measured
@@ -227,14 +229,16 @@ publication and delivery operations.
 
 ## Remaining work
 
-- Use the [v0.1.0 baseline](../releases/v0.1.0.md) for initial consumer integration
+- Use the [v0.1.0 baseline](../releases/v0.1.0.md) for initial consumer
-  under the [maintainer procedure](../release.md).
+  integration under the [maintainer procedure](../release.md). Consumers that
+  adopt the maintained tag workflow select ReleaseKit through the tagged
+  source's `go.mod` rather than a separate workflow version value.
 - Choose the broader consumer integration test plan and migration sequence.
   Evaluate API clarity, product-specific checks, and the infrastructure removed
   from each consuming repository.
 - Provision delivery credentials and activate consumer Woodpecker workflows
-  using the maintained example's `v0.1.0` pin or a later selected immutable
+  as part of deployment. The tagged consumer's module configuration selects
-  version as part of deployment.
+  the ReleaseKit version used by the maintained workflow.
 - Verify live Gitea delivery and Woodpecker execution. Existing verification uses
   local Git and HTTP fixtures; no live deployment has been verified.
 - Keep ReleaseKit executable binary distribution deferred until deliverables

docs/roadmap/v0.2.0.md

@@ -1,10 +1,15 @@
 # ReleaseKit v0.2.0 roadmap
 
-Status: Agreed feature scope; implementation planning is recorded separately.
+Status: Implemented and locally verified. Stages 1–15 are complete; see the
+[implementation plan](implementation.md) for the completion record. Audita's
+module-selected local and CI integration is committed at `17421bc`. Broader
+consumer adoption, architecture review, hosted deployment, and release tagging
+remain separate work.
 
 This roadmap catalogs improvements to ReleaseKit v0.1.0. Each item records its
 rationale, target state, and relevant scope decisions. The
-[implementation plan](implementation.md) owns the staged work.
+[implementation plan](implementation.md) owns the staged work and verification
+evidence.
 
 The priorities in [ADR 0002](../adr/0002-routine-releases.md) guide this work:
 minimize application-owned release code, duplicated mechanics, and routine
@@ -12,13 +17,13 @@ developer decisions through a standard, minimal API.
 
 ## 1. Establish the shared validation API and profile model
 
-### Rationale and current baseline
+### Rationale and baseline at plan start
 
 The shared validation foundation and its remediation are complete. ReleaseKit
 has common candidate execution, facade-owned diagnostics, committed-file
 inspection, and a product-specific additional-check extension point. The
-optional v0.2.0 capabilities still need their functioning API/profile selections
+optional v0.2.0 capabilities now have functioning API/profile selections and
-and checker implementations.
+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
@@ -32,17 +37,16 @@ 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.
 
-Completion should provide equivalent Go and profile declarations for the
+The implemented API and profile provide equivalent declarations for the
 validation capabilities below through the existing shared foundation.
 
 ## 2. Use the application's module-selected ReleaseKit version in CI
 
-### Rationale and current baseline
+### Rationale and baseline at plan start
 
-The maintained [CI template](../../examples/woodpecker/tag-delivery.yml) selects
+At the v0.1.0 planning baseline, the maintained CI template selected ReleaseKit
-ReleaseKit through a separate `RELEASEKIT_VERSION` value and invokes its command
+through a separate `RELEASEKIT_VERSION` value and invoked its command with an
-with an explicit `@version`. The [adoption guidance](../consumers/delivery.md#woodpecker-tag-workflows)
+explicit `@version`.
-instructs consumers to maintain that workflow pin.
 
 Audita demonstrates the resulting duplication: its local release wrapper builds
 ReleaseKit using the application's module dependencies, while CI independently
@@ -51,6 +55,9 @@ Maintainers must remember to coordinate both declarations.
 
 Using the application's module-selected version for both paths gives upgrades
 one dependency declaration and keeps local publication and CI delivery aligned.
+Stages 12–14 changed the maintained template and Audita's workflow to this
+approach; the current [adoption guidance](../consumers/delivery.md#woodpecker-tag-workflows)
+describes it.
 
 ### Target end state
 
@@ -69,14 +76,15 @@ 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.
 
-Audita adopts the module-based integration as the first consumer migration.
+Audita adopted the module-based integration as the first consumer migration in
+commit `17421bc`.
 
-Completion should leave downstream maintainers with one ReleaseKit dependency
+The maintained template and Audita's first migration now use one ReleaseKit
-update for this integration and a maintained template they can adopt directly.
+module declaration for local and hosted integration.
 
 ## 3. Select one base test invocation, including race testing
 
-### Rationale and current baseline
+### Rationale and baseline at plan start
 
 ReleaseKit always runs its standard offline Go suite before additional product
 checks. ConfigKit selects race-enabled testing for its release validation.
@@ -99,12 +107,13 @@ 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.
 
-Completion should let ConfigKit and PromptKit select a race-enabled suite once
+The API and profile now let ConfigKit and PromptKit select a race-enabled suite
-and remove the corresponding consumer-owned test invocation.
+once and remove the corresponding consumer-owned test invocation when they
+adopt the selection.
 
 ## 4. Offer a separate full vet pass
 
-### Rationale and current baseline
+### Rationale and baseline at plan start
 
 ConfigKit and PromptKit currently run a full `go vet` pass in addition to their
 test suites. ReleaseKit relies on test-time vet unless a consumer supplies an
@@ -121,12 +130,12 @@ 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.
 
-Completion should replace ConfigKit's and PromptKit's separate vet commands and
+The API and profile now support replacing ConfigKit's and PromptKit's separate
-manual test-time vet settings with one declarative choice.
+vet commands and manual test-time vet settings with one declarative choice.
 
 ## 5. Verify package compilation for selected targets
 
-### Rationale and current baseline
+### Rationale and baseline at plan start
 
 ReleaseKit's existing build declaration selects executable artifacts and their
 delivery. ConfigKit is a source-only library that checks package compilation
@@ -148,12 +157,12 @@ 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.
 
-Completion should let ConfigKit declare its two Linux targets and remove its
+The API and profile now let ConfigKit declare its two Linux targets and remove
-release-specific compilation loop.
+its release-specific compilation loop when it adopts the selection.
 
 ## 6. Check an optional expected publication endpoint
 
-### Rationale and current baseline
+### Rationale and baseline at plan start
 
 ReleaseKit resolves and captures the selected remote's push endpoint and
 rechecks it during publication. ConfigKit additionally declares an expected
@@ -173,12 +182,12 @@ 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.
 
-Completion should let consumers declare the intended push destination without
+Consumers can now declare the intended push destination without maintaining
-maintaining their own publication preflight logic.
+their own publication preflight logic.
 
 ## 7. Offer Go formatting validation
 
-### Rationale and current baseline
+### Rationale and baseline at plan start
 
 PromptKit maintains a shell loop that enumerates tracked Go files and checks
 their formatting. ReleaseKit currently leaves this generic mechanism to
@@ -196,12 +205,12 @@ 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.
 
-Completion should let PromptKit remove its local formatting loop and select
+PromptKit can now remove its local formatting loop and select the shared check
-the shared check through its release profile.
+through its release profile when it adopts the capability.
 
 ## 8. Offer offline Markdown-link validation
 
-### Rationale and current baseline
+### Rationale and baseline at plan start
 
 PromptKit's largest generic validation block is a local Markdown-link checker.
 It owns parsing, destination resolution, heading anchors, and diagnostics.
@@ -232,12 +241,12 @@ 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.
 
-Completion should let PromptKit replace its local Markdown checker with a
+PromptKit can now replace its local Markdown checker with a profile selection
-profile selection and rely on shared parsing rules and diagnostics.
+and rely on shared parsing rules and diagnostics when it adopts the capability.
 
 ## 9. Offer module-distribution checks
 
-### Rationale and current baseline
+### Rationale and baseline at plan start
 
 PromptKit checks that released source is independent of neighboring checkouts
 by excluding committed workspace files and local filesystem module replacements.
@@ -260,12 +269,12 @@ 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.
 
-Completion should let PromptKit declare its distribution requirements and
+PromptKit can now declare its distribution requirements and remove the
-remove the corresponding consumer-owned checks.
+corresponding consumer-owned checks when it adopts the selections.
 
 ## 10. Offer an individual-file-size check
 
-### Rationale and current baseline
+### Rationale and baseline at plan start
 
 Unintentionally committed binaries and large assets can increase the size of
 released source. ReleaseKit currently leaves file-size inspection to consumers.
@@ -286,5 +295,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.
 
-Completion should let consumers catch oversized candidate files through a
+Consumers can now catch oversized candidate files through a small declaration
-small declaration and remove any corresponding local inspection code.
+and remove corresponding local inspection code when they adopt the check.