🎨Harness Maxxing anpassen

Dein Server, dein Produkt: Du kannst alles ändern, und Updates behalten deine Änderungen. Bitte einfach Claude darum („setz ein Snake-Spiel auf mein Dashboard“, „erlaube 20 Sessions pro Topic“) – Claude wählt die passende Ebene unten aus, hält fest, was gemacht wurde, und übernimmt es bei jedem Update.

Drei Ebenen

Claude versucht immer zuerst die ersten beiden Ebenen, bevor der Produktcode angefasst wird. Die Weboberfläche selbst lässt sich nicht anpassen (sie wird fertig gebaut ausgeliefert): Visuelle Ergänzungen sind Erweiterungen. Siehe Dashboard-Widgets und Seitenerweiterungen.

Anpassungen

Eine Anpassung ist eine Änderung am Code-Verzeichnis (/opt/claude-maxxing), die als Git-Commit mit einem Titel und der Begründung gespeichert wird:

maxxing custom save "Allow 20 sessions per topic" --why "I run many research threads in parallel"
maxxing custom                 # list, unsaved changes, pending update
maxxing custom drop <id>       # remove one

Jede Anpassung wird in <workspace>/CUSTOMIZATIONS.md aufgelistet (Titel, Begründung, Dateien) und als Patch in <workspace>/customizations/ exportiert. Beides ist Teil des Memory-Backups.

Intelligente Updates

Vorher: Einstellungen -> System zeigt, was das nächste Update auf deinem Server bewirkt – getestet an einer Wegwerf-Kopie, noch nichts wurde verändert (maxxing update --preflight auf dem Server). Jede Anpassung wird entweder übernommen, auf geändertem Code übernommen (danach geprüft), ist jetzt im Produkt enthalten (Harness schlägt vor, sie zu entfernen) oder muss angepasst werden. Ungespeicherte Änderungen, Änderungen an den Oberflächendateien und Erweiterungen, die die neue Version nicht mehr unterstützt, werden ebenfalls aufgelistet.

• Alles kompatibel: Update erledigt alles. Nach dem Neustart werden deine Erweiterungen und Anpassungen automatisch geprüft, und Harness wendet die Workspace-Neuerungen der Version in einer Session von system/harness an.
• Etwas muss angepasst werden: Update mit Harness öffnet eine Session, die jede Änderung anhand dessen, wofür sie gedacht ist (zusammen mit ihr festgehalten), an den neuen Code anpasst, testet und dann das Update durchführt. Die aktuelle Version läuft weiter, bis alles funktioniert.

Nachher: „Nach dem Update geprüft: Deine Erweiterungen und Änderungen funktionieren“ – oder was nicht mehr funktioniert, mit Mit Harness beheben. Du kannst jederzeit mit maxxing update --verify prüfen (oder mit „Jetzt prüfen“).

Gib jeder Anpassung eine Prüfung – einen Befehl, der erfolgreich ist, solange sie funktioniert – und sie wird nach jedem Update getestet: maxxing custom save "..." --why "..." --check "<command>", oder später maxxing custom check <id> "<command>". Erweiterungen geben die Version des Erweiterungsvertrags an, den sie nutzen ("api": 1 in manifest.json): Eine Version, die ihn nicht mehr unterstützt, wird vor dem Update angekündigt.

Vorsichtige Updates

maxxing update (oder das Topic system/harness (system/update auf älteren Servern) oder Einstellungen -> System) sorgt für Sicherheit:

1. Ungespeicherte Änderungen am Code werden zuerst als Anpassung gespeichert – nichts geht jemals verloren. Änderungen an der fertig gebauten Oberfläche (web/) können keine Anpassungen sein: Sie werden stattdessen beiseitegelegt (git stash), statt das Update zu blockieren, und Harness baut nach, was sie bewirkt haben, als Erweiterung.
2. Deine Anpassungen werden erneut auf die neue Version angewendet.
3. Kein Konflikt: Das Update wird abgeschlossen („N Anpassungen übernommen“).
4. Konflikt (die neue Version hat dieselben Zeilen geändert): Nichts ändert sich, die aktuelle Version läuft weiter, und Einstellungen -> System zeigt „Update wartet auf Harness“. Im Topic system/harness (system/update auf älteren Servern) liest Claude CUSTOMIZATIONS.md, passt jede Anpassung an den neuen Code an und schließt das Update ab (maxxing update --resume). Wird eine Anpassung nicht mehr gebraucht (das Produkt macht es jetzt selbst), sagt Claude dir Bescheid und entfernt sie.
5. Die neue Version startet nicht: Es wird automatisch auf die vorherige Version zurückgesetzt (und nach --branch auf den vorherigen Branch).

maxxing update --rollback kehrt zu der Version (und dem Branch) zurück, die vor dem letzten Update lief. Der Befehl weigert sich zu laufen, solange das Code-Verzeichnis ungespeicherte Änderungen hat (nichts wird verändert): Lege sie zuerst beiseite (git stash), führe den Rollback aus und hole sie dann zurück (git stash pop). Eine Anpassung, die kurz davor gespeichert wurde, würde durch den Rollback rückgängig gemacht.

Automatische Updates

Standardmäßig aus. Einstellungen -> System -> Von selbst aktualisieren, wenn niemand da ist: Wenn eine neue Version erschienen ist, niemand auf der Oberfläche ist und nichts läuft (kein Turn, keine Nachricht in der Warteschlange, kein geplanter Job, 10 Minuten lang nichts), und das Update „einfach“ ist (keine Anpassung, die angepasst werden muss, keine ungespeicherte Änderung, kein Upgrade-Hinweis, der etwas verlangt), führt Harness maxxing update von selbst aus und startet für ein paar Sekunden neu. Andernfalls wartet es und sagt dir in den Benachrichtigungen Bescheid. Es fasst nie einen Server an, dessen Code auf einem Branch im Test ist (detached HEAD), oder ein Update, das bereits auf dich wartet (Konflikt, zurückgesetzte Version), und probiert eine bestimmte Version höchstens einmal am Tag aus.

Neuer Server

Stelle dein Memory-Backup auf dem neuen Server wieder her (RESTORE_FROM=owner/name bei der Installation): Das Installationsprogramm wendet deine Anpassungen erneut an. Andernfalls führe maxxing custom restore aus.

Siehe auch: maxxing custom --help und den Skill maxxing-customize (dem folgt Claude).