Pular para o conteúdo principal
Nota de ingestão

Fonte vigente confirmada pelo Founder em 2026-09-17: export .dc.html (edição em português). Convertido automaticamente; pode conter artefatos de layout do export. Conteúdo NÃO foi reescrito. A versão anterior (inglês, do pacote Governance v1.0) permanece no histórico Git. Em 2026-09-17 o REGUA_DOCS_GOVERNANCE_PATCH_v0.1 foi aplicado com aprovação explícita do Founder (APPROVE_APPLY=YES): ver PATCH_MANIFEST no histórico Git. Versão do documento: 1.1.

SISTEMA DE GOVERNANÇA

RÉGUA

Inteligência Operacional

VOLUME 01

Operating System

V1.0 · 2026CANONICAL SOURCE: 01_REGUA_OPERATING_SYSTEM_v1.0.md

01 — PRINCÍPIOS OPERACIONAIS

Como executamos sem perder a verdade

01Problema antes de ferramenta.

02Processo antes de automação.

03Medir antes de prometer resultado.

04Evidência antes de teatro de status.

05UNKNOWN antes de certeza inventada.

06Simples antes de sofisticado.

07Integração antes de substituição, quando viável.

08Responsabilidade humana em decisões de alto risco.

09Nenhum deploy crítico sem autorização e rollback.

10Escalar apenas o que provou valor.

RÉGUA · INTELIGÊNCIA OPERACIONALOPERATING SYSTEM · V1.0 · 202602

02 — MODELO DE EXECUÇÃO

QUALIFY→CHARTER→RADIOGRAFAR→ESTABELECER→GOVERNAR→GATE 01→UNIR→GATE 02→AFERIR→GATE 03→CLOSEOUT

Método RÉGUA: R—Radiografar · É—Estabelecer · G—Governar · U—Unir · A—Aferir. Lógica operacional: Entender → Medir → Governar → Implementar → Provar → Escalar. Gates são pontos de decisão, não fases.

PAPÉIS DO PROJETO

Project Owner

Escopo, prioridade, alinhamento com cliente, decisões maiores, aprovação de gate.

Execution Owner

Entrega, status atual, evidência, bloqueios, handoffs técnicos.

Client Owner

Decisões do lado cliente, acesso, dependências, validação/aceite.

AI Agent

Análise, rascunho, código, teste, documentação, revisão. Nunca aprovador responsável por decisões críticas de produção.

RÉGUA · INTELIGÊNCIA OPERACIONALOPERATING SYSTEM · V1.0 · 202603

03 — MÁQUINA DE ESTADOS

Estados padrão do projeto

PLANNED

IN_PROGRESS

IMPLEMENTED

DEPLOYED

VALIDATING

DONE

IMPLEMENTED ≠ DEPLOYED · DEPLOYED ≠ VALIDATED · VALIDATED ≠ DONE

COMMITTED, PUSHED e IMPLEMENTED_LOCAL são eventos/evidências de execução — não são estados de projeto. A máquina oficial de estados é somente: PLANNED, IN_PROGRESS, IMPLEMENTED, DEPLOYED, VALIDATING, DONE (+ BLOCKED, UNKNOWN, CANCELLED).

ESTADOS AUXILIARES

BLOCKED

O que bloqueia, quem resolve, o que falta, data-alvo.

UNKNOWN

Um fato necessário ainda não é conhecido.

CANCELLED

Trabalho intencionalmente interrompido.

DEFINITION OF DONE

Critérios de aceite atendidos; testes obrigatórios aprovados; evidência anexada; estado de deploy corretamente registrado; nenhum blocker crítico escondido; documentação atualizada; rollback/runbook atualizado; aceite do cliente/owner quando exigido. Merge, commit ou deploy isolados nunca são suficientes.

RÉGUA · INTELIGÊNCIA OPERACIONALOPERATING SYSTEM · V1.0 · 202604

04 — DEFINITION OF PASS & EVIDÊNCIA

PASS SIGNIFICA

Uma condição declarada foi verificada contra evidência. Toda declaração de PASS responde: o que foi testado, onde, como, qual evidência existe, quem/o que verificou e quando.

HIERARQUIA DE EVIDÊNCIA (preferência decrescente)

  1. Evidência direta do sistema
  2. Evidência de teste reproduzível
  3. Evidência de monitoramento/log
  4. Aceite do cliente/usuário
  5. Observação documentada
  6. Inferência informada, explicitamente rotulada como inferência

QUALIDADE DA EVIDÊNCIA

Deve ser relevante, atribuível, datada quando o tempo importa, vinculada ao ambiente correto e suficiente para a afirmação feita.

RÉGUA · INTELIGÊNCIA OPERACIONALOPERATING SYSTEM · V1.0 · 202605

05 — PRODUÇÃO & MUDANÇA

DISCIPLINA DE PRODUÇÃO

Ambientes possíveis: local, desenvolvimento, staging/teste, produção — sempre explícito na evidência de execução.

REGRA DE PRODUÇÃO

Nenhuma mudança crítica de produção sem: autorização explícita, escopo conhecido, critérios de aceite, caminho de rollback, owner responsável e plano de validação pós-mudança. Se faltar qualquer condição, a mudança não está autorizada.

CONTROLE DE MUDANÇA — MATERIAL E CRITICAL

Uma mudança é MATERIAL quando altera de forma relevante pelo menos um destes: escopo aprovado; arquitetura; integração; modelo/fluxo de dados; comportamento de negócio; critérios de aceite; dependência do cliente; prazo/custo de forma relevante; risco operacional; comportamento em produção. Se não altera nenhum destes de forma relevante, não exige change-control completo.

Mudança MATERIAL requer análise explícita de impacto: mudança solicitada · razão · impacto · riscos · issues/arquivos afetados · decisão de aprovação · data-alvo

Uma mudança é CRITICAL quando pode afetar: disponibilidade de produção; integridade/perda de dados; segurança ou privacidade; credenciais/permissões; regra financeira/comercial relevante; obrigação regulatória; decisão de negócio de alto risco; grande volume de usuários/clientes; operação com rollback difícil ou irreversível. Mudança CRITICAL segue integralmente a REGRA DE PRODUÇÃO acima.

Em dúvida real: CLASSIFICATION=UNKNOWN e tratar como o nível mais restritivo até classificar.

Nenhum scope drift silencioso.

RÉGUA · INTELIGÊNCIA OPERACIONALOPERATING SYSTEM · V1.0 · 202606

06 — IA EM EXECUÇÃO (MÍNIMO INSTITUCIONAL)

Em complemento ao AI Execution Protocol dedicado (03_REGUA_AI_EXECUTION_PROTOCOL_v1.0.md), toda execução assistida por IA segue estas regras institucionais mínimas.

ANTES

Estado atual do projeto, escopo exato, documentos canônicos, restrições, issues relevantes, permissões de deploy/mudança.

DURANTE — NÃO PODE

Inventar fatos; mudar escopo/arquitetura em silêncio; declarar PASS sem evidência; tratar código como deploy; tratar deploy como validação; criar fonte de verdade sem querer; executar deploy crítico sem autorização.

DEPOIS

O que mudou, arquivos/issues afetados, evidência, testes realizados, blockers, unknowns, próxima ação, estado atual.

WEEKLY EXECUTIVE UPDATE — formato mínimo

STATUSWHAT CHANGEDEVIDENCEIN PROGRESSNEXTBLOCKERSUNKNOWNSCLIENT DEPENDENCIESTARGET DATESDECISIONS NEEDED

O Weekly Update resume; não substitui o Linear.

RÉGUA · INTELIGÊNCIA OPERACIONALOPERATING SYSTEM · V1.0 · 202607

07 — GOVERNANÇA DE GATES

GATE 01Vale fazer?

Problema claro? Relevante e recorrente? Baseline possível? Valor esperado significativo? Risco aceitável? Existe owner?

Outcomes: APPROVE · ADJUST · BLOCK · REJECT

Approver obrigatório: Régua Project Owner. O Client Owner co-aprova quando a decisão altera escopo contratado, prioridade do cliente, dependência relevante, custo/prazo acordado ou regra operacional do cliente.

GATE 02Funciona com segurança?

Fluxo funciona no ambiente certo? Limites respeitados? Logs disponíveis? Falhas aceitáveis? Rollback validado? Escalonamento humano presente?

Outcomes: APPROVE PILOT/PRODUCTION · ADJUST · BLOCK · REJECT

Approver obrigatório: Régua Project Owner. O Client Owner co-aprova quando houver entrada em produção, impacto no processo real do cliente, risco relevante de dados/financeiro/regulatório ou mudança percebida por usuário/cliente.

GATE 03Provou valor?

Métrica acordada foi medida? Comparação válida? Valor melhorou materialmente? Custo/complexidade aceitáveis? Exceções entendidas?

Outcomes: SCALE · ADJUST · MAINTAIN · STOP

Approver obrigatório: Régua Project Owner. Em projeto de cliente, o Client Owner registra aceite/decisão junto ao SCALE/MAINTAIN/STOP.

REGRA GERAL DE APROVAÇÃO — Founder solo pode acumular Project Owner + Execution Owner; a autoaprovação deve permanecer explícita no registro do Gate. IA nunca é approver responsável.

RÉGUA · INTELIGÊNCIA OPERACIONALOPERATING SYSTEM · V1.0 · 202608

08 — DOCUMENTAÇÃO, NOMENCLATURA E HANDOFF

Documentação é proporcional a risco e valor de reutilização — não existe para parecer organizada. Nomes estáveis e versões explícitas: PROJECT_CHARTER_v1.0.md. Evitar final.md, latest-real-final.md.

PADRÃO DE HANDOFF

O schema canônico de handoff é o template HANDOFF.md. Este documento não duplica a lista de campos: toda transferência material usa o template diretamente.

CONDIÇÃO DE SUCESSO DO OPERATING SYSTEM

Este sistema é bem-sucedido quando, a qualquer momento, respondemos sem adivinhar: o que buscamos, o estado atual, o que foi implementado, o que está deployado, o que foi validado, o que está bloqueado, o que é desconhecido, quem é o próximo owner e qual a próxima decisão.

RÉGUA · INTELIGÊNCIA OPERACIONALOPERATING SYSTEM · V1.0 · 202609

09 — ANTI-PADRÕES

  • Verdade do projeto presa em histórico de chat
  • Fontes de verdade duplicadas
  • Scope drift não documentado
  • "Done" sem evidência
  • Deploy sem rollback
  • Certeza gerada por IA sem verificação
  • Documentação enorme que ninguém usa
  • Esconder blockers para preservar aparências

TERRA FÉRTIL — PRIMEIRA APLICAÇÃO

Charter → escopo comercial/operacional atual → Current State Map → System Map → Unknown Log → Baseline → Opportunity Register → Governar (fluxo futuro, limites, critérios de aceite, rollback) → Gate 01 → só então o primeiro piloto. Bubble, WATI, atendimento fora do horário e follow-up seguem hipóteses até a evidência confirmar.

RÉGUA · INTELIGÊNCIA OPERACIONALOPERATING SYSTEM · V1.0 · 202610