feat(hook): o host roteia todo comando por codemode, e avisa quando a rajada devia ter sido script

[SouzaRodrigo61]

Por que

codemode exec ja se anunciava como "the path a host's shell tool should call", mas
faltava o verbo que fala o protocolo do host. Quem queria isso instalava rtk hook claude
-- um segundo binario no PreToolUse, embrulhando por fora o mesmo rtk que ja roda dentro
deste desde a 0.2.0.

E faltava o outro lado: o codemode run colapsa N chamadas em uma, mas so quando o modelo
escolhe escrever o script -- e ele descobre a terceira chamada uma de cada vez, cada uma
parecendo "so mais uma verificacao". Medido numa sessao real: 76 Bash, zero script.

O que entra

codemode hook claude -- le o JSON da chamada na stdin e devolve o comando reescrito
como codemode exec -- '<cmd>', em um argumento (argv-de-um e linha de shell no
exec_one, e e isso que preserva pipe, && e redirect). Num spawn so: filtro do rtk,
denylist, corte de saida e telemetria -- que ate agora so via script, nunca comando solto.

--wrap <prefixo> -- um host aceita UMA reescrita por chamada. Dois hooks que respondem
updatedInput nao se compoem: o ultimo apaga o outro, e qual e o ultimo e sorteio (medido:
metade do trafego ia por um roteador, metade pelo outro). --wrap encadeia dentro de uma
resposta so: <wrap> codemode exec -- '<cmd>'. O embrulhado fica por fora e recebe a saida
ja filtrada; o codemode continua vendo o comando original, entao o roteamento e o verbo da
telemetria seguem certos. O codemode nao sabe o que e o programa embrulhado, de proposito.

--post -- conta a rajada por sessao (estado em ~/.codemode/bursts/, verbo e
workdir, nunca a linha) e injeta uma linha de contexto ao passar de 5 comandos no mesmo
diretorio em 180s. Teto de 3 por sessao, rajada zerada a cada aviso, silencio total quando
o modelo roda codemode run. E pergunta, nao acusacao: o hook nao sabe se a serializacao
era legitima.

Duas correcoes, uma delas de coisa quebrada

• run_in_background passa cru. O exec so devolve a saida no fim e mataria em
  --cmd-timeout: servidor de dev e tail -f nunca responderiam.
• Builtin de estado sozinho passa cru (cd, export, source, set, trap...).
  Rodar num filho e no-op silencioso -- o host le pwd no shell pai depois do comando.
  cd /x && cargo test continua reescrito, porque ali o cd vale pro comando que vem junto.
• Telemetria grava o verbo, nao a linha. Com a linha inteira chegando num argumento so,
  cmd.first() passou a gravar caminho, header e token no runs.jsonl.

Como testar

cargo test --bin codemode hook::          # 16 testes do modulo
echo '{"tool_name":"Bash","tool_input":{"command":"git status"},"cwd":"/tmp"}' | codemode hook claude

No settings.json do Claude Code:

{ "hooks": {
  "PreToolUse":  [{ "matcher": "Bash", "hooks": [{ "type": "command",
     "command": "'/abs/path/codemode' hook claude" }] }],
  "PostToolUse": [{ "matcher": "Bash", "hooks": [{ "type": "command",
     "command": "'/abs/path/codemode' hook claude --post" }] }]
} }

Caminho absoluto importa: sessao spawnada com PATH minimo perde o hook calada.

Evidencia viva

Numa sessao real, o aviso saiu sozinho na quinta chamada, com os verbos extraidos atraves
do embrulho:

codemode: 5 comandos em 28s no mesmo diretorio (ls x2, echo, python3, for). Se os proximos dois ja estao decididos, isso e um script e nao N chamadas -- codemode list antes.

Custo medido: hook 0-10ms, contra ~822ms de round-trip por tool-call.

O que fica torto

• Linha que comeca com palavra-chave de shell (for i in ...; do) reporta for como verbo.
  Cosmetico; consertar exige interpretar keyword de shell.
• 5/180s/3 sao desenho, nao medida. Em uma semana o codemode gain diz se a razao
  exec vs run mexeu. Se nao mexer, o hook e ruido e sai.

Co-authored com Claude Code.

🤖 Generated with Claude Code