Ciclo de vida de una tarea

Qué cubre esta página

El flujo real de una tarea en un Puruto
Diferencias entre ejecución por agente y por CLI
Dónde encajan skills, .env, runtime local, IPC y ecosistema
Qué puntos conviene validar cuando algo falla

Resumen

En Puruto, una tarea no “la ejecuta el framework”.

La ejecución pasa por esta secuencia:

Entrada (usuario, puruto-cron, puruto-telegram o script)
Selección de comando/skill
Lectura de reglas del repo (CLAUDE.md, agent.md, SKILL.md)
Ejecución de comandos/scripts
Lectura/escritura de estado local (.env, DB, ficheros)
Resultado (respuesta al usuario, artefactos, notificaciones)

Flujo base (modo agente)

1. El usuario pide una acción

Ejemplos:

init
status
list
una skill de dominio (/ingest, /report)

En puruto-telegram, la entrada puede venir desde un chat. En puruto-cron, desde un job programado.

2. El agente identifica la skill adecuada

El agente se apoya en:

CLAUDE.md / agent.md
descripción de la skill en SKILL.md
reglas y comandos sugeridos en la propia skill

Esto se ve en los snapshots generados por el framework (tests/text_snapshots/*.txt), donde cada skill define frontmatter y pipeline.

3. La skill ejecuta su pipeline

Ejemplos reales de pipelines scaffold:

init en un Puruto estándar: verifica .env, crea carpetas, inicializa DB (si aplica)
status: inspecciona .env, rutas (PURUTO_DATA_PATH) y DB
puruto-cron/init: init-db, sync-jobs, status
puruto-telegram/init: verifica token, instala deps, crea DB y prepara inbox

Flujo base (modo CLI)

Cuando trabajas sin agente, el ciclo se simplifica:

Ejecutas generate.py, validate.py o upgrade.py
El script lee archivos y parámetros
Escribe/valida artefactos
Devuelve salida humana o JSON

No hay interpretación de skills, pero sí se mantiene el contrato estructural del repo.

Dónde aparecen los estados y artefactos

Configuración

.env.example (plantilla)
.env (runtime local)
.puruto-standard-version (versión del estándar)
.puruto-ipc.json (si hay delegación IPC)

Estructura funcional

.claude/skills/
README.md
CLAUDE.md / agent.md

Runtime local (según tipo)

db/ (SQLite)
runs/, notifications/ en puruto-cron
inbox/ y .channels.json en puruto-telegram

Ciclo de vida con IPC (delegación)

Si el Puruto se generó con --ipc true, la tarea puede incluir una delegación:

La skill /call lee .puruto-ipc.json
Verifica allowed_targets, allowed_actions, max_hops
Construye InvocationRequest
Usa ipc.py / invoker.py (scaffold)
Recibe InvocationResult
Devuelve resumen o error (DENIED, TIMEOUT, etc.)

El validador (validate.py) comprueba consistencia estructural de estos artefactos.

Ciclo de vida en `puruto-cron`

Resumen de flujo (MVP scaffold):

El job se declara en .jobs.json
sync-jobs lo persiste en SQLite
El scheduler determina próximas ejecuciones
run-now o scheduler dispara ejecución
Se generan artefactos/notificaciones (según runtime)
Opcionalmente se replica a puruto-telegram vía outbox/inbox local

Ciclo de vida en `puruto-telegram`