Follow-up Autonomy

mandatory

Follow-up executável que NÃO exige decisão do owner = standing yes. A IA não pergunta "quer que eu faça?"; implementa (inline) ou enfileira em ticket e segue. Só sobe ao owner o que é genuinamente dele: decisão (owner-decision), aquisição de ativo (asset-acquisition) ou ação destrutiva/irreversível.

Ratificada pelo owner em 2026-06-25. O default para todo follow-up executável que não exige decisão do owner é "sim, implementa". A IA não encerra um trabalho perguntando se o owner quer os follow-ups — assume que quer.

Regra

Quando concluir (ou avançar) uma tarefa e ela gerar trabalho de continuação ("Restante", "follow-up", "Next action", TODO descoberto no meio), a IA não pede permissão para os follow-ups que são, simultaneamente:

  • executáveis pela IA (não dependem de ativo nem de input externo), e
  • sem decisão de owner (não há bifurcação que só o owner resolve), e
  • não-destrutivos / reversíveis (não caem na regra global de confirmação).

Para esses, o standing answer é YES. A IA:

  1. implementa inline se ainda está no fluxo e cabe na janela; ou
  2. tria em ticket (backlog/pending/, fatiado se for grande — Categoria A da

    Regra 15 do /k-go) e segue — nunca os engaveta num "deixa pra depois" difuso.

A linha Próximo: do fechamento reflete o follow-up que a IA vai fazer ou já enfileirou — nunca uma pergunta de permissão ("quer que eu…?").

O que AINDA sobe ao owner (a autonomia NÃO cobre)

A autonomia é só sobre não pedir permissão pra trabalho executável. Continua indo ao owner, explicitamente e na hora:

Situação Marca Ação
Precisa de decisão que só o owner toma gated_by: owner-decision trazer a decisão à tona agora
Trava até compra de hardware/licença gated_by: asset-acquisition set-aside; perguntar antes de marcar
Destrutivo / irreversível / outward-facing (regra global do CLAUDE.md) confirmar antes
Bloqueado por lock duro de outra sessão (Regra 10 do /k-go) anotar + pular
Owner pediu "pare aqui" / "me pergunta antes" nesse fio — honrar

Por quê

  • Princípio #2 (Quality > Speed) + fase de aceleração: o gargalo é a IA

    esperar um "ok" pra trabalho que já está decidido. Follow-up executável é trabalho já triado — pedir permissão só adiciona latência sem reduzir risco.

  • Alinha qualquer sessão ao que o /k-go já faz dentro do seu fluxo (Modo

    BD + Regra 15): drenar o acionável sem re-perguntar o óbvio (Regra 4 do `k-go`).

  • Mapeia 1:1 na taxonomia da Regra 15 do /k-go: A = implementa;

    B = dirige/oferece evidência; C = set-aside-pergunta; owner-decision = sobe. Esta policy é o enunciado geral (fora do /k-go) do mesmo contrato.

Anti-patterns

Don't:

  • Fechar com "Quer que eu implemente o follow-up X?" quando X é executável e sem

    decisão → é exatamente o que esta policy elimina.

  • Tratar follow-up grande (Categoria A) como "long-running, deixa pra lá" → fatia

    em sub-tickets e segue.

  • Auto-executar algo destrutivo / owner-decision "porque a policy manda fazer

    follow-up" → a policy exclui esses; eles sobem ao owner.

Do:

  • Implementar ou enfileirar o follow-up e reportar o que fez/enfileirou.
  • Subir ao owner só decisão / aquisição de ativo / ação destrutiva.

Origem

Owner, 2026-06-25 (sessão atlas#006 S4 → karavan#017 017b-2): *"como são atividades que devem ser feitas algum dia e não precisam de ação/decisão do owner, … sempre considerar que vou querer que ela os implemente."* Formalizado aqui como default de comportamento fleet-wide.