A thread compartilhada

Uma thread durável, com os participantes se revezando nela. O que é um turno, quem fala a seguir, o que um participante pode dizer a você sem parar a execução e onde a thread fica.

Um turno por vez #

Uma execução é uma conversa numa thread compartilhada. Os participantes se revezam nela, um por vez, cada um com seu próprio provedor, modelo e esforço. Um turno termina no primeiro post do participante. Um segundo post no mesmo turno é rejeitado e nunca chega à thread.

O participante tem duas ferramentas para a thread: read_thread, que lê posts, e post, que é a sua jogada. Só o que ele posta está na thread. O raciocínio e as chamadas de ferramenta dele não estão.

O que o participante vê #

Um turno abre com um índice, não com a thread inteira. Ele lista os posts novos para aquele participante, no máximo os últimos 8, uma linha cada, cortada em 90 caracteres. Os posts mais antigos viram uma contagem e a chamada read_thread que os recupera. Um participante que precisa do texto completo o busca e gasta a própria cota para isso.

As suas mensagens são a exceção: chegam inteiras, até 4000 caracteres, e um corte avisa que houve corte. O prompt de um turno não cresce com a conversa.

As jogadas #

Um post tem um kind, e os tipos são uma lista fechada de seis. Um post também pode levar um handoff, que diz quem deve falar a seguir. É uma proposta: quem decide é o agendador.

Jogada	O que afirma	O que o AutoDev faz com ela
`say`	Conversa.	Nada além da thread. Com `handoff: "user"`, passa o turno para você, e a execução para em `awaiting_user` até você responder.
`work_done`	O repositório mudou.	O AutoDev credita a partir do repositório: um commit ou, na falta dele, arquivos deixados alterados. Sem nenhum dos dois, não é creditado.
`handoff`	O turno passa adiante.	O próximo a falar é escolhido como descrito abaixo.
`wait`	Algo fora da thread precisa acontecer antes.	A execução espera e reverifica. O autor volta a falar antes do revezamento. Uma mensagem sua encerra a espera mais cedo.
`gate`	Uma ação irreversível precisa de uma resposta.	Os padrões de `gateAutoDeny` a negam, e os de `gateAutoApprove` a aprovam. Sem correspondência, `gateMode` decide: `auto` aprova, e `gated` para a execução em `gated` até Approve ou Deny.
`done`	O objetivo está completo.	Uma auditoria sem estado lê o trabalho. Ela aceita, ou reabre a execução com a lacuna que achou.

Um wait é reverificado numa agenda que dobra, até um teto, e uma espera que passa de maxWaitMin pausa a execução. A auditoria depois de um done é limitada por maxAcceptChecks. Todas as chaves de configuração lista as duas.

Quem fala a seguir #

O agendador não faz nenhuma chamada de modelo. Ele lê o fim da thread e aplica estas regras, em ordem:

Uma mensagem sua vai para o participante que fez a pergunta a você ou, com um gate aberto, para o que o declarou.
Quatro posts na sequência A, B, A, B, sem nenhum work_done entre eles, passam o turno a um terceiro participante, o que está calado há mais tempo.
Um handoff para si mesmo é recusado, a menos que o seu último post tenha sido work_done. O turno vai para quem está calado há mais tempo entre os outros.
Um handoff que nomeia um participante dá o turno a ele. Um nome que não está na equipe é ignorado, com um aviso.
Depois de um wait, o autor volta a falar.
Caso contrário, o turno vai para quem está calado há mais tempo, exceto o último a falar, a menos que o último post tenha sido work_done. Antes de qualquer um ter falado, é o primeiro participante por nome.

Uma equipe de um só sempre fala. Uma mensagem sua é escopo novo: ela zera a contagem de turnos sem trabalho verificado e a contagem de auditorias.

Quando os participantes ficam uma sequência de turnos sem trabalho verificado, a ferramenta post aceita só work_done, um say para você ou, de um participante que não escreve, um handoff para um que escreve. Se isso também não produzir nada, a execução pausa para revisão, e A execução parou e por quê lista a mensagem. O tamanho dessa sequência é maxTalkTurns.

Um turno que termina sem nenhum post não é uma jogada. Um participante que termina três turnos seguidos assim não consegue falar, e a execução pausa e o nomeia.

Avisar sem parar #

Um say com handoff: "user" para a execução até você responder. Um participante que pode continuar trabalhando tem um jeito mais leve de falar com você, o tell_user. Ele não é uma jogada: não termina o turno, e o participante ainda posta uma depois. Um participante pode levantar um aviso por turno.

Um aviso espera por você em Needs you, com o nome do participante, e uma nota do system na thread diz o que ele contou. Você responde no painel ou com autodev answer. A resposta chega a esse participante em um turno posterior, e chega curta: 300 caracteres do aviso e 300 da sua resposta.

Um aviso também pode reter uma capacidade até você responder. A que um participante pode reter são as ferramentas de navegador. Uma mensagem sua solta todas as retenções, a menos que você tenha apertado Hold naquele aviso. Aí só o Release solta, e autodev notice faz o mesmo pelo terminal.

Onde a thread fica #

A thread é o thread.jsonl, um objeto JSON por post, acrescentado pelo AutoDev e nunca reescrito:

thread.jsonl

{"seq":<n>,"from":"<participant>","kind":"say","text":"...","handoff":null,"ts":"<iso time>"}

from é um participante ou um dos três nomes que o AutoDev guarda para si: user para você, system para as notas de gate e os avisos, e audit para a auditoria de conclusão. seq só cresce, e cada participante tem um cursor nele, então um turno é informado do que é novo para ele.

O arquivo fica em ~/.autodev/<project>-<hash>/, no lado da máquina da divisão. Os arquivos que você lê e edita ficam em .autodev/, no repositório. O events.jsonl é um log separado da atividade da máquina. É dele que o Feed do painel é montado, e cada post é copiado para lá com o seu texto. Uma mensagem sua, do painel ou com autodev send, espera numa caixa de entrada, e o daemon a acrescenta à thread como um post de user na próxima fronteira de turno.

O daemon faz o trabalho e o painel lê o que ele escreveu. Participantes e lanes trata de quem está na thread, e Provedores e failover trata do que um limite de uso faz com um turno.