Spec permanente do bounded context. Vive no repo enquanto o sistema viver. Atualize quando arquitetura ou regra de domínio mudar — não quando código mudar.
Em uma frase: o que esse contexto faz e o que não faz.
Exemplo: "Analisa documentos fiscais para identificar fato gerador de PIS/COFINS, classificar regime (cumulativo/não-cumulativo), e sinalizar créditos elegíveis. Não calcula valor — isso é responsabilidade de quantifiers/pis-cofins."
De onde vêm os dados, em que formato, com quais garantias.
- Fonte primária: [bounded context anterior, ex: parsers/sped-fiscal-parser]
- Schema esperado: ver
specs/[contexto-anterior]/contracts/ - Garantias do input:
- [garantia 1, ex: documentos já validados sintaticamente]
- [garantia 2, ex: campos obrigatórios sempre presentes]
- [garantia 3, ex: valores monetários como Decimal string]
O que esse contexto produz, em que formato, com quais garantias.
- Estrutura: [tipo, ex: AnalisePisCofins]
- Schema: ver
specs/[contexto-atual]/contracts/ - Garantias do output:
- [garantia 1, ex: classificação de regime sempre presente]
- [garantia 2, ex: citação legal sempre presente para cada decisão]
- [garantia 3, ex: campos opcionais explicitamente marcados como tal]
Regras tributárias específicas codificadas neste contexto. Cada regra cita fonte legislativa.
- [Regra 1]: [descrição]. Fonte: [Lei/Decreto, artigo]
- [Regra 2]: [descrição]. Fonte: [Lei/Decreto, artigo]
- [Regra 3]: [descrição]. Fonte: [Lei/Decreto, artigo]
Exemplo:
- Regime cumulativo: Aplicável quando empresa optante do Lucro Presumido, alíquotas 0,65% PIS e 3% COFINS. Fonte: Lei 9.718/1998, art. 3º.
- Regime não-cumulativo: Aplicável quando Lucro Real, alíquotas 1,65% PIS e 7,6% COFINS, com direito a crédito. Fonte: Lei 10.637/2002 e 10.833/2003.
Casos limite conhecidos e o comportamento esperado.
- [Caso 1]: [descrição]. Comportamento: [o que fazer]. Justificativa: [por quê]
- [Caso 2]: [descrição]. Comportamento: [o que fazer]. Justificativa: [por quê]
Exemplo:
- Empresa optante muda regime durante exercício: Documentos do período anterior à mudança seguem regime antigo, posteriores seguem novo. Justificativa: princípio da irretroatividade tributária.
O que esse contexto explicitamente NÃO faz. Ajuda a evitar scope creep.
- Não calcula valor de imposto (responsabilidade do quantifier correspondente)
- Não decide se documento é fiscalmente válido (responsabilidade do parser)
- Não consulta API externa em runtime (offline-first)
- [adicionar conforme aplicável]
- Upstream: [contextos que alimentam este]
- Downstream: [contextos que consomem este]
@docs/[arquivo-tabela].md— Read when: [quando consultar]@docs/[arquivo-legislação].md— Read when: [quando consultar]
- [tabela 1, ex: alíquotas vigentes por NCM]
- [tabela 2, ex: lista de produtos monofásicos]
Como verificar que a implementação está correta.
- Casos de teste obrigatórios: [lista]
- Conformidade com legislação: [como validar — ex: comparar com cálculo de auditoria fiscal de referência]
- Regressão de regimes/períodos passados: [estratégia — ex: dataset de documentos com resultado conhecido]
Log curto de mudanças significativas. Não é changelog completo — só marcos.
- YYYY-MM-DD: Criado.
- YYYY-MM-DD: [mudança significativa, ex: adicionado tratamento de monofásicos]
- YYYY-MM-DD: [mudança significativa, ex: revisão para Reforma Tributária EC 132/2023]
Esta seção é para o processo de criação desta spec. Apagar após a spec ser revisada e aceita. Não é parte permanente do documento.
Durante a criação/revisão desta spec, ambiguidades não resolvidas:
- [pergunta] — resolver via [entrevista | consulta legislativa | ADR]
Quando todas as ambiguidades foram resolvidas e a spec está pronta para uso, apagar esta seção inteira. Spec finalizada não carrega perguntas pendentes — ou a regra está definida em "Domain rules", ou o tratamento está em "Edge cases", ou a decisão arquitetural virou ADR.