@polymorphism-tech/morph-spec 8.37.1 → 8.40.0

package/framework/mcp/registry.json

@@ -5,6 +5,7 @@
     "context7": {
       "phases": ["proposal", "plan", "implement"],
       "tools": ["resolve-library-id", "query-docs"],
+      "serverNames": ["context7", "plugin_context7_context7"],
       "detection": "enabledPlugins includes context7 or mcpServers includes context7",
       "fallback": "WebSearch + WebFetch for library documentation",
       "usage": "Library documentation lookups, API reference, implementation patterns",
@@ -33,7 +34,8 @@
     "playwright": {
       "phases": ["uiux", "implement"],
       "tools": ["browser_navigate", "browser_snapshot", "browser_take_screenshot", "browser_console_messages", "browser_click", "browser_resize"],
-      "detection": "mcpServers includes playwright",
+      "serverNames": ["playwright", "plugin_playwright_playwright"],
+      "detection": "mcpServers includes playwright or enabledPlugins includes playwright",
       "fallback": "WebFetch for read-only page content, manual testing",
       "usage": "UI preview, smoke testing, page inspection, responsive testing, screenshot capture",
       "healthCheck": {
@@ -168,6 +170,7 @@
     "gemini-image": {
       "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",
@@ -285,9 +288,37 @@
         ],
         "setupGuide": null
       }
+    },
+    "neon": {
+      "phases": ["plan", "implement"],
+      "tools": ["list_projects", "describe_table_schema", "get_database_tables", "run_sql", "explain_sql_statement", "prepare_database_migration", "complete_database_migration", "compare_database_schema", "create_branch", "list_branches", "get_connection_string"],
+      "serverNames": ["neon", "Neon"],
+      "detection": "mcpServers includes neon (case-insensitive)",
+      "fallback": "SQL via the connection string (psql / dotnet ef) and the neonctl CLI for branches",
+      "usage": "Schema inspection, migration dry-run on a throwaway branch (prepare_database_migration → complete_database_migration), query tuning. The server exposes DESTRUCTIVE tools (delete_branch, delete_project, reset_from_parent): never call one without explicit human confirmation",
+      "healthCheck": {
+        "toolPattern": "neon",
+        "testCall": "Call list_projects with limit 1",
+        "testParams": { "limit": 1 },
+        "successIndicator": "Returns the project list (possibly empty)",
+        "failureHint": "Neon MCP not responding. Re-run the OAuth flow: claude mcp add --transport http neon https://mcp.neon.tech/mcp"
+      },
+      "install": {
+        "autoInstall": false,
+        "transport": "http",
+        "config": {
+          "type": "http",
+          "url": "https://mcp.neon.tech/mcp"
+        },
+        "credentials": [],
+        "prerequisites": [],
+        "stackRelevance": ["neon"],
+        "warnings": ["OAuth against your Neon account on first use. The server can delete branches and projects: keep destructive calls behind a human."],
+        "setupGuide": "Run: claude mcp add --transport http neon https://mcp.neon.tech/mcp"
+      }
     }
   },
-  "_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) stay out of this matrix on purpose — only universal ones are listed.",
+  "_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"],

package/framework/rubrics/backend.json

@@ -10,8 +10,8 @@
     },
     "code_quality": {
       "weight": 0.25,
-      "validators": ["architecture", "reuse"],
-      "description": "Architecture patterns, dependency direction, code structure, and reuse of what the codebase already has"
+      "validators": ["architecture", "reuse", "code-budget"],
+      "description": "Architecture patterns, dependency direction, code structure, reuse of what the codebase already has, and comment and test budget"
     },
     "design_ui": {
       "weight": 0.05,

package/framework/rubrics/default.json

@@ -10,8 +10,8 @@
     },
     "code_quality": {
       "weight": 0.25,
-      "validators": ["architecture", "reuse"],
-      "description": "Architecture patterns, code structure, and reuse of what the codebase already has"
+      "validators": ["architecture", "reuse", "code-budget"],
+      "description": "Architecture patterns, code structure, reuse of what the codebase already has, and comment and test budget"
     },
     "design_ui": {
       "weight": 0.15,

package/framework/rubrics/frontend.json

@@ -10,8 +10,8 @@
     },
     "code_quality": {
       "weight": 0.15,
-      "validators": ["architecture", "reuse"],
-      "description": "Architecture patterns, code structure, and reuse of what the codebase already has"
+      "validators": ["architecture", "reuse", "code-budget"],
+      "description": "Architecture patterns, code structure, reuse of what the codebase already has, and comment and test budget"
     },
     "design_ui": {
       "weight": 0.35,

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/infrastructure-standards.md

@@ -12,7 +12,6 @@ stacks:
 
 @.morph/framework/standards/infrastructure/docker/coolify-deploy.md
 @.morph/framework/standards/infrastructure/docker/local-compose-isolation.md
-@.morph/framework/standards/infrastructure/docker/local-compose-isolation.md
 
 ## Infrastructure Templates
 

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
 
@@ -191,16 +192,21 @@ Every task in `tasks.json` MUST reference its FR(s) in the `description` field s
 
 ## Debugging
 
-When a bug or unexpected behavior shows up mid-task, invoke `superpowers:systematic-debugging`
-with the `Skill()` tool **before proposing a fix** — root cause first, never a patch on the
-symptom. This is MANDATORY; do NOT skip it.
+When a bug or unexpected behavior shows up mid-task, find the **root cause before proposing a
+fix** — never a patch on the symptom. This is MANDATORY:
+
+1. Reproduce it and read the full error, not the first line.
+2. For a known .NET/Next.js error, run `/morph-troubleshoot <keywords>` first.
+3. One hypothesis at a time, each tested by the smallest check that could refute it.
+4. After three failed fixes, stop and question the design instead of trying a fourth.
+5. Confirm the fix with the same check that reproduced the bug; add a test only when no existing one covers that behavior.
 
 Everything else that a rule like this might list is owned by the flow itself, and duplicating it
 here would put a second, staler copy in permanent context:
 
 | Concern | Where it actually lives |
 |---------|-------------------------|
-| TDD before writing code | The feature's `mandate.md` (TDD is built in) — the resident `.claude/CLAUDE.md` says to prefer `morph-*` over the generic `superpowers:*` equivalents |
+| How many tests to write | The test budget copied into the feature's `mandate.md`: one test per postcondition, same-behavior cases in one table, no test that only pins text |
 | Verifying a task before `status: "done"` | `morph-spec verify {feature} [task]` (build + tests + validators + e2e), then the `morph-eval` skill for the 0-10 score |
 | Parallel dispatch | `morph-spec dag {feature}` decides sequential vs parallel; execution and isolation rules are in `morph-apply` §2/§3b |
 | Closing the phase / opening the PR | `morph-review` for Gate 3, then `morph-spec finish {feature} --pr\|--merge` |

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.1"
+cliVersion: "8.40.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.1"
+cliVersion: "8.40.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.1"
+cliVersion: "8.40.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,13 @@ 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.
+    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`).
     Não modifique spec.md, mandate.md.
 
     Contrato do relatório final:
@@ -192,12 +200,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 +229,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 +286,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.1"
+cliVersion: "8.40.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.1"
+cliVersion: "8.40.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.1"
+cliVersion: "8.40.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.1"
+cliVersion: "8.40.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,15 @@ 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.
+
+   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`).
+
    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 +96,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 +124,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 +144,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.1"
+cliVersion: "8.40.0"
 stacks:
   - dotnet
   - nextjs