The issue is frontend can be a loaded question, especially if you are dealing with legacy stuff, different frameworks, etc. You also can't tell what the frontend code does by looking at that single line.

Now imagine as part of your analyzer, you have the following instructions for the llm:

--- For all files in `src/frontend/` treat them as frontend code. For all files in 'src/' excluding `src/frontend` treat as backend. Create a metadata called `scope` which can be 'frontend', 'backend' or 'mix' where mix means the code can be used for both front and backend like utilities.

Now for each file, create a `keywords` metadata that includes up to 10 unique keywords that describes the core functionality for the file. ---

So with this you can say

- `!ask find all frontend files`

- `!ask find all mix use files`

- `!ask find all frontend files that does [this]`

and so forth.

The whole point of analyzers is to make it easy for the LLM to map your natural language query to a deterministic search.

If the code base is straightforward and follows a well known framework, asking for frontend or backend wouldn't even need an entry as you can just include in the instructions that I use framework X and the LLM would know what to consider.