[🤖] Aunque haya coordinador, necesito dirigir yo mismo cada sesión

✨ Resumen de GPT-5.6 Sol

Al intentar repartir un trabajo de folleto entre varias sesiones, temí que el coordinador se limitara a recibir informes y acabara perdiendo el contexto. Este es el registro de cómo hice revisar el Skill para poder dirigir personalmente todas las sesiones sin perder el estado de coordinación.

Por qué no podía confiar en el coordinador

Hoy me encargaron en el trabajo la creación de un folleto. Como nunca había hecho uno, pensé que sería útil contar con un coordinador que leyera el material, dividiera las tareas y coordinara varias sesiones de Codex. Quería que leyera todos los chats del proyecto actual y dijera a cada sesión qué debía hacer.

Pero nada más dar la orden empecé a preocuparme.

¿No acabará como antes, recibiendo informes sin parar hasta perder el contexto y empezar a decir tonterías?

No era una desconfianza vaga. Ya había separado el coordinador de los workers y sufrido cómo los informes terminaban desbordando la conversación del coordinador. Por eso había reconstruido el Skill custom-coordinate-parallel-workers alrededor de informes en archivos y checkpoints. Entonces también comprobé la herramienta local de estados, pero no llegué a operar todo el flujo hasta el final con varias sesiones reales de Codex.

Esta vez sí tenía un trabajo real: el folleto. Sin embargo, justo cuando iba a volver a asignar el papel de coordinador, pensé que acumular bien los informes en archivos no resolvía por sí solo el problema. Mientras el coordinador lee informes y reparte trabajo, yo no soy alguien que se queda quieto mirando. Seguiré abriendo las distintas sesiones, corregiré en el acto una dirección equivocada, aportaré más material cuando haga falta y también cambiaré prioridades.

Para que un coordinador funcione de verdad, el estado de coordinación tenía que resistir incluso cuando yo interviniera directamente en otras sesiones.

Seguiré dando órdenes en las demás sesiones

La primera versión actualizada del Skill todavía se parecía a una estructura en la que yo daba órdenes al coordinador y observaba cómo las demás sesiones ejecutaban sus instrucciones. Volví a decirlo de inmediato.

También tengo que poder dar toda clase de órdenes en esas sesiones.

Yo no quería una estructura en la que el coordinador monopolizara toda la autoridad para dar instrucciones. Basta con que gestione el objetivo general, la propiedad del trabajo, las dependencias y el orden de integración. Pero quien mira el resultado concreto en cada sesión de trabajo y decide sigo siendo yo. Si le digo a un worker que cambie un texto o un resultado dentro del alcance actual, debe aplicarlo de inmediato. En cambio, si la instrucción toca archivos de otra sesión, un contrato compartido, un despliegue o estado externo, no puede ampliar el alcance por su cuenta. Debe conservar el resultado que pedí y detenerse para que el coordinador vuelva a organizar el trabajo.

Con ese criterio ordené revisar una vez más custom-coordinate-parallel-workers. Incluso si daba una instrucción adicional después de terminar el trabajo, ya no podía quedar aplastada en un resumen de 256 caracteres. Había que registrar por separado el resultado que quería, lo que debía preservarse, los archivos afectados, los efectos externos y la sesión donde apareció la instrucción original. Aunque el coordinador perdiera la memoria de la conversación, debía poder recuperar mi instrucción desde los archivos.

También impedí que el coordinador cerrara una solicitud de cambio limitándose a escribir «aceptada». Una solicitud no puede darse por terminada hasta quedar vinculada a un informe nuevo con el cambio real o a una nueva assignment. Como la mera existencia de un vínculo tampoco demuestra que el contenido sea correcto, dejé además un paso que obliga al coordinador a comparar el resultado solicitado y las condiciones de preservación con el diff real.

Lo importante no era que hubiera más archivos de estado. Era impedir que una instrucción desapareciera cuando yo hablara directamente con cualquier sesión y, a la vez, evitar que rompiera en silencio la propiedad general.

No uní el coordinador con la sesión de auditoría

Durante la revisión también pensé si custom-coordinate-parallel-workers no cumplía en la práctica el mismo papel que el Graph Engineering Gate Skill que había creado el día anterior. En aquel momento se llamaba custom-graph-engineering-gate. Ambos trataban varias sesiones y estados de review, así que unirlos sonaba razonable.

Esta vez no los uní de inmediato. Hice que custom-deliberate revisara críticamente la idea. La conclusión fue mantenerlos separados.

custom-coordinate-parallel-workers es control de ejecución: gestiona propiedad de archivos entre sesiones de trabajo, instrucciones del usuario, informes, Git index, orden de integración y efectos externos. En cambio, el Skill de auditoría inspecciona en una sesión aparte y sin el contexto anterior un resultado ya integrado y congelado. Cuando el coordinador revisa informes decide si el trabajo puede integrarse. Eso es una review de integración, no el veredicto de un auditor independiente.

Unir ambos podría añadir automáticamente una sesión de auditoría a todo trabajo paralelo. También podría hacer que una review normal del coordinador pareciera una auditoría independiente. Por eso los mantuve separados y solo dejé explícito el límite entre ellos. La sesión de auditoría independiente debe abrirse únicamente cuando un resultado la necesite de verdad, después de que el coordinador lo haya congelado.

Decidí no confundir una estructura más grande con una estructura más segura. Los papeles necesarios deben conectarse, pero no fusionarse fingiendo que son el mismo papel.

La instrucción de transición que entregué al coordinador

No me limité a formular principios. Escribí y entregué al coordinador una larga instrucción de transición: primero debía reconstruir los archivos actuales y las sesiones existentes, clasificar los conflictos y solo después emitir assignments. Allí puse de una vez que no debía borrar cambios existentes sin cuidado, que tenía que preservar las instrucciones dadas directamente por el usuario en cada sesión, que cada worker solo podía modificar sus rutas y que la integración y el trabajo con Git correspondían únicamente al coordinador.

El original contenía detalles capaces de identificar el trabajo y los materiales reales, así que no lo publiqué tal cual. Adjunto solo una copia pública en la que el nombre de la empresa, el ámbito de actividad, los nombres de clientes y materiales de casos, los servicios concretos y las rutas locales personales se sustituyeron por expresiones generales.

Ver la instrucción pública y redactada de transición al coordinador

Diré que es suficiente después del trabajo real

Las transiciones de estado, la propiedad de archivos, las dependencias, la congelación, las instrucciones adicionales del usuario y la recuperación de archivos de estado antiguos quedaron cubiertas por comprobaciones automáticas. Durante la revisión crítica también se encontró y cerró una brecha que permitía cerrar una solicitud aceptada sin vincularla a un resultado nuevo.

Aun así, volví a preguntar.

¿Se ha mejorado lo suficiente?

La respuesta fue que era suficiente para iniciar un pilot controlado, pero no para afirmar que se había demostrado en varias sesiones reales de Codex. Esta conversación era una side session, por lo que no podía abrir workers reales y comprobar a la vez la entrega de notificaciones, la intervención del usuario y la recuperación del coordinador. Que una máquina de estados local pase no es la misma evidencia que ver al coordinador interpretar e integrar correctamente mis instrucciones durante un trabajo largo.

Así que decidí no imaginar y añadir más reglas aquí. En la sesión del coordinador repartiré de verdad el trabajo del folleto, observaré personalmente cada sesión y también daré instrucciones intermedias. Veré hasta el final si el coordinador pierde mis instrucciones, invade la propiedad de otra sesión o puede recuperar el objetivo original y la siguiente acción aunque se acumulen informes. Si el resultado llega hoy, continuaré escribiendo hoy; si llega mañana, podré continuar mañana.

Después de terminar el artículo, también volví a mirar el nombre del Skill de auditoría. El nombre anterior, custom-graph-engineering-gate, explicaba el concepto del que había partido, pero no mostraba en absoluto qué hacía realmente el Skill.

Lo que hago de verdad es detener el resultado de un trabajo y abrir una sesión de auditoría aparte. Por eso cambié el nombre actual a custom-open-audit-session. El nombre antiguo queda en el registro de aquel momento, pero este es ahora el único nombre que debe invocarse.

No hace falta aplazar también la conclusión del artículo. Hoy no decidí confiar en el coordinador. Dejé claro el requisito de que la estructura no puede derrumbarse aunque yo intervenga directamente en todas las sesiones y, en vez de decir que ya era suficiente, dejé pendiente un E2E para comprobarlo en trabajo real.

Si esta estructura merece confianza no lo decidirán las explicaciones ni el número de tests, sino el trabajo real del folleto que yo mismo observaré.