El panel, pestaña a pestaña

El dashboard del panel es tu superficie de administración. Todo lo que cambias aquí se firma, se versiona y lo recogen los clientes en su siguiente sincronización: las sesiones no necesitan reiniciarse. Cada acción exige el rol admin y queda auditada con su autor.

Entra con tu email de organización y contraseña. En un despliegue nuevo la primera cuenta de administrador se crea con la variable PANEL_ADMIN_PASSWORD. Ver Despliegue.

La barra lateral tiene diez pestañas: Catalog, Prompts, Skills, Connectors, Users, Teams & roles, Keys, Audit, Releases y, para super-admins, Tenants.

Catalog: conexiones

Autoriza o revoca los servidores que los agentes pueden usar. Cada entrada tiene un id, un nombre, un endpoint (o un builtin que ejecuta el propio cliente), un ámbito (global o team) y el secreto del servicio. El secreto se queda en el panel: las sesiones llegan a cada servidor a través del proxy local y la credencial se inyecta allí. El agente nunca la ve. Una entrada con el secreto vacío no envía cabecera de autorización a nadie.

Chronos siembra ocho conexiones de serie (Playwright, GitMCP, AWS Knowledge, AWS, Figma, Replicate y los builtins de skills e índice de código), cada una con su propia guarda de siembra: si revocas una, un redespliegue no la vuelve a activar. El detalle de cada una y sus flujos de credencial (set token de Figma y Replicate, el rol cross-account de AWS) está en Conectores y credenciales.

Catalog: capability packs

La misma pestaña lista cada capability pack con su tipo, dónde corre y su estado por ámbito. Dos familias:

• Packs de contenido: skills y optimizadores que se inyectan en las sesiones: los skills de método, los de ingeniería, pulse y el optimizador tempo (desactivado por defecto).
• Packs de framework: interruptores sobre la plataforma, no anulables por sesión: cloud-aws, seo, agents, scripts-local-overrides, workspace-env-vars, session-missions y external-network-mode (desactivado por defecto). Ver Qué gobierna el panel.

Activar o desactivar un pack es un cambio de cascada: sube la versión de packs, queda auditado y llega a cada cliente en su siguiente sincronización. Se aplica cuando las sesiones leen la política, así que apagar algo detiene también los workspaces que ya existen.

Prompts: contexto gobernado

Prompts de empresa, estándares, skills y convenciones: markdown gobernado que se aplica a cada sesión de la compañía (global) o de un equipo. Cada entrada tiene un id estable, un nombre, un tipo (prompt, standard, skill, convention), un ámbito y un cuerpo en markdown con vista previa.

Al arrancar una sesión el cliente descarga el paquete firmado, verifica la firma, resuelve la cascada y materializa el resultado en el contexto gestionado del agente: máxima precedencia, no anulable y nunca escrito en un repositorio. La auditoría registra los cambios solo con metadatos; el cuerpo del markdown no aparece nunca en el registro.

Skills: la cola de revisión de Techne

Donde la experiencia de las sesiones se convierte en capacidad gobernada. Los desarrolladores proponen skills desde sesiones terminadas y cada propuesta aterriza aquí. La lees, la editas si hace falta, eliges ámbito (global o un equipo) y publicas con Approve & publish, o la rechazas. También puedes importar un SKILL.md desde una URL. El ciclo completo está en Techne.

Connectors: trackers de incidencias

Conecta Jira o Linear una vez, para toda la organización o por equipo: id, nombre, endpoint y una credencial que se escribe una vez y no vuelve a mostrarse. Los workspaces enlazan después un proyecto o un equipo por el id del conector en su configuración versionada: ningún secreto vive en un repositorio. Campos y detalle en Conectores y credenciales.

Users

El panel es la fuente de identidad de la organización; esta pestaña guarda también el nombre de la empresa. Crea usuarios con email, nombre, equipos y rol. Si los creas sin contraseña se genera una de un solo uso que se muestra exactamente una vez; el usuario la rota en su primer acceso. Desde aquí también puedes deshabilitar un usuario (bloquea el panel y el acceso desde la app) o resetear su credencial.

Aprobación de dispositivos. Un desarrollador conecta la app con un código de dispositivo: la app se lo muestra, él aprueba la máquina en la página de activación del panel tras iniciar sesión y las claves públicas de firma quedan fijadas en su equipo. Deshabilitar la cuenta revoca también esta vía.

Teams & roles

La pertenencia a equipos y el rol de cada miembro: developer, reviewer, maintainer o admin. El rol decide qué puede hacer cada uno en local: solo los roles con pr.merge pueden mergear y settings.approve controla quién aprueba propuestas de scripts. Los cambios aplican en la siguiente sincronización de cada cliente.

Keys

Las claves de firma Ed25519 del modelo de confianza. La clave activa firma los paquetes nuevos; las anteriores se conservan en el conjunto de confianza, así las sesiones vivas siguen verificando tras una rotación. Las claves privadas nunca salen del servidor.

Audit

La parte central del registro: quién autorizó qué conexión, qué credenciales se entregaron y a quién, cambios de cascada y de rol y qué sesiones cargaron qué versión del catálogo. Complementa el registro local de cada sesión. Ver Auditoría.

Releases

La puerta de despliegue del cliente de escritorio. Los builds registrados aparecen por versión y plataforma; los punteros de canal (stable, internal, alpha, beta) deciden qué sirve cada canal de actualización. Promocionar un build a un canal es lo que de verdad lo despliega: publicar una release en el repositorio no cambia nada para los actualizadores.

Tenants (super-admin)

Los despliegues multi-tenant añaden la pestaña Tenants y un selector de organización en la barra superior: crea organizaciones (cada una se siembra con los valores por defecto del producto), consulta su estado y administra cualquiera de ellas. Cada fila de catálogo, pack, contexto y usuario pertenece a su organización; las guardas de siembra son por organización, así que las revocaciones de un tenant nunca se filtran a otro. Quién es super-admin lo decide la variable PANEL_SUPER_ADMINS del despliegue. Ver Despliegue.

API de administración

Todo lo que hace el dashboard existe también como API autenticada, con los mismos roles y la misma auditoría. Los clientes solo consumen paquetes firmados; ninguna ruta les sirve secretos.