# Rubrica: Qualidade de Código (Peso 25%)

Avalia naming, ausência de code smells e aderência aos padrões do stack do projeto.

## Score 9-10 — Exemplar

- Nomes de variáveis, funções e classes comunicam intenção sem precisar de comentários.
- Funções com responsabilidade única: cada função faz uma coisa e tem no máximo 20-25 linhas.
- Classes com responsabilidade única: coesas, sem mistura de concerns.
- Zero duplicação óbvia — lógica repetida foi extraída.
- **Nada do que foi criado aqui já existia no projeto**: os conceitos novos batem com o veredito do `reuse-map.md`, e cada `CRIAR` tem justificativa que se sustenta.
- Segue os padrões do stack conforme os standards do projeto (ex: Result pattern para .NET, hooks pattern para React).
- Sem "dead code" — sem variáveis não usadas, sem blocos comentados, sem imports desnecessários.

## Score 7-8 — Bom

- Nomes claros na maioria dos casos, com raras abreviações não óbvias.
- Funções e classes bem dimensionadas com poucos casos acima do ideal.
- Duplicação mínima e pontual.
- No máximo um conceito recriado que já existia no codebase, com impacto pequeno e localizado.
- Segue padrões do stack com desvios isolados e justificáveis.
- Sem dead code significativo.

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

- Alguns nomes genéricos ou pouco descritivos (`data`, `result`, `temp`).
- Funções longas (>30 linhas) ou com múltiplas responsabilidades.
- Duplicação perceptível que aumenta custo de manutenção.
- Um ou dois tipos/componentes recriados que já existiam em outro arquivo do projeto.
- Desvios dos padrões do stack sem justificativa.
- Dead code pontual.

## Score 3-4 — Problemático

- Nomes que exigem contexto externo para entender o que representam.
- Funções com >50 linhas ou classes com >200 linhas sem coesão.
- Duplicação significativa: mesma lógica em múltiplos lugares.
- Conceito central do domínio redeclarado na MESMA feature (o caso `SimpleBuilding`: cinco cópias na mesma pasta, uma já divergindo do resto).
- Não segue os padrões do stack — código parece escrito para outro contexto.

## Score 1-2 — Reprovado

- Nomes arbitrários ou gerados automaticamente sem semântica.
- Funções/classes sem separação de responsabilidades — "god objects".
- Duplicação massiva ou copy-paste evidente.
- Ignora por completo o que o projeto já tem: o `reuse-map.md` mandou REUSAR e o código criou do zero.
- Completamente fora dos padrões do stack — exige reescrita.

> **O escopo desta dimensão é o CODEBASE, não só o diff.** "Duplicação" lê-se
> naturalmente como repetição *dentro do que foi escrito* — e foi assim que
> `SimpleBuilding` foi redefinido cinco vezes na mesma pasta do ProspectPRO sem
> que nenhuma avaliação pegasse: cada diff, sozinho, parecia limpo. Antes de
> pontuar, pergunte de fora do diff. Ferramentas: o `reuse-map.md` da feature
> (`2-plan/reuse-map.md`) diz o que o plano decidiu; `morph-spec graph explain
> <símbolo>` diz o que existe de fato (**sem grafo: `grep -rn "<símbolo>"`**);
> o nó `validators` do `morph-spec verify` já traz os achados do validador
> `reuse`. Um símbolo criado contra um veredito `REUSAR` é achado desta
> dimensão, mesmo que o código esteja impecável por dentro.

## Teto de prova de observabilidade GenAI

Quando a feature **chama LLM**, o avaliador aplica também
`.morph/framework/evals/proof-rubrics/observabilidade-genai.md` e grava a nota sob a chave `obs` na
linha `**Proof-Scores:**`. Ela **não** é dimensão do composto — nenhum peso muda — e entra aqui como
teto sobre esta dimensão:

| Proof-Score `obs` | teto nesta dimensão |
|---|---|
| 9 a 10 | sem teto |
| 7 a 8 | 9 |
| 4 a 6 | 7 |
| 0 a 3 | 5 |

A rubrica pergunta a **propriedade** ("dá para reconstruir o que foi ao provedor, e o que ele
respondeu, neste turno?"), não a tecnologia: telemetria própria com teste de fidelidade alcança a
faixa mais alta tanto quanto um span OpenTelemetry.

**Aplicabilidade tem duas etapas, e ela NÃO se declara determinística** (a versão anterior se
declarava, e errava na primeira feature que encontrou): (1) **filtro mecânico de alta recall** — o
`mandate.md` cita ao menos um standard `ai-agents`; falso ⇒ `not_evaluated`. (2) **determinação
escrita pelo avaliador** — a feature entrega código que **chama um modelo**? — registrada **com o
motivo** no relatório. Tasks com `group` em `{docs, tests}` são **indício** contra, não veredito.
`not_evaluated` **não aplica teto**, e um `not_evaluated` sem motivo escrito não é dispensa. Sem a
chave `obs` no `**Proof-Scores:**`, também não há teto a aplicar.

## Perguntas de avaliação

1. É possível entender o que uma função faz apenas pelo seu nome e assinatura?
2. Alguma função tem mais de 30 linhas ou mais de uma responsabilidade clara?
3. Há lógica duplicada que poderia ser extraída?
3b. **O que foi criado aqui já existia no projeto?** Confira os tipos, componentes, hooks e serviços novos contra o `reuse-map.md` e contra o grafo — e diga no relatório o que você conferiu.
4. O código segue os padrões definidos nos standards do projeto?
5. Há variáveis não usadas, imports desnecessários ou blocos comentados?