Selbstverbesserungskreis - Betrieb¶

Stand: 05.10.2026. Ausbau (03.10.2026, Auftrag "Finaler Ausbauauftrag zum kontrolliert selbstverbessernden System"): docs/ausbau/AUSFUEHRUNGSPROTOKOLL.md, docs/ausbau/ledger.json, docs/ausbau/nachweise/. Autonomer Betrieb (04./05.10.2026, Auftrag "Produktionsautonomie"): Abschnitt 9 dieses Dokuments, ops/selfimprove/betrieb/LIESMICH.md, docs/LENNY_PRODUKTIONSAUTONOMIE_ABSCHLUSS.md, docs/produktionsautonomie/.

1. Wer macht was¶

Rolle	Wo	Aufgabe
Zustandsmaschine, Audit, Detektor, Endpunkte	Server (`core/si_state.py`, `si_store.py`, `si_detektor.py`, `si_routes.py`)	19 Zustaende, jeder Wechsel gegen Modus, Admin-Veto, Versuchsgrenze, Parallelitaet und Pflicht-Artefakte geprueft; Audit-Kette (Hash) laesst sich nicht aendern. Der Detektor (alle 15 Minuten) prueft Invarianten (`core/si_invariants.py`) und legt Laeufe an.
Entscheider	Server (`core/si_gate.py`)	Deterministisch: APPROVE nur, wenn alle geforderten Gates gruen sind und das Zielproblem behoben ist. Kein Modell, keine Meinung.
Controller	lokal (`ops/selfimprove/controller.py`)	Fuehrt einen Lauf Schritt fuer Schritt weiter (Dienstkonto `selfimprove`: kein Admin, keine Sperraufhebung). Nichts, was der Server nicht zulaesst.
Autopilot	lokal (`ops/selfimprove/autopilot.py`)	Der Controller ohne Bediener: ein Durchgang fuehrt jeden offenen Lauf mit denselben Schritten weiter (rebase, bau, teste, deploye, naechster Versuch mit Befund). Entscheidet nichts - jeder Schritt ist ein Zustandswechsel, den der Server prueft; verweigert er ihn (Veto, Modus, Parallelitaet), wartet der Lauf. Faengt keinen Bauversuch an, wenn die Coding-KI nicht angemeldet ist. Nicht als Dauerdienst eingerichtet (siehe Abschnitt 8).
Coding-KI	lokal (`agent.py`)	Nur fuer CODE_GAP. Eigener Worktree, bereinigte Umgebung, Allowlist, hoechstens ein Commit-Stapel; kein Zugang zu Produktion, Server oder Schluesseln.
Evaluator + Sandbox	lokal + Server (`evaluator.py`, `sandbox.py`)	Baseline und Kandidat laufen in getrennten Containern auf einer KOPIE der Produktionsdaten; alle Gates; die Produktion bleibt unveraendert (G23).
Deployer	lokal (`deployer.py`)	Rollback-Ziel -> `deploy.sh --commit` (Deploy-Schranke: Tests + core-Grundlinie) -> Health -> Smoke -> Hard Security Checks -> Probation oder sofortiger Rollback.
Watcher	Server-Host (Cron alle 5 Minuten, `si/bin/watcher.py`)	Beobachtet die 24-h-Probation; Hard-Fail -> Rollback, nach 24 h ohne Hard-Fail -> `accepted`. Laeuft ohne Controller.
Administrator	`/v1/admin/selfimprove/*`	Veto (problem, change, candidate, run), Modus, Aufhebung. Nur der Administrator hebt etwas auf.

2. Modi und Obergrenze¶

config/self_improvement_policy.json (Admin, im verbotenen Bereich) setzt die Obergrenze self_improvement_mode; der Administrator setzt den Modus zur Laufzeit (POST /v1/admin/selfimprove/mode mit off|observe|build|deploy und Grund) - wirksam ist nie mehr als die Obergrenze, und kein Kandidat und keine Automatik kann beides aendern.

Modus	erlaubt
off	nichts (Detektor schweigt)
observe	erkennen, klassifizieren, protokollieren
build	zusaetzlich reproduzieren, spezifizieren, Candidate bauen und testen
deploy	zusaetzlich deployen (Produktion)

Weitere Grenzen der Policy: 3 Patch-Versuche je Problem, 1 aktiver CODE-Candidate, 24 h Probation, Absagequote hoechstens +1,0 Prozentpunkte, p95-Latenz und Spitzen-Speicher hoechstens +25 %, keine neuen Laufzeit-Abhaengigkeiten, keine zerstoerende Schema-Migration.

3. Ein Lauf (SIR--)¶

detected -> classified -> reproducing -> specified -> queued -> building -> candidate_ready -> testing -> approved -> deploying -> probation -> accepted
                                         |                                  |                      |                        \-> rolled_back
                                         \-> non_reproducible / unresolved  \-> build_failed       \-> rejected (naechster Versuch mit Befund)
                                         (UNKNOWN: nie reproducing; admin_blocked / policy_blocked jederzeit)

Klasse	Aenderung	Pruefung	Ende
CODE_GAP	Commit der Coding-KI im Scope der Change-Spec (`allowed_scope`, `forbidden_scope` aus der Policy)	alle Gates G1-G28	Deploy, 24 h Probation, dann `accepted`; Hard-Fail -> `rolled_back`
CONFIG_GAP	genau EINE Zeile `LENNY_ENABLE_*=1` in der Compose-Datei (nur EIN, nie AUS)	wie CODE_GAP, der erwartete Antwort-Unterschied ist benannt	Deploy, Zielschalter wirkt -> `accepted` (keine Probation)
DATA_GAP	Belegsatz-Stapel aus dem Luecken-Protokoll (nur strenger Wikipedia-Beleg, `candidate_only`, ohne globalen Stabilitaets-Pass)	G6-G9, G18-G20 in der Sandbox, Rueckweg getestet	Anwendung als Aenderungssatz, Wirkung geprueft -> `accepted`, sonst Rueckweg
RULE_GAP	Regelkandidat im Kreativ-Gehirn	Schattenlauf, Wirkungsmeldungen, `herkunft: kreativ`	wie DATA_GAP
UNKNOWN	keine	-	`unresolved`, nie eine Aenderung

4. Befehle (lokal, im Verzeichnis `ops/`)¶

export SSH_KEY_PATH=/e/Lenny_Hyper/experiments/lenny_language_layer_prototype_v1/deploy/ssh/lenny_deploy_key   # nur fuer deploy/teste
python -m selfimprove.controller status                       # Modus, offene Laeufe, Audit
python -m selfimprove.controller rebase <run>                 # Basis veraltet -> neu reproduzieren und spezifizieren
python -m selfimprove.controller bau <run> [--agent claude-code|scripted|session] [--rezept datei.json]
python -m selfimprove.controller abschliessen <run> --bericht <text> --transkript <jsonl>   # nur agent session: Transkript wird geprueft
python -m selfimprove.controller teste <run>                  # Bewertung in der Server-Sandbox (ca. 25 Minuten)
python -m selfimprove.controller deploye <run>                # Rollback-Ziel, deploy.sh, Pruefungen, Probation/accepted/Rollback
python -m selfimprove.controller versuch <run> --befund "..." # naechster Versuch nach rejected/build_failed
python -m selfimprove.controller wiederoeffne <run> --grund "..."   # unresolved mit NEUER Evidenz erneut oeffnen (Abschnitt 13); der Detektor fuehrt ihn bis queued weiter
python -m selfimprove.controller erkenne-daten                # haeufigste belegbare Definitionsluecke -> DATA_GAP-Lauf
python -m selfimprove.controller erkenne-regel <datei>        # RULE_GAP-Lauf aus {stapel, anfrage, erwartung}
python -m selfimprove.controller export <run>                 # kompletter Verlauf als Nachweisdatei
python -m selfimprove.autopilot [--daten] [--dauer]           # alle offenen Laeufe ohne Bediener weiterfuehren (siehe unten)

Autopilot. Ein Durchgang geht ueber alle offenen Laeufe und bringt jeden so weit, wie er ohne Bediener kommt (bis zu einer Wartestelle, einem Endzustand oder einem Fehler); der Bericht steht als JSON auf der Konsole und in <work>/autopilot.log.jsonl. Exitcode 0 = kein Fehler, 1 = ein Schritt endete mit einem Fehler, 2 = ein anderer Autopilot arbeitet (Schloss <work>/autopilot.lock, nach 6 h als verwaist uebernommen). --daten legt zusaetzlich die haeufigste belegbare Datenluecke als DATA_GAP-Lauf an (nur wenn keiner offen ist); --dauer wiederholt alle 15 Minuten, bis <work>/autopilot.stop existiert. Der Autopilot wartet statt zu scheitern: Modus observe/off (nichts), Modus build (bauen und testen, nicht deployen), ein gesperrter Lauf (wird nicht angefasst), ein anderer aktiver CODE-Kandidat, ein anderer Neustart-Deploy in der Probation, eine nicht angemeldete Coding-KI (der Lauf bleibt in queued, es wird kein Versuch verbraucht). Den Agenten session kennt er nicht - das ist der Weg des Orchestrators von Hand.

Wiederoeffnen (Abschnitt 13). Nach drei verbrauchten Versuchen steht ein Fall auf unresolved und bleibt erhalten; mit NEUER Evidenz darf er erneut geoeffnet werden (wiederoeffne <run> --grund "was ist neu": Uebergang unresolved -> detected mit dem Artefakt neue_evidenz; das Versuchsbudget beginnt neu). Den Weitergang bis queued uebernimmt der Detektor des Servers beim naechsten Durchgang (hoechstens 15 Minuten) - dasselbe gilt fuer einen Lauf, der wegen des Modus off in detected liegen blieb. Ohne Begruendung oeffnet der Controller nichts (keine Endlosschleife); ein vom Administrator gesperrter Lauf bleibt gesperrt.

claude-code startet claude -p im Worktree und braucht eine angemeldete CLI (claude login; ohne Anmeldung meldet der Dispatcher "Failed to authenticate" und beginnt keinen Versuch). session ist die Coding-KI als Subagent einer Sitzung; ihr Transkript wird gegen dieselbe Allowlist geprueft. scripted fuehrt ein eingechecktes Rezept (ops/selfimprove/drills/) aus - nur fuer Selbsttests.

5. Administrator¶

POST /v1/admin/selfimprove/block     {"ziel_art": "problem|change|candidate|run", "ziel": "<id>", "grund": "..."}   -> admin_blocked
POST /v1/admin/selfimprove/unblock   {"ziel_art": ..., "ziel": ..., "grund": ...}                                    -> nur der Administrator
POST /v1/admin/selfimprove/mode      {"modus": "off|observe|build|deploy", "grund": "..."}
GET  /v1/admin/selfimprove           Uebersicht und Admin-Ereignisse

Neue Evidenz zu einem gesperrten Fall wird angehaengt; sie hebt den Block nie auf. Wissenssperren (Fragment, Relation, Zweig) liegen auf einer eigenen Ebene (/v1/admin/sperre*, core/admin_sperre.py): gesperrt heisst Wirkung null in Antwort, Evidenz, Befoerderung, Stabilitaet und Ableitung - gespeichert bleibt alles.

6. Probation und Rollback¶

Marke probation.json im Rollback-Verzeichnis /opt/lenny/v01b/si/rollback/<rb>/; der Watcher schreibt watcher_state.json und meldet dem Kreis.
Sofort-Rollback bei: Tenant-Leck, umgangener Admin-Sperre, verletzter Datenintegritaet, dauerhaft rotem Health, Gold-Hard-Fail (auch: das Zielproblem besteht in der Produktion nicht), Mischzustand der Identitaet, Neustart-Serie, ungewoehnlicher Fehlerquote.
Tenant-Isolation (Abschnitt 25) prueft der Watcher stuendlich in der Produktion: das Dienstkonto selfimprove hat EINE Angabe in seinem persoenlichen Gedaechtnis ("Ich wohne in ZorgstadtSelfimproveProbeX."; einmal geschrieben, danach nur gelesen); der Zugang traverse fragt viermal ueber Chat und Stream danach und darf sie nie sehen, ohne Anmeldung gibt es keinen Zugang (401). Positivkontrolle: der Eigentuemer bekommt sie zurueck - misslingt sie, ist das nur weich. Hart ist allein ein Fremdtreffer. Die Probe laeuft seit 03.10.2026 16:05 UTC (davor, ab 15:14:46Z, ohne sie: 10 Beobachtungen der Probation von Lauf 0003). Der Watcher-Stand auf dem Host steht in ops/selfimprove/watcher.py (die vorige Fassung: /opt/lenny/v01b/si/bin/watcher.py.vor_tenant.20261003T160407Z).
Was eine Wartung kurz erzeugen kann, ist nie sofort hart (Fund 03.10.2026 16:45 UTC: ein Fehlalarm der Schema-Pruefung rollte einen gesunden Kandidaten zurueck, weil der Cron think_pass (45 */3) beim Oeffnen der Datenbank die Trigger lai2_format_role_*_guard per DROP und CREATE neu anlegt und zur selben Minute wie der Watcher startete). Seit 03.10. 16:49 UTC gilt ein solcher Befund erst nach drei Wiederholungen im Abstand von 20 s als hart (WIEDERHOLUNGEN in watcher.py); ein Lesefehler der Datenbank, ein Aussetzer der API im Gold-Smoke ("nicht pruefbar") ist weich. Neue Pruefungen gegen crontab -l des Hosts halten und zuerst im Beobachtungsmodus laufen lassen.
Absturzschutz (seit 03.10. 18:10 UTC): eine Ausnahme in einer Pruefung (Integritaet, Zielfix, Gold-Smoke, Ausnahmen) oder bei einer Marke ist ein weicher Hinweis fehler (<Typ>: ...) im Watcher-Zustand und verhindert weder die uebrigen Pruefungen noch einen Rollback. Die vorige Fassung liegt als /opt/lenny/v01b/si/bin/watcher.py.vor_schutz.20261003T181016Z; die Arbeitskopie im Repository ist die Quelle (beim Ersetzen auf dem Host wird der sha256 der hochgeladenen Datei mit der Arbeitskopie verglichen; Stand 03.10.: 0c35ee3db9ab6f2e).
Die Verhaltensproben der Admin-Sperre (E-07 bis E-10) laufen nicht in der Produktion (dort gaebe es nur mit einem Administratorschluessel eine Sperre, und kein automatischer Prozess darf sperren oder aufheben), sondern gegen eine Sandbox des deployten Commits: python -m selfimprove.admin_beweis --commit <sha> und python -m selfimprove.veto_beweis --commit <sha> - der Watcher prueft in der Produktion, dass der Schutz der Sperr-Ereignisse (Trigger) steht und keine Ereignisse verloren gehen.
Rollback = rollback_host.py (vertraute Kopie): Abbild-Tag, Compose, image_id.env, Host-Dateien; danach wird die Identitaet des Vorstands geprueft und nachgewiesen, dass keine Administratorentscheidung verloren ging. Von Hand: python3 /opt/lenny/v01b/si/bin/rollback_host.py --plan <rb>/plan.json --grund "...".

7. Nachweis-Werkzeuge¶

Werkzeug	Zweck
`python -m selfimprove.admin_beweis --commit <sha>`	Laufzeit-Beweis der Wissenssperren (E-07 bis E-10, K-20/K-21) in einer frischen Sandbox
`python -m selfimprove.veto_beweis --commit <sha>`	Veto gegen einen Lauf (P8-4)
`python -m selfimprove.unknown_probe`	UNKNOWN erzeugt keine Aenderung (K-02), gegen die Produktion (nur Audit-Eintraege)
`python -m selfimprove.produktions_nachweis --name <stamm>`	Stand der Produktion, rein lesend
`LENNY_SI_LANGSAM=1 python -m pytest tests/test_si_evaluator_e2e.py`	der Evaluator an echten Kandidaten (guter, ohne Zielfix, Regression, Gate-Abschwaechung, Tenant-Leck, Admin-Lock, unbelegte Antwort, stille Sperre)
`ops/selfimprove/drills/`	eingecheckte Rezepte: Regression (soll an G2 scheitern), Produktionsfehler (nur in der Produktion falsch -> Rollback)
`python -m selfimprove.headless_beweis`	der Headless-Weg der Coding-KI (`claude -p`) EINMAL echt im isolierten Worktree; schreibt den Beleg, den der Autopilot fuer CODE verlangt (`AUTH_BLOCKED` ohne Anmeldung)
`python -m selfimprove.e2_beweis <run>`	E2: ein schlechter CODE-Kandidat (Regressions-Drill) wird vom Kreis automatisch abgelehnt, die Produktion bleibt unveraendert
`python -m selfimprove.e7_beweis --commit <sha>`	E7: Administrator-Veto waehrend eines autonomen Vorgangs, mit dem Autopiloten, in einer Server-Sandbox
`python -m selfimprove.probe_verkehr [--wirkung <regel>]`	Testverkehr des Feldzugangs in der Probe-Domaene `si-probe`: drei unabhaengige Beobachtungen (E3), optional Wirkungsmeldungen
`python -m selfimprove.aufraeumen [--ausfuehren]`	Rollback-Artefakte bereinigen: Plan (Trockenlauf) oder Ausfuehrung mit Vorher/Nachher-Messung (behalten: aktive Version, Ziel einer Probation, letzte drei gueltige)
`python -m selfimprove.auto_truth_nachweis --sandbox --status`	Sandbox-Testpromotion der Wahrheitspromotion und der Aktivierungsstatus am echten Bestand (SAFE-CLOSED ohne zweite Evidenzfamilie)
`docs/produktionsautonomie/skripte/e8_guard_atomaritaet.py`	E8: Guard-Atomaritaet unter parallelem Schreiben an einer Kopie der Produktions-DB (im Container ausfuehren)

8. Bekannte Grenzen¶

Erkennen (Detektor) und Beobachten (Watcher) laufen als Dienste auf dem Server. Bauen, Testen und Deployen fuehrt der Controller aus - als Kommando oder mit python -m selfimprove.autopilot. Seit dem 04.10.2026 laeuft der Autopilot als Betriebsjob in der Aufgabenplanung (Lenny-SelfImprove-Autopilot, alle 15 Minuten, siehe Abschnitt 9); er deployt dauerhaft ohne Bediener. Der Administrator behaelt Veto, Modus und Sperren; autopilot.pause haelt den Job an.
Fuer CODE_GAP braucht der Autopilot die angemeldete CLI (claude auth status zeigt loggedIn: true) UND den Beleg des Headless-Weges; ohne beides baut er nur CONFIG-, DATA- und RULE-Laeufe.
Eine Bewertung, ein Datensnapshot (Abschnitt 15.1): der Controller zieht EINE konsistente Kopie der Produktionsdaten (SQLite-Backup, Quelle nur lesend), Basis und Kandidat starten beide aus ihr, danach wird sie entfernt - auch bei einer gescheiterten Bewertung. Ohne sie sahen beide Instanzen verschiedene Daten (ein Cron der Produktion aenderte sie dazwischen) und G19 lehnte einen gesunden Kandidaten ab (Lauf 0011).
SSH: Ssh.run verbindet bis zu dreimal neu, aber nur bei Fehlern VOR Beginn der Sitzung (Connection closed by ..., refused, timed out); der Befehl ist dann nie gelaufen. Ein Abriss mitten im Befehl wird nie wiederholt. deploy.sh und die Tunnel der Sandbox haben diese Wiederholung nicht.
claude -p braucht eine angemeldete Claude-Code-CLI auf der Maschine des Controllers.
Die Produktion deployt nur der Controller mit dem Deploy-Schluessel; die Coding-KI hat ihn nie.

Fallen aus dem ersten echten Betrieb (05.10.2026).

Tests duerfen nicht vom Fortbestehen eines Defekts abhaengen. Ein Test, der den Probe-Defekt (probe_normalisierung, probe_kuerzung) voraussetzt, laesst genau den Fix scheitern, den der Kreis bauen soll (G2 fuehrt tests/ des Kandidaten-Commits aus; die Coding-KI darf bestehende Tests nicht aendern). Vor dem ersten echten CODE-Lauf den erwarteten Fix in einem Scratch-Worktree anwenden und die Vollsuite dort laufen lassen; den Defekt in Tests per Test-Double (Haken probe_modul) einspielen. Eine solche Korrektur muss ERST deployt sein, denn die Spec-Basis ist immer die Produktion.
Nie zwei Suiten (oder eine Suite und den Autopiloten) gleichzeitig auf demselben Repository: Branch- und Worktree-Namen der Kandidaten sind deterministisch (si/CH-<hash>, <work>/cand_c<hash>) und kollidieren (invalid reference).
Ein Befund wandert in jeden weiteren Versuch (Abschnitt 13) - auch durch den Rebase. Stellt sich spaeter heraus, dass der Befund irrefuehrt (Fehlalarm des Watchers, Fehler der Selbsttests), die Richtigstellung als Feld korrektur im Befund mitgeben (Controller.spezifiziere_neu), sonst glaubt die Coding-KI, das Problem sei nicht loesbar.
Die Konfigurationsquelle schlaegt nie einen Schalter vor, dessen Grundstellung AUS ein Test festschreibt (signale.FESTGESCHRIEBEN): das Einschalten ist die Freigabe der Entwickler; ein Kandidat scheitert ohnehin an G2.
Der strenge Wikipedia-Beleg nimmt nur ein grossgeschriebenes Substantiv als Oberkategorie; die Wikipedia drosselt (HTTP 429) - je Durchgang hoechstens LENNY_SI_UNKNOWN_BUDGET (8) Pruefungen, Absagen werden gemerkt.
Git-Push haengt: verwaiste git-credential-manager get-Prozesse abraeumen (Get-CimInstance Win32_Process | ? Name -match 'git-credential-manager|git-remote-https' | Stop-Process), danach ohne Zeitlimit im Hintergrund pushen.

9. Autonomer Betrieb (seit 04./05.10.2026)¶

Der reale Betriebsweg: Lenny beobachtet -> erkennt ein Defizit -> klassifiziert -> DATA / RULE / CONFIG bearbeitet der Autopilot selbst; bei CODE: Change-Spec -> Headless-Coding-KI (claude -p) -> Sandbox -> Evaluator -> Gates -> autonomer Deploy -> Probation -> accepted / Rollback. Der Administrator besitzt jederzeit das Veto; Sperren hebt keine Automatik auf.

Signalquellen (ops/selfimprove/signale.py, regel_zulauf.py, fehler_zulauf.py; Autopilot-Option --signale). Jede Quelle legt hoechstens einen Lauf an und scheitert fuer sich:

Quelle	Anlass	Klasse
Goldfall	ein bisher gruener Hard-Gold-Fall ist reproduzierbar rot (in allen Wiederholungen der Messung; hoechstens stuendlich gemessen; die erste Messung legt nur die Grundlinie an)	nach `si_klassifikation` (CODE nur, wenn sich der Code seit dem letzten Gruen geaendert hat, sonst UNKNOWN)
gleiche Fehler	drei unabhaengige Faelle derselben verletzten Eigenschaft (Komponente + Ausnahmeklasse) im Fehlerbuch des Servers (`GET /v1/selfimprove/fehlerbuch`, 29 Stellen im `api_server`), nicht nach Text geclustert	CODE_GAP (die Klassifikation kann nach den belegten Fakten auch DATA/RULE/CONFIG ergeben)
wiederkehrende Unknowns	semantisch gleiche Definitionsfragen ohne Antwortbasis, mindestens drei unabhaengige Faelle (verschiedene Frage oder Tag), Antwortweg vorhanden, strenger Wikipedia-Beleg; ALLE Gruppen kommen in Betracht, je Durchgang hoechstens 8 Belegpruefungen (`LENNY_SI_UNKNOWN_BUDGET`), Absagen werden gemerkt	DATA_GAP
Regelmuster	drei unabhaengige Beobachtungen (ohne gemeinsamen Wurzelbeleg) verlangen denselben Schluss in einer Domaene mit Regeln -> Regelhypothese `hyp-<sha>` (gemeinsamer Kern der Signale) als Kandidat im KREATIV-Gehirn	RULE_GAP
Konfiguration	Fragen, die der Code mit einem Schalter der Allowlist (3 Faehigkeiten mit Test) erkennt und die die Produktion ohne ihn abweist	CONFIG_GAP

Nicht ausreichend und nie ein Ausloeser: eine einzelne Beobachtung, ein Modellurteil ohne Beleg, dieselbe Anfrage wiederholt, dasselbe Fragment oder derselbe Wurzelbeleg mehrfach. Nicht angebunden (benannt): der Ausloeser D des Regelzuflusses (wiederkehrender Konflikt mit derselben Aufloesung) - das Protokoll kennt die Aufloesung eines Konflikts nicht.

Reihenfolge und Embargo. Hoechstens ein CODE-Kandidat gleichzeitig (Bau bis Probation); waehrend der 24-h-Probation eines CODE-/CONFIG-Laufs deployt der Autopilot keine DATA-/RULE-Aenderung (sie verfaelschte die Messung des Watchers) - die Laeufe werden gebaut und bewertet, der Deploy wartet. Ein Rebase im 2./3. Versuch behaelt den Befund des vorherigen Fehlversuchs.

Auto-Truth (Aufnahme in die WAHRHEIT) bleibt aus: LENNY_ENABLE_AUTO_WIKI_OLLAMA_PROMOTION=0. Eine Aufnahme verlangte mindestens zwei unabhaengige Evidenzfamilien (core/evidenzfamilie.py; Wikipedia und Wikidata zaehlen als EINE), Vorher/Nachher je Charge, einen Aenderungssatz mit exaktem Rueckweg und eine Wirkungsbeobachtung mit selbsttaetigem Rueckweg (core/wahrheitspromotion.py). Im Bestand gibt es nur die Familie wikimedia - die Aktivierung ist SAFE-CLOSED (auto_truth_nachweis --status).

Belegter Lauf (E1, 05.10.2026). Der erste vom Planer-Job ohne Sitzung gebaute CODE-Lauf war Problem A (SIR-20261002T214311Z-0001): Durchgang 05:41:47-06:23:21 UTC (2.494 s, Exitcode 0) - Bau mit claude -p (32 s, 0,10 USD, 0 Verstoesse), Evaluator APPROVE (14 von 14 Gates, Zielfix FAIL -> PASS, 20 min), Deploy-Schranke und Deploy (19 min), probation ab 06:23:18 UTC. Beleg: python -m selfimprove.e1_beleg <run_id> (elf Bedingungen, alle erfuellt), Nachweis docs/produktionsautonomie/nachweise/e1_*.json. Im Betriebsprotokoll sieht ein CODE-Durchgang so aus: ein langer start/ende-Block (Bewertung und Deploy laufen im Durchgang) mit aktionen: ["0001:queued->probation"]; waehrenddessen startet der Task Scheduler keine weiteren Takte (IgnoreNew), danach folgen die kurzen Durchgaenge (10-20 s), die eine Probation nur beobachten. Der Kandidaten-Branch si/CH-* ist nach dem Deploy in selbstverbesserung zusammenzufuehren, sonst dreht ein spaeterer manueller Deploy den Fix zurueck.