Como trabalhamos: a metodologia de engenharia PontoTi em 12 regras

Antes de escrever a primeira linha, escrevemos o problema: quem o sente, o que fica fora do âmbito e como se mede se a solução resultou.

Um Product Requirements Document impede que uma equipa construa funcionalidades a prever e descubra tarde que resolveu o problema errado.

Antes de a primeira função existir, desenhamos como as entidades se relacionam e a ordem real das chamadas entre sistemas, filas e bases de dados.

Um diagrama desactualizado é pior do que nenhum: por isso vive junto do código que descreve, no mesmo repositório, e é actualizado quando o código muda.

Cada produto tem uma tabela explícita que liga papel, recurso e acção a permitido ou negado. Não confiamos em «na prática ninguém vê isso»: um nível de acesso que não está escrito é tratado como não definido e, por omissão, negado.

Quando um produto serve mais do que um cliente ou organização na mesma base de dados, cada tabela com esses dados tem uma coluna de tenant explícita.

Não isolamos tenants apenas com filtros espalhados pelo código da aplicação — um filtro esquecido numa única query é o suficiente para mostrar dados de um cliente a outro.

O Row Level Security acrescenta isolamento dentro da própria base de dados PostgreSQL, independente da aplicação que lhe acede: mesmo que uma query se esqueça de filtrar por tenant, a base de dados recusa devolver linhas fora do papel autenticado.

Uma política de RLS só é considerada válida depois de um teste provar, na prática, que um tenant não vê dados de outro.

Segredos não entram em código, em logs, em prompts de IA nem em capturas de ecrã — vivem em variáveis de ambiente ou num vault, com âmbito mínimo por serviço e rotação planeada.

Um segredo que só uma pessoa sabe onde está não é gestão de segredos: é um ponto único de falha.

Cada módulo tem uma responsabilidade e uma fronteira claras, e uma dependência nova só entra no projecto com justificação. Preferimos reutilizar um padrão já existente no código a inventar uma abstracção nova para um problema que só aconteceu uma vez.

Um erro não tratado não pode derrubar a aplicação inteira nem mostrar a um utilizador uma stack trace ou um detalhe interno do sistema.

Cada produto tem um mecanismo central que captura, regista e alerta sobre falhas, e uma fronteira que contém o erro à parte da interface onde aconteceu.

Testes unitários verificam uma função isolada; testes de integração verificam se as peças falam bem entre si — base de dados, filas, APIs externas; testes E2E percorrem, num browser real, o caminho que uma pessoa real segue do princípio ao fim.

Os três níveis apanham erros diferentes; um produto com apenas um tipo de teste tem um ponto cego garantido.

Uma auditoria de segurança feita depois de um incidente já chegou tarde. Por isso a verificação de segurança faz parte do próprio processo de deploy e pode bloquear uma alteração antes de chegar a produção, em vez de apenas a documentar depois.

Um domínio público recebe tráfego que não vem de pessoas: scraping agressivo, tentativas de força bruta, bots a testar formulários.

Um Web Application Firewall filtra padrões de ataque conhecidos, o Bot Fight Mode distingue tráfego automatizado hostil do legítimo, e o rate limiting impede que um único cliente — humano ou não — consuma a capacidade destinada a todos os outros.

Toda a comunicação pública corre em HTTPS, com certificado válido e HSTS a instruir o browser a nunca voltar a tentar HTTP nesse domínio, incluindo subdomínios.

Quando o domínio passa por uma rede como a Cloudflare, o modo correcto é Full (Strict): a ligação entre a borda e a origem também precisa de certificado válido, não só a ligação entre o visitante e a borda.

Um produto novo cumpre as 12 regras desde o PRD, antes do primeiro deploy em produção. Um produto já em desenvolvimento fecha as lacunas que ainda tem, sem refazer o que já está validado.

Um produto já em produção é auditado regra a regra, com prioridade para o que protege dados de clientes primeiro — segredos, isolamento e acessos — e a documentação depois.

Nenhuma destas regras é decorativa: cada uma existe porque fecha uma forma concreta e conhecida de um sistema falhar.