@polymorphism-tech/morph-spec 8.37.0 → 8.38.0

package/framework/rules/csharp-standards.md

@@ -15,3 +15,4 @@ stacks:
 @.morph/framework/standards/backend/dotnet/scrutor.md
 @.morph/framework/standards/backend/dotnet/scalar-ui.md
 @.morph/framework/standards/backend/api/validation.md
+@.morph/framework/standards/architecture/code-comments.md

package/framework/rules/morph-workflow.md

@@ -156,6 +156,7 @@ Do not modify test files to make a failing test pass when the implementation is
 
 After making structural changes (new packages, dependencies, project config changes), update the project context:
 - Edit `.morph/context/README.md` — update Tech Stack, Architecture, Key Integrations sections
+- Any `.morph/context/*.md`: **rewrite the body, never stack** — the section that described the old fact now describes the new one (a value that still holds somewhere says where); a changelog keeps only date and reason
 - Update `.morph/config/config.json` — update stack, architecture, integrations, paths
 - Structural changes include: package.json, .csproj, next.config.*, tsconfig.json, docker-compose.yml
 

package/framework/rules/nextjs-standards.md

@@ -18,3 +18,4 @@ stacks:
 @.morph/framework/standards/frontend/nextjs/testing.md
 @.morph/framework/standards/frontend/nextjs/nextjs-patterns.md
 @.morph/framework/standards/frontend/nextjs/motion-patterns.md
+@.morph/framework/standards/architecture/code-comments.md

package/framework/schemas/config.schema.json

@@ -1,7 +1,7 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
   "title": "MORPH-SPEC .morph/config/config.json",
-  "description": "Describes ONLY project.tests[] — the plural declaration of the project's test suites. Everything else in config.json is deliberately left open (additionalProperties: true) so that configs already in the field never break on a key this schema has not heard of. The authority at runtime is validateTestNodes() in src/lib/tasks/test-nodes.js: a schema nothing calls is decoration.",
+  "description": "Describes project.tests[] — the plural declaration of the project's test suites — and finishBackup.retention. Everything else in config.json is deliberately left open (additionalProperties: true) so that configs already in the field never break on a key this schema has not heard of. The authorities at runtime are validateTestNodes() in src/lib/tasks/test-nodes.js and resolveBackupRetention() in src/lib/worktree/finish-backup.js: a schema nothing calls is decoration.",
   "type": "object",
   "additionalProperties": true,
   "properties": {
@@ -109,6 +109,46 @@
           }
         }
       }
+    },
+    "finishBackup": {
+      "type": "object",
+      "additionalProperties": true,
+      "description": "The backups `finish` and `worktree remove` write to .git/morph-spec/finish-backup/ before deleting a file that exists nowhere else.",
+      "properties": {
+        "retention": {
+          "description": "How long a backup lives. ON by default: a config without this key gets the defaults below - the maxCount newest backups of each namespace always stay, at any age (no age cut unless maxAgeDays is set), and .env* files inside a backup go after secretMaxAgeDays. One finish is one backup, even when it writes two folders (same stamp). Applied after every finish and every `worktree remove` that wrote a backup, and on demand by `morph-spec doctor --worktrees --prune`. A backup without its {folder}.manifest.json was written before this retention: the automatic prune never deletes it, never strips it and gives it no place in the count (it reports legacyPending); only the explicit `doctor --worktrees --prune` prunes it, counting it with the rest, and writes a manifest into every one it keeps. Only `false` turns retention off. Anything else it cannot read - an unknown key, a value that is not an integer >= 1, a retention that is neither `false` nor this object, a finishBackup that is not an object, a config.json that does not parse - SKIPS the prune for that run, with the reason in the output: never the defaults, because the operation deletes. The backup the running command just wrote is never pruned by it, and a backup stamped in the future is kept without taking a place in the count.",
+          "oneOf": [
+            {
+              "const": false,
+              "description": "Retention off: no backup and no .env* inside one is ever deleted."
+            },
+            {
+              "type": "object",
+              "additionalProperties": false,
+              "properties": {
+                "maxCount": {
+                  "type": "integer",
+                  "minimum": 1,
+                  "default": 20,
+                  "description": "Backups kept per namespace (the top level, and task/ for task isolation trees), newest first."
+                },
+                "maxAgeDays": {
+                  "type": ["integer", "null"],
+                  "minimum": 1,
+                  "default": null,
+                  "description": "Optional age cut: when set, no backup older than this survives, whatever the count. Absent or null (the default) means no age cut - a quiet period never empties the backups of the last features closed."
+                },
+                "secretMaxAgeDays": {
+                  "type": "integer",
+                  "minimum": 1,
+                  "default": 7,
+                  "description": "Files named .env* are deleted from a backup older than this; the rest of it stays, and its manifest keeps the names."
+                }
+              }
+            }
+          ]
+        }
+      }
     }
   }
 }

package/framework/schemas/feature.schema.json

@@ -60,7 +60,11 @@
             "description": "Risk signals evaluated (free-form): taskCount, evalScore, standardsViolations, designSystemDivergence..."
           },
           "trust": { "type": "string", "enum": ["auto", "manual"] },
-          "decidedAt": { "type": "string", "format": "date-time" }
+          "decidedAt": { "type": "string", "format": "date-time" },
+          "mockupsHash": {
+            "type": ["string", "null"],
+            "description": "uiux only: hash of the 1-design/mockups.md the decision saw (null = no mockup). A pause:false unlocks the auto signature only while the mockup is still this one."
+          }
         },
         "additionalProperties": false
       }

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.37.0"
+cliVersion: "8.38.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.37.0"
+cliVersion: "8.38.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.37.0"
+cliVersion: "8.38.0"
 ---
 
 # morph-apply
@@ -159,8 +159,9 @@ while (true):
 ```
 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) e os paths
-            dos alvos de reuso
+            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>
   instrução: |
     Leia o(s) standard(s) indicado(s) antes de escrever código.
@@ -172,6 +173,9 @@ 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.
     Não modifique spec.md, mandate.md.
 
     Contrato do relatório final:
@@ -192,12 +196,23 @@ dispatch Agent (subagent_type: "morph-{id}") with prompt:
          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
+         (`… > .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: commite `wip({taskId})` ao fim de cada task. Se você parar no
-       limite de turnos, é o commit que preserva o trabalho — sem ele, a retomada
-       recomeça do zero.
+    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
+       (`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.
     6. PROCESSOS: NUNCA `taskkill /IM node.exe` (derruba os MCPs de todas as
        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 é
@@ -210,16 +225,25 @@ dispatch Agent (subagent_type: "morph-{id}") with prompt:
 ```
 
 > **Passo pós-dispatch (do orquestrador, antes de avaliar qualquer relatório):** ao retomar o
-> controle, rode `git status --porcelain src/` e `grep -rn "MUTACAO" src/`. 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 é falha de protocolo: registre no
-> recap antes de pontuar.
+> controle, a auditoria do batch abaixo (`report-check` com os ids do batch) traz, no bloco `tree`,
+> o que está não commitado fora de `.morph/` (`dirty`, `diffstat`), os commits sobre a default
+> (`commits`) e os marcadores `MUTACAO` esquecidos (`markers`) — sem `git status`, `git diff` e
+> `grep` à parte. 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.
+
+> **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.
 
 > 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.
 
 > **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} --json` — 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:
+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)`.
@@ -258,6 +282,7 @@ re-apresente o gate**: siga direto para o encerramento (§6) conforme a decisão
 ### 6. Pós Gate 3 — encerramento
 
 - Aprovar o Gate 3: em auto, `morph-spec approve {feature} review --mode auto`; em manual, o hook state-sync registra a resposta "aprovado" em `AskUserQuestion` — **desde que a pergunta nomeie a feature** (senão aprove via `morph-spec approve`).
+- **Antes do `finish`, reescreva o contexto que a feature mudou.** Todo `.morph/context/*.md` que descreve um fato que esta feature alterou (fonte, token, fluxo, integração) tem o **corpo** reescrito — a seção que descrevia o antigo passa a descrever o novo, e o que ainda vale num escopo diz o escopo. O changelog do documento guarda só data e motivo, nunca o valor novo: um agente que lê só o corpo precisa receber a resposta de hoje. Commite na branch da feature — o `finish` exige a árvore limpa. UCs e ADRs não entram aqui: o `finish` aplica ao acervo o que o `spec.md` declarou revogar (`morph-plan` §3) e reporta em `supersededUseCases`/`adrIndex`/`revocationProblems`.
 - **Fechar a feature** com `morph-spec finish {feature} --pr|--merge`, modo escolhido via `AskUserQuestion` (header `"Integração"`): `--pr` (push + PR, review antes do merge) vs `--merge` (integra local, single-user direto). Não integre automaticamente sem essa escolha. Mecânica completa (o que cada modo faz, feature legada sem `morph/{f}`): `MORPH.md` §2.1/§2.2.
 - **`--pr` não encerra a feature; quem encerra é o merge.** O comando arquiva e termina (`finished: true`) nos dois modos, mas só `--merge` integra na hora (`integrated: true`); `--pr` sai com `integrated: false`, `awaiting: "merge"` e `pr: {number, url}` — o archive viaja no diff do PR e só chega na branch default quando alguém mergeia. Até lá a feature aparece em `morph-spec list`/`fleet` como `aguardando-merge`, sem cópia local. Nunca registre a feature como entregue só porque `finish --pr` retornou `finished: true`.
 

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.37.0"
+cliVersion: "8.38.0"
 ---
 
 # morph-brainstorming
@@ -21,7 +21,7 @@ O harness conhece o stack por padrão (backend .NET 10 + VSA + EF Core/Neon, IA
 
 ## Modo bug-lean (`workType: bug`)
 
-Quando a feature tem `workType: bug` (roteada pela `morph-proposal` — ver MORPH.md §2.1 "Roteamento por tipo de trabalho"), o brainstorming é enxuto. A varredura (Parte 0) continua rodando normalmente — o diagnóstico precisa do contexto técnico —, mas a árvore da Parte 1 é de **repro, diagnóstico e comportamento do sistema**, não de negócio; em modo automático (Parte 3) isso significa no máximo 1 pergunta de repro, e só se o pedido original não deixar claro. O `proposal.md` (Parte 4) foca em **Repro / Diagnóstico / Root cause provável / Escopo do fix**, sem as seções de negócio completas.
+Quando a feature tem `workType: bug` (roteada pela `morph-proposal` — ver MORPH.md §2.1 "Roteamento por tipo de trabalho"), o brainstorming é enxuto. A varredura (Parte 0) continua rodando normalmente — o diagnóstico precisa do contexto técnico —, mas a árvore da Parte 1 é de **repro, diagnóstico e comportamento do sistema**, não de negócio; em modo automático (Parte 3) isso significa no máximo 1 pergunta de repro, e só se o pedido original não deixar claro. O `proposal.md` (Parte 4) foca em **Repro / Diagnóstico / Root cause provável / Escopo do fix / Conflitos com o acervo**, sem as seções de negócio completas.
 
 Para `workType: feature` (ou features sem `workType` — compat, ver MORPH.md §2.1), o fluxo completo abaixo permanece integral.
 
@@ -36,11 +36,18 @@ Fato não se pergunta. Antes de levar a primeira pergunta ao usuário, levante o
    - Em brownfield, varre stack atual (.csproj, package.json, migrations), padrões (Guid.NewGuid vs Guid.CreateVersion7, sealed, result pattern), features existentes.
    - Produz `.morph/features/{feature}/0-proposal/stack-scan.md`.
 
-2. Leia o contexto que já existe no projeto: `.morph/context/` (se existir), `.morph/config/config.json` (stack, integrations, trust), as features ativas em `.morph/features/` e o **acervo de use cases** em `.morph/specs/usecases/`. O comportamento já implementado é o contexto mais barato que existe — e é ele que evita perguntar o que o sistema já responde.
+2. Leia o contexto que já existe no projeto: `.morph/context/` (se existir), `.morph/config/config.json` (stack, integrations, trust), as features ativas em `.morph/features/`, o **acervo de use cases** em `.morph/specs/usecases/` e o **índice de ADRs ativos** em `.morph/specs/adrs/` (um arquivo por ADR, se existir). O comportamento já implementado é o contexto mais barato que existe — e é ele que evita perguntar o que o sistema já responde.
 
-3. Reconciliação de design-system (se aplicável): comparar `.morph/context/design-system.md` (se existir) com o que foi detectado no stack-scan e com bundles/mocks recentes do usuário. Se houver **divergência** (tokens diferentes, framework version mismatch, fonte aprovada distinta), marque `signals.designSystemDivergence = true` — a escolha da fonte vira uma **decisão da árvore** (Parte 1), não uma pergunta solta. Resolvida, atualize `.morph/context/design-system.md` com a fonte escolhida + entrada de changelog (data, motivo).
+   O acervo tem ciclo de vida: UC com `status: superseded` **não é o comportamento vigente** — o vigente é o `superseded_by`, e `scope` (quando existe) diz onde o antigo ainda vale. Decisão vigente é a do índice; os `decisions.md` de `.morph/archive/` são **história, não instrução** — abra um só para entender por que algo é como é, nunca para decidir.
 
-4. Desvio de stack detectado (`stack-scan.md`, seção Desvios): "a migração entra nesta feature ou vira feature separada?" — pergunta feita pelo `morph-stack-scan` ao fim da varredura — também é decisão da árvore; a resposta vai para a seção "Compliance de stack" do `proposal.md` (Parte 4).
+3. **Conflitos com o acervo — avise, não entreviste.** Para cada UC vigente, ADR do índice ou documento de `.morph/context/` que o pedido novo **contradiz**:
+   - **Avise o usuário** — uma linha por conflito no resumo que abre a Parte 2 (fonte, o que ela diz, o que o pedido muda). Aviso, não pergunta.
+   - **Pedido explícito sobre o ponto → vale o mais novo.** Registre a escolha na coluna **Decisão** da seção de conflitos (o que muda, o que o antigo ainda cobre) e siga. Só entra na árvore (Parte 1) o conflito que o pedido deixa **ambíguo** — "o admin passa a Geist" não diz nada sobre a vitrine, então a vitrine é decisão; o admin não é.
+   - Todo conflito vai para a seção **Conflitos com o acervo** do `proposal.md` (Parte 4). A `2-plan/` só abre depois do Gate 1, então é a `morph-plan` que transforma cada decisão pelo novo em ADR no `decisions.md` e em linha de revogação no `spec.md` (§3) — é essa linha que o `finish` aplica ao acervo.
+
+4. Reconciliação de design-system (se aplicável): comparar `.morph/context/design-system.md` (se existir) com o que foi detectado no stack-scan e com bundles/mocks recentes do usuário. Se houver **divergência** (tokens diferentes, framework version mismatch, fonte aprovada distinta), marque `signals.designSystemDivergence = true` — a escolha da fonte vira uma **decisão da árvore** (Parte 1), não uma pergunta solta. Resolvida, **reescreva o corpo** de `.morph/context/design-system.md` com a fonte escolhida — a seção que descrevia a antiga passa a descrever a nova, e o valor que ainda vale num escopo diz o escopo. O changelog guarda **só data e motivo**, nunca o valor novo: quem lê só o corpo precisa receber a resposta de hoje.
+
+5. Desvio de stack detectado (`stack-scan.md`, seção Desvios): "a migração entra nesta feature ou vira feature separada?" — pergunta feita pelo `morph-stack-scan` ao fim da varredura — também é decisão da árvore; a resposta vai para a seção "Compliance de stack" do `proposal.md` (Parte 4).
 
 ### Parte 1 — Árvore de decisões abertas
 
@@ -93,10 +100,11 @@ options:
    - **Stack:** confirme o stack padrão ou documente desvios aprovados
    - **Riscos e dependências:** o que pode dar errado, o que esta feature depende
    - **Compliance de stack:** "Em compliance" ou lista de desvios detectados e plano de resolução
+   - **Conflitos com o acervo:** os conflitos da Parte 0 (passo 3), numa tabela `Fonte | O que diz hoje | O que o pedido muda | Decisão` — ou `Nenhum conflito encontrado.`. A seção existe sempre, também no bug-lean: ausente, ela diz que a checagem não rodou (o `validate-feature` avisa)
 
    **Não escreva critérios de aceite aqui.** O comportamento verificável mora nos **use cases**, destilados pela `morph-plan` na fase seguinte (`2-plan/usecases/UC-{nn}-{slug}.md`), onde cada pós-condição precisa ser observável em teste e chega literal ao `doneCriteria` das tasks. O `proposal.md` responde **o quê e por quê**; os use cases respondem **como o sistema se comporta**. Duplicar aqui produz duas fontes que divergem no primeiro ajuste.
 
-   **Se `workType: bug`** (modo bug-lean, ver nota no início da skill), substitua a lista acima pela estrutura enxuta: **Repro** (passos para reproduzir), **Diagnóstico** (o que foi observado/investigado), **Root cause provável** e **Escopo do fix** (o que muda, o que fica de fora) — sem as seções de negócio completas do fluxo `feature`. A condição verificável de que o bug foi corrigido vira a **pós-condição** que faltava no use case do acervo (`.morph/specs/usecases/`), corrigida ou acrescentada na fase plan.
+   **Se `workType: bug`** (modo bug-lean, ver nota no início da skill), substitua a lista acima pela estrutura enxuta: **Repro** (passos para reproduzir), **Diagnóstico** (o que foi observado/investigado), **Root cause provável**, **Escopo do fix** (o que muda, o que fica de fora) e **Conflitos com o acervo** — sem as seções de negócio completas do fluxo `feature`. A condição verificável de que o bug foi corrigido vira a **pós-condição** que faltava no use case do acervo (`.morph/specs/usecases/`), corrigida ou acrescentada na fase plan.
 
    Um bom proposal.md tem no máximo 2 páginas. Se está crescendo além disso, o escopo precisa ser cortado.
 
@@ -142,7 +150,7 @@ options:
    No caminho manual, o hook state-sync.js detecta a aprovação automaticamente (grava o gate no `feature.json` autoritativo, `approvedBy: "manual"`) — **atribuindo pela feature nomeada na pergunta**; sem o nome, e com mais de uma feature na árvore, ele recusa a gravar e avisa (aprove então por `morph-spec approve {feature} proposal`). Em modo auto sem AskUserQuestion, aprove via `morph-spec approve {feature} proposal --mode auto` (ou `morph-spec advance {feature}` para já criar a pasta 2-plan/) — nunca via Edit à mão de state.json.
 
 ## Output esperado
-- `.morph/features/{feature}/0-proposal/proposal.md` — proposta aprovada, com desvios de stack (se houver) resolvidos na seção "Compliance de stack"
+- `.morph/features/{feature}/0-proposal/proposal.md` — proposta aprovada, com desvios de stack (se houver) resolvidos na seção "Compliance de stack" e os conflitos com o acervo listados em "Conflitos com o acervo"
 - Gate 1 apresentado e aprovado
 
 ## Referências
@@ -150,3 +158,4 @@ options:
 - `morph-spec standards --find "<query>"` — para referência de standards relevantes à stack (ver `morph-standards`)
 - `.claude/skills/morph-stack-scan/SKILL.md` — invocada na Parte 0 (varredura), antes de qualquer pergunta
 - `.morph/framework/MORPH.md` §5 — regras de pausa do Gate 1 (trust mode)
+- `.morph/specs/usecases/` e `.morph/specs/adrs/` — o acervo vigente (UC `superseded` e `decisions.md` arquivado não são instrução); lidos na Parte 0

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.37.0"
+cliVersion: "8.38.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.37.0"
+cliVersion: "8.38.0"
 ---
 
 # morph-hotfix

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.37.0"
+cliVersion: "8.38.0"
 ---
 
 # morph-implement
@@ -62,7 +62,8 @@ Ao iniciar cada task de `tasks.json` — antes de escrever qualquer código. Nor
    Standard: [path do .md do standard identificado no passo 2]
    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]
+     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]
    Done quando: [doneCriteria do tasks.json]
@@ -73,6 +74,10 @@ 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.
+
    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 é
@@ -86,12 +91,23 @@ Ao iniciar cada task de `tasks.json` — antes de escrever qualquer código. Nor
       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.
 
    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: commite `wip({taskId})` ao fim de cada task. Se você parar no
-      limite de turnos, é o commit que preserva o trabalho — sem ele, a retomada
-      recomeça do zero.
+   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
+      (`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.
    6. PROCESSOS: NUNCA `taskkill /IM node.exe` (derruba os MCPs de todas as
       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 é
@@ -103,11 +119,15 @@ Ao iniciar cada task de `tasks.json` — antes de escrever qualquer código. Nor
    justificativa em uma linha. Relatório ausente, oco, ou sem os 4 itens, é
    falha de protocolo.
    ```
-   **Passo pós-dispatch (seu, antes de avaliar o relatório):** rode `git status --porcelain src/`
-   e `grep -rn "MUTACAO" src/` ao retomar o controle. 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 é falha de protocolo: registre no recap antes de
-   pontuar.
+   **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.
 
    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,
@@ -119,11 +139,20 @@ Ao iniciar cada task de `tasks.json` — antes de escrever qualquer código. Nor
    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 o mesmo loop da cláusula 3 do template
+   do passo 4 (compilar uma vez, `--filter`, saída em arquivo).
 
    **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"`

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