# Konektory (https://docs.vitrinka.ai/cs/operator/connectors)



## Kde integrace nastavíte [#owner]

Proměnné prostředí určují výchozí nastavení instalace ([Konfigurace](/cs/operator/configuration#integrations)). Správci připojují workspace a projekty k externím systémům přes příslušná nastavení nebo API. Všechny tyto integrace jsou volitelné.

## GitHub App [#github]

Jedna GitHub App na instalaci pohání commit pilulky u sad, připojení repozitáře per workspace a webhooky pull requestů a check suite, které připojují odkazy k úkolům a zobrazují stav kontrol každého pull requestu (App odebírá události Pull requests, Pushes a Check suites). Instalace App je pověření workspace; **které repozitáře patří kterému projektu** se deklaruje per projekt v Nastavení → Projekty → repozitáře (první je výchozí, na který se commit pilulky, prohlížeč kódu a sběr release rozřeší, když karta nemá vlastní sadu; `vitrinka setup` naváže origin checkoutu, když projekt ještě žádný nemá, a nahraná sada si dál razítkuje vlastní repozitář jako zálohu). Nastavte `GITHUB_APP_ID`, `GITHUB_APP_PRIVATE_KEY`, `GITHUB_APP_SLUG`, `GITHUB_APP_CLIENT_ID`, `GITHUB_APP_CLIENT_SECRET` a `GITHUB_WEBHOOK_SECRET`; webhook App nasměrujte na `POST /api/v1/github/webhook` — jedinou URL App pro všechny workspace: doručení se přesměruje do workspace, který navázal instalaci uvedenou v payloadu, a pak se ověří proti webhook secretu. Admin workspace pak App nainstaluje do organizace a naváže ji — vazba vyžaduje důkaz, že instalující uživatel instalaci vlastní. Workspace může navázat víc GitHub účtů (organizaci i osobní účet, několik organizací); každá instalace obsluhuje repozitáře svého účtu a patří právě jednomu workspace. Nastavení → GitHub ukazuje, na které repozitáře každý účet dosáhne, a řádky repozitářů v Nastavení → Projekty z tohoto grantu napovídají a varují u `github.com` repozitáře, který žádný navázaný účet nepřečte — je to upozornění, nikdy blokace, takže vlastní hostovaný remote nebo repozitář deklarovaný dřív, než je jeho účet navázán, se stále uloží. `GITHUB_TOKEN` je záložní přístup pro commit pilulky, když App nastavená není, a `GITHUB_LOGIN=1` přidá na přihlašovací stránky **Continue with GitHub**.

Pod `AIR_GAP=1` se všechno z GitHubu vymaže ([Air-gapped nasazení](/cs/security/airgap#switch)).

## Zrcadlo Jira [#jira]

Úkoly projektu můžete synchronizovat s Jirou. Jiru workspace připojíte v **Settings → Trackers** (nebo přes `PUT /api/v1/connectors/jira`) — je to totéž jediné připojení trackeru, které používají schválená hlášení — a projekt pak navážete přes `PUT /api/v1/projects/{project}/mirror`. Nastavení určuje zdroj pravdy (`local` nebo `remote`) a mapování stavů. Synchronizace přepíše konfliktní změny na druhé straně a zapíše událost `mirrored`. Spustíte ji přes `POST /api/v1/projects/{project}/mirror/sync`. Proměnná `VITRINKA_CONNECTOR_POLL` řídí kontrolu tiketů připojených ke schváleným hlášením, nikoli synchronizaci úkolů projektu.

Navázání zrcadla i spuštění synchronizace jsou operace pro admina a výš. Připojení, které uloží admin workspace, dosáhne jen na veřejné internetové adresy; Jira na privátní, loopback nebo interní adrese funguje, až když připojení uloží pravomoc nad instalací ([Odchozí cíle](#outbound)). V air-gapped instalaci takové připojení dosáhne jen na interní adresy, takže funguje jen Jira Server nebo Data Center uvnitř sítě, a připojení, které nikdo s pravomocí nad instalací neuložil, nedosáhne nikam ([Air-gapped nasazení](/cs/security/airgap#stays)).

## Plane [#plane]

`PLANE_API_URL`, `PLANE_API_TOKEN` a `PLANE_WORKSPACE` dohromady zapnou napojení na Plane: každá publikovaná sada, která odkazuje na issue, u něj dostane jeden komentář, aktualizovaný na místě při každém pushi. Pro Plane zrcadlo neexistuje.

## AI backend [#ai]

`AI_BACKEND_URL` a `AI_BACKEND_TOKEN` nastavují backend chatu a přehledu běhů dostupný přes `/api/v1/eve/`. Požadavky měnící stav na spravovaném backendu čerpají AI kredity organizace (**Settings → Organization → Plan & billing**). Čtení zůstává dostupné a vlastní backend workspace používá vlastní výpočetní prostředky bez spravovaných kreditů. Admin workspace může jeden workspace nasměrovat na vlastní backend v **Settings → Workspace → AI → Backend**, kde má přednost před `AI_BACKEND_URL` — na veřejné adrese; backend na privátní, loopback nebo interní adrese potřebuje uložení od pravomoci nad instalací ([Odchozí cíle](#outbound)). Backend, který určuje `AI_BACKEND_URL`, je váš jako provozovatele a pravidlo se ho netýká. Poskytovatele za @zmínkami a review passy volí každá organizace v **Settings → Organization → AI** a vlastní endpoint, který tam uvede (`base_url`), se řídí stejným pravidlem. `EVE_URL` a `EVE_SECRET` nastavují samostatný kanál podepsaný HMAC pro zmínky na nástěnce a AI kontroly.

## Přepis schůzek [#stt]

Snap přepisuje schůzku na Macu. Instalace může místo toho přepisovat na serveru s jedním sidecarem whisper.cpp vedle vitrinky: enterprise balík ho nese jako volitelný profil `stt`, ve vnitřní síti compose bez publikovaného portu, takže zvuk ji nikdy neopustí. Žádný image model neobsahuje.

Zapněte profil a nasměrujte na něj server v `.env`, jednou stáhněte model do volume `vitrinka-stt-models` (asi 1,6 GB) a spusťte to; sidecar model načítá při startu, což může trvat až dvě minuty.

```bash
# .env
COMPOSE_PROFILES=stt
VITRINKA_STT_URL=http://vitrinka-stt:8080

docker compose --profile stt run --rm --entrypoint sh vitrinka-stt -c \
  'curl -fL -o /models/ggml-large-v3-turbo.bin https://huggingface.co/ggerganov/whisper.cpp/resolve/main/ggml-large-v3-turbo.bin'
docker compose up -d
```

`VITRINKA_STT_MODEL` určuje soubor modelu (výchozí `ggml-large-v3-turbo.bin`, vícejazyčný, takže zvládne češtinu) a `VITRINKA_STT_THREADS` počet vláken dekódování (výchozí `4`; odpovídá jádrům, která sidecaru dáte). V air-gapped instalaci stáhněte soubor modelu i připnutý image sidecaru na připojeném stroji, image nahrajte do svého registru a nasměrujte na něj `VITRINKA_STT_IMAGE`, pak model zkopírujte do volume přes `docker compose --profile stt cp ggml-large-v3-turbo.bin vitrinka-stt:/models/`.

Každá organizace se pak rozhodne sama: admin organizace zapne **Settings → Organization → AI → server transcription**, které je ve výchozím stavu vypnuté. Od té chvíle se schůzka, která dorazí bez přepisu, přepíše na serveru. `AIR_GAP=1` sidecar nechává běžet, protože je to interní endpoint. Schůzky z pohledu člověka: [schůzky](/cs/use/day#meetings).

## Odchozí cíle [#outbound]

Tři nastavení nechají server volat adresu, kterou zvolil admin: tracker workspace (**Settings → Trackers**), AI backend workspace (**Settings → Workspace → AI → Backend**) a vlastní AI endpoint organizace (`base_url` v **Settings → Organization → AI**). Kde se může zaregistrovat kdokoli, spravuje každý účet vlastní workspace i organizaci, takže o tom, co vaše síť zpřístupní, uložení adminem nikdy nerozhoduje: cíl, který uloží běžný admin, dosáhne jen na veřejné internetové adresy — ověřuje se při uložení a znovu při každém požadavku, včetně každého přesměrování, bez proxy z prostředí. Cíl na privátní, loopback nebo interní adrese funguje, až když ho uloží [pravomoc nad instalací](/cs/security/identity#deployment): platformní admin nebo admin organizace, kterou jmenuje `VITRINKA_OPS_ORG`, který zároveň drží adminské místo, jež nastavení vyžaduje (admin daného workspace, nebo dané organizace). Takové uložení cíl označí; u označeného trackeru nebo AI backendu Settings ukazuje „saved by deployment authority — may reach your internal network“. Běžný admin dál smí měnit ostatní nastavení — klíč projektu, typ issue, režim synchronizace, model — ale změna toho, kam se cíl připojuje (URL, nebo token, klíč či e-mail, které určují jak), značku smaže a cíl je znovu jen na veřejných adresách. Token, který uložila pravomoc nad instalací, zůstává u cíle, pro který byl uložen: běžný admin, který změní URL nebo e-mail označeného trackeru, musí zadat vlastní token, a kdo označený AI backend nasměruje jinam, uložený token tím zahodí. URL každého cíle musí být https, nebo http jen na loopback, protože jeho token nebo klíč jde s každým požadavkem; tracker následuje přesměrování jen na stejného hostitele a nikdy na holé http a AI endpoint organizace nenásleduje žádné. Pod `AIR_GAP=1` dosáhne označený cíl do vaší interní sítě — loopback, privátní, link-local, CGNAT a třída E, nikdy endpoint cloudových metadat nebo přihlašovacích údajů — a nikdy na veřejný internet; neoznačený nedosáhne nikam a stejně tak veřejný výchozí endpoint poskytovatele. API nastavení značku hlásí jako `deploymentManaged` (AI organizace: `deployment_managed`).

Odmítnutí řekne, co změnit nebo koho požádat, a nikdy neuvede adresu, na kterou se hostitel přeložil. Uložení, které pravidlo odmítne, dostane `403` — `422` pro veřejného hostitele pod `AIR_GAP=1` — a nic se neuloží; požadavek na cíl, který na svou adresu dosáhnout nesmí, například interní cíl, který po upgradu nikdo znovu neuložil, dostane `502` s kódem `not_configured` a opakování nepomůže.

**Po upgradu** je každý tracker, AI backend a AI endpoint uložený před tímto pravidlem neoznačený. Každý, který míří do vaší interní sítě — na air-gapped instalaci všechny —, ať jednou uloží někdo s pravomocí nad instalací, přihlášený s adminským místem, které nastavení vyžaduje:

* **Settings → Trackers** → **save**; prázdný token ponechá ten uložený.
* **Settings → Workspace → AI → Backend** → klikněte do URL backendu a stiskněte Enter, nebo pošlete `PUT /api/v1/workspace/ai-backend` s aktuální `url`.
* **Settings → Organization → AI** → uložte poskytovatele beze změny.

Zpětné čtení pak ukáže `deploymentManaged: true` (AI organizace: `deployment_managed: true`) a u trackeru nebo AI backendu ukáže Settings řádek uvedený výše.

## Agenti přes OAuth [#oauth]

Hostovaní AI asistenti, kteří mluví MCP přes HTTP, se připojují přes OAuth 2.1 s PKCE: metadata na `/.well-known/oauth-authorization-server` a `/.well-known/oauth-protected-resource`. Klienti se registrují dokumentem metadat client ID (přednostně) nebo dynamicky na `POST /oauth/register` — pod `AIR_GAP=1` jen tak, protože žádný dokument metadat se nestahuje — a zdrojem je `/mcp`. Souhlas pokrývá každý týmový workspace organizace, ve které byl udělen, jehož jste členem — ověřuje se při každém požadavku. Uživatelé i admini workspace vidí živý seznam připojení s odvoláním na jedno kliknutí. Lokální agenti — Claude Code, Codex, Cursor — registrují tentýž vstup a přihlašují se stejným OAuth tokem ([MCP klienti](/cs/dev/mcp/clients)). Model tokenů je na [Identita a přístup](/cs/security/identity#agents).