eric/ReleaseKit
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 1 Wiki Activity

Complete the v0.2.0 implementation audit

Browse Source
This commit is contained in:
Eric Rakestraw
2026-10-07 23:52:55 +00:00
parent c8fa8ef85f
commit edd670e62f
6 changed files with 121 additions and 96 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
README.md
View File

@@ -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

7
docs/internal/overview.md
View File

@@ -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.

34
docs/roadmap/implementation.md
View File

@@ -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,

66
docs/roadmap/model.md
View File

@@ -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.

22
docs/roadmap/releasekit.md
View File

@@ -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 <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
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

85
docs/roadmap/v0.2.0.md
View File

@@ -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.