LENNY - Abschlussbericht zum finalen Ausbauauftrag "Kontrolliert selbstverbesserndes System"¶
Stand: {{STAND}} ({{STAND_MESZ}}); alle Zeiten UTC, MESZ = UTC + 2 (z. B. 15:14 UTC = 17:14 MESZ). Repository E:\Lenny_zf, Branch selbstverbesserung, Prototyp experiments/lenny_language_layer_prototype_v1, Commit {{HEAD}}.
Auftrag: LENNY_FINALER_AUSBAUAUFTRAG_SELBSTVERBESSERUNG (45 Abschnitte). Aufbau nach Abschnitt 44 (A Implementiert, B Gates, C End-to-End-Nachweise, D Rest) und den Pflichtangaben
der Ausfuehrungsanweisung (Ausgangszustand, Endzustand, Chronologie, Deployments, Rollbacks, Migrationen, Konfiguration, Abweichungen, Funde, Blocker). Die Tabellen entstehen
aus docs/ausbau/ledger.json und docs/ausbau/nachweise/ (python tools/ausbau_bericht.py), nicht aus dem Gedaechtnis; die Chronologie im Detail steht in
docs/ausbau/AUSFUEHRUNGSPROTOKOLL.md, der Betrieb in docs/SELBSTVERBESSERUNG_BETRIEB.md.
0. Ergebnis in Kuerze¶
- Der Kreis laeuft in der Produktion - Erkennen, Klassifizieren, Reproduzieren, Spezifizieren, Bauen, Pruefen, Deployen, Beobachten, Zurueckrollen - fuer alle vier Klassen: DATA_GAP, RULE_GAP, CONFIG_GAP
und CODE_GAP. Modus
deploy(die Obergrenze der Policy), ohne menschliche Vorabfreigabe; Administratoren haben Veto, Sperre und Reaktivierung. - Implementierungsposten I-001 bis I-046: {{ZAEHLER_POSTEN}} DONE. Gates G1 bis G30: {{ZAEHLER_GATES}}. End-to-End-Nachweise (Abschnitt 44 C): {{ZAEHLER_E2E}} DONE. Abschlusskriterien (Abschnitt 40): {{ZAEHLER_KRITERIEN}} belegt.
- Produktion: Commit {{PROD_COMMIT}} (
/healthnennt Commit und die volle Versionsidentitaet). Seit dem Ausgangsstand {{COMMITS_SEIT_AUSGANG}} Commits ({{AENDERUNGSUMFANG}}). - Ehrlich vorweg (Einzelheiten in Abschnitt 12 und 13): der erste CODE-Lauf (0003) wurde nach 90 Minuten Probation vom Watcher zurueckgerollt - ein Fehlalarm seiner Schema-Pruefung, nicht der Kandidat; der Fehler
ist behoben, der Detektor hat das Problem selbst neu angelegt; der Wiederholungslauf 0011 scheiterte danach an einem zweiten Werkzeugfehler (getrennte Datenkopien in der Bewertung, ebenfalls behoben) und stand auf
unresolved(er wurde am 04.10. mit neuer Evidenz wieder geoeffnet und wartet inqueuedauf den Bau). Der Erfolgslauf ist {{LAUF_ERFOLG_ID}} (Problem C): Bewertung APPROVE, autonomer Deploy, 24 Stunden Probation ohne Hard-Fail,acceptedam {{ACC_KURZ}}. Die Coding-KI lief als Subagent der Sitzung, nicht ueberclaude -p(die CLI ist auf dieser Maschine nicht angemeldet); der Controller ist ein Kommando mit Autopilot, kein Dauerdienst; Auto-Truth-Promotion ist weiterhin aus. - Zuletzt gefunden und behoben (04.10., Abschnitt 13): ein mit neuer Evidenz wieder geoeffneter Lauf wurde vom Detektor nicht weitergefuehrt - der Fix (d482939) ist von Hand mit dem Sicherheitsnetz des Controllers deployt und an Problem B in der Produktion belegt.
{{TAB_KRITERIEN}}
Das Urteil steht am Ende von Abschnitt 18.
1. Ausgangszustand¶
Stand 02.10.2026 17:06 UTC: Commit 8632d51 (Abschluss des Zwischenauftrags), um 17:25 UTC deployt; Produktion = Repository.
Vorhanden: der Antwortweg (Wahrheits- und Kreativgehirn, Router, Mandanten- und persoenliches Gedaechtnis), die administrative Sperrebene (D-021: Fragment, Relation, Zweig sperren und reaktivieren, append-only mit Datenbank-Triggern), Evidenzfamilien (D-022), das eingefrorene Hard-Gold (D-024, 26 Faelle), die Codepfade fuer Befoerderungsquelle und Draht-Verlauf (beide Schalter aus).
Nicht vorhanden: jede Selbstverbesserung. Es gab keine Policy-Datei, keine Zustandsmaschine, keinen Detektor, keine Coding-KI-Anbindung, keine Sandbox, keinen Evaluator, keine Versionsidentitaet,
keine Deploy-Schranke (Tests liefen nicht im Deploy), keinen Rollback-Pfad, keine Probation, keinen Watcher. Die Auto-Befoerderung (LENNY_ENABLE_AUTO_WIKI_OLLAMA_PROMOTION) war seit 02.10.2026 10:02 UTC aus.
Modell-Image ollama/ollama:latest wurde bei jedem Deploy neu gezogen. Von den 1.282 befoerderten Fragmenten trugen 1.198 im letzten Ereignis keine Quelle.
2. Endzustand¶
| Angabe | Wert |
|---|---|
Produktion (Commit, /health) |
{{PROD_ZEILE}} |
| Versionsidentitaet | Commit, Abbild-Digest, Config-Hash, Env-Hash, Policy-Hash, Schema, Datenstand ({{DATENSTAND}}), Modell-Digests (gepinnt), Goldset-Version - vollstaendig: true |
| Modus | deploy (Policy-Obergrenze; Administrator kann absenken, nie anheben) |
Policy (config/self_improvement_policy.json) |
3 Versuche je Problem, 1 CODE-Kandidat gleichzeitig, 24 h Probation, Absagequote +1,0 pp, p95 und Peak-Speicher je +25 %, keine neuen Laufzeit-Abhaengigkeiten, keine destruktive Migration, Vollmatrix Tenant, Admin-Lock-Tests, Gold, Replay |
| Probation | {{PROBATION_ZEILE}} |
| Watcher | Host-Cron alle 5 Minuten (/opt/lenny/v01b/si/bin/watcher.py), stuendliche Tenant-Probe (seit 03.10. 16:04 UTC), Wiederholungen vor jedem Befund, der durch eine Wartung kurz entstehen kann (seit 03.10. 16:49 UTC), Absturzschutz je Pruefung und je Marke (seit 03.10. 18:10 UTC) |
| Offene Laeufe | {{OFFENE_LAEUFE}} |
| Repository | Branch selbstverbesserung, Commit {{HEAD}}; akzeptierte Kandidaten sind gemergt; auf origin/selbstverbesserung gepusht (erster Push 04.10.2026 19:45 UTC) |
3. Chronologie der tatsaechlich ausgefuehrten Arbeit¶
(Auszug; vollstaendig mit Nachweisen: docs/ausbau/AUSFUEHRUNGSPROTOKOLL.md.)
02.10.2026
- 10:36-21:02 Phase 0 bis 3: Versionsmarke, Befoerderungsquelle, Draht-Verlauf, Policy, Modell-Festnagelung, Versionsidentitaet, Replay, Vorher/Nachher, Widerspruchsauswahl, Baender, Schwelle je Regel,
Wirkungsmeldung, Schattenlauf, Kreativ im Antwortweg, Raumbestimmung, Sicherheitsgrad (alle neuen Schalter aus).
- 18:30 Phase 1: Deploy-Schranke, Aenderungssatz, Bestreitung nur Admin, Dienstzugaenge. 21:09 Phase 4: Klassifikation, problem_record, Change-Spec, Invariantenregister.
- 21:30-21:44 Deploy 1 (36809f6): Selbstverbesserungskreis serverseitig (19 Zustaende, Audit mit Hash-Kette, Admin-Veto, Detektor, Endpunkte). Der Detektor erkennt die beiden Probe-Defekte in der Produktion selbst.
- 22:00-23:30 Phase 5/6: Coding-KI-Dispatcher, Server-Sandbox, Evaluator; Zieltest an lokalen Instanzen.
03.10.2026
- 01:22 Fund und Behebung: der Evaluator liess die Suite im geteilten Worktree laufen - ein Kandidat mit Regression wurde freigegeben. Seither eigener Worktree je bewertetem Commit.
- 02:17-02:44 Deploy 2 (8d50784), 02:55 Watcher auf dem Host installiert. 03:00 DATA_GAP und RULE_GAP (Server, Controller, Evaluator). 03:46-04:10 Deploy 3 (48f3b04): Befoerderungsquelle und Draht-Verlauf an.
- 03:20 erster abgelehnter Kandidat (Regressions-Drill, G2). 03:22-03:40 DATA-Fehlersuche: der globale Stabilitaets-Pass veraenderte unbeteiligte Antworten (G7/G19 rot) - Stapel ohne globalen Pass.
- 06:24 Rollback-Probe auf dem Produktionshost (9 Schritte gruen). 06:28 Veto-Beweis. 06:30-07:28 Admin-Beweis in vier Runden: gesperrte Relationen und Zweige wirkten noch in Teilen der Antwortwege - behoben in fuenf Commits.
- 07:40-08:02 Deploy 4 (2c9dce8): Admin-Sperre in allen Antwortwegen; der Detektor legt die CODE-Laeufe fuer Problem B und C selbst an.
- 08:04-09:24 CONFIG_GAP (Sicherheitsgrad): Versuch 1 REJECT (zwei Fehler des Werkzeugs, nicht der Aenderung), Versuch 2 APPROVE; 09:25 der erste Controller-Deploy scheitert (rc 127, WSL-Bash), Host-Rollback, rolled_back.
- 08:37-09:01 Deploy 5 (ee97f87). 09:28-10:18 CONFIG-Lauf 0007 accepted (Sicherheitsgrad an). 10:19-11:23 DATA-Lauf 0008 accepted ("Determinismus"). 12:25-12:41 RULE-Lauf 0009 accepted.
- 11:30 Fund in den ersten Live-Antworten: der Sicherheitsgrad stand an falscher Basis - behoben (router_basis); 11:31-11:51 Deploy 6 von der Schranke angehalten, 12:02-12:24 Deploy 7 (ba83df9) gruen.
- 12:45-13:03 Drill auf Problem A: REJECT durch Messrauschen (G27) verbrauchte den letzten Versuch - G27 bestaetigt jetzt eine Ueberschreitung durch eine zweite Messung. 13:33 Deploy 8 (a68c194).
- 13:33-14:21 Drill auf Problem C: Kandidat APPROVE, autonom deployt, der Host-Watcher findet 14:20:40 den Hard-Fail und rollt zurueck (rolled_back).
- 14:22-14:51 Echte Coding-KI an Problem B: Fix (Commit 26bd02c), Bewertung APPROVE (14 Gates gruen), 14:52-15:15 autonomer Deploy, Probation ab 15:14:46.
- 15:18-16:05 Beweise auf dem Produktionsstand (Admin 34 von 34, Veto 22 von 22), vollstaendige E2E (8 von 8), Autopilot, G10-Messung, Tenant-Probe in der Probation (Fund beim Durchgehen von Abschnitt 25).
- 16:45:19 Rollback von Lauf 0003 durch den Watcher - Fehlalarm der Schema-Pruefung (der think_pass-Cron legte Trigger neu an, genau als der Watcher las). 16:45:38 der Detektor legt das Problem selbst neu an (Lauf 0011). 16:49 Watcher behoben und auf dem Host ersetzt.
- 16:50-17:32 Lauf 0011 (Problem B): Versuch 2 build_failed (die Coding-KI benutzte echo - Allowlist-Verstoss), Versuch 3 candidate_ready (Commit d93a06c, 0 Verstoesse), Bewertung REJECT durch G19: eine unerwartete Aenderung ("Nenne ein Beispiel fuer Waerme" verlor "Frost") - ein Messartefakt, denn Basis und Kandidat hatten die Produktionsdaten zu verschiedenen Zeitpunkten kopiert und ein Cron hatte sie dazwischen geaendert. Drei Versuche verbraucht: Lauf 0011 unresolved.
- 17:35-17:55 Evaluator behoben: ein Datensnapshot je Bewertung fuer Basis und Kandidat (Abschnitt 15.1), 7 Tests. Danach Lauf 0010 (Problem C, 2. Versuch): Coding-KI (58 Aufrufe, 0 Verstoesse), Commit fee644a, Bewertung, Deploy und Probation:
{{CHRONIK_0010}}
04.10.2026 {{CHRONIK_ABSCHLUSS}}
4. A. Implementiert (I-001 bis I-046)¶
Je Posten: DONE nur mit gebauter Funktion UND Nachweis (Test und/oder Laufzeit). "Beweis und Runtime-Nachweis" nennt den Code, die Messung und - mit "Runtime:" - den Beleg aus dem Betrieb.
{{TAB_POSTEN}}
5. Testergebnisse¶
- Deploy-Schranke (bei jedem Deploy,
tests/pluscore/-Grundlinie, kein Schalter zum Ueberspringen):
{{TAB_DEPLOYS}}
deploy_fb09da5_gate_rot.log ist der Deploy, den die Schranke angehalten hat (ein roter Test) - kein Deploy. deploy_a1c0286_... ist der erste Controller-Deploy (rc 127 vor der Schranke, siehe Abschnitt 9).
- Evaluator-E2E mit acht echten Kandidaten (lokale Instanzen, LENNY_SI_LANGSAM=1 python -m pytest tests/test_si_evaluator_e2e.py): 8 von 8 Tests gruen, 966 s (am 03.10.); Wiederholung am 04.10. nach den letzten Werkzeug-Aenderungen (Snapshot, SSH-Wiederholung, Watcher): 8 von 8 gruen, 874 s.
{{TAB_E2E_KANDIDATEN}}
- Endstand-Schranke (Worktree des Commits, dieselbe Schranke wie im Deploy; zwischen dem geprueften Code-Stand und dem End-Commit dieses Berichts liegen nur Dokumentation und Nachweisdateien): {{ENDSTAND_SCHRANKE}}
- Selbstverbesserungs-Tests (
tests/test_si_*.py): 32 Dateien, darunter Zustandsmaschine (56), Detektor (19), Controller (28 und 23), Evaluator (26, 14, 8), Watcher (40), Autopilot (19), Agent (18), Deployer (11), Snapshot (7), SSH-Wiederholung (7).
6. Laufzeitnachweise¶
Alle Laeufe des Kreises (Export je Lauf: docs/ausbau/nachweise/lauf_*.json; Hash-Kette des Audits ist lueckenlos):
{{TAB_LAEUFE}}
Die Laeufe 0005 und 0006 sind die K-02-Proben (UNKNOWN: keine Aenderung, nachweise/k02_unknown_probe.json); die Laeufe 0010 (Problem C) und 0011 (Problem B) hat der Detektor nach dem Rollback von 0004 bzw. 0003 selbst neu angelegt.
Lauf 0003 steht auf rolled_back: der Watcher hat ihn nach 90 Minuten Probation zurueckgerollt - wegen eines Fehlalarms seiner Schema-Pruefung (Abschnitt 9 und 13), nicht wegen des Kandidaten (Bewertung APPROVE, alle 14 Gates gruen). Der Fehler im Watcher ist behoben. Lauf 0011 (Problem B, vom Detektor neu angelegt) stand nach drei verbrauchten Versuchen auf unresolved - Allowlist-Verstoss der Coding-KI, Messartefakt der Bewertung, Fehlalarm der Beobachtung; keiner davon war ein Fehler des Fixes - und wurde am 04.10. mit neuer Evidenz wieder geoeffnet (Abschnitt 13): er steht auf queued. Der Erfolgslauf ist {{LAUF_ERFOLG_ID}} (Problem C).
{{LAUF_ERFOLG}}
Bewertungen der Kandidaten (Evaluator in der Server-Sandbox, alle Gates der Klasse; nachweise/bewertung_*.json):
{{TAB_BEWERTUNGEN}}
Weitere Belege: nachweise/admin_beweis_fee644a.json (34 von 34), nachweise/veto_beweis_fee644a.json (22 von 22) auf dem Endstand der Produktion, davor dieselben auf 26bd02c (admin_beweis_26bd02c.json, veto_beweis_26bd02c.json), nachweise/k02_unknown_probe.json, nachweise/rollback_probe_identitaet.json,
nachweise/produktion_*.json (Stand der Produktion, rein lesend), nachweise/phase6_evaluator_e2e_final.json.
7. B. Gates G1 bis G30¶
{{TAB_GATES}}
8. Ausgefuehrte Deployments¶
| Nr. | Commit | Zeit (UTC) | Weg | Ergebnis |
|---|---|---|---|---|
| 1 | 36809f6 | 02.10. 21:31-21:44 | deploy.sh von Hand |
gruen; Zustandsmaschine, Detektor, Endpunkte live; Schranke 3.159 Tests, 0 Fehlschlaege |
| 2 | 8d50784 | 03.10. 02:17-02:44 | von Hand | gruen; Schranke 3.264 Tests; Identitaet vollstaendig |
| 3 | 48f3b04 | 03.10. 03:46-04:10 | von Hand | gruen; Befoerderungsquelle und Draht-Verlauf an |
| 4 | 2c9dce8 | 03.10. 07:40-08:02 | von Hand | gruen; Admin-Sperre in allen Antwortwegen; Detektor legt die CODE-Laeufe an |
| 5 | ee97f87 | 03.10. 08:40-09:01 | von Hand | gruen; Werkzeug-Fixes (Replay-Anhang, Konfigurations-Tests) |
| - | a1c0286 | 03.10. 09:25 | Controller (CONFIG, Lauf 0002) | gescheitert nach 20 s (rc 127): WSL-Bash; Produktion nie umgeschaltet; Host-Rollback; rolled_back |
| - | 82c36dd | 03.10. 09:54-10:18 | Controller (CONFIG, Lauf 0007) | gruen; accepted (Sicherheitsgrad an) |
| 6 | fb09da5 | 03.10. 11:31-11:51 | von Hand | von der Schranke angehalten (1 roter Test), kein Deploy |
| 7 | ba83df9 | 03.10. 12:02-12:24 | von Hand | gruen; Sicherheitsgrad an richtiger Basis, Absage ohne Stufe |
| 8 | a68c194 | 03.10. 13:10-13:33 | von Hand | gruen; G27-Bestaetigung, Drill-Rezept, Drill-Tests |
| - | 869c7c1 | 03.10. 13:55-14:16 | Controller (CODE-Drill, Lauf 0004) | gruen, Probation, vom Watcher nach 4 Minuten zurueckgerollt |
| - | 26bd02c | 03.10. 14:52-15:15 | Controller (CODE, Lauf 0003) | gruen; Probation; nach 90 Minuten vom Watcher zurueckgerollt (16:45:19 UTC) - Fehlalarm seiner Schema-Pruefung |
| {{DEPLOY_ERFOLG}} |
Die Datenlaeufe (0008 DATA, 0009 RULE) deployen keinen Code: der Server wendet den freigegebenen Stapel als Aenderungssatz an (Rueckweg getestet), Abschnitt 25 verlangt dafuer keine Probation.
9. Ausgefuehrte Rollbacks¶
| Zeit (UTC) | Ausloeser | Weg | Ergebnis |
|---|---|---|---|
| 03.10. 06:24 | Rollback-Probe (Identitaetsrollback auf dem Produktionshost) | rollback_host.py |
9 Schritte gruen (Compose, image_id.env, Host-Dateien, Abbild-Tag, compose up --no-build, Health, Identitaet, Abbild, Admin-Ereignisse 8/0 unveraendert) |
| 03.10. 09:25 | Deploy ueber den Controller scheitert (rc 127) | Controller, idempotenter Host-Rollback | Lauf 0002 rolled_back; Produktion unveraendert (ee97f87 gesund) |
| 03.10. 14:20:40 | Gold-Hard-Fail im Betrieb: die Reproduktion probe_vokale besteht in der Produktion nicht (Drill, Lauf 0004) |
Host-Watcher (Cron), ohne Controller | 9 Schritte gruen, Produktion zurueck auf a68c194, Admin-Ereignisse 8/0 vorher wie nachher; Lauf 0004 rolled_back (nachweise/lauf_SIR-20261003T080247Z-0004.json) |
| 03.10. 16:45:19 | Lauf 0003: Watcher-Rollback durch einen Fehlalarm: "Schema nicht konsistent: Trigger lai2_format_role_delete_guard und lai2_format_role_update_guard verschwunden" - der think_pass-Cron legte sie beim Oeffnen der Datenbank gerade neu an (DROP, dann CREATE) | Host-Watcher (Cron), ohne Controller | 9 Schritte gruen, Produktion zurueck auf a68c194, Admin-Ereignisse 8/0 vorher wie nachher; Lauf 0003 rolled_back. Der Rollback selbst arbeitete einwandfrei, die Pruefung davor nicht - behoben (Abschnitt 13) |
10. Migrationen und Datenaenderungen¶
- Additiv, nichts geloescht, nichts umgeschrieben: neue Datenbank
selfimprove.db(Laeufe, Ereignisse mit Hash-Kette, Artefakte, Admin-Ereignisse; Update/Delete per Trigger gesperrt); inlenny_fragments.dbdie Tabellensi_changesetsundsi_changeset_opsmit Triggern (Aenderungssaetze, angelegt bei der ersten Nutzung). Die Admin-Sperrtabelle bestand schon. - Datenaenderungen der Laeufe (je Aenderungssatz mit Rueckweg): Lauf 0008
CS-20261003T112235Z-c23dd80d(Belegsatz-Stapel zu "Determinismus",candidate_only, Herkunft Kandidat), Lauf 0009CS-20261003T124046Z-3180eb01(Regelkandidat in der Probe-Domaenesi-probe, Schattenlauf). Datenstand heute{{DATENSTAND_KURZ}}(jeder Aenderungssatz der Cron-Wrapper zaehlt die Generation weiter). - Wiedereroeffnung von Lauf 0011 (04.10. 19:12 UTC): Ereignisse in
selfimprove.db(Hash-Kette:unresolved -> detectedmit dem Artefaktneue_evidenz, danach vier Uebergaenge des Detektors bisqueued); keine Fachdaten. - Persoenliche Angabe des Dienstkontos
selfimprove("Wohnort: ZorgstadtSelfimproveProbeX") fuer die Tenant-Probe des Watchers - das einzige, was die Probe schreibt. - Beim Test von I-019 blieb ein Hinweis in
contests.jsonl(Produktionsdatei) stehen; er ist ein Datensatz des Bestreitungs-Tests, kein Wissen. - Nicht angefasst: die 54 Auto-Befoerderungen vom 02.10. (gemessen: 1 von 54 haette die Baender bestanden), alle Bestandsfragmente, alle Admin-Sperr-Ereignisse (8 vorher, 8 nachher), Modelle und Modell-Digests.
- Auf dem Host: Verzeichnis
/opt/lenny/v01b/si/(Watcher,rollback_host.py, 16 Rollback-Ziele mit Abbild-Tagsv01b-lenny-api:rb-..., Watcher-Protokoll), Crontab-Eintrag*/5(Sicherung der alten Crontab:si/crontab.vor_watcher.20261003T025518Z).
11. Neue und geaenderte Konfiguration; Schalter¶
Neu: config/self_improvement_policy.json (Admin-Obergrenze, nicht durch den Kreis aenderbar), config/model_pins.json (Modell- und Image-Digests), deploy/deploy.sh (Deploy-Schranke, --commit,
Importpruefung vor dem Umschalten, Identitaetsdatei), deploy/docker/docker-compose.yml (unten). Das Ollama-Image ist per Digest festgenagelt (vorher :latest).
Schalter im Compose gegenueber dem Ausgangsstand (git diff 8632d51..HEAD):
| Zustand | Schalter |
|---|---|
| an (neu) | IDENTITAET, AENDERUNGSSAETZE, BEFOERDERUNG_QUELLE, VERDRAHTUNG_VERLAUF, BESTREITUNG_NUR_ADMIN, LUECKEN_ZUGANG, WIDERSPRUCH_AUSWAHL, BAENDER_ENTSCHEIDUNG, SCHWELLE_REGEL, WIRKUNGSMELDUNG, AUSWERTUNG_KREATIV, REGEL_SCHATTEN, ARM_WIRKUNG, RUECKKEHR, SELFIMPROVE, SELFIMPROVE_DETEKTOR, SICHERHEITSGRAD (durch den CONFIG-Lauf 0007) |
| aus (vorher an, Laeufe ohne Ausloeser, D-015) | ABSTRAKTIONSMASS, KNOTEN_ZUSAMMENFUEHRUNG, FAMILIENLAUF, HALTBARKEIT, WIDERSPRUCHSSUCHE, WISSENSBIOGRAFIE, KREATIV_SAAT, KREATIV_ASSOZIATION, KREATIV_KOMBINATION, KREATIV_HYPOTHESE, KREATIV_PERSPEKTIVE, KREATIV_WERTUNG, KREATIV_ZWEIG, KREATIV_AUFLADUNG, KREATIV_VERFALL |
| aus (unveraendert, bewusst) | AUTO_WIKI_OLLAMA_PROMOTION (Auto-Truth-Promotion), Kreativ im Antwortweg und im Raum (Standard aus) |
Weitere Betriebs-Konfiguration: Modus deploy; Dienstkonto selfimprove (Schluessel auf dem Host in ops/lenny_keys.env, lokal in der Schluesseldatei des Controllers); Watcher-Takt 5 Minuten, Gold-Smoke und Tenant-Probe stuendlich.
12. Bekannte Abweichungen (mit technischem Grund)¶
| Thema | Problem (Abweichung und technischer Grund) | Loesungsvorschlag | Status |
|---|---|---|---|
Coding-KI als Subagent der Sitzung statt claude -p |
Der Headless-Aufruf scheitert auf dieser Maschine ("Failed to authenticate: OAuth session expired and could not be refreshed"); eine Anmeldung kann der Auftrag nicht erzeugen. Der Dispatcher-Weg (claude -p, bereinigte Umgebung, Allowlist) ist gebaut und getestet, aber nicht im Laufzeitbetrieb belegt. Der Subagent arbeitet im isolierten Workspace; sein Transkript wird gegen dieselbe Allowlist geprueft (Lauf 0003: 38 Werkzeugaufrufe, 0 Verstoesse). K-05 ist damit strukturell und per Transkript belegt, nicht durch Prozess-Isolation. |
claude login auf dieser Maschine (oder ein Token); danach laeuft CODE auch im Autopiloten |
gebaut und getestet; wartet auf Marco |
| Controller ist ein Kommando (mit Autopilot), kein Dauerdienst | Er braucht das Repository, den Deploy-Schluessel und - fuer CODE - eine angemeldete CLI auf der Maschine des Bedieners. Der Autopilot (python -m selfimprove.autopilot) nimmt dem Bediener das Aufrufen ab (19 Tests, ein Durchgang gegen die Produktion); als Dauerdienst ist er nicht eingerichtet, weil ein ruhender Dauer-Deploy ohne Bediener eine Entscheidung des Administrators ist. Erkennen (Detektor) und Beobachten (Watcher) laufen ohne ihn. |
Windows-Planer-Eintrag, z. B. alle 15 Minuten python -m selfimprove.autopilot im Verzeichnis ops/ (mit SSH_KEY_PATH) |
gebaut und getestet; nicht eingerichtet; wartet auf Marco |
| Der Detektor erkennt, was als Invariante registriert ist | Registriert sind vier Probe-Invarianten, die Unveraenderlichkeit der Admin-Sperr-Ereignisse und die Modell-Pins. Abschnitt 9 nennt, wann ein CODE_GAP automatisch zulaessig ist (der Server erzwingt diese Anlaesse); "Goldfall faellt" und "gleicher Fehler in drei unabhaengigen Faellen" sind keine laufenden Detektoren - das Hard-Gold prueft der Watcher stuendlich nur waehrend einer Probation. Die Probe-Defekte liegen absichtlich in core/selfimprove_probe.py, einem Modul, das kein Antwortweg ruft. |
weitere Invarianten sind je eine Registerzeile mit Test | Umfang, kein offener Posten (kein Kriterium haengt daran) |
| RULE_GAP-Ausloeser synthetisch | Keine Komponente leitet heute Regelkandidaten aus Beobachtungen ab; Lauf 0009 belegt den Weg (Kandidat, Schattenlauf, Wirkungsmeldungen, Bewertung, Anwendung, Rueckweg) mit einem Kandidaten in der Probe-Domaene si-probe. |
sobald eine Komponente Regeln vorschlaegt, nutzt sie erkenne-regel |
Weg belegt, Zulauf fehlt im Produkt |
| Admin- und Veto-Verhalten in Sandkaesten bewiesen, nicht in der Produktion | In der Produktion gaebe es Sperren nur mit einem Administratorschluessel, und kein automatischer Prozess darf sperren oder aufheben. Die Sandkaesten laufen auf dem deployten Commit mit einer Kopie der Produktionsdaten (Zweigblock Hund - Tier an echten Daten). In der Produktion prueft der Watcher den Schutz der Sperr-Ereignisse (Trigger, keine verlorenen Ereignisse). | keiner - die Trennung ist gewollt | erledigt |
| Tenant-Probe der Probation mit Dienstkonten | Die Produktions-Probe nutzt zwei Zugaenge ohne Mandant; die volle Mandanten-Matrix (4 Zugaenge und anonym) laeuft vor jedem Deploy in der Sandbox (G1). Die Probe fehlte in den ersten 50 Minuten der Probation von Lauf 0003 (Fund beim Durchgehen von Abschnitt 25, 16:04 UTC nachgeruestet). | keiner | erledigt, offen genannt |
| Rauschbehandlung der Gates | Ein gefallener Test wird einmal im selben Baum wiederholt und als flackernd ausgewiesen (mehr als 20 Faelle gelten als Bruch); G27 bestaetigt eine Latenz-Ueberschreitung durch eine zweite Messung. Die Schwellen (+25 %, +1 pp) sind unveraendert; eine echte Verschlechterung steht in beiden Messungen. |
keiner | erledigt |
| Kein Datenbank-Snapshot je Code-Deploy | Abschnitt 24 Punkt 2 nennt "Datenaenderungssatz/Snapshot". Festgehalten wird der Datenstand (data_generation, Zahl der Aenderungssaetze) im Rollback-Plan und im Audit; Datenaenderungen eines Laufs nimmt der Controller ueber den Aenderungssatz zurueck (si_changeset.rueckweg, getestet; Rueckweg der Laeufe 0008 und 0009 vorgesehen). Eine Datenbank-Kopie je Deploy zieht der Kreis nicht: sie zurueckzuspielen wuerde spaetere Administratorentscheidungen und Nutzerdaten verlieren (Abschnitt 26, F-J: Admin-Ereignisse haben Vorrang vor dem technischen Rollback). Ein Code-Rollback fasst keine Datenbank an. |
falls gewuenscht: Notfall-Kopie je Deploy, Rueckspielen nur durch den Administrator | Entscheidung, kein offener Posten |
| Auto-Truth-Promotion bleibt aus | Phase 3, letzter Punkt: "kontrolliert wieder aktivieren, sofern alle zugehoerigen Gates gruen sind". Die Gates G1 bis G30 sind gruen und die Voraussetzungen I-029 bis I-037 stehen - aber fuer DIESEN Pfad sind die noetigen Gates nicht gebaut, und Abschnitt 2 der Beschreibung bindet: "Auto-Promotion bleibt aus, bis die noetigen Gates gebaut sind" (die Bedingung der Phase 3, "sofern alle zugehoerigen Gates gruen sind", ist fuer ihn nicht erfuellt). Der Pfad der Auto-Befoerderung (process_next_auto_promotion_candidate) entscheidet seit I-014 nach Modellurteil UND Baender-Regel, kennt aber keine Evidenzfamilien (D-022 verlangt mindestens zwei unabhaengige; Wikipedia, Wikidata und Wiktionary zaehlen als EINE - gemessen 02.10.: 0 von 26.918 Fragmenten haben zwei) und hat keine Vorher/Nachher-Pruefung und keine Wirkungsmessung mit Rueckweg je Befoerderung (Abschnitt 32). Unter D-022 befoerderte er nichts, ohne D-022 waere er nicht "auf denselben Grundprinzipien" (Abschnitt 32); dazu steht im Compose Marcos Vorbehalt "nicht ohne neue Entscheidung wieder einschalten". Ob und mit welcher zweiten, unabhaengigen Quelle automatisch befoerdert werden darf, ist eine Doktrinfrage (D-001: "keine technische"). |
Marco entscheidet die Quelle; danach ein CONFIG-Lauf ueber den Autopiloten (Rueckweg: Schalter wieder auf 0) und eine Wirkungsmessung je Befoerderung | wartet auf Marco |
| Werkzeug-Aenderungen sind lokal | ops/selfimprove/** (Controller, Evaluator, Deployer, Autopilot) laeuft auf der Maschine des Bedieners, gehoert zum verbotenen Bereich der Coding-KI und ist nicht im Produktions-Abbild. |
keiner | erledigt |
| Branch veroeffentlicht, Kandidaten-Branches nicht | selbstverbesserung ist am 04.10.2026 19:45 UTC nach origin gepusht (66 Commits seit signalbaum 8632d51; remote und lokal gleich, geprueft per git ls-remote). Die Kandidaten-Branches si/CH-* (Audit-Spur der Kandidaten, z. B. 26bd02c, d93a06c, c21dfc5, 869c7c1) liegen nur lokal; im Branch steckt von ihnen nur, was gemergt wurde (82c36dd, fee644a). |
git push origin "refs/heads/si/*:refs/heads/si/*" nach Marcos Ja (sonst lassen sich diese Commits aus Bericht und Ledger auf dem Server nicht aufloesen) |
Branch erledigt; Kandidaten-Branches wartet auf Marco |
| Commit-Autor | Die Commits der Coding-KI tragen den Git-Benutzer des Repositorys (Marco Oppel); der Konfigurations-Kandidat traegt "Lenny Selbstverbesserung". | keiner | erledigt |
13. Zusaetzlich gefundene reale Fehler und ihre Behebung¶
| Fund | Wie gefunden | Behebung (Commit) |
|---|---|---|
| Evaluator liess die Suite im geteilten Worktree laufen: ein Kandidat mit Regression wurde freigegeben | E2E mit Kandidat "Regression" (02.10./03.10.) | eigener Worktree je bewertetem Commit (2da19e7) |
Detektor haengte bei jeder Beobachtung Evidenz an; nach einem Rollback bekam das Problem immer Versuch 1 ohne Befund und blieb in reproducing haengen |
Rollback-Drill / Detektor-Test | nur neue Evidenz; naechste Versuchsnummer mit Befund (6c258fa, fb846c5) |
| Regelanlage war nicht idempotent | RULE-Tests | b5794fe |
| Globaler Stabilitaets-Pass veraenderte drei unbeteiligte Antworten (G7/G19 rot) | DATA-Bewertung gegen die Server-Sandbox | Stapel ohne globalen Pass, Server prueft es bindend (bcd4bd5) |
| Befoerderungsquelle (I-004) und Draht-Verlauf (I-005) standen in der Produktion aus: G10 und G3 waeren nicht erzwungen | Durchgehen der Gates gegen den Produktionsstand | eingeschaltet (48f3b04, Deploy 3) |
Admin-Sperre wirkte in Teilen der Antwortwege nicht: gesperrte Relation/Zweig in der Faktenkette, im gewichteten Speicher, in der Ableitung, in frag.relations-Schleifen, in den JSONL-Speichern, in der gewichteten Textroute |
Admin-Beweis in vier Runden an frischen Sandkaesten | 6d30b49, 33c3c59, 21e639a, a6fc902, 29d98c0; Lint-Test prueft jede Relationsschleife |
| Ein einzelner flackernder core-Test (Wanduhr) verbrauchte Versuch 2 | Drill auf Problem A | Gate wiederholt einen gefallenen Test einmal und weist ihn aus (21e639a) |
| Konfigurations-Kandidat abgelehnt: der Replay-Vergleich kannte den erlaubten Absatz nur am Textende (G19), die Konfigurations-Tests schlugen an der eigenen Aenderung fehl (G2) | CONFIG-Lauf 0002, Versuch 1 | _nur_anhang kennt den Absatz vor der Fusszeile, Tests nehmen einen Schalter, der noch auf 0 steht (ee97f87) |
Erster Controller-Deploy scheiterte (rc 127): bash loest unter Windows aus Python auf die WSL-Bash auf |
CONFIG-Lauf 0002 | git_bash() und msys_pfad() (e1ec07d) |
| Sicherheitsgrad an falscher Basis ("Determinismus" Stufe 6 auf einem rohen Fragment, "Hund" Stufe 2; Absagen trugen eine Stufe) - die Gates sehen so etwas nicht | die ersten Live-Antworten nach dem CONFIG-Lauf | Stufe folgt der Basis, die der Antwortweg meldet; Absage und Rueckfrage tragen keine Stufe (b35e850, ba83df9) |
Deploy 6 an einem Test angehalten: test_kette_ohne_verlust nimmt die Schalter aus dem Compose und verglich Zeichen fuer Zeichen |
Deploy-Schranke | Test schaltet den Sicherheitsgrad fuer seine Probe aus (ba83df9) |
| G27 lehnte einen Kandidaten wegen Messrauschen ab (965 -> 1.311 ms bei einem Modul ohne Antwortweg) und verbrauchte den letzten Versuch von Problem A | Drill auf Problem A | zweite Messung bestaetigt eine Ueberschreitung, je Instanz der bessere p95 (a68c194) |
test_si_drills pruefte, dass die Probe-Defekte bestehen bleiben - jede Behebung haette die Suite gebrochen |
Vorbereitung des Ersatz-Drills | Vergleich mit dem Stand statt mit dem Defekt (a68c194) |
| E2E "unbelegte Antwort": G18 blieb gruen - der Patch ersetzte nur eine von zwei Absageformulierungen | vollstaendige E2E (03.10. 15:28) | Kandidat ersetzt beide: G5, G18, G19 rot (13df383) |
| Realdaten-Pruefung des Admin-Beweises wurde uebersprungen (die Definition nennt "Tier" nicht mehr) | Admin-Beweis auf 26bd02c | Pruefung auf die Formen, die die Kante vorher aussprechen (07b3028) |
| Der Watcher pruefte die Tenant-Isolation nicht (Pflichtpunkt der Beobachtung, Abschnitt 25) | Durchgehen von Abschnitt 25 gegen den Watcher | stuendliche Produktions-Probe, Fremdtreffer = Sofort-Rollback (07b3028, live 16:04 UTC) |
| Zeitangaben im Ausfuehrungsprotokoll mischten MESZ und UTC | Gegenpruefung mit den Commit-Zeiten | auf UTC vereinheitlicht |
Der Watcher rollte einen gesunden Kandidaten zurueck: seine Schema-Pruefung sah zwei lai2_format_role_*_guard-Trigger fehlen - der think_pass-Cron (45 */3) legt sie beim Oeffnen der Datenbank per DROP und CREATE neu an, und beide Crons starten zur Minute :45 |
die echte Probation von Lauf 0003, 03.10. 16:45 UTC (der Rollback selbst lief einwandfrei) | Befunde, die eine Wartung kurz erzeugen kann, gelten erst nach drei Wiederholungen im Abstand von 20 s als hart; ein Lesefehler der Datenbank ist weich; 5 neue Tests, auf dem Host um 16:49 UTC ersetzt (d2c914c). Der Detektor legte das Problem 19 Sekunden nach dem Rollback selbst neu an |
| Der Gold-Smoke des Watchers wertete einen Aussetzer der API (HTTP != 200) als Absage - "war richtig, ist jetzt unknown" haette einen gesunden Kandidaten zurueckgerollt | Durchsicht des Watchers nach dem Fehlalarm | Eine Goldfrage ohne HTTP-200-Antwort wird wiederholt; kommt keine, ist der Durchgang nicht auswertbar (weich), der naechste Tick versucht es erneut (d2c914c) |
| Der Watcher konnte durch eine Ausnahme in EINER Pruefung (oder bei EINER Marke) alle uebrigen Pruefungen und damit auch einen Rollback verlieren: ein Absturz beendete den ganzen Tick, ohne dass es jemand sah | Durchsicht des Watchers nach dem Fehlalarm, waehrend der Schranke von Lauf 0010 | _geschuetzt() je Pruefung und Absturzfang je Marke: die Ausnahme wird zu einem weichen Hinweis fehler (<Typ>: ...), die uebrigen Pruefungen und ein echter Hard-Fail laufen weiter; 2 neue Tests (40 im Watcher); auf dem Host um 18:10 UTC atomar ersetzt (371a286) |
Ssh.run verband nie neu: ein Aussetzer des Hosts von wenigen Sekunden (Connection closed by ... port 22, rc 255) liess Admin- und Veto-Beweis scheitern und haette einen autonomen Deploy mittendrin abgebrochen (dieselbe Klasse traegt Sandbox, Evaluator, Controller, Deployer) |
Beweislauf auf fee644a, 04.10. 03:51 UTC | bis zu drei Verbindungsversuche, aber nur bei Fehlern VOR Beginn der Sitzung (der Befehl ist dann nie gelaufen); ein Abriss mitten im Befehl, der eigene Exitcode des Befehls und Zeitueberschreitungen werden nie wiederholt; 7 neue Tests (8484e8e) |
Ein wieder geoeffneter Lauf wurde vom Detektor nicht weitergefuehrt (Abschnitt 13: ein unresolved-Fall "darf spaeter mit neuer Evidenz erneut geoeffnet werden"): der Uebergang unresolved -> detected und das neue Versuchsbudget waren gebaut und getestet, aber der Detektor fuehrte nur NEU angelegte Laeufe weiter - ein wieder geoeffneter Lauf (und einer, der wegen des Modus off in detected stehen blieb) haette dort fuer immer gewartet |
Gegenlesen von Abschnitt 13, 04.10. nach dem Ende der Probation | core/si_detektor.py fuehrt einen bestehenden Lauf in detected beim naechsten Durchgang weiter (ein gesperrter Lauf bleibt gesperrt); neu controller wiederoeffne <run> --grund (nur unresolved/non_reproducible, ohne Begruendung nichts); 6 neue Tests (zwei der drei Detektor-Tests schlugen vor der Korrektur fehl); von Hand mit dem Sicherheitsnetz des Controllers deployt (d482939, 19:12 UTC) und an Problem B in der Produktion belegt: wieder geoeffnet 19:12:48, vom Detektor bis queued weitergefuehrt 19:27:18 |
Beobachtung, nicht behoben: install_brain_guards (core/fragment_store.py) legt die Brain- und LAI/2-Waechter-Trigger per DROP und CREATE OHNE gemeinsame Transaktion neu an - bei jedem Oeffnen der Datenbank durch einen Cron oder den Server sind die Guards fuer einen kurzen Augenblick aus |
Ursachenanalyse des Rollbacks von Lauf 0003 | Der Watcher toleriert das Fenster jetzt. Das Fenster selbst ist ein Fehler des Produkts (ein Schreibzugriff in diesem Augenblick liefe an den Guards vorbei): DROP und CREATE in EINER Transaktion (BEGIN IMMEDIATE ... COMMIT) machen es atomar - eine Aenderung an core/fragment_store.py, ausserhalb dieses Auftrags; als Entscheidung in Abschnitt 19 |
Beobachtung, nicht behoben: im Container-Log der Produktion steht einmal [DEUTUNG] uebersprungen: KeyError: 'JaNein' |
Durchsicht des Logs waehrend der Probation | Das Deutungs-Feature (lenny_deutung, nicht der Kreis) faengt den Fehler ab, die Antwort bleibt unberuehrt; mit den Fragen der Isolationsprobe und den Gold-Fragen nicht nachzustellen. Ausserhalb des Auftrags - als Beobachtung fuer die Seite, die dieses Feature pflegt |
14. Verbleibende Blocker¶
| Thema | Problem | Loesungsvorschlag | Status |
|---|---|---|---|
| Headless-Coding-KI | claude -p braucht eine Anmeldung der CLI auf dieser Maschine. Bis dahin baut der Autopilot nur CONFIG-, DATA- und RULE-Laeufe; CODE-Laeufe braucht der Orchestrator mit dem Sitzungs-Subagenten. |
claude login (oder Token) |
wartet auf Marco |
| MCP-Server mit Autorisierung (nicht Teil dieses Auftrags) | figma, intercom, asana, atlassian, clickup, linear, monday, notion und slack sind nicht nutzbar, bis sie autorisiert sind. | ueber die Connector-Einstellungen von claude.ai oder /mcp freigeben |
wartet auf Marco |
| Sonst | Kein Posten, kein Gate und kein Kriterium ist durch einen technischen Blocker offen. | - | - |
15. C. End-to-End-Nachweise (Abschnitt 44)¶
{{TAB_E2E}}
Die vier Laeufe der Phase 8 (Abschnitt 39):
{{TAB_P8}}
Die geforderten Einzelbelege:
- Ein schlechter Candidate wurde automatisch abgelehnt: Lauf 0001 (drei Versuche REJECT: G2 zweimal, G27 einmal), Lauf 0002 Versuch 1 (G2 und G19), Lauf 0011 Versuch 2 (die Coding-KI loeste das Problem, verstiess aber gegen die Allowlist:
build_failed, Versuch verbraucht), sieben von acht Kandidaten der E2E (Tabelle in Abschnitt 5, z. B. Tenant-Leck G1, Admin-Lock G13/G16, stille Sperre G13, Gate-Abschwaechung G25/G26, unbelegte Antworten G5/G18/G19). In allen Faellen blieb die Produktion unveraendert (G23produktion_unveraendert). - Ein autonomer Candidate war erfolgreich: Lauf {{LAUF_ERFOLG_ID}} (Problem C) - der Detektor legt das Problem nach dem Rollback des Drills (Lauf 0004) selbst neu an (14:20:59 UTC), Spec mit dem Befund des Rollbacks, Coding-KI (Commit fee644a, 58 Aufrufe, 0 Verstoesse), Bewertung (APPROVE), autonomer Deploy, Probation{{ERFOLG_LAUF}}. Zuvor die Laeufe 0007, 0008 und 0009 bis
acceptedund Lauf 0003 (APPROVE, autonom deployt, vom Fehlalarm des Watchers zurueckgerollt). - Der Rollback-Pfad: Lauf 0004 (produktiver Hard-Fail, Watcher, 4 Minuten nach dem Deploy), Lauf 0003 (Watcher-Rollback nach 90 Minuten - ein Fehlalarm, der Rollback selbst einwandfrei: 9 Schritte, Admin-Ereignisse unveraendert) und Lauf 0002 (Deploy scheitert, Host-Rollback); Rollback-Probe auf dem Host.
- Admin-Sperre und Veto sind unveraenderlich: Fragment-, Relations- und Zweigblock wirksam in jedem Antwortweg (Definition, Ja/Nein, Kategorie, abgeleiteter Pfad); Reaktivierung nur durch den Administrator; Versuche durch das Dienstkonto (403), einen Nutzer (403) und
anonym (401) abgewiesen; Wiederanlage desselben Wissens unter neuer Kennung bringt es nicht zurueck; gesperrtes Wissen bleibt gespeichert und fachlich unveraendert; Veto gegen einen Lauf haelt ihn an, neue Evidenz hebt es nicht auf; Hash-Kette bleibt lueckenlos
(
nachweise/admin_beweis_fee644a.json,nachweise/veto_beweis_fee644a.json; frueher..._26bd02c.json).
16. Abschlusskriterien (Abschnitt 40)¶
{{TAB_KRITERIEN_NACHWEIS}}
17. D. Rest¶
{{REST}}
18. Urteil¶
{{URTEIL}}
19. Nach dem Bericht: Entscheidungen und Empfehlungen¶
Diese Punkte sind keine Restpunkte des Auftrags, sondern Entscheidungen, die bei dir liegen:
{{ENTSCHEIDUNGEN}}