rewrite: Reimplementar session event streaming em Go (session-event.ts + session-message-updater.ts)

[ElioNeto]

Parte do epic #1036

Depende de: #1042 #1040 #1041 #1043

Objetivo

Reescrever packages/core/src/session-event.ts (9 KB) e packages/core/src/session-message-updater.ts (13 KB) em Go. Esses módulos gerenciam o streaming de eventos da sessão com LLM e são o coração do agent swarm.

Mapeamento Effect-TS → Go

O maior desafio aqui é que o código atual usa Effect fibers e streams (packages/core/src/effect/). O equivalente em Go é:

Effect-TS	Go
Effect.fiber	goroutine
Stream	channel
Effect.cancel	context.WithCancel
Effect.retry	loop com backoff
Layer (dependency injection)	struct com interfaces

Comportamentos a preservar

• Recepção e roteamento de eventos de sessão
• Streaming de tokens LLM para o cliente
• Atualização incremental de mensagens
• Cancelamento de sessão em andamento
• Redução de múltiplos eventos em uma mensagem consolidada
• Persistência de eventos para reconstrução de contexto

Endpoints Go a implementar

POST /session                    ← cria sessão
GET  /session/:id/events         ← SSE com eventos em tempo real
POST /session/:id/message        ← envia mensagem ao LLM
DELETE /session/:id              ← cancela sessão
GET  /session/:id/messages       ← histórico de mensagens

Tarefas

• Mapear todos os tipos de evento de session-event.ts
• Implementar internal/session/event.go
• Implementar internal/session/updater.go com goroutines
• Implementar SSE handler para streaming de tokens
• Implementar cancelamento via context.Context
• Atualizar cliente TS em packages/go-core-client
• Criar testes unitários em Go
• Criar testes de paridade (via harness de rewrite: Criar harness de testes de paridade legado vs nova implementação #1040)
• Ativar feature flag go-core-session e validar

Critérios de aceite

• Todos os testes de paridade passam
• Latência de primeiro token igual ou inferior ao legado TS
• Cancelamento responde em ≤ 500ms
• Agent swarm funciona com múltiplas sessões concorrentes
• Rollback via feature flag funciona sem redeploy

[ElioNeto]

Skipping via delivery-loop pipeline — too complex for automatic resolution.

Esta issue é um enhancement estratégico que requer:

• Decisões de arquitetura e design
• Planejamento humano
• Implementação em Go (nova linguagem)

Needs manual triage and planning by the engineering team.

[ElioNeto]

Análise da implementação — gaps de paridade identificados

✅ O que está correto

• Event Bus com chan bufferizado (64) e publish non-blocking é a escolha certa
• SSE com event: connected + event: heartbeat a cada 10s garante keepalive
• Filtragem por session_id no handler é o modelo correto para isolamento de sessões

⚠️ Gap 1 — Backpressure: push-based vs pull-based

O session-event.ts legado usa Effect Streams (pull-based com backpressure implícito). O Event Bus Go é push-based: quando o buffer de 64 enche, o comportamento atual não está documentado.

Risco: sessões LLM com tokens rápidos + cliente SSE lento (rede ruim, tab em background) podem silenciosamente perder eventos.

Ação recomendada: documentar explicitamente no event.go o comportamento de overflow (drop silencioso ou block) e adicionar métrica/log de eventos descartados.

// Recomendado em bus.go:
select {
case sub.ch <- event:
default:
    // buffer cheio: drop + log
    log.Printf("[eventbus] drop session=%s type=%s buffer_full", event.SessionID, event.Type)
    s.metrics.DroppedEvents.Inc()
}

⚠️ Gap 2 — session-message-updater.ts não foi migrado

O updater (13KB) faz redução stateful de eventos: agrega tokens em mensagem consolidada, gerencia estado de reasoning, tool_call e content. Esse estado é não trivial e não existe equivalente em internal/eventbus/.

O GoCoreClient.session.publish() atual só emite eventos raw — a consolidação ainda acontece no TS. Isso precisa ser explicitado como escopo fora desta issue e rastreado separadamente.

Recomendação: abrir issue rewrite: Migrar session-message-updater para Go com dependência em #1045.

⚠️ Gap 3 — Reconexão do EventSource no cliente TS

GoCoreClient.session.stream() retorna um EventSource nativo. Se o Go server estiver down (restart, deploy), o EventSource reconecta infinitamente sem fallback para o legado TS.

Ação recomendada: adicionar maxRetries no client.ts — após N falhas consecutivas, desativar a feature flag automaticamente e rotear para o TS legado.