LENNY - Abschlussbericht "Produktionsautonomie"

Stand: 05.10.2026 07:02 UTC (09:02 MESZ), fortgeschrieben 15:06 UTC (17:06 MESZ) (Endpush, Betriebsprotokoll, Probation); alle Zeiten UTC, MESZ = UTC + 2 (z. B. 05:00 UTC = 07:00 MESZ). Repository E:\Lenny_zf, Branch selbstverbesserung, Prototyp experiments/lenny_language_layer_prototype_v1. Auftrag: LENNY - Produktionsabschluss Autonomie.md (16 Abschnitte, Start 04.10.2026 ~19:50 UTC). Quelle der Tabellen: docs/produktionsautonomie/ledger.json (python tools/pa_ledger.py md) und docs/produktionsautonomie/nachweise/; Betrieb: docs/SELBSTVERBESSERUNG_BETRIEB.md (Abschnitt 9) und ops/selfimprove/betrieb/LIESMICH.md.

0. Ergebnis in Kuerze

• Der reale Betriebsweg laeuft ohne Bediener (Abschnitt 16 des Auftrags): Lenny beobachtet, erkennt ein Defizit, klassifiziert und bearbeitet DATA / RULE / CONFIG selbst; bei CODE baut die Headless-Coding-KI (claude -p) einen Kandidaten, der Evaluator bewertet ihn in der Sandbox (14 Gates), der Autopilot deployt, der Host-Watcher beobachtet 24 Stunden - der Administrator behaelt jederzeit das Veto, und keine Automatik hebt eine Sperre auf (E7).
• RULE-Zulauf in der Produktion belegt (E3): drei unabhaengige Beobachtungen -> Regelhypothese hyp-aba2e0031692 -> RULE_GAP-Lauf 0014 -> Schatten -> accepted; Wirkungsmeldungen bewegen das Vertrauen (0,10 -> 0,20). Ehrlich dazu: die drei Beobachtungen stammen aus eingespeistem Testverkehr des Feldzugangs traverse-field in der Probe-Domaene si-probe (das Beobachtungsprotokoll des Servers laeuft erst seit 05.10. 00:48 UTC, organische Muster dieser Art gab es noch nicht); der Mechanismus - Protokoll, Cluster, Hypothese, Schatten, Entscheidung - lief dabei vollstaendig und real in der Produktion. Der DATA-Zulauf arbeitet dagegen mit echten Daten: Lauf 0016 ("Tinktur", Abschnitt 9) legte der Planer-Job selbst an.
• Regelmaessiger Autopilot als Planer-Job alle 15 Minuten (hoechstens eine Instanz, Protokoll mit Zeit, PID und Exitcode ohne Secrets; 69 Takte seit 04.10. 20:39 UTC, alle Exitcode 0, Stand 05.10.2026 14:56 UTC, Abschnitt 7).
• E1 belegt - der erste ohne Sitzung gebaute CODE-Lauf ging bis in die Probation: Problem A (Lauf 0001) wurde vom Planer-Job mit claude -p gebaut (Agent claude-code, 9 Turns, 32 s, 0,10 USD, 0 Verstoesse), der Evaluator gab APPROVE (14 von 14 Gates, Zielfix FAIL -> PASS), der Planer deployte 0d7f4e8 (Deploy-Schranke, Health, Smoke und Security gruen) - der Lauf steht seit 05.10.2026 06:23 UTC (08:23 MESZ) in probation. Die einzige Handarbeit im Lauf ist in Abschnitt 6 vollstaendig benannt.
• Die uebrigen Posten: Guard-Atomaritaet (Laufzeit E8), [DEUTUNG]-Fix, Rollback-Bereinigung, Auto-Truth SAFE-CLOSED mit Sandbox-Beweis, fuenf Signalquellen im Betrieb, Produktion auf 0d7f4e8 (zwei Sammel-Deploys von Hand und ein autonomer Deploy des Planers, alle mit Rollback-Netz und gruener Schranke) - Einzelheiten in den Abschnitten 3 bis 16.
• Ehrlich vorweg: die ersten Laeufe im echten Betrieb brachten neun Funde (Abschnitt 17), darunter einen Fehler der eigenen Selbsttests, der den ersten echten Fix von Problem A haette scheitern lassen. Alle sind behoben und getestet; der Evaluator und der Datenkreis haben jeden unbrauchbaren Kandidaten (Laeufe 0013 und 0015) abgelehnt - nichts davon kam in die Produktion.
• Nicht fertig, aber benannt (Abschnitt 17): die 24-h-Probation von Problem A laeuft (Ende fruehestens 06.10. 06:23 UTC), Problem B (Lauf 0012) wartet laut Policy hinter ihr (hoechstens ein CODE-Kandidat) und baut danach selbst; Auto-Truth bleibt SAFE-CLOSED (nur eine Evidenzfamilie, E6 nicht real moeglich); Ausloeser D des Regelzuflusses ist nicht angebunden; der Endpush war am Vormittag PUSH_AUTH_BLOCKED (Anmeldung des Git Credential Managers) und ist um 15:01 UTC gelungen (Abschnitt 13, Remote ff1cc2b).

1. Ausgangsstand

Produktion d482939 (seit 04.10.2026 19:12 UTC; der Selbstverbesserungs-Ausbau war abgeschlossen), Branch selbstverbesserung auf dem Remote 9ba0f54 (04.10. 19:45 UTC). Offen waren: ein vom Watcher zurueckgerollter Lauf (0011, Problem B) mit Fehlalarm-Verdacht, ein erschoepftes Problem A (0001), kein Headless-Weg der Coding-KI, kein regelmaessiger Autopilot, RULE_GAP nur mit vorgegebenem Regelkandidaten, Auto-Truth ohne Sicherheitsstandard.

2. Finaler Produktionscommit

Angabe	Wert
Produktionscommit	0d7f4e8cbe2298a15acbbaa29263ebfec691c0d2 (Kandidat CAND-0d7f4e8cbe22, Problem A) - seit 05.10.2026 06:23 UTC (08:23 MESZ) in der Produktion, vom Planer-Job ohne Bediener deployt
Vorgaenger	b787d8f (05.10. 05:38 UTC, zweiter Sammel-Deploy), 3784085 (05.10. 00:48 UTC, erster Sammel-Deploy), d482939 (Ausgangsstand)
/health-Identitaet (05.10. 06:28 UTC)	code_commit 0d7f4e8c..., image_digest sha256:0b6e71dc...ea07, config_hash_env 24e43e2e... (seit dem Ausgangsstand unveraendert), policy_hash 89098a12..., data_generation g54 (26.940 Fragmente, 26.662 Relationen), Identitaet vollstaendig, Modelle gepinnt
Bereitstellung	deploy/deploy.sh --commit 0d7f4e8 durch den Controller des Planers: Deploy-Schranke gruen, Rollback-Ziel rb-b787d8fc3bf3-20261005t060339z, Deploy 1.149 s, Health, Smoke und Security gruen
Zweigspitze	selbstverbesserung traegt den Kandidaten als Zusammenfuehrung (af8a9b9); zum Produktionscommit unterscheiden sich nur drei Dateien (Betriebsdokument, ops/selfimprove/controller.py - Planer-Seite, ein Test)

Stand 05.10.2026 06:28 UTC. Weitere Produktions-Deploys geschehen nur noch durch den Kreis selbst (Problem B nach der Probation von A, DATA/RULE nach dem Embargo).

3. Guard-Atomaritaet (Abschnitt 1, E8)

Thema	Befund	Beleg	Status
Ursache	install_brain_guards und install_lai2_core_proof_schema liefen jede DROP-/CREATE-Anweisung im Autocommit bei jedem Oeffnen der Datenbank; dazwischen gab es einen Augenblick ohne Schutz (vor dem Fix gemessen: 941 von 1.441 Umgehungsversuchen angenommen)	Commit 3479710	behoben
Fix	eine Transaktion (BEGIN IMMEDIATE, bei offener Transaktion SAVEPOINT), Integritaetspruefung am Ende nimmt einen unvollstaendigen Satz zurueck, bei Fehler bleiben die alten Waechter wirksam	core/fragment_store.py (_atomic_ddl, _atomic), tests/test_brain_guards_atomar.py (9 Tests)	DONE
Laufzeit (E8)	an einer Kopie der Produktionsdatenbank im Container (LAI/2.0, Rolle core, 46 Waechter): 31 Installationen, 9.538 Schreibversuche mit ungueltigem Brain durch 4 parallele Schreiber - 0 angenommen, 0 von 197.799 Beobachtungen mit unvollstaendigem Waechtersatz. Negativkontrolle ohne Huelle: 219.290 von 226.311 Beobachtungen sehen nur 45 von 46 Waechtern	docs/produktionsautonomie/nachweise/e8_guard_atomaritaet_produktion_3784085.json, Skript docs/produktionsautonomie/skripte/e8_guard_atomaritaet.py	DONE

Ehrlich: in der Negativkontrolle auf der Produktionskopie wurde der Brain-Waechter selbst im Zeitraum nicht getroffen (0 von 3.849 Versuchen angenommen) - das fehlende Stueck war ein Proof-/Pressure-Trigger; der Umgehungsfall am Brain-Waechter ist durch die Unit-Tests (und die lokalen Proben mit 893 von 1.052 bzw. 1.341 von 3.469 angenommenen Versuchen) belegt.

4. Problem A (Lauf 0001, probe_normalisierung)

Problem A ist der Probe-Defekt normalisiere (faltet Umlaute nicht). Seine drei frueheren Versuche (03.10.) waren Selbsttest-Drills (scripted: Regressions- und Produktionsfehler-Rezept) und scheiterten an der Regression, an einem wanduhrabhaengigen core-Test und an Messrauschen (G27 p95) - nicht an einer Loesung der Coding-KI; der Defekt bestand unveraendert (unresolved).

Zeit (UTC)	Ereignis
05.10. 01:23	wiedergeoeffnet mit neuer Evidenz (controller wiederoeffne, Versuchsbudget beginnt neu): die Fehlversuche waren Drills/Messrauschen, der Defekt besteht, der Headless-Weg der Coding-KI ist belegt, die Produktion laeuft auf 3784085, der Rebase ist korrigiert
05.10. 01:33	der Detektor fuehrt den Lauf bis queued (Versuchsbudget zurueckgesetzt)
05.10. 01:34-01:55	E2 an diesem Lauf: Versuch 1 = Regressions-Drill (drills/regression.json, Agent scripted, im Audit so gekennzeichnet) -> Evaluator REJECT (G2: test_woerter_zaehlen faellt - die Regression; kein Deploy, Produktion unveraendert, Beleg e2_SIR-20261002T214311Z-0001_20261005T0155Z.json)
05.10. ~05:10	Der erste echte Fix haette an einem Fehler der Selbsttests scheitern muessen: test_der_spec_zur_invariante_ist_ein_echter_code_gap_im_scope_der_probe setzte den Defekt voraus und faellt, sobald er behoben ist. Gefunden, indem der Fix aus dem Headless-Beleg in einem Scratch-Worktree gegen die Vollsuite gemessen wurde (3.727 gruen, 2 rot - der zweite war eine Kollision paralleler Laeufe und isoliert gruen); Korrektur (der Defekt kommt als Test-Double) und zweiter Sammel-Deploy vor dem Bau

Versuch 2 - der echte Fix, ohne Sitzung:

Zeit (UTC)	Ereignis
05.10. 05:21-05:38	zweiter Sammel-Deploy (b787d8f; Deploy-Schranke gruen: tests/ 3.750 Tests, 0 Fehlschlaege) - die Produktion traegt den korrigierten Selbsttest
05:39	Detektor: "Problem erneut beobachtet, mit neuer Evidenz"
05:40	Basis veraltet (Produktion ist auf b787d8f): Change-Spec fuer Versuch 2 erneuert, der Befund des Drills uebernommen mit der Richtigstellung zum fehlerhaften Selbsttest (von Hand ausgeloest, Abschnitt 6)
05:41:47	Planer-Job: Durchgang pid 3940 (--betrieb --signale, claude im PATH)
05:42:37	Bau Versuch 2 mit claude-code (headless, isolierter Worktree)
05:43:30	Kandidat CAND-0d7f4e8cbe22: Commit 0d7f4e8, Branch si/CH-3e2d574950cc, zwei Dateien (core/selfimprove_probe.py +3/-1, tests/test_si_ch_3e2d574950cc.py mit 4 Tests)
05:43:31-06:03:10	Evaluator (Server-Sandbox, Kandidat gegen Basis): APPROVE, alle 14 geforderten Gates gruen, Zielfix FAIL -> PASS
06:03:41	deploying, Rollback-Ziel rb-b787d8fc3bf3-20261005t060339z; Deploy-Schranke: tests/ 3.754 Tests = 3.733 gruen, 0 Fehlschlaege, 0 Fehler, 19 uebersprungen, 2 xfailed (895 s); core/ 2.081 gruen = Grundlinie (163 s)
06:23:18	probation - Health, Smoke, Security gruen, Deploy 1.149 s, Produktion auf 0d7f4e8
06:25:39	erste Probation-Beobachtung des Host-Watchers

Der Fix ist der kleinste wirksame Eingriff: nach dem Kleinschreiben faltet normalisiere ae/oe/ue/ss, zaehle_woerter blieb unveraendert (die Regression des Drills ist damit vermieden). Die Coding-KI hat nur drei Testdateien (21 Tests) ausgefuehrt und das ehrlich im Endtext gesagt; die vollstaendige Suite, die Gold-/Replay-Gates und den Zielfix pruefte der Evaluator. Der Kandidat ist in selbstverbesserung uebernommen (Zusammenfuehrung af8a9b9), damit ein spaeterer manueller Deploy ihn nicht zurueckdreht.

Ergebnis: wiedergeoeffnet, ueber Coding-KI und Evaluator abgearbeitet, bewilligt und deployt - Status DONE bis zur Probation. Die Probation laeuft bis fruehestens 06.10.2026 06:23 UTC (08:23 MESZ); danach setzt der Watcher accepted oder rollt selbsttaetig zurueck (nicht von mir abzuwarten, nicht von mir zu entscheiden).

5. Problem B (Lauf 0011/0012, probe_kuerzung)

Problem B ist der Probe-Defekt kuerze (liefert n+1 statt n Zeichen). Verlauf:

Zeit (UTC)	Ereignis
04.10. ~20:00	Lauf 0011, Versuch 1: fachlich richtig, aber build_failed - der Sitzungs-Subagent las seinen Auftrag aus einer Datei ausserhalb des Workspaces (Allowlist-Verstoss, Fehler der Orchestrierung; die Grenze wurde nicht aufgeweicht)
04.10. 20:39-21:40	Versuch 2 (Kandidat CH-211f2d238cd8, Commit 0a73dcd): Bewertung (14 Gates), APPROVE, autonomer Deploy, Probation - dann Rollback durch den Host-Watcher (21:40): Mischzustand: config_hash_env weicht ab
05.10. 00:00-00:40	Ursachenanalyse: ein Fehlalarm, kein Fehler des Kandidaten. Der erste Aufruf von /mcp importiert ops/gemma_loop_server.py nachtraeglich; sein Modulkopf setzt LENNY_GEMMA_STATE_DIR per os.environ.setdefault und veraenderte so den Umgebungshash der LAUFENDEN Produktion (config_hash_env: 32a4578a... -> 83d817d7...). Behebung: core/si_identity rechnet mit der Umgebung des Prozessstarts (_ENV_START), Commit 690d96e, 5 Tests
05.10. 00:50	Laufzeitbeweis im Produktionsabbild: ein frischer Prozess importiert erst si_identity, dann gemma_loop_server - LENNY_GEMMA_STATE_DIR steht danach in der Umgebung, der Hash bleibt 24e43e2e... (und das Gegenbeispiel ohne Schnappschuss waere ein anderer) - docs/produktionsautonomie/nachweise/identitaet_laufzeit_3784085.json
05.10. 01:12	Lauf 0012 (der Detektor legte das Problem nach dem Rollback neu an, Versuch 3 von 3): im ersten Autopilot-Durchgang scheiterte der Rebase (SpecFehler: Versuch 2 und 3 muessen den Befund erhalten) und liess den Lauf in reproducing zurueck, wo ihn kein Autopilot mehr anfasst. Ursache: Controller.rebasiere gab den Befund des vorherigen Fehlversuchs nicht weiter. Behoben (1758fd7: Befund bleibt, Messung vor dem Zustandswechsel, ein Spec-Fehler laesst nie einen Lauf in reproducing zurueck; 3 Tests), Lauf 0012 mit dem korrigierten Controller fortgesetzt - der Befund traegt die Richtigstellung, dass der Rollback ein Fehlalarm war

Ausgang (Stand 05.10.2026 06:28 UTC): Lauf 0012 steht in queued (Versuch 3 von 3, Change-Spec CH-4021757458ce auf b787d8f). Er wartet auf die Policy: hoechstens ein CODE-Kandidat gleichzeitig, und die laufende Probation von Problem A zaehlt dazu. Jeder Durchgang des Planers versucht ihn weiterzufuehren (0012:queued->queued im Betriebsprotokoll), der Detektor haelt die Evidenz frisch (zuletzt 06:23). Nach dem Ende der Probation von A (fruehestens 06.10. 06:23 UTC) baut der Planer ihn ohne weiteres Zutun - Bau mit claude -p, Evaluator, Deploy, 24 h Probation (accepted frueh am 07.10. zu erwarten). Der bekannte Werkzeugfehler (der Rollback-Fehlalarm) ist behoben und die Wiederoeffnung mit neuer Evidenz geschehen - es ist keine Sonderbehandlung noetig, nur die Reihenfolge der Policy. Status BLOCKED (zeitgebunden, Policy): nicht fehlerhaft, nicht vergessen.

6. Headless-Coding-KI (Abschnitt 4)

Die CLI ist angemeldet (claude auth status: loggedIn, claude.ai) - der Punkt ist nicht mehr AUTH_BLOCKED. python -m selfimprove.headless_beweis fuehrt den Weg Dispatcher -> claude -p -> isolierter Git-Worktree -> Commit -> Nachpruefung EINMAL echt aus (an der Probe-Invariante probe_normalisierung, die im Basis-Stand der Produktion wirklich verletzt ist; der Kandidat wird nie deployt) und schreibt den Beleg E:/si_work/headless_beweis.json nur nach einem Lauf ohne Verstoss mit erfuellter Invariante, gruenem neuem Test und belegter Isolation; eine Attrappe (art: attrappe) nimmt der Autopilot nie an.

Versuch (05.10.2026)	Ergebnis
1 und 2 (00:55 UTC)	kein Commit: die Coding-KI schrieb Fix und Test, doch ein Bash-Heredoc wurde im Modus dontAsk verweigert, sie zog daraus "Bash ist verweigert" und fuehrte weder Test noch git commit aus. Der erste Lauf liess keine Spur - Transkript-Sicherung (beweis_<zeit>.transkript.json) ergaenzt
Behebung	der Auftrags-Prompt nennt jetzt ausdruecklich die erlaubten Bash-Formen (WERKZEUG_HINWEIS: Dateien nur ueber Read/Edit/Write, je Aufruf EIN erlaubter Befehl, bei Verweigerung dieselbe Form erneut), das build_log traegt den Endtext der Coding-KI (Tests)
3 (01:01 UTC)	belegt: Commit 8683802b im isolierten Worktree, 66 s, 9 Turns, 0,077 USD, 8 Werkzeugaufrufe (Bash, Edit, Read, Write), 0 Verstoesse; Invariante vorher verletzt, nachher erfuellt; neuer Test tests/test_si_ch_6c4c20d860cb.py 3 passed; Isolation: Hauptbaum und Produktion unveraendert, Worktree ausserhalb des Hauptbaums, Umgebung der CLI ohne LENNY_/OLLAMA_-Werte und ohne Geheimnisse (nur die Anmeldung der CLI selbst), eigener Branch si/..., Werkzeug-Allowlist

Der Fix der Coding-KI (normalisiere faltet ae/oe/ue/ss, kleinster wirksamer Eingriff, nur core/selfimprove_probe.py plus ein neuer Test) war inhaltlich richtig. Der Beleg schaltet den CODE-Weg des Autopiloten nur frei (autopilot.coding_ki_bereit: angemeldet UND Beleg gruen); den Rest (Evaluator, Deploy, Probation) beweist der erste vom Autopiloten ohne Sitzung gebaute CODE-Lauf (E1, unten). In der Umgebung des Planers liegt die CLI im PATH des Benutzers (C:/Users/marco/.local/bin); das Betriebsprotokoll haelt es je Aufruf fest (claude_im_pfad).

E1 - autonomer Headless-CODE (Beleg docs/produktionsautonomie/nachweise/e1_SIR-20261002T214311Z-0001_20261005T0624Z.json)

Das Belegwerkzeug (python -m selfimprove.e1_beleg <run_id>, 11 Tests; liest nur den Kreis, das Betriebsprotokoll und /health, schreibt nichts am Lauf) verlangt ALLE Bedingungen. Fuer Lauf 0001 sind alle elf belegt (ok: true):

Bedingung	Beleg
CODE_GAP mit reproduzierbarer Invariante	Spec CODE_GAP, Reproduktion invariante probe_normalisierung
Der Detektor fuehrte den Lauf bis queued	Audit: Akteur detector (unresolved -> detected -> classified -> reproducing -> specified -> queued, 05.10. 01:33)
Gebaut von claude -p headless	build_log: Agent claude-code, Modell claude-sonnet-5-5, 9 Turns, 32,3 s, 0,103 USD, rc 0, acht Werkzeugaufrufe (Read, Edit, Write, Bash fuer pytest, git add, git commit); die Bauversuche davor waren die Rezept-Drills (scripted, E2)
Kein Sitzungs-Subagent, kein Rezept im erfolgreichen Versuch	Audit: "Bau Versuch 2 (CODE_GAP) mit Agent claude-code"
Nachpruefung des Dispatchers	0 Verstoesse (Werkzeug-Allowlist, Workspace, Umgebung ohne Geheimnisse)
Evaluator APPROVE	14 von 14 Gates gruen, Zielfix FAIL -> PASS (docs/ausbau/nachweise/bewertung_SIR-20261002T214311Z-0001_CAND-0d7f4e8cbe22.json)
Deploy gesund	Health, Smoke (26 Gold-Faelle: keine neuen Falschen, keine Verschlechterung, keine verlorene Provenienz, kein unerlaubtes Unknown), Security (8 Pruefungen) gruen
Probation und Produktion auf dem Kandidaten	probation seit 06:23:18; /health: code_commit 0d7f4e8c...
Kein Mensch im Ablauf	Akteure im Audit: nur detector und selfimprove (Dienstkonto)
Die Schritte liefen im Betriebsjob des Planers	autopilot.betrieb.jsonl: Durchgang pid 3940, 05:41:47-06:23:21 UTC (2.494 s), Exitcode 0, Aktionen 0001:queued->probation

Handarbeit im Lauf, vollstaendig benannt: (1) Das Wiederoeffnen mit neuer Evidenz (01:23, vom Auftrag verlangt). (2) Um 05:40 erneuerte ich die Change-Spec auf die neue Produktionsbasis - dieselbe Funktion (Controller.spezifiziere_neu), die der Autopilot bei veralteter Basis selbst ruft; ich loeste sie von Hand aus, um dem uebernommenen Befund die Richtigstellung zum fehlerhaften Selbsttest beizufuegen (ohne sie haette die Coding-KI glauben koennen, das Problem sei nicht loesbar). Der Akteur im Audit ist auch dort das Dienstkonto, der Weg derselbe. (3) Kein Eingriff in Bau, Bewertung, Entscheidung, Deploy oder Probation: die Zustandswechsel 425 bis 431 stammen alle aus dem Durchgang des Planer-Jobs, den der Betriebsjob (nicht eine Sitzung) um 05:41:47 UTC startete.

7. Scheduler / Autopilot (Abschnitt 5)

Der Autopilot laeuft als Betriebsjob des Betriebssystems (ops/selfimprove/betrieb/installiere_job.ps1, Handbuch ops/selfimprove/betrieb/LIESMICH.md, docs/SELBSTVERBESSERUNG_BETRIEB.md Abschnitt 9):

Anforderung (Abschnitt 5)	Umsetzung / Beleg
OS-Job alle 15 Minuten	Aufgabe Lenny-SelfImprove-Autopilot, Intervall PT15M, Aktion conhost.exe --headless cmd.exe /c <work>/autopilot_job_lokal.cmd (Windows Script Host ist per Gruppenrichtlinie gesperrt und wird nicht benutzt), Benutzer marco, Anmeldeart Interactive, Ebene Limited: kein gespeichertes Kennwort, keine Administratorrechte; Hoechstlaufzeit 5 h
hoechstens eine Instanz	MultipleInstances = IgnoreNew UND Schloss <work>/autopilot.lock (nach 6 h als verwaist uebernommen); ein zweiter Start ueberspringt mit Exitcode 0
Exitcodes und Zeitstempel	Betriebsprotokoll <work>/autopilot.betrieb.jsonl: je Aufruf start/ende bzw. uebersprungen mit UTC-Zeit, PID, Exitcode, Dauer, Aktionen; conhost --headless reicht den Exitcode nicht an den Planer weiter - massgeblich ist das Protokoll. Stand 05.10.2026 14:56 UTC: 69 Takte seit 04.10. 20:39 UTC (49 Durchgaenge, 20 wegen der Pause-Marke uebersprungen), alle Exitcode 0, Median-Abstand 15,0 Minuten (groesste Luecke 48 Minuten: ein langer Arbeitsdurchgang - waehrend er laeuft, startet der Task Scheduler keinen weiteren Takt)
keine Secrets	die Aufgabe enthaelt nur Pfade; der Controller liest die Zugangsdateien selbst; Fehlertexte laufen durch schwaerze (Bearer-Token, Schluessel, Passwoerter); gesichert durch Tests
ein Fehler haelt den naechsten Lauf nicht auf	die Wiederholung gehoert dem Planer, nicht dem Ergebnis des vorigen Aufrufs; jede Ausnahme wird protokolliert (Exitcode 1), der naechste Aufruf in 15 Minuten laeuft trotzdem; Fehler einzelner Laeufe/Quellen sind isoliert
Umgebungspruefung	vor jedem Durchgang: git, Repository, ssh, SSH-Schluesseldatei, Git-Bash, deploy.sh, Dienstkonto-Zugang, Arbeitsverzeichnis, SSH-Verbindung, Health (10 von 10 gruen unter dem Planer) - bei Rot beginnt der Durchgang nichts
sauberer Arbeitsbaum	der Job laeuft nur auf committetem Code: uncommittete Aenderungen verfolgter Dateien in ops/ oder core/ des Hauptbaums ueberspringen den Durchgang
Pause	<work>/autopilot.pause (Wartung, Handarbeit); gesetzt vom 05.10. ~00:30 UTC (Sammel-Deploy und Handlaeufe; erster uebersprungener Takt 00:42:59 UTC, letzter 05:27:59 UTC) bis ~05:40 UTC (Neueinrichtung des Jobs mit --betrieb --signale; erster Durchgang danach 05:41:47 UTC, seither ohne Pause)
CODE erst nach belegtem Headless-Weg	autopilot.coding_ki_bereit: claude auth status angemeldet UND headless_beweis.json mit art: echter_lauf, ok: true (Abschnitt 6)

Durchgaenge mit Arbeit (Betriebsprotokoll; alle uebrigen Takte pruefen nur, ob etwas zu tun ist):

Ende des Durchgangs (UTC)	Anzahl	Dauer	Aktionen (<Lauf>:<von>-><nach>)
04.10. 21:18	1	2.313 s	0011:candidate_ready->probation
04.10. 21:28	1	12 s	0011:probation->probation
04.10. 21:43 - 23:58	10	11-18 s	0012:queued->queued
05.10. 00:13 - 00:28	2	9-11 s	0012:queued->queued
05.10. 06:23	1	2.494 s	0001:queued->probation, 0012:queued->queued
05.10. 06:27	1	16 s	0001:probation->probation, 0012:queued->queued
05.10. 06:58	1	996 s	0001:probation->probation, 0012:queued->queued, 0016:queued->approved
05.10. 07:12 - 14:57	32	15-43 s	0001:probation->probation, 0012:queued->queued, 0016:approved->approved

Der erste Arbeitsdurchgang (04.10. ~21:18 UTC) bewertete und deployte Problem B (Versuch 2, vom Sitzungs-Subagenten gebaut - damals gab es noch keinen Headless-Weg); der zweite ist der E1-Durchgang (05.10. 05:41-06:23 UTC): --signale und claude im PATH, Bau mit claude -p, Bewertung, Deploy, Probation in einem Durchgang von 41 Minuten. Die Takte waehrend eines laufenden Durchgangs startet der Task Scheduler gar nicht (IgnoreNew, nichts zu protokollieren). Im Durchgang von 06:41 UTC legte die Unknown-Quelle ausserdem selbst den DATA-Lauf 0016 an (Abschnitt 9): angelegt, gebaut und bewertet (APPROVE) in 17 Minuten - der Deploy wartet auf das Ende der Probation von A (Embargo). Seither bis 14:56 UTC wiederholt sich derselbe ruhige Durchgang alle 15 Minuten (A beobachten, B und 0016 warten), ohne Fehler.

8. RULE-GAP-Zulauf (Abschnitt 6, E3)

Der Regelkandidat entsteht jetzt aus dem Betrieb (ops/selfimprove/regel_zulauf.py, Server: api_server._evaluation_beobachtung_protokollieren, Schalter LENNY_ENABLE_REGEL_SCHATTEN war an):

Stufe	Beleg in der Produktion (05.10.2026)
Beobachtungen	drei POST /v1/evaluations des Feldzugangs traverse-field in der Probe-Domaene si-probe, als Testverkehr eingespeist durch ops/selfimprove/probe_verkehr.py (01:11 UTC, je eigener Beleg), Antwort unknown (rule_below_trust_gate) - Beobachtungsprotokoll des Servers; die Proben des Dienstkontos selfimprove zaehlen bewusst nicht
Cluster / unabhaengig	Domaene + verlangter Schluss hypothese:probe-y; 3 unabhaengige Faelle, 3 Belegwurzeln, 1 Zugang - Bericht der Signalquelle regelmuster
Hypothese	hyp-aba2e0031692: requires symptom:probe-c, symptom:probe-d (gemeinsamer Kern), concludes hypothese:probe-y - RULE_GAP-Lauf SIR-20261005T011226Z-0014 (01:12 UTC), Klasse aus belegten Fakten (RULE_GAP: Fakten vorhanden, es fehlt der Schluss)
Kreativ + Schatten	Kandidat im KREATIV-Gehirn (frag:regel:si:si-probe:hyp-aba2e0031692, Namensraum evaluation:si-probe), Schattenlauf in der Sandbox: davor unknown, danach 1 kreativer Treffer, 9 Wirkungsmeldungen der Bewertung
Entscheidung	Evaluator APPROVE (alle 13 geforderten Gates gruen, Zielfix FAIL -> PASS), Anwendung als Aenderungssatz CS-20261005T021613Z-1ed66678 mit Rueckweg, accepted (02:16 UTC): die Auswertung bleibt unknown - ein Schluss der Regel wird NICHT als Wahrheit ausgegeben
Wirkung / Schwelle	drei unabhaengige Wirkungsmeldungen bestaetigt des Feldzugangs (je Auswertungs-Referenz): Vertrauen 0,10 -> 0,15 -> 0,20, traegt: false (Balken nicht erreicht)
Auswahl (LAI/2)	verlangt zwei unabhaengige Evidenzfamilien (core/rueckkehr.py); fuer die Probe-Domaene gibt es sie nicht - die Regel bleibt Kandidat, es gibt keine Rueckkehr in die Wahrheit

Ausloeser des Auftrags: A (wiederholter gleicher Schluss) und C (Fakten da, Schlussluecke kehrt wieder) sind angebunden (in den Beobachtungen dieselbe Messung), B (wiederholte Wirkung) traegt die Hypothese nach dem Ursprung; D (wiederkehrender Konflikt mit derselben Aufloesung) ist NICHT angebunden - das Protokoll kennt die Aufloesung eines Konflikts nicht. Nicht ausreichend und nie Ausloeser: eine einzelne Beobachtung, ein Modellurteil, dieselbe Anfrage wiederholt, dasselbe Fragment oder derselbe Wurzelbeleg. Nachweis: docs/produktionsautonomie/nachweise/ (Ledger E3), Lauf-Export docs/ausbau/nachweise/lauf_SIR-20261005T011226Z-0014.json, Werkzeug ops/selfimprove/probe_verkehr.py (Testverkehr des Feldzugangs; die Domaene si-probe dient nur den Proben des Kreises).

9. Detektor-Erweiterungen (Abschnitt 8)

Fuenf reale Signalquellen sind an den Autopiloten angebunden (ops/selfimprove/signale.py, fehler_zulauf.py, regel_zulauf.py, Option --signale); jede legt hoechstens einen Lauf an, scheitert fuer sich und entscheidet nichts - Klassifikation, Change-Spec, Gates, Veto und Versuchsgrenze sind die des Kreises. UNABHAENGIG heisst: verschiedene Eingaben an verschiedenen Tagen (dieselbe Frage im Minutentakt ist ein Fall; derselbe Beleg, dasselbe Fragment oder dieselbe Quelle mehrfach ebenfalls).

Quelle	Ergebnis im ersten echten Durchgang (05.10.2026 01:11 UTC, Autopilot --signale, Agent scripted, einmalig)	Fund an den echten Daten	Behebung
Goldfall faellt	Grundlinie angelegt (signale/gold.json, 26 Faelle, 0 gefallen); ein Fall wird erst Problem, wenn er vorher gruen war und in allen Wiederholungen rot ist	-	-
drei gleiche Fehler (nach verletzter Eigenschaft)	Fehlerbuch des Servers live (GET /v1/selfimprove/fehlerbuch 200, 29 Stellen im api_server), keine_aenderung, noch kein Eintrag	-	-
wiederkehrende Unknowns -> DATA	47 Gruppen mit mindestens drei unabhaengigen Faellen (3.665 Eintraege in 14 Tagen), Lauf 0013 (Bauchspeicheldruese, 4 Fragen) -> sicherer Datenkreis -> 3 Versuche, Evaluator REJECT (G24 Zielfix FAIL -> FAIL) -> unresolved, nichts deployt	(1) nur die ersten 20 Gruppen wurden geprueft - die einzige mit Beleg stand auf Rang 22; (2) der strenge Beleg nahm aus "ist ein quer im Oberbauch ... Druesenorgan" die Kategorie "quer"; (3) HTTP 429 der Wikipedia bei wiederholten Abfragen	alle Gruppen, Budget 8 Pruefungen je Durchgang (LENNY_SI_UNKNOWN_BUDGET), gemerkte Absagen (24 h bzw. 15 min); ein kleingeschriebenes Einzelwort ist nie Kategorie, Ortsadverbien eroeffnen keine (Tests)
Regelmuster -> RULE	Lauf 0014 (siehe Abschnitt 8): APPROVE, accepted	-	-
Konfigurationsabweichung -> CONFIG	Lauf 0015 (LENNY_ENABLE_URSACHE_ANSWERS=1, 33 Luecken-Fragen) -> 3 Versuche REJECT: G2 (test_compose_zeile_steht_aus) und G24 -> unresolved	die Suite schreibt die Grundstellung AUS aller drei Schalter der Allowlist fest (Freigabe durch die Entwickler); die Quelle schlug sie trotzdem vor	FESTGESCHRIEBEN: ein Schalter, dessen Grundstellung ein Test festhaelt, wird nie vorgeschlagen - faellt der Test (die Freigabe), ist er frei (Tests)

Nach den Korrekturen: Lauf 0016 (DATA_GAP, Begriff "Tinktur") - vom Planer-Job selbst, ohne jede Handarbeit. Im Durchgang von 06:41 UTC (--signale) fand die Unknown-Quelle im Luecken-Protokoll vier Fragen "Was ist Tinktur?" an drei Tagen (23., 26. und 28.09.; drei unabhaengige Faelle) mit strengem Wikipedia-Beleg, legte den Lauf an (SIR-20261005T064157Z-0016, 06:41:57 UTC), der sichere Datenkreis baute den Datenstapel CAND-9e06eb65d7a2 (fragment_training, Quelle wikipedia_de, Agent controller-daten) und bewertete ihn: APPROVE, alle 13 geforderten Gates gruen, Zielfix FAIL -> PASS (06:58 UTC, 17 Minuten nach dem Anlegen). Der Deploy wartet bewusst: waehrend der Probation von Problem A (CODE) deployt der Autopilot keine Daten (Embargo - ein Daten-Deploy verfaelschte die Messung des Watchers); der Planer holt ihn nach, sobald keine CODE-Probation mehr laeuft (voraussichtlich erst nach der Probation von Problem B, die auf die von A folgt). Andere Gruppen uebersprang die Quelle im selben Durchgang mit Grund und merkte die Absage (z. B. Wikipedia 404 fuer ASCII-gefaltete Schreibweisen wie "Gemaelde", "der erste Satz nennt keine Oberkategorie").

Die Funde sind genau der Zweck der echten Daten: der Datenkreis und der Evaluator haben die unbrauchbaren Kandidaten abgelehnt (nichts kam in die Produktion), und die Quellen sind danach strenger. Belege: docs/ausbau/nachweise/lauf_SIR-20261005T0112*.json, lauf_SIR-20261005T0113*.json, die Evaluator-Bewertungen bewertung_SIR-20261005T01*.

10. Auto-Truth-Status (Abschnitt 7, E5, E6)

SAFE-CLOSED. Gebaut und getestet (core/evidenzfamilie.py, core/wahrheitspromotion.py, core/si_changeset.py, ask_lenny.py, 41 Tests): Evidenzfamilien (evidence_family, root_source_id; mindestens zwei unabhaengige Familien, Wikipedia und Wikidata zaehlen als EINE, fail-closed), Vorher/Nachher je atomarer Charge (Gold, Replay, Zielwirkung auf Datenebene, Regression), ein Aenderungssatz je Promotion mit exaktem Rueckweg (Konflikte werden gemeldet, die Admin-Sperrtabelle bleibt unberuehrt), Wirkungsbeobachtung mit selbsttaetigem Rueckweg, Aktivierungsbedingungen. Der Auto-Pfad ist fail-closed: ohne ausreichende Evidenz evidenz_unzureichend (7 Tage Pause), ohne Messweg (LENNY_PROMOTION_CHARGE_RUNNER) charge_nicht_verfuegbar; der Produktionsschalter LENNY_ENABLE_AUTO_WIKI_OLLAMA_PROMOTION=0 bleibt aus.

Nachweis	Ergebnis
E5 (eine Familie)	keine Promotion: Evidenz-Tor im Auto-Pfad (Unit-Test) und Stufe e5_eine_familie der Sandbox-Testpromotion
Sandbox-Testpromotion (ops/selfimprove/auto_truth_nachweis.py --sandbox, 7,3 s)	auf Datenbankkopien mit dem echten Antwortweg: Charge angewandt (ACCEPT, Zielwirkung im Datenstand), Beobachtung ohne Befund, harter Befund -> Rueckweg, exakter Rueckweg (fremde Aenderung, Ursprung und Admin-Sperre bleiben), Antwort nach dem Rueckweg wie vorher
Aktivierungsstatus am echten Bestand (--status)	SAFE-CLOSED; fehlt: zwei unabhaengige Familien real testbar, Lauf-Runner aktiv, Gold-Schranke gruen
E6 (zwei Familien)	nicht real verfuegbar (siehe Abschnitt 11); eine synthetische zweite Familie gibt es nur in der Sandbox-Testpromotion und ist dort als synthetisch markiert - kein Beleg fuer die Produktion

Ehrlich: Die Zielwirkung ist eine Wirkung im DATENSTAND; ob eine aufgenommene Aussage sofort beantwortet wird, entscheidet weiterhin das Vertrauen (Stabilitaet oder externe Verifikation, ask_lenny._vertrauensarm). Beleg: docs/produktionsautonomie/nachweise/auto_truth_3784085.json.

11. Evidenzfamilien

Am echten Bestand (lesend, im Container, 05.10.2026): 22.698 Fragmente der Wahrheit, davon 5.982 mit Beleg; alle Belege gehoeren zur Familie wikimedia; 0 Fragmente tragen Belege aus zwei unabhaengigen Familien. Eine zweite unabhaengige Quelle wurde bewusst NICHT erfunden oder nur fuer die Zahl eingefuehrt (Abschnitt 12 des Auftrags). Die Auto-Truth-Promotion bleibt deshalb aus; das ist kein Blocker der uebrigen Produktionsautonomie (Abschnitt 15 des Auftrags).

12. Rollback-Bereinigung (Abschnitt 9)

Werkzeug ops/selfimprove/aufraeumen.py (28 Tests; Trockenlauf und Ausfuehrung, Muster-Pruefung auch auf dem Host, docker rmi ohne -f). Behalten: aktive Version samt Rollback-Ziel, Ziel jeder laufenden Probation und jedes offenen Laufs, die letzten drei vollstaendig gueltigen Staende (Verzeichnis mit Compose, Archiv, Plan UND Abbild-Tag mit der im Plan genannten ID), alles juenger als 6 Stunden. Ausgefuehrt am 05.10.2026 00:53 UTC (Beleg docs/produktionsautonomie/nachweise/rollback_bereinigung_20261005T0053Z.json):

Messgroesse	vorher	nachher
Rollback-Verzeichnisse	20 (18,4 MB)	4 (3,7 MB)
Abbild-Tags v01b-lenny-api:rb-*/rollback-*	22	5
freier Platz (Rollback-Ordner)	28,94 GB	28,96 GB (+15,06 MB)
freier Platz (Docker-Wurzel)	-	+0,15 MB (die Schichten der Staende sind geteilt)
/health-Identitaet	Commit 3784085, Abbild-Digest, Umgebungshash	unveraendert
Rollback-Ziel der aktiven Version	rb-d48293942fca-20261005t003056z	weiter vollstaendig (rollback_bereit ok)

Zweite Ausfuehrung (Endstand, 05.10.2026 06:43 UTC) nach den drei Deploys des Tages: es standen wieder 11 Verzeichnisse (10,5 MB) und 12 Abbild-Tags; entfernt wurden die vier aelteren als 6 Stunden und nicht referenzierten (3,7 MB), uebrig sind 7 Verzeichnisse (6,8 MB) und 8 Tags. Health unveraendert, das Rollback-Ziel der aktiven Version und das Ziel der laufenden Probation (rb-b787d8fc3bf3-20261005t060339z) vollstaendig vorhanden, 0 Loeschfehler (docs/produktionsautonomie/nachweise/rollback_bereinigung_20261005T0643Z.json).

Keine Datenbanken, keine Audit-Nachweise und keine fremden Abbilder wurden angefasst. Beobachtung ausserhalb des Auftrags: docker system df meldet 128,5 GB freigebbare Abbilder (84 %) - nicht Teil von Abschnitt 9, nicht angefasst.

13. Branch-Push (Abschnitt 10)

Zeit (UTC)	Ereignis
05.10. 00:56-01:07	erster Push von selbstverbesserung blieb am Git Credential Manager haengen (git-credential-manager get, im timeout 280 abgebrochen). Ursache: vier VERWAISTE git-credential-manager.exe get-Prozesse (Elternprozess weg, Stunden alt) aus frueheren git-Aufrufen
05.10. 01:08-01:10	Prozesse abgeraeumt, git push origin selbstverbesserung ohne Zeitlimit im Hintergrund: 9ba0f54..3784085 (18 Commits, 37 Dateien; vorher Scan der Aenderungen auf Schluessel, Tokens und private Schluessel: keine Treffer; keine temporaeren Produktionskopien im Repository)
05.10. 07:02-07:10	Endpush mit dem Abschlussstand: PUSH_AUTH_BLOCKED (zwei Versuche, jeder nach 5 Minuten beendet). Der Git Credential Manager (Anbieter generic, Gitea-OAuth gegen git.mycubeserver.com) findet keine gespeicherten Zugangsdaten und kann den OAuth-Aktualisierungstoken nicht erneuern (Spur des Credential Managers: unauthorized_client: token was already used); der Browser-Ablauf (Gitea "Anwendung autorisieren") lief damals nicht durch, und im Terminal ohne Tastatur fragt git per /dev/tty vergeblich nach Benutzername und Kennwort. Eine OAuth-Freigabe ist nicht Sache der Automatik, und Zugangsdaten werden weder gesucht noch ersetzt (Abschnitt 10 des Auftrags: PUSH_AUTH_BLOCKED dokumentieren und weiterarbeiten).
05.10. 15:01	Endpush gelungen (auf Anweisung des Administrators wiederholt): 9a37300..ff1cc2b, 19 Commits. Der Credential Manager holte die Anmeldung diesmal innerhalb von 4 Sekunden und speicherte sie (ob die Gitea-Freigabe im Browser selbsttaetig durchlief oder vom Administrator bestaetigt wurde, zeigt seine Spur nicht; ich habe nichts freigegeben); git ls-remote origin selbstverbesserung bestaetigt ff1cc2b. Vorher Geheimnis-Scan: 63 geaenderte Dateien, 0 Treffer; keine Datenbanken, Schluessel oder Produktionskopien. Berichtigung: als bisherigen Remote-Stand meldete git 9a37300 (der Stand des Zweigs um 03:09 MESZ), nicht 3784085, wie das lokale Tracking zeigte; 9a37300 ist ein Vorfahr des Endstands, es war ein reiner Fast-Forward, nichts ging verloren.

Nachgeholt (15:01 UTC): der Stand ist vollstaendig committet, per Geheimnis-Scan geprueft und gepusht. Die Kandidaten-Branches si/CH-* (Audit-Spur der Selbstverbesserung) liegen weiter NUR lokal - sie zu pushen (git push origin "refs/heads/si/*:refs/heads/si/*") ist eine Entscheidung des Administrators und wurde nicht ohne Auftrag getan.

14. [DEUTUNG] KeyError 'JaNein' (Abschnitt 11)

Thema	Befund	Beleg	Status
Ursache	frage_deutung._FORM_ABSICHT kannte die Formen JaNein und Urs nicht; die Deutung wurde bei jeder Ja/Nein-Frage mit KeyError: 'JaNein' uebersprungen (abgefangen, die Antwort blieb unveraendert - kein Hard-Blocker)	Commit 3479710	behoben
Fix	die Formen sind im Vertrag; Wirk hat keine Absicht und faellt auf die Tafel zurueck	core/frage_deutung.py, tests/test_deutung_ja_nein.py (6 Regressionstests)	DONE
Laufzeit vorher (Produktion d482939, 05.10. 00:45 UTC)	dreimal [DEUTUNG] uebersprungen: KeyError: 'JaNein' bei drei Ja/Nein-Fragen; Fehlerbuch-Endpunkt noch 404	docs/produktionsautonomie/nachweise/pa11_vorher_d482939.json	belegt
Laufzeit nachher (Produktion 3784085, 00:50 UTC)	dieselben Fragen, gleiche Antworten, kein DEUTUNG/KeyError/Traceback im Container-Log; Fehlerbuch 200, 0 Eintraege	docs/produktionsautonomie/nachweise/pa11_nachher_3784085.json	DONE
Laufzeit am Produktionscommit (0d7f4e8, 06:42 UTC)	dieselben Fragen: HTTP 200, keine DEUTUNG-/KeyError-/Traceback-Zeile, Fehlerbuch 200, 0 Eintraege (core/frage_deutung.py seit 3784085 unveraendert)	docs/produktionsautonomie/nachweise/pa11_nachher_0d7f4e8.json	DONE

15. Vollstaendige Tests

Messung	Ergebnis
Deploy-Schranke vor dem zweiten Sammel-Deploy (Commit b787d8f, 05.10.2026 05:21-05:38 UTC)	tests/: 3.750 Tests, 0 Fehlschlaege, 0 Fehler, 21 uebersprungen (799 s); core/: 2.210 Tests, 7 Fehlschlaege + 24 Fehler = die bekannten Altfaelle, 2.081 gruen = die Grundlinie (163 s) - Schranke gruen
Deploy-Schranke vor dem ersten Sammel-Deploy (3784085, 00:31-00:48 UTC)	gruen (tests/ ohne Fehlschlag, core-Grundlinie 2.081)
Vollsuite mit angewandtem Fix von Problem A in einem Scratch-Worktree (05:04-05:17 UTC)	3.727 gruen, 2 rot: der Selbsttest, der den Probe-Defekt voraussetzte (behoben), und ein Agent-Test, der nur an einer Kollision paralleler Laeufe scheiterte (isoliert gruen)
Neue Tests dieses Auftrags (Auswahl)	test_brain_guards_atomar 9, test_deutung_ja_nein 6, test_wahrheitspromotion 41, test_si_aufraeumen 28, test_si_headless_beweis 12, test_si_e2_beweis 11, test_si_e1_beleg 11, test_si_e7_beweis 3, test_si_probe_verkehr 6, test_si_signale 33 (u. a. Budget, gemerkte Absagen, festgeschriebene Schalter), test_si_controller 31 (Rebase im 3. Versuch), test_si_daten_quelle, test_si_identity 5, test_si_autopilot_betrieb 25, test_regel_zulauf 19, test_fehlerbuch 15, test_fehler_zulauf 20

Endstand - Vollsuite des Code-Stands der Zweigspitze af8a9b9 (05.10.2026 06:26-06:41 UTC, Deploy-Schranke unit_gates deploy-gate in einem frischen Worktree des Commits, danach entfernt; docs/produktionsautonomie/nachweise/vollsuite_af8a9b9.json):

Stufe	Ergebnis
tests/	3.755 Tests: 3.734 gruen, 0 Fehlschlaege, 0 Fehler, 19 uebersprungen, 2 erwartet fehlgeschlagen (729 s); keine flackernden Faelle
core/	2.210 Tests: 7 Fehlschlaege + 24 Fehler (die bekannten Altfaelle der Grundlinie), 2.081 gruen = die Grundlinie (2.081), nichts ausgefallen (161 s)
Schranke	gruen

Der Produktionscommit 0d7f4e8 selbst bestand dieselbe Schranke vor seinem Deploy (06:04-06:19 UTC; tests/ 3.754 Tests, 3.733 gruen, 0 Fehlschlaege; core/ 2.081 gruen); zur Zweigspitze af8a9b9 unterscheiden sich nur drei Dateien (Betriebsdokument, ops/selfimprove/controller.py - Planer-Seite, ein Test). Danach kamen nur noch Dokumentation, Ledger und Nachweise. Die Schranke ist die der Produktion und wurde nicht abgeschwaecht (die sieben Fehlschlaege und 24 Fehler in core/ sind Altfaelle der Grundlinie, kein Teil dieses Auftrags).

16. Runtime-Smokes

Gemessen an der laufenden Produktion 0d7f4e8 (soweit nicht anders angegeben, 05.10.2026 06:23-06:43 UTC):

Messung	Ergebnis	Beleg
Health	status: ok, Identitaet vollstaendig (Commit, Abbild, Konfiguration, Umgebung, Policy, Schema, Datenstand g54, Modelle gepinnt)	Abschnitt 2, Deploy-Ereignis
Smoke (26 Gold-Faelle vorher/nachher)	hart: keine neuen Falschen, keine Verschlechterung, keine verlorene Provenienz, kein unerlaubtes Unknown; Absagequote 88,46 % vorher und nachher (3 richtig, 0 falsch, 23 unknown)	docs/ausbau/nachweise/lauf_SIR-20261002T214311Z-0001.json (deploy_event)
Security (8 Pruefungen)	alle gruen: Chat ohne Anmeldung 401, Dienstkonto ohne Admin-Endpunkt 403, Nutzer ohne Admin-Endpunkt 403 und ohne Kreis 403, anonym 401, Dienstkonto kann keine Sperre aufheben 403, Admin-Sperr-Ereignisse unveraenderlich (Trigger), Audit des Kreises lueckenlos	dito
Probation-Beobachtung des Watchers (erster Tick 06:25 UTC)	Admin-Sperre ok, 0 Tracebacks, Container ohne Neustart, Datenintegritaet ok, Gold-Smoke ok, Health ok, Identitaet ohne Abweichung, Tenant-Isolation (9 Faelle, 0 Lecks), Zielfix wirksam	Artefakt probation_events des Laufs 0001
Probation-Beobachtung des Watchers, fortgeschrieben (Stand 05.10. 14:55 UTC)	103 Ticks seit 06:25 UTC, hard_fail: false, keine harten Befunde, 0 rote Health-Durchgaenge; letzte Pruefung: Admin-Sperre, Container, Health, Identitaet und Zielfix ok; Gold-Smoke (14:30 UTC): Absagequote 88,46 % wie vorher, 0 falsch	Artefakt probation_events des Laufs 0001
E7 Admin-Veto	26 Schritte gruen (Server-Sandbox, Stand 3784085): der Administrator sperrt, 3 Durchgaenge + Detektor + neue Evidenz bewegen nichts, 409 admin_gesperrt, die Aufhebung nur durch den Administrator (Dienstkonto 403), danach setzt der Autopilot fort, Audit-Kette lueckenlos	docs/produktionsautonomie/nachweise/e7_admin_veto_autopilot_3784085.json
E8 Guard-Atomaritaet (06:43 UTC, Kopie der Produktions-DB im Container der Produktion)	die deployte atomare Fassung: 24.781 Schreibversuche mit ungueltigem Brain - 0 angenommen, 0 von 304.571 Beobachtungen mit unvollstaendigem Waechtersatz, 33 Installationen, 0 Fehler; Negativkontrolle ohne Huelle: 445.419 von 458.359 Beobachtungen sehen nur 45 von 46 Waechtern - die Messung sieht den Fehler; Kopie danach geloescht	docs/produktionsautonomie/nachweise/e8_guard_atomaritaet_produktion_0d7f4e8.json (frueherer Lauf an 3784085: ..._3784085.json; core/fragment_store.py ist seither unveraendert)
PA-11 [DEUTUNG] (06:42 UTC)	drei Ja/Nein-Fragen: HTTP 200, keine DEUTUNG-, KeyError- oder Traceback-Zeile im Container-Log, Fehlerbuch 200 mit 0 Eintraegen	docs/produktionsautonomie/nachweise/pa11_nachher_0d7f4e8.json
Identitaet nach dem Lazy-Import	config_hash_env bleibt 24e43e2e... (seit dem Ausgangsstand unveraendert)	identitaet_laufzeit_3784085.json; /health 06:28 UTC
Rollback-Bereinigung (Endstand 06:43 UTC)	11 -> 7 Verzeichnisse (10,5 -> 6,8 MB), 12 -> 8 Abbild-Tags; Health unveraendert; das Rollback-Ziel der aktiven Version vollstaendig; keine Datenbank, kein Audit angefasst	docs/produktionsautonomie/nachweise/rollback_bereinigung_20261005T0643Z.json

17. Verbleibende echte Blocker

Punkt	Art	Stand
Auto-Truth (E6, Aktivierung)	Datenlage: im Bestand gibt es nur die Evidenzfamilie wikimedia; eine zweite unabhaengige Quelle wurde nicht erfunden	SAFE-CLOSED - ausdruecklich belegt, dass keine unsichere Promotion erfolgt; kein Blocker der uebrigen Produktionsautonomie (Abschnitt 15 des Auftrags)
Probation von Problem A (24 h) und Bau + Probation von Problem B	zeitgebunden (Policy: 24 h Probation, hoechstens ein CODE-Kandidat gleichzeitig), laufen autonom weiter	A: probation seit 05.10. 06:23 UTC, Ende fruehestens 06.10. 06:23 UTC (08:23 MESZ), 103 Ticks des Watchers (Stand 14:55 UTC), kein harter Befund. B: Lauf 0012 queued, der Planer baut ihn danach selbst (Abschnitt 5). Weder von mir abzuwarten noch zu entscheiden
Lauf 0016 (DATA, Begriff "Tinktur")	approved, der Deploy wartet laut Embargo auf das Ende der CODE-Probation (A, danach B)	deployt der Planer selbst; keine Handarbeit noetig
RULE-Zulauf aus organischem Verkehr	Datenlage: das Beobachtungsprotokoll des Servers laeuft erst seit 05.10. 00:48 UTC; der Beleg E3 nutzte eingespeisten Testverkehr des Feldzugangs in der Probe-Domaene si-probe	der Mechanismus lief real und vollstaendig; organische Muster fliessen automatisch ein, sobald sie auftreten (--signale ist aktiv)
Auswahl in LAI/2 fuer Regelhypothesen	verlangt zwei unabhaengige Evidenzfamilien; fuer die Probe-Domaene gibt es keine	die Regel bleibt Kandidat (gewollt)
Ausloeser D des Regelzuflusses (wiederkehrender Konflikt mit derselben Aufloesung)	Datenlage: das Protokoll kennt die Aufloesung eines Konflikts nicht	nicht angebunden, benannt
Kandidaten-Branches si/CH-* auf dem Remote	Entscheidung des Administrators	lokal vorhanden, nicht gepusht
Wikipedia-Rate-Limit (HTTP 429) fuer die Belegsuche der Unknowns	extern	gemildert (Budget, gemerkte Absagen), nicht beseitigt
ASCII-gefaltete Begriffe im Luecken-Protokoll (z. B. "Gemaelde")	Wikipedia kennt keine Seite dazu (HTTP 404); die Quelle merkt die Absage fuer 24 h	nicht behoben (Auftrag Abschnitt 12: keine unnoetigen Erweiterungen) - eine Rueckfaltung ae/oe/ue waere ein moeglicher naechster Schritt
128,5 GB freigebbare Docker-Abbilder (84 %) auf dem Host	Betrieb, ausserhalb von Abschnitt 9	nicht angefasst

AUTH_BLOCKED (Headless-Coding-KI) liegt nicht vor: die CLI ist angemeldet und hat den E1-Lauf gebaut. PUSH_AUTH_BLOCKED lag am Vormittag fuer den Endpush vor und ist behoben (Abschnitt 13: gepusht um 15:01 UTC, Remote ff1cc2b); es hat keinen anderen Teil des Auftrags aufgehalten.

Funde dieses Auftrags (alle behoben, mit Test)

Fund	Wirkung	Behebung
Identitaets-Drift durch einen nachtraeglichen Import (gemma_loop_server)	Fehlalarm des Watchers, ein gesunder CODE-Kandidat (0011) wurde zurueckgerollt	si_identity rechnet mit der Umgebung des Prozessstarts (690d96e)
Controller.rebasiere im 2./3. Versuch	der Lauf blieb in reproducing, wo ihn kein Autopilot mehr anfasst (Lauf 0012)	Befund bleibt, Messung vor dem Zustandswechsel, ein Spec-Fehler laesst nie einen Lauf haengen (1758fd7)
erster echter Headless-Lauf	die Coding-KI gab nach einem verweigerten Bash-Heredoc auf, kein Commit	der Auftrag nennt die erlaubten Bash-Formen; Transkript und Endtext werden gesichert
Unknown-Quelle	die einzige belegbare Luecke stand auf Rang 22 und wurde nie geprueft; die Wikipedia wurde alle 15 Minuten gedrosselt	alle Gruppen, Budget, gemerkte Absagen
strenger Wikipedia-Beleg	aus "ist ein quer im Oberbauch ... Druesenorgan" wurde die Kategorie "quer"	ein kleingeschriebenes Einzelwort ist nie Kategorie; der Datenkreis hatte den Kandidaten bereits per Messung abgelehnt
Konfigurationsquelle	schlug Schalter vor, deren Grundstellung AUS die Suite festschreibt (drei Bewertungen umsonst)	FESTGESCHRIEBEN
Selbsttest haengt vom Probe-Defekt ab	haette jeden echten Fix von Problem A an G2 scheitern lassen	der Defekt kommt als Test-Double; zweiter Sammel-Deploy vor dem Bau
verwaiste git-credential-manager-Prozesse	der Push haengt	abgeraeumt; im Handbuch dokumentiert
zwei Suiten gleichzeitig	Branch-/Worktree-Namen der Kandidaten kollidieren	im Handbuch dokumentiert; nie parallel

Anhang: Abschlussstatus je Punkt (Abschnitt 14 des Auftrags)

Nicht pauschal "fertig": jeder Punkt mit Status, Commit, Tests, Runtime-Nachweis und Produktionsstand. Quelle: docs/produktionsautonomie/ledger.json. DONE heisst: gebaut UND der geforderte Nachweis erbracht. BLOCKED nennt den Grund. NOT DONE: nicht real moeglich, nicht erfunden.

ID	Punkt	Status	Kern	Commit	Tests	Runtime-Nachweis	Produktionsstand
PA-01	install_brain_guards atomar (Abschnitt 1)	DONE	Waechter-Installation in EINER Transaktion; Fehler zwischen DROP und CREATE bringt die alten Waechter zurueck	3479710	test_brain_guards_atomar.py	E8 an der Produktionskopie: 24.781 Umgehungsversuche, 0 angenommen	seit 3784085, jetzt 0d7f4e8 (Datei unveraendert)
PA-02	Problem B vollstaendig weiterfuehren (Abschnitt 2)	BLOCKED (zeitgebunden)	Lauf 0012 (Versuch 3) queued hinter der Probation von A; der Rollback-Fehlalarm ist behoben	1758fd7	test_si_identity.py, test_si_controller.py	lauf_SIR-20261004T214027Z-0012.json, identitaet_laufzeit_3784085.json	wartet auf die Policy; baut danach autonom
PA-03	Problem A wieder oeffnen und abarbeiten (Abschnitt 3)	DONE	Lauf 0001 wiedergeoeffnet, vom Planer headless gebaut, APPROVE 14/14, deployt, probation	0d7f4e8	test_si_ch_3e2d574950cc.py, test_si_controller.py	e1_...json, lauf_SIR-20261002T214311Z-0001.json	0d7f4e8 seit 06:23 UTC (Probation bis 06.10.)
PA-04	Headless Coding-KI produktionsfaehig (Abschnitt 4)	DONE	claude -p angemeldet; erster echter Lauf 01:01 UTC (0 Verstoesse); E1 darueber ohne Sitzung	0d7f4e8	test_si_headless_beweis.py, test_si_agent.py, test_si_e1_beleg.py	E:/si_work/headless_beweis.json, e1_...json	wirksam im Planer-Job
PA-05	Autopilot als 15-Minuten-Betriebsjob (Abschnitt 5)	DONE	Planer-Job alle 15 min, eine Instanz, Protokoll ohne Secrets, Fehler stoppen nichts	91064e4	test_si_autopilot_betrieb.py	autopilot.betrieb.jsonl (Kopie in den Nachweisen), Abschnitt 7	laeuft seit 04.10. 20:39 UTC
PA-06	Natuerlicher RULE_GAP-Zulauf (Abschnitt 6)	DONE	Beobachtungen -> Cluster -> Hypothese -> Schatten -> Entscheidung (Lauf 0014 accepted)	4bde769	test_regel_zulauf.py	lauf_SIR-20261005T011226Z-0014.json	Server-Teil seit 3784085
PA-07	Auto-Truth-Promotion auf Sicherheitsstandard (Abschnitt 7)	DONE	Evidenzfamilien, Vorher/Nachher, Aenderungssatz, Rueckweg gebaut; SAFE-CLOSED (nur Familie wikimedia)	c0a9649	test_wahrheitspromotion.py	auto_truth_3784085.json	Schalter AUS (LENNY_ENABLE_AUTO_WIKI_OLLAMA_PROMOTION=0)
PA-08	Detektor aus realen Produktproblemen erweitern (Abschnitt 8)	DONE	fuenf Signalquellen im Betrieb (Laeufe 0013 DATA, 0014 RULE, 0015 CONFIG; Fehlerbuch live); --signale im Planer-Job legte selbst Lauf 0016 (DATA) an	4bde769	test_si_signale.py, test_regel_zulauf.py, test_fehler_zulauf.py	lauf_SIR-20261005T0112*.json, lauf_SIR-20261005T064157Z-0016.json	--signale im Planer-Job aktiv
PA-09	Rollback-Artefakte bereinigen (Abschnitt 9)	DONE	aufraeumen.py; 20 -> 4 Verzeichnisse, danach Endstand 11 -> 7	3bd461e	test_si_aufraeumen.py	rollback_bereinigung_20261005T0053Z.json, ..._0643Z.json	Health unveraendert, Rollback-Ziel vollstaendig
PA-10	Branch selbstverbesserung sichern/pushen (Abschnitt 10)	DONE	Pushes am 05.10. 01:10 UTC und 15:01 UTC (9a37300..ff1cc2b, 19 Commits); dazwischen am Vormittag PUSH_AUTH_BLOCKED (Credential Manager), danach behoben; Geheimnis-Scan sauber (63 Dateien, 0 Treffer)	ff1cc2b (Stand des Endpushs)	-	Abschnitt 13, git ls-remote origin selbstverbesserung	Remote = lokal (danach nur ein Protokoll-Commit zu diesem Push)
PA-11	[DEUTUNG] KeyError 'JaNein' (Abschnitt 11)	DONE	_FORM_ABSICHT kennt JaNein/Urs; 6 Regressionstests	3479710	test_deutung_ja_nein.py	pa11_vorher_d482939.json, pa11_nachher_3784085.json, pa11_nachher_0d7f4e8.json	kein KeyError mehr in der Produktion
E1	autonomer Headless CODE (kein Sitzungs-Subagent)	DONE	autonomer Headless-CODE bis probation, alle elf Bedingungen	0d7f4e8	test_si_e1_beleg.py	e1_SIR-20261002T214311Z-0001_20261005T0624Z.json	0d7f4e8
E2	schlechter CODE-Candidate wird automatisch REJECT	DONE	Kandidat mit Regression -> automatisch REJECT (G2), Produktion unveraendert	8cd74a6	test_si_e2_beweis.py	e2_SIR-20261002T214311Z-0001_20261005T0155Z.json	unveraendert
E3	RULE aus Beobachtungen (automatische Regelhypothese bis Entscheidung)	DONE	RULE aus drei Beobachtungen -> Hypothese -> Schatten -> accepted; Vertrauen 0,10 -> 0,20	4bde769	test_regel_zulauf.py, test_si_probe_verkehr.py	lauf_SIR-20261005T011226Z-0014.json	Regel im KREATIV-Gehirn
E4	DATA aus wiederholten Unknowns	DONE	DATA aus wiederkehrenden Unknowns -> sicherer Datenkreis: Lauf 0013 abgelehnt (nichts deployt); Lauf 0016 (Tinktur) vom Planer-Job selbst angelegt, gebaut, APPROVE 13/13	22053a4	test_si_signale.py, test_si_daten_quelle.py	lauf_SIR-20261005T011223Z-0013.json, lauf_SIR-20261005T064157Z-0016.json	0016: Deploy wartet auf das Ende der Probation von A (Embargo)
E5	Auto-Truth ohne ausreichende Evidenz: keine Promotion	DONE	eine Familie -> keine Promotion (Evidenz-Tor, Sandbox-Stufe)	c0a9649	test_wahrheitspromotion.py	auto_truth_3784085.json	Schalter AUS
E6	Auto-Truth mit zwei unabhaengigen Familien (nur wenn real verfuegbar)	NOT DONE	nicht real verfuegbar: keine zweite unabhaengige Familie im Bestand; nicht erfunden	-		Abschnitt 11	SAFE-CLOSED
E7	Admin-Veto waehrend eines autonomen Vorgangs	DONE	Admin-Veto im autonomen Vorgang: admin_gesperrt, keine Wiederaufnahme durch eine Automatik	1758fd7	test_si_e7_beweis.py	e7_admin_veto_autopilot_3784085.json	Server-Sandbox, Stand 3784085
E8	Guard-Atomaritaet unter parallelem Schreiben	DONE	Guard-Atomaritaet unter parallelem Schreiben: kein Zeitraum ohne wirksame Waechter	f3fb74a	test_brain_guards_atomar.py	e8_guard_atomaritaet_produktion_0d7f4e8.json	0d7f4e8

Begruendung (Abschnitt 15 des Auftrags): Headless-CODE funktioniert real (E1: claude -p im Planer-Job bis in die Probation, Abschnitt 6), der regelmaessige Autopilot laeuft als Betriebsjob (Abschnitt 7, 69 Takte, alle Exitcode 0) und der RULE-Zulauf funktioniert real in der Produktion (E3, Abschnitt 8: Protokoll, Cluster, Hypothese, Schatten, Entscheidung - mit eingespeistem Testverkehr als Eingabe, organische Muster stehen noch aus; der DATA-Zulauf arbeitet dagegen schon mit echten Daten, Lauf 0016). Auto-Truth ist ausdruecklich SAFE-CLOSED (Abschnitt 10/11) - es erfolgt keine unsichere Promotion; das verhindert den Status nicht. Offen und benannt: die zeitgebundene Probation von A, Bau und Probation von B (Abschnitt 17), der Ausloeser D und E6 (Datenlage).

LENNY PRODUKTIONSAUTONOMIE: COMPLETE