From f20020d9f40a32571ab46c3c3ee6d94a2b9c8128 Mon Sep 17 00:00:00 2001 From: Eric Rakestraw Date: Wed, 11 Nov 2026 20:57:59 +0000 Subject: [PATCH] Record continuation execution settings decision --- docs/roadmap/conversation-continuation.md | 40 ++++++++++++++--------- 1 file changed, 25 insertions(+), 15 deletions(-) diff --git a/docs/roadmap/conversation-continuation.md b/docs/roadmap/conversation-continuation.md index dceb8a4..165ca9f 100644 --- a/docs/roadmap/conversation-continuation.md +++ b/docs/roadmap/conversation-continuation.md @@ -100,30 +100,40 @@ supported by PromptKit, without silently adding a raw provider-envelope API. ### 2. How Are Follow-Up Execution Settings Selected? -**Status: open.** Decide which settings come from the follow-up request and -which, if any, carry forward from the originating exchange. +**Status: accepted.** A continuation supplies existing conversational context +to a normally configured new execution. Conversation history does not introduce +another source of execution-setting inheritance. -**Recommendation:** preserve conversation content while resolving the new +**Accepted approach:** preserve conversation content while resolving the new profile and output contract through the follow-up prompt and ordinary request overrides. The follow-up can therefore use a different model and response -schema without modifying the original exchange. Reuse existing selection and -precedence rules rather than adding another settings-resolution system. +schema without modifying the original exchange. Explicit request overrides use +ordinary precedence, including complete replacement of the output contract +when supplied. Reuse existing selection and precedence rules. In particular, prefer the follow-up prompt's default profile when no explicit profile is supplied, with the ordinary missing-profile behavior if neither is available. Do not retain the original direct credential merely to retain -conversation history; resolve credential supply for the new execution. +conversation history; resolve credential supply for the new execution using +the ordinary credential rules. -**Alternative:** inherit the originating execution's profile and settings unless -overridden. This is convenient for repeated turns against the same model, but -adds another precedence source and can make a follow-up prompt's defaults -surprising. Inheriting an old output contract is especially unsuitable when -proposal and revision responses have different shapes. +Select the session ID using the new request's explicit value or the follow-up +prompt's session template under the existing rules. Do not implicitly inherit +the preceding execution's session ID. An application can explicitly supply the +same session ID across turns. Conversation relationships are recorded separately +and do not depend on a shared session ID. -**Details to settle:** session-ID inheritance versus follow-up template -resolution, explicit overrides, credential lifetime, and the ordering of -follow-up definition messages and caller-appended messages. Preserve authored -roles rather than silently rewriting follow-up system or developer messages. +**Alternative considered, not selected:** inherit the originating execution's +profile and settings unless overridden. This is convenient for repeated turns +against the same model, but adds another precedence source and can make a +follow-up prompt's defaults surprising. Inheriting an old output contract is +especially unsuitable when successive turns expect different response shapes. +An explicit inheritance option is not selected for this feature; reconsider it +only if ordinary selection leaves a demonstrated usability gap. + +**Implementation planning detail:** specify message assembly order for captured +history, follow-up definition messages, and caller-appended messages, preserving +authored roles. This does not reopen the accepted execution-setting precedence. ### 3. Should PromptKit Coordinate Turns, And Where Does Application Work Run?