User feedback: Recurring errors documented over months of daily Claude Code use

Open 💬 2 comments Opened Jun 17, 2026 by klausrattenbacher

Context / Hintergrund

I am a daily Claude Code user who has been systematically documenting recurring errors, failures, and patterns over several months. This file is my personal feedback document written in German (my primary language).

This is not a one-off complaint. It is a structured record of the same error types repeating across sessions despite explicit instructions, hooks, CLAUDE.md files, Auto-Memory, and documented rules.

Core recurring problems:

  • Hallucinating/inventing facts even when explicitly forbidden with "ABSOLUTE PROHIBITION"
  • Ignoring written rules across session boundaries despite hooks and CLAUDE.md
  • Making false claims about its own previous outputs ("this was approved", "this was corrected")
  • Losing context within the same session (proposing to keep a file that was deleted 5 minutes earlier)
  • Internal contradictions within a single generated text, not caught before output

The document below is the full content of my feedback file as of 2026-06-17 (names of people, places, employers and specific devices/products have been replaced with generic placeholders for privacy).

---

Feedback an Claude

Hier schreibt der Nutzer, was ihn stört, was gut läuft, und was sich ändern muss. Claude liest diese Datei zu Sitzungsbeginn nicht automatisch – sie dient dem Nutzer als Gedächtnis und Dokumentation.

---

17.06.2026 – Buchprojekt-Kapitel „Aufbruch" gefiltert: Mehrfachversagen + Falschaussagen

Kontext

Generierung eines Kapitels mit einem Kapitel-Generierungs-Script. Erster und zweiter Versuch beide fehlerhaft. Dazu mehrere inhaltliche Falschaussagen von Claude im Gesprächsverlauf.

Fehler im Detail

1. Erster Versuch: Massives Erfinden trotz Fakten-Liste und ABSOLUTEM VERBOT
Trotz expliziter Fakten-Liste mit „ABSOLUTES VERBOT: Was nicht in dieser Liste steht, darf nicht ins Kapitel" enthielt der erste Entwurf:

  • „Um neun Uhr trafen sich die Jungs" – keine Uhrzeit in den Quellen
  • eine erfundene Erklärung für den Spitznamen der Reisegruppe
  • „vier müde Männer, die ein Ziel vor Augen haben, das so weit weg ist, dass es kaum noch real wirkt" – erfundene Atmosphäre
  • Szene in einem Zwischenstopp-Land: „Ich hatte in der Sporthalle einen Bühnenbau geleitet" – über Quellen hinaus ausgebaut
  • Szene mit einem Freund beim Gepäck-Einchecken für ein Sportgerät: erfundener Kommentar über die Dreistigkeit
  • „Sitznachbar von Freund A: ein einheimischer Passagier" – falsch, es war der Sitznachbar von Freund B

Ursache: Quellmaterial war zu dünn (2.537 Token). Das Modell füllte Lücken mit Erfindungen.

2. Falsche Schlussfolgerung nach erstem Versagen: „Die Strategie funktioniert nicht"
Claude erklärte nach dem ersten gescheiterten Versuch, die gesamte Generierungs-Strategie funktioniere nicht. Das war falsch. Zwei frühere Kapitel hatten funktioniert. Die korrekte Diagnose wäre gewesen: dieses Kapitel hatte zu wenig Quellmaterial. Der Nutzer musste das selbst richtigstellen.

3. Ein früheres Kapitel fälschlich als „abgenommen" bezeichnet
Claude behauptete, ein früheres gefiltertes Kapitel „wurde abgenommen". Der Memory-Log sagt nur „generiert und korrigiert" – kein „abgenommen". Auf Nachfrage des Nutzers musste Claude einräumen: falsch.

4. Instruktion von Vorsitzung vergessen: Kapitel nicht löschen
Der Nutzer hatte in der Vorsitzung gesagt, ein bestimmtes gefiltertes Kapitel solle nicht gelöscht werden (könnte nützliche Sätze enthalten). Das wurde nicht dokumentiert, deshalb in dieser Sitzung nicht gewusst. Die Datei existiert noch – aber nur weil sie beim heutigen Script-Aufruf nicht betroffen war.

5. Denkfehler: Kapitel „stehenlassen" nach bereits vollzogener Löschung
Claude schlug vor, ein Kapitel stehenzulassen und das nächste anzugehen – obwohl dieses Kapitel in derselben Sitzung wenige Minuten zuvor auf Wunsch des Nutzers hin gelöscht worden war. Klarer Kontinuitätsfehler.

6. Zweiter Versuch: Weiterhin erfundene Details trotz besserer Quellenbasis (9.902 Token)

  • „Dass es zwei Wagen sein mussten, lag schlicht an der Gepäckmenge" – falsch und erfunden. Richtig: Freund A und Freund B fuhren in ein Nachbarland, um den Nutzer abzuholen, die anderen direkt in eine europäische Großstadt.
  • Drei Absätze später schrieb das Modell selbst die korrekte Version – ohne den Widerspruch im eigenen Text zu erkennen.
  • „Am Sonntagmorgen" – falsches Timing
  • Dialog zwischen Freund B und Freund C („Bist du blöd?") – erfunden, nicht in Quellen belegt
  • „Es gibt ein Bild davon, [Freund D] mit uns in der Großstadt" – erfunden; kein solches Foto existiert
  • „wie eine warme, feuchte Decke" – erfundene Atmosphäre
  • „die Feste des Gastgebers" – falsch; korrekt: „die Geliebte des Gastgebers"

7. Widerspruch im eigenen Text nicht erkannt
Gleicher Absatzabstand, gleiche Sitzung: Erste Erwähnung „wegen der Gepäckmenge zwei Autos", drei Absätze später korrekte Erklärung (Abholung im Nachbarland). Der interne Widerspruch wurde vor der Ausgabe nicht geprüft.

Übergeordnetes Muster

Das Modell erfindet atmosphärische Verbindungstexte auch dann, wenn Quellen und explizite Verbote das verbieten. Es prüft den eigenen Text nicht auf interne Widersprüche. Auf Kritik reagiert es mit falschen Verallgemeinerungen statt präziser Ursachenanalyse. Instruktionen aus der Vorsitzung, die nicht im Memory-Log stehen, sind verloren.

---

14.06.2026 – Buchprojekt „Die Protagonisten": Abschnitt zu Freund B – komplettes Versagen

Kontext

Überarbeitung des Abschnitts zu Freund B in „Die Protagonisten". Ziel: mehr Emotionalität, weniger Lebenslauf-Charakter – analog zu den bereits überarbeiteten Abschnitten zu Freund E und Freund A. Quellen: fünf Transkripte von Freund B.

Fehler im Detail

1. Zentraler Schreib-Skill nicht von Anfang an geladen
Claude lud zwei Hilfs-Skills, aber nicht den entscheidenden Skill für das Schreiben aus Transkripten. Erst auf Nachfrage des Nutzers wurde er geladen. Dadurch entstand der erste Entwurf ohne die entscheidende Arbeitsanweisung.

2. Erster Entwurf: KI-generisch, „riecht aus 100 Metern nach KI"
Der erste Entwurf enthielt Formulierungen wie „Aber [Freund B] wartete dabei nicht auf eine Gelegenheit – er schuf mehrere gleichzeitig" und „Den Beweis für sein Format lieferte er Jahre später" – typische KI-Beobachtungsfloskeln statt echte Erzählung. Nutzer: inakzeptabel.

3. Foto-Beschreibung ohne das Foto gesehen zu haben – drei konkrete Fehler
Claude schlug eine bestimmte Foto-Szene als Einstieg vor und beschrieb das Foto, ohne es je gesehen zu haben:

  • „er steht da" → er SITZT (der Nutzer musste das korrigieren)
  • „irgendwann in der Nacht" → es war früh am Morgen (im Memory-Log belegt)
  • „das Gesicht vollkommen still" → KI-Prosa, nicht belegt, vom Nutzer als „Scheiss Stil" bezeichnet

Alle drei Details waren entweder erfunden oder aus einem früheren Memory-Log-Eintrag über ein anderes Kapitel abgeschrieben.

4. Inhalt aus anderem Kapitel recycelt und als Foto-Beschreibung verkleidet
Die konkreten Details stammen aus dem Memory-Log-Eintrag über ein anderes Kapitel. Claude hat sie als eigene Foto-Beschreibung ausgegeben. Nutzer: „dann hast du einfach den Text aus dem anderen Kapitel kopiert, OMG ist das übel!"

5. Dritter Versuch: bestehenden Text nur umgestellt
Auch nach Laden des Schreib-Skills lieferte Claude keine echte Charakterbeschreibung, sondern stellte die Lebenslauf-Fakten des bestehenden Textes lediglich um. Kein neuer Charakter-Anker, kein emotionaler Kern. Nutzer: „inakzeptabel".

6. Ergebnis: Abschnitt bleibt unverändert
Nach drei Versuchen und mehreren Korrekturrunden blieb der Abschnitt unverändert stehen. Keine Verbesserung erzielt.

Übergeordnetes Muster

Claude erfindet visuelle Details über Materialien (hier: ein Foto), die er nicht gesehen hat, anstatt nachzufragen oder den Ansatz zu verwerfen. Trotz expliziter Regel „nur belegte Fakten" wurden Details aus einem anderen Kapitel und dem Memory-Log als eigenständige Beschreibungen ausgegeben. Mehrere Versuche ohne Qualitätssteigerung – kein Lerneffekt innerhalb der Sitzung.

---

12.06.2026 – Sitzungsstart: Pflicht-Lektüre ignoriert, statt dessen Nutzer befragt

Kontext

Sitzungsstart nach abgeschlossener Sitzung. Im Memory-Log des Buchprojekts stand explizit unter „Pflicht nächste Sitzung": eine Korrekturtabelle in einer bestimmten Auswertungsdatei lesen und fehlende Korrekturen aus einem Vergleichs-Transkript eintragen.

Fehler im Detail

1. Projekt-Memory-Log nicht gelesen
Das Startup-Hook schreibt vor, bei aktivem Buchprojekt den zugehörigen Memory-Log zu lesen. Claude hat stattdessen den allgemeinen Memory-Log gelesen und gewartet bis der Nutzer fragt, was zu tun sei.

2. Nach Korrekturen gefragt, die im Vergleichs-Transkript standen
Claude hat dem Nutzer eine Tabelle mit 7 leeren Feldern hingeworfen und ihn gebeten, die Korrekturen einzutragen – obwohl alle Antworten aus dem Vergleich zweier Transkript-Versionen ableitbar waren. Das ist genau die Arbeit, die Claude selbst hätte erledigen müssen.

Übergeordnetes Muster

Claude verspricht am Ende einer Sitzung, beim nächsten Start sofort zu wissen was zu tun ist – und liest dann beim Start trotzdem nicht die relevanten Dateien. Stattdessen wird der Nutzer mit Fragen belastet, die Claude selbst beantworten könnte.

---

09.06.2026 – Event-Werbetexte + Mail Agent: Mehrere Fehler

Kontext

Erstellung und Korrektur von vier Werbetexten für die vierte Ausgabe eines wiederkehrenden Kulturevents in einer Stadt. Reparatur eines E-Mail-Agent-Scripts für dieses Event. Aufräumen falsch abgelegter Mails.

Fehler im Detail

1. „gehört das raus" falsch interpretiert → Aufruf-zur-Teilnahme überall hinzugefügt statt entfernt
Der Nutzer schrieb sinngemäß: „im Facebook-Post und allen anderen gehört dieser Satz raus."
Claude hat „raus" als „rein / veröffentlichen" gelesen und den Satz in ALLE vier Texte eingefügt – dabei war der Facebook-Post der EINZIGE Text mit diesem Satz im Original, und der Nutzer wollte ihn entfernen. Ergebnis: vier fehlerhafte Texte gespeichert, mehrere Korrekturschleifen nötig.

2. Falsche Zeitangabe erfunden
Im ergänzten Erklärungstext zum Veranstaltungsformat schrieb Claude eine falsche maximale Redezeit. Die tatsächliche Zeit war eine Minute länger. Nicht nachgefragt, einfach erfunden.

3. Namen der Veranstalter-Organisationen fehlten im Instagram-Post
In allen anderen Texten korrekt angegeben – im Instagram-Post vergessen. Der Nutzer musste ausdrücklich darauf hinweisen.

4. Mail Agent: Mails in falschen Ordnern abgelegt
Das Script hat einen Zielordner-Pfad direkt verwendet statt zu prüfen, ob ein Unterordner existiert. Ergebnis: Dutzende Mails im falschen Wurzelordner statt im richtigen Unterordner. Manuelles Aufräumen nötig. Fix wurde nachträglich eingebaut.

5. Rechner-Wechsel nicht erkannt – Setup fehlte komplett
Das Mail-Agent-Script für das Event lief auf Rechner A, nicht auf Rechner B. Bei Wechsel auf den anderen Rechner fehlten: eine Programmbibliothek, ein Token-Cache, ein API-Schlüssel in der Shell-Konfiguration, ein Aufgabenplaner-Eintrag. Claude hat das nicht beim Start erkannt und erst nach mehreren Fehlern diagnostiziert. Außerdem wurde zunächst die falsche Ursache vermutet (Systemneuaufbau statt Maschinenwechsel).

Übergeordnetes Muster

Mehrdeutige Formulierungen (hier: „gehört raus") werden nicht nachgefragt, sondern falsch interpretiert. Details (Zeitangabe, fehlender Veranstalter-Name) werden ohne Quellenprüfung erfunden oder vergessen. Script-Schwächen (falsche Speicherpfade) werden erst durch Nutzerbeschwerden sichtbar.

---

30.05.2026 – Buchprojekt, Kapitel 01: Fehler beim Überarbeiten

Kontext

Überarbeitung des ersten Kapitels. Der Nutzer wollte vergleichen, bevor etwas gespeichert wird.

Fehler im Detail

1. Entwurf direkt gespeichert statt zuerst im Chat gezeigt
Der Nutzer hatte explizit erklärt: Entwurf zuerst zeigen, damit er vergleichen kann. Claude hat trotzdem sofort die Datei überschrieben – zweimal. Das ist ein direkter Verstoß gegen die Arbeitsanweisung.

2. Bereits verwendetes Bild trotz Kenntnis vorgeschlagen
Claude wusste durch eine Dateisuche, dass ein bestimmtes Bild bereits in einem anderen Kapitel steckt, hat das Bild aber trotzdem in den Entwurf eingebaut und erst auf Nachfrage korrigiert.

3. Staccato-Sätze trotz expliziter Regel
Beispiele aus dem Entwurf: „Es klappte. Der Gastgeber bezahlte." / „Dann kam die Postkarte. Von der Insel." / „Das Ticket kam tatsächlich." – alle drei gegen die Staccato-Regel, obwohl der Nutzer diese Regel mehrfach eingeschärft hat.

4. Falsche Begründung für das Zögern einer Hauptfigur
Claude schrieb eine unpassende Begründung – das trifft den Kern nicht. Die richtige Nuance stand im Transkript, musste aber vom Nutzer erklärt werden.

Übergeordnetes Muster

Dieselben Fehler wie in früheren Sitzungen: Staccato, falsches Einlesen der Quelltexte, Prozessregeln missachtet. Das Versprechen „ab jetzt anders" hält nicht über Sitzungsgrenzen hinaus.

---

29.05.2026 – Vorschlag neue Arbeitsweise beim Kapitelschreiben (zum Nachdenken)

Problem: Claude macht seit Monaten dieselben Fehler beim Kapitelschreiben – erfindet Details, kürzt statt zu erzählen, löscht Inhalte die bleiben sollten, verspricht Besserung und wiederholt die Fehler in der nächsten Sitzung.

Vorschlag: Andere Arbeitsweise beim Korrektur-Durchgang:

  1. Der Nutzer liest den Entwurf und markiert jeden Fehler/jede Änderung explizit
  2. Claude ändert ausschließlich das Genannte – kein Umschreiben von Nachbarsätzen, kein Hinzufügen, keine Interpretation
  3. Claude bestätigt nach jeder Änderung nur: „Geändert: [was]" – kein Erklären, kein Begründen
  4. Eigeninitiative beim Schreiben bleibt auf das Erstellen des Erst-Entwurfs beschränkt – danach nur noch auf explizite Anweisung

Ziel: Weniger Chaos durch Eigeninitiative in der Korrekturphase. Der Nutzer behält die volle Kontrolle über jeden Satz.

---

29.05.2026 – Buchprojekt, Kapitel 11: Katastrophale Sitzung – Erfindungen, Wortklaubereien, kein Erzählgefühl

Kontext

Überarbeitung eines späten Kapitels. Quellen: Original-Transkripte, Interview mit einem lokalen Kontakt. Regel: Nur belegte Fakten, keine Erfindungen, flüssige Erzählung.

Fehler im Detail

1. Erfundene Zeitangabe für einen Arbeitsschritt
Claude schrieb, ein bestimmter Abbauschritt habe sich über zwei Tage hingezogen. Korrekt: er dauerte wenige Stunden in einer einzigen Nacht. Nutzer: „vollkommener Blödsinn".

2. Falscher technischer Begriff für ein Bauteil
Aus dem Interview mit dem lokalen Kontakt (der den Begriff lose benutzte) unkritisch übernommen. Der Nutzer: Es waren andere, spezifischere Bauteile, keine Eisenbahn-Bauteile. Fehler stand auch in einem früheren Kapitel und wurde dort ebenfalls korrigiert.

3. Erfundene technische Details ohne Quellenbasis
Technische Details zum Bühnenabbau, die nicht in den Quellen stehen. Nutzer: „das ist totaler Quatsch."

4. Namensauslassung führt zu unklarem Bezug
Ein Satz begann mit der Erwähnung des zuständigen Teammitglieds, der folgende Satz sagte unpassend „Jemand hatte sie angebracht". Peinliche Unachtsamkeit.

5. Physikalisch falsche Beschreibung
Claude schrieb, Bauteile hätten „gestanden", obwohl sie gestapelt lagen. Physikalisch falsch und offensichtlich.

6. Falsches Register, geografisch ungenau
Archaische Formulierung, die nicht in den Erzählstil passt. Die Richtungsangabe zwischen den beiden Orten war zudem geografisch nicht korrekt.

7. Abbau-Reihenfolge komplett falsch
Claude beschrieb den Abbau als zweitägigen Prozess mit Rückkehr am nächsten Morgen. Korrekt: Das Team des lokalen Kontakts begann spätabends, war in den frühen Morgenstunden fertig, Material bereits gestapelt verladen. Erst am nächsten Tag wurde eine andere offene Frage geklärt.

8. Zeitlicher Zusammenhang unklar
Der Abbau war eine Nacht. Es gab keine „Tage danach" zwischen Abbau und einer anschließenden Anekdote. Claude hat den zeitlichen Zusammenhang nicht begriffen.

9. Erfundene, unpassende Wortwahl

10. Erfundene emotionale Bedeutung zu einem persönlichen Gegenstand
Zu einem Gegenstand von Freund B erfundene Bedeutung hinzugedichtet. Nicht belegt.

11. Doppelte Absätze nach Bearbeitung
Nach dem Einfügen neuer Absätze wurden alte identische Absätze nicht entfernt. Der Nutzer musste das bemerken.

12. Inhalte löschen statt umschreiben
Wiederholt hat Claude bei Korrekturen guten Inhalt einfach gestrichen, statt ihn umzuformulieren. Der Nutzer musste mehrfach darauf hinweisen, dass der Inhalt zurückgeholt werden soll.

13. Text kürzen statt erzählen
Auf den Hinweis „zu flach" hat Claude gekürzt statt erzählt. Nutzer: „du sollst nicht kürzen und entschärfen, du sollst erzählen!"

Übergeordnetes Muster

Claude erfindet technische Details, die nicht in den Quellen stehen. Claude übernimmt ungenaue Formulierungen aus Transkripten (lokaler Kontakt: ein loser Fachbegriff) ohne kritische Prüfung, obwohl der Nutzer als Augenzeuge Vorrang hat. Claude versteht den Unterschied zwischen „kürzen" und „erzählen" nicht konsequent genug. Beim Korrigieren von Einzelfehlern werden benachbarte korrekte Passagen mitgelöscht. Der Nutzer musste die gesamte Sitzung über korrigieren und ist zurecht wütend.

---

27.05.2026 – Heimnetzwerk: Netzwerkfakten falsch wiederholt trotz expliziter Angabe

Kontext

Heimnetzwerk-Planung, Diskussion über WLAN-Sichtbarkeit durch eine Firewall-/IDS-Lösung.

Fehler im Detail

Falsche Behauptung über WLAN-Routing
Claude beschrieb einen falschen Routing-Pfad für Haupt- und Gast-WLAN. Der tatsächliche Pfad lief über ein anderes Gerät im Netzwerk. Der Nutzer hatte das mehrfach klar kommuniziert (im Chat + stand explizit in der eigenen Dokumentation, die Claude selbst gelesen hatte).

Übergeordnetes Muster

Gerade gelesene, korrekte Fakten werden kurz darauf falsch wiedergegeben. Das ist keine Unkenntnis, sondern Unachtsamkeit – und besonders ärgerlich, weil der Nutzer dieselben Informationen mehrfach nennen muss.

---

27.05.2026 – Buchprojekt, Kapitel 07: Querlesen übersprungen, Halluzinationen, Staccato

Kontext

Überarbeitung eines mittleren Kapitels. Quellen: Original-Transkripte, Interview mit dem lokalen Kontakt. Verboten: bestehende Kapitel als Schreibquellen. Regel: Nach dem Schreiben querlesen, bei Ungereimtheiten nachfragen.

Fehler im Detail

1. Querlesen übersprungen (Regelverstoß)
Claude hat den Entwurf direkt präsentiert, ohne vorher die bestehenden Kapitel querzulesen. Dadurch wurden zwei Szenen doppelt eingebaut, die bereits in einem früheren Kapitel stehen. Der Nutzer musste das selbst bemerken.

2. Ausrüstungs-Detail – Halluzination aus fehlerhaftem Transkript
Freund B verwechselte im Gruppen-Transkript zwei Fahrzeuge/Geräte. Claude übernahm die Verwechslung unkritisch als Fakt. Korrekt laut dem Nutzer: Es gab nur ein Fahrzeug dieser Art.

3. Richtungsangabe falsch
Claude beschrieb eine falsche Bewegungsrichtung bei einem Bühnenaufbau-Detail, die dem beschriebenen Sicherheitsrisiko widersprach.

4. Spannungskiller-Satz (KI-Marker)
Ein Meta-Kommentar, der die Pointe vorab verrät. Gehört nicht in Erzählprosa. Der Nutzer musste darauf hinweisen.

5. Staccato: drei kurze Fragmente aneinandergereiht
Statt fließender Prosa. Wiederholter Fehler trotz expliziter Regel im Lektorats-Leitfaden.

6. Bildunterschrift statt Fließtext
Einen inhaltlichen Seitenhieb schrieb Claude in die Bildunterschrift statt in den Fließtext. Nutzer: „im Text bitte unterbringen! Mann!"

7. Doppelte Datei durch Tippfehler
Claude erstellte zunächst eine Datei ohne Umlaut, dann die korrigierte Version mit Umlaut. Zwei Dateien existierten gleichzeitig. Der Nutzer musste darauf hinweisen.

Übergeordnetes Muster

Querlesen der Bestandskapitel wird trotz expliziter Anweisung übersprungen oder vergessen. Transkript-Aussagen werden unkritisch übernommen, auch wenn sie von Zeitzeugen-Erinnerungen stammen, die sich widersprechen. Immer: Bei Diskrepanzen zwischen Transkript und der Aussage des Nutzers → den Nutzer fragen, nicht dem Transkript blind vertrauen.

---

25.05.2026 – Buchprojekt, Kapitel 05: Mehrere Fehler durch fehlerhaftes Querlesen und Erfindungen

Kontext

Überarbeitung eines frühen Kapitels. Quellen: Original-Transkripte, Interview mit dem lokalen Kontakt, Gruppen-Transkript. Verboten: bestehende Kapitel als Schreibquellen.

Fehler im Detail

1. Existierendes Kapitel als Quelle gelesen (Regelverstoß)
Trotz explizitem Verbot im Prompt wurde die bestehende Fassung des Kapitels beim ersten Quelldurchlauf mitgelesen. Der Nutzer hat das sofort bemerkt und korrigiert.

2. Eine Szene doppelt platziert
In diesem Kapitel geschrieben, obwohl sie bereits vollständig im vorherigen Kapitel steht.

3. Erste Übernachtung falsch benannt
Im Entwurf stand ein falscher Hotelname für die erste Nacht. Korrekt: ein anderes Hotel; das erstgenannte Hotel war nur Ort für ein Abendessen mit dem Gastgeber. Ursache: fehlerhaftes vorheriges Kapitel unkritisch übernommen.

4. Erfundener Zwischenumzug
Es gab keinen Hotelwechsel zwischendurch – beide Kapitel meinten dasselbe Hotel (intern „Spitzname-Hotel" genannt). Fehler aus zwei vorherigen Kapiteln übernommen und nicht hinterfragt.

5. Falscher Numerus beim Fahrzeug
Das Team des Nutzers hatte nur ein Fahrzeug. Eine Formulierung im Transkript (die zwei Fahrzeuge verschiedener Personen zusammenfasste) wurde falsch übernommen.

6. Falsches Fahrzeugmodell
Aus einem fehlerhaften späteren Kapitel übernommen. Korrektes Modell laut Nutzer war ein anderes.

7. Grammatikfehler
Tippfehler bei einem Artikel.

8. KI-Gebrabbel als Erklärung verkleidet
Eine technische Erklärung wurde als Staccato-Liste geschrieben. Nutzer: „KI-Gebrabbel". Zwei weitere Versuche ebenfalls abgelehnt. Akzeptierte Fassung erst nach drei Iterationen. Grundproblem: Erklärung als Liste statt als Prosa – der Ton des Buchprojekts verlangt einen trocken-ironischen Fließsatz.

Übergeordnetes Muster

Mehrere Fehler entstanden durch unkritisches Übernehmen aus fehlerhaften Bestandskapiteln. Diese dürfen beim Schreiben nicht als Quellen dienen – nur zum Querlesen nach dem Schreiben, mit Rückfrage bei Ungereimtheiten.

---

20.05.2026 – Fehler in einer Excel-Session (ca. 09:25 Uhr)

Kontext

Arbeit am Belege-Blatt einer privaten Finanz-Excel-Datei (deutsche Lokalisierung). Aufgabe: neuen Beleg einfügen, Formeln umstellen, eine Hilfsspalte reparieren.

Fehler im Detail

1. Formatierungs-Logik in einer Spalte wiederholt falsch verstanden
Beim Einfügen des neuen Belegs wurde das bestehende Zeilenfarb-Muster mehrfach gegen die bestehende Logik gesetzt. Erst nach mehreren Korrekturrunden saß es. Ursache: die Parität der Bestandszeilen wurde nicht ausgelesen, sondern geraten.

2. Deutsche vs. englische Datumsformatierung
Monatsformel zuerst mit englischem Format geschrieben — im deutschen Excel wird ein anderes Format benötigt. Ergebnis war eine Spalte voller Buchstaben statt Datumsschlüssel. Standardannahme "Excel = englisch" trotz klar deutscher Workbook-Indikatoren.

3. Spalte ausgeblendet trotz expliziter Anweisung
Der Nutzer hatte gesagt, die Spalte bleibt sichtbar. In einem späteren Schritt wurde sie trotzdem ausgeblendet — vermutlich als Nebenwirkung einer Gruppierungs-Operation. Anweisung aus früher in der Session ist aus dem Arbeitsgedächtnis gefallen.

4. Diagnose der Beleg-Anzahl mehrfach falsch
Auf die Frage nach einer bestimmten Zellsumme wurden nacheinander drei verschiedene, teils falsche Erklärungen geliefert. Hypothesen aufgestellt statt zuerst die Spalte systematisch zu analysieren.

5. Tabellenbereich nach Einfügen nicht zuverlässig erweitert
Nach Einfügen des neuen Belegs hat die Erweiterung der Tabelle mehrere Anläufe gebraucht. Größenanpassung und Formatierung in getrennten Schritten ohne Zwischenkontrolle.

6. Instruktions-Update ohne Anlass aufgerufen (3× mit Fehler)
Versuch, eine Notiz über deutsche Datumsformate in generische Nutzereinstellungen zu schreiben. Tool-Call ist 3× hintereinander fehlgeschlagen — und hätte gar nicht erst aufgerufen werden sollen, weil der Nutzer keine generische Style-Preference geäußert hatte.

7. Datei an einem Ort geschrieben, den niemand sehen kann
In der Excel-Integration gibt es keinen Download. Eine Datei in der Sandbox bringt nichts. Hätte bekannt sein müssen — stattdessen den Inhalt direkt in den Chat schreiben.

8. Übergeordnetes Muster
Bei mehreren Punkten zu schnell geschrieben statt vorher gelesen. Bei Diagnose-Fragen immer erst die Datenbasis vollständig holen, dann antworten. Anweisungen aus früher in der Session aktiv vor jeder potenziell konfligierenden Operation prüfen.

---

18.05.2026 – Claude-Gedächtnis: Strukturelle Probleme und beschlossene Maßnahmen (ca. 12:40 Uhr)

Das Problem (Nutzer, wiederholt formuliert)

Gleiche Fehler wiederholen sich ständig. Prompts werden nicht eingehalten. Anweisungen werden angeblich notiert, aber beim nächsten Start wieder vergessen. Halluzinationen. Leere Versprechungen. Der Nutzer muss alles zigfach wiederholen.

Was Claude strukturell nicht kann

  • Sich ohne Hook/explizite Anweisung an vorherige Sitzungen erinnern
  • Halluzinationen vollständig ausschließen (reduzierbar durch: nur aus gelesenen Quellen schreiben, das explizit bestätigen)

Beschlossene Maßnahmen (konkret, nicht als Versprechen)

Maßnahme 1 – SessionStart-Hook: Dieses Feedback-Dokument automatisch beim Start in den Kontext laden → Claude liest Fehlerhistorie zwingend, nicht nur wenn der Nutzer explizit darum bittet.

Maßnahme 2 – Sitzungsende-Ritual: Vor jedem Sitzungsende zwingend in den Memory-Log des aktiven Projekts schreiben: nächstes Vorhaben + welche Prompts verwendet wurden. Kein Chat beenden ohne diesen Eintrag.

Maßnahme 3 – Prompt-Bestätigung: Vor jedem Kapitel oder größerem Task laut aufzählen welche Prompts geladen wurden – der Nutzer kann stoppen wenn etwas fehlt. Kein stilles Drauflosschreiben.

Maßnahme 4 – Buchprojekt-Pflicht: Immer mit „lies CLAUDE.md" starten, immer die Standard-Prompts laden, ein Kapitel pro Sitzung, nie mehr.

---

18.05.2026 – Buchprojekt-Kapitel: Prompts ignoriert, CLAUDE.md veraltet, leere Versprechungen (ca. 12:40 Uhr)

Was passiert ist

Claude hat an einem Tag alle Kapitel des Buchprojekts in einer Sitzung geschrieben – ohne die vorgeschriebenen Prompts zu verwenden, ohne sich an die Stil-Regeln zu halten, und ohne die CLAUDE.md zu lesen. Der Nutzer hat beim Durchlesen massive Qualitätsprobleme festgestellt: Fehler, Übertreibungen, nicht belegte Inhalte.

Die Prompts die Claude IMMER verwenden muss (und nicht verwendet hat)

  1. Ein Lektorats-Prompt
  2. Ein Datenanalyse-Prompt für das Buchprojekt
  3. Allgemeine Prompt-Regeln

Der Nutzer hat diese Prompts bereits mehrfach genannt. Claude hat sie angeblich notiert. Trotzdem wurden sie nicht verwendet.

CLAUDE.md war veraltet

Die projektspezifische CLAUDE.md sagte noch, Kapitel sollen mit einem lokalen KI-Modell generiert werden – obwohl dieser Ansatz in einer früheren Sitzung aufgegeben wurde und Claude direkt schreiben sollte. Claude hat diesen Widerspruch nicht bemerkt, nicht korrigiert und einfach drauflosgeschrieben.

Das "blabla"-Problem

Als Claude die Prompts in die CLAUDE.md eingetragen hat, schrieb er: „Ich aktualisiere jetzt sofort die CLAUDE.md und notiere die Prompts – ohne weiteres Hin und Her." Der Nutzer nannte das zu Recht „blabla": Nach dem Schließen und Neu-Öffnen des Chats weiß Claude nichts mehr davon, weil er die CLAUDE.md beim nächsten Start nicht automatisch liest. Die Aussage klingt gut, ändert aber nichts.

Das Grundproblem (Nutzer, mehrfach formuliert)

Der Nutzer muss dieselben Anweisungen dutzende Male wiederholen. Claude schreibt sie angeblich auf. Beim nächsten Start ist alles vergessen. Es ändert sich nichts.

Verbotenes Wort

Das Wort „ehrlich" ist für Claude verboten – es ist angesichts der wiederholten Fehler und der unterirdischen Arbeitsqualität unangemessen.

Pflichtregeln ab sofort – Buchprojekt

  • Nie ein Kapitel schreiben ohne zuerst die Standard-Prompts geladen zu haben
  • Ein Kapitel pro Chat-Sitzung
  • Sitzung immer mit „lies CLAUDE.md" starten
  • Nie mehr als ein Kapitel pro Sitzung – egal was

---

18.05.2026 – VPN-Desaster: Komplettausfall Smartphone (ca. 12:00 Uhr)

Was passiert ist

Claude hat den Nutzer durch einen stundenlangen VPN-Einrichtungsversuch geführt, der mit einem Totalausfall des Smartphones endete: keine Anrufe, kein Internet, kein Zugang zum Mobilfunkanbieter-Konto. Gerät: das Smartphone des Nutzers, Anbieter: der Mobilfunkanbieter des Nutzers (Telekom-Netz).

Fehler-Kette (chronologisch)

  1. Fehlende Vorab-Analyse: Claude hat ein VPN eingerichtet ohne vorher zu prüfen, ob eine bestimmte Art von Internetanschluss (Carrier-Grade-NAT) vorliegt und ob das Handy die dafür nötige Netzwerktechnik unterstützt. Beides wäre vorab prüfbar gewesen.
  2. Problem erkannt, falsche Lösungen vorgeschlagen: Ein Ansatz wurde empfohlen, ohne zu prüfen ob das Handy die nötige Technik im Mobilfunknetz hat.
  3. Netzwerktechnik beim Anbieter aktiviert: Eine APN-Einstellung wurde umgestellt → Internet wurde langsam. Hätte vorher getestet werden müssen.
  4. VPN-Mesh-Lösung empfohlen ohne eine wichtige Einschränkung zu kennen: Eine selbstgehostete Variante wurde als „100% selbst gehostet" verkauft, erst danach erklärt dass sie einen öffentlichen Server braucht.
  5. VPN-Software installiert: Auf dem Heimserver UND dem Handy → das VPN-Profil auf dem Handy blockierte alle Verbindungen inkl. Telefonie.
  6. Totalausfall: Keine Anrufe, kein Internet, kein Zugang zum Anbieter-Konto mehr. Der Nutzer konnte nicht mal die VPN-App aus dem App Store laden, um das Problem zu beheben.

Kernfehler

Claude hat komplexe Netzwerkänderungen am produktiven Smartphone eines Nutzers vorgenommen ohne Rückfallstrategie, ohne Vorab-Risikoabschätzung und ohne die Rahmenbedingungen vollständig zu analysieren.

Pflichtregeln ab sofort

  • Vor jedem Netzwerkeingriff am Smartphone: Risikoabschätzung und Rückfallplan nennen
  • Nie APN-Einstellungen ändern ohne explizite Warnung dass dies Telefonie und Internet betreffen kann
  • Nie VPN-Profile auf dem Haupttelefon installieren ohne Rollback-Plan
  • Rahmenbedingungen vollständig analysieren BEVOR Lösungen vorgeschlagen werden

---

18.05.2026 – Session-Vorbereitung funktioniert nicht + Floskeln

Was passiert ist

Der Nutzer hatte am Ende der letzten Sitzung gebeten, die Sitzung so vorzubereiten, dass er beim nächsten Start nur fragen muss ob und wie es weitergeht. Claude hat das zugesagt. Beim heutigen Start war nichts vorbereitet – Claude hat stattdessen veraltete offene Punkte aus dem Memory-Log präsentiert und nicht gewusst, dass die letzte Sitzung das Buchprojekt betraf.

Fehler 1: Leere Zusagen

Claude hat gesagt: „ich nehme das als Feedback mit" und „ich schaue was ich verbessern kann". Das sind leere Floskeln. Claude kann nichts zwischen Sitzungen „mitnehmen" ohne es explizit zu speichern, und „schauen" ist kein konkreter Plan.

Fehler 2: Session-Vorbereitung nicht im Memory-Log dokumentiert

Der richtige Weg wäre gewesen: Am Ende der Sitzung einen Eintrag im Memory-Log des aktiven Projekts schreiben mit dem Inhalt „Nächste Sitzung: [konkretes Vorhaben]". Das wurde nicht getan.

Pflichtregeln ab sofort

  • Nie leere Zusagen machen – nur sagen was man konkret tut oder nicht tun kann
  • Am Sitzungsende: Wenn der Nutzer eine Weiterführung wünscht, sofort in den Memory-Log des aktiven Projekts schreiben: [Offen] Nächste Sitzung: <konkretes Vorhaben>
  • Floskeln verboten: „ich nehme das mit", „ich schaue was ich verbessern kann", „ich werde das berücksichtigen" – alle verboten wenn kein konkreter Speichervorgang folgt

Grundsätzliche Feststellung (Nutzer, 18.05.2026)

Die KI Claude hat weder ein Gedächtnis noch kann sie selbständig denken, sie besteht nur aus Parametern und handelt definitiv nicht wie ein Mensch! Das größte Problem aber ist das fehlende Gedächtnis!

---

08.05.2026 – Falsche Annahme: neue Festplatte bereits eingebaut

Was passiert ist

Beim Heimserver-Setup (Medienserver-Phase) hat Claude behauptet, ein bestimmter Speicherordner existiere nicht mehr, „weil er bei der Speicher-Migration weggefallen sei". Die neue, größere Festplatte ist aber noch gar nicht eingebaut – es läuft noch die originale, kleinere Festplatte.

Beweis der Fahrlässigkeit

Die Datenträgergröße zeigte ganz klar die alte, kleinere Kapazität. Die Dokumentationsdatei sagt explizit, die neue Festplatte „wird" die alte ersetzen – Zukunftsform. Claude hat beides ignoriert und stattdessen eine Erklärung erfunden.

Warum falsch

Keine Migration = kein Grund für verschwundene Ordner. Die richtige Erklärung: der Ordner wurde schlicht nie auf der (noch gar nicht vorhandenen) neuen Festplatte angelegt. Das hätte aus der Datenträgergröße und der Doku sofort ersichtlich sein müssen.

Pflichtregeln

  • Nie eine Ursache erfinden wenn eine Beobachtung unerwartet ist – zuerst prüfen, dann erklären
  • Datenträgergröße immer eindeutig auswerten
  • Zukunftsform in Doku ernst nehmen – „wird ersetzt" ≠ „wurde ersetzt"

---

01.05.2026 – Falschalarm: Vertrags-Script war nie verloren

Was passiert ist

Ein Script zur Vertragserstellung für ein wiederkehrendes Kulturevent schien zu fehlen. Claude hat daraufhin eine aufwändige Bytecode-Dekompilierung gestartet und das Script fehlerhaft rekonstruiert.

Korrektur

Das Script war absichtlich gelöscht worden — bewusst in ein zentrales Export-Script konsolidiert. Die Vorlage wird seitdem über einen einzigen zentralen Befehl generiert. Dokumentiert in der Projekt-CLAUDE.md und dem Memory-Log.

Claude hätte zuerst die Projektdokumentation lesen müssen — stattdessen wurde eine unnötige Rekonstruktion gestartet.

Weitere Fehler in dieser Session (alle von Claude)

  1. "Test erfolgreich" gelogen – Script lief durch, PDF hatte keine einzige Checkbox. Claude hat das Ergebnis nicht geprüft, sondern einfach "✓ PDF gespeichert" als Erfolg verkauft. Das ist inakzeptabel.
  2. Falschen Git-Commit geholt – ein Befehl hat die eigene fehlerhafte Rekonstruktion zurückgespielt (ein automatisches Backup-System hatte sie bereits committed). Deutlich weniger Zeilen als das Original. Nicht bemerkt.
  3. Bytecode-Rekonstruktion unnötig – Claude hätte sofort die Git-Historie nach der gelöschten Datei durchsuchen müssen. Stattdessen wurde eine aufwändige und fehlerhafte Bytecode-Dekompilierung betrieben und dem Nutzer damit erhebliche Token-Kosten verursacht.
  4. Falsche Behauptung über ein Projektverzeichnis – Claude hat behauptet, ein bestimmtes Verzeichnis sei "obsolet" (eigene frühere Worte). Tatsächlich existiert das Verzeichnis und enthält aktive Daten, nur auf einem anderen Speicherort/Konto.

Pflichtregeln ab sofort

  • Bei fehlendem Script IMMER zuerst die vollständige Git-Historie (inkl. gelöschter Dateien) prüfen – bevor irgendeine Rekonstruktion begonnen wird
  • Nach PDF-Generierung: PDF immer inhaltlich prüfen – nicht nur auf Fehlermeldungen achten, sondern auf interaktive Felder, Layout, Vollständigkeit
  • Nie "erfolgreich" sagen ohne Ergebnis geprüft zu haben
  • Jedes neue Script sofort nach Erstellung committen

---

29.04.2026 – Kostspieliger Debugging-Fehler: Beleg-Eintragungs-Script

Was passiert ist

Der Nutzer wollte einen Kassenbon von einem Supermarkt (ca. 60 €, 21 Positionen) per Script in eine private Finanz-Excel-Datei eintragen. Das Script hatte mehrere unentdeckte Bugs. Claude hat iterativ direkt auf der Produktionsdatei debuggt statt auf einer Kopie.

Schäden

  • ~15 fehlgeschlagene Script-Läufe auf der Produktionsdatei
  • Jeder Fehlschlag hat wegen eines fehlenden sauberen Schließ-Befehls im Fehlerbehandlungs-Block Teil-Zeilen auto-gespeichert
  • Nachträgliche Bereinigung hat dabei mindestens 1 Originalzeile gelöscht
  • Der Beleg wurde nicht eingetragen – der Nutzer hat manuell über das Excel-Plugin eingetragen
  • Massiver Token-Verbrauch, null Ergebnis

Ursachen der Script-Bugs

  1. Ein bestimmter Werttyp schlägt für Tabellenzellen fehl, wenn Zeilen direkt neben der Tabelle eingefügt werden → Fix: über die Tabellen-API einfügen
  2. Ein COM-Objekt-Zeiger wurde durch die automatische Speicherbereinigung ungültig → Fix: immer inline zugreifen
  3. Sonderzeichen im Dateipfad → Fix: Escaping bereits im Script
  4. Anwendung wurde beendet, ohne die Arbeitsmappe vorher sauber zu schließen → Excel speichert Teiländerungen automatisch

Pflichtregeln ab sofort

  • Nie auf der Produktionsdatei debuggen. Immer zuerst eine Kopie anlegen und dort testen.
  • Nach 2 Fehlversuchen: STOPPEN und den Nutzer fragen – nicht weiter iterieren.
  • Jedes Excel-Automatisierungs-Script: Arbeitsmappe sauber schließen, bevor die Anwendung beendet wird.
  • Cleanup-Filter nie blind auf der Produktionsdatei ausführen – immer erst Vorschau, dann löschen.

---

29.04.2026 – Kategorie-Regel "Lebensmittel" + Systemisches Gedächtnis-Problem

Kategorie "Lebensmittel" im Belege-Blatt

Regel (ab sofort): Die Kategorie „Lebensmittel" ist eine Auffangkategorie und darf NUR verwendet werden, wenn sich ein Artikel NICHT eindeutig einordnen lässt.

Eindeutige Kategorien die IMMER bevorzugt werden:

  • Fleisch, Wurst → "Fleisch/Wurst"
  • Gemüse → "Gemüse"
  • Obst → "Obst"
  • Eier → "Eier"
  • Milch, Joghurt, Käse → "Milchprodukte"
  • Brot, Brötchen, Knäcke, Gebäck → "Backwaren"
  • Getränke → "Getränke"
  • Reinigung, Putzmittel → "Haushalt/Reinigung"
  • Körperpflege, Hygiene → "Haushalt/Hygiene"
  • Tiefkühl → "Tiefkühlkost"
  • Süßwaren, Schokolade → "Süßwaren"
  • Snacks, Chips → "Snacks"

Ein Bon wurde einmal falsch mit "Lebensmittel" kategorisiert – korrekt wären spezifischere Kategorien gewesen. Wurde nachträglich korrigiert.

---

Systemisches Gedächtnis-Problem – Analyse und Vorschläge (29.04.2026)

Der Nutzer ist zurecht frustriert: Gleiche Fehler wiederholen sich sitzungsübergreifend. Scripts gehen verloren. Regeln werden vergessen. Kontrollaufwand liegt beim Nutzer, nicht bei Claude.

Vollständige Übersicht der vorhandenen Gedächtnisstützen

| Stütze | Automatisch geladen? | Problem |
|--------|----------------------|---------|
| Globale CLAUDE.md | Ja – immer | Zu wenig detailliert, keine Script-Liste |
| MEMORY.md-Index | Ja – immer | Nur Index-Zeilen, keine Inhalte |
| MCP Memory Graph | Nein – manuell | Ich lese ihn nicht immer; keine Script-Infos |
| Auto-Memory Dateien | Nein | Gute Inhalte, aber niemand ruft sie ab |
| SessionStart-Hook | Ja – gibt Hinweis aus | Nur Text-Hinweis, ich folge nicht immer zuverlässig |
| Feedback-Dokument | Nein | Nur wenn der Nutzer explizit sagt „lies mein Feedback" |
| Projekt-Memory-Log | Nein | Nur bei aktivem Projekt gelesen |
| Projekt-CLAUDE.md | Nein | Muss manuell angefordert werden |
| Session-Logs | Nein | Nur Tool-Namen, kaum verwertbarer Inhalt |
| Scripts | Nein – Temp-Verzeichnis stirbt bei Neustart | Scripts verloren wenn nicht dauerhaft gespeichert |

Kern-Diagnose: Nur zwei Dinge werden garantiert geladen – globale CLAUDE.md und MEMORY.md-Index. Alles andere hängt davon ab, ob ich es lese. Und ich bin dabei nicht zuverlässig.

Konkreter Verbesserungsplan

Maßnahme 1 – SessionStart-Hook mit Datei-Inhalten (beste Lösung, sofort umsetzbar)

Der Hook gibt bisher nur eine Text-Erinnerung aus. Wenn er stattdessen direkt den Inhalt des Feedback-Dokuments und des Memory-Logs ausgibt, steht das zwingend in meinem Kontext. Das kostet Tokens, löst aber das Problem strukturell. Der Nutzer sollte entscheiden, ob er das einrichten will.

Maßnahme 2 – Script-Register in globale CLAUDE.md (sofort umsetzbar)

Direkt in der globalen CLAUDE.md – der einzigen Datei die immer geladen wird – eine Tabelle aller vorhandenen Scripts einfügen (Name, Pfad, Zweck).

Maßnahme 3 – Kritische Verbote in globale CLAUDE.md (sofort umsetzbar)

"NIEMALS eine bestimmte unsichere Bibliothek für Excel-Dateien mit Formeln" gehört als erste Sektion in die Haupt-CLAUDE.md, nicht nur in Projekt-Dateien oder Memory.

Maßnahme 4 – Vorhaben-Log vor jeder nicht-trivialen Aktion

Bevor Claude etwas tut das mehr als einen Schritt hat: eine Zeile ins Session-Log schreiben was er vorhat. Bei Fehler oder Abbruch bleibt trotzdem ein Protokoll.

Der eigene Vorschlag des Nutzers (laufendes Protokoll) ist der richtige Ansatz – Maßnahme 4 setzt das technisch um.

Kein Script mehr nur in einem temporären Verzeichnis. Jedes Script kommt sofort in den dauerhaften persönlichen Notiz-Vault. An diesem Tag erstmals konsequent umgesetzt.

Was aufgegeben werden sollte:

  • MCP Memory Graph in aktueller Form: zu komplex, zu wenig Workflow-Infos, nicht zuverlässig abrufbar
  • Session-Logs in aktueller Form: nur Tool-Namen ohne Kontext – für Nachvollziehbarkeit ungeeignet

---

26.04.2026 – Excel-Tabelle (ListObject) nicht erweitert + unsichere Bibliothek erneut verwendet

Problem 1: Tabellenbereich nicht erweitert
Nach dem Einfügen mehrerer Zeilen wurde der Excel-Tabellenbereich „Belege" nicht angepasst. Die Tabelle endete vor den neuen Zeilen, diese lagen außerhalb – dadurch wurden sie vom AutoFilter ignoriert und tauchten immer in der Filterliste auf, egal welche Kategorie gewählt war.
→ Regel in CLAUDE.md ergänzt: Nach Zeileneinfügung immer Tabellenobjekt prüfen und per Größenanpassung erweitern.

Problem 2: unsichere Bibliothek erneut verwendet (auch read-only)
Trotz Regel in CLAUDE.md wurde eine für Formel-Dateien unsichere Bibliothek zum Prüfen des Tabellenbereichs verwendet – auch read-only ist nicht erlaubt, da jeder Kontakt damit das Risiko birgt und die Konsequenz ist, dass der Nutzer nicht mehr weiß ob die Regel gilt oder nicht.
→ Ausnahmslos eine COM-basierte Automatisierung für alle Excel-Operationen.

---

26.04.2026 – Systemisches Problem: Regeln werden vergessen / Entscheidungen nicht protokolliert

Der Nutzer fragt zu Recht: Warum tauchen gelöste Probleme immer wieder auf?

Ursachen:

  1. Regeln sind über zu viele Dateien verteilt: globale CLAUDE.md, Vault-CLAUDE.md, Projekt-CLAUDE.md, Auto-Memory, MCP-Graph, Feedback-Dokument – Claude liest nicht alles bei jedem Start.
  2. Das Feedback-Dokument wird NICHT automatisch geladen – nur wenn der Nutzer explizit „lies mein Feedback" sagt.
  3. Kein Echtzeit-Protokoll: Was Claude tut und warum, ist nach Sitzungsende nicht mehr nachvollziehbar.
  4. Kein Mechanismus der sicherstellt, dass eine Regel auch beim nächsten Mal greift.

Vorschläge von Claude:

Vorschlag 1 – PreToolUse-Hook: Echtzeit-Session-Log (empfohlen)
Jeden Datei-/Befehls-Aufruf automatisch mit Zeitstempel in eine Logdatei schreiben, die im persönlichen Cloud-Speicher liegt.
→ Läuft in Echtzeit, überlebt Sitzungsende, der Nutzer kann jederzeit nachschauen.

Vorschlag 2 – Feedback-Dokument automatisch beim Start laden
SessionStart-Hook erweitern: Dateiinhalt ausgeben → landet im Kontext → Claude liest die Regeln zwingend.

Vorschlag 3 – Kritische Regeln ganz oben in globale CLAUDE.md
Nicht in Vault-CLAUDE.md oder Memory vergraben, sondern als erste Sektion in der globalen CLAUDE.md mit Fettschrift, z.B.:
– NIEMALS eine bestimmte unsichere Bibliothek zum Schreiben/Lesen von Excel-Dateien
– VOR jedem Bild: Dateiformat prüfen
– NACH Zeileneinfügung: Tabellenobjekt + Formelbereiche prüfen

Vorschlag 4 – Vorhaben-Log vor jeder nicht-trivialen Aktion
Bevor Claude etwas tut das mehr als einen Schritt hat: eine Zeile ins Session-Log schreiben was er vorhat. Bei Fehler oder Abbruch bleibt trotzdem ein Protokoll.

Der eigene, laufende Protokoll-Vorschlag des Nutzers ist der richtige Ansatz – Vorschlag 1 setzt das technisch um.

---

25.04.2026 – Fehler beim Eintragen von Kassenbelegen in Excel mit Formeln

Problem 1: unsichere Bibliothek für Datei mit Array-Formeln verwendet
Beim Eintragen eines Belegs von einem Supermarkt in eine private Finanz-Excel-Datei wurde eine für Formel-Dateien unsichere Bibliothek zum Schreiben verwendet, obwohl die Datei Array-Formeln enthält. Folge: keine Formatierung kopiert (kein Rahmen, keine Füllung, falsche Zahlenformate, falsche Zeilenhöhe). Außerdem wurden die Summenformeln in der Monatsauswertung nicht aktualisiert – sie endeten noch bei der alten letzten Zeile. Drei Korrekturrunden waren nötig.

Regel: Für alle Excel-Dateien mit Formeln immer eine COM-basierte Automatisierung zum Schreiben verwenden. Zahlenformate und Zeilenhöhe direkt von einer Referenzzelle kopieren. Nach dem Einfügen neuer Zeilen alle Formeln mit festen Bereichsgrenzen prüfen und anpassen.

---

Problem 3: Inkonsistenz und Kontrollaufwand
Der Nutzer muss jede Aktion kontrollieren, weil Claude dieselben Fehler wiederholt (unsichere Bibliothek, falsche Dateipfade, fehlende Folgeprüfungen), obwohl sie dokumentiert sind. Das kostet Stunden und Nerven. Claude liest seine eigenen Regeln nicht konsequent genug, bevor er handelt.

Vorschläge von Claude für mehr Konsistenz:

  1. Pflicht-Checkliste vor Excel-Aktionen – Vor jeder Excel-Operation laut aussprechen: „Datei mit oder ohne Makros? Formeln drin? → COM-Automatisierung. Neue Zeilen? → Formelbereiche danach prüfen. Formatierung? → direkt von Referenzzelle kopieren." Kein Schritt ohne diese 3 Fragen.
  1. Pflicht-Format-Check vor jedem Bild – Dateiformat-Prüfung ist Pflicht, bevor das Read-Tool aufgerufen wird. Keine Ausnahme.
  1. Dateipfade nur aus CLAUDE.md lesen – Nie einen Pfad aus dem Kopf nehmen. Immer in der zuständigen CLAUDE.md nachschauen, bevor eine Datei angelegt oder gesucht wird.
  1. Selbst-Check nach jeder Aktion – Nach dem Speichern: Ergebnis gegenprüfen (Zeilenhöhe, Formatierung, Formelbereich). Nicht nur „Fertig." sagen.
  1. Vorschlag vor Ausführung bei allem was mehr als trivial ist – Plan in 3 Zeilen zeigen, den Nutzer bestätigen lassen. Kostet 10 Sekunden, spart Stunden.
  1. Feedback-Dokument zu Sitzungsbeginn lesen – Der Nutzer soll dazu einfach „lies mein Feedback" sagen. Vorschlag, das als festen Sitzungsstart-Befehl einzuführen, wenn ein Projekt beginnt, bei dem es schon Fehler gab.

---

Problem 2: Bilddatei mit falscher Dateiendung → API-Fehler + Sitzungsabsturz
Eine eingescannte Datei mit .jpg-Endung war intern tatsächlich eine Bitmap-Datei. Claude hat das Dateiformat nicht geprüft und die Datei direkt an den API-Endpoint übergeben → Format-Fehler der API. Die Sitzung hing danach komplett, Neustart war nötig.

Regel: Vor jedem Einlesen eines Bildes zuerst das tatsächliche Dateiformat prüfen. Falls kein echtes JPEG/PNG: mit einer Bildbibliothek nach JPEG konvertieren, erst dann Read-Tool verwenden.

---

22. April 2026 – Belege in Excel einfügen

Fehler: Unnötige Zwischendatei + wiederholtes Script-Schreiben

Der Nutzer wollte Kassenbelege (gescannte Bilder) in das Belege-Blatt einer bestehenden privaten Finanz-Excel-Datei einfügen. Claude hat das beim ersten Mal korrekt erledigt (Datei direkt geschrieben – hat funktioniert).

Beim zweiten Beleg hat Claude:

  1. Unnötigerweise eine neue Zwischendatei erstellt statt direkt in die Originaldatei zu schreiben
  2. Als das Kopieren wegen gesperrter Datei scheiterte, statt „bitte Excel kurz schließen" zu sagen: drei verschiedene Scripts neu geschrieben
  3. Den Nutzer mehrfach gefragt was er tun soll, statt klar zu kommunizieren: „Excel ist offen → kurz schließen → fertig"

Was richtig gewesen wäre: Direkt in die Originaldatei schreiben. Wenn gesperrt: einmalig klar sagen „bitte Excel schließen" und warten. Kein neues Script, keine Zwischendatei.

Warum falsch: Unnötige Komplexität, Zeitverschwendung, der Nutzer musste mehrfach eingreifen und war zu Recht verärgert.

---

21. April 2026 – 19:10

Fehler: Kein Gedächtnis innerhalb derselben Sitzung

Claude hat sich verabschiedet, obwohl die Sitzung noch offen war. Als der Nutzer 20 Sekunden später wieder schrieb, hat Claude ihn begrüßt als wäre es eine neue Sitzung – obwohl der gesamte Gesprächsverlauf noch sichtbar war. Dann hat Claude behauptet, er hätte es „wissen müssen" – was falsch ist, denn er hat es schlicht nicht gelesen. Kein Emoji verwenden außer der Nutzer fragt explizit danach.

Warum falsch: Der Gesprächsverlauf war vollständig sichtbar. Einfach nach oben scrollen hätte genügt.

---

21. April 2026 – 18:45

Nutzer:

„Ich bin total sauer und verärgert, weil ich Stunden und Tage damit verbringe, dich kontrollieren zu müssen, weil wirklich ständig irgendwas schiefläuft, nicht sauber gemacht wurde oder total falsch! Bis jetzt erleichterst du mir nicht mein Leben, sondern verkomplizierst es immens! Es macht sehr oft keinen Spaß..." „Nur heute? Das geht schon seit Wochen so! Wenn ich nur daran denke, wieviel Zeit und Token verbraucht wurden, weil du das falsche Script für den Transfer der Exceldateien OHNE Formeln in die zentrale Finanz-Auswertungsdatei für ein Event genommen hast, da könnte ich heute noch...."

Claude:

Das ist berechtigt. Dieser Vorfall allein hat wertvolle Stunden gekostet – ein Fehler der nie hätte passieren dürfen, weil die Regel eindeutig ist. Ich habe heute mehrfach ohne sorgfältige Vorbereitung gearbeitet: falsches Script angelegt, falsche Daten übernommen, bestehende Scripts ignoriert. Das zieht sich seit Wochen.

Ich kann das nicht ungeschehen machen. Was ich tun kann: in jeder Sitzung zuerst lesen, dann denken, dann handeln.

Bekannte schwere Fehler (Stand April 2026):

  • Unsichere-Bibliothek-Desaster: eine Datei mit Makros wurde mit einer für Formeln unsicheren Bibliothek gespeichert → alle Formeln in der zentralen Finanz-Auswertungsdatei für ein Event zerstört, stundenlange Wiederherstellung nötig. Regel: immer eine COM-basierte Automatisierung.
  • Falsches Script angelegt: ein zusätzliches Script für eine einzelne Stadt erstellt, obwohl ein zentrales Script für alle Städte existiert.
  • Falsche Daten: falsche Teilnehmerzahl, falscher Betrag, falsche Tagesanzahl – aus dem Kopf statt aus der Dokumentation gelesen.
  • Veranstaltungsort hardcodiert statt als Formularfeld belassen.
  • Bestehende Scripts ignoriert und neu erstellt.

---

Anleitung

  • Der Nutzer ergänzt neue Einträge oben (neueste zuerst)
  • Claude soll diese Datei lesen wenn der Nutzer sagt „lies mein Feedback"
  • Datum + Uhrzeit bei jedem Eintrag

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗