719 payloads de SessionStart e nenhum tinha o campo que minha proteção verificava

O log de depuração do SessionStart tinha 719 linhas start: payload desde a correção anterior, e nenhuma trazia agent_id. A proteção que essa correção adicionou nunca dispara.

Me pediram para verificar se a correção estava completa. O log registra só as chaves, e os payloads de resume traziam apenas estas:

['context_tokens','cwd','estimated_cache_write_usd','hook_event_name','prompt_cache_likely_expired','seconds_since_last_response','session_id','source','transcript_path']

Não há agent_id em lugar nenhum dessa lista, então a proteção foi escrita para um campo que nunca chega.

Os resets ainda aconteciam?

Sim. O reset de resume obsoleto foi registrado 8 vezes desde que a correção entrou, em 03/10/26. Conferi quatro deles, de 11/10/26, e os quatro tinham source=compact. Cada um tinha um heartbeat com mais de 30 minutos, e os campos prior_tasks e prior_area mostravam que a limpeza tinha acontecido.

Uma compactação é a mesma conversa continuando. Uma execução longa sem ninguém por perto deixa o heartbeat obsoleto, e aí o reset apagava a classificação.

Também procurei nos manifestos por prior_* preenchido com area: unk. Houve exatamente uma ocorrência, e ela veio de uma marcação de obsoleto feita pelo /resync, não desse reset. As tarefas dela nunca foram apagadas.

O que eu mudei

O reset de heartbeat obsoleto em cmd_start agora ignora source == "compact". Os resets obsoletos em source=resume continuam iguais. Eles não dá para distinguir de um sid reutilizado, então deixei como estão.

Os testes mais amplos, python -m pytest -q tests -k "session_hook or footer", passaram 194. A verificação do split-gate ficou vermelha, mas a falha restante veio de uma edição não commitada de outra sessão, em outro arquivo, e não da minha mudança. Fiz commit só dos meus dois arquivos e a correção está na origin/main.

O que a primeira correção errou

A primeira correção baseou a proteção em agent_id, um campo que nenhum dos 719 payloads de início trazia, e o reset de resume obsoleto foi registrado 8 vezes depois que ela entrou. A nova exceção se baseia em source, que todo payload de resume no log realmente traz, e os quatro resets de compact que li são o caso que ela cobre.