---
name: linguagem-ubiqua
description: Extrai um glossário de linguagem ubíqua no estilo DDD da conversa atual, sinalizando ambiguidades e propondo termos canônicos. Salva em UBIQUITOUS_LANGUAGE.md. Use quando o usuário quiser definir termos do domínio, construir um glossário, consolidar terminologia, criar uma linguagem ubíqua, ou mencionar "modelo de domínio" ou "DDD".
disable-model-invocation: true
---

# Linguagem Ubíqua

Extrai e formaliza a terminologia do domínio da conversa atual em um glossário consistente, salvo em um arquivo local.

## Processo

1. **Varrer a conversa** em busca de substantivos, verbos e conceitos relevantes ao domínio
2. **Identificar problemas**:
   - Mesma palavra usada para conceitos diferentes (ambiguidade)
   - Palavras diferentes usadas para o mesmo conceito (sinônimos)
   - Termos vagos ou sobrecarregados
3. **Propor um glossário canônico** com escolhas opinativas de termos
4. **Escrever em `UBIQUITOUS_LANGUAGE.md`** no diretório de trabalho usando o formato abaixo
5. **Exibir um resumo** inline na conversa

## Formato de Saída

Escreva um arquivo `UBIQUITOUS_LANGUAGE.md` com esta estrutura:

```md
# Linguagem Ubíqua

## Ciclo de vida do pedido

| Termo           | Definição                                                  | Aliases a evitar         |
| --------------- | ---------------------------------------------------------- | ------------------------ |
| **Pedido**      | Solicitação de um cliente para comprar um ou mais itens    | Compra, transação        |
| **Nota fiscal** | Solicitação de pagamento enviada ao cliente após a entrega | Boleto, fatura, cobrança |

## Pessoas

| Termo       | Definição                                 | Aliases a evitar          |
| ----------- | ----------------------------------------- | ------------------------- |
| **Cliente** | Pessoa ou organização que realiza pedidos | Comprador, conta, usuário |
| **Usuário** | Identidade de autenticação no sistema     | Login, conta              |

## Relacionamentos

- Uma **Nota fiscal** pertence a exatamente um **Cliente**
- Um **Pedido** gera uma ou mais **Notas fiscais**

## Diálogo de exemplo

> **Dev:** "Quando um **Cliente** faz um **Pedido**, criamos a **Nota fiscal** imediatamente?"
> **Especialista de domínio:** "Não — uma **Nota fiscal** só é gerada após a confirmação de um **Fulfillment**. Um único **Pedido** pode gerar múltiplas **Notas fiscais** se os itens forem enviados em **Remessas** separadas."
> **Dev:** "Então se uma **Remessa** for cancelada antes do envio, não existe **Nota fiscal** para ela?"
> **Especialista de domínio:** "Exatamente. O ciclo de vida da **Nota fiscal** está atrelado ao **Fulfillment**, não ao **Pedido**."

## Ambiguidades sinalizadas

- "conta" foi usado para se referir tanto a **Cliente** quanto a **Usuário** — são conceitos distintos: um **Cliente** realiza pedidos, enquanto um **Usuário** é uma identidade de autenticação que pode ou não representar um **Cliente**.
```

## Regras

- **Seja opinativo.** Quando existirem múltiplas palavras para o mesmo conceito, escolha a melhor e liste as demais como aliases a evitar.
- **Sinalize conflitos explicitamente.** Se um termo for usado de forma ambígua na conversa, destaque na seção "Ambiguidades sinalizadas" com uma recomendação clara.
- **Inclua apenas termos relevantes para especialistas do domínio.** Ignore nomes de módulos ou classes a menos que tenham significado na linguagem do domínio.
- **Mantenha as definições enxutas.** Máximo de uma frase. Defina o que o termo É, não o que ele faz.
- **Mostre relacionamentos.** Use nomes de termos em negrito e expresse cardinalidade quando óbvia.
- **Inclua apenas termos do domínio.** Ignore conceitos genéricos de programação (array, função, endpoint) a menos que tenham significado específico no domínio.
- **Agrupe termos em múltiplas tabelas** quando surgirem agrupamentos naturais (ex: por subdomínio, ciclo de vida ou ator). Cada grupo recebe seu próprio título e tabela. Se todos os termos pertencem a um único domínio coeso, uma tabela é suficiente — não force agrupamentos.
- **Escreva um diálogo de exemplo.** Uma conversa curta (3-5 trocas) entre um dev e um especialista de domínio que demonstre como os termos interagem naturalmente. O diálogo deve clarificar fronteiras entre conceitos relacionados e mostrar os termos sendo usados com precisão.

<exemplo>

## Diálogo de exemplo

> **Dev:** "Como testo o **serviço de sync** sem Docker?"

> **Especialista de domínio:** "Forneça a **camada de filesystem** em vez da **camada Docker**. Ela implementa a mesma interface de **Sandbox service**, mas usa um diretório local como **sandbox**."

> **Dev:** "Então o **sync-in** ainda cria um **bundle** e o desempacota?"

> **Especialista de domínio:** "Exatamente. O **serviço de sync** não sabe com qual camada está se comunicando. Ele chama `exec` e `copyIn` — a **camada de filesystem** apenas executa esses comandos como comandos shell locais."

</exemplo>

## Re-execução

Quando invocada novamente na mesma conversa:

1. Leia o `UBIQUITOUS_LANGUAGE.md` existente
2. Incorpore novos termos das discussões subsequentes
3. Atualize definições se o entendimento tiver evoluído
4. Ressinalize novas ambiguidades
5. Reescreva o diálogo de exemplo incorporando os novos termos