@polymorphism-tech/morph-spec 7.5.0 → 7.7.0

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.5.0"
+cliVersion: "7.7.0"
 ---
 
 # morph-apply
@@ -33,34 +33,29 @@ Executar todas as tasks pendentes de uma feature até `done`, aplicando `morph-e
 ### 1. Carregar contexto
 
 - Ler `.morph/config/config.json → trust`.
-- Parsear `tasks.json` via `src/lib/tasks/tasks-json-parser.js`:
-  ```js
-  import { parseTasksJson, getReadyTasks, getPendingTasks, updateTaskStatus, writeTasksJson, groupTasks } from '../../../src/lib/tasks/tasks-json-parser.js';
-  const data = await parseTasksJson('.morph/features/{feature}/2-plan/tasks.json');
-  ```
+- **Use a tool Read** em `.morph/features/{feature}/2-plan/tasks.json` para carregar as tasks (ids, `dependencies`, `effort`, `group`, `status`, `doneCriteria`). Não escreva scripts para isso — o parse e a validação de schema acontecem no comando CLI do passo 2.
 
 ### 2. Análise de DAG — decisão sequencial vs paralelo
 
-Construir o grafo de dependências e detectar fluxos de trabalho independentes. Há duas formas de paralelismo a detectar — e a segunda é a que mais aparece na prática:
+Rode o comando CLI (ele parseia o tasks.json, valida o schema e pondera o esforço):
 
-```js
-const groups = groupTasks(data); // { backend: [ids], frontend: [ids], tests: [...], infra: [...], docs: [...] }
-const independentRoots = data.tasks.filter(t => t.dependencies.length === 0);
+```
+morph-spec dag {feature}
 ```
 
-**Regras de decisão:**
+O comando analisa `dependencies`, `group` e `effort` das tasks pendentes e imprime a decisão pronta com justificativa. As regras que ele aplica (e que você segue):
 
-1. Se `data.tasks.length <= 3`: **sequencial** (overhead de Agent dispatch não compensa).
-2. **Fluxos de domínio independentes (o caso comum — backend ‖ frontend).** Use `groupTasks(data)` para separar as tasks por `group`. Dois grupos formam fluxos paralelos quando **nenhuma task de um grupo depende de uma task de outro grupo** (as cadeias só convergem, se convergirem, numa task final de integração). Se existem **≥ 2 fluxos de domínio independentes** — ex: a cadeia `backend` `T1→…→T11` e a cadeia `frontend` `T12→T13` não se cruzam até `T14` —, dispache **um sub-agent por fluxo, em paralelo**, cada um com a persona e o standard do seu domínio (ver passo 3b). Esse é exatamente o caso que a regra antiga de "≥3 raízes independentes" deixava passar (duas cadeias contam como 2 raízes, não 3).
-3. **Raízes independentes (fan-out na largura).** Identificar tasks **100% independentes** (`dependencies: []`). Se `independentRoots.length >= 3`: dispachar essas raízes em **paralelo**, depois cair em sequencial para o resto.
+1. Se `tasks.length <= 3`: **sequencial** (overhead de Agent dispatch não compensa).
+2. **Fluxos de domínio independentes (o caso comum — backend ‖ frontend).** Grupos cujas tasks não dependem de tasks de outro grupo formam fluxos paralelos (as cadeias só convergem, se convergirem, numa task final de integração). **≥ 2 fluxos independentes com peso de esforço suficiente** → dispache **um sub-agent por fluxo, em paralelo**, cada um com a persona e o standard do seu domínio (ver passo 3b).
+3. **Raízes independentes (fan-out na largura).** Tasks 100% independentes (`dependencies: []`). **≥ 3 raízes com effort M ou maior** → dispachar essas raízes em **paralelo**, depois cair em sequencial para o resto.
 4. Caso contrário: **sequencial puro** com auto-advance.
 
-> 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.
+> **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.
 
-Logar a decisão (mostre qual forma disparou):
+Registre a linha de decisão que o comando imprimiu, por exemplo:
 ```
-DAG analysis: 14 tasks, groups {backend:9, frontend:2, tests:2, infra:1}; backend ‖ frontend independentes até T14 → 2 fluxos paralelos (1 agente backend, 1 agente frontend) + T14 sequencial no fim
-DAG analysis: 12 tasks, 4 raízes independentes → parallel batch (T1, T3, T7, T9) + sequential remainder
+DAG: 14 tasks, fluxos {backend:9, frontend:2} independentes (peso 18‖4) → 2 fluxos paralelos + T14 (integração) sequencial no fim
+DAG: 12 tasks, 4 raízes independentes (3 com peso ≥ M) → parallel batch (T1, T3, T7) + T9 (S) inline + restante sequencial
 ```
 
 ### 3a. Modo Sequencial (auto-advance)
@@ -68,13 +63,12 @@ DAG analysis: 12 tasks, 4 raízes independentes → parallel batch (T1, T3, T7,
 Loop:
 ```
 while (true):
-  ready = getReadyTasks(data)
+  ready = tasks 'pending' cujas dependencies estão todas 'done' (releia tasks.json)
   if ready.length === 0:
     break
 
   task = ready[0]
-  updateTaskStatus(data, task.id, 'in_progress')
-  writeTasksJson(tasksPath, data)
+  marcar task.status = 'in_progress' em tasks.json (tool Edit — só campos mutáveis)
 
   // Loop de correção autônomo — a barra de qualidade é >= 9 (ver MORPH.md §0).
   // Entre tasks NÃO há pausa humana: score < 9 dispara re-implementação, não AskUserQuestion.
@@ -86,25 +80,24 @@ while (true):
       (no attempt > 1: passar o feedback priorizado do morph-eval anterior como input)
     result = invoke Skill(morph-eval) with implementation output
     if result.score > best.score: best = result
-    // Persista o score no feature.json autoritativo da feature, sob taskScores — torna o
-    // evalScore um signal de disco no MOMENTO da implementação (não no fim). O hook
-    // gate-guard.js e o Gate 3 leem dali. Edit em .morph/features/** é permitido. Grave:
-    //   taskScores[task.id] = { lastScore: result.score, bestScore: best.score, attempts: attempt, updatedAt: <ISO> }
-    edit .morph/features/{feature}/feature.json com o taskScores acima
+    // Persista o score no feature.json autoritativo — torna o evalScore um signal
+    // de disco no MOMENTO da implementação (não no fim). O hook gate-guard.js e o
+    // Gate 3 leem dali. O timestamp é carimbado server-side pelo CLI — NUNCA edite
+    // feature.json à mão para isso:
+    run: morph-spec score {feature} {task.id} {result.score} --dims {arch},{contracts},{quality},{tests}
 
     if result.score >= 9:
       break
 
   if best.score >= 9:
-    updateTaskStatus(data, task.id, 'done')
+    marcar task.status = 'done' em tasks.json (tool Edit — atualize também outputs
+    reais e, se divergirem do planejado, registre o porquê em notes)
   else:
     // 3 tentativas sem atingir 9 — AQUI sim escala ao humano (escape definido).
     // Esta é a única pausa do loop de implement, e só após esgotar o loop de correção.
     registrar em recap.md: as 3 tentativas e o melhor score (best.score) com o feedback
     AskUserQuestion: "Task {id} não atingiu score 9 após 3 tentativas (melhor: {best.score}) — aceitar mesmo assim, continuar tentando, ou pular?"
     options: [aceitar (marca done com ressalva no recap), continuar tentando (+3 tentativas), pular task (marca blocked)]
-
-  writeTasksJson(tasksPath, data)
 ```
 
 > **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.
@@ -113,18 +106,30 @@ while (true):
 
 **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:
 
-- **Persona:** em `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`). Pegue o texto do campo `persona`.
+- **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.
+- **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.
 
 ```
-dispatch Agent (subagent_type: "general-purpose") with prompt:
-  persona: <texto do campo `persona` do agente de domínio em agents.json>
+dispatch Agent (subagent_type: "morph-{id}") with prompt:
   contexto: spec.md, mandate.md, task description completa, doneCriteria
   standard: <path(s) .md do(s) standard(s) do domínio — leia-o(s) antes de implementar>
   instrução: |
-    Adote a persona acima. Leia o(s) standard(s) indicado(s) antes de escrever código.
+    Leia o(s) standard(s) indicado(s) antes de escrever código.
     Implemente esta task (ou cadeia de tasks do fluxo) isoladamente.
     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.
+    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. Você roda em batch paralelo: NÃO rode build/test da suíte compartilhada
+       (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:
       - sumário das mudanças
       - arquivos modificados (paths)
@@ -132,12 +137,16 @@ dispatch Agent (subagent_type: "general-purpose") with prompt:
       - auto-score 0-10 (rubric: completeness, correctness, mandate compliance)
 ```
 
-> Este template é deliberadamente paritário com o template sequencial em `morph-implement` §4: ambos passam **persona + standard escopados**. 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 cláusulas de protocolo. 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): 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 (Promise.all equivalente). Depois, sequencialmente:
-- Para cada output retornado:
+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:
+- **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)`.
-  - Se score >= 9: marcar `done`.
+  - Gravar o score: `morph-spec score {feature} {taskId} {score} --dims {a},{c},{q},{t}`.
+  - Se score >= 9: marcar `done` em tasks.json (tool Edit — só campos mutáveis).
   - Se score < 9: marcar `pending` novamente com nota — volta ao modo sequencial, onde o loop de correção (até 3 tentativas) busca o score 9.
 
 Depois do batch paralelo, executar o restante em modo sequencial (passo 3a).
@@ -157,7 +166,7 @@ Sinais de risco para Gate 3:
 - Presença de erros não resolvidos.
 - Mudanças incidentais em standards/.morph/framework/.
 
-Mesma lógica do Gate 1/Gate 2 via `shouldPauseGate(config, signals)`:
+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`
@@ -178,6 +187,9 @@ Mesma lógica do Gate 1/Gate 2 via `shouldPauseGate(config, signals)`:
 - Não pular `morph-eval` — uma task só avança com score >= 9; abaixo disso, o loop de correção roda (não pausa).
 - Não reescrever spec.md/mandate.md durante implement (são read-only após Gate 2 — `protect-spec-files.js` hook bloqueia).
 - 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).
 
 ## Output esperado
 
@@ -193,5 +205,6 @@ Mesma lógica do Gate 1/Gate 2 via `shouldPauseGate(config, signals)`:
 - `framework/skills/core/morph-implement/SKILL.md`
 - `framework/skills/core/morph-eval/SKILL.md`
 - `framework/skills/core/morph-review/SKILL.md`
-- `src/lib/tasks/tasks-json-parser.js` — DAG queries (`getReadyTasks`, `getPendingTasks`)
-- `src/lib/risk-detector.js` — `shouldPauseGate`
+- `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/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.5.0"
+cliVersion: "7.7.0"
 ---
 
 # morph-brainstorming
@@ -75,17 +75,12 @@ O harness conhece o stack por padrão. Não pergunte sobre tecnologia a menos qu
 
 5. Apresente o Gate 1 segundo trust mode.
 
-   Ler `.morph/config/config.json → trust` (default `"auto"`). Calcular sinais de risco via `src/lib/risk-detector.js`:
+   Ler `.morph/config/config.json → trust` (default `"auto"`). Calcular os sinais de risco em linguagem natural — sem scripts:
 
-   ```js
-   import { shouldPauseGate, getRiskSignals } from '../../../src/lib/risk-detector.js';
-   const signals = {
-     designSystemDivergence: /* from passo 3 */,
-     standardsViolations: /* lista de violações detectadas */,
-   };
-   const { pause, reason } = shouldPauseGate(config, signals);
-   const riskList = getRiskSignals(signals);
-   ```
+   - `designSystemDivergence` = detectado no passo 3 (fontes de design conflitantes).
+   - `standardsViolations` = lista de violações detectadas.
+
+   **Decisão de pausa** (regras da tabela do MORPH.md §5): `trust: manual` → pausa sempre; `designSystemDivergence` → pausa; `standardsViolations` não-vazio → pausa; caso contrário → auto-passa (`pause: false`). Monte `reason` com o sinal que disparou.
 
    **Persista a decisão no `feature.json` autoritativo da feature ANTES de apresentar ou auto-aprovar** — grave
    `gateDecisions.proposal = { pause, reason, signals, trust, decidedAt: <ISO> }` em `.morph/features/{feature}/feature.json`
@@ -127,4 +122,4 @@ O harness conhece o stack por padrão. Não pergunte sobre tecnologia a menos qu
 - `.morph/framework/MORPH.md` — seções 1 (Papéis), 2 (Fases), 5 (Gates), Trust Mode
 - `.morph/framework/standards/STANDARDS.json` — para referência de standards relevantes à stack
 - `framework/skills/core/morph-stack-scan/SKILL.md` — invocada na Parte 2
-- `src/lib/risk-detector.js` — `shouldPauseGate(config, signals)` para Gate 1
+- `.morph/framework/MORPH.md` §5 — regras de pausa do Gate 1 (trust mode)

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.5.0"
+cliVersion: "7.7.0"
 ---
 
 # morph-eval
@@ -17,11 +17,13 @@ O objetivo não é punir — é identificar o que melhorar antes de seguir adian
 Após concluir uma tarefa ou ao finalizar a fase de implementação.
 Também invocado ao receber o retorno de um sub-agent com auto-score < 7.
 
+> **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.
+
 ## O que fazer
 
 1. Identifique o escopo da avaliação: tarefa única ou fase completa.
 
-2. Para cada dimensão, leia a rubrica correspondente em `framework/evals/rubrics/`:
+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
@@ -49,9 +51,9 @@ Também invocado ao receber o retorno de um sub-agent com auto-score < 7.
 - Trace atualizado com `eval_score` e `eval_dimensions`
 
 ## Referências
-- `framework/evals/rubrics/architecture.md` — rubrica de arquitetura (30%)
-- `framework/evals/rubrics/contracts.md` — rubrica de contratos (25%)
-- `framework/evals/rubrics/code-quality.md` — rubrica de qualidade (25%)
-- `framework/evals/rubrics/test-coverage.md` — rubrica de cobertura (20%)
-- `framework/evals/trace-schema.md` — formato canônico do trace
-- `framework/MORPH.md` — seção 1 (papel Evaluator)
+- `.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/trace-schema.md` — formato canônico do trace
+- `.morph/framework/MORPH.md` — seção 1 (papel Evaluator)

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.5.0"
+cliVersion: "7.7.0"
 ---
 
 # morph-implement
@@ -35,7 +35,7 @@ Ao iniciar cada task de `tasks.json` — antes de escrever qualquer código. Nor
 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.
-   - O `**Persona:**` que você grava no recap (passo 6) **deve** ser o `name` exato de um agente que existe em `agents.json` — é assim que o reviewer audita de qual ponto de vista a task foi feita. Uma persona que não casa com nenhum agente do registro é um sinal de que o consult não aconteceu.
+   - 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:
    - **Domínio diferente do que você tem carregado agora** (a persona do passo 3 difere da que você vinha usando) — gatilho mais importante: o especialista carrega seus próprios standards sem inchar seu contexto.
@@ -47,7 +47,7 @@ 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.
 
-   **Se for despachar — use este template (passe a persona e o standard escopados, nunca um agente genérico sem contexto de domínio):**
+   **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]
 
@@ -56,10 +56,20 @@ Ao iniciar cada task de `tasks.json` — antes de escrever qualquer código. Nor
    Arquivos relevantes: [lista de paths]
    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.
+   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.
    ```
-   Após receber o retorno: se auto-score < 7, aplique `morph-eval` antes de aceitar. Se >= 7, integre ao recap.md e vá para o passo 7.
+   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.
 
    **Se não — siga para o passo 5.**
 
@@ -74,7 +84,7 @@ Ao iniciar cada task de `tasks.json` — antes de escrever qualquer código. Nor
    ## T{N} — {title}
 
    **Standard:** {standard-id} (`.morph/framework/standards/{path}.md`)
-   **Persona:** {agent-name}
+   **Persona:** {mecanismo real — `morph-{id}` | `general-purpose (fallback: {id})` | `inline ({id})`}
    **Files:**
    - `{path}`
    - `{path}`
@@ -93,26 +103,22 @@ Ao iniciar cada task de `tasks.json` — antes de escrever qualquer código. Nor
      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 `framework/evals/trace-schema.md`)
+   - 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` via `updateTaskStatus`:
-
-   ```js
-   import { parseTasksJson, updateTaskStatus, writeTasksJson, getReadyTasks } from '../../../src/lib/tasks/tasks-json-parser.js';
-   const data = await parseTasksJson(tasksPath);
-   updateTaskStatus(data, task.id, 'done');
-   await writeTasksJson(tasksPath, data);
-   ```
+8. Atualizar `tasks.json` marcando a task como `done` — **direto com a tool `Edit` (ou `Write`)**, sem scripts:
 
-   `tasks.json` é protegido após o Gate 2, mas os campos de progresso (`status`,
-   `outputs`, `notes`) continuam graváveis durante a fase implement. `writeTasksJson`
-   grava o arquivo inteiro (Write) e é o caminho mais simples; **uma `Edit` que mexe
-   só nesses campos mutáveis também é permitida** — 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.
+   - 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`.
+   - **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.
+   - `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.
 
@@ -127,4 +133,4 @@ Ao iniciar cada task de `tasks.json` — antes de escrever qualquer código. Nor
 - `.morph/framework/agents.json` — personas dos agentes por domínio
 - `.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
-- `src/lib/tasks/tasks-json-parser.js` — `parseTasksJson`, `updateTaskStatus`, `writeTasksJson`
+- `.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 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.5.0"
+cliVersion: "7.7.0"
 ---
 
 # morph-plan
@@ -42,7 +42,7 @@ Ao iniciar a fase plan — após o `proposal.md` ser aprovado e antes de qualque
 
 4. Produza `tasks.json` em `.morph/features/{feature}/2-plan/` seguindo o schema em `.morph/framework/schemas/tasks.schema.json`.
 
-   **Formato obrigatório** (validado pelo parser em `src/lib/tasks/tasks-json-parser.js`):
+   **Formato obrigatório** (schema em `.morph/framework/schemas/tasks.schema.json` — o hook `tasks-json-guard` valida cada write):
 
    ```json
    {
@@ -72,27 +72,17 @@ 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.
 
-   Antes de retornar, validar com:
-   ```js
-   import { validateTasksJson, writeTasksJson } from '../../../src/lib/tasks/tasks-json-parser.js';
-   const { valid, errors } = validateTasksJson(data);
-   if (!valid) throw new Error(errors.join('\n'));
-   await writeTasksJson(tasksPath, data);
-   ```
+   Antes de retornar, valide rodando `morph-spec dag {feature}` — o comando parseia e valida o schema do tasks.json (ids únicos `T\d+`, enums de `status`/`effort`, `dependencies` válidas) e já imprime a análise de DAG que a `/morph-apply` vai usar. Erros de schema abortam com a lista do que corrigir.
 
 5. Apresente o Gate 2 segundo trust mode.
 
-   Ler `.morph/config/config.json → trust` (default `"auto"`). Calcular sinais de risco:
+   Ler `.morph/config/config.json → trust` (default `"auto"`). Calcular os sinais de risco em linguagem natural — sem scripts:
 
-   ```js
-   import { shouldPauseGate, getRiskSignals } from '../../../src/lib/risk-detector.js';
-   const signals = {
-     taskCount: data.tasks.length,
-     designSystemDivergence: /* herdado do brainstorming */,
-     standardsViolations: /* detectado em mandate */,
-   };
-   const { pause, reason } = shouldPauseGate(config, signals);
-   ```
+   - `taskCount` = número de tasks do tasks.json.
+   - `designSystemDivergence` = herdado do brainstorming.
+   - `standardsViolations` = violações detectadas no mandate.
+
+   **Decisão de pausa** (regras da tabela do MORPH.md §5): `trust: manual` → pausa sempre; `designSystemDivergence` → pausa; `standardsViolations` não-vazio → pausa; `taskCount > 20` → pausa; caso contrário → auto-passa (`pause: false`).
 
    **Persista a decisão no `feature.json` autoritativo da feature ANTES de apresentar ou auto-aprovar** — grave
    `gateDecisions.plan = { pause, reason, signals, trust, decidedAt: <ISO> }` em `.morph/features/{feature}/feature.json`
@@ -137,5 +127,6 @@ Ao iniciar a fase plan — após o `proposal.md` ser aprovado e antes de qualque
 - `.morph/framework/schemas/tasks.schema.json` — schema obrigatório de tasks.json
 - `.morph/features/{feature}/0-proposal/proposal.md` — escopo da feature
 - `.morph/features/{feature}/0-proposal/stack-scan.md` — contexto técnico detectado
-- `src/lib/tasks/tasks-json-parser.js` — `validateTasksJson`, `writeTasksJson`
-- `src/lib/risk-detector.js` — `shouldPauseGate`, `getRiskSignals`
+- `.morph/framework/schemas/tasks.schema.json` — schema e enums de tasks.json
+- `morph-spec dag {feature}` — valida o tasks.json e imprime a análise de DAG
+- `.morph/framework/MORPH.md` §5 — regras de pausa de gate (trust mode)

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.5.0"
+cliVersion: "7.7.0"
 ---
 
 # morph-proposal
@@ -52,12 +52,7 @@ Ler `.morph/config/config.json → trust` (default `"auto"`). Calcular sinais de
 - `designSystemDivergence` — detectado pela morph-brainstorming.
 - `standardsViolations` — violações de mandate listadas na proposal (não deveria, mas verifica).
 
-Usar `src/lib/risk-detector.js`:
-
-```js
-import { shouldPauseGate } from '../../../src/lib/risk-detector.js';
-const { pause, reason } = shouldPauseGate(config, signals);
-```
+**Decisão de pausa** (regras da tabela do MORPH.md §5, aplicadas em linguagem natural — sem scripts): `trust: manual` → `pause: true` sempre; `designSystemDivergence` → pausa; `standardsViolations` não-vazio → pausa; caso contrário → `pause: false` (auto-passa). Monte `reason` com o sinal que disparou.
 
 **Se `pause === true`**, apresentar via `AskUserQuestion`:
 
@@ -136,4 +131,4 @@ Lógica idêntica ao passo 3 (`shouldPauseGate` + AskUserQuestion ou auto-aprova
 - `.morph/framework/MORPH.md` — charter NLH completo
 - `framework/skills/core/morph-brainstorming/SKILL.md`
 - `framework/skills/core/morph-plan/SKILL.md`
-- `src/lib/risk-detector.js` — `shouldPauseGate`, `getRiskSignals`
+- `.morph/framework/MORPH.md` §5 — regras de pausa de gate (trust mode)

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.5.0"
+cliVersion: "7.7.0"
 ---
 
 # morph-review
@@ -33,7 +33,27 @@ e o `recap.md` estar atualizado. Normalmente invocada pela skill orquestradora `
    - Se não atendido: registre como "bloqueante" com descrição do gap.
    - Se parcialmente atendido: registre como "pendência" com o que falta.
 
-4. Execute morph-eval na implementação completa (fase, não tarefa) para obter scores por dimensão.
+4. **Despache o avaliador independente** — o score do Gate 3 nunca é auto-atribuído por quem implementou:
+   - Rode a suíte de testes do projeto e capture a **saída real** (não um resumo seu).
+   - Gere o **diff da implementação** (`git diff` do range da feature, ou a lista de arquivos do recap.md com seus conteúdos atuais).
+   - Despache o subagent registrado `morph-evaluator` (gerado de `agents.json` — a persona do avaliador é o system prompt dele, com tools read-only), com contexto fresco:
+     ```
+     dispatch Agent (subagent_type: "morph-evaluator") with prompt:
+       contexto: mandate.md + spec.md + diff da implementação + saída real dos testes
+       instrução: |
+         Você NÃO participou da implementação — avalie apenas o que está no diff,
+         contra o mandate. Aplique as rubricas em .morph/framework/evals/rubrics/
+         (architecture 30%, contracts 25%, code-quality 25%, test-coverage 20%)
+         seguindo as bandas 0-10 de cada uma.
+         NÃO reescreva código. NÃO toque em tasks.json, feature.json nem no board
+         de sessão. Ao concluir, ENTREGUE o relatório final — terminar idle sem
+         reportar é falha de protocolo.
+         Retorne: score 0-10 por dimensão, score composto (arch×0.30 + contracts×0.25
+         + quality×0.25 + tests×0.20), e feedback priorizado (bloqueantes primeiro)
+         para qualquer dimensão < 9.
+     ```
+   - **Fallback (tipo não registrado):** se `morph-evaluator` não estiver na sua lista de subagent types, despache `general-purpose` colando o campo `persona` do agente `evaluator` (Read em `.morph/framework/agents.json`) no topo do prompt — e **registre o fallback no review-report** (seção de método).
+   - Os scores por dimensão e o composto do review-report vêm **desse retorno**, não da sua auto-avaliação. Se o avaliador ficar idle sem reportar, cobre via SendMessage antes de prosseguir.
 
 5. Produza `review-report.md` em `.morph/features/{feature}/4-review/` com:
    - Scores por dimensão (arquitetura, contratos, qualidade, cobertura)
@@ -55,16 +75,12 @@ e o `recap.md` estar atualizado. Normalmente invocada pela skill orquestradora `
 
 8. Apresente o Gate 3 segundo trust mode.
 
-   Ler `.morph/config/config.json → trust` (default `"auto"`). Calcular sinais de risco:
+   Ler `.morph/config/config.json → trust` (default `"auto"`). Calcular os sinais de risco em linguagem natural — sem scripts:
 
-   ```js
-   import { shouldPauseGate } from '../../../src/lib/risk-detector.js';
-   const signals = {
-     evalScore: phaseScores.composite,
-     standardsViolations: blockingItems.filter(b => b.kind === 'standard').map(b => b.id),
-   };
-   const { pause, reason } = shouldPauseGate(config, signals);
-   ```
+   - `evalScore` = score composto retornado pelo **avaliador independente** (passo 4).
+   - `standardsViolations` = ids dos itens bloqueantes de standard encontrados no passo 3.
+
+   **Decisão de pausa** (mesmas regras da tabela do MORPH.md §5): `trust: manual` → `pause: true` sempre; `standardsViolations` não-vazio → `pause: true`; `evalScore < 9` → `pause: true`; caso contrário → `pause: false` (auto-passa).
 
    **Se `pause === true`**, use `AskUserQuestion`:
 
@@ -96,11 +112,11 @@ e o `recap.md` estar atualizado. Normalmente invocada pela skill orquestradora `
 - Gate 3 registrado aprovado em `.morph/features/{feature}/feature.json` (autoritativo), na forma canônica `{ approved, timestamp, approvedBy }` — via `morph-spec approve` em auto, ou pelo hook state-sync no caminho manual
 
 ## Referências
-- `.morph/framework/MORPH.md` — seção 5 (Gate 3), seção 1 (papel Evaluator), Trust Mode
-- `framework/skills/core/morph-eval/SKILL.md` — para calcular scores por dimensão
+- `.morph/framework/MORPH.md` — seção 5 (Gate 3 + regras de pausa), seção 1 (papel Evaluator), Trust Mode
+- `.claude/agents/morph-evaluator.md` — subagent do avaliador (gerado de `.morph/framework/agents.json`), despachado no passo 4
+- `framework/skills/core/morph-eval/SKILL.md` — rubricas e bandas que o avaliador aplica
 - `.morph/framework/evals/trace-schema.md` — formato canônico do trace
 - `.morph/features/{feature}/2-plan/mandate.md` — critérios de done da feature
 - `.morph/features/{feature}/2-plan/spec.md` — arquitetura e contratos
 - `.morph/features/{feature}/2-plan/decisions.md` — ADRs registrados (se existir)
 - `.morph/features/{feature}/3-implement/recap.md` — registro de execução
-- `src/lib/risk-detector.js` — `shouldPauseGate` para Gate 3

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.5.0"
+cliVersion: "7.7.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.5.0"
+cliVersion: "7.7.0"
 ---
 
 # morph-standards