{"version":"2.1.269","anchor":"turn-start-stream-event-doc-typed-prompt-turns-now-also-sta","canonical_anchor":"user-message-uuid-stamping-semantics-for-the-sdk-message-str","heading":"user_message_uuid stamping behavior for SDK streams clarified","tier":"notice","area":"SDK","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.269\/e\/turn-start-stream-event-doc-typed-prompt-turns-now-also-sta","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.269","markdown":"### user_message_uuid stamping behavior for SDK streams clarified\n\nDocumentation for the SDK's user_message_uuid now matches its actual behavior across partial and complete assistant messages\n\n**What**\n\n- The documented behavior of `user_message_uuid` changed: it stamps the turn's first top-level assistant message (which may be only a thinking block, or a synthetic API-error message), not simply the first reply frame.\n\n- With `--include-partial-messages`, the first non-ping stream event is now stamped independently of the completed message, so the same uuid can appear on two frames instead of the partial stream replacing the complete-message stamp.\n\n- The SDK docstring now also clarifies that a turn started by a typed prompt stamps both its first non-ping stream event and, independently, its first complete assistant message (`SDKAssistantMessage.user_message_uuid`), so both can carry the same uuid.\n\n**Why** This makes the SDK's documentation match its real streaming behavior, so integrators relying on `user_message_uuid` to correlate partial and complete messages get accurate expectations instead of being misled by outdated docs.\n\n- Area: SDK\n- Names: `user_message_uuid`\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 1\/5"}