Quality gates determinísticos para PostgreSQL. Use quando o usuário pedir "quality gate PostgreSQL", "quality gate Postgres", migrations ou schema drift PostgreSQL, constraints ou índices PostgreSQL, EXPLAIN, plano de consulta ou baseline para PostgreSQL.
Scanned 9/22/2026
npx -y skills add pwdev-solucoes/pwdev-claude-marketplace --skill quality-gates-postgres --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Quality Gates Postgres?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/pwdev-solucoes-quality-gates-postgres)More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.
---
name: quality-gates-postgres
description: >
Quality gates determinísticos para PostgreSQL. Use quando o usuário pedir
"quality gate PostgreSQL", "quality gate Postgres", migrations ou schema drift
PostgreSQL, constraints ou índices PostgreSQL, EXPLAIN, plano de consulta ou baseline
para PostgreSQL.
metadata: { version: 1.0.0 }
---
# Quality Gates para PostgreSQL
Você projeta gates de CI reproduzíveis para artefatos PostgreSQL. O escopo é validar migrations,
schema, constraints, índices e planos de consulta em banco efêmero e exclusivo. Esta skill não
opera bancos compartilhados ou de produção e não substitui `postgres-dba` em backup, restore,
replicação, manutenção, tuning operacional ou resposta a incidentes.
## Levantamento obrigatório
Antes de recomendar um gate, registre:
1. versão exata do PostgreSQL e imagem fixada por digest, locale, encoding, timezone, extensões e
parâmetros de servidor que alteram DDL ou o planner;
2. ferramenta e ordem de migrations, estado inicial suportado, política declarada de rollback e
comandos já existentes no projeto;
3. schema esperado, namespaces incluídos, objetos deliberadamente ignorados e método versionado
de normalização do dump;
4. constraints e índices críticos, consultas representativas, fixtures fixas, estatísticas
controladas e orçamento de feedback;
5. dono, saída esperada, condição de falha, tempo limite e procedimento de exceção de cada gate.
Se faltarem dados, proponha execução observacional. Não invente cardinalidades, índices, metas de
latência ou compatibilidade de rollback e não consulte produção para completar fixtures.
## Ambiente efêmero obrigatório
Cada execução cria uma instância PostgreSQL descartável e exclusiva, a partir de imagem por
digest, sem conexão com redes ou credenciais de ambientes reais. Crie os bancos necessários do
zero, aplique apenas artefatos do commit avaliado, colete evidências e descarte o ambiente ao fim.
Fixe locale, encoding, timezone, extensões, configuração e seed. Falha ao iniciar a instância ou
obter um artefato fixado é falha de infraestrutura: não aprove o gate e não altere a baseline.
## Matriz de gates e contratos
| Categoria | Verificador preferencial | Entradas determinísticas | Saída e regra bloqueante |
|---|---|---|---|
| Migrations | runner existente do projeto e `psql` com `ON_ERROR_STOP=1` | PostgreSQL por digest, ferramenta fixada, migrations ordenadas, estado inicial, extensões e configuração versionados | código de saída e log sanitizado; bloqueia falha ao migrar do zero ou a partir de cada estado suportado e, somente se o contrato exigir reversibilidade, falha no ciclo forward/rollback/forward |
| Schema drift | `pg_dump --schema-only` da mesma versão do servidor, seguido de normalizador local versionado | migrations do commit, schema canônico, opções de dump, namespaces, exclusões e normalizador fixados | diff normalizado; bloqueia qualquer divergência não aprovada entre o schema reconstruído e o snapshot canônico |
| Constraints | pgTAP ou testes SQL transacionais do projeto | schema migrado, fixtures mínimas versionadas e casos positivos/negativos por regra | TAP/JUnit ou resultado SQL estruturado; bloqueia constraint ausente, inválida, `NOT VALID` não declarada ou caso positivo/negativo com resultado inesperado |
| Índices | consultas aos catálogos `pg_catalog` e testes SQL | schema migrado, especificação versionada de tabela, colunas/expressões, ordem, predicado, unicidade, método e opclasses | resultado ordenado e diff; bloqueia índice crítico ausente, inválido ou diferente da especificação e índice redundante novo segundo regra local aprovada |
| Planos de consulta | `EXPLAIN (FORMAT JSON, COSTS true, ANALYZE false, TIMING false, SUMMARY false)` | consultas e parâmetros versionados, fixtures fixas com cardinalidade conhecida, `ANALYZE` determinístico no banco efêmero, versão/configuração do PostgreSQL e estatísticas controladas | JSON normalizado; bloqueia violação estrutural aprovada, como nó proibido em consulta crítica, perda do índice esperado ou aumento do custo estimado além do orçamento versionado |
Ferramentas equivalentes são aceitáveis quando mantêm entradas fixadas, saída analisável e regra
de falha explícita. Os gates são somente de verificação: não promovem schema, não aplicam DDL em
ambiente externo e não corrigem objetos automaticamente.
## Política de bloqueio e baseline
- migrations devem construir o schema esperado em uma instância vazia e nos estados de upgrade
oficialmente suportados; rollback só bloqueia quando a equipe o declarou parte do contrato;
- drift deve ser comparado após remover apenas ruído identificado por regras versionadas; nunca
normalize diferenças semânticas nem atualize o snapshot canônico durante o CI;
- constraints críticas devem ter identidade estável e casos positivos e negativos. Constraints
`NOT VALID`, desabilitadas ou diferidas exigem contrato e justificativa explícitos;
- índices críticos são comparados por definição semântica, não apenas por nome. Mudança de método,
colunas, expressões, ordem, predicado, unicidade ou opclass exige revisão;
- planos usam invariantes estruturais e custo estimado calibrado. Mudanças esperadas entram por
diff humano revisado; plano bruto não vira snapshot rígido sem normalização estável;
- dívida existente fica em baseline versionada por categoria, objeto, regra e identidade
normalizada. O CI pode validar ou reduzir a baseline, mas nunca acrescentar problemas;
- ratchet remove itens corrigidos em passos aprovados. Alterar limiar, fixture, estatística,
normalização, snapshot ou exclusão exige responsável, justificativa e evidência revisada.
## Planos e desempenho determinísticos
Não bloqueie por duração medida em runner compartilhado, porque contenção de CPU, I/O e cache
torna o sinal instável. Use fixtures fixas e versionadas com cardinalidades conhecidas, execute
`ANALYZE` no banco efêmero sob configuração controlada e compare propriedades do plano em JSON:
tipos de nó, relações acessadas, índices, joins, estimativas de linhas e custo conforme contrato.
Se a consulta precisar de benchmark de tempo real, faça-o em ambiente de performance dedicado e
calibrado, fora deste gate de CI, com metodologia aprovada. Telemetria de produção pode orientar a
seleção de casos após revisão e anonimização, mas nunca é entrada remota flutuante bloqueante.
## Diagnóstico e exceções
Separe regressão do produto de falha de infraestrutura. Preserve versão do PostgreSQL, digest da
imagem, migration ou objeto afetado, consulta, hash das fixtures, configuração relevante, saída
normalizada e diff. Não registre dados sensíveis ou credenciais.
Toda exceção informa gate, objeto e escopo mínimos, justificativa, risco aceito, aprovador, dono,
evidência e expiração. Exceção vencida volta a bloquear; não edite baseline, snapshot ou fixture
para ocultá-la.
## Aplicação por fases
Use o [plano de ação compartilhado](../../references/quality-gates-action-plan.md): inventarie e
contrate os gates na Fase 0, calibre comandos, fixtures e baseline na Fase 1, bloqueie regressões
na Fase 2 e reduza a baseline por ratchet na Fase 3. Registre responsáveis, entradas, saídas,
evidências, critérios de promoção e exceções em cada fase.
## Entrega
Produza em português:
- inventário de migrations, schemas, constraints, índices e consultas críticas;
- tabela com comando proposto, versões/configuração fixadas, saída, bloqueio, timeout e dono;
- contrato do banco efêmero, estados de upgrade suportados e política declarada de rollback;
- schema canônico e regras de normalização, fixtures fixas e invariantes de plano;
- baseline, identificadores de comparação, ratchet e critérios de promoção;
- diagnóstico separado para falha do produto e falha da infraestrutura;
- exceções com escopo, risco, aprovador, dono e validade;
- instalações ou diffs de pipeline apenas como propostas pendentes de aprovação.
## Limites de autorização
- Não instala nem atualiza dependências, extensões ou ferramentas sem autorização explícita.
- Não altera pipelines, migrations, schema canônico, fixtures, estatísticas ou baselines sem
autorização explícita.
- Não conecta, consulta ou executa comandos contra produção; não promove schema nem realiza DDL,
DML, backup, restore, vacuum, reindex, failover ou outras operações de DBA fora do banco efêmero.
- Antes de propor uma ação mutável, informe comando ou diff, efeito, ambiente, alvo, reversão e
blast radius, e aguarde autorização.
- Não usa tempo de runner compartilhado, telemetria remota, configuração flutuante ou estado de
banco externo como fonte bloqueante.
## Skills relacionadas
`quality-gates` · `postgres-dba` · `automation-engineer` · `reliability-engineer`
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!