@polymorphism-tech/morph-spec 8.44.0 → 8.45.0

package/framework/evals/proof-rubrics/verde-nao-e-coberto.md

@@ -1,48 +0,0 @@
-# Prova: Verde Não É Coberto
-
-> Escopo: Gate 3 (avaliador independente). Não é dimensão do score composto — impõe **teto** em
-> Cobertura de Testes (`evals/rubrics/test-coverage.md`, seção "Tetos de prova").
-
-## O que esta prova responde
-
-Um teste que **nasce verde** nunca teve fase RED: ele afirma uma pós-condição que o backend já
-garantia antes da mudança. Ele não está errado — está **vazio**. E é indistinguível, no relatório de
-execução, de um teste que protege alguma coisa.
-
-A pergunta é: **qual asserção deste teste teria falhado ANTES da mudança?** Se nenhuma, o teste
-documenta, não cobre — e isso precisa estar **declarado**, não escondido no verde.
-
-## Bandas 0-10
-
-| 0-3 | 4-6 | 7-8 | 9-10 |
-|---|---|---|---|
-| Testes novos apresentados como cobertura sem que nenhum tenha tido fase RED. Pré-condições afirmadas em prosa/comentário, nunca medidas | Alguns testes nascem verdes e isso não é declarado. `DoesNotContain` de um item só, deixando os irmãos abertos | O relatório reconhece pelo enunciado quais testes nascem verdes e os declara. Falta a asserção positiva no campo novo ao lado do `DoesNotContain` | Cada teste que nasce verde está declarado como tal, com o motivo. Pré-condições medidas (`Assert.NotNull`), listas EXATAS em vez de negativas pontuais, e mudança de semântica coberta pelo par positivo+negativo |
-
-## Anti-padrões literais
-
-- **Pós-condição que o backend já garante apresentada como cobertura nova** — a fase RED não
-  aconteceu. Reconheça pelo ENUNCIADO ("o campo X nunca vem nulo" num campo `NOT NULL` desde a
-  migração) e **declare no relatório**. (memória: pós-condição verde-de-nascença numa feature cujo
-  contrato já a garantia no schema)
-- **Comentário que afirma um fato em vez de asserção** — `// aqui o id já existe` não falha nunca.
-  Comentário que afirma fato vira asserção **ou some**.
-- **`DoesNotContain` de UM item** — provar que "banana" sumiu deixa "maçã" e "pera" livres. Quando o
-  contrato é "só isto e nada mais", asserte a **lista exata**.
-- **Pré-condição afirmada em prosa** — "o registro existe neste ponto" precisa ser
-  `Assert.NotNull(x)`. Sem isso, um teste que passa por vacuidade (coleção vazia, nulo silencioso)
-  se lê como verde legítimo.
-- **Mudar semântica e asserir só o lado novo** — ao trocar o texto/o campo, o par é obrigatório:
-  asserção **positiva** no campo novo **e** `DoesNotContain` do texto substituído. Sem o negativo, o
-  teste passa com os dois presentes.
-
-## Como registrar no relatório
-
-Na seção de análise de cobertura, uma linha por teste que nasce verde:
-
-```markdown
-- `test/x.test.js:41` — nasce VERDE: a pós-condição P3 já era garantida pelo `NOT NULL` da coluna
-  desde a migração 0007. Documenta, não cobre. Não conta para a faixa 9-10 de Cobertura.
-```
-
-E no `**Proof-Scores:**`, a chave `verde`. Um relatório que não distingue "cobre" de "documenta"
-não pode passar de 8 nesta prova, por mais testes que tenha.

package/framework/evals/rubrics/README.md

@@ -1,45 +0,0 @@
-# Sistema de Avaliação Graduada — morph-spec NLH
-
-## Como funciona
-
-A skill `morph-eval` avalia o output de uma tarefa ou fase usando 4 dimensões.
-Cada dimensão tem uma rubrica própria. O score final é ponderado.
-
-| Dimensão            | Peso | Arquivo              |
-|---------------------|------|----------------------|
-| Arquitetura         | 30%  | architecture.md      |
-| Contratos           | 25%  | contracts.md         |
-| Qualidade de código | 25%  | code-quality.md      |
-| Cobertura de testes | 20%  | test-coverage.md     |
-
-## Escala de scores
-
-| Score | Ação                                                                                       |
-|-------|--------------------------------------------------------------------------------------------|
-| 9-10  | Aprovado — sem output no contexto, siga para próxima tarefa                                 |
-| < 9   | Feedback priorizado — alimenta o loop de correção autônomo do morph-apply (re-implementa, sem pausa humana, até 3 tentativas) |
-
-A barra de aprovação por tarefa é **9**. Abaixo disso o modelo corrige sozinho — não escala ao humano entre tarefas. A escalada humana só acontece quando o loop de correção esgota 3 tentativas sem atingir 9 (ver morph-apply/SKILL.md §3a e MORPH.md §0).
-
-## Como calcular o score composto
-
-```
-score = (arquitetura × 0.30) + (contratos × 0.25) + (qualidade × 0.25) + (testes × 0.20)
-```
-
-Arredonde para uma casa decimal.
-
-## Formato de output quando score < 9
-
-Produza exatamente este bloco (não mais, não menos):
-
-```
-Score: [X.X/10]
-  Arquitetura: X | Contratos: X | Qualidade: X | Testes: X
-Issues (ordenados por impacto):
-  - [descrição do problema mais impactante]
-  - [próximo problema]
-Ação: [feedback priorizado — alimenta o loop de correção | escalar (só após 3 tentativas)]
-```
-
-Quando score ≥ 9: nenhum output. O silêncio é o sinal de aprovação.

package/framework/evals/rubrics/architecture.md

@@ -1,103 +0,0 @@
-# Rubrica: Arquitetura (Peso 30%)
-
-Avalia se a implementação segue o padrão arquitetural definido no spec.md e mandate.md.
-
-## Verificações mecânicas obrigatórias (auto-reprovação se falhar)
-
-Estas duas checagens são objetivas — não dependem de julgamento sobre estilo — e cobrem bugs reais que
-já derrubaram uma app em produção (ver `backend/integrations/neon-auth/neon-auth.md` → "Known Failure
-Modes"). Rode ambas sempre que o diff tocar endpoints minimal API ou fetch de dados cross-camada, mesmo
-que o mandate não as mencione explicitamente. Uma violação em qualquer uma delas é bloqueante — não
-"ressalva" — independente do resto do score de arquitetura.
-
-1. **DI de todo serviço injetado em endpoint.** Para cada parâmetro de tipo serviço em uma lambda de
-   endpoint minimal API (qualquer tipo que não seja `TRequest`, `CancellationToken`, `ClaimsPrincipal`
-   ou um primitivo de rota/query), confirme que existe `AddScoped<T>()` / `AddSingleton<T>()` /
-   `AddTransient<T>()` correspondente em `Program.cs` (ou registro via assembly-scanning). Um serviço
-   não registrado é inferido como `[FromBody]` pelo Minimal API e derruba a app inteira no startup —
-   isso é "Score 1-2", não "Score 5-6 com ressalva", porque não é estilo: é a aplicação não subir.
-2. **Nenhum prefixo de rota reusado para dois propósitos.** Se o projeto tem chamadas server-direct ao
-   backend E chamadas client-side via proxy same-origin, confirme que existem DUAS constantes
-   nomeadas distintas (uma por propósito) e que nenhuma delas aparece do lado errado (grep: arquivos de
-   Server Component só importam a constante server-direct; hooks/Client Component só importam a
-   constante de proxy). Uma única constante reusada para os dois quebra silenciosamente um dos dois
-   caminhos em runtime, sem sinal em build — também bloqueante.
-
-## Score 9-10 — Exemplar
-
-- Segue o padrão de feature folder rigorosamente: cada feature tem seus próprios handlers, commands/queries, validators e endpoints.
-- Zero dependências diretas entre features — comunicação cross-feature via interface, evento ou shared kernel explícito.
-- Domain logic completamente isolado de infraestrutura: nenhum import de ORM, HTTP client ou I/O direto em objetos de domínio.
-- Inversão de dependência aplicada onde a arquitetura exige.
-
-## Score 7-8 — Bom
-
-- Segue o padrão com desvios menores e justificados.
-- Dependências cross-feature existem mas são poucas, documentadas e via abstração.
-- Pequenas impurezas de infraestrutura em domain que não afetam testabilidade.
-- Estrutura de pastas correta, responsabilidades bem definidas.
-
-## Score 5-6 — Aceitável com ressalvas
-
-- Estrutura de pastas correta mas responsabilidades começam a se misturar.
-- Dependências cross-feature sem justificativa clara.
-- Domain logic com acoplamento a infraestrutura que dificulta testes unitários.
-- Padrão seguido na maior parte, mas com violações perceptíveis.
-
-## Score 3-4 — Problemático
-
-- Desvios significativos do padrão definido no spec.md.
-- Múltiplas violações de separação de responsabilidades.
-- Feature não isolada — mudanças nela provavelmente afetam outras.
-- Difícil de testar sem mocks de infraestrutura.
-
-## Score 1-2 — Reprovado
-
-- Ignora completamente a arquitetura definida.
-- Implementação plana sem estrutura de feature.
-- Dependências circulares ou acoplamento total entre camadas.
-- Requer refatoração antes de qualquer entrega.
-- Qualquer violação das "Verificações mecânicas obrigatórias" acima (DI faltando, prefixo de rota
-  reusado) — teto de score 2 independente de quão bem o resto segue o padrão.
-
-## Perguntas de avaliação
-
-1. Os arquivos estão nas pastas corretas da feature conforme o padrão do projeto?
-2. Há imports diretos entre features sem passar por abstração?
-3. Objetos de domínio importam de infraestrutura (ORM, HTTP, I/O)?
-4. Se remover esta feature, alguma outra quebra?
-5. O padrão arquitetural descrito no spec.md foi seguido?
-6. Todo serviço injetado numa lambda de endpoint minimal API tem `AddScoped`/`AddSingleton`/
-   `AddTransient` correspondente em `Program.cs`?
-7. Se o diff tem chamada server-direct ao backend E chamada client-side via proxy para o mesmo
-   recurso, elas usam duas constantes de prefixo distintas — nenhuma reusada para o outro propósito?
-
-## Tetos de prova de mídia (Gate 3)
-
-Quando — e **somente** quando — a feature gera mídia (alguma task de `tasks.json` cita, em
-`standards[]`, um dos três standards de mídia de `ai-agents/`), o avaliador independente também
-aplica `.morph/framework/evals/proof-rubrics/media-claims.md` e grava ` media={n}` na linha
-`**Proof-Scores:**`.
-
-Ela **não** é uma quinta dimensão do composto — nenhum peso muda por causa dela. Ela entra aqui,
-como teto sobre esta dimensão, pelo mesmo mecanismo do teto de prova em Cobertura.
-
-**Por que aqui e não em Cobertura:** as quatro afirmações que ela cobra — custo, revisão humana,
-marcação, hot path não bloqueado — são **propriedades estruturais**: onde a chamada mora, que
-estados existem, o que é persistido, o que é publicado. Uma feature que gera mídia dentro do turno
-de conversa está arquiteturalmente errada, não mal testada. E há uma consequência técnica: o `min`
-que limita Cobertura é calculado sobre a lista explícita das quatro provas de evidência, com `media`
-**fora** dela — senão um `media=4` derrubaria o teto de teste por um motivo que não tem nada a ver
-com teste.
-
-| Proof-Score de media | teto nesta dimensão |
-|---|---|
-| 9 a 10 | sem teto |
-| 7 a 8 | 8 |
-| 4 a 6 | 6 |
-| 0 a 3 | 3, e o item entra como **bloqueante** listado no relatório |
-
-Sem a chave `media`, não há teto a aplicar. Mas a ausência da seção `## Mídia gerada` num relatório
-de feature que gera mídia **pausa o Gate 3** por conta própria (`src/lib/risk-detector.js`), antes
-de qualquer discussão de nota. Feature que não gera mídia é isenta automaticamente — a chave não
-aparece e o sinal é falso.

package/framework/evals/rubrics/code-quality.md

@@ -1,98 +0,0 @@
-# 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.
-- Quase nenhum comentário: nome, tipo e teste explicam o código. O que sobra é só o porquê que o código não mostra (`architecture-code-comments`), sem `///`/JSDoc que repete a assinatura, banner de seção nem história de task, UC, ADR, Gate ou avaliador.
-
-## 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.
-- Um ou outro comentário que repete o código ou doc-comment dispensável; nenhum narra o processo.
-
-## 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.
-- Comentário de processo (UC, ADR, `T{n}`, Gate, `spec.md`, mockup), comentário afirmando comportamento que nenhum teste cobra, ou `///`/JSDoc em todo membro de aplicação repetindo a assinatura.
-
-## 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.
-- Blocos longos de comentário contando a história da implementação, em vários arquivos.
-
-## 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?
-6. Algum comentário existe onde um nome, uma função extraída, um tipo ou um teste bastaria? Algum conta história de processo, repete o código ou a assinatura, ou passa de ~3 linhas sem justificar? O validador `code-budget` do nó `validators` já conta, nas linhas adicionadas, os comentários que citam processo e a densidade de comentário sobre código; leia os arquivos citados antes de pontuar.

package/framework/evals/rubrics/condensed.md

@@ -1,57 +0,0 @@
-# Rubrica Condensada — Eval Inline por Task
-
-Versão compacta das 4 rubricas completas de `.morph/framework/evals/rubrics/`, para o eval
-**inline por task** (`morph-eval` §2, escopo tarefa única). Mesmas dimensões, mesmos
-pesos, mesma régua — só menos texto por banda.
-
-> **O Gate 3 NÃO usa esta condensada.** O avaliador independente da `morph-review`
-> (persona `evaluator`, contexto fresco) sempre lê as 4 rubricas completas — a régua
-> do juiz de fase não muda. Esta condensada só corta releitura no loop intra-task.
-
-## Verificações mecânicas obrigatórias — auto-reprovação (teto 2)
-
-Se o diff toca endpoint minimal API ou fetch cross-camada, independente do resto:
-
-- Serviço injetado na lambda do endpoint sem `AddScoped`/`AddSingleton`/`AddTransient` em `Program.cs`.
-- Chamada server-direct e client-side proxy pro mesmo recurso reusando a mesma constante de prefixo.
-
-## Dimensões e pesos
-
-| Dimensão | Peso |
-|---|---|
-| Arquitetura | 30% |
-| Contratos | 25% |
-| Qualidade de código | 25% |
-| Cobertura de testes | 20% |
-
-## Bandas por dimensão
-
-| Dimensão | 1-3 | 4-6 | 7-8 | 9-10 |
-|---|---|---|---|---|
-| **Arquitetura** | Ignora a arquitetura do spec.md; sem feature folder; deps circulares; ou violação mecânica acima | Pastas corretas, responsabilidades se misturam; deps cross-feature sem justificativa; domain acoplado a infra | Desvios menores justificados; deps cross-feature via abstração; impurezas de infra pontuais | Feature folder rigoroso; zero deps cross-feature diretas; domain isolado; DI onde exige |
-| **Contratos** | Sem tipos ou `any` generalizado; zero validação; sem tratamento de erro; naming arbitrário | `any`/genérico visível; validação parcial; mix exceptions/Result; naming inconsistente | Tipos bem definidos, `any` raro e justificado; validação na maioria; erro consistente | Zero `any`; validação em todos endpoints; Result pattern/discriminated union; naming consistente |
-| **Qualidade** | Nomes arbitrários; god objects; duplicação massiva; recria o que o `reuse-map` mandou REUSAR; fora do padrão do stack | Nomes genéricos (`data`,`temp`); funções >30 linhas; duplicação perceptível; conceito da MESMA feature redeclarado; comentário que narra task/UC/ADR ou `///`/JSDoc repetindo a assinatura | Nomes claros, raras exceções; bem dimensionado; duplicação mínima; no máximo um conceito recriado | Nomes comunicam intenção; funções ≤20-25 linhas, 1 responsabilidade; zero duplicação/dead code; nada criado que já existia no projeto; quase nenhum comentário, só o porquê que o código não mostra |
-| **Testes** | Sem testes ou sem asserts reais; zero edge case; nomes genéricos | Happy path OK, edge cases parciais; erros só óbvios; testes interdependentes; teste de texto de arquivo sem substituto em runtime; cópias em vez de tabela ou excesso sem justificativa | Happy path completo; maioria dos edge cases; erros nos fluxos principais | Toda pós-condição do `usecase` tem teste; A1/A2 cobertos; edge+erro cobertos, em tabela; isolados; dentro do orçamento |
-
-> **Qualidade olha o CODEBASE, não só o diff.** Símbolo novo cujo nome já existe no projeto não aparece no diff — é preciso perguntar de fora dele. O nó `validators` do `morph-spec verify` já traz os achados do validador `reuse`; o `2-plan/reuse-map.md` diz o que o plano decidiu por conceito.
-
-> Task com `usecase: UC-nn`: pós-condição sem teste **impede a faixa 9-10** em Testes, mesmo com o resto da suíte completo (herdado de `test-coverage.md`).
-
-> Teste que só lê texto de arquivo não cobre pós-condição de comportamento: sem substituto em runtime, ela conta como sem teste (herdado de `test-coverage.md`, pergunta 7).
-
-> Orçamento por task: um teste por pós-condição + um de regressão por bug, cenários do mesmo comportamento numa tabela; teste que só fixa copy é achado (herdado de `test-coverage.md`, pergunta 8). O validador `code-budget` do nó `validators` avisa sobre teste acima de 1,5× a produção, sobre comentário que cita processo e sobre densidade de comentário acima de 1 linha a cada 10 de código.
-
-> Task de UI cuja tela tem `### Checklist de tela` no `1-design/mockups.md`: item divergente sem justificativa em `decisions.md` → teto 8 em Contratos; paginação, ordenação ou filtro que o checklist põe no servidor entregue em memória (ou ausente), ou estado vazio/carregando/erro decidido e ausente → teto 6 (herdado de `contracts.md`, "Contrato de tela").
-
-## Score composto
-
-```
-score = (arquitetura × 0.30) + (contratos × 0.25) + (qualidade × 0.25) + (testes × 0.20)
-```
-
-Arredonde para uma casa decimal. ≥9 aprova em silêncio; <9 alimenta o loop de correção do `morph-apply`.
-
-## Quando abrir a completa em vez desta
-
-Dúvida de banda, violação mecânica suspeita, ou escopo de fase (Gate 3) — abra
-`.morph/framework/evals/rubrics/{dimension}.md`. Esta condensada é o atalho do caso comum.

package/framework/evals/rubrics/contracts.md

@@ -1,67 +0,0 @@
-# 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).
-
-## Contrato de tela (feature com UI)
-
-Quando o `1-design/mockups.md` declara telas (`## Tela:`) com `### Checklist de tela`, o checklist é
-um contrato como os tipos da spec: cada item decidido (volume, paginação, ordenação, filtro, os três
-estados, mobile, abas) é conferido contra a tela **entregue** e registrado na seção `## Checklist de
-tela` do `evaluator-report.md` — uma linha por item, com o planejado, o observado e o veredito
-(`cumpre` / `diverge` / `não verificável`, com o motivo).
-
-| Achado | Teto em Contratos |
-|---|---|
-| Item `diverge` sem justificativa registrada em `decisions.md` | 8 |
-| Paginação, ordenação ou filtro que o checklist põe no servidor, entregue em memória no cliente ou ausente | 6 |
-| Estado vazio, carregando ou de erro que o checklist decide e a tela não tem | 6 |
-
-`não verificável` (stack fora do ar) não é divergência: o avaliador lê o código — a query recebe
-página e ordenação? o estado vazio existe? — e diz no veredito por onde conferiu. Itens "não se
-aplica" e a superfície não precisam de linha. Sem a seção, ou com item decidido sem linha, o
-`morph-spec gate-check` pausa o Gate 3 por conta própria, antes de qualquer nota.
-
-## 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?
-6. Em feature com UI: cada item decidido do checklist de tela foi conferido contra a tela entregue, e toda divergência tem justificativa?

package/framework/evals/rubrics/test-coverage.md

@@ -1,99 +0,0 @@
-# Rubrica: Cobertura de Testes (Peso 20%)
-
-Avalia se os testes cobrem os comportamentos esperados, são isolados e têm nomes úteis.
-
-## Score 9-10 — Exemplar
-
-- **Cada pós-condição do use case referenciado tem teste correspondente.** Se a task traz `usecase: "UC-07"`, abra `2-plan/usecases/UC-07-*.md` e percorra as pós-condições (P1, P2…): cada uma precisa de ao menos um teste que a verifique. Pós-condição sem teste **impede a faixa 9-10**, por mais completa que a suíte pareça no resto.
-- Happy path coberto para todos os casos de uso relevantes — "relevantes" são os use cases referenciados pelas tasks da feature, não uma lista implícita.
-- Fluxos alternativos do use case (A1, A2…) cobertos: são os edge cases de **comportamento** e foram declarados justamente para serem testados.
-- Edge cases críticos cobertos: null/undefined, string vazia, boundary values, coleção vazia — como linhas da tabela do comportamento (`[Theory]`/`it.each`), não como cópias do mesmo teste.
-- **Dentro do orçamento da task**: um teste por pós-condição, mais um de regressão por bug; o que passa disso tem justificativa escrita na task.
-- Casos de erro cobertos: o que acontece quando a operação falha, quando a dependência retorna erro.
-- Testes completamente isolados — cada teste pode rodar sozinho em qualquer ordem.
-- Nomes de teste descrevem o comportamento esperado: `"deve retornar erro quando email já existe"` (não `"testEmail"`).
-- Testes testam comportamento, não implementação — refatorar sem mudar comportamento não quebra testes.
-
-## Score 7-8 — Bom
-
-- Happy path coberto em todos os casos relevantes.
-- Maioria dos edge cases cobertos, com poucos gaps identificáveis.
-- Casos de erro cobertos para os fluxos principais.
-- Isolamento correto na maioria dos testes.
-- Nomes descritivos com raras exceções genéricas.
-
-## Score 5-6 — Aceitável com ressalvas
-
-- Happy path coberto, mas edge cases com cobertura parcial.
-- Casos de erro não cobertos sistematicamente — só os mais óbvios.
-- Alguns testes com dependências entre si (ordem importa).
-- Nomes misturados: alguns descritivos, outros genéricos.
-- Testes que testam implementação (dependentes de detalhes internos).
-- Cenários do mesmo comportamento copiados em N testes em vez de uma tabela, ou testes além do orçamento da task sem justificativa.
-
-## Score 3-4 — Problemático
-
-- Apenas happy path coberto, sem edge cases.
-- Testes interdependentes ou com estado compartilhado.
-- Nomes que não descrevem o comportamento testado.
-- Cobertura presente mas superficial — testes passam mas não protegem contra regressão.
-- Suíte inflada: a maior parte dos testes novos fixa texto ou repete o mesmo comportamento.
-
-## Score 1-2 — Reprovado
-
-- Ausência de testes ou testes que não verificam nada significativo.
-- Testes que sempre passam independente do comportamento (sem asserts reais).
-- Sem cobertura de qualquer edge case ou caminho de erro.
-- Nomes completamente genéricos ou numerados.
-
-## Perguntas de avaliação
-
-0. A task referencia um `usecase`? Se sim: **toda** pós-condição daquele use case tem teste correspondente? (Sem isso, o teto é 8.)
-1. O happy path está coberto para todos os casos de uso da tarefa?
-2. Os edge cases críticos (null, vazio, boundary) estão cobertos?
-3. O que acontece quando uma dependência falha — isso está testado?
-4. Os testes podem rodar em qualquer ordem sem interferir entre si?
-5. Os nomes dos testes descrevem o comportamento esperado sem precisar ler o corpo?
-6. **Esta mudança é uma CORREÇÃO? Então: o que ela abriu?** Que comportamento antes correto pode ter
-   regredido por causa dela, e existe teste que pegaria essa regressão? Toda pergunta acima olha para
-   frente (o que a mudança deve fazer); esta olha para os lados. Numa feature real, três de três
-   rodadas de correção abriram um problema novo — o fix de um shadow abriu um laço de LLM a cada 15
-   min; o fecho de um fail-open abriu um P1; a correção desse P1 saiu com meio predicado. Nenhuma
-   apareceu no score, porque score não pergunta isso. **Sem resposta a esta pergunta numa correção,
-   o teto de Cobertura é 8.**
-7. **Quantos testes desta task asseram sobre TEXTO DE ARQUIVO** (prompt, migration, config,
-   markdown, código-fonte lido como string, copy de UI, config de tenant)? **Cada um tem
-   substituto em runtime** — um teste que exercita o sistema ou, em critério sobre saída de LLM,
-   a evidência em `3-implement/evidencias/{taskId}.md` apontando um eval? Teste de texto prova a
-   VERSÃO do arquivo, não o comportamento: quando é o único teste de uma pós-condição, **a
-   pós-condição conta como sem teste** (pergunta 0 — teto 8). Exceções: pós-condição com
-   `> [!note] Por que artefato:` e o único teste de estrutura por fonte de prompt
-   (`ai-agents-testing-ai`). Medido: 12 suítes, 106 testes sobre versões superadas do prompt.
-   Teste cuja asserção é só a presença ou ausência de uma string de copy é **achado** mesmo quando
-   há teste de runtime ao lado: essa checagem é analyzer, lint ou validação no publish.
-8. **A task cabe no orçamento?** Um teste por pós-condição, mais um de regressão por bug; o
-   excesso tem justificativa na task? Cenários do mesmo comportamento estão numa tabela, e a
-   fixture é a compartilhada, não uma refeita? O validador `code-budget` do nó `validators` avisa
-   quando as linhas de teste adicionadas passam de 1,5× as de produção. Mutante sobrevivente da
-   prova de mutação se fecha apertando asserção ou somando linha de tabela: um teste novo por
-   mutante é excesso, não cobertura.
-
-## Tetos de prova (Gate 3)
-
-No Gate 3 o avaliador independente pontua **a própria evidência** 0-10 nas cinco rubricas de
-`.morph/framework/evals/proof-rubrics/` (`mutation-proof.md`, `verde-nao-e-coberto.md`,
-`fiacao.md`, `guard-cego.md`, `eval-de-modelo.md`) e grava a linha `**Proof-Scores:**` no `evaluator-report.md`.
-
-Elas **não** são dimensões do composto — nenhum peso muda por causa delas. Elas entram aqui, como
-teto sobre esta dimensão, pelo mesmo mecanismo que "pós-condição sem teste impede a faixa 9-10":
-
-| menor Proof-Score das cinco | teto nesta dimensão |
-|---|---|
-| 9 a 10 | sem teto |
-| 7 a 8 | 8 |
-| 4 a 6 | 6 |
-| 0 a 3 | 3, e o item entra como **bloqueante** listado no relatório |
-
-Sem a linha `**Proof-Scores:**`, não há teto a aplicar — mas a ausência da seção `## Mutações` num
-relatório de feature com código de produção **pausa o Gate 3** por conta própria
-(`src/lib/risk-detector.js`), antes de qualquer discussão de nota.

package/framework/evals/scenarios/dotnet-crud.yaml

@@ -1,42 +0,0 @@
-name: dotnet-crud
-description: CRUD operations for product catalog in .NET 10 VSA application with Neon PostgreSQL
-stack: dotnet-neon
-
-request: |
-  Add CRUD operations for a product catalog to the .NET 10 application.
-  Products have: name, description, price (decimal), category, imageUrl, isActive.
-  Implement using Vertical Slice Architecture with IHandler<TRequest, TResponse>,
-  Result<T> railway-oriented error handling (no exceptions in handlers),
-  sealed records for DTOs, and FluentValidation via Scrutor decorators.
-  Use IApiEndpoint auto-discovery for Minimal API route registration.
-  Include pagination for the list endpoint with TanStack Query-compatible
-  response format, search by name/category, and soft-delete (isActive flag).
-  Database is Neon PostgreSQL via EF Core + Npgsql.
-  API docs via Scalar UI.
-
-phases_to_eval:
-  - proposal
-  - spec
-  - tasks
-
-skip_implementation: true
-
-dimensions:
-  proposal:
-    completeness: "Covers all CRUD operations plus pagination, search, soft-delete, Scalar UI docs"
-    scope: "Product catalog only — no cart, orders, or user management"
-  spec:
-    specificity: "API contracts with sealed record DTOs, Result<T> return types, FluentValidation rules, specific HTTP status codes"
-    data_model: "Product entity with all fields, EF Core configuration, Neon PostgreSQL constraints"
-    architecture: "VSA feature folders, IHandler pattern, Scrutor pipeline, IApiEndpoint discovery, ApplicationDbContext direto no slice (sem repository genérico)"
-    completeness: "All CRUD endpoints, pagination params (page/pageSize), search filters, error responses via Result<T>"
-  tasks:
-    granularity: "Each task 15-60 minutes, no mega-tasks"
-    coverage: "All spec FRs mapped to at least one task"
-    ordering: "Entity/migration first, then handlers, then validation decorators, then API endpoints, then tests"
-  cross_phase:
-    fr_coverage_threshold: 0.95
-    mandate_completeness: 0.9
-
-threshold: 8.0
-max_iterations: 3

package/framework/evals/scenarios/nextjs-auth.yaml

@@ -1,38 +0,0 @@
-name: nextjs-auth
-description: OAuth2 authentication feature for Next.js + shadcn/ui application with Neon Auth
-stack: nextjs-neon
-
-request: |
-  Add user authentication to the Next.js application using Neon Auth (Better Auth).
-  Users should be able to sign in with Google OAuth, view their profile page
-  showing name, email, and avatar using shadcn/ui Card and Avatar components,
-  and sign out. Use TanStack Query for data fetching and cache management.
-  Protect authenticated routes with Next.js middleware.
-  Session data lives in the Neon PostgreSQL database.
-
-phases_to_eval:
-  - proposal
-  - spec
-  - tasks
-
-skip_implementation: true
-
-dimensions:
-  proposal:
-    completeness: "Covers sign-in, profile with shadcn/ui components, sign-out, Neon Auth session storage, middleware route protection"
-    scope: "Appropriately scoped — no admin dashboard, no multi-provider auth beyond Google"
-  spec:
-    specificity: "Each FR has testable acceptance criteria with specific status codes, Neon Auth config, TanStack Query hooks"
-    data_model: "User and Session entities defined with Prisma schema or Drizzle schema for Neon PostgreSQL"
-    architecture: "Next.js App Router structure, API routes, middleware, shadcn/ui component boundaries, TanStack Query patterns"
-    completeness: "OAuth flow via Neon Auth, token refresh, error handling, logout flow, loading states with Framer Motion"
-  tasks:
-    granularity: "Each task 15-60 minutes, no mega-tasks"
-    coverage: "All spec FRs mapped to at least one task"
-    ordering: "Dependencies respected — Neon Auth setup before routes, routes before UI, UI before tests"
-  cross_phase:
-    fr_coverage_threshold: 0.95
-    mandate_completeness: 0.9
-
-threshold: 8.0
-max_iterations: 3

package/framework/evals/suites/standard.yaml

@@ -1,5 +0,0 @@
-name: standard
-description: Core eval suite — one scenario per major stack
-scenarios:
-  - nextjs-auth
-  - dotnet-crud