[Bug] Code navigation excludes Java packages containing vendor, causing empty References

[buptwlh]

What happened?

Summary

Cmd/Ctrl+click opens the References panel, but it reports "No results" for symbols in first-party Java source files whose package path contains a directory named vendor (for example, src/main/java/com/example/vendor/app/).

The local checkout exists, ripgrep is installed and available to the review process, and ordinary ripgrep searches find the symbols. The cause is the unconditional --glob !vendor exclusion used by code navigation, not a missing Java language server or a restriction to changed files.

Steps to reproduce in Plannotator

1. Use a local Java repository containing first-party source under a package such as com.example.vendor.app.
2. Make a change to a class or method in that package and start a local plannotator review.
3. Cmd/Ctrl+click a class or method identifier in the diff.

Expected: Search-based navigation should find matching definitions/references in the first-party source, whether or not the target file was changed.

Actual: The References panel opens but reports "No results". The entire package subtree is excluded from the search.

Minimal reproduction of the underlying search bug

This uses synthetic source only and does not require an IDE or Java build:

repro_dir="$(mktemp -d)"
cd "$repro_dir"
mkdir -p src/main/java/com/example/vendor/app
cat > src/main/java/com/example/vendor/app/ExampleService.java <<'JAVA'
package com.example.vendor.app;

public class ExampleService {
    public String fetchContent() { return "example"; }
}
JAVA

rg -n --type java --glob '!vendor' --word-regexp -- fetchContent .
printf "exit_code=%s\n" "$?"

rg -n --type java --word-regexp -- fetchContent .
printf "exit_code=%s\n" "$?"

The first search prints no matches and exits with code 1. The second finds ExampleService.java:4 and exits with code 0. I verified this with ripgrep 15.2.0.

Root cause and diagnostic evidence

In packages/shared/code-nav.ts at v0.27.15, CODE_NAV_IGNORED_GLOBS includes vendor, and buildRgArgs() turns it into --glob !vendor. Because this is an unanchored directory-name exclusion, it prunes a directory called vendor at any depth, including a valid Java package segment.

In the affected local review:

• The running review process had the correct repository working directory and /opt/homebrew/bin on PATH.
• POST /api/code-nav/resolve returned HTTP 200 with backend: "search", complete: true, and empty definitions and references.
• Replaying the full navigation ripgrep arguments in that same directory produced 0 matches.
• Removing only the !vendor exclusion, keeping all other arguments unchanged, produced 7 matches across 3 files, including the interface and implementation.

This rules out missing ripgrep, Java file-type filtering, and absence of the target source. The source paths and identifiers here are anonymized; no private project code is attached.

Possible fix / regression coverage

• Avoid treating every directory named vendor as third-party dependencies regardless of source-root/package context, or provide an explicit way to override the navigation exclusions.
• Add a regression test proving that an ordinary Java source path such as src/main/java/com/example/vendor/app/ExampleService.java remains searchable while intended dependency directories can still be excluded.
• Other bare directory-name exclusions may deserve the same check when they overlap with legitimate package names.

This is a correctness issue in the existing ripgrep-based navigation introduced in #694 / #711; it does not require full LSP-based Java implementation resolution.

Additional environment details

• macOS, Apple Silicon
• ripgrep 15.2.0 installed through Homebrew
• Codex via ChatGPT desktop; local Git review
• Observed with plannotator review --git --base origin/master --diff-type since-base --json

Plannotator version

plannotator 0.27.15

OS

macOS

Agent

Codex

Where did it happen?

Code review

[backnotprop]

Thanks for such a precise report. The minimal rg repro made this a five-minute diagnosis. You're exactly right: a ripgrep glob with no slash matches a path segment at any depth, so --glob !vendor was pruning your whole package subtree.

#1559 splits the list. Names that can only be tool output (node_modules, .git, .next, __pycache__, .turbo, .cache, .venv, .pytest_cache) stay excluded at any depth. The ambiguous ones (vendor, target, build, dist, coverage) are now excluded only at the search root, since ripgrep's default .gitignore handling already covers nested directories that are genuinely build output. As belt and braces, a segment the file you clicked from lives under is never excluded for that request. The regression tests use the exact src/main/java/com/example/vendor/app/ shape from your report.

Merged in #1559 and it will go out in the next release. Thanks again.