Die KI-Session-Übergabe

Claude Code nutzt ein endliches Kontextfenster. Seine am 17. Juli 2026 geprüfte offizielle Dokumentation beschreibt, dass ältere Tool-Ausgaben entfernt werden können, wenn es sich füllt. Auch der Gesprächsverlauf kann dann zusammengefasst werden; Detailanweisungen aus frühen Turns können verloren gehen, auch wenn wichtige Anfragen und Codeausschnitte erhalten bleiben. Laut derselben Dokumentation startet jede neue Session mit einem frischen Kontextfenster. Das ist Claude-Code-spezifisches Verhalten, kein Beleg für identischen Feldverlust in jedem Tool.

Die bequeme Deutung heißt „verlorene Produktivität“. Die folgenreichere heißt fehlender oder veralteter Verifikationszustand. Eine empfangende Session weiß womöglich nicht, was geprüft, zurückgestellt, angenommen oder überholt wurde. Das erzeugt ein Review-Risiko - dieselbe Grenze, die den Soll-Ist-Abgleich motiviert, nur über die Zeit gestreckt. Der Juni-2026-Preprint zu Delegation Contracts rahmt Aufzeichnungen zu „beauftragt, erlaubt, geliefert, belegt“ als Eingaben für Nachprüfbarkeit. Er testet dieses Übergabeformat nicht und belegt weder Kontinuität, Reproduzierbarkeit, Wiederherstellung noch Defekt-Outcomes.

1. Stabile Wahrheiten in die Instruktionsdatei. Aufbau, Konventionen, Constraints - laut offizieller Claude-Code-Dokumentation wird die projektweite CLAUDE.md in frische Sessions geladen und nach Kompaktierung wieder eingespeist. Sie ist Kontext, keine erzwungene Setup. Nur Regeln; kein Arbeitszustand.
2. Die Übergabe vor dem Session-Ende schreiben. Behaupteter Stand, Entscheidungen mit Begründung, Belege und Grenzen, Annahmen, offene Risiken oder Konflikte, operatorgeführte Entscheidungen und nächster Schritt - kompakt genug fürs Review.
3. Im Repo speichern. Ein uebergabe.md beim Code (oder je Arbeitsstrang) kann versioniert und gedifft werden. Zugriff, Pfadfindung und Aufbewahrung bleiben getrennte Konfigurationsfragen.
4. Die nächste Session damit starten. Erste Anweisung: Übergabe lesen, dann Revision, Behauptungen und Belege mit aktuellem Repo und Run-Status vergleichen.
5. Die Schleife schließen. Punkte unter „offen“ bleiben gelistet, bis ein benannter Operator sie löst, akzeptiert oder eskaliert. Die Datei allein erzwingt diesen Prozess nicht.

STAND        Rate-Limit-Header-Arbeit · 2 von 3 Tasks fertig
             [fertig] Retry-After bei 429 · [fertig] Unit-Tests
             [in Arbeit] CDN-Durchreich-Check

ENTSCHEIDUNGEN  Header-Wert = Rest des Fensters, NICHT fix 60 s
                (folgt RFC-6585-Guidance; mit mk besprochen)

VERIFIZIERT  Kriterien 1, 2, 4 BESTANDEN (siehe soll-ist-abgleich.md)
OFFEN        Kriterium 3: Header hinter CDN sichtbar - braucht
             Staging-Zugang · NICHT annehmen, dass es geht

NÄCHSTER SCHRITT  Staging-Check fahren, dann Kriterium 3
                  schließen und den Prüfbericht aktualisieren

• Protokoll-Kippen. Eine Übergabe ist ein Zustands-Schnappschuss, kein Chat-Log. Ein übergroßer Dump kann Entscheidungen und Risiken verdecken, die der Empfänger prüfen muss.
• Das Modell ungeprüft schreiben lassen. Eine Session, die sich selbst zusammenfasst, erbt die eigenen blinden Flecken - als Entwurf fein, aber was offen versus fertig ist, bestätigt der Mensch.
• Die Instruktionsdatei aufblähen. Arbeitszustand in CLAUDE.md kann zu veraltetem Kontext werden, den eine künftige Session für aktuell hält. Flüchtigen Stand getrennt halten.
• Übergabe ohne Verifikationsstatus. „Wo ich aufgehört habe“ ohne „was ungeprüft ist“ übergibt die Arbeit, aber nicht das Risiko - die nächste Session braucht beides.
• Veralteter, partieller oder widersprüchlicher Stand. Schnappschuss datieren, Quellrevision nennen und Konflikte zeigen. Repo, aktueller Run und frische Checks stehen über einer Übergabe, die nicht mehr mit ihnen übereinstimmt.
• Transfer mit Freigabe verwechseln. Belege und offene Risiken wechseln die Session; menschliche Annahme-, Release- und Eskalationsentscheidungen entstehen nicht allein dadurch, dass die Datei gelesen wurde.

Reality Graph kann eine Übergabe aus deklariertem Auftragszustand, Grenzen, Prüfergebnissen und offenen Punkten im strukturierten Auftrag und seinem Prüfbericht zusammenstellen. Offene Punkte, die eine Session überdauern, lassen sich zusätzlich als Ticket führen, an dem der nächste Run ansetzt, damit die Arbeit nicht nur in einer einzigen Datei hängt. Diese Aufzeichnungen können in eurer Umgebung gespeichert und als Teil des Verifikations-Loopgeprüft werden. Sie bleiben Behauptungen und Belege mit Zeitstempeln und Grenzen; Kontinuität, Vollständigkeit, Wiederherstellung, korrekte Interpretation oder Operator-Freigabe garantieren sie nicht.