Fix searchMatch key mutation in regex lorebook

[renamerdis-wq]

PR Checklist

• Required Checks
  • Have you added type definitions? (N/A, no new types introduced; the change only uses locals inferred from existing types)
  • Have you tested your changes?
  • Have you checked that it won't break any existing features?
• If your PR uses models¹, check the following:
  • Have you checked if it works normally in all models?
  • Have you checked if it works normally in all web, local, and node-hosted versions? If it doesn't, have you blocked it in those versions?
• If your PR is highly AI generated², check the following:
  • Have you understood what the code does?
  • Have you cleaned up any unnecessary or redundant code?
  • Is it not a huge change?
    • We currently do not accept highly AI generated PRs that are large changes.

Summary

Fixes the arg.keys[0] mutation bug in regex lorebook key matching, which caused regex lorebook entries to silently fail on all messages after the first non-matching one.

Related Issues

Fixes #1530

Changes

• Removed the mutation of arg.keys[0] during regex key iteration in searchMatch (src/ts/process/lorebook.svelte.ts).
• Each key is now parsed into local pattern and flags variables using ^\/([\s\S]*)\/([dgimsuvy]*)$.
• Updated: Keys are parsed and compiled once into a { regex, source }[] array before the message scan instead of being re-parsed and re-compiled for each message; lastIndex is reset before each .test() call for g/y flagged regexes.
• This fixes all four reported defects:
  • matches in later scanned messages failing;
  • the opening / being retained as part of the pattern;
  • flagless regexes never being evaluated;
  • multiple regex keys overwriting arg.keys[0].

Impact

• Regex lorebook entries now activate correctly regardless of which scanned message contains the match.
• Error behavior is preserved: keys that fail to parse or compile still return false, same as before.
  Updated: regex keys are validated up front, so any malformed key makes the entry inactive. See the verification comment below for details.
• Pure string/regex parsing change — model-agnostic, no platform-specific code, so behavior is identical across web, local, and node-hosted versions.

Additional Notes

Manual verification on a local node-hosted build, with a test lorebook covering each reported defect:

• a match in the first scanned message (/studio/i — also covers the leading-slash defect);
• a match only in the last scanned message (the mutation defect);
• a flagless regex (/flagless/);
• multiple comma-separated regex keys where only the second key matches.

All four entries activate correctly on the fixed build (verified via the lore monitor and the actual prompt sent).

Minor edge case: an empty pattern key (//) previously was silently skipped and now compiles to an empty regex (matches everything). This follows the parsing approach proposed and approved in #1530.

Verification screenshots (lore monitor + actual request body)

All four test entries activate — TEST1 (match only in the last scanned message), TEST2 (/studio/i, the leading-slash case from the issue), TEST3 (flagless /flagless/), TEST4 (second of two comma-separated keys):

Footnotes

1. Modifies the behavior of prompting, requesting, or handling responses from AI models. ↩

2. Over 80% of the code is AI generated. ↩

[cubicj]

I reproduced all four defects from #1530 on current main and ran the same cases against this branch, a match only in the last scanned message, the leading slash case, a flagless key, and the second of two keys matching. All four activate here, the (?!)| workaround keys people use today keep matching, and the error cases behave the same as before, non-/ keys, unclosed regexes, and bad flags all still return false. The parse also handles slashes inside the pattern correctly, /a\/b/i and /[/]/g both split at the right place. pnpm check, pnpm test, and pnpm build pass on this head.

One change I would like to ask for. The parse and the new RegExp construction sit inside the message loop, but the keys never change during a scan, so every message re-parses and re-compiles every key, and recursive scanning repeats all of it each round. I would rather see the keys parsed and compiled once before the message loop. Two things to watch if you take this: a reused regex makes .test() stateful under the g and y flags, which your current version avoids by constructing a fresh regex each time, so the compiled regexes need their lastIndex reset or the flags handled some other way. And validating all keys up front means an entry with any malformed key is always inactive, where the current code stops validating later keys once an earlier one matches the first scanned message. I think the stricter behavior is the right one, but it is a small semantic change so I am calling it out.

Two smaller notes, neither blocking. A key of exactly / used to be skipped with the remaining keys still evaluated, and now it fails the parse and deactivates the entry. Nobody realistically has that key, I am noting it only because the PR body covers // but not this case. And in regex mode @@exclude_keys_all acts as ANY rather than ALL, since this branch returns on the first key match before arg.all is read. That is pre-existing rather than something this PR introduces, but regex exclude keys only start working with this fix, so this is where it will start to show.

Does hoisting the compilation look right to you, or is there a reason to prefer the per-iteration construction that I am missing?

[renamerdis-wq]

Thanks for the thorough review :)
There wasn’t any particular reason for keeping the parsing and RegExp construction inside the message loop.

I’ll move them before the scan as you suggested, and I’ll make sure to reset lastIndex before each .test() call so the behavior of the g and y flags remains unchanged.

I’m currently traveling, so I’ll update the branch as soon as I’m back.

[renamerdis-wq]

Sorry for the delayed update, and thanks for your patience 🙇🏻‍♀️

Updated the branch with the requested changes!

I moved regex parsing/compilation before the message scan and reset lastIndex before each .test() call.
The branch is also rebased onto the current upstream main, so the PR now contains a single commit on top of it.

I also manually verified the relevant cases in the RisuAI UI, including /apple/g, malformed regex handling, and the exact / case.

pnpm check, pnpm test, and pnpm build all pass.

Thanks again for the review :)

Verification screenshots (lore monitor + actual request body)

TEST1 (match only in the last scanned message)
→ Activated correctly when the trigger appeared only in a later scanned message.

TEST2 (/studio/i, the leading-slash case from the issue)
→ Activated correctly without treating the leading / as part of the pattern.

TEST3 (flagless /flagless/)
→ Activated correctly with no regex flags.

TEST4 (second of two comma-separated keys)
→ Activated correctly from the second key (/포도밭/i).

TEST5 (/apple/g)
→ Activated correctly with the compiled global RegExp reused during the message scan.

TEST6 (/foo/i,/(/)
→ Stayed inactive as expected because the malformed second regex fails upfront validation.

TEST7 (exact /)
→ Stayed inactive as expected because the key does not match the regex literal format.

I also checked the actual request body to confirm that only TEST1-5 were inserted into the prompt, while TEST6-7 were not.

[cubicj]

I went through 4fa72fb against the two asks from the last round. The parse and the RegExp construction now run once before the message scan, and lastIndex is reset before each .test() call. I compared the reused compiled regexes against fresh per-iteration construction across the constructible flag combinations, including repeated g and y rounds, and found no mismatches. The four defect cases from #1530 and the (?!)| workaround keys give the same results as my pass on 970cd98, and the upfront validation delta is now disclosed in the PR body.

pnpm check, pnpm test, and pnpm build are clean on this head, and the branch sits on current main as a single commit.

Approving — thanks for the careful follow-ups!

[sub-hub]

Thanks for the PR.

Reviewed the final head: the per-iteration arg.keys[0] mutation is gone, keys are parsed/compiled once with a proper /pattern/flags split, and lastIndex is reset for g/y regexes. I traced the only caller and didn't find any regressions; behavior for non-/ keys and invalid flags is unchanged.

This also matches reports from users: regex lorebook entries only ever matched the oldest message within the search depth (e.g. always message 0), and people were using /(?!)|... workarounds for the leading-slash issue. Those workaround keys keep working after this change.

Noting the intentional behavior change for release notes: a malformed regex key now makes the whole entry inactive (previously, flagless malformed keys were skipped).