@polymorphism-tech/morph-spec 8.40.0 → 8.41.0

package/framework/mcp/registry.json

@@ -167,62 +167,21 @@
         "description": "Official Stitch agent skills for Claude Code — design generation, multi-page loops, design.md export"
       }
     },
-    "gemini-image": {
+    "morph-assets": {
       "phases": ["uiux", "implement"],
-      "tools": ["generate_image", "edit_image", "continue_editing", "list_images", "get_image_info", "get_configuration_status"],
-      "serverNames": ["gemini-image", "gemini-image-mcp"],
-      "detection": "mcpServers includes gemini-image-mcp",
-      "fallback": "Manual image creation, stock photos, or placeholder divs",
-      "usage": "AI image generation for project assets (heroes, illustrations, brand images) using Gemini models",
+      "tools": ["generate_image", "edit_image", "continue_editing", "generate_video", "generate_loop_video", "get_video", "media_tool", "list_models", "library", "usage"],
+      "serverNames": ["morph-assets"],
+      "detection": "mcpServers includes morph-assets",
+      "fallback": "Manual image creation, stock photos or client-provided footage; a static poster image instead of video. Canvas frame-scrub works from any frame sequence, AI-generated or not",
+      "usage": "Single MCP for AI image and video generation plus local post-production, all models via OpenRouter. Images: default openai/gpt-image-2.5-flare, drafts microsoft/mai-image-2.6-flash, google/gemini-3.1-flash-image for 2K/4K or 6-14 references; `models` compares the same request across 2-4 models. Video: default bytedance/seedance-1-5-pro (draft/loop), final bytedance/seedance-2.0 1080p via promoteFrom; generate_video with endImage produces the directional footage that frame-scrub needs (start frame differs from end frame), generate_loop_video is only for seamless ambient loops. media_tool (ffmpeg) extracts scrub frames, posters, concat, compress and builds the approval picker. library replaces the old list_images/get_image_info/list_videos",
       "healthCheck": {
-        "toolPattern": "gemini-image",
-        "testCall": "Call get_configuration_status to verify API key and server health",
-        "testParams": {},
-        "successIndicator": "Returns status with valid API key configured",
-        "failureHint": "Gemini Image MCP not responding. Check that GEMINI_API_KEY is set in the MCP env config and that MORPH_HUB points at a built morph-HUB checkout."
-      },
-      "install": {
-        "autoInstall": false,
-        "transport": "stdio",
-        "config": {
-          "type": "stdio",
-          "command": "node",
-          "args": ["${MORPH_HUB}/mcps/gemini-image/dist/index.js"]
-        },
-        "credentials": [
-          {
-            "name": "Gemini API Key",
-            "envVar": "GEMINI_API_KEY",
-            "secret": true,
-            "helpUrl": "https://aistudio.google.com/apikey"
-          }
-        ],
-        "prerequisites": [
-          "Google AI Studio API key",
-          "Local morph-HUB checkout with mcps/gemini-image built, exposed via the MORPH_HUB env var"
-        ],
-        "stackRelevance": ["nextjs", "next"],
-        "warnings": [
-          "Internal Polymorphism MCP, not published to npm. The public gemini-image-mcp package was unpublished in 2025-04, so npx installs no longer work.",
-          "Requires GEMINI_API_KEY environment variable. Image generation costs apply per Google AI pricing."
-        ],
-        "setupGuide": "1. Get an API key at https://aistudio.google.com/apikey\n2. Build the MCP: cd $MORPH_HUB/mcps/gemini-image && npm install && npm run build\n3. Run: claude mcp add gemini-image-mcp -e GEMINI_API_KEY=<key> -- node $MORPH_HUB/mcps/gemini-image/dist/index.js\n4. Verify with get_configuration_status"
-      }
-    },
-    "seedance": {
-      "phases": ["uiux", "implement"],
-      "tools": ["generate_video", "generate_loop_video", "get_video", "list_videos"],
-      "detection": "mcpServers includes seedance",
-      "fallback": "Use client-provided footage or a static poster image; canvas frame-scrub works from any frame sequence, AI-generated or not",
-      "usage": "AI video generation for scroll-driven heroes and ambient backgrounds. generate_video with endImage produces the directional footage that frame-scrub needs (start frame differs from end frame); generate_loop_video is only for seamless ambient loops",
-      "healthCheck": {
-        "toolPattern": "seedance",
-        "testCall": "Call list_videos with limit 1 to verify the server responds (reads local history, spends no credits)",
+        "toolPattern": "morph-assets",
+        "testCall": "Call usage with op 'balance' to verify the OpenRouter key (reads the credit balance, spends no credits)",
         "testParams": {
-          "limit": 1
+          "op": "balance"
         },
-        "successIndicator": "Returns the local job history, or 'No videos in history yet'",
-        "failureHint": "Seedance MCP not responding. Check that REPLICATE_API_TOKEN is set in the MCP env config and that MORPH_HUB points at a built morph-HUB checkout."
+        "successIndicator": "Returns the OpenRouter credit balance",
+        "failureHint": "morph-assets MCP not responding. Check that OPENROUTER_API_KEY is set (morph-HUB root .env or the MCP env config) and that MORPH_HUB points at a morph-HUB checkout with mcps/morph-assets built."
       },
       "install": {
         "autoInstall": false,
@@ -230,28 +189,30 @@
         "config": {
           "type": "stdio",
           "command": "node",
-          "args": ["${MORPH_HUB}/mcps/seedance/dist/index.js"]
+          "args": ["${MORPH_HUB}/mcps/morph-assets/dist/index.js"]
         },
         "credentials": [
           {
-            "name": "Replicate API Token",
-            "envVar": "REPLICATE_API_TOKEN",
+            "name": "OpenRouter API Key",
+            "envVar": "OPENROUTER_API_KEY",
             "secret": true,
-            "helpUrl": "https://replicate.com/account/api-tokens"
+            "helpUrl": "https://openrouter.ai/settings/keys"
           }
         ],
         "prerequisites": [
-          "Replicate account with billing enabled",
-          "Local morph-HUB checkout with mcps/seedance built, exposed via the MORPH_HUB env var",
-          "ffmpeg on PATH to extract frames for scroll-scrubbing"
+          "OpenRouter account with credits",
+          "Local morph-HUB checkout with mcps/morph-assets built, exposed via the MORPH_HUB env var",
+          "ffmpeg on PATH for media_tool (scrub frames, poster, concat, compress)"
         ],
-        "stackRelevance": ["next", "react", "vite", "astro"],
+        "stackRelevance": ["next", "nextjs", "react", "vite", "astro"],
         "warnings": [
-          "Internal Polymorphism MCP, not published to npm. Requires a local morph-HUB checkout.",
-          "Paid per generation. Draft at fast/480p/4s first, render 1080p only after the take is approved.",
+          "Internal Polymorphism MCP, not published to npm. Requires a local morph-HUB checkout. Replaces the former gemini-image and seedance MCPs.",
+          "Paid per generation. Every call estimates cost first; dryRun only estimates. Above US$2, over the project budget or with unknown price it returns CONFIRMATION_REQUIRED + confirmToken: get human approval, then repeat the same call with the token.",
+          "Video is async: if generate_video returns 'generating', poll get_video with the ids. Never resend generate_video (a different request is billed again). Draft at 480p first, promote to 1080p only after the take is approved.",
+          "Video has no ZDR on OpenRouter and human faces in img2vid frames trigger moderation: keep sensitive content and faces out of the frames.",
           "Generation is stochastic and needs a human approval gate. Do not wire it into an unattended phase."
         ],
-        "setupGuide": "1. Get a token at https://replicate.com/account/api-tokens\n2. Build the MCP: cd $MORPH_HUB/mcps/seedance && npm install && npm run build\n3. Run: claude mcp add seedance -e REPLICATE_API_TOKEN=<token> -- node $MORPH_HUB/mcps/seedance/dist/index.js\n4. Verify with list_videos (reads local history, spends no credits)"
+        "setupGuide": "1. Get a key at https://openrouter.ai/settings/keys and set OPENROUTER_API_KEY in the morph-HUB root .env\n2. Build the MCP: cd $MORPH_HUB && npm install && npm run build -w mcps/morph-assets\n3. Run: claude mcp add morph-assets -e OPENROUTER_API_KEY=<key> -- node $MORPH_HUB/mcps/morph-assets/dist/index.js\n4. Verify with usage op 'balance' (spends no credits)"
       }
     },
     "graphify": {
@@ -321,9 +282,9 @@
   "_phaseMatrixNote": "Keys must be the v5 phases from framework/phases.json. The v4 keys 'design' and 'tasks' both collapsed into 'plan'; 'review' was absent entirely, so a project in review resolved to undefined. Stack-scoped MCPs (asaas, neon) stay out of this matrix on purpose — only universal ones are listed.",
   "phaseMatrix": {
     "proposal": ["context7", "graphify"],
-    "uiux": ["playwright", "context7", "stitch", "gemini-image", "seedance"],
+    "uiux": ["playwright", "context7", "stitch", "morph-assets"],
     "plan": ["context7", "graphify"],
-    "implement": ["context7", "playwright", "vercel", "gemini-image", "seedance", "graphify"],
+    "implement": ["context7", "playwright", "vercel", "morph-assets", "graphify"],
     "review": ["playwright", "context7", "graphify"]
   }
 }

package/framework/skills/core/create-umbraco-lp/SKILL.md

@@ -4,7 +4,7 @@ description: Guia a criação de uma landing page nova ponta-a-ponta a partir do
 version: core
 when-to-invoke: ao iniciar um novo projeto de LP com o template Umbraco genérico
 user-invokable: true
-cliVersion: "8.40.0"
+cliVersion: "8.41.0"
 stacks:
   - umbraco
 ---

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

@@ -4,7 +4,7 @@ description: Migra uma landing page existente (React/Vite, Next.js estático ou
 version: core
 when-to-invoke: ao receber instrução "use /migrate-lp-to-umbraco {projeto}" do usuário, ou quando o usuário descrever necessidade de migrar uma LP para Umbraco
 user-invokable: true
-cliVersion: "8.40.0"
+cliVersion: "8.41.0"
 stacks:
   - umbraco
 ---

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

@@ -4,7 +4,7 @@ description: Orquestra a execução autônoma de tasks de uma feature morph-spec
 version: core
 when-to-invoke: após Gate 2 aprovado, ao receber instrução "use /morph-apply" ou "implementar feature"
 user-invokable: true
-cliVersion: "8.40.0"
+cliVersion: "8.41.0"
 ---
 
 # morph-apply
@@ -138,7 +138,7 @@ while (true):
     options: [aceitar (marca done com ressalva no recap), continuar tentando (+3 tentativas), pular task (marca blocked)]
 ```
 
-> **Loop por task filtra; Gate 3 e CI não.** No loop o filtro é **automático**: `verify {feature} {task.id}` deixa o `group` da task escolher os nós e os arquivos de teste de `outputs` estreitarem o comando — cada nó **aparece** em `nodes.tests.runs[]` com `selection` (`narrowed`/`whole`/`out-of-scope`/`full` e o motivo), nenhum some. `--filter {ids}` só força a escolha de nós (os não casados aparecem como `skip` nomeando o filtro, e um `--filter` que não casa nada é erro de uso, exit 2, nunca um verde); `--full` desliga o recorte. A verificação pós-batch e a do Gate 3 (`morph-spec verify {feature} --json`) rodam **sem filtro**, e `verify {feature}` **nunca recorta**: a prova que o avaliador lê tem de cobrir todos os nós, e o CI idem. Forma de `project.tests[]`, regras e limites do recorte, e a tabela da divisão: `.morph/framework/CLI.md`, seção "Suítes de teste".
+> **Loop por task filtra; Gate 3 e CI não.** O sub-agent despachado não roda `verify`: só o filtro dos próprios testes, uma vez (cláusula 3). No loop o filtro é **automático**: `verify {feature} {task.id}` deixa o `group` da task escolher os nós e os arquivos de teste de `outputs` estreitarem o comando — cada nó **aparece** em `nodes.tests.runs[]` com `selection` (`narrowed`/`whole`/`out-of-scope`/`full` e o motivo), nenhum some. `--filter {ids}` só força a escolha de nós (os não casados aparecem como `skip` nomeando o filtro, e um `--filter` que não casa nada é erro de uso, exit 2, nunca um verde); `--full` desliga o recorte. A verificação pós-batch e a do Gate 3 (`morph-spec verify {feature} --json`) rodam **sem filtro**, e `verify {feature}` **nunca recorta**: a prova que o avaliador lê tem de cobrir todos os nós, e o CI idem. Forma de `project.tests[]`, regras e limites do recorte, e a tabela da divisão: `.morph/framework/CLI.md`, seção "Suítes de teste".
 >
 > **Verify vermelho consome uma tentativa** do loop (≤3) e devolve `feedback[]` acionável (erros de build, falhas de teste — linhas prefixadas por `[tests/{id}]`, que nomeiam a suíte —, issues de validador). O `morph-eval` NUNCA é invocado sobre código que não passou no verify — o juiz julga arquitetura/contratos/qualidade, o que o código determinístico não pega sozinho. Código roda antes, grátis; o juiz gasta tokens só no que sobra.
 
@@ -156,15 +156,18 @@ while (true):
 - **Standard(s):** use `task.standards` quando presente; senão, do array `standards` do agente resolvido acima em `agents.json` (e/ou do `mandate.md`), selecione o(s) path(s) `.md` relevante(s) à task.
 - **Fallback (tipo não registrado):** se `morph-{id}` não estiver na sua lista de subagent types (stack não instalado neste projeto), use `subagent_type: "general-purpose"` colando o campo `persona` no prompt — e **registre nas `notes` da task**: `dispatch-fallback: general-purpose ({id} não registrado)`. O recap deve refletir o mecanismo real.
 
+**Cole o template literal**: só os campos entre `<>` mudam; não parafraseie cláusula nem omita os parágrafos de leitura, ferramentas e comentário.
+
 ```
 dispatch Agent (subagent_type: "morph-{id}") with prompt:
   contexto: spec.md, mandate.md, task description completa, doneCriteria,
             task.reuse (veredito REUSAR/ESTENDER/CRIAR por conceito), os paths
             dos alvos de reuso e o que você já leu para a task (`arquivo:linhas`
             + o trecho)
-  standard: <path(s) .md do(s) standard(s) do domínio — leia-o(s) antes de implementar>
+  standards: <por standard: id + digest do `standards --find` + as 3-8 regras do
+             .md que ESTA task aplica, coladas; o path só para consulta pontual>
   instrução: |
-    Leia o(s) standard(s) indicado(s) antes de escrever código.
+    Siga as regras dos standards acima; abra o .md só para uma dúvida pontual.
     Implemente esta task (ou cadeia de tasks do fluxo) sem depender do trabalho
     dos outros agentes deste batch: seu ISOLAMENTO é de ESTADO e de ÁRVORE DE
     TRABALHO — nunca de conhecimento do codebase. Antes de criar tipo,
@@ -173,9 +176,20 @@ dispatch Agent (subagent_type: "morph-{id}") with prompt:
     (`no-graph`), caia para `grep -rn "<nome>"` e siga — a ausência de grafo
     nunca bloqueia. Se algo cobre o caso, reuse ou estenda; se criar mesmo
     assim, diga por que em uma linha no relatório.
-    Leitura: não releia o que este prompt já traz. Em arquivo grande, `Grep`
-    acha a linha e `Read` com `offset`/`limit` lê só o trecho; leituras que não
-    dependem uma da outra vão no mesmo turno, em paralelo.
+    Leitura e turnos: cada turno custa ~10 s antes de a tool rodar, e o teto de
+    turnos corta sem aviso. Chamadas que não dependem uma da outra vão no MESMO
+    turno: leia de uma vez todos os arquivos que este prompt lista, dispare os
+    Grep juntos. Use Read/Grep/Glob — nunca `grep`, `sed -n`, `cat`, `find`,
+    `ls` via Bash. Não releia o que este prompt já traz. Em arquivo grande, `Grep`
+    acha a linha e `Read` com `offset`/`limit` lê só o trecho; log de build/teste
+    se lê pelo `Grep` do erro, não inteiro.
+
+    Ferramentas: antes de supor a API de uma biblioteca (MAF, EF Core, Next,
+    shadcn, SDK de provedor), consulte o MCP `context7` (`resolve-library-id` →
+    `query-docs`). Impacto e vizinhança de símbolo vêm do grafo
+    (`morph-spec graph`), não de varredura por grep. Tool `mcp__…` que não esteja
+    carregada se carrega com `ToolSearch` (`select:<nome>`); MCP ausente nunca
+    bloqueia — siga com o fallback.
     Comentário: o padrão é nenhum. Nome, tipo e teste explicam o código; sem
     `///`/JSDoc em membro de aplicação, cabeçalho, banner de seção ou história
     da task. Só o porquê que o código não mostra, em uma linha
@@ -192,17 +206,21 @@ dispatch Agent (subagent_type: "morph-{id}") with prompt:
     2. NÃO toque em tasks.json, feature.json, state.json nem no board de
        sessão — todo estado (status de task, scores, gates) é gravado
        exclusivamente pelo orquestrador.
-    3. Verificação condicional ao isolamento:
-       - Batch SEM isolamento (working tree compartilhada): NÃO rode build/test da
-         suíte compartilhada — edições concorrentes quebram o build umas das outras;
-         a verificação é do orquestrador, pós-batch (`morph-spec verify`).
-       - Batch COM isolamento (você recebeu `isolation: "worktree"`): rode build/test
-         DENTRO do seu worktree; commite seu trabalho na branch do worktree como
-         último ato antes do relatório; reporte a branch — nunca faça merge nem
-         toque na árvore principal.
-       - Ao rodar teste: compile uma vez e rode sem recompilar (`dotnet test
-         --no-build`); só os testes que a mudança toca (`--filter`) e, depois de
-         uma falha, só os que falharam. Grave a saída em arquivo uma vez
+    3. TESTE — a prova é do orquestrador (`morph-spec verify`), não sua.
+       Escreva os testes pelo orçamento: um por pós-condição, um de regressão
+       por bug, variantes numa tabela (`[Theory]`/`it.each`). NÃO rode teste a
+       cada marco nem faça ciclo red→green: escreva código e testes, compile, e
+       rode SÓ o filtro dos seus testes UMA vez, antes do relatório; se falhar,
+       corrija e rode só os que falharam. Não rode `morph-spec verify`.
+       - Batch SEM isolamento (working tree compartilhada): só compile —
+         edições concorrentes quebram o build umas das outras; o teste roda no
+         verify do orquestrador, pós-batch.
+       - Batch COM isolamento (você recebeu `isolation: "worktree"`): a regra
+         acima vale DENTRO do seu worktree; commite seu trabalho na branch do
+         worktree como último ato antes do relatório; reporte a branch — nunca
+         faça merge nem toque na árvore principal.
+       - Ao rodar: compile uma vez e rode sem recompilar (`dotnet test
+         --no-build`), com `--filter`. Grave a saída em arquivo uma vez
          (`… > .morph/logs/test-last.log 2>&1`, sem nada depois) e leia o arquivo:
          rodar de novo com outro `| tail`/`| grep` repete o teste para ver outras
          linhas, e com pipe ou `; echo` o exit é o do último comando, não o do teste.
@@ -210,8 +228,8 @@ dispatch Agent (subagent_type: "morph-{id}") with prompt:
     4. ESCOPO: no máximo 3 tasks e ~4 arquivos por dispatch. Escopo maior falha e
        volta — fatie antes, não depois.
     5. SOBREVIVÊNCIA: o limite de turnos (`maxTurns`, no seu system prompt)
-       corta sem aviso: commite `wip({taskId})` a cada marco (arquivo que
-       compila, teste que passa), não só ao fim da task — e só os seus arquivos
+       corta sem aviso: commite `wip({taskId})` a cada marco (um arquivo ou
+       uma fatia coerente escrita — sem rodar teste para isso), não só ao fim da task — e só os seus arquivos
        (`git add <paths>`, nunca `-A`). Sem commit, a retomada recomeça do zero.
        A ~70% do limite, grave o relatório parcial no arquivo canônico: `PARCIAL`
        na 1ª linha, o feito e o que falta, sem auto-score. Depois siga ou pare,
@@ -221,6 +239,9 @@ dispatch Agent (subagent_type: "morph-{id}") with prompt:
        sessões). Encerre dev server pelo PID que você mesmo subiu.
     7. RETORNO: o relatório no arquivo canônico é o retorno. `SendMessage` não é
        substituto do relatório e não deve ser chamado.
+    8. MUTAÇÃO: nunca altere, reverta, mova ou apague código de produção para ver
+       um teste falhar (`sed`, `mv`, `git show HEAD:… >`, `git stash`, `git
+       checkout --`). A prova de que o teste morde é do avaliador no Gate 3.
 
     Seu relatório final deve conter APENAS: (1) o que foi feito em 2-3
     frases, (2) arquivos modificados, (3) problemas encontrados e como foram
@@ -243,11 +264,11 @@ dispatch Agent (subagent_type: "morph-{id}") with prompt:
 > re-despache só o que falta a partir do último `wip`. Nunca pontue nem marque `done` sobre um
 > parcial.
 
-> 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 7 cláusulas** do contrato do relatório final (as 3 do relatório + escopo, sobrevivência, processos e retorno) e os mesmos 4 itens de relatório — racional completo em `MORPH.md` §6. A única diferença é que aqui múltiplos agentes rodam ao mesmo tempo, um por fluxo independente.
+> 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 8 cláusulas** do contrato do relatório final (relatório, estado, teste, escopo, sobrevivência, processos, retorno e mutação), os mesmos parágrafos de leitura/turnos e ferramentas e os mesmos 4 itens de relatório — racional completo em `MORPH.md` §6. A única diferença é que aqui múltiplos agentes rodam ao mesmo tempo, um por fluxo independente.
 
 > **Alternativa quando os fluxos tocam os mesmos projetos/arquivos** (ex.: o mesmo csproj de testes compartilhado): siga a §3b-w abaixo em vez desta seção — despache com `isolation: "worktree"`, cada agente trabalha numa working tree própria e o orquestrador integra ao final.
 
-Aguardar todos os agentes terminarem, depois **auditar os relatórios contra o trabalho** com `morph-spec report-check {feature} {T1} {T2} … --json` (os ids do batch: sem eles o modo feature só audita tasks já `done`, e as do batch ainda não estão) — determinístico e independente da palavra dos agentes; é o passo que pega tanto o relatório ausente quanto o `report-stale` (completo, porém gravado antes do fim do trabalho: o agente relatou cedo e continuou escrevendo). Em `report-stale`, **não re-despache** — leia o campo `observed` (writes reais do `events.jsonl`) e atualize o relatório a partir dele. Vereditos e ações: `MORPH.md` §6. Em seguida **ler** `.morph/features/{feature}/3-implement/reports/{taskId}.md` de cada task — é o valor de retorno autoritativo; a mensagem de texto do dispatch, se chegou inteira, é só um atalho que economiza essa leitura. Depois, sequencialmente:
+**Batch SEM isolamento:** aguardar todos os agentes terminarem, depois **auditar os relatórios contra o trabalho** com `morph-spec report-check {feature} {T1} {T2} … --json` (os ids do batch: sem eles o modo feature só audita tasks já `done`, e as do batch ainda não estão) — determinístico e independente da palavra dos agentes; é o passo que pega tanto o relatório ausente quanto o `report-stale` (completo, porém gravado antes do fim do trabalho: o agente relatou cedo e continuou escrevendo). Em `report-stale`, **não re-despache** — leia o campo `observed` (writes reais do `events.jsonl`) e atualize o relatório a partir dele. Vereditos e ações: `MORPH.md` §6. Em seguida **ler** `.morph/features/{feature}/3-implement/reports/{taskId}.md` de cada task — é o valor de retorno autoritativo; a mensagem de texto do dispatch, se chegou inteira, é só um atalho que economiza essa leitura. Depois, sequencialmente:
 - **Rodar `morph-spec verify {feature} --json` uma única vez, pós-batch** (escopo feature, **sem `--filter`**) — os agentes não a rodaram (cláusula 3). Vermelho: use `verify.feedback` para corrigir/redespachar ANTES de qualquer morph-eval. (Com isolamento por worktree, cada agente já rodou o verify dentro do seu worktree; o orquestrador roda o verify compartilhado UMA vez após o merge — ver §3b-w.)
 - Para cada relatório retornado:
   - Aplicar `Skill(morph-eval)`.
@@ -257,13 +278,22 @@ Aguardar todos os agentes terminarem, depois **auditar os relatórios contra o t
 
 Depois do batch paralelo, executar o restante em modo sequencial (passo 3a).
 
+**Batch COM isolamento (§3b-w): dispatch rolling, não por onda.** Nenhum agente escreve na
+árvore principal, então o orquestrador não espera o batch inteiro: a cada relatório que chega,
+audita (`report-check {feature} {taskId}`), integra aquela branch (§3b-w passo 2), roda
+`verify {feature} {taskId}` e `morph-eval` + `score` daquela task, e **despacha na hora** toda
+task que ficou `ready` (`getReadyTasks`) cujos `outputs` não colidem com os das tasks em voo —
+o worktree nasce da branch da feature, já com o merge que acabou de entrar. Cap de 4 em voo. O
+`verify {feature}` de escopo feature roda uma vez, quando nada mais está em voo. Medido: uma task
+esperou 43 min pela onda depois de a dependência dela já estar pronta.
+
 ### 3b-w. Batch isolado por worktree (quando o dag recomenda)
 
 Quando o `morph-spec dag {feature}` reporta `isolation.recommended: "worktree"` (dois fluxos paralelos planejam escrever no mesmo path — colisão de `outputs`), despache cada fluxo com o parâmetro `isolation: "worktree"` do tool Agent. Cada agente trabalha numa working tree própria; build/test rodam lá dentro sem colidir.
 
-1. **Dispatch:** mesmo `subagent_type: "morph-{id}"` e standards de §3b, mais `isolation: "worktree"`. O worktree vem do hook `WorktreeCreate` do morph: nasce em `worktrees/<n>` na branch `morph-task/<n>`, com junctions (`node_modules`, `.claude`, `.morph/framework`) e `.morph/worktree.env` já prontos — se faltar infra mesmo assim, o agente roda `morph-spec worktree link --all` (fail-open); se ainda impossível, reporta "verificação: não executada" (o verify pós-merge cobre). Dev server/compose dentro do worktree já sai nas portas do bloco (o hook `worktree-env-inject` prefixa o comando; fora do Claude, `eval "$(morph-spec env)"`). O agente commita na branch do worktree como último ato e reporta a branch. Um `morph-spec verify {feature} {task}` rodado ali pelo agente é **consultivo**: lê os `outputs` **planejados** (o sub-agent não edita `tasks.json` — cláusula 2), não é persistido (worktree não registrado: `unregistered-worktree`) e não prova nada — a prova é o verify de escopo feature do passo 3.
-2. **Integração (orquestrador, após todos os relatórios):** faça o merge de cada branch reportada, uma por vez, na ordem de chegada — `git merge --no-ff <branch>`. Conflito → `git merge --abort`, marque a task de volta a `pending` com nota "merge conflict — reexecutar sequencial", siga para a próxima branch. Os paths em conflito são exatamente os de `isolation.collisions` do dag.
-3. **Pós-merge:** rode `morph-spec verify {feature} --json` UMA vez (o merge é o novo ponto de integração — verificação compartilhada obrigatória), depois `morph-eval` + `morph-spec score` por relatório, como em §3b.
+1. **Dispatch:** mesmo `subagent_type: "morph-{id}"` e standards de §3b, mais `isolation: "worktree"`. O worktree vem do hook `WorktreeCreate` do morph: nasce em `worktrees/<n>` na branch `morph-task/<n>`, com junctions (`node_modules`, `.claude`, `.morph/framework`) e `.morph/worktree.env` já prontos — se faltar infra mesmo assim, o agente roda `morph-spec worktree link --all` (fail-open); se ainda impossível, reporta "verificação: não executada" (o verify pós-merge cobre). Dev server/compose dentro do worktree já sai nas portas do bloco (o hook `worktree-env-inject` prefixa o comando; fora do Claude, `eval "$(morph-spec env)"`). O worktree nasce da branch `morph/<feature>` quando a sessão está nela (o trabalho já integrado da feature vem junto, sem `merge` manual) e com os `.env*` da raiz copiados — o prompt de dispatch não manda o agente preparar nada disso. Sessão fora de `morph/<feature>` (orquestrador na raiz) faz o worktree nascer da default: aí, e só aí, o prompt abre com `git merge --ff-only morph/<feature>`. O agente commita na branch do worktree como último ato e reporta a branch. Ele não roda `morph-spec verify` (cláusula 3): a prova é o verify do orquestrador depois do merge.
+2. **Integração (orquestrador, a cada relatório que chega):** faça o merge de cada branch reportada, uma por vez, na ordem de chegada — `git merge --no-ff <branch>`. Conflito → `git merge --abort`, marque a task de volta a `pending` com nota "merge conflict — reexecutar sequencial", siga para a próxima branch. Os paths em conflito são exatamente os de `isolation.collisions` do dag.
+3. **Pós-merge:** `verify {feature} {taskId}` no merge de cada task (dispatch rolling, §3b), depois `morph-eval` + `morph-spec score`; `morph-spec verify {feature} --json` de escopo feature UMA vez, quando nada mais está em voo (o merge é o novo ponto de integração — verificação compartilhada obrigatória).
 4. **Cleanup:** o hook `WorktreeRemove` remove o worktree **limpo** ao fim do subagent (branch sobrevive) — mas não conte com ele: rode `morph-spec worktree remove --target <path>` por worktree que sobrou (NUNCA `git worktree remove` cru — as junctions do passo 1 seriam atravessadas e o `node_modules`/`.claude` da raiz apagados) + `git branch -d morph-task/<n>` das branches integradas + `git worktree prune` (fail-open). Worktree sujo (subagent não commitou) fica, vira `unintegrated-work` no `doctor --worktrees`, e a task volta a `pending`. Branches não integradas ficam e são registradas no recap com o motivo.
 5. **Agente morto no meio:** se commitou, a branch sobrevive (retomável); senão, a task volta a `pending` na lane sequencial. Registre a falha de protocolo no recap.
 

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

@@ -4,7 +4,7 @@ description: Entende o negócio, os usuários e a arquitetura antes de qualquer
 version: core
 when-to-invoke: ao receber um novo request de feature, antes de morph-plan
 user-invokable: true
-cliVersion: "8.40.0"
+cliVersion: "8.41.0"
 ---
 
 # morph-brainstorming

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

@@ -4,7 +4,7 @@ description: Avalia a qualidade de uma tarefa ou fase com rubricas graduadas 0-1
 version: core
 when-to-invoke: ao completar uma tarefa ou ao finalizar uma fase de implementação
 user-invokable: false
-cliVersion: "8.40.0"
+cliVersion: "8.41.0"
 ---
 
 # morph-eval

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

@@ -4,7 +4,7 @@ description: ADW cirúrgico de hotfix — resolve uma queda/bug crítico de prod
 version: core
 when-to-invoke: ao receber "/morph-hotfix {feature}", quando a morph-proposal classifica o pedido como workType hotfix (Passo 0), ou o usuário diz "produção caiu / hotfix / urgente"
 user-invokable: true
-cliVersion: "8.40.0"
+cliVersion: "8.41.0"
 ---
 
 # morph-hotfix
@@ -43,7 +43,7 @@ subagent_type: "morph-scout"
 
 **Fallback** (se `morph-scout` não estiver registrado nos subagent types deste projeto): `general-purpose` com o campo `persona` do agente `scout` colado no prompt, **registrando o fallback nas notes da task**.
 
-Peça ao scout: localizar o root cause provável, os arquivos afetados e o blast radius (o que mais pode quebrar). Ele é read-only (Read/Glob/Grep/Bash somente-leitura) — não escreve código. Inclua as 7 cláusulas do contrato do relatório final no prompt (template literal em `morph-implement` §4 / `morph-apply` §3b): relatório no arquivo canônico como retorno, sem `SendMessage`; não tocar `tasks.json`/`feature.json`/`state.json` nem o board de sessão; sem build/test da suíte compartilhada em batch paralelo; no máximo 3 tasks por dispatch; commit `wip({taskId})` ao fim de cada task; nunca `taskkill /IM node.exe`.
+Peça ao scout: localizar o root cause provável, os arquivos afetados e o blast radius (o que mais pode quebrar). Ele é read-only (Read/Glob/Grep/Bash somente-leitura) — não escreve código. Inclua as 8 cláusulas do contrato do relatório final no prompt (template literal em `morph-implement` §4 / `morph-apply` §3b): relatório no arquivo canônico como retorno, sem `SendMessage`; não tocar `tasks.json`/`feature.json`/`state.json` nem o board de sessão; sem build/test da suíte compartilhada em batch paralelo; no máximo 3 tasks por dispatch; commit `wip({taskId})` ao fim de cada task; nunca `taskkill /IM node.exe`; nunca mutar código de produção para ver teste falhar.
 
 ### 3. Hotfix brief (`0-proposal/proposal.md`)
 

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

@@ -4,7 +4,7 @@ description: Guia a execução de cada tarefa de implementação com standard e
 version: core
 when-to-invoke: ao iniciar cada task de implementação listada em tasks.json
 user-invokable: false
-cliVersion: "8.40.0"
+cliVersion: "8.41.0"
 ---
 
 # morph-implement
@@ -54,12 +54,14 @@ Ao iniciar cada task de `tasks.json` — antes de escrever qualquer código. Nor
 
    > **Relação com `morph-spec dag`:** a decisão do DAG (na `morph-apply` §2) governa o **paralelismo ENTRE tasks** — quantos sub-agents rodam ao mesmo tempo. Os gatilhos acima governam o **dispatch INDIVIDUAL desta task**. São ortogonais e coexistem: `DAG: sequencial` NÃO significa "tudo inline" — significa "uma task por vez, na ordem". Exemplo: cadeia única backend de 12 tasks (DAG: sequencial); T7 tem effort L → despache T7 sozinha para `morph-dotnet-senior` e aguarde o retorno antes de seguir; T8 (S, mesmo domínio) roda inline.
 
-   **Se for despachar — use `subagent_type: "morph-{id}"` do agente identificado no passo 3.** Os subagents são gerados de `agents.json` na instalação (`.claude/agents/morph-{id}.md`) e a persona é o **system prompt** deles — não a cole no prompt. **Fallback:** se `morph-{id}` não estiver na sua lista de subagent types (stack não instalado), use `general-purpose` colando o campo `persona` no prompt e registre nas `notes` da task: `dispatch-fallback: general-purpose ({id} não registrado)`. Template do prompt (cláusulas do relatório em forma curta — racional completo em `MORPH.md` §6):
+   **Se for despachar — use `subagent_type: "morph-{id}"` do agente identificado no passo 3.** Os subagents são gerados de `agents.json` na instalação (`.claude/agents/morph-{id}.md`) e a persona é o **system prompt** deles — não a cole no prompt. **Fallback:** se `morph-{id}` não estiver na sua lista de subagent types (stack não instalado), use `general-purpose` colando o campo `persona` no prompt e registre nas `notes` da task: `dispatch-fallback: general-purpose ({id} não registrado)`. Template do prompt (cláusulas do relatório em forma curta — racional completo em `MORPH.md` §6). **Cole-o literal**: só os campos entre colchetes mudam; não parafraseie cláusula nem omita os parágrafos de leitura, ferramentas e comentário — foi assim que regras chegaram tortas ao sub-agent em campo:
    ```
    Implementar [ID]: [title da task]
 
    Spec: [description completa do tasks.json]
-   Standard: [path do .md do standard identificado no passo 2]
+   Standards: [por standard: `id` + o digest do `standards --find` + as 3-8 regras
+     do .md que ESTA task aplica, coladas. O path vai junto só para consulta
+     pontual — o sub-agente não relê standards inteiros]
    Arquivos relevantes: [os `target` de task.reuse + o que o scout/grafo apontou
      — este campo não é decorativo: é por ele que o código já existente chega
      ao sub-agente, que trabalha em contexto fresco e não conhece o projeto.
@@ -74,9 +76,20 @@ Ao iniciar cada task de `tasks.json` — antes de escrever qualquer código. Nor
    a ausência de grafo nunca bloqueia. Se algo cobre o caso, reuse ou estenda;
    se criar mesmo assim, diga por que em uma linha no relatório.
 
-   Leitura: não releia o que este prompt já traz. Em arquivo grande, `Grep`
-   acha a linha e `Read` com `offset`/`limit` lê só o trecho; leituras que não
-   dependem uma da outra vão no mesmo turno, em paralelo.
+   Leitura e turnos: cada turno custa ~10 s antes de a tool rodar, e o teto de
+   turnos corta sem aviso. Chamadas que não dependem uma da outra vão no MESMO
+   turno: leia de uma vez todos os arquivos que este prompt lista, dispare os
+   Grep juntos. Use Read/Grep/Glob — nunca `grep`, `sed -n`, `cat`, `find`,
+   `ls` via Bash. Não releia o que este prompt já traz. Em arquivo grande, `Grep`
+   acha a linha e `Read` com `offset`/`limit` lê só o trecho; log de build/teste
+   se lê pelo `Grep` do erro, não inteiro.
+
+   Ferramentas: antes de supor a API de uma biblioteca (MAF, EF Core, Next,
+   shadcn, SDK de provedor), consulte o MCP `context7` (`resolve-library-id` →
+   `query-docs`). Impacto e vizinhança de símbolo vêm do grafo
+   (`morph-spec graph`), não de varredura por grep. Tool `mcp__…` que não esteja
+   carregada se carrega com `ToolSearch` (`select:<nome>`); MCP ausente nunca
+   bloqueia — siga com o fallback.
 
    Comentário: o padrão é nenhum. Nome, tipo e teste explicam o código; sem
    `///`/JSDoc em membro de aplicação, cabeçalho, banner de seção ou história
@@ -89,25 +102,28 @@ Ao iniciar cada task de `tasks.json` — antes de escrever qualquer código. Nor
       cortesia best-effort e pode não chegar inteira). NÃO chame SendMessage.
    2. NÃO toque em tasks.json, feature.json, state.json nem no board de sessão
       — todo estado é gravado exclusivamente pelo orquestrador.
-   3. Verificação condicional ao isolamento: em batch paralelo SEM isolamento,
-      NÃO rode build/test da suíte compartilhada — a verificação
-      (`morph-spec verify`) é do orquestrador, pós-batch. Em batch COM
-      `isolation: "worktree"`, rode build/test no seu worktree, commite na
-      branch do worktree como último ato antes do relatório — nunca faça merge.
-      Worktree não commitado NÃO é removido pelo hook e vira pendência do
-      `doctor`; o commit é o que torna o seu trabalho integrável.
-      Ao rodar teste: compile uma vez e rode sem recompilar (`dotnet test
-      --no-build`); só os testes que a mudança toca (`--filter`) e, depois de
-      uma falha, só os que falharam. Grave a saída em arquivo uma vez
-      (`… > .morph/logs/test-last.log 2>&1`, sem nada depois) e leia o arquivo:
-      rodar de novo com outro `| tail`/`| grep` repete o teste para ver outras
-      linhas, e com pipe ou `; echo` o exit é o do último comando, não o do teste.
+   3. TESTE — a prova é do orquestrador (`morph-spec verify {feature} {task}`,
+      logo depois do seu retorno), não sua. Escreva os testes pelo orçamento:
+      um por pós-condição, um de regressão por bug, variantes numa tabela
+      (`[Theory]`/`it.each`). NÃO rode teste a cada marco nem faça ciclo
+      red→green: escreva código e testes, compile, e rode SÓ o filtro dos seus
+      testes UMA vez, antes do relatório; se falhar, corrija e rode só os que
+      falharam. Em batch paralelo SEM isolamento, só compile — o teste roda no
+      verify pós-batch. Em batch COM `isolation: "worktree"`, o mesmo vale no
+      seu worktree, e o último ato antes do relatório é o commit na branch do
+      worktree — nunca faça merge; worktree não commitado NÃO é removido pelo
+      hook e vira pendência do `doctor`. Ao rodar: compile uma vez e rode sem
+      recompilar (`dotnet test --no-build`), com `--filter`. Grave a saída em
+      arquivo uma vez (`… > .morph/logs/test-last.log 2>&1`, sem nada depois)
+      e leia o arquivo: rodar de novo com outro `| tail`/`| grep` repete o teste
+      para ver outras linhas, e com pipe ou `; echo` o exit é o do último
+      comando, não o do teste.
 
    4. ESCOPO: no máximo 3 tasks e ~4 arquivos por dispatch. Escopo maior falha e
       volta — fatie antes, não depois.
    5. SOBREVIVÊNCIA: o limite de turnos (`maxTurns`, no seu system prompt)
-      corta sem aviso: commite `wip({taskId})` a cada marco (arquivo que
-      compila, teste que passa), não só ao fim da task — e só os seus arquivos
+      corta sem aviso: commite `wip({taskId})` a cada marco (um arquivo ou
+      uma fatia coerente escrita — sem rodar teste para isso), não só ao fim da task — e só os seus arquivos
       (`git add <paths>`, nunca `-A`). Sem commit, a retomada recomeça do zero.
       A ~70% do limite, grave o relatório parcial no arquivo canônico: `PARCIAL`
       na 1ª linha, o feito e o que falta, sem auto-score. Depois siga ou pare,
@@ -117,6 +133,9 @@ Ao iniciar cada task de `tasks.json` — antes de escrever qualquer código. Nor
       sessões). Encerre dev server pelo PID que você mesmo subiu.
    7. RETORNO: o relatório no arquivo canônico é o retorno. `SendMessage` não é
       substituto do relatório e não deve ser chamado.
+   8. MUTAÇÃO: nunca altere, reverta, mova ou apague código de produção para ver
+      um teste falhar (`sed`, `mv`, `git show HEAD:… >`, `git stash`, `git
+      checkout --`). A prova de que o teste morde é do avaliador no Gate 3.
 
    Seu relatório (no arquivo, e na mensagem final quando ela chega) deve conter
    APENAS: (1) o que foi feito em 2-3 frases, (2) arquivos modificados,
@@ -156,8 +175,8 @@ Ao iniciar cada task de `tasks.json` — antes de escrever qualquer código. Nor
 5. Implemente a tarefa seguindo o standard e a persona identificados.
    Se encontrar ambiguidade de escopo não coberta pelo mandate, registre no decisions.md
    e resolva da forma mais conservadora — não pause para perguntar, a menos que seja bloqueante.
-   Testes rodados durante a implementação inline seguem o mesmo loop da cláusula 3 do template
-   do passo 4 (compilar uma vez, `--filter`, saída em arquivo).
+   Testes rodados durante a implementação inline seguem a cláusula 3 do template do passo 4
+   (sem red→green, uma rodada do filtro no fim, saída em arquivo) e a 8 (sem mutação).
 
    **Task com `3-implement/evidencias/{ID}.md` em `outputs`** (critério sobre saída de LLM —
    `morph-plan` §5): rode o eval ANTES de marcar `done` — e só o eval. Com nó `runner: "evals"`
@@ -246,7 +265,7 @@ Ao iniciar cada task de `tasks.json` — antes de escrever qualquer código. Nor
    > tasks.json + recap.md + `taskScores` do feature.json. **NÃO escreva o trace
    > manualmente** — a escrita manual foi removida da cerimônia por task.
 
-9. Quando invocada por `morph-apply`, retornar o controle à skill orquestradora — ela decide qual task vem em seguida via `getReadyTasks(data)`. Não rode a suíte de testes inteira do projeto por conta própria ao fim da task quando invocada pela `morph-apply` — a verificação determinística (`morph-spec verify {feature} {task}`) é do orquestrador, logo após seu retorno (ver morph-apply §3a). **Única exceção:** a execução de evidência do passo 5 — só o nó `evals`, filtrado, com `--skip-e2e`, nunca persistida (`--no-persist`); ela não é a verificação da task e não substitui a do orquestrador. **A divisão:** no loop por task o recorte é **automático** — o `group` da task escolhe as suítes e os arquivos de teste dos `outputs` (passo 8) estreitam o comando dentro de cada uma (o relógio de uma task não paga a suíte inteira); `--filter {ids}` só força a escolha de suítes (um nó não casado aparece como `skip` nomeando o filtro, e um filtro que não casa nada é erro de uso, exit 2) e `--full` desliga o recorte. A suíte **inteira** roda no Gate 3 e no CI, sem filtro — `verify {feature}` nunca recorta. A suíte completa de um projeto grande não cabe numa invocação de Bash do harness — rode em background ou por partes, nunca "suba o limite" (não há constante de timeout global no CLI). Detalhe e forma de `project.tests[]`: `.morph/framework/CLI.md`, seção "Suítes de teste". 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.
+9. Quando invocada por `morph-apply`, retornar o controle à skill orquestradora — ela decide qual task vem em seguida via `getReadyTasks(data)`. Não rode a suíte de testes inteira do projeto por conta própria ao fim da task quando invocada pela `morph-apply` — a verificação determinística (`morph-spec verify {feature} {task}`) é do orquestrador, logo após seu retorno (ver morph-apply §3a). **Única exceção:** a execução de evidência do passo 5 — só o nó `evals`, filtrado, com `--skip-e2e`, nunca persistida (`--no-persist`); ela não é a verificação da task e não substitui a do orquestrador. **A divisão:** no loop por task o recorte é **automático** — o `group` da task escolhe as suítes e os arquivos de teste dos `outputs` (passo 8) estreitam o comando dentro de cada uma (o relógio de uma task não paga a suíte inteira); `--filter {ids}` só força a escolha de suítes (um nó não casado aparece como `skip` nomeando o filtro, e um filtro que não casa nada é erro de uso, exit 2) e `--full` desliga o recorte. O sub-agent despachado roda só o filtro dos próprios testes, uma vez (cláusula 3), e nunca o `verify`. A suíte **inteira** roda no Gate 3 e no CI, sem filtro — `verify {feature}` nunca recorta. A suíte completa de um projeto grande não cabe numa invocação de Bash do harness — rode em background ou por partes, nunca "suba o limite" (não há constante de timeout global no CLI). Detalhe e forma de `project.tests[]`: `.morph/framework/CLI.md`, seção "Suítes de teste". 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)

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

@@ -4,7 +4,7 @@ description: Conduz a AUTORIA de mídia gerada por IA — escolher o modelo pelo
 version: core
 when-to-invoke: quando a tarefa é PRODUZIR imagem ou vídeo por IA (catálogo, marketing, asset de LP) e alguém precisa decidir modelo, prompt e aprovação
 user-invokable: true
-cliVersion: "8.40.0"
+cliVersion: "8.41.0"
 stacks:
   - dotnet
   - nextjs
@@ -212,4 +212,4 @@ trabalho de design". Tratar a saída como entregável vetorial é o erro clássi
 
 - Os cinco standards da tabela do topo — a fonte de API, custo, prazo e conformidade.
 - Proveniência do conhecimento absorvido: `.morph/framework/standards/PROVENANCE.json`
-  (`gemini-image`, `cinematic-lp`, `brand-design`).
+  (`morph-image`, `cinematic-lp`, `brand-design`).

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

@@ -4,7 +4,7 @@ description: Guia a produção dos artefatos de planejamento de uma feature (use
 version: core
 when-to-invoke: ao iniciar a fase plan de uma feature, após o Gate 1 (proposal aprovado)
 user-invokable: true
-cliVersion: "8.40.0"
+cliVersion: "8.41.0"
 ---
 
 # morph-plan
@@ -308,6 +308,12 @@ Ao iniciar a fase plan — após o `proposal.md` ser aprovado e antes de qualque
 
    **Preencha `outputs` (paths planejados) em cada task** — o `morph-spec dag` usa os outputs para detectar colisão de arquivos entre fluxos paralelos e recomendar `isolation: "worktree"`. Task sem `outputs` entra como footprint desconhecido (não força isolamento, mas o dag não consegue protegê-la de colisão).
 
+   **Tamanho da task: no máximo 8 `outputs`** (testes incluídos). Uma task inteira cabe num
+   dispatch; acima disso o sub-agente bate no teto de turnos e a retomada recomeça fria. Fatie por
+   pós-condição (uma task por pós-condição ou par delas, com a dependência explícita). Antes do
+   Gate 2, o `morph-spec dag` recusa (exit 1) e o `gate-check plan` pausa com `oversizedTasks`;
+   depois do Gate 2 é só aviso.
+
    **Critério sobre saída de LLM vira eval de runtime — nunca "suíte estrutural".** Duas etapas,
    como na `morph-review`: (1) **filtro mecânico** — o `mandate.md` cita ao menos um standard
    `ai-agents`; senão, a regra não se aplica. (2) **determinação sua, por task** — o

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

@@ -4,7 +4,7 @@ description: Orquestra a fase de proposta+plano de uma feature morph-spec. Encad
 version: core
 when-to-invoke: ao receber instrução "use /morph-proposal" do usuário, ou ao iniciar uma nova feature
 user-invokable: true
-cliVersion: "8.40.0"
+cliVersion: "8.41.0"
 ---
 
 # morph-proposal

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

@@ -4,7 +4,7 @@ description: Conduz a fase de revisão e produz o review-report.md para o Gate 3
 version: core
 when-to-invoke: ao iniciar a fase review, após todas as tasks de tasks.json estarem com status `done`
 user-invokable: true
-cliVersion: "8.40.0"
+cliVersion: "8.41.0"
 ---
 
 # morph-review

package/framework/skills/core/morph-stack-scan/SKILL.md

@@ -4,7 +4,7 @@ description: Varre o codebase existente, detecta stack atual, compara com o stac
 version: core
 when-to-invoke: ao iniciar uma feature em projeto brownfield (codebase já existente)
 user-invokable: true
-cliVersion: "8.40.0"
+cliVersion: "8.41.0"
 ---
 
 # morph-stack-scan

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

@@ -4,7 +4,7 @@ description: Localiza um standard específico via busca server-side (morph-spec
 version: core
 when-to-invoke: quando precisar consultar um standard específico durante a implementação
 user-invokable: true
-cliVersion: "8.40.0"
+cliVersion: "8.41.0"
 ---
 
 # morph-standards