Ollama local inference added; Supabase client refactored to pass user JWT for RLS enforcement
The two most importable commits in this fork. One adds a clean Ollama streaming client to the TS LLM layer. The other closes a tenant-isolation gap by threading the request JWT through every Supabase call so Row Level Security actually applies.
86f1ef0 adds backend/src/lib/llm/ollama.ts: a streaming client that POSTs to OLLAMA_URL (default http://127.0.0.1:11434) on /api/chat, registered in the LLM index and models map. Standard Ollama chat format, nothing unusual. The same commit refactors createServerSupabase in supabase.ts to accept an optional token argument - when present, it constructs the client with the anon key and Authorization: Bearer <token>, relying on Supabase's RLS to scope the queries to that user. Without a token, it falls back to the service-role key (which bypasses RLS). It also extracts ~368 lines of system prompt and schema constants out of chatTools.ts into a new systemContext.ts.
0a309b61 threads the token through every route. Before this commit, createServerSupabase() was called without arguments throughout chat.ts, documents.ts, downloads.ts, projects.ts, tabular.ts, user.ts, and workflows.ts - all running under the service-role key, bypassing RLS entirely. After, each call becomes createServerSupabase(res.locals.token as string). It also extracts extractPdfText and generateDocx from chatTools.ts into a new parsers.ts.
Two things to verify before adopting. First, the service-role fallback still exists: any route that calls createServerSupabase() without passing the token will silently bypass RLS. Check that no path was missed. Second, the chatTools.ts → systemContext.ts/parsers.ts extraction is a large code movement that will conflict with upstream merges. Diff carefully to confirm it's a pure move with no behavioral changes.
Spotted something wrong? Or know the PR text has fresher detail than the writeup above?