ConfigKit/docs/internal/overview.md

Internal Component Overview

ConfigKit exposes one supported root configkit package. The root owns public named types, declaration comments, constructors, and explicit conversion/wrapper code. It delegates loading and frozen inspection to internal/engine through private state; public signatures and fields do not expose engine types.

Implemented component owners:

• internal/engine owns host and native-filesystem source acquisition and explicitly selected configuration discovery. A search resolves once during shared acquisition; the selected concrete file or absent-input state then follows the existing composition, metadata, and resource-context lifecycle. It also owns grouped strict composition, recursive precedence assembly, per-input mapping and sequence-item placement, YAML collection declarations and operations for identified sequences, and application identity registrations for strict composition, inheritance, and final validation. It applies the selected collection operation at precedence boundaries and owns dependency-ready, destination-local inheritance before typed decoding. CLI assignment follows inheritance and decoding, before application resolution. The engine also owns shared source-version checking with sanitized declaration evidence. Explicit import discovery supports declared paths, directory searches, and globs; root-owned defaults are converted to the engine's single defaults input and snapshotted during load preflight before acquisition, while source-local empty-selection evidence crosses the facade without changing acquisition order. The root constructs placement directly on engine options and inputs using explicit enum conversion; public types and fields remain root-owned. Import and inheritance resolution share dependency-ready scheduling within their composition scopes. It retains each source's effective placement alongside physical source identity and owns schema inspection, lifecycle coordination, callback auditing, provenance/history, passive source-context retention, secret resolution and bootstrap, operation-local secret failure-location attribution, safe inspection rendering, and effective-value comparison over frozen inspection snapshots. It never imports the root package.
• Root Source, Filesystem, Input, Underlay, Path, Secret, records, lifecycle callbacks, results, and bootstrap reports are root-defined wrappers or records. Callback wrappers pass only live engine context during a callback; Result.Config is detached and its private inspection remains frozen independently.
• Root conversion files explicitly cross the path, record, callback, secret, search-description, and error boundaries. There are no public aliases, anonymous engine embeddings, or public engine bridge methods.
• Root Diff and Difference provide the public comparison boundary and convert detached engine records to root-owned paths and snapshots; consumer examples own presentation of the safe changed regions.
• internal/document owns the parser-independent ordered tree and cloning. internal/yaml is the sole upstream YAML adapter and parser/dumper boundary.
• Engine mechanism tests own source, composition, inheritance, decoding, callback, provenance, source-context, secret, history, rendering, and bootstrap behavior. Root tests own public API compatibility, facade integration, documentation links, and dependency/public boundary checks. Consumer examples remain under examples/consumers.

Dependency direction is root to engine to document/YAML support. The root may import only internal/engine among project internal production packages; engine and its supporting packages do not import root. The root boundary test enforces these constraints and rejects exported aliases, fields, or signatures involving internal types.

The configuration contract owns implemented YAML and lifecycle semantics, including configuration discovery, input destinations, shared source-version checks, and effective configuration diffs. The strict composition contract owns sequence declarations, identity, operations, ownership, and final validation; CLI overrides own override ordering. The consumer guide links maintained workflow examples. The consumer adoption guide owns application guidance. The architecture policy owns contributor boundaries; ADR 0006 records the facade decision and ADR 0010 records the diff decision; ADR 0011 records the placement decision. See the development guide for validation commands and release procedure for source-candidate gates. ADR 0009 records why inheritance is a built-in post-assembly structural operation. ADR 0012 records the relative-import extension; ADR 0013 records the source-version decision. ADR 0014 records explicit sequence placement and composition. ADR 0015 records the shared dependency-ready ordering decision; ADR 0016 records the independent selection controls. ADR 0017 and ADR 0018 record collection operations and CLI ordering. ADR 0019 records explicit main-file discovery. The import internals document candidate and namespace identities, discovery and scheduling, and the bounded algorithms.

Implementation flow

The root facade converts caller-owned values into engine-owned requests. Its ImportDefaults conversion maps fields without taking ownership; engine load preflight snapshots the defaults once before source acquisition or callbacks. Ordinary and grouped loading then carry that read-only value through their normalized loadRequest and acquisition policy, while declaration resolution copies values needed by its independently owned effective policy. Placement is constructed directly on the engine's options and input records after explicit root-to-engine enum conversion. See lifecycle.go, layered.go, and load_request.go. Load-wide definition, version, default-import, and override policy stays distinct from each input's source, filesystem, destination, and import settings.

acquisition.go defines acquisition policy, load-wide accounting, and tier-scoped repetition/namespace state. Each input is acquired under that policy; grouped requests retain acquired underlay scopes until their tier is composed in load_request.go. Completed tiers then share one assembly handoff that applies collection declarations and projects only that tier's source/version evidence; the caller keeps main-version protection and its projection explicit. Live filesystem access handles are confined to acquisition and closed there. Resolved filesystem facts used to authorize access are separate from passively retained resource contexts. Non-import validation retains those facts on assembledInput for passive-context construction and ordinary-overlay handling: see filesystem_context.go and source_context.go.

Import responsibilities are split across candidate selection and path normalization in import_selection.go, source reading and traversal admission in import_acquisition.go, directory walking in directory_walk.go, dependency graph scheduling in import_graph.go, and projection of acquired evidence into final source coordinates in import_projection.go. The import internals page describes the boundaries and identities.

After acquisition handles are closed, grouped composition and inheritance run on the retained ordered documents. inheritance.go coordinates traversal and inheritance_schedule.go applies dependency-ready templates; inheritance_prepare.go prepares child and parent inputs, inheritance_combine.go returns the combined value with its origin, policy, sequence, and diagnostic evidence, and inheritance_finalize.go accounts for and finalizes the result. Projection and schema work have separate operation owners: value_operation.go holds per-operation state, projection.go builds projected values, schema.go owns descriptor caching and type policy, and schema_fields.go owns ordinary and inline field assembly. decode.go consumes those descriptors for typed decoding.

Behavioral ownership follows the same handoffs: imports and grouped lifetimes are covered by imports_test.go, load_request_test.go, and focused source, discovery, and destination tests; inheritance by the inheritance test files; reflection behavior by schema_test.go, projection_test.go, and decode_test.go. The development test map links focused commands. clone.go owns typed copying, using the shared descriptors and per-operation traversal helpers.