Lavern · Explore

Clawern on Windows

Do we need the heavy local Clawern daemon on Windows, or is a small uploader plus server-side processing the right shape? Short answer: the daemon was never on Windows to begin with, and a thin client + the Azure pipeline is the correct architecture for a Windows firm.

The premise: there's nothing to port

Clawern's rich local experience does not run on Windows today. daemon-factory.ts is explicit:

throw new Error(
  `Daemon mode is not supported on ${process.platform}. ` +
  `Use manual mode: lavern --serve --claw`
);

• macOS → launchd LaunchAgent (daemon.ts)
• Linux → systemd user service (daemon-systemd.ts)
• Windows → unsupported; foreground manual mode only
• Menu bar app (menubar/) → macOS SwiftUI, no Windows equivalent

So on Windows there is no background daemon, no tray surface, no set-and-forget watcher. The question isn't "should we keep the Windows Clawern?" — there isn't one. It's "what should the Windows experience be?"

The principle

Separate the Clawern function from the Clawern implementation.

• Function — drop a document, get an analysed, cited, audited bundle back. This is valuable and worth keeping on every platform.
• Implementation — background daemon, menu bar, local filesystem watch, local Ollama, on-device precedent board. This is a macOS / Linux privacy story. It does not fit a Windows firm that is already on M365, Entra ID, and Azure.

On Windows, keep the function. Move the implementation to the server — which is the Azure pipeline we already designed.

Three thin-client shapes

Option	What it is	Effort	When
A. No local component	Just the web dashboard. Drag a file into the browser → engagement runs server-side.	Zero — exists	Most Windows firm users. The simplest answer.
B. Cowork mode	The viz/src/cowork/ File System Access API path — the browser reads and writes a local folder while the tab is open. A thin uploader that already ships.	Zero — exists	Users who want folder-level work without an install. Chromium-only; tab must stay open.
C. Tiny tray uploader	A genuinely small background agent: watch a folder, push new files to Blob via SAS, done. No analysis, no state, no model. The "drop and forget" feel, brain in Azure.	Small — ~1 week	Customers who want the set-and-forget retainer experience on Windows.

Recommendation

1. Ship A and B now. They already work, need no install, and cover the majority of Windows users. A Windows firm dragging a contract into the dashboard is the whole interaction.
2. Build C only on demand. If customers ask for the folder-watch retainer experience, build a true ~200-line uploader — watch + SAS upload — registered as a Windows Scheduled Task or a minimal service. A single Go or Node binary. Resist re-implementing the daemon, menu bar, Telegram bot, and precedent board on the client; all of that lives server-side now.

How option C wires into the lean Azure pipeline

The uploader is just the ingestion mouth of the pipeline already specified in the Azure migration doc. It does one job and stops.

Windows folder (watched)
        │  new file appears
        ▼
Tiny uploader  ──①── request user-delegation SAS from lavern-api
        │
        └────②── PUT file → Blob container  lavern-uploads/<user>/<dropId>/
                          │
                          ③ Event Grid: BlobCreated
                          ▼
                 Service Bus  →  Azure Function (analysis/ingest)
                          │            (parse · SMAC-L1 sanitise ·
                          │             anonymise · dispatch workflow)
                          ▼
                 lavern-worker (Container Apps, KEDA)
                          │  runs the engagement
                          ▼
                 Deliverable + audit bundle → Blob  lavern-deliveries/
                          │
                          ④ notify (email / dashboard / webhook)

Everything from step ③ onward is the same code path the dashboard and KB use. The uploader contributes only steps ① and ②. No Clawern runtime on the client at all — the processor, curator, and precedent board all run server-side.

The one real cost

The heavy local Clawern exists for a single promise: your documents never leave your machine — local Ollama, anonymise-before-escalate, on-device state. Thin-client + server gives that up. Documents go to Azure.

Two mitigations keep most of the value:

• Sanitise and anonymise server-side. The SMAC-L1 defence in sanitize-text.ts and the reversible anonymiser in anonymize.ts both run inside the ingest Function. You keep the injection defence and can still redact before any frontier call.
• Build local-only as a funded exception. If a specific customer demands true on-device processing on Windows, that is when you build a Windows Service + local model path — deliberately, not on spec. It becomes a privacy-tier feature, not the Windows default.

What this means for the roadmap

Surface	Windows default	Built only on demand
Interactive review	Web dashboard (A) / Cowork (B)	—
Set-and-forget retainer	Tray uploader (C) → Azure pipeline	—
Strict local-only	Not offered	Windows Service + local model
macOS / Linux	Full local Clawern (daemon, menu bar)	—

Net: on Windows you carry the local daemon as a privacy-tier exception, not as the default. The cloud pipeline is the natural home, and you avoid porting the daemon, menu bar app, and on-device pipeline to a platform that didn't have them.