4.2 KiB
ConfigKit v1.1.0
ConfigKit now accepts field-level resolution records inside lists and follows registered records across position changes when reporting their provenance and history. This release also standardizes more release validation on ReleaseKit.
Field-level resolution in lists
Applications can normalize or derive a field inside a list and record that
field directly. For example, changing /resources/0/path can be covered by
RecordNormalization at that path, without recording the entire /resources
list when no other changes require coverage.
For ordinary lists of equal length, resolution auditing compares corresponding positions recursively. Positions are addresses; ConfigKit does not infer an element's identity from similar values. A length change still requires a record for the list or an ancestor.
For collections registered through Definition.SequenceIdentities, ConfigKit
matches records between the resolution-entry and final snapshots when both
endpoints have valid, unique identities. Field edits can be recorded individually.
Changes to identity order or membership still require list or ancestor coverage;
changing an identity is treated as removal and addition. When matching is
unavailable, a changed registered collection is audited as a whole. Existing
final identity validation remains in place, allowing resolution to repair entry
values.
See recorded application resolution for the complete rules.
Matched history and inspection
For eligible registered collections, inspection at a surviving record's final position follows its own entry evidence, including earlier values, input explicitness, and source attribution. A record no longer inherits the evidence of a different record that previously occupied its final position. Original source coordinates remain intact, while reported operation paths follow the matched final record.
Collection inspection retains removed records' evidence. Removed fields of surviving moved records remain available through metadata history and explanation, including deep inherited fields. Sensitivity propagation protects matched and removed evidence and recorded dependencies; detached before/after snapshots remain conservatively masked.
Correspondence lookup, sensitivity propagation, and resolution-change ordering reuse indexes, a work queue, and prepared pointer strings to avoid repeated prefix construction, full-map passes, and formatting during sorting. No end-to-end performance improvement is claimed.
Compatibility
This is a backward-compatible extension of resolution auditing and inspection.
Existing callbacks that record a whole list remain supported. Records and helper
targets for surviving values refer to final positions; helpers do not follow
later moves automatically. Resolution.EntryInfo and Resolution.IsExplicit
retain their fixed entry-snapshot meaning.
Public effective-configuration diffs continue to report list changes atomically. Source composition, collection merge operations, configuration syntax, and public path addressing are unchanged. No new public Go symbols are required.
The consumer minimum remains Go 1.27.0, and the YAML dependency is unchanged. Linux amd64 and arm64 remain release-validated; macOS remains best-effort.
Release tooling
ReleaseKit advances from v0.6.0 to v0.8.0. The runbook uses the module-selected
go tool releasekit command and documents saved publication attempts and
reconciliation after failed or uncertain tag pushes.
ReleaseKit now checks committed Markdown links and rejects filesystem dependency replacements during candidate validation. The custom documentation-link Go test is removed, so automated link feedback occurs during candidate validation rather than ordinary Go tests. Source publication and hosted Gitea delivery remain separate outcomes; CI remains outside release gates. See the release procedure.