Výpočet kontroly (kohorty, osy a deterministické diffy)

Záložka Kontrola u PR je živý průběh pipeline kontroly, dokud běží, a potom artefakt, který zveřejnila, i s akcemi na něm. Jedna záložka ve dvou stavech, protože jde o totéž ve dvou časech. Není výchozí: PR nemá kontrolu, dokud o ni někdo nepožádá, a otevře ji Zeptat se AI.

V pozadí té záložky cc_server sestavuje kohorty souborů, pouští deterministické osy a podává je přes RPC operace review_studio.* (cohorts, blastRadius, cohortImpact, ciSignals, dependencyDiffs, setContractDecision, approveVisual, compute a jejich dvojčata watch*). Uložené rozložení, které pořád nese jméno pr.reviewStudio, otevře tutéž záložku Kontrola.

Na záložce Kontrola:

Agent skládající průvodce zveřejní obyčejný artefakt konverzace nástrojem publish_artifact, takže ho záložka vykreslí stejným prohlížečem artefaktů, jaký otevře bublina chatu. Žádná kopie systému artefaktů ve tvaru kontroly neexistuje.
Zjištění sedí v postranní liště vedle něj a verdikt na úzkém pruhu nad artefaktem, ne v hlavičce nástěnky.
Když se head PR posune za kontrolu, objeví se pruh, že je zastaralá.

Průběh je v Používejte AI kontrolu a jednání podle výsledku v Zkontrolujte a sloučte PR.

Kohorty

Kohorty seskupí změněné soubory PR do košů odvozených z obsahu: soubory, které k sobě patří významem, seřazené podle dopadu, takže nejrizikovější skupina se čte první. Přepočítají se při každé změně head SHA a nahradí se vcelku. Klíč každé kohorty je stabilní napříč pushi, takže souhrn a postup kontroly přežijí rebase.

Když repozitář nemá index kódu, kohorty spadnou na seskupení podle cest. Indexovat jde v Nastavení → Pracovní prostor → Repozitáře. Každý řádek repozitáře má akci Indexovat kód, která spustí pipeline index_code a průběh hlásí přímo na řádku.

Graf kódu parsuje jen jazyky, ke kterým se dodává gramatika (Dart, JS/TS, PHP, Python, Rust, Zig, C/C++, Go, Java, Ruby, C#, Swift, Kotlin, R, Assembly, MATLAB, Ada). Repozitář v jiném jazyce sémantické kohorty nevyrobí, ať ho indexuješ sebedřív.

Agent může ke kohortě zapsat souhrn v markdownu nástrojem set_cohort_summary a přiložit strukturovaný diagram průchodu nástrojem add_review_diagram: typovaný objekt sekvence, relace entit nebo stavového automatu, nikdy text mermaid. Každá hrana se ověří proti skutečnému grafu kódu. Hranu, kterou graf nepotvrdí, se označí jako neověřená a nenakreslí se jako fakt.

Osa API kontraktu

Smluvní osa počítá diff jen z explicitních souborů specifikace. Shoduje se se šesti výchozími jmény — openapi.yaml, openapi.yml, openapi.json, swagger.yaml, swagger.yml, swagger.json — a s každým změněným souborem, jehož jméno obsahuje openapi nebo swagger a končí na .yaml, .yml nebo .json. Kontrakt odvozený z kódu handleru je mimo rozsah a schémata GraphQL se nediffují.

Každá změna se zařadí: přidaný, odebraný nebo upravený endpoint, parametr, schéma a odpověď. Nese závažnost breaking (odebraný endpoint nebo parametr, zpřísněný typ, nový povinný parametr), non-breaking (aditivní) nebo informační. Zamítnutá změna bránu kontraktu neprojde, stejně jako breaking změna ponechaná bez rozhodnutí. Schválená breaking změna jen varuje. Když breaking změna není, brána projde. Diff označený jako odvozený (poradní) bránu nikdy nedrží.

Schválení nebo zamítnutí změny je review_studio.setContractDecision.

Vizuální osa

Když PR mění komponenty UI v repozitáři Flutter s aplikací Widgetbook, průchod výpočtu vykreslí změněné komponenty před změnou a po ní headless zlatým průchodem flutter test ve worktree daného PR na base a na head a potom porovná pixely.

Snímky ve stavu changed nebo removed drží vizuální bránu, dokud je neschválíš. Stavy unchanged, added a approved ji uvolní. Nedostupnost má jeden ze čtyř důvodů: „no Flutter SDK on host“, „no Widgetbook app in repo“, „no golden-testable use-cases“ nebo „golden harness error“.

Schválení zamýšlené změny je review_studio.approveVisual.

Osy a verdikt

Osa	Pohání
Správnost	Recenzenti (tokeny)
Zabezpečení	Recenzenti (tokeny)
Mezera v testech	Recenzenti (tokeny)
Vizuální	Deterministicky (golden harness)
API kontrakt	Deterministicky (diff specifikace)

Tři tokenové osy se zapíšou, když vedoucí agent zavolá finalize_review. Dvě deterministické osy zapíše průchod výpočtu.

Každá osa ohlásí jeden z těchto stavů:

Stav	Význam
Pass	Proběhla a nenašla nic blokujícího
Warn	Proběhla, má neblokující výhrady
Fail	Proběhla a našla blokující problém
Partial	Proběhla, ale nedokončila se; výsledky jsou neúplné
Unavailable	Nespustila se vůbec

Osu s bránou projde jen pass a warn. Partial a unavailable se od fail schválně liší a ani jeden bránu neprojde.

Osy se složí do Ship, Hold nebo Block a verdikt umějí jen zpřísnit. Nikdy se nezmírní. Osa s bránou ve stavu fail vynutí Block. Osa ve stavu partial nebo unavailable vynutí aspoň Hold. Blokující osa, která se nespustila, verdikt podrží: chybějící důkaz se v zelenou bránu nepromění.

Verdikt na záložce Kontrola je ten, který zapsal finalize_review.