反馈harness问题

[snjxh-maket]

Windows 11 中文版 + 微软拼音 + dsh web，在 composer
打字、确认前就出现错字（如「你好」→「尼哈奥尼」），会出现乱码，全新窗口/粘贴可绕过

[argszero]

Thanks for the report — Windows 11 + 微软拼音 + the web composer is a real configuration, and the "错字出现在确认前 + 新窗口/粘贴可绕过" signature is informative. Source context from master (d347e70390) to help narrow it:

The composer is a Lexical contenteditable, not a plain <textarea>/<input>. The editable surface is a contenteditable div bound to a Lexical editor (packages/client/ui-conversation/src/client/input/editor/ComposerContentEditable.tsx), with a custom pipeline around it (draft machine, submission machine, token spans/claims, reference-entity transforms). Typing goes through Lexical's input pipeline; composition events (compositionstart/update/end) are handled by Lexical + the browser, not by a React controlled-value path.

Why paste and fresh windows bypass it is consistent with that stack:

• Paste is a separate code path (facade.ts:338 paste() → sanitize → insertText with a PASTE_TAG) that never touches the typing/composition pipeline — so pasting 你好 lands intact.
• A fresh window clearing the bug points to a corrupted editor/decoration state accumulated during the failed composition, not a static transform that always mangles (a static regex/transform would reproduce deterministically in every window).

The garble pattern ("你好" → "尼哈奥尼" — each target character echoed as something like a pinyin-syllable homophone string) looks like the IME's composition string being fed back into the editor as separate insertions mid-composition — i.e., the editor re-enters or re-dispatches text while the composition is still open, and each re-entry is interpreted as independent input. That class of bug usually lives in: (a) Lexical's own Windows IME handling (upstream issue class — worth a minimal Lexical-only repro to isolate), or (b) one of the custom transforms (reference entity / claim decor / span-map) reacting to the composition text and rewriting nodes while the IME still owns the composition.

To move this forward I'd want:

1. Exact version (the screenshot context suggests a recent build — 0.1.2-rc.1? alpha?) and whether it happens on every session or after some trigger.
2. Does the garble appear only in the editor's visible text, or also in the sent message? (i.e., is it a display/decoration artifact or does the committed text get corrupted?)
3. Does it reproduce with a different IME (e.g., the built-in Microsoft Pinyin vs a third-party one)? If only 微软拼音, it's composition-event-shaped; if all IMEs, it's the editor pipeline.
4. A minimal repro: in a fresh session, does typing "nihao" and choosing the candidate produce the garble immediately, or after several compositions?

If you can capture the composition (a screen recording including the candidate window) and confirm the version, this is likely diagnosable to a specific transform or an upstream Lexical issue — happy to dig in with that in hand. Also worth filing against the ui-conversation package with the keyboard-layout note, since IME-specific bugs tend to need a Windows reporter to reproduce at all.

[snjxh-maket]

Hi, Thanks for looking into this. Here are the additional details: Version: 0.1.2-rc.1-d4eb4f4 The garbled text is also corrupted in the sent message, so it is not just a visual/display issue in the composer. I only have the built-in Microsoft Pinyin IME on Windows 11, so unfortunately I cannot test this with another IME. Opening a new window sometimes restores normal input, but most of the time the problem still occurs. The issue happens immediately with the very first composition. For example, when I type nihao and select the candidate for “你好”, the garbled text appears right away. I will also attach a screen recording showing the composition process and the garbled text appearing in the composer. Thanks! Message ID: ***@***.***> 从QQ邮箱发来的超大附件 2609071103404821.mp4 (344.2KB, 2026年10月7日 11:31) 进入下载页面 ：https://wx.mail.qq.com/ftn/download?func=3&k=cf9a1535da04aaa1fde94b3536666565fb05603534666565184a08531b04075d08515204054b55550154480105020448520454041951010703015304515f55510771650702565c5507545405075255510857541b5916517177a47748100f382af8cf549b91815417966cd81b3566656530656535&key=cf9a1535da04aaa1fde94b3536666565fb05603534666565184a08531b04075d08515204054b55550154480105020448520454041951010703015304515f55510771650702565c5507545405075255510857541b5916517177a47748100f382af8cf549b91815417966cd81b3566656530656535&code=0ee54fee&from=

[argszero]

Thanks — this is exactly the data that discriminates the mechanisms. Key updates to the hypothesis:

"Sent message is also corrupted" rules out the display/projection layer entirely. The wrong text is what the draft machine commits and what goes over the wire — so the corruption happens in the composer's commit path (or before it: at composition-commit → model-update time), not in rendering.

"Immediate on the very first composition" + "new window mostly doesn't help" together point to a deterministic per-composition transform, not accumulated state. That's an important narrowing: my earlier "state corruption in a long session" guess is out. The failure reproduces from a clean editor on the first IME commit.

Putting the two together, the interesting question becomes what the committed text actually is. Your example (typing nihao, selecting 你好, garbled right away) — the earlier garbling looked like the pinyin string itself being re-entered/re-composed (你→尼哈奥尼 reads like "nihaoni" re-segmented). If the composer's commit path takes the composition's text value but then re-runs it through the token-span/claim pipeline (which in this harness splits content and re-inserts with transform markers), a CJK commit could be getting re-inserted as if it were fresh text input — and a contenteditable re-insert under an active IME context would re-open composition on the wrong buffer.

Three asks that would pin it (the recording may already answer 1–2):

1. What exactly is in the sent message — the full 尼哈奥尼? or 你好 plus trailing garbage? and is it always the same transform for the same input (type nihao → 你好 twice: same garbling both times)?
2. Does it also corrupt direct keyboard input with the IME in English mode (type ASCII with 微软拼音 active but no composition)? If ASCII is clean, it's composition-commit-specific; if ASCII also corrupts, it's the insertion path generally.
3. Is the displayed garbling byte-identical to the sent garbling? (If display shows 你好 but sent is 尼哈奥尼, the corruption is between model and send; if both show 尼哈奥尼, it's at commit.)

Version noted: 0.1.2-rc.1-d4eb4f4. One more useful check on your side: does the plain-text fallback (paste the same 你好, or type via an on-screen keyboard / IME candidate paste) stay clean? Paste already bypasses (separate path), so this isolates whether the composition-commit handler itself is the transform point.

I'll also re-check the commit path in master for anything that re-inserts or re-runs composition buffers on CJK text — if the transform is in-tree and deterministic, a repro without the IME (synthesizing the same compositionstart→insertText→compositionend sequence) should trigger it cross-platform.

[snjxh-maket]

Hi, Thanks for the follow-up. I did some additional testing, and here are the results: The garbled text is typically something like “尼哈奥”, but the exact output varies depending on what I type. It happens before I press Enter to commit the IME composition. In other words, the garbled text already appears in the composer while I am still in the process of entering the text, rather than only appearing after I confirm the candidate. The garbling seems to be related to the pronunciation of the original text. For example, typing “你好” may result in something like “你好+尼哈奥”, while other text can produce much longer and seemingly irregular output. For example, “我知道” may become something similar to “沃兹＇达奥沃＇兹沃兹沃兹沃”. The corrupted output can contain a mixture of English letters, Chinese characters, and sometimes punctuation. It often contains homophones of the original text, but the overall format seems irregular and unpredictable. Repeating the same input twice usually produces roughly the same type of garbling, although it is not necessarily byte-for-byte identical. I also tested typing with Microsoft Pinyin in English mode. Interestingly, even direct English/ASCII input can become corrupted, so the issue does not appear to be limited to Chinese IME composition. I will attach a screen recording to this email showing the issue in detail. My version is 0.1.2-rc.1-d4eb4f4. I hope the recording and these additional details help narrow down where the text is being re-inserted or transformed. Thanks!

…

---原始邮件--- 发件人: ***@***.***&gt; 发送时间: 2026年9月7日(周一) 上午10:41 收件人: ***@***.***&gt;; 抄送: ***@***.******@***.***&gt;; 主题: Re: [deepseek-ai/deepseek-harness] 反馈harness问题 (Discussion #5836) Thanks for the report — Windows 11 + 微软拼音 + the web composer is a real configuration, and the "错字出现在确认前 + 新窗口/粘贴可绕过" signature is informative. Source context from master (d347e70) to help narrow it: The composer is a Lexical contenteditable, not a plain <textarea&gt;/<input&gt;. The editable surface is a contenteditable div bound to a Lexical editor (packages/client/ui-conversation/src/client/input/editor/ComposerContentEditable.tsx), with a custom pipeline around it (draft machine, submission machine, token spans/claims, reference-entity transforms). Typing goes through Lexical's input pipeline; composition events (compositionstart/update/end) are handled by Lexical + the browser, not by a React controlled-value path. Why paste and fresh windows bypass it is consistent with that stack: Paste is a separate code path (facade.ts:338 paste() → sanitize → insertText with a PASTE_TAG) that never touches the typing/composition pipeline — so pasting 你好 lands intact. A fresh window clearing the bug points to a corrupted editor/decoration state accumulated during the failed composition, not a static transform that always mangles (a static regex/transform would reproduce deterministically in every window). The garble pattern ("你好" → "尼哈奥尼" — each target character echoed as something like a pinyin-syllable homophone string) looks like the IME's composition string being fed back into the editor as separate insertions mid-composition — i.e., the editor re-enters or re-dispatches text while the composition is still open, and each re-entry is interpreted as independent input. That class of bug usually lives in: (a) Lexical's own Windows IME handling (upstream issue class — worth a minimal Lexical-only repro to isolate), or (b) one of the custom transforms (reference entity / claim decor / span-map) reacting to the composition text and rewriting nodes while the IME still owns the composition. To move this forward I'd want: Exact version (the screenshot context suggests a recent build — 0.1.2-rc.1? alpha?) and whether it happens on every session or after some trigger. Does the garble appear only in the editor's visible text, or also in the sent message? (i.e., is it a display/decoration artifact or does the committed text get corrupted?) Does it reproduce with a different IME (e.g., the built-in Microsoft Pinyin vs a third-party one)? If only 微软拼音, it's composition-event-shaped; if all IMEs, it's the editor pipeline. A minimal repro: in a fresh session, does typing "nihao" and choosing the candidate produce the garble immediately, or after several compositions? If you can capture the composition (a screen recording including the candidate window) and confirm the version, this is likely diagnosable to a specific transform or an upstream Lexical issue — happy to dig in with that in hand. Also worth filing against the ui-conversation package with the keyboard-layout note, since IME-specific bugs tend to need a Windows reporter to reproduce at all. — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***&gt; 从QQ邮箱发来的超大附件 2609071955312971.mp4 (660.4KB, 2026年10月7日 19:56) 进入下载页面 ：https://wx.mail.qq.com/ftn/download?func=3&k=9b9b43638f04acfca9e81d6363666338c0353963616663384c4b5e054e50550a05000152534b075a07551e57525553155c5607064c55550a5d56565a59045b085370335157565a0853550a565455520a5d53024d0c16572c41f0bd028ca116540c173f771c7a3be95740dc176366633864643363&key=9b9b43638f04acfca9e81d6363666338c0353963616663384c4b5e054e50550a05000152534b075a07551e57525553155c5607064c55550a5d56565a59045b085370335157565a0853550a565455520a5d53024d0c16572c41f0bd028ca116540c173f771c7a3be95740dc176366633864643363&code=dd3cafc8&from=