Publikace je podmíněna vším, co může učinit publikovaný web chybným, a na nic jiného nečeká; kontroly, které rozhodují, zda se změna smí mergovat, běží vedle ní na stejném commitu, ne před ní

Co to znamená

Push do masteru, který může změnit web, spustí jednu úlohu a ta publikuje, jakmile jsou bajty dokázány: commitnutá odvozená data jsou pro strom aktuální, web se z nich sestaví a projdou všechny statické kontroly nad výstupem. Nečeká na behaviorální sadu, kontroly crate, pokrytí, sadu pro macOS, kontrolu měření výkonu ani sondu v prohlížeči. Ty běží nad stejným commitem paralelně ve validačním workflow a brání sloučení přes stav ci — chrání repozitář, ne publikované bajty. Nic, co může publikované bajty učinit chybnými, nebylo z cesty publikace odstraněno; odstraněno bylo jen to, co ji mohlo pouze zdržet. Nasazení jsou serializovaná a to běžící se nikdy neruší: GitHub drží jen nejnovější čekající běh, takže novější push nahradí každé starší pending nasazení, kdežto zrušení běžícího by publikaci vyhladovělo, kdykoli merge přicházejí rychleji, než běh doběhne. Publikace se měří zvenčí, ne předpokládá ze zeleného jobu: web servíruje commit, ze kterého byl sestaven, workflow čeká, až veřejná URL pojmenuje tento, a čte vlastní build větve, kterou GitHub pro pushnutou větev provedl — build, který skončil chybou, je selhání běhu, který publikoval, protože publikace jsou dva kroky a jen první je věcí tohoto repozitáře.

Princip

Dva workflow. .github/workflows/validate.yml plánuje z .ai/repo/ci/gates.yaml, které kontroly může změna ovlivnit, a spouští je; scripts/ci/verdict z toho dělá jediný stav, který vyžaduje pravidlo větve. .github/workflows/pages.yml je publikační cesta: spouští se přímo při pushi do masteru, jehož cesty mohou změnit web — blok paths: je scripts/pages paths, sjednocení tříd modelu kontrol, které jmenují kontrolu site-build, plus samotná publikační cesta — v jediném jobu, který drží pages-<ref> s cancel-in-progress: false, s contents: write pro push větve a pages: read pro dotaz GitHubu, zda ji sestavil, a bez dalšího oprávnění. Job spouští scripts/pages build, scripts/pages check a poté scripts/site-deploy --skip-build, tentýž skript, kterým nasazuje člověk. pages build zjistí, že site/data/generated je aktuální, porovnáním kanonického vstupního hashe stromu s tím, který nese commitnuté source.json — generate-site-data --fingerprint, jeden hashovací proces nad vlastním seznamem vstupů generátoru — a pak jej vykreslí bez opětovného generování; strom, jehož commitnutá odvozená data jsou zastaralá, se odmítne, ne tiše regeneruje, protože projekce v rozporu se svými zdroji je vada k opravě u zdroje. Model je .ai/repo/ci/pages.yaml: spouštěč, cesta nasazení, řízené rozpočty a cache domény; ani workflow, ani skript nenese vlastní seznam cest, rozpočet nebo název kontroly. Každá fáze se v souhrnu jobu měří proti těmto rozpočtům, přičemž fronta Actions a vlastní „pages build and deployment“ GitHubu se hlásí vedle řízené cesty jako externí latence a nemíchají se do ní. Polovina publikování, kterou tento repozitář nevlastní, se čte, a ne odvozuje: vlastní „pages build and deployment“ GitHubu může skončit chybou na větvi, která byla pushnuta dokonale, a 2026-09-10 v 17:35:10Z se to stalo — gh-pages dfd9c989c, Page build failed., 27 minut zastaralého webu při zelených všech signálech. scripts/pages built je jediný čtenář stavu toho buildu pro oba volající: publikační job selže na errored ve chvíli, kdy k tomu dojde, a scripts/ci/pages-check položí tutéž otázku při další validaci masteru stejným příkazem. Build, který jen ještě neskončil, je poznámka, nikdy verdikt. test/cases/180_publication_is_observed.sh drží obě síťové poloviny proti fixture webu a stubovanému API buildů. test/cases/97_pages_fast_path.sh drží přímý spouštěč, odvozené cesty, že se žádné probíhající nasazení neruší, minimální oprávnění, že na publikační cestě není žádná těžká kontrola a žádná neopustila validační workflow, že jen publikační měření smí selhat měkce, že otisk je hodnota, kterou generátor zapisuje, a že build, který generování přeskočí, je bajt po bajtu web buildu, který ho nepřeskočí; test/cases/26_ci_wiring.sh drží oba workflow a dělení mezi nimi a shellová doktrína ci v lib/doctor.sh stále vyžaduje bash test/run.sh ve validačním workflow bez spolknutého exit kódu.

Jak to vidět

scripts/pages paths                                     # what a push must touch to publish
scripts/pages budget                                    # the controlled budgets, from the model
scripts/pages benchmark -n 5                            # the controlled path, measured here
just test-shell 97_pages_fast_path
gh run list --workflow pages --branch master --limit 5

Co nepokrývá

Nečiní publikaci bezpodmínečnou vůči správnosti: publikuje se master a o tom, co se na master může dostat, rozhoduje stav ci validačního workflow, což je nastavení repozitáře na GitHubu, nikoli vlastnost těchto souborů. Nezkracuje frontu Actions, přidělování runnerů ani vlastní sestavení Pages větve gh-pages na GitHubu; to se měří a hlásí a cíl end-to-end se vůči nim stanovuje, nevynucuje. Nenahrazuje prohlížečovou sondu: sonda stále běží při každém commitu, který může změnit web, a trasa, na které selže, je vada k opravě, ne zablokované nasazení.

Proč existuje

Publikace dříve čekala, pro každý commit masteru, na každou kontrolu, která rozhoduje, zda se změna smí mergovat — mezi nimi behaviorální sadu, kontroly crate a browser probe — a web se proto zveřejnil desítky minut po pushi, který jej změnil, pokud vůbec. Problémem nebyly kontroly, ale jejich pozice. Projekce nejnovějšího commitu stojí za publikaci ve chvíli, kdy je projekce prokázána, a důkaz, že je projekce správná, je něco jiného a mnohem menšího než důkaz, že je správný repozitář.