CL-2026-04-11 - Hotfix BK-170: side opinion timeout no Squad Social
- Escopo:
cerebro-kernel - Projetos afetados:
cerebro,rionoteatro - Aprovacao humana obrigatoria:
nao - Revisor IA:
auto-revisao
Contexto
No tab-squad do Rio no Teatro, uma run real do rnt-social-v1 estava morrendo no step copy com feedback = timeout, mesmo já tendo produzido o artefato principal do copy.
Diagnostico
O store do Squad mostrou:
- run
run_1775902297413_zn79t6 state = canceledabortReason = timeoutcurrent_step_key = copy
Na mesma run:
researchconcluiucopyficoufailed- o artefato principal de
copyfoi salvo normalmente payload.sideOpinionsdo artefato já trazia:engine = opencodestatus = failederror = timeout
Leitura técnica:
- a geração principal do copy não era o gargalo
- a side opinion do
opencodecontinuava bloqueando o step - quando ela excedia o orçamento restante, o runtime abortava a run inteira
Mudanca aplicada
Arquivo alterado:
kernel/index.js
Hotfix:
- introduzido
STUDIO_SQUAD_SIDE_OPINION_TIMEOUT_MS - default operacional:
30000 - side opinions do step
copyagora passam porwithTimeout(...) - se a opinião lateral estourar esse tempo:
- ela falha como metadado auxiliar
- não deve mais monopolizar o timeout global da run
Kimi
O engine kimi já estava suportado no runtime e no Studio. A rodada revalidou a operação local com:
```bash
printf 'Responda apenas KIMI_OK\n' | /root/cerebro/tools/kimi --timeout 30
```
Resultado:
KIMI_OK
Conclusão:
kimi(NVIDIA/Kimi 2.5) já pode ser usado como side opinion no lugar doopencode- a troca operacional no RNT pode ser feita sem mudança estrutural do kernel
Validacao
node --check /root/cerebro/kernel/index.js- teste local do wrapper
tools/kimi - inspeção do SQLite:
studio_squad_runsstudio_squad_stepsstudio_squad_artifacts
Risco residual
- o hotfix isola a opinião lateral, mas não muda a configuração persistida do RNT
- se o admin continuar com
sideOpinions = opencode, a opinião extra ainda pode falhar por timeout - o resultado esperado agora é degradação graciosa, não cancelamento da run principal