Panel de configuración

zerocode, el panel Config configura un ZeroClaw en ejecución. Cada ajuste tiene un control tipado, validación y una explicación en línea. Un guardado correcto persiste el cambio, mientras que la aplicación a los componentes en ejecución depende del ajuste y del destino. Abre Config desde cualquier sesión de zerocode para editar los ajustes.

La configuración aún se conserva en tu archivo de configuración, y la documentación describe los campos relevantes para que puedas ver exactamente qué escribe cada control. Interpreta esas descripciones como el resultado persistido, no como una instrucción para abrir el archivo en un editor. La edición manual es una alternativa de respaldo para hosts sin interfaz gráfica y aprovisionamiento mediante scripts, en los casos donde la documentación lo indica explícitamente.

Modificadores de las combinaciones de teclas

Las combinaciones de teclas usan nombres canónicos de modificadores: control es Control literal, primary es Comando en macOS y Control en el resto, y super es Super/Comando literal. Por ejemplo, control+c, primary+r y alt+shift+up son valores persistidos portátiles. Los valores antiguos ctrl+... se migran una sola vez al cargar la configuración y se reescriben con la forma canónica correspondiente.

Por qué el panel sobre el archivo

• Validación. Los controles rechazan valores mal formados antes de que lleguen al daemon, por lo que un error tipográfico no puede dejar la configuración en un estado que falle al cargarse.
• Descubribilidad. Cada configuración incluye una descripción en línea, por lo que no tienes que consultar la referencia de configuración para saber qué hace un campo.
• Comentarios de la aplicación. Los cambios guardados muestran los resultados confirmados de la aplicación para los destinos en ejecución afectados cuando el daemon los admite. Otros ajustes requieren una recarga explícita.
• Listas respaldadas por el registro. Las opciones de proveedor, canal, modelo y tema provienen del registro del backend, por lo que las opciones que ves son exactamente las que esta compilación admite.

Cambios guardados y aplicados

Después de que una edición de Config del daemon se guarde correctamente, el resumen de la aplicación mantiene la propiedad guardada y su revisión separadas de los resultados de los destinos en ejecución. Pulse s fuera de un editor o de un campo de búsqueda para abrir el estado de la aplicación. Use Arriba/Abajo o Re Pág/Av Pág para desplazarse y Escape para volver. La acción configurada application_status puede reemplazar el atajo predeterminado.

Cada resultado muestra los componentes de ruta canónicos, su revisión y la instancia del daemon o de la sesión a la que describe. Una sesión puede mostrar Applied live mientras el daemon sigue mostrando Reload required para el mismo cambio. Pending significa que el destino aún no ha confirmado la actualización; Rejected significa que el destino al que se intentó aplicar no la aceptó. La capacidad del esquema y un guardado correcto, por sí solos, no establecen que el cambio se haya aplicado.

Un recibo ausente, una API de estado no compatible, una lectura fallida, una época de daemon de reemplazo o un resultado ausente muestran Application status unavailable. El daemon conserva un conjunto acotado de cambios observados, no un inventario completo ni un historial persistente. El truncamiento y los registros ausentes nunca implican éxito. Los resultados de una edición anterior no relacionada conservan su revisión real; los resultados de una edición posterior de otro escritor no pueden confirmar tu guardado. Las operaciones de alias enrutadas a través de métodos del ciclo de vida separados pueden no tener recibo de guardado y permanecen sin disponibilidad para la retroalimentación de guardado exacto.

El estado de la aplicación se actualiza mientras Config está visible. Salir de Config o perder la conexión invalida su vista de aplicación en caché. La recarga continúa a través de la acción de recarga explícita existente y su confirmación; leer el estado no la activa. Los ajustes locales de ZeroCode, los archivos de personalidad y los archivos de habilidades mantienen su propia retroalimentación de guardado, porque no comparten el registro de aplicación de configuración del daemon.

Configuración local de la interfaz de usuario (zerocode-config.toml)

Algunas opciones describen cómo el propio zerocode renderiza sus paneles, en lugar de cómo se comporta el demonio. Se encuentran en el archivo propio de zerocode, <config-dir>/zerocode-config.toml, y se editan desde el panel Config de zerocode.

El rastreador TodoWrite es uno de ellos. Es una cuestión exclusiva de visualización: el demonio simplemente emite actualizaciones del plan y, a través de ACP, el cliente controla por completo el formato, por lo que es responsabilidad de zerocode:

[todotracker]
enabled = true           # interruptor maestro; cuando es false, el rastreador nunca se renderiza
enabled_at_start = false # visible al iniciar, antes de que llegue el primer plan
location = "right"       # "bottom", "left" o "right"
width = 32               # ancho de columna objetivo del panel lateral (izquierda/derecha)
max_height = 5           # altura máxima de la franja inferior en filas

La barra lateral del agente a nivel de shell se guarda en el mismo archivo. La sección predeterminada se serializa explícitamente para que las anulaciones de entorno tengan un nodo de esquema al que apuntar:

[sidebar]
visible = true # show the agent/session sidebar at launch
width = 24     # target width in terminal columns

Presiona Ctrl+B para mostrar u ocultar la barra lateral. Quickstart sigue accesible desde la barra de modos del teclado y también aparece como un acceso directo en la barra lateral, incluso con anchos de terminal reducidos. Al seleccionar un agente existente desde la barra lateral se inicia una nueva sesión de Chat o Code sin reemplazar las demás sesiones que ya gestiona ese panel.

TodoWrite values se vuelven a leer en cada límite de sesión, así que una edición hecha en el panel Config se aplica a la siguiente sesión que inicies, reinicies o a la que cambies, sin necesidad de reiniciar zerocode.

Anulaciones del entorno

Cualquier campo se puede sobrescribir para una sola ejecución con una variable ZEROCODE_. La sintaxis consiste en el prefijo seguido de la ruta de configuración en minúsculas, con . escrito como __:

ZEROCODE_todotracker__enabled=false zerocode
ZEROCODE_todotracker__location=parte inferior zerocode
ZEROCODE_sidebar__visible=false zerocode

Estas anulaciones son transitorias para el proceso: solo afectan a la instancia en ejecución y nunca se vuelven a escribir en zerocode-config.toml. Guardar un campo no relacionado en el panel Config no incorporará al archivo un valor inyectado mediante una variable de entorno.

Actualización desde un [todotracker] propiedad de un demonio

Antes de que se trasladara esta configuración, [todotracker] era una sección del config.toml del demonio. Si la estableciste allí, copia los valores:

1. Abra el archivo config.toml de su demonio y anote los valores de [todotracker].
2. Coloca el mismo bloque en <config-dir>/zerocode-config.toml (mostrado arriba) o configúralos desde Config → Todo tracker.
3. Elimina la sección [todotracker] del config.toml del demonio.

Las variables de entorno existentes ZEROCLAW_todotracker__* no es necesario eliminarlas antes de actualizar: los cinco campos reconocidos (enabled, enabled_at_start, location, width, max_height) son aceptados e ignorados por el demonio, por lo que una implementación que funcionaba anteriormente sigue iniciándose. Ya no tienen ningún efecto, así que cámbialas a la nomenclatura ZEROCODE_ indicada arriba.