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

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.