⚡ Bolt: Add fast early-exit bitflags for path fuzzy matching

[AhmmedSamier]

💡 What: Adds a new parallel array itemPathBitflags to the SearchEngine to track bitflags specifically for the relativeFilePath property. This allows for an $O(1)$ early-exit check in tryFuzzyMatchPath before invoking expensive Fuzzysort.single() calculations.
🎯 Why: Previously, if an item passed the aggregate itemBitflags check, the fallback search path would eventually call tryFuzzyMatchPath. However, the required query characters might have only existed in the name or fullName properties. This resulted in wasted CPU cycles running the Fuzzysort algorithm on path strings that had zero chance of matching.
📊 Impact: Reduces redundant string evaluations during the fallback phases of fuzzy search, leading to faster response times, especially for queries that closely match item names but not their paths.
🔬 Measurement: Search queries triggering the path fallback match will complete faster due to the bypass. Verified via unit tests ensuring identical results and correct array lifecycle management.

---

PR created automatically by Jules for task 15537001597443492960 started by @AhmmedSamier

Summary by CodeRabbit

• Bug Fixes

  • Improved fuzzy path matching so results can now skip unnecessary work when the path clearly can’t match, making searches faster and more responsive.
  • Kept search results consistent during item updates, additions, removals, and clearing.

• Documentation

  • Added a note about fuzzy path matching checks to the project documentation.

[google-labs-jules]

👋 Jules, reporting for duty! I'm here to lend a hand with this pull request.

When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down.

I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job!

For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with @jules. You can find this option in the Pull Request section of your global Jules UI settings. You can always switch back!

New to Jules? Learn more at jules.google/docs.

---

For security, I will only act on instructions from the user who triggered this task.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[coderabbitai]

📝 Walkthrough

Walkthrough

Adds a new itemPathBitflags parallel Uint32Array to SearchEngine, computed from each item's relativeFilePath. All index-maintenance paths (setItems, addItems, truncateArrays, moveItem, clear, getCacheSize) are updated to keep it consistent. tryFuzzyMatchPath gains an O(1) bitflag containment early-exit before calling Fuzzysort.single. A changelog note is added to .jules/bolt.md.

Changes

itemPathBitflags early-exit for tryFuzzyMatchPath

Layer / File(s)	Summary
computeItemBitflags and prepareItemAtIndex: pathFlags language-server/src/core/search-engine.ts	computeItemBitflags return shape gains pathFlags derived from relativeFilePath, OR'd into aggregate flags; prepareItemAtIndex stores the result into itemPathBitflags.
itemPathBitflags field and index-maintenance language-server/src/core/search-engine.ts	Declares the itemPathBitflags Uint32Array field and keeps it aligned in setItems, addItems, truncateArrays, moveItem, clear, and getCacheSize.
prepareSearchContext wiring and tryFuzzyMatchPath early-exit language-server/src/core/search-engine.ts	prepareSearchContext passes itemPathBitflags into the per-search context; tryFuzzyMatchPath uses it for an O(1) bitflag containment check before invoking Fuzzysort.single.
Changelog note .jules/bolt.md	Documents that path fuzzy-match properties lacked bitflag early-exit checks and states the requirement to include them for all fuzzy-matched properties.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related PRs

• AhmmedSamier/DeepLens#503: Applies the same pattern to tryFuzzyMatchName using a parallel per-item bitflag array, directly analogous to this PR's tryFuzzyMatchPath change.
• AhmmedSamier/DeepLens#519: Adds a parallel per-item bitflag array for fullName and uses it for an O(1) early-exit in the corresponding tryFuzzyMatch* function, same structural approach.
• AhmmedSamier/DeepLens#521: Extends computeItemBitflags/prepareSearchContext with per-property bitflag arrays and early-exit logic in tryFuzzyMatch* for fullName vs relativeFilePath.

Suggested labels

codex

🐇 A path once checked the long, slow way,
Now bits stand guard to save the day!
With pathFlags set and checked at speed,
Fuzzysort skips what can't proceed.
Early exit, hooray! ✨

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly summarizes the main change: adding fast early-exit bitflags for path fuzzy matching.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch bolt/path-bitflag-early-exit-15537001597443492960

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (1)

.jules/bolt.md (1)

99-99: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value

Consider consistent heading format for changelog entries.

Previous entries use bracketed Title Case (e.g., [Fast Name Property Early-Exit], [O(1) FullName Property Early-Exit in Fuzzy Match]). Consider aligning this entry to ## 2026-06-29 - [Path Fuzzy Match Early-Exit] for consistency.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.jules/bolt.md at line 99, The changelog entry heading is inconsistent with
the surrounding Title Case bracketed format used in previous entries. Update the
heading in the markdown entry for the relevant changelog section so it follows
the same pattern as the existing headings, using the title-cased bracketed form
and keeping the date prefix unchanged.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In @.jules/bolt.md:
- Around line 99-101: The changelog entry in the markdown section is out of
chronological order; move the `2026-06-29` item so it appears before the
`2026-08-01` entry. Update the ordering within the same changelog list and keep
the existing entry text intact, using the nearby heading and dated entries to
locate the affected section.

---

Nitpick comments:
In @.jules/bolt.md:
- Line 99: The changelog entry heading is inconsistent with the surrounding
Title Case bracketed format used in previous entries. Update the heading in the
markdown entry for the relevant changelog section so it follows the same pattern
as the existing headings, using the title-cased bracketed form and keeping the
date prefix unchanged.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 9ef6d88a-ccf8-4f8b-978a-82e4f740669a

📥 Commits

Reviewing files that changed from the base of the PR and between 124aa21 and e7dcd05.

📒 Files selected for processing (2)

• .jules/bolt.md
• language-server/src/core/search-engine.ts

[coderabbitai]

📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win

Fix chronological ordering of changelog entry.

The date 2026-06-29 is out of order. It should appear before the 2026-08-01 entry to maintain chronological sequence.

🧰 Tools

🪛 LanguageTool

[grammar] ~100-~100: Ensure spelling is correct
Context: ...Path properties were missing early-exit bitflag checks. Action: Always verify all f...

(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.jules/bolt.md around lines 99 - 101, The changelog entry in the markdown
section is out of chronological order; move the `2026-06-29` item so it appears
before the `2026-08-01` entry. Update the ordering within the same changelog
list and keep the existing entry text intact, using the nearby heading and dated
entries to locate the affected section.