Summary

Multiple hot paths recompile regex patterns per call instead of caching them. The codebase already has a clean LazyLock<Regex> / Vec<CompiledPattern> style elsewhere — the offenders just weren't migrated.

Location

• crates/librefang-channels/src/qq.rs:132,135,138,141,144,147,150,153,156,159 — strip_markdown calls regex_lite::Regex::new(...).unwrap() 10 times per outbound message (~50–200µs each → ~1ms/message of pure compile).
• crates/librefang-runtime/src/agent_loop.rs:5713 — Pattern 9: <function name=…> recompiled on every model turn for every Groq/Llama agent.
• crates/librefang-kernel/src/orchestration.rs:237 (MatchesRegex) — recompiled per quality-gate evaluation.

Compare correct usage: crates/librefang-channels/src/sanitizer.rs:47-89 compiles in from_config and stores patterns: Vec<CompiledPattern>.

Failure mode

• ~1ms compile overhead per outbound QQ message dwarfs the actual replace.
• For Groq/Llama agents the per-turn regex compile sits inside the LLM response loop, multiplying with turn count.
• Quality-gate MatchesRegex recompiles on every eval, defeating any performance work on the gate engine.

Fix direction

• Move each pattern into a static OUTBOUND_BOLD: LazyLock<Regex> = LazyLock::new(|| Regex::new(...).unwrap()); (use std::sync::LazyLock).
• For orchestration.rs MatchesRegex, compile once per config load and store the compiled Regex in the gate struct.
• Add a benchmark or cargo asm guard in CI to catch regressions.