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

Document shared source version checks

Browse Source
This commit is contained in:
Eric Rakestraw
2026-10-15 16:23:39 +00:00
parent 358b28c421
commit 020d72084d
12 changed files with 165 additions and 38 deletions
Download Patch File Download Diff File Expand all files Collapse all files

34
docs/roadmap/promptkit-feature-request.md
View File

@@ -284,6 +284,12 @@ new limit values or their accounting machinery.
## Partially Accepted Addition: Shared Source Specification Checks
Status: the shared-policy portion below is implemented. Current behavior is
defined by the [configuration contract](../config.md#shared-source-version-checks),
and the accepted decision and implementation evidence are in
[ADR 0013](../adr/0013-shared-source-version-checks.md) and the
[source-version roadmap](source-version-checks.md).
### Accepted Scope
A ConfigKit consumer defines one configuration specification, which may evolve
@@ -322,16 +328,19 @@ separate from `Definition.Version`, with ordinary imports exempt from independen
checks. It also recommended consuming accepted entry headers and exposing them
as source evidence while leaving imported release metadata untouched.
That full set of semantics has not been accepted. The accepted direction uses
one shared `Definition.Version` policy and optional or required declarations
across participating sources. Separately versioned subsets or collections are
outside this addition's scope and may be considered independently in the future.
Header consumption and inspection from the original proposal remain design
suggestions, not accepted requirements.
The independent collection-entry policies and exemption for ordinary imports
were not accepted. The accepted direction instead uses one shared
`Definition.Version` policy and optional or required declarations across
participating sources. Separately versioned subsets or collections remain
outside this addition's scope. Header consumption and sanitized source evidence,
which were suggestions in the original proposal, were subsequently accepted for
this shared-policy design and are implemented as described by the linked
contract.
### Remaining Design Work
### Design Questions Resolved by the Accepted Roadmap
The following details remain to be resolved before implementation:
The following questions were open in the original request and are resolved by
the accepted roadmap and ADR 0013:
- How the configured declaration path is interpreted for individual sources,
particularly before destination placement.
@@ -345,10 +354,11 @@ The following details remain to be resolved before implementation:
existing string/decimal-integer version vocabulary.
- The opt-in API, callback lifecycle, and source-local diagnostic attribution.
In particular, the original example of an imported `version: "2.4.0"` release
label is not guaranteed to remain outside checking in an enabled mode. That
depends on the chosen header lookup semantics. No automatic field consumption,
new coercion, or per-collection checker should be inferred from partial acceptance.
In particular, an imported `version: "2.4.0"` at the configured source-local
header path is checked and consumed in an enabled mode. Consumers that need an
ordinary release label retain it at a different path. No automatic field
consumption applies in the default mode, and no new coercion or per-collection
checker is part of the implemented design.
## Requested Addition: Relative Import Destinations