⚡ Bolt: Optimize routing engine by caching module search text

.jules/bolt.md

@@ -1,3 +1,8 @@
+## 2024-03-24 - Python Routing Engine Iteration Performance
+**Learning:** The Python routing engine (`src/runtime.py`) iterates over module properties frequently during the scoring loop. Repeated string allocations and manipulations (`.lower()`) on `PortingModule` properties (like `name`, `source_hint`, `responsibility`) in the inner loop of `_score` causes unnecessary overhead, as these properties are static for a given module. This is specifically highlighted in the context given as a memory hint: "property caching (e.g., using `@functools.cached_property` on `PortingModule` properties like `search_text`) is critical for performance to avoid redundant string allocations and manipulations."
+
+**Action:** Add a `@functools.cached_property` called `search_text` to the `PortingModule` dataclass that precomputes and lowercases the combined searchable fields. Update `_score` in `src/runtime.py` to use this single precomputed string instead of repeatedly building the `haystacks` list and lowering the fields on every token evaluation.
+
 ## 2024-04-09 - Rust String Cloning Optimization
 **Learning:** In Rust, building lists of string parts for joining (e.g., `vec![string1.clone(), string2.clone()].join(" ")`) is a common pattern that can lead to unnecessary heap allocations. This codebase frequently does this when formatting reports. When the source values are already `String`s, borrowing them as `&str` and pushing them to a `Vec<&str>` before calling `.join()` entirely avoids these intermediate heap allocations. Additionally, calling `.to_string()` on static string slices just to appease a `Vec<String>` is wasteful when `Vec<&str>` works perfectly.
 **Action:** When constructing strings from parts using `Vec` and `.join()`, look for opportunities to use a `Vec<&str>` populated with borrowed string slices (`.as_str()`) instead of a `Vec<String>` populated with cloned strings (`.clone()`).