RFC: headless Web/Server mode (--features server) + Connectors (Google Drive, local folder)

[johnsonafool]

Draft / RFC. This is a large change (≈90 files) and I'd like your steer before polishing it further. If the direction is welcome I can split it into three reviewable PRs (see the end). Everything here is opt-in behind a Cargo feature; the default desktop build is unchanged in behaviour.

What this adds

1. Headless Web / Server mode (--features server)

llm-wiki-server is a Tauri-free binary (axum) that serves the built React frontend over HTTP and answers everything the frontend used to get from Tauri IPC, so a small team can self-host one instance and use LLM Wiki from a browser.

browser ── /web/rpc/{cmd} ──▶ web/rpc.rs → the same command functions
        ◀─ /web/events  (SSE) ── AppCtx::emit
        ── /web/file, /web/upload, /web/proxy (outbound LLM calls), /web/auth/*
tiny_http :19828 local API + :19827 clip server run unchanged

• AppCtx replaces tauri::AppHandle in commands; command bodies are untouched, only the attribute (#[cfg_attr(feature = "desktop", tauri::command)]) and the runtime shim (crate::rt::*) change.
• Frontend: all host calls go through src/lib/backend/ (Tauri on desktop, /web/* in the browser); feature code no longer imports @tauri-apps/* directly. Plugin replacements (store, dialog, http, opener) are listed in plans/web-server-mode.md.
• Auth: one shared password → HttpOnly; SameSite=Lax session cookie (or Authorization: Bearer). No password + loopback bind = open access (same trust model as the desktop); non-loopback bind without a password generates one and prints it.
• Raw filesystem RPC commands are confined to registered project folders and the data dir (same allow-list as /web/file).
• Dockerfile + docker-compose.yml; flags/env documented in plans/web-server-mode.md.

2. Connectors (Settings → Connectors)

Pull documents from external systems into raw/sources/@<name>/ on a schedule; the existing source-folder watcher then ingests them, so nothing downstream knows a connector exists.

• Connector trait (test / list_all(cursor) / fetch), a descriptor registry that drives a generic settings form, a shared SyncEngine (version diff, sanitised paths, atomic writes, deletions, per-instance state), OAuth PKCE helper, minute scheduler.
• Kinds shipped: local-folder (reference implementation) and google-drive (bring-your-own OAuth client, delta sync via changes.list, Docs/Sheets/Slides exported as Office files).
• Design notes in plans/connectors.md.

3. Included fix (also submitted separately)

API / MCP chat now honours taskModelRouting.chatPresetId — see the standalone PR "fix(api): honor the Chat task preset for local API / MCP chat".

Verified

Check	Result
npm run build (typecheck + vite)	✅
vitest	✅ 132 files / 1876 tests
cargo check desktop and server features	✅
cargo test --features server --lib	402 pass; 7 pre-existing Windows-only failures in commands::fs / commands::file_history (e.g. /tmp/... asserted absolute) — untouched by this change
Headless server smoke (login, RPC, file allow-list, upload, proxy, SSE, connectors, search, logout)	✅ 17/17
Desktop release build from this branch, run on Windows	✅
Browser end-to-end (login → create project → import → ingest → chat with SSE)	✅ manually, Chromium

Not verified by me: macOS / Linux builds (CI should tell), long soak of ingest through /web/proxy.

Known gaps

• Ingest still runs in the browser tab (as on desktop); closing the tab pauses it.
• Trust model is one shared password; /web/proxy lets an authenticated user reach any URL from the server (documented; the desktop already allows pointing the app at any endpoint). TLS should sit in front for anything beyond a LAN.
• Folder-import UX in the browser is upload-based; see "Known gaps / next milestones" in plans/web-server-mode.md.

Proposed split, if you'd like to take this

1. AppCtx + rt host abstraction (mechanical, no behaviour change) — makes the rest possible and small to review.
2. Web/Server mode behind the server feature.
3. Connectors.

Happy to rebase, rename, or drop parts. Thanks for building LLM Wiki — we're using it as the engine for a team knowledge base and wanted to give this back.