Zdůvodnění
Worker, který něco zahájil a čeká na to, se může mýlit třemi způsoby a jen jeden vypadá jako selhání. Může čekat na něco, co už skončilo — výsledek ležel nespotřebovaný, zatímco worker nečinně seděl, což výpadek terminálového fokusu 2026-09-10 způsobil čtyřikrát za jediný večer. Může čekat na něco, co zemřelo — potomek je pryč, žádný výsledek nikdy nedorazí a čekání se stalo trvalým. Nebo může čekat na něco, co skutečně ještě pracuje, což je jediný případ, kdy je čekání správné.
Zevnitř čekání jsou tyto tři případy nerozlišitelné, protože všechny tři vytvářejí stejné pozorování: nic nového. Absence výstupu není důkazem o žádném z nich. Worker, který klid bere jako pokrok, bude u prvních dvou případů čekat věčně, a tento repozitář to viděl: derivace, jejíž druhá fáze minuty nic nevypíše, vypadá přesně jako přerušený běh a agent, který už byl zabit, nějakou dobu vypadal přesně jako agent, který přemýšlí.
Repozitář už odmítá stejnou úvahu o verdiktech — kontrola, která nehlásila, je neznámá, nikdy ne úspěšná. To pravidlo řídí, jak se čte chybějící verdikt dokončeného běhu. Toto pravidlo řídí živý případ: co musí worker zařídit dřív, než začne čekat, aby se ticho stalo otázkou, na kterou umí odpovědět, a ne stavem, který může jen snášet.
Uspořádání je levné a je třeba je udělat předem. Jakmile je worker zablokován na příkazu v popředí bez timeoutu, už není kam obnovu umístit.
Požadované chování
Každé čekání nese tři věci: timeout, aby skončilo; predikát dokončení nad skutečným stavem, aby rozlišil hotovo od ticha; a cestu zotavení, aby dosažení timeoutu vedlo jinam než k zastavení.
Nic se nespouští bez podmínky dokončení. Podproces, pracovník na pozadí, delegát, sada testů, build či externí příkaz se spouští spolu s odpovědí na to, jak bude jeho dokončení pozorováno — exit status, soubor, značka, zpráva. Zachovej identifikátor, který to umožňuje: pid, id běhu, id úlohy, výstupní cestu.
Ticho se prověřuje, neinterpretuje. Kde operace v očekávaném intervalu nevykáže žádný pozorovatelný pokrok, worker se podívá: na proces a jeho potomky, na výstupní a logové soubory, na artefakty stavu. Zjistí, zda práce postupuje, skončila, nebo je mrtvá, a jedná podle toho, co našel. Zejména zkontroluje, zda výsledek, na který čeká, už nedorazil a jen nebyl spotřebován, protože to je ze tří možností nejlevnější na opravu a nejsnáze přehlédnutelné.
Žádné neomezené čekání na popředí. Příkaz, který může blokovat, dostane timeout nebo běží pod něčím, co ho dohlíží. Výstup se zachytává, místo aby zůstal v terminálu, aby otázka „co to řeklo“ přežila čekání.
Chování při selhání
scripts/liveness-check čte každý sledovaný shellový soubor a hlásí dva tvary tohoto pravidla. Síťové volání bez meze, jak dlouho smí blokovat — curl bez --max-time, -m nebo --connect-timeout, na pozici příkazu — je nález unbounded-network: smyčka opakování, jejíž tělo může čekat navždy, není omezená. Proces poslaný na pozadí, jehož dokončení nic nezaznamená v následujících šesti příkazech, je nález unsupervised-spawn: nic nezachytí $! a nic nečeká, takže práce je spuštěna tam, kde ji žádný predikát nikdy nerozhodne. Kontrola běží always: true v úloze structure a dluh, který existoval při jejím nasazení, je uveden v .ai/repo/liveness-baseline.txt jako path:class; nález mimo ten seznam selže a hlásí se i řádek základu, který už neodpovídá ničemu, takže ratchet se utahuje, nehnije.
Co sken nevidí, zůstává revizi: čekání uvnitř programu v Rustu, obnovovací cesta, která existuje, ale je chybná, a predikát dokončení, který čte špatnou věc. Sken rozhoduje o tvarech, které jmenuje; ostatní nepotvrzuje.
Ověření
scripts/liveness-check, kontrolované v jobu structure a testované mutací v test/cases/122_liveness_gate.sh; test/cases/121_liveness_doctrine.sh drží třídu a blok vynucování tohoto pravidla. Následné ADR 0039 jmenované je hotovo: toto pravidlo se rozhoduje svým skenem, ne revizí.