api/v1/search/find: FindRequest has no mode field, client mode parameter silently dropped

[pty819]

/api/v1/search/find has no mode parameter despite being documented in client tool schemas

Problem

The Hermes Agent OpenViking plugin exposes a viking_search tool with a mode parameter ({type: "string", enum: ["auto", "fast", "deep"]}) and sends it to the server's /api/v1/search/find endpoint. However, the server's FindRequest Pydantic model has no mode field, so the parameter is silently dropped by Pydantic's default extra='ignore' behavior.

Relevant code

Server-side — server/routers/search.py:FindRequest:

class FindRequest(BaseModel):
    query: str
    target_uri: Union[str, List[str]] = ""
    limit: int = 10
    node_limit: Optional[int] = None
    score_threshold: Optional[float] = None
    filter: Optional[Dict[str, Any]] = None
    include_provenance: bool = False
    since: Optional[str] = None
    until: Optional[str] = None
    time_field: Optional[TimeField] = None
    level: Optional[Union[int, str, List[int]]] = None
    telemetry: TelemetryRequest = False
    # ⚠️ No `mode` field

Client-side (Hermes Agent plugin) sends mode:

mode = args.get("mode", "auto")
if mode != "auto":
    payload["mode"] = mode

What actually controls search behavior

The HierarchicalRetriever has an internal mode parameter (RetrieverMode.THINKING / RetrieverMode.QUICK) that controls whether rerank is applied, but:

1. VikingFS.find() calls retriever.retrieve() without passing mode, so it always defaults to RetrieverMode.THINKING (with rerank if configured)
2. The server FindRequest model has no mode field, so there's no HTTP API surface for clients to switch between thinking/quick mode
3. Rerank is purely server-side controlled by the [rerank] section in ov.conf

Suggested fix

Either:

1. Add a mode field to FindRequest and pass it through to the retriever, so clients can choose between thinking (vector + rerank) and quick (vector only) mode per-request — useful for use cases where rerank is too expensive for background/prefetch queries but desired for explicit user searches.

2. Or remove the mode parameter from client-facing documentation/schemas if the server should always use its configured default, to avoid confusion for integrators who expect it to work.

Note: The SearchRequest model (for /api/v1/search/search) also lacks a mode field, though the /search endpoint is a separate endpoint.