Document sequence composition for consumers

This commit is contained in:
2026-10-16 19:37:59 +00:00
parent 77c5d9482a
commit acddce8e2f
18 changed files with 300 additions and 39 deletions

View File

@@ -15,11 +15,12 @@ PromptKit repository at
PromptKit selected mounted mappings instead; this feature is not a dependency
of that design or a request to restore multiple installed prompt versions.
A narrower [sequence placement and composition roadmap](sequence-composition.md)
now covers placing source mappings as sequence items, single-field identities,
duplicate rejection during strict composition, and whole-sequence replacement
between precedence layers. The additional capabilities below remain deferred
and are not requirements of that roadmap.
A narrower [sequence placement and composition feature](../config.md#strict-document-composition)
is implemented: consumers can place imported mappings as sequence items and
register a single literal string identity field for duplicate-rejecting strict
composition. Precedence still replaces sequences as whole values. This entry
tracks broader identified-record behavior that remains deferred and is not part
of that implemented contract.
### Motivation and proposed behavior
@@ -27,13 +28,16 @@ Allow applications to declare that selected sequences contain records identified
by explicit fields, while retaining sequence-shaped output for slice decoding
and effective YAML. This could make composite identities and independently
authored catalogs more convenient than encoding identity in nested mapping keys.
Current [composition](../config.md#strict-document-composition) and
[overlay](../config.md#selected-overlays) treat sequences atomically.
Current [composition](../config.md#strict-document-composition) appends distinct
records only at explicitly registered paths; other sequences remain atomic.
Selected [overlays](../config.md#selected-overlays) always treat sequences
atomically.
The proposed opt-in registration belongs in the reusable application definition:
an exact effective sequence path after input/import placement, plus an ordered,
nonempty set of distinct direct string-field names. For example, records at
`profiles` could be identified by `(namespace, id)`. Records `(provider, brief)`
The proposed broader opt-in registration would extend the current reusable
application definition from one identity field to a composite identity made of
an ordered, nonempty set of distinct direct string-field names. For example,
records at `profiles` could be identified by `(namespace, id)`. Records
`(provider, brief)`
and `(application, brief)` would coexist, and a later layer could update the
provider record's temperature while retaining its backend and model.