# Lessons

- Vor dem Abschluss immer den aktuellen Workspace-Stand erneut verifizieren, wenn der Nutzer parallel selbst Änderungen gemacht haben könnte; Zwischenstände nicht als finalen Restzustand formulieren.
- Absichtliche Schutzmechanismen wie Kontakt-Obfuskation nicht entfernen, nur weil eine formell sauberere Lösung möglich erscheint; erst die Nutzerintention prüfen und den Tradeoff zwischen Rechtssicherheit und Spam-Schutz explizit machen.
- Bei englischer Website-Copy keine abstrakten Übergangsformulierungen wie "bringing together" oder zu konzeptionelle Bildsprache verwenden, wenn der Nutzer natürliche, muttersprachliche Formulierungen will; lieber direkte, idiomatische Sätze mit klaren Substantiven und Verben schreiben.
- Wenn der Nutzer für Website-Copy einen konservativen Ton verlangt, Superlative, Selbstinszenierung und stilisierte Attribute weiter reduzieren; kurze, sachliche Selbstbeschreibung bevorzugen.
- Bei englischer Selbstbeschreibung im konservativen Ton `self-taught` gegenüber formelleren Wörtern wie `autodidact` bevorzugen, wenn Natürlichkeit wichtiger ist als begriffliche Präzision.
- Bei Selbstbeschreibungen keine Hobbys als primäre Rollen labeln, wenn der Nutzer sie nur freizeitlich betreibt; Hobbys explizit als interests, hobbies oder spare-time activities formulieren.
- Bei kurzer Hero-Copy immer auch den visuellen Umbruch prüfen: zu viele hervorgehobene Wörter, zu enge `max-width` oder unruhige Parallelkonstruktionen verschlechtern den Lesefluss selbst dann, wenn die Grammatik korrekt ist.
- Bei schlecht formatierten Markdown-Tabellen zuerst die fehlenden `prose`-Styles im Renderer prüfen und dort beheben; Content nicht mit `<br>`-Workarounds verbiegen, wenn das eigentliche Problem fehlendes Tabellen-CSS ist.
- Bei Mastodon-Automation keine unnötigen API-Calls mit zusätzlichen Scopes (z. B. `verify_credentials`) erzwingen; den minimalen Scope-Pfad für den eigentlichen Task bevorzugen, um Token-Fehler zu vermeiden.
- Bei Social-Webmentions nicht nur Quell-URL-Erreichbarkeit prüfen: Interaktions-URLs mit Hash-Signaturen (`favorited-by`, `liked_by`) brauchen eine API-basierte Validierung der konkreten Like/Repost-Relation, sonst bleiben gelöschte Reaktionen sichtbar.
- Bei Umbenennung-Tasks (z. B. articles→blog) immer ALLE Vorkommen prüfen: Code, Pfade, Kommentare und Label-Strings in Scripts — nicht nur die offensichtlichen getCollection/URL-Stellen. Danach grep-Verifikation ausführen.
- CLAUDE.md-Konventionen einhalten: Plan in `tasks/todo.md` schreiben (nicht nur TodoWrite-Tool), nach Nutzerkorrekturen `tasks/lessons.md` aktualisieren, TodoWrite-Tool nur ergänzend nutzen.