\n\nDocumentación externa revisada el 12 de octubre de 2026. Se conservan los casos históricos y las decisiones operativas del entorno.
\n
Un modelo guiado es un agente al que se le permite razonar y proponer con amplitud, pero cuya capacidad de actuar está recortada por un entorno diseñado para exigir intervención humana en los puntos sensibles.
\nLa seguridad no debería depender de que el modelo “se acuerde” de preguntar. Una instrucción como pedime permiso antes de instalar algo mejora el comportamiento esperado, pero no constituye una barrera. Si el harness permite ejecutar cualquier comando, el proceso tiene acceso a credenciales y la red alcanza producción, la acción sigue siendo técnicamente posible.
\nLa prevención de desastre surge de qué tan bien está armado el lugar donde trabaja el agente:
\nLa regla madre es simple: las instrucciones orientan; el entorno limita.
\nDefinen intención y método:
\nSon imprescindibles para producir buen trabajo, pero son una política blanda. El modelo puede interpretar mal una frase, olvidar una restricción después de una conversación larga o creer que una acción es una consecuencia obvia del objetivo.
\nEs el CLI o entorno que traduce decisiones del modelo en acciones reales: Codex, Claude Code, OpenCode u otro agente.
\nEl harness puede:
\nEsta es la primera capa de enforcement. Si ssh, git push o una edición están en deny, el modelo no debería poder convertir su intención en esa acción mediante la herramienta normal.
Incluye el sistema operativo, contenedor, sandbox, usuario, worktree y conectividad.
\nUn agente puede tener permiso de ejecutar shell y aun así estar contenido si:
\nEsta capa protege incluso cuando el harness está mal configurado o aparece una vía no contemplada.
\nSon las credenciales y permisos del sistema destino:
\nEs la última red. Aunque el agente escape de las capas anteriores, no debería poseer autoridad para realizar una acción que nunca necesitó.
\nEn una sesión de OpenCode con GLM 5.3, el agente podía instalar una librería o conectarse por SSH sin consultar. Sólo frenaba si la instrucción le pedía expresamente solicitar permiso primero.
\nEl comportamiento no se explica únicamente por la personalidad del modelo. En OpenCode V1, la mayoría de los permisos parten de allow; el agente Build tiene acceso amplio y tanto instalar dependencias como ejecutar ssh pasan por bash. Si bash está habilitado, no hay una pausa obligatoria entre la decisión y la ejecución.
La instrucción “preguntame antes” agregaba una convención. El entorno seguía permitiendo actuar sin ella.
\nPara esa configuración V1, la solución durable no es redactar una amenaza más dramática en el prompt. Es configurar bash para que las acciones sensibles sean ask o deny, y quitar del entorno las credenciales que el agente no necesita.
Usar un modelo externo a OpenAI o Anthropic no implica quedar sin controles. Si GLM, DeepSeek, Qwen o cualquier otro modelo corre dentro de OpenCode, las llamadas a herramientas siguen pasando por OpenCode y pueden quedar sometidas a sus permisos.
\nLo que cambia es el grado de integración y previsibilidad:
\nPor eso el modelo no debe ser la frontera. La política tiene que sobrevivir al cambio de proveedor.
\nCodex separa dos dimensiones que suelen mezclarse:
\nLos tres niveles clásicos del sandbox son:
\nread-only;workspace-write;danger-full-access.Pero eso no equivale a tres modos completos de operación. La aprobación se configura aparte mediante políticas como on-request, never o controles granulares por categoría. También existen perfiles de permisos integrados como :read-only, :workspace y :danger-full-access.
El valor de esta separación es que se puede permitir edición dentro del workspace y, al mismo tiempo, exigir aprobación para una escalada o rechazar directamente ciertas clases de solicitud. La referencia actual agrega approvals_reviewer = "user" | "auto_review": cambia quién revisa solicitudes elegibles, no el sandbox ni las acciones ya permitidas dentro de él. Configuración de Codex.
Claude Code ofrece modos de interacción como:
\ndefault, mostrado como Manual;acceptEdits;plan;bypassPermissions cuando está habilitado;auto cuando está disponible en la sesión;dontAsk, que rechaza llamadas que necesitarían preguntar.En auto, un clasificador revisa acciones elegibles; no equivale a aprobación humana en cada paso. bypassPermissions conserva excepciones documentadas y no elimina todos los controles. Permisos actuales.
Además de esos modos, las reglas permiten clasificar herramientas o comandos como allow, ask o deny. bypassPermissions no debe confundirse con “trabajar más rápido”: elimina pausas y sólo tiene sentido dentro de un contenedor o VM donde el alcance ya esté controlado por afuera.
OpenCode usa permisos allow, ask y deny, configurables globalmente y por agente. Puede aplicar reglas a edición, shell, acceso a directorios externos, web, skills y subagentes, incluso discriminando comandos mediante patrones.
En V1, Plan restringe ediciones y bash; --auto aprueba solicitudes que quedarían en ask, respetando deny. V2 cambia el esquema a un array permissions con action, resource y effect, y renombra bash a shell y task a subagent. Su Plan bloquea ediciones salvo archivos de planificación, pero eso no constituye un bloqueo general de shell. Permisos V2.
La conclusión no es que OpenCode carezca de control. Es que hay que diseñarlo: sus defaults priorizan fluidez y no representan automáticamente una política conservadora.
\nLa revisión operativa del 12 de octubre de 2026 agrega una distinción práctica a este principio. Un perfil de rol puede decir “sólo lectura” y, aun así, no haber demostrado que la sesión cargue esas reglas o que todas sus herramientas respeten el límite. En la instalación OMP revisada, el enforcement efectivo seguía sin verificarse y las operaciones LSP requerían atención específica. Eso es un control pendiente de validar, no un sandbox garantizado.
\nEn la integración n8n del mismo caso se retiró un proxy que generaba copias y se pasó a un catálogo positivo de herramientas, un filtro de escrituras acotadas y readback, la lectura posterior que compara el estado real con el cambio permitido. Los registros revisados muestran pruebas positivas y negativas para ese circuito; no demuestran todos los posibles modos de falla. No se midieron fallo, salida inválida ni timeout del hook, por lo que lectura posterior y recuperación siguieron siendo necesarias.
\nEl aprendizaje no es que un filtro vuelva segura cualquier herramienta. Es que la autorización debe describir el objeto y la operación, la comprobación debe observar su efecto y los límites no probados deben permanecer visibles. La autonomía LIVE pequeña del caso V4 depende de ese alcance explícito; no permite aplicar la misma autoridad a cualquier agente o proyecto.
\nMás que memorizar nombres de modos que cambian entre herramientas, conviene definir capacidades estables.
\nUso: discovery, auditoría, planificación y revisión.
\nUso: desarrollo cotidiano con intervención humana en cambios de superficie.
\nUso: tareas bien especificadas y fáciles de validar.
\nUso: trabajos largos donde las pausas manuales cuestan más que recrear el entorno.
\nEste ejemplo conserva el formato V1: no lo copies como configuración V2. En V2 hay que migrar reglas y probar sus efectos; renombrar una clave no convierte el objeto en el array requerido. Este perfil permite exploración local, pregunta antes de editar o instalar y bloquea accesos que no deberían ocurrir desde un worker común:
\n{\n \"$schema\": \"https://opencode.ai/config.json\",\n \"permission\": {\n \"*\": \"ask\",\n \"read\": \"allow\",\n \"glob\": \"allow\",\n \"grep\": \"allow\",\n \"list\": \"allow\",\n \"lsp\": \"allow\",\n \"edit\": \"ask\",\n \"external_directory\": \"deny\",\n \"bash\": {\n \"*\": \"ask\",\n \"git status*\": \"allow\",\n \"git diff*\": \"allow\",\n \"git log*\": \"allow\",\n \"rg *\": \"allow\",\n \"npm install*\": \"ask\",\n \"pnpm add*\": \"ask\",\n \"ssh *\": \"ask\",\n \"scp *\": \"ask\",\n \"rsync *\": \"ask\",\n \"docker *\": \"ask\",\n \"git push*\": \"deny\",\n \"sudo *\": \"deny\",\n \"rm -rf *\": \"deny\",\n \"*deploy*\": \"deny\"\n }\n }\n}OpenCode evalúa reglas por coincidencia y prevalece la última que coincide, por eso el catch-all aparece primero y las excepciones después.
\nEste ejemplo es una base editorial, no una configuración universal. Cada proyecto debe declarar sus comandos seguros y sus operaciones prohibidas. Un patrón demasiado amplio como *deploy* también puede bloquear comandos inocentes con ese texto; la política real debe probarse con el CLI y versión utilizados.
La prueba negativa es clave. Ver que git status funciona no demuestra que ssh producción esté bloqueado.
El enforcement evita acciones no autorizadas, pero una buena instrucción reduce intentos inútiles y mejora el razonamiento:
\nTrabajás en un entorno guiado.\n\nPodés inspeccionar el repositorio y ejecutar validaciones locales de solo lectura.\nAntes de editar, instalar dependencias, usar red privada o iniciar una conexión SSH,\nexplicá por qué es necesario y solicitá aprobación.\n\nNo realices push, deploy, migraciones ni cambios externos.\nSi una acción necesaria está bloqueada, no busques una vía alternativa:\ndetenete y entregá el comando o cambio propuesto para revisión humana.La frase más importante es no busques una vía alternativa. Un agente orientado a completar objetivos puede interpretar un bloqueo como un obstáculo técnico que debe resolver. La instrucción aclara que, en este contexto, el bloqueo es una decisión de gobierno.
\nUn buen entorno no intenta adivinar si el modelo será obediente. Parte de que cualquier modelo puede equivocarse, olvidar contexto o perseguir el objetivo con demasiado entusiasmo.
\nLa calidad del modelo determina cuánto trabajo útil produce dentro del perímetro. La calidad del entorno determina cuánto daño puede producir fuera de él.
\n\n\nDocumentación externa revisada el 12 de octubre de 2026. Se conservan los casos históricos y las decisiones operativas del entorno.
\n
Trabajar desde Codex, Claude Code u OpenCode en una terminal no vuelve más capaz al modelo que conversa en una web. Cambia su posición respecto del trabajo.
\nEn un chat sin entorno de ejecución conectado, el modelo recibe una pregunta, archivos elegidos por la persona o una copia del contexto. En un CLI, el agente puede habitar el repositorio: leer su estado actual, inspeccionar el historial, modificar archivos, ejecutar comandos y observar el resultado.
\nLa diferencia útil es contexto entregado versus contexto verificable, y recomendación versus ciclo de ejecución. Esa frontera no coincide necesariamente con navegador versus terminal: Claude Code también puede trabajar sobre repositorios desde la web. Elegí por acceso al entorno, herramientas y permisos, no sólo por la apariencia de la interfaz. Superficies oficiales.
\n\n\nLa diferencia decisiva es si el agente puede inspeccionar, actuar y verificar en el entorno real de ejecución.
\n
El CLI puede recorrer una secuencia completa sin que una persona copie cada resultado:
\nEse feedback reduce la distancia entre lo que el modelo cree y lo que el sistema hace. Una respuesta convincente puede estar equivocada; una prueba ejecutada contra el proyecto ofrece evidencia.
\nDesde la terminal, el agente puede acceder —si el entorno lo permite— a:
\nAGENTS.md o CLAUDE.md;No hace falta comprimir manualmente todo eso en un prompt. El agente puede descubrirlo y citar su evidencia.
\nUn CLI se integra con pipes, scripts, CI, tareas programadas y procesos no interactivos. También permite repetir el mismo método en sesiones distintas: preparar un worktree, ejecutar una auditoría, validar un resultado y producir un artifact.
\nEsto lo vuelve especialmente valioso para un esquema coordinador–workers: una terminal conserva la visión global y otras resuelven tareas acotadas en espacios aislados.
\nLas interfaces web como ChatGPT o Claude son una superficie especialmente cómoda para:
\nLa frontera tampoco es absoluta. Las experiencias web modernas pueden conectar repositorios y ejecutar agentes remotos; los CLIs pueden conversar, investigar y producir documentación. La pregunta correcta es dónde vive el contexto autoritativo y dónde conviene cerrar el loop.
\n| Trabajo | \nSuperficie sugerida | \nMotivo | \n
|---|---|---|
| Explorar una idea o comparar enfoques | \nWeb | \nConversación amplia y mezcla de fuentes | \n
| Entender el comportamiento exacto de un repo | \nCLI | \nAcceso al estado y herramientas reales | \n
| Implementar un cambio multiarchivo | \nCLI en worktree | \nEdición, pruebas y diff trazable | \n
| Producir un informe o guía portable | \nWeb, con evidencia del CLI | \nMejor síntesis sin perder verificación | \n
| Prototipar una dirección visual | \nWeb o canvas | \nIteración visual más directa | \n
| Integrar el prototipo al producto | \nCLI | \nAjuste contra componentes, build y tests | \n
| Automatizar una tarea repetible | \nCLI o SDK | \nEjecución componible y no interactiva | \n
| Operar sobre producción | \nGate humano y entorno restringido | \nLa superficie no reemplaza el control | \n
La terminal también aumenta el radio de impacto. Si el proceso ve claves SSH, tokens cloud, una base productiva y una shell sin restricciones, el agente puede actuar sobre todo eso.
\nPor eso CLI no significa seguro. Significa cercano al sistema. Esa cercanía es una ventaja sólo cuando se acompaña con:
\nallow, ask y deny explícitos;La editorial sobre modelos guiados desarrolla esta idea: las instrucciones orientan, pero el entorno limita.
\nUsar la conversación para clarificar objetivo, audiencia, restricciones, riesgos y criterios de éxito.
\nAbrir el proyecto, verificar el estado real y transformar la intención en un plan apoyado en archivos, comandos y dependencias concretas.
\nDelegar implementaciones, auditorías o pruebas en worktrees separados. Cada worker recibe una tarea verificable y la autoridad mínima necesaria.
\nEl coordinador revisa diffs, corre la suite relevante y resuelve interacciones entre cambios.
\nTraducir el resultado en una guía, decisión o artifact que otra persona —o su agente— pueda reutilizar sin heredar todo el ruido operativo.
\nConviene pasar de la web a la terminal cuando la respuesta depende del estado vivo de un sistema y necesita un ciclo de inspección, acción y verificación. Conviene volver a la web cuando el valor principal está en comprender, decidir o comunicar.
\nNo hay una superficie superior. Hay una superficie más honesta respecto de la tarea.
\n\n\nRevisada el 12 de octubre de 2026. Los nombres, límites y catálogos cambian; verificar las fichas oficiales antes de convertir esta guía en política.
\n
Elegir modelo es asignar capacidad a una tarea. Antes de mirar el selector, conviene responder:
\nUn worker con objetivo acotado, tests claros y poco contexto no necesita el modelo más grande. Un coordinador que debe conservar la intención, detectar conflictos entre cinco cambios y decidir qué integrar sí puede justificarlo.
\nLa regla económica es costo por tarea resuelta, no costo por token. Un modelo barato que entra en loops, falla pruebas o necesita tres reintentos puede resultar más caro que uno superior usado una sola vez.
\nAntes de cambiar de familia o subir al modelo premium:
\nSubir razonamiento sirve cuando el modelo puede resolver el problema pero necesita explorar más. Subir de modelo sirve cuando aparece una brecha de capacidad: pierde relaciones, no sostiene el horizonte, juzga mal los tradeoffs o repite el mismo tipo de error.
\n| Modelo | \nRol sugerido | \nTareas recomendadas | \nCuándo subir | \n
|---|---|---|---|
| GPT-6 Luna | \nWorker rápido y eficiente | \nExtracción, resúmenes, tests, documentación y cambios locales verificables | \nLa tarea requiere juicio sostenido entre archivos | \n
| GPT-6.1 Sol | \nGeneralista fuerte o coordinador, cuando esté disponible | \nCódigo complejo, investigación, herramientas y flujos agénticos con varias restricciones | \nAun con razonamiento alto no sostiene el trabajo de punta a punta | \n
| GPT-6 Astra | \nCoordinador y juez de máxima exigencia | \nArquitectura, síntesis extensa, decisiones ambiguas, investigación profunda y workflows largos | \nReservar para la cola difícil, no como default | \n
Luna es ideal cuando el contrato de la tarea cabe en pocas frases y el resultado tiene una comprobación clara. Sol es el siguiente escalón para trabajo que ya necesita interpretación, autonomía y coordinación.
\nPasar a Sol cuando aparezcan varias de estas señales:
\nAstra se justifica cuando el problema combina amplitud, ambigüedad y consecuencias: no sólo debe escribir bien, sino preservar coherencia durante un proceso largo y juzgar el conjunto.
\nGPT-6.1 Sol es la recomendación actual de OpenAI para código complejo cuando la cuenta y el cliente lo habilitan. GPT-6 Sol y GPT-5.6 siguen siendo alternativas durante el despliegue. La disponibilidad depende del plan, el cliente y el workspace; cambiar el nombre en una configuración no concede acceso. Modelos y disponibilidad.
\nHaiku 5.5 se publicó el 7 de octubre y Sonnet 5.5 el 28 de septiembre de 2026. Son versiones del catálogo de Anthropic; cada proveedor y harness debe exponerlas por separado. Haiku · Sonnet.
\n| Modelo | \nRol sugerido | \nTareas recomendadas | \nCuándo subir | \n
|---|---|---|---|
| Claude Haiku 5.5 | \nWorker veloz | \nClasificación, extracción, cambios repetitivos, subagentes acotados y tareas de alto volumen | \nFalta consistencia o el trabajo exige razonamiento entre varias piezas | \n
| Claude Sonnet 5.5 | \nDefault equilibrado | \nDesarrollo cotidiano, análisis, contenido, uso de herramientas y agentes con alcance medio | \nEl horizonte se alarga o el costo del juicio incorrecto aumenta | \n
| Claude Opus 5.5 | \nCoordinador senior | \nCoding agente complejo, planificación amplia, revisión crítica y decisiones de alto impacto | \nOpus con esfuerzo alto sigue sin cerrar el problema | \n
| Claude Fable 5.1 | \nFrontera para la cola difícil | \nRazonamiento muy demandante y trabajo agente de largo horizonte | \nUsar de forma selectiva y medir si mejora la tasa de resolución | \n
Haiku funciona mejor como ejecutor de unidades pequeñas y comprobables. Sonnet es un punto de partida práctico cuando la tarea necesita comprender intención además de seguir instrucciones. La documentación actual de Anthropic recomienda comenzar con Opus 5.5 para la mayoría de los trabajos; esta guía prioriza el costo por tarea resuelta dentro de una orquestación con workers.
\nSubir de Sonnet a Opus cuando:
\nLa documentación de Anthropic recomienda probar primero más effort cuando el modelo tiene esa opción. Si Opus en sus niveles más altos no alcanza, Fable es hoy el paso siguiente para problemas de frontera.
El nivel de razonamiento es un presupuesto de deliberación, no un multiplicador mágico de inteligencia. En general, más razonamiento implica más tiempo y más tokens, y permite explorar hipótesis, revisar decisiones y sostener pasos intermedios.
\n| Nivel conceptual | \nUsarlo para | \nEvitarlo cuando | \n
|---|---|---|
| Bajo o light | \nEdiciones locales, consultas directas y tareas con camino obvio | \nHay ambigüedad o varias restricciones en tensión | \n
| Medio | \nDesarrollo diario, debugging moderado y decisiones reversibles | \nLa tarea es trivial o extremadamente compleja | \n
| Alto o extra high | \nArquitectura, bugs esquivos, migraciones y síntesis multiarchivo | \nEl resultado se verifica con una transformación simple | \n
| Max | \nUn único modelo necesita agotar una investigación difícil | \nLa tarea puede dividirse mejor entre agentes | \n
| Ultra | \nEl trabajo se separa naturalmente y conviene delegar en subagentes | \nHay una sola pieza indivisible o mucha coordinación accidental | \n
En Codex, Max entrega más deliberación al mismo modelo; Ultra puede delegar automáticamente en subagentes. GPT-6 Luna llega hasta Max, sin Ultra. En Claude, el comportamiento depende del modelo: el pensamiento adaptativo y effort son controles blandos, y Haiku 5.5 admite pensamiento adaptativo y effort, a diferencia de Haiku 4.5. Ficha de Haiku 5.5.
Dos advertencias:
\nprovider/model#variant configuran opciones como esfuerzo o presupuesto; sus nombres y efectos dependen del modelo y proveedor. Variantes.OpenCode Go reúne modelos de varios proveedores y ofrece Go y Go Plus. La tabla siguiente es una heurística editorial de arranque, no un benchmark oficial de OpenCode. Agrupa opciones relevantes del catálogo consultado el 12 de octubre de 2026; la lista exacta y los límites deben comprobarse en /models y en la ficha oficial antes de asignar un worker.
| Opciones del catálogo de Go | \nPunto de partida sugerido | \nPapel inicial | \n
|---|---|---|
| Grok 4.7 y 4.6 | \nRevisión independiente, razonamiento amplio y segunda opinión | \nCoordinador o reviewer selectivo | \n
| GLM 5.3 Flash, 5.3, 5.2 | \n5.3 Flash para trabajo acotado; 5.3 para planificación y cambios cruzados | \nWorker económico; 5.3 como escalamiento | \n
| GPT-6 Luna y GPT-5.6 Luna | \nGPT-6 Luna para implementación, refactors, tests y documentación verificable; 5.6 como fallback probado | \nWorker general | \n
| Kimi K3, K2.7 Code, K2.6 | \nK2.7 Code para código; K3 para síntesis y tareas más exigentes | \nWorker de código; K3 selectivo | \n
| LongCat 2.0 | \nMantenimiento simple, lotes y tareas repetibles | \nWorker de volumen | \n
| MiMo V2.6 Flash y Pro; V2.5 y Pro | \nV2.6 Flash para tareas baratas y comprobables; Pro cuando hace falta más juicio; V2.5 como fallback | \nWorker económico | \n
| MiniMax M3 y M2.7 | \nM3 como generalista; M2.7 como fallback evaluado | \nWorker general | \n
| Muse Spark 1.3 y 1.2 Contributor (regiones limitadas) | \nImplementación, tests y docs con alcance bien delimitado | \nContributor acotado | \n
| Qwen3.8 Max, 3.8 Flash, 3.7 Plus | \n3.8 Flash para volumen; 3.8 Max para planificación y revisión | \nWorker o reviewer según variante | \n
| DeepSeek V4.1 Flash, V4 Pro, V4 Flash, V4 Flash Vision Exp | \nV4.1 Flash para trabajo corriente; Pro para debugging/revisión; Vision para insumos visuales | \nWorker especializado | \n
| Hy4 preview y Hy3 | \nHy4 sólo en sandbox de evaluación; Hy3 después de una prueba contra el repo | \nExperimental o worker evaluado | \n
| LongCat 2.5 Preview Free y Step 5 Preview Free | \nProbar sólo con tareas reproducibles y sin depender de su disponibilidad futura | \nExperimentación temporal | \n
| Claude Haiku 5.5 | \nExtracción, clasificación y subagentes acotados | \nWorker de volumen | \n
| Space Bunny | \nEvaluar cambios pequeños con tests | \nWorker experimental | \n
Los cupos de cinco horas, semana y mes se expresan en dólares de uso por modelo: los recuentos de solicitudes son estimaciones, no cantidades garantizadas. Una opción barata puede tener un cupo menor; las variantes gratuitas son temporales. Catálogo y límites.
\nPara cada familia que parezca prometedora, construir un set pequeño de tareas reales:
\nMedir tasa de resolución, reintentos, tiempo, costo y respeto del contrato. La elección final puede diferir por repositorio: un modelo excelente programando puede ser un coordinador mediocre, y uno muy convincente puede ignorar límites operativos si el entorno no los aplica.
\nLas versiones anteriores del catálogo sirven como fallback cuando una integración o comportamiento está validado, pero no deberían conservarse por inercia. Las variantes preview o Exp deben permanecer fuera del camino crítico hasta superar una evaluación propia.
| Responsabilidad | \nCapacidad mínima útil | \nEscalamiento | \n
|---|---|---|
| Discovery de sólo lectura | \nModelo rápido con razonamiento bajo | \nSubir si omite relaciones importantes | \n
| Cambio aislado con tests | \nWorker económico con razonamiento bajo o medio | \nMejorar el contrato; luego subir modelo | \n
| Bug multiarchivo | \nGeneralista con razonamiento medio o alto | \nEscalar si repite hipótesis fallidas | \n
| Coordinación de varios workers | \nModelo fuerte con razonamiento alto | \nModelo frontera si no integra el panorama | \n
| Auditoría de seguridad o arquitectura | \nModelo fuerte y segunda opinión de otra familia | \nEscalar por desacuerdo o evidencia incompleta | \n
| Acción irreversible | \nNingún modelo decide solo | \nGate humano y enforcement externo | \n
El selector no es una jerarquía de empleados. Es una caja de cambios: el mejor nivel es el que entrega suficiente control y potencia sin gastar complejidad donde no agrega valor.
\nUn backend puede compilar y aun así fallar al iniciar. El build verifica que sus pasos terminaron; no demuestra que el proceso de producción resuelva sus imports, cargue la configuración, abra el puerto y responda una petición.
\nEn un incidente real, un archivo de entrada terminó con contenido duplicado. La publicación avanzó, pero el servidor entró en un ciclo de fallas por declaraciones repetidas. La recuperación exigió corregir el código y volver a publicar. El problema que importaba ya estaba en el repositorio: faltaba una prueba capaz de verlo antes del deploy.
\nSi un generador, un merge o un agente modifica el punto de arranque, revisá el diff y ejecutá la comprobación sintáctica del runtime. Detectá duplicaciones evidentes de imports, inicialización del servidor o bloques completos antes de dar por terminado el cambio.
\nEsta revisión es específica del proyecto: no alcanza con buscar una cadena repetida y asumir que toda repetición es un error.
\nEjecutá el comando de producción en un entorno de prueba con la configuración necesaria. Esperá a que el proceso abra el puerto y hacé una solicitud HTTP a un endpoint liviano. Si el proceso muere o la solicitud falla, la publicación queda bloqueada.
\nNo sustituyas esta comprobación por el modo de desarrollo. Los scripts, variables, bundlers y rutas de imports pueden ser distintos.
\nUna secuencia mínima, adaptada al proyecto, se parece a esto:
\nnpm run build\nPORT=5000 npm run start\n# En otra terminal:\ncurl --fail --show-error http://127.0.0.1:5000/healthEl ejemplo supone que existen start y /health; usá los nombres reales del servicio. El proceso debe poder cerrarse limpiamente al terminar la prueba.
Configurá el healthcheck del hosting para que una publicación sólo se considere lista cuando el backend responde. Una página estática o un proceso iniciado durante un instante no prueban que la API esté operativa.
\nEl endpoint de salud debería ser barato y representar la capacidad que necesitás para servir tráfico. Si depende de servicios externos, distinguí entre proceso vivo y servicio listo para evitar reinicios causados por una dependencia temporalmente caída.
\nCada paso responde una pregunta distinta. Un check verde no reemplaza al siguiente.
\nEl contrato de la tarea tiene que pedir evidencia concreta: comando ejecutado, salida relevante, código de respuesta HTTP y resultado del despliegue. La frase «funciona» no alcanza para cruzar el límite de producción.
\nSi el preflight falla, el agente corrige y repite la prueba. Si falta configuración que sólo existe en producción, registra qué pudo verificar y qué queda pendiente para un entorno equivalente; no convierte una suposición en aprobación.
\nLos registros del caso operativo revisados el 12 de octubre de 2026 aportan otra variante del mismo problema. Una integración n8n había pasado 56 tests, auditoría y revisión estática, pero todavía no había ejecutado su nodo HTTP real. La primera petición real al workflow ya publicado falló en su nodo HTTP. Es un resultado de ese circuito y esa configuración, no un defecto universal de n8n ni una prueba de que los tests fueran inútiles: faltaba cubrir el camino que producía el efecto.
\nEn la aceptación posterior quedaron registrados dos recorridos: modificar un parámetro autorizado, publicar, leer el estado y comprobar la respuesta del webhook; después restaurar, volver a publicar y verificar que el webhook recuperara el comportamiento original. Restaurar una definición sin comprobar la versión activa no cerraba el ciclo.
\nEsta evidencia fue leída en los registros del proyecto, no reproducida para esta editorial. Tampoco cubrió fallos o timeouts del hook de control. La distinción vigente es útil para cualquier handoff: listo local no es aplicado; aplicado no es aceptado. El postflight inmediato prueba una condición puntual; cuando el objetivo depende del uso habitual, hace falta observar el ciclo natural acordado antes de cerrar. Ver la evolución del cockpit.
\nLa publicación empieza antes del botón de deploy. Primero hay que demostrar que el mismo programa que va a recibir tráfico puede arrancar y responder. Después, el hosting tiene que negarse a declarar exitoso un despliegue que no supera esa prueba.
\n\n\n", "headings": [ { "label": "El falso positivo del build verde", "depth": 2, "id": "el-falso-positivo-del-build-verde" }, { "label": "Tres controles, tres preguntas distintas", "depth": 2, "id": "tres-controles-tres-preguntas-distintas" }, { "label": "1. ¿El archivo de entrada conserva una estructura válida?", "depth": 3, "id": "1-el-archivo-de-entrada-conserva-una-estructura-valida" }, { "label": "2. ¿Arranca el comando que usa producción?", "depth": 3, "id": "2-arranca-el-comando-que-usa-produccion" }, { "label": "3. ¿El despliegue espera una respuesta saludable?", "depth": 3, "id": "3-el-despliegue-espera-una-respuesta-saludable" }, { "label": "El orden importa", "depth": 2, "id": "el-orden-importa" }, { "label": "Cuando trabaja un agente", "depth": 2, "id": "cuando-trabaja-un-agente" }, { "label": "Del test local al efecto publicado", "depth": 2, "id": "del-test-local-al-efecto-publicado" }, { "label": "Regla transferible", "depth": 2, "id": "regla-transferible" } ], "raw": "---\nslug: preflight-despliegue-backend\ntitle: Antes de publicar, probá el arranque real\ntype: guide\norder: 12\nsummary: \"Un build exitoso no garantiza que el backend pueda iniciar. Un preflight con el comando de producción y un healthcheck bloqueante cierran esa brecha.\"\ntags: [deploy, backend, preflight, healthcheck, produccion, agentes]\nrelated: [modelos-guiados-el-entorno-es-la-politica, continuidad-y-observabilidad, orquestacion]\narea: Gobierno de agentes\nglyph: ◉\nhue: rgba(237,195,94,.25)\n---\n\n# Antes de publicar, probá el arranque real\n\n## El falso positivo del build verde\n\nUn backend puede compilar y aun así fallar al iniciar. El build verifica que sus pasos terminaron; no demuestra que el proceso de producción resuelva sus imports, cargue la configuración, abra el puerto y responda una petición.\n\nEn un incidente real, un archivo de entrada terminó con contenido duplicado. La publicación avanzó, pero el servidor entró en un ciclo de fallas por declaraciones repetidas. La recuperación exigió corregir el código y volver a publicar. El problema que importaba ya estaba en el repositorio: faltaba una prueba capaz de verlo antes del deploy.\n\n## Tres controles, tres preguntas distintas\n\n### 1. ¿El archivo de entrada conserva una estructura válida?\n\nSi un generador, un merge o un agente modifica el punto de arranque, revisá el diff y ejecutá la comprobación sintáctica del runtime. Detectá duplicaciones evidentes de imports, inicialización del servidor o bloques completos antes de dar por terminado el cambio.\n\nEsta revisión es específica del proyecto: no alcanza con buscar una cadena repetida y asumir que toda repetición es un error.\n\n### 2. ¿Arranca el comando que usa producción?\n\nEjecutá el comando de producción en un entorno de prueba con la configuración necesaria. Esperá a que el proceso abra el puerto y hacé una solicitud HTTP a un endpoint liviano. Si el proceso muere o la solicitud falla, la publicación queda bloqueada.\n\nNo sustituyas esta comprobación por el modo de desarrollo. Los scripts, variables, bundlers y rutas de imports pueden ser distintos.\n\nUna secuencia mínima, adaptada al proyecto, se parece a esto:\n\n```bash\nnpm run build\nPORT=5000 npm run start\n# En otra terminal:\ncurl --fail --show-error http://127.0.0.1:5000/health\n```\n\nEl ejemplo supone que existen `start` y `/health`; usá los nombres reales del servicio. El proceso debe poder cerrarse limpiamente al terminar la prueba.\n\n### 3. ¿El despliegue espera una respuesta saludable?\n\nConfigurá el healthcheck del hosting para que una publicación sólo se considere lista cuando el backend responde. Una página estática o un proceso iniciado durante un instante no prueban que la API esté operativa.\n\nEl endpoint de salud debería ser barato y representar la capacidad que necesitás para servir tráfico. Si depende de servicios externos, distinguí entre **proceso vivo** y **servicio listo** para evitar reinicios causados por una dependencia temporalmente caída.\n\n## El orden importa\n\n1. Revisar el diff del punto de entrada.\n2. Correr build y comprobación sintáctica.\n3. Levantar el comando real en un entorno de prueba.\n4. Probar una respuesta HTTP.\n5. Publicar con healthcheck bloqueante.\n6. Confirmar la respuesta desde la URL desplegada.\n\nCada paso responde una pregunta distinta. Un check verde no reemplaza al siguiente.\n\n## Cuando trabaja un agente\n\nEl contrato de la tarea tiene que pedir evidencia concreta: comando ejecutado, salida relevante, código de respuesta HTTP y resultado del despliegue. La frase «funciona» no alcanza para cruzar el límite de producción.\n\nSi el preflight falla, el agente corrige y repite la prueba. Si falta configuración que sólo existe en producción, registra qué pudo verificar y qué queda pendiente para un entorno equivalente; no convierte una suposición en aprobación.\n\n## Del test local al efecto publicado\n\nLos registros del caso operativo revisados el 12 de octubre de 2026 aportan otra variante del mismo problema. Una integración n8n había pasado 56 tests, auditoría y revisión estática, pero todavía no había ejecutado su nodo HTTP real. La primera petición real al workflow ya publicado falló en su nodo HTTP. Es un resultado de ese circuito y esa configuración, no un defecto universal de n8n ni una prueba de que los tests fueran inútiles: faltaba cubrir el camino que producía el efecto.\n\nEn la aceptación posterior quedaron registrados dos recorridos: modificar un parámetro autorizado, publicar, leer el estado y comprobar la respuesta del webhook; después restaurar, **volver a publicar** y verificar que el webhook recuperara el comportamiento original. Restaurar una definición sin comprobar la versión activa no cerraba el ciclo.\n\nEsta evidencia fue leída en los registros del proyecto, no reproducida para esta editorial. Tampoco cubrió fallos o timeouts del hook de control. La distinción vigente es útil para cualquier handoff: **listo local no es aplicado; aplicado no es aceptado**. El postflight inmediato prueba una condición puntual; cuando el objetivo depende del uso habitual, hace falta observar el ciclo natural acordado antes de cerrar. Ver [la evolución del cockpit](/entrada/caso-orca-cockpit-multiagente).\n\n## Regla transferible\n\n**La publicación empieza antes del botón de deploy.** Primero hay que demostrar que el mismo programa que va a recibir tráfico puede arrancar y responder. Después, el hosting tiene que negarse a declarar exitoso un despliegue que no supera esa prueba.\n\n> Caso basado en un incidente real. Se omitieron nombres, fechas, repositorios y detalles operativos identificables.\n" }, { "slug": "amp-fabrica-agentes-cloud", "title": "Amp y la fábrica de agentes en la nube", "summary": "Amp empaqueta agente, máquina, contexto y Git en una sola superficie. No inventa el desarrollo multiagente, pero vuelve producto una práctica que todavía solemos construir a mano.", "type": "editorial", "order": 13, "tags": [ "amp", "orbs", "agentes", "cloud", "orca", "github", "multi-modelo", "automatizaciones" ], "related": [ "orquestacion", "caso-orca-cockpit-multiagente", "workspaces-y-worktrees", "guia-escalado-modelos" ], "area": "Gobierno de agentes", "glyph": "◌", "hue": "rgba(87,217,232,.22)", "file": "amp-fabrica-agentes-cloud.md", "html": "Caso basado en un incidente real. Se omitieron nombres, fechas, repositorios y detalles operativos identificables.
\n
\n\nVigencia editorial: 12 de octubre de 2026. Amp declara una filosofía de frontera y sin compromiso de compatibilidad hacia atrás; modelos, routing, precios y funciones pueden cambiar con rapidez.
\n
Amp no resulta interesante porque haya inventado otro agente capaz de editar archivos. Ese espacio ya está lleno. Lo atractivo es que intenta convertir en producto todo lo que rodea al agente: la máquina donde trabaja, el contexto que conserva, el repositorio que modifica, las pruebas que ejecuta, los agentes que coordina y la continuidad necesaria para terminar aunque la computadora del usuario esté apagada.
\nEn otras palabras, Amp comercializa una versión ordenada de una fábrica que muchos equipos todavía arman artesanalmente con CLIs, worktrees, sesiones persistentes, servidores y bastante disciplina operativa.
\nUna conversación puede producir una buena idea, pero el desarrollo real exige un entorno. Hay que clonar código, instalar dependencias, ejecutar servicios, inspeccionar CI, probar la aplicación y devolver cambios revisables.
\nAmp reúne esas piezas alrededor de sus Threads y Orbs. Un Thread conserva la conversación y el trabajo; un Orb es una máquina remota aislada, creada para ese hilo, con su propia copia del repositorio y sus herramientas. Puede seguir ejecutándose cuando el usuario cierra la notebook, dormirse cuando queda inactivo y despertar después con archivos, servicios e historial disponibles.
\nLa novedad no está en ninguna pieza aislada. Está en tratarlas como una sola unidad operativa:
\nagente + contexto + máquina + código + evidencia.
\nEsa combinación permite pedir algo más exigente que “escribí esta función”. Se le puede pedir que implemente el cambio, levante el sistema, lo pruebe de punta a punta y deje una rama o un pull request acompañado por evidencia.
\nAmp ofrece cuatro modos de base en The Dial: low, medium, high y ultra. La idea es elegir según la dificultad y el costo de equivocarse, no enamorarse del nombre de un modelo.
| Modo | \nLectura práctica | \n
|---|---|
low | \nCambios chicos, tests y refactors con resultado evidente | \n
medium | \nDesarrollo cotidiano con algo de ambigüedad o varios pasos | \n
high | \nTrabajo delicado que debería llegar cerca de una revisión final | \n
ultra | \nArquitectura, migraciones y problemas abiertos entre varios sistemas | \n
Detrás de cada posición, Amp puede combinar modelo principal, nivel de razonamiento, herramientas, instrucciones, subagentes y un Oracle que aporta una segunda opinión. El routing automático cambia cuando aparecen mejores modelos, mientras que la intención del modo permanece estable.
\nLa abstracción es sana: una organización no debería reescribir su política cada vez que cambia el ranking de proveedores. “Usar capacidad alta cuando una omisión sutil sería cara” envejece mejor que “usar siempre el modelo X”.
\nSin embargo, Amp no obliga a entregar todo el control. Es posible fijar modelos y esfuerzo por separado para el agente principal, el Oracle y los subagentes, además de definir modos personalizados mediante plugins.
\nEl Dial se puede personalizar, pero el modo de un Thread queda fijado al enviar su primer mensaje: cambiarlo exige abrir otro hilo. Conviene elegir el esfuerzo antes de empezar.
\nAmp distingue entre subagentes especializados y agentes completos ejecutados en otros Threads.
\nLos subagentes internos sirven para búsquedas, investigación, lectura de conversaciones previas y consultas difíciles al Oracle. Trabajan con una ventana de contexto separada y devuelven un resumen al agente principal. Mantienen limpio el hilo central, aunque tienen límites claros: no conversan entre sí y no pueden ser orientados a mitad del trabajo.
\nLa delegación entre agentes completos es más ambiciosa. Un agente puede iniciar otro Thread en un Orb, transferirle instrucciones o archivos y continuar trabajando mientras espera el resultado. Cada hilo obtiene su propia conversación, copia de trabajo y máquina. Eso habilita fan-out real: varias investigaciones, navegadores, resoluciones o proyectos avanzando en paralelo.
\nEl aislamiento es deliberado. Los archivos sin commit y los cambios no aparecen mágicamente en los otros entornos; deben transferirse o integrarse de forma explícita. Esa fricción evita bastante caos, pero no elimina la necesidad de un buen coordinador.
\nAmp y Orca se pisan, pero no son exactamente el mismo producto.
\n| Dimensión | \nCockpit con Orca y CLIs | \nAmp | \n
|---|---|---|
| Unidad de trabajo | \nSesión, terminal y worktree administrados por el usuario | \nThread con working copy y Orb aislado | \n
| Infraestructura | \nMáquina local, WSL, SSH y servidores propios | \nOrbs cloud, ejecución local o runners propios | \n
| Selección de modelos | \nExplícita y granular por herramienta | \nRouting por dificultad, con posibilidad de fijarlo | \n
| Coordinación | \nFlexible, visible y artesanal | \nDelegación integrada entre subagentes y Threads | \n
| Continuidad | \nDepende de procesos y hosts administrados | \nEl Orb sigue trabajando y se pausa automáticamente | \n
| GitHub | \nCredenciales y flujo del entorno local | \nGitHub App, tokens breves, branches, PR y CI integrados | \n
| Dependencia de plataforma | \nMenor: piezas intercambiables | \nMayor: Orbs, Threads y coordinación viven en Amp | \n
Orca funciona especialmente bien como cabina de mando. Permite observar varias herramientas, elegir deliberadamente qué CLI y qué proveedor ocupa cada rol, intervenir sesiones y conservar control sobre la infraestructura.
\nAmp funciona más como una fábrica administrada. Entrega entornos remotos descartables, continuidad, aislamiento y un camino directo desde la consigna hasta una PR. Reduce trabajo operativo a cambio de aceptar más decisiones y más infraestructura de la plataforma.
\nNo hay un ganador universal. Hay dos preferencias distintas: gobernar cada pieza o comprar una unidad de ejecución ya resuelta.
\nLa integración con GitHub está pensada para trabajar sin distribuir tokens permanentes dentro de cada Orb. Amp usa una GitHub App y entrega credenciales breves cuando Git o gh necesitan comunicarse. Puede clonar repositorios privados, crear ramas y pull requests, consultar CI y firmar commits; las reglas de protección siguen aplicándose como si actuara el usuario.
Es una base razonable para equipos, pero la prudencia sigue siendo la misma: empezar con repositorios seleccionados, permisos mínimos y ramas protegidas. Que un agente tenga una máquina aislada no significa que deba recibir acceso a toda la organización.
\nLas automatizaciones de Amp permiten que un Thread se reactive una vez o de forma recurrente conservando su historia. Puede revisar errores cada hora, observar un proceso largo, verificar CI después de un cambio o recordar el retiro de un feature flag.
\nEso es más expresivo que un cron aislado porque el agente retoma decisiones y evidencia anteriores. También es más riesgoso si la consigna es vaga o los permisos son amplios. Una automatización agéntica necesita:
\nLa continuidad no reemplaza al gobierno. Lo vuelve más importante.
\nLa tarifa actual combina planes mensuales y pago por uso; distingue consumo de agentes y herramientas de la asignación de Orbs. Los Orbs se miden por minuto, los tamaños mayores consumen más asignación y la pausa no genera costo.
\nSe pueden conectar claves o suscripciones compatibles, pero hay que revisar el routing efectivo. La suscripción de Claude cubre el modo Claude Code, no los modos propios de Amp. Con ChatGPT, las llamadas y herramientas no cubiertas siguen consumiendo créditos de Amp; la suscripción tampoco cubre el Orb. Detalle por modo.
\nPara evaluar el producto no alcanza con comparar precio por token. Hay que medir:
\nUn agente barato que necesita tres rondas no necesariamente es económico. Un Orb que cuesta centavos puede ahorrar una hora de preparación o, si queda sobredimensionado y mal controlado, sumar gasto sin mejorar el resultado.
\nAmp no debería reemplazar de golpe un entorno multiagente que ya funciona. La prueba útil es acotada:
\nLos primeros casos adecuados son features autónomas que terminan en PR, investigaciones largas que no conviene ejecutar localmente y tareas paralelas entre repositorios. Producción, secretos amplios y automatizaciones con capacidad de mutación deberían llegar después de validar el comportamiento real.
\nAmp no reemplaza la necesidad de pensar cómo trabajan los agentes. La vuelve visible como producto.
\nSu aporte más fuerte no es prometer un modelo milagroso, sino reconocer que la calidad del desarrollo agéntico depende tanto del entorno como de la inteligencia: aislamiento, continuidad, herramientas, permisos, coordinación y evidencia.
\nPara quien ya construyó un cockpit artesanal, Amp puede sentirse menos como una revolución y más como una industrialización. La pregunta no es si puede escribir código. La pregunta es cuánto control conviene conservar y cuánto trabajo operativo vale la pena delegar a la plataforma.
\nGuía de seguimiento para elegir qué modelos probar
\nRecorrido de interfaz del 3 de octubre de 2026 · Revisión documental del 12 de octubre de 2026. En esta última consulta, la portada mostraba datos de uso hasta el 11 de octubre.
\nUn ranking resulta útil cuando ayuda a tomar una decisión concreta: qué modelo conviene probar, para qué trabajo y con qué costo de equivocarse. El problema aparece cuando una posición se convierte en una conclusión que la medición nunca prometió.
\nOpenRouter reúne señales de uso real, gasto, velocidad y evaluaciones de capacidad. La propuesta de esta guía es recorrer sus secciones, identificar qué cuenta cada una y convertirlas en un seguimiento repetible. Primero elegimos qué observar; después verificamos si esa señal mejora nuestro trabajo.
\nEl recorrido principal cubre las trece subsecciones de Text. También incluye las otras pestañas de Rankings y sus unidades. Los nombres y controles del recorrido corresponden al 3 de octubre; los ejemplos numéricos son didácticos y no presentan ganadores actuales. [1]
\nAntes de comparar dos modelos, anotá cinco cosas: unidad, población, ventana temporal, agregación y condiciones. Es una ficha mínima que evita conclusiones enormes a partir de números pequeños.
\nUnidad: tokens, solicitudes, dólares, segundos o puntos de un benchmark. Un cambio de unidad cambia la pregunta.
\nPoblación: todo el tráfico elegible, una muestra clasificada, un idioma, una aplicación o una prueba concreta.
\nVentana: un día completo, siete días, treinta días o la fecha de un experimento. La fecha de consulta no reemplaza a la fecha de los datos.
\nAgregación: suma, cuota, variación, mediana o índice compuesto. Un promedio y una mediana pueden contar historias diferentes.
\nCondiciones: versión, variante, proveedor, esfuerzo de razonamiento, caché, herramientas y harness. El mismo nombre puede cubrir configuraciones distintas.
\nOpenRouter observa el tráfico que pasa por su plataforma y entra en cada dataset público. Esa población no permite inferir por sí sola la cuota mundial de un laboratorio, su número de clientes o todo su negocio. Los datos privados y las exclusiones documentadas también importan. [2]
\nEs el panorama histórico del volumen semanal de tokens. Permite ver qué modelos sostienen actividad, cuáles aparecen de golpe y cómo cambia el tamaño total del tráfico. La visualización destaca nueve modelos y agrupa el resto en Others. La unidad suma entrada y salida; cada variante se trata por separado. [1]
\nCómo seguirlo: compará varias semanas, registrá la escala y mirá el total además de cada color. La escala lineal ayuda a dimensionar diferencias absolutas; la logarítmica facilita ver órdenes de magnitud. Cambiar de escala no modifica los datos, pero sí su apariencia.
\nQué evitar: interpretar más tokens como más personas o más productividad. Un agente que relee un repositorio, encadena turnos o genera respuestas largas puede mover mucho volumen. Los tokenizadores tampoco segmentan el texto de manera idéntica entre proveedores. [7]
\nLa tabla permite ordenar ese uso y elegir modelos abiertos, cerrados o todos. Today, This Week y This Month abarcan respectivamente 1, 7 y 30 días completos, con cierre en UTC. New & Trending compara los últimos siete días con los siete anteriores; exige un millón de tokens en la ventana actual y puede anteponer hasta cinco modelos nuevos. [1]
\nEl crecimiento compara volúmenes: pasar de 10 a 15 millones de tokens representa un aumento del 50%. No significa subir cincuenta puntos de cuota. Y new señala falta de una base previa comparable, no una tasa de crecimiento infinita.
\nCómo seguirlo: conservá una vista semanal para la tendencia y una mensual para la persistencia. Separá lanzamientos, variantes gratuitas y versiones estables. Un filtro de apertura cambia el conjunto comparado; no certifica licencias, permisos de uso ni calidad del modelo.
\nEsta sección acerca el ranking al trabajo concreto. Permite alternar Share of spend y Share of tokens. Las tareas se infieren sobre una muestra de prompts y la interfaz indica que corrige las magnitudes por muestreo. La documentación del Auto Router vincula la vista de gasto con una ventana móvil de siete días. [3] [4]
\nEl mapa de rectángulos o treemap contiene dos niveles que conviene leer por separado. El área de una tarea indica cuánto representa dentro del total de la métrica elegida. Al abrirla, la lista muestra la participación de cada modelo dentro de esa tarea. El tamaño de Classification y el porcentaje de un modelo en Classification tienen denominadores diferentes.
\nEjemplo: si una tarea concentra el 10% del gasto y un modelo reúne el 20% del gasto de esa tarea, su porción del total sería el 2%, siempre que ambos porcentajes compartan universo y ventana. Leer el 20% como cuota de todo OpenRouter multiplicaría por diez la interpretación.
\nLos colores distinguen cuatro familias. En la revisión había 29 etiquetas; conservar sus nombres facilita encontrarlas aunque cambie su posición en el gráfico:
\nGeneral: Classification, Content Writing, Roleplay & Fiction, Q&A & Knowledge, Conversation, Research & Reports, Customer Support, Summarization, Security Audit, Math, Finance & Trading, Translation y DevOps
\nAgent: Workflow Execution, Multi-step Planning, Tool Dispatch, Web Search y Memory Extraction
\nCode: Code Generation, Debugging, File I/O, Code Review, Shell Execution, Frontend & UI, Repo Scanning, DevOps & Config y SQL & Database
\nData: Data Extraction y Data Transformation
\nCómo seguirlo: elegí la tarea más cercana a tu trabajo y alterná gasto y tokens. Si un modelo gana mucho más espacio en gasto, investigá precio, longitud, razonamiento y mezcla de trabajo. Si gana en tokens, investigá volumen y variantes gratuitas. Ninguna de esas diferencias identifica por sí sola qué respuestas fueron correctas.
\nLa clasificación es una estimación de la intención del prompt. Una sesión de programación puede pasar por planificación, lectura de archivos, búsqueda, generación y revisión. No conviene tratar cada casillero como una industria separada ni sumar sus posiciones para inventar una nota general.
\nLímite metodológico: la interfaz explica que los deltas comparan con la ventana anterior, pero no desarrolla allí todos sus detalles. Antes de publicar una variación como puntos porcentuales, verificá la definición concreta. Tampoco se publica en estas vistas una ficha completa de tamaño muestral, precisión del clasificador, intervalos de confianza y tratamiento contable del gasto.
\nHay además una diferencia relevante para quien quiera automatizar el seguimiento: la API de clasificaciones documenta cuotas de solicitudes y tokens, excluye other del denominador y ordena modelos por solicitudes. Esos campos no sustituyen automáticamente la cuota de gasto del treemap. Un nombre parecido no garantiza el mismo cálculo. [5]
\nAcá la pregunta pasa al costo observado de una sesión de agente. La unidad es USD por sesión y el resumen es la mediana, separado por harness. La interfaz revisada mostraba Hermes Agent, Claude Code, Kilo Code y Codex, con tramos de 1, 2 a 9, 10 a 49 y 50 o más turnos.
\nEl tooltip define una ventana de 30 días, uso pago y escala logarítmica. Una sesión se atribuye a un modelo cuando ese modelo procesó al menos el 80% de sus tokens. La referencia del dataset confirma que las aplicaciones no se mezclan, que se publican medianas y que el snapshot se actualiza semanalmente. [1] [6]
\nCómo seguirlo: fijá primero el harness y después un tramo comparable. La mediana describe el centro de la distribución: la mitad de las sesiones queda por debajo y la otra mitad por encima. No muestra cuánto cuesta la cola de sesiones difíciles ni alcanza para presupuestar un mes completo.
\nUna sesión barata puede haber sido simple, corta, abortada o fallida. Una larga puede haber resuelto un trabajo valioso. Para decidir en tu entorno, agregá éxito, reintentos y tiempo de revisión. La regla del 80% también limita la lectura de flujos que reparten mucho trabajo entre varios modelos. La delimitación exacta de sesión y los umbrales de publicación no quedan especificados en la referencia consultada.
\nAgrupa por autor del modelo y cuenta solicitudes de texto. Absolute muestra magnitudes; Percentage, la parte de cada autor sobre el total del período. El autor del modelo no necesariamente coincide con la empresa que sirve el endpoint. [1]
\nCómo seguirlo: mirá ambas vistas. Si un autor pasa de 100 a 120 solicitudes mientras el total pasa de 200 a 300, su volumen crece un 20% y su cuota cae de 50% a 40%. Las dos observaciones son compatibles.
\nEsta sección permite detectar cambios en la composición del tráfico. Para explicar la causa necesitás más evidencia: lanzamientos, disponibilidad, precios, integraciones o decisiones de routing. No alcanza con que dos curvas se muevan a la vez. Conservá también la fecha del punto observado; el texto resumido y el gráfico pueden referirse a cortes distintos.
\nEsta es la sección para comparar resultados de evaluaciones. El selector revisado reunía trece métricas de tres familias: evaluaciones ejecutadas por OpenRouter, índices de Artificial Analysis y ratings de Design Arena. Conviene conservar esa procedencia junto al puntaje. [2]
\nGPQA Diamond, τ²-Bench Airline y VGI-Bench: el panel presenta accuracy. Para GPQA Diamond y VGI-Bench, el tooltip precisa mediana de accuracy entre proveedores, medida por OpenRouter. Cada prueba tiene su propio protocolo; conviene abrir su ficha antes de interpretar el porcentaje.
\nIntelligence Index, Coding Index y Agentic Index: son índices compuestos de Artificial Analysis. Sirven para una preselección general, de código o de agentes. Un valor de índice no debe leerse automáticamente como porcentaje de tareas resueltas.
\nCode Categories, UI Component, Game Development, Data Visualization, 3D, Image y SVG ELO: son ratings de Design Arena para comparaciones cara a cara. Su escala es relativa al sistema de evaluación y a sus participantes; 1.500 puntos Elo no equivalen a un 75% de calidad.
\nEn una evaluación de exactitud, el denominador son los casos evaluados bajo un protocolo. En un índice compuesto intervienen varias pruebas y sus reglas de combinación. En Elo intervienen comparaciones y resultados relativos. Estas metodologías responden preguntas diferentes: no conviene promediarlas como si compartieran una escala.
\nGPQA Diamond usa preguntas científicas de opción múltiple. La ficha actual presenta variabilidad entre ejecuciones y costo, y publica snapshots descargables. El protocolo de 90 días descrito en la revisión anterior no pudo reconfirmarse en la ficha accesible el 12 de octubre: no lo extrapoles como regla vigente. El widget y la tabla detallada pueden usar representaciones distintas; citá la vista y el snapshot de los que sale tu cifra. [23]
\nLa siguiente descripción de VGI-Bench se conserva como registro del 3 de octubre: su ficha no pudo reconfirmarse el 12 de octubre. No tomes esos umbrales como un contrato vigente.
\nVGI-Bench significa Video General Intelligence Bench y evalúa comprensión de videos largos. La implementación de OpenRouter entrega el video y una pregunta de opción múltiple en un turno, con temperatura 0, y corrige la letra final. Usa un conjunto público de 439 preguntas, exige al menos 395 respuestas para incluir una ejecución y considera los últimos 90 días. Sirve para investigar comprensión temporal y audiovisual; su accuracy no es una nota de generación de video. [21]
\nτ²-Bench Airline evalúa atención al cliente con un usuario simulado y herramientas de aerolínea. El éxito exige el estado final esperado de la base de datos y los mensajes requeridos, sin crédito parcial. La ficha fija el simulador, limita la ejecución a 200 pasos y agrega pruebas de 90 días ponderadas por tareas, con mínimo de 45 por pareja modelo y proveedor. Su resultado principal usa routing predeterminado si existe; en otro caso, la mediana entre proveedores. Esa regla de la ficha detallada no debe generalizarse a todo el widget. [22]
\nTambién cambia el eje económico. El gráfico ofrece Weighted Avg Input Price, Input List Price y Avg Price Per 100 Requests. Las dos primeras vistas se expresan por millón de tokens de entrada; la tercera usa solicitudes. El precio efectivo de las fichas incorpora el uso observado, donde caché y descuentos pueden separarlo del precio publicado. [9]
\nCómo seguirlo: fijá el benchmark y el eje de precio antes de comparar. El precio de entrada deja fuera la salida y otros componentes de tu factura; el promedio por solicitudes depende del tamaño de esas solicitudes. Ninguno equivale sin más a costo por tarea resuelta.
\nShow Pareto ayuda a encontrar opciones que no quedan superadas simultáneamente en las dos dimensiones elegidas. Si dos candidatos tienen la misma nota y uno cuesta menos, el más caro queda dominado en ese gráfico. Esa conclusión puede cambiar al agregar latencia, confiabilidad, permisos o desempeño en español. La frontera visible tampoco representa modelos que el gráfico no incluyó.
\nEl enlace View all benchmarks lleva a un catálogo más amplio con familias Agents, Media, Artifacts, Reasoning y Search. Sus experimentos pueden evaluar también herramientas, motores de búsqueda y presupuestos. Revisá la ejecución concreta: la última fecha general del catálogo no actualiza retrospectivamente cada tarjeta. [8]
\nTiene dos modos: Highest throughput y Lowest latency. El tooltip de elegibilidad admite modelos con al menos 100.000 solicitudes en las últimas 24 horas. Ese umbral describe quién puede aparecer; por sí solo no especifica cómo se agregaron todos los valores de rendimiento.
\nThroughput expresa la velocidad de generación en tokens por segundo. La latencia requiere leer su definición en la vista correspondiente: esperar el primer token y recibir la respuesta completa son experiencias distintas. Las fichas de rendimiento de OpenRouter distinguen TTFT y medidas de latencia; no conviene asumir que todos los paneles usan el mismo percentil o ventana. [10] [11]
\nCómo seguirlo: compará el mismo endpoint, contexto y configuración. Para una respuesta larga importa la velocidad sostenida; para una interacción breve puede dominar la espera inicial. En un agente, sumá además herramientas, turnos y reintentos. Un modelo rápido escribiendo puede tardar más en terminar el trabajo.
\nNo atribuyas automáticamente el mejor rendimiento de un proveedor a todos los que sirven ese modelo. Si la vista no declara el percentil, la ventana o la ponderación entre proveedores, conservá esa limitación en la comparación.
\nPermite segmentar por idioma natural y alternar magnitud absoluta o porcentaje. Los datos por idioma proceden de muestras extrapoladas; la referencia pública los trata como estimaciones semanales. La cuota se interpreta dentro del idioma seleccionado, no sobre todos los idiomas. [7]
\nCómo seguirlo: para un producto en español, mirá español aunque el panorama general esté dominado por inglés. Después probá tareas reales: comprensión de consignas, registro, regionalismos, extracción y fidelidad de las respuestas. El tráfico en un idioma no evalúa por sí mismo la calidad en ese idioma.
\nUna conversación puede mezclar idiomas, código y citas. Sin una definición publicada del clasificador y su error, cambios pequeños merecen cautela. La extrapolación da una estimación de volumen; no elimina el sesgo de selección ni garantiza representatividad de todo uso del español.
\nPara automatizar: los filtros category y language_type usan estimaciones semanales, rechazan period=day y no se combinan con filtros exactos de modalidad/contexto ni entre sí. La última semana puede superar end_date; el agrupamiento mensual asigna cada semana al mes en que comienza. Un corte mensual no es necesariamente exacto en sus bordes. [7]
Aplica una lectura similar a lenguajes de programación, con Python como selección inicial en la revisión. Muestra uso por tokens en una muestra clasificada. Las vistas absolutas y porcentuales conservan la unidad del segmento, que no es una tasa de resolución de problemas. [1] [7]
\nCómo seguirlo: compará el lenguaje de tu repositorio y cruzalo con Coding Index o un benchmark de código pertinente. Eso arma una lista de candidatos. La prueba propia debe incluir comprensión del proyecto, un cambio con tests, un bug y una revisión de diff.
\nQue un modelo aparezca mucho en Python puede reflejar la integración de una aplicación o el volumen de un usuario intensivo. Tampoco identifica framework, dificultad, versión ni resultado final. Un cambio de participación justifica investigar; para reemplazar el modelo hace falta verificar una mejora.
\nCuenta solicitudes por la longitud observada de prompt y completion. El selector ofrece menos de 1K, 1K a 10K, 10K a 100K, 100K a 1M y 1M a 10M tokens. La unidad del gráfico es solicitudes, con vista absoluta o porcentual. [1]
\nCómo seguirlo: elegí el tramo de tus cargas de trabajo. Ver uso con entradas y salidas extensas puede indicar que vale la pena probar un modelo para documentos largos o repositorios grandes. La ventana máxima anunciada requiere una consulta separada a la ficha del modelo.
\nLa capacidad nominal, la longitud realmente utilizada y la calidad al recuperar información son tres mediciones diferentes. Para validar contexto largo, usá datos relevantes ubicados en distintas partes del material y verificá relaciones entre ellos. Caber en el límite no demuestra comprensión.
\nPresenta la distribución de actividad de herramientas entre modelos. El filtro público tool_calling identifica solicitudes donde se registró al menos una llamada; eso no permite equiparar automáticamente solicitudes con cantidad de llamadas individuales. Al exportar datos, conservá el campo contado por esa vista. [7]
\nCómo seguirlo: usalo para identificar modelos presentes en flujos con herramientas. Después medí selección de herramienta, argumentos válidos, interpretación del resultado, recuperación de errores y respeto de permisos.
\nMás actividad puede acompañar un agente útil o un loop improductivo. También puede cambiar por cómo el harness divide una operación. La cuota del gráfico no revela qué porcentaje de llamadas tuvo éxito ni qué porcentaje de todo el tráfico de ese modelo usó herramientas.
\nDentro de Text, Images muestra imágenes procesadas por modelos y permite alternar volumen o participación. Es importante distinguir este bloque de la pestaña superior Image, orientada a generación de imágenes. El dataset documenta por separado entrada image y salida image_output. [1] [7]
\nCómo seguirlo: para entender capturas, facturas o gráficos, mirá el uso multimodal y armá pruebas de lectura concretas. Para generar ilustraciones, elegí la pestaña de generación y sus evaluaciones correspondientes.
\nUna solicitud puede contener más de una imagen. Cantidad de imágenes, solicitudes con imágenes y tokens de imagen no son intercambiables. Y procesar muchas imágenes no demuestra exactitud en OCR, conteo, interpretación espacial o seguimiento visual de instrucciones.
\nOrdena aplicaciones y agentes que participan en la atribución pública de uso. El volumen está expresado en tokens y el selector permite cambiar el período. Las apps ocultas o privadas quedan fuera; el dataset puede reunir aliases de una misma aplicación. [2]
\nCómo seguirlo: cruzalo con los movimientos de modelos. Una integración grande puede alterar la demanda sin que haya cambiado el modelo. La app añade instrucciones, herramientas, memoria y routing, por lo que conviene evaluarla como sistema.
\nEl ranking no cuenta instalaciones, usuarios activos ni toda la actividad de una aplicación fuera de OpenRouter. Tampoco todos los controles llamados trending comparten fórmula: la API de apps describe crecimiento absoluto excedente frente a tres períodos previos, mientras el ranking de modelos compara crecimiento porcentual entre dos ventanas. [2]
\nLa barra superior permite salir de Text. En Image, Video, Speech, Embeddings, Rerank y Transcription, las tablas se ordenan por solicitudes y el gráfico superior puede ofrecer otra unidad. Batch parte de subsolicitudes y también permite ordenar por tokens. Verificá cuál de los dos componentes cambia con cada selector. [13] [14] [15] [16] [17] [18] [19]
\nImage: el gráfico alterna solicitudes e imágenes. Una solicitud que devuelve varias imágenes cuenta una vez en la tabla por solicitudes.
\nVideo: solicitudes u horas en el gráfico. Un número de solicitudes no informa duración total, resolución ni costo de los clips.
\nSpeech: solicitudes en la vista revisada. Para una prueba propia importan también duración del audio, inteligibilidad, pronunciación y seguimiento del estilo.
\nEmbeddings: solicitudes o tokens en el gráfico. Evaluá además la recuperación con tu corpus; más volumen no demuestra mejores vecinos semánticos.
\nRerank: solicitudes o documentos. Un pedido puede reordenar muchos documentos, así que ambos volúmenes responden preguntas distintas.
\nTranscription: el gráfico alterna solicitudes y caracteres; la tabla conserva solicitudes. Evalúa el uso de transcripción de voz a texto. Para elegir, medí errores sobre audios representativos, acentos y condiciones acústicas.
\nBatch: el selector Subrequests o Tokens modifica tanto el gráfico como la tabla. Ofrece filtro de texto, embeddings o todas las modalidades. Las subsolicitudes cuentan el trabajo dentro de los lotes, no el número de lotes. Agregá tiempo de finalización, fallos y costo al comparar alternativas.
\nLas primeras seis pestañas incluyen Top Models, Leaderboard y Market Share. Esta última conserva solicitudes por autor. Batch incluye las dos primeras. No todas las modalidades replican las trece secciones de Text.
\nEn las tablas se mantienen controles de período como Today, This Week, This Month y New & Trending. La disponibilidad de un control no basta para atribuirle todos los umbrales y reglas del ranking de texto; verificá la nota metodológica de esa modalidad antes de reutilizar su cálculo.
\nConfundir participación y crecimiento. Pasar de 10% a 15% es ganar 5 puntos porcentuales y crecer 50% respecto de la cuota inicial. Indicá cuál calculaste.
\nLeer una cuota sin su total. Un segmento puede ganar participación mientras cae su volumen. Guardá ambos cuando estén disponibles.
\nComparar cortes distintos. Un día parcial, un cierre UTC y una semana de clasificación no describen exactamente el mismo período.
\nTratar ausencia como cero. Un modelo fuera del top visible, sin datos suficientes o sin puntaje publicado puede ser simplemente no observable en esa vista.
\nExplicar correlaciones como causas. Un lanzamiento, una oferta gratuita o un cambio de routing son hipótesis hasta contar con evidencia adicional.
\nEl límite más importante atraviesa toda la guía: el uso observado ayuda a elegir candidatos; la aptitud para nuestro trabajo se comprueba con resultados. OpenRouter también recomienda contrastar benchmarks generales con prompts reales y costo por tarea completada. [12]
\nNo hace falta mirar todos los paneles cada día. Conviene mantener una pregunta estable y usar las secciones que aportan evidencia para responderla.
\nDefinir el trabajo. Por ejemplo, revisar cambios de un backend en Python con tests disponibles y sin acceso a producción. Acordar qué cuenta como éxito antes de ver las respuestas.
\nElegir el segmento. Abrir Code Review, Programming en Python y el tramo de contexto habitual. Usar el ranking general como contexto.
\nGuardar la observación. Registrar fecha de consulta, fecha de datos, unidad, filtro, período, variante exacta y fuente. Si se usa la API, conservar también los metadatos.
\nArmar una lista breve. Incluir el modelo actual, un candidato de costo menor y otro que prometa mayor capacidad. Un pico de uso alcanza para entrar a la prueba, no para ganar.
\nFijar condiciones comparables. Mismo conjunto de casos, contexto, herramientas, presupuesto y criterios de evaluación. Registrar proveedor, esfuerzo y límites; documentar cualquier diferencia necesaria.
\nMedir el resultado completo. Éxito, errores relevantes, intentos, tiempo hasta un resultado utilizable, costo total y revisión humana. Contar también fallos y abandonos.
\nRepetir donde haya variación. Usar varios intentos cuando corresponda, conservar los casos difíciles y revisar las diferencias pequeñas con prudencia. Separar mejoras consistentes de una buena ejecución aislada.
\nTomar una decisión reversible. Mantener, probar en un entorno acotado o reemplazar. Definir qué deterioro justificaría volver al modelo anterior y cuándo revisar otra vez.
\nLa métrica económica interna puede ser tan concreta como gasto de todos los intentos dividido por tareas aceptadas. Por ejemplo, USD 12 para 30 tareas aceptadas da USD 0,40 por tarea aceptada. Un segundo modelo que gastó USD 9 pero sólo cerró 15 queda en USD 0,60. El precio por token no hacía visible esa diferencia.
\nEl costo de revisión humana conviene registrarlo aparte y, si importa para la decisión, incorporarlo con un criterio explícito. No hace falta fingir una precisión que todavía no existe: un registro consistente vale más que una cifra muy exacta cuyo denominador cambia cada semana.
\nUna ficha útil puede ocupar diez líneas: objetivo; casos y criterio de aceptación; fecha; modelo y variante; proveedor; harness y herramientas; configuración; éxitos sobre intentos; costo y tiempo; decisión. Para el seguimiento público, agregá la vista exacta de OpenRouter y su unidad.
\nSi un panel no publica tamaño de muestra, incertidumbre, ventana o tratamiento de caché y descuentos, anotá no publicado en vez de completar el hueco por intuición. El estudio histórico State of AI y un panel actual pueden usar taxonomías o métodos distintos; una explicación de 2025 no debe trasladarse automáticamente a la interfaz de 2026.
\nPara republicar datos, OpenRouter permite reutilización con atribución bajo CC BY 4.0. Guardá el snapshot, citá la fuente y su fecha real, y señalá tus transformaciones. Los ejemplos de respuesta de una documentación describen el formato: sus cifras no son observaciones actuales. [2] [20]
\nEl valor de Rankings está en reducir el espacio de búsqueda. Permite detectar dónde aumenta la actividad, qué tareas atraen inversión y qué alternativas merecen una evaluación. El beneficio aparece cuando esa observación termina en una prueba bien definida.
\nPara Golden Path, el criterio de cierre es práctico: elegir la combinación de modelo, proveedor y harness que resuelva el trabajo con suficiente calidad, costo y control. Conservar la evidencia de esa elección hace posible revisarla cuando cambie el catálogo, sin empezar de cero ni perseguir cada nuevo primer puesto.
\nRecorrido y fuentes originales del 3 de octubre de 2026. El 12 de octubre se reconfirmaron Rankings, Data API, los datasets de tokens y sesiones, clasificación por tarea y τ²-Bench Airline; se revisó la ficha actual de GPQA. Los controles dinámicos y las demás fichas conservan la fecha original. Los enlaces a Rankings abren vistas dinámicas; sus valores pueden cambiar después de esta revisión. Las capturas de referencia aportadas para la guía corresponden a la navegación de Text y a Top models by task.
\nMuchos pasos de una aplicación con IA no necesitan otro párrafo. Necesitan saber qué hacer a continuación: a qué equipo enviar un pedido, si una afirmación está respaldada, qué candidato revisar primero o si vale la pena llamar a un modelo más costoso.
\nJev 1.13, de TypeSafe, está diseñado para ese tipo de decisiones. Recibe texto o estado estructurado y devuelve respuestas tipadas, no prosa libre. La documentación de System One distingue tres primitivas:
\n| Primitiva | \nPregunta | \nRespuesta | \n
|---|---|---|
| Choice | \n¿Cuál de estas opciones describe mejor el caso? | \nUna opción y probabilidades | \n
| Score | \n¿Dónde cae el caso en una escala definida? | \nUna puntuación sobre los niveles configurados | \n
| Noul | \n¿Se cumple esta condición? | \nUna probabilidad entre 0 y 1 | \n
Las opciones y los criterios los define la aplicación. Jev juzga un estado dentro de ese marco; el código decide qué acción corresponde, con sus propias reglas y permisos.
\nUna solicitud entrante puede ir a soporte técnico, facturación o revisión manual. Si la elección es ambigua, la aplicación puede pedirle a Jev una categoría y enviar los casos de baja confianza a una persona. La misma idea sirve para clasificar incidentes o separar señales útiles del ruido en una cola.
\nCuando ya existe una lista acotada de opciones, Jev puede puntuar cuáles parecen más pertinentes: recuerdos recuperados, alertas o tareas por revisar. Primero conviene reducir el conjunto con filtros baratos; pedir una decisión sobre toda la base aumenta costo y ruido.
\nUn LLM generativo puede extraer datos de una conversación, pero redactar una afirmación no la convierte en un hecho. Un gate puede evaluar si hay evidencia, si el dato parece duradero o si contradice lo ya registrado. Las mutaciones siguen pasando por validación e idempotencia del sistema.
\nSi la tarea sólo requiere elegir entre rutas conocidas, quizá no haga falta llamar a un modelo de razonamiento largo. Jev puede ayudar a derivar casos claros y dejar los difíciles para otro modelo o una revisión humana. El ahorro real se mide junto con los errores de derivación: abaratar una llamada a costa de perder casos importantes sería una pésima cuenta.
\nUna probabilidad alta no demuestra que la respuesta individual sea correcta. TypeSafe describe la calibración como una propiedad que se mide sobre conjuntos de predicciones, no como una garantía por caso. Hay que probar con datos del dominio, idiomas reales y ejemplos difíciles antes de elegir umbrales.
\nAdemás, Score usa la escala configurada: si los criterios tienen cinco niveles, no se debe interpretar su valor crudo como un número entre 0 y 1 sin normalizarlo. Y una decisión bien formada tampoco autoriza por sí misma un envío, una escritura o una publicación.
\nLa arquitectura útil suele tener cuatro piezas: estado relevante → pregunta acotada → respuesta tipada → regla determinista. Se registran las decisiones para poder comparar aciertos y errores; ante fallos del proveedor, la aplicación elige un fallback explícito.
\nEn una v2 de ficción interactiva probamos a Jev como parte de un Director que observa escenas y decide qué relaciones, hechos, temas y promesas dejan consecuencias. Ahí la pregunta no era «escribí una escena mejor», sino «¿qué cambió realmente y quién puede recordarlo?».
\nEl diseño, las correcciones encontradas en las pruebas y sus límites están en el caso del Director narrativo. Es un ejemplo de aplicación; routing, scoring y gates son otros puntos de partida que requieren su propia evaluación.
\n", "headings": [ { "label": "Una pregunta distinta a «escribime una respuesta»", "depth": 2, "id": "una-pregunta-distinta-a-escribime-una-respuesta" }, { "label": "Cuatro lugares donde tiene sentido probarlo", "depth": 2, "id": "cuatro-lugares-donde-tiene-sentido-probarlo" }, { "label": "Routing y clasificación", "depth": 3, "id": "routing-y-clasificacion" }, { "label": "Scoring y orden de candidatos", "depth": 3, "id": "scoring-y-orden-de-candidatos" }, { "label": "Gates antes de persistir", "depth": 3, "id": "gates-antes-de-persistir" }, { "label": "Escalamiento entre modelos", "depth": 3, "id": "escalamiento-entre-modelos" }, { "label": "La confianza no es un permiso", "depth": 2, "id": "la-confianza-no-es-un-permiso" }, { "label": "Qué uso terminó siendo concreto", "depth": 2, "id": "que-uso-termino-siendo-concreto" } ], "raw": "---\nslug: jev-decisiones-estructuradas\ntitle: \"Jev: decisiones pequeñas dentro de sistemas grandes\"\ntype: concept\norder: 13\nsummary: \"Qué hace un modelo de decisiones estructuradas y dónde conviene ponerlo: routing, clasificación, scoring y gates antes de cambiar el estado.\"\ntags: [jev, decisiones, routing, scoring, agentes, arquitectura]\nrelated: [caso-jev-director-narrativo, modelos-guiados-el-entorno-es-la-politica, orquestacion]\narea: Gobierno de agentes\nglyph: ◈\nhue: rgba(168,106,255,.24)\n---\n\n# Jev: decisiones pequeñas dentro de sistemas grandes\n\n## Una pregunta distinta a «escribime una respuesta»\n\nMuchos pasos de una aplicación con IA no necesitan otro párrafo. Necesitan saber **qué hacer a continuación**: a qué equipo enviar un pedido, si una afirmación está respaldada, qué candidato revisar primero o si vale la pena llamar a un modelo más costoso.\n\n[Jev 1.13](https://openrouter.ai/typesafe/jev-1.13), de TypeSafe, está diseñado para ese tipo de decisiones. Recibe texto o estado estructurado y devuelve respuestas tipadas, no prosa libre. La [documentación de System One](https://docs.typesafe.ai/concepts/system-one) distingue tres primitivas:\n\n| Primitiva | Pregunta | Respuesta |\n| --- | --- | --- |\n| **Choice** | ¿Cuál de estas opciones describe mejor el caso? | Una opción y probabilidades |\n| **Score** | ¿Dónde cae el caso en una escala definida? | Una puntuación sobre los niveles configurados |\n| **Noul** | ¿Se cumple esta condición? | Una probabilidad entre 0 y 1 |\n\nLas opciones y los criterios los define la aplicación. Jev juzga un estado dentro de ese marco; el código decide qué acción corresponde, con sus propias reglas y permisos.\n\n## Cuatro lugares donde tiene sentido probarlo\n\n### Routing y clasificación\n\nUna solicitud entrante puede ir a soporte técnico, facturación o revisión manual. Si la elección es ambigua, la aplicación puede pedirle a Jev una categoría y enviar los casos de baja confianza a una persona. La misma idea sirve para clasificar incidentes o separar señales útiles del ruido en una cola.\n\n### Scoring y orden de candidatos\n\nCuando ya existe una lista acotada de opciones, Jev puede puntuar cuáles parecen más pertinentes: recuerdos recuperados, alertas o tareas por revisar. Primero conviene reducir el conjunto con filtros baratos; pedir una decisión sobre toda la base aumenta costo y ruido.\n\n### Gates antes de persistir\n\nUn LLM generativo puede extraer datos de una conversación, pero redactar una afirmación no la convierte en un hecho. Un gate puede evaluar si hay evidencia, si el dato parece duradero o si contradice lo ya registrado. Las mutaciones siguen pasando por validación e idempotencia del sistema.\n\n### Escalamiento entre modelos\n\nSi la tarea sólo requiere elegir entre rutas conocidas, quizá no haga falta llamar a un modelo de razonamiento largo. Jev puede ayudar a derivar casos claros y dejar los difíciles para otro modelo o una revisión humana. El ahorro real se mide junto con los errores de derivación: abaratar una llamada a costa de perder casos importantes sería una pésima cuenta.\n\n## La confianza no es un permiso\n\nUna probabilidad alta no demuestra que la respuesta individual sea correcta. TypeSafe describe la calibración como una propiedad que se mide sobre conjuntos de predicciones, no como una garantía por caso. Hay que probar con datos del dominio, idiomas reales y ejemplos difíciles antes de elegir umbrales.\n\nAdemás, *Score* usa la escala configurada: si los criterios tienen cinco niveles, no se debe interpretar su valor crudo como un número entre 0 y 1 sin normalizarlo. Y una decisión bien formada tampoco autoriza por sí misma un envío, una escritura o una publicación.\n\nLa arquitectura útil suele tener cuatro piezas: **estado relevante → pregunta acotada → respuesta tipada → regla determinista**. Se registran las decisiones para poder comparar aciertos y errores; ante fallos del proveedor, la aplicación elige un fallback explícito.\n\n## Qué uso terminó siendo concreto\n\nEn una v2 de ficción interactiva probamos a Jev como parte de un Director que observa escenas y decide qué relaciones, hechos, temas y promesas dejan consecuencias. Ahí la pregunta no era «escribí una escena mejor», sino «¿qué cambió realmente y quién puede recordarlo?».\n\nEl diseño, las correcciones encontradas en las pruebas y sus límites están en [el caso del Director narrativo](/entrada/caso-jev-director-narrativo). Es un ejemplo de aplicación; routing, scoring y gates son otros puntos de partida que requieren su propia evaluación.\n\n" }, { "slug": "gentle-ai-engram-memoria-y-proceso", "title": "Gentle AI y Engram: memoria y proceso para agentes de código", "summary": "Qué aporta un configurador de entorno y qué resuelve una memoria persistente cuando el trabajo de agentes cruza sesiones, herramientas y proyectos.", "type": "editorial", "order": 14, "tags": [ "gentle-ai", "engram", "memoria", "agentes", "gobierno", "workflow" ], "related": [ "orquestacion", "continuidad-y-observabilidad", "modelos-guiados-el-entorno-es-la-politica" ], "area": "Gobierno de agentes", "glyph": "◈", "hue": "rgba(168,106,255,.24)", "file": "gentle-ai-engram-memoria-y-proceso.md", "html": "\n\nRevisión documental: 12 de octubre de 2026. Las integraciones y sus capacidades varían; esta revisión no implica una nueva prueba del entorno.
\n
Un agente puede terminar una tarea correctamente y, al abrir una sesión nueva, volver a preguntar por decisiones que el equipo ya tomó. También puede recordar una regla vieja, aplicar un proceso enorme a un cambio trivial o entregar código sin una prueba verificable. Son fallas distintas: continuidad, vigencia del contexto y evidencia del resultado.
\nEl ecosistema de Gentleman Programming propone dos piezas relacionadas. Gentle AI configura los agentes de código que ya usás con componentes de memoria, flujo de trabajo, skills y revisión. Engram aporta una memoria persistente, consultable desde distintos agentes. Una pieza organiza el entorno; la otra conserva conocimiento entre sesiones. No hace falta adoptar todo el ecosistema para evaluar cada una.
\nGentle AI es un configurador, no un modelo ni un agente nuevo. Prepara integraciones para herramientas como Claude Code, OpenCode y Codex, y ofrece componentes y presets para elegir cuánto gobierno necesita el entorno. La guía de uso previsto describe Organic Driven Development (ODD) como el camino cotidiano: explorar el proyecto, hacer cambios entendidos con un flujo liviano, verificar el resultado y dejar una referencia recuperable cuando el trabajo crece.
\nEsa proporcionalidad importa. Si corregir una etiqueta exige el mismo ritual que migrar un módulo, el equipo termina ignorando el ritual. Para un cambio grande, en cambio, una descripción de la feature y sus avances permite que otra sesión retome el trabajo sin reconstruir la historia a partir de commits y chats.
\n| Capa | \nPregunta que responde | \nEvidencia esperada | \n
|---|---|---|
| Configuración | \n¿Qué herramientas y reglas tiene este agente? | \nComponentes instalados y diagnóstico del entorno | \n
| Proceso | \n¿Cómo se explora, implementa y retoma esta tarea? | \nAlcance, decisiones y estado actual | \n
| Verificación | \n¿Qué comportamiento se comprobó? | \nPruebas, revisión o chequeos pertinentes | \n
| Memoria | \n¿Qué conviene recuperar en la próxima sesión? | \nObservaciones con contexto y proyecto | \n
La documentación actual establece test-first cuando existe una prueba pertinente y ejecutable; si no, exige explicar la excepción y verificar por otra vía. RDD está habilitado por defecto con opt-out, respeta desactivaciones explícitas y vincula la revisión al candidato congelado. La revisión automática se reserva para candidatos de alto riesgo; las capacidades difieren por integración. Eso no autoriza commit, push ni release. Un workflow prolijo no convierte una comprobación superficial en evidencia.
\nEngram es una memoria local para agentes, implementada como binario de Go con SQLite y búsqueda de texto completo. Expone CLI, servidor MCP, API HTTP y TUI. El agente puede guardar y buscar observaciones sobre decisiones, descubrimientos, errores resueltos o convenciones del proyecto. La documentación lo presenta como memoria curada, no como un registro indiscriminado de cada conversación.
\nSupongamos que un portal usa IDs largos como strings para no perder precisión en JavaScript. Al terminar una sesión, guardar «los IDs de CRM se tratan como strings en API, ordenamiento y exportación; revisar el adaptador antes de normalizarlos» sirve más que conservar cien mensajes donde apareció el tema. La próxima sesión puede buscar la decisión, comprobar que sigue vigente en el código y trabajar desde ahí.
\nEsa última comprobación es crucial. Una memoria es una pista con procedencia, no una orden superior ni la fuente de verdad del repositorio. Si el contrato cambió, hay que corregir o reemplazar la observación. Engram mantiene SQLite local como fuente autoritativa: Git Sync exporta fragmentos portables y Engram Cloud ofrece replicación y acceso compartido opcionales por proyecto. Compartir memoria exige definir quién puede escribir, qué información se guarda y cómo se resuelven decisiones contradictorias.
\nEn un entorno donde un coordinador deriva trabajo a distintos modelos, cada worker debería recibir el contexto mínimo necesario: objetivo, límites, estado del repo y decisiones relevantes. Engram puede ayudar a recuperar estas últimas; Gentle AI puede dar una configuración y un recorrido de trabajo repetibles. La coordinación y la autorización de cambios siguen perteneciendo al sistema que dirige el trabajo y a las personas responsables.
\nUn piloto razonable sería:
\nNo conviene medir el éxito por la cantidad de recuerdos guardados. La señal útil es que la próxima persona o agente pueda tomar una decisión correcta con menos reconstrucción y con evidencia visible.
\nLa memoria persistente introduce una deuda propia: información obsoleta que suena convincente. El proceso también puede volverse burocracia si se aplica sin escala. Por eso hay que separar recuerdo, estado actual, prueba y permiso. Ninguna observación habilita por sí sola una escritura en producción; ningún checklist demuestra que se ejecutó el comando correcto.
\nGentle AI y Engram son interesantes cuando el dolor real es volver a explicar el contexto, perder decisiones entre herramientas o no poder retomar trabajo delegado. Probados por separado y con métricas simples, pueden darle continuidad al entorno sin convertir cada tarea en una ceremonia.
\n", "headings": [ { "label": "El problema no empieza cuando el agente se equivoca", "depth": 2, "id": "el-problema-no-empieza-cuando-el-agente-se-equivoca" }, { "label": "Gentle AI: configurar el modo de trabajo", "depth": 2, "id": "gentle-ai-configurar-el-modo-de-trabajo" }, { "label": "Engram: recordar decisiones, no grabar todo", "depth": 2, "id": "engram-recordar-decisiones-no-grabar-todo" }, { "label": "Un punto dulce para un entorno con varios agentes", "depth": 2, "id": "un-punto-dulce-para-un-entorno-con-varios-agentes" }, { "label": "El límite que define si sirve", "depth": 2, "id": "el-limite-que-define-si-sirve" } ], "raw": "---\nslug: gentle-ai-engram-memoria-y-proceso\ntitle: \"Gentle AI y Engram: memoria y proceso para agentes de código\"\ntype: editorial\norder: 14\nsummary: \"Qué aporta un configurador de entorno y qué resuelve una memoria persistente cuando el trabajo de agentes cruza sesiones, herramientas y proyectos.\"\ntags: [gentle-ai, engram, memoria, agentes, gobierno, workflow]\nrelated: [orquestacion, continuidad-y-observabilidad, modelos-guiados-el-entorno-es-la-politica]\narea: Gobierno de agentes\nglyph: ◈\nhue: rgba(168,106,255,.24)\n---\n\n# Gentle AI y Engram: memoria y proceso para agentes de código\n\n> Revisión documental: 12 de octubre de 2026. Las integraciones y sus capacidades varían; esta revisión no implica una nueva prueba del entorno.\n\n## El problema no empieza cuando el agente se equivoca\n\nUn agente puede terminar una tarea correctamente y, al abrir una sesión nueva, volver a preguntar por decisiones que el equipo ya tomó. También puede recordar una regla vieja, aplicar un proceso enorme a un cambio trivial o entregar código sin una prueba verificable. Son fallas distintas: continuidad, vigencia del contexto y evidencia del resultado.\n\nEl ecosistema de [Gentleman Programming](https://gentlemanprogramming.com/) propone dos piezas relacionadas. **Gentle AI** configura los agentes de código que ya usás con componentes de memoria, flujo de trabajo, skills y revisión. **Engram** aporta una memoria persistente, consultable desde distintos agentes. Una pieza organiza el entorno; la otra conserva conocimiento entre sesiones. No hace falta adoptar todo el ecosistema para evaluar cada una.\n\n## Gentle AI: configurar el modo de trabajo\n\n[Gentle AI](https://github.com/Gentleman-Programming/gentle-ai) es un configurador, no un modelo ni un agente nuevo. Prepara integraciones para herramientas como Claude Code, OpenCode y Codex, y ofrece componentes y presets para elegir cuánto gobierno necesita el entorno. La [guía de uso previsto](https://github.com/Gentleman-Programming/gentle-ai/blob/main/docs/intended-usage.md) describe **Organic Driven Development (ODD)** como el camino cotidiano: explorar el proyecto, hacer cambios entendidos con un flujo liviano, verificar el resultado y dejar una referencia recuperable cuando el trabajo crece.\n\nEsa proporcionalidad importa. Si corregir una etiqueta exige el mismo ritual que migrar un módulo, el equipo termina ignorando el ritual. Para un cambio grande, en cambio, una descripción de la feature y sus avances permite que otra sesión retome el trabajo sin reconstruir la historia a partir de commits y chats.\n\n| Capa | Pregunta que responde | Evidencia esperada |\n| --- | --- | --- |\n| Configuración | ¿Qué herramientas y reglas tiene este agente? | Componentes instalados y diagnóstico del entorno |\n| Proceso | ¿Cómo se explora, implementa y retoma esta tarea? | Alcance, decisiones y estado actual |\n| Verificación | ¿Qué comportamiento se comprobó? | Pruebas, revisión o chequeos pertinentes |\n| Memoria | ¿Qué conviene recuperar en la próxima sesión? | Observaciones con contexto y proyecto |\n\nLa [documentación actual](https://github.com/Gentleman-Programming/gentle-ai) establece test-first cuando existe una prueba pertinente y ejecutable; si no, exige explicar la excepción y verificar por otra vía. RDD está habilitado por defecto con opt-out, respeta desactivaciones explícitas y vincula la revisión al candidato congelado. La revisión automática se reserva para candidatos de alto riesgo; las capacidades difieren por integración. Eso no autoriza commit, push ni release. Un workflow prolijo no convierte una comprobación superficial en evidencia.\n\n## Engram: recordar decisiones, no grabar todo\n\n[Engram](https://github.com/Gentleman-Programming/engram) es una memoria local para agentes, implementada como binario de Go con SQLite y búsqueda de texto completo. Expone CLI, servidor MCP, API HTTP y TUI. El agente puede guardar y buscar observaciones sobre decisiones, descubrimientos, errores resueltos o convenciones del proyecto. La documentación lo presenta como **memoria curada**, no como un registro indiscriminado de cada conversación.\n\nSupongamos que un portal usa IDs largos como strings para no perder precisión en JavaScript. Al terminar una sesión, guardar «los IDs de CRM se tratan como strings en API, ordenamiento y exportación; revisar el adaptador antes de normalizarlos» sirve más que conservar cien mensajes donde apareció el tema. La próxima sesión puede buscar la decisión, comprobar que sigue vigente en el código y trabajar desde ahí.\n\nEsa última comprobación es crucial. Una memoria es una pista con procedencia, no una orden superior ni la fuente de verdad del repositorio. Si el contrato cambió, hay que corregir o reemplazar la observación. Engram mantiene SQLite local como fuente autoritativa: Git Sync exporta fragmentos portables y Engram Cloud ofrece replicación y acceso compartido opcionales por proyecto. Compartir memoria exige definir quién puede escribir, qué información se guarda y cómo se resuelven decisiones contradictorias.\n\n## Un punto dulce para un entorno con varios agentes\n\nEn un entorno donde un coordinador deriva trabajo a distintos modelos, cada worker debería recibir el contexto mínimo necesario: objetivo, límites, estado del repo y decisiones relevantes. Engram puede ayudar a recuperar estas últimas; Gentle AI puede dar una configuración y un recorrido de trabajo repetibles. La coordinación y la autorización de cambios siguen perteneciendo al sistema que dirige el trabajo y a las personas responsables.\n\nUn piloto razonable sería:\n\n1. Elegir **un repositorio** con decisiones que se repiten entre sesiones.\n2. Guardar pocas observaciones útiles: contratos, convenciones, errores difíciles y motivos de arquitectura. Vincularlas al código o documento vigente.\n3. Pedir al agente que busque contexto al empezar y que **verifique cada recuerdo** antes de aplicarlo.\n4. Medir durante varias tareas cuántas aclaraciones se evitaron, cuántos recuerdos fueron pertinentes y cuántos estaban desactualizados.\n5. Recién entonces sumar un proceso de trabajo o revisión donde la frecuencia y el riesgo del cambio lo justifiquen.\n\nNo conviene medir el éxito por la cantidad de recuerdos guardados. La señal útil es que la próxima persona o agente pueda tomar una decisión correcta con menos reconstrucción y con evidencia visible.\n\n## El límite que define si sirve\n\nLa memoria persistente introduce una deuda propia: información obsoleta que suena convincente. El proceso también puede volverse burocracia si se aplica sin escala. Por eso hay que separar **recuerdo**, **estado actual**, **prueba** y **permiso**. Ninguna observación habilita por sí sola una escritura en producción; ningún checklist demuestra que se ejecutó el comando correcto.\n\nGentle AI y Engram son interesantes cuando el dolor real es volver a explicar el contexto, perder decisiones entre herramientas o no poder retomar trabajo delegado. Probados por separado y con métricas simples, pueden darle continuidad al entorno sin convertir cada tarea en una ceremonia.\n" }, { "slug": "tailscale-red-privada-identidad", "title": "Tailscale: una red privada que empieza por la identidad", "summary": "Tailnets, WireGuard, conexiones directas y relays: un mapa para entender qué resuelve Tailscale y qué responsabilidades siguen siendo tuyas.", "type": "concept", "order": 14, "tags": [ "tailscale", "redes", "wireguard", "identidad", "infraestructura" ], "related": [ "tailscale-permisos-grants", "tailscale-entorno-agentes", "acceso-portatil-orca" ], "area": "Gobierno de agentes", "glyph": "◈", "hue": "rgba(87,217,232,.24)", "file": "tailscale-red-privada-identidad.md", "html": "Una estación con WSL, una notebook de viaje y una VPS pueden tener todo lo necesario para colaborar y, aun así, no poder hablarse con facilidad. Las direcciones cambian, hay NAT de por medio y publicar SSH o un panel de administración en Internet suma una superficie que después hay que cuidar.
\nTailscale permite conectar usuarios y dispositivos en una tailnet, una red privada superpuesta a las redes donde ya viven. Cada dispositivo entra autenticado, recibe una dirección estable dentro de esa red y puede encontrar a otros por nombre con MagicDNS. Instalarlo no convierte automáticamente a cada servicio en una aplicación segura: primero hay que definir quién se conecta y qué puede alcanzar. Qué es una tailnet · MagicDNS
\nWireGuard cifra el tráfico entre los dispositivos. El plano de control coordina identidades, claves y políticas; el plano de datos transporta los paquetes cifrados. Tailscale intenta establecer una conexión directa por UDP. Si la red no lo permite, puede usar un peer relay de la tailnet o un relay DERP. En los tres casos el tráfico entre los extremos mantiene cifrado de extremo a extremo; lo que suele cambiar es la latencia y el caudal. Plano de control y de datos · Tipos de conexión
\nLa distinción importa: que un salto pase por un relay no significa que el servicio al otro lado se haya vuelto público. También evita prometer una conexión directa que depende del NAT, los firewalls y la red de cada extremo.
\n| Pieza | \nResponde a | \nEjemplo | \n
|---|---|---|
| Tailnet | \n¿Qué identidades y dispositivos pertenecen a la red? | \nNotebook, estación y VPS | \n
| MagicDNS | \n¿Cómo encuentro un nodo por un nombre estable? | \nestacion en vez de una IP cambiante | \n
| Grant | \n¿Quién puede llegar a qué destino y puerto? | \nNotebook → estación por TCP 22 | \n
| Servicio | \n¿Quién puede usar la aplicación una vez conectado? | \nLogin y permisos del panel interno | \n
Un grant de red habilita una conexión; no implementa por sí solo las autorizaciones de una app. Y un nombre de MagicDNS simplifica el destino; no otorga permisos. Esas dos confusiones son bastante caras cuando el primer prototipo empieza a crecer.
\nDesde una notebook podés entrar por SSH al entorno que ya tiene tus repos y agentes. Una VPS puede aceptar conexiones de administración dentro de la tailnet sin exponer ese puerto públicamente. Un panel de desarrollo puede compartirse con un equipo pequeño por Tailscale Serve, sujeto a las reglas de acceso de la red. En cada caso la identidad y el destino quedan explícitos. Serve
\nTailscale tampoco enciende una computadora apagada, arregla un proceso caído ni sustituye backups. Si Orca vive en una estación de trabajo, el acceso remoto depende de que esa estación y WSL estén disponibles. La guía Acceso portátil a Orca desarrolla esa topología.
\nElegí un cliente, un host y un servicio. Incorporá ambos dispositivos a la tailnet; comprobá el nombre y la conexión; limitá el acceso al puerto que realmente necesitás. Recién después sumá otros destinos. La próxima entrada baja esa decisión a políticas, grants y pruebas negativas: Permisos que se pueden explicar.
\n", "headings": [ { "label": "El problema de las máquinas dispersas", "depth": 2, "id": "el-problema-de-las-maquinas-dispersas" }, { "label": "Qué ocurre cuando dos nodos se hablan", "depth": 2, "id": "que-ocurre-cuando-dos-nodos-se-hablan" }, { "label": "Cuatro piezas para no mezclar conceptos", "depth": 2, "id": "cuatro-piezas-para-no-mezclar-conceptos" }, { "label": "Dónde sí cambia el trabajo cotidiano", "depth": 2, "id": "donde-si-cambia-el-trabajo-cotidiano" }, { "label": "Una primera decisión razonable", "depth": 2, "id": "una-primera-decision-razonable" } ], "raw": "---\nslug: tailscale-red-privada-identidad\ntitle: \"Tailscale: una red privada que empieza por la identidad\"\ntype: concept\norder: 14\nsummary: \"Tailnets, WireGuard, conexiones directas y relays: un mapa para entender qué resuelve Tailscale y qué responsabilidades siguen siendo tuyas.\"\ntags: [tailscale, redes, wireguard, identidad, infraestructura]\nrelated: [tailscale-permisos-grants, tailscale-entorno-agentes, acceso-portatil-orca]\narea: Gobierno de agentes\nglyph: ◈\nhue: rgba(87,217,232,.24)\n---\n\n# Tailscale: una red privada que empieza por la identidad\n\n## El problema de las máquinas dispersas\n\nUna estación con WSL, una notebook de viaje y una VPS pueden tener todo lo necesario para colaborar y, aun así, no poder hablarse con facilidad. Las direcciones cambian, hay NAT de por medio y publicar SSH o un panel de administración en Internet suma una superficie que después hay que cuidar.\n\nTailscale permite conectar usuarios y dispositivos en una **tailnet**, una red privada superpuesta a las redes donde ya viven. Cada dispositivo entra autenticado, recibe una dirección estable dentro de esa red y puede encontrar a otros por nombre con MagicDNS. Instalarlo no convierte automáticamente a cada servicio en una aplicación segura: primero hay que definir quién se conecta y qué puede alcanzar. [Qué es una tailnet](https://tailscale.com/docs/concepts/tailnet) · [MagicDNS](https://tailscale.com/docs/features/magicdns)\n\n## Qué ocurre cuando dos nodos se hablan\n\nWireGuard cifra el tráfico entre los dispositivos. El plano de control coordina identidades, claves y políticas; el plano de datos transporta los paquetes cifrados. Tailscale intenta establecer una conexión directa por UDP. Si la red no lo permite, puede usar un peer relay de la tailnet o un relay DERP. En los tres casos el tráfico entre los extremos mantiene cifrado de extremo a extremo; lo que suele cambiar es la latencia y el caudal. [Plano de control y de datos](https://tailscale.com/docs/concepts/control-data-planes) · [Tipos de conexión](https://tailscale.com/docs/reference/connection-types)\n\nLa distinción importa: que un salto pase por un relay no significa que el servicio al otro lado se haya vuelto público. También evita prometer una conexión directa que depende del NAT, los firewalls y la red de cada extremo.\n\n## Cuatro piezas para no mezclar conceptos\n\n| Pieza | Responde a | Ejemplo |\n| --- | --- | --- |\n| Tailnet | ¿Qué identidades y dispositivos pertenecen a la red? | Notebook, estación y VPS |\n| MagicDNS | ¿Cómo encuentro un nodo por un nombre estable? | `estacion` en vez de una IP cambiante |\n| Grant | ¿Quién puede llegar a qué destino y puerto? | Notebook → estación por TCP 22 |\n| Servicio | ¿Quién puede usar la aplicación una vez conectado? | Login y permisos del panel interno |\n\nUn grant de red habilita una conexión; no implementa por sí solo las autorizaciones de una app. Y un nombre de MagicDNS simplifica el destino; no otorga permisos. Esas dos confusiones son bastante caras cuando el primer prototipo empieza a crecer.\n\n## Dónde sí cambia el trabajo cotidiano\n\nDesde una notebook podés entrar por SSH al entorno que ya tiene tus repos y agentes. Una VPS puede aceptar conexiones de administración dentro de la tailnet sin exponer ese puerto públicamente. Un panel de desarrollo puede compartirse con un equipo pequeño por Tailscale Serve, sujeto a las reglas de acceso de la red. En cada caso la identidad y el destino quedan explícitos. [Serve](https://tailscale.com/docs/features/tailscale-serve)\n\nTailscale tampoco enciende una computadora apagada, arregla un proceso caído ni sustituye backups. Si Orca vive en una estación de trabajo, el acceso remoto depende de que esa estación y WSL estén disponibles. La guía [Acceso portátil a Orca](/entrada/acceso-portatil-orca) desarrolla esa topología.\n\n## Una primera decisión razonable\n\nElegí **un cliente, un host y un servicio**. Incorporá ambos dispositivos a la tailnet; comprobá el nombre y la conexión; limitá el acceso al puerto que realmente necesitás. Recién después sumá otros destinos. La próxima entrada baja esa decisión a políticas, grants y pruebas negativas: [Permisos que se pueden explicar](/entrada/tailscale-permisos-grants).\n" }, { "slug": "tailscale-permisos-grants", "title": "Tailscale: permisos que se pueden explicar", "summary": "Diseñar grants por identidad, destino y puerto; comprobar accesos permitidos y denegados; distinguir red, SSH y permisos de aplicación.", "type": "guide", "order": 15, "tags": [ "tailscale", "grants", "acl", "ssh", "seguridad", "politicas" ], "related": [ "tailscale-red-privada-identidad", "tailscale-entorno-agentes", "acceso-portatil-orca" ], "area": "Gobierno de agentes", "glyph": "⚿", "hue": "rgba(168,106,255,.24)", "file": "tailscale-permisos-grants.md", "html": "El primer prototipo suele conectar dos dispositivos y celebrar que se ven. Para operar un entorno con agentes, VPS y paneles internos hace falta una pregunta más precisa: ¿qué identidad puede iniciar una conexión a qué destino y en qué puerto?
\nTailscale recomienda grants para expresar esos permisos. Cada grant define src, dst y capacidades de red (ip) o de aplicación (app). Las conexiones que no tengan una regla que las permita quedan denegadas; atención, porque una tailnet recién creada suele traer una política inicial allow all. Hay que revisar y reemplazar esa regla amplia antes de dar por hecho el mínimo privilegio. Grants · Política inicial y ACL
Supongamos una notebook, un host de desarrollo y una VPS. El objetivo es notebook → host por SSH, host → VPS por HTTPS, y ningún acceso de la notebook a la base de datos de la VPS. Esa matriz se puede revisar sin conocer la sintaxis de HuJSON.
\n| Origen | \nDestino | \nPuerto | \nDecisión | \n
|---|---|---|---|
| Notebook de trabajo | \nHost de desarrollo | \nTCP 22 | \nPermitir | \n
| Host de desarrollo | \nAPI interna de la VPS | \nTCP 443 | \nPermitir | \n
| Notebook de trabajo | \nBase de datos de la VPS | \nTCP 5432 | \nDenegar | \n
Una forma esquemática de llevarla a grants sería:
\n{\n \"tagOwners\": {\n \"tag:dev-host\": [\"autogroup:admin\"],\n \"tag:internal-api\": [\"autogroup:admin\"]\n },\n \"grants\": [\n {\n \"src\": [\"persona@ejemplo.com\"],\n \"dst\": [\"tag:dev-host\"],\n \"ip\": [\"tcp:22\"]\n },\n {\n \"src\": [\"tag:dev-host\"],\n \"dst\": [\"tag:internal-api\"],\n \"ip\": [\"tcp:443\"]\n }\n ]\n}Es un ejemplo para adaptar: los nombres y la identidad son ficticios; los tags sólo tienen sentido si los dispositivos tienen esas etiquetas asignadas. Antes de aplicar una política real, revisá los grants y ACL existentes: una regla amplia que permanezca activa puede seguir habilitando tráfico. Las políticas permiten sumar accesos, no escribir una regla deny para restar los que otra ya concedió. Sintaxis de grants · Tags
El src por correo identifica al usuario, no exclusivamente a su notebook: también puede habilitar sus otros dispositivos con identidad de usuario. Para limitarlo a una sola máquina, usá un selector de dispositivo, como su IP de Tailscale o un alias hosts, y verificá el alcance en la vista previa. Selectores de grants
SSH habitual sobre Tailscale conserva sshd, usuarios y claves SSH del host; la tailnet aporta una ruta privada y el grant habilita el puerto. Tailscale SSH deja que Tailscale gestione autenticación y autorización SSH en nodos compatibles, con sus propias reglas ssh y opciones como check. Activar sólo el grant de TCP 22 no equivale a haber configurado Tailscale SSH. Tampoco sirve para hacer Tailscale SSH hacia una máquina que sólo está detrás de un subnet router. Tailscale SSH
Si ya existe un flujo SSH que funciona para Orca, el primer paso puede ser conservarlo y limitar la ruta. Una migración a Tailscale SSH merece su propia prueba de usuarios, sesiones y recuperación.
\nPrimero usá Preview rules para inspeccionar los destinos que ve una identidad y agregá tests de política para las conexiones esperadas. Después probá desde un dispositivo real: SSH al host permitido y conexión al puerto restringido de un destino que esté encendido y escuchando. Un timeout hacia una máquina apagada no demuestra que un grant esté funcionando. Editar y previsualizar políticas
\nPara diagnosticar, tailscale ping --tsmp verifica conectividad antes de comprobar la política; tailscale ping --icmp verifica conectividad incluyendo las reglas. Si ambos pasan pero la aplicación falla, revisá el puerto, el servicio y sus permisos. Para el puerto concreto, probá el protocolo real: un ping no verifica que TCP 22 o 443 esté habilitado. Diagnóstico de políticas
El resultado que queremos poder escribir en una línea es: «esta identidad llega a este servicio por este puerto; a aquel otro no». Con esa política lista, el caso de un entorno con agentes muestra dónde ubicar cada conexión.
\n", "headings": [ { "label": "Estar en la tailnet no alcanza", "depth": 2, "id": "estar-en-la-tailnet-no-alcanza" }, { "label": "Dibujar la política antes del archivo", "depth": 2, "id": "dibujar-la-politica-antes-del-archivo" }, { "label": "SSH tiene dos modos de operación", "depth": 2, "id": "ssh-tiene-dos-modos-de-operacion" }, { "label": "Probar que el límite existe", "depth": 2, "id": "probar-que-el-limite-existe" } ], "raw": "---\nslug: tailscale-permisos-grants\ntitle: \"Tailscale: permisos que se pueden explicar\"\ntype: guide\norder: 15\nsummary: \"Diseñar grants por identidad, destino y puerto; comprobar accesos permitidos y denegados; distinguir red, SSH y permisos de aplicación.\"\ntags: [tailscale, grants, acl, ssh, seguridad, politicas]\nrelated: [tailscale-red-privada-identidad, tailscale-entorno-agentes, acceso-portatil-orca]\narea: Gobierno de agentes\nglyph: ⚿\nhue: rgba(168,106,255,.24)\n---\n\n# Tailscale: permisos que se pueden explicar\n\n## Estar en la tailnet no alcanza\n\nEl primer prototipo suele conectar dos dispositivos y celebrar que se ven. Para operar un entorno con agentes, VPS y paneles internos hace falta una pregunta más precisa: **¿qué identidad puede iniciar una conexión a qué destino y en qué puerto?**\n\nTailscale recomienda **grants** para expresar esos permisos. Cada grant define `src`, `dst` y capacidades de red (`ip`) o de aplicación (`app`). Las conexiones que no tengan una regla que las permita quedan denegadas; atención, porque una tailnet recién creada suele traer una política inicial *allow all*. Hay que revisar y reemplazar esa regla amplia antes de dar por hecho el mínimo privilegio. [Grants](https://tailscale.com/docs/features/access-control/grants) · [Política inicial y ACL](https://tailscale.com/docs/features/access-control/acls)\n\n## Dibujar la política antes del archivo\n\nSupongamos una notebook, un host de desarrollo y una VPS. El objetivo es notebook → host por SSH, host → VPS por HTTPS, y ningún acceso de la notebook a la base de datos de la VPS. Esa matriz se puede revisar sin conocer la sintaxis de HuJSON.\n\n| Origen | Destino | Puerto | Decisión |\n| --- | --- | --- | --- |\n| Notebook de trabajo | Host de desarrollo | TCP 22 | Permitir |\n| Host de desarrollo | API interna de la VPS | TCP 443 | Permitir |\n| Notebook de trabajo | Base de datos de la VPS | TCP 5432 | Denegar |\n\nUna forma esquemática de llevarla a grants sería:\n\n```json\n{\n \"tagOwners\": {\n \"tag:dev-host\": [\"autogroup:admin\"],\n \"tag:internal-api\": [\"autogroup:admin\"]\n },\n \"grants\": [\n {\n \"src\": [\"persona@ejemplo.com\"],\n \"dst\": [\"tag:dev-host\"],\n \"ip\": [\"tcp:22\"]\n },\n {\n \"src\": [\"tag:dev-host\"],\n \"dst\": [\"tag:internal-api\"],\n \"ip\": [\"tcp:443\"]\n }\n ]\n}\n```\n\nEs un ejemplo para adaptar: los nombres y la identidad son ficticios; los tags sólo tienen sentido si los dispositivos tienen esas etiquetas asignadas. Antes de aplicar una política real, revisá los grants y ACL existentes: una regla amplia que permanezca activa puede seguir habilitando tráfico. Las políticas permiten sumar accesos, no escribir una regla `deny` para restar los que otra ya concedió. [Sintaxis de grants](https://tailscale.com/docs/reference/syntax/grants) · [Tags](https://tailscale.com/docs/features/tags)\n\nEl `src` por correo identifica al usuario, no exclusivamente a su notebook: también puede habilitar sus otros dispositivos con identidad de usuario. Para limitarlo a una sola máquina, usá un selector de dispositivo, como su IP de Tailscale o un alias `hosts`, y verificá el alcance en la vista previa. [Selectores de grants](https://tailscale.com/docs/reference/syntax/grants)\n\n## SSH tiene dos modos de operación\n\n**SSH habitual sobre Tailscale** conserva `sshd`, usuarios y claves SSH del host; la tailnet aporta una ruta privada y el grant habilita el puerto. **Tailscale SSH** deja que Tailscale gestione autenticación y autorización SSH en nodos compatibles, con sus propias reglas `ssh` y opciones como `check`. Activar sólo el grant de TCP 22 no equivale a haber configurado Tailscale SSH. Tampoco sirve para hacer Tailscale SSH hacia una máquina que sólo está detrás de un subnet router. [Tailscale SSH](https://tailscale.com/docs/features/tailscale-ssh)\n\nSi ya existe un flujo SSH que funciona para Orca, el primer paso puede ser conservarlo y limitar la ruta. Una migración a Tailscale SSH merece su propia prueba de usuarios, sesiones y recuperación.\n\n## Probar que el límite existe\n\nPrimero usá **Preview rules** para inspeccionar los destinos que ve una identidad y agregá tests de política para las conexiones esperadas. Después probá desde un dispositivo real: SSH al host permitido y conexión al puerto restringido de un destino que esté encendido y escuchando. Un timeout hacia una máquina apagada no demuestra que un grant esté funcionando. [Editar y previsualizar políticas](https://tailscale.com/docs/features/tailnet-policy-file/manage-tailnet-policies)\n\nPara diagnosticar, `tailscale ping --tsmp` verifica conectividad antes de comprobar la política; `tailscale ping --icmp` verifica conectividad incluyendo las reglas. Si ambos pasan pero la aplicación falla, revisá el puerto, el servicio y sus permisos. Para el puerto concreto, probá el protocolo real: un ping no verifica que TCP 22 o 443 esté habilitado. [Diagnóstico de políticas](https://tailscale.com/docs/features/tailnet-policy-file/manage-tailnet-policies)\n\nEl resultado que queremos poder escribir en una línea es: «esta identidad llega a este servicio por este puerto; a aquel otro no». Con esa política lista, el [caso de un entorno con agentes](/entrada/tailscale-entorno-agentes) muestra dónde ubicar cada conexión.\n" }, { "slug": "comparar-harness-cli-codex-claude-opencode-cline", "title": "Comparar harness CLI: Codex, Claude Code, OpenCode V2, Cline y OMP", "summary": "Ventajas, diferencias y desventajas de cinco harness de programación: cómo elegirlos, repartir responsabilidades y evaluar el costo real de trabajar con agentes.", "type": "editorial", "order": 18, "tags": [ "harness", "cli", "codex", "claude-code", "opencode", "cline", "omp", "agentes", "permisos" ], "related": [ "guia-escalado-modelos", "terminal-vs-web-superficies-trabajo", "orquestacion", "enrutamiento-modelo-esfuerzo-rol-harness" ], "area": "Gobierno de agentes", "glyph": "⚿", "hue": "rgba(168,106,255,.24)", "file": "comparar-harness-cli-codex-claude-opencode-cline.md", "html": "\n\nActualizada el 12 de octubre de 2026. Las capacidades dependen de la versión y la configuración instalada.
\n
Elegir un agente de programación suele empezar por una pregunta: ¿qué modelo conviene usar? Pero hay otra decisión que cambia el trabajo cotidiano: qué harness va a convertir las respuestas de ese modelo en acciones sobre un proyecto.
\nCodex CLI, Claude Code, OpenCode, Cline y Oh My Pi (OMP) pueden ocupar ese lugar. Comparten el objetivo de trabajar con código y herramientas, pero ofrecen distintas maneras de organizar contexto, permisos, extensiones y ejecución. Entender esas diferencias permite elegir con criterio y también combinarlos sin convertir el repositorio en una pelea de cuatro agentes por el mismo archivo.
\nEsta comparación distingue capacidades documentadas de recomendaciones editoriales. Los roles sugeridos son una propuesta de uso; no representan un benchmark de calidad, velocidad o costo.
\nEl modelo interpreta información y propone acciones. El harness administra el ciclo de trabajo: prepara el contexto, expone herramientas, ejecuta llamadas, recoge resultados y permite continuar hasta obtener una entrega o encontrar un bloqueo.
\nLa CLI es la interfaz de terminal para acceder a ese sistema. Harness y CLI están relacionados, pero no son sinónimos: un mismo agente puede tener terminal, extensión de editor y aplicación de escritorio.
\nEsto explica por qué cambiar de interfaz no siempre equivale a cambiar de agente y por qué usar un modelo parecido en dos herramientas puede producir experiencias distintas. Importan las instrucciones que recibe, las herramientas disponibles y la forma en que se gestiona la sesión.
\nPara elegir conviene mirar cinco cosas: el modelo disponible, el control de ejecución, la continuidad del contexto, la integración con el proyecto y el costo de operar todo ese conjunto.
\nCodex CLI permite inspeccionar un repositorio, editar archivos y ejecutar herramientas locales. Admite trabajo interactivo y automatización mediante codex exec, además de seleccionar modelo, esfuerzo de razonamiento y permisos. Documentación oficial.
Su sandbox establece límites para los comandos que ejecuta, con implementación específica por plataforma. La política de aprobación decide cuándo una acción necesita autorización; es una capa diferente del sandbox. Sandbox de Codex.
\nVentaja editorial: resulta atractivo cuando querés delegar una implementación y revisar una entrega concreta: cambios, comandos ejecutados y validación. El límite de ejecución ayuda a definir qué puede hacer el agente durante ese trabajo.
\nDesventaja práctica: un entorno mal preparado puede bloquear instalaciones, acceso de red o herramientas que el proyecto necesita. Resolverlo exige configurar permisos y dependencias; dar acceso total como respuesta automática elimina una parte del control que motivó la elección.
\nCodex también admite proveedores personalizados con un endpoint compatible con Responses API y proveedores locales mediante --oss. No basta con que el servicio ofrezca Chat Completions: hay que validar protocolo, herramientas y autenticación. Configuración de proveedores.
Dónde lo pondría: implementación delimitada, diagnóstico de errores y revisión de cambios que se puedan comprobar con las herramientas reales del repositorio.
\nClaude Code dispone de contexto de proyecto mediante CLAUDE.md, skills, MCP, hooks y plugins. Los hooks permiten asociar acciones al ciclo de ejecución. Extensiones de Claude Code.
Sus subagentes pueden tener instrucciones, herramientas y permisos propios, además de contexto separado. Sus solicitudes consumen los límites de uso correspondientes; delegar no vuelve gratuito el trabajo. Subagentes de Claude Code.
\nVentaja editorial: ofrece piezas útiles para convertir un flujo habitual en una configuración reutilizable. Por ejemplo, separar exploración, implementación y revisión con responsabilidades claras.
\nDesventaja práctica: cada especialización agrega algo que mantener. Instrucciones repetidas, hooks innecesarios y delegaciones demasiado amplias pueden aumentar el consumo y dificultar entender por qué el agente actuó de determinada manera.
\nSu propuesta está centrada en el ecosistema Claude. Eso simplifica algunas decisiones, pero conviene considerarlo si buscás una infraestructura de ejecución que alterne entre proveedores independientes.
\nDónde lo pondría: como candidato a coordinar tareas que requieren dividir responsabilidades y sostener convenciones del proyecto. Ese rol es una decisión de arquitectura, no una afirmación de superioridad frente a Codex.
\nEl sitio oficial de OpenCode referencia V2 en su instalación y presenta una herramienta abierta disponible en terminal, editor y escritorio, con soporte para múltiples proveedores y modelos locales. OpenCode. Esta editorial cubre su oferta actual; no atribuye a V2 un listado de mejoras frente a V1 sin una comparación de versiones.
\nOpenCode documenta agentes principales, subagentes y configuración de modelos por agente. Incluye Build y Plan, con distinto acceso a herramientas. Agentes. Sus permisos permiten autorizar, preguntar o denegar acciones; la documentación describe defaults mayormente permisivos. Permisos.
\nVentaja editorial: permite diseñar un reparto de modelos según la tarea. Podés probar un proveedor para exploración y otro para implementación sin reemplazar necesariamente toda la interfaz de trabajo.
\nDesventaja práctica: esa libertad traslada decisiones al operador. Hay que evaluar modelos, compatibilidad con herramientas, límites del proveedor y comportamiento ante errores. Que dos modelos aparezcan en el mismo selector no significa que resuelvan una tarea con la misma confiabilidad.
\nV2 tiene documentación y esquema propios: permissions, shell y subagent reemplazan nombres de V1. “Allow always” guarda aprobaciones por proyecto; los subagentes usan sus propios permisos. Revisá esos alcances antes de migrar. Permisos V2.
La configuración de permisos merece atención propia. Una regla del harness y una barrera del sistema operativo son mecanismos diferentes; no corresponde tratarlos como equivalentes.
\nDónde lo pondría: ejecutores especializados y pruebas controladas de proveedores. Para reducir costos, mediría tareas aceptadas y correcciones posteriores, no solamente precio por token.
\nCline tiene CLI interactiva y modo headless. Documenta ejecución desde pipes, salida JSON, selección de proveedor mediante autenticación y gestión de MCP. También contempla ejecución sin intervención mediante autoaprobación, que puede modificar archivos y ejecutar comandos. CLI de Cline.
\nVentaja editorial: es un candidato práctico para encargos puntuales que reciben una entrada concreta y devuelven un resultado: analizar un diff, explicar un fallo o preparar una revisión. Su CLI permite incorporar esas tareas a scripts.
\nDesventaja práctica: un encargo aparentemente pequeño puede crecer si no tiene límite. Un pedido de revisión puede terminar convertido en una sesión de implementación si el objetivo y los permisos quedan abiertos. Además, cambiar de proveedor requiere volver a evaluar la calidad del resultado.
\nLa referencia actual de Cline marca --auto-approve con default true y no ofrece una allowlist/denylist nativa de comandos shell: remite a hooks PreToolUse. No des por hecho que habrá confirmación ni que un encargo de revisión será de sólo lectura. Controles de CLI.
Headless describe una forma de ejecutar sin interfaz interactiva; no acredita por sí solo aislamiento ni confiabilidad. Para automatizar, hace falta decidir qué cambios están autorizados y cómo se acepta la salida.
\nDónde lo pondría: como comodín para tareas acotadas y una segunda mirada sobre cambios preparados por otro agente. También puede asumir trabajo principal si encaja mejor con el proyecto; el rol de comodín es una elección operativa.
\nOMP es un fork de Pi orientado a programación. Su propuesta combina acceso a múltiples proveedores con herramientas integradas de búsqueda, LSP, depuración, ejecución y edición con anclajes hash. También admite extensiones y subagentes. Proyecto OMP.
\nVentaja editorial: es un candidato sólido para experimentar con una misma familia de modelos sobre superficies de herramientas distintas. Sus herramientas especializadas pueden resultar útiles en navegación simbólica, refactors localizados e inspección de código.
\nDesventaja práctica: más herramientas no garantizan mejor resultado. La integración LSP depende del entorno y del lenguaje, las extensiones requieren mantenimiento y no corresponde equiparar automáticamente sus controles de permisos con el sandbox de Codex.
\nDónde lo pondría: exploración estructural, cambios acotados y pruebas A/B contra otro harness usando el mismo modelo. Los beneficios alegados por su proyecto deben comprobarse en el repositorio propio; no son un benchmark independiente frente a Codex.
\nLa siguiente tabla resume el criterio editorial desarrollado arriba.
\n| Harness | \nVentaja para aprovechar | \nDesventaja a gestionar | \nRol sugerido | \n
|---|---|---|---|
| Codex CLI | \nTrabajo local con límites de ejecución configurables | \nFricción si permisos o entorno no acompañan al proyecto | \nImplementación y validación delimitadas | \n
| Claude Code | \nEspecialización mediante contexto, extensiones y subagentes | \nConsumo y mantenimiento de la configuración | \nCoordinación de responsabilidades | \n
| OpenCode V2 | \nFlexibilidad para combinar proveedores y agentes | \nEvaluación y configuración a cargo del operador | \nEjecutores especializados | \n
| Cline CLI | \nEncargos interactivos o integrados a scripts | \nControl del alcance y aceptación de la salida | \nComodín y revisión adicional | \n
| OMP | \nLSP, herramientas de edición y ejecución extensibles; multiproveedor | \nComplejidad de configuración y validación de controles | \nExploración estructural y experimentación entre harnesses | \n
Los roles se superponen. El enfoque de asignar también el harness por función se desarrolla en Enrutamiento avanzado: modelo, esfuerzo, rol y harness. La tabla propone por dónde empezar a probar cada herramienta, no exclusividades.
\nUna combinación razonable empieza con un responsable de la tarea. Ese agente o persona conserva el objetivo, decide qué se delega y acepta el resultado. Cada ejecutor recibe un encargo que puede terminar de forma verificable.
\nPor ejemplo, para corregir una integración:
\nEl reparto puede hacerse entre estos cinco harness, pero no requiere usarlos todos. Dos herramientas con responsabilidades claras pueden aportar más que cinco sesiones abiertas con contexto duplicado.
\nLa delegación entre productos necesita una integración explícita: comando, script, API u otro mecanismo disponible. Un subagente nativo de un harness no se convierte automáticamente en una sesión de otro.
\nCada encargo debería definir objetivo, archivos autorizados, restricciones, validación y salida esperada. Ese contrato hace posible cambiar de herramienta sin reconstruir toda la intención del trabajo.
\nElegí algunas tareas representativas: un bug reproducible, una modificación pequeña y una revisión de código. Prepará el mismo punto de partida y registrá modelo, versión, permisos y contexto de cada prueba.
\nCompará tiempo hasta obtener un resultado aceptable, intervenciones humanas, costo o consumo de cuota y defectos encontrados después. Cuando cambies simultáneamente de modelo y harness, interpretá el resultado como evaluación de la combinación completa.
\nLa pregunta que importa es cuánto trabajo confiable obtenés por el costo total. Ese costo incluye revisar, corregir, mantener configuración y recuperar contexto, además de pagar inferencia.
\nCodex, Claude Code, OpenCode, Cline y OMP ofrecen puntos de entrada distintos a un mismo problema: transformar una intención en trabajo ejecutable y revisable.
\nLa elección mejora cuando el proyecto conserva sus contratos, convenciones y comprobaciones fuera de una sesión particular. Así, el harness puede cambiar y el equipo sigue sabiendo qué había que hacer, qué se hizo y cómo se verificó.
\nLa autonomía que vale la pena ampliar es la que produce evidencia suficiente para confiar en la entrega.
\n", "headings": [ { "label": "Qué es un harness y qué aporta la CLI", "depth": 2, "id": "que-es-un-harness-y-que-aporta-la-cli" }, { "label": "Codex CLI y el trabajo dentro de límites explícitos", "depth": 2, "id": "codex-cli-y-el-trabajo-dentro-de-limites-explicitos" }, { "label": "Claude Code y la especialización del flujo de trabajo", "depth": 2, "id": "claude-code-y-la-especializacion-del-flujo-de-trabajo" }, { "label": "OpenCode V2 y la flexibilidad de proveedores", "depth": 2, "id": "opencode-v2-y-la-flexibilidad-de-proveedores" }, { "label": "Cline y las tareas que entran y salen de la terminal", "depth": 2, "id": "cline-y-las-tareas-que-entran-y-salen-de-la-terminal" }, { "label": "Oh My Pi (OMP) y la instrumentación del harness", "depth": 2, "id": "oh-my-pi-omp-y-la-instrumentacion-del-harness" }, { "label": "Comparación de ventajas y costos operativos", "depth": 2, "id": "comparacion-de-ventajas-y-costos-operativos" }, { "label": "Cómo combinarlos sin multiplicar el desorden", "depth": 2, "id": "como-combinarlos-sin-multiplicar-el-desorden" }, { "label": "Cómo evaluar cuál conviene en tu proyecto", "depth": 2, "id": "como-evaluar-cual-conviene-en-tu-proyecto" }, { "label": "Elegir según la responsabilidad que vas a delegar", "depth": 2, "id": "elegir-segun-la-responsabilidad-que-vas-a-delegar" } ], "raw": "---\nslug: comparar-harness-cli-codex-claude-opencode-cline\ntitle: \"Comparar harness CLI: Codex, Claude Code, OpenCode V2, Cline y OMP\"\ntype: editorial\norder: 18\nsummary: \"Ventajas, diferencias y desventajas de cinco harness de programación: cómo elegirlos, repartir responsabilidades y evaluar el costo real de trabajar con agentes.\"\ntags: [harness, cli, codex, claude-code, opencode, cline, omp, agentes, permisos]\nrelated: [guia-escalado-modelos, terminal-vs-web-superficies-trabajo, orquestacion, enrutamiento-modelo-esfuerzo-rol-harness]\narea: Gobierno de agentes\nglyph: ⚿\nhue: rgba(168,106,255,.24)\n---\n\n# Comparar harness CLI: Codex, Claude Code, OpenCode V2, Cline y OMP\n\n> Actualizada el 12 de octubre de 2026. Las capacidades dependen de la versión y la configuración instalada.\n\nElegir un agente de programación suele empezar por una pregunta: ¿qué modelo conviene usar? Pero hay otra decisión que cambia el trabajo cotidiano: qué harness va a convertir las respuestas de ese modelo en acciones sobre un proyecto.\n\nCodex CLI, Claude Code, OpenCode, Cline y Oh My Pi (OMP) pueden ocupar ese lugar. Comparten el objetivo de trabajar con código y herramientas, pero ofrecen distintas maneras de organizar contexto, permisos, extensiones y ejecución. Entender esas diferencias permite elegir con criterio y también combinarlos sin convertir el repositorio en una pelea de cuatro agentes por el mismo archivo.\n\nEsta comparación distingue capacidades documentadas de recomendaciones editoriales. Los roles sugeridos son una propuesta de uso; no representan un benchmark de calidad, velocidad o costo.\n\n## Qué es un harness y qué aporta la CLI\n\nEl modelo interpreta información y propone acciones. El harness administra el ciclo de trabajo: prepara el contexto, expone herramientas, ejecuta llamadas, recoge resultados y permite continuar hasta obtener una entrega o encontrar un bloqueo.\n\nLa CLI es la interfaz de terminal para acceder a ese sistema. Harness y CLI están relacionados, pero no son sinónimos: un mismo agente puede tener terminal, extensión de editor y aplicación de escritorio.\n\nEsto explica por qué cambiar de interfaz no siempre equivale a cambiar de agente y por qué usar un modelo parecido en dos herramientas puede producir experiencias distintas. Importan las instrucciones que recibe, las herramientas disponibles y la forma en que se gestiona la sesión.\n\nPara elegir conviene mirar cinco cosas: el modelo disponible, el control de ejecución, la continuidad del contexto, la integración con el proyecto y el costo de operar todo ese conjunto.\n\n## Codex CLI y el trabajo dentro de límites explícitos\n\nCodex CLI permite inspeccionar un repositorio, editar archivos y ejecutar herramientas locales. Admite trabajo interactivo y automatización mediante `codex exec`, además de seleccionar modelo, esfuerzo de razonamiento y permisos. [Documentación oficial](https://learn.chatgpt.com/docs/codex/cli).\n\nSu sandbox establece límites para los comandos que ejecuta, con implementación específica por plataforma. La política de aprobación decide cuándo una acción necesita autorización; es una capa diferente del sandbox. [Sandbox de Codex](https://learn.chatgpt.com/docs/sandboxing).\n\n**Ventaja editorial:** resulta atractivo cuando querés delegar una implementación y revisar una entrega concreta: cambios, comandos ejecutados y validación. El límite de ejecución ayuda a definir qué puede hacer el agente durante ese trabajo.\n\n**Desventaja práctica:** un entorno mal preparado puede bloquear instalaciones, acceso de red o herramientas que el proyecto necesita. Resolverlo exige configurar permisos y dependencias; dar acceso total como respuesta automática elimina una parte del control que motivó la elección.\n\nCodex también admite proveedores personalizados con un endpoint compatible con Responses API y proveedores locales mediante `--oss`. No basta con que el servicio ofrezca Chat Completions: hay que validar protocolo, herramientas y autenticación. [Configuración de proveedores](https://learn.chatgpt.com/docs/config-file/config-advanced).\n\n**Dónde lo pondría:** implementación delimitada, diagnóstico de errores y revisión de cambios que se puedan comprobar con las herramientas reales del repositorio.\n\n## Claude Code y la especialización del flujo de trabajo\n\nClaude Code dispone de contexto de proyecto mediante `CLAUDE.md`, skills, MCP, hooks y plugins. Los hooks permiten asociar acciones al ciclo de ejecución. [Extensiones de Claude Code](https://code.claude.com/docs/en/features-overview).\n\nSus subagentes pueden tener instrucciones, herramientas y permisos propios, además de contexto separado. Sus solicitudes consumen los límites de uso correspondientes; delegar no vuelve gratuito el trabajo. [Subagentes de Claude Code](https://code.claude.com/docs/en/sub-agents).\n\n**Ventaja editorial:** ofrece piezas útiles para convertir un flujo habitual en una configuración reutilizable. Por ejemplo, separar exploración, implementación y revisión con responsabilidades claras.\n\n**Desventaja práctica:** cada especialización agrega algo que mantener. Instrucciones repetidas, hooks innecesarios y delegaciones demasiado amplias pueden aumentar el consumo y dificultar entender por qué el agente actuó de determinada manera.\n\nSu propuesta está centrada en el ecosistema Claude. Eso simplifica algunas decisiones, pero conviene considerarlo si buscás una infraestructura de ejecución que alterne entre proveedores independientes.\n\n**Dónde lo pondría:** como candidato a coordinar tareas que requieren dividir responsabilidades y sostener convenciones del proyecto. Ese rol es una decisión de arquitectura, no una afirmación de superioridad frente a Codex.\n\n## OpenCode V2 y la flexibilidad de proveedores\n\nEl sitio oficial de OpenCode referencia V2 en su instalación y presenta una herramienta abierta disponible en terminal, editor y escritorio, con soporte para múltiples proveedores y modelos locales. [OpenCode](https://opencode.ai/). Esta editorial cubre su oferta actual; no atribuye a V2 un listado de mejoras frente a V1 sin una comparación de versiones.\n\nOpenCode documenta agentes principales, subagentes y configuración de modelos por agente. Incluye Build y Plan, con distinto acceso a herramientas. [Agentes](https://opencode.ai/v2/docs/agents/). Sus permisos permiten autorizar, preguntar o denegar acciones; la documentación describe defaults mayormente permisivos. [Permisos](https://opencode.ai/v2/docs/permissions/).\n\n**Ventaja editorial:** permite diseñar un reparto de modelos según la tarea. Podés probar un proveedor para exploración y otro para implementación sin reemplazar necesariamente toda la interfaz de trabajo.\n\n**Desventaja práctica:** esa libertad traslada decisiones al operador. Hay que evaluar modelos, compatibilidad con herramientas, límites del proveedor y comportamiento ante errores. Que dos modelos aparezcan en el mismo selector no significa que resuelvan una tarea con la misma confiabilidad.\n\nV2 tiene documentación y esquema propios: `permissions`, `shell` y `subagent` reemplazan nombres de V1. “Allow always” guarda aprobaciones por proyecto; los subagentes usan sus propios permisos. Revisá esos alcances antes de migrar. [Permisos V2](https://opencode.ai/v2/docs/permissions/).\n\nLa configuración de permisos merece atención propia. Una regla del harness y una barrera del sistema operativo son mecanismos diferentes; no corresponde tratarlos como equivalentes.\n\n**Dónde lo pondría:** ejecutores especializados y pruebas controladas de proveedores. Para reducir costos, mediría tareas aceptadas y correcciones posteriores, no solamente precio por token.\n\n## Cline y las tareas que entran y salen de la terminal\n\nCline tiene CLI interactiva y modo headless. Documenta ejecución desde pipes, salida JSON, selección de proveedor mediante autenticación y gestión de MCP. También contempla ejecución sin intervención mediante autoaprobación, que puede modificar archivos y ejecutar comandos. [CLI de Cline](https://docs.cline.bot/usage/cli-overview).\n\n**Ventaja editorial:** es un candidato práctico para encargos puntuales que reciben una entrada concreta y devuelven un resultado: analizar un diff, explicar un fallo o preparar una revisión. Su CLI permite incorporar esas tareas a scripts.\n\n**Desventaja práctica:** un encargo aparentemente pequeño puede crecer si no tiene límite. Un pedido de revisión puede terminar convertido en una sesión de implementación si el objetivo y los permisos quedan abiertos. Además, cambiar de proveedor requiere volver a evaluar la calidad del resultado.\n\nLa referencia actual de Cline marca `--auto-approve` con default `true` y no ofrece una allowlist/denylist nativa de comandos shell: remite a hooks `PreToolUse`. No des por hecho que habrá confirmación ni que un encargo de revisión será de sólo lectura. [Controles de CLI](https://docs.cline.bot/usage/cli-overview).\n\nHeadless describe una forma de ejecutar sin interfaz interactiva; no acredita por sí solo aislamiento ni confiabilidad. Para automatizar, hace falta decidir qué cambios están autorizados y cómo se acepta la salida.\n\n**Dónde lo pondría:** como comodín para tareas acotadas y una segunda mirada sobre cambios preparados por otro agente. También puede asumir trabajo principal si encaja mejor con el proyecto; el rol de comodín es una elección operativa.\n\n## Oh My Pi (OMP) y la instrumentación del harness\n\nOMP es un fork de Pi orientado a programación. Su propuesta combina acceso a múltiples proveedores con herramientas integradas de búsqueda, LSP, depuración, ejecución y edición con anclajes hash. También admite extensiones y subagentes. [Proyecto OMP](https://github.com/can1357/oh-my-pi).\n\n**Ventaja editorial:** es un candidato sólido para experimentar con una misma familia de modelos sobre superficies de herramientas distintas. Sus herramientas especializadas pueden resultar útiles en navegación simbólica, refactors localizados e inspección de código.\n\n**Desventaja práctica:** más herramientas no garantizan mejor resultado. La integración LSP depende del entorno y del lenguaje, las extensiones requieren mantenimiento y no corresponde equiparar automáticamente sus controles de permisos con el sandbox de Codex.\n\n**Dónde lo pondría:** exploración estructural, cambios acotados y pruebas A/B contra otro harness usando el mismo modelo. Los beneficios alegados por su proyecto deben comprobarse en el repositorio propio; no son un benchmark independiente frente a Codex.\n\n## Comparación de ventajas y costos operativos\n\nLa siguiente tabla resume el criterio editorial desarrollado arriba.\n\n| Harness | Ventaja para aprovechar | Desventaja a gestionar | Rol sugerido |\n| --- | --- | --- | --- |\n| Codex CLI | Trabajo local con límites de ejecución configurables | Fricción si permisos o entorno no acompañan al proyecto | Implementación y validación delimitadas |\n| Claude Code | Especialización mediante contexto, extensiones y subagentes | Consumo y mantenimiento de la configuración | Coordinación de responsabilidades |\n| OpenCode V2 | Flexibilidad para combinar proveedores y agentes | Evaluación y configuración a cargo del operador | Ejecutores especializados |\n| Cline CLI | Encargos interactivos o integrados a scripts | Control del alcance y aceptación de la salida | Comodín y revisión adicional |\n| OMP | LSP, herramientas de edición y ejecución extensibles; multiproveedor | Complejidad de configuración y validación de controles | Exploración estructural y experimentación entre harnesses |\n\nLos roles se superponen. El enfoque de asignar también el harness por función se desarrolla en [Enrutamiento avanzado: modelo, esfuerzo, rol y harness](/entrada/enrutamiento-modelo-esfuerzo-rol-harness). La tabla propone por dónde empezar a probar cada herramienta, no exclusividades.\n\n## Cómo combinarlos sin multiplicar el desorden\n\nUna combinación razonable empieza con un responsable de la tarea. Ese agente o persona conserva el objetivo, decide qué se delega y acepta el resultado. Cada ejecutor recibe un encargo que puede terminar de forma verificable.\n\nPor ejemplo, para corregir una integración:\n\n1. El responsable define el contrato esperado y reproduce el error.\n2. Un ejecutor prepara el cambio en una rama o worktree propio.\n3. Otro agente revisa el diff con acceso de lectura y busca casos omitidos.\n4. El responsable comprueba la ejecución real, resuelve observaciones y prepara la entrega.\n\nEl reparto puede hacerse entre estos cinco harness, pero no requiere usarlos todos. Dos herramientas con responsabilidades claras pueden aportar más que cinco sesiones abiertas con contexto duplicado.\n\nLa delegación entre productos necesita una integración explícita: comando, script, API u otro mecanismo disponible. Un subagente nativo de un harness no se convierte automáticamente en una sesión de otro.\n\nCada encargo debería definir objetivo, archivos autorizados, restricciones, validación y salida esperada. Ese contrato hace posible cambiar de herramienta sin reconstruir toda la intención del trabajo.\n\n## Cómo evaluar cuál conviene en tu proyecto\n\nElegí algunas tareas representativas: un bug reproducible, una modificación pequeña y una revisión de código. Prepará el mismo punto de partida y registrá modelo, versión, permisos y contexto de cada prueba.\n\nCompará tiempo hasta obtener un resultado aceptable, intervenciones humanas, costo o consumo de cuota y defectos encontrados después. Cuando cambies simultáneamente de modelo y harness, interpretá el resultado como evaluación de la combinación completa.\n\nLa pregunta que importa es cuánto trabajo confiable obtenés por el costo total. Ese costo incluye revisar, corregir, mantener configuración y recuperar contexto, además de pagar inferencia.\n\n## Elegir según la responsabilidad que vas a delegar\n\nCodex, Claude Code, OpenCode, Cline y OMP ofrecen puntos de entrada distintos a un mismo problema: transformar una intención en trabajo ejecutable y revisable.\n\nLa elección mejora cuando el proyecto conserva sus contratos, convenciones y comprobaciones fuera de una sesión particular. Así, el harness puede cambiar y el equipo sigue sabiendo qué había que hacer, qué se hizo y cómo se verificó.\n\nLa autonomía que vale la pena ampliar es la que produce evidencia suficiente para confiar en la entrega.\n" }, { "slug": "enrutamiento-modelo-esfuerzo-rol-harness", "title": "Enrutamiento avanzado de agentes: modelo, esfuerzo, rol y harness", "summary": "Por qué elegir un agente exige evaluar no solo el modelo y su razonamiento, sino la función y el harness: Codex frente a OMP como caso de contraste.", "type": "editorial", "order": 19, "tags": [ "orquestacion", "harness", "cli", "codex", "omp", "routing", "agentes", "benchmarks", "gobierno" ], "related": [ "comparar-harness-cli-codex-claude-opencode-cline", "guia-escalado-modelos", "orquestacion", "protocolos-humanos-cuota-rct-overdrive" ], "area": "Gobierno de agentes", "glyph": "⌘", "hue": "rgba(87,217,232,.24)", "file": "enrutamiento-modelo-esfuerzo-rol-harness.md", "html": "\n\nPropuesta arquitectónica, 8 de octubre de 2026. No describe una implementación ya validada. Diferenciamos capacidades documentadas, hipótesis y resultados que todavía hay que medir.
\n
Las primeras estrategias de orquestación respondían dos preguntas: qué modelo utilizar y cuánto esfuerzo de razonamiento asignarle. Incorporar roles agrega otra: para qué función se lo necesita. Pero todavía falta una decisión: en qué harness ejecutar ese trabajo.
\nLa configuración operativa deja de ser solo modelo + esfuerzo y pasa a ser modelo + esfuerzo + rol + harness. No es una fórmula de puntuación ni una afirmación de que cuatro variables bastan: permisos, repositorio, presupuesto, contexto y disponibilidad siguen siendo restricciones de elegibilidad.
Un modelo puede mostrar comportamientos diferentes según cómo el harness le entregue instrucciones, resultados de lectura, herramientas de edición y mecanismos de compactación. Por eso, comparar modelos ignorando su entorno de ejecución puede confundir causas.
\nCodex CLI y Oh My Pi pueden operar con modelos de la familia OpenAI, según la autenticación y las versiones compatibles. Eso permite diseñar un contraste útil: mismo modelo, mismo esfuerzo y misma tarea; distinto harness.
\nCodex ofrece un ciclo integrado de lectura, edición, comandos, aprobaciones y sandbox. Es una opción inicial razonable para cambios completos que exigen pruebas y una entrega verificable. Codex.
\nOMP, derivado de Pi, ofrece herramientas especializadas, incluida integración LSP, depuración y edición con anclajes hash, además de extensibilidad y acceso multiproveedor. Es un candidato interesante para explorar referencias, localizar símbolos y hacer modificaciones focalizadas. OMP.
\nLa diferencia no demuestra que uno programe mejor que el otro. LSP puede ahorrar exploración cuando el lenguaje y el servidor están disponibles; también puede aportar poco en un proyecto pequeño o mal indexado. Un flujo integrado puede mejorar la coherencia de tareas largas, pero eso también requiere medición. Los benchmarks publicados por un proveedor no sustituyen las pruebas sobre un proyecto propio.
\n| Dimensión | \nCodex CLI | \nOMP | \nHipótesis que vale probar | \n
|---|---|---|---|
| Ciclo de ejecución | \nHerramientas, comandos y controles integrados | \nSuperficie de herramientas especializada y extensible | \n¿Cuál termina la tarea con menos intervenciones? | \n
| Exploración | \nLectura y búsqueda del repositorio | \nBúsqueda y operaciones LSP cuando están disponibles | \n¿Cuál localiza cambios correctos con menos lecturas? | \n
| Edición | \nEdición según herramientas del agente | \nEdición hash-anchored y operaciones estructuradas | \n¿Cuál produce menos intentos fallidos? | \n
| Contexto | \nGestión integrada de sesión y compactación | \nConfiguración y estrategias propias de sesión | \n¿Cuál conserva mejor las restricciones? | \n
| Seguridad | \nSandbox y aprobaciones explícitos | \nControles dependientes de configuración y herramientas | \n¿Cuál respeta el mismo contrato de permisos? | \n
| Costo | \nCuota de suscripción o API, según acceso | \nSuscripción compatible u otras API, según proveedor | \n¿Cuál reduce costo total por tarea aceptada? | \n
No hay que confundir harness con proveedor de inferencia. En OMP, la ruta de autenticación puede afectar facturación, límites y modelos disponibles; una suscripción de Codex y una clave de OpenAI API no son intercambiables por definición. Antes del A/B, fijar el identificador efectivo de modelo y las condiciones de acceso. Un alias del harness tampoco basta: OpenCode V2, por ejemplo, separa el ID del catálogo de modelID, enviado al proveedor. Registrá ambos antes de afirmar que dos ejecuciones usaron el mismo modelo. Aliases y proveedores.
Un coordinador que solo escoge el modelo más fuerte puede terminar pagando por capacidad ociosa y usando herramientas inadecuadas. Un planificador más fino resuelve la tarea por etapas:
\nEl rol no es una etiqueta estética: define el contrato. Un revisor no debería adquirir permisos de escritura por elegir otro CLI. El harness se elige después de establecer qué acciones están autorizadas.
\n| Tipo de encargo | \nRol | \nHarness candidato inicial | \nCondición para preferirlo | \n
|---|---|---|---|
| Localizar impacto entre módulos | \nExplorador | \nOMP | \nLSP operativo y ahorro medido de lecturas | \n
| Corregir bug con tests | \nImplementador | \nCodex | \nMayor tasa de resolución aceptada | \n
| Refactor de símbolos | \nImplementador especializado | \nOMP | \nEdición y renombres estructurados verificables | \n
| Cambios transversales | \nImplementador | \nCodex | \nMejor consistencia en tests y contratos | \n
| Revisar un diff | \nRevisor | \nCualquiera elegible, con lectura únicamente | \nMenos defectos omitidos y menor costo de revisión | \n
| Recuperar trabajo fallido | \nDiagnóstico y fallback | \nHarness alternativo permitido | \nEvidencia de que el cambio de herramientas corrige la falla | \n
Son hipótesis de asignación, no propiedades exclusivas de los productos. Si las pruebas contradicen la tabla, cambia la tabla, no la evidencia.
\nPara delegar sin quedar atrapados en una CLI, el coordinador puede construir un sobre de tarea independiente del proveedor:
\ntask_id: BUG-142\nrole: implementer\ngoal: \"Corregir duplicación de eventos sin alterar el contrato HTTP\"\nrepository_ref: \"commit-inmutable\"\nscope:\n writable: [\"src/events/**\", \"tests/events/**\"]\nconstraints:\n network: false\n secrets: none\n production_write: false\nacceptance:\n - \"tests de regresión aprobados\"\n - \"diff acotado al scope\"\noutputs: [\"resumen\", \"diff\", \"tests\", \"uso\", \"bloqueos\"]Ese contrato debe traducirse a mecanismos reales del harness y del sistema operativo. Escribir network: false en un YAML no desconecta la red por arte de magia. Si el harness no puede respetar una restricción crítica, se descarta como candidato, aunque su benchmark sea excelente.
Actualización del 12 de octubre de 2026: el caso operativo V4 ya documenta dirección general con Opus, integración con Sol low y coordinación de paquetes con Sol medium. Implementación LIVE y auditoría se reparten entre familias distintas. Es evidencia de una política adoptada en un proyecto, no de un router automático validado ni de una ventaja medida de rendimiento. La propuesta A/B de este artículo sigue pendiente de esa validación.
\nLa comprobación del harness también sigue siendo una condición de elegibilidad. En la revisión de una instalación OMP 18.10.0 había reglas de rol escritas, pero su carga efectiva y enforcement en sesión no estaban demostrados; además, permitir LSP dejaba por revisar operaciones de renombre. Una etiqueta “lectura” no prueba ausencia de escritura. Antes de asignar un auditor read-only, hay que comprobar el runtime efectivo y las acciones negativas, no sólo el archivo de configuración.
\nPor la misma razón, un aviso de cuota no cambia automáticamente modelo, esfuerzo ni proveedor. La recuperación por fallo técnico y la gestión humana de cuota son decisiones distintas; ninguna autoriza buscar una ruta con menos controles.
\nLa comparación útil no enfrenta modelos distintos por accidente. Para tareas pareadas, mantener iguales: commit inicial, fixtures, modelo e identificador de versión cuando sea posible, esfuerzo efectivo, instrucciones funcionales, alcance, presupuesto y pruebas de aceptación. Documentar diferencias inevitables en prompts de sistema, herramientas y compactación: son precisamente parte del tratamiento experimental.
\nUsar varias tareas representativas y al menos tres repeticiones por configuración, sin reutilizar soluciones previas y con worktrees limpios. Medir:
\nEl indicador central no es la velocidad de generar un patch, sino el costo total por tarea aceptada, incluyendo revisión, retrabajo y fallas. Si las métricas de consumo no son comparables entre proveedores, informarlas por separado y privilegiar calidad y costo monetario observado.
\nUn router avanzado necesita evitar dos trampas. La primera es cambiar automáticamente de harness ante cualquier error: si falla un test por lógica, otro CLI no garantiza resolverlo. La segunda es premiar al agente que reporta éxito más rápido, cuando la verificación independiente dice otra cosa.
\nConviene registrar (tipo de tarea, modelo, esfuerzo, harness, versión, herramientas, permisos, resultado) y actualizar preferencias solo con un tamaño de muestra razonable. Ante fallos de infraestructura o herramientas, permitir fallback compatible. Ante una restricción de seguridad, detener y escalar, no buscar un harness más permisivo.
También importa el costo de cambiar de superficie: instalación, contexto que hay que reconstruir, complejidad de los logs y nuevas clases de errores. Un único harness consistente puede superar a un router sofisticado si la operación es pequeña.
\nLa evolución no consiste en acumular CLIs. Consiste en dejar de considerar al harness una constante invisible.
\nUn coordinador maduro debería poder responder: ¿qué combinación de modelo, esfuerzo, rol y harness produce una entrega verificable para esta función, dentro de las restricciones y el presupuesto disponible?
\nLa respuesta no sale de preferencias de marca. Sale de contratos portables, experimentos reproducibles y métricas de tareas aceptadas. El harness se convierte así en una variable de planificación, no en una religión del terminal.
\nPara una panorámica de los productos y sus compensaciones, ver Comparar harness CLI.
\nPara administrar una ronda ante escasez o vencimiento de cuota, ver RCT y Overdrive: protocolos humanos de gestión de proveedores. La activación corresponde al operador; es una capa distinta del enrutamiento delegado.
\n", "headings": [ { "label": "El cuarto parámetro", "depth": 2, "id": "el-cuarto-parametro" }, { "label": "Caso de contraste: OpenAI en Codex y en OMP", "depth": 2, "id": "caso-de-contraste-openai-en-codex-y-en-omp" }, { "label": "El selector como planificador de trabajo", "depth": 2, "id": "el-selector-como-planificador-de-trabajo" }, { "label": "Una matriz de enrutamiento inicial", "depth": 2, "id": "una-matriz-de-enrutamiento-inicial" }, { "label": "Un contrato portable entre harnesses", "depth": 2, "id": "un-contrato-portable-entre-harnesses" }, { "label": "Del diseño propuesto a una asignación contextual", "depth": 2, "id": "del-diseno-propuesto-a-una-asignacion-contextual" }, { "label": "Benchmark A/B: aislar el efecto del harness", "depth": 2, "id": "benchmark-a-b-aislar-el-efecto-del-harness" }, { "label": "Fallback, aprendizaje y límites", "depth": 2, "id": "fallback-aprendizaje-y-limites" }, { "label": "De elegir el mejor modelo a elegir el mejor entorno de trabajo", "depth": 2, "id": "de-elegir-el-mejor-modelo-a-elegir-el-mejor-entorno-de-trabajo" } ], "raw": "---\nslug: enrutamiento-modelo-esfuerzo-rol-harness\ntitle: \"Enrutamiento avanzado de agentes: modelo, esfuerzo, rol y harness\"\ntype: editorial\norder: 19\nsummary: \"Por qué elegir un agente exige evaluar no solo el modelo y su razonamiento, sino la función y el harness: Codex frente a OMP como caso de contraste.\"\ntags: [orquestacion, harness, cli, codex, omp, routing, agentes, benchmarks, gobierno]\nrelated: [comparar-harness-cli-codex-claude-opencode-cline, guia-escalado-modelos, orquestacion, protocolos-humanos-cuota-rct-overdrive]\narea: Gobierno de agentes\nglyph: ⌘\nhue: rgba(87,217,232,.24)\n---\n\n# Enrutamiento avanzado de agentes: modelo, esfuerzo, rol y harness\n\n> Propuesta arquitectónica, 8 de octubre de 2026. No describe una implementación ya validada. Diferenciamos capacidades documentadas, hipótesis y resultados que todavía hay que medir.\n\n## El cuarto parámetro\n\nLas primeras estrategias de orquestación respondían dos preguntas: **qué modelo** utilizar y **cuánto esfuerzo de razonamiento** asignarle. Incorporar roles agrega otra: **para qué función** se lo necesita. Pero todavía falta una decisión: **en qué harness ejecutar ese trabajo**.\n\nLa configuración operativa deja de ser solo `modelo + esfuerzo` y pasa a ser **`modelo + esfuerzo + rol + harness`**. No es una fórmula de puntuación ni una afirmación de que cuatro variables bastan: permisos, repositorio, presupuesto, contexto y disponibilidad siguen siendo restricciones de elegibilidad.\n\nUn modelo puede mostrar comportamientos diferentes según cómo el harness le entregue instrucciones, resultados de lectura, herramientas de edición y mecanismos de compactación. Por eso, comparar modelos ignorando su entorno de ejecución puede confundir causas.\n\n## Caso de contraste: OpenAI en Codex y en OMP\n\nCodex CLI y Oh My Pi pueden operar con modelos de la familia OpenAI, según la autenticación y las versiones compatibles. Eso permite diseñar un contraste útil: **mismo modelo, mismo esfuerzo y misma tarea; distinto harness**.\n\nCodex ofrece un ciclo integrado de lectura, edición, comandos, aprobaciones y sandbox. Es una opción inicial razonable para cambios completos que exigen pruebas y una entrega verificable. [Codex](https://github.com/openai/codex).\n\nOMP, derivado de Pi, ofrece herramientas especializadas, incluida integración LSP, depuración y edición con anclajes hash, además de extensibilidad y acceso multiproveedor. Es un candidato interesante para explorar referencias, localizar símbolos y hacer modificaciones focalizadas. [OMP](https://github.com/can1357/oh-my-pi).\n\nLa diferencia **no demuestra que uno programe mejor que el otro**. LSP puede ahorrar exploración cuando el lenguaje y el servidor están disponibles; también puede aportar poco en un proyecto pequeño o mal indexado. Un flujo integrado puede mejorar la coherencia de tareas largas, pero eso también requiere medición. Los benchmarks publicados por un proveedor no sustituyen las pruebas sobre un proyecto propio.\n\n| Dimensión | Codex CLI | OMP | Hipótesis que vale probar |\n| --- | --- | --- | --- |\n| Ciclo de ejecución | Herramientas, comandos y controles integrados | Superficie de herramientas especializada y extensible | ¿Cuál termina la tarea con menos intervenciones? |\n| Exploración | Lectura y búsqueda del repositorio | Búsqueda y operaciones LSP cuando están disponibles | ¿Cuál localiza cambios correctos con menos lecturas? |\n| Edición | Edición según herramientas del agente | Edición hash-anchored y operaciones estructuradas | ¿Cuál produce menos intentos fallidos? |\n| Contexto | Gestión integrada de sesión y compactación | Configuración y estrategias propias de sesión | ¿Cuál conserva mejor las restricciones? |\n| Seguridad | Sandbox y aprobaciones explícitos | Controles dependientes de configuración y herramientas | ¿Cuál respeta el mismo contrato de permisos? |\n| Costo | Cuota de suscripción o API, según acceso | Suscripción compatible u otras API, según proveedor | ¿Cuál reduce costo total por tarea aceptada? |\n\nNo hay que confundir **harness** con **proveedor de inferencia**. En OMP, la ruta de autenticación puede afectar facturación, límites y modelos disponibles; una suscripción de Codex y una clave de OpenAI API no son intercambiables por definición. Antes del A/B, fijar el identificador efectivo de modelo y las condiciones de acceso. Un alias del harness tampoco basta: OpenCode V2, por ejemplo, separa el ID del catálogo de `modelID`, enviado al proveedor. Registrá ambos antes de afirmar que dos ejecuciones usaron el mismo modelo. [Aliases y proveedores](https://opencode.ai/v2/docs/providers/).\n\n## El selector como planificador de trabajo\n\nUn coordinador que solo escoge el modelo más fuerte puede terminar pagando por capacidad ociosa y usando herramientas inadecuadas. Un planificador más fino resuelve la tarea por etapas:\n\n1. **Clasificar el trabajo:** exploración, implementación, refactor, depuración, test, revisión o documentación.\n2. **Aplicar restricciones duras:** permisos, secretos, lenguaje, herramientas disponibles, límites de cuota, latencia aceptable y aislamiento requerido.\n3. **Seleccionar un rol:** responsable, explorador, implementador, revisor o verificador; cada rol con alcance y salida esperada.\n4. **Evaluar parejas modelo–harness:** compatibilidad real, esfuerzo configurable, herramientas y evidencia empírica para ese tipo de tarea.\n5. **Ejecutar y verificar:** en worktree aislado, con tests, diff, registro de consumo y aceptación humana cuando corresponda.\n6. **Aprender sin automatizar a ciegas:** registrar resultados, ajustar reglas y conservar una ruta de fallback segura.\n\nEl rol no es una etiqueta estética: define el contrato. Un revisor no debería adquirir permisos de escritura por elegir otro CLI. El harness se elige **después** de establecer qué acciones están autorizadas.\n\n## Una matriz de enrutamiento inicial\n\n| Tipo de encargo | Rol | Harness candidato inicial | Condición para preferirlo |\n| --- | --- | --- | --- |\n| Localizar impacto entre módulos | Explorador | OMP | LSP operativo y ahorro medido de lecturas |\n| Corregir bug con tests | Implementador | Codex | Mayor tasa de resolución aceptada |\n| Refactor de símbolos | Implementador especializado | OMP | Edición y renombres estructurados verificables |\n| Cambios transversales | Implementador | Codex | Mejor consistencia en tests y contratos |\n| Revisar un diff | Revisor | Cualquiera elegible, con lectura únicamente | Menos defectos omitidos y menor costo de revisión |\n| Recuperar trabajo fallido | Diagnóstico y fallback | Harness alternativo permitido | Evidencia de que el cambio de herramientas corrige la falla |\n\nSon **hipótesis de asignación**, no propiedades exclusivas de los productos. Si las pruebas contradicen la tabla, cambia la tabla, no la evidencia.\n\n## Un contrato portable entre harnesses\n\nPara delegar sin quedar atrapados en una CLI, el coordinador puede construir un sobre de tarea independiente del proveedor:\n\n```yaml\ntask_id: BUG-142\nrole: implementer\ngoal: \"Corregir duplicación de eventos sin alterar el contrato HTTP\"\nrepository_ref: \"commit-inmutable\"\nscope:\n writable: [\"src/events/**\", \"tests/events/**\"]\nconstraints:\n network: false\n secrets: none\n production_write: false\nacceptance:\n - \"tests de regresión aprobados\"\n - \"diff acotado al scope\"\noutputs: [\"resumen\", \"diff\", \"tests\", \"uso\", \"bloqueos\"]\n```\n\nEse contrato debe traducirse a mecanismos **reales** del harness y del sistema operativo. Escribir `network: false` en un YAML no desconecta la red por arte de magia. Si el harness no puede respetar una restricción crítica, se descarta como candidato, aunque su benchmark sea excelente.\n\n## Del diseño propuesto a una asignación contextual\n\nActualización del 12 de octubre de 2026: el [caso operativo V4](/entrada/caso-orca-cockpit-multiagente) ya documenta dirección general con Opus, integración con Sol low y coordinación de paquetes con Sol medium. Implementación LIVE y auditoría se reparten entre familias distintas. Es evidencia de una política adoptada en un proyecto, **no de un router automático validado ni de una ventaja medida de rendimiento**. La propuesta A/B de este artículo sigue pendiente de esa validación.\n\nLa comprobación del harness también sigue siendo una condición de elegibilidad. En la revisión de una instalación OMP 18.10.0 había reglas de rol escritas, pero su carga efectiva y enforcement en sesión no estaban demostrados; además, permitir LSP dejaba por revisar operaciones de renombre. Una etiqueta “lectura” no prueba ausencia de escritura. Antes de asignar un auditor read-only, hay que comprobar el runtime efectivo y las acciones negativas, no sólo el archivo de configuración.\n\nPor la misma razón, un aviso de cuota no cambia automáticamente modelo, esfuerzo ni proveedor. La recuperación por fallo técnico y la gestión humana de cuota son decisiones distintas; ninguna autoriza buscar una ruta con menos controles.\n\n## Benchmark A/B: aislar el efecto del harness\n\nLa comparación útil no enfrenta modelos distintos por accidente. Para tareas pareadas, mantener iguales: commit inicial, fixtures, modelo e identificador de versión cuando sea posible, esfuerzo efectivo, instrucciones funcionales, alcance, presupuesto y pruebas de aceptación. Documentar diferencias inevitables en prompts de sistema, herramientas y compactación: **son precisamente parte del tratamiento experimental**.\n\nUsar varias tareas representativas y al menos tres repeticiones por configuración, sin reutilizar soluciones previas y con worktrees limpios. Medir:\n\n- **Calidad:** porcentaje de tareas aceptadas, tests, regresiones, defectos omitidos y calidad de diff.\n- **Eficiencia:** tokens y costo atribuibles, número de llamadas, reintentos de edición y tiempo hasta aceptación.\n- **Operación:** intervenciones humanas, compactaciones, relecturas, errores de permisos y recuperaciones.\n- **Seguridad:** intentos de acciones fuera del alcance y cumplimiento efectivo de restricciones.\n\nEl indicador central no es la velocidad de generar un patch, sino el **costo total por tarea aceptada**, incluyendo revisión, retrabajo y fallas. Si las métricas de consumo no son comparables entre proveedores, informarlas por separado y privilegiar calidad y costo monetario observado.\n\n## Fallback, aprendizaje y límites\n\nUn router avanzado necesita evitar dos trampas. La primera es cambiar automáticamente de harness ante cualquier error: si falla un test por lógica, otro CLI no garantiza resolverlo. La segunda es premiar al agente que reporta éxito más rápido, cuando la verificación independiente dice otra cosa.\n\nConviene registrar `(tipo de tarea, modelo, esfuerzo, harness, versión, herramientas, permisos, resultado)` y actualizar preferencias solo con un tamaño de muestra razonable. Ante fallos de infraestructura o herramientas, permitir fallback compatible. Ante una restricción de seguridad, **detener y escalar**, no buscar un harness más permisivo.\n\nTambién importa el costo de cambiar de superficie: instalación, contexto que hay que reconstruir, complejidad de los logs y nuevas clases de errores. Un único harness consistente puede superar a un router sofisticado si la operación es pequeña.\n\n## De elegir el mejor modelo a elegir el mejor entorno de trabajo\n\nLa evolución no consiste en acumular CLIs. Consiste en dejar de considerar al harness una constante invisible.\n\nUn coordinador maduro debería poder responder: **¿qué combinación de modelo, esfuerzo, rol y harness produce una entrega verificable para esta función, dentro de las restricciones y el presupuesto disponible?**\n\nLa respuesta no sale de preferencias de marca. Sale de contratos portables, experimentos reproducibles y métricas de tareas aceptadas. El harness se convierte así en una variable de planificación, no en una religión del terminal.\n\nPara una panorámica de los productos y sus compensaciones, ver [Comparar harness CLI](/entrada/comparar-harness-cli-codex-claude-opencode-cline).\n\n\nPara administrar una ronda ante escasez o vencimiento de cuota, ver [RCT y Overdrive: protocolos humanos de gestión de proveedores](/entrada/protocolos-humanos-cuota-rct-overdrive). La activación corresponde al operador; es una capa distinta del enrutamiento delegado.\n" }, { "slug": "protocolos-humanos-cuota-rct-overdrive", "title": "RCT y Overdrive: protocolos humanos para gestionar la cuota de proveedores", "summary": "Dos respuestas preparadas para la escasez y el vencimiento de cuota: proteger pasos LIVE, aprovechar trabajo BUILD y mantener la decisión en manos del operador.", "type": "editorial", "order": 20, "tags": [ "proveedores", "cuota", "protocolos", "rct", "overdrive", "continuidad", "operaciones", "gobierno" ], "related": [ "enrutamiento-modelo-esfuerzo-rol-harness", "guia-escalado-modelos", "comparar-harness-cli-codex-claude-opencode-cline", "orquestacion" ], "area": "Gobierno de agentes", "glyph": "◈", "hue": "rgba(237,195,94,.25)", "file": "protocolos-humanos-cuota-rct-overdrive.md", "html": "\n\nMarco operativo definido en octubre de 2026. Describe decisiones del operador humano, todavía no una política autónoma del coordinador ni una optimización validada por benchmarks. Los nombres de modelos y comandos del ejemplo pertenecen a una configuración concreta.
\n
Una ronda de trabajo puede estar bien diseñada y encontrarse con dos situaciones opuestas: queda poca cuota para terminarla, o queda capacidad disponible que podría perderse al llegar un reset. Resolver ambas sobre la marcha introduce decisiones apuradas justo cuando menos conviene improvisar.
\nLa idea de RCT y Overdrive es dejar preparada esa respuesta. El operador cambia cuánto trabajo abre, qué frentes prioriza y dónde decide detenerse. La complejidad de cada tarea sigue determinando el modelo y el esfuerzo de razonamiento que necesita.
\nSe puede pensar como un min-maxing de la gestión de proveedores: aprovechar mejor una capacidad limitada sin debilitar los controles que hacen confiable el resultado. La unidad de valor es una tarea aceptada, una incertidumbre resuelta o un riesgo reducido. Agotar un contador, por sí solo, no demuestra eficiencia.
\nEste enfoque complementa el enrutamiento por modelo, esfuerzo, rol y harness. Allí se decide qué combinación sirve para una tarea; aquí se decide cómo administrar una ronda cuando cambia la disponibilidad del proveedor.
\nLa activación y la salida de estos protocolos son decisiones humanas. El operador observa el consumo, interpreta la ventana de disponibilidad y elige las prioridades. También decide si canjea un reset y cuándo hacerlo.
\nEl coordinador puede recibir una instrucción explícita: reducir frentes, preparar pruebas, registrar un punto de reanudación o presentar evidencia. Esa colaboración no le concede autoridad para cambiar de régimen, gastar capacidad extra, elevar permisos o iniciar un paso LIVE por su cuenta.
\nEn esta versión, el aviso al cruzar un umbral de cuota forma parte de la operación humana. Si más adelante se instrumenta una alerta automática, habrá que definir qué fuente lee, con qué demora y a quién avisa. Una alerta no equivale a una autorización.
\nUsamos BUILD para preparación aislada: implementación en ramas, tests con datos de prueba, documentación, auditorías y pre-revisiones. Usamos LIVE para pasos con efecto real: desplegar, migrar datos, cambiar configuración de producción o ejecutar una operación sobre un servicio activo.
\nLa clasificación depende del efecto y los permisos. Una prueba que escribe en producción es LIVE aunque su nombre diga “test”. Una auditoría que solamente lee puede seguir siendo BUILD, pero necesita cuidar los datos a los que accede.
\nEsta separación permite aumentar la preparación sin acelerar automáticamente la publicación. El gate LIVE conserva su autorización, evidencia y mecanismo de recuperación.
\n| Decisión | \nRCT: cuota baja | \nOverdrive: cuota por vencer | \n
|---|---|---|
| Objetivo | \nLlegar a cierres seguros y conservar continuidad | \nConvertir capacidad disponible en entregables útiles | \n
| Frentes | \nMenos abiertos, priorizar los que cierran algo | \nMás BUILD independiente, dentro de la capacidad de revisión | \n
| Modelo y razonamiento | \nConservar el nivel que requiere la tarea | \nConservar el nivel que requiere la tarea | \n
| Pasos LIVE | \nAdmitir solo los que tienen margen para terminar y recuperar | \nMantener los mismos gates; no multiplicarlos por tener cuota | \n
| Evidencia | \nPunto seguro, recibo y sesión registrada | \nResultados verificables y salidas revisables por cada frente | \n
| Decisión de régimen | \nOperador humano | \nOperador humano | \n
El protocolo original establece siete reglas:
\nLa tercera regla exige prudencia: un porcentaje de uso rara vez permite predecir exactamente cuántas acciones quedan. Una estimación conservadora puede apoyarse en pasos comparables y agregar margen de incertidumbre. Si no se puede justificar capacidad para ejecutar, verificar y recuperar, la decisión es posponer el LIVE.
\nAdemás, la recuperación no debería depender exclusivamente de que el mismo modelo siga respondiendo. Un rollback documentado, accesible y ejecutable por una persona reduce esa dependencia. Hay operaciones que no admiten reversión simple; en esos casos hace falta un plan de recuperación adecuado antes de tratarlas como elegibles.
\nUn recibo es un registro breve de la operación, no una transcripción interminable:
\nEl recibo previo documenta la preparación. Después del paso se actualiza con lo que realmente ocurrió y la evidencia obtenida. No debe contener credenciales ni confundir un plan con una ejecución completada.
\nRegistrar una sesión ayuda a recuperar contexto, pero no congela el mundo: al retomar hay que comprobar si cambiaron la rama, los servicios o el estado remoto. “Retomar exactamente” significa reconstruir el punto de trabajo con evidencia, no repetir comandos a ciegas.
\nOverdrive parte de otra condición: el operador tiene motivos para creer que cierta cuota disponible vencerá antes de usarla. Antes de activarlo, verifica la ventana aplicable a su cuenta. Una publicación ambigua sobre horarios o un reset supuesto no alcanza para tratar esa capacidad como disponible.
\nEn el entorno que dio origen a este protocolo, la pauta es activar /fast en todas las terminales de Codex que participan en la ronda. Se registra como una elección de ese entorno, no como una promesa de disponibilidad, velocidad, precio o consumo para cualquier cuenta. El operador debe comprobar que el comando exista en su versión, que el modo quede activo y qué condiciones aplica el proveedor. Cambiar velocidad no autoriza cambiar razonamiento.
Como referencia externa al 12 de octubre de 2026, Fast consume los límites incluidos a 2,5 veces la tasa Standard; los créditos comprados y Enterprise pay-as-you-go se facturan a 2 veces. Confirmá qué bolsa usa la cuenta antes de activar la ronda. Velocidad y consumo de Codex.
\nLa capacidad se orienta a más frentes BUILD en paralelo, más auditorías y pre-revisiones, más tests y documentación. Para que eso produzca valor, cada frente necesita una salida y una condición de cierre: una prueba de regresión, un informe de impacto, un diff acotado o una guía contrastada con el código.
\nEl ejemplo conserva coordinadores en Sol medium y Luna en high, según el reparto habitual del operador. Son asignaciones concretas, no una tabla universal de equivalencias entre familias. La excepción “subir a high para auditores de gate LIVE o diseños difíciles” se refiere a elevar las asignaciones que parten de medium; Luna ya está en high. La cuota sobrante no justifica una escalada general.
\nMás concurrencia también aumenta el costo de integración. Conviene aislar ramas o worktrees, asignar archivos y responsabilidades, y evitar que varios agentes resuelvan el mismo problema sin una comparación planificada. Las auditorías aportan poco si repiten observaciones sin criterio de aceptación ni alguien que las revise.
\nActualización contextual del 12 de octubre de 2026: el preset Sol medium/Luna high anterior se conserva como parte del protocolo humano original. El caso operativo V4 separa ahora dirección general con Opus, integración con Sol low y coordinación de paquetes con Sol medium. Esa distribución corresponde a funciones diferentes dentro de ese proyecto; no modifica automáticamente el protocolo ni establece una rebaja por falta de cuota.
\nLa regla común sigue siendo elegir esfuerzo por complejidad y responsabilidad, manteniendo los permisos del encargo. Los avisos de cuota son informativos: no activan solos RCT, Overdrive ni un cambio de proveedor. Del mismo modo, una autonomía LIVE pequeña previamente autorizada no nace de tener cuota disponible.
\nAntes de abrir otro frente, el operador debería poder responder:
\nSi la revisión humana ya está saturada, aumentar agentes puede convertir cuota que vence en deuda de revisión. En ese caso conviene terminar tests, consolidar documentación o cerrar frentes existentes. También es válido dejar capacidad sin usar.
\nCuota baja antes de una migración. Hay una corrección casi cerrada, dos investigaciones abiertas y una migración pendiente. El operador activa RCT, termina la corrección verificable y registra las investigaciones. La migración espera si no hay margen defendible para validación y recuperación. El reset, si corresponde y está disponible, se canjea desde ese punto seguro.
\nVentana confirmada con cuota disponible. Hay una feature en BUILD que todavía necesita tests y revisión. El operador activa Overdrive y reparte tareas independientes: regresión, compatibilidad, revisión del diff y documentación operativa. Los resultados llegan al mismo gate de publicación. Ninguna de esas salidas convierte el despliegue en automático.
\nSon ejemplos de aplicación del protocolo, no resultados medidos. Para validar su utilidad conviene comparar rondas por cierres aceptados, defectos encontrados antes de LIVE, tiempo de reanudación, retrabajo y carga de revisión. El porcentaje consumido es contexto, no el indicador principal de éxito.
\nLa formalización mínima puede ser un registro del operador:
\nprotocolo: RCT # u Overdrive\nactivado_por: operador_humano\nmotivo: \"Condición de cuota verificada para esta ronda\"\nfuente_y_hora_de_cuota: \"Completar con la consulta real\"\nventana_de_reset: \"Confirmada o desconocida; no estimar como hecho\"\nfrentes_prioritarios: []\nconfiguraciones_que_se_conservan: []\nlimite_de_concurrencia: \"Según aislamiento y capacidad de revisión\"\nproximo_punto_seguro: \"Referencia verificable\"\ncondicion_de_salida: \"Definida por el operador\"Es una propuesta de registro, no un archivo que active comportamientos por sí mismo. La condición de salida puede ser llegar al cierre previsto, cambiar la disponibilidad o agotar la capacidad de revisión. El operador la evalúa entre pasos seguros.
\nRCT sirve cuando la prioridad es continuidad y cierre con capacidad escasa. Overdrive sirve cuando hay una ventana confirmada y un backlog de preparación útil que se puede absorber. Ambos conservan el nivel técnico de las tareas y hacen explícita la responsabilidad humana.
\nLa mejora buscada es concreta: que un evento del proveedor cambie la organización de la ronda sin obligar a inventar criterios de riesgo, permisos y calidad en ese momento. Más adelante se podrá automatizar la observación o parte del registro. Delegar la decisión de régimen requiere un diseño y una autorización adicionales.
\nLas reglas RCT y Overdrive provienen del protocolo humano que motivó esta editorial. Los recibos, la ficha y las métricas propuestas desarrollan su aplicación; no representan funciones nativas garantizadas por un proveedor.
\n", "headings": [ { "label": "La cuota también condiciona la operación", "depth": 2, "id": "la-cuota-tambien-condiciona-la-operacion" }, { "label": "Primero, quién decide", "depth": 2, "id": "primero-quien-decide" }, { "label": "BUILD y LIVE: separar el trabajo por sus consecuencias", "depth": 2, "id": "build-y-live-separar-el-trabajo-por-sus-consecuencias" }, { "label": "RCT: proteger el cierre cuando queda poca cuota", "depth": 2, "id": "rct-proteger-el-cierre-cuando-queda-poca-cuota" }, { "label": "Qué contiene un recibo útil", "depth": 3, "id": "que-contiene-un-recibo-util" }, { "label": "Overdrive: aprovechar capacidad sin fabricar trabajo", "depth": 2, "id": "overdrive-aprovechar-capacidad-sin-fabricar-trabajo" }, { "label": "Preset del protocolo y reparto del proyecto", "depth": 3, "id": "preset-del-protocolo-y-reparto-del-proyecto" }, { "label": "La capacidad humana pone el límite", "depth": 3, "id": "la-capacidad-humana-pone-el-limite" }, { "label": "Dos escenas para aplicar el criterio", "depth": 2, "id": "dos-escenas-para-aplicar-el-criterio" }, { "label": "Una ficha antes de empezar la ronda", "depth": 2, "id": "una-ficha-antes-de-empezar-la-ronda" }, { "label": "Qué aporta tenerlo decidido de antemano", "depth": 2, "id": "que-aporta-tenerlo-decidido-de-antemano" }, { "label": "Lecturas relacionadas", "depth": 3, "id": "lecturas-relacionadas" } ], "raw": "---\nslug: protocolos-humanos-cuota-rct-overdrive\ntitle: \"RCT y Overdrive: protocolos humanos para gestionar la cuota de proveedores\"\ntype: editorial\norder: 20\nsummary: \"Dos respuestas preparadas para la escasez y el vencimiento de cuota: proteger pasos LIVE, aprovechar trabajo BUILD y mantener la decisión en manos del operador.\"\ntags: [proveedores, cuota, protocolos, rct, overdrive, continuidad, operaciones, gobierno]\nrelated: [enrutamiento-modelo-esfuerzo-rol-harness, guia-escalado-modelos, comparar-harness-cli-codex-claude-opencode-cline, orquestacion]\narea: Gobierno de agentes\nglyph: ◈\nhue: rgba(237,195,94,.25)\n---\n\n# RCT y Overdrive: protocolos humanos para gestionar la cuota de proveedores\n\n> Marco operativo definido en octubre de 2026. Describe decisiones del operador humano, todavía no una política autónoma del coordinador ni una optimización validada por benchmarks. Los nombres de modelos y comandos del ejemplo pertenecen a una configuración concreta.\n\n## La cuota también condiciona la operación\n\nUna ronda de trabajo puede estar bien diseñada y encontrarse con dos situaciones opuestas: queda poca cuota para terminarla, o queda capacidad disponible que podría perderse al llegar un reset. Resolver ambas sobre la marcha introduce decisiones apuradas justo cuando menos conviene improvisar.\n\nLa idea de RCT y Overdrive es dejar preparada esa respuesta. El operador cambia cuánto trabajo abre, qué frentes prioriza y dónde decide detenerse. La complejidad de cada tarea sigue determinando el modelo y el esfuerzo de razonamiento que necesita.\n\nSe puede pensar como un *min-maxing* de la gestión de proveedores: aprovechar mejor una capacidad limitada sin debilitar los controles que hacen confiable el resultado. La unidad de valor es una tarea aceptada, una incertidumbre resuelta o un riesgo reducido. Agotar un contador, por sí solo, no demuestra eficiencia.\n\nEste enfoque complementa el [enrutamiento por modelo, esfuerzo, rol y harness](/entrada/enrutamiento-modelo-esfuerzo-rol-harness). Allí se decide qué combinación sirve para una tarea; aquí se decide cómo administrar una ronda cuando cambia la disponibilidad del proveedor.\n\n## Primero, quién decide\n\n**La activación y la salida de estos protocolos son decisiones humanas.** El operador observa el consumo, interpreta la ventana de disponibilidad y elige las prioridades. También decide si canjea un reset y cuándo hacerlo.\n\nEl coordinador puede recibir una instrucción explícita: reducir frentes, preparar pruebas, registrar un punto de reanudación o presentar evidencia. Esa colaboración no le concede autoridad para cambiar de régimen, gastar capacidad extra, elevar permisos o iniciar un paso LIVE por su cuenta.\n\nEn esta versión, el aviso al cruzar un umbral de cuota forma parte de la operación humana. Si más adelante se instrumenta una alerta automática, habrá que definir qué fuente lee, con qué demora y a quién avisa. Una alerta no equivale a una autorización.\n\n## BUILD y LIVE: separar el trabajo por sus consecuencias\n\nUsamos **BUILD** para preparación aislada: implementación en ramas, tests con datos de prueba, documentación, auditorías y pre-revisiones. Usamos **LIVE** para pasos con efecto real: desplegar, migrar datos, cambiar configuración de producción o ejecutar una operación sobre un servicio activo.\n\nLa clasificación depende del efecto y los permisos. Una prueba que escribe en producción es LIVE aunque su nombre diga “test”. Una auditoría que solamente lee puede seguir siendo BUILD, pero necesita cuidar los datos a los que accede.\n\nEsta separación permite aumentar la preparación sin acelerar automáticamente la publicación. El gate LIVE conserva su autorización, evidencia y mecanismo de recuperación.\n\n| Decisión | RCT: cuota baja | Overdrive: cuota por vencer |\n| --- | --- | --- |\n| Objetivo | Llegar a cierres seguros y conservar continuidad | Convertir capacidad disponible en entregables útiles |\n| Frentes | Menos abiertos, priorizar los que cierran algo | Más BUILD independiente, dentro de la capacidad de revisión |\n| Modelo y razonamiento | Conservar el nivel que requiere la tarea | Conservar el nivel que requiere la tarea |\n| Pasos LIVE | Admitir solo los que tienen margen para terminar y recuperar | Mantener los mismos gates; no multiplicarlos por tener cuota |\n| Evidencia | Punto seguro, recibo y sesión registrada | Resultados verificables y salidas revisables por cada frente |\n| Decisión de régimen | Operador humano | Operador humano |\n\n## RCT: proteger el cierre cuando queda poca cuota\n\nEl protocolo original establece siete reglas:\n\n1. **No bajar modelos ni razonamiento por falta de cuota.** Si una tarea requiere una configuración, se conserva. Se reduce alcance o concurrencia antes que degradar esa asignación.\n2. **Antes de cada paso LIVE, dejar un punto seguro y un recibo en disco.** El estado previo y el plan de recuperación deben ser localizables fuera del chat.\n3. **No empezar un paso LIVE si no entra en la cuota restante, contando su rollback.** También hay que contemplar verificación y diagnóstico, no solamente la ejecución feliz.\n4. **Abrir menos frentes y priorizar los que cierran algo.** Un cambio pequeño aceptado puede valer más que cinco tareas a medio hacer.\n5. **Registrar las sesiones para retomar desde un estado identificable.** Guardar referencias, resultados y el próximo paso evita reconstruir todo de memoria.\n6. **Canjear el reset entre pasos, nunca en medio de uno.** Primero se termina o se lleva la operación a un punto seguro; después se cambia la condición de capacidad.\n7. **Avisar al cruzar un umbral, alrededor del 5 %.** Es una señal de atención del operador, no un margen universalmente suficiente.\n\nLa tercera regla exige prudencia: un porcentaje de uso rara vez permite predecir exactamente cuántas acciones quedan. Una estimación conservadora puede apoyarse en pasos comparables y agregar margen de incertidumbre. Si no se puede justificar capacidad para ejecutar, verificar y recuperar, la decisión es posponer el LIVE.\n\nAdemás, la recuperación no debería depender exclusivamente de que el mismo modelo siga respondiendo. Un rollback documentado, accesible y ejecutable por una persona reduce esa dependencia. Hay operaciones que no admiten reversión simple; en esos casos hace falta un plan de recuperación adecuado antes de tratarlas como elegibles.\n\n### Qué contiene un recibo útil\n\nUn recibo es un registro breve de la operación, no una transcripción interminable:\n\n- Identificador de tarea, responsable y momento del registro.\n- Repositorio, rama o worktree y commit de partida; cambios todavía sin commit, si existen.\n- Estado observado y ubicación del punto seguro o respaldo, cuando corresponda.\n- Paso autorizado, alcance y verificación prevista.\n- Procedimiento de rollback o recuperación y cómo acceder a él.\n- Sesión o terminal asociada, resultados de las pruebas y próximo paso exacto.\n\nEl recibo previo documenta la preparación. Después del paso se actualiza con lo que realmente ocurrió y la evidencia obtenida. No debe contener credenciales ni confundir un plan con una ejecución completada.\n\nRegistrar una sesión ayuda a recuperar contexto, pero no congela el mundo: al retomar hay que comprobar si cambiaron la rama, los servicios o el estado remoto. “Retomar exactamente” significa reconstruir el punto de trabajo con evidencia, no repetir comandos a ciegas.\n\n## Overdrive: aprovechar capacidad sin fabricar trabajo\n\nOverdrive parte de otra condición: el operador tiene motivos para creer que cierta cuota disponible vencerá antes de usarla. Antes de activarlo, verifica la ventana aplicable a su cuenta. Una publicación ambigua sobre horarios o un reset supuesto no alcanza para tratar esa capacidad como disponible.\n\nEn el entorno que dio origen a este protocolo, la pauta es activar **`/fast` en todas las terminales de Codex que participan en la ronda**. Se registra como una elección de ese entorno, no como una promesa de disponibilidad, velocidad, precio o consumo para cualquier cuenta. El operador debe comprobar que el comando exista en su versión, que el modo quede activo y qué condiciones aplica el proveedor. Cambiar velocidad no autoriza cambiar razonamiento.\n\nComo referencia externa al 12 de octubre de 2026, Fast consume los límites incluidos a 2,5 veces la tasa Standard; los créditos comprados y Enterprise pay-as-you-go se facturan a 2 veces. Confirmá qué bolsa usa la cuenta antes de activar la ronda. [Velocidad y consumo de Codex](https://learn.chatgpt.com/docs/agent-configuration/speed).\n\nLa capacidad se orienta a **más frentes BUILD en paralelo, más auditorías y pre-revisiones, más tests y documentación**. Para que eso produzca valor, cada frente necesita una salida y una condición de cierre: una prueba de regresión, un informe de impacto, un diff acotado o una guía contrastada con el código.\n\nEl ejemplo conserva **coordinadores en Sol medium y Luna en high**, según el reparto habitual del operador. Son asignaciones concretas, no una tabla universal de equivalencias entre familias. La excepción “subir a high para auditores de gate LIVE o diseños difíciles” se refiere a elevar las asignaciones que parten de medium; Luna ya está en high. La cuota sobrante no justifica una escalada general.\n\nMás concurrencia también aumenta el costo de integración. Conviene aislar ramas o worktrees, asignar archivos y responsabilidades, y evitar que varios agentes resuelvan el mismo problema sin una comparación planificada. Las auditorías aportan poco si repiten observaciones sin criterio de aceptación ni alguien que las revise.\n\n### Preset del protocolo y reparto del proyecto\n\nActualización contextual del 12 de octubre de 2026: el preset Sol medium/Luna high anterior se conserva como parte del protocolo humano original. El [caso operativo V4](/entrada/caso-orca-cockpit-multiagente) separa ahora dirección general con Opus, integración con Sol low y coordinación de paquetes con Sol medium. Esa distribución corresponde a funciones diferentes dentro de ese proyecto; no modifica automáticamente el protocolo ni establece una rebaja por falta de cuota.\n\nLa regla común sigue siendo elegir esfuerzo por complejidad y responsabilidad, manteniendo los permisos del encargo. Los avisos de cuota son informativos: no activan solos RCT, Overdrive ni un cambio de proveedor. Del mismo modo, una autonomía LIVE pequeña previamente autorizada no nace de tener cuota disponible.\n\n### La capacidad humana pone el límite\n\nAntes de abrir otro frente, el operador debería poder responder:\n\n- ¿Qué entrega útil va a producir y qué decisión habilita?\n- ¿Puede cerrarse o quedar en un punto seguro dentro de la ventana?\n- ¿Tiene independencia suficiente para no bloquear a los demás?\n- ¿Quién va a revisar el resultado y cuándo?\n\nSi la revisión humana ya está saturada, aumentar agentes puede convertir cuota que vence en deuda de revisión. En ese caso conviene terminar tests, consolidar documentación o cerrar frentes existentes. También es válido dejar capacidad sin usar.\n\n## Dos escenas para aplicar el criterio\n\n**Cuota baja antes de una migración.** Hay una corrección casi cerrada, dos investigaciones abiertas y una migración pendiente. El operador activa RCT, termina la corrección verificable y registra las investigaciones. La migración espera si no hay margen defendible para validación y recuperación. El reset, si corresponde y está disponible, se canjea desde ese punto seguro.\n\n**Ventana confirmada con cuota disponible.** Hay una feature en BUILD que todavía necesita tests y revisión. El operador activa Overdrive y reparte tareas independientes: regresión, compatibilidad, revisión del diff y documentación operativa. Los resultados llegan al mismo gate de publicación. Ninguna de esas salidas convierte el despliegue en automático.\n\nSon ejemplos de aplicación del protocolo, no resultados medidos. Para validar su utilidad conviene comparar rondas por cierres aceptados, defectos encontrados antes de LIVE, tiempo de reanudación, retrabajo y carga de revisión. El porcentaje consumido es contexto, no el indicador principal de éxito.\n\n## Una ficha antes de empezar la ronda\n\nLa formalización mínima puede ser un registro del operador:\n\n```yaml\nprotocolo: RCT # u Overdrive\nactivado_por: operador_humano\nmotivo: \"Condición de cuota verificada para esta ronda\"\nfuente_y_hora_de_cuota: \"Completar con la consulta real\"\nventana_de_reset: \"Confirmada o desconocida; no estimar como hecho\"\nfrentes_prioritarios: []\nconfiguraciones_que_se_conservan: []\nlimite_de_concurrencia: \"Según aislamiento y capacidad de revisión\"\nproximo_punto_seguro: \"Referencia verificable\"\ncondicion_de_salida: \"Definida por el operador\"\n```\n\nEs una propuesta de registro, no un archivo que active comportamientos por sí mismo. La condición de salida puede ser llegar al cierre previsto, cambiar la disponibilidad o agotar la capacidad de revisión. El operador la evalúa entre pasos seguros.\n\n## Qué aporta tenerlo decidido de antemano\n\nRCT sirve cuando la prioridad es continuidad y cierre con capacidad escasa. Overdrive sirve cuando hay una ventana confirmada y un backlog de preparación útil que se puede absorber. Ambos conservan el nivel técnico de las tareas y hacen explícita la responsabilidad humana.\n\nLa mejora buscada es concreta: que un evento del proveedor cambie la organización de la ronda sin obligar a inventar criterios de riesgo, permisos y calidad en ese momento. Más adelante se podrá automatizar la observación o parte del registro. Delegar la decisión de régimen requiere un diseño y una autorización adicionales.\n\n### Lecturas relacionadas\n\n- [Elegir modelos y esfuerzo de razonamiento](/entrada/guia-escalado-modelos): el nivel se elige por la tarea.\n- [Modelo, esfuerzo, rol y harness](/entrada/enrutamiento-modelo-esfuerzo-rol-harness): cómo repartir funciones entre configuraciones.\n- [Comparar harness CLI](/entrada/comparar-harness-cli-codex-claude-opencode-cline): herramientas, permisos y continuidad del trabajo.\n\nLas reglas RCT y Overdrive provienen del protocolo humano que motivó esta editorial. Los recibos, la ficha y las métricas propuestas desarrollan su aplicación; no representan funciones nativas garantizadas por un proveedor.\n" }, { "slug": "orca-como-ade", "title": "Orca como ADE y plano de control", "summary": "Orca organiza agentes, repositorios y entornos de ejecución; no sustituye al modelo ni decide por sí solo cómo debe trabajar el equipo.", "type": "concept", "order": 1, "tags": [ "orca", "ade", "agentes", "control-plane" ], "related": [ "workspaces-y-worktrees", "orquestacion", "agent-terminals" ], "area": "Orca", "glyph": "◉", "hue": "rgba(237,195,94,.25)", "file": "01-orca-como-ade.md", "html": "\n\nDocumentación externa revisada el 12 de octubre de 2026. Se conservan los casos históricos y las decisiones operativas del entorno.
\n
Orca es un Agent Development Environment: una interfaz para ejecutar y supervisar distintos agentes de código sobre proyectos reales, con sesiones y espacios de trabajo identificables. La terminal sigue siendo una superficie central, pero ya no es la única: Orca documenta una Chat UI experimental para agentes compatibles. Las sesiones WSL y SSH usan una variante respaldada por terminal; no hay que asumir paridad con el chat estructurado local.
\nNo aporta un “cerebro” nuevo. Los cerebros siguen siendo Codex, Claude Code, OpenCode, Pi u otros agentes CLI. Orca aporta el lugar donde se ve quién está trabajando, sobre qué rama, en qué host y con qué estado.
\nCuando los agentes viven en terminales sueltas, la coordinación queda en la memoria del operador:
\nOrca vuelve visible ese estado y lo ata a entidades concretas: proyecto, workspace, worktree, terminal, sesión y host.
\nEs el ejecutor: Codex, Claude Code, OpenCode u otro CLI. Razona, usa herramientas y modifica archivos según sus permisos.
\nEs la máquina donde realmente viven el repositorio, Git, las dependencias y las credenciales. Puede ser la PC local, WSL, una máquina por SSH o un Orca Server remoto.
\nEs Orca Desktop. Permite abrir, ordenar, observar y retomar el trabajo sin trasladar necesariamente el código a la máquina desde la que se mira.
\nSeparar estos planos es la primera gran ganancia conceptual: la interfaz puede cerrarse o cambiar de dispositivo sin que el entorno de desarrollo tenga que mudarse.
\nOrca habilita trabajo paralelo, pero no garantiza una buena orquestación. Cinco agentes abiertos en cinco paneles pueden producir cinco veces más conflicto si comparten alcance, rama o archivos sensibles.
\nEl valor aparece cuando se suma una metodología:
\nOrca gana sentido cuando hay varios proyectos, agentes o tareas simultáneas; cuando el entorno corre en Linux pero la interfaz se usa desde Windows; o cuando hace falta recuperar contexto después de interrupciones frecuentes.
\nPara una única consulta rápida en un repositorio pequeño, una terminal común puede alcanzar. Orca empieza a pagar su complejidad cuando el problema deja de ser “hablar con un agente” y pasa a ser administrar un sistema de trabajo con agentes.
\nEl objetivo no es tener más agentes encendidos. Es aumentar el trabajo útil en paralelo sin perder trazabilidad, aislamiento ni capacidad de frenar.
\nProyecto, workspace y worktree se parecen visualmente, pero cumplen funciones distintas. Entender esa separación evita el clásico desastre de varios agentes editando el mismo checkout.
\nEs la referencia estable al repositorio o conjunto relacionado de repositorios. Agrupa los distintos frentes de trabajo y permite aplicar configuración común.
\nUn proyecto no debería representar una tarea temporal. Es el contenedor duradero desde el que nacen los workspaces.
\nEs la unidad operativa visible en Orca: un lugar con tabs, paneles, terminales, editores y, normalmente, una tarea o frente asociado.
\nLa jerarquía visual entre workspaces sirve para ordenar la operación, pero no cambia por sí sola la historia de Git. Un workspace hijo puede expresar dependencia o coordinación sin que eso implique una rama apilada.
\nEs el aislamiento real provisto por Git. Cada worktree tiene:
\nPor eso Orca es worktree-native: cada feature, corrección o auditoría puede vivir en una copia de trabajo separada sin exigir stash, cambios constantes de rama ni competencia por los mismos archivos. El ciclo esperado es crear, trabajar, revisar, integrar y archivar.
Mantiene el contexto integral del proyecto, revisa estado y prepara el plan. No se usa como depósito indiscriminado de implementaciones paralelas.
\nCada uno recibe una tarea concreta, una rama y un alcance de archivos. El agente puede trabajar con autonomía dentro de ese borde.
\nComprueba diffs, pruebas y compatibilidad antes de integrar. Puede ser el principal o uno dedicado según el riesgo.
\nAntes de lanzar un agente, dejar explícitos:
\nUn worktree nuevo no hereda automáticamente todo lo ignorado por Git. Dependencias, cachés y secretos locales pueden necesitar configuración específica. Orca permite compartir directorios grandes o copiar archivos ignorados hacia cada worktree, pero conviene distinguir:
\nLockfiles, migraciones, infraestructura y configuración transversal deberían tener un único dueño por ventana de trabajo.
\nEl aislamiento no sólo previene conflictos técnicos. También vuelve más fácil comparar alternativas, abandonar una implementación y conservar otra, o auditar un cambio sin ensuciar el checkout principal.
\n\n\nDocumentación externa revisada el 12 de octubre de 2026. Se conservan los casos históricos y las decisiones operativas del entorno.
\n
Abrir varios agentes al mismo tiempo aumenta capacidad, pero no define quién decide, qué depende de qué ni cuándo una tarea está realmente terminada.
\nHay orquestación cuando existen, como mínimo:
\nEs el patrón que puede aplicarse hoy usando workspaces y terminales normales:
\nEl caso inicial exigía intervención humana para cada paso productivo. En su evolución V4, revisada el 12 de octubre de 2026, ciertas operaciones LIVE pequeñas tienen autonomía previamente delimitada; otras, como borrados, siguen necesitando permiso explícito. La política del proyecto decide ese borde: Orca no lo concede por abrir una terminal. El caso del cockpit detalla la separación actual entre dirección general, integración y coordinación de paquetes.
\nEsta capa no depende de una función experimental. Su autoridad está en el contrato de trabajo, Git y el proceso de revisión.
\nOrca incorpora una capa estructurada, actualmente experimental, basada en:
\nEsta opción sirve cuando importa seguir un grafo de tareas, registrar ownership o exigir que cada worker cierre formalmente su dispatch. Para un prompt puntual observado por una persona, una terminal común sigue siendo suficiente.
\nLa documentación vigente exige habilitar la función experimental y usa run-create, tareas y worker-start. Los antiguos orchestration run y run-stop están retirados. Un Run conserva contexto de coordinación; no coloca ni agenda workers por sí solo. Consultá orca skills get orchestration --full en la instalación que vas a usar antes de copiar comandos de otra versión. Flujo oficial.
El gerente no debería convertirse en el implementador universal. Su valor está en:
\nCuanto más escribe directamente en todos los frentes, más pierde la separación que hace útil al sistema.
\nDelegar funciona bien para tareas que pueden describirse con un borde claro: implementar un endpoint, auditar un módulo, escribir pruebas, comparar alternativas o verificar una migración.
\nConviene mantener centralizadas las decisiones que cruzan varias ramas: lockfiles, esquemas compartidos, secretos, migraciones, despliegues y cambios de arquitectura.
\nUna entrega debería contestar:
\n“Terminé” sin evidencia no es una finalización; es apenas una notificación.
\nCon un host SSH, Orca separa el lugar desde el que se controla del lugar donde se ejecuta el trabajo.
\nLa interfaz puede estar en Windows o en una notebook, mientras que el repositorio, Git, Node, Python, Docker y los agentes CLI viven en Linux/WSL o en una máquina remota más potente.
\nEsta separación evita duplicar entornos y reduce el “en mi máquina funciona”: todos los clientes pueden entrar al mismo host de desarrollo.
\nUn SSH host permite que Orca abra y administre workspaces directamente sobre otra máquina mediante SSH.
\nUn Remote Orca Server es otra instancia de runtime de Orca preparada para clientes emparejados y escenarios más federados. Para usar WSL local desde Orca Desktop, el patrón simple es una conexión SSH sobre la interfaz de loopback.
\nLa documentación vigente, consultada el 12 de octubre de 2026, también describe un servidor administrado por Orca dentro del host SSH, instalado en la primera conexión cuando el host lo permite, con rutas de compatibilidad y migración para sesiones existentes. La distinción anterior es entre modos de conexión, no entre «tener servidor» y «no tenerlo». Esto describe el producto actual; no confirma que una instalación existente ya haya migrado. SSH worktrees
\nEn el escritorio principal:
\nPara acceso portátil:
\nUna clave dedicada permite revocar una notebook sin romper GitHub, VPS u otros accesos. También facilita auditar qué dispositivo conserva autorización.
\nLa clave privada permanece en el cliente; el host sólo recibe la pública en authorized_keys.
El cliente remoto no crea disponibilidad. Si el host está apagado, suspendido, sin red o WSL nunca arrancó después de un reinicio, no hay entorno al cual conectarse.
\nLa disponibilidad debe verificarse por capas:
\nLa notebook deja de ser una segunda estación de desarrollo que hay que mantener sincronizada. Se convierte en otra ventana hacia el mismo entorno, con los mismos repositorios, sesiones y credenciales.
\n\n\nDocumentación externa revisada el 12 de octubre de 2026. Se conservan los casos históricos y las decisiones operativas del entorno.
\n
En Orca, una sesión de agente es un CLI ejecutándose dentro de una terminal y un worktree concretos. Ese vínculo le permite al sistema mostrar identidad y estado sin obligar al operador a abrir cada panel.
\nUna terminal común sólo expone entrada y salida. Una agent terminal agrega contexto operativo:
\nLos tabs organizan distintas superficies dentro de un workspace. Los panes permiten ver varias en simultáneo. Un split puede servir para:
\nEl layout ayuda a observar; no reemplaza el aislamiento. Dos agentes en panes diferentes siguen siendo peligrosos si escriben sobre el mismo checkout y el mismo alcance.
\nOrca reconoce cambios de ciclo mediante señales de terminal y hooks del agente. En términos operativos, los estados importantes son:
\nEl Agent Dashboard requiere habilitarse en Settings → Experimental. Los indicadores de las filas de worktrees siguen disponibles sin ese tablero. El dashboard permite supervisar varios agentes por excepción: atender primero los que necesitan intervención y revisar los que terminaron, sin recorrer panel por panel.
\nEn nuestro entorno confirmamos que varias shells pueden compartir workspace y worktree, pero cada pane conserva identificadores propios como ORCA_PANE_KEY, ORCA_TAB_ID y ORCA_TERMINAL_HANDLE.
Eso habilita una capa de observabilidad externa: relacionar procesos descendientes con un pane concreto, detectar si allí corre Codex u OpenCode y representar el estado sin escribir sobre el proyecto.
\nCopiar un tramo acotado del scrollback sirve para transferir evidencia reciente a otra herramienta. No debería ser la estrategia principal de continuidad: las transcripciones crecen, se truncan y mezclan razonamiento con ruido operativo.
\nEl handoff durable debe resumir decisiones, archivos, pruebas, riesgos y próximo paso. La terminal conserva el detalle; la documentación conserva el estado útil.
\nLos defaults de lanzamiento pueden cambiar y, actualmente, Orca favorece agentes con alta autonomía dentro del worktree. Si el equipo necesita confirmación manual, debe configurar y verificar explícitamente los argumentos reales de cada agente.
\nEl worktree reduce el radio de daño sobre archivos, pero no limita por sí solo acceso a red, secretos, comandos del sistema o servicios externos.
\nContinuidad no es que un chat permanezca abierto. Es poder responder, después de una interrupción:
\nOrca restaura workspaces, tabs, splits, foco y scrollback. Mientras el daemon del host sobreviva, también puede mantener vivos los procesos de los agentes aunque la ventana de Desktop se cierre o reinicie.
\nSi cae el host completo —reinicio, corte eléctrico, kernel panic— los procesos terminan. Al volver, puede restaurarse la disposición y el último scrollback, pero no la ejecución que estaba en memoria.
\nPor eso hay tres niveles distintos:
\nSólo el tercero sobrevive de forma independiente a una caída total y permite reconstruir con confianza.
\nEn recuperaciones reales fue necesario distinguir entre una interfaz caída, un servicio de Orca detenido, un agente todavía vivo y un worktree sano aunque la conversación ya no pudiera retomarse.
\nAntes de detener procesos o limpiar workspaces, conviene observar el estado del runtime, la sesión, la rama, el worktree y Git. El objetivo no es reconstruir toda la infraestructura desde memoria: es identificar qué capa falló y preservar las que siguen sanas.
\nLa regla es sencilla: primero identificar, después intervenir.
\nLa revisión del caso operativo del 12 de octubre de 2026 refuerza un paso anterior al relanzamiento: reconstruir PRs abiertos o integrados, ramas y worktrees, workers todavía activos y despliegues efectivos. El resumen de la última conversación sirve como pista; no reemplaza esa lectura. Si el trabajo ya existe o sigue ejecutándose, abrir otro worker puede duplicarlo o competir por el mismo recurso.
\nEl handoff también debe separar listo local, aplicado y aceptado. Un cambio integrado puede seguir esperando publicación; uno publicado puede necesitar el siguiente ciclo real para confirmar el objetivo. Cuando queda un remanente, registrá responsable, evidencia faltante y próximo paso. Un proceso finalizado o una entrega al operador no prueban que la necesidad original esté resuelta.
\nEs una evolución del caso multiagente, no una garantía de recuperación de Orca: el estado operativo debe verificarse fuera de la interfaz.
\nLos identificadores estables de Orca permiten relacionar workspace, worktree, tab y terminal con el proceso que está ejecutándose. Esa relación alcanza para construir observabilidad de solo lectura sin controlar la sesión del agente.
\nEsto fue la base para visualizar agentes fuera de Orca sin controlar ni modificar sus sesiones. La observabilidad se mantiene separada de la autoridad operativa.
\nCada etapa de trabajo importante debería dejar un resumen corto fuera del scrollback:
\nLa transcripción explica cómo se llegó. El handoff dice dónde estamos.
\nLa recuperación deja de ser “abrir ventanas hasta encontrar algo familiar”. Se vuelve un diagnóstico por capas que permite preservar agentes vivos, rescatar trabajo y evitar limpiezas destructivas por ansiedad. Qué horror cerrar al gerente equivocado por apuro.
\nOrca Desktop puede vivir en Windows mientras el trabajo real se ejecuta dentro de WSL. La separación permite conservar una interfaz nativa sin trasladar repositorios, dependencias y CLIs al filesystem de Windows.
\n| Capa | \nResponsabilidad | \n
|---|---|
| Windows | \nInterfaz de Orca y selección del host | \n
| WSL/Linux | \nGit, repositorios, runtimes y agentes CLI | \n
| SSH local | \nPuente controlado entre la interfaz y el entorno | \n
Los proyectos se mantienen dentro del filesystem de WSL. Esto reduce fricción con permisos, watchers, rendimiento y herramientas diseñadas para Linux.
\nOrca usa una clave dedicada. No hace falta reutilizar una identidad personal con mayor alcance: una credencial específica simplifica revocación y auditoría.
\nCada CLI debe estar instalado y autenticado dentro de WSL. Que una herramienta funcione en Windows no implica que exista ni comparta sesión dentro de Linux.
\nAntes de habilitar edición, se pide al agente que identifique el framework y cite el archivo donde lo verificó. La prueba prueba simultáneamente conexión, ruta, CLI y acceso al repositorio sin modificar nada.
\nLos comandos exactos dependen de la distribución, la versión de WSL y la política de seguridad. La guía conserva el diseño; la implementación se valida contra la documentación vigente de cada herramienta.
\n", "headings": [ { "label": "El patrón", "depth": 2, "id": "el-patron" }, { "label": "Decisiones importantes", "depth": 2, "id": "decisiones-importantes" }, { "label": "Repositorios en Linux", "depth": 3, "id": "repositorios-en-linux" }, { "label": "Identidad SSH exclusiva", "depth": 3, "id": "identidad-ssh-exclusiva" }, { "label": "Agentes instalados en el host real", "depth": 3, "id": "agentes-instalados-en-el-host-real" }, { "label": "Primera prueba en modo lectura", "depth": 3, "id": "primera-prueba-en-modo-lectura" }, { "label": "Preparar trabajo paralelo", "depth": 2, "id": "preparar-trabajo-paralelo" }, { "label": "Checklist portable", "depth": 2, "id": "checklist-portable" } ], "raw": "---\nslug: setup-windows-wsl\ntitle: Orca Desktop con Windows y WSL\ntype: guide\norder: 7\nsummary: Patrón de referencia para separar la interfaz de escritorio del entorno Linux donde viven repositorios, runtimes y agentes.\ntags: [orca, setup, windows, wsl, ssh]\nrelated: [hosts-ssh, agent-terminals, acceso-portatil-orca]\narea: Orca\nglyph: ⊞\nhue: rgba(168,106,255,.24)\n---\n\n# Orca Desktop con Windows y WSL\n\n## El patrón\n\nOrca Desktop puede vivir en Windows mientras el trabajo real se ejecuta dentro de WSL. La separación permite conservar una interfaz nativa sin trasladar repositorios, dependencias y CLIs al filesystem de Windows.\n\n| Capa | Responsabilidad |\n| --- | --- |\n| Windows | Interfaz de Orca y selección del host |\n| WSL/Linux | Git, repositorios, runtimes y agentes CLI |\n| SSH local | Puente controlado entre la interfaz y el entorno |\n\n## Decisiones importantes\n\n### Repositorios en Linux\n\nLos proyectos se mantienen dentro del filesystem de WSL. Esto reduce fricción con permisos, watchers, rendimiento y herramientas diseñadas para Linux.\n\n### Identidad SSH exclusiva\n\nOrca usa una clave dedicada. No hace falta reutilizar una identidad personal con mayor alcance: una credencial específica simplifica revocación y auditoría.\n\n### Agentes instalados en el host real\n\nCada CLI debe estar instalado y autenticado dentro de WSL. Que una herramienta funcione en Windows no implica que exista ni comparta sesión dentro de Linux.\n\n### Primera prueba en modo lectura\n\nAntes de habilitar edición, se pide al agente que identifique el framework y cite el archivo donde lo verificó. La prueba prueba simultáneamente conexión, ruta, CLI y acceso al repositorio sin modificar nada.\n\n## Preparar trabajo paralelo\n\n- un worktree y una rama por tarea;\n- un único responsable para recursos compartidos;\n- alcance y validaciones escritos antes de ejecutar;\n- revisión humana antes de merge o deploy;\n- credenciales limitadas al host y al proyecto necesarios.\n\n## Checklist portable\n\n- [ ] El servicio SSH del entorno Linux está activo.\n- [ ] Orca usa una clave exclusiva.\n- [ ] El host local conecta sin depender de una terminal abierta.\n- [ ] Los repositorios se abren desde el filesystem Linux.\n- [ ] Los agentes están disponibles y autenticados en ese host.\n- [ ] La prueba de solo lectura terminó con Git limpio.\n- [ ] La estrategia de worktrees está definida.\n\nLos comandos exactos dependen de la distribución, la versión de WSL y la política de seguridad. La guía conserva el diseño; la implementación se valida contra la documentación vigente de cada herramienta.\n" }, { "slug": "acceso-portatil-orca", "title": "Acceso portátil a Orca mediante red privada", "summary": "Usar otro dispositivo como cliente del mismo entorno de desarrollo, sin duplicar repositorios ni publicar SSH en Internet.", "type": "guide", "order": 8, "tags": [ "orca", "tailscale", "ssh", "wsl", "remoto", "seguridad" ], "related": [ "hosts-ssh", "setup-windows-wsl", "tailscale-red-privada-identidad", "tailscale-entorno-agentes" ], "area": "Orca", "glyph": "↗", "hue": "rgba(87,217,232,.22)", "file": "08-acceso-portatil.md", "html": "Trabajar desde una notebook sobre el mismo entorno, repositorios y agentes que viven en la estación principal.
\nEl dispositivo portátil no recrea el stack ni mantiene clones paralelos. Funciona como cliente de Orca y conecta por SSH a través de una red privada.
\nEl cliente apunta a una identidad privada estable del host y no a una dirección interna efímera. Esto evita reconfigurar la conexión después de reinicios o cambios de red.
\nLa notebook sólo debería iniciar conexiones al host de desarrollo y al puerto necesario. Otros servidores y destinos quedan fuera de alcance.
\nEl usuario cotidiano del dispositivo no necesita capacidad para modificar las reglas de la red privada. La conectividad autorizada y la administración de esa conectividad son permisos distintos.
\nSe valida que el host permitido responda y que un destino explícitamente bloqueado no sea alcanzable. Probar contra una máquina apagada no demuestra que la política funcione.
\nEl acceso remoto depende de que el host esté encendido, conectado y con el entorno de ejecución iniciado. La red privada no reemplaza una estrategia de encendido remoto ni de recuperación del sistema.
\nLa movilidad deja de crear una segunda estación de desarrollo. Hay un único estado de Git, una única política de credenciales y los mismos agentes vistos desde otro cliente.
\nUn proyecto de transformación digital combinaba integraciones, datos, APIs, seguridad y operación productiva. Una sola conversación podía conservar el contexto, pero se convertía en cuello de botella al abrir varios frentes en paralelo.
\nLa alternativa de lanzar agentes sin estructura tampoco servía: aumentaba el riesgo de cambios superpuestos, decisiones contradictorias y pérdida de contexto al cambiar de sesión.
\nUn agente de mayor capacidad opera sobre el workspace principal. Su función es:
\nEl coordinador no existe para implementar todo. Existe para que cada tarea nazca con contexto suficiente y vuelva con evidencia comparable.
\nLas tareas acotadas se asignan según costo, disponibilidad y fortaleza del agente. Pueden convivir modelos y CLIs distintos sin cambiar la metodología.
\nCada worker recibe:
\nLos agentes de revisión se separan, cuando corresponde, de quienes realizaron la implementación.
\nLa documentación V4, revisada el 12 de octubre de 2026, separa responsabilidades que antes se concentraban en un solo coordinador. El diseño anterior queda como historia del caso; la distribución vigente distingue tres niveles:
\n| Nivel | \nAsignación del entorno | \nResponsabilidad | \n
|---|---|---|
| Dirección general | \nOpus | \nConversación con la persona, prioridades y decisiones transversales | \n
| Integración | \nSol con esfuerzo low | \nReconstruir estado, ordenar dependencias e integrar evidencia de los paquetes | \n
| Coordinación de paquete | \nSol con esfuerzo medium | \nConducir una capacidad acotada hasta su aceptación | \n
Son asignaciones de este proyecto, no una recomendación universal ni una equivalencia entre modelos. Para implementación LIVE se usa Luna con esfuerzo high o Sonnet; la auditoría cambia a la familia opuesta al implementador. Separar familias agrega diversidad de revisión, pero no garantiza detectar errores ni reemplaza las pruebas.
\nLa unidad sigue siendo una capacidad, una tarea, una rama y un worktree. BUILD/LIVE y el gate de tres partes ya existían en V3: paridad con el comportamiento del CRM, recuperación preparada y auditoría. V4 modifica el reparto de autoridad y permite operaciones LIVE pequeñas dentro de un alcance previamente autorizado, con verificación y reversión automática acotada. Borrados y tombstones, las marcas de eliminación, requieren permiso humano explícito. Tener una regla en el repositorio no concede permisos en otra sesión o herramienta.
\nLa dirección general recibe una bandeja de decisiones agrupadas por urgencia: incidentes, destrabes y asuntos sin apuro. El integrador reúne evidencia; no interrumpe a la persona por cada avance ni convierte una decisión pendiente en permiso implícito.
\nEl circuito vigente distingue listo local, aplicado y aceptado. Un PR integrado demuestra integración; un postflight inmediato demuestra el comportamiento que efectivamente midió. La aceptación natural requiere observar el ciclo real acordado. Si queda trabajo, el handoff conserva el remanente, su responsable y la evidencia que falta: entregar el problema a otra persona no equivale a resolverlo.
\nAl retomar, primero se reconstruyen PRs, ramas, workers y despliegues reales. Sólo después se abre trabajo nuevo. Esa comprobación evita duplicar una implementación que siguió avanzando mientras la conversación estaba cerrada.
\nEsta actualización resume documentación y registros del proyecto revisados el 12 de octubre, anonimizados. No constituye una nueva ejecución de sus pruebas ni una validación universal de sus controles. Los contratos de rol deben contrastarse con los permisos efectivos del runtime, como explica el entorno es la política.
\nLos frentes dejaron de ser terminales anónimas. Cada uno quedó ligado a un proyecto, worktree, agente y estado visible.
\nDistintos CLIs convivieron en una misma superficie. El modelo pudo elegirse por tarea sin perder el mapa general del proyecto.
\nLas implementaciones no compitieron por el mismo checkout. Cada rama podía revisarse, compararse o descartarse sin contaminar el trabajo principal.
\nSeparar interfaz, proceso, sesión, worktree y estado persistente permitió recuperar trabajo después de interrupciones sin asumir que todo seguía vivo ni tomar acciones destructivas por reflejo.
\nLa interfaz funcionó como cockpit mientras repositorios y agentes permanecían en un entorno de ejecución central. Otros dispositivos podían actuar como ventanas hacia el mismo estado, sin crear copias divergentes.
\nLa mejora no vino de “usar muchos modelos”. Vino de diseñar un sistema donde los modelos pueden reemplazarse, las tareas quedan aisladas y el contexto importante no depende de ninguno de ellos.
\nOrca volvió visible y operable esa arquitectura. La calidad del resultado siguió dependiendo de los contratos de trabajo, Git, las validaciones y la supervisión humana.
\n\n\n", "headings": [ { "label": "Situación inicial", "depth": 2, "id": "situacion-inicial" }, { "label": "Modelo inicial adoptado", "depth": 2, "id": "modelo-inicial-adoptado" }, { "label": "Agente coordinador", "depth": 3, "id": "agente-coordinador" }, { "label": "Implementadores y revisores", "depth": 3, "id": "implementadores-y-revisores" }, { "label": "Flujo operativo inicial", "depth": 2, "id": "flujo-operativo-inicial" }, { "label": "Evolución del caso: V4, octubre de 2026", "depth": 2, "id": "evolucion-del-caso-v4-octubre-de-2026" }, { "label": "Del merge al resultado aceptado", "depth": 3, "id": "del-merge-al-resultado-aceptado" }, { "label": "Qué aportó Orca", "depth": 2, "id": "que-aporto-orca" }, { "label": "Paralelismo comprensible", "depth": 3, "id": "paralelismo-comprensible" }, { "label": "Libertad de proveedor", "depth": 3, "id": "libertad-de-proveedor" }, { "label": "Aislamiento real", "depth": 3, "id": "aislamiento-real" }, { "label": "Continuidad", "depth": 3, "id": "continuidad" }, { "label": "Operación remota", "depth": 3, "id": "operacion-remota" }, { "label": "Beneficios obtenidos", "depth": 2, "id": "beneficios-obtenidos" }, { "label": "La lección transferible", "depth": 2, "id": "la-leccion-transferible" } ], "raw": "---\nslug: caso-orca-cockpit-multiagente\ntitle: Caso real — Orca como cockpit multiagente\ntype: case-study\norder: 9\nsummary: La evolución de un coordinador único a dirección, integración y paquetes separados, con auditoría cruzada y aceptación verificable.\ntags: [orca, caso-real, multiagente, worktrees, orquestacion]\nrelated: [orquestacion, workspaces-y-worktrees, continuidad-y-observabilidad]\narea: Orca\nglyph: ◈\nhue: rgba(236,95,189,.24)\n---\n\n# Caso real — Orca como cockpit multiagente\n\n## Situación inicial\n\nUn proyecto de transformación digital combinaba integraciones, datos, APIs, seguridad y operación productiva. Una sola conversación podía conservar el contexto, pero se convertía en cuello de botella al abrir varios frentes en paralelo.\n\nLa alternativa de lanzar agentes sin estructura tampoco servía: aumentaba el riesgo de cambios superpuestos, decisiones contradictorias y pérdida de contexto al cambiar de sesión.\n\n## Modelo inicial adoptado\n\n### Agente coordinador\n\nUn agente de mayor capacidad opera sobre el workspace principal. Su función es:\n\n- revisar el estado general;\n- mantener decisiones y restricciones vigentes;\n- preparar el plan;\n- dividir el trabajo en unidades verificables;\n- revisar implementaciones y auditorías;\n- decidir el siguiente frente.\n\nEl coordinador no existe para implementar todo. Existe para que cada tarea nazca con contexto suficiente y vuelva con evidencia comparable.\n\n### Implementadores y revisores\n\nLas tareas acotadas se asignan según costo, disponibilidad y fortaleza del agente. Pueden convivir modelos y CLIs distintos sin cambiar la metodología.\n\nCada worker recibe:\n\n- su propio worktree y rama;\n- un alcance explícito;\n- restricciones operativas;\n- condiciones de finalización;\n- una forma esperada de entregar evidencia.\n\nLos agentes de revisión se separan, cuando corresponde, de quienes realizaron la implementación.\n\n## Flujo operativo inicial\n\n1. El coordinador inspecciona el proyecto y prepara una tarea.\n2. Se crea un worktree desde una base conocida.\n3. El implementador trabaja dentro de su alcance.\n4. Entrega cambios, pruebas, riesgos y pendientes.\n5. Otro agente o el coordinador revisa el resultado.\n6. La integración y cualquier acción productiva permanecen detrás de un gate humano.\n\n## Evolución del caso: V4, octubre de 2026\n\nLa documentación V4, revisada el 12 de octubre de 2026, separa responsabilidades que antes se concentraban en un solo coordinador. El diseño anterior queda como historia del caso; la distribución vigente distingue tres niveles:\n\n| Nivel | Asignación del entorno | Responsabilidad |\n| --- | --- | --- |\n| Dirección general | Opus | Conversación con la persona, prioridades y decisiones transversales |\n| Integración | Sol con esfuerzo low | Reconstruir estado, ordenar dependencias e integrar evidencia de los paquetes |\n| Coordinación de paquete | Sol con esfuerzo medium | Conducir una capacidad acotada hasta su aceptación |\n\nSon asignaciones de este proyecto, no una recomendación universal ni una equivalencia entre modelos. Para implementación LIVE se usa Luna con esfuerzo high o Sonnet; la auditoría cambia a la familia opuesta al implementador. Separar familias agrega diversidad de revisión, pero no garantiza detectar errores ni reemplaza las pruebas.\n\nLa unidad sigue siendo una capacidad, una tarea, una rama y un worktree. **BUILD/LIVE y el gate de tres partes ya existían en V3**: paridad con el comportamiento del CRM, recuperación preparada y auditoría. V4 modifica el reparto de autoridad y permite operaciones LIVE pequeñas dentro de un alcance previamente autorizado, con verificación y reversión automática acotada. Borrados y tombstones, las marcas de eliminación, requieren permiso humano explícito. Tener una regla en el repositorio no concede permisos en otra sesión o herramienta.\n\nLa dirección general recibe una bandeja de decisiones agrupadas por urgencia: incidentes, destrabes y asuntos sin apuro. El integrador reúne evidencia; no interrumpe a la persona por cada avance ni convierte una decisión pendiente en permiso implícito.\n\n### Del merge al resultado aceptado\n\nEl circuito vigente distingue **listo local, aplicado y aceptado**. Un PR integrado demuestra integración; un postflight inmediato demuestra el comportamiento que efectivamente midió. La aceptación natural requiere observar el ciclo real acordado. Si queda trabajo, el handoff conserva el remanente, su responsable y la evidencia que falta: entregar el problema a otra persona no equivale a resolverlo.\n\nAl retomar, primero se reconstruyen PRs, ramas, workers y despliegues reales. Sólo después se abre trabajo nuevo. Esa comprobación evita duplicar una implementación que siguió avanzando mientras la conversación estaba cerrada.\n\nEsta actualización resume documentación y registros del proyecto revisados el 12 de octubre, anonimizados. No constituye una nueva ejecución de sus pruebas ni una validación universal de sus controles. Los contratos de rol deben contrastarse con los permisos efectivos del runtime, como explica [el entorno es la política](/entrada/modelos-guiados-el-entorno-es-la-politica).\n\n\n## Qué aportó Orca\n\n### Paralelismo comprensible\n\nLos frentes dejaron de ser terminales anónimas. Cada uno quedó ligado a un proyecto, worktree, agente y estado visible.\n\n### Libertad de proveedor\n\nDistintos CLIs convivieron en una misma superficie. El modelo pudo elegirse por tarea sin perder el mapa general del proyecto.\n\n### Aislamiento real\n\nLas implementaciones no compitieron por el mismo checkout. Cada rama podía revisarse, compararse o descartarse sin contaminar el trabajo principal.\n\n### Continuidad\n\nSeparar interfaz, proceso, sesión, worktree y estado persistente permitió recuperar trabajo después de interrupciones sin asumir que todo seguía vivo ni tomar acciones destructivas por reflejo.\n\n### Operación remota\n\nLa interfaz funcionó como cockpit mientras repositorios y agentes permanecían en un entorno de ejecución central. Otros dispositivos podían actuar como ventanas hacia el mismo estado, sin crear copias divergentes.\n\n## Beneficios obtenidos\n\n- más frentes simultáneos sin compartir archivos de trabajo;\n- continuidad del contexto aunque cambiara el implementador;\n- selección de modelo por costo y tipo de tarea;\n- handoffs más claros y revisables;\n- menor dependencia de una sesión o interfaz concreta;\n- separación explícita entre planificación, implementación, auditoría y producción.\n\n## La lección transferible\n\nLa mejora no vino de “usar muchos modelos”. Vino de diseñar un sistema donde los modelos pueden reemplazarse, las tareas quedan aisladas y el contexto importante no depende de ninguno de ellos.\n\nOrca volvió visible y operable esa arquitectura. La calidad del resultado siguió dependiendo de los contratos de trabajo, Git, las validaciones y la supervisión humana.\n\n> Caso basado en un entorno real. Se removieron nombres de empresa, repositorios, infraestructura, incidentes identificables y datos operativos.\n" }, { "slug": "planificar-workstation-am5-escalable", "title": "Planificar una workstation AM5 escalable", "summary": "Cómo auditar una PC existente y migrar a AM5 en tres escalones — económico, medio y high-end — sin recomprar media máquina en cada etapa.", "type": "guide", "order": 9, "tags": [ "hardware", "am5", "workstation", "ryzen", "wsl", "agentes", "upgrade" ], "related": [ "setup-windows-wsl", "orquestacion", "agent-terminals" ], "area": "Orca", "glyph": "◈", "hue": "rgba(168,106,255,.24)", "file": "planificar-workstation-am5-escalable.md", "html": "Caso basado en un entorno real. Se removieron nombres de empresa, repositorios, infraestructura, incidentes identificables y datos operativos.
\n
\n\nReferencias externas revisadas el 12 de octubre de 2026. Los modelos concretos sirven como referencia de arquitectura, no como una lista eterna de compra. Antes de comprar, validar precios, BIOS, QVL de memoria, dimensiones y requisitos eléctricos contra las fichas vigentes.
\n
Una migración escalable no consiste en armar tres PCs. Consiste en definir una máquina final y construirla por etapas.
\nEl error clásico es comprar una configuración económica completa, reemplazar media PC para llegar a gama media y volver a reemplazarla para alcanzar high-end. Esta guía invierte la lógica:
\n\n\nNo comprar en una etapa ninguna pieza que sepamos que habrá que reemplazar en la siguiente, salvo una pieza transitoria elegida deliberadamente.
\n
En AM5 esa pieza puede ser el procesador de entrada. Motherboard, memoria, almacenamiento, gabinete, refrigeración y fuente deberían comprarse pensando desde el primer día en el destino final.
\nEste patrón nació al evaluar una workstation AM4 todavía competente: Ryzen 7 de ocho núcleos, X570, 32 GB DDR4, una RTX serie 30, NVMe rápido y fuente de 850 W de buena calidad. La conclusión no fue “cambiar todo”, sino separar lo que había envejecido de lo que todavía tenía valor.
\nAntes de elegir un Ryzen, inventariar la máquina. La pregunta no es solamente qué tengo, sino qué puede cruzar de plataforma sin convertirse en cuello de botella o riesgo.
\n| Componente | \nQué registrar | \nPregunta de validación | \n
|---|---|---|
| CPU | \nmodelo, núcleos, consumo y carga habitual | \n¿El límite real hoy es CPU? | \n
| Motherboard | \nsocket, chipset, BIOS, slots y conectividad | \n¿Obliga a cambiar de plataforma? | \n
| RAM | \ncapacidad, módulos, velocidad y uso pico | \n¿La capacidad actual ya llega al límite? | \n
| GPU | \nmodelo, consumo y resolución objetivo | \n¿Necesita cambiar ahora o puede migrar? | \n
| Fuente | \nmodelo exacto, potencia, edad y conectores | \n¿Tiene calidad y margen para el destino final? | \n
| Cooler | \nmodelo, socket soportado y capacidad térmica | \n¿Tiene kit AM5 y margen para el CPU final? | \n
| NVMe/SATA | \nmodelo, salud, capacidad y uso | \n¿Puede reutilizarse como disco principal o secundario? | \n
| Gabinete | \nformato, airflow y clearances | \n¿Entran motherboard, GPU y refrigeración futuras? | \n
| Periféricos PCIe/USB | \nplacas, DAC, capturadoras, red, docks | \n¿La nueva placa ofrece lanes y puertos suficientes? | \n
| Sistema | \nWindows/Linux, WSL, VMs, Docker, agentes | \n¿Qué recurso se satura durante el trabajo real? | \n
Para una workstation de desarrollo y agentes conviene observar al menos:
\nSi 32 GB de RAM llegan al límite pero la GPU permanece holgada, comprar una GPU primero sería una mejora espectacularmente cara del componente equivocado.
\nUna migración de socket obliga a reemplazar CPU + motherboard + RAM. No necesariamente obliga a reemplazar todo lo demás.
\nUna GPU PCIe moderna, un buen NVMe, gabinete adecuado y una fuente ATX de calidad pueden migrar. Un cooler puede hacerlo si el fabricante ofrece compatibilidad o mounting AM5.
\nLa fuente merece una revisión particular: no alcanza con leer “850 W”. Importan modelo, calidad, antigüedad, protecciones, conectores y la GPU final prevista.
\nLa RAM DDR4, en cambio, no migra: AM5 utiliza DDR5.
\nLa siguiente matriz no propone tres builds independientes. Propone tres estados de la misma workstation.
\n| Pieza | \nEcon | \nMedia | \nHigh-end | \n
|---|---|---|---|
| CPU | \nRyzen 5 9600X | \nmantener el 9600X o subir sólo si existe una necesidad concreta | \nRyzen 9 9950X3D / 9950X3D2 según carga y precio | \n
| Motherboard | \nB850 sólida | \nla misma | \nla misma, o X870E sólo si el I/O lo justificaba desde el inicio | \n
| RAM | \n64 GB DDR5, 2×32 | \nla misma | \n64 GB o 128 GB si las mediciones lo justifican | \n
| GPU | \nreutilizar una GPU vigente | \nmantener | \nactualizar al final según workload | \n
| NVMe | \nreutilizar uno sano | \nsumar capacidad | \nGen5 sólo si la carga aprovecha su rendimiento | \n
| Fuente | \nreutilizar si pasa la auditoría | \nla misma | \ncambiar sólo si la GPU/CPU final lo exige | \n
| Cooler | \ncomprar con margen para el destino | \nel mismo | \nel mismo si fue dimensionado correctamente | \n
| Gabinete | \nreutilizar si cumple | \nel mismo | \nel mismo | \n
El objetivo de la gama económica no es construir una PC barata. Es pagar el mínimo razonable para entrar a la plataforma correcta.
\nUn Ryzen 5 9600X funciona bien como pieza transitoria: 6 núcleos / 12 hilos, arquitectura Zen 5, AM5, DDR5 y PCIe 5.0.
\nNo tiene que ser el procesador definitivo. Tiene que permitir migrar la plataforma sin degradar la experiencia mientras se financia el resto.
\nUna B850 bien elegida puede acompañar toda la ruta. Conviene revisar:
\nComprar una motherboard mínima para reemplazarla después destruye buena parte del beneficio de una migración progresiva.
\nPara desarrollo con WSL, Docker, navegadores, IDEs, agentes y servicios locales, 2×32 GB es un punto de partida mucho más durable que 2×16 GB.
\nEn una motherboard de cuatro DIMM, además deja dos slots libres. Llenar cuatro DIMM puede reducir la frecuencia de memoria soportada y complicar la estabilidad, por lo que “compro dos módulos ahora y agrego otros dos iguales después” no siempre es la estrategia más limpia.
\nDDR5-6000 con perfil EXPO y latencias razonables es una referencia habitual para Ryzen, pero EXPO es overclocking de memoria, no una velocidad garantizada del procesador. El kit concreto debe validarse contra CPU, placa y QVL, y probarse con la capacidad y cantidad de módulos elegidas. AMD EXPO
\nEsta etapa es deliberadamente rara: puede no requerir otro CPU.
\nSi el procesador de entrada sigue resolviendo el workload, la plata puede producir más valor en almacenamiento adicional, refrigeración, backup, red, UPS o quedar reservada para el salto final.
\nUn Ryzen 7 de ocho núcleos puede ser una excelente compra cuando la máquina vaya a quedarse en gama media durante años. Si el destino ya está definido como Ryzen 9 high-end, comprar un Ryzen 7 solamente para usarlo unos meses crea un escalón innecesario.
\n\n\nLa gama media es un estado de madurez del sistema, no la obligación de comprar un CPU intermedio.
\n
Para una workstation híbrida que mezcla desarrollo, multitarea pesada y gaming, la familia Ryzen 9 X3D ofrece un destino interesante.
\nEl Ryzen 9 9950X3D combina 16 núcleos / 32 hilos con 3D V-Cache. El Ryzen 9 9950X3D2 Dual Edition mantiene 16/32 y extiende el enfoque de 3D V-Cache a ambos CCD.
\nAMD especifica un TDP de 200 W para el X3D2, frente a 170 W para el 9950X3D, y recomienda refrigeración líquida para un rendimiento óptimo. Si ése es el destino, hay que dimensionar VRM, cooler y fuente para ese modelo desde el inicio; compartir socket no garantiza el mismo margen térmico. 9950X3D2 Dual Edition · 9950X3D
\nEso no vuelve automáticamente al X3D2 la compra correcta. Su sentido aparece cuando la carga y el presupuesto pueden aprovecharlo.
\nPara gaming prioritario, un Ryzen 7 X3D puede ser una alternativa más racional. Para compilación, virtualización, creación, multitarea y muchos procesos concurrentes, los 16 núcleos pueden aportar valor real.
\nNo elegir chipset por prestigio.
\nB850 puede ser suficiente cuando se necesita una GPU, varios NVMe, buen USB y una plataforma robusta.
\nX870E empieza a justificar su precio cuando el diseño necesita más conectividad y lanes PCIe, varios dispositivos de alta velocidad, USB4 u opciones de expansión que efectivamente se van a usar.
\nUSB4 es estándar en X870E y opcional en B850: no alcanza con el nombre del chipset para saber qué puertos trae una placa concreta. Compará su manual y el reparto de lanes al poblar los slots. Chipsets AM5
\nLa pregunta correcta no es “¿cuál es más high-end?”, sino:
\n\n\n¿qué recurso de X870E utilizará esta workstation que B850 no puede entregar?
\n
Si la respuesta es “ninguno”, el presupuesto probablemente tenga un destino mejor.
\nSupongamos una máquina AM4 con Ryzen 7 de ocho núcleos, X570, 32 GB DDR4, RTX serie 30, NVMe PCIe 4.0 rápido y fuente 850 W de buena calidad.
\n| Pieza | \nDecisión | \n
|---|---|
| CPU AM4 | \nno migra | \n
| X570 | \nno migra | \n
| DDR4 | \nno migra | \n
| RTX serie 30 | \nmigrar | \n
| NVMe PCIe 4.0 | \nmigrar | \n
| fuente 850 W | \nmigrar si pasa revisión | \n
| gabinete | \nmigrar si cumple clearances | \n
| cooler | \nvalidar mounting y capacidad | \n
El primer desembolso AM5 se concentra así en CPU + motherboard + DDR5 + refrigeración si hace falta, en lugar de financiar una PC completamente nueva.
\nNo conviene atar la planificación a una sola tienda o país. Para cada etapa, cotizar las piezas en tres mercados y comparar el costo total de adquisición.
\n| Canal | \nDónde puede destacar | \nQué validar antes de comprar | \n
|---|---|---|
| Argentina | \ndisponibilidad inmediata, cuotas, devolución y garantía local | \nprecio contado vs financiado, reputación del vendedor y garantía | \n
| Amazon | \ncomponentes nuevos, catálogo amplio y ofertas puntuales | \nenvío a Argentina, cargos estimados, vendedor, garantía y devolución internacional | \n
| eBay | \noportunidades, generaciones anteriores, open-box y usado | \ncondición real, reputación, fotos, devolución, envío, cargos y riesgo de garantía | \n
Para una compra internacional, usar como referencia:
\ncosto puesto =\n precio del componente\n+ envío\n+ impuestos / cargos de importación aplicables\n+ conversión y costos del medio de pago\n+ eventual gestión logísticaLas reglas aduaneras, franquicias, impuestos y esquemas de courier pueden cambiar. Antes de cerrar una compra internacional hay que recalcularlos con las condiciones vigentes.
\nComo regla de evaluación, no como mandato:
\nEn eBay, CPU, RAM y hardware open-box o usado pueden ser tentadores, pero una workstation de producción no debería ahorrar una cantidad pequeña a cambio de una procedencia dudosa. Para motherboard, GPU y almacenamiento usado, la vara de evidencia del vendedor debe ser especialmente alta.
\n| Criterio | \nArgentina | \nAmazon | \neBay | \n
|---|---|---|---|
| Precio final puesto | \ncalcular | \ncalcular | \ncalcular | \n
| Tiempo de entrega | \ncomparar | \ncomparar | \ncomparar | \n
| Garantía utilizable | \nvalidar | \nvalidar | \nvalidar | \n
| Devolución práctica | \nvalidar | \nvalidar | \nvalidar | \n
| Nuevo / open-box / usado | \nconfirmar | \nconfirmar | \nconfirmar | \n
| Riesgo logístico | \nestimar | \nestimar | \nestimar | \n
| Ahorro vs alternativa | \ncalcular | \ncalcular | \ncalcular | \n
La opción ganadora no es necesariamente la más barata: es la que ofrece suficiente ahorro para compensar tiempo, garantía y riesgo.
\nAntes de pagar:
\n\n\n¿Esta pieza forma parte de la máquina final o resuelve un cuello de botella medido durante suficiente tiempo como para justificar ser transitoria?
\n
Si ninguna de las dos es cierta, probablemente no haya que comprarla.
\nSETUP ACTUAL\n\nCPU:\nMotherboard:\nRAM:\nGPU:\nFuente (modelo exacto + antigüedad):\nCooler:\nGabinete:\nNVMe/SATA:\nPlacas PCIe:\nPeriféricos USB críticos:\nSistema operativo:\nWSL / VMs / Docker:\nCarga habitual:\nGaming (resolución / Hz):\nRAM pico:\nCPU pico:\nVRAM pico:\nTemperaturas:\nProblema que quiero resolver:\nPresupuesto por etapa:\nDestino final deseado:Con esos datos se puede clasificar cada componente como MIGRAR / REEMPLAZAR / VALIDAR / COMPRAR DESPUÉS y recién entonces construir las tres etapas.
\nUna buena ruta de upgrade no maximiza la potencia del próximo ticket. Maximiza cuántas compras siguen teniendo sentido cuando la máquina llega a su forma final.
\nAM5 es especialmente útil para esta estrategia porque permite separar el cambio de plataforma del salto al procesador definitivo. El setup económico deja de ser un destino mediocre y se convierte en la primera versión funcional de una workstation que todavía está creciendo.
\n\n\nVigencia editorial: 12 de octubre de 2026. OpenDesign evoluciona rápido; verificar adaptadores, catálogo y requisitos en la documentación oficial antes de fijarlos como política.
\n
Los agentes de código aprendieron a construir interfaces antes de aprender a sostener una identidad visual. Pueden transformar una consigna en HTML, CSS y componentes funcionales, pero todavía tienden a diseñar cada ejecución como si fuera la primera: inventan una paleta, cambian la escala tipográfica, alteran el espaciado y terminan regresando al mismo dashboard genérico con cards flotantes.
\nOpenDesign parte de una tesis más interesante que “la IA ahora diseña”: la capacidad ya existe, pero le falta una dirección visual persistente y un método de producción.
\nNo presenta un nuevo modelo. Se instala como una capa alrededor de los agentes que ya usamos —Codex, Claude Code, OpenCode, Cursor, Gemini CLI, Hermes y otros— y los convierte en motores de un workspace de diseño local.
\nEn un prompt tradicional, producto y estética suelen quedar mezclados:
\n\n\nHacé un dashboard moderno, elegante, oscuro, con métricas, filtros y un estilo premium.
\n
La descripción parece suficiente hasta que hay que producir una segunda pantalla, una presentación o un email con la misma marca. Entonces aparece la deriva: cada agente interpreta “moderno” de una manera distinta.
\nOpenDesign separa el proceso en piezas:
\n| Pieza | \nResponsabilidad | \n
|---|---|
| Brief | \nObjetivo, audiencia y contenido | \n
| Skill | \nMétodo de trabajo y reglas de producción | \n
| Template | \nTipo y estructura del artefacto | \n
DESIGN.md | \nIdentidad visual que debe conservarse | \n
| Agente | \nRazonamiento y ejecución | \n
La combinación permite mantener constante el lenguaje visual mientras cambia el artefacto. Un mismo sistema puede orientar una landing, un dashboard, un prototipo móvil o un deck sin volver a describir la marca desde cero.
\nDESIGN.md como contrato visualLa pieza más valiosa del enfoque es DESIGN.md: un archivo que codifica decisiones sobre color, tipografía, jerarquía, composición, espaciado, superficies, componentes y restricciones.
No es sólo una colección de tokens. Puede expresar criterio:
\nOpenDesign puede extraer ese sistema desde capturas, Figma, una URL o un repositorio y guardarlo junto al proyecto. Desde ese momento, la dirección deja de vivir únicamente en la memoria de una conversación o en el ojo de una persona.
\nEse archivo puede versionarse, revisarse y utilizarse con distintos agentes. Cambiar Codex por Claude Code no debería exigir reconstruir la identidad; cambiar una landing por una presentación tampoco.
\nEl flujo propuesto es:
\nbrief → template → dirección → DESIGN.md → artefacto → handoff → memoriaEl agente recibe el sistema visual y las instrucciones correspondientes. Con un CLI y herramientas de filesystem escribe los archivos del proyecto; una ejecución BYOK/API sin esas herramientas devuelve un bloque de artefacto para la preview. No son recorridos equivalentes de edición. Contrato de ejecución. El resultado puede continuar como código o exportarse, según el formato, a HTML, ZIP, PDF, PPTX o video.
\nEsto cambia la unidad de valor. Ya no se trata sólo de generar una pantalla atractiva, sino de construir un proceso capaz de producir una familia coherente de artefactos.
\nOpenDesign no reemplaza al agente que implementa. Tampoco reemplaza automáticamente a Figma o a una persona diseñadora.
\nSu papel se parece más al de un director creativo compartido:
\nEl modelo sigue resolviendo y escribiendo. OpenDesign condiciona el terreno donde toma esas decisiones.
\nEsta distinción importa porque el diseño agéntico no mejora solamente comprando un modelo más grande. También mejora reduciendo la cantidad de decisiones visuales que el modelo debe improvisar.
\nOpenDesign se acerca más a un IDE visual dirigido por agentes que a un canvas colaborativo tradicional.
\n| OpenDesign favorece | \nFigma favorece | \n
|---|---|
| Generación desde intención | \nManipulación visual directa | \n
| Artefactos que nacen como código | \nDiseño libre sobre canvas | \n
| Sistemas portables entre agentes | \nBibliotecas maduras de componentes | \n
| Automatización y repetición | \nComentarios y redlines precisos | \n
| Handoff directo a ingeniería | \nColaboración visual multipersona | \n
La comparación describe énfasis de trabajo, no exclusividades: OpenDesign también documenta comentarios y espacios de equipo. Su FAQ aclara que no hay exportación a Figma, por lo que no conviene asumir un round-trip nativo. Alcance actual.
\nNo hace falta elegir uno como reemplazo absoluto del otro. Un equipo puede explorar y producir en OpenDesign, revisar o refinar en Figma cuando el tipo de trabajo lo requiera y devolver las decisiones confirmadas al sistema portable.
\nEn un entorno donde distintos agentes cumplen roles diferentes, DESIGN.md funciona como una política compartida. El coordinador puede definir la dirección; un worker producir el primer artefacto; otro revisar accesibilidad; otro integrarlo al producto. Todos leen el mismo contrato visual.
Esto permite separar responsabilidades:
\nOrca o cockpit → coordina sesiones y proyectos\nCodex / Claude → razonan e implementan\nOpenDesign → conserva dirección visual y métodos\nGitHub → versiona el resultado\nFigma → habilita revisión manual cuando hace falta\nHosting → publica el artefactoOpenDesign no necesita apropiarse de toda la fábrica para resultar útil. Puede entrar como una especialidad, igual que un agente de seguridad, un navegador o una herramienta de pruebas.
\nEl proyecto es ambicioso: combina aplicación de escritorio, daemon local, adaptadores para numerosos CLIs, skills, plugins, MCP, generación multimedia y previews. Cada integración suma valor, pero también superficie de falla.
\nAdemás, un catálogo enorme no garantiza calidad uniforme. Skills y plugins comunitarios deben tratarse como código e instrucciones de terceros, especialmente cuando el agente tiene acceso al filesystem y a la terminal.
\nOpen source tampoco significa costo cero. La aplicación puede ser gratuita, pero cada generación consume la cuota o los créditos del agente y proveedor seleccionado.
\nOpenDesign merece atención porque ataca el punto exacto donde el desarrollo asistido suele perder calidad: la inconsistencia entre ejecuciones.
\nLos modelos ya saben producir interfaces. Lo difícil es enseñarles qué decisiones no deben volver a tomar, qué identidad deben preservar y cómo transferir ese criterio a otro agente y otro formato.
\nAl transformar la dirección visual en archivos versionables, OpenDesign mueve el diseño desde el prompt efímero hacia la infraestructura del proyecto. Esa idea es más importante que cualquier template de su catálogo.
\n\n\nVigencia editorial: 12 de octubre de 2026. Los mecanismos de autenticación, modelos y límites dependen de cada proveedor y pueden cambiar.
\n
“Local-first” suena a una sola computadora. En Windows con WSL, sin embargo, una computadora contiene dos entornos que comparten recursos pero no necesariamente ejecutables, credenciales ni sesiones.
\nLa aplicación de OpenDesign puede vivir en Windows mientras Codex, Claude Code, OpenCode y los repositorios viven dentro de Ubuntu. En la pantalla todo parece local; desde el daemon son mundos distintos.
\nEsta frontera define mucho más que la instalación. Define quién ejecuta el modelo, dónde se guardan las credenciales y contra qué cuota se contabiliza cada generación.
\nOpenDesign puede llegar a un modelo por tres rutas conceptuales:
\n| Ruta | \nAutenticación | \nConsumo | \n
|---|---|---|
| Local CLI | \nAutenticación del agente instalado | \nPlan o facturación API, según esa autenticación | \n
| BYOK / proveedor custom | \nClave API | \nCuenta o saldo API del proveedor | \n
| OpenDesign Cloud | \nCuenta de OpenDesign | \nCréditos incluidos o comprados allí | \n
Si OpenDesign lanza un Codex CLI autenticado con ChatGPT, el trabajo se descuenta de la cuota de Codex. Si lanza Claude Code autenticado con Pro o Max, consume ese plan. Si recibe una clave en el panel de proveedores, ya no está usando la sesión del CLI: realiza llamadas API.
\nLa interfaz no cambia esta regla. La decide el camino efectivo que toma la request.
\nUn daemon iniciado por una aplicación de Windows inspecciona el entorno de Windows. No necesariamente ve:
\nPATH de la shell de WSL;.bashrc o servicios de systemd.Por eso tener codex, claude u opencode funcionando desde Ubuntu no garantiza que OpenDesign Desktop los muestre como Local CLI.
La solución más directa para conservar la aplicación nativa es duplicar los CLIs en Windows y autenticarlos allí. Las instalaciones quedan separadas, aunque consuman la misma cuota del plan.
\nOpenDesign Desktop en Windows\n ↓\nCodex / Claude Code nativos\n ↓\nCuotas de ChatGPT y ClaudeSi los agentes ya viven en WSL, la guía oficial de WSL2 recomienda ejecutar OpenDesign en ese mismo entorno. Así CLI, daemon, módulos y credenciales coinciden. La interfaz puede abrirse desde el navegador de Windows. Revisá también qué ejecutable resuelve od: Linux incluye una utilidad del sistema con ese nombre, ajena a OpenDesign.
Navegador Windows\n ↓\nOpenDesign daemon en WSL\n ↓\nCLIs y repositorios de WSLExiste una tercera opción: exponer en WSL un proxy compatible con OpenAI y configurarlo como proveedor custom.
\nOpenDesign en Windows\n ↓\nProxy local en 127.0.0.1\n ↓\nProveedor externoLa conectividad Windows–WSL y las defensas SSRF del daemon también importan: OpenDesign bloquea por defecto endpoints privados/internos; si esa protección rechaza el destino, revisá la allowlist exacta documentada, sin abrir rangos amplios. Es una condición de despliegue que hay que probar. Seguridad del proxy.
\nEste camino no reutiliza automáticamente la cuota de Codex o Claude. OpenDesign cree que está hablando con una API; el proxy decide qué proveedor y credencial utiliza detrás.
\nEl patrón permite adaptar protocolos y sesiones, pero publicar una API no habilita cualquier uso. OpenCode Go está pensado para tráfico de agentes de programación: exige un cliente identificable y una sesión estable. Un proxy no vuelve compatible un workload arbitrario; hay que verificar el cliente y el endpoint de cada modelo, que puede usar Responses, Chat Completions o Messages.
\nUn proxy no es necesariamente un parche. Puede convertirse en una frontera de control:
\nPero cada responsabilidad agregada también convierte al proxy en infraestructura que alguien debe mantener.
\nUn endpoint compatible no garantiza una conversación correctamente identificada. OpenCode Go solicita una sesión estable por conversación mediante información nativa del cliente o el encabezado x-opencode-session.
El proxy debe evitar dos extremos:
\nLa unidad correcta suele ser un thread o proyecto de OpenDesign:
\nx-opencode-session = hash(project_id + conversation_id)La derivación no debe incluir prompts, secretos ni la API key.
\nCuando OpenDesign obliga a completar un campo API key para un proveedor custom, hay dos diseños posibles.
\nOpenDesign guarda la key del proveedor y la transmite al proxy, que la reenvía.
\nEs simple, pero la credencial queda almacenada y circula por más componentes.
\nOpenDesign utiliza un token local aleatorio. El proxy lo valida y obtiene la key real desde su propio entorno protegido.
\nOpenDesign → token local\nProxy → valida token local\nProveedor externo → recibe la key realEsta separación limita el impacto de una exportación, un log accidental o una falla en el cliente. Para una instalación estable es la opción preferible.
\nUn puente de este tipo debería cumplir al menos con estas condiciones:
\nAuthorization, bodies completos ni variables sensibles;User-Agent identificable;Abrirlo en 0.0.0.0 transforma un puente local en un servicio accesible desde la red. Esa decisión exige autenticación, firewall y una revisión distinta.
La regla para entender el gasto es seguir la request completa:
\n¿Quién recibió finalmente la llamada autenticada?La etiqueta del modelo en la interfaz puede confundir. Un modelo de OpenAI servido por OpenCode Go no consume el plan de ChatGPT; consume la asignación del proveedor que atendió la request.
\nPara preservar sesiones existentes y separar consumos, una distribución posible es:
\n| Camino | \nUso | \n
|---|---|
| OpenDesign → Codex Windows | \nTrabajo descontado del plan de Codex | \n
| OpenDesign → Claude Code Windows | \nTrabajo descontado del plan de Claude | \n
| OpenDesign → proxy WSL → OpenCode Go | \nModelos económicos bajo los límites de Go | \n
| Orca → CLIs WSL | \nDesarrollo y coordinación existentes | \n
La duplicación de CLIs no es elegante, pero mantiene claras las fronteras. Mover todo el daemon a WSL reduce duplicación, aunque renuncia a parte de la comodidad de la aplicación nativa.
\nLa integración local no depende sólo de que dos procesos vivan en la misma computadora. Depende de que compartan el entorno correcto.
\nInstalar los CLIs en Windows es la ruta más simple para que OpenDesign Desktop consuma cuotas de los planes. Ejecutar el daemon en WSL es la ruta más coherente para reutilizar instalaciones existentes. Un proxy es la ruta más flexible cuando el proveedor ofrece una API y necesitamos controlar sesiones, credenciales o compatibilidad.
\nNinguna opción gana siempre. La decisión correcta surge de elegir qué queremos preservar: comodidad de escritorio, sesiones existentes, control del tráfico o aislamiento de credenciales.
\n\n\nReferencia de producto revisada el 12 de octubre de 2026: Hermes Agent de Nous Research. Los circuitos y permisos de esta guía son decisiones de diseño, no garantías automáticas del producto.
\n
Hermes sirve cuando el valor del agente no está solamente en conversar con una persona técnica, sino en estar disponible dentro de un circuito operativo: recibir consultas desde un canal compartido, consultar sistemas conectados y emitir alertas antes de que alguien recuerde mirar un tablero.
\nEn este circuito complementa a Codex, Claude Code u OpenCode. Hermes también ofrece CLI y herramientas de desarrollo; acá interesa su gateway de mensajería, que acerca esas capacidades al equipo y a sus canales.
\nMuchas capacidades internas terminan concentradas en quien tiene acceso al CRM, conoce una consulta o paga un asiento de una herramienta. Hermes permite envolver esas capacidades en una interfaz conversacional más accesible:
\nEl salto importante es pasar de un asistente que responde cuando lo llaman a un agente que forma parte del sistema de trabajo.
\nEl equipo consulta desde un canal que ya usa, sin aprender una interfaz nueva ni abrir una sesión técnica. Esto no elimina el control de acceso: exige allowlists, identidades claras y capacidades diferentes según usuario o canal.
\nUn evento pasivo en una cola o un sistema de Signals se transforma en una alerta accionable. La automatización tiene que distinguir información operativa de avisos sensibles y elegir el canal correcto para cada una.
\nHermes puede usar herramientas conectadas para consultar CRM, bases, documentación o servicios. El valor no está en sumar todos los MCP posibles, sino en elegir el mínimo que permita resolver el caso y otorgar el menor privilegio necesario.
\nInstalar Hermes no define:
\nEsas decisiones forman parte del producto. Un agente accesible por más personas amplifica utilidad, pero también superficie de riesgo y consumo.
\nEl agente debe acercar capacidades al equipo sin acercar autoridad innecesaria.
\nUna consulta comercial puede necesitar lectura de CRM. No necesita editar registros, acceder a producción por SSH ni conocer credenciales. La experiencia se diseña desde ese límite y no desde todo lo que técnicamente podría conectarse.
\n", "headings": [ { "label": "La idea central", "depth": 2, "id": "la-idea-central" }, { "label": "Qué problema resuelve", "depth": 2, "id": "que-problema-resuelve" }, { "label": "Dónde aporta valor", "depth": 2, "id": "donde-aporta-valor" }, { "label": "Acceso distribuido", "depth": 3, "id": "acceso-distribuido" }, { "label": "Proactividad", "depth": 3, "id": "proactividad" }, { "label": "Integración", "depth": 3, "id": "integracion" }, { "label": "Lo que no resuelve solo", "depth": 2, "id": "lo-que-no-resuelve-solo" }, { "label": "Principio de diseño", "depth": 2, "id": "principio-de-diseno" } ], "raw": "---\nslug: hermes-agente-operativo\ntitle: Hermes como agente operativo\ntype: concept\norder: 1\nsummary: Un agente autoalojado que lleva consultas y alertas a los canales donde trabaja el equipo, sin convertir cada interacción en una sesión técnica.\ntags: [hermes, agentes, canales, mcp, automatizacion]\nrelated: [hermes-preset-instalacion, caso-hermes-operaciones, modelos-guiados-el-entorno-es-la-politica]\narea: Hermes\nglyph: ✦\nhue: rgba(236,95,189,.24)\n---\n\n# Hermes como agente operativo\n\n> Referencia de producto revisada el 12 de octubre de 2026: [Hermes Agent de Nous Research](https://hermes-agent.nousresearch.com/docs). Los circuitos y permisos de esta guía son decisiones de diseño, no garantías automáticas del producto.\n\n## La idea central\n\nHermes sirve cuando el valor del agente no está solamente en conversar con una persona técnica, sino en **estar disponible dentro de un circuito operativo**: recibir consultas desde un canal compartido, consultar sistemas conectados y emitir alertas antes de que alguien recuerde mirar un tablero.\n\nEn este circuito complementa a Codex, Claude Code u OpenCode. Hermes también ofrece CLI y herramientas de desarrollo; acá interesa su gateway de mensajería, que acerca esas capacidades al equipo y a sus canales.\n\n## Qué problema resuelve\n\nMuchas capacidades internas terminan concentradas en quien tiene acceso al CRM, conoce una consulta o paga un asiento de una herramienta. Hermes permite envolver esas capacidades en una interfaz conversacional más accesible:\n\n- consultas sobre datos operativos desde WhatsApp, Slack o Discord;\n- avisos proactivos disparados por cron o eventos;\n- separación entre canales del equipo y notificaciones administrativas;\n- acceso a sistemas mediante integraciones MCP con alcance controlado;\n- operación continua en infraestructura propia o gestionada.\n\nEl salto importante es pasar de **un asistente que responde cuando lo llaman** a **un agente que forma parte del sistema de trabajo**.\n\n## Dónde aporta valor\n\n### Acceso distribuido\n\nEl equipo consulta desde un canal que ya usa, sin aprender una interfaz nueva ni abrir una sesión técnica. Esto no elimina el control de acceso: exige allowlists, identidades claras y capacidades diferentes según usuario o canal.\n\n### Proactividad\n\nUn evento pasivo en una cola o un sistema de Signals se transforma en una alerta accionable. La automatización tiene que distinguir información operativa de avisos sensibles y elegir el canal correcto para cada una.\n\n### Integración\n\nHermes puede usar herramientas conectadas para consultar CRM, bases, documentación o servicios. El valor no está en sumar todos los MCP posibles, sino en elegir el mínimo que permita resolver el caso y otorgar el menor privilegio necesario.\n\n## Lo que no resuelve solo\n\nInstalar Hermes no define:\n\n- dónde alojarlo;\n- qué modelo usar;\n- quién puede hablarle;\n- qué herramientas puede ejecutar;\n- cuántos subagentes lanzar;\n- cómo manejar fallos y secretos.\n\nEsas decisiones forman parte del producto. Un agente accesible por más personas amplifica utilidad, pero también superficie de riesgo y consumo.\n\n## Principio de diseño\n\n**El agente debe acercar capacidades al equipo sin acercar autoridad innecesaria.**\n\nUna consulta comercial puede necesitar lectura de CRM. No necesita editar registros, acceder a producción por SSH ni conocer credenciales. La experiencia se diseña desde ese límite y no desde todo lo que técnicamente podría conectarse.\n" }, { "slug": "hermes-preset-instalacion", "title": "Preset de instalación de Hermes", "summary": "Cinco decisiones previas para montar Hermes sin copiar una infraestructura ajena: hosting, modelo, canales, concurrencia e integraciones.", "type": "guide", "order": 2, "tags": [ "hermes", "setup", "hosting", "modelos", "mcp" ], "related": [ "hermes-agente-operativo", "caso-hermes-operaciones" ], "area": "Hermes", "glyph": "◇", "hue": "rgba(168,106,255,.24)", "file": "hermes-preset-instalacion.md", "html": "\n\nReferencia de producto revisada el 12 de octubre de 2026: Hermes Agent de Nous Research. Los circuitos y permisos de esta guía son decisiones de diseño, no garantías automáticas del producto.
\n
Levantar Hermes no empieza con un comando. Empieza con cinco decisiones que determinan costo, seguridad y utilidad. El preset no prescribe un proveedor: funciona como guía para diseñar la instancia según el contexto.
\nOpciones habituales:
\nSepará el host del gateway del backend donde ejecuta herramientas: Hermes documenta backends como Docker, SSH, Daytona y Modal. Elegir un sandbox serverless no resuelve por sí solo la disponibilidad del gateway ni exige una GPU local para usar un modelo remoto.
\nPreguntas útiles:
\nReutilizar un VPS reduce costo, pero comparte fallas y recursos con lo que ya vive allí. La capacidad se mide después del despliegue; no se adivina desde la ficha comercial.
\nSe puede usar una API directa, un agregador como OpenRouter o el proveedor ofrecido por el ecosistema de Hermes.
\nSi no está claro qué modelo conviene, el método más sano es un benchmark pequeño con consultas reales. Puntuar precisión y costo sobre el mismo set evita elegir por reputación o por una demo amable.
\nLa key debería ser exclusiva para el proyecto. Aísla gasto, telemetría, revocación y radio de impacto.
\nHermes puede conectarse a WhatsApp, Telegram, Discord, Slack, Teams, Signal, email y otros canales. La pregunta no es cuántos soporta, sino quién necesita acceso y qué información puede recibir.
\nSeparar canales por rol evita que una alerta administrativa termine en un espacio comercial. Un mismo agente puede conversar con el equipo y notificar al administrador, pero cada recorrido necesita su propia política.
\nArrancar con un límite conservador de subagentes es una decisión operativa, no una pérdida de potencia. Se sube el paralelismo cuando existen métricas reales de CPU, RAM, latencia y costo.
\nSi la infraestructura aloja otros servicios, el agente no puede tratar todos los recursos como propios.
\nPara cada MCP o herramienta conectada, declarar:
\nUna empresa de servicios necesitaba acercar información operativa a un equipo no técnico y transformar eventos pasivos en avisos accionables. El objetivo no era sumar otro chat con IA, sino reducir la dependencia de una persona que supiera consultar cada sistema.
\nHermes se planteó como una capa conversacional conectada a herramientas internas, disponible desde canales que el equipo ya utilizaba.
\nLa primera versión se instaló en infraestructura existente. Para evitar que el nuevo servicio compitiera sin control con otras cargas, se definió una concurrencia conservadora y se postergó cualquier ampliación hasta contar con métricas reales.
\nEl acceso al proveedor de modelos se creó exclusivamente para el proyecto. Esto permitió comparar alternativas, observar gasto y revocar la integración sin afectar otros agentes.
\nLa elección del modelo se hizo con un conjunto fijo de consultas representativas, puntuando precisión y costo. La comparación se apoyó en tareas reales y no en una impresión general.
\nLas consultas del equipo y las alertas administrativas se trataron como recorridos diferentes. Cada canal recibió sólo la información correspondiente a su rol.
\nLas credenciales permanecieron en el entorno de ejecución. No se copiaron a documentación, prompts ni archivos de contexto compartidos con el agente.
\nLa primera versión se consideró válida cuando pudo demostrar tres comportamientos:
\nCada hito describe una evidencia observable. “El agente está instalado” no cuenta como resultado.
\nEl equipo ganó una vía directa para consultar información y recibir avisos sin depender de una interfaz especializada. La organización, a la vez, conservó el control mediante permisos mínimos, identidades autorizadas y separación de canales.
\n\n\n", "headings": [ { "label": "Contexto anonimizado", "depth": 2, "id": "contexto-anonimizado" }, { "label": "Decisiones tomadas", "depth": 2, "id": "decisiones-tomadas" }, { "label": "Reutilizar infraestructura con un límite inicial", "depth": 3, "id": "reutilizar-infraestructura-con-un-limite-inicial" }, { "label": "Aislar proveedor y consumo", "depth": 3, "id": "aislar-proveedor-y-consumo" }, { "label": "Separar audiencias", "depth": 3, "id": "separar-audiencias" }, { "label": "Mantener secretos fuera del contexto", "depth": 3, "id": "mantener-secretos-fuera-del-contexto" }, { "label": "MVP verificable", "depth": 2, "id": "mvp-verificable" }, { "label": "Qué aprendimos", "depth": 2, "id": "que-aprendimos" }, { "label": "Beneficio obtenido", "depth": 2, "id": "beneficio-obtenido" } ], "raw": "---\nslug: caso-hermes-operaciones\ntitle: Caso real — Hermes como interfaz operativa\ntype: case-study\norder: 3\nsummary: Un agente autoalojado acercó consultas y alertas a canales cotidianos, con permisos acotados y pruebas de negocio observables.\ntags: [hermes, agentes, canales, operaciones, caso-real]\nrelated: [hermes-agente-operativo, hermes-preset-instalacion]\narea: Hermes\nglyph: ◈\nhue: rgba(87,217,232,.22)\n---\n\n# Caso real — Hermes como interfaz operativa\n\n## Contexto anonimizado\n\nUna empresa de servicios necesitaba acercar información operativa a un equipo no técnico y transformar eventos pasivos en avisos accionables. El objetivo no era sumar otro chat con IA, sino reducir la dependencia de una persona que supiera consultar cada sistema.\n\nHermes se planteó como una capa conversacional conectada a herramientas internas, disponible desde canales que el equipo ya utilizaba.\n\n## Decisiones tomadas\n\n### Reutilizar infraestructura con un límite inicial\n\nLa primera versión se instaló en infraestructura existente. Para evitar que el nuevo servicio compitiera sin control con otras cargas, se definió una concurrencia conservadora y se postergó cualquier ampliación hasta contar con métricas reales.\n\n### Aislar proveedor y consumo\n\nEl acceso al proveedor de modelos se creó exclusivamente para el proyecto. Esto permitió comparar alternativas, observar gasto y revocar la integración sin afectar otros agentes.\n\nLa elección del modelo se hizo con un conjunto fijo de consultas representativas, puntuando precisión y costo. La comparación se apoyó en tareas reales y no en una impresión general.\n\n### Separar audiencias\n\nLas consultas del equipo y las alertas administrativas se trataron como recorridos diferentes. Cada canal recibió sólo la información correspondiente a su rol.\n\n### Mantener secretos fuera del contexto\n\nLas credenciales permanecieron en el entorno de ejecución. No se copiaron a documentación, prompts ni archivos de contexto compartidos con el agente.\n\n## MVP verificable\n\nLa primera versión se consideró válida cuando pudo demostrar tres comportamientos:\n\n1. Un usuario autorizado formulaba una consulta operativa y recibía una respuesta consistente con el sistema fuente.\n2. Un evento controlado producía una alerta dentro del intervalo esperado.\n3. Una notificación restringida llegaba al canal administrativo, pero no al canal general.\n\nCada hito describe una evidencia observable. “El agente está instalado” no cuenta como resultado.\n\n## Qué aprendimos\n\n- Reutilizar infraestructura funciona cuando la capacidad empieza acotada y se mide.\n- Una credencial por proyecto simplifica costo, auditoría y revocación.\n- El valor aparece en el recorrido completo: canal → agente → herramienta → respuesta.\n- Separar audiencias es tan importante como conectar canales.\n- Un MVP operativo necesita pruebas de negocio, no solamente checks técnicos.\n\n## Beneficio obtenido\n\nEl equipo ganó una vía directa para consultar información y recibir avisos sin depender de una interfaz especializada. La organización, a la vez, conservó el control mediante permisos mínimos, identidades autorizadas y separación de canales.\n\n> Caso basado en una implementación real. Se removieron nombres, infraestructura, métricas y circuitos internos.\n" }, { "slug": "backup-versionado-crm", "title": "Del backup a una plataforma de funciones CRM", "summary": "El backup read-only se convirtió en la base de una plataforma interna para analizar, revisar y desplegar funciones CRM con autoridades separadas.", "type": "concept", "order": 1, "tags": [ "zoho-crm", "backup", "git", "deluge", "auditoria", "despliegue" ], "related": [ "arquitectura-read-only", "mapa-procesos-verificacion", "modelos-guiados-el-entorno-es-la-politica" ], "area": "CRM versionado", "glyph": "▣", "hue": "rgba(237,195,94,.25)", "file": "backup-versionado-crm.md", "html": "Caso basado en una implementación real. Se removieron nombres, infraestructura, métricas y circuitos internos.
\n
\n\nActualizado el 12 de octubre de 2026 con la evolución interna conocida como V2, documentada en el proyecto como etapa de despliegue multiusuario. Las capacidades implementadas y las pruebas pendientes se distinguen abajo.
\n
El código Deluge de las automatizaciones vive dentro de Zoho CRM. La interfaz actual ya ofrece una pestaña Revisions con las últimas 30 versiones; para Deluge, cada guardado crea una revisión. Ese historial acotado no reemplaza un repositorio externo con diffs, análisis y una política propia de conservación. Gestión de funciones.
\nEl punto de partida fue descargar código y metadata de todas las funciones, generar un árbol determinista y crear un commit sólo cuando algo cambiaba realmente. Esa capa sigue siendo de lectura.
\nLa evolución agregó un recorrido para preparar cambios, revisarlos y publicarlos con una autoridad distinta. El repositorio pasó a funcionar como una pequeña plataforma interna de gestión de funciones: CLI, contratos, controles de Git y una vía explícita de despliegue. La CLI y la revisión en GitHub organizan quién puede proponer, quién puede publicar y qué evidencia exige cada transición.
\ngit log, diffs y blame sobre funciones antes opacas.Scheduler diario\n → sync Node.js\n → API de Zoho CRM en modo lectura\n → árbol generado y normalizado\n → commit sólo ante cambio\n → repositorio Git privado\n → webhook de resultado\n → alerta únicamente ante problemaLa credencial de sincronización sólo posee ZohoCRM.settings.functions.READ. La restricción vive debajo del código: aunque el proceso intentara actualizar una función, no tendría autoridad para hacerlo.
El snapshot convirtió intuiciones en inventario. La primera auditoría encontró una superficie relevante de funciones expuestas por REST, automatizaciones de prueba todavía activas, funciones sin documentación y credenciales literales dentro del código.
\nLas cifras concretas no son necesarias para reutilizar el método. El aprendizaje importante es que esos riesgos no eran observables desde una revisión casual de la interfaz: aparecieron al descargar, normalizar y clasificar el árbol completo.
\nEl snapshot del caso no verificaba todas las asociaciones, por lo que el reporte sólo podía marcar candidatas, no afirmar que una función estuviera en desuso. La interfaz actual de Zoho sí documenta asociaciones, referencias y dependencias en Glance. Consultarlas agrega evidencia; no demuestra que el cliente de backup las descargue ni descarta invocaciones externas. Gestión de funciones.
\nUn backup que cambia todos los días sin cambios reales es ruido. Para que Git cuente una historia útil:
\napi_name no es único.La CLI implementa creación o actualización de una función Deluge por vez. Para modificar una existente, el recorrido multiusuario parte de una base obtenida de producción. El cambio se prepara fuera del árbol generado, se versiona como propuesta y pasa por revisión antes de que un responsable habilitado lo despliegue.
\nProducción → base del cambio → propuesta en cambios/\n → pull request → revisión del responsable → merge\n → controles previos → despliegue explícito\n → nueva descarga y comparaciónLa separación evita dos errores distintos: editar un backup como si fuera código listo para publicar y entregar permisos productivos a toda persona que necesita analizarlo. Un colaborador puede preparar una propuesta con acceso de lectura; la publicación pertenece a otro rol.
\nEl recorrido normal documentado exige comprobar la identidad de la función, la procedencia del archivo y que producción no haya cambiado desde la base de la propuesta. La descarga posterior permite comparar lo recibido por el CRM con lo enviado, con una comparación exacta o normalizada. No es una prueba de equivalencia semántica. Existen opciones heredadas para trabajar fuera del recorrido normal, por lo que esas garantías dependen de usarlo con su base y controles completos. Cada barrera tiene un costo: mantener metadata, resolver conflictos y rechazar cambios que antes se habrían pegado directamente en la interfaz. Ese costo compra una revisión reproducible.
\nLa documentación interna revisada describe la implementación de esta vía y registra pruebas de sus controles con la escritura deshabilitada. También deja pendiente el primer despliegue real desde el directorio de cambios y la incorporación de colaboradores. Por eso corresponde hablar de una capacidad implementada con validación operativa todavía incompleta, no de un circuito productivo ya probado de punta a punta.
\nLa escritura no es una transacción atómica con rollback automático: si la comparación posterior falla, la herramienta informa el problema y exige inspección. La lectura posterior comprueba contenido; no prueba por sí sola el comportamiento del circuito de negocio, sus asociaciones ni los efectos externos de una función. Esos resultados requieren pruebas específicas y observación después del cambio.
\nTiene sentido cuando varias personas o agentes necesitan analizar y proponer cambios sobre automatizaciones sensibles, mientras la autoridad productiva debe quedar acotada. Un equipo pequeño con cambios excepcionales puede empezar por el backup y la revisión manual: sumar un camino de despliegue antes de definir responsables y verificaciones sólo agrega otra forma de equivocarse.
\nLa condición para avanzar es poder sostener ambas mitades: una fotografía confiable de producción y una publicación explícita que no herede los permisos del análisis. La arquitectura read-only explica esa separación; el mapa de procesos muestra cómo convertir un hallazgo en trabajo verificable.
\nEl backup ya había permitido revisar cambios, auditar riesgos y analizar el estado sin repartir credenciales productivas. La nueva etapa usa esa base para ordenar el trayecto entre un hallazgo y su publicación. El beneficio observado de la lectura se conserva; el cierre completo del despliegue queda sujeto a las pruebas pendientes.
\n", "headings": [ { "label": "El problema", "depth": 2, "id": "el-problema" }, { "label": "Cuatro resultados en una sola corrida", "depth": 2, "id": "cuatro-resultados-en-una-sola-corrida" }, { "label": "La capa de observación", "depth": 2, "id": "la-capa-de-observacion" }, { "label": "Qué volvió visible", "depth": 2, "id": "que-volvio-visible" }, { "label": "La regla de valor", "depth": 2, "id": "la-regla-de-valor" }, { "label": "Del inventario al cambio revisable", "depth": 2, "id": "del-inventario-al-cambio-revisable" }, { "label": "Qué está demostrado y qué queda abierto", "depth": 2, "id": "que-esta-demostrado-y-que-queda-abierto" }, { "label": "Cuándo conviene este diseño", "depth": 2, "id": "cuando-conviene-este-diseno" }, { "label": "Beneficio obtenido", "depth": 2, "id": "beneficio-obtenido" } ], "raw": "---\nslug: backup-versionado-crm\ntitle: Del backup a una plataforma de funciones CRM\ntype: concept\norder: 1\nsummary: El backup read-only se convirtió en la base de una plataforma interna para analizar, revisar y desplegar funciones CRM con autoridades separadas.\ntags: [zoho-crm, backup, git, deluge, auditoria, despliegue]\nrelated: [arquitectura-read-only, mapa-procesos-verificacion, modelos-guiados-el-entorno-es-la-politica]\narea: CRM versionado\nglyph: ▣\nhue: rgba(237,195,94,.25)\n---\n\n# Del backup a una plataforma de funciones CRM\n\n> Actualizado el 12 de octubre de 2026 con la evolución interna conocida como V2, documentada en el proyecto como etapa de despliegue multiusuario. Las capacidades implementadas y las pruebas pendientes se distinguen abajo.\n\n## El problema\n\nEl código Deluge de las automatizaciones vive dentro de Zoho CRM. La interfaz actual ya ofrece una pestaña Revisions con las últimas 30 versiones; para Deluge, cada guardado crea una revisión. Ese historial acotado no reemplaza un repositorio externo con diffs, análisis y una política propia de conservación. [Gestión de funciones](https://www.zoho.com/crm/developer/docs/functions/management.html).\n\nEl punto de partida fue descargar código y metadata de todas las funciones, generar un árbol determinista y crear un commit sólo cuando algo cambiaba realmente. Esa capa sigue siendo de lectura.\n\nLa evolución agregó un recorrido para preparar cambios, revisarlos y publicarlos con una autoridad distinta. El repositorio pasó a funcionar como una pequeña plataforma interna de gestión de funciones: CLI, contratos, controles de Git y una vía explícita de despliegue. La CLI y la revisión en GitHub organizan quién puede proponer, quién puede publicar y qué evidencia exige cada transición.\n\n## Cuatro resultados en una sola corrida\n\n1. **Backup:** código fuente completo fuera del CRM.\n2. **Historial:** `git log`, diffs y blame sobre funciones antes opacas.\n3. **Auditoría:** reportes regenerados que muestran superficie REST, funciones de prueba, higiene y secretos literales.\n4. **Mapa:** agrupación por circuitos de negocio para poder analizar una rama sin recorrer manualmente todo el árbol.\n\n## La capa de observación\n\n```text\nScheduler diario\n → sync Node.js\n → API de Zoho CRM en modo lectura\n → árbol generado y normalizado\n → commit sólo ante cambio\n → repositorio Git privado\n → webhook de resultado\n → alerta únicamente ante problema\n```\n\nLa credencial de sincronización sólo posee `ZohoCRM.settings.functions.READ`. La restricción vive debajo del código: aunque el proceso intentara actualizar una función, no tendría autoridad para hacerlo.\n\n## Qué volvió visible\n\nEl snapshot convirtió intuiciones en inventario. La primera auditoría encontró una superficie relevante de funciones expuestas por REST, automatizaciones de prueba todavía activas, funciones sin documentación y credenciales literales dentro del código.\n\nLas cifras concretas no son necesarias para reutilizar el método. El aprendizaje importante es que esos riesgos no eran observables desde una revisión casual de la interfaz: aparecieron al descargar, normalizar y clasificar el árbol completo.\n\nEl snapshot del caso no verificaba todas las asociaciones, por lo que el reporte sólo podía marcar candidatas, no afirmar que una función estuviera en desuso. La interfaz actual de Zoho sí documenta asociaciones, referencias y dependencias en Glance. Consultarlas agrega evidencia; no demuestra que el cliente de backup las descargue ni descarta invocaciones externas. [Gestión de funciones](https://www.zoho.com/crm/developer/docs/functions/management.html).\n\n## La regla de valor\n\nUn backup que cambia todos los días sin cambios reales es ruido. Para que Git cuente una historia útil:\n\n- el JSON ordena sus claves;\n- los archivos normalizan saltos de línea;\n- los reportes no incluyen timestamps de generación;\n- el prune sólo corre si todas las descargas finalizaron;\n- la categoría forma parte de la ruta porque `api_name` no es único.\n\n## Del inventario al cambio revisable\n\nLa CLI implementa creación o actualización de una función Deluge por vez. Para modificar una existente, el recorrido multiusuario parte de una base obtenida de producción. El cambio se prepara fuera del árbol generado, se versiona como propuesta y pasa por revisión antes de que un responsable habilitado lo despliegue.\n\n```text\nProducción → base del cambio → propuesta en cambios/\n → pull request → revisión del responsable → merge\n → controles previos → despliegue explícito\n → nueva descarga y comparación\n```\n\nLa separación evita dos errores distintos: editar un backup como si fuera código listo para publicar y entregar permisos productivos a toda persona que necesita analizarlo. Un colaborador puede preparar una propuesta con acceso de lectura; la publicación pertenece a otro rol.\n\nEl recorrido normal documentado exige comprobar la identidad de la función, la procedencia del archivo y que producción no haya cambiado desde la base de la propuesta. La descarga posterior permite comparar lo recibido por el CRM con lo enviado, con una comparación exacta o normalizada. No es una prueba de equivalencia semántica. Existen opciones heredadas para trabajar fuera del recorrido normal, por lo que esas garantías dependen de usarlo con su base y controles completos. Cada barrera tiene un costo: mantener metadata, resolver conflictos y rechazar cambios que antes se habrían pegado directamente en la interfaz. Ese costo compra una revisión reproducible.\n\n## Qué está demostrado y qué queda abierto\n\nLa documentación interna revisada describe la implementación de esta vía y registra pruebas de sus controles con la escritura deshabilitada. También deja pendiente el primer despliegue real desde el directorio de cambios y la incorporación de colaboradores. Por eso corresponde hablar de una capacidad implementada con validación operativa todavía incompleta, no de un circuito productivo ya probado de punta a punta.\n\nLa escritura no es una transacción atómica con rollback automático: si la comparación posterior falla, la herramienta informa el problema y exige inspección. La lectura posterior comprueba contenido; no prueba por sí sola el comportamiento del circuito de negocio, sus asociaciones ni los efectos externos de una función. Esos resultados requieren pruebas específicas y observación después del cambio.\n\n## Cuándo conviene este diseño\n\nTiene sentido cuando varias personas o agentes necesitan analizar y proponer cambios sobre automatizaciones sensibles, mientras la autoridad productiva debe quedar acotada. Un equipo pequeño con cambios excepcionales puede empezar por el backup y la revisión manual: sumar un camino de despliegue antes de definir responsables y verificaciones sólo agrega otra forma de equivocarse.\n\nLa condición para avanzar es poder sostener ambas mitades: una fotografía confiable de producción y una publicación explícita que no herede los permisos del análisis. La [arquitectura read-only](/entrada/arquitectura-read-only) explica esa separación; el [mapa de procesos](/entrada/mapa-procesos-verificacion) muestra cómo convertir un hallazgo en trabajo verificable.\n\n## Beneficio obtenido\n\nEl backup ya había permitido revisar cambios, auditar riesgos y analizar el estado sin repartir credenciales productivas. La nueva etapa usa esa base para ordenar el trayecto entre un hallazgo y su publicación. El beneficio observado de la lectura se conserva; el cierre completo del despliegue queda sujeto a las pruebas pendientes.\n" }, { "slug": "arquitectura-read-only", "title": "Read-only como decisión arquitectónica", "summary": "Mantener el backup y el análisis sin autoridad productiva mientras una vía separada permite desplegar cambios revisados y verificables.", "type": "guide", "order": 2, "tags": [ "read-only", "permisos", "zoho", "seguridad", "snapshots" ], "related": [ "backup-versionado-crm", "mapa-procesos-verificacion", "modelos-guiados-el-entorno-es-la-politica" ], "area": "CRM versionado", "glyph": "⌁", "hue": "rgba(87,217,232,.22)", "file": "arquitectura-read-only.md", "html": "\n\nActualizado el 12 de octubre de 2026. La etapa inicial era enteramente read-only; la evolución multiusuario conserva esa frontera para observación y agrega una vía de escritura controlada.
\n
En las funciones Deluge de Zoho CRM, crear o actualizar mediante la API publica el cambio inmediatamente. La API V8 distingue este comportamiento de Java, Node.js y Python, que sí admiten borradores y publicación separada. Un PUT sobre Deluge en producción puede afectar código activo: no hay que generalizar la protección de borradores de otros runtimes. Funciones en V8.
Por eso la lectura no se planteó como una convención del script, sino como una propiedad del sistema. La evolución del proyecto cambia el alcance de esa frase: describe la sincronización y el análisis, mientras el despliegue tiene credenciales, comandos y condiciones propios.
\nEl token de lectura usa solamente ZohoCRM.settings.functions.READ. No posee Create, Update, Publish ni Delete. La credencial rechaza una mutación aunque el código la intente.
El cliente original sólo implementaba lectura. La etapa de despliegue incorpora operaciones mutativas en una vía explícita y deshabilitada por defecto. Ya no sería correcto describir todo el proyecto como exclusivamente GET: lo que debe conservarse es que la tarea de observación carezca de autoridad para publicar.
functions/ representa una fotografía del CRM y no se edita a mano. Las propuestas viven en cambios/, con su base y metadata para revisión. La separación hace visible qué fue observado y qué se quiere cambiar; una sincronización posterior vuelve a reflejar el estado productivo.
El repositorio conserva snapshots y ahora también organiza propuestas mediante pull requests y responsables de revisión. Merge y despliegue son pasos distintos: tener un cambio en Git no equivale a haberlo publicado ni a haber verificado su resultado.
\nEl colaborador trabaja con permisos de lectura. El responsable del despliegue necesita una credencial autorizada por los scopes y el perfil de CRM, además de habilitar expresamente la escritura y pasar controles adicionales. El flag de la CLI evita accidentes; no es por sí solo una frontera de permisos. Una persona autorizada a editar desde la interfaz de CRM todavía puede hacerlo por fuera de esta convención. En el recorrido normal documentado para cambios revisados:
\napi_name que colisiona no autoriza elegir cualquier destino;main alineado con origin/main;La CLI también conserva una opción explícita para archivos fuera de main; si falta la cabecera de base, esa ruta puede continuar con una advertencia y sin protección contra deriva. Por eso no alcanza con que el repositorio contenga los controles: el equipo debe exigir el recorrido revisado y tratar las excepciones como decisiones de mayor riesgo.
Si producción cambió en el medio dentro del recorrido protegido, la propuesta debe volver a revisarse sobre una base vigente. La comparación permite detectar parte de la deriva de código antes de escribir; no constituye un bloqueo atómico frente a cambios concurrentes ni garantiza que datos, conexiones o asociaciones sigan iguales.
\nLa comparación normalizada elimina espacios y paréntesis: puede considerar iguales textos distintos y no es una prueba semántica. Si la verificación posterior falla, se informa el error; no hay rollback automático. La operación puede haber publicado ya, y un fallo de notificación tampoco la deshace.
\nEstos controles complementan la revisión humana. Tampoco convierten Deluge en un runtime con borradores: el riesgo de publicación inmediata sigue siendo relevante. La documentación registra pruebas sin escritura y deja pendiente el primer despliegue real de esta vía; no hay que presentar el guardrail probado como una prueba completa del despliegue.
\napi_name; el nombre solo puede colisionar.El código fuente puede contener credenciales literales. Antes del primer push hay que escanear el árbol y decidir cada hallazgo:
\nUna credencial de proveedor cloud puede ser detectada y revocada automáticamente al subirla. Excluir evita esa rotura, pero crea una deuda explícita: la función deja de tener historia.
\nUna corrida normal sin cambios no crea commit ni manda una notificación. El silencio es saludable sólo si existe un control separado que detecta cuando la señal deja de llegar.
\nEl dead-man's switch vive fuera del scheduler y distingue la última ejecución del último éxito. Debe alertar si cualquiera de esas señales envejece: una sucesión de errores no puede mantener fresca la señal de salud. Si compartiera proceso con el sync, morirían juntos y el silencio sería ambiguo.
\nLa autoridad debe seguir a la tarea: observar con permisos de lectura, proponer en un espacio separado y publicar sólo desde una vía explícita, revisada y verificable.
\n", "headings": [ { "label": "Por qué no alcanza con prometer que no vamos a escribir", "depth": 2, "id": "por-que-no-alcanza-con-prometer-que-no-vamos-a-escribir" }, { "label": "Las barreras", "depth": 2, "id": "las-barreras" }, { "label": "Scope mínimo", "depth": 3, "id": "scope-minimo" }, { "label": "Lectura y escritura separadas", "depth": 3, "id": "lectura-y-escritura-separadas" }, { "label": "Árbol generado", "depth": 3, "id": "arbol-generado" }, { "label": "Git como revisión y procedencia", "depth": 3, "id": "git-como-revision-y-procedencia" }, { "label": "La autoridad para desplegar no se hereda", "depth": 2, "id": "la-autoridad-para-desplegar-no-se-hereda" }, { "label": "Decisiones que evitan backups falsos", "depth": 2, "id": "decisiones-que-evitan-backups-falsos" }, { "label": "El caso incómodo de los secretos", "depth": 2, "id": "el-caso-incomodo-de-los-secretos" }, { "label": "Operación silenciosa, vigilancia activa", "depth": 2, "id": "operacion-silenciosa-vigilancia-activa" }, { "label": "Principio reusable", "depth": 2, "id": "principio-reusable" } ], "raw": "---\nslug: arquitectura-read-only\ntitle: Read-only como decisión arquitectónica\ntype: guide\norder: 2\nsummary: Mantener el backup y el análisis sin autoridad productiva mientras una vía separada permite desplegar cambios revisados y verificables.\ntags: [read-only, permisos, zoho, seguridad, snapshots]\nrelated: [backup-versionado-crm, mapa-procesos-verificacion, modelos-guiados-el-entorno-es-la-politica]\narea: CRM versionado\nglyph: ⌁\nhue: rgba(87,217,232,.22)\n---\n\n# Read-only como decisión arquitectónica\n\n> Actualizado el 12 de octubre de 2026. La etapa inicial era enteramente read-only; la evolución multiusuario conserva esa frontera para observación y agrega una vía de escritura controlada.\n\n## Por qué no alcanza con prometer que no vamos a escribir\n\nEn las funciones Deluge de Zoho CRM, crear o actualizar mediante la API publica el cambio inmediatamente. La API V8 distingue este comportamiento de Java, Node.js y Python, que sí admiten borradores y publicación separada. Un `PUT` sobre Deluge en producción puede afectar código activo: no hay que generalizar la protección de borradores de otros runtimes. [Funciones en V8](https://www.zoho.com/crm/developer/docs/api/v8/whats-new.html).\n\nPor eso la lectura no se planteó como una convención del script, sino como una propiedad del sistema. La evolución del proyecto cambia el alcance de esa frase: describe la sincronización y el análisis, mientras el despliegue tiene credenciales, comandos y condiciones propios.\n\n## Las barreras\n\n### Scope mínimo\n\nEl token de lectura usa solamente `ZohoCRM.settings.functions.READ`. No posee Create, Update, Publish ni Delete. La credencial rechaza una mutación aunque el código la intente.\n\n### Lectura y escritura separadas\n\nEl cliente original sólo implementaba lectura. La etapa de despliegue incorpora operaciones mutativas en una vía explícita y deshabilitada por defecto. Ya no sería correcto describir todo el proyecto como exclusivamente `GET`: lo que debe conservarse es que la tarea de observación carezca de autoridad para publicar.\n\n### Árbol generado\n\n`functions/` representa una fotografía del CRM y no se edita a mano. Las propuestas viven en `cambios/`, con su base y metadata para revisión. La separación hace visible qué fue observado y qué se quiere cambiar; una sincronización posterior vuelve a reflejar el estado productivo.\n\n### Git como revisión y procedencia\n\nEl repositorio conserva snapshots y ahora también organiza propuestas mediante pull requests y responsables de revisión. Merge y despliegue son pasos distintos: tener un cambio en Git no equivale a haberlo publicado ni a haber verificado su resultado.\n\n## La autoridad para desplegar no se hereda\n\nEl colaborador trabaja con permisos de lectura. El responsable del despliegue necesita una credencial autorizada por los scopes y el perfil de CRM, además de habilitar expresamente la escritura y pasar controles adicionales. El flag de la CLI evita accidentes; no es por sí solo una frontera de permisos. Una persona autorizada a editar desde la interfaz de CRM todavía puede hacerlo por fuera de esta convención. En el recorrido normal documentado para cambios revisados:\n\n- la función debe resolverse sin ambigüedad; un `api_name` que colisiona no autoriza elegir cualquier destino;\n- el archivo a publicar debe estar versionado, sin cambios locales y en `main` alineado con `origin/main`;\n- una comparación por hash del código normalizado detecta cambios productivos respecto de la base usada para preparar la propuesta;\n- después de publicar se descarga el código y se compara con el enviado, de forma exacta o normalizada.\n\nLa CLI también conserva una opción explícita para archivos fuera de `main`; si falta la cabecera de base, esa ruta puede continuar con una advertencia y sin protección contra deriva. Por eso no alcanza con que el repositorio contenga los controles: el equipo debe exigir el recorrido revisado y tratar las excepciones como decisiones de mayor riesgo.\n\nSi producción cambió en el medio dentro del recorrido protegido, la propuesta debe volver a revisarse sobre una base vigente. La comparación permite detectar parte de la deriva de código antes de escribir; no constituye un bloqueo atómico frente a cambios concurrentes ni garantiza que datos, conexiones o asociaciones sigan iguales.\n\nLa comparación normalizada elimina espacios y paréntesis: puede considerar iguales textos distintos y no es una prueba semántica. Si la verificación posterior falla, se informa el error; no hay rollback automático. La operación puede haber publicado ya, y un fallo de notificación tampoco la deshace.\n\nEstos controles complementan la revisión humana. Tampoco convierten Deluge en un runtime con borradores: el riesgo de publicación inmediata sigue siendo relevante. La documentación registra pruebas sin escritura y deja pendiente el primer despliegue real de esta vía; no hay que presentar el guardrail probado como una prueba completa del despliegue.\n\n## Decisiones que evitan backups falsos\n\n- La ruta incluye categoría y `api_name`; el nombre solo puede colisionar.\n- La corrida aborta ante una colisión en vez de sobrescribir en silencio.\n- El prune se desactiva si hubo una descarga fallida.\n- Sin snapshot previo legible, el fallback es una descarga completa.\n- Si el conteo esperado no coincide con la paginación, no se guarda una foto parcial.\n\n## El caso incómodo de los secretos\n\nEl código fuente puede contener credenciales literales. Antes del primer push hay que escanear el árbol y decidir cada hallazgo:\n\n1. rotar y retirar la credencial;\n2. versionar en repositorio privado si el riesgo fue aceptado;\n3. excluir temporalmente el archivo y documentar que queda sin backup.\n\nUna credencial de proveedor cloud puede ser detectada y revocada automáticamente al subirla. Excluir evita esa rotura, pero crea una deuda explícita: la función deja de tener historia.\n\n## Operación silenciosa, vigilancia activa\n\nUna corrida normal sin cambios no crea commit ni manda una notificación. El silencio es saludable sólo si existe un control separado que detecta cuando la señal deja de llegar.\n\nEl dead-man's switch vive fuera del scheduler y distingue la última ejecución del último éxito. Debe alertar si cualquiera de esas señales envejece: una sucesión de errores no puede mantener fresca la señal de salud. Si compartiera proceso con el sync, morirían juntos y el silencio sería ambiguo.\n\n## Principio reusable\n\n**La autoridad debe seguir a la tarea: observar con permisos de lectura, proponer en un espacio separado y publicar sólo desde una vía explícita, revisada y verificable.**\n" }, { "slug": "mapa-procesos-verificacion", "title": "Del backup al mapa de procesos", "summary": "El mapa de procesos permite analizar sin acceso productivo; la nueva vía de cambios conecta los hallazgos verificables con revisión y despliegue controlado.", "type": "case-study", "order": 3, "tags": [ "procesos", "auditoria", "agentes", "verificacion", "zoho-crm" ], "related": [ "backup-versionado-crm", "arquitectura-read-only", "orquestacion" ], "area": "CRM versionado", "glyph": "⌘", "hue": "rgba(168,106,255,.24)", "file": "mapa-procesos-verificacion.md", "html": "\n\nActualizado el 12 de octubre de 2026. Se preserva la prueba piloto de análisis y se distingue de la posterior etapa de despliegue multiusuario.
\n
El backup respondía qué código existía. No explicaba cómo se organizaba el negocio, qué funciones componían un circuito ni cómo comprobar que una corrección había sido aplicada.
\nLa segunda etapa agregó tres piezas:
\n| Pieza | \nQué responde | \n
|---|---|
| Diccionario de recursos | \nQué funciones usan cada recurso compartido y cuál es el radio de impacto | \n
| Árbol de procesos | \nQué circuitos existen y qué funciones forman cada rama | \n
| Contrato de análisis | \nCómo debe analizarse una rama y qué evidencia entregar | \n
Los datos que cambian se regeneran con cada sincronización. La organización conceptual se expresa mediante reglas mantenidas por personas.
\nNo se escriben listas manuales de funciones dentro de la documentación: envejecen al día siguiente. Una regla absorbe nuevas funciones y el reporte marca las que no encajan en ninguna rama.
\nEl proceso para una persona o agente es deliberadamente acotado:
\n| Entregable | \nPropósito | \n
|---|---|
manual-operativo.md | \nExplicar el circuito en términos de negocio | \n
mejoras-propuestas.md | \nOrdenar hallazgos por consecuencia, anclados a archivo y línea | \n
validar.sh | \nConvertir cada hallazgo en un chequeo ejecutable | \n
En la prueba original, el agente partía de reportes calculados y no de una búsqueda ciega entre más de mil trescientas funciones. Ese tamaño describe el inventario de entonces, no un conteo actualizado. La ventaja del método es acotar el contexto y hacer repetible el análisis.
\nEl análisis corrige defectos visibles; no rediseña procesos ni propone migraciones amplias. En una plataforma donde publicar es inmediato, un rediseño grande sobre un circuito que mueve dinero requiere otro nivel de gobierno.
\nLa restricción no queda sólo en el prompt: todo hallazgo desarrollado debe poder expresarse como un chequeo automático. Si no se puede verificar, se anota como idea separada y no se presenta como corrección lista.
\nCuando alguien informa que corrigió un hallazgo, no hace falta volver a contratar razonamiento para leer el código. Se ejecuta validar.sh contra el snapshot actual.
La prosa envejece; el chequeo se reevalúa. Esta separación reduce supervisión y evita que el informe se convierta en una verdad congelada.
\nLa nueva etapa agrega continuidad al trabajo: un hallazgo verificable puede convertirse en una propuesta de cambio separada del snapshot, pasar por un pull request y llegar a un responsable con autoridad para desplegar. El mapa ayuda a elegir dónde mirar; el contrato determina qué evidencia entregar; la vía de despliegue gobierna cuándo se permite escribir.
\nSon verificaciones diferentes:
\n| Verificación | \nQué establece | \nQué no establece | \n
|---|---|---|
| Chequeo del hallazgo | \nSi el código satisface una condición concreta | \nQue todo el proceso funcione correctamente | \n
| Comparación con la base productiva | \nSi se detecta deriva bajo la comparación normalizada desde que se preparó la propuesta | \nCambios borrados por la normalización, equivalencia semántica ni estabilidad de dependencias | \n
| Descarga posterior al despliegue | \nSi el código descargado coincide con el enviado bajo la comparación implementada | \nQue sus efectos de negocio sean los esperados | \n
Una corrección de idempotencia, por ejemplo, puede tener un chequeo estático que detecte la condición de protección y aun necesitar una prueba de ejecuciones repetidas para demostrar que no duplica efectos. La presencia de validar.sh mejora la revisión; no autoriza a confundir inspección de código con validación integral.
La documentación de la etapa multiusuario registra controles probados con escritura deshabilitada y mantiene pendiente el primer despliegue real desde cambios/. El circuito completo es la dirección implementada por el proyecto, con esa validación operativa aún abierta. La prueba piloto que sigue demuestra el análisis y sus entregables, no un despliegue posterior.
Una rama sin manual previo fue analizada siguiendo únicamente el contrato. El agente entregó los tres archivos y los hallazgos prioritarios se verificaron contra el código.
\nLa prueba encontró errores de idempotencia, validaciones incompletas y superficie de ejecución externa que requería revisión. Las reglas de anonimización preservan las categorías del problema, pero no publican el circuito, los nombres ni las condiciones exactas del cliente.
\nEl análisis también marcó como no confirmados los puntos que la API no permitía comprobar. Esa disciplina fue parte del éxito, no una limitación a esconder.
\nPara un circuito desconocido, conviene empezar por mapa, contrato y chequeos antes de preparar cambios. Cuando el hallazgo ya tiene evidencia, se puede usar la plataforma de funciones para organizar la propuesta y la separación de autoridades para limitar su publicación. Un rediseño amplio o una condición que el snapshot no permite comprobar necesitan otra investigación; no deben disfrazarse de corrección lista para desplegar.
\nLa capacidad de diagnóstico dejó de depender de quien conoce de memoria la organización. El costo central queda en generar el snapshot y los reportes; cada miembro del equipo puede analizar una rama con su propia herramienta y verificar correcciones sin acceso productivo.
\n", "headings": [ { "label": "El salto de la segunda etapa", "depth": 2, "id": "el-salto-de-la-segunda-etapa" }, { "label": "Generado y curado", "depth": 2, "id": "generado-y-curado" }, { "label": "Unidad de trabajo: una rama", "depth": 2, "id": "unidad-de-trabajo-una-rama" }, { "label": "El límite que sostiene la calidad", "depth": 2, "id": "el-limite-que-sostiene-la-calidad" }, { "label": "Verificación sin IA", "depth": 2, "id": "verificacion-sin-ia" }, { "label": "Del hallazgo a una propuesta desplegable", "depth": 2, "id": "del-hallazgo-a-una-propuesta-desplegable" }, { "label": "Prueba piloto", "depth": 2, "id": "prueba-piloto" }, { "label": "Elegir el siguiente paso", "depth": 2, "id": "elegir-el-siguiente-paso" }, { "label": "Beneficio obtenido", "depth": 2, "id": "beneficio-obtenido" } ], "raw": "---\nslug: mapa-procesos-verificacion\ntitle: Del backup al mapa de procesos\ntype: case-study\norder: 3\nsummary: El mapa de procesos permite analizar sin acceso productivo; la nueva vía de cambios conecta los hallazgos verificables con revisión y despliegue controlado.\ntags: [procesos, auditoria, agentes, verificacion, zoho-crm]\nrelated: [backup-versionado-crm, arquitectura-read-only, orquestacion]\narea: CRM versionado\nglyph: ⌘\nhue: rgba(168,106,255,.24)\n---\n\n# Del backup al mapa de procesos\n\n> Actualizado el 12 de octubre de 2026. Se preserva la prueba piloto de análisis y se distingue de la posterior etapa de despliegue multiusuario.\n\n## El salto de la segunda etapa\n\nEl backup respondía qué código existía. No explicaba cómo se organizaba el negocio, qué funciones componían un circuito ni cómo comprobar que una corrección había sido aplicada.\n\nLa segunda etapa agregó tres piezas:\n\n| Pieza | Qué responde |\n| --- | --- |\n| Diccionario de recursos | Qué funciones usan cada recurso compartido y cuál es el radio de impacto |\n| Árbol de procesos | Qué circuitos existen y qué funciones forman cada rama |\n| Contrato de análisis | Cómo debe analizarse una rama y qué evidencia entregar |\n\n## Generado y curado\n\nLos datos que cambian se regeneran con cada sincronización. La organización conceptual se expresa mediante reglas mantenidas por personas.\n\nNo se escriben listas manuales de funciones dentro de la documentación: envejecen al día siguiente. Una regla absorbe nuevas funciones y el reporte marca las que no encajan en ninguna rama.\n\n## Unidad de trabajo: una rama\n\nEl proceso para una persona o agente es deliberadamente acotado:\n\n1. Abrir una copia de trabajo del repositorio.\n2. Elegir una rama del árbol de procesos.\n3. Seguir el contrato de análisis.\n4. Entregar tres artefactos.\n\n| Entregable | Propósito |\n| --- | --- |\n| `manual-operativo.md` | Explicar el circuito en términos de negocio |\n| `mejoras-propuestas.md` | Ordenar hallazgos por consecuencia, anclados a archivo y línea |\n| `validar.sh` | Convertir cada hallazgo en un chequeo ejecutable |\n\nEn la prueba original, el agente partía de reportes calculados y no de una búsqueda ciega entre más de mil trescientas funciones. Ese tamaño describe el inventario de entonces, no un conteo actualizado. La ventaja del método es acotar el contexto y hacer repetible el análisis.\n\n## El límite que sostiene la calidad\n\nEl análisis corrige defectos visibles; no rediseña procesos ni propone migraciones amplias. En una plataforma donde publicar es inmediato, un rediseño grande sobre un circuito que mueve dinero requiere otro nivel de gobierno.\n\nLa restricción no queda sólo en el prompt: **todo hallazgo desarrollado debe poder expresarse como un chequeo automático**. Si no se puede verificar, se anota como idea separada y no se presenta como corrección lista.\n\n## Verificación sin IA\n\nCuando alguien informa que corrigió un hallazgo, no hace falta volver a contratar razonamiento para leer el código. Se ejecuta `validar.sh` contra el snapshot actual.\n\nLa prosa envejece; el chequeo se reevalúa. Esta separación reduce supervisión y evita que el informe se convierta en una verdad congelada.\n\n## Del hallazgo a una propuesta desplegable\n\nLa nueva etapa agrega continuidad al trabajo: un hallazgo verificable puede convertirse en una propuesta de cambio separada del snapshot, pasar por un pull request y llegar a un responsable con autoridad para desplegar. El mapa ayuda a elegir dónde mirar; el contrato determina qué evidencia entregar; la vía de despliegue gobierna cuándo se permite escribir.\n\nSon verificaciones diferentes:\n\n| Verificación | Qué establece | Qué no establece |\n| --- | --- | --- |\n| Chequeo del hallazgo | Si el código satisface una condición concreta | Que todo el proceso funcione correctamente |\n| Comparación con la base productiva | Si se detecta deriva bajo la comparación normalizada desde que se preparó la propuesta | Cambios borrados por la normalización, equivalencia semántica ni estabilidad de dependencias |\n| Descarga posterior al despliegue | Si el código descargado coincide con el enviado bajo la comparación implementada | Que sus efectos de negocio sean los esperados |\n\nUna corrección de idempotencia, por ejemplo, puede tener un chequeo estático que detecte la condición de protección y aun necesitar una prueba de ejecuciones repetidas para demostrar que no duplica efectos. La presencia de `validar.sh` mejora la revisión; no autoriza a confundir inspección de código con validación integral.\n\nLa documentación de la etapa multiusuario registra controles probados con escritura deshabilitada y mantiene pendiente el primer despliegue real desde `cambios/`. El circuito completo es la dirección implementada por el proyecto, con esa validación operativa aún abierta. La prueba piloto que sigue demuestra el análisis y sus entregables, no un despliegue posterior.\n\n## Prueba piloto\n\nUna rama sin manual previo fue analizada siguiendo únicamente el contrato. El agente entregó los tres archivos y los hallazgos prioritarios se verificaron contra el código.\n\nLa prueba encontró errores de idempotencia, validaciones incompletas y superficie de ejecución externa que requería revisión. Las reglas de anonimización preservan las categorías del problema, pero no publican el circuito, los nombres ni las condiciones exactas del cliente.\n\nEl análisis también marcó como no confirmados los puntos que la API no permitía comprobar. Esa disciplina fue parte del éxito, no una limitación a esconder.\n\n## Elegir el siguiente paso\n\nPara un circuito desconocido, conviene empezar por mapa, contrato y chequeos antes de preparar cambios. Cuando el hallazgo ya tiene evidencia, se puede usar la [plataforma de funciones](/entrada/backup-versionado-crm) para organizar la propuesta y la [separación de autoridades](/entrada/arquitectura-read-only) para limitar su publicación. Un rediseño amplio o una condición que el snapshot no permite comprobar necesitan otra investigación; no deben disfrazarse de corrección lista para desplegar.\n\n## Beneficio obtenido\n\nLa capacidad de diagnóstico dejó de depender de quien conoce de memoria la organización. El costo central queda en generar el snapshot y los reportes; cada miembro del equipo puede analizar una rama con su propia herramienta y verificar correcciones sin acceso productivo.\n" }, { "slug": "caso-tablero-continuidad-operativa", "title": "Caso real — De contador a tablero de continuidad operativa", "summary": "Una herramienta personal creció hasta unir incidentes, salud de servicios y señales progresivas sin llevar credenciales al navegador.", "type": "case-study", "order": 1, "tags": [ "caso-real", "observabilidad", "astro", "typescript", "n8n", "incidentes", "seguridad" ], "related": [ "continuidad-y-observabilidad", "caso-orca-cockpit-multiagente" ], "area": "Casos de producto", "glyph": "◌", "hue": "rgba(87,217,232,.22)", "file": "caso-tablero-continuidad-operativa.md", "html": "La primera necesidad parecía mínima: mostrar cuánto tiempo había pasado desde el último incidente. Pero un número aislado no explicaba qué había ocurrido, si el problema seguía abierto ni qué parte del entorno estaba afectada.
\nEl producto terminó convirtiéndose en una pequeña central operativa: continuidad, bitácora de incidentes, métricas y salud de varios servicios en una sola superficie.
\n| Capa | \nTecnología | \nResponsabilidad | \n
|---|---|---|
| Interfaz | \nAstro + Tailwind CSS | \nSitio estático rápido, responsive y fácil de desplegar | \n
| Dominio | \nTypeScript | \nCálculo de continuidad, estados, normalización y fusión de señales | \n
| Respaldo local | \nlocalStorage | \nConservar acciones cuando la capa remota no responde | \n
| Integración | \nn8n | \nPersistencia de incidentes y ejecución de comprobaciones | \n
| Persistencia | \nData Tables | \nSincronización del historial entre dispositivos | \n
| Entrega | \nHosting estático con políticas de seguridad | \nPublicación del frontend sin secretos embebidos | \n
La decisión central fue mantener el navegador como consumidor de un contrato acotado. Los accesos autenticados y las credenciales quedaron del lado de la capa de integración, que sólo publicaba estados normalizados.
\nUn incidente no es solamente una fecha de reinicio. Tiene inicio real, momento de reporte, estado, cierre y una nota opcional de resolución.
\nModelarlo de esa manera resolvió casos que el contador simple escondía:
\nLa interfaz pasó de celebrar un número a representar honestamente el estado operativo.
\nLas comprobaciones se dividieron por grupos y el frontend las solicitó en paralelo. Cada respuesta parcial se fusiona con el estado existente sin borrar servicios que esa rama no observó.
\nEsto permitió que una caída conocida apareciera apenas se detectaba, aun cuando otras fuentes siguieran demoradas. También exigió reglas explícitas para evitar carreras, datos viejos y estados transitorios engañosos.
\nNo toda respuesta HTTP exitosa prueba que el servicio esté sano. Un frontend puede devolver su HTML genérico ante una ruta inexistente y producir un falso verde.
\nPor eso el tablero distingue:
\nSeparar liveness de readiness evitó alertar como caída cada reinicio normal. Validar el cuerpo además del código HTTP evitó checks verdes que en realidad no medían nada.
\nEl endurecimiento no quedó para el final:
\nLos workflows también se trataron como código: se verificaron sus nodos, contratos y recorridos para detectar errores de generación, grupos duplicados y respuestas cruzadas.
\nLa observabilidad útil no consiste en sumar checks. Consiste en definir qué prueba cada señal, qué no puede probar y cómo se combinan resultados incompletos sin mentirle al operador.
\nEl contador siguió siendo la imagen central, pero el verdadero producto pasó a ser el modelo de continuidad que había detrás.
\n\n\n", "headings": [ { "label": "El punto de partida", "depth": 2, "id": "el-punto-de-partida" }, { "label": "La arquitectura que lo hizo posible", "depth": 2, "id": "la-arquitectura-que-lo-hizo-posible" }, { "label": "De un timestamp a un ciclo de vida", "depth": 2, "id": "de-un-timestamp-a-un-ciclo-de-vida" }, { "label": "Salud progresiva, no una espera monolítica", "depth": 2, "id": "salud-progresiva-no-una-espera-monolitica" }, { "label": "Semántica antes que color", "depth": 3, "id": "semantica-antes-que-color" }, { "label": "Seguridad y resiliencia como parte del producto", "depth": 2, "id": "seguridad-y-resiliencia-como-parte-del-producto" }, { "label": "Beneficios obtenidos", "depth": 2, "id": "beneficios-obtenidos" }, { "label": "La lección transferible", "depth": 2, "id": "la-leccion-transferible" } ], "raw": "---\nslug: caso-tablero-continuidad-operativa\ntitle: Caso real — De contador a tablero de continuidad operativa\ntype: case-study\norder: 1\nsummary: Una herramienta personal creció hasta unir incidentes, salud de servicios y señales progresivas sin llevar credenciales al navegador.\ntags: [caso-real, observabilidad, astro, typescript, n8n, incidentes, seguridad]\nrelated: [continuidad-y-observabilidad, caso-orca-cockpit-multiagente]\narea: Casos de producto\nglyph: ◌\nhue: rgba(87,217,232,.22)\n---\n\n# Caso real — De contador a tablero de continuidad operativa\n\n## El punto de partida\n\nLa primera necesidad parecía mínima: mostrar cuánto tiempo había pasado desde el último incidente. Pero un número aislado no explicaba qué había ocurrido, si el problema seguía abierto ni qué parte del entorno estaba afectada.\n\nEl producto terminó convirtiéndose en una pequeña central operativa: continuidad, bitácora de incidentes, métricas y salud de varios servicios en una sola superficie.\n\n## La arquitectura que lo hizo posible\n\n| Capa | Tecnología | Responsabilidad |\n|---|---|---|\n| Interfaz | Astro + Tailwind CSS | Sitio estático rápido, responsive y fácil de desplegar |\n| Dominio | TypeScript | Cálculo de continuidad, estados, normalización y fusión de señales |\n| Respaldo local | `localStorage` | Conservar acciones cuando la capa remota no responde |\n| Integración | n8n | Persistencia de incidentes y ejecución de comprobaciones |\n| Persistencia | Data Tables | Sincronización del historial entre dispositivos |\n| Entrega | Hosting estático con políticas de seguridad | Publicación del frontend sin secretos embebidos |\n\nLa decisión central fue mantener el navegador como consumidor de un contrato acotado. Los accesos autenticados y las credenciales quedaron del lado de la capa de integración, que sólo publicaba estados normalizados.\n\n## De un timestamp a un ciclo de vida\n\nUn incidente no es solamente una fecha de reinicio. Tiene inicio real, momento de reporte, estado, cierre y una nota opcional de resolución.\n\nModelarlo de esa manera resolvió casos que el contador simple escondía:\n\n- una incidencia abierta detiene la continuidad y evita un falso “todo bien”;\n- varias incidencias pueden superponerse;\n- el nuevo período sano comienza después del último cierre efectivo;\n- registros antiguos pueden seguir leyéndose sin reescribir el historial;\n- un corte de conectividad no obliga a perder el alta o el cierre local.\n\nLa interfaz pasó de celebrar un número a representar honestamente el estado operativo.\n\n## Salud progresiva, no una espera monolítica\n\nLas comprobaciones se dividieron por grupos y el frontend las solicitó en paralelo. Cada respuesta parcial se fusiona con el estado existente sin borrar servicios que esa rama no observó.\n\nEsto permitió que una caída conocida apareciera apenas se detectaba, aun cuando otras fuentes siguieran demoradas. También exigió reglas explícitas para evitar carreras, datos viejos y estados transitorios engañosos.\n\n### Semántica antes que color\n\nNo toda respuesta HTTP exitosa prueba que el servicio esté sano. Un frontend puede devolver su HTML genérico ante una ruta inexistente y producir un falso verde.\n\nPor eso el tablero distingue:\n\n- **operativo:** la señal esperada respondió y su contenido es válido;\n- **degradado:** el proceso está vivo, pero todavía no puede atender correctamente;\n- **caído:** existe evidencia concreta de indisponibilidad;\n- **no verificable:** hubo respuesta, pero no demuestra la condición buscada;\n- **sin datos o comprobando:** todavía no existe una lectura suficiente.\n\nSeparar liveness de readiness evitó alertar como caída cada reinicio normal. Validar el cuerpo además del código HTTP evitó checks verdes que en realidad no medían nada.\n\n## Seguridad y resiliencia como parte del producto\n\nEl endurecimiento no quedó para el final:\n\n- el frontend nunca recibe credenciales de proveedores;\n- una política CSP estricta limita la ejecución inesperada;\n- las dependencias se auditan y actualizan;\n- los endpoints aceptados se normalizan y restringen;\n- los estados parciales conservan la última observación válida;\n- las animaciones respetan preferencias de movimiento reducido;\n- el área con scroll puede recorrerse con teclado.\n\nLos workflows también se trataron como código: se verificaron sus nodos, contratos y recorridos para detectar errores de generación, grupos duplicados y respuestas cruzadas.\n\n## Beneficios obtenidos\n\n- una lectura común para continuidad, incidentes y dependencias;\n- detección más temprana gracias a respuestas progresivas;\n- menos falsos positivos y falsos verdes;\n- continuidad de uso ante fallas temporales de la integración;\n- una frontera clara entre visualización pública y acceso autenticado;\n- comportamiento comprobable incluso cuando la automatización vive fuera del repositorio tradicional.\n\n## La lección transferible\n\nLa observabilidad útil no consiste en sumar checks. Consiste en definir qué prueba cada señal, qué no puede probar y cómo se combinan resultados incompletos sin mentirle al operador.\n\nEl contador siguió siendo la imagen central, pero el verdadero producto pasó a ser el modelo de continuidad que había detrás.\n\n> Caso basado en una implementación real. Se removieron nombres, dominios, endpoints, cantidades, proveedores internos y datos operativos identificables.\n" }, { "slug": "caso-widgets-crm-flujos-guiados", "title": "Caso real — Widgets que convierten reglas del CRM en flujos guiados", "summary": "Dos widgets embebidos llevaron contexto, validaciones y automatización al punto exacto donde el equipo tomaba decisiones.", "type": "case-study", "order": 2, "tags": [ "caso-real", "crm", "widgets", "javascript", "deluge", "n8n", "integraciones", "ux" ], "related": [ "backup-versionado-crm", "arquitectura-read-only", "modelos-guiados-el-entorno-es-la-politica" ], "area": "Casos de producto", "glyph": "◆", "hue": "rgba(236,95,189,.24)", "file": "caso-widgets-crm-flujos-guiados.md", "html": "Caso basado en una implementación real. Se removieron nombres, dominios, endpoints, cantidades, proveedores internos y datos operativos identificables.
\n
El CRM concentraba datos y automatizaciones, pero algunas tareas seguían exigiendo conocer demasiadas reglas de memoria: qué opciones eran válidas, qué límites aplicaban, cuándo correspondía una aprobación y cómo reportar un problema sin perder el contexto de origen.
\nLa solución no fue crear otra aplicación separada. Se construyeron widgets embebidos que aparecían dentro del registro y convertían esas reglas en recorridos guiados.
\nEl primer widget reúne configuración del registro, catálogo vigente, medios de pago, cuotas, descuentos, condiciones adicionales y una eventual contraoferta.
\nAntes de permitir una confirmación:
\nLa interfaz hace visible la política mientras la persona decide. No depende de que recuerde una tabla externa ni de que descubra el error después de guardar.
\nEl segundo widget puede abrirse desde distintos módulos. Detecta la entidad y el registro de origen, recupera su contexto y prepara un reporte vinculado desde el comienzo.
\nUn buscador con categorías reemplaza una lista extensa y permite explorar o encontrar un tipo de problema ignorando mayúsculas y tildes. La selección debe provenir del catálogo: escribir texto parecido no alcanza para enviar una clasificación ambigua.
\nTambién contempla adjuntos, estados de carga, errores parciales y módulos que todavía no tienen todos sus campos confirmados. El flujo principal permanece operativo aunque falle información secundaria de diagnóstico.
\n| Pieza | \nFunción | \n
|---|---|
| Widget HTML/CSS/JavaScript | \nInteracción rápida dentro del iframe del CRM | \n
| SDK de widgets | \nContexto de página, lectura del registro, adjuntos y cierre del popup | \n
| Funciones del CRM | \nDatos preparados y reglas cercanas al modelo de negocio | \n
| Webhook | \nContrato explícito de salida | \n
| n8n | \nOrquestación de escrituras y acciones posteriores | \n
| CRM | \nFuente de verdad y trazabilidad final | \n
La frontera fue deliberada: el widget guía, valida y presenta; las funciones recuperan contexto; la automatización coordina la escritura. Ninguna pieza necesita fingir que es todo el sistema.
\nUn límite que sólo existe en documentación llega tarde. Mostrarlo junto al control afectado reduce ensayo, error y consultas laterales.
\nUna etapa incorrecta bloquea el recorrido completo. Una combinación inválida bloquea sólo esa alternativa. Un fallo al adjuntar se informa sin ocultar que el registro principal ya fue creado.
\nCarga, error técnico, contexto no habilitado y flujo normal tienen pantallas separadas. Esto evita interfaces mezcladas donde parece posible confirmar mientras todavía falta información crítica.
\nEl SDK y sus respuestas no siempre llegan con la forma ideal. Se agregaron watchdogs, parseo defensivo, protección contra doble envío y aislamiento de diagnósticos para que una falla secundaria no rompa los controles esenciales.
\nEl reporte nace relacionado con el registro desde el cual se abrió. Eso elimina la búsqueda manual posterior y mejora la calidad de la información que recibe quien resuelve el problema.
\nUn buen widget de CRM no es un formulario más lindo. Es una capa de traducción entre el modelo de datos, la política del negocio y la decisión humana.
\nCuando el control aparece en el punto de trabajo, la prevención deja de depender de capacitación perfecta: el propio entorno conduce hacia una acción válida.
\n\n\n", "headings": [ { "label": "El problema de fondo", "depth": 2, "id": "el-problema-de-fondo" }, { "label": "Dos recorridos, una misma idea", "depth": 2, "id": "dos-recorridos-una-misma-idea" }, { "label": "Selección y confirmación de una propuesta", "depth": 3, "id": "seleccion-y-confirmacion-de-una-propuesta" }, { "label": "Reporte contextual de problemas", "depth": 3, "id": "reporte-contextual-de-problemas" }, { "label": "Arquitectura de integración", "depth": 2, "id": "arquitectura-de-integracion" }, { "label": "Decisiones que dieron resultado", "depth": 2, "id": "decisiones-que-dieron-resultado" }, { "label": "Reglas visibles en el momento correcto", "depth": 3, "id": "reglas-visibles-en-el-momento-correcto" }, { "label": "Bloqueos proporcionales", "depth": 3, "id": "bloqueos-proporcionales" }, { "label": "Estados mutuamente excluyentes", "depth": 3, "id": "estados-mutuamente-excluyentes" }, { "label": "Robustez en un entorno embebido", "depth": 3, "id": "robustez-en-un-entorno-embebido" }, { "label": "Contexto que viaja con la acción", "depth": 3, "id": "contexto-que-viaja-con-la-accion" }, { "label": "Beneficios obtenidos", "depth": 2, "id": "beneficios-obtenidos" }, { "label": "La lección transferible", "depth": 2, "id": "la-leccion-transferible" } ], "raw": "---\nslug: caso-widgets-crm-flujos-guiados\ntitle: Caso real — Widgets que convierten reglas del CRM en flujos guiados\ntype: case-study\norder: 2\nsummary: Dos widgets embebidos llevaron contexto, validaciones y automatización al punto exacto donde el equipo tomaba decisiones.\ntags: [caso-real, crm, widgets, javascript, deluge, n8n, integraciones, ux]\nrelated: [backup-versionado-crm, arquitectura-read-only, modelos-guiados-el-entorno-es-la-politica]\narea: Casos de producto\nglyph: ◆\nhue: rgba(236,95,189,.24)\n---\n\n# Caso real — Widgets que convierten reglas del CRM en flujos guiados\n\n## El problema de fondo\n\nEl CRM concentraba datos y automatizaciones, pero algunas tareas seguían exigiendo conocer demasiadas reglas de memoria: qué opciones eran válidas, qué límites aplicaban, cuándo correspondía una aprobación y cómo reportar un problema sin perder el contexto de origen.\n\nLa solución no fue crear otra aplicación separada. Se construyeron widgets embebidos que aparecían dentro del registro y convertían esas reglas en recorridos guiados.\n\n## Dos recorridos, una misma idea\n\n### Selección y confirmación de una propuesta\n\nEl primer widget reúne configuración del registro, catálogo vigente, medios de pago, cuotas, descuentos, condiciones adicionales y una eventual contraoferta.\n\nAntes de permitir una confirmación:\n\n- verifica que el registro esté en la etapa correcta;\n- filtra las opciones por contexto;\n- calcula importes y cuotas en tiempo real;\n- aplica límites distintos según el tipo de propuesta;\n- deshabilita combinaciones incompatibles y explica el motivo;\n- deriva excepciones al rol aprobador;\n- adjunta documentación cuando corresponde;\n- arma un payload único y evita envíos duplicados.\n\nLa interfaz hace visible la política mientras la persona decide. No depende de que recuerde una tabla externa ni de que descubra el error después de guardar.\n\n### Reporte contextual de problemas\n\nEl segundo widget puede abrirse desde distintos módulos. Detecta la entidad y el registro de origen, recupera su contexto y prepara un reporte vinculado desde el comienzo.\n\nUn buscador con categorías reemplaza una lista extensa y permite explorar o encontrar un tipo de problema ignorando mayúsculas y tildes. La selección debe provenir del catálogo: escribir texto parecido no alcanza para enviar una clasificación ambigua.\n\nTambién contempla adjuntos, estados de carga, errores parciales y módulos que todavía no tienen todos sus campos confirmados. El flujo principal permanece operativo aunque falle información secundaria de diagnóstico.\n\n## Arquitectura de integración\n\n| Pieza | Función |\n|---|---|\n| Widget HTML/CSS/JavaScript | Interacción rápida dentro del iframe del CRM |\n| SDK de widgets | Contexto de página, lectura del registro, adjuntos y cierre del popup |\n| Funciones del CRM | Datos preparados y reglas cercanas al modelo de negocio |\n| Webhook | Contrato explícito de salida |\n| n8n | Orquestación de escrituras y acciones posteriores |\n| CRM | Fuente de verdad y trazabilidad final |\n\nLa frontera fue deliberada: el widget guía, valida y presenta; las funciones recuperan contexto; la automatización coordina la escritura. Ninguna pieza necesita fingir que es todo el sistema.\n\n## Decisiones que dieron resultado\n\n### Reglas visibles en el momento correcto\n\nUn límite que sólo existe en documentación llega tarde. Mostrarlo junto al control afectado reduce ensayo, error y consultas laterales.\n\n### Bloqueos proporcionales\n\nUna etapa incorrecta bloquea el recorrido completo. Una combinación inválida bloquea sólo esa alternativa. Un fallo al adjuntar se informa sin ocultar que el registro principal ya fue creado.\n\n### Estados mutuamente excluyentes\n\nCarga, error técnico, contexto no habilitado y flujo normal tienen pantallas separadas. Esto evita interfaces mezcladas donde parece posible confirmar mientras todavía falta información crítica.\n\n### Robustez en un entorno embebido\n\nEl SDK y sus respuestas no siempre llegan con la forma ideal. Se agregaron watchdogs, parseo defensivo, protección contra doble envío y aislamiento de diagnósticos para que una falla secundaria no rompa los controles esenciales.\n\n### Contexto que viaja con la acción\n\nEl reporte nace relacionado con el registro desde el cual se abrió. Eso elimina la búsqueda manual posterior y mejora la calidad de la información que recibe quien resuelve el problema.\n\n## Beneficios obtenidos\n\n- menos decisiones inválidas antes de escribir en el CRM;\n- políticas comerciales convertidas en feedback inmediato;\n- excepciones encaminadas al aprobador correcto;\n- reportes más consistentes y vinculados a su origen;\n- menor carga cognitiva para el equipo operativo;\n- trazabilidad de extremo a extremo entre interfaz, funciones, automatización y registro final;\n- una base reutilizable para sumar recorridos sin sacar al usuario de su herramienta cotidiana.\n\n## La lección transferible\n\nUn buen widget de CRM no es un formulario más lindo. Es una capa de traducción entre el modelo de datos, la política del negocio y la decisión humana.\n\nCuando el control aparece en el punto de trabajo, la prevención deja de depender de capacitación perfecta: el propio entorno conduce hacia una acción válida.\n\n> Caso basado en dos implementaciones reales. Se removieron nombres, dominios, módulos internos, catálogos, cifras, identificadores y detalles comerciales sensibles.\n" }, { "slug": "caso-jev-director-narrativo", "title": "Caso: un Director que separa narración y memoria", "summary": "Una arquitectura orquestada donde un modelo redacta la escena, Jev decide sus consecuencias y un registro de eventos reconstruye lo que cada personaje puede recordar.", "type": "case-study", "order": 3, "tags": [ "jev", "narrativa", "memoria", "agentes", "eventos", "caso-real" ], "related": [ "jev-decisiones-estructuradas", "orquestacion", "continuidad-y-observabilidad" ], "area": "Casos de producto", "glyph": "◉", "hue": "rgba(236,95,189,.24)", "file": "caso-jev-director-narrativo.md", "html": "Caso basado en dos implementaciones reales. Se removieron nombres, dominios, módulos internos, catálogos, cifras, identificadores y detalles comerciales sensibles.
\n
En una aplicación de ficción interactiva, el modelo generativo podía producir escenas y diálogos. El desafío era conservar las consecuencias: quién descubrió un secreto, qué promesa quedó pendiente, cómo cambió una relación y qué tema seguía abierto.
\nUn chat largo no es una fuente estable para reconstruir todo eso. Repetirle el historial entero al narrador consume contexto y no garantiza que distinga entre un hecho duradero, una interpretación y un gesto cotidiano. La v2 incorporó un Director que observa cada turno y mantiene un estado narrativo separado de la prosa.
\nEl flujo divide responsabilidades:
\nreplay.El Director tiene un núcleo de eventos y reducers sin llamadas al modelo; la parte que consulta a Jev vive separada. Así se puede probar la lógica de estado sin red y revisar de dónde salió cada consecuencia.
\nLos candidatos son pares dirigidos entre el protagonista y los demás personajes presentes. La dirección importa: la confianza de A hacia B puede cambiar aunque la de B hacia A no lo haga. El primer llamado a Jev pregunta, en lote, si hubo un cambio genuino; un segundo llamado evalúa dimensión, dirección y magnitud sólo para los candidatos seleccionados.
\nLas pruebas mostraron que un gesto agradable podía recibir demasiado peso si se miraba sólo la intensidad del momento. El cálculo incorporó otras dos señales: la probabilidad de que la relación haya cambiado y si alguien aprendió algo nuevo de la otra persona. Un café cotidiano y una revelación dejan huellas distintas.
\nEl código acota el delta máximo por escena e invierte el signo cuando corresponde a tensión: mejorar una relación puede bajar la tensión mientras suben confianza o cercanía. También normaliza correctamente Score antes de aplicar el cambio; el valor crudo representa la escala de criterios definida en la pregunta.
\nPara el estado narrativo, un compilador propone afirmaciones en tercera persona. Jev las clasifica como hecho duradero, tema abierto, promesa o nada. Luego compara candidatos con lo ya registrado y con otros del mismo turno para evitar duplicados semánticos.
\nLa pregunta «¿quién se enteró?» se hace por separado. Que un personaje esté en la escena no implica que oyó una conversación privada o entendió una alusión. Si se entera varios turnos más tarde, se actualiza la lista de quienes conocen el mismo hecho; no se inventa otro hecho igual.
\nLos eventos resultantes alimentan un registro del cual se reconstruye el estado. El resumen que recibe el narrador incluye hechos que conoce alguno de los presentes, relaciones expresadas en palabras y asuntos pendientes. Los recuerdos, además, se filtran por línea de tiempo: no entra un evento futuro ni uno que ocurrió exclusivamente en otra rama. Ese último filtro es una regla de código, no una decisión de Jev.
\nEl Director está implementado en una rama v2 y se calibró con fragmentos de historia anotados a mano. Se hizo además una comparación a ciegas de la respuesta del narrador con y sin el resumen del Director sobre una sesión real: 20 pares; 7 preferencias por la versión con resumen, 5 por la versión sin él y 8 empates. Es evidencia acotada de coherencia; no demuestra una mejora clara de la calidad de escritura.
\nLa atribución de quién sabe qué todavía falla en escenas implícitas; en pruebas manuales un modelo generativo usado como juez resolvió mejor algunos ejemplos. También quedan promesas condicionales sin detectar y una falla de red al consultar Jev todavía puede cortar el turno. La v2 está en evaluación, con trabajo pendiente antes de tratarla como una solución cerrada.
\nLa separación deja un contrato legible: un modelo redacta, otro ayuda a decidir qué consecuencias hubo y el código determina qué queda registrado y qué puede recordarse. Jev aporta decisiones estructuradas donde la pregunta es pequeña y verificable; el Director aporta reglas, trazabilidad y límites temporales.
\nEl valor del caso no está en sumar un modelo al pipeline. Está en poder señalar un turno, una decisión y un evento cuando la historia recuerda algo que no debería, o se olvida de algo que sí pasó.
\n\n\n", "headings": [ { "label": "El problema que apareció después de escribir", "depth": 2, "id": "el-problema-que-aparecio-despues-de-escribir" }, { "label": "La orquestación", "depth": 2, "id": "la-orquestacion" }, { "label": "Relaciones: que un momento pese no significa que cambie todo", "depth": 2, "id": "relaciones-que-un-momento-pese-no-significa-que-cambie-todo" }, { "label": "Hechos: saber algo no es haber estado cerca", "depth": 2, "id": "hechos-saber-algo-no-es-haber-estado-cerca" }, { "label": "Lo que la prueba permite afirmar", "depth": 2, "id": "lo-que-la-prueba-permite-afirmar" }, { "label": "La decisión arquitectónica", "depth": 2, "id": "la-decision-arquitectonica" } ], "raw": "---\nslug: caso-jev-director-narrativo\ntitle: \"Caso: un Director que separa narración y memoria\"\ntype: case-study\norder: 3\nsummary: \"Una arquitectura orquestada donde un modelo redacta la escena, Jev decide sus consecuencias y un registro de eventos reconstruye lo que cada personaje puede recordar.\"\ntags: [jev, narrativa, memoria, agentes, eventos, caso-real]\nrelated: [jev-decisiones-estructuradas, orquestacion, continuidad-y-observabilidad]\narea: Casos de producto\nglyph: ◉\nhue: rgba(236,95,189,.24)\n---\n\n# Caso: un Director que separa narración y memoria\n\n## El problema que apareció después de escribir\n\nEn una aplicación de ficción interactiva, el modelo generativo podía producir escenas y diálogos. El desafío era conservar las consecuencias: quién descubrió un secreto, qué promesa quedó pendiente, cómo cambió una relación y qué tema seguía abierto.\n\nUn chat largo no es una fuente estable para reconstruir todo eso. Repetirle el historial entero al narrador consume contexto y no garantiza que distinga entre un hecho duradero, una interpretación y un gesto cotidiano. La v2 incorporó un **Director** que observa cada turno y mantiene un estado narrativo separado de la prosa.\n\n## La orquestación\n\nEl flujo divide responsabilidades:\n\n1. **Narrador:** escribe la escena y entrega acciones con los personajes identificados.\n2. **Constructor de candidatos:** arma pares de relación a partir de esos identificadores. Un compilador pequeño propone afirmaciones sobre hechos, temas y promesas.\n3. **Jev:** responde preguntas tipadas sobre cambios de relación, categorías narrativas, equivalencia con asuntos registrados y quién se enteró.\n4. **Código de dominio:** transforma decisiones válidas en eventos, limita su efecto y reconstruye el estado mediante `replay`.\n5. **Contexto del siguiente turno:** resume lo relevante para el narrador y recupera sólo recuerdos que corresponden a ese punto de la historia.\n\nEl Director tiene un núcleo de eventos y reducers sin llamadas al modelo; la parte que consulta a Jev vive separada. Así se puede probar la lógica de estado sin red y revisar de dónde salió cada consecuencia.\n\n## Relaciones: que un momento pese no significa que cambie todo\n\nLos candidatos son pares dirigidos entre el protagonista y los demás personajes presentes. La dirección importa: la confianza de A hacia B puede cambiar aunque la de B hacia A no lo haga. El primer llamado a Jev pregunta, en lote, si hubo un cambio genuino; un segundo llamado evalúa dimensión, dirección y magnitud sólo para los candidatos seleccionados.\n\nLas pruebas mostraron que un gesto agradable podía recibir demasiado peso si se miraba sólo la intensidad del momento. El cálculo incorporó otras dos señales: la probabilidad de que la relación haya cambiado y si alguien aprendió algo nuevo de la otra persona. Un café cotidiano y una revelación dejan huellas distintas.\n\nEl código acota el delta máximo por escena e invierte el signo cuando corresponde a tensión: mejorar una relación puede bajar la tensión mientras suben confianza o cercanía. También normaliza correctamente *Score* antes de aplicar el cambio; el valor crudo representa la escala de criterios definida en la pregunta.\n\n## Hechos: saber algo no es haber estado cerca\n\nPara el estado narrativo, un compilador propone afirmaciones en tercera persona. Jev las clasifica como hecho duradero, tema abierto, promesa o nada. Luego compara candidatos con lo ya registrado y con otros del mismo turno para evitar duplicados semánticos.\n\nLa pregunta «¿quién se enteró?» se hace por separado. Que un personaje esté en la escena no implica que oyó una conversación privada o entendió una alusión. Si se entera varios turnos más tarde, se actualiza la lista de quienes conocen **el mismo hecho**; no se inventa otro hecho igual.\n\nLos eventos resultantes alimentan un registro del cual se reconstruye el estado. El resumen que recibe el narrador incluye hechos que conoce alguno de los presentes, relaciones expresadas en palabras y asuntos pendientes. Los recuerdos, además, se filtran por línea de tiempo: no entra un evento futuro ni uno que ocurrió exclusivamente en otra rama. Ese último filtro es una regla de código, no una decisión de Jev.\n\n## Lo que la prueba permite afirmar\n\nEl Director está implementado en una rama v2 y se calibró con fragmentos de historia anotados a mano. Se hizo además una comparación a ciegas de la respuesta del narrador con y sin el resumen del Director sobre una sesión real: **20 pares; 7 preferencias por la versión con resumen, 5 por la versión sin él y 8 empates**. Es evidencia acotada de coherencia; no demuestra una mejora clara de la calidad de escritura.\n\nLa atribución de quién sabe qué todavía falla en escenas implícitas; en pruebas manuales un modelo generativo usado como juez resolvió mejor algunos ejemplos. También quedan promesas condicionales sin detectar y una falla de red al consultar Jev todavía puede cortar el turno. La v2 está en evaluación, con trabajo pendiente antes de tratarla como una solución cerrada.\n\n## La decisión arquitectónica\n\nLa separación deja un contrato legible: **un modelo redacta, otro ayuda a decidir qué consecuencias hubo y el código determina qué queda registrado y qué puede recordarse**. Jev aporta decisiones estructuradas donde la pregunta es pequeña y verificable; el Director aporta reglas, trazabilidad y límites temporales.\n\nEl valor del caso no está en sumar un modelo al pipeline. Está en poder señalar un turno, una decisión y un evento cuando la historia recuerda algo que no debería, o se olvida de algo que sí pasó.\n\n> Caso basado en una v2 funcional en evaluación. Se anonimizaron producto, personajes, sesiones y detalles del repositorio; las cifras corresponden a una prueba comparativa acotada, no a una medición de producción.\n" }, { "slug": "tailscale-entorno-agentes", "title": "Tailscale en un entorno de agentes: portátil, VPS y WSL", "summary": "Un diseño de referencia anonimizado para acceder al host de trabajo, operar una VPS y compartir previews internas sin publicar puertos de administración.", "type": "guide", "order": 10, "tags": [ "tailscale", "orca", "wsl", "vps", "ssh", "agentes" ], "related": [ "tailscale-red-privada-identidad", "tailscale-permisos-grants", "acceso-portatil-orca", "hosts-ssh" ], "area": "Casos de producto", "glyph": "◆", "hue": "rgba(237,195,94,.24)", "file": "tailscale-entorno-agentes.md", "html": "Caso basado en una v2 funcional en evaluación. Se anonimizaron producto, personajes, sesiones y detalles del repositorio; las cifras corresponden a una prueba comparativa acotada, no a una medición de producción.
\n
Un desarrollador trabaja en Windows con WSL 2: ahí viven repositorios, agentes y procesos locales. También administra una VPS y quiere entrar desde una notebook cuando se mueve. El objetivo es conservar una sola estación de trabajo y darle rutas privadas a operaciones puntuales. Este es un diseño de referencia anonimizado, no el registro de una implementación ya verificada.
\nLa guía de acceso portátil a Orca plantea esa continuidad. Acá ampliamos el mapa para incorporar la VPS y las previews de desarrollo.
\n| Desde | \nHacia | \nUso | \nLímite | \n
|---|---|---|---|
| Notebook | \nHost Windows/WSL | \nOrca y SSH | \nSólo la identidad y el puerto autorizados | \n
| Host de trabajo | \nVPS | \nAdministración o API interna | \nSólo los servicios necesarios | \n
| Equipo invitado | \nPreview local | \nRevisión de una interfaz | \nAcceso temporal y restringido | \n
La notebook funciona como cliente; los repos, credenciales de ejecución y ramas siguen en el host. La VPS es otro nodo con identidad propia. Los agentes pueden operar por esas rutas, pero su capacidad de modificar código o producción sigue dependiendo de credenciales, permisos del servicio y aprobaciones del flujo de trabajo.
\nTailscale documenta un conflicto cuando se ejecuta a la vez en Windows y dentro de WSL 2: el tráfico cifrado de WSL sobre el Tailscale del host puede fallar por el tamaño de los paquetes. Para este diseño, el punto de partida es instalar Tailscale en Windows y mantener una sola instancia de red. Si un cliente remoto necesita llegar a sshd dentro de WSL, hay que verificar la ruta Windows → WSL, la dirección y el puerto de escucha, el firewall y el modo de red de WSL vigente; no asumir que la IP de la tailnet del Windows apunta mágicamente al Linux. Tailscale en WSL 2
Antes de cambiar reglas de red, comprobá desde la propia máquina Windows que podés conectar al SSH de WSL. Después comprobalo desde la notebook por la dirección de Tailscale del host. Si una actualización de WSL cambia el enrutamiento, la prueba remota es la que detecta la regresión. La alternativa de ejecutar Tailscale sólo dentro de WSL existe, pero requiere evaluar su ciclo de vida y las consideraciones de MTU que describe la documentación.
\nEn la VPS, Tailscale puede dar una dirección privada estable para SSH o una API interna. Un servidor automatizado debería tener identidad de máquina mediante tag y una forma de autenticación administrada, sin pegar auth keys en repositorios o imágenes. La política puede habilitar host de trabajo → VPS TCP 22 o 443 y dejar fuera la base de datos. La app y SSH siguen validando usuarios, sesiones y acciones. Configurar servidores · Auth keys
\nSi el servicio está en un contenedor, decidí dónde vive Tailscale: en el host con un proxy al contenedor o en un contenedor con estado y autenticación propios. La primera opción reduce identidades que gestionar para pocas apps; la segunda sirve cuando se necesita un ciclo de vida independiente. Ninguna habilita automáticamente acceso a toda la red Docker. Parámetros para Docker
\nTailscale Serve publica un servicio local hacia la tailnet y mantiene las reglas de acceso de la red. Funnel lo expone a Internet: sirve para una demo pública deliberada, con controles de la aplicación y un tiempo de vida claro. Para una revisión interna de un panel o una interfaz, Serve es el punto de partida. Revisá el comando y sus requisitos en la documentación vigente antes de activarlo, porque su sintaxis cambió con el tiempo. Serve · Funnel
\nEl resultado es concreto: movilidad sin clones paralelos, VPS administrable por ruta privada y previews que se comparten con alcance explícito. La red conecta las piezas; la autorización de cada servicio y la continuidad operativa siguen en manos del equipo.
\n", "headings": [ { "label": "El escenario", "depth": 2, "id": "el-escenario" }, { "label": "Mapa de conexiones", "depth": 2, "id": "mapa-de-conexiones" }, { "label": "La decisión incómoda de WSL 2", "depth": 2, "id": "la-decision-incomoda-de-wsl-2" }, { "label": "Administrar la VPS sin confundir red con autoridad", "depth": 2, "id": "administrar-la-vps-sin-confundir-red-con-autoridad" }, { "label": "Previews: Serve y Funnel hacen trabajos distintos", "depth": 2, "id": "previews-serve-y-funnel-hacen-trabajos-distintos" }, { "label": "Un preflight que cabe en una tarde", "depth": 2, "id": "un-preflight-que-cabe-en-una-tarde" } ], "raw": "---\nslug: tailscale-entorno-agentes\ntitle: \"Tailscale en un entorno de agentes: portátil, VPS y WSL\"\ntype: guide\norder: 10\nsummary: \"Un diseño de referencia anonimizado para acceder al host de trabajo, operar una VPS y compartir previews internas sin publicar puertos de administración.\"\ntags: [tailscale, orca, wsl, vps, ssh, agentes]\nrelated: [tailscale-red-privada-identidad, tailscale-permisos-grants, acceso-portatil-orca, hosts-ssh]\narea: Casos de producto\nglyph: ◆\nhue: rgba(237,195,94,.24)\n---\n\n# Tailscale en un entorno de agentes: portátil, VPS y WSL\n\n## El escenario\n\nUn desarrollador trabaja en Windows con WSL 2: ahí viven repositorios, agentes y procesos locales. También administra una VPS y quiere entrar desde una notebook cuando se mueve. El objetivo es conservar **una sola estación de trabajo** y darle rutas privadas a operaciones puntuales. Este es un diseño de referencia anonimizado, no el registro de una implementación ya verificada.\n\nLa [guía de acceso portátil a Orca](/entrada/acceso-portatil-orca) plantea esa continuidad. Acá ampliamos el mapa para incorporar la VPS y las previews de desarrollo.\n\n## Mapa de conexiones\n\n| Desde | Hacia | Uso | Límite |\n| --- | --- | --- | --- |\n| Notebook | Host Windows/WSL | Orca y SSH | Sólo la identidad y el puerto autorizados |\n| Host de trabajo | VPS | Administración o API interna | Sólo los servicios necesarios |\n| Equipo invitado | Preview local | Revisión de una interfaz | Acceso temporal y restringido |\n\nLa notebook funciona como cliente; los repos, credenciales de ejecución y ramas siguen en el host. La VPS es otro nodo con identidad propia. Los agentes pueden operar por esas rutas, pero su capacidad de modificar código o producción sigue dependiendo de credenciales, permisos del servicio y aprobaciones del flujo de trabajo.\n\n## La decisión incómoda de WSL 2\n\nTailscale documenta un conflicto cuando se ejecuta **a la vez en Windows y dentro de WSL 2**: el tráfico cifrado de WSL sobre el Tailscale del host puede fallar por el tamaño de los paquetes. Para este diseño, el punto de partida es instalar Tailscale **en Windows** y mantener una sola instancia de red. Si un cliente remoto necesita llegar a `sshd` dentro de WSL, hay que verificar la ruta Windows → WSL, la dirección y el puerto de escucha, el firewall y el modo de red de WSL vigente; no asumir que la IP de la tailnet del Windows apunta mágicamente al Linux. [Tailscale en WSL 2](https://tailscale.com/docs/install/windows/wsl2)\n\nAntes de cambiar reglas de red, comprobá desde la propia máquina Windows que podés conectar al SSH de WSL. Después comprobalo desde la notebook por la dirección de Tailscale del host. Si una actualización de WSL cambia el enrutamiento, la prueba remota es la que detecta la regresión. La alternativa de ejecutar Tailscale *sólo* dentro de WSL existe, pero requiere evaluar su ciclo de vida y las consideraciones de MTU que describe la documentación.\n\n## Administrar la VPS sin confundir red con autoridad\n\nEn la VPS, Tailscale puede dar una dirección privada estable para SSH o una API interna. Un servidor automatizado debería tener identidad de máquina mediante tag y una forma de autenticación administrada, sin pegar auth keys en repositorios o imágenes. La política puede habilitar host de trabajo → VPS TCP 22 o 443 y dejar fuera la base de datos. La app y SSH siguen validando usuarios, sesiones y acciones. [Configurar servidores](https://tailscale.com/docs/how-to/set-up-servers) · [Auth keys](https://tailscale.com/docs/features/access-control/auth-keys)\n\nSi el servicio está en un contenedor, decidí dónde vive Tailscale: en el host con un proxy al contenedor o en un contenedor con estado y autenticación propios. La primera opción reduce identidades que gestionar para pocas apps; la segunda sirve cuando se necesita un ciclo de vida independiente. Ninguna habilita automáticamente acceso a toda la red Docker. [Parámetros para Docker](https://tailscale.com/docs/features/containers/docker/docker-params)\n\n## Previews: Serve y Funnel hacen trabajos distintos\n\n**Tailscale Serve** publica un servicio local hacia la tailnet y mantiene las reglas de acceso de la red. **Funnel** lo expone a Internet: sirve para una demo pública deliberada, con controles de la aplicación y un tiempo de vida claro. Para una revisión interna de un panel o una interfaz, Serve es el punto de partida. Revisá el comando y sus requisitos en la documentación vigente antes de activarlo, porque su sintaxis cambió con el tiempo. [Serve](https://tailscale.com/docs/features/tailscale-serve) · [Funnel](https://tailscale.com/docs/features/tailscale-funnel)\n\n## Un preflight que cabe en una tarde\n\n1. Elegí el host que será el nodo de Tailscale en la máquina Windows/WSL; verificá que SSH de WSL sea accesible desde Windows.\n2. Registrá notebook, host y VPS con identidades distinguibles; asigná tags a servidores, no a personas.\n3. Definí una [política mínima por origen, destino y puerto](/entrada/tailscale-permisos-grants) y revisá que no quede una regla amplia anterior.\n4. Probá notebook → host y host → VPS con el protocolo real. Probá también una conexión que debe fallar hacia un servicio **encendido**.\n5. Reiniciá WSL o el host y repetí las pruebas. Si el host está apagado, ningún túnel conserva el entorno de agentes disponible.\n\nEl resultado es concreto: movilidad sin clones paralelos, VPS administrable por ruta privada y previews que se comparten con alcance explícito. La red conecta las piezas; la autorización de cada servicio y la continuidad operativa siguen en manos del equipo.\n" } ] }