tapir/docs/homelab-integration.md

# Tapir — Homelab Integration Facts

The concrete endpoints, conventions, and identifiers Tapir depends on, so an independent
session doesn't have to rediscover them. **Verify anything marked "confirm" before relying on
it** — endpoints and aliases drift, and this file is a snapshot (2026-06-02), not a live source.

## Local AI (the Primary in `llm.Router`)

- **LiteLLM gateway:** OpenAI-compatible, lives in k3s namespace `ai-stack` (verified 2026-06-02
  from koala via `kubectl get svc -n ai-stack`):
  - **In-cluster:** `http://litellm.ai-stack.svc.cluster.local:4000/v1/` (ClusterIP `10.43.159.89:4000`).
  - **Off-cluster (host / NodePort):** `http://koala:30401/v1/` — service `litellm-nodeport` (`4000:30401`).
  - NOTE: the earlier `31234` was **wrong** — `31234` is the `llama-swap` NodePort (`8080:31234`),
    not LiteLLM. Use `30401` for off-cluster LiteLLM. `confirm` resolved.
- **Auth key:** treat as a secret via the SecretStore port; do not hardcode in committed code.
  NOTE: the documented `sk-local-123` returned `401` on `30401/v1/models` (2026-06-02) — it is
  stale or the gateway now enforces the `LITELLM_MASTER_KEY` (1Password `op://HomeLab/LITELLM_MASTER_KEY`).
  Resolve the live key from the vault when wiring; `sk-local-123` is no longer valid. `confirm` partially resolved.
- **Model alias format:** `host/name`, e.g. `koala/qwen3-coder-30b`, `koala/phi4-mini`,
  `iguana/devstral`, `iguana/deepseek-r1-14b`. **Not** the `ollama/` prefix form.
- **Which alias for summarization:** alias-as-config, **`confirm` resolved** (2026-06-02, Worker F).
  The alias is never hardcoded: it is `TAPIR_SUMMARIZER_MODEL` (format `host/name`), wired through
  the summarizer's `Endpoint.Model`. **Default: `koala/phi4-mini`** — a non-thinking instruct model
  chosen for safety: it cannot fall into the empty-content trap below, so the demo summarizes even
  if no one tunes it. It is provisional and overridable; **final live alias selection happens at
  demo time when the gateway is reachable**, where a more capable model (e.g.
  `iguana/deepseek-r1-14b`) is preferred for summary quality if its latency/output is acceptable.
  The `max_tokens` fix below means thinking models no longer return empty content, so they are now
  viable choices, not blocked ones. Do not assume a coder alias is right for prose.
- **Thinking models need an explicit `max_tokens`.** qwen3 / deepseek-r1 spend the budget on
  reasoning and return **empty content** if `max_tokens` is too low (or unset). The summarizer's
  parser treats an empty summary as an error for exactly this reason. **Done (2026-06-02, Worker F):**
  the copied `llm.Client` now sends a generous `max_tokens` (8192) on every request per ADR-004, so
  thinking models no longer return empty content. A non-thinking instruct model remains the safe
  default (`koala/phi4-mini`), but thinking aliases are now viable.

This maps directly onto the copied `llm` package: `Client` is the OpenAI-compatible caller,
`Router.Primary` points at this gateway with a chosen alias, `Router.Fallback` is the user's BYO.

## BYO AI (the Fallback in `llm.Router`)

- Per-user, opt-in: Anthropic / OpenAI / Gemini. All reachable as OpenAI-compatible or via a thin
  adapter. The user's key is stored only as a secret reference (data-model `AI_CREDENTIAL`).
- Used **only** when Primary fails and the user has configured a provider (see
  `docs/use-cases/ai_routing.feature`). With no BYO, work is queued for retry — content is never
  sent externally.

## Brain sink (optional delivery target)

- Reached via **brain-mcp** over HTTP, calling the `brain_ingest` tool (ADR-005). Do **not** use
  the filesystem `brain` package from `hyperguild/ingestion`.
- **brain-mcp base URL:** **confirm** — not pinned in this snapshot. The homelab convention is
  `*-mcp.d-ma.be` ingress hostnames (e.g. `git-mcp.d-ma.be`, `brain-mcp.d-ma.be` is the likely
  form), but verify before wiring.
- brain distinguishes `knowledge/` (session-derived) from `wiki/` (stable, manually promoted).
  Tapir summaries are session-derived signal → `knowledge/`-style ingestion. `brain_ingest` runs
  the LLM extraction pipeline; there is a raw-ingest path (`brain_ingest_raw`) and a reliable
  `brain_write` fallback when the local extraction model is unavailable — relevant if ingestion
  reliability becomes an issue.

## Auth / identity (Stage 1+, dormant at Stage 0)

- **Dex** (`auth.d-ma.be`) is the homelab OIDC provider. When Tapir needs real user identity
  (Stage 1, Future B), it authenticates via Dex — not a new auth system (ADR-002).
- If Tapir ever exposes an MCP surface, use the **`mcp-chassis`** shared Go library
  (`gitea.d-ma.be/mathias/mcp-chassis`) for the Dex-JWT validator + Bearer middleware + RFC 9728
  metadata, rather than hand-rolling it.

## Secrets (OAuth tokens + BYO keys)

- Convention: **ESO + 1Password** (the homelab's External Secrets Operator against a 1Password
  vault). Tables store only an opaque `*_secret_ref`; the secret material lives in the vault and
  is surfaced to the workload via ESO.
- **Exact ref format / vault item naming for Tapir:** **confirm / decide during build.** Follow
  the pattern existing services use (e.g. how `gitea-mcp` references `GITEA_MCP_DEFAULT_TOKEN`)
  rather than inventing a new scheme.
  - **Adapter status (YouTube):** the YouTube `VideoSource` adapter does **not** assume a scheme.
    The OAuth refresh-token reference is an opaque `Config.TokenSecretRef` resolved through the
    `SecretStore` port (`youtube.New(cfg, secrets)`). Pinning the actual vault-item name only
    changes wiring/config, not the adapter — so this `confirm` does not block the adapter. Decide
    the name when wiring the live connection and record it here.
  - **Per-user token-ref scheme (Stage 1 web connect):** the web connect flow
    (`/oauth/youtube/connect` → `/oauth/youtube/callback`) persists each user's refresh token
    under a **per-user ref `youtube/<userID>/refresh_token`** (`web.YouTubeTokenRef`), not the
    Stage-0 single `youtube/refresh_token`. This is what keeps tokens isolated across tenants
    behind the `SecretStore` port; the `video_connections` row stores only this opaque
    `token_ref`, never the token. The connect callback URL is
    `TAPIR_YT_CONNECT_REDIRECT_URL` (default `https://tapir.d-ma.be/oauth/youtube/callback`) and
    must be in the Google OAuth client's authorized redirects for live connect.

## Hosts (for reference)

- **koala** — Arch, RTX 5070, k3s single-node, Gitea, GPU inference. Where Tapir most likely runs
  and where the local models live.
- **iguana** — Mac Studio M2 Ultra, ollama + mlx-whisper, also serves models via the gateway.
- **piguard** — Pi, NPM perimeter (public HTTPS edge). Note: the May-2026 architecture review has
  LiteLLM relocating from piguard into k3s/ai-stack on koala — **confirm current location** if
  latency or endpoint matters.

## Network egress the build and runtime assume

If the koala act_runner (or a dev environment) has locked-down egress, these must be reachable
or the build/run fails. Split into build-time and runtime because they're different lists and
fail at different stages.

### Build-time (CI `check`/`build`, and local `go`/`task` work)

- `proxy.golang.org`, `sum.golang.org` — Go module proxy + checksum DB. The default `GOPROXY`.
  If a homelab GOPROXY (e.g. Athens) exists, point `GOPROXY` at it and this pair is not needed
  directly — **confirm** whether one is run.
- `go.dev`, `dl.google.com` — Go toolchain download (the CI `setup-go` step / `go-version-file`).
  Not needed if the runner already has the matching Go installed.
- `raw.githubusercontent.com` — the CI installs golangci-lint via its install script from here
  (`.gitea/workflows/ci.yml`).
- `github.com`, `codeload.github.com` — any module not served by the proxy (incl. golangci-lint
  and, later, `golang.org/x/oauth2` and its deps) is fetched from GitHub.
- `objects.githubusercontent.com` — GitHub release asset downloads (some installers redirect here).

A configured `GOPROXY` collapses most of the module-fetch entries into one host. Recording the
homelab's actual `GOPROXY`/`GONOSUMCHECK` policy here once known would remove the **confirm**.

### Runtime (the running service)

- `koala:4000` (or the NodePort / post-relocation address) — LiteLLM gateway, the Primary.
- brain-mcp host (`*-mcp.d-ma.be`, **confirm**) — only when the brain sink is enabled.
- `www.googleapis.com` / YouTube Data API + `oauth2.googleapis.com` (token exchange/refresh) —
  the YouTube provider adapter (`internal/adapters/youtube`). OAuth is hand-rolled on
  `golang.org/x/oauth2` (ADR-006); the Google token endpoint is hardcoded inline to avoid the
  heavy `golang.org/x/oauth2/google` dependency.
  - **`confirm` — captions.download ownership limitation.** The Data API `captions.download`
    endpoint only authorizes the *owner* of the video; for arbitrary subscribed channels it
    typically returns `403`. The adapter lists tracks via `captions.list` (no track → `SourceNone`,
    ADR-007) and downloads the selected track as WebVTT; a download failure surfaces as an error
    (retryable), not a silent skip. If the owner-only limit proves blocking in practice, the
    fallback is the unofficial `timedtext` endpoint or the deferred STT path (ADR-007) — a new
    ADR, not a default. Verify against a real non-owned video before relying on live caption
    download.
- `api.vimeo.com` — the Vimeo provider adapter.
- BYO-AI endpoints, per configured provider and **only when a user opts in**:
  `api.anthropic.com`, `api.openai.com`, `generativelanguage.googleapis.com`.
- 1Password / ESO reach for secret resolution follows the homelab's existing ESO egress, not
  Tapir-specific — no new rule expected.

Note: a user with **no** BYO configured means the service never needs the third-party AI hosts
(the local-first guarantee, `docs/use-cases/ai_routing.feature`). Don't allow them by default;
allow per-provider when a user connects one.

> The claude.ai chat sandbox (where planning sessions run code) has its **own** separate egress
> allowlist — unrelated to koala. It blocked `go.dev` during scaffolding, which is why the
> scaffold was reviewed but not compile-verified in-chat; verification belongs on koala via
> `task check` regardless.

## Deployment / GitOps (when Tapir reaches deploy)

- The homelab is **Flux GitOps**: manifests in `mathias/infra` under `k3s/`, Flux watches `main`.
- Tapir's k3s manifests will live in `infra/k3s/apps/tapir/` (by convention) — not in this repo.
  This repo is the application; `infra` is the deployment source of truth.
- Multi-tenancy primitives (NetworkPolicy per namespace, Kyverno, postgres role-per-tenant,
  `tenant=` label) exist in the architecture review (SC7/P6) and apply at Stage 1 — not Stage 0.

---

_Snapshot date 2026-06-02. Items marked **confirm** were not verified to a pinned source at
snapshot time — check brain or the live cluster before depending on them._

## Stage 1 — multi-user facts (verified 2026-06-03)

### Postgres RLS (ADR-012)
- **The deployed DSN MUST connect as a non-superuser, non-BYPASSRLS role.** The
  app uses the `tapir` role (table owner, non-superuser). `FORCE ROW LEVEL
  SECURITY` is applied on all user-owned tables; a superuser DSN silently bypasses
  FORCE and isolation is dead in prod. Verify: `SELECT rolsuper FROM pg_roles
  WHERE rolname = 'tapir'` must return `f`.
- Scoping is via `set_config('tapir.current_user_id', $userID, true)` (transaction-
  local, auto-resets on commit — never leaks across a pooled connection).

### Per-user YouTube token persistence
- Stage-1 uses the **file-backed SecretStore** at `TAPIR_SECRETS_FILE=/data/secrets.json`
  mounted from a **PVC** (`tapir-secrets`, 64Mi, RWO). Tokens survive pod restarts.
  Upgrading to an ESO-backed per-user SecretStore is backlog (infra#86).
- Per-user token ref scheme: `youtube/<userID>/refresh_token` (Worker C, ADR-006).
  The Stage-0 single ref `youtube/refresh_token` is no longer used by `serve`; it
  remains valid for the CLI `tapir run` (single-user, host-side).

### Web YouTube connect
- Redirect URI (registered in Google OAuth client, type Web): `https://tapir.d-ma.be/oauth/youtube/callback`.
- Config env: `TAPIR_YT_CONNECT_REDIRECT_URL=https://tapir.d-ma.be/oauth/youtube/callback`.
  `TAPIR_YT_CLIENT_ID` / `TAPIR_YT_CLIENT_SECRET` from the Web client (not the Desktop client used for the CLI).

### Identity resolution
- `user_identities(dex_subject → user_id)` table is **intentionally NOT RLS-enabled**
  (it's auth plumbing, holds no user data; data isolation is on the user-owned tables).
  All data access after subject resolution goes through `withUser`.

## Scheduled discovery (ADR-018, verified 2026-06-05)

`tapir serve` runs discovery for **all users** in-process on a timer (no CronJob). Two env
knobs plus one load-bearing deployment constraint:

- `TAPIR_DISCOVERY_INTERVAL` — Go duration, e.g. `2h`. The cadence the serve process runs a
  discovery pass for every registered user (run-once-on-startup, then every interval).
  **Unset or `0` = disabled** (dev/tests never auto-fetch).
- `TAPIR_FETCH_RATE` — Go duration, default `2s`. The **process-wide per-egress-IP caption-fetch
  rate gate** (ADR-014 item 2). Every caption fetch — scheduler runners *and* the web "Summarize"
  click-path — serialises through this one limiter so the pod cannot collectively trip 429s. `0`
  = unlimited (dev/tests). This is the precondition that makes auto-summarize-on-a-schedule safe;
  do not raise it aggressively without watching for 429s.
- **SINGLE-REPLICA WARNING (load-bearing).** The scheduler lives in the web process, so
  `replicas: 1` in the deployment manifest is load-bearing: running `tapir serve` at >1 replica
  makes **every** replica run the discovery loop → every user fetched in parallel from the same
  egress IP (429s + duplicate work). Do **not** scale `serve` past 1 replica without first moving
  discovery to a k8s CronJob or adding leader election. The process logs a `Warn` at startup when
  scheduled discovery is enabled, as a reminder.