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.