Conteúdo detalhado
🚧 Onde estamos no loop
Você já fechou a Identidade (Módulo 4.2) e o Substrato (Módulo 4.3). Ao digitar /os-coach next, o coach lê o seu memory.md, vê que a próxima camada não-feita é a de número 3 — Regras & Ganchos, e começa a te coachar nela. O loop é sempre o mesmo: ele faz 2-3 perguntas, espera, constrói os arquivos reais, anota onde você parou e aponta o próximo passo.
🌱 Novo aqui?
Camada é cada uma das 6 partes de um OS (Identidade, Substrato, Regras, Habilidades, Ferramentas, Agentes). Guardrail (em PT: cerca) é uma proteção que impede o sistema de fazer besteira. memory.md é o arquivo onde o coach guarda onde você está, pra retomar do mesmo ponto em qualquer sessão.
🚧 O que é
A camada de Regras & Ganchos são as cercas do seu OS: as linhas que ele nunca pode cruzar, mais alguns reflexos automáticos que aplicam essas linhas sem ninguém precisar lembrar.
- •Vem depois de Identidade e Substrato — você só protege o que já existe.
- •Mora na pasta rules/, em dois arquivos: always.md e never.md.
Como ler: as duas camadas de baixo já estão feitas. next te coloca na camada 3 e roda o mesmo ciclo de sempre — perguntar, construir, persistir, seguir.
Por que aprender
Porque a ordem importa. Regras sem substrato protegem o vazio; regras antes da identidade não sabem o que estão defendendo. Chegando aqui na sequência certa, cada cerca que você levanta protege algo que já tem valor — e o coach já conhece seu objetivo, então as perguntas são curtas.
Conceitos-chave
🪧 Regra vs Gancho: o sinal e a porta trancada
O coach distingue duas coisas que parecem iguais mas têm força diferente. A analogia que ele usa: uma regra é uma placa escrita "não entre"; um gancho é uma porta trancada que fisicamente não abre. A placa é uma sugestão forte — o modelo quase sempre obedece, mas pode julgar. A porta trancada é determinística: não tem "quase".
🌱 Novo aqui?
Gancho (em inglês hook) é um pedacinho de automação que o harness dispara sozinho em certo momento (ex.: toda vez que você vai salvar algo). Determinístico quer dizer "acontece sempre igual, sem depender de bom senso". O harness é o programa de terminal (Claude Code, Codex) que dá mãos à IA.
Como ler: comece pelas regras (texto que você escreve hoje). O gancho é a versão "porta trancada" de uma regra crítica — o coach identifica qual regra merece virar reflexo e anota pra você (ou um técnico) ligar depois.
✓ Boa regra
- ✓Concreta e testável: dá pra dizer "violou" ou "não violou".
- ✓Amarrada ao seu objetivo, não genérica.
- ✓Curta: uma linha por regra.
✗ Regra fraca
- ✗Vaga: "seja cuidadoso", "use o bom senso".
- ✗Genérica: serviria pra qualquer OS.
- ✗Tão longa que ninguém consegue checar.
Por que aprender
Porque saber a diferença evita dois erros: confiar numa placa pra coisas que precisam de porta trancada (ex.: vazar dado privado) e gastar energia construindo automação pra coisas que uma simples linha de texto já resolve. A regra é barata; o gancho é forte. Use cada um no lugar certo.
Conceitos-chave
❓ As 2-3 perguntas que o coach faz
Como em toda camada, o coach faz no máximo 2-3 perguntas em linguagem simples e então espera você responder. Ele não despeja as seis camadas de uma vez nem te entrega um formulário. Para a camada de Regras, as perguntas do playbook são estas:
Qual o pior erro?
"Qual o pior erro que este OS poderia cometer?" — essa resposta vira uma never-rule.
Algo automático?
"Tem algo que deveria acontecer automaticamente toda vez?" (um lembrete, uma verificação, um backup) — isso é candidato a gancho.
Dado privado?
"Tem algum dado privado que nunca pode sair desta pasta ou ser compartilhado?" — vira uma regra de "nunca publicar/compartilhar".
💡 A sacada
Você não precisa pensar em "todas as regras possíveis". Pense só na única coisa que doeria mais se acontecesse. Uma never-rule afiada vale mais que dez regras mornas — e o coach reusa o objetivo do memory.md, então não repete o que você já contou.
Por que aprender
Porque te tira do branco. "Que regras eu coloco?" paralisa; "qual o pior erro possível?" é fácil de responder. As três perguntas convertem medo difuso em três artefatos concretos, e você só dá um passo por vez.
Conceitos-chave
⛔ Pior erro → never-rule concreta
Sua resposta ao "pior erro" não fica vaga: o coach a escreve como uma never-rule clara e testável em rules/never.md. O erro comum que ele evita é a regra vaga. Compare: "seja cuidadoso com clientes" não dá pra checar; "nunca misture os números de dois clientes diferentes" dá — ou misturou, ou não.
Recriação ilustrativa — rules/never.md
# Never # O que este OS nunca pode fazer. - Nunca envio mensagem a um cliente sem você ler e aprovar antes. - Nunca deixo um prazo passar em silêncio: se algo está em risco, eu aviso alto. - Nunca misturo os números de dois clientes diferentes.
✓ Concreta (testável)
- ✓"Nunca misturo números de dois clientes."
- ✓"Nunca envio sem sua aprovação."
- ✓"Nunca converto valores sem indicar a moeda."
✗ Vaga (não checável)
- ✗"Seja cuidadoso."
- ✗"Evite confusão."
- ✗"Use o bom senso com dados."
Por que aprender
Porque uma regra só protege se der pra verificar. A versão testável também é a que a auditoria (Módulo 4.6) consegue pontuar: ela vira o critério de "esta camada está sólida?". Vaga não pontua; concreta sim.
Conceitos-chave
♻️ O reflexo automático (o gancho a anotar)
O done-check desta camada pede pelo menos um reflexo automático identificado. Se você nomeou um comportamento que deveria acontecer toda vez, o coach o anota como um gancho a ligar depois e descreve o que ele guardaria — sem fingir que já está implementado. Você não precisa programar nada agora: basta dizer qual reflexo importa.
🔁 Reflexos típicos por objetivo
- Nunca perder prazo — avisar automaticamente quando faltarem 3 dias de uma data contratada.
- Dado sensível — checar e bloquear informação privada antes de qualquer envio pra fora (um PII guard).
- Trabalho que sai — exigir sua aprovação antes de qualquer coisa ir para um cliente.
Recriação ilustrativa — anotação do gancho em memory.md
## Open questions
- Gancho a ligar: avisar 3 dias antes de cada data contratada
(hoje é uma regra em always.md; vira reflexo determinístico depois).
🌱 Novo aqui?
PII é "Personally Identifiable Information" — informação que identifica uma pessoa (nome, e-mail, CPF, telefone). Um PII guard é um reflexo que varre o que vai sair e barra se encontrar esse tipo de dado. É o exemplo clássico de regra que merece virar gancho, porque um vazamento não se desfaz.
Por que aprender
Porque reflexo não depende de memória humana. Uma regra que você precisa "lembrar de seguir" falha no pior dia; um gancho que dispara sozinho não. Identificar o reflexo agora deixa o caminho pronto pra blindar a parte mais crítica do seu OS quando você (ou um técnico) for ligar a automação.
Conceitos-chave
🔒 A regra de dado privado
Se você marcou algum dado como privado, o coach adiciona uma regra de "nunca commitar nem compartilhar" e mantém a regra de ouro da skill: um valor sensível nunca é escrito ao pé da letra dentro da pasta. No lugar entra um handle não-identificador (iniciais, "Cliente A", um código curto). E ele nunca escreve uma nota que diz "este campo está excluído" e depois lista o campo — essa contradição é, em si, um vazamento.
⚠️ Por que isso é "porta trancada", não "placa"
Um vazamento de dado pessoal é irreversível — não dá pra "despublicar" o que já saiu. Por isso a regra de dado privado é a primeira candidata a virar gancho (PII guard), e por isso, numa auditoria, um vazamento limita aquela camada e vira o movimento nº 1 a corrigir.
Recriação ilustrativa — rules/always.md (trecho)
# Always
- Sempre uso um handle ("Cliente A") no lugar do nome real do cliente.
- Sempre mantenho o mapa nome-real fora desta pasta.
- Sempre trato esta pasta como se ela pudesse ir parar num backup público.
Por que aprender
Porque é o que faz seu OS ser seguro de cultivar. Você vai querer versionar a pasta, fazer backup, talvez sincronizar entre máquinas. Sem a regra de dado privado, qualquer uma dessas ações pode expor o que era pra ficar só com você. A cerca aqui não é burocracia: é o que te deixa dormir tranquilo usando o sistema todo dia.
Conceitos-chave
✅ Done-check + copy-run
A camada de Regras está sólida quando: (1) a resposta do pior erro está escrita como uma never-rule clara e testável; e (2) pelo menos um reflexo automático foi identificado. Se faltar uma dessas, o coach marca a camada como in progress e diz exatamente o que falta — ele não infla "ok" falso.
Checklist da camada Regras
- ✓rules/never.md tem o pior erro como never-rule concreta.
- ✓rules/always.md tem as restrições do dia a dia (ex.: aprovação, handle de dado privado).
- ✓Pelo menos um reflexo (gancho) está identificado e anotado.
- ✓Nenhum valor sensível foi escrito ao pé da letra na pasta.
Objetivo: abrir a camada de Regras e deixar o coach construir os dois arquivos a partir das suas respostas.
1) Cole no Claude Code (dentro da pasta do seu OS):
/os-coach next
2) Ele faz 2-3 perguntas. Responda em texto livre (troque pelos seus):
Pior erro: <ex.: enviar algo errado a um cliente sem eu ver> Algo automático: <ex.: me avisar 3 dias antes de cada prazo> Dado privado: <ex.: nomes dos clientes, nunca compartilhar>
3) O coach cria, na sua pasta:
rules/ ├── always.md # o que ele sempre faz └── never.md # os hard stops (pior erro)
Como verificar: abra rules/never.md e cheque se o pior erro virou uma linha que dá pra dizer "violou ou não". Rode /os-coach status e confirme que Rules aparece como solid (ou in progress com o que falta).
Por que aprender
Porque o done-check é o que separa "tem um arquivo" de "tem uma cerca de verdade". Rodar o copy-run e checar o resultado é o hábito que você repete em toda camada — e é exatamente o que a auditoria do Módulo 4.6 vai pontuar depois. Camada fechada, o coach te manda para a próxima: Habilidades.
Conceitos-chave
✅ Resumo do módulo
Próximo módulo:
4.5 — Habilidades → Ferramentas → Agentes 🧩