@polymorphism-tech/morph-spec 4.22.0 → 6.0.0

package/framework/commands/morph-proposal.md

@@ -1,210 +1,54 @@
 ---
-description: MORPH Spec Pipeline — creates or resumes feature planning through proposal, design, plan, and tasks phases with mandatory approval pauses. Use whenever the user wants to plan, spec, or design a new feature, or when they say /morph-proposal. This is the primary entry point for all MORPH-SPEC feature work.
+description: Inicia uma nova feature MORPH-SPEC. Roda morph-brainstorming para entender negócio + escanear stack, depois morph-plan para produzir spec/mandate/tasks. Pausa nos Gates 1 e 2.
 argument-hint: <feature-name>
-allowed-tools: Read, Write, Edit, Bash, Glob, Grep, AskUserQuestion
+allowed-tools: Read, Write, Edit, Bash, Glob, Grep, Agent, AskUserQuestion, Skill
 ---
 
-# MORPH Spec Pipeline
+# /morph-proposal — NLH Pipeline
 
-Guide a feature through the full planning pipeline (proposal through tasks) with mandatory approval pauses at each gate.
+Conduz a feature do request inicial até o Gate 2 (plano aprovado), sem intervenção do usuário entre os gates.
 
----
-
-## 1. Resume Logic
-
-Check if the feature already has state:
-
-```bash
-morph-spec state get {feature-name}
-```
-
-- **Exists:** Read the current phase and resume from where it stopped (skip completed phases). Create pipeline master tasks (Step 6) and mark already-completed phases as `completed`.
-- **Does not exist:** Start from scratch (PHASE 0)
-
----
-
-## 2. PHASE 0: PROPOSAL
-
-### Step 1: Load project context
-
-Read these files to understand the project before writing anything:
-- `.morph/context/README.md` — project overview, tech stack, architecture
-- `.morph/config/config.json` — project configuration (language, workflow, architecture style)
-
-### Step 2: Detect agents
-
-Read `framework/agents.json` (or `.morph/framework/agents.json` in client projects). For each agent:
-1. Check if `always_active: true` — include automatically
-2. Compare agent `keywords[]` and `domains[]` against the feature description — include on match
-3. **Document false-positive exclusions**: for agents that match on keywords but are irrelevant to this feature, note why they were excluded (this helps audit agent selection later)
-
-Register each selected agent:
-```bash
-morph-spec state add-agent {feature-name} {agent-id}
-```
-
-### Step 3: Determine if UI/UX phase is needed
-
-If `ui-designer` is among the selected agents, the feature will trigger the UI/UX phase later. Note this decision — it affects the pipeline path.
-
-### Step 4: Create proposal
+## Argumentos
 
-Read the proposal template at `framework/templates/docs/proposal.md` first, then create:
+`{feature-name}` — nome em kebab-case da feature.
 
-```
-.morph/features/{feature-name}/
-  0-proposal/proposal.md
-```
+## Fluxo
 
-Fill every section of the template. In particular:
-- **Metadata table**: date, author, status, priority, stack
-- **Problem Statement**: use the What/Who/Impact structure from the template
-- **Proposed Solution**: technical approach, key features, user journey
-- **Success Metrics**: quantified current vs target values
-- **Scope**: explicit In Scope, Out of Scope, and Future Considerations
-- **Risks**: table with likelihood, impact, mitigation
-- **Dependencies**: checklist of prerequisites
-- **Estimated Effort**: broken down by phase (in hours)
-- **Questions & Open Points**: seed 3-6 questions to be resolved during the design phase
+1. **Detecta contexto:** verifica se `.morph/features/{feature-name}/` já existe.
+   - Se existe e tem `0-proposal/proposal.md`: pular para passo 3.
+   - Se não existe: criar a estrutura e seguir o passo 2.
 
-### Step 5: Register state
+2. **Invocar `morph-brainstorming`** (skill em `framework/skills/core/morph-brainstorming/`):
+   - Faz até 4 perguntas de negócio via AskUserQuestion.
+   - Roda Explore subagent para detectar stack e estado do codebase.
+   - Produz `proposal.md` em `.morph/features/{feature-name}/0-proposal/`.
+   - Apresenta o **Gate 1**.
 
-```bash
-morph-spec state init {feature-name}
-morph-spec state set {feature-name} status draft
-morph-spec state mark-output {feature-name} proposal
-```
+3. **Aguardar aprovação do Gate 1.**
+   - Resposta válida: "aprovado", "pode avançar", "lgtm".
+   - Se ajustes solicitados: aplicar e reapresentar o gate.
 
-### Step 6: Create pipeline master tasks
+4. **Após Gate 1, invocar `morph-plan`** (skill em `framework/skills/core/morph-plan/`):
+   - Lê `proposal.md`.
+   - Produz `spec.md`, `mandate.md`, `tasks.md` em `.morph/features/{feature-name}/2-plan/`.
+   - Apresenta o **Gate 2** com template fixo (ver SKILL.md passo 5).
 
-> **MANDATORY** — Create one native task per pipeline phase for progress visibility.
-> These are high-level tasks — one per phase, not per workflow step.
+5. **Aguardar aprovação do Gate 2.**
+   - Resposta válida: "pode implementar", "aprovado".
+   - Se ajustes solicitados: aplicar e reapresentar o gate.
 
-```
-TaskCreate: "Proposal"     → description: "Define feature scope and approach"
-TaskCreate: "Design"       → description: "Schema analysis, spec, contracts, decisions"
-TaskCreate: "Plan"         → description: "Implementation plan with TDD and file paths"
-TaskCreate: "Tasks"        → description: "Break spec into T001-T00N with dependencies"
-```
+6. **Após Gate 2:** sinalizar ao usuário que `/morph-apply {feature-name}` está pronto para iniciar a implementação.
 
-If `ui-designer` is among the activated agents, also create:
-```
-TaskCreate: "UI/UX"        → description: "Design system, mockups, components, flows"
-```
-
-Wire dependencies matching the phase sequence:
-- UI/UX (if created) ← Proposal
-- Design ← UI/UX (or Proposal if no UI/UX)
-- Plan ← Design
-- Tasks ← Plan
-
-Mark "Proposal" as `in_progress` immediately.
-
-### MANDATORY PAUSE
-
-Use `AskUserQuestion` to present the approval gate with these elements:
-
-1. **Proposal summary** — 3-4 sentence overview of what was proposed
-2. **Agents activated** — table showing agent ID, tier, role, and why selected
-3. **Effort estimate** — total hours from the proposal
-4. **Key decisions pending** — 2-3 design decisions that will be resolved in the design phase
-
-Options: Approve proposal / Request changes / Reject
-
-After approval:
-```bash
-morph-spec approve {feature-name} proposal
-morph-spec phase advance {feature-name}
-```
-
----
-
-## 3. PHASE 1: UI/UX (conditional)
-
-Check if `ui-designer` is in `activeAgents`:
-- **Yes:** Invoke the `morph-phase-uiux` skill. **MANDATORY PAUSE** after generating UI deliverables.
-- **No:** Skip to PHASE 2.
-
-> **Task lifecycle:** `TaskUpdate` the "Proposal" task → `completed`. `TaskUpdate` the "UI/UX" task → `in_progress` (if UI/UX), or the "Design" task → `in_progress` (if skipping UI/UX).
-
-After approval:
-```bash
-morph-spec approve {feature-name} uiux
-morph-spec phase advance {feature-name}
-```
-
----
+## Anti-padrões
 
-## 4. PHASE 2: DESIGN
+- Não pular o Gate 1 mesmo que o usuário pareça apressado — proposal.md é o contrato de escopo.
+- Não escrever código nesta fase. Apenas artefatos de planejamento.
+- Não perguntar sobre stack — o stack padrão é VSA + .NET 10 + MAF + Next.js + Neon.
 
-> **Task lifecycle:** `TaskUpdate` the completing phase task (UI/UX or Proposal) → `completed`. `TaskUpdate` the "Design" task → `in_progress`.
+## Referências
 
-Invoke the `morph-phase-design` skill.
-
-Summary: generate spec.md, contracts.cs (or contracts-vsa.cs for VSA), decisions.md with ADRs.
-
-### MANDATORY PAUSE
-
-Present: spec, contracts, decisions, effort estimate. Use `AskUserQuestion` with options: Approve design / Adjust scope / Modify contracts.
-
-After approval:
-```bash
-morph-spec approve {feature-name} design
-morph-spec phase advance {feature-name}
-```
-
----
-
-## 5. PHASE 3: PLAN
-
-> **Task lifecycle:** `TaskUpdate` the "Design" task → `completed`. `TaskUpdate` the "Plan" task → `in_progress`.
-
-Invoke the `morph-phase-plan` skill.
-
-Summary: generate a detailed implementation plan with exact file paths, TDD structure, and context-aware execution strategy.
-
-### MANDATORY PAUSE
-
-Present: implementation plan with recommended strategy. Use `AskUserQuestion` with options: Approve plan / Adjust strategy / Modify plan.
-
-After approval:
-```bash
-morph-spec approve {feature-name} plan
-morph-spec phase advance {feature-name}
-```
-
----
-
-## 6. PHASE 4: TASKS
-
-> **Task lifecycle:** `TaskUpdate` the "Plan" task → `completed`. `TaskUpdate` the "Tasks" task → `in_progress`.
-
-Invoke the `morph-phase-tasks` skill.
-
-Summary: break spec into tasks T001-TXXX with dependencies, checkpoints, estimates.
-
-### MANDATORY PAUSE
-
-Present: task breakdown, execution order, total estimate. Use `AskUserQuestion` with options: Approve tasks / Reprioritize / Add or remove tasks.
-
-After approval:
-```bash
-morph-spec approve {feature-name} tasks
-morph-spec phase advance {feature-name}
-```
-
----
-
-## 7. Planning Complete
-
-> **Task lifecycle:** `TaskUpdate` the "Tasks" task → `completed`.
-
-After task approval:
-
-```
-Planning complete! Run /morph-apply {feature-name} to start implementation.
-```
-
----
+- `framework/MORPH.md` — charter completo
+- `framework/skills/core/morph-brainstorming/SKILL.md`
+- `framework/skills/core/morph-plan/SKILL.md`
 
-**Feature requested:** $ARGUMENTS
+**Feature:** $ARGUMENTS

package/framework/commands/morph-status.md

@@ -1,71 +1,40 @@
 ---
-description: Show current MORPH project status and all features in development with their phases and approvals
+description: Show current MORPH-SPEC feature status (phase, gates, task counts)
 argument-hint: [feature-name]
 allowed-tools: Read, Bash
 ---
 
-# MORPH Project Status
+# MORPH Status
 
-Show the current MORPH project status and features in development.
+Show the status of a MORPH-SPEC feature: current phase, approval gates, and output completion.
 
 ## Usage
 
-**ALWAYS** use the state-manager CLI to get status:
-
 ```bash
-morph-spec state list
+morph-spec status <feature-name>
 ```
 
-This command automatically shows:
-- All active features
-- Current phase of each feature
-- Task progress (X/Y)
-- Active agents
-
-## Additional Checks
-
-### 1. MORPH Configuration
-- [ ] `.morph/config/config.json` configured
-- [ ] `.morph/framework/standards/` present
-
-### 2. Specific Feature Details
-
-To get detailed JSON for a feature:
+Optional flags:
+- `--json` — emit JSON for tooling
+- `-v, --verbose` — show output files and gate details
 
-```bash
-morph-spec state get {feature-name}
-```
-
-## Output
+## Resolving the active feature
 
-The `morph-spec state list` command automatically generates a formatted dashboard:
+If the user did not pass a feature name in `$ARGUMENTS`:
 
-```
-╔════════════════════════════════════════════════════════════════╗
-║                    MORPH-SPEC PROJECT STATUS                   ║
-╠════════════════════════════════════════════════════════════════╣
-║ Project: {PROJECT_NAME}                                        ║
-║ Type: dotnet-nextjs                                            ║
-╠════════════════════════════════════════════════════════════════╣
-║ FEATURES                                                       ║
-╠════════════════════════════════════════════════════════════════╣
-║  {feature-1}                                                   ║
-║    Phase: implement        | Tasks: 5/12                       ║
-║    Agents: ef-modeler hangfire-orchestrator                     ║
-╠════════════════════════════════════════════════════════════════╣
-║  {feature-2}                                                   ║
-║    Phase: design           | Tasks: 0/0                        ║
-║    Agents: None                                                ║
-╚════════════════════════════════════════════════════════════════╝
-```
+1. Read `.morph/state.json`.
+2. Pick the most recently updated feature whose `status !== 'completed'`.
+3. If none exists, ask the user which feature to inspect via `AskUserQuestion`.
 
-**Simply run the command and show the result to the user.**
+## What you display
 
-## Available Actions
+The CLI prints a banner, the phase chain (`proposal → uiux → plan → implement → review`),
+output completion (X/13 outputs), task progress, and next-step suggestions.
 
-Suggest next actions:
-- `/morph-proposal {feature}` - Create a new feature
-- `/morph-apply {feature}` - Implement a feature
+After running the CLI, summarize:
+- Current phase and which gate (if any) is open
+- Outstanding outputs for the current phase
+- Recommended next slash command (`/morph-proposal`, `/morph-apply`, or a gate approval)
 
 ---
 

package/framework/commands/morph-troubleshoot.md

@@ -69,7 +69,7 @@ site:learn.microsoft.com {error}
 **WebSearch usage example:**
 
 If the user asks about a SignalR error:
-1. First: `morph-spec troubleshoot SignalR connection`
+1. First: search standards/codebase via Grep
 2. If not found: WebSearch with `site:github.com/dotnet/aspnetcore SignalR connection closed`
 3. Return formatted relevant links
 
@@ -103,7 +103,7 @@ When finding a solution, present in the following format:
 ✅ Solution:
    {code or steps to resolve}
 
-📚 See full: morph-spec read {file}
+📚 See full: open {file}
 
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 ```

package/framework/evals/rubrics/README.md

@@ -0,0 +1,44 @@
+# 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                                                                 |
+|-------|----------------------------------------------------------------------|
+| 8-10  | Aprovado — sem output no contexto, siga para próxima tarefa          |
+| 6-7.9 | Feedback priorizado — liste o que melhorar, modelo continua          |
+| < 6   | Escale para revisão humana — relatório detalhado obrigatório         |
+
+## 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 < 8
+
+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 — continua | escalar para revisão humana]
+```
+
+Quando score ≥ 8: nenhum output. O silêncio é o sinal de aprovação.

package/framework/evals/rubrics/architecture.md

@@ -0,0 +1,46 @@
+# Rubrica: Arquitetura (Peso 30%)
+
+Avalia se a implementação segue o padrão arquitetural definido no spec.md e mandate.md.
+
+## 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.
+
+## 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?

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

@@ -0,0 +1,50 @@
+# 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.
+- 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.
+- 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.
+- 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.
+- 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.
+- Completamente fora dos padrões do stack — exige reescrita.
+
+## 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?
+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?

package/framework/evals/rubrics/contracts.md

@@ -0,0 +1,47 @@
+# 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?

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

@@ -0,0 +1,50 @@
+# 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
+
+- Happy path coberto para todos os casos de uso relevantes.
+- Edge cases críticos cobertos: null/undefined, string vazia, boundary values, coleção vazia.
+- 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).
+
+## 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.
+
+## 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
+
+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?

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

@@ -0,0 +1,42 @@
+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, Repository/UnitOfWork"
+    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