tderoussel/session-log

Sitzungsprotokoll

Schreibt eine dauerhafte Aufzeichnung einer Arbeitssitzung. Diese Protokolle werden von allen, die sie später lesen, als Grundwahrheit behandelt – auch von dir, sechs Wochen später, ohne jeglichen Kontext. Genauigkeit zählt mehr als Glanz.

Wann dies ausgeführt werden soll

• Ein Build, eine Fehlerbehebung, ein Audit oder eine Recherchewelle ist gerade abgeschlossen
• Eine Sitzung endet und es gibt Zustände, die die nächste benötigen würde
• Etwas wurde auf den Grund gegangen und der Mechanismus ist es wert, festgehalten zu werden

Führe es nicht für triviale Arbeiten aus. Eine einzeilige Korrektur braucht kein Protokoll.

Wo es abgelegt wird

Dort, wo das Projekt seine Sitzungsaufzeichnungen führt – ein docs/sessions/-Verzeichnis, ein Notiz-Vault, ein Wiki. Frage einmal nach, wenn es nicht offensichtlich ist, und bleibe dann konsistent.

Ein Dateiname, der das Datum und eine kurze Beschreibung enthält, sortiert und scannt gut: YYYY-MM-DD Kurzbeschreibung.md.

Schritte

1. Sammle die Fakten vor dem Schreiben

Schreibe nicht allein aus dem Gedächtnis des Gesprächs. Sammle:

• PR-Nummern, Commit-SHAs, Migrations-Zeitstempel, Deploy-IDs
• Was tatsächlich verifiziert wurde und mit welchem Befehl
• Was fehlgeschlagen ist und was noch offen ist
• Alles, was nur ein Mensch tun kann

Wenn eine Tatsache nicht bestätigt werden kann, markiere sie als unbestätigt, anstatt sie wegzulassen oder zu behaupten.

2. Schreibe den Hauptteil

# YYYY-MM-DD — <was auf den Grund gegangen oder ausgeliefert wurde>

<Eine Zeile, die benennt, wie die Arbeit durchgeführt wurde: wer plante, wer baute, wer prüfte.>

## Was passiert ist

- Mechanismen zuerst. Warum es passiert ist, nicht nur was.
- Konkrete Beweise: PR-Nummern, SHAs, Zeitstempel, Zeilenanzahlen, Logzeilen.
- Unterscheide ausdrücklich zwischen belegtem und gefolgertem.

## Fehlerbehebung

1. Nummerierte Schritte. Jeder gibt an, was verifiziert wurde und wie.

## Geltende DO-NOT-Regeln
<Nur wenn die Sitzung Verbote hervorgebracht hat. Begründe jedes mit dem Vorfall, der es verursacht hat.>

## Verbleibende Punkte – benötigt einen Menschen

- [ ] Dinge, die nur sie tun können

Links: <zugehörige Dokumente>

Wenn das Notizsystem Frontmatter verwendet, füge ein outcome-Feld hinzu: ein vollständiger Satz, der angibt, was jetzt wahr ist, was vorher nicht wahr war. Es ist die meistgelesene Zeile der Datei. Mach daraus eine echte Behauptung, kein Etikett.

3. Die beiden Abschnitte, die jeder weglässt

## Verbleibende Punkte und der Links-Fußnote sind erforderlich. Sie sind die beiden Abschnitte, die Wert nach vorne tragen, und werden am häufigsten weggelassen – in einem Vault, gemessen an 230 bestehenden Protokollen, kamen sie nur in etwa 21 % bzw. 28 % vor.

Schreibe beide, jedes Mal. Wenn nichts wirklich für einen Menschen aufgehoben ist, schreibe Keine – es wird nichts aufgehoben., anstatt die Überschrift zu löschen.

4. Markiere jede Behauptung

Kennzeichne jede als VERIFIED (wie) oder ASSUMED (warum nicht geprüft) inline. Vermenge sie nicht.

„Verifiziert“ sollte bedeuten, dass ein Mensch oder ein Befehl es tatsächlich bestätigt hat. Eine Behauptung über die Produktion erfordert eine Abfrage gegen die Produktion – kein erfolgreicher Test, kein gemergter PR, kein grüner Deploy.

5. Überprüfe jeden Link vor dem Speichern

Prüfe jedes Linkziel gegen eine echte Datei, bevor du es schreibst. Ein Notizsystem sammelt schnell kaputte Verweise an, und ein Protokoll voller toter Links ist ein Protokoll, dem niemand vertraut.

6. Aktualisiere den Projektzustand

Wenn die Arbeit den Status eines Projekts geändert hat, füge einen datierten Statusabschnitt zum Hauptdokument dieses Projekts hinzu – neuestes zuerst, voranstellen, niemals Geschichte überschreiben.

Wenn die Arbeit ein Programm mit einem Übergabedokument vorangebracht hat, aktualisiere es direkt, damit die nächste Sitzung korrekt übernimmt.

7. Gib die Lehren zurück

Wenn der Benutzer während der Sitzung etwas korrigiert hat, schreibe die Lektion an einem dauerhaften Ort – eine Regeln-Datei, einen Wissensspeicher, diesen Skill selbst. So hören Korrekturen auf, sich zu wiederholen.

Hausstil

• Spezifisch und widerlegbar. Vage Zusammenfassungen sind hier schlimmer als nichts.
• Gib nie einen Status an, ohne zu sagen, wie er überprüft wurde.
• Führe mit schlechten Nachrichten. Vergrabe sie nicht.
• Schreibe für einen Leser, der keinerlei Kontext hat.

Nicht tun

• Überschreibe kein bestehendes Protokoll. Lies zuerst, dann bearbeite.
• Schreibe nicht in maschinell erzeugte Verzeichnisse.
• Erstelle keine temporären Dateien oder Build-Ausgaben neben den Notizen.