@polymorphism-tech/morph-spec 8.16.0 → 8.18.0

package/framework/docs/CLI.md

@@ -0,0 +1,40 @@
+# morph-spec CLI — Referência Completa
+
+> Referência completa (flags, semântica, exemplos) dos comandos `morph-spec` usados pela LLM em vez de editar o estado à mão. Resumo rápido em `.morph/framework/CLAUDE.md`; racional dos gates em `.morph/framework/MORPH.md` §5, dispatch de sub-agents em §6, worktree/fleet em §2.2.
+
+---
+
+## Gates e estado
+
+- **`morph-spec approve <feature> <gate> --mode auto`** — aprova um gate (`proposal`/`plan`/`review`) em `trust: auto`. **O Gate 3 exige `4-review/evaluator-report.md`**: sem o relatório do avaliador independente o comando recusa (exit 1). Se o dispatch do avaliador for impossível nesta sessão, aprove com `--self-assessed` — a degradação é gravada em `approvalGates.review.selfAssessed` e aparece marcada no `morph-spec list`. `--force` **não** dispensa esta regra (é só para ordem de gate). **Exceção `hotfix`:** esse tipo nunca despacha o avaliador (`morph-hotfix` §7); o Gate 3 exige `4-review/review-report.md` no lugar do `evaluator-report.md`, e a assinatura humana continua obrigatória via `--approver` (o backstop de `--mode auto` acima permanece recusando).
+- **`morph-spec advance <feature>`** — aprova o gate da fase corrente **e** cria a pasta da próxima fase num passo só (`--design` toma o ramo opcional de uiux a partir da proposta).
+- **`morph-spec score <feature> <task> <score> [--dims a,c,q,t]`** — grava `taskScores` no feature.json com timestamp server-side; **nunca edite taskScores à mão**. Em PowerShell, cite o valor de `--dims` entre aspas (`--dims "9.5,9,9,9"`) — sem aspas, a lista pode chegar como tokens separados; o parser aceita ambas as formas, mas citar evita qualquer ambiguidade.
+- **`morph-spec gate-decision <feature> <gate> --pause <bool> [--reason <txt>] [--signals <json>]`** — grava `gateDecisions` no feature.json com timestamp server-side (shape em `framework/schemas/feature.schema.json`); **nunca edite gateDecisions à mão** — o Edit manual colide com o hook state-sync.
+
+## Features
+
+- **`morph-spec create <feature> --description "<o quê/porquê>" --type <feature|bug|chore|hotfix> [--request "<txt>"] [--name "<nome>"] [--worktree]`** — cria a estrutura da feature + `feature.json` canônico explicitamente (nascimento explícito no início da proposal; o hook state-sync continua cobrindo o caminho implícito como fallback). **Identidade no nascimento:** `name` (default = slug) e `description` são carimbados; a `--description` é **obrigatória** numa feature nova (ou `--request`, que a semeia) — sem nenhuma das duas o `create` recusa (fim dos scaffolds anônimos). `--type` classifica direto; `--request "<pedido>"` roda o detector determinístico (empate/sem sinal sai com exit 2 e candidatos — a LLM decide e re-roda com `--type` + `--request`/`--description`); `--worktree` já nasce a feature no seu worktree próprio. **Toda feature nasce numa branch `morph/{f}`** (ramificada da default) mesmo sem `--worktree` — por isso o fechamento por `morph-spec finish` é idêntico nos dois fluxos.
+- **`morph-spec list [--all] [--json]`** — o quadro de auditoria: uma linha por feature × workType × status × fase × gates G1/G2/G3 × descrição, com `⚠` para inconsistências (sem descrição, ordem de gate). `--all` inclui as arquivadas; `--json` para scripting. É o complemento do `delete` (enxergar o que está morto antes de remover).
+- **`morph-spec delete <feature> [--archive] [--force]`** — remove uma feature. Hard por padrão (pasta apagada, git-aware, + entrada podada do índice raiz para não ressuscitar); `--archive` move para `.morph/archive` com status `abandoned` em vez de apagar. Recusa se algum gate estiver aprovado, a menos que `--force`. Use para faxina de scaffolds mortos e drafts abandonados (`archive` é para trabalho concluído; `delete` é para trabalho morto).
+- **`morph-spec retype <feature> <newType>`** — muda o tipo de trabalho mid-flight; desfaz só os gates carimbados por política, preserva aprovações humanas; bloqueado após o Gate 3.
+
+## Worktree / Fleet
+
+- **`morph-spec finish <feature> --pr|--merge`** — o **encerramento único** da feature (worktree ou comum): **arquiva** commitando `features/{f} → archive/{f}` dentro de `morph/{f}` — promovendo junto, no mesmo commit, os use cases da feature para o acervo permanente `.morph/specs/usecases/` com `status: implemented` (fail-open: sem `2-plan/usecases/`, no-op silencioso) — depois integra. `--merge` faz merge `--no-ff` **local** na default (sem push); `--pr` faz `push` + `gh pr create` (exige `origin` + `gh`, checados **antes** de arquivar — um `--pr` recusado não deixa meio-estado). Desmonta o worktree (PROVE-or-DECLINE) e libera o bloco de portas; no `--pr` **preserva** a branch (o PR precisa dela) e fica em `morph/{f}`. Flags: `--keep` mantém o worktree, `--force` dispensa o Gate 3, `--discard-ignored` consente descartar gitignored no teardown. Substitui o antigo `worktree finish` + `archive` separados.
+- **`morph-spec archive <feature>`** — arquiva-**sem-integrar** (atômico, git-aware, commita o move escopado por pathspec): reservado a features legadas (sem branch `morph/{f}`) e faxina. O fechamento normal (arquiva **e** integra num passo) é `morph-spec finish`. É o que `/morph-archive` chama.
+- **`morph-spec worktree setup|link|list`** — gerencia o ciclo do worktree por feature (`setup` cria `worktrees/{f}/` na branch `morph/{f}`, aloca o bloco de portas e escreve `.morph/worktree.env`; `link` religa infra compartilhada; `list` mostra fase/gate de cada worktree ativo). O fechamento saiu daqui — use `morph-spec finish` (acima).
+- **`morph-spec handoff <feature>`** — regenera o documento de retomada (`.morph/features/{f}/handoff.md`): comprimido, derivado, aponta para os artefatos em vez de copiá-los. Gerado automaticamente em `setup`/`create --worktree`/`advance`.
+- **`morph-spec fleet`** — visão da frota: toda feature ativa (raiz + worktrees) com fase, gates pendentes, tasks, **remoto** (`local`/`pushed`/`PR #N`), **claim** (que sessão está na feature), portas, handoff e atividade. Use entre sessões para decidir onde atuar.
+- **`morph-spec claim [feature] [--release] [--list] [--json]`** — posse **advisory** de feature. Cada sessão reclama sua feature ativa automaticamente (hook SessionStart) e renova o heartbeat a cada tool call; o registro vive em `<git-common-dir>/morph-spec/claims.json`, compartilhado por todos os worktrees. **`morph-spec claim <feature>` (sem flags) ADQUIRE** — se esta árvore já tinha claim vivo em outra feature, ele é liberado no mesmo passo (o CLI reporta "movido de X para Y"); é o jeito de trocar de feature no meio da tarefa sem a dança de dois passos `--release` + reclamar. `--list` força a leitura sem adquirir mesmo passando uma feature. **Claims avisam, nunca bloqueiam** — mas se o SessionStart avisar que outra sessão tem claim vivo, **confirme antes de `finish`/`archive`/`delete`**: duas sessões na mesma feature já custaram um recap.md inteiro e um sub-agent (o worktree sumiu debaixo dele). Claim órfão de sessão morta: `morph-spec claim <f> --release`.
+
+## Validação
+
+- **`morph-spec dag <feature>`** — análise do DAG de tasks.json com decisão sequencial vs paralelo **ponderada por effort** (raízes S vão inline, nunca ganham agente próprio). Também cruza `tasks.json` com os use cases: `usecase` apontando para um `UC-{nn}` inexistente é **erro** (exit 1, não despacha); pós-condição órfã e `doneCriteria` que parafraseou em vez de copiar são avisos. `--mermaid` nunca é bloqueado.
+- **`morph-spec verify <feature> [task] [--json]`** — cadeia determinística build+testes+validadores (código antes do juiz LLM); escopo de task quando informado, senão a feature inteira.
+- **`morph-spec doctor --worktrees [--prune] [--json]`** — reconcilia o registro do git × as pastas em disco × as features conhecidas. Worktrees órfãos acumulavam **invisíveis**: o `fleet` só reporta worktrees em branch `morph/*`, então um worktree em outra branch (resíduo de finish anterior) não aparecia em lugar nenhum. `--prune` roda o único reparo seguro (`git worktree prune` — registros de pastas que já sumiram); apagar pasta que ainda existe é reportado com o comando exato, nunca executado.
+- **`morph-spec report-check <feature> [task] [--json]`** — audita os relatórios de sub-agent contra o trabalho que realmente entrou. **Relatório ausente NÃO quer dizer que o agente falhou** — ele pode ter feito tudo e perdido o meio de gravar. O comando responde a pergunta certa (`work-landed-report-missing` → aceite degradado, NÃO re-despache; `no-work-no-report` → re-despache uma vez). Protocolo completo em MORPH.md §6.
+
+## Observabilidade
+
+- **`morph-spec telemetry [--json] [--feature <f>] [--limit <n>]`** — reconstrói o caminho de execução da sessão a partir de `.morph/logs/events.jsonl` (skills invocadas, personas despachadas + prompts, standards/base de conhecimento lidos, mix de tools, prompts do usuário). Capturado silenciosamente pelo hook `telemetry-log` em todo tool call e todo UserPromptSubmit.
+- **`morph-spec cost [feature] [--by task|phase] [--json]`** — custo da execução a partir do mesmo `events.jsonl`: duração por task (TaskStart→TaskEnd), bytes de contexto re-ingerido por tipo (`rubric`/`standard`/`skill`/`agents`/`plan-artifact`/`code`), dispatches + tamanho de prompt e mix de tools. Bytes re-ingeridos são **proxy determinística** de custo de token (tokens reais não são observáveis por hook). Use antes/depois de mudar skill ou fluxo para medir o efeito.

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,9 @@ 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.18.0"
+stacks:
+  - umbraco
 ---
 
 # create-umbraco-lp

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

@@ -4,7 +4,9 @@ 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.18.0"
+stacks:
+  - umbraco
 ---
 
 # 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.18.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.
 
@@ -220,12 +231,8 @@ O comando grava `gateDecisions.review = { pause, reason, signals, trust, decided
 
 ### 6. Pós Gate 3 — encerramento
 
-- Aprovar o Gate 3: em auto, `morph-spec approve {feature} review --mode auto`; em manual, o hook state-sync registra a resposta "aprovado" em AskUserQuestion — **desde que a pergunta nomeie a feature** (o template acima nomeia; se você improvisar sem o nome e houver mais de uma feature na árvore, o hook recusa a gravar e avisa, e você aprova por `morph-spec approve`). O gate fica gravado no `feature.json` autoritativo da feature — nunca via Edit à mão de `state.json`.
-- **Fechar a feature** com `morph-spec finish {feature} --pr|--merge` — um passo só: arquiva commitando `features/{f} → archive/{f}` dentro de `morph/{f}`, integra e desmonta o worktree (se houver). Escolha o modo com `AskUserQuestion` (header `"Integração"`):
-  - **Abrir PR** (`--pr`): faz `push` de `morph/{f}` + `gh pr create` com base na default — para review por outro humano/CI antes do merge. Exige `origin` + `gh` autenticado (checados **antes** de arquivar; se faltarem, `finish` recusa sem efeito colateral — caia para `--merge`). A branch é preservada e a sessão fica em `morph/{f}`.
-  - **Merge local** (`--merge`): merge `--no-ff` na default **localmente**, sem push — para o fluxo single-user direto. Remove a branch e o worktree.
-- Não integre automaticamente sem a escolha do modo: `finish` toca o remoto (`--pr`) ou a branch default (`--merge`) — é uma ação de saída que pede confirmação.
-- Feature **legada** (criada antes do modelo "nasce numa branch", sem `morph/{f}`): `finish` recusa e roteia para `morph-spec archive {feature}` (arquivar-sem-integrar); nesse caso, arquive.
+- Aprovar o Gate 3: em auto, `morph-spec approve {feature} review --mode auto`; em manual, o hook state-sync registra a resposta "aprovado" em `AskUserQuestion` — **desde que a pergunta nomeie a feature** (senão aprove via `morph-spec approve`).
+- **Fechar a feature** com `morph-spec finish {feature} --pr|--merge`, modo escolhido via `AskUserQuestion` (header `"Integração"`): `--pr` (push + PR, review antes do merge) vs `--merge` (integra local, single-user direto). Não integre automaticamente sem essa escolha. Mecânica completa (o que cada modo faz, feature legada sem `morph/{f}`): `MORPH.md` §2.1/§2.2.
 
 ## Anti-padrões
 
@@ -247,10 +254,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.18.0"
 ---
 
 # morph-brainstorming
@@ -17,17 +17,7 @@ Ao iniciar uma nova feature — antes de qualquer especificação técnica ou pl
 
 ## Stack padrão (baked in)
 
-O harness conhece o stack por padrão. Não pergunte sobre tecnologia a menos que haja ambiguidade real.
-
-| Camada | Stack |
-|--------|-------|
-| Backend | .NET 10, VSA (feature-folder: handler + validator + endpoint + errors + tests) |
-| ORM | EF Core + Neon (Postgres), `Guid.CreateVersion7()`, `sealed` classes, `result.Match()` |
-| IA | Microsoft Agent Framework (MAF) — quando a feature envolve agentes |
-| Frontend | Next.js App Router + Tailwind + Framer Motion + Shadcn |
-| Jobs async | Hangfire — apenas se a feature requer processamento em background |
-
-**Padrões proibidos:** `Guid.NewGuid()`, classes não-sealed sem justificativa, exceptions sem result pattern, camada de Service/Manager entre handler e dados, repository genérico (`IRepository<T>`/`IUnitOfWork`), SQL cru sem justificativa. Acesso a dados em VSA: `ApplicationDbContext` direto no slice (`DbSet<T>` já é repository, `DbContext` já é unit of work); para concorrência ou SQL específico, store dedicado hand-written com justificativa em `decisions.md`.
+O harness conhece o stack por padrão (backend .NET 10 + VSA + EF Core/Neon, IA via MAF, frontend Next.js/Tailwind/Shadcn) e a lista de padrões proibidos (`Guid.NewGuid()`, classes não-sealed, Service/Manager layer, repository genérico, SQL cru). **Não pergunte sobre tecnologia a menos que haja ambiguidade real** — stack nunca entra na árvore de decisões. Regra canônica: `MORPH.md` § "Stack baked-in".
 
 ## Modo bug-lean (`workType: bug`)
 

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.18.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.18.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.18.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)