T2 — Governor-Agent — aktueller Stand

1:1-Spiegel aus dem Repo

Quelle: comms/T2_AKTUELL.md · Stand der Quelldatei: 09.08.2026 21:33 · erzeugt: 14.08.2026 00:33 Diese Seite ist eine wortgetreue Kopie. Geaendert wird immer die Quelldatei, nie diese Seite.

Sprint: 3 (Agenten-Runtime) · Auftrag T2-01 R5 WD-Haertung B5/B6 · UEBERNOMMEN 2026-08-09 20:10 · ZURUECKGEGEBEN 2026-08-09 21:40

MELDUNG T2 · T2-01 · Runde 5 · 2026-08-09 ~21:40 · STOPP

T2 AKTUELL · Runde 5: WD-Haertung B5 + WD-Registrierung B6 — GEBAUT, GEPRUEFT, LIVE

W6-WD v0.2.3 ist publiziert und laeuft (aktive Version 2db41818, vorher 3fe4be51 = v0.2.2, 41 Knoten). Gate-Report mit allen Belegen: ablauf/T2-01_governor-agent/GATE_5.md · Spezifikation und Rechenwege: SPEZ_WD_HAERTUNG_v1.1.md.

Erledigt

Die Ursache der Fehlabschaltungen war eine einzige Zeile — aber sie war nicht die einzige Fehlfunktion.

1. Mitternachts-Luecke (B5). Weder die Zaehlung noch die Dedupe-Funktion waren tagesgebunden: errors_24h ist ueber v_gov_digest bereits ein rollierendes 24-h-Fenster, w6a_alert_seen prueft ein Zeitfenster ab Ack-Erteilung. Tagesgebunden war allein die Signatur: new Date().toISOString().slice(0,10) liefert das UTC-Datum — der Workflow-Timezone Europe/Berlin wirkt dort nicht. Um 00:00 UTC entstand eine neue Signatur, die Dedupe musste false liefern, der Befund galt als frisch. Alle drei Vorfaelle liegen im ersten Takt nach UTC-Mitternacht (gov 37 · 43/44 · 49/50). Behoben, indem die Datumsstelle entfaellt statt umgerechnet zu werden — das ist G's Variante (a).

2. Der schwerere Befund: „fail_streak" war gar kein Streak. Die Schwelle 3 ist eine absolute Anzahl in 24 h. Zum Abschaltzeitpunkt am 08.08. hatte EIA 87 erfolgreiche von 97 Laeufen (10,3 % Fehlerquote) — und wurde abgeschaltet. Am 07.08. waren es 95 von 98 (3,1 %). VKA: 19 von 23. Bei 96 Laeufen/Tag misst die Schwelle die Taktrate, nicht die Gesundheit.

3. F21 — der Not-Aus fuettert die Abschaltautomatik (neuer Befund, Wurzel liegt ausserhalb meiner Zone). Ein vom Kill-Switch korrekt geblockter Lauf wird als status='error' gebucht (runs 303/424). Agent aus → jeder Takt bucht einen „Fehler" → naechste Abschaltung. Der CHECK auf agent_runs.status erlaubt ('running','ok','partial','error'); errors_24h zaehlt nur 'error'. Der Fix ist ein Wort: geblockte Laeufe als partial buchen.

Gebaut (v0.2.3): Signatur ohne Datum · Werkzeuge (kind='werkzeug') erzeugen gar keinen Befund mehr · Auto-Disable nur noch bei echtem Totalausfall (kein einziger erfolgreicher Lauf in 24 h) mit Mindestbeleg 4 Laeufe, Schalter an, kein Not-Aus, kein Werkzeug, nicht der Waechter selbst · Zwei-Takte-Regel: erst Vorwarnung, Vollzug erst im Folgetakt · Gate Schalter pruefen (G1) auf w6.agents.enabled UND w6.wd.enabled · Registry-Zeile wd + Laufbuchung in agent_runs (Status ok/partial, nie error).

Gegenprobe an der Historie: in allen vier Vorfaellen ist die Erfolgs-Bedingung verletzt → beide Fehlabschaltungen waeren mit v0.2.3 nicht passiert, ein echter Totalausfall fuehrt weiterhin zur Abschaltung.

Beweis	Beleg
H1 — der Vorfall vom 08.08. exakt nachgestellt (EIA 10/97 · VKA 4/23 · gread 3/19 werkzeug · BMA 3/3), also „522-Fenster + Tageswechsel + Werkzeugfehler" in einem Takt	exec 8993: 3 Befunde gemeldet, gread ohne Befund, targets: [] — keine Abschaltung
H2a/H2b — echter Totalausfall 8/8: erst Vorwarnung, dann Vollzug	8991 (targets: [], „VORWARNUNG …") → 8992 (targets:[{eia}], ADMIN-Aufruf, Mail nennt den Vollzug)
H3 — globaler Not-Aus	8994: G1:kill_switch(global), Befunde bilden lief nicht, Lauf als partial gebucht
H4 — Odoo nicht erreichbar (522)	8997: „ok (eingeschraenkt: Schalterlage nicht lesbar - kein Auto-Disable)", kein Eingriff
H5 — Waechter selbst 48/48 Fehler	8996: „Waechter schaltet sich nicht selbst ab"
H6 — alles gruen · H8 — Schluessel fehlen	8987 (still) · 8995 (Anlaufschutz, Schutz bleibt wirksam)
Betriebsprobe live, zwei Takte	exec 9000 (19:00:47Z) gruen · agent_runs run 502, agent wd, status ok, „0 neue(r) Befund(e) · ok (Anlaufschutz: w6.wd.enabled fehlt in Odoo)" · nach fix3 run 506 (19:30:47–19:30:49) gruen und icp_checked_at aller Agenten wieder auf 19:30:49 = Spiegel schreibt nachweislich wieder

Der Harness ist vollstaendig inert: Trigger-, HTTP-, Gmail- und ADMIN-Knoten sind gepinnt — es wurde nichts versendet, nichts geschaltet, nichts geschrieben.

Subagent-Review nach D-063 vor der Abgabe gefahren; Urteil war „nicht publizierbar" — zu Recht. Wichtigster Punkt: h.runs_24h || 0 haette bei fehlender Laufzahl „0 Erfolge" ergeben und damit abgeschaltet — die einzige Stelle, an der eine fehlende Information in Richtung Eingriff aufloeste. Jetzt gilt durchgehend: fehlende Information sperrt den Eingriff, sie loest ihn nie aus. Ebenfalls behoben: Dedupe sperrte den Disable-Pfad 24 h · kind-Fallback bei unlesbarer Config · fehlender globaler Schluessel haette den Waechter dauerhaft selbst geblockt · kein run_end bei hartem Mailfehler. Die Zwei-Takte-Regel ist aus diesem Review entstanden.

Eigene Regression im Livelauf gefunden und behoben. Durch das neue Gate wurde Weiterlaufen? zum Vorgaenger von ICP-Spiegel (CP), dessen Body $json.icps las → p_values undefiniert → PostgREST PGRST202 → der Spiegel schrieb still nichts mehr (neverError:true). Aufgefallen nur daran, dass icp_checked_at beim 19:00-Takt auf 18:30:49 stehen blieb. Behoben in fix3 (Body zieht die Karte benannt), publiziert als 2db41818; Gegenpruefung ueber alle 41 Knoten: das war der einzige betroffene.

Zustand

WD v0.2.3 aktiv (2db41818), 30-min-Takt und Digest 07:30 unveraendert. Registry: neue Zeile wd (kind=agent, stage 1, w6.wd.enabled, alle 30 min) — der Waechter hat ab jetzt Kachel, Herzschlag und Laufhistorie; der Schalter fehlt noch in Odoo (Anlaufschutz greift). EIA/VKA laufen unveraendert weiter (eia=1, vka=1, bma=0). Kein Agent wurde geschaltet, keine Mail versendet, kein Odoo-Write.

Uebergaben

An M — ein Handgriff: Systemparameter w6.wd.enabled = 1 in Odoo anlegen (Einstellungen → Technisch → Systemparameter). Danach ist B6 vollstaendig; bis dahin laeuft der Waechter im Anlaufschutz und sagt das in jedem Lauf.

An G — vier Entscheide (Details in GATE_5.md §6): 1. F21 an der Wurzel schliessen: geblockte Laeufe in EIA/VKA/GRT-1 als partial statt error buchen. Ein Wort je Flow. Solange das offen ist, bleibt „Agent war lange aus" der einzige Weg, auf dem die 24-h-Quote noch kippen kann — die Zwei-Takte-Regel faengt genau das ab, heilt es aber nicht. 2. Verhalten bei globalem Not-Aus bestaetigen: gebaut ist „Gate prueft beide" wie beauftragt — waehrend eines Not-Aus laeuft damit keine Ueberwachung (kein stale_run/dead_job-Alarm). Folgt LIES_MICH_ZUERST, ist aber eine bewusste Entscheidung und keine Nebenwirkung. Bestaetigen oder Ausnahme fuer den Waechter beschliessen. 3. Nachlieferung einspielen? Der SQL-Wortlaut fuer public.w6a_fail_profile(p_hours) liegt fertig in SPEZ §4 (rein additiv, read-only, klassifiziert geblockt/transient/vollzug, liefert letzter_erfolg). Nicht eingespielt — Migrationen sind G's Akt und die Nummer (v0_9_13) muss mit T5 abgestimmt sein. Mit ihr liefere ich v0.2.4 mit G's Original-Wortlaut („6-h-Fenster", „>=3 aufeinanderfolgende Stunden"). 4. Grundsatz: fail_streak_disable als Quote statt als absolute Anzahl definieren? Fuer Takt-Agenten ist eine Anzahl konstruktionsbedingt sinnlos (3 Fehler = 3,1 % bei EIA, = 3 Tage Totalausfall bei BMA).

Redaktionell: die Freigabe nennt fuer die Registry schedule 'stuendlich :00'; der Trigger laeuft real alle 30 min — ich habe die Wahrheit eingetragen (alle 30 min). Bitte kurz nicken.

Offen / Naechster Schritt

STOPP. Der publizierte Stand laeuft; die naechsten regulaeren Takte sind die weitere Betriebsprobe. B2 aus der Runde-5-Freigabe (Dedupe-UX fuer human:%) liegt bei T5/RPC und bleibt unveraendert offen; B3 ist durch D-049 gedeckt und hier nur vermerkt.

Befunde

• F21 (hoch, an G): geblockte Laeufe als error gebucht → der Not-Aus erzeugt die Fehlerlawine, die zur naechsten Abschaltung fuehrt. Fix: partial.
• F22 (mittel, an G): fail_streak_disable ist eine absolute Anzahl und damit taktratenabhaengig — 3 Fehler heissen bei EIA 3,1 % Fehlerquote, bei BMA drei Tage Totalausfall.
• F23 (mittel, an G/T5): v_board_header reicht registry.kind nicht durch; der WD kommt nur ueber w6a_agent_config je Kandidat an die Agentenart. Fuer eine Auswertung ueber alle Agenten waere kind in der View der sauberere Ort.
• F24 (niedrig, Betriebswissen): HTTP-Knoten mit neverError:true verschlucken auch Strukturfehler wie PGRST202 — ein Knoten kann monatelang „gruen" laufen und nichts tun. Die eigene Regression heute war genau dieser Fall und wurde nur ueber den fachlichen Nebeneffekt (icp_checked_at stand still) sichtbar. Vorschlag: bei RPC-Knoten die Antwort auf code-Felder pruefen, statt nur den HTTP-Status zu ignorieren.

Abholung: zentral durch G ueber Cowork. Weiter erst nach FREIGABEN-Eintrag; auf »weiter« im Terminal zuerst FREIGABEN.md und comms/G_AKTUELL.md neu lesen.