@polymorphism-tech/morph-spec 8.16.0 → 8.17.0

package/README.md

@@ -3,7 +3,7 @@
 > Spec-driven development framework for multi-stack projects. Turns feature requests into implementation-ready code through structured, AI-orchestrated phases.
 
 **Package:** `@polymorphism-tech/morph-spec`
-**Version:** 8.16.0  
+**Version:** 8.17.0  
 **Requires:** Node.js 22+, Claude Code
 
 ---
@@ -368,4 +368,4 @@ Code generated by morph-spec (contracts, templates, implementation output) belon
 
 ---
 
-*morph-spec v8.16.0 by [Polymorphism Tech](https://polymorphism.tech)*
+*morph-spec v8.17.0 by [Polymorphism Tech](https://polymorphism.tech)*

package/bin/morph-spec.js

@@ -26,6 +26,7 @@ import { statusCommand } from '../src/commands/project/status.js';
 import { worktreeSetupCommand, worktreeLinkCommand, worktreeListCommand } from '../src/commands/project/worktree.js';
 import { fleetCommand } from '../src/commands/project/fleet.js';
 import { claimCommand } from '../src/commands/project/claim.js';
+import { standardsCommand } from '../src/commands/project/standards.js';
 import { reportCheckCommand } from '../src/commands/state/report-check.js';
 
 // === Approval gates (human-only) ===
@@ -381,6 +382,16 @@ program
   .option('--json', 'Output as JSON')
   .action((feature, options) => claimCommand(feature, options));
 
+// ─── Standards search (server-side, R2 token cut) ─────────────────────────
+program
+  .command('standards')
+  .description('Search STANDARDS.json server-side (top 3, full digest) instead of reading the whole registry. No --find: list categories + counts')
+  .option('--find <query>', 'Search query — matches name/id, tags/aliases, category, digest')
+  .option('--category <category>', 'Restrict --find to a single category')
+  .option('--tags <tags>', 'Restrict --find to standards carrying any of these comma-separated tags')
+  .option('--json', 'Output as JSON')
+  .action((options) => standardsCommand(options));
+
 // ─── Sub-agent report protocol ────────────────────────────────────────────
 program
   .command('report-check <feature> [task]')

package/claude-plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "morph-spec",
-  "version": "8.16.0",
+  "version": "8.17.0",
   "displayName": "MORPH-SPEC Framework",
   "description": "Spec-driven development with 38 agents and 8-phase workflow for .NET/Blazor/Next.js/Azure",
   "publisher": "polymorphism-tech",

package/docs/CHEATSHEET.md

@@ -185,4 +185,4 @@ Never edited directly — go through CLI commands or `morph-spec update` instead
 
 ---
 
-*morph-spec v8.16.0 by Polymorphism Tech*
+*morph-spec v8.17.0 by Polymorphism Tech*

package/docs/QUICKSTART.md

@@ -249,4 +249,4 @@ morph-spec doctor
 
 ---
 
-*morph-spec v8.16.0 by Polymorphism Tech*
+*morph-spec v8.17.0 by Polymorphism Tech*

package/framework/CLAUDE.md

@@ -15,10 +15,10 @@ Se não houver feature ativa, pergunte ao usuário qual feature trabalhar.
 
 **NUNCA:**
 - Pular para código sem proposal aprovado (Gate 1) e plano aprovado (Gate 2).
-- Modificar o contrato do plano depois do Gate 2: `spec.md`, `mandate.md`, e os campos de plano de `tasks.json` (`title`, `description`, `dependencies`, `effort`, `doneCriteria`, `group`) estão congelados. **Os use cases (`2-plan/usecases/UC-*.md`) NÃO estão** — são editáveis por design, é assim que se muda o comportamento e se re-roda `implement`; a auditoria fica no git.
+- Modificar o contrato do plano depois do Gate 2: `spec.md`, `mandate.md`, e os campos de plano de `tasks.json` (`title`, `description`, `dependencies`, `effort`, `doneCriteria`, `group`, `agent`, `standards`) estão congelados. **Os use cases (`2-plan/usecases/UC-*.md`) NÃO estão** — são editáveis por design, é assim que se muda o comportamento e se re-roda `implement`; a auditoria fica no git.
 - Escrever critérios de aceite no `proposal.md`. O comportamento verificável mora nos use cases, cuja pós-condição precisa ser **observável em teste** e chega **literal** ao `doneCriteria` da task.
 - Editar `.morph/specs/usecases/` à mão. O acervo só se escreve pela promoção do `finish`, que lê de `2-plan/usecases/` — é ela que carimba `status: implemented` e sobrescreve por ID. Para mudar um UC existente (o caso `bug`), copie-o para o `2-plan/usecases/` da feature e corrija lá.
-- Tocar os campos de contrato do plano em `tasks.json` após o Gate 2 (`title`, `description`, `dependencies`, `effort`, `doneCriteria`, `group`) — o hook `protect-spec-files` faz diff semântico e bloqueia mudanças neles, seja via `Write` ou `Edit`. (Os campos mutáveis `status`/`outputs`/`notes` continuam graváveis por `Write` ou `Edit` — ver SEMPRE.)
+- Tocar os campos de contrato do plano em `tasks.json` após o Gate 2 (`title`, `description`, `dependencies`, `effort`, `doneCriteria`, `group`, `agent`, `standards`) — o hook `protect-spec-files` faz diff semântico e bloqueia mudanças neles, seja via `Write` ou `Edit`. (Os campos mutáveis `status`/`outputs`/`notes` continuam graváveis por `Write` ou `Edit` — ver SEMPRE.)
 - Listar perguntas em texto simples — sempre use a tool `AskUserQuestion` (1-4 perguntas por chamada).
 - Usar `Guid.NewGuid()`, classes não-sealed sem justificativa, exceptions como fluxo de controle, camada de Service/Manager entre handler e dados, repository genérico (`IRepository<T>`/`IUnitOfWork`), ou SQL cru sem justificativa.
 
@@ -29,7 +29,12 @@ Se não houver feature ativa, pergunte ao usuário qual feature trabalhar.
 - Apresentar gates com o template fixo definido em MORPH.md / morph-plan. **A pergunta PRECISA nomear a feature** ("Gate 2 — Plano de {feature} aprovado?"): é por esse nome que o hook `state-sync` atribui a aprovação ao `feature.json` certo, na árvore certa. Sem nome, e havendo mais de uma feature na árvore, ele **recusa a gravar** e avisa — adivinhar já carimbou um Gate 2 na feature errada. Nesse caso aprove com `morph-spec approve <feature> <gate>`.
 - Registrar decisões não triviais em `decisions.md`.
 - Aplicar `morph-eval` após cada tarefa; silêncio em score ≥ 9 é o sinal correto. Score < 9 dispara o loop de correção autônomo (re-implementa, sem pausa), não escala ao humano entre tarefas. No Gate 3, o score composto da feature vem do **avaliador independente** despachado pela `morph-review` (persona `evaluator`, contexto fresco) — nunca de auto-avaliação de quem implementou.
-- Incluir as 3 cláusulas do contrato do relatório final em todo dispatch de sub-agent (**o sub-agent GRAVA o relatório em arquivo canônico ANTES de encerrar — `.morph/features/{f}/3-implement/reports/{taskId}.md`, ou `4-review/evaluator-report.md` para o avaliador — com os 4 itens obrigatórios (o quê / arquivos / problemas / auto-score 0-10); esse arquivo é o valor de retorno autoritativo, a última mensagem de texto é cortesia best-effort e pode não chegar inteira; ainda assim não chamar `SendMessage`, que gera um evento a mais e custa um turno inútil**; não tocar tasks.json/feature.json/board; sem build/test da suíte compartilhada em batch paralelo) — templates em `morph-implement` §4 e `morph-apply` §3b. **O orquestrador lê o arquivo ao retomar controle** — nunca confia só na mensagem de retorno da tool.
+- **Contrato do relatório final** em todo dispatch de sub-agent:
+  1. Grava o relatório em arquivo canônico ANTES de encerrar — `.morph/features/{f}/3-implement/reports/{taskId}.md` (avaliador: `4-review/evaluator-report.md`) — com os 4 itens obrigatórios (o quê / arquivos / problemas / auto-score 0-10). Esse arquivo é o retorno autoritativo, não a mensagem final; nunca chamar `SendMessage`.
+  2. Não tocar `tasks.json`/`feature.json`/`state.json` nem o board de sessão — estado é do orquestrador.
+  3. Sem build/test da suíte compartilhada em batch paralelo sem isolamento (verificação é do orquestrador, pós-batch).
+
+  Racional completo: `MORPH.md` §6. Templates curtos: `morph-implement` §4, `morph-apply` §3b. **O orquestrador lê o arquivo ao retomar controle** — nunca confia só na mensagem de retorno da tool.
 
 ## Slash commands
 

package/framework/MORPH.md

@@ -199,7 +199,7 @@ O índice de standards fica em `framework/standards/STANDARDS.json`. Cada entrad
 
 **Fluxo de consulta:**
 
-1. Antes de iniciar uma tarefa, identifique de 1 a 3 standards relevantes pelo `id` ou `tags`.
+1. Antes de iniciar uma tarefa, identifique de 1 a 3 standards relevantes — rode `morph-spec standards --find "<domínio/tecnologia da task>"` (o comando devolve o top 3 como `id · path · digest`, sem você abrir o índice inteiro) em vez de filtrar `id`/`tags` à mão no JSON.
 2. Leia apenas o arquivo `.md` daquele standard específico — o path está no campo `path` do JSON.
 3. Aplique o standard durante a implementação. Se precisar de contexto adicional, leia mais um standard.
 4. Registre no recap.md qual standard foi consultado e como foi aplicado.

package/framework/evals/rubrics/condensed.md

@@ -0,0 +1,49 @@
+# Rubrica Condensada — Eval Inline por Task
+
+Versão compacta das 4 rubricas completas de `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; fora do padrão do stack | Nomes genéricos (`data`,`temp`); funções >30 linhas; duplicação perceptível | Nomes claros, raras exceções; bem dimensionado; duplicação mínima | Nomes comunicam intenção; funções ≤20-25 linhas, 1 responsabilidade; zero duplicação/dead code |
+| **Testes** | Sem testes ou sem asserts reais; zero edge case; nomes genéricos | Happy path OK, edge cases parciais; erros só óbvios; testes interdependentes | 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; isolados |
+
+> 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`).
+
+## 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
+`framework/evals/rubrics/{dimension}.md`. Esta condensada é o atalho do caso comum.

package/framework/hooks/claude-code/core/protect-spec-files.js

@@ -41,6 +41,15 @@ import { validateTasksDoc, outputsDivergenceViolations } from '../../shared/task
  * Compare two tasks.json structures and return the list of plan-contract
  * violations — changes that touch anything other than the mutable fields.
  *
+ * Frozen-by-default, not an enumerated frozen list: the loop below walks the
+ * UNION of old/new task keys and flags any key not in `mutableFields`. A new
+ * plan-contract field (e.g. `agent`/`standards`, stamped by morph-plan — R2
+ * token-cut) needs NO entry added here to become protected; it is frozen the
+ * moment it exists on a task, simply by never being added to
+ * MUTABLE_SPEC_FIELDS (output-schema.js → `npm run generate` →
+ * framework/hooks/shared/phase-utils.js). Only fields that must stay
+ * EDITABLE post-Gate-2 (today: status, outputs, notes) belong in that list.
+ *
  * @param {object} oldDoc - parsed previous file content
  * @param {object} newDoc - parsed proposed file content
  * @param {string[]} mutableFields - field names allowed to change

package/framework/rules/morph-task-tracking.md

@@ -49,8 +49,10 @@ touching ONLY the mutable fields:
 - `notes` — free-text record (deviations, context, resolved blockers)
 
 The plan contract — `title`, `description`, `dependencies`, `effort`, `doneCriteria`,
-`group` — is frozen after Gate 2. Any attempt to change it is blocked by the
-`protect-spec-files` hook.
+`group`, `agent`, `standards` — is frozen after Gate 2. Any attempt to change it is
+blocked by the `protect-spec-files` hook. `agent` (persona id, no `morph-` prefix)
+and `standards` (paths pinned by morph-plan) are optional — legacy plans without
+them remain valid.
 
 Use the `Write` tool (whole-file rewrite) OR the `Edit` tool — `Edit` is allowed
 as long as it touches only `status`, `outputs`, and `notes`. State is then synced

package/framework/schemas/tasks.schema.json

@@ -30,6 +30,16 @@
             "type": "string",
             "pattern": "^UC-\\d+$",
             "description": "ID of the use case this task realizes (2-plan/usecases/UC-{nn}-{slug}.md). Optional: technical tasks with no observable behaviour have none."
+          },
+          "agent": {
+            "type": "string",
+            "minLength": 1,
+            "description": "Persona id assigned by morph-plan for this task — the bare framework/agents.json id, no 'morph-' prefix (e.g. \"dotnet-senior\"). Optional. Part of the plan contract: frozen after Gate 2."
+          },
+          "standards": {
+            "type": "array",
+            "items": { "type": "string", "minLength": 1 },
+            "description": "Standards pinned by morph-plan for this task, as paths relative to the framework root (e.g. \"standards/backend/dotnet/vsa-handler-patterns.md\"). Optional. Part of the plan contract: frozen after Gate 2."
           }
         },
         "additionalProperties": false

package/framework/skills/core/create-umbraco-lp/SKILL.md

@@ -4,7 +4,7 @@ description: Guia a criação de uma landing page nova ponta-a-ponta a partir do
 version: core
 when-to-invoke: ao iniciar um novo projeto de LP com o template Umbraco genérico
 user-invokable: true
-cliVersion: "8.16.0"
+cliVersion: "8.17.0"
 ---
 
 # create-umbraco-lp

package/framework/skills/core/migrate-lp-to-umbraco/SKILL.md

@@ -4,7 +4,7 @@ description: Migra uma landing page existente (React/Vite, Next.js estático ou
 version: core
 when-to-invoke: ao receber instrução "use /migrate-lp-to-umbraco {projeto}" do usuário, ou quando o usuário descrever necessidade de migrar uma LP para Umbraco
 user-invokable: true
-cliVersion: "8.16.0"
+cliVersion: "8.17.0"
 ---
 
 # migrate-lp-to-umbraco

package/framework/skills/core/morph-apply/SKILL.md

@@ -4,7 +4,7 @@ description: Orquestra a execução autônoma de tasks de uma feature morph-spec
 version: core
 when-to-invoke: após Gate 2 aprovado, ao receber instrução "use /morph-apply" ou "implementar feature"
 user-invokable: true
-cliVersion: "8.16.0"
+cliVersion: "8.17.0"
 ---
 
 # morph-apply
@@ -78,10 +78,22 @@ while (true):
   // Entre tasks NÃO há pausa humana: score < 9 dispara re-implementação, não AskUserQuestion.
   attempt = 0
   best = { score: 0, output: null }
+  skillLoaded = false   // true assim que Skill(morph-implement) foi invocada nesta sessão
   while attempt < 3:
     attempt += 1
-    invoke Skill(morph-implement) with task
-      (no attempt > 1: passar o feedback priorizado da tentativa anterior como input)
+
+    if attempt == 1 or not skillLoaded:
+      // attempt 1 sempre invoca — é o que carrega mandate/spec/standard/persona
+      // pela primeira vez. Reinvoca também se skillLoaded caiu para false (ver nota).
+      invoke Skill(morph-implement) with task
+        (no attempt > 1: passar o feedback priorizado da tentativa anterior como input)
+      skillLoaded = true
+    else:
+      // attempt > 1, skill já em contexto desde attempt 1: NÃO reinvoque a Skill —
+      // aplique o feedback priorizado direto ao código já implementado (mesma
+      // lógica do passo 1 do morph-implement, "isto NÃO é implementação do zero",
+      // só que sem reler o documento inteiro da skill de novo).
+      aplicar feedback priorizado da tentativa anterior ao código já implementado
 
     // CÓDIGO ANTES DO JUIZ — barreira determinística e barata (build+testes+validadores).
     run: morph-spec verify {feature} {task.id} --json
@@ -115,14 +127,18 @@ while (true):
 
 > **Verify vermelho consome uma tentativa** do loop (≤3) e devolve `feedback[]` acionável (erros de build, falhas de teste, issues de validador). O `morph-eval` NUNCA é invocado sobre código que não passou no verify — o juiz julga arquitetura/contratos/qualidade, o que o código determinístico não pega sozinho. Código roda antes, grátis; o juiz gasta tokens só no que sobra.
 
+> **Retry sem re-invoke — e a exceção que evita rodar sem a skill.** `skillLoaded` cai de volta para `false` (forçando reinvocação no próximo attempt) se houver `/compact` OU troca de sessão (nova sessão retomando via `handoff.md`) entre a última invocação e o attempt corrente — os dois eventos podem descartar o conteúdo da skill do seu contexto sem avisar. Sem essa exceção, um retry pós-compact aplicaria feedback sem o mandate/standard/persona carregados. Fora desses dois casos, reinvocar a Skill só para aplicar um feedback pontual é exatamente o custo repetido (~13KB por tentativa) que este corte existe para eliminar.
+>
+> **Isto vale para a LEITURA da skill pelo orquestrador — não para o conteúdo de um dispatch.** Se o attempt 1 foi despachado a um sub-agent (§3b) e o attempt 2 também dispara os gatilhos de dispatch do `morph-implement` §4, o prompt de dispatch completo é reenviado normalmente: o sub-agent de um novo dispatch não tem o contexto do attempt anterior, então o corte de reinvoke não se aplica a ele. O que muda aqui é só a leitura da skill pelo ORQUESTRADOR no loop sequencial inline.
+
 > **Por que loop e não pausa:** MORPH.md §0 manda auto-avançar entre tasks. Score baixo numa task individual é um problema de qualidade que o modelo deve **corrigir sozinho**, não delegar ao humano no meio da implementação. A pausa só existe quando o loop de correção se esgota (3 tentativas) — o "escape" do modelo autônomo. O trust mode não muda esse loop: ele governa os **gates** (proposal/plan/review), não o ciclo de correção intra-task.
 
 ### 3b. Modo Paralelo (para o subset independente)
 
 **Antes de despachar, escope cada agente ao seu domínio.** Um agente genérico sem persona nem standard não "conhece" as convenções daquele domínio — produz código fora do padrão. Para cada fluxo/task a despachar, resolva:
 
-- **Subagent:** em `.morph/framework/agents.json`, encontre o agente cujo `domains` cobre o `group`/domínio da task (ex: `backend` → `dotnet-senior`, `frontend` → `nextjs-expert`/`ui-designer`, `database` → `ef-modeler`). O `subagent_type` do dispatch é **`morph-{id}`** (ex.: `morph-dotnet-senior`) — os subagents são gerados de `agents.json` na instalação e a persona já é o **system prompt** deles; não a cole no prompt.
-- **Standard(s):** do array `standards` desse mesmo agente em `agents.json` (e/ou do `mandate.md`), selecione o(s) path(s) `.md` relevante(s) à task.
+- **Subagent:** use `task.agent` (id da persona, sem prefixo `morph-`) já carimbado em `tasks.json` pelo `morph-plan` §5a — o `subagent_type` do dispatch é **`morph-{task.agent}`** (ex.: `morph-dotnet-senior`). **Fallback (plano legado, task sem `agent`):** em `.morph/framework/agents.json`, encontre o agente cujo `domains` cobre o `group`/domínio da task (ex: `backend` → `dotnet-senior`, `frontend` → `nextjs-expert`/`ui-designer`, `database` → `ef-modeler`).
+- **Standard(s):** use `task.standards` quando presente; senão, do array `standards` do agente resolvido acima em `agents.json` (e/ou do `mandate.md`), selecione o(s) path(s) `.md` relevante(s) à task.
 - **Fallback (tipo não registrado):** se `morph-{id}` não estiver na sua lista de subagent types (stack não instalado neste projeto), use `subagent_type: "general-purpose"` colando o campo `persona` no prompt — e **registre nas `notes` da task**: `dispatch-fallback: general-purpose ({id} não registrado)`. O recap deve refletir o mecanismo real.
 
 ```
@@ -137,34 +153,29 @@ dispatch Agent (subagent_type: "morph-{id}") with prompt:
     Contrato do relatório final:
     1. GRAVE um relatório por task concluída em
        `.morph/features/{feature}/3-implement/reports/{taskId}.md` ANTES de
-       encerrar — mesmo quando esta sessão cobre várias tasks do fluxo, um
-       arquivo por task. Esse arquivo é o valor de retorno autoritativo; a sua
-       última mensagem de texto é cortesia best-effort e pode não chegar
-       inteira ao orquestrador (o evento recebido às vezes é só um
-       idle_notification, sem texto). Ainda assim NÃO chame SendMessage: ele
-       gera um evento a mais além da notificação de término, custando um turno
-       inútil ao orquestrador. Relatório ausente, oco, ou sem os itens abaixo,
-       é falha de protocolo.
-    2. NÃO toque em tasks.json, feature.json, state.json nem no board de sessão
-       (TaskCreate/TaskUpdate) — todo estado (status de task, scores, gates) é
-       gravado exclusivamente pelo orquestrador.
+       encerrar (um arquivo por task, mesmo cobrindo várias tasks do fluxo
+       numa sessão só) — é o retorno autoritativo, não a sua mensagem final
+       (que é cortesia best-effort e pode não chegar inteira). NÃO chame
+       SendMessage.
+    2. NÃO toque em tasks.json, feature.json, state.json nem no board de
+       sessão (TaskCreate/TaskUpdate) — todo estado (status de task, scores,
+       gates) é gravado exclusivamente pelo orquestrador.
     3. Verificação condicional ao isolamento:
        - Batch SEM isolamento (working tree compartilhada): NÃO rode build/test da
          suíte compartilhada — edições concorrentes quebram o build umas das outras;
-         a verificação é do orquestrador, uma vez, pós-batch (`morph-spec verify`).
+         a verificação é do orquestrador, pós-batch (`morph-spec verify`).
        - Batch COM isolamento (você recebeu `isolation: "worktree"`): rode build/test
          DENTRO do seu worktree; commite seu trabalho na branch do worktree como
-         último ato antes do relatório; reporte a branch + status de build no
-         relatório; NUNCA faça merge nem toque na árvore principal.
-
-    Seu relatório final deve conter:
-      - sumário das mudanças
-      - arquivos modificados (paths)
-      - standard(s) consultado(s)
-      - auto-score 0-10 (rubric: completeness, correctness, mandate compliance)
+         último ato antes do relatório; reporte a branch — nunca faça merge nem
+         toque na árvore principal.
+
+    Seu relatório final deve conter APENAS: (1) o que foi feito em 2-3
+    frases, (2) arquivos modificados, (3) problemas encontrados e como foram
+    resolvidos, (4) auto-score 0-10 com justificativa em uma linha. Relatório
+    ausente, oco, ou sem os 4 itens, é falha de protocolo.
 ```
 
-> Este template é deliberadamente paritário com o template sequencial em `morph-implement` §4: ambos despacham o **subagent registrado do domínio (`morph-{id}`)** com standard escopado e as mesmas cláusulas do contrato do relatório final. A única diferença é que aqui múltiplos agentes rodam ao mesmo tempo, um por fluxo independente.
+> Este template é deliberadamente paritário com o template sequencial em `morph-implement` §4: ambos despacham o **subagent registrado do domínio (`morph-{id}`)** com standard escopado e as **mesmas 3 cláusulas curtas** do contrato do relatório final e os mesmos 4 itens de relatório — racional completo em `MORPH.md` §6. A única diferença é que aqui múltiplos agentes rodam ao mesmo tempo, um por fluxo independente.
 
 > **Alternativa quando os fluxos tocam os mesmos projetos/arquivos** (ex.: o mesmo csproj de testes compartilhado): siga a §3b-w abaixo em vez desta seção — despache com `isolation: "worktree"`, cada agente trabalha numa working tree própria e o orquestrador integra ao final.
 
@@ -247,10 +258,11 @@ O comando grava `gateDecisions.review = { pause, reason, signals, trust, decided
 
 ## Referências
 
-- `.morph/framework/MORPH.md` — charter NLH
-- `framework/skills/core/morph-implement/SKILL.md`
+- `.morph/framework/MORPH.md` — charter NLH; §6 tem o racional completo do contrato do relatório final (aqui e no `morph-implement` §4 estão só as versões curtas coladas no dispatch)
+- `framework/skills/core/morph-implement/SKILL.md` — §4 tem o template sequencial paritário a este §3b
 - `framework/skills/core/morph-eval/SKILL.md`
 - `framework/skills/core/morph-review/SKILL.md`
+- `framework/skills/core/morph-plan/SKILL.md` §5a — resolve e carimba `task.agent`/`task.standards` no plano; fonte primária deste §3b
 - `morph-spec dag {feature}` — análise de DAG e decisão sequencial vs paralelo (ponderada por effort), incluindo recomendação de isolamento (`isolation.recommended: "worktree"`)
 - `morph-spec verify {feature} [task] --json` — cadeia determinística build+testes+validadores (código antes do juiz)
 - `morph-spec score {feature} {task} {score} [--dims a,c,q,t]` — grava taskScores no feature.json com timestamp server-side

package/framework/skills/core/morph-brainstorming/SKILL.md

@@ -4,7 +4,7 @@ description: Entende o negócio, os usuários e a arquitetura antes de qualquer
 version: core
 when-to-invoke: ao receber um novo request de feature, antes de morph-plan
 user-invokable: true
-cliVersion: "8.16.0"
+cliVersion: "8.17.0"
 ---
 
 # morph-brainstorming

package/framework/skills/core/morph-eval/SKILL.md

@@ -4,7 +4,7 @@ description: Avalia a qualidade de uma tarefa ou fase com rubricas graduadas 0-1
 version: core
 when-to-invoke: ao completar uma tarefa ou ao finalizar uma fase de implementação
 user-invokable: false
-cliVersion: "8.16.0"
+cliVersion: "8.17.0"
 ---
 
 # morph-eval
@@ -19,21 +19,23 @@ Também invocado ao receber o retorno de um sub-agent com auto-score < 7.
 
 **Somente após `morph-spec verify {feature} {task}` verde** (a `morph-apply` garante isso no loop §3a). O verify é a barreira determinística (build+testes+validadores); esta skill julga o que o código não pega: arquitetura, contratos, qualidade, cobertura qualitativa.
 
-> **Escopo de fase (Gate 3):** a avaliação da feature inteira NÃO é feita por quem implementou — a `morph-review` despacha a persona `evaluator` de `agents.json` (contexto fresco, sem autoria; recebe mandate + diff + saída real dos testes) usando esta skill como guia. O eval por task pode ser inline; o score composto do Gate 3 vem sempre do avaliador independente.
+> **Escopo de fase (Gate 3):** a avaliação da feature inteira NÃO é feita por quem implementou — a `morph-review` despacha a persona `evaluator` de `agents.json` (contexto fresco, sem autoria; recebe mandate + diff + saída real dos testes) usando esta skill como guia, **sempre com as 4 rubricas completas** — nunca a condensada, que é exclusiva do eval inline por task. O eval por task pode ser inline; o score composto do Gate 3 vem sempre do avaliador independente, com a régua completa.
 
 ## O que fazer
 
 0. Confirme que o `morph-spec verify` da task está verde (a morph-apply passa o resultado; numa invocação manual, rode `morph-spec verify {feature} {task} --json`). Se estiver vermelho, NÃO avalie — devolva o `feedback[]` do verify ao loop de correção.
 
-1. Identifique o escopo da avaliação: tarefa única ou fase completa.
+1. Identifique o escopo da avaliação: tarefa única (eval inline) ou fase completa (Gate 3).
 
-2. Para cada dimensão, leia a rubrica correspondente em `.morph/framework/evals/rubrics/`:
-   - `architecture.md` — peso 30% — vertical slice, separação de responsabilidades, infra
-   - `contracts.md` — peso 25% — tipos, validação, tratamento de erros, naming
-   - `code-quality.md` — peso 25% — naming, ausência de code smells, padrões do stack
-   - `test-coverage.md` — peso 20% — happy path, edge cases, isolamento, naming de testes
+2. Leia a rubrica correspondente ao escopo:
+   - **Tarefa única (eval inline, o caso comum):** leia SÓ `.morph/framework/evals/rubrics/condensed.md` — tabela única com as 4 dimensões e seus pesos, condensada das completas. Não abra as 4 rubricas completas para esse escopo; a condensada é fiel a elas (dimensões e pesos idênticos, enforced por `scripts/check-rubric-parity.js`).
+   - **Fase completa (Gate 3):** o avaliador independente despachado pela `morph-review` (persona `evaluator`, contexto fresco) usa **sempre** as 4 rubricas completas — a régua do juiz de Gate 3 não muda:
+     - `architecture.md` — peso 30% — vertical slice, separação de responsabilidades, infra
+     - `contracts.md` — peso 25% — tipos, validação, tratamento de erros, naming
+     - `code-quality.md` — peso 25% — naming, ausência de code smells, padrões do stack
+     - `test-coverage.md` — peso 20% — happy path, edge cases, isolamento, naming de testes
 
-3. Atribua um score de 1 a 10 para cada dimensão seguindo as bandas da rubrica.
+3. Atribua um score de 1 a 10 para cada dimensão seguindo as bandas da rubrica (condensada ou completa, conforme o passo 2).
 
 4. Calcule o score composto: (arch × 0.30) + (contracts × 0.25) + (quality × 0.25) + (tests × 0.20).
 
@@ -53,9 +55,10 @@ Também invocado ao receber o retorno de um sub-agent com auto-score < 7.
 
 ## Referências
 - `morph-spec verify {feature} [task] --json` — barreira determinística (build+testes+validadores) que precede esta skill
-- `.morph/framework/evals/rubrics/architecture.md` — rubrica de arquitetura (30%)
-- `.morph/framework/evals/rubrics/contracts.md` — rubrica de contratos (25%)
-- `.morph/framework/evals/rubrics/code-quality.md` — rubrica de qualidade (25%)
-- `.morph/framework/evals/rubrics/test-coverage.md` — rubrica de cobertura (20%)
+- `.morph/framework/evals/rubrics/condensed.md` — rubrica condensada (4 dimensões + pesos), usada no eval INLINE por task
+- `.morph/framework/evals/rubrics/architecture.md` — rubrica completa de arquitetura (30%) — Gate 3, avaliador independente
+- `.morph/framework/evals/rubrics/contracts.md` — rubrica completa de contratos (25%) — Gate 3, avaliador independente
+- `.morph/framework/evals/rubrics/code-quality.md` — rubrica completa de qualidade (25%) — Gate 3, avaliador independente
+- `.morph/framework/evals/rubrics/test-coverage.md` — rubrica completa de cobertura (20%) — Gate 3, avaliador independente
 - `.morph/framework/evals/trace-schema.md` — formato canônico do trace
 - `.morph/framework/MORPH.md` — seção 1 (papel Evaluator)

package/framework/skills/core/morph-hotfix/SKILL.md

@@ -4,7 +4,7 @@ description: ADW cirúrgico de hotfix — resolve uma queda/bug crítico de prod
 version: core
 when-to-invoke: ao receber "/morph-hotfix {feature}", quando a morph-proposal classifica o pedido como workType hotfix (Passo 0), ou o usuário diz "produção caiu / hotfix / urgente"
 user-invokable: true
-cliVersion: "8.16.0"
+cliVersion: "8.17.0"
 ---
 
 # morph-hotfix

package/framework/skills/core/morph-implement/SKILL.md

@@ -4,7 +4,7 @@ description: Guia a execução de cada tarefa de implementação com standard e
 version: core
 when-to-invoke: ao iniciar cada task de implementação listada em tasks.json
 user-invokable: false
-cliVersion: "8.16.0"
+cliVersion: "8.17.0"
 ---
 
 # morph-implement
@@ -18,23 +18,28 @@ Ao iniciar cada task de `tasks.json` — antes de escrever qualquer código. Nor
 
 ## O que fazer
 
-1. **Garanta que o conteúdo do plano está no seu contexto antes de implementar** — `mandate.md`, `spec.md` e `decisions.md` de `.morph/features/{feature}/2-plan/`. Se você não tem o conteúdo atual desses arquivos em contexto (sessão fresca / cold start de `/morph-apply`, ou conteúdo possivelmente desatualizado), **use a tool Read para carregá-los**: primeiro `mandate.md`, depois `spec.md`, depois `decisions.md`.
+1. **Leia o plano integral na primeira task da sessão.** No cold start (primeira task que você implementa nesta sessão — início de `/morph-apply`, ou a primeira depois de um `/compact`), **use a tool Read** em `mandate.md`, `spec.md` e `decisions.md` de `.morph/features/{feature}/2-plan/`, nessa ordem, e mantenha-os em contexto pelo resto da sessão. Nunca implemente a primeira task da sessão sem o mandate em contexto.
 
-   > Por que "garanta que está em contexto" e não "sempre Read": numa sessão quente, onde você acabou de escrever esses arquivos no mesmo turno, o conteúdo já está disponível e um Read seria redundante. Mas o contrato é o conteúdo estar em contexto — não confie em cache de turnos anteriores que pode ter sido truncado ou evictado. Na dúvida, Read. Nunca implemente sem o mandate em contexto.
+   **Nas tasks seguintes da MESMA sessão, não releia por padrão.** O conteúdo carregado na task anterior continua válido — o contrato do plano está congelado pós-Gate 2 (`protect-spec-files` bloqueia mudança nos campos de contrato), então reler os três arquivos a cada task é custo sem sinal novo. Releia (o arquivo relevante, não necessariamente os três) só quando:
+   - houve `/compact` desde a última leitura — o compact pode ter descartado o conteúdo do contexto; ou
+   - a task corrente referencia um FR ou uma decisão que você não tem em contexto — dúvida legítima, não default cego.
+
+   > "Na dúvida, Read" continua valendo — mas como **gatilho** de releitura pontual (compact, ou lacuna de conteúdo específico), nunca como default de reler tudo a cada task. Isso é o que muda: o contrato deixou de ser "por task" e passou a ser "por sessão".
 
    Do `mandate.md`, identifique os standards obrigatórios e patterns proibidos. Do `spec.md`, a arquitetura e as seções de FRs referenciadas pela `description` da task corrente. Do `decisions.md`, as ADRs já registradas — para não contradizê-las nem re-decidir o que já foi decidido.
 
    **Se a `morph-apply` passou `feedback` de uma tentativa anterior** (loop de correção — a task foi implementada mas o `morph-eval` deu score < 9): isto NÃO é uma implementação do zero. Leia o feedback priorizado, identifique os pontos bloqueantes listados, e **corrija especificamente esses pontos** no código já existente. Não reescreva o que já passou; foque no que o eval apontou. Registre no recap qual feedback foi endereçado em qual tentativa.
 
 2. Identifique o standard mais relevante para a tarefa atual:
-   - Consulte `framework/standards/STANDARDS.json` — filtre por `category` e `tags`.
-   - **Use a tool Read no arquivo `.md` do standard identificado** (campo `path` no JSON) — não baste o digest do index; abra o arquivo. O index só diz que o standard existe; as convenções estão no `.md`.
+   - Rode `morph-spec standards --find "<domínio/tecnologia da task>"` (filtros opcionais `--category`, `--tags`, `--json`) — o comando busca em `framework/standards/STANDARDS.json` e devolve o top 3 candidatos como `id · path · digest`, sem você abrir o index inteiro.
+   - **O digest decide a escolha.** Escolha 1-3 standards pelo `digest` retornado. Depois, **use a tool Read APENAS no(s) arquivo(s) `.md` escolhido(s)** (campo `path` do resultado) — o digest te diz qual candidato é o certo; o arquivo escolhido se lê inteiro, porque é onde vivem as convenções aplicáveis.
    - **Tarefas de agente de IA (MAF):** Read os `framework/standards/ai-agents/*.md` relevantes para a task. Mesmo que você consulte docs externas (context7) para a superfície da API do `Microsoft.Agents.AI`, as **convenções de projeto** (single-agent por padrão, provider/caching/observability, A2A, middleware) vêm desses standards. Uma fonte externa não as conhece.
    - Se nenhum standard cobrir o caso, registre no decisions.md e adote o critério mais conservador.
 
 3. Identifique a persona de agente adequada para a tarefa:
-   - **Use a tool Read em `.morph/framework/agents.json`** — não recupere a persona de memória. O registro existe para ser consultado; pular o Read significa que a persona vira um rótulo inventado em vez de uma seleção auditável. Encontre o agente cujo `domains` cobre o domínio da tarefa.
-   - Leia o campo `persona` do agente e adote esse ponto de vista durante a implementação. O array `standards` desse agente é o ponto de partida para o passo 2.
+   - **Fonte primária: `task.agent` do tasks.json.** O `morph-plan` já resolveu `agents.json` uma vez no momento do plano e carimbou `agent` (id da persona, sem prefixo `morph-`) e `standards` por task (ver `morph-plan` §5a) — use esses campos diretamente, sem reabrir `agents.json`.
+   - **Fallback — plano legado (task sem `agent`):** **use a tool Read em `.morph/framework/agents.json`** — não recupere a persona de memória. Encontre o agente cujo `domains` cobre o domínio da tarefa e leia o campo `persona` para adotar o ponto de vista durante a implementação.
+   - O array de standards — `task.standards` quando presente, ou o `standards` do agente lido no fallback — é o ponto de partida do passo 2.
    - O `**Persona:**` que você grava no recap (passo 6) **deve** refletir o mecanismo REAL usado: `morph-{id}` (dispatch pelo subagent registrado), `general-purpose (fallback: {id})` (tipo não registrado — registre também nas `notes` da task), ou `inline ({id})` (você executou inline adotando a persona). É assim que o reviewer audita contra o que o runtime realmente registrou — uma auto-declaração que não casa com o dispatch é drift.
 
 4. Decida se a task deve ser despachada para um sub-agent. Dispatch é o **default** para o caso pesado/multi-domínio (ver `.morph/framework/MORPH.md` seção 6) — despache quando a task dispara qualquer gatilho:
@@ -49,7 +54,7 @@ Ao iniciar cada task de `tasks.json` — antes de escrever qualquer código. Nor
 
    > **Relação com `morph-spec dag`:** a decisão do DAG (na `morph-apply` §2) governa o **paralelismo ENTRE tasks** — quantos sub-agents rodam ao mesmo tempo. Os gatilhos acima governam o **dispatch INDIVIDUAL desta task**. São ortogonais e coexistem: `DAG: sequencial` NÃO significa "tudo inline" — significa "uma task por vez, na ordem". Exemplo: cadeia única backend de 12 tasks (DAG: sequencial); T7 tem effort L → despache T7 sozinha para `morph-dotnet-senior` e aguarde o retorno antes de seguir; T8 (S, mesmo domínio) roda inline.
 
-   **Se for despachar — use `subagent_type: "morph-{id}"` do agente identificado no passo 3.** Os subagents são gerados de `agents.json` na instalação (`.claude/agents/morph-{id}.md`) e a persona é o **system prompt** deles — não a cole no prompt. **Fallback:** se `morph-{id}` não estiver na sua lista de subagent types (stack não instalado), use `general-purpose` colando o campo `persona` no prompt e registre nas `notes` da task: `dispatch-fallback: general-purpose ({id} não registrado)`. Template do prompt:
+   **Se for despachar — use `subagent_type: "morph-{id}"` do agente identificado no passo 3.** Os subagents são gerados de `agents.json` na instalação (`.claude/agents/morph-{id}.md`) e a persona é o **system prompt** deles — não a cole no prompt. **Fallback:** se `morph-{id}` não estiver na sua lista de subagent types (stack não instalado), use `general-purpose` colando o campo `persona` no prompt e registre nas `notes` da task: `dispatch-fallback: general-purpose ({id} não registrado)`. Template do prompt (cláusulas do relatório em forma curta — racional completo em `MORPH.md` §6):
    ```
    Implementar [ID]: [title da task]
 
@@ -59,27 +64,22 @@ Ao iniciar cada task de `tasks.json` — antes de escrever qualquer código. Nor
    Done quando: [doneCriteria do tasks.json]
 
    Contrato do relatório final:
-   1. GRAVE seu relatório em `.morph/features/{feature}/3-implement/reports/[ID].md`
-      ANTES de encerrar — esse arquivo é o valor de retorno autoritativo desta
-      sessão. A sua última mensagem de texto é cortesia best-effort: pode não
-      chegar inteira ao orquestrador (o evento recebido às vezes é só um
-      idle_notification, sem texto). Ainda assim NÃO chame SendMessage: ele
-      gera um evento a mais além da notificação de término, custando um turno
-      inútil ao orquestrador. Relatório ausente, oco, ou sem os 4 itens abaixo,
-      é falha de protocolo.
+   1. GRAVE `.morph/features/{feature}/3-implement/reports/[ID].md` ANTES de
+      encerrar — é o retorno autoritativo, não a sua mensagem final (que é
+      cortesia best-effort e pode não chegar inteira). NÃO chame SendMessage.
    2. NÃO toque em tasks.json, feature.json, state.json nem no board de sessão
-      (TaskCreate/TaskUpdate) — todo estado é gravado exclusivamente pelo
-      orquestrador.
+      — todo estado é gravado exclusivamente pelo orquestrador.
    3. Verificação condicional ao isolamento: em batch paralelo SEM isolamento,
       NÃO rode build/test da suíte compartilhada — a verificação
-      (`morph-spec verify`) é do orquestrador, uma vez, pós-batch. Em batch
-      COM `isolation: "worktree"`, rode build/test dentro do seu worktree,
-      commite na branch do worktree como último ato antes do relatório
-      e reporte a branch — nunca faça merge.
+      (`morph-spec verify`) é do orquestrador, pós-batch. Em batch COM
+      `isolation: "worktree"`, rode build/test no seu worktree, commite na
+      branch do worktree como último ato antes do relatório — nunca faça merge.
 
    Seu relatório (no arquivo, e na mensagem final quando ela chega) deve conter
    APENAS: (1) o que foi feito em 2-3 frases, (2) arquivos modificados,
-   (3) problemas encontrados e como foram resolvidos, (4) auto-score 0-10.
+   (3) problemas encontrados e como foram resolvidos, (4) auto-score 0-10 com
+   justificativa em uma linha. Relatório ausente, oco, ou sem os 4 itens, é
+   falha de protocolo.
    ```
    Após o retorno do dispatch: **leia primeiro** `.morph/features/{feature}/3-implement/reports/[ID].md`
    — é o valor de retorno autoritativo. Trate a mensagem de texto do sub-agent, se chegou inteira,
@@ -154,8 +154,9 @@ Ao iniciar cada task de `tasks.json` — antes de escrever qualquer código. Nor
 - Trace em `.morph/traces/` gerado automaticamente pelo hook `trace-autogen` (a skill não o escreve)
 
 ## Referências
-- `.morph/framework/standards/STANDARDS.json` — índice de standards (não carregue todos — filtre por task)
-- `.morph/framework/agents.json` — personas dos agentes por domínio
+- `morph-spec standards --find "<query>" [--category] [--tags] [--json]` — busca de standard por digest (passo 2); não abre `STANDARDS.json` inteiro
+- `.morph/framework/agents.json` — personas dos agentes por domínio; lido apenas no fallback do passo 3 (task sem `agent` — plano legado)
 - `.morph/framework/MORPH.md` seção 6 — critérios de dispatch e contrato de retorno do sub-agent
 - `.morph/features/{feature}/2-plan/mandate.md` — contrato da feature
+- `.morph/features/{feature}/2-plan/tasks.json` — `task.agent`/`task.standards` carimbados pelo `morph-plan` §5a (fonte primária dos passos 2 e 3)
 - `.morph/framework/schemas/tasks.schema.json` — schema de tasks.json (enum de status e campos)

package/framework/skills/core/morph-plan/SKILL.md

@@ -4,7 +4,7 @@ description: Guia a produção dos artefatos de planejamento de uma feature (use
 version: core
 when-to-invoke: ao iniciar a fase plan de uma feature, após o Gate 1 (proposal aprovado)
 user-invokable: true
-cliVersion: "8.16.0"
+cliVersion: "8.17.0"
 ---
 
 # morph-plan
@@ -118,7 +118,9 @@ Ao iniciar a fase plan — após o `proposal.md` ser aprovado e antes de qualque
          "status": "pending",
          "outputs": [],
          "group": "backend",
-         "usecase": "UC-07"
+         "usecase": "UC-07",
+         "agent": "dotnet-senior",
+         "standards": ["standards/backend/dotnet/vsa-handler-patterns.md"]
        }
      ]
    }
@@ -132,6 +134,14 @@ Ao iniciar a fase plan — após o `proposal.md` ser aprovado e antes de qualque
    - `group` (opcional): backend, frontend, tests, infra, docs. Default backend.
    - `outputs` (opcional): array de paths que serão criados/modificados.
    - `usecase` (opcional): o **ID** do use case que a task realiza — `UC-07`, nunca o nome do arquivo. Task puramente técnica (build, config, migração) não tem.
+   - `agent` (opcional): o `id` da persona de `agents.json` responsável pelo domínio da task — **sem** o prefixo `morph-` (ex.: `"dotnet-senior"`, não `"morph-dotnet-senior"`). Carimbado no passo 5a abaixo; ausente numa task sem domínio de agente claro (config/docs) ou num plano legado.
+   - `standards` (opcional): array de paths relativos de `framework/standards/` (ex.: `["standards/backend/dotnet/vsa-handler-patterns.md"]`) — os standards da persona resolvida em `agent`, mais qualquer standard específico que a task exija.
+
+   **5a. Carimbe `agent` e `standards` — uma leitura de `agents.json`, N tasks.** Antes de fechar o array `tasks`, **use a tool Read UMA VEZ** em `.morph/framework/agents.json` (não releia por task — é essa releitura repetida por task, hoje feita em `morph-implement`/`morph-apply` a cada dispatch, que este passo existe para eliminar). Para cada task do plano, resolva:
+   - `agent`: o `id` da persona (chave do objeto `agents`, sem prefixo `morph-`) cujo `domains` cobre o `group`/domínio da task — o mesmo casamento que `morph-implement` §3 e `morph-apply` §3b fariam manualmente a cada dispatch; aqui você faz uma vez, no plano.
+   - `standards`: o array `standards` dessa persona, mais qualquer standard adicional que a task especificamente exija (some, não substitua).
+
+   Uma task cujo domínio não bate com nenhuma persona registrada (ex.: task pura de config/docs) fica sem `agent` — `morph-implement` cai no fallback de Read de `agents.json` nesse caso.
 
    **O `doneCriteria` carrega a pós-condição LITERAL.** Este é o elo que amarra a cadeia inteira: a pós-condição escrita em linguagem de negócio chega **sem tradução** ao critério que o `morph-spec verify` e o `morph-eval` cobram. Copie o texto da pós-condição, prefixado pelo seu rótulo (`"P2 — Cada veterinário traz..."`). Reescrever com outras palavras aqui é exatamente o ponto em que o requisito se perde hoje.
 
@@ -193,7 +203,7 @@ Ao iniciar a fase plan — após o `proposal.md` ser aprovado e antes de qualque
 - `.morph/features/{feature}/2-plan/usecases/UC-{nn}-{slug}.md` — um arquivo por use case, com pós-condições testáveis
 - `.morph/features/{feature}/2-plan/spec.md` — especificação técnica completa
 - `.morph/features/{feature}/2-plan/mandate.md` — contrato de implementação
-- `.morph/features/{feature}/2-plan/tasks.json` — task list estruturada válida contra schema, com o `doneCriteria` carregando a pós-condição literal
+- `.morph/features/{feature}/2-plan/tasks.json` — task list estruturada válida contra schema, com o `doneCriteria` carregando a pós-condição literal e, por task, `agent`/`standards` carimbados a partir de `agents.json` (passo 5a)
 - Gate 2 registrado aprovado em `.morph/features/{feature}/feature.json` (autoritativo)
 
 Ao registrar a aprovação do Gate 2, atualize o frontmatter de cada use case de `status: draft` para `status: approved`. O ciclo fecha na integração: `morph-spec finish` promove os use cases para o acervo permanente `.morph/specs/usecases/` já com `status: implemented`. O status é **descritivo** — quem trava fase é o gate, não este campo.
@@ -202,6 +212,7 @@ Ao registrar a aprovação do Gate 2, atualize o frontmatter de cada use case de
 
 - `.morph/framework/MORPH.md` — seções 2 (Fases), 3 (Contratos de Output), 5 (Gates), Trust Mode
 - `.morph/framework/standards/STANDARDS.json` — para identificar standards relevantes ao mandate
+- `.morph/framework/agents.json` — personas por domínio; lido UMA VEZ no passo 5a para carimbar `agent`/`standards` por task
 - `.morph/framework/schemas/tasks.schema.json` — schema obrigatório de tasks.json
 - `.morph/specs/usecases/` — acervo permanente de use cases do projeto (leia antes de numerar; em `bug`, é onde mora o UC a corrigir)
 - `.morph/features/{feature}/0-proposal/proposal.md` — escopo da feature

package/framework/skills/core/morph-proposal/SKILL.md

@@ -4,7 +4,7 @@ description: Orquestra a fase de proposta+plano de uma feature morph-spec. Encad
 version: core
 when-to-invoke: ao receber instrução "use /morph-proposal" do usuário, ou ao iniciar uma nova feature
 user-invokable: true
-cliVersion: "8.16.0"
+cliVersion: "8.17.0"
 ---
 
 # morph-proposal

package/framework/skills/core/morph-review/SKILL.md

@@ -4,7 +4,7 @@ description: Conduz a fase de revisão e produz o review-report.md para o Gate 3
 version: core
 when-to-invoke: ao iniciar a fase review, após todas as tasks de tasks.json estarem com status `done`
 user-invokable: true
-cliVersion: "8.16.0"
+cliVersion: "8.17.0"
 ---
 
 # morph-review

package/framework/skills/core/morph-stack-scan/SKILL.md

@@ -4,7 +4,7 @@ description: Varre o codebase existente, detecta stack atual, compara com o stac
 version: core
 when-to-invoke: ao iniciar uma feature em projeto brownfield (codebase já existente)
 user-invokable: true
-cliVersion: "8.16.0"
+cliVersion: "8.17.0"
 ---
 
 # morph-stack-scan

package/framework/skills/core/morph-standards/SKILL.md

@@ -4,7 +4,7 @@ description: Localiza e carrega um standard específico do STANDARDS.json sob de
 version: core
 when-to-invoke: quando precisar consultar um standard específico durante a implementação
 user-invokable: true
-cliVersion: "8.16.0"
+cliVersion: "8.17.0"
 ---
 
 # morph-standards

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@polymorphism-tech/morph-spec",
-  "version": "8.16.0",
+  "version": "8.17.0",
   "description": "MORPH-SPEC: NLH (Natural Language Harness) for spec-driven development with Claude Code",
   "keywords": [
     "claude-code",
@@ -45,7 +45,7 @@
     "generate:check": "node scripts/generate-refs.js --check",
     "generate-standards": "node scripts/generate-standards-registry.js",
     "generate-standards:check": "node scripts/generate-standards-registry.js --check",
-    "validate": "node scripts/validate-framework.js",
+    "validate": "node scripts/validate-framework.js && node scripts/check-rubric-parity.js",
     "freshness": "node scripts/check-freshness.js",
     "verify": "npm run generate:check && npm run generate-standards:check && npm run validate && npm run freshness && npm test",
     "test": "node scripts/run-tests.mjs",

package/src/commands/project/standards.js

@@ -0,0 +1,220 @@
+/**
+ * `morph-spec standards --find "<query>" [--category <c>] [--tags <a,b>] [--json]`
+ *
+ * Server-side replacement for "read the whole STANDARDS.json to pick 1-3
+ * standards" (R2 of the performance plan — token cut per task). Today
+ * morph-implement loads the full 65 KB / 60-entry registry (with a `digest`
+ * per entry) just to choose a couple of relevant standards: ~16k tokens per
+ * task. This command searches server-side and returns only the TOP 3 hits —
+ * `id · path · digest` — where the digest is the FULL text: it is what
+ * substitutes for actually reading the standard's .md file.
+ *
+ * Without `--find` (a bare call): lists categories + counts — a cheap
+ * orientation view, no scoring.
+ *
+ * A query with no hit exits 0 (this is advisory tooling, not a gate) with a
+ * human-readable warning + category suggestions on stderr, and — under
+ * `--json` — a stable `{ query, results: [], suggestion }` shape on stdout so
+ * a JSON consumer never has to special-case "no results" as a parse error.
+ */
+
+import { existsSync, readFileSync } from 'fs';
+import { join } from 'path';
+import chalk from 'chalk';
+
+/**
+ * Resolve STANDARDS.json the same way doctor.js resolves the standards root:
+ * an installed project first (`.morph/framework/standards/`), falling back
+ * to this package's own bundled copy (`framework/standards/`) — the framework
+ * repo in dev, or the npm package's own copy before `setup-infra` has run.
+ *
+ * @param {string} targetPath - project root to look for `.morph/` under
+ * @returns {string|null} absolute path to STANDARDS.json, or null if neither exists
+ */
+export function resolveStandardsJsonPath(targetPath) {
+  const installed = join(targetPath, '.morph', 'framework', 'standards', 'STANDARDS.json');
+  if (existsSync(installed)) return installed;
+
+  const packageFallback = join(import.meta.dirname, '..', '..', '..', 'framework', 'standards', 'STANDARDS.json');
+  if (existsSync(packageFallback)) return packageFallback;
+
+  return null;
+}
+
+/** Load + parse STANDARDS.json. Throws on missing/invalid file — caller decides how to report it. */
+function loadRegistry(standardsJsonPath) {
+  const raw = readFileSync(standardsJsonPath, 'utf8');
+  return JSON.parse(raw);
+}
+
+/**
+ * category → count, sorted by count desc then name asc.
+ * @param {object[]} standards
+ * @returns {{ category: string, count: number }[]}
+ */
+export function categoryCounts(standards) {
+  const counts = {};
+  for (const std of standards) {
+    const cat = std.category || 'uncategorized';
+    counts[cat] = (counts[cat] || 0) + 1;
+  }
+  return Object.entries(counts)
+    .map(([category, count]) => ({ category, count }))
+    .sort((a, b) => b.count - a.count || a.category.localeCompare(b.category));
+}
+
+/**
+ * Simple weighted relevance score for one standard against a query.
+ * Tiers, as specified: name/id > tags(+aliases) > digest. category/subcategory
+ * ride alongside the tags tier (lighter). A token-level fallback keeps
+ * multi-word queries findable even without a verbatim phrase match anywhere.
+ *
+ * @param {object} std - one STANDARDS.json entry
+ * @param {string} query - raw user query (already trimmed, non-empty)
+ * @returns {number} score, 0 = no match
+ */
+export function scoreStandard(std, query) {
+  const q = query.toLowerCase();
+  const tokens = q.split(/\s+/).filter((t) => t.length >= 3);
+
+  const name = String(std.name || '').toLowerCase();
+  const id = String(std.id || '').toLowerCase();
+  const category = String(std.category || '').toLowerCase();
+  const subcategory = String(std.subcategory || '').toLowerCase();
+  const tags = (std.tags || []).map((t) => String(t).toLowerCase());
+  const aliases = (std.aliases || []).map((a) => String(a).toLowerCase());
+  const digest = String(std.digest || '').toLowerCase();
+
+  let score = 0;
+
+  // Tier 1: name / id — the strongest signal.
+  if (id === q || name === q) score += 20;
+  else if (id.includes(q) || name.includes(q)) score += 12;
+
+  // Tier 2: tags / aliases (curated search terms) + category/subcategory.
+  if (tags.includes(q) || aliases.includes(q)) score += 8;
+  else if (tags.some((t) => t.includes(q)) || aliases.some((a) => a.includes(q))) score += 5;
+  if (category === q || subcategory === q) score += 4;
+
+  // Tier 3: digest — weakest signal, full-phrase substring only.
+  if (digest.includes(q)) score += 2;
+
+  // Token-level fallback for multi-word queries with no verbatim match above.
+  for (const tok of tokens) {
+    if (name.includes(tok) || id.includes(tok)) score += 2;
+    if (tags.some((t) => t.includes(tok)) || aliases.some((a) => a.includes(tok))) score += 1;
+    if (digest.includes(tok)) score += 0.5;
+  }
+
+  return score;
+}
+
+/**
+ * Rank standards against a query, applying optional category/tags filters
+ * first. Returns the TOP 3 with score > 0, sorted desc (ties broken by id).
+ *
+ * @param {object[]} standards
+ * @param {string} query
+ * @param {{ category?: string, tags?: string[] }} [filters]
+ * @returns {Array<object & { score: number }>}
+ */
+export function findStandards(standards, query, filters = {}) {
+  const category = filters.category?.toLowerCase();
+  const tags = (filters.tags || []).map((t) => t.toLowerCase());
+
+  let candidates = standards;
+  if (category) {
+    candidates = candidates.filter((s) => String(s.category || '').toLowerCase() === category);
+  }
+  if (tags.length) {
+    candidates = candidates.filter((s) =>
+      (s.tags || []).some((t) => tags.includes(String(t).toLowerCase())));
+  }
+
+  return candidates
+    .map((s) => ({ ...s, score: scoreStandard(s, query) }))
+    .filter((s) => s.score > 0)
+    .sort((a, b) => b.score - a.score || String(a.id).localeCompare(String(b.id)))
+    .slice(0, 3);
+}
+
+/** Parse `--tags a,b,c` into a trimmed, non-empty array. */
+function parseTagsOption(raw) {
+  if (!raw) return [];
+  return String(raw).split(',').map((t) => t.trim()).filter(Boolean);
+}
+
+/**
+ * @param {{ find?: string, category?: string, tags?: string, json?: boolean, cwd?: string }} [options]
+ */
+export function standardsCommand(options = {}) {
+  const cwd = options.cwd || process.cwd();
+  const standardsJsonPath = resolveStandardsJsonPath(cwd);
+
+  if (!standardsJsonPath) {
+    console.error(chalk.red('\n❌ STANDARDS.json não encontrado — nem em .morph/framework/standards/ nem no pacote.'));
+    console.error(chalk.gray('   Rode `morph-spec setup-infra` (projeto instalado) ou verifique framework/standards/ (repo do framework).\n'));
+    process.exit(1);
+  }
+
+  let registry;
+  try {
+    registry = loadRegistry(standardsJsonPath);
+  } catch (err) {
+    console.error(chalk.red(`\n❌ STANDARDS.json inválido em ${standardsJsonPath}: ${err.message}\n`));
+    process.exit(1);
+  }
+
+  const standards = Array.isArray(registry.standards) ? registry.standards : [];
+  const query = (options.find || '').trim();
+
+  // ── Bare call (no --find): categories + counts, cheap orientation ────────
+  if (!query) {
+    const counts = categoryCounts(standards);
+    if (options.json) {
+      console.log(JSON.stringify({ total: standards.length, categories: counts }));
+      process.exit(0);
+    }
+    console.log(chalk.bold(`\nSTANDARDS.json — ${standards.length} standards, ${counts.length} categorias\n`));
+    const col = (s, w) => String(s).padEnd(w);
+    for (const { category, count } of counts) {
+      console.log(`  ${col(category, 20)}${count}`);
+    }
+    console.log(chalk.gray('\nUse --find "<query>" para buscar (top 3, com digest completo).\n'));
+    process.exit(0);
+  }
+
+  // ── --find: score + filter ────────────────────────────────────────────
+  const filters = { category: options.category, tags: parseTagsOption(options.tags) };
+  const results = findStandards(standards, query, filters);
+
+  if (!results.length) {
+    const counts = categoryCounts(standards);
+    if (options.json) {
+      console.log(JSON.stringify({ query, results: [], suggestion: { categories: counts } }));
+      process.exit(0);
+    }
+    console.error(chalk.yellow(`\n⚠️  Nenhum standard encontrado para "${query}".`));
+    console.error(chalk.gray('   Categorias disponíveis: ' +
+      counts.map((c) => `${c.category} (${c.count})`).join(', ') + '\n'));
+    process.exit(0);
+  }
+
+  const shaped = results.map((r) => ({
+    id: r.id, name: r.name, path: r.path, category: r.category, digest: r.digest, score: r.score,
+  }));
+
+  if (options.json) {
+    console.log(JSON.stringify({ query, results: shaped }));
+    process.exit(0);
+  }
+
+  console.log(chalk.bold(`\nTOP ${shaped.length} para "${query}"\n`));
+  shaped.forEach((r, i) => {
+    console.log(chalk.cyan(`${i + 1}. ${r.id}`) + chalk.gray(`  (${r.category})`));
+    console.log(`   ${r.path}`);
+    console.log(chalk.gray(`   ${r.digest}`));
+    console.log('');
+  });
+  process.exit(0);
+}

package/src/lib/tasks/tasks-json-parser.js

@@ -87,6 +87,32 @@ export function validateTasksJson(data) {
     if (task.usecase !== undefined && (typeof task.usecase !== 'string' || !USECASE_RE.test(task.usecase))) {
       errors.push(`${ctx}.usecase must match /^UC-\\d+$/ (the ID alone, e.g. "UC-07")`);
     }
+
+    // Optional: morph-plan may stamp a persona + standards per task (R2 token
+    // cut — `morph-spec standards --find` replaces reading the whole
+    // STANDARDS.json). Both are part of the plan contract and frozen after
+    // Gate 2 by protect-spec-files (any key outside MUTABLE_SPEC_FIELDS is
+    // blocked by construction — see that hook's top comment). Type-check
+    // only here: no cross-check against agents.json, since stack-filtered
+    // installs carry fewer personas than the full set and would false-fail.
+    if (task.agent !== undefined) {
+      if (typeof task.agent !== 'string' || !task.agent.trim()) {
+        errors.push(`${ctx}.agent must be a non-empty string (persona id, e.g. "dotnet-senior")`);
+      } else if (task.agent.startsWith('morph-')) {
+        errors.push(`${ctx}.agent must be the bare persona id — no "morph-" prefix (got "${task.agent}")`);
+      }
+    }
+    if (task.standards !== undefined) {
+      if (!Array.isArray(task.standards)) {
+        errors.push(`${ctx}.standards must be an array of paths`);
+      } else {
+        task.standards.forEach((s, i) => {
+          if (typeof s !== 'string' || !s.trim()) {
+            errors.push(`${ctx}.standards[${i}] must be a non-empty string path`);
+          }
+        });
+      }
+    }
   }
 
   return { valid: errors.length === 0, errors };