Docs: lessons.md — Hung-Chat fortsetzen via reflog-Recovery
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
parent
664e34fc53
commit
4bded129ce
@ -1,5 +1,23 @@
|
||||
# Lessons
|
||||
|
||||
## 2026-05-30 — Abgestürzten/„aufgehängten" Chat fortsetzen: zuerst reflog lesen
|
||||
|
||||
**Muster:** User bat, einen anderen, aufgehängten Chat-Strang „zu Ende zu bringen".
|
||||
Der Working Tree sah harmlos aus (nur untracked), aber der eigentliche Fortschritt lag
|
||||
in einem per `reset --hard HEAD~1` weggesetzten Commit, der nur noch im **reflog**
|
||||
(dangling) lebte.
|
||||
|
||||
**Regel:** Bei „mach weiter wo es hing":
|
||||
1. `git reflog` + `git log --oneline -20` zuerst — Ground Truth, NICHT der
|
||||
(evtl. stale) gitStatus-Snapshot oder Konversations-interne Annahmen.
|
||||
2. Reset-weggesetzte/dangling Commits (`git fsck --lost-found`, reflog) inspizieren
|
||||
(`git show <sha>`) — dort steckt oft die unfertige Arbeit.
|
||||
3. **Verstehen WARUM weggesetzt**, bevor man blind cherry-picked: hier brach ein
|
||||
bestehender Test (`.toBe(signal)`-Identitätscheck), den der Fix zwingend ändert.
|
||||
Der Reset war die Reaktion darauf, nicht „Fix war falsch". Erst die Reset-Ursache
|
||||
beheben (Test auf Verhalten umstellen), dann den Fix recovern.
|
||||
4. Eigene Memory (`project_*`) lesen — sie dokumentierte Bug + intendierten Fix exakt.
|
||||
|
||||
## 2026-05-30 — Release verifizieren BEVOR "fertig" gesagt wird; curl -F mit Leerzeichen im Pfad
|
||||
|
||||
**Muster A (Edit ins Leere + trotzdem released):** Ein Edit schlug fehl ("String not
|
||||
|
||||
Loading…
Reference in New Issue
Block a user