Runbooks | Procedimentos Operacionais
Procedimentos passo-a-passo para tarefas recorrentes do projeto. Cada runbook define: gatilho (quando rodar), passos (antes/durante/depois), critério de pronto, escalação. Atualização: quando o procedimento muda, ou após um incidente que exige ajuste.
Runbooks disponíveis
| Runbook | Gatilho | Owner típico |
|---|---|---|
| Rodar uma reunião | Antes / durante / depois de qualquer reunião | Quem conduz ou registra |
| Promover sinais de reunião | Depois de toda reunião com conteúdo material | Quem registra a ata |
| Onboardar pessoa nova | Nova pessoa entra no projeto (Anouk ou cliente) | Pedro ou Rafael |
| Acionar Axios ou agente operacional | Precisa de ajuda de agente para tarefa específica | Qualquer pessoa Anouk |
| Publicar ou ressincronizar wikis | Mudança material no vault ou incidente no build | Pedro |
| Gestão de tasks | Criar / editar / fechar task no sistema 1-task-1-nota | Qualquer pessoa Anouk |
| Revisão mensal de DEFINICOES | Última sexta de cada mês | Pedro |
Quando criar um runbook novo
Crie um runbook quando:
- A tarefa é recorrente (≥ 3x por trimestre)
- Tem passos não-triviais (≥ 5 passos com ordem importa)
- Pode ser executada por diferentes pessoas (e elas precisam de consistência)
- Tem pontos de falha conhecidos que valem documentar
Para começar um runbook novo, copie um existente (runbook-rodar-reuniao.md é um bom ponto de partida) e adapte. Não há template separado — os runbooks existentes já servem de referência de estrutura.
Estrutura padrão
Todo runbook segue este esqueleto:
- Frontmatter com title, updated, owner, publish
- Cabeçalho com tag, descrição em uma frase
- Quando rodar (gatilho explícito)
- Pré-requisitos (o que precisa estar pronto antes)
- Passos numerados com tempo estimado por passo
- Checklist final (o que validar antes de declarar completo)
- Antipadrões a evitar (lições aprendidas)
- Ver também
Ver também
- STYLE-GUIDE — convenções gerais
- MEMORY-CONTRACT — regras canônicas
- Guia de uso do Obsidian
- Scripts operacionais