lab
Esc

Prueba con

↑↓ para moverte · Enter para abrir · también en /buscar?q= para agentes

sistema avanzado codexelixirorquestacionincidencias

Symphony: inicia trabajo de Codex desde un gestor de incidencias

Asigna incidencias a ejecuciones de Codex en espacios separados y observa su avance mediante un servicio coordinador.

✓ verificado el 26 oct 2026

Instrucciones para tu agente

Esto es lo que se copia. Pégaselo a tu agente y te lo monta paso a paso.

O ábrelo directamente en ClaudeChatGPT

Pega este texto a tu agente (Claude Code, Codex, OpenCode, Hermes o el que uses) y dile «ayúdame a montarlo». Son los pasos para ponerlo en marcha; el porqué de cada pieza está en la guía completa.


Para el agente: cómo acompañar al usuario

  1. Pregunta primero para qué lo quiere. Si su objetivo no necesita algún paso, sáltalo.
  2. Antes de instalar, comprueba lo que ya tiene (versiones, claves, sistema operativo).
  3. Avanza un paso cada vez: explica en una frase qué vas a hacer y deja que el usuario lo ejecute o lo apruebe.
  4. Tras cada paso, comprueba que funcionó antes de seguir. Si falla, para y explica el error.
  5. No inventes comandos ni opciones: si la documentación del proyecto contradice estos pasos, manda la documentación.
  6. Al terminar, haz una prueba real con el objetivo del usuario y dile dónde profundizar.

Pasos de configuración

Paso 1: prepara la referencia

Comprueba que Git, mise y Codex están disponibles y que Codex puede acceder a su modelo. Lee elixir/mise.toml: esta revisión fija Erlang 28 y Elixir 1.19.5-otp-28. Los comandos oficiales para preparar el código son:

git clone https://github.com/openai/symphony
cd symphony/elixir
mise trust
mise install
mise exec -- mix setup
mise exec -- mix build

Paso 2: adapta el flujo de trabajo

La referencia incluida contiene el proyecto y procedimientos de los autores; no la arranques tal cual. Crea WORKFLOW.prueba.md en symphony/elixir con esta adaptación del ejemplo mínimo del README:

---
tracker:
  kind: linear
  provider:
    api_key: $LINEAR_API_KEY
    project_slug: "SLUG_DE_TU_PROYECTO_DE_PRUEBA"
  required_labels: ["ensayo-symphony"]
  active_states: ["Todo"]
  terminal_states: ["Done", "Canceled", "Cancelled"]
workspace:
  root: ~/code/symphony-prueba
hooks:
  after_create: |
    git clone --depth 1 "$SOURCE_REPO_URL" .
agent:
  max_concurrent_agents: 1
  max_turns: 1
codex:
  command: codex app-server
---
Lee el README y resume el propósito del repositorio. No modifiques archivos
ni el gestor de incidencias. Incluye los archivos que has consultado.
Incidencia: {{ issue.identifier }} — {{ issue.title }}

Sustituye el slug por el del proyecto de ensayo y carga LINEAR_API_KEY y SOURCE_REPO_URL (URL de un repositorio público de prueba) desde el entorno del servicio antes de arrancar. Crea una única incidencia Todo con la etiqueta ensayo-symphony. Mantén las políticas limitadas predeterminadas descritas en el README. Después:

mise exec -- ./bin/symphony ./WORKFLOW.prueba.md

Comprobación

Usa una incidencia de prueba y confirma el espacio de trabajo asignado, la ejecución de Codex y sus evidencias. El agente de esta prueba no cambia la incidencia de estado: detén el servicio con Ctrl+C tras revisar el resultado para evitar reintentos sobre la misma tarea. El bloqueo y la recuperación necesitan una prueba posterior propia antes de dejarlo sin supervisión.

Si algo falla

Si no arranca, revisa YAML, entorno de ejecución y acceso al gestor. Si una tarea espera aprobación, consulta su estado bloqueado; reiniciar el servicio no conserva ese mapa en memoria.

ver en .md ¿Prefieres el recurso entero?

Qué es

Symphony es una especificación y una implementación experimental de coordinación de trabajo para agentes. La referencia en Elixir consulta un gestor de incidencias y abre ejecuciones de Codex para los trabajos elegibles.

Para qué te sirve

  • Cuando quieres estudiar cómo convertir una incidencia en un espacio de ejecución independiente.
  • Cuando necesitas observar agentes que trabajan sobre tareas de un gestor existente.
  • Cuando diseñas reintentos, concurrencia y estados de bloqueo para un servicio coordinador.

Cómo funciona

El servicio consulta el gestor configurado, crea un espacio de trabajo por incidencia y lanza Codex en modo App Server. WORKFLOW.md combina configuración con las instrucciones que recibirá el agente. La referencia actual incluye varios adaptadores de gestores; el ejemplo inicial se centra en Linear.

Esta ficha documenta la carpeta elixir, no todas las posibles implementaciones de la especificación. Sus hooks y políticas determinan qué puede hacer cada ejecución y cómo prepara el proyecto.

Antes de empezar

Necesitas Codex operativo, Git, acceso al gestor y mise para preparar Erlang 28 y Elixir 1.19.5-otp-28, fijados en elixir/mise.toml. Revisa el flujo de trabajo antes de arrancar: sus ejemplos pueden incluir acciones sobre incidencias y repositorios. Usa un proyecto de pruebas.

Límites y alternativas

Los autores presentan la referencia como prototipo para evaluación. El mapa de bloqueos descrito en su README es volátil y se pierde al reiniciar; una incidencia activa puede volver a ser candidata. Una implementación de producción debe revisar autorización, recuperación e idempotencia según sus requisitos.

Recursos