Semana 25–31/05 — Governança: CODEOWNERS em todo repo + gate de autorização de deploy
CODEOWNERS chega a todos os repositórios de front — 045206ec2 no front-web-base, e93a938 no front-cactus-core, 296deb8 no front-ops, 333c4f3 no front-tests-e2e, da59ea2 no front-service-api e dfd3af6 no front-service-api-dev-proxy. A regra default é * apontando pro time de codeowners de front — qualquer arquivo do repositório passa a exigir review de quem está no time, e adicionar codeowner virou uma mudança de membro de team no GitHub em vez de edição de arquivo.
.github/ endurecido com owners explícitos — 848c853a6. A ownership default segue no time, mas .github/ (workflows e o próprio CODEOWNERS) passa a exigir aprovação nominal de dois owners específicos. A justificativa está no commit: arquivos de governança não deveriam ser mergeáveis só porque qualquer membro do time aprovou — uma aprovação futura maliciosa ou distraída bastaria pra neutralizar a proteção. A sintaxe é gitignore-like com last-match-wins: a regra mais específica abaixo substitui a default acima, não faz união.
Gate de autorização para workflow_dispatch de deploy — front-ops 5dbdcb5 adiciona o campo opcional deploy_protection.required_team no deploy.yml de cada ambiente. Quando presente, deploys manuais via workflow_dispatch naquele ambiente ficam restritos a membros do time nomeado; push (auto-deploy) nunca é gateado por esse campo e continua disparando exatamente como antes. A implementação consulta GET /orgs/.../teams/.../memberships/<actor> com um token que passou a carregar read:org, e falha rápido com erro linkando o time. Aplicado aos 13 ambientes de produção do web-base — todos sem prefixo stage-/dev-/performance-, menos os dois ambientes internos.
Gate movido pro job check — 3d645e8 (mais o gêmeo ee5751e) reposiciona a verificação: o gate é uma pré-condição, como a checagem de elegibilidade de auto-deploy que já existia, então pertence ao job que valida inputs e resolve config. O ganho concreto é a forma da falha na UI — vira check ❌ → deploy skipped em vez de check ✅ → deploy ❌, que sugeria falsamente que o deploy tinha sido tentado. Sem mudança de comportamento: mesmo schema de campo, mesmas checagens, mesmas mensagens de erro.
PWA funcionando de ponta a ponta — instalação do app agora é dinâmica por marca, cada brand tem seu próprio manifesto e ícones configurados corretamente
Correção do favicon dinâmico por brand — cada marca exibe seu favicon correto no browser e na aba
Correção da estrutura de overrides de brand para que marcas como state77, casateste e outras carreguem suas configurações sem conflito com o base
Implementado sistema centralizado de registro de rotas com tipos, mapa de caminhos e helpers (routeHref, gameHref, sportPath, routePattern, isRouteActive)
Todos os componentes, configs de header, menu, sidebar, navegação e gamificação migrados para usar os novos helpers
Suporte a override de rotas por marca: exemplo com state77 usando caminhos customizados (/casino, /deportes, /gamificacion, /jugador)
Documentação adicionada no CLAUDE.md com guia de uso do Route Registry