51 lines
2.4 KiB
Markdown
51 lines
2.4 KiB
Markdown
# Source origins during resolution
|
|
|
|
Status: implemented (2026-09-12); release preparation remains separate.
|
|
|
|
ConfigKit now exposes fixed entry-state provenance during an active
|
|
`Definition.Resolve` callback:
|
|
|
|
```go
|
|
func (r *Resolution) InputInfo(path Path) (FieldInfo, bool)
|
|
func (r *Resolution) Source(id string) (SourceInfo, bool)
|
|
```
|
|
|
|
These methods support application-owned normalization and other domain decisions
|
|
before ConfigKit publishes its frozen result. They are additive: existing loading,
|
|
composition, decoding, resolution recording, credential timing, and inspection
|
|
semantics remain unchanged.
|
|
|
|
## Canonical behavior
|
|
|
|
Go reference comments on `Resolution` own the API/lifetime definition. The
|
|
[configuration contract](../config.md#recorded-application-resolution) owns entry
|
|
state, exact path matching, source records, misses, detachment, and callback-scope
|
|
behavior. The [consumer adoption guide](../consumers/README.md#source-aware-application-path-policy)
|
|
and maintained [`NotariusPathConfig` example](../../examples/consumers/consumers.go)
|
|
own the application workflow, including its canonical symlink-base choice.
|
|
|
|
`InputInfo` describes decoded configuration at callback entry, including retained
|
|
defaults and explicit nulls, and is unaffected by subsequent application changes.
|
|
`Source` resolves records already acquired for that load without filesystem,
|
|
credential, or parsing work. Both return detached records and require the existing
|
|
active callback context.
|
|
|
|
ConfigKit continues to provide provenance rather than filesystem policy. Consumers
|
|
choose how to interpret relative paths, select default and CLI bases, and handle
|
|
missing or composite file provenance. The maintained example leaves values unchanged
|
|
with a warning when its chosen base is unavailable; it performs no existence or
|
|
confinement check.
|
|
|
|
## Evidence and handoff
|
|
|
|
The completed staged record in [implementation.md](implementation.md) maps all
|
|
twelve acceptance criteria to focused lifecycle, provenance, ownership, consumer,
|
|
explanation, and secret tests. The final implementation commit is expected to run
|
|
the source checker and the documented two-toolchain gate before any release
|
|
candidate is selected.
|
|
|
|
Publication remains a maintainer decision. Release preparation must choose the
|
|
version, write a version-matched note, retire this completed roadmap with link
|
|
repair, obtain exact-candidate Linux/macOS evidence, and follow the
|
|
[release procedure](../release.md).
|