Operator Core

Ein Operator 'nutzt' KI nicht über eine Website: Er bedient sie von seiner eigenen Maschine aus, mit Zugriff auf seine Dateien, sein git und sein Terminal. Genau das ist Claude Code. Bevor du es installierst, brauchst du drei Fundamente: ein Terminal, in dem du Befehle ausführst, einen Editor (VS Code), in dem du Code siehst und bearbeitest, und einen Paketmanager, um Werkzeuge zu installieren. Auf macOS ist das Terminal Terminal.app oder iTerm2; auf Windows nimm WSL2 (Ubuntu), weil Claude Code und die meisten Werkzeuge eine Unix-artige Umgebung voraussetzen. Versuch nicht, von reinem PowerShell aus zu arbeiten: Das kostet dich doppelt so viel.

Schau zuerst nach, was du schon hast. Öffne das Terminal und führe `node --version` und `git --version` aus. Wenn `node` nicht existiert oder älter als v18 ist, installier Node LTS. Auf macOS ist Homebrew der saubere Weg: `/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"` und danach `brew install node git`. Nach der Homebrew-Installation druckt dir der Installer ZWEI Zeilen `eval "$(/opt/homebrew/bin/brew shellenv)"` aus, die du in dein `~/.zprofile` einfügen musst — wenn du sie überspringst, 'verschwindet' `brew`, sobald du ein neues Terminal öffnest. Das ist der erste PATH-Fehler, dem du begegnen wirst, und du solltest ihn verstehen: Der PATH ist die Liste der Ordner, in denen die Shell nach Befehlen sucht; liegt das Werkzeug in keinem davon, sagt die Shell `command not found`, obwohl die Datei auf der Festplatte existiert.

Installier Claude Code mit `npm install -g @anthropic-ai/claude-code` und überprüf es mit `claude --version`. Wenn npm sich über Berechtigungen beschwert (`EACCES`), nimm NICHT `sudo npm` — das hinterlässt dir root-Dateien, die du später nicht mehr löschen kannst. Die richtige Lösung ist, npm auf ein Präfix in deinem Home-Verzeichnis zeigen zu lassen: `npm config set prefix ~/.npm-global` und `export PATH=~/.npm-global/bin:$PATH` in dein `~/.zshrc` eintragen. Lad es neu mit `source ~/.zshrc`. Jetzt startet `claude` und fordert dich auf, dich mit deinem Anthropic-Konto über den Browser zu authentifizieren; dieses Token wird gespeichert, und du musst es nie wieder eingeben.

VS Code ist dein Fenster zum Code, während Claude Code deine Hände sind. Installier es von code.visualstudio.com und öffne darin die Befehlspalette (Cmd+Shift+P) → 'Shell Command: Install code command in PATH'. Das gibt dir den Befehl `code .`, um den aktuellen Ordner aus dem Terminal heraus in VS Code zu öffnen — die Geste, die du hundertmal am Tag machen wirst. Installier mindestens diese Erweiterungen: die offizielle für deine Sprache, GitLens und einen Formatter wie Prettier. Bläh den Editor nicht mit 40 Erweiterungen auf; jede ist Angriffsfläche und Lärm.

Der reale Arbeitsablauf ist immer derselbe, und du verinnerlichst ihn in diesem Modul. Du öffnest ein Terminal, navigierst mit `cd ~/mein-projekt` in dein Projekt, tippst `claude`, um die Sitzung zu starten, und in einem anderen Tab (oder geteilten Panel von VS Code) hast du den Editor offen mit `code .`. Claude Code schlägt Änderungen vor, du prüfst sie im Editor oder mit `git diff`, und du nimmst sie an. Terminal und Editor konkurrieren nicht: Im Terminal passiert die Aktion, im Editor verifizierst du. In MOONKEY LAB sieht eine typische Sitzung zum Beispiel so aus: `cd ~/xop && claude`, und du bittest es, eine Astro-Komponente anzufassen, während du die Datei in VS Code anschaust.

Verifizier die gesamte Umgebung mit einer Feuerprobe, bevor du das Modul für abgeschlossen erklärst. Erstell einen Ordner `mkdir ~/lab-01 && cd ~/lab-01`, initialisier git mit `git init`, starte `claude` und bitte es, eine `hola.txt` mit deinem Namen zu erstellen. Verlass Claude, führ `cat hola.txt` aus, um zu bestätigen, dass die Datei auf der Festplatte existiert, und `code .`, um sie im Editor zu sehen. Wenn die vier Schritte funktionieren (Terminal navigiert, claude startet und schreibt, die Datei erscheint, VS Code öffnet sie), ist deine Umgebung einsatzbereit. Notier dir in einer persönlichen Notiz die exakten Versionen, die du installiert hast: Wenn in einem Monat etwas kaputtgeht, erspart dir diese Notiz einen ganzen Nachmittag.

CLAUDE.md ist eine Textdatei im Wurzelverzeichnis deines Projekts, die Claude Code beim Start jeder Sitzung automatisch liest. Es ist keine Dokumentation für Menschen (auch wenn sie das nebenbei leistet): Es ist der Kontext, den die KI lädt, bevor sie irgendetwas tut. Wenn deine `package.json` React sagt, du aber Astro benutzt, oder wenn du eine Regel hast wie 'füge nie Abhängigkeiten hinzu, ohne sie zu begründen', dann lebt das in dieser Datei. Die KI errät dein Urteilsvermögen nicht; du schreibst es ihr einmal auf, und sie nutzt es für immer wieder.

Der Anfängerfehler ist, eine generische CLAUDE.md zu schreiben ('das ist ein Webprojekt, nutze Best Practices'). Das bringt nichts, weil die KI Best Practices ohnehin annimmt. Der Wert liegt im SPEZIFISCHEN und NICHT-OFFENSICHTLICHEN: welchen Stack du WIRKLICH nutzt (nicht den, der so aussieht), welche Tabellen deiner Datenbank zu einem anderen Projekt gehören und nicht angefasst werden dürfen, welchem i18n-Muster du folgst, was übersetzt wird und was nicht. Schau dir die echte CLAUDE.md von MOONKEY LAB an: Sie hat einen Abschnitt '⚠️ Die Supabase-DB ist GETEILT mit XHUB IRON', der die verbotenen Tabellen (`iron_*`, `world_*`) und die erlaubten (`profiles, progress, feedback, leads, proofs`) auflistet. Diese eine Zeile verhindert, dass die KI Daten eines anderen Produkts löscht. Das ist die Art von Wissen, die nur du hast und die diese Datei festhält.

Strukturier eine wirksame CLAUDE.md in klare Abschnitte mit Markdown-Überschriften. Die, die zählen: (1) Vision — ein Satz, was das Projekt ist. (2) Realer Stack — exakte Versionen und Werkzeuge, mit Markierung dort, wo die Realität vom Anschein abweicht. (3) Sicherheits- oder Datenmodell — wer was anfassen darf. (4) Konventionen — Benennungen, Ordnerstruktur, Typografie, was auch immer Regeln hat. (5) Ton — wie der Text klingen soll, den sie generiert. (6) Kostenregeln — was NICHT zu tun ist. In MOONKEY sagt dieser letzte Abschnitt wörtlich 'Keine Abhängigkeiten ohne Begründung hinzufügen. Kein JS, wo HTML/CSS reicht.' — konkrete Verbote, keine vagen Ratschläge.

Die goldene Regel lautet: Jede Zeile von CLAUDE.md muss eine Entscheidung verändern. Wenn ein Satz nicht ändert, was die KI standardmässig täte, streich ihn. 'Schreib sauberen Code' ändert nichts. 'Hrefs müssen locale-aware sein: nutze localizedPath(/pfad, locale), niemals rohes /pfad (bricht unter Sprachpräfix)' ändert jeden Link, den sie generiert. Das Zweite ist Gold; das Erste ist Füllmaterial. Eine CLAUDE.md mit 80 dichten Zeilen ist mehr wert als eine mit 300 Zeilen Selbstverständlichkeiten, und sie verbraucht in jeder Sitzung weniger Kontext.

CLAUDE.md ist ein lebendes Dokument, kein Gründungsakt. Jedes Mal, wenn die KI etwas systematisch falsch macht — eine Abhängigkeit hinzufügt, die du nicht wolltest, das falsche i18n-Muster benutzt, einen Markenbegriff übersetzt, der nicht übersetzt wird — ist das ein Versagen der Datei, nicht der KI. Geh zurück und füge die Regel hinzu. Mit der Zeit wird die Datei zum Destillat all deiner Korrekturen. In der Praxis endet eine gute Sitzung mit 'füg das zu CLAUDE.md hinzu, damit es nicht nochmal passiert'. Halte ausserdem die Dinge deiner Maschine und persönliche Vorlieben aus der CLAUDE.md des Repos heraus (das gehört in den User-Speicher oder in eine nicht versionierte CLAUDE.local.md): Die des Repos teilt sich das Team.

Um sie zu schreiben, fang nicht mit einer leeren Vorlage an. Führ `claude` in deinem Projekt aus und bitte es: 'Geh die Struktur des Repos durch, lies package.json und die Config-Dateien, und schlag einen Entwurf einer CLAUDE.md vor, der den realen Stack und die Konventionen festhält, die du erkennst.' Die KI ist hervorragend darin, deinen eigenen Code zu lesen und zusammenzufassen. Dann korrigierst DU: Du fügst die Verbote hinzu, die sie nicht wissen kann (die Tabellen eines anderen Projekts, die Begriffe, die nicht übersetzt werden, die Geschäftsentscheidungen), und löschst das Generische. Dieser Zyklus — die KI schlägt aus dem Code vor, du injizierst das Wissen, das nur in deinem Kopf ist — produziert in zwanzig Minuten eine ehrliche Datei.

Ein Prompt ist keine Frage: Er ist eine Arbeitsanweisung. Wenn du einen kompetenten Kollegen bittest, etwas zu tun, sagst du nicht 'reparier das Login'; du sagst 'der Magic-Link von Supabase leitet nach der Authentifizierung nicht weiter, schau dir den Callback in src/lib/supabase.ts an, das Problem ist wahrscheinlich die Redirect-URL in der Config'. Du gibst ihm implizite Rolle, Kontext, Fokus und eine Hypothese. Ein guter Prompt macht dasselbe explizit. Die vier Säulen sind: ROLLE (wer die KI sein soll: 'du bist ein Postgres-Ingenieur, der RLS prüft'), KONTEXT (was sie wissen muss: den Stack, die Datei, die Einschränkung), STRUKTUR (wie du die Ausgabe willst: 'gib nur das SQL zurück, ohne Erklärung' oder 'liste 3 Optionen mit Trade-offs') und ABSICHT (das wahre Ziel hinter der Anfrage, nicht nur der Schritt).

Die ROLLE ist kein Theater: Sie ändert, welches Wissen die KI aktiviert und welchen Massstab sie anlegt. 'Prüf diesen Code' produziert eine weiche Prüfung. 'Du bist ein adversarialer Sicherheitsauditor: Deine Aufgabe ist es, die Behauptung zu widerlegen, dass diese RLS sicher ist, such den Eskalationspfad' produziert eine völlig andere Analyse, weil du ihr eine Haltung gegeben hast. In XCAP tragen die Research-Prompts die Rolle eines 'Analysten, der sich selbst nicht belügt', gerade weil der Standard-Bias eines Modells ist, gefällig zu sein; die Rolle wirkt dem entgegen.

Die STRUKTUR der Ausgabe spart dir am meisten Zeit und wird am meisten vergessen. Wenn du das Format nicht angibst, wählt die KI eines, und meist ist es lange Prosa, die du zusammenkürzen musst. Sag genau, was du willst: 'Gib einen einzigen SQL-Block zum Einfügen zurück, ohne Kommentare oder Erklärung.' Oder 'Antworte mit einer Tabelle mit drei Spalten: Option, Vorteil, Risiko.' Oder 'Gib mir den Diff, nicht die ganze Datei.' In MOONKEY, wo der Ton 'klar, direkt, ohne Rauch und Emojis' ist, enthält ein Prompt zur Copy-Generierung genau diese Format-Einschränkung wörtlich, denn sonst packt die KI Verzierungen hinein, die du danach von Hand löschst.

Die ABSICHT ist das Warum, und sie schaltet Lösungen frei, nach denen du nicht gefragt hast. Wenn du sagst 'füg dieser Spalte einen Index hinzu', fügt die KI ihn hinzu. Wenn du sagst 'diese Query braucht 2 Sekunden auf der Konto-Seite, und ich will sie unter 200ms bringen; der Index ist meine erste Idee, aber sei offen für Alternativen', sagt sie dir vielleicht, dass das eigentliche Problem ein N+1 ist und der Index nicht hilft. Wenn du die Absicht nennst, kann die KI deine vorgeschlagene Lösung hinterfragen und eine bessere anbieten. Wenn du nur den Befehl gibst, führt sie blind aus.

Ein Arsenal ist eine versionierte Sammlung dieser Prompts, nach Aufgabe organisiert, die du wiederverwendest. Fang nicht jedes Mal bei null an: Hab einen Prompt für 'RLS-Sicherheitsaudit', einen für 'generier Copy in der Stimme der Marke', einen für 'refaktorier diese Komponente unter Erhalt des Verhaltens', einen für 'schreib die Commit-Nachricht aus dem Diff'. Speicher sie in einer Datei `prompts.md` in deinem Projekt oder in einer Notiz. MOONKEY LAB hat eine ganze Seite, `/prompts`, dafür reserviert, denn ein Arsenal ist ein Vermögenswert: Jeder verfeinerte Prompt ist Arbeit, die du nicht wiederholst. Parametrisier die Prompts mit Platzhaltern `[DATEI]`, `[EINSCHRÄNKUNG]`, die du beim Benutzen ausfüllst.

Iterier den Prompt, nicht die Ausgabe. Wenn ein Ergebnis schlecht ausfällt, ist der Reflex des Anfängers, die Antwort von Hand zu korrigieren. Der Reflex des Operators ist, sich zu fragen 'was hat dem Prompt gefehlt zu wissen' und den Prompt zu reparieren. Wenn die KI Tabs benutzt hat und du Leerzeichen willst, bearbeite nicht die Datei: Füg 'Einrückung mit 2 Leerzeichen' zum Prompt hinzu und speicher ihn für immer so. Jede Korrektur, die du in die Vorlage steckst, ist eine Korrektur, die du nicht wieder machst. Mit der Zeit werden deine Arsenal-Prompts chirurgisch präzise, und die Ergebnisse stimmen beim ersten Mal — was das Ziel ist: aufhören zu iterieren.

Git löst ein einziges Problem, aber das wichtigste: zu jedem früheren Zustand deines Projekts zurückkehren zu können. Jedes Mal, wenn du einen `commit` machst, frierst du eine Momentaufnahme des Projekts ein, zu der du immer zurückkehren kannst. Das ändert deine Arbeitspsychologie: Wenn du weisst, dass der letzte gute Zustand gespeichert ist, lässt du die KI aggressive Änderungen machen, ohne Angst, denn das Schlimmste, was passiert, ist `git restore` und du gehst zurück. Ein Operator ohne Git arbeitet mit Angst; mit Git arbeitet er schnell. Der minimale Ablauf ist: `git status`, um zu sehen, was sich geändert hat, `git add -p`, um Änderungen Stück für Stück zu prüfen und auszuwählen, `git commit -m 'nachricht'`, um einzufrieren, und `git log --oneline`, um deine Geschichte zu sehen.

Der tägliche Zyklus ist sehen-prüfen-einfrieren. Nach einer Claude-Code-Sitzung vertrau NIEMALS darauf, dass die Änderung korrekt ist: Führ `git diff` aus und lies genau, was sie angefasst hat. Hier entdeckst du, ob die KI etwas geändert hat, das sie nicht sollte, versehentlich eine Zeile gelöscht oder eine Abhängigkeit hinzugefügt hat. `git diff` ist dein Prüfwerkzeug Nummer eins, und du benutzt es in jeder Sitzung. Erst wenn der Diff dich überzeugt, machst du `git add` und `git commit`. Diese Gewohnheit — den Diff lesen, bevor du annimmst — ist das, was einen Operator von jemandem unterscheidet, der blind kopiert und einfügt.

Commits sollten atomar sein: ein Commit, eine logische Änderung, mit einer Nachricht, die das WARUM erklärt, nicht das Was. 'Login repariert' ist schlecht (was war damit?). 'Magic-Link-Redirect korrigiert: Die Callback-URL enthielt das Locale nicht und brach unter /en/' ist gut: In sechs Monaten sagt dir diese Nachricht, warum du diese Datei angefasst hast. Claude Code ist hervorragend darin, Commit-Nachrichten aus dem Diff zu schreiben — bitte es 'schreib eine Commit-Nachricht für diese Änderungen, die das Warum erklärt', und meist trifft es ins Schwarze. Aber prüf nach: Manchmal beschreibt es das Was, und du musst nach dem Warum fragen.

Branches sind Paralleluniversen zum Experimentieren, ohne das anzufassen, was funktioniert. Der Hauptbranch (`main`) ist deine stabile Version. Wenn du etwas Riskantes probieren willst — eine grosse Refaktorisierung, ein neues Feature — erstellst du mit `git checkout -b mein-experiment` einen Branch, arbeitest dort, und wenn es gut läuft, mergst du ihn; wenn es schiefgeht, löschst du ihn, und `main` merkt nichts. Praktische Operator-Regel: Arbeite für nicht-triviale Änderungen nie direkt auf `main`. Erstell einen Branch. In MOONKEY LAB geht jede Sicherheits- oder RLS-Änderung in ihren eigenen Branch und wird erst gemergt, wenn `get_advisors` grünes Licht gibt.

GitHub ist Git in der Cloud: deine Remote-Sicherung und der Ort, von dem dein Projekt deployt wird. Du verbindest dein lokales Repo mit `git remote add origin git@github.com:user/repo.git` und lädst hoch mit `git push`. Ab da bewahrt `git push` nach jeder guten Sitzung deine Arbeit ausserhalb deiner Maschine auf — wenn deine Festplatte stirbt, lebt dein Projekt weiter. Ausserdem beobachten Plattformen wie Cloudflare Pages (das MOONKEY LAB aus `garciafradepablo-pixel/xop` deployt) dein GitHub-Repo und veröffentlichen automatisch jeden Push auf `main`. So ist Git nicht nur Versionierung: Es ist der Motor deines Deploys, den du im nächsten Modul siehst. Um vom Terminal aus mit GitHub zu reden, installier das CLI `gh` und authentifizier dich mit `gh auth login`.

Eine `.gitignore` ist genauso wichtig wie die Commits: Sie listet die Dateien auf, die Git IGNORIEREN soll. Hier kommen `node_modules/` rein (wird aus package.json neu installiert, nicht versioniert), `.env`-Dateien (Geheimnisse — lade NIEMALS Schlüssel zu GitHub hoch) und Build-Artefakte. Eine `.env` mit einem Schlüssel in ein öffentliches Repo hochzuladen ist einer der häufigsten Sicherheitsvorfälle der Welt, und ist der Schlüssel einmal hochgeladen, bleibt er, auch wenn du den Commit löschst, in der Historie: Man muss ihn rotieren. Deshalb wird die `.gitignore` VOR dem ersten Commit konfiguriert. Bitte Claude Code 'generier eine .gitignore für ein Astro-Projekt mit Supabase' und prüf, dass sie `.env` und `node_modules` enthält.

Automatisierung fängt im Kleinen an: Ein Befehl, den du wiederholst, wird zu einem Skript. Wenn du jedes Mal am Ende `npm run build && git add -A && git commit -m wip && git push` schreibst, ist das ein vierzeiliges Skript `deploy.sh`, das du mit `./deploy.sh` ausführst. Das Prinzip ist: Was du mehr als dreimal machst, speicherst du. Bitte Claude Code 'erstell ein Bash-Skript, das Build, Commit mit Timestamp und Push macht und abbricht, wenn der Build fehlschlägt' — das `&&` zwischen den Befehlen garantiert bereits, dass die folgenden nicht laufen, wenn einer fehlschlägt, was genau das ist, was du bei einem Deploy willst.

Der moderne Deploy einer statischen Website ist fast gratis aufzusetzen und heisst Continuous Deployment. Plattformen wie Cloudflare Pages beobachten dein GitHub-Repo: Jedes Mal, wenn du `git push` auf `main` machst, klonen sie dein Repo, führen deinen Build-Befehl (`npm run build` für Astro) aus und veröffentlichen das Ergebnis unter einer echten URL. MOONKEY LAB funktioniert genau so: `git push` auf das Repo `garciafradepablo-pixel/xop`, und ein paar Sekunden später sind die Änderungen auf `moonkeylab.pages.dev`. Du lädst keine Dateien per FTP hoch, du fasst keinen Server an: Deine einzige Deploy-Geste ist `git push`. Das verbindet das Git-Modul mit diesem: Git versioniert nicht nur, es ist der Auslöser des Deploys.

Continuous Deployment zu konfigurieren ist ein einmaliger Vorgang. Du verbindest dein Cloudflare-Konto (oder Vercel oder Netlify) mit GitHub, wählst das Repo und deklarierst zwei Dinge: den Build-Befehl (`npm run build`) und den Ausgabeordner (`dist` bei Astro). Cloudflare speichert diese Config, und ab da löst jeder Push einen Build aus. Wenn der Build fehlschlägt, veröffentlicht es NICHT — deine vorherige Website bleibt am Leben. Das ist eine enorme Sicherheitseigenschaft: Ein kaputter Commit reisst deine Website nicht herunter, er wird einfach nicht deployt, und du wirst benachrichtigt. Du siehst das Build-Log im Cloudflare-Panel; wenn beim Deploy etwas fehlschlägt, aber lokal funktioniert, ist dieses Log das Erste, was du liest.

Umgebungsvariablen sind die Brücke zwischen deinem Deploy und deinen Geheimnissen, und hier kreuzt es sich mit der Sicherheit. Dein Code braucht die Supabase-URL und den Anon Key, aber die werden NICHT im Repo hartcodiert (das hast du im Git-Modul gesehen). Lokal leben sie in einer `.env`; beim Deploy trägst du sie im Cloudflare-Panel als Umgebungsvariablen ein, und die Plattform injiziert sie in den Build. Kritische Unterscheidung, die du in Ops & Security gründlich lernst: Der Anon Key von Supabase DARF im Client leben (er ist durch RLS geschützt), ein Service-Role Key NIEMALS — der würde vollen Zugriff geben und die gesamte Sicherheit umgehen. Zu wissen, welcher Schlüssel wohin gehört, ist Operator-Kompetenz.

Die nächste Stufe ist, wiederkehrende Aufgaben zu automatisieren, die nicht von einem Push abhängen: Dinge, die nach einem Zeitplan laufen sollen. Das sind geplante Aufgaben (Cron). In XCAP zum Beispiel gibt es 'Autopilot-Ticks' — Schleifen, die periodisch laufen, um Marktdaten aufzunehmen und das Ledger von Market Memory zu aktualisieren, ohne dass jemand einen Knopf drückt. Die allgemeine Idee: Du definierst einen Befehl und einen Zeitplan ('jeden Tag um 6:00', 'alle 15 Minuten'), und die Plattform führt ihn von selbst aus. Bei einer statischen Website lebt das meist in serverlosen Funktionen (Cloudflare Workers) oder in Cron Jobs. Der Operator-Schlüssel ist, dass die Schleife ehrlich und idempotent ist: dass zweimaliges Laufen keine Daten verdoppelt und dass sie Lernen anhäuft statt Rauschen — genau die Disziplin des 'Capital Invariant' von XCAP, wo sich der Zustand nur bei echten Ereignissen ändert, nicht bei jedem Tick.

Automatisieren ohne Beobachtbarkeit ist gefährlich: Ein System, das von selbst läuft und still fehlschlägt, ist schlimmer als ein manuelles. Für jede Automatisierung brauchst du eine Möglichkeit, zu wissen, ob sie funktioniert hat. Der Cloudflare-Build schickt dir eine E-Mail, wenn er fehlschlägt. Eine Cron-Aufgabe muss ihr Ergebnis irgendwo loggen, wo du nachschaust. Die Regel: Automatisier nie etwas, das du danach nicht verifizieren kannst. Fang immer mit einer Version an, die läuft und dich benachrichtigt, und erst wenn du ihr vertraust, lässt du sie wirklich allein laufen. Ein automatischer Deploy, ohne beim ersten Mal das Log zu prüfen, ist, wie man eine kaputte Website in die Produktion veröffentlicht, ohne es zu merken.

Der grundlegende Unterschied ist keiner des Modells, sondern des Paradigmas. ChatGPT ist eine Unterhaltung: Du schreibst, die KI antwortet mit Text, und du kopierst diesen Text von Hand in dein Projekt. Der Kontext lebt im Thread, und wenn der Thread zu gross wird oder du ihn schliesst, verdampft dieser Kontext. Claude Code ist ein Operator: Es lebt in deinem Terminal, liest und schreibt deine Dateien direkt, führt Befehle aus, macht Commits. Der Kontext lebt nicht in einer flüchtigen Unterhaltung — er lebt in CLAUDE.md und in deinem Repo, die permanent und versioniert sind. Umziehen heisst, dein Wissen von einem Ort, der gelöscht wird, an einen zu bewegen, der bestehen bleibt.

Fang damit an, zu prüfen, welcher wertvolle Kontext bei dir in ChatGPT gefangen ist. Wahrscheinlich gibt es Threads, in denen du den Stack eines Projekts definiert hast, Architekturentscheidungen, Stilkonventionen, Prompts, die gut funktioniert haben. All das ist ein Vermögenswert, der gerade nur in Threads existiert. Der erste Schritt des Umzugs ist, es herauszuziehen: Geh deine wichtigen Unterhaltungen durch und zieh die dauerhaften Entscheidungen heraus (nicht den ganzen Chat, die Schlussfolgerungen). 'Wir nutzen Astro, nicht React, wegen X', 'der Ton ist direkt ohne Emojis', 'die DB teile ich mit einem anderen Projekt, und diese Tabellen sind unantastbar'. Das ist genau das Material einer CLAUDE.md.

Das Herzstück des Umzugs ist, die CLAUDE.md aus diesem herausgezogenen Kontext aufzubauen. Was du in ChatGPT zu Beginn jedes Threads wiederholen musstest ('denk dran, dass ich Astro und Supabase nutze und der Ton ist...'), schreibst du in Claude Code einmal in CLAUDE.md, und es wird von selbst in jeder Sitzung geladen, für immer. Das knüpft direkt an das Modul OC-02 an: Der Umzug ist nichts anderes, als den verstreuten Kontext deiner Threads in die Datei des persistenten Gedächtnisses zu kippen. Eine gute Übung ist, ChatGPT selbst zu bitten: 'fass alle technischen Entscheidungen und Konventionen dieses Threads in Bullet-Form für eine Kontext-Datei zusammen' — und diese Ausgabe als Entwurf zu nutzen.

Ändere auch deine Art, Dinge zu verlangen. In ChatGPT verlangst du 'schreib mir den Code für X' und bekommst einen Block, den du einfügst. In Claude Code verlangst du 'erstell die Datei src/lib/x.ts, die X macht, gemäss den Konventionen von CLAUDE.md, und zeig mir den Diff' — die KI erstellt die Datei am richtigen Ort, du prüfst den Diff mit git und machst einen Commit. Die Geste des Kopierens-und-Einfügens verschwindet. Das erfordert, eine Gewohnheit zu verlernen: Hör auf, die KI als Textgenerator zu behandeln, und fang an, sie als Mitarbeiter zu behandeln, der auf deinem Projekt einwirkt. Am Anfang fällt es schwer, darauf zu vertrauen, dass sie die richtigen Dateien anfasst; deshalb sind `git diff` und die Commits aus Modul OC-04 dein Sicherheitsnetz.

Gut umzuziehen bedeutet, das ganze System aufzubauen, nicht nur das Werkzeug zu wechseln. Das System eines Operators ist: ein Repo mit git, eine CLAUDE.md mit dem Kontext, eine .gitignore, die Geheimnisse schützt, ein Arsenal von Prompts in einer prompts.md und das angeschlossene Continuous Deployment. Wenn du diese fünf Elemente hast, hast du aufgehört, 'eine KI zu nutzen', und eine Operation aufgebaut. Jedes der vorherigen Module von Operator Core war ein Teil; dieses Modul setzt sie zusammen, indem es ein echtes Projekt aus dem Chaos der ChatGPT-Threads zu diesem dokumentierten System umzieht. Das Ergebnis ist, dass jede neue Sitzung — deine oder die eines Mitarbeiters — mit dem gesamten geladenen Kontext startet.

Der Wert, den du sofort spürst, ist die Kontinuität. In ChatGPT bedeutet, ein Projekt nach einer Woche wieder aufzunehmen, Threads neu zu lesen und sich zu erinnern, wo du warst. Im umgezogenen System öffnest du das Terminal, `cd` ins Projekt, `claude`, und die KI kennt schon den Stack, die Konventionen und die Verbote, weil sie in CLAUDE.md stehen; du siehst, wo du warst, in `git log`. Das Projekt dokumentiert sich selbst. Diese Kontinuität ist das, was es erlaubt, viele Projekte gleichzeitig zu bedienen, ohne dass sie sich vermischen — wie es nötig ist, wenn du XNLAB, XHUB, XCAP, Espejo und diese Schule parallel führst: jedes mit seiner CLAUDE.md, seinem Repo und seinem isolierten Kontext, alle mit demselben Ablauf bedient.

Verifizierung ist NICHT automatisiertes Testen, und sie betrifft NICHT nur die Sicherheit. Sie ist die allgemeine Disziplin, zu beweisen, dass sich eine Änderung so verhält, wie du es erwartest, BEVOR du sie veröffentlichst. Sie hat vier Ebenen, die in Reihenfolge angewendet werden, und du brauchst fast nie alle vier: (1) Kompiliert / startet es ohne Fehler? (2) Sagt der Diff, was du zu verlangen glaubtest? (3) Hat sich das beobachtbare Verhalten so geändert, wie du es erwartet hast? (4) Hast du etwas kaputtgemacht, das vorher funktioniert hat (Regression)?

Die billige und obligatorische Ebene: DEN DIFF LESEN. Bevor du irgendetwas annimmst, `git diff` (oder das Diff-Panel des Editors). Claude Code ist hervorragend darin, zu beschreiben, was es getan hat, und mittelmässig darin, zu verraten, was es zu viel getan hat: eine Datei, die du nicht anzufassen verlangt hast, ein vergessenes `console.log`, eine hinzugefügte Abhängigkeit, ein 'nebenbei' gelöschter Block. Wenn der Diff mehr anfasst, als dein Satz verlangt hat, ist das ein Signal, kein Zufall. Regel: Nimm nie eine Änderung an, deren Diff du nicht Zeile für Zeile verstehst.

'Sieht aus, als würde es funktionieren' ist eine bequeme Lüge mit drei Gesichtern. Gesicht 1: Es startete ohne Fehler → du verwechselst 'crasht nicht' mit 'macht das Richtige'. Gesicht 2: Ich habe es einmal mit dem Glücksfall getestet → du hast nicht den leeren Input, das Duplikat, den Nutzer ohne Berechtigung getestet. Gesicht 3: Die KI hat mir gesagt, sie habe es verifiziert → die KI hat nichts ausgeführt, sie hat Text vorhergesagt. Das Gegenmittel ist immer dasselbe: das reale Verhalten mit deinen eigenen Augen beobachten, nicht den Bericht dessen akzeptieren, der die Änderung gemacht hat (weder Mensch noch KI).

Smoke Test = der kürzeste Weg, der beweist, dass das zentrale Stück atmet. Es ist keine vollständige Abdeckung; es sind die 20 % der Tests, die 80 % der Katastrophen abfangen. Für eine Website: starte `npm run dev`, öffne die Route, die du angefasst hast, mach die Hauptaktion, schau, dass das Erwartete passiert. Für ein Skript: führ es mit einem bekannten Input aus und vergleich die Ausgabe mit dem, was du WEISST, dass es ergeben soll. Du definierst den Smoke Test, BEVOR du die Änderung verlangst, nicht danach, um dich nicht selbst zu täuschen, indem du den Test an das Ergebnis anpasst.

Assertion statt Beobachtung: Schau nicht auf den Bildschirm und such Bestätigung, sondern definier im Voraus die falsifizierbare Aussage. Schlecht: 'mal schauen, ob es richtig lädt'. Gut: 'wenn ich das Formular ohne E-Mail abschicke, muss der Fehler "E-Mail erforderlich" erscheinen und es darf KEINE Zeile in `leads` eingefügt werden'. Eine gute Verifizierung lässt sich als Satz schreiben, der eindeutig falsch wäre, wenn die Änderung fehlgeschlagen ist. Wenn du diesen Satz nicht schreiben kannst, weisst du nicht, was du verifizierst.

Regression: Die neue Änderung macht oft das Alte kaputt. Die Frage, die den Senior vom Junior unterscheidet, ist nicht 'funktioniert mein Feature?', sondern 'was funktionierte vorher, das meine Änderung kaputtgemacht haben könnte?'. In dieser Schule kann das Anfassen von `galaxy.ts` die SVG-Karte und alle Konstellations-Seiten kaputtmachen, weil sie aus derselben Datei generiert werden. Bevor du veröffentlichst, listet mental, welche ANDEREN Dinge von dem abhängen, was du angefasst hast, und prüf mindestens eines.

Wie du Claude Code ALS Verifizierer benutzt, ohne ihm das Urteil zu überlassen: Bitte es, den echten Befehl auszuführen (`npm run build`, den Test, das Skript) und dir die ROHE Ausgabe einzufügen, nicht seine Zusammenfassung. 'Führ den Build aus und füg mir die vollständige Ausgabe ein' ist verifizierbar; 'funktioniert der Build?' lädt zur gefälligen Halluzination ein. Die KI verifiziert, indem sie ausführt und Beweise zeigt; du verifizierst, indem du diese Beweise liest. Nie umgekehrt.

Verifizierung im Verhältnis zum Risiko (nicht jede Verifizierung kostet gleich viel). Einen Copy-Text ändern: den Diff lesen reicht. RLS, einen Postgres-Trigger oder den Zahlungsfluss anfassen: Build + Smoke + Regression + Advisors prüfen. Der reife Operator kalibriert den Aufwand der Verifizierung an den Kosten des Irrtums, er verifiziert nicht alles gleich und vertraut nicht allem gleich.

Die Signale der Kontext-Degradation, in Reihenfolge ihres Auftretens: (1) die KI fragt dich erneut etwas, das du schon beantwortet hast; (2) sie implementiert Code neu, der schon existierte, oder macht eine vereinbarte Änderung rückgängig; (3) ihre Antworten werden generisch, verlieren die konkreten Namen deines Projekts; (4) sie bearbeitet die falsche Datei oder erfindet Pfade. Sobald du Signal 1-2 siehst, bist du in der roten Zone. Warte nicht auf Signal 4: Da räumst du schon einen Schaden auf statt voranzukommen.

Die richtige Intuition ist kontraintuitiv: Wenn die Sitzung entgleist, ist stoppen und neu starten SCHNELLER als beharren. Gegen einen gesättigten Kontext zu kämpfen ist negativer Zinseszins: Jeder Zug fügt Rauschen zum Rauschen hinzu. Die Frage ist nicht "wie erklär ich es besser?", sondern "hilft mir dieser Kontext noch oder stört er mich schon?". Wenn er stört, ist die Lösung kein besserer Prompt, sondern ein neuer Kontext.

Das Handoff: wie man neu startet, OHNE den Stand zu verlieren. Bevor du eine entgleiste Sitzung schliesst, verlang die Übergabe-Zusammenfassung: "Fass in einem Block zusammen, was wir versuchten, welche Entscheidungen wir trafen, welche Dateien wir anfassten, was offen blieb und was der nächste konkrete Schritt ist". Dieser Block ist dein portabler Stand. Neue Sitzung → du fügst die Zusammenfassung ein → Claude Code startet mit frischem Kontext und Erinnerung an das Wichtige, ohne das Rauschen mitzuschleppen. Das Handoff verwandelt einen Neustart mit Totalverlust in einen Neustart mit fast null Kosten.

Dein persistentes Gedächtnis lebt auf der Festplatte, nicht im Fenster. Was wirklich wichtig ist, darf nicht nur im Chat leben: Es lebt in `CLAUDE.md` (Projektentscheidungen, Konventionen, was NICHT anzufassen ist) und in Notiz-Dateien des Repos. Eine neue Sitzung, die deine `CLAUDE.md` liest, kennt schon das Wesentliche. Regel: Wenn du eine Entscheidung morgen brauchen wirst, lass sie nicht im Chat — schreib sie in `CLAUDE.md`. Das Kontextfenster ist flüchtiger RAM; das Repo ist deine Festplatte.

Prävention: kurze Sitzungen mit einzigem Fokus schlagen den Marathon. Eine Sitzung = ein abgegrenztes Ziel. "Reparier die RLS-Verifizierung" ist eine gute Sitzung; "refaktorier das ganze Backend" ist ein Marathon, der sich auf halbem Weg degradiert. Wenn eine Aufgabe gross ist, teilst du sie in unabhängige Sitzungen mit Handoff dazwischen, statt sie ganz in ein Fenster zu packen, das es nicht aushält.

Delegation an Subagenten: Parallelität und Kontext-Isolation. Ein Subagent ist eine Kind-Sitzung mit ihrem EIGENEN Kontextfenster, der du eine abgegrenzte Aufgabe und einen definierten Liefergegenstand gibst. Zwei Gewinne: (1) Parallelarbeit — ein Subagent prüft die Sicherheit, während ein anderer Tests schreibt; (2) Isolation — der Subagent verbrennt seinen Kontext beim Untersuchen einer riesigen Datei und gibt dir nur die Zusammenfassung zurück, ohne deine Hauptsitzung zu verunreinigen. Du delegierst das, was aufwendig zu erkunden, aber kompakt zu berichten ist.

Wie man einen guten Auftrag für einen Subagenten schreibt: so, als hätte der Subagent keine Erinnerung an deine Unterhaltung — denn er hat keine. Absolute Pfade, selbständiger Kontext und ein expliziter Liefergegenstand ("gib mir X zurück"). Ein vager Auftrag an einen Subagenten ist schlimmer als nicht zu delegieren: Du verbrauchst ein ganzes Fenster, um generischen Müll zu erhalten. Der Subagent glänzt bei Aufgaben mit klarer Grenze, nicht bei "hilf mir mit dem hier".

Den Faden zurückgewinnen, wenn Claude Code sich mitten in der Aufgabe verliert: Schieb nicht weiter. Stopp, bitte es, dir mit SEINEN Worten zu sagen, was es glaubt zu tun und warum. Wenn seine Version nicht mit deiner übereinstimmt, da ist die Abweichung — korrigier sie explizit oder mach ein Handoff in eine saubere Sitzung. Die schlechteste Option ist die des Anfängers: mehr Anweisungen auf ein Modell zu häufen, das schon falsch verstanden hat, und Korrekturen auf ein grundlegendes Missverständnis zu stapeln.