Regressivo por funcionalidade

O brabo-qa não aprova só "a stack sobe": ele tem um regressivo por funcionalidade do Brabo. Toda PR que mexe numa funcionalidade roda o regressivo dela, para atestar que ela não foi afetada. Na dev isso não bloqueia nada; na main o catálogo inteiro roda e vale como portão. A decisão está no ADR 0268.

O catálogo e o mapa

brabo-qa/funcionalidades.yml guarda as 14 funcionalidades (autenticação, sessão e canal, turno do agente, aprovações, time e handoffs, projetos, git, backlog, gates, container e broker, runner, providers e gasto, RAG e grafo, instalação) e, para cada uma, os globs de caminho por repositório. O id é estável e nunca é renomeado; aposentar é status: aposentada. A spec do Playwright se liga à funcionalidade pela tag do próprio teste ({ tag: '@f-<id>' }), e o filtro é --grep. Mora no brabo-qa (e não no brabo-contracts, consumido por tag) para que ajustar o mapa seja uma PR só (RN-1031).

PR para a dev: atesta, não bloqueia

1. O job regressivo-dev do qa-e2e-gatilho.yml do brabo-ci cruza os arquivos da PR com o mapa.
2. Três regras valem antes do mapa (RN-1033): docs e testes do repositório não tocam funcionalidade (neutral); lockfile, Dockerfile, entrada da app, schema e a subida de TAG do contracts rodam o catálogo inteiro; caminho sem dono no mapa roda o smoke instalacao + autenticacao e é listado como "sem dono no mapa".
3. O brabo-qa roda as specs das funcionalidades tocadas contra a imagem sha-<12> do head da PR, que o ci.yml publica e assina só para PR do próprio repositório; PR de fork não recebe segredo e fica sem regressivo (RN-1035).
4. O resultado volta como o check Regressivo do brabo-qa (success, failure ou neutral).

Esse check nunca é exigido. Nenhum ruleset o cita e o merge segue livre com ele vermelho (RN-1032). O nome é distinto do E2E do brabo-qa de propósito, para não se confundir com o portão da main.

PR para a main: o catálogo inteiro

O check E2E do brabo-qa (ADR 0267) roda todas as specs e traz a tabela funcionalidade | specs | resultado. Funcionalidade do catálogo sem spec aparece como "sem cobertura" e não reprova (RN-1034); hoje essa é a situação de 10 das 14, e cada uma deixa a lista quando ganha uma spec. O /qa-aceitar <justificativa> do dono segue valendo para vermelho de spec ou ambiente.

A regra do card

PR que toca uma funcionalidade do catálogo ajusta o regressivo dela no brabo-qa contra a dev, ou diz no card por que não precisa. Quando um card entra, o levantamento avalia se ele mexe numa funcionalidade e anota os id do catálogo. Se o mapa diz que a funcionalidade foi tocada e nenhuma spec @f-<id> mudou, o App comenta uma vez na PR, como lembrete.

O que o run mostra

Cada run do regressivo mostra o resultado por funcionalidade, e não só o bloco de specs. O grafo ganha um job Funcionalidade · <id> para cada funcionalidade com spec executada, verde ou vermelho. O Summary traz o veredito, a recomendação, a tabela, as falhas sem ANSI, o flaky, uma seção por funcionalidade e o link do HTML do Playwright. Cada spec que falhou vira anotação no arquivo dela. A spec sem tag @f-* aparece como "sem funcionalidade" e nunca some do relatório. Os números e as opções descartadas estão no ADR 0277.

O relatório de decisão

O brabo-qa gera um relatório (relatorio-regressivo.md, derivado de um relatorio-regressivo.json) com a recomendação que compõe a decisão: aprovar, aceitar com justificativa ou bloquear. A regra é fixa e está em RN-1051: digest ou assinatura bloqueia; spec em funcionalidade que a PR toca bloqueia; spec fora do que a PR toca, ou sem funcionalidade, pede aceite com justificativa. Quando o dono aceita um vermelho com /qa-aceitar, o check preserva esse relatório e registra o aceite contra a recomendação (RN-1052).

Na main o relatório é o portão. Na dev ele é só o atestado, e nada bloqueia.

O que o regressivo não cobre

O brabo-runner não tem regressivo no catálogo: a PR dele se atesta pelo próprio CI (o binário linux-x64 entra na PR, runner#28), e o contrato runner ↔ engine só é provado no TP-01 (RN-1075, no brabo-ci).

O que isto custa

Uma PR para a dev gasta de 8 a 12 minutos assíncronos de CI no brabo-qa e de 3 a 5 minutos no CI do repositório (a imagem). Os repositórios são públicos, e o runner padrão não consome minutos pagos. Os golden-sets (conhecimento, gates) continuam agendados: o resumo cita o último run, sem rodar na PR.

Para ver de qual run do Actions saiu cada resultado, e que irmãos ele leu, veja os Vínculos no Summary (ADR 0271).