Eine Write-Loop, die niemals etwas merged

Eine Zeit lang war die Memory-Layer meines Homelabs ein hervorragender Beobachter. Sie konnte mir sagen, wenn ein Decision Record veraltet war, wenn ein dokumentierter Service nicht mit dem laufenden übereinstimmte oder wenn eine Annahme widersprochen wurde. Dann hörte sie damit auf, weil das Einzige, was nach dem Feststellen passierte, war, dass ich einen Report las.

Genau an diesem Punkt geht selbstgehostete Automatisierung meistens schief, deshalb will ich genau erklären, was ich gebaut habe – und was nicht.

Erkennen, vorschlagen, genehmigen, handeln

Jeder Analystenfund wird auf einen typisierten Vorschlag abgebildet:

Fund	Vorschlag	Was die Genehmigung bewirkt
veraltete Entscheidung	Supersession-Entwurf	legt eine Drafting-Task an
undokumentiertes Subjekt	Doku-Task	legt eine Docs-Task an
deklarierte vs. beobachtete Abweichung	Reconciliation	legt eine Placement-Task an
widersprochene Tatsache	Fact Reconciliation	füllt eine Correction-Queue, die selbst nochmal separat freigegeben wird

Die letzte Zeile ist die spannende. Eine genehmigte Fact Reconciliation ändert keine Tatsache. Sie erhält das Recht, als Fact Change vorgeschlagen zu werden, den dann wieder ein Mensch genehmigt. Zwei Gates, bevor sich ein gespeicherter Glaube bewegt.

Drei Einschränkungen, die es sicher machen

Belegt oder verworfen. Ein Vorschlag ohne Zitat wird blockiert und gezählt, aber nie vorgeschlagen. Gleiche Regel wie überall sonst im System.

Begrenztes Fan-out, partitioniert nach Co-Location. Maximal ein Vorschlag pro Subjekt und Typ. Ohne diese Regel würde ein einzelnes Host-Problem zu einem Vorschlag pro Service auf diesem Host führen, und du hättest eine Queue mit hundert Einträgen für ein einziges Problem. Das Limit liegt bei 25.

Zweistufig, niemals automatisch angewendet. Detection ist ein reiner Read. Queueing hängt eine git-ignorierte Pending-Datei an. Nur ein explizites Approve-with-Apply schreibt in die Commit-Schicht – und die Commit-Schicht ist eine Knowledge-Taskliste, keine Infrastruktur.

Das entscheidende Merkmal des Executors

Der letzte Schritt verwandelt einen genehmigten Vorschlag in einen Branch, einen Commit und einen Draft Pull Request, der niemals gemerged wird. Das ist keine Einschränkung, die ich aufheben will; das ist das Produkt.

Standardmäßig ist das Feature hinter einem Environment-Flag deaktiviert, weigert sich, bestehende Dateien zu überschreiben, fügt immer nur eine neue Markdown-Datei hinzu und fasst niemals Compose-Files, Container oder Hosts an. Die komplette Kette vom Erkennen bis zum gemergten Change durchläuft vier menschliche Gates.

Ich habe das einmal live getestet, bei einem echten Fund zu einem Backup-Repository. Es hat den PR eröffnet. Es hat den PR nicht gemerged. Beide Hälften dieses Satzes waren der Test.

Warum nicht einfach automatisch anwenden

Weil der Wert der Schleife darin liegt, dass sie bemerkt – und Bemerken ist günstig zu überprüfen, während Handeln teuer rückgängig zu machen ist. Der Engpass in meinem Homelab war nie meine Fähigkeit, Änderungen durchzuführen. Es war das Wissen, welche Änderungen nötig sind. Den Teil zu automatisieren, in dem ich gut bin, um den Teil zu sparen, in dem ich schlecht bin, wäre der falsche Trade gewesen.

Ein System, das mir jeden Morgen zuverlässig fünf korrekte, zitierte, mit einem Klick überprüfbare Tasks liefert, gibt mir bereits den Großteil des Werts, den volle Autonomie verspricht – bei einem Bruchteil des Blast Radius.