Record captured exchange inspection decision

docs/roadmap/conversation-continuation.md

@@ -389,8 +389,8 @@ classification hierarchy, and aggregate reporting are not part of this minimal
 termination contract. They require a demonstrated consumer need before addition.
 This does not remove fields from existing response values or observation APIs.
 Decision 5 reuses ordinary run accounting without expanding this result.
-Decision 6 separately evaluates inspection without presuming that it needs to
-expand the coordinator's termination result.
+Decision 6 exposes captured-exchange details without expanding the coordinator's
+termination result.
 
 Audita retains its own meanings for acceptance, rejection, withdrawal, and
 assessment unavailability. A normal stop does not assert any of those outcomes.
@@ -467,26 +467,41 @@ not all provider calls performed inside those executions or application callback
 
 ### 6. Where Should Continuation Inspection Live?
 
-**Status: open.** Clarify the request's references to inspection without changing
-the established resource-inspection boundary.
+**Status: accepted; exact method and type shape remain for implementation
+planning.** Provide explicit access to the captured exchange's existing content
+and minimal identity metadata, following the general pattern of
+`PreparedExecution.Details()`.
 
-**Recommendation:** expose originating exchange, follow-up prompt, and execution
-relationships in continuation details, prepared execution metadata, sequence
-reports, and observations as appropriate. Keep `InspectPrompt`, `InspectProfile`,
-and `InspectBackend` focused on their configured resources. Reuse the existing
-approach to generically renderable inspection data where new details are exposed.
-Any proposed report should demonstrate its consumer value; Decision 4's minimal
-termination contract does not promise a sequence report or response archive.
+**Accepted inspection scope:** expose the logical message history, including
+the final assistant response, the exchange's originating run identity, and the
+immediate parent relationship selected in Decision 5. Existing execution results
+and preparation details continue supplying their ordinary information. Reuse
+existing types where useful rather than creating a second comprehensive
+execution report.
 
-**Alternative:** introduce a dedicated conversation inspection API. This may
-be useful if a retained exchange needs a richer view, but should be justified
-against a simple details method. Extending resource inspection with execution
-history would give those APIs a different responsibility.
+Details should be generically renderable through ordinary encoders so consumers
+can display them without field-by-field adapters. Reading or modifying a
+returned details value must not alter retained history or another branch's
+execution. Access reads captured values without rerendering templates, reloading
+inputs, or making provider calls. Captured message content remains separate
+from ordinary metadata-only execution observations.
 
-**Details to settle:** the minimum inspectable metadata, how callers explicitly
-access captured message content, and separation of content-bearing details from
-metadata-only observations. Public type names and serialization details belong
-in implementation planning after this boundary is settled.
+The exchange contains logical conversation history because continuation needs
+it. This does not create a separate archive of execution results or expand the
+coordinator's minimal termination result. `InspectPrompt`, `InspectProfile`, and
+`InspectBackend` retain their configured-resource responsibilities.
+
+**Representation alternatives for implementation planning:** a small details
+accessor on a retained exchange is the preferred pattern. A public data value
+may also satisfy the accepted behavior with fewer API elements, provided its
+ownership rules prevent caller mutations from affecting retained branch state.
+Choose the exact representation and serialization details during API planning.
+
+**Alternative considered, not selected:** an engine-level conversation lookup
+and inspection API. Such an API could serve a searchable conversation registry,
+but this feature does not select that registry. Explicit access through an
+already-held exchange satisfies the present need. Richer reporting or registry
+capabilities require separate consumer justification.
 
 ## Proposed Delivery And Validation
 
@@ -517,6 +532,9 @@ coverage should establish:
   and count shared initial work once, without coordinator-provided totals.
 - Immediate parent relationships distinguish successive turns and independent
   branches using existing run identities.
+- Explicit exchange details expose captured logical history and minimal identity
+  metadata through ordinary encoding. Mutating returned details does not affect
+  retained branch state, and inspection requires no rendering or external reads.
 
 These are planning targets, not new implemented guarantees. Keep additional
 mechanisms and constraints tied to the selected decisions and demonstrated