Clarify future message normalization opportunities
This commit is contained in:
@@ -49,10 +49,14 @@ field-level change history while preserving the origins needed to resolve
|
|||||||
relative resources such as `content_file`. Assess whether that inspection
|
relative resources such as `content_file`. Assess whether that inspection
|
||||||
benefit justifies changing the execution-owned normalization approach.
|
benefit justifies changing the execution-owned normalization approach.
|
||||||
|
|
||||||
Include message-role and cache-control normalization in this reevaluation.
|
Include normalization of roles and cache-control values in configured messages
|
||||||
Upstream support would need to preserve untouched field origins within nested
|
in this reevaluation. This could make inspection reflect the values used for
|
||||||
message lists as well as outer resource lists. PromptKit would continue owning
|
execution and reduce separate normalization paths. Upstream support would need
|
||||||
the normalization rules; ConfigKit would record their effects and provenance.
|
to preserve untouched field origins within nested message lists as well as outer
|
||||||
|
resource lists. PromptKit would continue owning the normalization rules;
|
||||||
|
ConfigKit would record their effects and provenance. Caller-appended messages
|
||||||
|
would still need request-time normalization because they do not pass through
|
||||||
|
ConfigKit.
|
||||||
Consider moving these transformations only if it improves inspection consistency
|
Consider moving these transformations only if it improves inspection consistency
|
||||||
and simplifies implementation without changing execution behavior.
|
and simplifies implementation without changing execution behavior.
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user