Quando a tarefa precisa de workflow próprio

A execução padrão do Kadu roda a skill num runner com Node, jq e Python. Uma tarefa que depende de ferramenta que o runner não traz, de IP de saída conhecido ou de um runner próprio precisa de um workflow do GitHub Actions no próprio repositório.

O caso da Kobana é o workspace security: o security-scan.yml instala a suíte de pentest, agenda o scan semanal e o mensal e roda num runner com IP de saída fixo. O modelo para copiar é o wh-run-skill.yml do mesmo repositório: checkout do Playbook, instalação do Claude Code, um stub dos helpers em /tmp/agent_state.sh, claude -p "/<plugin>:<skill>" --plugin-dir e set +e em volta do pipeline.

Dois caminhos de execução

A tarefa passa a ter dois caminhos, e o que muda entre eles não aparece em lugar nenhum se não for escrito:

	Disparo pelo Kadu	Workflow próprio
Runner	o do Kadu, sem as ferramentas	o do workflow, com as ferramentas instaladas
Variáveis	só o que está em required_secrets	só o que o bloco env: do passo mapeia de secrets.*/vars.*
Instrumentação	o console de verdade	o stub, que só ecoa no log do run
Arquivos de saída	$OUTPUT_FILES_DIR, publicado pelo Kadu	upload-artifact do próprio workflow

Duas consequências:

• Toda variável de configuração entra nos dois lugares: em required_secrets, para o Kadu, e no env: do workflow, para a agenda. Esquecer um lado faz a configuração valer num caminho e cair no padrão no outro.
• Ferramenta ausente vira pendência, e não erro. O disparo pelo console chega sem as ferramentas: a skill registra o que faltou e segue. Quem precisa da execução completa é o workflow.

Workflow que gera tráfego nasce fechado

Um workflow que gera tráfego contra terceiros ou contra produção nasce fail-closed: sem a variável de autorização (vars.SECURITY_SCAN_AUTORIZADO=true, no caso da Kobana), o job termina verde com um ::notice e não faz nada. Um cron vermelho toda semana por configuração faltando vira ruído que ninguém lê.