Correct, and it is my bug: #757 added chat_at_streaming with buf.push_str(&String::from_utf8_lossy(&part)), which decodes each network chunk on arrival, so a code point split across two chunks is replaced before anything can reassemble it. Chinese and emoji are where it shows first.

Verified here. With the fix, 3 new tests pass and the crate is 26 green. With hunks 1 to 3 reverted and the tests kept:

---- tests::bytewise_utf8_survives_collected_streaming stdout ----
assertion `left == right` failed
  left: "����������"
 right: "你好🦀"

Same failure on the raw and tool paths. Moving the buffer to Vec<u8> and decoding only a complete frame is the right fix, and covering all three streaming methods rather than only the one I touched is the reason this is worth merging as it is.

One correction to the framing, for the record rather than for you to change: git blame puts the same pattern in chat_tools_stream_with and chat_stream_raw at the shallow boundary of this clone (2026-08-29), so those two predate #757. #757 copied an existing pattern into a third place. Your fix is the first time any of the three has been right.

Three things I would not block on:

• buf.windows(2).position(|w| w == b"\n\n") is a byte-by-byte scan where str::find used std's accelerated search. The rescan from zero on every chunk was already quadratic in the old code, so this is a constant factor on a pathological frame, not a new class. Mentioning it so the next person does not have to rediscover why it is a loop.
• bytewise_sse depends on hyper surfacing each one-byte write as its own bytes_stream() item. It does today, which the revert proves, but nothing forces it: if hyper ever coalesced, the test would go green while testing nothing. Splitting deliberately on a known code-point boundary would not depend on that.
• The trailing-frame decode still yields U+FFFD when a stream dies mid-character. Unavoidable, and #768 turns that case into an error anyway.

Comments in this repo are Chinese. The new ones are English.