CW-043 · A provider an operator can run themselves

Priority P1 · Area assistant · Estimate M · Phase 3

#37 was asked to choose between telling the truth about ASSISTANT_PROVIDER and making it true. The decision was make it true; what shipped was the truth-telling half — the names with no implementation are gone, a deployment that reports an assistant must now have one, and llm-provider.ts says plainly that it is a seam rather than a capability.

That work is right and it is finished. The gap is mine: I changed the decision in a comment and in the backlog prose, and left the acceptance criteria describing the option I had rejected. The criteria were met exactly as written. A decision that does not reach the acceptance criteria has not been made, so this is the remaining half with criteria of its own rather than a reopened ticket.

It matters more now than when the decision was taken. #38 and #39 have shipped, so a team's attendance and a payroll run's figures now pass through a model. An organisation that cannot send those to a third party can use none of it — and spec.md § Agreed direction states that self-hosting the model is a requirement, not a convenience.

llm-provider.ts points at CW-018 (#16) for this. That is the wrong home: CW-018 is embeddings for knowledge search, a different call to a different kind of model. Chat and embeddings should not share a ticket.

Scope

• An OpenAiCompatibleProvider implementing LlmProvider: base URL, optional API key (a local server often needs none), and the tool-calling contract the interface already defines.
• ASSISTANT_PROVIDER accepts the name only once it exists — the rule #37 set.
• Documented against at least one local runtime end to end, so the claim is demonstrated rather than asserted.

Acceptance

• With a local OpenAI-compatible server, the assistant answers a policy question and completes a tool call, with no request leaving the host.
• Every guardrail holds identically: no tool takes an employee id, write actions still need confirmed: true, tool calls are audited.
• Switching provider needs no code change beyond configuration.

Files backend/src/modules/assistant/providers/, backend/src/core/config/, docs/ai-assistant.md

Start by reading the existing LlmProvider contract and backend/src/modules/assistant/providers/, then inspect the related configuration in backend/src/core/config/. Implement and document the provider so a local OpenAI-compatible server can answer a policy question and complete a tool call without changing code, while preserving the stated guardrails; update docs/ai-assistant.md with the end-to-end local-runtime evidence.