BK-64 - Progresso Contínuo e Controles Reais de Parada (AbortController)

Objetivo Funcional

Implementar execução contínua com progresso inline e dois controles de parada reais via AbortController: por sessão e global (pânico). A solução visa interromper efetivamente as chamadas LLM em voo, em vez de depender apenas de polling entre ciclos, garantindo uma resposta imediata e uma interface de usuário clara no Studio.

Contrato WebSocket

Stop Session (studio_chat_stop_session)

• Request:

```json

{

"type": "studio_chat_stop_session",

"sessionKey": "string",

"requestId": "string (opcional)"

}

```

• Response (studio_chat_stop_session_ok):

```json

{

"type": "studio_chat_stop_session_ok",

"ok": true,

"sessionKey": "string",

"abortedCount": "number",

"activeCount": "number",

"timestamp": "number",

"requestId": "string (ou null se não passado)",

"error": "string (opcional em caso de erro)"

}

```

Panic (studio_chat_panic)

• Request:

```json

{

"type": "studio_chat_panic",

"requestId": "string (opcional)"

}

```

• Response (studio_chat_panic_ok):

```json

{

"type": "studio_chat_panic_ok",

"ok": true,

"abortedCount": "number",

"activeCount": "number",

"timestamp": "number",

"requestId": "string (ou null se não passado)",

"error": "string (opcional em caso de erro)"

}

```

Result Payload de Abort (no studio_chat_result)

Quando uma execução é abortada, a payload do result de erro trará um campo abortReason:

• session_stop:

```json

{

"ok": false,

"error": "Execução interrompida por Parar Sessão.",

"abortReason": "session_stop"

}

```

• panic_stop:

```json

{

"ok": false,

"error": "Execução interrompida por Pânico.",

"abortReason": "panic_stop"

}

```

• timeout:

```json

{

"ok": false,

"error": "Timeout da execução atingido.",

"abortReason": "timeout"

}

```

Diagrama de Fluxo

```

Request de Execução (Studio -> Kernel)

|-> Kernel recebe o request

|-> Kernel registra a execução no ExecutionRegistry (register -> AbortController)

|-> Kernel inicia a execução e passa o signal do AbortController para o LLM

[Fluxo Normal]

|-> Execução finaliza com sucesso ou falha natural

|-> Kernel remove o registro (unregister)

|-> Retorna studio_chat_result

[Fluxo Abort (Parar Sessão)]

|-> Studio envia studio_chat_stop_session com sessionKey

|-> Kernel busca o ExecutionRegistry por sessionKey e chama controller.abort(reason)

|-> Fetch/LLM lança AbortError no try/catch

|-> Kernel captura o AbortError, identifica o reason ('session_stop')

|-> Kernel chama unregister e responde studio_chat_result com falha e reason

|-> Studio visualiza o card amarelo de abort

[Fluxo Panic]

|-> Studio envia studio_chat_panic

|-> Kernel chama ExecutionRegistry.abortAll('panic_stop')

|-> Todos os controllers disparam abort(reason)

|-> Todas as requisições ativas lançam AbortError e falham com 'panic_stop'

|-> Kernel chama unregister de cada um

|-> Studio visualiza o card vermelho de pânico

```

Limites Conhecidos Documentados

1. Requisições em andamento por ferramentas que não recebem AbortSignal diretamente não serão interrompidas instantaneamente, mas a Promise do LLM falhará.
2. A dual-write (JSONL) não é afetada.
3. Se o frontend desconectar antes do result, o backend abortará o registro correspondente (opcional se desejado no futuro, mas o controle de parada é manual ou por timeout).