El hilo compartido
Un hilo duradero en el que los participantes se turnan. Qué es un turno, quién habla después, qué puede decirte un participante sin detener la ejecución y dónde vive el hilo.
Un turno a la vez #
Una ejecución es una conversación en un hilo compartido. Los participantes se turnan en él, uno a la vez, cada uno con su propio proveedor, modelo y esfuerzo. Un turno termina con la primera publicación del participante. Una segunda publicación en el mismo turno se rechaza y nunca llega al hilo.
El participante tiene dos herramientas para el hilo: read_thread, que lee publicaciones, y post, que es su jugada. Solo lo que publica está en el hilo. Su razonamiento y sus llamadas a herramientas no lo están.
Qué ve el participante #
Un turno se abre con un índice, no con el hilo entero. Lista las publicaciones nuevas para ese participante, como máximo las últimas 8, una línea cada una, cortada a 90 caracteres. Las publicaciones más antiguas se reducen a una cuenta y a la llamada read_thread que las recupera. Un participante que necesita el texto completo lo pide y gasta su propia cuota en hacerlo.
Tus mensajes son la excepción: llegan completos, hasta 4000 caracteres, y un corte lo avisa. El prompt de un turno no crece con la conversación.
Las jugadas #
Una publicación tiene un kind, y los tipos son una lista cerrada de seis. Una publicación también puede llevar un handoff, que nombra quién debe hablar después. Es una propuesta: decide el planificador.
| Jugada | Qué afirma | Qué hace AutoDev con ella |
|---|---|---|
say | Conversación. | Nada más allá del hilo. Con handoff: "user" te pasa el turno a ti, y la ejecución se detiene en awaiting_user hasta que respondas. |
work_done | El repositorio cambió. | AutoDev lo acredita a partir del repositorio: un commit o, si no lo hay, archivos que quedaron modificados. Sin ninguno de los dos, no se acredita. |
handoff | El turno pasa a otro. | El siguiente en hablar se elige como se describe abajo. |
wait | Algo ajeno al hilo tiene que ocurrir antes. | La ejecución espera y vuelve a comprobar. El autor vuelve a hablar antes que la rotación. Un mensaje tuyo acaba la espera antes. |
gate | Una acción irreversible necesita una respuesta. | Los patrones de gateAutoDeny la niegan, y los de gateAutoApprove la aprueban. Sin coincidencia, decide gateMode: auto aprueba, y gated detiene la ejecución en gated hasta Approve o Deny. |
done | El objetivo está completo. | Una auditoría sin estado lee el trabajo. Acepta, o reabre la ejecución con la carencia que encontró. |
Un wait se vuelve a comprobar con una agenda que se duplica, hasta un tope, y una espera que supera maxWaitMin pausa la ejecución. La auditoría tras un done está limitada por maxAcceptChecks. Todas las claves de configuración enumera las dos.
Quién habla después #
El planificador no hace ninguna llamada a un modelo. Lee el final del hilo y aplica estas reglas, en orden:
- Un mensaje tuyo va al participante que te hizo la pregunta o, con un gate abierto, al que lo declaró.
- Cuatro publicaciones en la secuencia A, B, A, B, sin ningún
work_doneentre ellas, pasan el turno a un tercer participante, el que lleva más tiempo callado. - Un
handoffa uno mismo se rechaza, salvo que su última publicación fuerawork_done. El turno va a quien lleve más tiempo callado entre los demás. - Un
handoffque nombra a un participante le da el turno. Un nombre que no está en el equipo se ignora, con una advertencia. - Después de un
wait, su autor vuelve a hablar. - En cualquier otro caso, el turno va a quien lleve más tiempo callado, salvo el último en hablar, a menos que la última publicación fuera
work_done. Antes de que nadie haya hablado, es el primer participante por nombre.
Un equipo de uno siempre habla. Un mensaje tuyo es alcance nuevo: reinicia la cuenta de turnos sin trabajo verificado y la cuenta de auditorías.
Cuando los participantes pasan una racha de turnos sin trabajo verificado, la herramienta post acepta solo work_done, un say dirigido a ti o, de un participante que no escribe, un handoff a uno que sí. Si eso tampoco produce nada, la ejecución se pausa para revisión, y La ejecución se detuvo y por qué enumera el mensaje. La longitud de esa racha es maxTalkTurns.
Un turno que termina sin ninguna publicación no es una jugada. Un participante que termina tres turnos seguidos así no puede hablar, y la ejecución se pausa y lo nombra.
Avisarte sin detener #
Un say con handoff: "user" detiene la ejecución hasta que respondas. Un participante que puede seguir trabajando tiene una forma más ligera de llegar a ti, tell_user. No es una jugada: no termina el turno, y el participante aún publica una después. Un participante puede levantar un aviso por turno.
Un aviso te espera en Needs you, con el nombre del participante, y una nota de system en el hilo dice qué te contó. Lo respondes en el panel o con autodev answer. La respuesta llega a ese participante en un turno posterior, y llega corta: 300 caracteres del aviso y 300 de tu respuesta.
Un aviso también puede retener una capacidad hasta que respondas. La que un participante puede retener son las herramientas de navegador. Un mensaje tuyo suelta todas las retenciones, salvo que hayas pulsado Hold en ese aviso. Entonces solo Release lo suelta, y autodev notice hace lo mismo desde la terminal.
Dónde vive el hilo #
El hilo es thread.jsonl, un objeto JSON por publicación, que AutoDev añade y nunca reescribe:
{"seq":<n>,"from":"<participant>","kind":"say","text":"...","handoff":null,"ts":"<iso time>"}from es un participante o uno de los tres nombres que AutoDev se reserva: user para ti, system para las notas de gate y los avisos, y audit para la auditoría de finalización. seq solo crece, y cada participante tiene un cursor sobre él, así que a un turno se le informa de lo que es nuevo para él.
El archivo está en ~/.autodev/<project>-<hash>/, en el lado de la máquina de la división. Los archivos que lees y editas se quedan en .autodev/, en el repositorio. events.jsonl es un log aparte de la actividad de la máquina. De él se construye el Feed del panel, y cada publicación se copia allí con su texto. Un mensaje tuyo, desde el panel o con autodev send, espera en una bandeja de entrada, y el daemon lo añade al hilo como una publicación de user en el siguiente límite de turno.
El daemon hace el trabajo y el panel lee lo que escribió. Participantes y lanes cubre quién está en el hilo, y Proveedores y failover cubre lo que un límite de uso le hace a un turno.