Thanks — clampSurrogateBoundary is correct and the edge tests are thorough.

Since the sibling #16404 (same author, same root cause: naive UTF-16 truncation on the CJK hard-cut fallback) needs the exact same logic for topic-title truncation and currently inlines a byte-identical copy of this boolean, the main thing I'd raise on this PR is where the shared fix should live:

1. Promote the helper to src/shared/utils/. It's pure, stateless, cross-process-safe string logic, and the need isn't channel-specific — topic naming hits it, and src/renderer/utils/naming.ts has the same latent hard cut in its fallback (text.substring(0, maxLength)). One shared home lets fix(topic-naming): keep surrogate pairs whole when truncating the first-message title #16404 and the renderer import it instead of re-implementing. It also removes the layering reason fix(topic-naming): keep surrogate pairs whole when truncating the first-message title #16404 gave for inlining (a services/ → ai/channels/ import would invert layering).

2. For the one-shot truncation callers, a code-point view reads cleaner than the manual high/low-surrogate check and is just as correct: [...text].slice(0, maxLength).join('') — the spread iterates code points, so surrogate pairs are atomic, no 0xd800/0xdc00 math. Note that's for the truncate-once shape (topic naming). For splitMessage here, keep the index-clamp you have: it clamps an arbitrary boundary inside a loop, and maxLength is a hard platform limit, so the budget must stay in code units — [...text].slice would shift it to code points. So a reasonable shared util exposes both: clampSurrogateBoundary(text, index) for channels and a thin truncate(text, max) wrapper for one-shot callers.

Intl.Segmenter ('grapheme') would be the most thorough — it also keeps ZWJ emoji, flags, skin-tone and combining sequences whole — but it isn't worth it here: the only visible corruption is the � from a split surrogate, which the code-point boundary already removes; a split grapheme still renders as a valid (smaller) glyph. It's also heavier (construct once at module scope) and counts graphemes, which can overshoot a hard length budget. Worth revisiting only for a general UI-truncation util later.

Not blocking.

Done — promoted the helper to src/shared/utils/text.ts and pointed the channel code (splitMessage plus the Discord/Slack truncations) at it, so there's one home for the surrogate arithmetic now. The unit tests moved alongside it under shared/utils/__tests__/.

I kept the function as clampSurrogateBoundary(text, index) rather than swapping splitMessage to a code-point view, for the reason you noted: the platform caps here are hard limits in UTF-16 code units, so the budget has to stay in code units. I wrote that trade-off into the JSDoc so the soft, one-shot callers know to reach for the code-point view instead.

That leaves the sibling #16404 and the src/renderer/utils/naming.ts fallback free to add a thin code-point truncate wrapper next to it. I'll fold #16404 onto this shared home once this lands, as agreed. Rebased onto main.

Maintainer decision on consolidation: let's fold the sibling #16404 into this PR and fix both surfaces in one shot, rather than landing them sequentially.

Why consolidate here:

1. Both surfaces are main-process and now share the same arithmetic. Keeping fix(topic-naming): keep surrogate pairs whole when truncating the first-message title #16404's inline copy would re-introduce exactly the duplication this promotion eliminated. A single PR that wires both consumers to src/shared/utils/text.ts reaches the consolidated end-state atomically, with no transitional inline copy to clean up later.
2. It's easier to review as one change — and this PR needs a fresh review anyway: the two existing approvals are against acb2540ceb (the pre-promotion inline version), so they don't cover the current shared-util structure.

Concretely, please pull #16404's TopicNamingService.truncateText fix and its regression test in here, so this PR ends up with:

• clampSurrogateBoundary(text, index) consumed by the channels sites (splitMessage + Discord/Slack editMessage) — the index-clamp form, correct for the hard code-unit caps.
• the topic-naming call site wired to the shared helper — either a thin code-point truncate(text, max) wrapper next to it (cleanest for the soft one-shot cap) or a direct slice(0, clampSurrogateBoundary(normalized, maxLength)). Your call; both remove the duplicate boolean.

Then close #16404.

I verified the helper promotion itself is correct: three real consumers, no duplicate entry point, pure stateless @shared util, placement and @shared alias resolve cleanly, and the channels integration test keeps the surrogate path covered through splitMessage's public API. No moved bug at any call site — all operate with 0 < index < length, and truncated lengths stay within the platform limits (Discord ≤2000, Slack ≤4000).

One non-blocking note for the merged result: splitMessage's safe precondition narrows to maxLength >= 2 (at maxLength === 1 with a leading surrogate pair the clamp returns 0 → empty chunk → no progress). Unreachable with every real platform limit, so just noting it.

Out of scope for this PR, worth a separate follow-up: src/renderer/utils/naming.ts has the same latent naive-truncation pattern (text.substring(0, maxLength) in its fallback). It's renderer-side and pre-existing, so it shouldn't ride along here — a small follow-up PR can adopt the same shared helper (the truncate wrapper fits its soft-cap shape).

Done, folded #16404 into this PR as requested. TopicNamingService.truncateText now clamps its cut through the same clampSurrogateBoundary helper from src/shared/utils/text.ts, and the regression test (emoji straddling the 50-char first-message cut) came over with it. All 6 tests in TopicNamingService.test.ts pass. Closing #16404.

Rebased on latest main to clear the conflict. Heads-up on how the fold-in from #16404 shifted, since main moved under it:

The TopicNamingService.truncateText path I pointed at on 07-11 was refactored away upstream — first-user-message title truncation now goes through the new shared helper truncateFirstUserMessageTitleSource in src/shared/utils/conversationTitle.ts, which does a bare slice(0, 50). That's the same mid-surrogate cut, just relocated, so I moved the guard there (it now slices at clampSurrogateBoundary(...)). Net effect: TopicNamingService.ts itself no longer needs a change and drops out of the diff.

Coverage is at both layers:

• conversationTitle.test.ts — unit test on truncateFirstUserMessageTitleSource directly (emoji straddling index 49/50 no longer leaves a lone surrogate).
• TopicNamingService.test.ts — the end-to-end auto-rename test from fix(topic-naming): keep surrogate pairs whole when truncating the first-message title #16404, adjusted for the method now being synchronous.

Verified locally: the shared and main vitest projects are green (11 and 32 tests). Channels side is untouched.