From edd670e62fc1146b50c71659beb5d38f9423139d Mon Sep 17 00:00:00 2001 From: Eric Rakestraw Date: Wed, 7 Oct 2026 23:52:55 +0000 Subject: [PATCH] Complete the v0.2.0 implementation audit --- README.md | 3 +- docs/internal/overview.md | 7 +-- docs/roadmap/implementation.md | 34 +++++++++----- docs/roadmap/model.md | 66 +++++++++++++------------- docs/roadmap/releasekit.md | 22 +++++---- docs/roadmap/v0.2.0.md | 85 +++++++++++++++++++--------------- 6 files changed, 121 insertions(+), 96 deletions(-) diff --git a/README.md b/README.md index 8f1d2d3..9fb44ae 100644 --- a/README.md +++ b/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 diff --git a/docs/internal/overview.md b/docs/internal/overview.md index 1cec3bc..020a47b 100644 --- a/docs/internal/overview.md +++ b/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 -adoption work. +broader migrations beyond Audita and measurement of realized savings remain +future adoption work. diff --git a/docs/roadmap/implementation.md b/docs/roadmap/implementation.md index f2a1ac9..471e60e 100644 --- a/docs/roadmap/implementation.md +++ b/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) -are complete. `Check` and `Publish` share candidate-request conversion and validation. +At baseline commit `3974a46`, the foundation and all six +[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 -incrementally with each capability; remaining selections are not yet -implemented. The consumer CI template still selects an independent tool -version. This sequence completes every remaining release-roadmap capability and -Audita's CI migration. -It ends with local verification and committed changes. Architecture review, -hosted deployment, release tagging, and decisions about further testing follow -this implementation. +The stages in this plan complete the remaining v0.2.0 validation selections, +module-selected CI bootstrap, and Audita migration. Audita's migration is +recorded in commit `17421bc`. The final local audit covers the full Go suite, +compiled API/dependency boundaries, maintained examples, documentation, and +dependency notices. Architecture review, 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, diff --git a/docs/roadmap/model.md b/docs/roadmap/model.md index 47ff424..7621c41 100644 --- a/docs/roadmap/model.md +++ b/docs/roadmap/model.md @@ -1,7 +1,8 @@ # Validation API and profile model -Status: Shared validation foundation, Go race selection, and separate full vet -implemented; remaining v0.2.0 capabilities and their settings are future work. +Status: Complete for the agreed v0.2.0 shared validation model. Every selection +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 -full vet pass. Package compilation, formatting, Markdown, module-distribution, -and file-size checks will use the same model as their capabilities are added. +request and profile have structured selections for race testing, separate full +vet, package compilation, formatting, Markdown, module distribution, and file +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 -`validation` object in the release profile. Use typed Go fields and ordinary -JSON settings to express the same supported selections. Group related choices, -including base-test and vet settings, so their relationship is clear. +The facade-owned `ValidationSpec` on `ReleaseRequest` has a corresponding +`validation` object in the release profile. Typed Go fields and ordinary JSON +settings express the same supported selections. Related choices, including +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 -and current rollout. The facade exposes `ReleaseRequest.Validation.Go.Race` and -`FullVet`, and profiles accept `validation.go.race` and -`validation.go.full_vet`. Race selection adds `-race` to the one base Go suite. -Full-vet selection disables test-time vet and runs native -`go vet -mod=readonly ./...` after successful tests. Each remaining setting -will be introduced with its first working capability. Individual checkers, -module-selected CI tooling, and the publication endpoint expectation remain -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. +The [implementation plan](implementation.md) records the completed rollout and +verification. The facade and CLI profile expose equivalent selections for the +single test suite, separate full vet, package compilation, formatting, Markdown, +module distribution, file size, and the expected publication endpoint. Shared +execution, ordering, diagnostics, cancellation, and failure stopping are +implemented by the owners described above. The maintained Woodpecker template +and Audita's local wrapper use the module-selected ReleaseKit version; see the +[v0.2.0 roadmap](v0.2.0.md) and [delivery guide](../consumers/delivery.md). ## Adoption evidence -Evaluate the design against all three known consumer shapes: Audita's default -validation and executable builds; ConfigKit's selected test, vet, and library -compilation checks; and PromptKit's shared validation plus substantive example -assertions. +Self-contained integration fixtures evaluate all three known consumer shapes: +Audita's default validation and executable builds; ConfigKit's selected test, +vet, and library compilation checks; and PromptKit's shared validation plus +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 -release operation. The model should support the agreed v0.2.0 capabilities with -shared execution and clear diagnostics while keeping product-specific work in -the existing extension point. +The model gives each adopting consumer a small declaration and the same routine +release operation. Shared execution and diagnostics cover the agreed v0.2.0 +capabilities while product-specific work remains in the existing extension +point. diff --git a/docs/roadmap/releasekit.md b/docs/roadmap/releasekit.md index a39eeef..a6517f9 100644 --- a/docs/roadmap/releasekit.md +++ b/docs/roadmap/releasekit.md @@ -1,7 +1,8 @@ # ReleaseKit: shared release process -Status: Initial implementation, policy adoption, and architecture remediation -are complete. Consumer adoption and live CI integration work remain. +Status: The v0.2.0 implementation, policy adoption, and architecture +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 -preserved in Git history. +The initial foundation, policy adoption, and remediation plans are preserved +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 ` 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 - under the [maintainer procedure](../release.md). +- Use the [v0.1.0 baseline](../releases/v0.1.0.md) for initial consumer + 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 - version as part of deployment. + as part of deployment. The tagged consumer's module configuration selects + 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 diff --git a/docs/roadmap/v0.2.0.md b/docs/roadmap/v0.2.0.md index 284a0a8..953b726 100644 --- a/docs/roadmap/v0.2.0.md +++ b/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 -and checker implementations. +optional v0.2.0 capabilities now have 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 @@ -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 -ReleaseKit through a separate `RELEASEKIT_VERSION` value and invokes its command -with an explicit `@version`. The [adoption guidance](../consumers/delivery.md#woodpecker-tag-workflows) -instructs consumers to maintain that workflow pin. +At the v0.1.0 planning baseline, the maintained CI template selected ReleaseKit +through a separate `RELEASEKIT_VERSION` value and invoked its command with an +explicit `@version`. 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 -update for this integration and a maintained template they can adopt directly. +The maintained template and Audita's first migration now use one ReleaseKit +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 -and remove the corresponding consumer-owned test invocation. +The API and profile now let ConfigKit and PromptKit select a race-enabled suite +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 -manual test-time vet settings with one declarative choice. +The API and profile now support replacing ConfigKit's and PromptKit's separate +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 -release-specific compilation loop. +The API and profile now let ConfigKit declare its two Linux targets and remove +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 -maintaining their own publication preflight logic. +Consumers can now declare the intended push destination without maintaining +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 -the shared check through its release profile. +PromptKit can now remove its local formatting loop and select the shared check +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 -profile selection and rely on shared parsing rules and diagnostics. +PromptKit can now replace its local Markdown checker with a profile selection +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 -remove the corresponding consumer-owned checks. +PromptKit can now declare its distribution requirements and remove the +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 -small declaration and remove any corresponding local inspection code. +Consumers can now catch oversized candidate files through a small declaration +and remove corresponding local inspection code when they adopt the check.