From d923d6dabb3a02e38b18c83e3a335b4c44cac4ae Mon Sep 17 00:00:00 2001 From: Sucukdeluxe Date: Thu, 28 May 2026 22:25:16 +0200 Subject: [PATCH] =?UTF-8?q?Docs:=20tasks/lessons.md=20=E2=80=94=20Befund-g?= =?UTF-8?q?egen-Realitaet=20gaten=20+=20Crash-Debris=20stashen?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-Authored-By: Claude Opus 4.8 (1M context) --- tasks/lessons.md | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) create mode 100644 tasks/lessons.md diff --git a/tasks/lessons.md b/tasks/lessons.md new file mode 100644 index 0000000..672d98e --- /dev/null +++ b/tasks/lessons.md @@ -0,0 +1,31 @@ +# Lessons + +## 2026-05-28 — Analyse-Befund gegen beobachtete Realität gaten (Advisor-Korrektur) + +**Muster:** Meine Analyse sagte einen *häufigen* Bug voraus (jede letzte Datei im +Standard-Modus + jede Nested-Datei landet unbenannt), während der User nur "1-2 pro +Staffel" meldete. Ich habe die Diskrepanz bemerkt ("zu schwer um unbemerkt zu bleiben") +und sie mit weiterem Timing-Argument wegrationalisiert. + +**Regel:** Wenn die eigene Analyse etwas vorhersagt, das der beobachteten Realität +widerspricht, NICHT die bequeme Lesart wählen — **mit einem Reproduktions-Test gaten**, +bevor man fixt. Failing Test gegen den Ist-Stand zuerst (TDD/systematic-debugging Phase 4): +- reproduziert → Bug bestätigt, mit Sicherheit fixen. +- reproduziert nicht → Analyse hat eine Mitigation übersehen, kein Fix für Nicht-Bug. + +## 2026-05-28 — Crash-Debris im Working Tree: stashen, nicht verwerfen + +**Muster:** Eine abgestürzte Session (API 400) hinterließ ein uncommittetes Working Tree, +das drei releaste Commits revertierte. Verlockung: `git checkout`/discard, um clean HEAD +zu bekommen. + +**Regel:** Fremde/unverstandene uncommittete Änderungen **`git stash`** (non-destruktiv, +recoverable), nie blind verwerfen. Gibt clean HEAD, nichts geht verloren, kein Stall auf +User-Rückfrage. Danach dem User sagen WAS gestasht wurde und WARUM. + +## Wiring-Lock vs. Mechanism-Test + +Ein Test, der eine Hilfsfunktion mit dem richtigen Flag direkt aufruft, beweist nur, dass +das Flag funktioniert — NICHT, dass der Produktionspfad das Flag setzt. Für echte +Absicherung einen End-to-End-Test durch den realen Einstiegspunkt fahren und per +Negativ-Gate (Flag temporär entfernen → Test muss fallen) verifizieren.