[JoaoLuisQuirino]

Fecha #136.

O que muda

Uma segunda tela abre um chat com turno rodando e manda uma mensagem com mode: "queue" antes de o socket dela contar que há turno. A sessão se acha livre e a mensagem vira abertura, esperando o stepStart dela, que só vem quando a fila chegar nela. Enquanto isso, os frames do turno que roda eram lembrados como de turno encerrado, e o stepFinish dele era descartado.

Agora um stepStart que nomeia outra mensagem, com a abertura esperando, quer dizer que há um turno rodando à frente dela. A abertura passa a esperar o turno dela como um steer na fila (strayedSteers, com o waiter), e os frames do turno que roda contam como dele. O turnEnd desse turno sai sem resolver o sendAndWait da mensagem na fila; o stepStart da própria mensagem a reassocia pelo clientMessageId, e remover da fila rejeita só ela. O forgetFinishedTurn continua só para a própria abertura. A outra ordem, vista na dev: o stepStart do turno que roda chega no replay enquanto a mensagem ainda está saindo (abrindo o canal, lendo a base do turno). A sessão já está em streaming quando a mensagem ia virar abertura; agora ela vai atrás desse turno como um steer (sendBehindRunningTurn), sem zerar o conteúdo nem emitir outro turnStart. Mudança em dispatchSend, sendBehindRunningTurn, handleEvent e openingQueuedBehind (src/agentSession.ts).

Mudança de comportamento

• A tela que mandou para a fila com turno rodando passa a emitir o turnEnd desse turno, e o Stop dela é reconhecido. Antes, nenhum turnEnd, e o Stop dava "Agent turn cancellation was not acknowledged before the safety timeout". Visto em produção e reproduzido na dev com a box viva (0.3.3 e 0.3.4).

Release

sdk-core 0.3.5, com o corpus contracts/v0.3.5 (mesmos casos da 0.3.4) e current no manifest. Publicação fica com o Joao.

Testes

npm test: 735 de 735 (16 arquivos). Testes novos em agentChannel.test.ts, sessão aberta por taskId e sendAndWait(x, { mode: "queue" }) pelo canal direto, com a box pondo x na fila atrás do turno de outra mensagem: (1) o turno que roda fecha com turnEnd, a promise de x segue pendente e resolve só com o turno dela; (2) remover x da fila rejeita só ela, e o turno que roda segue até o turnEnd; (3) o stepStart do turno que roda chega antes de x sair: x vai atrás dele, o turno fecha com turnEnd depois de toolCall e textDelta, um turnStart só, e x resolve com o turno dela. Os três falham sem a mudança. typecheck, lint, format:check, build, check:exports, check:contracts e smoke:package verdes.

🤖 Generated with Claude Code

[JoaoLuisQuirino]

/gandalf

[gandalf-the-grey-bot]

Gandalf, análise 1 · commit 931a4861efbb6db7fb63efe7a1eae949e41a3664

Pega-rápido
A issue #136 descreve uma corrida: uma tela põe uma mensagem na fila enquanto outra já está executando, antes de receber o estado do socket. O PR permite que a primeira tela reconheça o fim desse turno; a mesma mudança também pode encerrar cedo demais a espera pela própria mensagem.

Insights
O mérito está aprovado: a corrida é concreta no fluxo do SDK e corrigir a associação de estado no core é melhor do que adicionar espera nos consumidores. O relato de ocorrência em produção e reprodução na dev está documentado, mas não foi confirmado operacionalmente. O risco encontrado é a resposta ser associada ao turno errado; não identifiquei impacto de segurança ou escala.

Forma da implementação
Precisa ajuste na separação entre o turno alheio observado e o waiter da mensagem local enfileirada.

Finding

• major src/agentSession.ts:1651: sendAndWait(..., { mode: "queue" }) pode resolver com o resultado do turno alheio antes de a mensagem local sair da fila. O detalhe e o teste necessário estão no comentário da linha.

Confiança, comentários e testes

• Confiança alta: o fluxo lido guarda o waiter na abertura e finishTurn o resolve sem confirmar que o turno tomou a mensagem.
• O CI do SHA revisado passou: build, test, pr-convention e compatibility (18 e 22), com 733 testes em 16 arquivos (run). O teste novo cobre send, mas não prova que a promise de sendAndWait fica pendente até o turno próprio.

Decisão: não aprovaria até corrigir o finding major e cobrir esse caso no teste.

Aqui o meu check é obrigatório: depois de um push, comente /gandalf para eu revisar o commit novo e liberar o merge.

[gandalf-the-grey-bot]

Gandalf, análise 1 · commit 931a486

Pega-rápido

A issue #136 relata que, numa sessão compartilhada, uma mensagem enviada antes de a segunda tela reconhecer o turno ativo podia perder o encerramento da resposta. O PR mantém o encerramento do turno observado e acrescenta um teste com send.

Insights

O problema é real: a issue documenta reprodução em produção e em dev, e esperar o socket anunciar o turno é apenas um contorno, não uma garantia para a API. Corrigir a sessão compartilhada é proporcional. Mas a mudança também pode soltar a espera da mensagem enfileirada quando termina o turno de outro cliente, quebrando o vínculo entre sendAndWait e a resposta da mensagem.

Forma da implementação

Precisa ajuste. A mudança é localizada e a estrutura é simples. Falta separar o acompanhamento do turno alheio do waiter da mensagem que ainda está na fila.

Findings

• major src/agentSession.ts:1655: sendAndWait de uma mensagem enfileirada pode resolver com o turno de outro cliente antes de a própria mensagem começar. O contrato em README.md:104 e os testes existentes exigem que cada espera resolva com o turno que respondeu àquela mensagem. Separe os estados e cubra a corrida com sendAndWait.

Confiança, comentários e testes

Confiança alta: o caminho da fila até finishTurn foi rastreado e comparado com a base. O CI no head revisado passou: 733 testes em 16 arquivos. A suíte não cobre este caso, porque o teste novo usa send, não sendAndWait.

Decisão

Não aprovaria até o ajuste que preserve a associação entre a mensagem enfileirada e o turno que a responde. Depois da correção, publique o Core antes dos SDKs consumidores: platform-sdk e functions-sdk-js ainda fixam mitra-core-sdk em 0.3.4; coordene também o PR #122, que declara 0.3.5.

Para uma nova análise depois de mudanças, comente /gandalf no PR ou me chame no Slack.
Aqui o meu check é obrigatório: depois de um push, comente /gandalf para eu revisar o commit novo e liberar o merge.

[JoaoLuisQuirino]

/gandalf

[gandalf-the-grey-bot]

Sem finding novo de linha nesta rodada. O ponto anterior foi corrigido; ver o comentário de análise 2 no PR.

[gandalf-the-grey-bot]

Gandalf, análise 2 · commit 00ff5ce7b9b0ae029bf8194867807ec925229fc0

Desde a análise 1: o finding sobre a associação do waiter foi corrigido (fio 1, fio 2); os dois fios estão resolvidos. Nenhum achado segue aberto e não há achado novo. A coordenação de release continua pendente: o PR #122 também declara 0.3.5; alinhe a versão e publique o Core antes dos SDKs consumidores.

Decisão: mergeável; antes da publicação, alinhe o 0.3.5 com o PR #122 e publique o Core antes dos SDKs dependentes.

Aqui o meu check é obrigatório: depois de um push, comente /gandalf para eu revisar o commit novo e liberar o merge.

[JoaoLuisQuirino]

/gandalf

[gandalf-the-grey-bot]

Sem achados novos no delta revisado desde a análise 2.

[gandalf-the-grey-bot]

Gandalf, análise 3 · commit 900cd7b

Desde a análise 2: o delta cobre a ordem inversa da corrida; os dois fios anteriores seguem resolvidos; nenhum achado novo. O CI do commit revisado passou em build, testes, convenção do PR e compatibilidade (18 e 22). A coordenação com o PR #122 segue pendente: ambos declaram 0.3.5.

Decisão: mergeável; alinhe 0.3.5 com o PR #122 antes da publicação e publique o Core antes dos SDKs dependentes.

Aqui o meu check é obrigatório: depois de um push, comente /gandalf para eu revisar o commit novo e liberar o merge.

[JoaoLuisQuirino]

/gandalf

[gandalf-the-grey-bot]

Sem novos achados de linha nesta rodada. Os pontos anteriores seguem resolvidos; o veredito consolidado está no comentário final.

[gandalf-the-grey-bot]

Gandalf, análise 4 · commit 3c252ed

Desde a análise 3: o delta é documental em CHANGELOG.md e contracts/README.md; os pontos anteriores seguem resolvidos e não há achados novos. A coordenação de publicação do 0.3.5 permanece registrada.

Decisão: mergeável no SHA auditado; manter alinhada a publicação do 0.3.5.

Aqui o meu check é obrigatório: depois de um push, comente /gandalf para eu revisar o commit novo e liberar o merge.