Konektory

Kde integrace nastavíte

Proměnné prostředí určují výchozí nastavení instalace (Konfigurace). 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

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í).

Zrcadlo 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). 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í).

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_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). 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

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.

# .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.

Odchozí cíle

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í: 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

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). Model tokenů je na Identita a přístup.