Contexto de Domínio e Passagem de Decisões

Gerencie "o que esses termos de negócio significam" separadamente de "por que esta opção foi escolhida". Não crie um "esqueleto" vazio quando não houver conteúdo estável.

Artefato de Contexto de Domínio: Apenas Linguagem de Domínio

Quando termos exigem explicação repetida, um termo tem múltiplos significados ou linguagem pouco clara causa erros de limite de módulo, primeiro reutilize o glossário/documento de modelo de domínio existente do repositório ou a função context em .governance/docs-map.json. Somente quando não existir um equivalente, crie preguiçosamente o CONTEXT.md padrão de templates/context.example.md.

Registre apenas:

• Termos de domínio e definições precisas;
• Relações entre conceitos centrais;
• Ambigüidades confirmadas e a interpretação escolhida;
• Ambigüidades ainda aguardando confirmação de um proprietário de domínio.

Não inclua detalhes de implementação, estado atual, cronogramas de tarefas, requisitos completos, justificativa de decisão ou histórico. Mantenha-os em código/MAP, STATUS/Rastreador de Issues, Spec, ADR e LOG, respectivamente. Os termos devem ser rastreáveis a código, contratos ou evidências de negócio. Marque itens não confirmados como needs confirmation; não adivinhe.

Passagem de ADR: Reutilize a Capacidade Existente

Esta habilidade não define um segundo diretório de ADR, esquema de numeração, ciclo de vida ou modelo. Quando uma decisão é difícil de reverter, confundiria um leitor futuro sem contexto e envolve um tradeoff real:

1. Leia e execute architecture-decision-records, preservando a localização e o formato de ADR existentes do repositório.
2. Se não houver convenção, deixe que essa habilidade escolha a localização mínima viável; não crie um sistema separado aqui.
3. Vincule ao ADR de CONTEXT.md, do mapa do projeto ou da Spec/Issue relevante em vez de copiar o corpo da decisão.
4. Quando uma decisão for aceita, substituída ou descontinuada, anexe um evento ao histórico do projeto de acordo com as regras do documento vivo.

Detalhes de implementação rotineiros, mudanças facilmente reversíveis e experimentos de curta duração não precisam de ADRs.

Quando Ativar

• Termos de domínio são reexplicados repetidamente ou linguagem ambígua causa desvio na implementação.
• O projeto precisa de um ponto de entrada estável para a linguagem de domínio, mas não tem um documento equivalente.
• O trabalho de contexto descobre uma decisão duradoura que deve ser passada para architecture-decision-records.

Quando Usar

Use esta habilidade quando a linguagem de domínio estável precisar de um lar único e com base em evidências, ou quando o trabalho de contexto revelar uma decisão difícil de reverter que pertence ao sistema de ADR existente do repositório.

Como Funciona

1. Reutilize o contexto mapeado ou o artefato de glossário quando um existir; crie CONTEXT.md apenas quando não houver uma fonte de verdade equivalente disponível.
2. Registre definições precisas de domínio, relações, interpretações confirmadas e ambiguidades explicitamente não confirmadas, sem misturar estado de implementação ou tarefa.
3. Encaminhe tradeoffs duradouros para architecture-decision-records e vincule o ADR resultante em vez de copiar sua justificativa para documentos de contexto.
4. Mantenha cronogramas, bloqueios e status de execução no rastreador de issues existente.

Exemplos

• Defina um termo de negócio sobrecarregado uma vez e vincule-o ao código ou contrato que prova seu significado.
• Marque uma interpretação de domínio como needs confirmation até que um proprietário de domínio a resolva.
• Passe uma decisão duradoura de armazenamento ou limite para o fluxo de trabalho de ADR existente e vincule-a a partir do artefato de contexto.

Antipadrões

• Copiar tarefas atuais, cronogramas, requisitos completos ou detalhes de implementação para CONTEXT.md.
• Criar arquivos de contexto vazios ou um segundo sistema de ADR por completude.
• Tratar interpretações de domínio não confirmadas como fatos, ou copiar corpos de ADR para mapas e logs.

Habilidades Relacionadas

• architecture-decision-records: a única metodologia de ADR para decisões difíceis de reverter.
• living-docs-governance: manutenção do ciclo de vida para o mapa do projeto, status e histórico.
• docs-governance: roteamento entre capacidades e ordem de encerramento.

Limites de Cronograma e Tarefa

Mantenha tarefas, status, bloqueios e cronogramas no rastreador existente do projeto, como GitHub Issues ou Linear, como a única fonte de verdade. Use .scratch/ local apenas quando não houver um rastreador externo e o projeto o adotar explicitamente. Não coloque cronogramas em CONTEXT.md, ADRs, PROJECT_STATUS ou no banco de dados de índice de histórico.