sunkai174634
## Bug Description When `POST /api/v1/search/search` is called with `context_type: "memory"` and a `session_id`, the query planner can classify the generated query as `resource`. The request then returns no memory results even though the same query is present in the memory index and succeeds through `/api/v1/search/find` with the same `context_type`. This makes an explicitly memory-scoped session-aware search silently return zero results because the planner output overrides the caller's requested context scope. ## Environment - OpenViking: `v0.4.22` - Query planner: OpenAI-compatible API with a local intent-analysis model - Retrieval backend: cosine-style vector search, 1024-dimensional embeddings - Client: REST API / CLI session-aware search ## Steps to Reproduce 1. Create a temporary OpenViking session. 2. Add a user message asking to retrieve a known historical memory, for example: ```text Retrieve the historical records about the OpenViking update, compatibility cleanup, and vector rebuild. ``` 3. Call session-aware search with an explicit memory scope: ```json { "query": "Retrieve the historical records about the OpenViking update, compatibility cleanup, and vector rebuild.", "session_id": "<temporary-session-id>", "context_type": "memory", "limit": 5, "score_threshold": 0 } ``` 4. Inspect the generated query plan and the result. ## Actual Behavior The query planner returns a valid JSON plan, but one or more generated queries contain: ```json { "context_type": "resource" } ``` The final response contains zero results under the explicitly requested memory scope: ```text total results = 0 ``` The observed planner latency was approximately 1-2 seconds. This is not a service, index, or embedding failure: the vector index was consistent and direct memory retrieval worked. ## Expected Behavior When the caller supplies a single context type such as `context_type: "memory"`, every generated query should remain constrained to that type. The planner should not be allowed to change it to `resource` or `skill`. For a single-type request, the server should either: - inject the requested type as a hard constraint into the planner prompt and validate the output, or - normalize/reject planner outputs whose `context_type` differs from the request, or - bypass intent planning and perform a direct scoped retrieval, equivalent to `/api/v1/search/find`. For a multi-type request, planner-selected types may remain valid if they are restricted to the requested set. ## Additional Observations - Greetings correctly produce an empty query plan. - Resource-only requests are classified as `resource` as expected. - Mixed memory/resource requests tend to be biased toward `resource`, and can omit the memory query. - Switching between the bundled v4/v7 prompt mappings did not reliably fix the classification for this local intent-analysis model. - A client-side workaround is to use `/api/v1/search/find` whenever the recall scope is strictly `memory`; however, the server should preserve the caller's explicit scope in `/search/search` as well. ## Proposed Fix Treat a single-value `context_type` request as an authoritative scope throughout the session-aware search pipeline. After planner output parsing, validate each generated query against the requested scope and either normalize it to the requested type or discard/replan invalid entries. This would prevent valid memory searches from becoming silent zero-result resource searches.