[rudycelekli]

graphicle_memory::standing::openings panics on a conversation whose first user sentence is longer than 300 bytes when byte 300 of it falls inside a multi-byte character.

What happens

User: I need help with éééé… (200 × "é")

byte index 306 is not a char boundary; it is inside 'é' (bytes 305..307) of `User: I need help with ééé…`

Text in any language beyond ASCII can trigger it: two-byte Latin or Cyrillic letters, three-byte CJK. observer::outline calls openings on each conversation document it outlines, so one such document makes it panic.

Root cause

An opening longer than 300 bytes is shortened to its last word within the first 300 bytes:

b = a + text[a..a + 300].rfind(' ').unwrap_or(300);
while !text.is_char_boundary(b) { b -= 1; }

The boundary loop protects b, but text[a..a + 300] slices first and panics before the loop runs.

Change

Step the 300-byte cut back to a character boundary first, then look for the last space before it. When a space is found, b is that space as before; when none is found, b is the cut, the same value the old loop produced. So the result is unchanged in every case that did not panic.

Test

standing::tests::a_long_opening_ends_on_a_character_boundary: an opening where byte 300 is inside an é (cut at the last space), and one with no space in its first 300 bytes where byte 300 is inside a CJK character (cut at the last whole character). On main the first case panics.

Verification

In crates/graphicle-memory, with Rust 1.95.0:

• cargo fmt --check: clean
• cargo clippy --locked --all-targets -- -D warnings: clean on Rust 1.95.0 (macOS).
• cargo test --locked --all-targets: 168 passed, 0 failed.

I left CHANGELOG.md to you.

🤖 Generated with Claude Code

[VikramLex]

Thank you, @rudycelekli. Merged for 0.1.2, with your test. Backing off to a character boundary before looking for the space fixes the panic and keeps the cut where it was for ASCII text. The CHANGELOG credits you.