delegar-pool

Delegar a un dev efímero vía pool exec (headless) — mecánica agnóstica a la tarea

Patrón de lanzamiento reutilizable para pool (poolside.ai), análogo en rol a delegar-ollama pero para el CLI pool en vez de ollama launch claude. Esta skill NO sabe de CCDD ni de qué tarea estás delegando — solo de cómo invocar pool exec sin perder tiempo ni confiar ciegamente en su reporte. Verificado en vivo 2026-07-26 con contratos KDD reales en Python y Rust.

Rol (misma doctrina que delegar-glm-ccdd)

pool es un implementador efímero, no un par de confianza. Yo (el orquestador) redacto el contrato + tests congelados, delego la implementación, y verifico el resultado yo mismo — nunca confío en el exit code ni en el resumen que pool imprime al final.

Comando base

pool exec --unsafe-auto-allow -d <REPO_O_DIR> -f <prompt.txt> -o json > <log.txt> 2>&1

• --unsafe-auto-allow OBLIGATORIO en no-interactivo. Sin él, la primera acción que requiera aprobación (leer O escribir, no importa cuál) falla con "approval required in non-interactive mode: encountered unexpected error" y exit code 1. No existe modo headless sin este flag — no está en el README, pero sí en pool exec --help.
• Prompt en ARCHIVO (-f), nunca inline (-p) para instrucciones multilínea — mismo motivo que en delegar-ollama (comillas/escaping).
• -o json da NLJSON estructurado (reasoning/thought/toolCall/ toolCallResult/assistantMessage) — más auditable que texto plano, no hace falta parsear logs crudos.
• -d <dir> fija el cwd de la sesión; no asumas que hereda el cwd del shell.
• Exit codes: 0 = tarea completa, 4 = fallo explícito reportado por pool, cualquier otro = error inesperado (incluida la falta de --unsafe-auto-allow).

El riesgo real NO es que se cuelgue esperando aprobación

Verificado dos veces (lectura primero, escritura primero) SIN el flag: el rechazo de aprobación es casi instantáneo (segundos), con error explícito, no un cuelgue. El riesgo real es el tiempo de razonamiento ANTES de llegar a esa acción. Trayectoria real auditada (%LOCALAPPDATA%\poolside\trajectories\trajectory-standalone_*.ndjson): 27m30s de corrida total, de los cuales ~27 minutos fueron tres bloques de thought consecutivos sin ninguna tool call, y el rechazo de aprobación en sí tardó 24ms. Conclusión: lanzá SIEMPRE con --unsafe-auto-allow desde el arranque en un directorio desechable — no hay forma de "probar primero sin el flag" barato, porque el costo no está en el rechazo sino en el razonamiento previo, que podés terminar pagando igual.