Three problems surfaced when driving search_kb / read_chunk through a
real DeepSeek chat for the first time:
1. vite.config.ts: minisearch wasn't in `aliasedDeps`, so when
@crema/lexical-rag-ui imports it, Vite couldn't resolve the bare
specifier from the sibling lib's location. Added it next to the
other shared deps. tsconfig paths alone is not enough — the Vite
alias is what propagates resolution to sibling-lib code.
2. ai.tsx reindexKB: was using `toast.show?.()` which doesn't exist on
useToast()'s API. Optional chaining silently no-op'd, so the button
click ran the fetch but produced zero UI feedback (success or
failure). Switched to the actual API: toast.info / toast.success /
toast.error. Added a console.error in the catch arm so the
underlying exception is visible in DevTools when something does go
wrong.
3. ai.tsx MAX_TOOL_ITERATIONS: cap was 3, which is too tight for
agentic search→read→search loops on real questions. Bumped to 6.
More importantly, when the cap IS reached, the runner now
synthesises tool-error messages for each pending tool_call and
continues the chat — instead of silently dropping them, which left
the conversation with an assistant.tool_calls turn but no matching
tool messages. DeepSeek (and the OpenAI spec) reject that
conversation with 400 ("insufficient tool messages following
tool_calls"), poisoning the thread. Now the model gets a clean
"max iterations reached" signal and produces a final answer.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
628691d2df