Document sequence composition for consumers
This commit is contained in:
@@ -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.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user