@polymorphism-tech/morph-spec 7.6.0 → 7.7.1

package/framework/hooks/shared/tasks-validator.js

@@ -0,0 +1,68 @@
+/**
+ * tasks-validator.js — minimal hook-side schema validation for tasks.json.
+ *
+ * Mirrors VALID_STATUS / VALID_EFFORT from src/lib/tasks/tasks-json-parser.js.
+ * Hooks are installed standalone into target projects (.morph/framework/hooks/),
+ * so they cannot import from src/ — the enum lives here, duplicated on purpose
+ * and covered by tests on both sides.
+ */
+
+export const VALID_TASK_STATUS = ['pending', 'in_progress', 'done', 'skipped', 'blocked'];
+export const VALID_TASK_EFFORT = ['S', 'M', 'L', 'XL'];
+
+/**
+ * Validate the parts of a tasks.json document that hooks care about:
+ * a tasks[] array whose entries carry a valid status (and effort, when set).
+ * The production failure this guards: a leaf agent writing status "completed"
+ * (not in the enum) without any validation.
+ *
+ * @param {object} doc - parsed tasks.json
+ * @returns {{ valid: boolean, errors: string[] }}
+ */
+export function validateTasksDoc(doc) {
+  if (!doc || typeof doc !== 'object' || !Array.isArray(doc.tasks)) {
+    return { valid: false, errors: ['tasks.json must be an object with a tasks[] array'] };
+  }
+
+  const errors = [];
+  for (const task of doc.tasks) {
+    const id = task?.id ?? '?';
+    if (!VALID_TASK_STATUS.includes(task?.status)) {
+      errors.push(`task '${id}': invalid status '${task?.status}' (valid: ${VALID_TASK_STATUS.join(', ')})`);
+    }
+    if (task?.effort !== undefined && !VALID_TASK_EFFORT.includes(task.effort)) {
+      errors.push(`task '${id}': invalid effort '${task.effort}' (valid: ${VALID_TASK_EFFORT.join(', ')})`);
+    }
+  }
+  return { valid: errors.length === 0, errors };
+}
+
+/**
+ * Planned-vs-real outputs divergence: tasks whose `outputs` changed relative
+ * to the previous document but whose `notes` is still empty. The divergence
+ * itself is legitimate (outputs is a mutable progress field) — shipping it
+ * without an explanatory note is what gets flagged.
+ *
+ * @param {object} oldDoc - parsed previous tasks.json
+ * @param {object} newDoc - parsed proposed tasks.json
+ * @returns {string[]} human-readable violation messages (empty = OK)
+ */
+export function outputsDivergenceViolations(oldDoc, newDoc) {
+  const violations = [];
+  const oldById = new Map((oldDoc?.tasks ?? []).map(t => [t.id, t]));
+
+  for (const task of newDoc?.tasks ?? []) {
+    const old = oldById.get(task.id);
+    if (!old) continue;
+    const outputsChanged =
+      JSON.stringify(old.outputs ?? []) !== JSON.stringify(task.outputs ?? []);
+    const hasNote = typeof task.notes === 'string' && task.notes.trim().length > 0;
+    if (outputsChanged && !hasNote) {
+      violations.push(
+        `task '${task.id}': outputs diverged from the plan but 'notes' is empty — ` +
+        `record why in 'notes' in the same edit`
+      );
+    }
+  }
+  return violations;
+}

package/framework/mcp/registry.json

@@ -58,50 +58,6 @@
         "setupGuide": null
       }
     },
-    "github": {
-      "phases": ["tasks", "implement"],
-      "tools": ["get_repo", "search_code", "create_issue", "create_pull_request", "search_issues"],
-      "detection": "mcpServers includes github",
-      "fallback": "Bash `gh` CLI commands",
-      "usage": "Repo metadata, code search, issue creation, PR management",
-      "healthCheck": {
-        "toolPattern": "github",
-        "testCall": "Call any read-only GitHub tool (e.g., search_repositories or get_repo) to verify connectivity",
-        "testParams": {},
-        "successIndicator": "Returns repository data or search results without auth errors",
-        "failureHint": "GitHub MCP not responding. If using Docker, ensure Docker Desktop is running. Verify GITHUB_PERSONAL_ACCESS_TOKEN env var is set. Ensure the token has not expired and has the required scopes (repo, read:org)."
-      },
-      "install": {
-        "autoInstall": false,
-        "transport": "stdio",
-        "config": {
-          "type": "stdio",
-          "command": "docker",
-          "args": ["run", "-i", "--rm", "-e", "GITHUB_PERSONAL_ACCESS_TOKEN", "ghcr.io/github/github-mcp-server"],
-          "env": {
-            "GITHUB_PERSONAL_ACCESS_TOKEN": ""
-          }
-        },
-        "credentials": [
-          {
-            "name": "GitHub Personal Access Token",
-            "envVar": "GITHUB_PERSONAL_ACCESS_TOKEN",
-            "secret": true,
-            "helpUrl": "https://github.com/settings/tokens"
-          }
-        ],
-        "prerequisites": [
-          {
-            "name": "Docker",
-            "checkCommand": "docker --version",
-            "installUrl": "https://docs.docker.com/get-docker/"
-          }
-        ],
-        "stackRelevance": ["*"],
-        "warnings": [],
-        "setupGuide": "Official GitHub MCP Server (github/github-mcp-server). Requires Docker."
-      }
-    },
     "vercel": {
       "phases": ["implement"],
       "tools": ["search_docs", "list_projects", "get_deployments", "get_deployment_logs", "manage_env_vars"],
@@ -234,7 +190,8 @@
           {
             "name": "Gemini API Key",
             "envVar": "GEMINI_API_KEY",
-            "source": "Google AI Studio (https://aistudio.google.com/apikey)"
+            "secret": true,
+            "helpUrl": "https://aistudio.google.com/apikey"
           }
         ],
         "prerequisites": ["Google AI Studio API key"],
@@ -247,8 +204,8 @@
   "phaseMatrix": {
     "proposal": ["context7"],
     "uiux": ["playwright", "context7", "stitch", "gemini-image"],
-    "design": ["context7", "github"],
-    "tasks": ["context7", "github"],
-    "implement": ["context7", "playwright", "github", "vercel", "gemini-image"]
+    "design": ["context7"],
+    "tasks": ["context7"],
+    "implement": ["context7", "playwright", "vercel", "gemini-image"]
   }
 }

package/framework/rubrics/backend.json

@@ -1,7 +1,7 @@
 {
   "id": "backend",
-  "version": "1.0.0",
-  "description": "Backend-focused rubric. Higher weight on architecture, security, and package health.",
+  "version": "1.1.0",
+  "description": "Backend-focused rubric. Higher weight on architecture, security, and package health. Deterministic-validator rubric — approve threshold aligned to the single bar 9 from MORPH.md §0.",
   "categories": {
     "functionality": {
       "weight": 0.25,
@@ -35,7 +35,7 @@
     }
   },
   "thresholds": {
-    "approve": 8.0,
+    "approve": 9.0,
     "retry": 6.0
   }
 }

package/framework/rubrics/default.json

@@ -1,7 +1,7 @@
 {
   "id": "default",
-  "version": "1.0.0",
-  "description": "Default rubric for general-purpose projects. Balanced weights across all categories.",
+  "version": "1.1.0",
+  "description": "Default rubric for general-purpose projects. Balanced weights across all categories. Deterministic-validator rubric — approve threshold aligned to the single bar 9 from MORPH.md §0 (the LLM eval rubrics live in framework/evals/rubrics/*.md).",
   "categories": {
     "functionality": {
       "weight": 0.30,
@@ -30,7 +30,7 @@
     }
   },
   "thresholds": {
-    "approve": 8.0,
+    "approve": 9.0,
     "retry": 6.0
   }
 }

package/framework/rubrics/frontend.json

@@ -1,7 +1,7 @@
 {
   "id": "frontend",
-  "version": "1.0.0",
-  "description": "Frontend-focused rubric. Higher weight on design system compliance and UI quality.",
+  "version": "1.1.0",
+  "description": "Frontend-focused rubric. Higher weight on design system compliance and UI quality. Deterministic-validator rubric — approve threshold aligned to the single bar 9 from MORPH.md §0.",
   "categories": {
     "functionality": {
       "weight": 0.25,
@@ -30,7 +30,7 @@
     }
   },
   "thresholds": {
-    "approve": 8.0,
+    "approve": 9.0,
     "retry": 6.0
   }
 }

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.6.0"
+cliVersion: "7.7.1"
 ---
 
 # 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.6.0"
+cliVersion: "7.7.1"
 ---
 
 # 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.6.0"
+cliVersion: "7.7.1"
 ---
 
 # 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.6.0"
+cliVersion: "7.7.1"
 ---
 
 # 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.6.0"
+cliVersion: "7.7.1"
 ---
 
 # 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.6.0"
+cliVersion: "7.7.1"
 ---
 
 # 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)