Record logical conversation capture decision

docs/roadmap/conversation-continuation.md

@@ -1,8 +1,8 @@
 # Conversation Continuation And Application-Directed Interaction
 
-Status: proposed feature roadmap; open decisions await discussion. No
-implementation is authorized by this document. Recommendations below are not
-accepted contracts, except for the guiding principle explicitly recorded below.
+Status: feature roadmap under discussion; accepted directions and remaining
+open decisions are identified below. No implementation is authorized by this
+document. Recommendations remain proposals unless explicitly marked accepted.
 
 ## North Star: Content-Neutral, Generally Useful Capabilities
 
@@ -63,30 +63,34 @@ conversation storage, and batch-item reconciliation are outside its scope.
 The existing [prepared execution handle](../../prepared_execution.go) remains a
 single-use execution capability; continuation needs its own semantics.
 
-## Open Decisions In Discussion Order
+## Decisions In Discussion Order
 
 ### 1. What Does A Captured Exchange Contain?
 
-**Status: open.** Decide whether capture represents a logical conversation or
-the complete sequence of provider requests, including structural repair.
+**Status: core decision accepted; remaining lifecycle details open.** Capture
+represents the logical conversation. Structural-output repair attempts and
+corrective instructions are internal execution details, not conversation turns.
 
-**Recommendation:** capture the complete rendered request, preserving message
+**Accepted approach:** capture the complete rendered request, preserving message
 content, roles, and cache metadata, followed by the final assistant content
-returned by the run. An initial run that needed structural repair would retain
-its final content without adding the internal corrective instructions to the
-logical conversation. This supplies reusable context for subsequent turns while
-keeping transport attempts and structural repair separate from application
-turns. It also matches Audita's requested history.
+returned by the run. When structural repair succeeds, retain only the final
+corrected assistant content, excluding intermediate candidates and corrective
+instructions from the logical conversation. This supplies reusable context for
+subsequent turns while keeping transport attempts and structural repair separate
+from application turns. It also matches Audita's requested history.
 
-Make capture opt-in. A continuation would append its rendered follow-up messages
+Capture is opt-in. A continuation would append its rendered follow-up messages
 and final response to produce a new exchange, leaving the source exchange and
 other branches unchanged. Previously rendered history would not require the
 original input files or templates to be rendered again.
 
-**Alternative:** retain the actual corrective messages and responses that led
-to the final output. This provides more execution detail, but increases retained
-content and carries internal repair instructions into later model context.
-Attempt diagnostics can serve that need separately if a consumer requires it.
+**Alternative considered, not selected:** retain the corrective messages and
+responses that led to the final output. This provides more execution detail,
+but increases retained content and carries internal repair instructions into
+later model context.
+Fine-grained execution tracing is outside this feature's purpose. Existing
+attempt and usage observations remain separate from logical conversation
+content; this decision adds no requirement to capture internal repair text.
 
 **Details to settle:** capture availability after structural validation
 exhaustion or an operational failure; how callers request capture for ordinary