AI kontrola

Podoba kontroly

AI kontrola je jeden běh předpřipravené pipeline pr_review nad jedním otevřeným pull requestem. Pipeline otevře prostor kontroly daného PR, rozešle recenzenty, aby si v izolovaném checkoutu toho prostoru přečetli diff, každý zapíše zjištění jako strukturované uzly kontroly, vedoucí agent je složí do souvislého průvodce a finalizátor spočítá jeden verdikt: Ship, Hold nebo Block. Pipeline nezveřejňuje. Odeslání na GitHub je samostatný, záměrný krok, který udělá člověk.

Zbytek stránky vysvětluje jednotlivé díly a proč mají právě tenhle tvar.

Jeden prostor kontroly na každý PR

Kontext kontroly PR je prostor pro zprávy, režim review, druh pr, navázaný na pull request asociací prostoru kontroly. Vzniká idempotentně: stránka PR, pipeline kontroly i chat dohledají ten jediný podkladový prostor stejnou cestou v kódu. Šablona, která PR kontroluje, a člověk, který ho otevře, tak skončí v jednom prostoru nad jedním checkoutem.

Izolovaný worktree prostoru má PR checkoutnutý na jeho head ref. Jeden prostor znamená i jeden checkout: všichni recenzenti pracují ve stejném prostoru a sdílejí ho. Vlastní klon pracovního prostoru nedostane nikdo.

Každý recenzent píše do vlastního pojmenovaného proudu uvnitř toho jednoho prostoru a zjištění se zapisují jako zprávy review_node. Závěrečný sběr přes celý prostor je záměrný. Verdikt spočítaný ze zjištění jednoho vlákna by potichu byl verdiktem o jednom recenzentovi.

Asociace nese žebříček stavů requested → in progress → awaiting approval → completed. Podle něj se na záložce Kontrola u PR odemyká Zveřejnit na GitHub.

Úrovně kontroly

Jak hluboko kontrola jde, je politika pracovního prostoru se třemi úrovněmi. Nastavuje se v Nastavení → Pracovní prostor → Obecné, na kartě Politika pracovního prostoru:

Úroveň	Kteří recenzenti se rozešlou	Hlášení
light	jen Engineer	jen to, co podstatně záleží
balanced	Engineer, QA, architect (výchozí)	běžný průchod
thorough	všech pět, včetně zabezpečení a výkonu	nic se neodsouvá

Úroveň hýbe dvěma ovladači najednou. První je, kteří recenzenti se rozešlou. To vynucují stavové brány runWhen v šabloně pipeline. Znění promptu se dá obejít, bránu ne. Druhý je, kde se vykreslí zjištění pod prahem. Ani jeden ovladač zjištění nemaže. Úroveň, která hlásí méně, zapíše stejně a zbytek seskupí.

Průchody zabezpečení a výkonu znovu použijí předpřipravené agenty architect a engineer. Nové agenty nezavádějí. Specializace je zadání, se kterým se recenzent odešle, ne samostatný agent na každou osu. Agent na osu by v každém pracovním prostoru přidal pět řádků a žádnou schopnost navíc. Výběr recenzentů se do diffu nedívá kvůli jazyku ani doméně.

Uzly kontroly: zjištění jako data, ne jako text

Zjištění zapsané přes add_review_node se na PR stane uzlem kontroly. Ten vykresluje záložka Kontrola, z něj se počítá verdikt a „Zveřejnit na GitHub“ z něj udělá vložený komentář. Recenzent, který vrátí jen souvislý text, vyrobí běh pipeline, který vypadá úspěšně, a prázdnou plochu kontroly. Nosné je samotné zapsání.

Každý uzel nese:

Pole	Hodnoty
Druh	bug, suggestion, recommendation, question, ticket
Priorita	P0 (kritická) → P3 (drobnost)
Trojice třídění	kategorie (security, stability, …), závažnost, úsilí
Kotva	Cesta k souboru, začátek a konec řádku
Nesená oprava	Navržené náhradní řádky, volitelný diff, volitelný prompt opravy
Jistota	Skóre [0, 1]
Zdůvodnění	Analýza, napsaná před zjištěním

Dvě věci jsou záměrné. Návrh změny na GitHubu na jedno kliknutí se nabídne jen tehdy, když recenzent dodal přesné náhradní řádky. Odvozovat je z unified diffu se potichu pokazí a commit špatného odvození na jedno kliknutí je horší než tlačítko, které chybí. Schéma add_review_node dává reasoning před zjištění, takže model, který objekt plní v pořadí schématu, napíše analýzu jako první. Pole je volitelné a jeho vynechání uzel neodmítne. Uzel s poškozeným payloadem zmizí. Kontrolu neznečistí.

Shoda recenzentů

Uzel prochází open → consensus-ready → resolved nebo dismissed. Prostřední krok je jádro modelu: zjištění postoupí jen tehdy, když ho potvrdí jiný recenzent, a agent vlastní zjištění potvrdit nemůže. Nástroj MCP publish_review_to_github a výchozí RPC pořád zveřejňují jen zjištění potvrzená kolegou. Tlačítko Zveřejnit na GitHub na záložce Kontrola odešle každé zbývající otevřené zjištění.

Pravidlo se vynucuje na třech nezávislých místech, v nástroji pro potvrzení, ve finalizátoru a při zveřejnění, takže ho chyba volajícího na jednom z nich nezlomí. Všechny změny stavu jdou jednou službou, a proto stav něco znamená. Předtím se dvě poloviční cesty mohly rozejít v tom, jestli je totéž zjištění vyřešené.

Když se recenzenti neshodnou, stejný soubor a řádek, priority vzdálené o dvě a víc úrovní, nebo jeden to nazve bug a druhý suggestion, neshoda se ukáže nad seznamem zjištění. Tam se názory recenzentů rozcházejí a lidský úsudek má největší cenu.

Zamítnutí zjištění zapíše do domény paměti i měkký fakt o potlačení, s nízkou jistotou. Jedno zamítnutí je preference, ne pravidlo.

Kohorty: podle čeho se kontrola seskupuje

Průchod výpočtu kontroly seskupí změněné soubory PR do kohort odvozených z grafu kódu: změněné soubory se namapují na symboly, kterých se dotýkají, symboly na souvislé komponenty a kohorty se seřadí podle rozsahu dopadu. Kohorta nese vedené pořadí čtení, diagramy a postřehy.

Tvar určují dvě pravidla poctivosti. Klíče kohort se odvozují z obsahu a drží se napříč pushi, takže zjištění a postup kontroly přežijí rebase i force-push a neosiří. Když repozitář nemá index kódu, seskupení spadne na holé cesty a řekne to. Záložní cesta si sémantickou jistotu nevymýšlí.

Osy kontroly a brány

Vedle zjištění recenzentů kontrola sbírá výsledky os: šest os dvou druhů.

Osa	Druh	Z čeho
correctness, security	Řízená tokeny	vlastní zjištění recenzentů
testGap	Řízená tokeny	zjištění recenzentů
visual, apiContract	Deterministická	spočítaná bez utracení tokenů
performance	Deterministická	jen výčet. V produktu výsledek nic nepočítá

Verdikt osy je pass, warn, fail, partial nebo unavailable a bránu projde jen pass nebo warn. Rozdíl mezi fail, partial a unavailable je nosný: osa s bránou, která nedoběhla nebo se vůbec nespustila, celkový verdikt podrží a dál ho nepustí. Chybějící důkaz se v zelenou bránu nepromění.

Některé osy jsou schválně jen poradní. Osa mezery v testech, odvozená z kohort, nevidí pokrytí injekcí závislostí ani továren. Neindexovaný repozitář s důkladnou sadou testů a repozitář úplně bez testů odtamtud vypadají stejně, takže tvrdit jedno i druhé by byla lež. Ukáže se v přehledu a bránu nedrží. Tokenové osy jsou poradní, protože verdikt už řídí priority zjištění a druhá brána by je započítala dvakrát.

Verdikt

Finalizátor počítá verdikt ze zjištění ve stavu open nebo consensus-ready:

• jakékoli zjištění P0 s jistotou ≥ 0.7 → Block
• jinak jakékoli P0 s nízkou jistotou nebo jakékoli P1 → Hold
• jinak → Ship

Verdikt nese souhrnnou jistotu z rozptylu jistot, které do něj vstoupily. Shoda ji zvedá, rozchod snižuje.

Složení od vedoucího agenta (CEO) je redakční průchod. Ručně psaná druhá kopie zjištění je přesně to, co se od skutečných rozjede. Duplicitní zjištění se odsunou a neopakují se. Na jeden diff míří několik recenzentů se zadáními, která se schválně překrývají, takže když tatáž vada dojde k finalizátoru třikrát, systém funguje. Zveřejnit ji třikrát znamená, že se vlastní stavba systému vylije čtenáři do schránky. Při opakované kontrole dostanou zjištění otisk a porovnají se s předchozím kolem, takže na povrch vyjde rozdíl.

Nakonec vstoupí osy a verdikt umějí jen zpřísnit: osa s bránou, která selže, vynutí Block a zjištění ji nepřehlasují. Osa s bránou, která nedoběhla, vynutí aspoň Hold.

Zveřejnění zůstává na tobě

Pipeline na GitHub schválně nic neposílá. Zveřejnění pouští uživatel, aby se jedna kontrola neodeslala dvakrát. Když stiskneš Zveřejnit na GitHub:

• Odešle se jedna revize na GitHub. Zjištění už vyřešená nebo zamítnutá se přeskočí. Tlačítko zveřejní každé zbývající otevřené zjištění (selection: all_open). Nástroj MCP publish_review_to_github má pořád výchozí jen zjištění potvrzená kolegou (consensus).
• Zjištění ukotvená na soubor a řádek se stanou vloženými komentáři. Všechno ostatní splyne do těla shrnutí a každé nese patičku “— Control Center AI review”, aby byl zdroj jednoznačný.
• Kotvy se při zveřejnění znovu ověří proti aktuálnímu diffu PR. Komentář u kódu, který už byl přepsaný, důvěru podkope nejvíc. Když GitHub vloženou kotvu stejně odmítne, celá revize se pošle znovu a každé zjištění se složí do těla, takže se nic potichu nezahodí.
• Verdikt Block se odešle jako REQUEST_CHANGES, Hold jako COMMENT a Ship jako APPROVE z tlačítka (approve_on_ship: true). Nástroj MCP nechá Ship jako COMMENT, dokud nepředáš approve_on_ship.
• Revize se odešle pod identitou aplikace serveru. Kdo stiskl Zveřejnit, se zapíše pro bránu rolí a auditní záznam. Autorem na GitHubu to není.

Zveřejnění deklaruje třídu akce prPublish, takže ho úzké místo guardrailů hlídá jako každou měnící akci: ve výchozím stavu se zeptá a když není připojený žádný schvalovatel, zamítne. Viz Guardraily.

Co smí recenzent

Recenzenti běží v režimu review: sandbox jen ke čtení a sestavený seznam povolených nástrojů na zjištění, komentáře, tickety a kontrolu mezi sebou, bez změn. Recenzent nemůže opravit kód, který kritizuje. Může přiložit navrženou opravu a tu použije člověk. Zpráva, kterou režim při odmítnutí vrátí, řekne agentovi, který se přesto pokusí jednat, ať kontrolu dokončí a ať podle zveřejněného shrnutí jedná uživatel.

Související koncepty

• Guardraily — motor politik, který hlídá zveřejnění
• Režimy — co režim review u agenta mění
• Pipelines a automatizace — motor, na kterém kontrola běží
• Životní cyklus odeslání agenta — odkud se bere izolovaný worktree

Související návody

• Používejte AI kontrolu — spusť kontrolu a zveřejni ji
• Odešlete review agenty — recenzenty si vybereš sám
• Výpočet kontroly — kohorty, osy a diffy