@polymorphism-tech/morph-spec 8.44.0 → 8.45.0

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

@@ -4,57 +4,46 @@ 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.44.0"
+cliVersion: "8.45.0"
 ---
 
 # morph-implement
 
 ## Objetivo
-Garantir que cada tarefa seja executada com o standard correto, a persona de agente adequada,
-e que o resultado seja registrado no recap.md ao final.
+Executar uma task com o standard e a persona certos, até o `doneCriteria` valer e o
+`verify` da task ficar verde, e registrar o resultado no recap.
 
 ## Quando invocar
-Ao iniciar cada task de `tasks.json` — antes de escrever qualquer código. Normalmente invocada pela skill orquestradora `morph-apply`, que passa o objeto da task atual.
+Ao iniciar cada task de `tasks.json`, antes de escrever código. Normalmente chamada pela
+`morph-apply`, que passa a task atual.
 
 ## O que fazer
 
-1. **Leia o plano integral na primeira task da sessão.** No cold start (primeira task que você implementa nesta sessão — início de `/morph-apply`, ou a primeira depois de um `/compact`), **use a tool Read** em `mandate.md`, `spec.md` e `decisions.md` de `.morph/features/{feature}/2-plan/`, nessa ordem, e mantenha-os em contexto pelo resto da sessão. Nunca implemente a primeira task da sessão sem o mandate em contexto.
+1. **Contexto, uma vez por sessão.** Na primeira task da sessão (ou depois de um `/compact`), Read
+   em `2-plan/spec.md`, nos use cases que a task referencia (`2-plan/usecases/UC-*.md`) e em
+   `2-plan/decisions.md`. Nas tasks seguintes, **não releia por padrão**: o contrato do plano está
+   congelado desde o Gate 2. Releia só o trecho que falta para a task corrente.
 
-   **Nas tasks seguintes da MESMA sessão, não releia por padrão.** O conteúdo carregado na task anterior continua válido — o contrato do plano está congelado pós-Gate 2 (`protect-spec-files` bloqueia mudança nos campos de contrato), então reler os três arquivos a cada task é custo sem sinal novo. Releia (o arquivo relevante, não necessariamente os três) só quando:
-   - houve `/compact` desde a última leitura — o compact pode ter descartado o conteúdo do contexto; ou
-   - a task corrente referencia um FR ou uma decisão que você não tem em contexto — dúvida legítima, não default cego.
+   **Correção** (a `morph-apply` devolveu a task com o `feedback` do verify vermelho ou com critério
+   não atendido): corrija esses pontos no código existente — não reimplemente.
 
-   > "Na dúvida, Read" continua valendo — mas como **gatilho** de releitura pontual (compact, ou lacuna de conteúdo específico), nunca como default de reler tudo a cada task. Isso é o que muda: o contrato deixou de ser "por task" e passou a ser "por sessão".
+2. **Standard.** `morph-spec standards --find "<domínio da task>"` devolve `id · path · digest`.
+   O digest decide; Read só no `.md` escolhido. Task MAF: os `standards/ai-agents/*.md` relevantes
+   valem mesmo com docs externas consultadas. Nenhum standard cobre: registre em `decisions.md` e
+   siga o critério mais conservador.
 
-   Do `mandate.md`, identifique os standards obrigatórios e patterns proibidos. Do `spec.md`, a arquitetura e as seções de FRs referenciadas pela `description` da task corrente. Do `decisions.md`, as ADRs já registradas — para não contradizê-las nem re-decidir o que já foi decidido.
+3. **Persona.** `task.agent` e `task.standards` (carimbados pelo `morph-plan`). Plano legado sem
+   `agent`: Read em `.morph/framework/agents.json` e escolha por `domains`. O `**Persona:**` do recap
+   registra o mecanismo real: `morph-{id}`, `general-purpose (fallback: {id})` ou `inline ({id})`.
 
-   **Se a `morph-apply` passou `feedback` de uma tentativa anterior** (loop de correção — a task foi implementada mas o `morph-eval` deu score < 9): isto NÃO é uma implementação do zero. Leia o feedback priorizado, identifique os pontos bloqueantes listados, e **corrija especificamente esses pontos** no código já existente. Não reescreva o que já passou; foque no que o eval apontou. Registre no recap qual feedback foi endereçado em qual tentativa.
+4. **Despachar ou não.** Despache (`subagent_type: "morph-{id}"`) quando a task muda de domínio,
+   tem effort L/XL, já falhou 3 correções no mesmo ponto, exige ler arquivo > 500 linhas, ou repete
+   um padrão > 3 vezes. Inline só para S/M no domínio já carregado. O DAG da `morph-apply` decide
+   quantas tasks rodam ao mesmo tempo; este passo decide quem executa cada uma.
 
-2. Identifique o standard mais relevante para a tarefa atual:
-   - Rode `morph-spec standards --find "<domínio/tecnologia da task>"` (filtros opcionais `--category`, `--tags`, `--json`) — o comando busca em `.morph/framework/standards/STANDARDS.json` e devolve o top 3 candidatos como `id · path · digest`, sem você abrir o index inteiro.
-   - **O digest decide a escolha.** Escolha 1-3 standards pelo `digest` retornado. Depois, **use a tool Read APENAS no(s) arquivo(s) `.md` escolhido(s)** (campo `path` do resultado) — o digest te diz qual candidato é o certo; o arquivo escolhido se lê inteiro, porque é onde vivem as convenções aplicáveis.
-   - **Tarefas de agente de IA (MAF):** Read os `.morph/framework/standards/ai-agents/*.md` relevantes para a task. Mesmo que você consulte docs externas (context7) para a superfície da API do `Microsoft.Agents.AI`, as **convenções de projeto** (single-agent por padrão, provider/caching/observability, A2A, middleware) vêm desses standards. Uma fonte externa não as conhece.
-   - Se nenhum standard cobrir o caso, registre no decisions.md e adote o critério mais conservador.
-
-3. Identifique a persona de agente adequada para a tarefa:
-   - **Fonte primária: `task.agent` do tasks.json.** O `morph-plan` já resolveu `agents.json` uma vez no momento do plano e carimbou `agent` (id da persona, sem prefixo `morph-`) e `standards` por task (ver `morph-plan` §5a) — use esses campos diretamente, sem reabrir `agents.json`.
-   - **Fallback — plano legado (task sem `agent`):** **use a tool Read em `.morph/framework/agents.json`** — não recupere a persona de memória. Encontre o agente cujo `domains` cobre o domínio da tarefa e leia o campo `persona` para adotar o ponto de vista durante a implementação.
-   - O array de standards — `task.standards` quando presente, ou o `standards` do agente lido no fallback — é o ponto de partida do passo 2.
-   - O `**Persona:**` que você grava no recap (passo 6) **deve** refletir o mecanismo REAL usado: `morph-{id}` (dispatch pelo subagent registrado), `general-purpose (fallback: {id})` (tipo não registrado — registre também nas `notes` da task), ou `inline ({id})` (você executou inline adotando a persona). É assim que o reviewer audita contra o que o runtime realmente registrou — uma auto-declaração que não casa com o dispatch é drift.
-
-4. Decida se a task deve ser despachada para um sub-agent. Dispatch é o **default** para o caso pesado/multi-domínio (ver `.morph/framework/MORPH.md` seção 6) — despache quando a task dispara qualquer gatilho:
-   - **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.
-   - Esforço L ou XL (duração estimada > 5 minutos).
-   - Mais de 3 tentativas de correção falharam no mesmo problema.
-   - Análise de arquivo com > 500 linhas.
-   - Task repetitiva com > 3 instâncias do mesmo padrão.
-   - Risco de contaminar o contexto principal com detalhes de baixo nível irrelevantes para o fluxo.
-
-   Inline é aceitável só para tasks S/M **dentro do domínio já carregado**. Se for inline numa task que dispara um gatilho, registre a justificativa em uma linha no `decisions.md` — inline silencioso numa task pesada/multi-domínio é o anti-padrão da seção 6.
-
-   > **Relação com `morph-spec dag`:** a decisão do DAG (na `morph-apply` §2) governa o **paralelismo ENTRE tasks** — quantos sub-agents rodam ao mesmo tempo. Os gatilhos acima governam o **dispatch INDIVIDUAL desta task**. São ortogonais e coexistem: `DAG: sequencial` NÃO significa "tudo inline" — significa "uma task por vez, na ordem". Exemplo: cadeia única backend de 12 tasks (DAG: sequencial); T7 tem effort L → despache T7 sozinha para `morph-dotnet-senior` e aguarde o retorno antes de seguir; T8 (S, mesmo domínio) roda inline.
-
-   **Se for despachar — use `subagent_type: "morph-{id}"` do agente identificado no passo 3.** Os subagents são gerados de `agents.json` na instalação (`.claude/agents/morph-{id}.md`) e a persona é o **system prompt** deles — não a cole no prompt. **Fallback:** se `morph-{id}` não estiver na sua lista de subagent types (stack não instalado), use `general-purpose` colando o campo `persona` no prompt e registre nas `notes` da task: `dispatch-fallback: general-purpose ({id} não registrado)`. Template do prompt (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:
+   Tipo `morph-{id}` não registrado: `general-purpose` com o campo `persona` colado no prompt, e
+   `dispatch-fallback: general-purpose ({id} não registrado)` nas `notes` da task.
+   Template do prompt para `subagent_type: "morph-{id}"` — cole literal, só os campos entre colchetes mudam:
    ```
    Implementar [ID]: [title da task]
 
@@ -63,11 +52,9 @@ Ao iniciar cada task de `tasks.json` — antes de escrever qualquer código. Nor
      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.
-     O que você já leu para esta task entra como `arquivo:linhas` + o trecho]
-   Reuso: [task.reuse do tasks.json — `CONCEITO: VEREDITO → alvo`, uma linha por
-     conceito; ausente numa task que não introduz conceito]
+     — é por aqui que o código existente chega ao sub-agente, que trabalha em
+     contexto fresco. O que você já leu entra como `arquivo:linhas` + o trecho]
+   Reuso: [task.reuse — `CONCEITO: VEREDITO → alvo`, uma linha por conceito]
    Done quando: [doneCriteria do tasks.json]
 
    Antes de criar tipo, componente, hook ou serviço NOVO, verifique se já
@@ -87,21 +74,20 @@ Ao iniciar cada task de `tasks.json` — antes de escrever qualquer código. Nor
    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.
+   (`morph-spec graph`). Tool `mcp__…` não 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
    (`architecture-code-comments`). O elo com a pós-condição vai no nome do
-   teste; a densidade do arquivo vizinho não é modelo. O hook `comment-guard`
-   bloqueia a edição que adiciona história, banner ou bloco longo.
+   teste. O hook `comment-guard` bloqueia a edição que adiciona história,
+   banner ou bloco longo.
 
    Contrato do relatório final:
    1. GRAVE `.morph/features/{feature}/3-implement/reports/[ID].md` ANTES de
-      encerrar — é o retorno autoritativo, não a sua mensagem final (que é
-      cortesia best-effort e pode não chegar inteira). NÃO chame SendMessage.
+      encerrar — é o retorno autoritativo, não a sua mensagem final. 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. TESTE — a prova é do orquestrador (`morph-spec verify {feature} {task}`,
@@ -109,186 +95,100 @@ Ao iniciar cada task de `tasks.json` — antes de escrever qualquer código. Nor
       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.
-
+      testes UMA vez, em primeiro plano, antes do relatório; se falhar, corrija e rode só os que falharam. Grave a
+      saída em arquivo (`… > .morph/logs/test-last.log 2>&1`, sem nada depois)
+      e leia o arquivo — um pipe troca o exit do teste pelo do último comando.
+      Em batch paralelo SEM isolamento, só compile. Com `isolation: "worktree"`,
+      o mesmo vale no seu worktree, e o último ato é o commit na branch dele.
    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 (um arquivo ou
-      uma fatia coerente escrita — sem rodar teste para isso), não só ao fim da task — e só os seus arquivos
+      uma fatia coerente escrita), 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,
-      por decisão sua; ao concluir, o relatório final substitui o parcial, sem o
-      `PARCIAL`. Sem limite declarado, bastam os commits por marco.
+      na 1ª linha, o feito e o que falta, sem critério dado como atendido. Depois
+      siga ou pare, por decisão sua; o relatório final substitui o parcial.
    6. PROCESSOS: NUNCA `taskkill /IM node.exe` (derruba os MCPs de todas as
       sessões). Encerre dev server pelo PID que você mesmo subiu. Build e
-      suíte pesados (`dotnet build`, `dotnet test`, `docker compose up`) rodam
-      por `morph-spec heavy run -- <comando>`: exit 3 é fila cheia, não erro do
-      código — espere e repita.
+      suíte pesados rodam por `morph-spec heavy run -- <comando>`, em primeiro
+      plano. Exit 3 é fila cheia depois da espera da própria fila: não repita
+      nem espere em laço — diga no relatório o que não rodou.
    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,
-   (3) problemas encontrados e como foram resolvidos, (4) auto-score 0-10 com
-   justificativa em uma linha. Relatório ausente, oco, ou sem os 4 itens, é
-   falha de protocolo.
+   Formato do relatório:
+     (1) o que foi feito, em 2-3 frases;
+     **Arquivos:** um item `- \`path\`` por arquivo criado ou modificado;
+     **Critérios:** cada doneCriteria — atendido (o teste ou `arquivo:linha` que o
+       prova) ou não atendido (por quê);
+     (4) problemas encontrados e como foram resolvidos.
    ```
-   **Passo pós-dispatch (seu, antes de avaliar o relatório):** rode
-   `morph-spec report-check {feature} {taskId} --json` ao retomar o controle. Além do veredito do
-   relatório, o bloco `tree` traz o que está não commitado fora de `.morph/` (`dirty`, `diffstat`),
-   os commits sobre a default (`commits`) e os marcadores `MUTACAO` esquecidos (`markers`) — a
-   conferência de `git status`, `git diff` e `grep`, numa chamada só. Um sub-agent morto no meio
-   deixa o disco a meio caminho — e um relatório lido sobre uma árvore que ninguém conferiu avalia
-   um estado que ninguém quis. Árvore inesperadamente suja ou `markers` não vazio é falha de
-   protocolo: registre no recap antes de pontuar. Essa saída serve ao passo 7 enquanto a árvore
-   não mudar; depois de uma correção sua, rode de novo. Dispatch com `isolation: "worktree"`:
-   depois de ler o relatório, `morph-spec worktree reap --json` remove o worktree do agent que parou
-   limpo e sem commit exclusivo; o que fica vem listado com a razão.
-
-   Após o retorno do dispatch: **leia primeiro** `.morph/features/{feature}/3-implement/reports/[ID].md`
-   — é o valor de retorno autoritativo. Trate a mensagem de texto do sub-agent, se chegou inteira,
-   como um atalho que economiza essa leitura — nunca como a única fonte. Arquivo ausente é falha de
-   protocolo (registre no recap e re-despache/complete a partir do que o sub-agent já fez, se
-   recuperável). 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 a task deve evidência de runtime (`evidencias/` em `outputs`), confira o
-   arquivo como manda o passo 5 antes do `done`.
-
-   **Relatório com `PARCIAL` na 1ª linha = a task não está pronta**: o sub-agent parou antes do fim
-   (limite de turnos, cláusula 5). O `report-check` o acusa como `report-incomplete`, e aqui a ação é
-   retomar, não completar DEGRADADO: retome o MESMO agente por `SendMessage`, colando no recado
-   `tree.dirty` e `tree.commits` do `report-check` e o que falta (ele guarda o contexto), ou
-   re-despache só o que falta a partir do último `wip`. Nunca pontue nem marque `done` sobre um
-   parcial.
-
-   **Se não — siga para o passo 5.**
-
-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 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"`
-   declarado, `morph-spec verify {feature} --filter {id-do-nó-evals} --skip-e2e --no-persist`:
-   escopo de feature porque no de task o nó `evals` é pulado; `--filter` só estreita o nó de testes
-   (build e validadores rodam; o e2e subiria o stack, daí `--skip-e2e`); `--no-persist` garante que
-   esta execução nunca escreve no `feature.json` — é sonda, não prova para gate nenhum.
-   É a única exceção ao passo 9. Sem nó `evals`, execute o eval direto e registre
-   "nenhum nó — execução manual". Grave o arquivo com: o critério (literal); o id do nó e o
-   cenário (ou aquele rótulo); o modelo efetivo; a versão ou o hash do prompt, nunca o prompt cru;
-   entrada e saída sem dado pessoal (`ai-agents-testing-ai`, "Captura do que foi ao provedor"); o
-   veredito com a razão. Não é o `reports/{ID}.md`: aquele diz o que o sub-agente fez; este prova,
-   rodando, que a saída do modelo atende ao critério. Vale também para task despachada — sem o
-   arquivo, ela não vai para `done` (passo 8).
-
-6. Ao concluir a tarefa, **append** um bloco a `recap.md` em `.morph/features/{feature}/3-implement/`
-   usando este template **obrigatório** (campos não-opcionais — sem standard, a entrada não conta):
-
+   **Passo pós-dispatch (seu, ao retomar o controle):** `morph-spec report-check {feature} {taskId} --json`. O veredito do
+   relatório e o bloco `tree` (`dirty`, `diffstat`, `commits`, `markers`) mostram o disco que o agente
+   deixou. Árvore suja sem explicação ou `markers` não vazio: registre no recap. Com
+   `isolation: "worktree"`, depois de ler o relatório rode `morph-spec worktree reap --json`.
+
+   **Leia `3-implement/reports/[ID].md`** — a mensagem de texto do agente é atalho, nunca a fonte.
+   Arquivo ausente é falha de protocolo: registre e complete a partir do que ficou no disco.
+
+   **`PARCIAL` na 1ª linha = a task não está pronta** — o `report-check` o acusa como `report-incomplete`.
+   Retome o MESMO agente por `SendMessage`,
+   colando `tree.dirty`, `tree.commits` e o que falta; ou re-despache só o que falta a partir do
+   último `wip`. Nunca marque `done` sobre um parcial.
+
+5. **Implementação inline.** Siga o standard e a persona. Ambiguidade não coberta pelo plano:
+   registre em `decisions.md` e resolva pelo lado conservador, sem pausar. Testes: as cláusulas 3 e 8
+   do template valem para você também.
+
+   **Task com `3-implement/evidencias/{ID}.md` em `outputs`** (critério sobre saída de LLM): rode o
+   eval antes do `done`, e só ele. Com nó `runner: "evals"`:
+   `morph-spec verify {feature} --filter {id-do-nó-evals} --skip-e2e --no-persist` — escopo de
+   feature porque no de task o nó `evals` é pulado; `--skip-e2e` porque o stack subiria;
+   `--no-persist` porque esta execução é sonda, não prova de gate. Sem nó `evals`, rode o eval direto
+   e registre "nenhum nó — execução manual". O arquivo traz: o critério (literal), o nó e o cenário,
+   o modelo efetivo, a versão ou o hash do prompt (nunca o prompt cru), entrada e saída sem dado
+   pessoal, e o veredito com a razão. Não é o `reports/{ID}.md`: aquele diz o que o agente fez; este
+   prova, rodando, que a saída atende ao critério.
+
+6. **Recap.** Append em `3-implement/recap.md`:
    ```markdown
    ## T{N} — {title}
 
    **Standard:** {standard-id} (`.morph/framework/standards/{path}.md`)
-   **Persona:** {mecanismo real — `morph-{id}` | `general-purpose (fallback: {id})` | `inline ({id})`}
+   **Persona:** {`morph-{id}` | `general-purpose (fallback: {id})` | `inline ({id})`}
    **Files:**
    - `{path}`
-   - `{path}`
 
-   {2-3 frases sobre o que foi feito}
-
-   **Issues encontrados:** {breve descrição ou "nenhum"}
+   {2-3 frases}
    ```
+   Sem standard que cubra: `Standard: ad-hoc (see decisions.md ADR-{N})`. O `validate-completion`
+   cobra o bloco.
 
-   Regras:
-   - **Standard é obrigatório** — sempre referenciar pelo menos um standard de
-     `.morph/framework/standards/STANDARDS.json` que justificou as escolhas de implementação.
-     Se nenhum standard existente cobre, registre a decisão em `decisions.md` E cite
-     `Standard: ad-hoc (see decisions.md ADR-{N})` no recap.
-   - Sem standard ⇒ a task falha no validador de Gate 3 (`validate-completion`)
-     e o reviewer não consegue auditar de onde veio a decisão técnica.
-
-7. **Antes de marcar a task como `done`, audite o relatório contra o trabalho:**
-
-   ```
-   morph-spec report-check {feature} {taskId} --json
-   ```
-
-   Não é burocracia — é a única checagem que não depende da palavra do agente. Veredito
-   `report-stale` significa **relatório completo e VELHO**: a task seguiu escrevendo arquivos depois
-   que ele foi gravado, então o texto descreve um estado já ultrapassado. Aconteceu de verdade: o
-   sub-agent gravou o esqueleto dizendo "teste ainda não escrito — em andamento", escreveu os 9
-   testes, e foi cortado antes de atualizar. Quem leu o relatório quase marcou a task como
-   incompleta e re-despachou trabalho pronto. **Nesse caso não re-despache**: leia `observed`
-   (arquivos realmente escritos, do `events.jsonl`, não auto-declarados) e atualize o relatório a
-   partir dessa evidência. Demais vereditos: tabela em `MORPH.md` §6.
-
-8. Atualizar `tasks.json` marcando a task como `done` — **direto com a tool `Edit` (ou `Write`)**, sem scripts:
-
-   - Mude apenas os campos mutáveis da task: `status` (enum válido: `pending`,
-     `in_progress`, `done`, `skipped`, `blocked` — nunca invente valores como
-     `"completed"`), `outputs` (paths realmente produzidos) e `notes`.
-   - **`outputs` contém apenas paths realmente produzidos.** Deleções, remoções
-     e anotações (ex.: `"pasta/ (removido: a, b)"`) se registram em `notes`,
-     nunca em `outputs`. E `notes` é **uma string única** — não um array.
-   - **`outputs` DEVE listar TODO arquivo criado ou modificado pela task — sem exceção.**
-     Isso inclui artefato auxiliar que não estava no plano original (ex.: uma
-     factory de design-time, um seed, um arquivo de config gerado a reboque de
-     outro output) — se a task o produziu, ele entra em `outputs` junto com o
-     resto. Arquivo shipped sem dono em `outputs` de task alguma é falha de
-     protocolo: o Gate 3 (avaliador independente da `morph-review`) aponta como
-     achado de rastreabilidade, mesmo que o arquivo em si esteja correto — quem
-     lê `tasks.json`/`recap.md` depois precisa achar todo arquivo em produção
-     citado em algum lugar, e é essa a lacuna que este parágrafo fecha.
-   - **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 (e a
-     mensagem de violação aponta o campo/valor exato do problema). Isto é o
-     caso mais comum em que a regra acima se aplica: todo arquivo extra na lista
-     de "realmente produzidos" acima do planejado é, por definição, uma
-     divergência real vs. planejado — a note explica o porquê.
-   - `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.
+7. **Audite antes do `done`:** `morph-spec report-check {feature} {taskId} --json`. `report-stale` =
+   relatório completo e velho (a task seguiu escrevendo depois dele): **não re-despache** — leia
+   `observed` (escritas reais, do `events.jsonl`) e atualize o relatório. Demais vereditos:
+   `MORPH.md` §6.
 
-   > **Trace automático:** este write de `tasks.json` dispara o hook `trace-autogen`,
-   > que gera/atualiza `.morph/traces/YYYY-MM-DD-{feature}-implement.json` a partir de
-   > tasks.json + recap.md + `taskScores` do feature.json. **NÃO escreva o trace
-   > manualmente** — a escrita manual foi removida da cerimônia por task.
+8. Atualizar `tasks.json` marcando a task como `done` (Edit, só campos mutáveis):
+   - `status`: `pending` | `in_progress` | `done` | `skipped` | `blocked`.
+   - `outputs` DEVE listar TODO arquivo criado ou modificado pela task, inclusive artefato auxiliar
+     fora do plano (factory, seed, config gerada). Arquivo em produção sem dono em `outputs` é falha de
+     protocolo que o Gate 3 aponta. Deleções vão em `notes` (string única), nunca em `outputs`.
+   - Divergiu do planejado: o porquê em `notes` na mesma edição — o hook exige.
 
-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). **`verify` com exit 3** (`status: "busy"`) é fila de slot pesado cheia, não vermelho: nada foi verificado e nada foi gravado — repita a mesma chamada em vez de abrir uma tentativa de correção. **Ú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.
+9. Quando invocada por `morph-apply`, devolva o controle a ela e não rode a suíte do projeto: o `verify {feature} {task}` é do orquestrador. **Única exceção:** a execução de evidência do passo 5, filtrada ao nó `evals`, com `--skip-e2e` e `--no-persist`. No loop por task o recorte é automático (o `group` escolhe as suítes, os testes de `outputs` estreitam o comando; `--filter` só força a escolha de suítes, `--full` desliga o recorte); a suíte inteira roda no Gate 3 e no CI, sem filtro. Invocada manualmente: siga para a próxima task ready.
 
 ## Output esperado
-- Código implementado conforme o standard consultado (direto ou via sub-agent)
-- Quando despachada: `.morph/features/{feature}/3-implement/reports/{taskId}.md` — o relatório
-  autoritativo do sub-agent, canal durável (passo 4)
-- Na task com `3-implement/evidencias/{taskId}.md` em `outputs`: esse arquivo — a evidência de
-  runtime do eval (passo 5), distinta do relatório do sub-agent em `reports/`
-- `.morph/features/{feature}/3-implement/recap.md` atualizado com entrada da task concluída
-- `.morph/features/{feature}/2-plan/tasks.json` com status da task atualizado para `done`
-- `.morph/features/{feature}/2-plan/decisions.md` atualizado se houver decisão não trivial
-- Trace em `.morph/traces/` gerado automaticamente pelo hook `trace-autogen` (a skill não o escreve)
+- Código conforme o standard; `3-implement/reports/{taskId}.md` quando despachada
+- `3-implement/evidencias/{taskId}.md` na task que o lista em `outputs`
+- `recap.md` com o bloco da task; `tasks.json` com a task `done`
+- `decisions.md` quando houve decisão não trivial
 
 ## Referências
-- `morph-spec standards --find "<query>" [--category] [--tags] [--json]` — busca de standard por digest (passo 2); não abre `STANDARDS.json` inteiro
-- `.morph/framework/agents.json` — personas dos agentes por domínio; lido apenas no fallback do passo 3 (task sem `agent` — plano legado)
-- `.morph/framework/MORPH.md` seção 6 — critérios de dispatch e contrato de retorno do sub-agent
-- `.morph/features/{feature}/2-plan/mandate.md` — contrato da feature
-- `.morph/features/{feature}/2-plan/tasks.json` — `task.agent`/`task.standards` carimbados pelo `morph-plan` §5a (fonte primária dos passos 2 e 3)
-- `.morph/framework/schemas/tasks.schema.json` — schema de tasks.json (enum de status e campos)
+- `morph-spec standards --find` — passo 2
+- `.morph/framework/MORPH.md` §6 — dispatch e contrato do relatório
+- `.morph/framework/CLI.md`, seção "Suítes de teste" — recorte por task

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

@@ -4,7 +4,7 @@ description: Cuida da RAM e da CPU da máquina enquanto o morph-spec trabalha
 version: core
 when-to-invoke: quando a máquina está lenta ou sem RAM, um comando pesado esperou ou foi recusado pela fila, sobrou worktree de sub-agent, ou vários sub-agents pesados vão rodar em paralelo
 user-invokable: false
-cliVersion: "8.44.0"
+cliVersion: "8.45.0"
 ---
 
 # morph-machine
@@ -16,7 +16,7 @@ Manter a máquina do dev utilizável enquanto o trabalho paralelo do morph-spec
 ## Regras que não se negociam
 
 - **Nunca** `taskkill /IM`, `pkill`, `killall` nem `Stop-Process -Name`: derrubam os MCPs de todas as sessões abertas. O único que encerra processo é `doctor --procs --prune`, e por PID.
-- **Fila cheia não é erro de código.** `⏳ … não rodou`, `slots pesados ocupados` e exit 3 querem dizer "espere e repita o MESMO comando". Não entra no loop de correção, não conta como tentativa e não é vermelho no `verify`.
+- **Fila cheia não é erro de código.** `⏳ … não rodou`, `slots pesados ocupados` e exit 3 querem dizer que a fila já esperou o prazo dela (`heavy.waitTimeoutSec`). Não entra no loop de correção, não conta como tentativa e não é vermelho no `verify`. No máximo uma chamada nova; persistiu, siga sem aquela rodada e avise o usuário — nunca `sleep`/`until` nem retentativa agendada.
 - **Nunca remova worktree** por `git worktree remove`, `rm -rf` ou `Remove-Item -Recurse`: atravessa a junction e apaga o conteúdo real da raiz. Só `finish`, `worktree remove` ou `worktree reap`.
 - **Destrutivo pergunta antes.** `doctor --procs --prune` e `worktree reap` (sem `--dry-run`): mostre a lista e use `AskUserQuestion`.
 
@@ -25,7 +25,7 @@ Manter a máquina do dev utilizável enquanto o trabalho paralelo do morph-spec
 | Sintoma | Comando | Como ler e o que fazer |
 |---|---|---|
 | Máquina ou editor lento, pouca RAM | `morph-spec doctor --procs` (só lê) | Cada linha diz órfão ou protegido, com a razão. Sem órfão, a pressão vem de fora (vmmem do WSL, IDE): diga isso e passe a sugestão de `.wslconfig` que o relatório traz. Com órfão, mostre a lista e ofereça `--prune`. |
-| Comando voltou `⏳ … não rodou` ou exit 3 | `morph-spec heavy status` | Mostra quem segura cada vaga, há quanto tempo, e a RAM livre. A vaga solta sozinha (processo morto ou timeout). Espere e repita. Se a causa for RAM e nenhuma vaga estiver presa, rode `doctor --procs`. |
+| Comando voltou `⏳ … não rodou` ou exit 3 | `morph-spec heavy status` | Mostra quem segura cada vaga, há quanto tempo, e a RAM livre. A vaga solta sozinha (processo morto ou timeout). Vaga presa por sessão viva: diga ao usuário quem a segura. Se a causa for RAM e nenhuma vaga estiver presa, rode `doctor --procs`. |
 | Vão rodar vários sub-agents pesados em paralelo | `morph-spec heavy status` antes | São 2 vagas por padrão. O que não couber espera na fila sem falhar, mas cada espera custa turnos: despache só o que cabe. |
 | Build ou teste pesado avulso, fora do `verify` | `morph-spec heavy run -- <comando>` | Ou ligue o `heavy.gateBash` (abaixo) e o hook cuida disso. |
 | Sobrou `agent-*` em `worktrees/` ou branch `morph-task/agent-*` | `morph-spec worktree reap --dry-run`, depois `worktree reap` | Só remove o que parou, está limpo e não tem commit exclusivo; o resto volta com a razão (`dirty`, `locked`…). `doctor --worktrees` lista tudo, inclusive árvore fora do contêiner. |

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.44.0"
+cliVersion: "8.45.0"
 stacks:
   - dotnet
   - nextjs