talos

Governed AI Delivery Model — DelfosTI Resultados, no horas.

talos deja un repo, o una carpeta entera de repos de un cliente, GADM-ready en un comando. El repo recibe solo CLAUDE.md, configuración MCP, el pin de Talos y el bloque .gitignore de la carpeta local .talos/; skills/agentes llegan por plugin y los hooks por la configuración administrada de la máquina.

⚠️ Requiere talos-kit

Este paquete es el instalador, no el contenido. La metodología (skills, hooks, convenciones, agentes) vive en talos-kit, distribuido de forma privada por DelfosTI (GitLab / provisioning de máquina). Sin el kit, el comando no instala nada — está pensado para el ecosistema interno de DelfosTI, no para uso general.

$ npx @delfosti/talos
✖ talos-kit not found. Pass --kit <path> or set TALOS_KIT_PATH.

Uso

Laptop nueva: 3 comandos

npm i -g @delfosti/talos
cd C:\Clientes\Kipey && talos --token <deploy-token>   # el token solo la 1ª vez (o env TALOS_DEPLOY_TOKEN)
talos doctor                                            # opcional: verifica máquina y workspace

talos decide el modo por la carpeta, sin preguntas:

| Carpeta | Modo | | -------------------------------------------------------- | ------------------------------------------------ | | repo git (incluye monorepo con hijos que tienen .git) | por repo, igual que 1.1.0 | | sin .git propio (o con un .git stub) y ≥ 1 repo hijo | workspace: máquina + workspace en una pasada | | vacía / sin repos hijos | por repo |

--workspace y --repo fuerzan el modo (no se combinan). En modo workspace, una sola corrida hace:

1. Máquina: provisiona el kit desde GitLab si falta o no tiene la capacidad workspace-v1, instala los candados (managed-settings.json, con su propia UAC) y sincroniza el plugin talos@delfosti.
2. Workspace: CLAUDE.md con el bloque TALOS WORKSPACE (tu texto intacto), .mcp.json con los MCP aprobados, .claude/talos.json (pin talos.workspace.v1) y la carpeta .talos/. Los repos hijos no se modifican.

Un paso que falla no aborta el resto: sale con ✖ y su comando exacto. Exit 0 si todo va bien, 1 si hay algún ✖.

Comandos

talos [dir] [--workspace | --repo] [--dry-run] [--no-elevate] [--token <t>] [--kit <path>] [-y] [--skip-mcps]
talos init [dir] [--dry-run] [--workspace]     # solo la fase Workspace; no toca la máquina
talos doctor [dir]                             # diagnóstico de solo lectura; exit 1 si hay ✖
talos update [--dry-run] [--no-elevate]        # kit + candados + plugin (+ pin del workspace en el cwd)
talos machine --apply [--no-elevate]           # solo los candados (managed-settings.json)
talos provision [--target <dir>] [--dry-run]   # provisiona la máquina (TI, sin git)
talos rollback [--target <dir>]                # vuelve al kit anterior (offline)
talos auth login --core-url <url>               # autoriza el CLI en el back office
talos auth status                               # muestra estado y vencimiento sin revelar el token
talos auth logout                               # revoca el token y elimina la credencial local
talos context push --repo <nombre>               # publica contexto de un repo desde la rama base limpia
talos hu list                                    # lista HUs aprobadas de los proyectos autorizados
talos --version

--dry-run muestra el mismo plan con [dry-run] sin escribir nada y sin pedir UAC (talos e init tampoco descargan). --no-elevate (SSH, sesiones sin escritorio) no lanza la UAC: imprime el comando para una terminal de administrador. Todo es un comando del CLI: no hay scripts de doble clic.

talos auth login también acepta TALOS_CORE_URL. Muestra una URL y un código para aprobar el dispositivo en el navegador. La credencial dura hasta 90 días según el servidor y se guarda por usuario en Windows DPAPI, macOS Keychain o Linux libsecret; sin libsecret, el CLI avisa y usa ~/.talos/credentials.json con permisos 0600. logout requiere acceso al back office para revocar el token vigente; si la red falla, conserva la credencial para reintentar. talos auth login --scopes story:read,delivery:write permite solicitar permisos adicionales de forma explícita; el permiso por defecto sigue siendo solo context:push.

talos context push requiere context.projectRefId en .claude/talos.json (o --project <uuid>), una credencial con context:push y una rama base limpia, sin cambios locales y con HEAD igual a origin/<baseRef>. talos init registra repos[].baseRef desde origin/HEAD si está configurado; si no lo está, usa --base <rama> una vez. El CLI consulta la convención del back office, lee solo documentos seleccionados del commit y obtiene metadatos estructurales con codebase-memory 0.9.0. Publica el paquete comprimido y guarda el SHA confirmado en .talos/context-push-state.json. Si la indexación falla, publica solo los documentos aptos. No sube archivos sin seguimiento, binarios, secretos con patrones conocidos ni código fuente bruto.

talos hu list requiere story:read. talos hu pull <id> ya descarga y comprueba el hash del paquete aprobado, pero detiene la importación hasta que el kit soporte el contrato talos.hu-package.v2; no escribe una HU parcial.

Una sola carpeta: .talos/

.talos/ es la única carpeta de Talos, en el workspace y en cada repo: HUs en .talos/hus/<HU-id>/ (hu.md, plan.md, tasks.md, qa.md), estado de corridas en .talos/runs/, gobierno en .talos/governance/ y el índice local en .talos/codebase-memory/. No se versiona (el setup por repo añade /.talos/ al .gitignore). talos doctor avisa (⚠, nunca mueve nada) si encuentra talos/ en la raíz del workspace o openspec/changes en un repo, con el comando para moverlos a .talos/hus/<HU-id>/.

Flags del setup por repo

--skip-mcps no instala ni actualiza MCPs y preserva cualquier .mcp.json existente; el modo manual del explorer solo se habilita con recibo v2 explícito y si talos-codebase-memory y el nombre legacy están ausentes. --skip-tools es independiente y omite la inicialización de herramientas externas declaradas en el manifest (desde kit 1.5.1 no hay ninguna: la CLI de OpenSpec salió del setup).

Resolución del kit: --kit <path> › env TALOS_KIT_PATH › kit provisionado por TI › checkout hermano ../talos-kit.

Qué hace el setup

1. Detecta el stack (package.json / go.mod).
2. Reconciliación idempotente de los MCPs aprobados en .mcp.json; migra el nombre legacy a talos-codebase-memory, mientras una personalización se preserva y bloquea el setup hasta resolución explícita. Symlinks, JSON null y fingerprints incompletos fallan antes de cualquier escritura.
3. Aísla el almacén de codebase-memory por proyecto mediante CBM_CACHE_DIR + CBM_ALLOWED_ROOT, en .talos/codebase-memory/, y asegura esa ruta con un bloque administrado al final de .gitignore. Una instalación previa migra al almacén local y requiere una reindexación única.
4. Genera CLAUDE.md desde plantilla y escribe el pin/recibo .claude/talos.json.
5. Retira los restos de la CLI de OpenSpec (.claude/skills/openspec-*, openspec/config.yaml) — Talos guarda las HUs solo en .talos/hus/<id>/ y el setup no crea openspec/ ni talos/ — y verifica que el plugin Talos esté instalado para el usuario.

La metodología (skills y agentes) no se copia al repo: viaja por el plugin talos@delfosti. Los candados se despliegan por managed-settings de máquina.

Seguridad & IP

• Cero secretos en el paquete: publica solo bin/ + dist/ compilado (allowlist files).
• La metodología no viaja por npm: el instalador es un cascarón; el valor (kit) es privado.
• Los candados de seguridad (no leer .env, no push a ramas protegidas, no SQL destructivo) se aplican por managed-settings de máquina, no dependen de archivos mutables del proyecto.
• El guard MCP administrado bloquea un talos-codebase-memory local que intente sombrear la entrada project-scoped, porque Claude Code da mayor precedencia al scope local.

Licencia

Propietario — © 2026 DelfosTI. Todos los derechos reservados. Uso interno bajo autorización de DelfosTI. Ver LICENSE.