Resolve glossary paths at the ConfigKit application handoff

This commit is contained in:
2026-11-08 17:09:52 +00:00
parent 167d91131e
commit af6f62e14b
2 changed files with 37 additions and 17 deletions

View File

@@ -126,8 +126,10 @@ file remain terminal.
together with its [CLI precedence and native-support boundary](glossary-stages.md#cli-overrides-and-stage-precedence--resolved).
Use its [separate glossary and protection selections](glossary-stages.md#glossary-selection-and-protected-vocabulary--resolved),
including root protection defaulting through recorded application resolution.
Apply its [post-handoff application-resource path policy](glossary-stages.md#relative-paths-and-source-context--resolved)
while leaving upstream configuration resolution to ConfigKit.
Complete its required durable decision record. The glossary roadmap owns
the remaining path, list-input, combined-entry, and attribution decisions. This
the remaining list-input, combined-entry, and attribution decisions. This
application scope model does not change native source composition or
sibling-inheritance semantics.

View File

@@ -262,6 +262,34 @@ The open stage-identity decision concerns reporting and diagnostics; stage IDs
do not imply CLI targeting. Audita's domain-specific inheritance and fallback
rules remain within ConfigKit's supported application-resolution lifecycle.
### Relative Paths and Source Context — Resolved
ConfigKit owns configuration resolution upstream of its handoff to Audita,
including discovery, configuration source paths, imports, overlays, composition,
inheritance, and source resource contexts. Use its native behavior and public
handoff; do not reinterpret configuration paths, reload source documents, or
reconstruct its resolution rules in Audita.
The following policy applies to glossary and protection files consumed as
application data after that handoff:
- Resolve a relative file path supplied by configuration against the supplying
document's source resource context.
- Resolve a relative CLI file path against the invocation's working directory,
including when no main configuration file was found.
- Preserve each input path's source context through root-to-stage inheritance
and root protection defaulting. Deriving a protection list does not give its
paths a new filesystem base.
Use ConfigKit's public origin metadata and `Result.SourceContext` to obtain the
owning filesystem and base directory, following its
[source resource contract](https://forge.maximumdirect.net/base-layer/configkit/src/commit/191015e289d7f2b91abb9fdd9c4f2f5cf75b4de9/docs/config.md#source-resource-contexts).
Retain source attribution through Audita's recorded derivations so each file's
original context can be identified. Honor upstream filesystem and context
semantics; do not invent a host-file base for a contextless synthetic source.
This keeps imported configuration reusable while leaving configuration loading
and resolution under ConfigKit's ownership.
### ConfigKit Support
Use the selected ConfigKit v1.1.0 public lifecycle for this work. Its
@@ -331,8 +359,8 @@ requirement visible during library design without expanding those migrations
into feature implementation.
1. Apply the selected scope, glossary/protection selection, compound-value,
clearing, CLI precedence, and validation-profile fallback rules. Finalize path
resolution and remaining list-input details. Incorporate
clearing, CLI precedence, application-resource path resolution, and
validation-profile fallback rules. Finalize remaining list-input details. Incorporate
these into the version-3 schema rather than retain the old module-name list.
2. Resolve effective stage settings and carry them through stage execution,
proposal generation, and validation. Load correction/context and protection
@@ -364,6 +392,10 @@ lists, independent empty-list clearing, a glossary stage with no override using
both inputs, and a file selected only on a stage not entering root protection.
Verify that modules and validators receive their respective effective selections
and recorded source origins. Cover repeated modules and an empty stage list.
Exercise relative glossary and protection inputs from main and imported
configuration sources and from CLI assignments, including no-main-file operation.
Verify that inherited and derived protection inputs retain their original source
context while Audita leaves ConfigKit's configuration resolution unchanged.
Exercise the selected request and validation overrides through stage consumers,
including independent budgets without changing shared backend admission or the
@@ -396,20 +428,6 @@ guidance are in place before declaring this feature complete.
The recommendations below are proposals, not selected contracts.
### Relative Paths and Source Context
**Recommendation:** use ConfigKit's supported source context to resolve a
configuration path relative to the document supplying that value, and resolve
CLI paths relative to the working directory. Each inherited glossary or protection
path retains its source context, including protection derived from root glossary
paths. This supports reusable imported configuration; verify the native
facilities before selecting implementation.
**Alternative:** resolve all relative glossary paths from the working directory.
This has one simple base and suits invocation-local inputs, but makes reusable
configuration dependent on where Audita is launched. Decide the base explicitly
for no-main-file operation as well.
### Combined Entries and Protected Identities
**Recommendation:** preserve declared file and entry order, coalesce identical