@polymorphism-tech/morph-spec 7.8.1 → 7.9.0

package/framework/rules/nextjs-templates.md

@@ -1,40 +1,40 @@
----
-paths:
-  - "**/*.tsx"
-  - "**/*.ts"
-stacks:
-  - nextjs
----
-
-# Next.js Code Templates
-
-When implementing Next.js features, use these templates as reference patterns.
-Read the template file to see the exact pattern, then generate code following it.
-
-## Scaffold (preferred for new features)
-
-**Always use scaffold for new feature pages — never create feature files manually.**
-
-```bash
-morph-spec scaffold nextjs <feature> [--dry-run]
-```
-
-Examples:
-```bash
-morph-spec scaffold nextjs book
-morph-spec scaffold nextjs user-profile
-```
-
-Generates 4 files: page (Server Component), list component, form component, TanStack Query hook.
-
-**Only use `template render` for individual files when modifying an existing feature.**
-
-| Template | Path | Purpose |
-|----------|------|---------|
-| Server Page | `.morph/framework/templates/frontend/nextjs/page.tsx.hbs` | App Router server component |
-| Client Component | `.morph/framework/templates/frontend/nextjs/client-component.tsx.hbs` | `'use client'` component |
-| Feature Form | `.morph/framework/templates/frontend/nextjs/feature-form.tsx.hbs` | react-hook-form + Zod + shadcn |
-| Custom Hook | `.morph/framework/templates/frontend/nextjs/use-feature.ts.hbs` | TanStack Query hook |
-| Env Config | `.morph/framework/templates/frontend/nextjs/env.mjs.hbs` | T3 Env validation |
-| TypeScript Config | `.morph/framework/templates/frontend/nextjs/tsconfig.json.hbs` | Path aliases |
-| Dockerfile | `.morph/framework/templates/frontend/nextjs/Dockerfile.nextjs.hbs` | Multi-stage build |
+---
+paths:
+  - "**/*.tsx"
+  - "**/*.ts"
+stacks:
+  - nextjs
+---
+
+# Next.js Code Templates
+
+When implementing Next.js features, use these templates as reference patterns.
+Read the template file to see the exact pattern, then generate code following it.
+
+## Scaffold (preferred for new features)
+
+**Always use scaffold for new feature pages — never create feature files manually.**
+
+```bash
+morph-spec scaffold nextjs <feature> [--dry-run]
+```
+
+Examples:
+```bash
+morph-spec scaffold nextjs book
+morph-spec scaffold nextjs user-profile
+```
+
+Generates 4 files: page (Server Component), list component, form component, TanStack Query hook.
+
+**Only use `template render` for individual files when modifying an existing feature.**
+
+| Template | Path | Purpose |
+|----------|------|---------|
+| Server Page | `.morph/framework/templates/frontend/nextjs/page.tsx.hbs` | App Router server component |
+| Client Component | `.morph/framework/templates/frontend/nextjs/client-component.tsx.hbs` | `'use client'` component |
+| Feature Form | `.morph/framework/templates/frontend/nextjs/feature-form.tsx.hbs` | react-hook-form + Zod + shadcn |
+| Custom Hook | `.morph/framework/templates/frontend/nextjs/use-feature.ts.hbs` | TanStack Query hook |
+| Env Config | `.morph/framework/templates/frontend/nextjs/env.mjs.hbs` | T3 Env validation |
+| TypeScript Config | `.morph/framework/templates/frontend/nextjs/tsconfig.json.hbs` | Path aliases |
+| Dockerfile | `.morph/framework/templates/frontend/nextjs/Dockerfile.nextjs.hbs` | Multi-stage build |

package/framework/schemas/feature.schema.json

@@ -0,0 +1,128 @@
+{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "title": "MORPH-SPEC feature.json",
+  "description": "Canonical shape of the authoritative, committed per-feature state at .morph/features/{feature}/feature.json (v5 per-feature state model). Born via `morph-spec create` (explicit) or the state-sync hook (implicit fallback). Server-side writers: `morph-spec approve/advance` (approvalGates), `morph-spec score` (taskScores), `morph-spec gate-decision` (gateDecisions), `morph-spec archive` (status/archivedAt). Never hand-edit the CLI-owned fields — manual Edits collide with the state-sync hook. This schema is documentational: additionalProperties stays true so older/newer CLIs interoperate.",
+  "type": "object",
+  "required": ["status", "approvalGates"],
+  "properties": {
+    "status": {
+      "type": "string",
+      "enum": ["draft", "in_progress", "completed"],
+      "description": "Feature lifecycle status. `completed` is stamped by `morph-spec archive` together with archivedAt."
+    },
+    "createdAt": { "type": "string", "format": "date-time" },
+    "updatedAt": {
+      "type": "string",
+      "format": "date-time",
+      "description": "Stamped server-side on every CLI/hook write."
+    },
+    "archivedAt": {
+      "type": "string",
+      "format": "date-time",
+      "description": "Stamped by `morph-spec archive`."
+    },
+    "approvalGates": {
+      "type": "object",
+      "description": "One entry per gate. Written ONLY by `morph-spec approve`/`advance` (approvedBy: \"auto\") or the state-sync hook on a human \"aprovado\" answer (approvedBy: \"manual\").",
+      "properties": {
+        "proposal": { "$ref": "#/definitions/gate" },
+        "uiux": { "$ref": "#/definitions/gate" },
+        "plan": { "$ref": "#/definitions/gate" },
+        "review": { "$ref": "#/definitions/gate" }
+      },
+      "additionalProperties": false
+    },
+    "gateDecisions": {
+      "type": "object",
+      "description": "Trust decision persisted BEFORE acting on a gate, written ONLY by `morph-spec gate-decision` (decidedAt is server-side). Read by the gate-guard hook to verify the observed action matched the recorded decision.",
+      "propertyNames": { "enum": ["proposal", "uiux", "plan", "review"] },
+      "additionalProperties": {
+        "type": "object",
+        "required": ["pause", "reason", "signals", "trust", "decidedAt"],
+        "properties": {
+          "pause": { "type": "boolean", "description": "true = the gate must pause for a human (AskUserQuestion); false = auto-pass with a short summary." },
+          "reason": { "type": "string", "description": "The signal that drove the decision (or 'nenhum sinal de risco')." },
+          "signals": {
+            "type": "object",
+            "description": "Risk signals evaluated (free-form): taskCount, evalScore, standardsViolations, designSystemDivergence..."
+          },
+          "trust": { "type": "string", "enum": ["auto", "manual"] },
+          "decidedAt": { "type": "string", "format": "date-time" }
+        },
+        "additionalProperties": false
+      }
+    },
+    "taskScores": {
+      "type": "object",
+      "description": "Per-task eval scores, written ONLY by `morph-spec score` (updatedAt is server-side; attempts auto-increment; bestScore is kept).",
+      "propertyNames": { "pattern": "^T\\d+$" },
+      "additionalProperties": {
+        "type": "object",
+        "required": ["lastScore", "bestScore", "attempts", "updatedAt"],
+        "properties": {
+          "lastScore": { "type": "number", "minimum": 0, "maximum": 10 },
+          "bestScore": { "type": "number", "minimum": 0, "maximum": 10 },
+          "attempts": { "type": "integer", "minimum": 1 },
+          "dimensions": {
+            "type": "object",
+            "properties": {
+              "architecture": { "type": "number", "minimum": 0, "maximum": 10 },
+              "contracts": { "type": "number", "minimum": 0, "maximum": 10 },
+              "codeQuality": { "type": "number", "minimum": 0, "maximum": 10 },
+              "testCoverage": { "type": "number", "minimum": 0, "maximum": 10 }
+            },
+            "additionalProperties": false
+          },
+          "updatedAt": { "type": "string", "format": "date-time" }
+        },
+        "additionalProperties": false
+      }
+    },
+    "tasks": {
+      "type": "object",
+      "description": "Aggregate task counters (informational — the source of truth is 2-plan/tasks.json).",
+      "properties": {
+        "total": { "type": "integer", "minimum": 0 },
+        "completed": { "type": "integer", "minimum": 0 },
+        "inProgress": { "type": "integer", "minimum": 0 },
+        "pending": { "type": "integer", "minimum": 0 }
+      },
+      "additionalProperties": true
+    },
+    "outputs": {
+      "type": "object",
+      "description": "Outputs tracked by the state-sync hook: filename → { created, path }.",
+      "additionalProperties": {
+        "type": "object",
+        "properties": {
+          "created": { "type": "boolean" },
+          "path": { "type": "string" }
+        },
+        "additionalProperties": true
+      }
+    },
+    "activeAgents": { "type": "array", "items": { "type": "string" } },
+    "checkpoints": { "type": "array" },
+    "dispatchLog": {
+      "type": "array",
+      "description": "Dispatch events (capped at 50). Entries: { timestamp, phase, mode, agents: [{ id, subagentType, group, tasks }] }."
+    },
+    "trustConfig": { "type": "object" },
+    "contextBundles": { "type": "array" },
+    "fileChanges": { "type": "array" },
+    "skippedPhases": { "type": "array" }
+  },
+  "additionalProperties": true,
+  "definitions": {
+    "gate": {
+      "type": "object",
+      "required": ["approved"],
+      "properties": {
+        "approved": { "type": "boolean" },
+        "timestamp": { "type": ["string", "null"], "description": "ISO timestamp of the approval/revocation, null while never evaluated." },
+        "approvedBy": { "type": ["string", "null"], "description": "\"auto\" (policy gate), \"manual\" (human in the loop), a --approver name, or null while never evaluated." }
+      },
+      "additionalProperties": true
+    }
+  }
+}

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: "7.8.1"
+cliVersion: "7.9.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: "7.8.1"
+cliVersion: "7.9.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: "7.8.0"
+cliVersion: "7.9.0"
 ---
 
 # morph-apply
@@ -52,6 +52,8 @@ O comando analisa `dependencies`, `group` e `effort` das tasks pendentes e impri
 
 > **Peso de esforço:** a decisão é ponderada por `effort` (S=1, M=2, L=4, XL=8). **Raízes e fluxos compostos só de tasks S não ganham dispatch próprio** — overhead > trabalho. O comando os lista como `inline` (você os executa no modo sequencial) ou os agrupa num **único** agente quando são muitos. O cap de **4 agentes simultâneos** (anti-padrão abaixo) vale para ambas as formas. Se um fluxo de domínio é uma cadeia longa, despache o **fluxo inteiro** a um sub-agent (que executa a cadeia em ordem internamente) — um agente por fluxo, não um agente por task.
 
+> **DAG × gatilho de effort — decisões ortogonais que coexistem:** a decisão deste comando governa o **paralelismo ENTRE tasks** (quantos sub-agents ao mesmo tempo: fluxos/raízes independentes em batch). O gatilho de effort/domínio de `morph-implement` §4 governa o **dispatch INDIVIDUAL** de cada task quando ela chega ao topo do loop sequencial. `DAG: sequencial` significa "uma task por vez, na ordem" — **NÃO significa "tudo inline"**. Exemplo: cadeia única backend de 12 tasks → o DAG decide sequencial; T7 tem effort L → ao chegar em T7, o orquestrador a despacha **sozinha** para `morph-dotnet-senior` e aguarda o retorno (um agente por vez); T8 (S, mesmo domínio já carregado) roda inline. As duas regras nunca conflitam: o DAG decide *quantos ao mesmo tempo*, o gatilho de effort decide *quem executa cada task*.
+
 Registre a linha de decisão que o comando imprimiu, por exemplo:
 ```
 DAG: 14 tasks, fluxos {backend:9, frontend:2} independentes (peso 18‖4) → 2 fluxos paralelos + T14 (integração) sequencial no fim
@@ -120,9 +122,15 @@ dispatch Agent (subagent_type: "morph-{id}") with prompt:
     Não modifique spec.md, mandate.md.
 
     Protocolo obrigatório:
-    1. Ao concluir, ENTREGUE o relatório final — sua última mensagem é o relatório;
-       se a sessão permanecer viva aguardando, envie-o via SendMessage para main.
-       Terminar idle sem reportar é falha de protocolo.
+    1. ATO FINAL OBRIGATÓRIO — relatório via SendMessage: antes de encerrar,
+       chame a tool SendMessage com to:"main" e o relatório completo no content.
+       Sua última mensagem em texto NÃO chega ao orquestrador — só SendMessage
+       chega. Não termine idle "aguardando"; o SendMessage É o encerramento.
+       Exemplo literal (última chamada de tool da sua sessão):
+       SendMessage({ to: "main", content: "Fluxo backend concluído (T2→T7).
+       Sumário: ... Arquivos: src/... Standards: vsa-handler-patterns.
+       Auto-score: 9/10" })
+       Terminar idle sem SendMessage é 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.
@@ -130,7 +138,7 @@ dispatch Agent (subagent_type: "morph-{id}") with prompt:
        (dotnet test / npm test do projeto inteiro) — edições concorrentes quebram
        o build umas das outras; a verificação é do orquestrador, pós-batch.
 
-    Retorne:
+    Retorne no content do SendMessage:
       - sumário das mudanças
       - arquivos modificados (paths)
       - standard(s) consultado(s)
@@ -141,7 +149,7 @@ dispatch Agent (subagent_type: "morph-{id}") with prompt:
 
 > **Alternativa quando os fluxos tocam os mesmos projetos/arquivos** (ex.: o mesmo csproj de testes compartilhado): despache com `isolation: "worktree"` — cada agente trabalha numa working tree própria e o orquestrador integra ao final. Nesse caso a cláusula 3 vira "rode build/test apenas dentro do seu worktree".
 
-Aguardar todos os agentes terminarem. **Se um agente ficar idle sem entregar o relatório, cobre-o via SendMessage e registre a falha de protocolo no recap.** Depois, sequencialmente:
+Aguardar todos os agentes terminarem. O hook `subagent-report-guard` (Stop/SubagentStop) bloqueia uma vez o encerramento de um subagent despachado que não chamou SendMessage, com a instrução da cláusula 1 — o ciclo cobrar-esperar deixa de ser o caminho normal. **Fallback: se mesmo assim um agente ficar idle sem entregar o relatório, cobre-o via SendMessage e registre a falha de protocolo no recap.** Depois, sequencialmente:
 - **Rodar a verificação compartilhada uma única vez** (build + suíte de testes do projeto) — os agentes não a rodaram (cláusula 3 do protocolo).
 - Para cada relatório retornado:
   - Aplicar `Skill(morph-eval)`.
@@ -168,9 +176,13 @@ Sinais de risco para Gate 3:
 
 Mesma lógica do Gate 1/Gate 2 (regras da tabela do MORPH.md §5, aplicadas em linguagem natural — sem scripts): `trust: manual` → pausa sempre; `standardsViolations` não-vazio → pausa; `evalScore < 9` → pausa; caso contrário → auto-passa.
 
-**Persista a decisão no `feature.json` autoritativo da feature ANTES de apresentar ou auto-aprovar** — grave
-`gateDecisions.review = { pause, reason, signals, trust, decidedAt: <ISO> }` em `.morph/features/{feature}/feature.json`
-(o `signals.evalScore` aqui é o score composto do review-report; Edit em `.morph/features/**` é permitido). O hook `gate-guard.js` confere depois se a ação bateu. Sem o registro o guard não verifica.
+**Persista a decisão ANTES de apresentar ou auto-aprovar — via CLI, nunca editando feature.json à mão** (o Edit manual colide com o hook state-sync — erro "file modified since read"):
+
+```
+morph-spec gate-decision {feature} review --pause false --reason "score 9.2, sem violações" --signals '{"evalScore":9.2,"standardsViolations":[]}'
+```
+
+O comando grava `gateDecisions.review = { pause, reason, signals, trust, decidedAt }` no `feature.json` autoritativo com timestamp server-side (o `signals.evalScore` aqui é o score composto do review-report; shape canônico em `.morph/framework/schemas/feature.schema.json`). O hook `gate-guard.js` confere depois se a ação bateu. Sem o registro o guard não verifica.
 
 - Pause: `AskUserQuestion` com options `["aprovado, fechar feature", "preciso ajustar", "rollback"]`.
 - Auto: exibir summary do review-report, aprovar via `morph-spec approve {feature} review --mode auto`, e prosseguir.
@@ -189,7 +201,7 @@ Mesma lógica do Gate 1/Gate 2 (regras da tabela do MORPH.md §5, aplicadas em l
 - Não dispachar mais que 4 agentes em paralelo (sobrecarga de contexto + custo).
 - Não dispachar um agente inteiro para uma raiz de effort S — overhead > trabalho; o `morph-spec dag` já as marca como `inline`.
 - Não deixar sub-agent tocar `tasks.json`, `feature.json` ou o board de sessão — estado é do orquestrador (cláusula 2 do protocolo).
-- Não editar `feature.json` à mão para gravar scores — use `morph-spec score` (timestamp server-side).
+- Não editar `feature.json` à mão para gravar scores ou decisões de gate — use `morph-spec score` e `morph-spec gate-decision` (timestamps server-side; o Edit manual colide com o hook state-sync — "file modified since read").
 
 ## Output esperado
 
@@ -207,4 +219,5 @@ Mesma lógica do Gate 1/Gate 2 (regras da tabela do MORPH.md §5, aplicadas em l
 - `framework/skills/core/morph-review/SKILL.md`
 - `morph-spec dag {feature}` — análise de DAG e decisão sequencial vs paralelo (ponderada por effort)
 - `morph-spec score {feature} {task} {score} [--dims a,c,q,t]` — grava taskScores no feature.json com timestamp server-side
+- `morph-spec gate-decision {feature} {gate} --pause {bool} [--reason ...] [--signals ...]` — grava gateDecisions no feature.json com timestamp server-side (shape em `.morph/framework/schemas/feature.schema.json`)
 - `.morph/framework/MORPH.md` §5 — regras de pausa de gate (trust mode)

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: "7.8.1"
+cliVersion: "7.9.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: "7.8.1"
+cliVersion: "7.9.0"
 ---
 
 # morph-eval
@@ -39,16 +39,13 @@ Também invocado ao receber o retorno de um sub-agent com auto-score < 7.
 
 6. Registre o score no recap.md da tarefa avaliada.
 
-7. Atualize o trace de execução em `.morph/traces/YYYY-MM-DD-{feature}-{phase}.json`:
-   - Encontre a entrada da task avaliada em `tasks[]` pelo `id`
-   - Preencha `eval_score` com o score composto calculado no passo 4
-   - Preencha `eval_dimensions` com os scores individuais por dimensão
+7. **NÃO escreva o trace manualmente.** O arquivo `.morph/traces/YYYY-MM-DD-{feature}-implement.json` é gerado automaticamente pelo hook `trace-autogen` a cada write de `tasks.json`, lendo `eval_score`/`eval_dimensions` do registro `taskScores` do feature.json. Garanta apenas que o score foi persistido via `morph-spec score {feature} {task} {score} --dims {a},{c},{q},{t}` (a `morph-apply` faz esse registro no loop) — é dali que o trace lê.
 
 ## Output esperado
 - Score composto 0-10 com scores por dimensão
 - Ação tomada com base no score (aprovado em >=9 / feedback acionável para o loop em <9)
 - Entrada no recap.md com scores
-- Trace atualizado com `eval_score` e `eval_dimensions`
+- Score persistido em `taskScores` via `morph-spec score` (o trace é gerado automaticamente pelo hook `trace-autogen`)
 
 ## Referências
 - `.morph/framework/evals/rubrics/architecture.md` — rubrica de arquitetura (30%)

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: "7.8.0"
+cliVersion: "7.9.0"
 ---
 
 # morph-implement
@@ -47,6 +47,8 @@ Ao iniciar cada task de `tasks.json` — antes de escrever qualquer código. Nor
 
    Inline é aceitável só para tasks S/M **dentro do domínio já carregado**. Se for inline numa task que dispara um gatilho, registre a justificativa em uma linha no `decisions.md` — inline silencioso numa task pesada/multi-domínio é o anti-padrão da seção 6.
 
+   > **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:
    ```
    Implementar [ID]: [title da task]
@@ -57,17 +59,24 @@ Ao iniciar cada task de `tasks.json` — antes de escrever qualquer código. Nor
    Done quando: [doneCriteria do tasks.json]
 
    Protocolo obrigatório:
-   1. Ao concluir, ENTREGUE o relatório final — sua última mensagem é o relatório;
-      se a sessão permanecer viva aguardando, envie-o via SendMessage para main.
-      Terminar idle sem reportar é falha de protocolo.
+   1. ATO FINAL OBRIGATÓRIO — relatório via SendMessage: antes de encerrar,
+      chame a tool SendMessage com to:"main" e o relatório completo no content.
+      Sua última mensagem em texto NÃO chega ao orquestrador — só SendMessage
+      chega. Não termine idle "aguardando"; o SendMessage É o encerramento.
+      Exemplo literal (última chamada de tool da sua sessão):
+      SendMessage({ to: "main", content: "T{N} concluída. (1) O que foi feito:
+      handler + validator do slice X. (2) Arquivos: src/Features/X/Handler.cs,
+      tests/X/HandlerTests.cs. (3) Problemas: nenhum. (4) Auto-score: 9/10" })
+      Terminar idle sem SendMessage é falha de protocolo.
    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.
    3. Se você faz parte de um batch paralelo, NÃO rode build/test da suíte
       compartilhada — a verificação é do orquestrador, pós-batch.
 
-   Retorne 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.
+   Retorne no content do SendMessage 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.
    ```
    Após receber o retorno: o auto-score é **triagem, não aprovação** — se < 7, re-despache com o feedback específico (ou corrija inline) antes de prosseguir. Em qualquer caso, a task só avança quando `morph-eval` der score ≥ 9 (barra única do MORPH.md §0). Integre o relatório ao recap.md e vá para o passo 7.
 
@@ -102,31 +111,35 @@ Ao iniciar cada task de `tasks.json` — antes de escrever qualquer código. Nor
    - Sem standard ⇒ a task falha no validador de Gate 3 (`validate-completion`)
      e o reviewer não consegue auditar de onde veio a decisão técnica.
 
-7. Registre a entrada no trace de execução em `.morph/traces/YYYY-MM-DD-{feature}-implement.json`:
-   - Crie o arquivo se não existir (use o schema em `.morph/framework/evals/trace-schema.md`)
-   - Adicione entrada em `tasks[]` com: `id`, `title`, `status`, `standards_consulted`, `agent_persona`, `files_modified`, `sub_agent_dispatched`
-   - Deixe `eval_score` e `eval_dimensions` como `null` — serão preenchidos pelo morph-eval
-   - Se esta for a última tarefa da fase, preencha `completed_at`
-
-8. Atualizar `tasks.json` marcando a task como `done` — **direto com a tool `Edit` (ou `Write`)**, sem scripts:
+7. Atualizar `tasks.json` marcando a task como `done` — **direto com a tool `Edit` (ou `Write`)**, sem scripts:
 
    - Mude apenas os campos mutáveis da task: `status` (enum válido: `pending`,
      `in_progress`, `done`, `skipped`, `blocked` — nunca invente valores como
      `"completed"`), `outputs` (paths realmente produzidos) e `notes`.
+   - **`outputs` contém apenas paths realmente produzidos.** Deleções, remoções
+     e anotações (ex.: `"pasta/ (removido: a, b)"`) se registram em `notes`,
+     nunca em `outputs`. E `notes` é **uma string única** — não um array.
    - **Se os `outputs` reais divergirem dos planejados**, registre o porquê em
-     `notes` na mesma edição — o hook exige a note quando há divergência.
+     `notes` na mesma edição — o hook exige a note quando há divergência (e a
+     mensagem de violação aponta o campo/valor exato do problema).
    - `tasks.json` é protegido após o Gate 2: o hook `protect-spec-files` faz diff
      semântico e libera Write ou Edit desde que nenhum campo de contrato do plano
      (`title`, `description`, `dependencies`, `effort`, `doneCriteria`, `group`)
      mude e o schema continue válido.
 
-9. Quando invocada por `morph-apply`, retornar o controle à skill orquestradora — ela decide qual task vem em seguida via `getReadyTasks(data)`. Quando invocada manualmente, verificar se há próxima task ready e iniciá-la imediatamente aplicando esta skill desde o passo 1 (auto-advance). Pause apenas se encontrar ambiguidade bloqueante não coberta pelo mandate.
+   > **Trace automático:** este write de `tasks.json` dispara o hook `trace-autogen`,
+   > que gera/atualiza `.morph/traces/YYYY-MM-DD-{feature}-implement.json` a partir de
+   > tasks.json + recap.md + `taskScores` do feature.json. **NÃO escreva o trace
+   > manualmente** — a escrita manual foi removida da cerimônia por task.
+
+8. Quando invocada por `morph-apply`, retornar o controle à skill orquestradora — ela decide qual task vem em seguida via `getReadyTasks(data)`. Quando invocada manualmente, verificar se há próxima task ready e iniciá-la imediatamente aplicando esta skill desde o passo 1 (auto-advance). Pause apenas se encontrar ambiguidade bloqueante não coberta pelo mandate.
 
 ## Output esperado
 - Código implementado conforme o standard consultado (direto ou via sub-agent)
 - `.morph/features/{feature}/3-implement/recap.md` atualizado com entrada da task concluída
 - `.morph/features/{feature}/2-plan/tasks.json` com status da task atualizado para `done`
 - `.morph/features/{feature}/2-plan/decisions.md` atualizado se houver decisão não trivial
+- 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)

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

@@ -4,7 +4,7 @@ description: Guia a produção dos três artefatos de planejamento de uma featur
 version: core
 when-to-invoke: ao iniciar a fase plan de uma feature, após o Gate 1 (proposal aprovado)
 user-invokable: true
-cliVersion: "7.8.1"
+cliVersion: "7.9.0"
 ---
 
 # morph-plan

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: "7.8.1"
+cliVersion: "7.9.0"
 ---
 
 # morph-proposal
@@ -35,7 +35,7 @@ Conduzir uma feature do request inicial até o plano aprovado (Gate 2), sem inte
 - Se argumento ausente: perguntar via `AskUserQuestion` (1 pergunta, header "Feature").
 - Verificar `.morph/features/{feature-name}/`:
   - Se `0-proposal/proposal.md` existe e tem conteúdo: pular para passo 3.
-  - Caso contrário: criar a estrutura e seguir o passo 2.
+  - Caso contrário: rode `morph-spec create {feature-name}` — cria `.morph/features/{feature-name}/0-proposal/` e o `feature.json` canônico (shape em `.morph/framework/schemas/feature.schema.json`) num passo só, server-side. Não crie a estrutura à mão nem dependa do nascimento implícito via hook no primeiro Write. Depois siga o passo 2.
 
 ### 2. Invocar `Skill(morph-brainstorming)`
 

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: "7.8.1"
+cliVersion: "7.9.0"
 ---
 
 # morph-review
@@ -73,11 +73,7 @@ e o `recap.md` estar atualizado. Normalmente invocada pela skill orquestradora `
    (A barra de avanço por task é 9; uma dimensão individual abaixo de 8 no review da feature
    inteira é um bloqueante crítico que o loop de correção deveria ter pego.)
 
-7. Finalize o trace de execução em `.morph/traces/YYYY-MM-DD-{feature}-implement.json`:
-   - Preencha `phase_summary.tasks_completed`, `tasks_failed`, `avg_eval_score`
-   - Calcule `standards_most_used` a partir das entradas em `tasks[].standards_consulted`
-   - Preencha `sub_agents_dispatched` com a contagem de tasks onde `sub_agent_dispatched: true`
-   - Preencha `completed_at` com o timestamp atual
+7. **NÃO finalize o trace manualmente.** O hook `trace-autogen` gera e finaliza `.morph/traces/YYYY-MM-DD-{feature}-implement.json` automaticamente (incl. `phase_summary` e `completed_at`) no último write de `tasks.json` — quando a última task sai de `pending`/`in_progress`. Se o trace parecer desatualizado, a causa é um `morph-spec score` faltante ou um recap sem o bloco da task — corrija a fonte, não o trace.
 
 8. Apresente o Gate 3 segundo trust mode.
 

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: "7.8.1"
+cliVersion: "7.9.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: "7.8.1"
+cliVersion: "7.9.0"
 ---
 
 # morph-standards