@polymorphism-tech/morph-spec 8.15.1 → 8.17.0

package/framework/hooks/shared/state-writer.js

@@ -12,6 +12,7 @@
 
 import { readFileSync, writeFileSync, renameSync, unlinkSync, existsSync, mkdirSync } from 'fs';
 import { join, dirname } from 'path';
+import { clearStateCache } from './state-reader.js';
 
 const STATE_FILE = '.morph/state.json';
 const STATE_VERSION = '5.0.0';
@@ -73,6 +74,21 @@ export function persistFeature(featureName, feature, projectPath) {
     root.metadata = root.metadata || {};
     root.metadata.totalFeatures = Object.keys(root.features).length;
     atomicWriteJson(statePath, root);
+
+    // R1's loadState() memoizes per projectPath for the lifetime of the
+    // process. That was always safe when every hook was its own short-lived
+    // process (README history), but core/chain.js now runs multiple hooks
+    // — e.g. state-sync then gate-guard — IN ONE process. Without this,
+    // a loadState() call earlier in that same process (state-sync's
+    // handleWriteEdit reads via loadState before this write) would leave a
+    // stale snapshot cached, and gate-guard's loadState() right after this
+    // write would silently read the PRE-write state instead of what was
+    // just persisted — inverting the "gate-guard runs after state-sync so it
+    // sees the gate state-sync just recorded" ordering guarantee the
+    // registry comment documents. Invalidating here (the one place
+    // feature.json/state.json are actually written) covers every current
+    // and future caller, not just this one chain.
+    clearStateCache();
     return true;
   } catch {
     return false;

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.15.1"
+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.15.1"
+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.15.1"
+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.15.1"
+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.15.1"
+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.15.1"
+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.15.1"
+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.15.1"
+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.15.1"
+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.15.1"
+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.15.1"
+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.15.1"
+cliVersion: "8.17.0"
 ---
 
 # morph-standards

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@polymorphism-tech/morph-spec",
-  "version": "8.15.1",
+  "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",