# Rubrica: Contratos (Peso 25%)

Avalia a qualidade dos tipos, validações, tratamento de erros e naming dos contratos públicos.

## Score 9-10 — Exemplar

- Todos os tipos explícitos — zero `any`, zero `object` genérico onde um tipo específico cabe.
- Campos opcionais (`?`) usados apenas onde o dado é genuinamente opcional; campos obrigatórios sem nullable desnecessário.
- Validação de input declarada em todos os endpoints/handlers (FluentValidation, Zod, ou equivalente do stack).
- Error handling explícito via Result pattern, discriminated union ou equivalente — sem exceptions para fluxo de negócio.
- Nomes seguem a convenção do projeto: PascalCase para tipos, camelCase para propriedades, verbos para comandos.

## Score 7-8 — Bom

- Tipos bem definidos com pouquíssimos `any` ou genéricos desnecessários — e onde existem, são justificados.
- Validação presente na maioria dos endpoints, com poucos casos sem cobertura.
- Error handling consistente com o padrão do projeto, com desvios pontuais.
- Nomes claros e consistentes, com raras exceções.

## Score 5-6 — Aceitável com ressalvas

- Uso de `any` ou tipos genéricos em pontos visíveis da API.
- Validação parcial — alguns endpoints sem validação de input.
- Mix de estratégias de error handling (exceptions e Result no mesmo módulo).
- Nomes inconsistentes em algumas partes.

## Score 3-4 — Problemático

- Tipos amplamente genéricos ou ausentes onde deveriam ser específicos.
- Validação de input ausente em múltiplos pontos de entrada.
- Error handling imprevisível — sem padrão claro, exceptions misturadas com retornos especiais.
- Nomes que não comunicam intenção.

## Score 1-2 — Reprovado

- Contratos sem tipos definidos ou com `any` generalizado.
- Nenhuma validação de input.
- Sem tratamento de erro — falhas em runtime sem diagnóstico útil.
- Naming arbitrário ou genérico (`data`, `obj`, `result` sem qualificador).

## Perguntas de avaliação

1. Há `any` ou tipos genéricos onde um tipo específico seria possível?
2. Todos os endpoints/handlers têm validação de input declarada?
3. O tratamento de erros segue o padrão do projeto (Result, exceções, etc.)?
4. Os nomes dos tipos e propriedades comunicam claramente o que representam?
5. Campos opcionais fazem sentido semântico, ou são opcionais por comodidade?