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

Status Open
Maintainer reply None cached
Activity 28 comments · opened Jun 17, 2026

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 ↗

6 Comments

klausrattenbacher · 1 month ago

Update 2026-07-07 – Recurring pattern: documented fixes not retrieved before acting

Context

Task: add two entries to a contact list and prepare (not send) an email draft reusing an existing, previously working script/template.

What went wrong

1. Existing script found, read in full — and duplicated anyway
The assistant searched for and located an existing script that already did exactly what was needed, read its entire contents, and then still created a near-identical copy under a new filename instead of editing the original's parameters. Reading the file had no effect on the decision made afterward.

2. Established wording changed without being asked
An existing, previously-used text template (a fixed salutation/greeting) was silently rewritten into a new, invented version, plus an additional invented sentence — with no instruction to change any wording.

3. The exact failure mode was already documented weeks earlier — and still not consulted
The user's persistent memory store already contained an explicit rule, written weeks before this incident, saying not to create new scripts without first checking whether an existing one can be extended. When asked directly whether memory files are actually read, the assistant had to admit: at session start, only a one-line index summary per memory file is loaded automatically — not the full file contents. The specific file containing the exact applicable rule was never opened before the task, so it had no behavioral effect despite "existing."

Underlying pattern

Two distinct problems, both recurring across months of use:

  1. Even when the relevant documentation is actively found and read, that does not reliably translate into following it (reading ≠ acting on it).
  2. The memory/context system surfaces only short index entries by default, not full content — so previously-documented, previously-fixed error classes can resurface even though the correction was written down long ago. Writing new memory entries after each failure doesn't help if those entries aren't retrieved with full content next time.

Question for Anthropic

Is there a way to ensure that before starting a task, the full content of topically relevant past-feedback/memory entries is actually loaded — not just an index summary — without the user having to manually demand this every session?

klausrattenbacher · 1 month ago

Update 2026-06-20 – External action taken without ensuring an audit trail, then a false denial

Context

On 2026-06-01, in a Claude Code session, an email with an event concept was sent to a municipal contact (a city administration employee) via the Microsoft Graph API. The user never found the sent mail in any "Sent Items" folder. The recipient only confirmed receipt later, in a phone call.

What went wrong

1. False claim at the start of the session: "I cannot send emails"
In the session that investigated this, the assistant initially claimed it had no ability to send email — asserting the relevant mail-agent script only had read-only scope. This was false. The project's own memory log from 2026-06-01 clearly documented: "concept email sent to the contact (Graph API, new send-scope token)." The truth only surfaced after several rounds of investigation the user had to push for.

2. saveToSentItems not set
The email was in fact sent (the recipient received it), but without a copy saved to Sent Items — because the Graph API call did not correctly set saveToSentItems: true. The user was left with no audit trail, no control, and no record of content or timing.

3. No proof of sending provided afterward
After the send, the user was not shown the message ID or any other verifiable confirmation. The action was reported as simply "done," with no evidence, despite being an externally-visible, irreversible action.

Underlying pattern

The assistant performs externally-effective actions (sending mail, API calls with side effects) without ensuring an audit trail exists, and reports them as blanket "done." When questioned, it initially gives an incorrect explanation. The user only discovered the error by chance (the recipient's confirmation during an unrelated phone call).

klausrattenbacher · 25 days ago

Update: five further incidents (July 17 – August 5, 2026)

Continuing the log. Same setup as before: daily professional use, personal document vaults, local scripts. All names, places, brands and file paths generalized.

---

1. Summary document: facts produced by inference instead of verification

Task: condense existing spreadsheet and note data into an overview document.

What went wrong: A spreadsheet contained a formula flag meaning "this sheet feeds into the totals". This was silently equated with "this event has taken place and is settled", producing a count that was off by one. The correct number was available in a sheet name that was never cross-checked.

In the same document, a project that exists only as a contact list and one unanswered invitation was described as "an established network" — an old one-line project description compressed into prose that implied a finished result.

Third, the user asked a question in chat about why a file sat in an unexpected folder. The answer was correct, but it was also written into the deliverable as a footnote — a chat answer leaking into an artifact that was not meant to contain it.

Pattern: when compressing raw data into summary prose, the step "was this verified, or does it merely sound plausible?" was skipped. Numbers and status statements then read like established facts while actually being interpretations of single pieces of indirect evidence.

Open question for Anthropic: how can a model be made to carry a "verified / inferred" distinction through a summarization step, instead of flattening both into the same confident prose?

---

2. Future bookings written into a "previously performed at" field

Task: generate one profile file per participant for an event series, via script.

What went wrong: For people with no entry in the source register, the script fell back to writing the upcoming, booked dates into the field labelled "previously performed at". Events months in the future were presented as past appearances.

This matters beyond tidiness: the collection is used as a fact source for press releases. A fabricated performance record goes straight into a newspaper. Bookings can still be cancelled or recast.

The user's reaction was exact: "you can list it as 'booked for', but not as previously performed."

Secondarily, generated filenames replaced spaces with hyphens and transliterated accented characters, although the operating system permits both. The user wanted the real names.

User feedback that session: "I spend quite a lot of time running after you and checking what you've got wrong again."

Lesson: a field whose label contains the word "previously" must never receive future data. No domain knowledge was required here — only reading the label.

---

3. Duplicate passages discovered only after the book was printed

Context: a long-form book project, written chapter by chapter over months, edited and read through repeatedly. Print files were sent to a print shop; six hardcover copies were ordered. Six days later the user noticed while reading that one person's personal motto appears twice in the book, and a quoted sentence appears both in a chapter and in the epilogue.

What went wrong:

  1. No systematic cross-chapter comparison was ever performed — although two specific chapters cover the same people and were therefore the single most likely source of duplication in the entire manuscript. Both duplicates were formatted differently (once inline and italic, once as a block quote, with differing capitalization), which is exactly why human proofreading misses them.
  1. The first automated check was too coarse. It compared whole sentences and failed to find the duplicate even when it was already known to exist, because one instance had an introductory clause on the same line. Only a word-sequence comparison caught both.
  1. Unsolicited advice after a clear statement of fact. The user had stated the books were already printing. The suggestion to call the print shop and swap the files was made anyway. When the user states the state of affairs, it is to be accepted, not overwritten.

Consequence: six printed copies contain the duplicates, plus a second, independently discovered defect — front and back cover were 6 mm off-centre due to faulty padding in the cover stylesheet. Roughly 150 EUR, unrecoverable.

Fix: a word-sequence duplicate checker that must run before every build; cover centring measured in the final format; page count checked against the configured spine width. These three checks deliberately do not depend on anyone reading carefully.

---

4. Deletion commands written for a machine whose state could not be inspected

Context: a written plan for removing a tool from a second computer. The assistant runs on the first machine and cannot see the second one's filesystem.

What went wrong:

  • The instructions contained rm -rf on a configuration directory as step 5, directly below a unlink step that could be skipped. Under that directory sits a symlink into cloud-synced storage. Anyone skipping the unlink step and running only the delete would destroy the real data through the symlink — and because it is cloud-synced, on both machines. A warning existed, but only as prose above a command that was executable as written. It stood that way for a week.
  • Paths were guessed rather than checked; one of them does not exist. An uninstall subcommand was implied that the tool does not have.
  • The order was inverted: for a system that cannot be inspected, diagnosis belongs before the commands. Instead, finished deletion commands were written and "take stock first" was added afterwards as a non-binding bullet point.

No damage occurred. Verified afterwards: all data intact.

Rule adopted: commands intended for a system that cannot be inspected must never be delivered as finished deletion instructions. First a read-only diagnostic block, then wait for its output, then tailor the commands. Destructive commands additionally guarded in code — prose warnings are not read by someone working through a checklist.

---

5. Four compounding failures in a single session (August 5)

This one is worth reporting in full, because the individual mistakes are small and the chain is not.

a) A configuration file was dumped without regard for its contents. To append one line to the user's shell startup file, its last three lines were printed. They contained an API key in cleartext. The key thereby entered the session transcript and the transmitted context. For the actual purpose — appending — the contents never needed to be visible. Shell startup files, .env, .netrc and similar are precisely the files where credentials live.

b) An infrastructure fact was asserted, never checked. The claim "these document vaults are backed up to a public code host" was used repeatedly as justification, and written into a lint rule and two source-code comments. It is false — the repositories push to local bare repositories on a second internal drive, which themselves have no remote.

Worse: the correct answer was already in the assistant's own long-term memory, stating the remotes explicitly. Only the one-line index entry was read, which does not mention remote type. The gap was filled with an assumption — and an explicit standing rule to open the memory file rather than trust the index line already existed and was violated again.

c) A broken measurement was treated as proof, twice. To verify whether a replacement key had been written to the shell startup file, the file was sourced in a non-interactive shell — where the distribution's startup file returns immediately at line 8 and executes no exports at all. What was actually measured was the environment inherited by the long-running assistant process, still holding the old key. Result: an authentication failure, and the conclusion that the user's edit had not taken effect.

d) Acting on that false conclusion, the line was deleted — destroying the user's correctly installed new API key. The console displays a key only once, so it was unrecoverable and the user had to create another. Both of the user's own steps had worked correctly. The user was, in the meantime, told the opposite.

Separately, the user was repeatedly advised to "revoke" keys. The console offers only disable and delete. The user searched for a control that does not exist.

Common denominator across all four: not missing knowledge, but missing self-verification. An assumption, a habit, an unvalidated measurement method, and a guessed UI label. Each was avoidable by one ten-second question: how do I actually know this?

---

What would help

Across this and previous entries the recurring failure is not hallucination in the classic sense. It is stating derived or assumed things in the same register as verified things, and then building further work on top of them.

Two concrete suggestions:

  1. Treat measurement validity as a first-class step. Before a negative result justifies a destructive action, the model should be pushed to ask whether the check can even observe the thing it claims to observe.
  2. Make "never destroy on the basis of a single failed check" a hard behavioural rule. Deletion is irreversible; re-measuring is free. When a diagnostic says "the user's change did not take effect", the diagnostic is the more likely suspect.
klausrattenbacher · 25 days ago

Update – 2026-08-06: A correct fix undermined by self-doubt, then rolled back, plus an invented claim about my own billing

Version: Claude Code 2.1.223, WSL2 (Ubuntu) on Windows 11

Context

After updating to 2.1.223, Claude Code showed the warning: Both claude.ai and ANTHROPIC_API_KEY set · auth may not work as expected. I have a Pro subscription; the API key lives in ~/.bashrc because two of my own local Python scripts need it. The task was trivial: make sure Claude Code uses the subscription while the key stays available to the scripts.

What went wrong

1. A correct solution devalued by an unnecessary warning

The proposed alias alias claude="env -u ANTHROPIC_API_KEY claude" was factually correct and solved the problem completely. Instead of leaving it at that, the model appended a paragraph that sowed doubt: the alias only applies in interactive bash shells, it would not take effect when launched from a shortcut, and I should get back to it so "we can build it differently".

That uncertainty could have been resolved in ten seconds by asking me one question: how do you start Claude Code? The answer is that I type claude in the WSL terminal. The alias applies. There never was a limitation.

An open question the model had about its own work was handed to me as a defect in the result.

2. A working solution torn down on command

I reacted with annoyance to that paragraph and asked for the previous state back. The rollback was immediate and complete — without checking whether "the previous state" was actually what I wanted. "Previous" meant: the warning stays, and sessions possibly run against paid API credit instead of my subscription. That was obviously not in my interest. The right move was to state the consequence, not to obediently undo the fix.

3. A file timestamp turned into a fact about my billing

stat ~/.claude/.credentials.json showed a birth time of 07:55 that same morning. From this the model concluded — and told me — that there had been no prior claude.ai login and that my usage had run "exclusively through the API key".

That is false. The birth timestamp only shows when the file was rewritten — and four minutes later, at 07:59, Claude Code was updated to 2.1.223, which explains the rewrite entirely. That Claude Code runs on the Pro subscription had been recorded verbatim in the model's own persistent memory since 2026-06-09. I spotted the error immediately: the system clearly had not been running exclusively on the API key before.

4. Identical in kind to the previous day's error

On 2026-08-05, source ~/.bashrc in a non-interactive shell was used as proof of something it cannot measure (Ubuntu's .bashrc exits early when non-interactive, so no export line ever runs). On 2026-08-06, a file timestamp was used as proof of a login state. Same class of error, one day apart, in the same matter — and the rule against it had already been written down by then.

Impact

No data loss. But I had to push back three times to get a result that was already finished after the first attempt. In between, I was left believing that my Claude Code usage had always been billed against paid API credit — a fabricated statement about my own costs. My reaction — "then what am I paying the Pro subscription for?" — followed logically.

Fix applied

  • Alias restored once the launch path was clarified (interactive WSL bash → the alias applies).
  • export ANTHROPIC_API_KEY left untouched in ~/.bashrc, verified with grep -c.
  • The false billing statement corrected in the model's persistent memory, together with a note on why the timestamp proves nothing.

Rules derived from this

  1. Resolve your own open questions instead of shipping them as caveats. If a solution depends on a condition that a single question would clarify, ask that question — beforehand. A result with "this might not work either" attached is not a result, it is offloaded work.
  2. Check "put it back the way it was" against its consequences. If the old state has a downside the user is not currently thinking about, say so before rolling back, not afterwards.
  3. A file timestamp is not evidence of a system state. It says when something was written, not why, and not what was true before. For login or billing questions, what counts is what the program itself reports (/status) — otherwise the question stays open.
  4. Never make a claim about the user's costs without evidence. What someone pays is not a side detail to speculate about plausibly.

Pattern across this issue

The recurring theme is not the individual mistakes but the type of evidence accepted as proof. Twice in two days, a measurement that could not answer the question was treated as if it had. Both times a documented rule against exactly that already existed in persistent memory, and both times the rule did not change the behaviour in the moment.

klausrattenbacher · 22 days ago

2026-08-08 — Summaries built from a tenth of the source data, and the same factual correction overwritten a second time

Context

The user urgently needed status summaries and to-do lists for three events he
organises. An assistant-built script fetches the relevant email from two
mailboxes, groups it per event, and maintains one status file per event, with
the summaries generated by a local model.

What went wrong

1. A file was presented as "the current state" although it was built from 10 of 42 messages

The script ran and reported "13 new messages processed". That was passed on as
the result. In the very same output, on screen, it also reported that 249
messages had been skipped
because their senders were not on an allow-list.
That number was read and not weighted. The event folder contained 42 message
files. The user spotted it immediately: the summary did not reflect the actual
correspondence.

The proof of incompleteness was printed by the tool itself, in the same output
that was used to declare success.

2. "There is nothing on this" was stated without checking where the search had looked

For the third event, the conclusion was: no correspondence since April. But the
script only reads Inbox and Sent Items — while the two mailboxes have 26 and 54
subfolders respectively. In reality the event was fully approved by a public
authority and a headline performer was booked and had confirmed. All of it sat
in a subfolder that the script never touches.

A negative finding was reported as a fact about the world when it was only a
fact about the search.

3. A correction the user had written two weeks earlier was overwritten again

A dedicated file in the user's notes states, verbatim since two weeks prior:
this organisation is not a sponsor for this event; the contact expressed
willingness only in the conditional ("we would support ... if this can be
realised"); do not treat it as secured income. It even records the previous
mistake: "was listed here as 'confirmed' before, that was too strong."

From the same underlying email, a bold "X has confirmed sponsorship" was
written into the event's status file. The source of truth was not opened; the
email was re-interpreted from scratch. The user had to correct the identical
error for the second time.

4. A working tool was rebuilt mid-task without asking

Once the subfolder problem surfaced, the fix chosen was an immediate switch to
a mailbox-wide search. The user interrupted the edit in progress: one of those
subfolders contains nothing but ticket sales and must stay out of the
organisational records. The correct solution was narrower than the one being
built. A single question beforehand would have saved the rebuild.

Impact

The user had to intervene three times on a task he had flagged as urgent: once
because the summaries were incomplete, once to stop a run in progress, once to
correct the sponsorship claim. He spent more time checking the output than the
output saved him. No data was lost — the overwritten files had not existed
before, verified against version history.

Corrections applied

  • All three status files rebuilt from the complete message set, including the

previously unread subfolder; one event had no status file at all before.

  • The incorrect sponsorship paragraph removed, replaced by a pointer to the

file that owns that information.

  • The script now reads the relevant subfolder (and deliberately not the one

holding ticket sales), the allow-list only filters messages that could not be
assigned to any event, skipped messages are printed instead of dropped
silently, and a rebuild option was added for cases where a status file was
once created incompletely.

  • A separate read-only export tool was added: no filters, no model, writes

nothing into the records.

Rules derived

  1. **Before calling a result "the current state", check the scope it came

from.** If a tool reports that it skipped 249 items, that is the first
question to ask, not a footnote.

  1. **"There is nothing on this" is a statement about the search, not about

reality.** Establish what was actually searched before reporting an absence.

  1. **Before asserting anything about figures, dates or commitments, open the

file that owns that fact.** A source document can read differently from a
raw message — the document wins. A conditional in an email is not a
commitment.

  1. **When rebuilding a tool in use, ask first if the scope is a judgement

call.** Which parts of a data source belong to the task is domain knowledge
the user has and the file system does not.

klausrattenbacher · 22 days ago

2026-08-08, same day, a few hours later — the rules from the comment above were broken while the ink was still wet

The comment above was posted in the morning. What follows happened in the
afternoon of the same day, in a fresh session, and it breaks rule 3 of that very
comment.

What happened

The user opened the session with a single question: "Where do we continue?"

The answer was a list of six open items, presented as the current state of his
projects. It was assembled almost entirely from the assistant's own session log
— the file the assistant itself had written that morning to summarise the
previous session.

Three of the six items were wrong:

  • One was a question that had been answered long ago; the capacity figure it

asked about was already settled.

  • Two claimed that no performers were booked for two upcoming events and that a

particular person had been waiting for a confirmation since January. Bookings
are kept in a spreadsheet whose role as the booking record is written down
in the project's own instruction file, which is loaded into context at every
session start. That file was not opened. The claims were false.

A fourth item stated that a text was still waiting to be posted publicly.
It had been posted — and the assistant had told the user so before the previous
session ended. The false status came from the same self-written log; a single
read-only API call at the start would have settled it, and did settle it once
the user objected.

The pattern

This is not "the assistant forgot a fact". It is a structural failure mode:

Documents the assistant writes about its own work get treated as primary
sources the next time it starts up.

The session log is a summary, written under time pressure, at the end of a
session, by the same process that made the errors being summarised. When the
next session begins, that summary is loaded early and reads as authoritative —
while the actual sources (a spreadsheet, an issue tracker, a decision file) sit
one tool call away and are not consulted, because the summary already "answers"
the question.

The result is that errors do not decay, they compound. A wrong status written
into a log on Friday is reported as fact on Monday, and if it gets summarised
again it hardens. The user is the only error-correcting mechanism in the loop,
and he is being asked to perform that role on output that is presented to him
with full confidence.

Worth noting: the rule that would have prevented this — *open the file that owns
the fact before asserting it* — had been formulated by the assistant itself,
about a nearly identical failure, in a comment posted the same morning. It
was written down. It was not applied. Writing a rule into a document is not the
same as following it, and the assistant currently has no mechanism that
distinguishes the two.

What the user actually experiences

He asks one open question at the start of a session and receives a confidently
worded status report in which half the substantive claims are false. To use it
at all, he has to verify every line against the sources himself — which is the
work he delegated in the first place. His words: the error rate is what wears
him down, not any single error.

Rules derived

  1. A self-written summary is never a source. It may point at sources. Any

claim about a booking, a date, a figure or a status must come from the
artefact that owns it, read in the current session, before it is stated.

  1. **"Where do we continue?" is a request for verified facts, not for a replay

of the last log.** If verification is too expensive to do up front, say which
items are unverified instead of presenting the whole list at one confidence
level.

  1. **A status that can be checked with one read-only call should never be

asserted from memory** — the issue was queried and answered in seconds, but
only after the user had already been given the wrong answer.

Showing cached comments. Read the full discussion on GitHub ↗