Terminal y scripts
Chronos te da dos formas seguras de ejecutar comandos en una sesión: scripts con nombre y un terminal real. Ambos corren dentro del sandbox de la sesión (ficheros limitados a la copia de trabajo, red bajo la política de salida) y ambos quedan registrados.
Scripts con nombre
Los scripts son comandos que tu equipo define en el fichero versionado .chronos/settings.toml: revisados como cualquier otro código, lanzados por nombre desde la app, nunca texto libre detrás de un botón.
| Script | Para qué |
|---|---|
setup |
Preparar la sesión al crearla (instalar dependencias...) |
run |
Arrancar la app: ver Ejecutar el proyecto |
archive |
Limpiar al cerrar la sesión |
test, verify, qa, pentest |
Los hooks de verificación detrás de la pestaña Checks y de la puerta de merge |
Los hooks de verificación salen solo del fichero versionado: un settings.local.toml personal puede cambiar cómo arrancas tú el servidor, nunca lo que ejecuta la puerta de merge.
Si lo tecleas en cada sesión, hazlo script
Un comando que repites siempre pertenece a .chronos/settings.toml: queda revisado, versionado y disponible para todo el equipo con un clic.
El terminal
Cada sesión tiene pestañas de terminal reales (el + del panel derecho añade más). Es un PTY de verdad con una shell persistente dentro del sandbox: flechas, TUIs, colores y procesos largos funcionan. El daemon es el dueño del proceso, así que:
- La shell sobrevive a una recarga de la interfaz: el scrollback se repinta al volver.
- Cerrar la sesión mata todo lo que el terminal arrancó. Sin huérfanos.
- Cada comando que tecleas queda en el registro de auditoría (redactado, nunca con valores secretos).
El terminal arranca en la copia de trabajo de la sesión, en su rama. Ve las mismas variables del proyecto que tus scripts y servidores, más CHRONOS_PORT.
Qué bloquea el sandbox
El terminal solo puede escribir dentro de la copia de trabajo de la sesión (más lo que el repo permita explícitamente en su configuración) y las ubicaciones conocidas de credenciales están ocultas a la lectura. Una operación bloqueada falla con un error de permisos claro y un aviso que explica el motivo. Es deliberado: el terminal es la mayor superficie de ataque del producto, así que se apoya en que el sandbox esté ahí.
Aprobación para lo destructivo
Cualquier cosa potencialmente destructiva (push forzado, borrado masivo, instalaciones por red) dispara una puerta de aprobación antes de ejecutarse: el comando queda marcado en la app y no corre hasta que alguien con el permiso adecuado lo aprueba. Nada con efectos serios ocurre en silencio.
Por qué funciona así
- Sin sorpresas: todo lo ejecutable es o un script revisado o un comando registrado y con puerta.
- Reproducible: los scripts viven con el proyecto, así que una sesión se comporta igual para todos.
- Aislado: los comandos afectan a la copia de trabajo de la sesión, nunca a tu máquina ni a otras sesiones.
Siguiente: Pull requests y merge.