O X-PRO.ai compila o perfil de um projeto em uma biblioteca de guardrails em Markdown puro que um agente de IA lê enquanto desenvolve. O mesmo catálogo global produz as regras de um PoC descartável ou de um sistema regulado conforme as respostas — e cada decisão de incluir, adiar ou descartar uma prática fica registrada com seu motivo.
AWS & Azure Well-Architected, Google SRE, 12-factor, DORA — descrevem o que grandes sistemas fazem. Aplicados ao pé da letra em uma ferramenta interna de duas semanas, são desperdício. Aplicados de forma frouxa em uma plataforma de pagamentos, são perigosos. O difícil não é conhecer as práticas. É decidir o quanto de cada uma um projeto merece, e ser honesto sobre o que você escolheu pular.
Multi-região, circuit breakers, DDD tático completo e GitOps em um PoC que vive duas semanas. O rigor é real, o custo é real, e nada disso move o risco real do projeto.
Uma superfície de pagamento entregue com autenticação caseira, segredos no repositório e nenhum restore testado — porque as "boas práticas" foram tratadas como item opcional de backlog.
Tratar a calibração como uma computação auditável de primeira classe. Você perfila o projeto uma vez; um Tier é derivado; o Tier modula cada prática de Required até Discarded; e os trade-offs são registrados em vez de deixados implícitos. É um motor de trade-offs — não um template "do melhor dos mundos".
O catálogo é o dado; as suas respostas selecionam dele; os artefatos são a saída. Mude o catálogo e todo projeto que atualizar herda a melhoria. Mude as respostas e apenas os artefatos daquele projeto se movem.
O gerador é determinístico: mesmas respostas + mesma versão de catálogo = saída idêntica byte a byte. O lock file registra um answers_digest; se uma resposta muda, o digest diverge e os artefatos são marcados como obsoletos. Essa propriedade é o pré-requisito para auditar e versionar a saída.
Mova os controles. Criticidade soma cinco perguntas (impacto, sensibilidade, raio de impacto, SLA, reversibilidade). Complexidade soma quatro (domínio, integrações, dados, distribuição). Cada par de faixas mapeia para um Tier base pela matriz — e então os flags de override o elevam. Esta calculadora roda a lógica real do tier-engine.yaml.
Criticidade é o eixo dominante. Complexidade sozinha nunca alcança T3 — ela trava em T1 quando a criticidade é baixa e em T2 quando é média. T3 só é atingido por C-High × K-High, por C-Critical em qualquer complexidade, ou por um flag de override. A complexidade eleva o piso; ela não define o teto.
| K-Low | K-Med | K-High | |
|---|---|---|---|
| C-Critical | T3 | T3 | T3 |
| C-High | T2 | T2 | T3 |
| C-Med | T1 | T2 | T2 |
| C-Low | T0 | T1 | T1 |
Descartável / PoC. Rigor pesado não vaza — só o básico "decisão obrigatória" mais o ratchet de segredos.
Interno, baixa criticidade. Caminho crítico testado, logs estruturados, backup diário, autoridade única de decisão.
Produto. Monólito modular, métricas RED, testes de integração, multi-AZ, IaC e governança por ADR.
Crítico / regulado. Circuit breakers, tracing + SLOs, multi-região, zero-trust, PITR contínuo, canary.
Overrides só elevam o Tier, nunca o reduzem. O resultado é um Tier global mais um Tier por dimensão. Um produto consciente de custo pode rodar em T2 globalmente enquanto sua dimensão de segurança é elevada a T3 por um flag de pagamento.
A escada de tiers · overrides são um ratchet de via única
| Condição | Efeito | Por que só pode subir |
|---|---|---|
| Dados regulados | piso global T3 | A exposição regulatória é inegociável; o prazo não muda a lei. |
| Dados PII / financeiros | segurança ≥ T2 | Sensibilidade é uma propriedade do dado, não do orçamento. |
| Flag de pagamento / PCI | segurança ≥ T3 | Dados de cartão carregam um piso fixo de controles. |
| Impacto de risco à vida | piso global T3 | A falha pode ferir pessoas; o rigor não pode ser negociado. |
| Segredo no código | proibido — qualquer tier | Um ratchet rígido: APP-09 dispara até no piso T0. |
Quando o rigor exigido excede a capacidade declarada — um SLA de 99,9% contra uma restrição de "prazo apertado / equipe pequena" — isso é sinalizado como risco aceito no TRADE-OFFS.md. A geração prossegue. O ponto é uma decisão consciente, não uma parada.
Cada uma de confiabilidade, segurança, desempenho, custo, operacional, sustentabilidade resolve para o máximo entre o Tier global e qualquer override aplicável. O ratchet é monotônico — não há caminho que reduza uma dimensão abaixo do seu piso.
Este é o núcleo do estágio 3. Para cada uma das 40 práticas, o gerador lê a resposta, pega o tier efetivo da dimensão da prática e resolve um status. Duas ideias importam: required_if torna uma prática obrigatória por causa do que o projeto é; o Tier então escala o rigor de todo o resto.
Como o status é resolvido · para na primeira que casa
A calibração travou os dois refinamentos acima com golden fixtures: deferrable impede que fast_mvp rebaixe higiene barata (logs, monólito modular, CI/CD básico), e required_if captura mandatos guiados pela resposta que só o Tier deixaria passar.
Um único registro carrega sua diretiva (Do / Don't / Example / Verification). O Do/Don't compila para AI-AGENT-RULES.md; o Verification compila para DEFINITION-OF-DONE.md; um trade_off vira uma entrada no TRADE-OFFS.md. Um registro, vários destinos.
Um registro, vários destinos
Em geral não vira código — vira restrições que as outras camadas herdam, carregadas em uma linha propagates.
Apresentação, modelagem de domínio, comunicação, consistência, resiliência, observabilidade, auth, testes, config, extensibilidade.
Classificação, modelo, volume, integridade, acesso, retenção, privacidade, linhagem, backup/RPO, movimentação.
Hospedagem, computação, disponibilidade, RTO/DR, escalabilidade, postura de segurança, exposição, IaC, CI/CD, custo.
Aponte o Claude Code, Cursor, Copilot, ou qualquer agente LLM genérico para o AI-AGENT-RULES.md — ele achata as diretivas Required e Recommended em regras imperativas que o agente segue ao construir. Os nomes de arquivo ficam sem versão; cada arquivo declara sua versão internamente.
Uma plataforma interna de aprovação de despesas: ~2.000 funcionários, integra um ERP e um gateway de pagamento, construída por uma equipe pequena sob prazo apertado.
Scores: C = 8 (C-High), K = 4 (K-Med) → base T2. O flag payment_pci eleva a segurança para T3. O rigor de execução exigido excede a capacidade declarada de equipe/prazo — registrado como risco aceito, não como bloqueio.
O exemplo é gerado pelo mesmo gerador a partir do t2-expense.yaml, então fica em sincronia com o catálogo.
APP-07 auth → Required (override financeiro) · APP-05 resiliência → Recommended (deferrable=false, sobrevive ao fast_mvp) · APP-10 extensibilidade → Deferred (deferrable=true). Cada um dos 8 itens Deferred aparece no TRADE-OFFS.md com um gatilho de reativação.
Práticas do catálogo, ajuste do motor de tier, fixtures de calibração, o gerador, docs, ou um estudo de caso real para endurecer o framework. Mande uma mensagem e eu respondo diretamente.