Reconcile sequence identity documentation
This commit is contained in:
@@ -21,7 +21,7 @@ sanitized shapes using only ConfigKit and the Go standard library:
|
||||
| Named presets | One-load sibling inheritance, explicit false, nested destination resolution, and source/derivation inspection | Choosing and executing a preset |
|
||||
| Effective configuration diff | Same-type frozen effective comparisons for two selected files or base-versus-overlay impact | Source/options selection and consumer-owned safe presentation |
|
||||
| Shared source-version checks | One `Definition.Version` policy for accepted declarations across participating source documents, with optional or required declarations and sanitized evidence | Choosing which declarations the application accepts; final assembled schema and domain validation |
|
||||
| Identified prompt sequences | Explicit item path/glob imports, helper-supplied IDs, reusable single-field registration, same-sequence record inheritance, and main-tier replacement of a lower-priority collection | Prompt meaning and final domain validation |
|
||||
| Sequence catalogs | Declared collection operations, record inheritance, typed CLI and resolution, inspection, exact and wildcard application registrations | Catalog meaning and final domain validation |
|
||||
|
||||
The YAML under [`testdata`](../../examples/consumers/testdata) is loaded by the
|
||||
executable examples and ordinary tests. It contains no private application data,
|
||||
@@ -184,43 +184,35 @@ import, source-location, and ownership behavior.
|
||||
|
||||
## Identified prompt sequences
|
||||
|
||||
[`LoadPromptCatalog`](../../examples/consumers/prompt_catalog.go) uses one
|
||||
definition registration for the literal `prompts` path and `id` field. Its
|
||||
load-wide filename defaults accept two patterns, an explicit directory
|
||||
declaration overrides those patterns, and an exclusion omits one matching
|
||||
candidate. A nested ordinary helper import supplies an item's ID. A separate
|
||||
empty optional directory search is read from `SourceInfo.ImportSelections`.
|
||||
The executable example prints both the scheduled prompt order and the single
|
||||
empty-search outcome; the behavior test also follows a mounted resource through
|
||||
its effective metadata origin to the declaring source context. The completed
|
||||
main sequence replaces the lower-priority default collection as one value.
|
||||
The maintained [executable example and behavior tests](../../examples/consumers/prompt_catalog_test.go)
|
||||
show the scheduled result, empty-search inspection, excluded candidate, and
|
||||
resource lookup without a consumer-side discovery pass. The corresponding
|
||||
[complex fixture](../../examples/consumers/testdata/prompt-catalog/config.yml)
|
||||
and [simple required-file fixture](../../examples/consumers/testdata/prompt-catalog/simple.yml)
|
||||
are complete local examples.
|
||||
[`LoadPromptCatalog`](../../examples/consumers/prompt_catalog.go) shows the
|
||||
smaller import-focused adoption path: a registered `prompts.id` identity,
|
||||
directory and glob selection, a helper import that supplies an item's ID, and
|
||||
resource lookup through the effective source context. Its executable examples
|
||||
and tests are in
|
||||
[`prompt_catalog_test.go`](../../examples/consumers/prompt_catalog_test.go), with
|
||||
complete [catalog](../../examples/consumers/testdata/prompt-catalog/config.yml)
|
||||
and [required-file](../../examples/consumers/testdata/prompt-catalog/simple.yml)
|
||||
fixtures.
|
||||
|
||||
[`LoadRequiredPromptCatalog`](../../examples/consumers/prompt_catalog.go) and
|
||||
[`Example_requiredPromptCatalog`](../../examples/consumers/prompt_catalog_test.go)
|
||||
keep the smaller adoption path visible: one explicitly required file import,
|
||||
the same identity registration, and the same application validation.
|
||||
[`LoadSequenceCatalog`](../../examples/consumers/sequence_catalog.go) integrates
|
||||
an underlay declaration, imported main fragments, identified-record inheritance,
|
||||
selected overlay `append`, `upsert`, and `replace`, a typed CLI override, and
|
||||
recorded application resolution. Its tests and runnable example demonstrate
|
||||
stable output order, whole-record upsert, provenance/history inspection,
|
||||
resource lookup for inherited records, and secret-safe explanation in
|
||||
[`sequence_catalog_test.go`](../../examples/consumers/sequence_catalog_test.go).
|
||||
[`LoadNamespacedMapCatalog`](../../examples/consumers/sequence_catalog.go) adds
|
||||
an exact root registration and a wildcard namespace registration, showing that
|
||||
each concrete sequence has an independent identity scope. The same tests show
|
||||
that a YAML identity declaration without an application registration does not
|
||||
create final-result identity enforcement.
|
||||
|
||||
The registered `id` also identifies surviving prompt records that use
|
||||
`extends: {id: "base-id"}`. ConfigKit resolves these references within the
|
||||
completed prompt sequence after tier assembly, preserves the child's own ID, and
|
||||
records inherited values at the child's paths. The
|
||||
[configuration contract](../config.md#sibling-inheritance) defines the exact
|
||||
reference and nested collection behavior.
|
||||
|
||||
The example's `validatePromptCatalog` remains application-owned. It checks that
|
||||
prompt names and message lists satisfy this consumer's requirements after
|
||||
ConfigKit has composed, inherited, projected, and decoded the configuration.
|
||||
ConfigKit does not apply identity-based overlays or enforce final uniqueness
|
||||
after defaults and resolution. See the [strict composition contract](../config.md#strict-document-composition),
|
||||
[import syntax](../config.md#explicit-imports), and
|
||||
[ADR 0014](../adr/0014-sequence-placement-and-composition.md) for the exact
|
||||
boundaries.
|
||||
The examples keep prompt meaning and domain checks in the consuming application.
|
||||
The [configuration contract](../config.md#strict-document-composition) owns
|
||||
declaration, identity, operation, ownership, and final-validation semantics;
|
||||
[sibling inheritance](../config.md#sibling-inheritance) defines record
|
||||
relationships, and the [CLI contract](../config.md#explicit-cli-overrides) owns
|
||||
override ordering.
|
||||
|
||||
Known module catalogs should use canonical object entries with a module identifier
|
||||
and typed options. A small union struct is sufficient when the available option
|
||||
|
||||
Reference in New Issue
Block a user