Skip to content

find --fuzzy: minor review follow-ups (post-miss hint, tier-coverage tests) #421

Description

@HumanBean17

Tracking the low-value nits deliberately deferred from the #413 review, so they're not lost. All minor — bundle into one polish sweep.

1. Weak next-action after a true fuzzy miss (UX)

src/java_codebase_rag/jrag.py, the empty-result branch of _cmd_find_query_mode.

After --fuzzy genuinely finds nothing (exact + prefix + contains all empty), the suggested next action is jrag find --fqn-contains <query>. But fuzzy contains already searched s.name CONTAINS $needle OR s.fqn CONTAINS $needle; --fqn-contains is FQN-substring only — a strict subset of what fuzzy already tried. So the suggestion is a near-dead-end.

Suggestion: point at semantic search instead — jrag search <query> — which is genuinely a different (meaning-based) retrieval and more likely to help when the identifier doesn't match at all.

2. No test proves prefix and contains are distinct tiers

tests/graph/test_ladybug_queries.py. Each mode is tested independently, but no single test asserts a needle that prefix-misses yet contains-hits (e.g. prefix("Management") == [] and contains("Management") != []). Low impact — STARTS WITH vs CONTAINS are trivially distinct — but it would make the contract crisp. Defense-in-depth.

3. CLI fallback's contains tier never reached end-to-end

tests/package/test_jrag_locate.py. Test 15's needle ChatManag matches at the prefix tier (ChatManagementService), so the CLI fallback chain stops before contains. A needle like Management (no name starts with it, but ChatManagementService contains it) would exercise the contains tier through the CLI. The backend contains test covers the mode directly, so this is defense-in-depth only.

Related

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions