# Por que cada regra é assim Documento de apoio. **A página [Guia de um Builder](https://guia-de-um-builder.pages.dev) é o que o funcionário lê** — curta, sem jargão, focada em "o que eu faço agora". Este arquivo é para quem precisa do *porquê*: gestor questionando uma regra, alguém propondo mudança, ou quem vai comunicar o programa. Se este documento contradisser o contrato, **o contrato vence**: `homologacao.md` + `homologacao.json`. - **Contrato:** v1.5.0 · 22/08/2026 - **Dono:** Fundação (Carolina Bezerra) --- ## 1. Por que "propriedade" e não "classe" `classe` era a palavra do primeiro desenho, e ela não diz nada para quem não é técnico — em programação "classe" é outra coisa completamente. **Propriedade** responde a pergunta que a pessoa realmente faz: *isso é meu ou é da empresa?* Mesma lógica para **monitoramento**, que já se chamou `custodia` e depois `manutencao`. Custódia é palavra de cartório; manutenção soa a conserto. Monitoramento é o que a área de fato assume: olhar, cuidar, manter no ar. **Regra que ficou:** vocabulário é justamente o que o contrato único existe para padronizar. Se uma palavra é opaca para quem lê, ela troca no contrato — não só na página. Página e IA falando palavras diferentes é o problema que este desenho nasceu para evitar. --- ## 2. Por que quatro perguntas, e não três O documento original de homologação Git & Deploy definia três critérios: continuidade, confidencialidade e cross-área. Faltava o quarto, e ele é o mais perigoso. **Continuidade, confidencialidade e cross-área são problemas da empresa. Dado de pessoa é problema da lei** — LGPD. Por isso é o único critério que não admite "é pequeno demais pra contar": não aceita "é só um teste", "eu apago depois", "só eu uso". Na operação da LiveMode, o dado de pessoa que mais aparece é: **funcionário** (folha, avaliação, DISC, contato, saúde, foto), **casting** (talentos, apresentadores, atletas, influenciadores — nome, cachê, contato, agente), **empresas contratadas e fornecedores** (contato de pessoa física, contrato, valor), **marcas e contratos** (cotas, valores, cláusulas, prazos não públicos). ### A diferença entre a 2ª e a 4ª pergunta Confunde, e vale a distinção: **dado da empresa que não é público** (número, contrato, negociação) é risco de **negócio**. **Dado de pessoa** é risco **legal**. Um projeto pode ter os dois. Na dúvida entre eles, responder sim aos dois não muda nada de prático — dado de pessoa é o mais restritivo e carrega o outro. ### E a 3ª pergunta, que parece com a 1ª "Mais de um time usa" parece próximo de "vira problema se sair do ar". A diferença é o que cada uma implica: a primeira é sobre **operação** (se cair, alguém para). A terceira é sobre **decisão** — quando mais de um time depende, decisões de produto e processo deixam de ser de uma pessoa só, e o projeto não deveria ser construído e decidido sozinho. --- ## 3. Por que a etiqueta de risco existe Ela **não é julgamento novo**: sai direto das quatro perguntas. Isso é deliberado — se dependesse de opinião, duas pessoas avaliando o mesmo projeto chegariam a etiquetas diferentes, e a etiqueta perderia qualquer uso. | Etiqueta | Quando | |---|---| | `R1` baixo | nem dado da empresa nem dado de pessoa — projeto operacional | | `R2` alto | dado da empresa que não é público | | `R3` crítico | dado de pessoa | **Para que serve, concretamente:** responder *"quais projetos críticos existem na empresa?"* sem abrir um por um. É a primeira pergunta de qualquer revisão de acesso. Por isso a etiqueta vira também um marcador no repositório (`risco-r1|r2|r3`), não só uma linha num arquivo. **O que ela não é:** nota, prioridade ou permissão. Um projeto crítico bem cuidado é mais seguro que um simples abandonado. --- ## 4. Por que separar "de quem é" de "quem cuida" Era o buraco maior do primeiro desenho. "Corporativo" tinha um destino só: o projeto vira da empresa e alguém de Tecnologia cuida. **A operação não funciona assim.** Existem projetos com dado sensível geridos e mantidos pela própria área, e isso é legítimo — quem entende do assunto está lá. Então são duas coisas, não uma: - **A infraestrutura é sempre da empresa.** Não é escolha de ninguém: projeto da empresa mora na conta da empresa. É automático. - **Quem cuida do produto é uma escolha:** a área ou o time de Tecnologia. ### A regra que decide **Quando as quatro perguntas batem, o monitoramento é do time de Tecnologia.** É a diferença mais nítida do modelo: ser da empresa exige homologação; bater nas quatro exige também sair das mãos de uma área só. E existem exceções nos dois sentidos — um projeto que bate em um critério só pode acabar em Tecnologia se fizer sentido no caso. O contrato descreve o comum, não o único caminho, e a exceção fica registrada com o nome de quem decidiu. ### Por que o co-owner técnico não pode ser um nome Um segundo login no arquivo de revisores é **assinatura** — serve para desbloquear merge e nada mais. No dia em que o dono sai de férias, ninguém sabe o que fazer. Por isso o teste é objetivo, e reaproveita um item que já existia: **é quem coloca o projeto no ar do zero, em menos de uma hora, seguindo só o README, sem ligar para o dono.** Se ninguém passa nesse teste, não existe co-owner — existe um nome. E aí o monitoramento não pode ficar na área. Efeito colateral bom: aquele item deixou de ser um teste abstrato de continuidade e passou a ser **a prova de que a área consegue manter o que decidiu manter**. --- ## 5. Por que só três coisas travam o trabalho O desenho anterior tinha **oito** itens de bloqueio. **Oito bloqueios para 200 pessoas é cerimônia que o time aprende a contornar** — e regra contornada é pior que regra inexistente, porque dá a sensação de cobertura. A alternativa óbvia seria encurtar a lista. A escolha foi melhor: **modular o efeito** de cada item, usando a etiqueta de risco para recortar sem perder cobertura. | Efeito | O que faz | |---|---| | **trava o trabalho** | a IA para de ajudar a publicar. Só três itens: dado de pessoa, segredo, porta aberta | | **trava o selo** | não atrapalha o dia a dia; decide se o projeto recebe selo, endereço e acesso à conta da empresa | | **pendência** | registra dono e data. Nunca impede ninguém de trabalhar | **Por que exatamente esses três travam:** são os únicos cujo erro **não tem desfazer**. Dado de pessoa e segredo entram no histórico do projeto e em toda cópia já feita; porta aberta é encontrada pelo Google antes de você perceber. Todo o resto se conserta. **O que saiu de bloqueio e por quê:** declarar propriedade e nível, e nomear dono. Ninguém deve ficar impedido de trabalhar por não ter escrito duas linhas num arquivo. Sem declaração não há homologação — mas o trabalho continua. --- ## 6. Por que a plataforma é híbrida por propriedade **Projeto pessoal publica onde a pessoa quiser.** Sem governança, sem custo para a empresa. Governar projeto pessoal seria imposto sobre curiosidade, e curiosidade é o que este programa existe para destravar. **Projeto da empresa vive numa conta Cloudflare corporativa única**, com token recortado emitido pelo time de Governança, por projeto. **US$ 5/mês estrutural** — da conta, não por pessoa. Git não muda (GitHub Team). ### O ganho que não era obvio A pessoa **não gera credencial** em projeto da empresa. Isso elimina a maior classe de risco do item de segredo: token pessoal de escopo amplo, sem validade, que ninguém lista nem revoga. **Em 200 publicadores, seriam 200 tokens pessoais ativos.** E simplifica a comunicação: em vez de *"crie sua conta na plataforma X"*, a mensagem é *"o time te entrega o token do projeto"*. ### Por que não Cloudflare Access Dois motivos, e o segundo fecha a discussão: 1. Cobra **por pessoa** acima de 50 usuários — em 200 pessoas, faixa de R$ 69–92 mil/ano (preço por seat de 2026 **não confirmado**; confirmar antes de virar número oficial). 2. No Pages, **não cobre o domínio de produção por padrão** — só os deploys de preview. O caminho é **Pages Function** com o mesmo login Google que já usamos: custo R$ 0. A rota está decidida; **a construção não está autorizada**. Enquanto não estiver: projeto com dado interno vai para a Vercel, onde a proteção existe. Anunciar Cloudflare antes disso seria prometer uma porta que ninguém consegue fechar. Quando for construída, serão **duas skills irmãs**, não substituição — tem gente publicando na Vercel hoje, e trocar a plataforma debaixo de quem já publicou não é atualização, é quebra. ### Por que a transferência deixou de ser um procedimento No primeiro desenho, virar corporativo exigia seis passos manuais, incluindo *"revogue o seu token e confirme que ele morreu"* — o passo que ninguém fazia, e que deixava o projeto formalmente na empresa e materialmente na mão da pessoa. Com a conta corporativa única, **projeto novo nasce dentro da infraestrutura** e não há o que transferir. E para o caso comum — começou pessoal, virou da empresa — **quem conduz a transferência é o Sentinela**, o mais automaticamente possível. Não é lista de tarefas na mão de quem construiu. --- ## 7. Por que o gatilho é publicar "Quando o projeto ficar grande" não é observável — ninguém se autodeclara. **Publicar, ou mandar o link para uma segunda pessoa**, é um evento com data, que a própria pessoa sabe que aconteceu. A homologação tem **três momentos possíveis**, e vale dizer os três: | Quando | Por quê | |---|---| | **no início** | se já se sabe que é da empresa, começar homologado evita a transferência depois | | **durante** | as instruções do template rodam a qualquer momento, não só no fim | | **ao publicar** | **este é o momento em que não deveria passar.** Publicou e não fez nada? É agora | **E a responsabilidade é das duas pontas, não de uma.** Da pessoa: perceber que o projeto virou da empresa e levá-lo à homologação. Do gestor da área: mapear o que na área dele se enquadra. Só a pessoa vira autodenúncia; só o gestor vira auditoria de fora. As duas juntas é o que funciona sem robô. --- ## 8. Por que não há prazo por projeto O primeiro desenho tinha "5 dias úteis" depois do gatilho. Saiu. **Prazo por projeto, em escala, sempre vira letra morta** — ninguém acompanha 200 contadores, e um prazo que ninguém cobra ensina que os outros também não são cobrados. No lugar: **estado inválido**. `corporativa` + `rascunho` não é um cronômetro correndo, é uma porta que não abre — enquanto o projeto estiver assim, ele não recebe selo, nem endereço fixo, nem acesso à conta da empresa. A consequência é imediata e não precisa de ninguém fiscalizando. --- ## 9. A janela de regularização (não está na página) Para os projetos que **já existem** na data da divulgação. Está aqui e na comunicação interna, e **deliberadamente fora da página** do funcionário: a página é "o que eu faço agora", e a janela é um comunicado de transição. No meio do fluxo, ela confunde quem está aprendendo o processo pela primeira vez. | Fase | Prazo | Quem faz | Escopo | |---|---|---|---| | **1 · declarar** | **60 dias** da divulgação | cada pessoa, com o gestor | classificar e declarar: propriedade, nível, monitoramento, risco, co-owner | | **2 · migrar** | conforme a infraestrutura ficar pronta | **time de Tecnologia** | mover os projetos da empresa para a conta corporativa | **Duas fases de propósito.** Homologar um projeto da empresa hoje inclui migrar de plataforma, e isso depende do Tech. Sem a separação, a janela cobraria das pessoas uma coisa que só o Tech pode entregar — e é assim que um prazo perde credibilidade no primeiro mês. --- ## 10. Por que existe um contrato único Três lugares descrevem as mesmas regras: a página, a skill que roda no Claude Code, e o Sentinela. **Três prosas em três lugares divergem em semanas** — e foi exatamente o que aconteceu antes: a skill aplicava os guardrails, o Sentinela tinha lista própria, e ninguém sabia qual valia. A solução é estrutural, não de alinhamento: **um arquivo**, `homologacao.json`, que os três leem. Nenhum deles pode ter item próprio. Item novo é PR no contrato, e os três se atualizam juntos. A página faz `fetch` do arquivo em vez de guardar cópia. Se a regra muda, a página muda no mesmo deploy, sem ninguém reescrever HTML. **O que cada lado enxerga:** - **A pessoa** vê as quatro perguntas, a etiqueta, a matriz e o fluxo. Não vê os IDs dos itens nem os efeitos — ela não é especialista em governança. - **A IA e o Sentinela** veem os 12 itens com IDs, efeitos e evidências. É a parte operacional. --- ## 11. Correções que este programa fez no documento original Registradas para quem for atualizar o documento de homologação Git & Deploy: 1. **Faltava a camada de acesso na comparação de custo.** O documento compara Git e Deploy, mas não compara *proteção de acesso* — porque na Vercel ela era código nosso, não licença. Na Cloudflare é uma escolha entre código (R$ 0) e produto (por pessoa). Sem essa linha, alguém lê "Cloudflare é grátis" e depois recebe uma fatura. 2. **O custo de 200 seats na Vercel provavelmente está superestimado** — só quem publica ou administra precisa de seat; quem visita, não. Não muda a recomendação; muda o tamanho do argumento. 3. **O log de auditoria completo no n8n saiu do caminho crítico.** O que se precisa é log de acesso nos projetos grandes geridos por Tecnologia, e isso vem de graça no plano gratuito do Access quando a audiência é pequena. 4. **O cenário de transição precisava de data.** O documento recomenda começar num modelo que ele próprio descreve como violação de termos de uso. Violação aceita como transição precisa de prazo — são os 60 dias da Fase 1. --- ## 12. O que ainda não existe - **Verificação automática de segredo antes de salvar.** Hoje nada impede tecnicamente uma senha de entrar no histórico de um projeto privado, e a varredura nativa do GitHub não vem no plano que usamos. É o único item que ataca o erro sem desfazer, e o mais barato de todos. - **Backup dos repositórios fora do fornecedor.** - **Offboarding de projeto no processo de desligamento.** A regra de herança existe (vai para o gestor da área, valendo para projeto, skill e doc). Falta o gatilho: alguém executar no dia. - **Política de agentes**, mais ampla que o item que existe hoje no contrato. - **Distribuição das instruções para projetos que não nascem em código.** O template resolve o caso de quem constrói com agente num repositório. Mas um projeto pode nascer numa ferramenta de montagem visual, e aí não há onde colocar as instruções — a pessoa tem que pedir a checagem em voz alta, e provavelmente não vai. Instalar como plugin nas ferramentas corporativas de IA cobre parte do problema, não todo. **É a maior lacuna de alcance do programa hoje**, e ela cresce à medida que mais gente constrói fora de código.