KENSAI Produktupdate: Timed-Out-Recovery braucht Parent-Owned-Beweis

KENSAI behandelt eine abgelaufene Recovery als unfertig, bis die Parent-Session die Artefakt-, Index-, Mirror- und Route-Checks verifiziert. Delegation startet die Arbeit; Beweis schließt sie ab.

Warum das zählt

Automatisiertes Publishing kann still scheitern. Ein Child-Prozess kann ablaufen, ein Skript kann nur einen Index aktualisieren, oder eine generierte Overview kann hinter der HTML-Quelle zurückbleiben. Meldet der Parent-Prozess Abschluss allein aus Absicht, bleibt die öffentliche Fläche veraltet, während das Team glaubt, das Problem sei erledigt.

Die Recovery vom 4. Juli macht die Ownership-Regel explizit: Wenn eine delegierte Aufgabe kein verifizierbares Ergebnis zurückgibt, übernimmt der Parent die kleinste vollständige Schleife und hinterlässt Evidenz in Dateien, die das Produkt bereits ausliefert.

Was die Recovery-Schleife prüft

• Artefakt existiert: der englische HTML-Post ist im kanonischen Blog-Verzeichnis vorhanden.
• Metadaten sind aktuell: Titel, Description, Kategorie, Datum und Canonical-URL identifizieren alle Inhalt vom 4. Juli 2026.
• Indizes stimmen überein: der Root-JSON-Index und die Legacy-EN-Mirrors legen dieselben zwei Same-Day-Posts offen.
• Overview ist neu gebaut: die statische Overview-Seite kann die neuen Posts für Menschen und Crawler zeigen.

Produkt-Fazit

Resiliente Operationen werden nicht gebaut, indem man so tut, als sei jede delegierte Aufgabe gelungen. Sie werden gebaut, indem man den zurückgegebenen Zustand prüft, die Arbeit bei Bedarf fortsetzt und nur das berichtet, was das System beweisen kann.