Finalize ConfigKit architecture documentation
This commit is contained in:
@@ -5,9 +5,9 @@
|
||||
|
||||
## Context
|
||||
|
||||
Notarius's configuration boundary currently owns strict YAML parsing, input
|
||||
Notarius's former configuration boundary owned strict YAML parsing, input
|
||||
presence bookkeeping, defaults, normalization, environment overlays, and
|
||||
configuration inspection. Those general-purpose responsibilities have grown
|
||||
configuration inspection. Those general-purpose responsibilities had grown
|
||||
alongside application-specific pipeline and module semantics.
|
||||
|
||||
ConfigKit v0.3.0 provides strict typed YAML loading, imports, configuration
|
||||
@@ -47,8 +47,7 @@ boundary.
|
||||
|
||||
## Consequences
|
||||
|
||||
The implementation migrates configuration behavior in bounded increments, but
|
||||
the released application will have one ConfigKit-backed loader and one version
|
||||
5 contract. Operator documentation and maintained examples must move with the
|
||||
cutover. ConfigKit metadata is retained only at the configuration publication
|
||||
boundary; its types do not become module or runtime pipeline interfaces.
|
||||
The released application has one ConfigKit-backed loader and one version 5
|
||||
contract. Operator documentation and maintained examples move with the cutover.
|
||||
ConfigKit metadata is retained only at the configuration publication boundary;
|
||||
its types do not become module or runtime pipeline interfaces.
|
||||
|
||||
Reference in New Issue
Block a user