Níveis de Exigência LZR
Versão 1.0 — 2026-06-20. Define quanto de cada manual se aplica a cada projeto.
O que este arquivo responde: nem todo projeto LZR carrega o mesmo peso. Um protótipo de fim de semana não precisa do rigor de um produto que guarda dinheiro e dado de cliente. Aqui ficam os três níveis e a régua de qual nível vale pra cada projeto.
Regra de ouro deste acervo: este arquivo classifica as regras por nível — não as copia. Cada regra continua morando no seu manual (código, testes, design); aqui só se diz quando ela passa a ser obrigatória. As células abaixo nomeiam o bloco e apontam para o manual; quem muda a regra muda lá, não aqui.
Por que existe
Sem níveis, só há dois caminhos ruins: ou se aplica o rigor de produto crítico a tudo — e o protótipo trava sob peso que não precisa — ou se afrouxa para o protótipo e o produto crítico nasce sem a proteção que exige. O nível é o botão que ajusta o rigor sem abrir mão do piso. Ele decide o que é obrigatório agora; não decide o que é certo (isso é dos manuais).
Os três níveis (acumulativos)
| Nível | Para que tipo de projeto | Exemplos |
|---|---|---|
| Essencial | Protótipo, uso interno, projeto pessoal, site simples sem login nem dado de cliente. É o piso de qualidade e segurança que nunca se abre mão. | Página de campanha, ferramenta interna descartável, experimento de fim de semana |
| Produto | Vai pra mão do cliente: produção, usuários reais, dado de cliente em jogo. A maioria dos apps LZR. | A maior parte dos produtos da casa em operação |
| Crítico | Guarda dinheiro, guarda dado pessoal sensível (saúde, jurídico, licitação), separa vários clientes no mesmo sistema, ou tem inteligência artificial decidindo algo que afeta o usuário. | Produtos com cobrança, dados clínicos ou multi-cliente no núcleo |
Acumulativo: cada nível inclui tudo do anterior e acrescenta. Crítico = Produto + os itens críticos. Produto = Essencial + os itens de produto. Por cima de tudo, certas características ligam blocos de regra sozinhas, em qualquer nível — ver "Gatilhos".
Como o projeto declara seu nível
- Uma linha no atalho do projeto (o arquivo de instruções na raiz): "Nível de exigência: Produto".
- O agente lê na abertura da sessão e aplica o nível ao decidir o que é obrigatório.
- Sem a linha: na abertura, antes de codar, o agente roda a régua de desempate e percorre os gatilhos com o coder (tem dinheiro? multi-cliente? inteligência artificial? dado sensível? recebe arquivo? expõe porta de entrada a terceiros?). Só então fixa o nível. Enquanto não confirmado, trabalha no piso de Produto — nunca Essencial. Nenhum gatilho passa sem resposta.
Régua de desempate — qual é o nível do meu projeto
Responda na ordem; o primeiro "sim" fixa o nível:
- Guarda dinheiro, guarda dado pessoal sensível (saúde, jurídico, licitação), separa vários clientes no mesmo sistema, ou a inteligência artificial decide algo que afeta o usuário? → Crítico.
- Vai pra produção, com usuários reais e dado de cliente? → Produto.
- Protótipo, uso interno, pessoal, descartável? → Essencial.
Na dúvida entre dois, fica no mais alto.
Gatilhos — características que sobem o rigor sozinhas
Independentemente do nível geral, a presença destas características torna o bloco de regras correspondente obrigatório — em qualquer nível, inclusive Essencial:
| Se o projeto tem… | …então é obrigatório |
|---|---|
| Vários clientes no mesmo sistema (multi-cliente) | Proteção de acesso por linha e o teste real de separação de clientes (testes §8) — não só num nível, sempre que houver multi-cliente |
| Recebe dinheiro / cobra | Teste de integração no caminho do dinheiro; aviso externo tratado sem repetir efeito |
| Dado pessoal sensível | As regras de conformidade legal (manual próprio — próxima fase) |
| Inteligência artificial no produto | As regras de arquitetura de IA, incluindo avaliação da saída — ver arquitetura de IA |
| Recebe arquivo enviado pelo usuário | Validação de formato e tamanho e varredura antes de aceitar o arquivo |
| Expõe porta de entrada a terceiros (pública ou como fornecedor) | Versão na porta de entrada, limite de uso e chave que pode ser revogada |
O gatilho só eleva, nunca rebaixa. Um projeto Essencial que passa a separar clientes herda, naquele ponto, o rigor de quem separa clientes — incluindo o teste real.
A matriz — o que cada nível acrescenta, por tema
Cada célula nomeia o incremento e aponta pro manual onde a regra mora por extenso. O que não aparece numa coluna já veio da anterior (acumulativo). Itens marcados (próxima fase) existem em espírito mas ainda vão ganhar texto próprio no manual — ver "O que ainda entra".
| Tema | Essencial | Produto (+ ) | Crítico (+ ) |
|---|---|---|---|
| Qualidade de código | Piso de qualidade — ver "O piso que nunca escala" e código §2 | (igual — é piso) | (igual — é piso) |
| Estrutura de pastas | Estrutura-raiz padrão por tipo (código §3) | (igual) | (igual) |
| Testes | Lógica nova nasce com teste; camadas rápida + regra de negócio; catraca de cobertura (testes §1, §5, §6) | Integração e ponta a ponta no caminho de ouro (testes §5) | Alvo de maturidade mais alto nas camadas de dinheiro e acesso (testes §6); teste de acordo entre partes (próxima fase) |
| Banco de dados | Fundação de banco (código §7) | Proteção de acesso por linha quando há login/dado de cliente | Auditoria central imutável |
| Segurança | Piso de segurança — ver "O piso que nunca escala" e código §8 | Autorização verificada por rota; varredura de segredo no acervo; erro que não vaza detalhe interno | Checklist das falhas mais comuns; varredura de dependência; resposta formal a vulnerabilidade (próxima fase) |
| Frontend | Busca de dados padronizada; estados de tela (carregando/erro/vazio) (código §5) | Formulário validado na entrada; proteção de rota; navegação por histórico; paginação | Acessibilidade auditada (design §6). Onde o produto depende de velocidade ou de descoberta orgânica: orçamento de desempenho e busca para mecanismos |
| Backend | Camadas separadas (acesso a dados longe da regra de negócio); erro tratado, nunca engolido (código §6) | Versão na porta de entrada da API; limite de uso por cliente; operação multi-passo é tudo-ou-nada | Verificação de saúde. Onde há processamento assíncrono ou aviso externo: tratar sem repetir efeito e fila com reprocesso (próxima fase) |
| Design | Fundação visual: tokens (sem cor crua), escala de espaçamento, estados visuais, contraste mínimo (design §2–6) | Biblioteca de componentes compartilhada; movimento; microcopy; feedback padronizado | Acessibilidade auditada na norma nova (design §6) |
| Publicar e enxergar no ar | Publica com segredo fora do código (código §8) | Ambiente de teste antes da produção; erro capturado em ferramenta própria; conferência automática após publicar; volta rápida (próxima fase) | Alerta por limite (erro, lentidão, custo); painel de saúde; rastreamento de ponta a ponta (próxima fase) |
| Inteligência artificial | — (não se aplica a projetos sem IA) | — | Instrução versionada, camada isolada, avaliação da saída, resiliência, segurança de IA, privacidade — ver arquitetura de IA (todo projeto com IA sobe para Crítico automaticamente) |
Sobre cobertura de teste (esclarecimento, não regra nova): a trava real do dia a dia é a catraca — a cobertura parte de onde o projeto está e só sobe, nunca desce, em qualquer nível. O número de maturidade (80% no geral, 90%+ nas camadas críticas) é alvo aspiracional, medido na avaliação do projeto, não uma trava que bloqueia projeto novo. O nível sobe quais camadas de teste são obrigatórias e o alvo de maturidade — não transforma o alvo em trava. Fonte: testes §6.
O piso que nunca escala para baixo
Isto vale em qualquer projeto, inclusive no protótipo — não depende de nível, não se negocia:
- Segredo e chave fora do código.
- Toda entrada externa validada antes de usar (formulário, chamada de API, arquivo recebido, aviso de outro sistema).
- Tipagem estrita, zero
any. - Tolerância zero a erro e aviso pendente.
- Toda lógica nova nasce com teste.
- Código e nomes em inglês.
Um projeto pode ser pequeno; não pode ser inseguro nem mentir que está pronto.
O que ainda entra nesta matriz (próximas fases)
Esta é a fundação. Conforme os manuais novos e os pontos soltos nascerem, a matriz ganha linhas e as marcas (próxima fase) viram ponteiro real:
- Conformidade legal — tema próprio quando o manual de conformidade nascer; entra como gatilho para qualquer projeto com dado pessoal.
- Pontos soltos — teste de acordo entre partes, teste que verifica os próprios testes, tratamento de aviso externo sem repetir efeito, enxergar o sistema no ar (erro capturado, alerta, conferência pós-publicação, rastreamento), e — onde fizer sentido — documentação automática da porta de entrada e comparação de tela por imagem. Cada um ganha texto no manual certo e a matriz passa a apontar para ele.
Fronteiras deste arquivo: as regras moram nos manuais (código, testes, design). Aqui mora só a graduação — quanto de cada uma é obrigatório em cada projeto. Mudou uma regra? Muda no manual dela. Mudou quando ela pega? Muda aqui.