feat(query): add project-scoped filtering to Cypher queries for multi-project databases

[vitali87]

Problem

When multiple projects are indexed in the same Memgraph database, Cypher queries return results from all projects without disambiguation. The Cypher system prompt and examples do not mention filtering by project, so LLM-generated queries cannot scope results to a specific project.

This is distinct from #425 (cross-project indexing). That issue is about enabling cross-project retrieval. This issue is about the opposite: ensuring queries can be scoped to a single project when desired.

Current Behavior

A query like "show all classes" returns classes from every indexed project. The user has no way to scope queries to the project they are working on.

Expected Behavior

1. The Cypher system prompt should include the current project name as context
2. Query examples should demonstrate project-scoped patterns (e.g., MATCH (p:Project {name: $project})-[:CONTAINS_PACKAGE*]->...)
3. The query tool should automatically inject the project scope when a single project is being queried

Affected Components

• codebase_rag/prompts.py (CYPHER_SYSTEM_PROMPT, LOCAL_CYPHER_SYSTEM_PROMPT)
• codebase_rag/tools/codebase_query.py (query execution)
• codebase_rag/cypher_queries.py (example queries)

[evander-wang]

I'd like to add a related use case that's worth considering in the design.

Use Case: Discovery Phase Before Project Scoping

There's a chicken-and-egg problem here: sometimes I don't know which project to scope to until I've done an initial cross-project search.

Typical Workflow


1. Discovery Query (no project scope known yet)
   ▎ "Where is the payment processing logic?"
   
   - I need to search across ALL projects to find the entry point
   - Results should include project_name so I can identify which project contains what I'm looking for
2. Follow-up Queries (project scope now known)
   ▎ "In payment-service, show me the order-related classes"
   
   - Now I can scope queries to payment-service for deeper exploration
   
   Two-Phase Search Strategy
   
   This naturally leads to a two-phase approach:
   
3. Phase 1: Global Retrieval - Start with cross-project vector/similarity search to find relevant entry points. No project filtering at this stage since the target project is
   unknown.
4. Phase 2: Graph Traversal - Once the entry point and project_name are identified, subsequent Cypher graph queries can be scoped to that specific project for deeper code
   relationship exploration.
   
   The key insight is: project scope is a product of Phase 1, not a prerequisite for it.
   
   Implications for Implementation
   
   Rather than always injecting project scope, the system should:
   
5. Return project_name in query results by default - This helps users discover which project contains relevant code when they don't know beforehand
6. Let the LLM decide based on user intent - The system prompt should instruct the LLM to:
   - Use project filtering when the user explicitly mentions a project
   - Skip project filtering when the user is doing exploratory/broad searches
   - Include project context in results so follow-up queries can be scoped
7. Make project scoping optional, not mandatory - The current proposal seems to assume users always know their target project. In practice, finding the right project is often part
   of the query process itself.
8. Support the global-to-scoped transition - Ensure that global retrieval results include enough project context to enable scoped graph queries in follow-up interactions.