Upgrade ConfigKit, ReleaseKit, and PromptKit

This commit is contained in:
2026-10-11 01:35:09 +00:00
parent 07fab5586b
commit b01180ea83
9 changed files with 58 additions and 40 deletions

View File

@@ -1,8 +1,8 @@
# Library Updates: ConfigKit, ReleaseKit, and PromptKit
**Reviewed:** 2026-10-11.
**Status:** Reviewed and recommended; dependency upgrades and optional feature
adoption are not implemented by this document.
**Status:** Dependency upgrades complete. Optional inspection APIs remain unused
until a concrete application need arises.
## Scope and Reviewed Baseline
@@ -12,7 +12,7 @@ the work needed to adopt them. Audita's baseline is commit
The local library checkouts were clean and matched the released source commits;
the remote annotated tags were checked against their peeled commits.
| Library | Current import | Recommended import | Full reviewed upstream commit |
| Library | Reviewed baseline import | Adopted import | Full reviewed upstream commit |
| --- | --- | --- | --- |
| ConfigKit | v0.5.0 | v0.7.1 | `6fffde4af8f31f99d3ee295c426eb3234cb0fb77` |
| ReleaseKit | v0.3.0 | v0.4.1 | `2d5a8110c61e31daf8698766114ae305d0e0e469` |
@@ -233,13 +233,26 @@ performance gains, or operator-facing optional features. Actual implementation
should validate its final changed candidate and selected CI behavior. Live
delivery remains separate from release completion under the existing policy.
## Open Decisions
## Selected Scope and Completion Record
No decision blocks the basic dependency upgrade. Whether to expose configuration
comparison, definition listings, or requirement diagnostics remains optional.
Recommend upgrading first and designing the chosen operator features separately:
the current API additions are independently useful, and a dependency refresh
need not define a new CLI. A viable alternative is one combined feature effort
that upgrades dependencies and adds selected inspection commands; that can reduce
repeat integration work, but requires decisions about selection syntax, report
scope, disclosure, and command ownership before implementation.
The user selected a simple version upgrade, deferring inspection API exposure
until a concrete need arises. ConfigKit v0.7.1, ReleaseKit v0.4.1, and PromptKit
v0.14.0 are adopted together. The dependency/checksum changes retain Go 1.26.0,
the existing catalogs, and the current application APIs and configuration format.
Attribution and canonical upstream references now identify the selected releases.
CI delivery uses `--prepared`, with the runbook and existing workflow test updated.
Implementation validation on Go 1.26.8 Linux amd64 passed:
- The complete offline `go test -count=1 ./...` suite.
- The actual module-selected ReleaseKit builder for Linux amd64 and arm64, using
the disposable build identifier `v0.0.0`; its native injected-version check
passed and produced `audita v0.0.0`.
- Local, inheritance, service, and service-testing-overlay configuration examples,
using a synthetic service credential.
- Selected source revisions, unchanged upstream grants/license texts, and updated
upstream file-link destinations.
Build artifacts remained outside the repository. No source tag, hosted delivery,
or inference call was performed. Live CI delivery remains unobserved and separate
from this completed upgrade and source-release completion.