Případová studie: dodávka s AI pod dozorovou řídicí vrstvou

Co tato případová studie je (a co není)

Tato stránka dokumentuje jednu dodávku: web, který právě čtete. Vznikl 14. září 2026; postavil ho AI agent pro programování (Claude Code), kterého řídil jeden člověk, a mezi agentem a repozitářem stál jako dozorová řídicí vrstva Majordomus ve verzi 0.6.0. Stránka je pojatá jako technologické demo. Každé číslo na ní je spočítané ze záznamů, které po dodávce zůstaly: z ledgeru Majordomu, z deníku rozhodnutí a handoverů pracovního checkoutu, z historie Gitu a ze záznamů GitHubu o bězích pipeline a vydáních. Časová osa tyto záznamy vykresluje jeden po druhém a každá událost odkazuje na commit, běh, vydání nebo soubor, ze kterého pochází.

Stejně důležité je, čím stránka není:

• Není to kontrolované srovnání. Proběhlo jedno sezení s jedním člověkem a jedním agentem a žádné srovnatelné sezení bez dozoru. Z těchto záznamů neplyne žádný násobek zrychlení a stránka ho netvrdí. Uvádí naměřené doby; odhady ušetřeného času s vyznačenými předpoklady přenechává článku o účtování času.
• Není to obecné tvrzení o Majordomu. Ukazuje, jak ho nastavil jeden repozitář, které příkazy běžely, co zaznamenaly a co odmítly. Jiná konfigurace se chová jinak.
• Není to záznam všeho. Ledger ukládá přijaté operace. Příkaz, který Majordomus odmítl, v něm nezanechá žádnou položku, takže tření je tu vidět jen tam, kde ho zmiňuje handover, checkpoint nebo commit.
• Není to přepis konverzace. Zadání, texty checkpointů a lokální cesty zůstávají v checkoutu. Publikovaný snímek je kurátorovaný a docs/CASE-STUDY.md popisuje, co obsahuje a proč.

Metodická poznámka podrobně popisuje první vydání včetně druhů zadání, které práci řídily. Tato stránka se věnuje samotné dozorové vrstvě: jak byla nastavená, jak se používala každá její část a kde přestala pomáhat.

Výchozí stav

Agent a člověk. Agent četl repozitář, spouštěl příkazy, upravoval soubory, commitoval a pushoval. Člověk v prvních fázích poslal zhruba patnáct zpráv: žádosti, výtvarné zadání, dlouhá strukturovaná zadání a krátké pokyny jako „nasaď“, „vydávej automaticky“ nebo „použij Majordomus a vynucuj ho“. Implementační volby dělal agent. Později během dne pracovali na stejném checkoutu souběžně další agenti a druhé sezení; jak, popisuje oddíl o kontinuitě.

Repozitář. Web v Zole 0.23.6 v angličtině a češtině, stylovaný Tailwind CSS a doplněný o Alpine.js a Flowbite; validátory v Pythonu, sada testů v Playwrightu a pytest; malý workspace v Rustu, který čte JSON API webu; a workflow GitHub Actions, která nasazují na GitHub Pages a vytvářejí vydání. Web popisuje stránka O projektu a právě běžící build ukazuje stránka stavu.

Vrstva Majordomus. Majordomus drží svůj stav v adresáři .ai/, který má dvě poloviny:

• .ai/repo/ je v Gitu a sdílí ho každý checkout. Jeho manifest registruje jednotlivé sekce. Politika nastavuje rozpočty kontextu, interval checkpointů výchozího profilu, požadavky smlouvy o dokončení (dodržený rozsah, proběhlé ověření, aktualizovaný stav, žádné otevřené blokery, přítomná poznámka), oddíly, které musí mít handover (Objective, Current State, Next Action), a dvě položky vynucování, které vážou příkazy na hooky Gitu. Existují čtyři profily provádění (implementation, debugging, deep work, routine) a všechny úlohy tu běžely v profilu implementation. Pravidla leží v .ai/repo/rules/: zafixovaný převzatý základ, který se jen čte, a šest projektových pravidel. Architektonická rozhodnutí leží v .ai/repo/adrs/.
• .ai/local/ Git ignoruje. Obsahuje aktivní úlohu, ledger, do kterého se jen přidává, checkpointy, handovery, deník rozhodnutí a otevřené otázky. Nic z něj nesmí publikovat žádný generátor, a proto tato stránka nese kurátorovaný export, ne samotný adresář.

Z politiky vygeneroval Majordomus tři instrukční soubory, AGENTS.md, CLAUDE.md a GEMINI.md. Každý z nich odkáže agenta na .ai/README.md a jeho postup vyhledávání kontextu. První událost v ledgeru, v 10:26:23 UTC, je právě tato projekce.

Hooky a CI. Příkaz npm ci nasměruje Git na adresář .githooks/ v repozitáři. Workflow CI opakuje kontrolu zdraví Majordomu ve vlastním jobu, takže se kontroluje i klon bez hooků. Všechna místa vynucení uvádí tabulka zapojení.

Životní cyklus úlohy v praxi

Majordomus dovoluje jednu aktivní úlohu na checkout. Diagram životního cyklu výše prochází každý krok s jeho registrovaným příkazem a skutečným zaznamenaným příkladem; tento oddíl vypráví totéž popořadě.

Start s rozsahem. majordomus start otevře úlohu s názvem, profilem a cestami, na které smí sáhnout. První úloha začala v 10:26:23 UTC a nárokovala si 20 cest. Za zaznamenané období začalo šest úloh s rozsahem od jedné cesty po 31.

Práce a kontrola. majordomus check nic nezapisuje: ohlásí, zda je aktivní úloha v souladu s politikou, svým rozsahem a zaznamenaným stavem. majordomus watch hlásí odchylky mezi úlohou, jejím rozsahem, politikou a vygenerovanými instrukčními soubory. Společně zachytily dva problémy s rozsahem ještě před prvním pushem (viz co dozor zachytil).

Checkpoint. majordomus checkpoint zaznamená krátkou poznámku o průběhu, kterou politika omezuje na 40 řádků. Zaznamenalo se sedm checkpointů. Čtyři napsal agent; například checkpoint v 10:43:27 vznikl hned po prvním pushi, zatímco běžela pipeline. Dva byly odvozeny z Gitu bez jakéhokoli psaného textu a uvádějí jen, kolik souborů se od začátku úlohy změnilo: 65 ve 12:16:46 a 144 ve 12:52:41. Poslední patří úloze, která byla na konci snímku stále aktivní.

Zaznamenat rozhodnutí. majordomus decision přidá datovaný záznam s odůvodněním, odmítnutými alternativami a doklady. Zaznamenala se čtyři rozhodnutí; najdete je v oddílu o rozhodnutích a ADR.

Předat práci. majordomus handover zapíše záznam pro navázání se třemi oddíly, které politika vyžaduje. Vznikly čtyři handovery. Tři z nich předcházely o jednu až dvě sekundy ukončení úlohy jako partial, což je přesně vzorec, který smlouva o dokončení požaduje: jiný výsledek než completed potřebuje poznámku, co bude následovat.

Dokončit s ověřovacím příkazem. majordomus finish vyhodnotí smlouvu o dokončení. Výsledek completed vyžaduje ověřovací příkaz, který proběhl a skončil nulou, a ledger ukládá příkaz, jeho návratový kód a dobu běhu. V tomto repozitáři zvolil agent smoke test produkce, tedy skript za příkazem npm run smoke, spuštěný proti živé URL. První dokončená úloha se uzavřela v 10:47:25 UTC, necelé dvě minuty po publikování vydání v0.1.0, a její ověřovací příkaz skončil kódem 0 po 7 sekundách. Smlouva zaznamenala sedm požadavků jako pass, čtyři jako skipped a žádný jako fail; požadavky, které se na daný výsledek nebo konfiguraci nevztahují, se zaznamenají jako skipped. Druhá dokončená úloha se stejně uzavřela ve 13:08:34, po vydání v0.5.0.

Přečíst záznam. majordomus history vypíše ledger. Snímek, ze kterého tato stránka vychází, se exportoval z jeho výstupu ve formátu JSON.

Zapojení kontrol

Pravidlo, které nic nespouští, je jen doporučení. Majordomus porovnává položky vynucování ve své politice se skutečností: majordomus doctor selže, když deklarovaný příkaz chybí, není spustitelný, nevolá ho hook, který politika jmenuje, nebo ho volá tak, že spolkne jeho návratový kód. Stojí za tím převzaté pravidlo enforcement-wiring, které vynucuje právě doctor.

• Pre-commit. .githooks/pre-commit odmítne běžet bez nainstalovaného Majordomu a pak spustí majordomus doctor. Commit tedy vyžaduje zdravou a zapojenou vrstvu.
• Pre-push. .githooks/pre-push spustí majordomus finish --check, který vyhodnotí smlouvu o dokončení aktivní úlohy, aniž by úlohu uzavřel. Push, který nese práci mimo nárokovaný rozsah, se odmítne dřív, než opustí stroj.
• Zprávy commitů. .githooks/commit-msg spustí scripts/lint-commits.sh. Conventional Commits se vynucují, protože se z nich počítají verze vydání.
• Dozorový job v CI. Job Majordomus supervision v ci.yml nainstaluje Majordomus v zafixované verzi 0.6.0 (instalátor ověří SHA-256 vydání), nasměruje Git na hooky a spustí majordomus doctor. Prošel ve všech bězích Pages ve snímku.
• Brány nasazení. pages.yml spouští CI, pak Deploy, pak Verify production a nakonec Release. Deploy ověří, že URL Pages odpovídá základní URL v konfiguraci Zoly. Verify production počká, až živý web servíruje pushnutý commit, a pak proti němu spustí smoke test a prohlížečové testy příkazem npm run test:production. Release běží, jen když Verify production prošel.
• Rulesety repozitáře. Repozitář na GitHubu chrání tři rulesety: main vyžaduje CI, historii main nelze přepsat ani smazat a tagy v* nelze přesunout ani smazat. Požadavek na CI připouští výjimku pro administrátora a první push ji využil.

Vynucováním Majordomu v užším smyslu jsou jen oba hooky. Ostatní jsou běžné pojistky téhož repozitáře a tato zpráva jejich účinky od Majordomu neodděluje.

Pravidla vedle kódu

Pravidla jsou dokumenty v Markdownu s front matter: id, version, třída (blocking nebo advisory) a volitelné závislosti zapsané jako přesné odkazy id@version. Platná sada se skládá sčítáním, převzatý základ Majordomu plus vlastní pravidla projektu, a žádný mechanismus přepisu neexistuje. majordomus rules list sadu vypíše s třídou každého pravidla a příkazy, které ho vynucují.

Šest projektových pravidel s odkazy na jejich soubory:

• verified-deployment: nic se nehlásí jako nasazené, dokud job ověření ve workflow Pages neprojde proti živé URL, kterou vrátí GitHub.
• zola-source-of-truth: veškeré veřejné HTML generuje Zola; obsah žije v Markdownu, texty rozhraní ve slovnících překladů a šablony sdílejí oba jazyky.
• release-on-verified-main: Conventional Commits jsou povinné a každý ověřený push do main vytvoří vydání, jehož verze se odvodí z commitů.
• evidence-ledger: každé veřejné tvrzení je zaznamenané se zdroji, úrovní důkazů, mírou jistoty a datem revize, které ještě neuplynulo.
• no-neuro-overreach: žádná věta nesmí tvrdit, že signál, model nebo oblast mozku odhaluje, co člověk cítí.
• medical-claims: zjištění se uvádějí na úrovni skupin i s limity, nikdo se neposuzuje individuálně a každá výzkumná poznámka i rada nese klinické upozornění.

Všech šest je blokujících a jejich závislosti jsou výslovné: evidence-ledger závisí na verified-deployment, no-neuro-overreach na evidence-ledger a medical-claims na obou. Žádné z nich nemá blok x-majordomus a výpis pravidel u nich uvádí, že nemají validátor. Je to záměr a stojí to v každém souboru: Majordomus pravidla rozpozná, vypíše a načte do kontextu agenta, vynucují je však validátory projektu, joby v CI a revize. Pro čtení této případové studie je ten rozdíl podstatný. Když build shodí zakázaná formulace nebo tvrzení po datu revize, zachytil to validátor obsahu nebo validátor ledgeru projektu, ne Majordomus.

Vynucování Majordomu žije v převzatém základu. Čtyři jeho pravidla v této dodávce viditelně pracovala. Scope-integrity nepovažuje práci mimo nárokované cesty za práci úlohy; vynucují ho check, finish a watch. Verification-integrity vyžaduje, aby dokončený výsledek měl ověřovací příkaz, který skončil nulou, se zaznamenaným návratovým kódem a dobou běhu; vynucuje ho finish. Note-integrity vyžaduje, aby každý výsledek nesl poznámku s oddíly, které daný výsledek potřebuje; vynucuje ho také finish. Enforcement-wiring, popsané výše, vynucuje doctor.

Rozhodnutí a ADR

Pracovní rozhodnutí od trvalého oddělují dva mechanismy.

Deník rozhodnutí je lokální, jen se do něj přidává a zápis je levný. majordomus decision zaznamená, co se rozhodlo, proč, co se odmítlo a kde jsou doklady. Zapsaly se čtyři položky:

1. Strukturovaná data se sestavují jako data v Teře a serializují přes json_encode. Ručně psané JSON-LD v šablonách se escapuje jako HTML a rozbije se na uvozovkách. Odmítnuto: ručně psané řetězce JSON-LD a skript, který je vkládá v prohlížeči.
2. Náhledy odkazů jsou lokalizované podle jazyka a sitemapa uvádí každou jazykovou verzi. Odmítnuto: jedna anglická náhledová karta pro všechny stránky a jazykové alternativy jen v HTML.
3. Validátory v Pythonu se testují přes pytest v projektovém virtuálním prostředí. Odmítnuto: unittest ze standardní knihovny a globální instalace pytestu.
4. Důkazy se vedou jako datovaný ledger hodnocených zdrojů a odstupňovaných tvrzení a validátory shodí build na zastaralých nebo nekonzistentních položkách. Odmítnuto: volné poznámky o důkazech na každé stránce a jediný soubor, který míchá bibliografická fakta s redakčním úsudkem.

První tři se zaznamenaly během jedné sekundy (11:08:30 až 11:08:31 UTC), krátce před handoverem. Rozhodnutí se tedy zapisovala ve chvíli, kdy se úloha chystala uzavřít, ne průběžně.

Záznam architektonického rozhodnutí je v Gitu a je trvalý. Čtvrté rozhodnutí bylo sepsáno jako ADR-0001 s kontextem, rozhodnutím, odmítnutými alternativami a důsledky a ledger ho zaznamenává jako navržené ve 12:55:12. Agent ho nepřijal, protože přijetí je úkon člověka. Poslední handover té úlohy uvádí jako další krok přijetí nebo úpravu ADR-0001 a majordomus adr list ho stále ukazuje jako návrh. Samotné rozhodnutí je na webu vidět: stránka důkazů a stránka metod vykreslují hodnocení z ledgeru, který popisuje.

Co dozor zachytil

Nálezy na této stránce se generují ze záznamů, nepíšou se ručně. Exportní skript deklaruje, co hledat, a nález zveřejní, jen když ho potvrdí ledger, handover, checkpoint nebo data pipeline. Každá karta odkazuje na své doklady v časové ose. Popořadě:

• Odchylka od rozsahu po přesunu souborů. První úloha si nárokovala 20 cest, ale ne kořenové soubory přesunuté do adresářů pro dílo a statické soubory. Handover zaznamenává, že odchylku nahlásil majordomus watch. Úloha skončila jako partial 2 minuty 53 sekund po startu a restartovala se s rozsahem, který tyto soubory jmenoval.
• Rozsah „.“ před prvním pushem. Restartovaná úloha zadala jako rozsah jedinou tečku. Majordomus ji nečte jako celý repozitář, takže majordomus check nahlásil každý změněný soubor jako mimo rozsah. Úloha se v 10:39:39 restartovala s 26 výslovně vyjmenovanými cestami. První push přišel asi o tři minuty později a jeho pipeline prošla všemi sedmi joby.
• Zadání, které přerostlo rozsah. Když se práce rozrostla o workspace v Rustu, datové soubory a nástroje pro Python, handover zaznamenal, že nové cesty nejvyšší úrovně leží mimo nárokovaný rozsah. Nová úloha si nárokovala 31 cest.
• Výjimka z rulesetu. Checkpoint zapsaný po prvním pushi zaznamenává, že push prošel přes výjimku pro administrátora v rulesetu, který na main vyžaduje CI. Samotné nasazení zůstalo podmíněné závislostmi jobů ve workflow. Tohle se zaznamenalo, ne zabránilo.
• Dokončení jen s kontrolou živého webu. Obě úlohy uzavřené jako dokončené spustily jako ověřovací příkaz smoke test produkce a oba skončily kódem 0. Tři úlohy ukončené jako partial žádné dokončení netvrdily.
• Neúspěšná kontrola referencí zastavila nasazení. Tohle zachytilo CI, ne Majordomus. Běh 34842607207 selhal v jobu References (Crossref) a Deploy, Verify production i Release se přeskočily. Následovala oprava porovnávání názvů (commit 94d734c) a další běh publikoval ve 12:24:28 vydání v0.3.0, sedm minut po startu neúspěšného běhu.
• Neúspěšné ověření produkce. Opět CI. Běh 34860959250 nasadil build a pak selhal ve Verify production, když jeden z 84 prohlížečových testů proti živému webu vypršel; Release se přeskočil. Protože ověření živého webu potřebuje nasazení, zůstal neověřený build online až do dalšího běhu. Navazující commit udělal z tohoto testu deterministický a další běh, pro pozdější commit, který ho obsahoval, prošel a publikoval v0.6.0.
• ADR ponechané člověku. Popsáno v oddílu o rozhodnutích a ADR.

Tři události zmiňované v jiných popisech této dodávky mezi nálezy nejsou, protože je záznamy nepotvrzují: kontrola zdraví v pre-commit hooku, která měla upozornit, že README neodkazuje na bootstrap pro agenty, příkaz finish odmítnutý do doby, než existoval handover, a závislost pravidla, kterou resolver odmítal, dokud nebyla zapsána jako odkaz id@version. Odmítnutí se do ledgeru nezapisují a žádná z těch tří událostí se neobjevuje v handoveru, checkpointu ani commitu. Mohly se stát; tato stránka je nepočítá.

Kontinuita při restartech a souběžných pracovnících

Restart úlohy byl v zaznamenaném čase levný. Mezi handoverem, ukončením jako partial a dalším startem ledger nikdy neukazuje víc než dvě sekundy. Začalo šest úloh a tři z nich byly restarty. Levné je dělalo to, že stav žil v souborech, ne v konverzaci agenta. Handover nese cíl, aktuální stav a další krok spolu s poli spočítanými z Gitu (větev, commit, čistý nebo změněný strom, změněné soubory), která autor psát nesmí. Politika navíc nechává hooky sezení zapsat briefing při startu epizody, odvozený checkpoint při kompakci konverzace a záznam pro navázání, když epizoda skončí s dosud aktivní úlohou.

Později během dne dodávka prověřila těžší případ: několik pracovníků na jednom checkoutu současně. Na konci snímku je aktivní jedna úloha. Začala ve 14:54:07 UTC a nárokuje si 31 cest, tedy celý pracovní strom. Uvnitř ní pracovali zároveň obsahoví agenti, druhé sezení Claude a hlavní sezení, každý s určením, které soubory jsou jeho. Tuto stránku napsal jeden z těchto pracovníků, který měl zakázáno úlohy startovat, checkpointovat, předávat nebo dokončovat a upravovat soubory ostatních.

Takové uspořádání odhaluje limit. Majordomus vymezuje práci po úlohách a po checkoutech. Uvnitř jednoho checkoutu sdílejí souběžní pracovníci aktivní úlohu a Majordomus nerozliší, kdo změnil který soubor. Koordinace vycházela z výslovného rozdělení cest v zadání každého pracovníka a z Gitu. Převzatý základ formuluje odpověď Majordomu jako principy: jeden pracovník, jeden rozsah, rozsah nárokovaný jiným worktree jako hranice a souběžná práce navzájem izolovaná. Tato dodávka je uvnitř jednoho checkoutu neuplatnila.

Doklady o dodávce

Vše v tomto oddílu je odkazované a časovou osu lze vyfiltrovat jen na commity, běhy pipeline nebo vydání.

• Commity. Každý předmět commitu je Conventional Commit. První, plakát, nese čas 09:54:05 UTC, sekundu před vytvořením repozitáře na GitHubu; web následoval v 10:42:45.
• Běhy pipeline. První běh Pages začal v 10:43:02 a skončil v 10:45:45 se sedmi joby, které všechny prošly. Pozdější běhy narostly na deset jobů, jak do CI přibyly testy v Pythonu, job pro Rust a kontrola v Crossrefu. Dva z prvních sedmi běhů selhaly a obě selhání jsou uvedena i s tím, co následovalo.
• Vydání. Vydání v0.1.0 bylo publikováno v 10:45:42 po ověření živého webu: 51 minut 37 sekund po prvním commitu a 19 minut 19 sekund po inicializaci Majordomu. Vydání v0.2.0 až v0.5.0 následovala do 13:07:10, každé vytvořené jobem Release v běhu, jehož ověření produkce prošlo.
• Dokončené úlohy. Obě dokončené úlohy mají v ledgeru uložený ověřovací příkaz, návratový kód 0 a dobu běhu.

Dvě smyčky lze změřit přímo. Od commitu webu k publikovanému v0.1.0 uplynuly 2 minuty 57 sekund. Od startu běhu, který selhal na referencích, k publikovanému v0.3.0 uplynulo 7 minut 9 sekund. Primárními záznamy jsou stránka vydání a běhy workflow Pages; tatáž data čte gh run list.

Co to stálo a co to nevyřešilo

Tření. Tři ze šesti úloh skončily jako partial a restartovaly se kvůli tomu, jak byl zadaný jejich rozsah. Dva z těchto restartů proběhly během prvních čtrnácti minut dozoru. Rozsah je nutné psát jako výslovné cesty nejvyšší úrovně a rozrostlé zadání v této dodávce znamenalo úlohu uzavřít a otevřít novou, což odpovídá principu převzatého základu nárokovat cesty při startu úlohy místo tichého rozšiřování rozsahu. Samotné záznamy stály pozornost: sedm checkpointů, čtyři handovery a čtyři rozhodnutí mezi 10:26 a 13:08 UTC a k tomu úloha, která následovala. A protože smlouva o dokončení odmítá výsledek completed bez úspěšného ověřovacího příkazu, nešlo úlohu uzavřít jako dokončenou dřív, než pipeline nasadila a živý web odpověděl.

Co Majordomus nekontroloval.

• Zda je obsah pravdivý, dobře podložený a bezpečně formulovaný. To patří validátorům projektu a recenzentovi.
• Zda je ověřovací příkaz přiměřený. Smlouva kontroluje, že příkaz proběhl a skončil nulou; volba smoke testu živého webu byla rozhodnutím agenta.
• Zda testy dávají smysl a zda je padající test nestabilní, nebo odhaluje skutečnou chybu.
• Kdo co udělal uvnitř jednoho checkoutu sdíleného souběžnými pracovníky.
• Šest projektových pravidel, která vypisuje, ale nevynucuje.

Co záznamy ukázat nemohou. Odmítnuté příkazy v ledgeru nejsou. Čas, který člověk strávil čtením, rozhodováním a psaním zadání, se nikde nezaznamenává. Doby závisí na hardwaru, síti a frontě CI. A protože vedle Majordomu běžely běžné pojistky (lokální validace, prohlížečové testy, brány CI a rulesety), jejich účinky tu oddělit nelze.

Co se podle záznamů změnilo. Každé tvrzení o dokončení v tomto projektu je svázané se zaznamenaným příkazem a jeho návratovým kódem. Chyby v rozsahu se ukázaly lokálně, před jakýmkoli pushem, a ne jako neúspěšné běhy pipeline. A stav potřebný k navázání práce ležel v souborech, které mohl přečíst nový pracovník, což je mimochodem i to, co umožnilo tuto případovou studii napsat.

Jak to zopakovat

Záznamy jsou ve veřejném repozitáři s výjimkou .ai/local/, který checkout nikdy neopouští. Ve vlastním klonu je prozkoumáte takto:

1. Nainstalujte Majordomus z majordomus.dev a spusťte npm ci, aby byly hooky aktivní.
2. Zkontrolujte vrstvu příkazem majordomus doctor, platná pravidla vypište příkazem majordomus rules list a architektonická rozhodnutí příkazem majordomus adr list.
3. Historii pipeline přečtěte příkazem gh run list a životní cyklus úlohy v souboru .ai/repo/workflows/task-lifecycle.md.
4. V checkoutu s vlastním ledgerem ho vypíše majordomus history a python3 scripts/export-case-study.py znovu vytvoří snímek, ze kterého tato stránka vychází. S volbou pro kontrolu tentýž skript ověří commitnutý snímek bez lokálního stavu a bez přístupu k síti, a přesně tak s ním zachází CI.

Formát snímku, co obsahuje a co vynechává, popisuje docs/CASE-STUDY.md. Jak vznikal zbytek webu, vysvětlují technické články.