npm - theus-cli-linux-arm64 - Versions diffs - 1.2.2 → 1.3.0 - Mend

theus-cli-linux-arm64 1.2.2 → 1.3.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (758) hide show

package/vendor/theus-arsenal/skills/sistema-operativo-agentico/SKILL.md DELETED Viewed

@@ -1,375 +0,0 @@
----
-name: sistema-operativo-agentico
-description: Construye sistemas operativos multiagente persistentes sobre el CLI de Theus. Cubre
-  arquitectura de kernel, agentes especialistas, comandos slash, memoria basada en archivos,
-  automatización programada y gestión de estado sin bases de datos externas.
----
-# Sistema operativo agéntico
-Trata el CLI de Theus como un runtime persistente / sistema operativo en lugar de una sesión de chat. Esta skill codifica la arquitectura usada por montajes agénticos de producción: una configuración kernel que enruta tareas a agentes especialistas, memoria persistente basada en archivos, automatización programada y una capa de datos en JSON/markdown.
-## Cuándo activarla
-- Construir un flujo multiagente dentro del CLI
-- Montar automatización persistente que sobreviva reinicios de sesión
-- Crear un "OS personal" o "OS agéntico" para tareas recurrentes
-- El usuario dice "OS agéntico", "OS personal", "multiagente", "coordinador de agentes", "agente persistente"
-- Estructurar proyectos largos donde el contexto debe sobrevivir entre sesiones
-## Visión general de la arquitectura
-El OS agéntico tiene cuatro capas. Cada capa es un directorio en la raíz del proyecto.
-```
-raiz-del-proyecto/
-├── AGENTS.md          # Kernel: identidad, reglas de enrutamiento, registro de agentes
-├── agents/            # Definiciones de agentes especialistas (prompts en markdown)
-├── .theus/commands/   # Comandos slash: la CLI de cara al usuario
-├── scripts/           # Scripts daemon: tareas programadas o por eventos
-└── data/              # Estado: sistema de archivos JSON/markdown, sin BD externa
-```
-### Responsabilidades por capa
-| Capa | Propósito | Persistencia |
-|---|---|---|
-| Kernel (`AGENTS.md`) | Identidad, enrutamiento, políticas de modelo, registro de agentes | En git |
-| Agentes (`agents/`) | Identidades especialistas con tools y memoria acotadas | En git |
-| Comandos (`.theus/commands/`) | Comandos slash de cara al usuario (`/sync-diario`, `/prospeccion`) | En git |
-| Scripts (`scripts/`) | Daemons Python/JS disparados por cron o webhooks | En git |
-| Estado (`data/`) | Logs solo-anexar, estado de proyectos, registros de decisiones | Ignorado en git o versionado |
-## El kernel
-`AGENTS.md` es el kernel. Actúa como el COO / orquestador. El agente lo lee al inicio de la sesión y lo usa para enrutar el trabajo.
-### Estructura del kernel
-```markdown
-# AGENTS.md - Kernel del OS agéntico
-## Identidad
-Eres el COO de [nombre-del-proyecto]. Enrutas tareas a agentes especialistas.
-Nunca escribes código directamente. Delegas al agente correcto y sintetizas los resultados.
-## Registro de agentes
-| Agente | Rol | Disparador |
-|---|---|---|
-| @dev | Código, arquitectura, depuración | El usuario dice "construye", "arregla", "refactoriza" |
-| @redactor | Documentación, contenido, correos | El usuario dice "escribe", "redacta", "blog" |
-| @investigador | Investigación, análisis, verificación | El usuario dice "investiga", "analiza", "compara" |
-| @ops | DevOps, despliegue, infraestructura | El usuario dice "despliega", "CI", "servidor" |
-## Reglas de enrutamiento
-1. Analiza la solicitud del usuario en busca de palabras clave de intención
-2. Cruza con la columna de disparadores del registro de agentes
-3. Carga el archivo del agente correspondiente desde `agents/<nombre>.md`
-4. Cede la ejecución con el contexto completo
-5. Sintetiza y presenta el resultado al usuario
-## Políticas de modelo
-- Modelo por defecto: usa el predeterminado del repositorio o del harness.
-- Tareas @dev: prefiere un modelo de mayor razonamiento para arquitectura compleja.
-- Tareas @investigador: usa el modelo con capacidad de investigación configurado y las tools de búsqueda aprobadas.
-- Techo de costo: advierte antes de superar el umbral de gasto configurado del proyecto.
-```
-### Principio clave
-El kernel debe ser **pequeño y declarativo**. La lógica de enrutamiento vive en tablas de markdown, no en código. Esto hace al sistema inspeccionable y editable sin depurar.
-## Agentes especialistas
-Cada agente es un archivo markdown independiente en `agents/`. El agente carga el archivo relevante al enrutar una tarea.
-### Formato de definición de agente
-```markdown
-# @dev - Ingeniero de software
-## Identidad
-Eres un ingeniero de software senior. Escribes código limpio, probado y de calidad de producción.
-Prefieres soluciones simples. Haces preguntas aclaratorias cuando los requisitos son ambiguos.
-## Alcance de memoria
-- Lee `data/projects/<proyecto-actual>.md` para el contexto
-- Lee `data/decisions/` para las decisiones de arquitectura
-- Anexa logs de ejecución a `data/logs/<fecha>-@dev.md`
-## Acceso a tools
-- Acceso completo al sistema de archivos dentro de la raíz del proyecto
-- Operaciones git (status, diff, commit, branch)
-- Acceso al runner de tests
-- Servidores MCP según lo configurado en `.theus/mcp.json`
-## Restricciones
-- Escribe siempre tests para las funcionalidades nuevas
-- Nunca hagas commit directo a `main`; usa ramas de feature
-- Prefiere editar archivos existentes antes que crear nuevos
-- Mantén las funciones por debajo de 50 líneas cuando sea posible
-```
-### Patrón de colaboración multiagente
-Cuando una tarea abarca varios agentes, el kernel los ejecuta en secuencia o en paralelo:
-```
-Usuario: "Construye una landing page y escribe el post de lanzamiento"
-Enrutamiento del kernel:
-1. @dev - "Construye una landing page con [requisitos]"
-2. @redactor - "Escribe un post de lanzamiento para [producto] usando el copy de la landing"
-3. El kernel sintetiza ambas salidas en una respuesta unificada
-```
-Para ejecución en paralelo, usa la capacidad de tareas en segundo plano del CLI o scripts de shell que invoquen a Theus con contextos de agente específicos.
-## Comandos y flujos diarios
-Los comandos slash son archivos markdown en `.theus/commands/`. Definen flujos reutilizables.
-### Estructura de un comando
-```markdown
-# /sync-diario
-Ejecuta el briefing matutino:
-1. Lee `data/logs/last-sync.md` para el contexto
-2. Revisa el estado del proyecto: `git status`, PRs pendientes, salud del CI
-3. Revisa `data/inbox/` en busca de tareas nuevas o decisiones pendientes
-4. Genera un resumen de bloqueos, prioridades y siguientes acciones
-5. Anexa el briefing a `data/logs/daily/<fecha>.md`
-```
-### Conjunto estándar de comandos
-| Comando | Propósito |
-|---|---|
-| `/sync-diario` | Briefing matutino: estado, bloqueos, prioridades |
-| `/prospeccion` | Ejecutar el flujo de prospección (correo, LinkedIn, etc.) |
-| `/investigar <tema>` | Investigación profunda con seguimiento de citas |
-| `/postular-empleos` | Adaptar CV + carta de presentación a un rol objetivo |
-| `/analitica` | Extraer métricas de Stripe, GitHub o fuentes propias |
-| `/prep-entrevista` | Generar flashcards o preguntas de entrevista simulada |
-| `/decision <tema>` | Registrar una decisión con pros/contras y la ruta elegida |
-### Activación de comandos
-Coloca los archivos en `.theus/commands/<nombre-comando>.md`. El CLI los descubre automáticamente. Los usuarios los invocan con `/<nombre-comando>`.
-## Memoria persistente
-La memoria es basada en archivos. Sin base vectorial, sin Redis, sin PostgreSQL. Los archivos JSON y markdown en `data/` son la base de datos.
-### Estructura del directorio de memoria
-```
-data/
-├── daily-logs/         # Logs diarios de actividad, solo-anexar
-├── projects/           # Archivos de contexto por proyecto
-├── decisions/          # Decisiones de arquitectura y de negocio (formato ADR)
-├── inbox/              # Tareas o ideas nuevas a la espera de triaje
-├── contacts/           # Personas, empresas, notas de relación
-└── templates/          # Prompts y formatos reutilizables
-```
-### Formato del log diario
-```markdown
-# 2026-04-22 - Log diario
-## Sesiones
-- 09:00 - Sesión 1: Refactorizado el módulo de auth (@dev)
-- 11:30 - Sesión 2: Borrador de la actualización a inversores (@redactor)
-## Decisiones
-- Cambio de JWT a cookies de sesión (ver `data/decisions/2026-04-22-auth.md`)
-## Bloqueos
-- A la espera de la API key del proveedor (seguimiento 2026-04-24)
-## Siguientes acciones
-- [ ] Mergear el PR del refactor de auth
-- [ ] Enviar la actualización a inversores para revisión
-```
-### Patrón de auto-reflexión
-Al final de cada sesión, el kernel anexa una reflexión:
-```markdown
-## Reflexión - Sesión 3
-- Qué funcionó: la ejecución de agentes en paralelo ahorró 20 minutos
-- Qué no: @investigador chocó con una fuente de pago, falta mejor ranking de fuentes
-- Qué cambiar: añadir campo `source-tier` a las notas de investigación (credibilidad A/B/C)
-```
-Esto crea un bucle de retroalimentación que mejora el sistema con el tiempo sin cambios de código.
-## Automatización programada
-Las tareas del OS agéntico corren con un programador **externo** (cron del sistema operativo), no con temporizadores internos de la sesión del CLI, que mueren cuando la sesión termina.
-### macOS: LaunchAgent
-```xml
-<!-- ~/Library/LaunchAgents/com.agentic.sync-diario.plist -->
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" ...>
-<plist version="1.0">
-<dict>
-    <key>Label</key>
-    <string>com.agentic.sync-diario</string>
-    <key>ProgramArguments</key>
-    <array>
-        <string>/usr/local/bin/theus</string>
-        <string>--cwd</string>
-        <string>/ruta/al/proyecto</string>
-        <string>--command</string>
-        <string>/sync-diario</string>
-    </array>
-    <key>StartCalendarInterval</key>
-    <dict>
-        <key>Hour</key>
-        <integer>8</integer>
-        <key>Minute</key>
-        <integer>0</integer>
-    </dict>
-    <key>StandardOutPath</key>
-    <string>/tmp/agentic-sync-diario.log</string>
-</dict>
-</plist>
-```
-### Linux: temporizador systemd
-```ini
-# ~/.config/systemd/user/agentic-sync-diario.service
-[Unit]
-Description=Sync diario del OS agéntico
-[Service]
-Type=oneshot
-ExecStart=/usr/local/bin/theus --cwd /ruta/al/proyecto --command /sync-diario
-```
-```ini
-# ~/.config/systemd/user/agentic-sync-diario.timer
-[Unit]
-Description=Ejecutar el sync diario cada mañana
-[Timer]
-OnCalendar=*-*-* 8:00:00
-Persistent=true
-[Install]
-WantedBy=timers.target
-```
-En otras plataformas, cualquier programador del sistema (Programador de tareas de Windows, `crontab`) que invoque `theus --cwd <proyecto> --command /<comando>` cumple el mismo rol.
-## Capa de datos
-La capa de datos es tu sistema de archivos. Usa JSON para datos estructurados y markdown para contenido narrativo.
-### JSON para estado estructurado
-```json
-// data/projects/web-v2.json
-{
-  "name": "Web v2",
-  "status": "in-progress",
-  "milestone": "beta-launch",
-  "agents_involved": ["@dev", "@redactor"],
-  "files": {
-    "spec": "docs/web-v2-spec.md",
-    "design": "designs/web-v2.fig"
-  },
-  "metrics": {
-    "commits": 47,
-    "last_session": "2026-04-22T11:30:00Z"
-  }
-}
-```
-### Markdown para narrativa
-Usa markdown para todo lo que lee un humano: decisiones, logs, notas de investigación, fichas de contactos.
-### Evolución de esquemas
-Nunca renombres campos existentes. Añade campos nuevos y marca los viejos como deprecados:
-```json
-{
-  "name": "Web v2",
-  "status": "in-progress",
-  "milestone": "beta-launch",
-  "_deprecated_priority": "high",
-  "priority_v2": { "level": "high", "rationale": "Bloquea la demo a inversores" }
-}
-```
-Esto mantiene legible el histórico sin scripts de migración.
-## Antipatrones
-### Agente único monolítico
-```markdown
-# MAL - Un agente lo hace todo
-Eres desarrollador full-stack, redactor, investigador e ingeniero DevOps.
-```
-Divide en agentes especialistas. El kernel se encarga del enrutamiento.
-### Sesiones sin estado
-```markdown
-# MAL - Sin memoria entre sesiones
-Empezar de cero cada vez que se abre el CLI.
-```
-Lee siempre `data/` al inicio de la sesión y escribe de vuelta al final.
-### Credenciales incrustadas
-```markdown
-# MAL - API keys en archivos de agentes o en AGENTS.md
-La API key del proveedor es sk-xxxxxxxx
-```
-Usa variables de entorno o un `.env` cargado por los scripts. Los agentes referencian `process.env.API_KEY`.
-### Base de datos externa para estado simple
-```markdown
-# MAL - PostgreSQL para el OS agéntico de un solo usuario
-```
-Usa archivos JSON/markdown hasta que tengas múltiples usuarios concurrentes o GBs de datos.
-### Enrutamiento sobreingenierizado
-```markdown
-# MAL - Lógica de enrutamiento en código en vez de tablas markdown
-if (intent.includes('deploy')) { agent = opsAgent; }
-```
-Mantén el enrutamiento declarativo en tablas markdown de `AGENTS.md`. Es inspeccionable, editable y depurable.
-## Buenas prácticas
-- [ ] `AGENTS.md` tiene menos de 200 líneas y cabe en la ventana de contexto
-- [ ] Cada archivo de agente tiene menos de 100 líneas y se enfoca en un dominio
-- [ ] `data/` va ignorado en git para logs sensibles, versionado para decisiones y specs
-- [ ] Los comandos usan nombres imperativos: `/sync-diario`, no `/ejecutar-sync-diario`
-- [ ] Los logs son solo-anexar; nunca edites logs diarios pasados
-- [ ] Todo agente tiene una sección `Alcance de memoria` que define qué archivos lee
-- [ ] Las reflexiones se escriben al final de cada sesión
-- [ ] Las tareas programadas usan cron externo (LaunchAgent, systemd), no temporizadores de la sesión del CLI
-- [ ] Seguimiento de costos: registra el gasto de API por sesión en `data/logs/<fecha>-costos.json`
-- [ ] Un proyecto = un OS agéntico. No compartas un mismo `AGENTS.md` entre proyectos no relacionados.

package/vendor/theus-arsenal/skills/sistemas-latencia-critica/SKILL.md DELETED Viewed

@@ -1,65 +0,0 @@
----
-name: sistemas-latencia-critica
-description: Usa esta skill para sistemas sensibles a la latencia como dashboards en tiempo real, datos de mercado, agentes de streaming, gateways de ejecución, colas, cachés o infraestructura tipo HFT donde importan la frescura y la latencia p95.
----
-# Sistemas de latencia crítica
-Usa esta skill cuando importe el comportamiento en tiempo real, las rutas calientes, la frescura del streaming o la velocidad de ejecución. Esto incluye infraestructura tipo HFT, pero la skill tiene un enfoque de ingeniería: no autoriza trading en vivo ni asesoría financiera.
-## Separa las métricas
-No colapses todo en "rápido". Haz seguimiento de:
-- latencia p50, p95 y p99;
-- throughput;
-- edad de frescura de los datos;
-- profundidad de las colas;
-- tasa de aciertos de caché;
-- tiempo de respuesta de proveedores/APIs;
-- tiempo de renderizado en el navegador;
-- corrección bajo carga;
-- comportamiento ante fallos y reintentos.
-## Mapea la ruta caliente
-Escribe la ruta desde el usuario/evento hasta el estado final visible:
-```text
-evento origen -> API del proveedor -> worker de ingesta -> cola -> caché -> ruta edge
--> stream al cliente -> renderizado en el navegador -> estado visible para el usuario
-```
-Después, mide cada segmento por separado.
-## Orden de optimización
-1. Elimina los viajes de ida y vuelta innecesarios.
-2. Cachea las lecturas estables con metadatos de frescura.
-3. Agrupa (batch) las llamadas y escrituras pequeñas.
-4. Acerca el cómputo a los datos o al usuario.
-5. Separa las rutas calientes de las frías.
-6. Aplica backpressure antes de que las colas crezcan sin límite.
-7. Usa streaming solo cuando mejore la frescura o la experiencia de usuario.
-8. Añade canarios para datos obsoletos, proveedores degradados y estado de caché corrupto.
-## Verificación
-Usa lecturas en vivo cuando exista una superficie desplegada:
-- timing HTTP y cabeceras de respuesta;
-- timestamp de frescura del proveedor;
-- estado de las colas o los jobs;
-- estado del edge/caché;
-- verificación en el navegador para la frescura real de la UI;
-- logs alrededor de los reintentos y del modo degradado.
-Para rutas de datos de mercado o adyacentes a la ejecución, verifica además la edad del orderbook, los supuestos de VWAP, el estado del proveedor y el comportamiento del kill-switch antes de dar la ruta por lista.
-## Salvaguardas
-- No optimices la latencia eliminando validaciones requeridas.
-- No escondas datos obsoletos detrás de aciertos de caché rápidos.
-- No afirmes comportamiento de milisegundos a partir de etiquetas en el cliente sin medición.
-- No ejecutes órdenes en vivo, migraciones destructivas ni despliegues que impacten a clientes sin una puerta de aprobación explícita.
-- Mantén los secretos y las cargas privadas fuera de los logs y de los artefactos de benchmark.