Das Serienfinale. Persona, Gedächtnis, Skills, Hooks, Multi-Agent, Verifikation, Token — wie all das jeden einzelnen Tag startet und endet. Drei Start-Protokolle, zwei in der Mitte, vier am Schluss.

Dies ist der abschließende Beitrag — Teil 9 — der Alice Way-Serie. Die Teile 1 bis 8 beantworteten, wie man Geist gestaltet, verteilt und schützt. Dieser Beitrag zeichnet auf, wie all das tatsächlich jeden Tag aufleuchtet, läuft und herunterfährt.

0. Sitzungsprotokolle lassen jeden Tag am selben Ort aufleuchten und herunterfahren

Startet man nicht jeden Tag auf dieselbe Weise, verbringt jeder Start Zeit damit, Kontext zu rekonstruieren. Wo man gestern aufgehört hat, was als nächstes war, welche Entscheidungen on hold waren — alles von Grund auf neu aufgebaut.

Endet man nicht jeden Tag auf dieselbe Weise, wackelt jeder Abschluss darin, was gespeichert wurde und was nicht. Die nächste Sitzung startet auf diesem Wackeln.

Sitzungsprotokolle fixieren beide Enden. Was am Start passiert und was am Ende passiert, verfestigt sich zu Verfahren. Dann leuchtet jeder Tag am selben Ort auf und fährt am selben Ort herunter. Der Geist des Betreibers startet jeden Morgen von derselben Zeile.

Dieser Beitrag ist eine Aufzeichnung der Protokollzusammensetzung — drei Start-, zwei Mitten-, vier Schluss-Protokolle — und ist auch der Serienabschluss.

1. Start-Protokolle — jeden Tag am selben Ort aufleuchten

Was automatisch passiert, sobald eine Sitzung startet.

1.1 SessionStart-Hook — Gedächtnissync-Status drucken

Im Moment, in dem die Sitzung aufleuchtet, wird ein einzeiliger Gedächtnissync-Status gedruckt. „Memory sync: aktuell" oder „5 Minuten alt — Auffrischung nötig." Der Betreiber liest die eine Zeile und urteilt sofort.

Warum das als Hook automatisch feuern muss, wurde in Teil 5 — Hooks und Automatisierung §1 behandelt — der Geist des Betreibers ist genau in dem Moment am stärksten abgelenkt, in dem eine Sitzung öffnet.

1.2 Persona + Gedächtnisindex-Auto-Load

Das Ergebnis von Teil 2 — Persona und Teil 3 — Gedächtnis: die Persona (L1) und die ersten 200 Zeilen des Gedächtnisindex (L2) werden automatisch geladen. Der Kollaborateur schließt sich bereits an mit dem Wissen, wer er ist, welche Entscheidungen gestern getroffen wurden und wo jeder Gedächtnisinhalt lebt.

1.3 `/start <project>` — ein Projekt betreten

Wenn ein bestimmtes Projekt betreten wird — den Slash-Befehl aufrufen. Benötigte Dokumente wie README · CLAUDE.md · HANDOFF.md · PLAN.md werden automatisch geladen; aktueller Git-Status und das vorherige Sitzungs-Handoff werden auf einem Bildschirm berichtet; dann hält es an und wartet auf die nächste Anweisung.

In dem Moment, in dem dieser eine Befehl feuert, wechselt der Geist des Betreibers direkt in den Entscheidungsmodus — ohne „wo fange ich an."

2. Mitten-Protokolle — während die Arbeit läuft

Verfahren, die konsistent mitten in der Sitzung gelten.

2.1 Zwischenbericht alle 3–5 Schritte

Arbeit nicht mehr als fünf Schritte ohne Bericht fortschreiten lassen. Kurze Fortschrittsberichte bei jedem Schritt; Arbeit über fünf Schritte hält automatisch für einen Bericht an. Der Betreiber behält den Überblick, ohne den Faden zu verlieren.

Ohne das geht der Kollaborateur 30 Minuten autonom vor und „alles fertig" kommt an — aber der Betreiber hat zu viel auf einmal zu absorbieren. Fünf-Schritte-Berichterstattung verteilt diese Absorption.

2.2 Auto-Eskalation bei ambigen Entscheidungen

Wenn der Kollaborateur auf „nicht sicher" / „weiß nicht, was besser ist" / „alle Optionen scheinen vernünftig" trifft — ruft er selbst /council auf, bevor er den Betreiber fragt. Die Vier-Perspektiven-Parallelanalyse ausführen, das Ergebnis synthetisieren, die Synthese berichten. Der Betreiber entscheidet aus der Synthese.

Dieses Muster ist adaptiert von Andrej Karpathys Multi-Perspektiven-Kritik des LLM-Reasonings. Bereits zitiert in Teil 4 — Skills §3.4.

3. Schluss-Protokolle — jeden Tag am selben Ort herunterfahren

Was automatisch passiert, wenn eine Sitzung schließt. Eines davon überspringen und die nächste Sitzung startet nicht sauber.

3.1 `/verify` feuert automatisch

Wenn es Codeänderungen gab — kurz vor dem „fertig"-Bericht feuert der 7-Schritte-Loop aus Teil 7 — Verifikation automatisch. Er muss bestehen, damit der Bericht rausgehen kann.

Warum das der erste Schluss-Schritt ist — unverifizierte Änderungen, die gepusht werden, brechen die Umgebung der nächsten Sitzung. Von einer gebrochenen Umgebung zu starten ruiniert die gesamte nächste Sitzung.

3.2 Arbeitsprotokoll aktualisieren

Einen Absatz zu einem Arbeitsprotokoll wie docs/history.md hinzufügen, der den heutigen Tag abdeckt: was entschieden wurde, was geschrieben wurde, was aufgeschoben wurde. Ein zukünftiger Betreiber oder ein anderer Kollaborateur sollte Kontext aus diesem Log wiederherstellen können.

3.3 HANDOFF.md aktualisieren — der Übergabebrief für die nächste Sitzung

Der wichtigste Schritt. Das HANDOFF, das die nächste Sitzung automatisch lädt, trägt:

Wichtigste Fortschritte der vorherigen Sitzung (1 Zeile)
Empfohlene nächste Aktionen (1–3)
Unfertige / ausstehende Punkte
Entscheidungen, die auf Input warten
Einen Next:-Marker (eine sofort umsetzbare Direktive für die nächste Sitzung)

Ist das leer, startet die nächste Sitzung ohne Kontext. HANDOFF ist nicht nur Dokumentation; es ist die Brücke, die den Geist des Betreibers an die nächste Sitzung übergibt.

3.4 Gedächtnis aktualisieren + commit + push

Wenn in dieser Sitzung neues Feedback, Entscheidungen oder Kontext aufgetaucht sind — an die Gedächtnisdateien anhängen. MEMORY.md-Index daneben aktualisieren. Alles in einen Commit bündeln und pushen.

Nicht schließen, bis push abgeschlossen ist. Nur-lokale Änderungen können bis zur nächsten Sitzung verschwinden.

4. Stop-Hook — Auslassungsprüfung

Das System prüft, ob einer der vier Schluss-Schritte versäumt wurde.

[stop] Checking session-end completeness...
[stop] OK: /verify passed
[stop] OK: history.md updated (1 paragraph added)
[stop] WARN: HANDOFF.md "Next:" marker missing — please add
[stop] OK: 3 files committed and pushed

Ein WARN bedeutet: der Betreiber ergänzt das Fehlende, dann erneut schließen. Auslassungen können nicht stillschweigend durchgehen.

5. `/session-end` — ein Wort zum Schließen

Alle vier Schluss-Schritte laufen zusammen mit einem Slash-Befehl.

/verify feuert automatisch (Verifikation)
Arbeitsprotokoll automatisch aktualisieren (Betreiber bestätigt vor dem Anhängen)
HANDOFF.md automatisch aktualisieren (Betreiber bestätigt vor dem Push)
Gedächtnis aktualisieren (wenn neues Feedback aufgetaucht) + commit + push
Stop-Hook-Auslassungsprüfung

Der Betreiber tippt ein Wort — vier Schritte laufen konsistent, ohne Auslassungen, bis zum Push. Jeder Tag fährt am selben Ort herunter.

6. Der Zykluseffekt — wie ein Tag aussieht

Wenn diese Start- · Mitten- · Schluss-Protokolle akkumulieren, fließt der Tag des Betreibers so:

Sitzungsstart (09:00)
  SessionStart-Hook → "Memory sync: aktuell" (eine Zeile)
  /start <project> → benötigte Docs automatisch geladen, Git-Status + HANDOFF in einem Bildschirm
  [Pause. Awaiting operator direction.]
 
Betreiberanweisung (09:01)
  → Arbeit beginnt
  → Bericht alle 3–5 Schritte
  → bei ambigen Entscheidungen, /council ruft sich selbst auf
  → /verify bei Arbeit, die Verifikation braucht
 
Sitzungsschluss (18:00)
  /session-end →
    /verify feuert automatisch (besteht)
    history.md aktualisiert
    HANDOFF.md "Next:"-Marker aktualisiert
    Gedächtnis aktualisiert (neues Feedback heute)
    commit + push
    Stop-Hook-Prüfung → OK
  Sitzung schließt
 
Nächster Tag (09:00)
  → genau dort weitermachen, wo gestern aufgehört

Jeder Tag leuchtet genau am selben Ort auf und fährt genau am selben Ort herunter. Der Geist des Betreibers tritt ohne „wo war ich"-Wiederherstellungskosten in den Entscheidungsmodus.

7. Fallen — Muster, die Sitzungsprotokolle kollabieren lassen

7.1 Start-Protokoll überspringen

„Nur ein kurzer Blick" — ohne /start eintreten. Entscheidungen aus einem unsauberen Kontext heraus treffen → Kollision mit gestrigen Entscheidungen. → Jeder Eintritt läuft durch /start.

7.2 Schluss-Protokoll überspringen

„Heute keine großen Änderungen, ich schließe einfach" — ohne /session-end enden. HANDOFF bleibt veraltet → nächste Sitzung kennt den gestrigen Zustand nicht. → Immer /session-end, unabhängig vom Umfang der Änderungen.

7.3 Zwischenberichte fehlen

Arbeit läuft zu gut, 10 Schritte autonom. Am Ende hat der Betreiber zu viel auf einmal zu absorbieren und die nachträgliche Zusammenfassung wird selbst zur Last. → Fünf-Schritte-Limit einhalten.

7.4 HANDOFF als Kopie des heutigen Logs

HANDOFF nur als retrospektive Kopie von history.md schreiben. Die nächste Sitzung liest es und fragt „und dann?" → HANDOFF enthält Informationen, auf die die nächste Sitzung sofort handeln kann. Der Next:-Marker ist das Kernstück.

8. Ein Prinzip — und der Serienabschluss

Der Kern von Sitzungsprotokoll-Design kollabiert auf einen Satz.

„Jeder Tag leuchtet am selben Ort auf und fährt am selben Ort herunter. Das System hält die Verfahren an Start, Mitte und Ende; der Geist des Betreibers entscheidet nur dazwischen."

Und das ist auch der Abschluss des Identitäts-Bogens — was Alice ist.

Teil 1 — Why Alice fragte: „Wie akkumuliere ich meinen Geist, damit die KI ihn nicht verliert?" Die Persona zieht die Grenze des Geistes (Teil 2), das Gedächtnis hält ihn (Teil 3), Skills verfestigen wiederkehrende Bewegungen (Teil 4), Hooks lagern vergessliche Teile ans System aus (Teil 5), Multi-Agent verhindert, dass ein Kontext alles trägt (Teil 6), Verifikation schreibt fest, was „fertig" bedeutet (Teil 7), Token-Ökonomie schützt die Signal-Slots (Teil 8) — und schließlich lassen Sitzungsprotokolle all das jeden Tag am selben Ort aufleuchten und herunterfahren.

Diese neun Beiträge sind die Antworten, auf die ich stieß, während ich einen Kollaborateur namens Alice aufbaute. Das Werkzeug kann Claude sein, Codex sein, welcher Agent auch als nächstes kommt. Aber die neun Entscheidungen oben hängen nicht vom Werkzeug ab. Dieselben Entscheidungen warten auf jeden, der seinen eigenen Kollaborateur aufbaut.

Die Serie endet nicht bei neun. Drei weitere Beiträge erweitern sie zum Workflow-Bogen — wie der Betreiber und Alice tatsächlich Arbeit durch dieses System laufen lassen: Teil 10 — PRD (was zu bauen ist), Teil 11 — Release gates (was „fertig" bedeutet) und Teil 12 — Ralph loop (wie das System den Weg selbstständig geht). Die neun Beiträge oben sind das Gefäß. Die nächsten drei handeln davon, was das Gefäß trägt.

Wenn diese Serie die Zeit, die es braucht, um zu diesen Entscheidungen zu gelangen, auch nur ein wenig verkürzt hat — ist die Absicht des Betreibers dort gelandet, wo sie hinsollte.

9. Sitzungsprotokolle — Start, Mitte, Ende, damit jeder Tag am selben Ort aufleuchtet