🎨Personalizar Harness Maxxing

Tu servidor, tu producto: puedes cambiar lo que quieras, y las actualizaciones conservan tus cambios. Solo pídeselo a Claude ("pon un juego de la serpiente en mi panel", "permite 20 sesiones por tema"): elige el nivel adecuado de los de abajo, registra lo que hizo y lo mantiene en cada actualización.

Tres niveles

Nivel	Para	Dónde	Al actualizar
Extensiones	widgets (Card o HTML libre: juegos, canvas), páginas, su API	`<workspace>/extensions/`	nunca se tocan
Espacio de trabajo	cómo se comporta Claude en un tema, tareas programadas, tus propias skills	archivos `CLAUDE.md`, página Crons, `.claude/skills/`	nunca se tocan
Personalizaciones	cambiar el producto en sí (una regla del servidor, un límite, un comando de la CLI…)	el directorio del código, registradas con `maxxing custom save`	se reaplican sobre la nueva versión

Claude siempre prueba primero los dos primeros niveles antes de tocar el código del producto. La interfaz web en sí no se puede personalizar (se distribuye ya compilada): las adiciones visuales son extensiones. Consulta Widgets del panel y Extensiones de página.

Personalizaciones

Una personalización es un cambio en el directorio del código (/opt/claude-maxxing) guardado como un commit de git con un título y el motivo:

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

Cada personalización aparece en <workspace>/CUSTOMIZATIONS.md (título, motivo, archivos) y se exporta como un parche en <workspace>/customizations/. Ambos forman parte de la copia de seguridad de la memoria.

Actualizaciones inteligentes

Antes: Ajustes -> Sistema muestra lo que hará la próxima actualización en tu servidor, probada en una copia desechable, sin haber cambiado nada todavía (maxxing update --preflight en el servidor). Cada personalización se mantiene, se mantiene sobre código que cambió (se comprueba después), ya está incluida en el producto (Harness te ofrece eliminarla) o debe adaptarse. También se listan los cambios sin guardar, las ediciones de los archivos de la interfaz y las extensiones que la nueva versión ya no admite.

Todo compatible: Actualizar lo hace todo. Tras el reinicio, tus extensiones y personalizaciones se comprueban automáticamente, y Harness aplica las novedades del espacio de trabajo de esa versión en una sesión de system/harness.
Algo que adaptar: Actualizar con Harness abre una sesión que adapta cada cambio al nuevo código a partir de para qué sirve (registrado junto con él), prueba y luego actualiza. La versión actual sigue funcionando hasta que todo funcione.

Después: "Comprobado tras la actualización: tus extensiones y cambios funcionan", o lo que dejó de funcionar, con Arreglar con Harness. Puedes comprobarlo cuando quieras con maxxing update --verify (o "Comprobar ahora").

Dale a cada personalización una comprobación (un comando que se ejecuta con éxito mientras funciona) y se probará tras cada actualización: maxxing custom save "..." --why "..." --check "<command>", o más tarde maxxing custom check <id> "<command>". Las extensiones declaran la versión del contrato de extensiones que usan ("api": 1 en manifest.json): si una versión deja de admitirla, se avisa antes de que actualices.

Actualizaciones con cuidado

maxxing update (o el tema system/harness (system/update en servidores antiguos), o Ajustes -> Sistema) te mantiene a salvo:

Las ediciones sin guardar del código se guardan primero como una personalización: nunca se pierde nada. Las ediciones de la interfaz precompilada (web/) no pueden ser personalizaciones: se apartan (git stash) en lugar de bloquear la actualización, y Harness reconstruye lo que hacían como una extensión.
Tus personalizaciones se reaplican sobre la nueva versión.
Sin conflicto: la actualización termina ("N personalizaciones mantenidas").
Conflicto (la nueva versión cambió las mismas líneas): no cambia nada, la versión actual sigue funcionando y Ajustes -> Sistema muestra "La actualización espera a Harness". En el tema system/harness (system/update en servidores antiguos), Claude lee CUSTOMIZATIONS.md, adapta cada personalización al nuevo código y termina la actualización (maxxing update --resume). Si una personalización ya no hace falta (el producto ya lo hace), Claude te lo dice y la elimina.
La nueva versión no arranca: se revierte automáticamente a la anterior (y a la rama anterior tras --branch).

maxxing update --rollback vuelve a la versión (y a la rama) que funcionaba antes de la última actualización. Se niega a ejecutarse mientras el directorio del código tenga cambios sin guardar (no se cambia nada): apártalos primero (git stash), ejecuta el rollback y luego recupéralos (git stash pop). Una personalización guardada justo antes se desharía con el rollback.

Actualizaciones automáticas

Desactivadas por defecto. Ajustes -> Sistema -> Actualizar sola cuando no haya nadie: cuando sale una nueva versión, nadie está en la interfaz y no se está ejecutando nada (ningún turno, ningún mensaje en cola, ninguna tarea programada, nada durante 10 minutos), y la actualización es "simple" (sin personalizaciones que adaptar, sin cambios sin guardar, sin nota de actualización que pida algo), Harness ejecuta maxxing update por sí mismo y se reinicia durante unos segundos. En caso contrario, espera y te avisa en las notificaciones. Nunca toca un servidor cuyo código esté en una rama de pruebas (detached HEAD) ni una actualización que ya está esperándote (conflicto, versión revertida), y prueba una misma versión como máximo una vez al día.

Servidor nuevo

Restaura tu copia de seguridad de la memoria en el nuevo servidor (RESTORE_FROM=owner/name al instalar): el instalador reaplica tus personalizaciones. Si no, ejecuta maxxing custom restore.

Consulta también: maxxing custom --help y la skill maxxing-customize (lo que sigue Claude).