# Aus einem roten Check kann ein geprüfter Fix werden.

> Wenn ein geeigneter Check fehlschlägt, kann Hive einen begrenzten Coding-Agenten starten — Run, Logs, Diff und Testergebnisse sind bereits dabei. Der Kandidat landet auf Ihrem Branch; das nächste Gate entscheidet, ob er funktioniert.

Source: https://hiveci.io/de/self-healing-ci
Language: de
Alternate: https://hiveci.io/self-healing-ci

Autofix wird je Check bewusst aktiviert. Infrastrukturfehler und Timeouts verbrauchen keinen Agenten-Run.
## Die Fehlerbelege reisen mit der Arbeit.
Kein Ritual aus kopierten Logs und kein abgetrennter Chat. Run, Agent und prüfendes Gate bilden eine nachvollziehbare Kette.
1. **Ein deklarierter Check scheitert** — Hive klassifiziert den Fehler und materialisiert nur dann einen Fixer, wenn der Schritt ihn aktiviert hat und die Richtlinie ihn erlaubt.
2. **Die Belege sind schon da** — Der Agent liest Task, begrenzte Logs, benannte Tests, Branch-Diff und frühere verifizierte Fixes direkt.
3. **Ein Kandidat entsteht** — Der Agent arbeitet in einer isolierten Umgebung. Der Wrapper kontrolliert Umfang, Budget, Prüfung und Git-Lieferung.
4. **Das Branch-Gate läuft erneut** — Der gepushte Kandidat löst einen frischen Run aus. Dieser Run — nicht die Prosa des Agenten — entscheidet über den Merge.
## Ein Fixer ist ein Schritt, den Sie deklarieren. Von selbst weckt nichts einen.
Zwei Zeilen in der Pipeline-Datei, und sie sind der ganze Vertrag.
fix_step benennt einen ruhenden Agenten-Schritt; on_failure hängt ihn an genau ein Ziel. Ein Schritt ohne on_failure weckt nie einen Agenten, und eine Pipeline ohne deklarierten Fixer hat keinen Autofix — es gibt nichts abzuschalten.
Der Fixer muss existieren, genau einen Task reparieren und keine eigenen Abhängigkeiten haben. Alles andere weist die Pipeline-Sprache bei der Auswertung zurück, bevor ein Run entsteht.
```starlark
fixer = fix_step(target = "test")          # @hive//factory.star (agent, dormant)
hive.pipeline(name = "pr-checks", on = [hive.on.pull_request(branches=["main"])],
    steps = [
        hive.step(name = "test", image = CI, run = "go test ./...", on_failure = fixer),
        fixer,
    ])
```
Aus dem Autofix-Vertrag der Pipeline. Ohne on_failure schlägt der Schritt einfach am Gate fehl.
## Drei Schritte, ein Branch, nichts vom Agenten gemergt.
Derselbe Run wie im Hero, zu Ende verfolgt — aufgenommen aus dem eingecheckten Fixture-Set, also eine gestaltete Geschichte statt des Branches eines Kunden.
1. Run #4821 scheitert an test-2 mit drei benannten Tests; das Diagnose-Panel sagt, welche und warum.
2. Der Fixer erneuert die veralteten Order-Fixtures, lässt pytest bis 1262 grün laufen, pusht und öffnet einen Pull Request mit der Ursache.
3. Der Push löst einen frischen Run auf dem Branch-Head aus. Dieser Run — nicht die Zusammenfassung des Agenten — macht den Check grün, und Ihre Merge-Regeln entscheiden weiterhin.
## Geben Sie dem Modell Belege, keine Textwand.
Hive kompiliert aus eigenen Fakten ein begrenztes Aufgabenbriefing und stellt schmale Werkzeuge für die nächsten benötigten Belege bereit.
- **Fehler mit Namen** — Fehlgeschlagene Tasks, geparste Testergebnisse, Reports und begrenzte Log-Enden kommen strukturiert an.
- **Das exakte Branch-Delta** — Auslösender SHA und Diff halten den Agenten bei dem Fehler, der wirklich passiert ist.
- **Verifizierte Fixes statt Hörensagen** — Ähnliche frühere Ergebnisse erscheinen nur, wenn ein späteres Gate sie als grün bewiesen hat.
- **Aufrufe statt kopierter Seiten** — Der Agent untersucht aktuellen Run und ausgewählte Checks über geprüfte Fähigkeiten.
- **Budgets außerhalb des Prompts** — Turn-, Token-, Umfangs- und Lieferregeln erzwingt ein Wrapper, den das Modell nicht umschreiben kann.
- **Belege vor Lieferung** — Ein Kandidat muss den konfigurierten Verifier der Lane bestehen, bevor der Wrapper ihn liefern darf.
## Selbstheilend heißt nicht selbstautorisierend.
Die Automatisierung handelt innerhalb der Grenzen, die Pipeline und Plattform-Richtlinie festlegen.
- **Sie wählen die Checks, die einen Agenten wecken.** — Ein neuer Schritt hat standardmäßig keinen Fixer. Eine Laufzeit-Richtlinie kann einen problematischen Fixer ohne Pipeline-Änderung unterdrücken.
- **Der Kandidat muss CI weiterhin bestehen.** — Scheitert der Fixer, überschreitet er Grenzen oder kann er seine Arbeit nicht prüfen, bleibt der ursprüngliche Fehler bestehen.
- **Der normale Branch-Ablauf bleibt bestehen.** — Hive pusht einen Kandidaten auf den Branch. Pflicht-Checks, Review-Regeln und Merge-Richtlinie bleiben maßgeblich.
## Was ein Fixer nicht tut.
Jede Zeile ist eine Regel, die der Wrapper erzwingt — kein Versprechen, das das Modell halten soll.
| | |
|---|---|
| Keine Aktivierung, kein Fixer | Ein Schritt ohne on_failure weckt nie einen Agenten. Für jeden neuen Schritt und jede Pipeline gilt: kein Autofix, nichts abzuschalten. |
| Infrastruktur | Timeouts, Runner-Verlust und erkannte Infrastrukturfehler wecken nie einen Fixer. Nur ein Fehler, der nach Code-Arbeit aussieht. |
| Der eigene Commit | Der Push eines Fixers weckt nie einen weiteren Fixer, sodass ein falscher Kandidat keine Schleife starten kann. |
| Budget und Dauer-Rot | Turn- und Token-Budgets werden außerhalb des Prompts erzwungen, und ein Schritt, der über Kandidaten hinweg rot bleibt, verbraucht keine weiteren Agenten-Runs. |
| Eingriff des Betreibers | Eine Laufzeit-Richtlinie kann einen problematischen Fixer ohne Pipeline-Änderung unterdrücken — und ihn auf demselben Weg wieder freigeben. |
## Die Reparatur-Schleife ist eine Lane in einem größeren Agenten-System.
- **Agenten selbst steuern** — Workstation- und Cloud-Sessions starten, im Browser lenken und Branch- sowie CI-Status sehen.
- **Den CI/CD-Kern ansehen** — Pipelines, Runner, warme Caches, verwaltete Testdatenbanken und die API unter der Reparatur-Schleife.
## Bringen Sie ein Repository mit. Sehen Sie das ganze System arbeiten.
Starten Sie auf Ihrem eigenen Runner, lassen Sie Ihre bestehende CI daneben weiterlaufen und sehen Sie, wie Hive aus dem nächsten geeigneten roten Check einen prüfbaren Fix macht.