SplitMessage introduces non-trivial behavior (natural boundaries, code block fence handling, and the 500-char buffer) but there are no unit tests verifying chunk sizes, code-block integrity, and edge cases (e.g., long code blocks without closing fences, no whitespace, Unicode input). Given the repo has existing Go unit tests, please add focused tests in pkg/utils for this helper.

SplitMessage uses byte-based len() and byte indices when slicing (e.g., content[:msgEnd]). If msgEnd lands in the middle of a multi-byte UTF-8 rune, this will split the string into invalid UTF-8 and can produce garbled output or API rejections. Consider operating on []rune (or otherwise ensuring msgEnd aligns to rune boundaries) so chunk boundaries are Unicode-safe and the maxLen semantics align with character-based limits.

This function computes split points using len(content) and slices strings by byte index (e.g., content[:effectiveLimit] / msgEnd = effectiveLimit). When there’s no newline/space, msgEnd can land in the middle of a multi-byte UTF-8 rune, producing invalid UTF-8 chunks and potentially garbling output. Consider doing all length accounting/splitting in runes (or adjust msgEnd back to a valid rune boundary using utf8 helpers).

When splitting inside a code block, content = strings.TrimSpace(header + "\n" + content[msgEnd:]) removes all leading whitespace from the reopened chunk. If the code block content starts with indentation (common in code), this changes the message content rather than just splitting it. Consider avoiding TrimSpace here (e.g., only trimming leading newlines) to preserve code formatting.

Same as above: strings.TrimSpace(header + "\n" + content[msgEnd:]) in this branch can strip meaningful leading indentation/whitespace from code content after the reopened fence, altering output. Prefer preserving the original whitespace (or only trimming the newline(s) introduced by the split).

If the opening fence line doesn’t contain a newline (e.g., lang immediately followed by content), the `headerEnd == -1` branch sets `headerEnd = unclosedIdx + 3`, so `header` becomes just "" and the language tag is lost when reopening. Consider falling back to the next whitespace/end-of-string (or msgEnd) so the language specifier is preserved when present.

SplitMessage introduces fairly intricate splitting behavior (code-fence detection, fence injection/reopening, buffer logic). Adding unit tests (e.g., plain text, long code blocks, missing closing fence, and Unicode/multi-byte input) would help ensure this shared utility stays stable as other channels start using it.

The comment says "Check that second chunk starts with execution header" but should say "Check that second chunk starts with code block header" for consistency with the error message on line 76.

The SplitMessage function uses byte-based indexing (string slicing) which can split multi-byte UTF-8 characters, potentially creating invalid UTF-8 sequences. When slicing at positions found by findLastNewline, findLastSpace, or at arbitrary positions like effectiveLimit or innerLimit, the function may split in the middle of a multi-byte character. Consider using rune-based indexing or validating split points to ensure they fall on character boundaries. The test case "Preserve Unicode characters" acknowledges this issue but doesn't verify the output is valid UTF-8.

There is a potential infinite loop when msgEnd is set to 0. This can occur on line 95 when unclosedIdx is 0 (code block starts at the beginning), or potentially from other code paths. When msgEnd is 0, line 112 performs content = strings.TrimSpace(content[msgEnd:]) which doesn't reduce the content length (it's just trimming the same string), causing an infinite loop. The guard on lines 107-109 sets msgEnd to effectiveLimit only if msgEnd <= 0, but this happens AFTER the code block handling logic which may have set msgEnd to 0 and then taken a continue path earlier. Consider adding validation that msgEnd must be > 0 before line 111, or ensure line 95 sets msgEnd to at least 1.

The test cases only verify that specific chunks don't exceed maxLen, but don't comprehensively check all chunks. For example, in the "Simple split regular text" test (lines 36-39), only chunk 0 is checked, not chunk 1. In the "Long code block split" test (lines 69-78), neither chunk is explicitly checked for length. Consider adding a check that iterates through all chunks and verifies each one is <= maxLen to ensure the function never produces oversized chunks.

The test case acknowledges that splitting mid-rune (multi-byte UTF-8 character) would be bad, but doesn't verify that this doesn't happen. The test only checks that the chunk contains at least one instance of the Unicode character, but doesn't validate that all chunks contain valid UTF-8. Consider adding validation using utf8.ValidString() to ensure all chunks are valid UTF-8 sequences.

Send converts the full message to []rune only to check emptiness (len(runes) == 0), which allocates and can be expensive for long messages. This can be replaced with a simple msg.Content == "" (or len(msg.Content)==0) check without changing behavior.

SplitMessage computes split points using byte indexes (len, content[:effectiveLimit], content[:msgEnd]). When there are no ASCII split characters near the boundary (e.g., long CJK/emoji text), msgEnd can land in the middle of a UTF-8 sequence, producing invalid UTF-8 in a chunk (and JSON encoding will replace invalid bytes). Consider adjusting msgEnd to the nearest prior UTF-8 rune boundary (or operating on []rune) before slicing.