raise: atomares AI-Agent-Konfigurationsprofil-Switching

Der Name ist ein Homophon. Raise. Rice-aise. So oder so: das Tool, das ein Config-Drift-Problem gelöst hat, das mich still jede Woche verlangsamt hatte - monatelang, bevor ich zugab, dass es ein Problem war.

Warum es das gibt

Ich berate. Das bedeutet verschiedene Clients, verschiedene Codebases, verschiedene Context-Windows und - entscheidend - verschiedene Agent-Konfigurationen. Das Claude-Code-System-Prompt für meinen Infrastruktur-Client muss das Terraform-Layout, die Namenskonventionen und den PR-Prozess des Clients kennen. Dasselbe sieht für ein Produkt-Startup komplett anders aus. Gemini CLI hat ein separates Config-Format. Codex hat ein anderes. OpenCode hat noch eines. Pi hat noch eines.

Irgendwann zählte ich: Ich verwaltete maßgeschneiderte Config-Dateien über siebzehn KI-Coding-Tools für vier aktive Client-Engagements. Nicht Profile - flache Dateien. Ich bearbeitete sie von Hand vor dem Kontext-Wechsel zwischen Clients, was bedeutete, dass ich routinemäßig vergaß, ein Tool zu aktualisieren, eine Session mit dem falschen System-Prompt startete und Outputs produzierte, die subtil falsch für den Kontext waren, in dem ich mich tatsächlich befand.

Der Disziplin-Fix - “einfach sorgfältiger sein” - skaliert nicht. Ich brauchte den Tooling-Fix.

Wie es funktioniert

raise ist eine einzelne Go-Binary. Sie liest ein Verzeichnis benannter Profile, wobei jedes Profil ein Verzeichnisbaum ist, der die Config-Standorte für die zu verwaltenden Tools spiegelt. Wenn man raise use <profile> ausführt, führt es atomare Symlink-Swaps über jeden konfigurierten Tool-Standort gleichzeitig durch.

Atomar ist das Schlüsselwort. Der alte Ansatz für dieses Problem - “ein Shell-Skript schreiben, das Dateien kopiert” - hat ein Failure-Window. Wenn das Skript halbwegs einen Fehler wirft, befindet man sich in einem Hybrid-State, in dem manche Tools die neue Config haben und manche die alte. Das ist schlechter als jeder saubere State. Raise verwendet Symlinks statt Kopien und tauscht das Symlink-Target in einem einzelnen rename(2)-Syscall pro Standort - so atomar wie man auf einem POSIX-Filesystem werden kann.

Credential-Preservation ist der Teil, der am meisten Nachdenken erforderte. API-Keys, Auth-Tokens und Session-Credentials leben in denselben Config-Verzeichnissen wie System-Prompts und Tool-Settings. Man will nicht, dass diese mit dem Profil rotiert werden - sie sind pro-Machine, nicht pro-Engagement. Raise hat ein Credentials-Manifest pro Tool, das identifiziert, welche Config-Keys oder Datei-Abschnitte credential-adjacent sind, und sie vom Swap ausschließt. Das Profil speichert ein Template mit Platzhaltern; die Swap-Schicht füllt sie aus dem lokalen Credential-Store, bevor sie schreibt.

Siebzehn Tools zu unterstützen erforderte, siebzehn verschiedene Config-Konventionen zu auditieren. Manche Tools nutzen ~/.config/<tool>/config.json. Manche nutzen ~/.toolrc. Manche haben ein Verzeichnis, manche haben eine einzelne Datei, manche haben beides und jedes bedeutet etwas anderes. Die Tool-Registry in raise codiert das pro Tool - wo die Config lebt, was das Format ist, welche Felder Credentials sind. Ein neues Tool hinzuzufügen sind drei Ergänzungen zur Registry und ein Test-Fixture.

Was interessant ist

Der Teil, der mich überraschte: Das schwierigste Tool zu unterstützen war nicht das obskure. Es war Claude Code, das eine mehrschichtige Config-Hierarchie hat - globale Settings, Projekt-Settings, lokale Overrides - und bedeutungsvolle Semantik darüber, welche Schicht gewinnt. Ein Profil-Swap, der die Projekt-Schicht clobbert, bricht Repos, die projekt-spezifische Settings eingecheckt haben. Raise muss die Schicht-Semantik kennen und nur die Schichten berühren, die es berühren soll.

Die andere Überraschung war, wie viel Widerstand ich spürte, dieses Tool überhaupt zu bauen. Es gibt einen starken Pull im Developer-Tooling hin zu “ich sollte einfach disziplinierter sein”. Dieser Instinkt ist falsch. Disziplin ist für Dinge, die genuinely Urteilsvermögen erfordern; Config-File-Management ist nicht eines davon. Wenn man etwas öfter als zweimal pro Woche von Hand macht und dabei nichts Neues lernt, sollte man es automatisieren. Keine Ausnahmen.

Der Name kam aus einem Gespräch über das Prompt-Engineering-Konzept des “Raisens des Floors” von Agent-Outputs. Ein Profil, das für den Kontext falsch ist, senkt den Floor aktiv. Raise hält ihn dort, wo er hingehört.

Was ich ändern würde

Das Credentials-Manifest ist aktuell manuell gepflegt. Ich möchte einen First-Run-Wizard, der bestehende Config-Dateien inspiziert, credential-förmige Values identifiziert (API-Key-Muster, Token-Formate, Bearer-Strings) und automatisch ein Manifest vorschlägt. Die Information ist da; sie erfordert nur einen Read-Pass und einige Heuristiken.

Ich möchte auch einen raise diff <profil-a> <profil-b>-Befehl. Momentan muss man die Profil-Verzeichnisse selbst überschauen. Ein strukturiertes Diff, das System-Prompt-Änderungen separat von Tool-Setting-Änderungen hervorhebt, würde Profil-Auditing erheblich schneller machen, besonders wenn man ein Client-Engagement seit Wochen nicht angefasst hat und sich nicht mehr genau erinnert, was man konfiguriert hat.

Das Profil-Format ist aktuell verzeichnisbasiert, was flexibel aber nicht portabel ist. Ich denke über ein Single-File-Profil-Format nach - etwas wie ein TOML-Bundle, das über ein Git-Repo oder einen Gist geteilt werden kann - damit man Agent-Konfigurationen neben den eigentlichen Projekten versionieren kann. Das ist der natürliche nächste Schritt, um das für mehrere Personen genuinely nutzbar zu machen.