V1 · DRAFT PARA VALIDAÇÃO

Protocolo do Combinado

Como garantir que o que a gente combina em reunião acontece do jeito combinado.
Criado em 20/07/2026 · Origem: caso "offboarding do João" (Daily 17/07 + Estratégico 20/07)

1 O problema — a história de sexta

Sexta 08:45 — Daily
Eric instrui por voz: a reunião de offboarding do João seria o João executando os processos na frente do time, não explicando ferramentas. A fala do Eric não entrou na transcrição do Zoom.
O único registro escrito
A IA do Zoom gerou o next-step: "Apresentar os processos e Skills para a equipe às 17h30" — verbo errado, o oposto da instrução.
Sexta 17:30 — a reunião
João fez exatamente o que o registro dizia: apresentou. Ele já achava que "não tinha o que mostrar, é só rodar as skills" — discordância silenciosa que nunca apareceu. 5 pessoas assistiram sem corrigir (ninguém lembrava, um paralelizando, um chegou atrasado).
Segunda — Estratégico
Desvio descoberto post-mortem. "Acontece praticamente toda semana."
Conclusão do diagnóstico: o problema NÃO é falta de anotação nem má vontade. A anotação existiu — e estava errada. O combinado vive na memória de N pessoas, e o registro escrito, quando existe, não é validado nem tratado como fonte de verdade.

2 As 5 lacunas que o protocolo fecha

#LacunaO que acontece sem ela
1Registro escrito no momentoInstrução só em voz = N versões, uma por cabeça
2Dono único5 espectadores = zero guardião (difusão de responsabilidade)
3Read-backDesalinhamento invisível até a falha ("pintar de amarelo" vs "ver se está amarelo")
4Critério de prontoExecutor substitui a intenção pela interpretação própria
5Checkpoint antes da entregaDesvio só descoberto post-mortem
Régua de decisão: qualquer mudança neste protocolo se avalia por (a) quais das 5 lacunas fecha e (b) quanto custa por combinado. Custo alvo: até 2 minutos por combinado — acima disso o time abandona.

3 O rito

Durante a reunião — no momento em que o combinado nasce

  1. Quem pede nomeia UM dono (nunca "o time", nunca dois nomes).
  2. O dono escreve o card na hora, com 4 campos: o quê + por quê (a intenção) · critério de pronto ("como sabemos que deu certo") · prazo (data/hora, não "essa semana") · dono.
  3. Read-back: o dono lê o card em voz alta com as próprias palavras. Quem pediu confirma ou corrige. ~30 segundos. Só depois do "confirmado" o combinado existe.

Fim da reunião — 2 minutos finais

  1. Quem conduz lê a lista de cards criados. Card que não foi lido em voz alta não é combinado — é conversa.
  2. Next-steps automáticos do Zoom são INSUMO, nunca fonte de verdade: ou viram card com read-back, ou morrem.

Entre reuniões

  1. Regra da mudança: mudou o plano → atualiza o card E avisa quem pediu. Silêncio = plano original vale. "Mudou sem avisar" é a violação mais grave.
  2. Discordância surfaceada: se o dono acha que o combinado não faz sentido, fala NA HORA do read-back — não executa a versão dele em silêncio.
  3. Entrega no mesmo dia com gap > 4h ganha 1 checkpoint no meio (mensagem de 1 linha: "confirmando: vou fazer X às Yh").

Na daily / reunião seguinte

  1. Abertura = varrer os cards vencidos: feito / não feito / bloqueado, olhando o card, nunca a memória. Sem card não há cobrança; com card não há desculpa.

4 Papéis

Guardião do rito
DECIDIDO: DANIEL (fixo)
Garante que combinado falado virou card com read-back antes da reunião acabar. Fiscal do protocolo, não secretário. Condição do papel: guardião não paraleliza em reunião — ele modela a atenção.
Dono do card
Escreve, dá read-back, atualiza se mudar, reporta na cobrança.
Quem pediu
Confirma o read-back. Único que pode alterar a intenção.

5 Onde vive o card

DECIDIDO: AIOS

Todo o time loga, permissão por pessoa, visão "o que vence" pra abrir a daily. A IA gera drafts a partir da transcrição do Zoom e o dono valida o texto antes de virar compromisso — o passo de 60 segundos que faltou sexta.

ClickUp descartado (hoje é cemitério de card sem cobrança). Zoom Tasks descartado (nasce sozinho, ninguém olha).

Pendente: Daniel define o processo "combinado de reunião" no AIOS — card com os 4 campos + estados (aberto/feito/bloqueado) + cobrança na daily.

6 Piloto — os combinados de hoje no formato card

Drafts a partir da reunião de hoje, PENDENTES de read-back de cada dono:

DonoO quêCritério de prontoPrazo
DanielPlano de prioridades V3 vs iOSEric viu cronograma com data de venda da V3Hoje ~19h
DanielRevisar/polir apps (Meeting Hub primeiro)Apps testados funcionando antes do eventoAntes de qui 23/07
JairSeparação por linha de receita (Super SDR)Planilha apresentável na reunião de quartaTer 21/07 EOD
RicardoMCP no agente de suporte rodandoAgente respondendo com MCP em produçãoEsta semana
RicardoPrompt do MCP com dupla verificaçãoPrompt revisado com Daniel/GabrielEsta semana
EricAll Hands sexta 16h agendadaConvite na agenda de todos + pauta de fechamento de semestreSex 24/07 16h
EricReunião financeira com JairAgendada ter 17h30Ter 21/07 17h30
AsafeAssumir webinar + campanhas (transição João)Definido o que assume e primeiro ciclo rodadoA definir no read-back
RicardoAssumir criação de vídeos (transição João)Primeiro vídeo rodado pelo processo do JoãoA definir no read-back

7 Roteiro do alinhamento Eric + Daniel — hoje 19h

1
A história: mostrar a cadeia de evidência de sexta. Não é culpa de ninguém; é buraco de mecanismo.
2
O convite: Daniel como guardião fixo. Fiscalizar "isso virou card?" e o read-back em toda reunião. Condição: guardião não paraleliza — ele modela a atenção.
3
A construção: Daniel desenha o processo "combinado de reunião" no AIOS (4 campos, estados, visão de cobrança). IA gera drafts da transcrição; dono valida.
4
O teste: rodar os 9 combinados de hoje como primeiros cards, read-back na daily de amanhã.
5
A reunião dedicada: marcar com o estratégico pra instalar o protocolo (Daniel apresenta o sistema, Eric o porquê).