# Feature Patches

Este diretório guarda **patches por feature**: arquivos extras que são copiados para o projeto gerado quando o usuário seleciona um módulo específico no wizard do CLI.

## Estado atual

Este diretório está intencionalmente vazio (só este README). Todas as features já vivem dentro de `Firebase/` e são incluídas em `cli/templates/firebase/` pelo `cli/scripts/bundle-template.js` no momento do publish. Features opcionais são controladas por `removeModuleDirs()` em `cli/lib/scaffold/shared/generator-utils.js` — quando a feature não é selecionada, sua pasta é removida do projeto gerado.

## Quando criar um patch aqui

Apenas quando a feature precisar de arquivos que **não existem** em `Firebase/`. Se o mesmo caminho já existe em `Firebase/`, **não crie patch** — o patch vai sobrescrever silenciosamente o template atualizado pela versão (provavelmente antiga) que estiver no patch, causando regressão no projeto do cliente (perda de integrações, validações, UI nova, etc.).

## Como adicionar um patch

1. Crie `features/{modulo}/`.
2. Coloque os arquivos exatamente como devem aparecer no projeto gerado (caminhos relativos à raiz do projeto).
3. Adicione o nome do módulo a `ALLOWED_FEATURE_PATCHES` em `cli/scripts/check-feature-patches.js`, com um comentário de uma linha explicando por que o patch é necessário.
4. O engine aplica os patches depois de copiar o template base e o patch do backend.

## Drift guard

`cli/scripts/check-feature-patches.js` roda no `npm prepack` (antes de qualquer `npm publish` ou `npm pack`). O build falha se:

- alguma pasta dentro de `features/` não estiver listada em `ALLOWED_FEATURE_PATCHES`, ou
- algum arquivo dentro de um patch permitido tiver caminho equivalente em `Firebase/` (significa que o patch é duplicata desatualizada).

Esse é o mecanismo que impede o cenário em que patches divergem de `Firebase/` ao longo do tempo e o CLI passa a entregar código velho para os clientes.
