[JoaoLuisQuirino]

Closes #72.

O que muda para quem atualiza

• Dependência na @mitralab.io/sdk-core@0.3.0 oficial (feat(agent): sdk-core 0.3.0 com a experiencia T3 na sessao (#91) mitra-core-sdk#103).
• A mensagem enviada durante uma resposta vai na hora para a box, com clientMessageId e sem modo por padrão (o T3 decide). send(prompt, { mode: "queue" | "steer" }) escolhe de propósito.
• session.history é a conversa ao vivo, na ordem da box, pedida com kinds=all, com ferramenta como dois itens (igual à 0.2.13), a pergunta com o texto da pessoa e as aprovações e perguntas do agente onde vieram.
• steerQueueItem, resumeQueue e backgroundTasks.
• Corpus SDK-PARITY-001 fixado na 0.3.0, com o digest e o commit do squash da core (ff356e4).

Retrocompatibilidade

• O formato do histórico continua o da 0.2.13.
• Com a box antiga, as funções novas não aparecem.

Testes

src/client.test.ts passa a esperar o clientMessageId no envio, sem mode, e o &kinds=all no histórico. npm run check verde local.

🤖 Generated with Claude Code

[gandalf-the-grey-bot]

Gandalf, análise 1 · commit revisado 1f2137f · há commits mais novos não revisados (bfa0162)

Pega-rápido: a atualização leva ao Functions SDK a sessão de agente do Core 0.3.0, conforme a issue #72. O diff e o manifesto sustentam esse objetivo.

Insights: o mérito se sustenta. Delegar ao Core existente evita duplicar a sessão; não identifiquei no diff um novo risco de segurança ou escala. Qualidade é o ponto que impede a aprovação deste SHA.

Forma: a atualização concentra-se em versão, lockfile, manifesto, verificador e expectativas de cliente, sem churn em src/. A divisão é coerente, com ressalvas de compatibilidade e documentação dos novos recursos.

Finding

• 🔴 Blocking, src/client.test.ts:904-909: o teste exige UUID para clientMessageId, mas o Core 0.3.0 usa m-<timestamp>-<sequência> quando crypto.randomUUID global não está disponível. O job Node 18 falhou nessa asserção. Ajuste o teste para validar presença e envio sem mode, a menos que UUID seja contrato em todos os runtimes suportados.

O CI desse SHA terminou vermelho: build passou, compatibility (18) falhou e compatibility (22) foi cancelado após npm run check passar. Sugestões não bloqueantes: documentar a nova API de sessão no README e decidir se AgentBackgroundTask deve ser reexportado nominalmente pelo src/index.ts.

Confiança: mérito 9/10; sem score global, pois o Sonar não foi verificável e não há base suficiente para pontuar um padrão cross-repo. A análise cobre o SHA indicado, não os commits mais novos.

Decisão: não aprovaria este SHA até corrigir a expectativa incompatível e obter CI verde. Os dois pontos de documentação/tipos são perguntas, não bloqueios demonstrados.

Para uma nova análise depois de mudanças, comente /gandalf no PR ou me chame no Slack.