🎨Personnaliser Harness Maxxing

Votre serveur, votre produit : vous pouvez tout changer, et les mises à jour conservent vos changements. Demandez simplement à Claude (« mets un jeu de snake sur mon tableau de bord », « autorise 20 sessions par sujet ») : il choisit le bon niveau ci-dessous, note ce qu'il a fait et le reporte à chaque mise à jour.

Trois niveaux

Claude essaie toujours les deux premiers niveaux avant de toucher au code du produit. L'interface web elle-même ne peut pas être personnalisée (elle est livrée précompilée) : les ajouts visuels passent par des extensions. Voir Widgets du tableau de bord et Extensions de pages.

Personnalisations

Une personnalisation est une modification du répertoire du code (/opt/claude-maxxing) enregistrée sous forme de commit git avec un titre et la raison :

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

Chaque personnalisation est listée dans <workspace>/CUSTOMIZATIONS.md (titre, raison, fichiers) et exportée sous forme de patch dans <workspace>/customizations/. Les deux font partie de la sauvegarde de la mémoire.

Mises à jour intelligentes

Avant : Paramètres -> Système vous montre ce que la prochaine mise à jour fera à votre serveur - testée sur une copie jetable, rien n'est encore modifié (maxxing update --preflight sur le serveur). Chaque personnalisation est soit reportée, soit reportée sur du code qui a changé (vérifiée ensuite), soit désormais incluse dans le produit (Harness vous propose de la supprimer), soit à adapter. Les modifications non enregistrées, les modifications des fichiers de l'interface et les extensions que la nouvelle version ne prend plus en charge sont également listées.

• Tout est compatible : Mettre à jour fait tout. Après le redémarrage, vos extensions et personnalisations sont vérifiées automatiquement, et Harness applique les nouveautés d'espace de travail de la version dans une session de system/harness.
• Quelque chose à adapter : Mettre à jour avec Harness ouvre une session qui adapte chaque changement au nouveau code à partir de ce à quoi il sert (noté avec lui), teste, puis met à jour. La version actuelle continue de fonctionner jusqu'à ce que tout fonctionne.

Après : « Vérifié après la mise à jour : vos extensions et vos changements fonctionnent » - ou ce qui a cessé de fonctionner, avec Corriger avec Harness. Vous pouvez vérifier à tout moment avec maxxing update --verify (ou « Vérifier maintenant »).

Donnez à chaque personnalisation un contrôle - une commande qui réussit tant que la personnalisation fonctionne - et elle sera testée après chaque mise à jour : maxxing custom save "..." --why "..." --check "<command>", ou plus tard maxxing custom check <id> "<command>". Les extensions déclarent la version du contrat d'extension qu'elles utilisent ("api": 1 dans manifest.json) : une version qui cesse de la prendre en charge est annoncée avant la mise à jour.

Mises à jour prudentes

maxxing update (ou le sujet system/harness (system/update sur les anciens serveurs), ou Paramètres -> Système) vous protège :

1. Les modifications non enregistrées du code sont d'abord enregistrées comme personnalisation - rien n'est jamais perdu. Les modifications de l'interface précompilée (web/) ne peuvent pas devenir des personnalisations : elles sont mises de côté (git stash) au lieu de bloquer la mise à jour, et Harness reconstruit ce qu'elles faisaient sous forme d'extension.
2. Vos personnalisations sont rejouées par-dessus la nouvelle version.
3. Pas de conflit : la mise à jour se termine (« N personnalisations reportées »).
4. Conflit (la nouvelle version a modifié les mêmes lignes) : rien ne change, la version actuelle continue de fonctionner, et Paramètres -> Système affiche « La mise à jour attend Harness ». Dans le sujet system/harness (system/update sur les anciens serveurs), Claude lit CUSTOMIZATIONS.md, adapte chaque personnalisation au nouveau code, et termine la mise à jour (maxxing update --resume). Si une personnalisation n'est plus nécessaire (le produit le fait désormais), Claude vous le dit et la supprime.
5. La nouvelle version ne démarre pas : retour automatique à la version précédente (et à la branche précédente après --branch).

maxxing update --rollback revient à la version (et à la branche) qui fonctionnait avant la dernière mise à jour. La commande refuse de s'exécuter tant que le répertoire du code contient des modifications non enregistrées (rien n'est changé) : mettez-les d'abord de côté (git stash), lancez le retour en arrière, puis remettez-les en place (git stash pop). Une personnalisation enregistrée juste avant serait annulée par le retour en arrière.

Mises à jour automatiques

Désactivées par défaut. Paramètres -> Système -> Se mettre à jour tout seul quand personne n'est là : lorsqu'une nouvelle version est disponible, que personne n'est sur l'interface et que rien ne tourne (aucun tour, aucun message en attente, aucune tâche planifiée, rien depuis 10 minutes), et que la mise à jour est « simple » (aucune personnalisation à adapter, aucune modification non enregistrée, aucune note de mise à niveau demandant quelque chose), Harness lance maxxing update tout seul et redémarre pendant quelques secondes. Sinon, il attend et vous le signale dans les notifications. Il ne touche jamais à un serveur dont le code est sur une branche en test (HEAD détaché) ni à une mise à jour qui vous attend déjà (conflit, version annulée), et n'essaie une version donnée qu'une fois par jour au maximum.

Nouveau serveur

Restaurez votre sauvegarde de la mémoire sur le nouveau serveur (RESTORE_FROM=owner/name à l'installation) : l'installateur réapplique vos personnalisations. Sinon, lancez maxxing custom restore.

Voir aussi : maxxing custom --help et le skill maxxing-customize (ce que suit Claude).