base-layer/promptkit
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 6 Wiki Activity

Record continuation execution settings decision

Browse Source
This commit is contained in:
Eric Rakestraw
2026-11-11 20:57:59 +00:00
parent 9396183bdb
commit f20020d9f4
1 changed files with 25 additions and 15 deletions
Download Patch File Download Diff File Expand all files Collapse all files

40
docs/roadmap/conversation-continuation.md
View File

@@ -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?