---
fonte: 01-canonicos/seed-email.md
versao_da_fonte: v0.13
secao: 02
titulo: "EM0 — por que arquivo canônico próprio"
sequencia: 4 de 17
bytes_do_corpo: 1063
md5_do_corpo: 7c395cbd1cd91084819c40f683657f85
gerado_por: 06-validacao/geradores/gen-camada-ia.py
nota: fatia GERADA — o corpo abaixo é byte a byte o trecho do canônico; edite o canônico, nunca esta fatia. Canônico inteiro em https://ds.seed.eng.br/01-canonicos/seed-email.md
---
## 2. EM0 — por que arquivo canônico próprio

**Decisão:** o sistema de e-mail vive em `seed-email.md`, arquivo canônico novo. O Project
Knowledge passa de 7 para 8 arquivos canônicos.

**Racional:** a regra-mãe do `seed-componentes.md` é "componente consome semântico, nunca
hex". O e-mail consome hex literal por impossibilidade técnica. Hospedar as duas coisas no
mesmo arquivo criaria uma exceção que contamina a leitura de todo o resto — qualquer leitor
futuro passaria a duvidar da regra. Além disso o arquivo já tem 2.372 linhas.

**Alternativas descartadas:**
- *Seção nova no `seed-componentes.md`* — rejeitada pelo conflito de regra acima.
- *Viver nas skills `seed-ds-*`* — rejeitada porque skill é **consumidora** do canônico,
  nunca a fonte. Inverter isso quebraria a cadeia de propagação do projeto.

**Precedente interno:** a decisão NM5 do §45 (iconografia) já estabeleceu esse padrão para
outro objeto — quando um domínio cresce a ponto de ter regra própria, nasce arquivo próprio
por supersede formal.

---