@polymorphism-tech/morph-spec 8.47.0 → 9.1.0

package/framework/schemas/feature.schema.json

@@ -38,17 +38,16 @@
       "type": "object",
       "description": "One entry per gate. Written ONLY by `morph-spec approve`/`advance` (approvedBy: \"auto\") or the state-sync hook on a human \"aprovado\" answer (approvedBy: \"manual\").",
       "properties": {
-        "proposal": { "$ref": "#/definitions/gate" },
-        "uiux": { "$ref": "#/definitions/gate" },
         "plan": { "$ref": "#/definitions/gate" },
+        "uiux": { "$ref": "#/definitions/gate" },
         "review": { "$ref": "#/definitions/gate" }
       },
       "additionalProperties": false
     },
     "gateDecisions": {
       "type": "object",
-      "description": "Trust decision persisted BEFORE acting on a gate, written ONLY by `morph-spec gate-decision` (decidedAt is server-side). Read by the gate-guard hook to verify the observed action matched the recorded decision.",
-      "propertyNames": { "enum": ["proposal", "uiux", "plan", "review"] },
+      "description": "Trust decision persisted BEFORE acting on a gate, written ONLY by `morph-spec gate-decision` and `morph-spec gate-check` (decidedAt is server-side). Read by the gate-guard hook to verify the observed action matched the recorded decision.",
+      "propertyNames": { "enum": ["plan", "uiux", "review"] },
       "additionalProperties": {
         "type": "object",
         "required": ["pause", "reason", "signals", "trust", "decidedAt"],
@@ -57,48 +56,26 @@
           "reason": { "type": "string", "description": "The signal that drove the decision (or 'nenhum sinal de risco')." },
           "signals": {
             "type": "object",
-            "description": "Risk signals evaluated (free-form): taskCount, evaluatorVerdict, standardsViolations, designSystemDivergence..."
+            "description": "Risk signals evaluated (free-form): sliceCount, planChecks, reviewReports, standardsViolations, designSystemDivergence..."
           },
           "trust": { "type": "string", "enum": ["auto", "manual"] },
           "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
-      }
-    },
-    "taskVerifications": {
-      "type": "object",
-      "description": "Deterministic verify results per task, written ONLY by `morph-spec verify` (task scope). updatedAt is server-side; attempts auto-increment. Persisted only from the primary root or the feature's own registered worktree — see verify.js decidePersistence().",
-      "propertyNames": { "pattern": "^T\\d+$" },
-      "additionalProperties": {
-        "type": "object",
-        "required": ["status", "nodes", "attempts", "updatedAt"],
-        "properties": {
-          "status": { "type": "string", "enum": ["pass", "fail"] },
-          "nodes": {
-            "type": "object",
-            "required": ["build", "tests", "validators"],
-            "properties": {
-              "build": { "type": "string", "enum": ["pass", "fail", "skip"] },
-              "tests": { "type": "string", "enum": ["pass", "fail", "skip"] },
-              "validators": { "type": "string", "enum": ["pass", "fail", "skip"] },
-              "e2e": { "type": "string", "enum": ["pass", "fail", "skip"], "description": "Docker bring-up + Playwright specs against the running stack. Absent on entries written before the node existed — which is why it is NOT in `required`." },
-              "evals": { "type": ["string", "null"], "enum": ["pass", "fail", "skip", null], "description": "Eval suites, pulled out of the tests rollup. Written by the SAME function that writes the singular stamp (nodeStatuses in verify.js): the two shapes must stay identical, or a stamp would omit what the history records. null means the project declares no eval node at all — distinct from skip, which means it declares one and this run did not execute it. Absent on entries written before the field existed, which is why it is NOT in required." }
-            },
-            "additionalProperties": false
           },
-          "attempts": { "type": "integer", "minimum": 1 },
-          "updatedAt": { "type": "string", "format": "date-time" }
+          "source": {
+            "type": "string",
+            "enum": ["manual", "gate-check"],
+            "description": "Which command decided: `gate-decision` writes manual, `gate-check` writes gate-check. A manual pause:true is sticky: `gate-check` keeps it paused (manual reason, fresh signals); only a new `gate-decision --pause false` clears it."
+          }
         },
         "additionalProperties": false
       }
     },
     "verifications": {
       "type": "object",
-      "description": "Deterministic verify results at feature scope, written ONLY by `morph-spec verify` (feature scope, no task id).",
+      "description": "Deterministic verify results at feature scope, written ONLY by `morph-spec verify`.",
       "properties": {
         "feature": {
           "type": "object",
@@ -127,8 +104,8 @@
     },
     "verification": {
       "type": "object",
-      "description": "The single latest deterministic verify stamp (any scope), written ONLY by `morph-spec verify`. Distinct from `verifications`/`taskVerifications` above (per-scope history with attempts/nodes): this is overwritten by every verify call regardless of scope, carrying just enough to correlate a pass/fail with the exact commit it covers. Primary consumer: `morph-spec gate-check`, which feeds `status` to shouldPauseGate as `verificationStatus` — a red verify pauses the gate (risk-detector.js) — and `nodes.e2e`/`e2eReason` as `e2eStatus`/`e2eReason`, the pair that decides whether an e2e SKIP is a recorded dispensation or an absence of proof (a skip never reddens `status`, so the rollup alone is blind to it). `scope` is the third pause input: a dispensation only counts from a feature-scoped stamp (see the field below). The rest (sha/ts, and the derived `verificationStale`) is audit context.",
-      "required": ["status", "sha", "ts", "scope"],
+      "description": "The single latest deterministic verify stamp, written ONLY by `morph-spec verify`. Distinct from `verifications` above (history with attempts/nodes): this is overwritten by every persisted verify, carrying just enough to correlate a pass/fail with the exact commit it covers. Primary consumer: `morph-spec gate-check`, which feeds `status` to shouldPauseGate as `verificationStatus` — a red verify pauses the gate (risk-detector.js) — and `nodes.e2e`/`e2eReason` as `e2eStatus`/`e2eReason`, the pair that decides whether an e2e SKIP is a recorded dispensation or an absence of proof (a skip never reddens `status`, so the rollup alone is blind to it). The rest (sha/ts, and the derived `verificationStale`) is audit context.",
+      "required": ["status", "sha", "ts"],
       "properties": {
         "status": { "type": "string", "enum": ["pass", "fail"] },
         "nodes": {
@@ -142,31 +119,19 @@
             "evals": {
               "type": ["string", "null"],
               "enum": ["pass", "fail", "skip", null],
-              "description": "Status of the `runner: \"evals\"` entries of nodes.tests.runs[], pulled out of the rollup. The rollup cannot answer what Gate 3 asks: a red eval and a red unit test both read as tests:fail, and an eval SKIPPED at task scope leaves the rollup green. null means this project declares NO eval node - distinct from 'skip', which means it declares one and this run did not execute it; risk-detector.js pauses on the two for different reasons because they call for different actions. Absent on stamps written before this field existed."
+              "description": "Status of the `runner: \"evals\"` entries of nodes.tests.runs[], pulled out of the rollup. The rollup cannot answer what Gate 3 asks: a red eval and a red unit test both read as tests:fail. null means this project declares NO eval node - distinct from 'skip', which means it declares one and this run did not execute it; risk-detector.js pauses on the two for different reasons because they call for different actions. Absent on stamps written before this field existed."
             }
           },
           "additionalProperties": false
         },
         "e2eReason": { "type": ["string", "null"], "description": "The LITERAL reason the e2e node skipped (e2e-check.js's own wording), or null when it did not skip. risk-detector.js's classifyE2eSkip() reads it: 'project does not containerize' / 'does not touch runtime' are legitimate dispensations and pass; 'docker is not available' / 'requested' (--skip-e2e) / anything unclassifiable — null included — are an absence of proof and pause Gate 3. A skip recorded WITHOUT a reason is refused on purpose: a nameless dispensation is a silent no-op." },
         "sha": { "type": ["string", "null"], "description": "HEAD commit SHA at verify time (git rev-parse HEAD); null when not in a git repo or no commits yet." },
-        "ts": { "type": "string", "format": "date-time", "description": "Server-side timestamp, same instant as the corresponding verifications/taskVerifications entry's updatedAt." },
-        "scope": { "type": "string", "description": "'feature', or 'task:<id>' for a task-scoped verify. READ BY THE GATE, not just audit: this stamp is singular and any verify overwrites it, so a 'task:<id>' value at ship time means the last verify was NOT the feature's. risk-detector.js therefore accepts an e2e dispensation ('project'/'scope' in e2eReason) only from scope === 'feature' — a `morph-spec verify {f} {task}` of a task whose group does not touch runtime stamps exactly the legitimate-sounding reason that would otherwise buy Gate 3 for the whole feature (the last task of a feature is typically group: docs). Absent/unknown falls on the safe side, like an unclassifiable reason." },
+        "ts": { "type": "string", "format": "date-time", "description": "Server-side timestamp, same instant as the corresponding verifications entry's updatedAt." },
         "source": { "type": "string", "enum": ["ci"], "description": "Present only when the stamp came from `verify --ci`: the verify --json the project CI uploaded for the pushed commit, judged by the same rules as a local run. Absent = local run." },
         "ciRun": { "type": "string", "description": "URL of the CI run whose artifact wrote this stamp (with source: ci). `sha` is that run's headSha, so verificationStale compares the code CI saw with HEAD." }
       },
       "additionalProperties": false
     },
-    "tasks": {
-      "type": "object",
-      "description": "Aggregate task counters (informational — the source of truth is 2-plan/tasks.json).",
-      "properties": {
-        "total": { "type": "integer", "minimum": 0 },
-        "completed": { "type": "integer", "minimum": 0 },
-        "inProgress": { "type": "integer", "minimum": 0 },
-        "pending": { "type": "integer", "minimum": 0 }
-      },
-      "additionalProperties": true
-    },
     "outputs": {
       "type": "object",
       "description": "Outputs tracked by the state-sync hook: filename → { created, path }.",
@@ -234,7 +199,7 @@
         "approved": { "type": "boolean" },
         "timestamp": { "type": ["string", "null"], "description": "ISO timestamp of the approval/revocation, null while never evaluated." },
         "approvedBy": { "type": ["string", "null"], "description": "\"auto\" (approve/advance --mode auto), \"manual\" (human in the loop), \"policy:{workType}\" (gate stamped at birth by `morph-spec create` per the work type's skippedGates — see src/core/work-types.js; the gate-guard hook only special-cases \"auto\", so policy-stamped gates stay silent to it), a --approver name, or null while never evaluated." },
-        "selfAssessed": { "type": "boolean", "description": "Gate `review` SOMENTE. `true` quando o Gate 3 foi aprovado sem `4-review/evaluator-report.md`, via `morph-spec approve <f> review --self-assessed`. O veredito deveria vir do avaliador independente; esta flag registra a degradação em vez de deixá-la silenciosa, e aparece no `morph-spec list`." }
+        "selfAssessed": { "type": "boolean", "description": "Gate `review` SOMENTE. `true` quando o Gate 3 foi aprovado sem os relatórios de review exigidos (`4-review/verifier.md`, `reviewer.md`, `security.md`), via `morph-spec approve <f> review --self-assessed` ou um \"aprovado\" humano sem eles. O veredito deveria vir dos agentes independentes; esta flag registra a degradação em vez de deixá-la silenciosa, e aparece no `morph-spec list`." }
       },
       "additionalProperties": true
     }

package/framework/skills/README.md

@@ -12,10 +12,9 @@ These are the only skills the harness needs. MORPH.md references them by path.
 
 | Skill                | Purpose                                                              | User-invocable |
 |----------------------|----------------------------------------------------------------------|----------------|
-| `morph-brainstorming` | Business understanding + brownfield scan → proposal.md (Gate 1)     | yes            |
-| `morph-stack-scan`    | Detect stack drift in existing projects, report in stack-scan.md     | yes            |
-| `morph-plan`          | Produce use cases + spec.md + tasks.json (Gate 2)                   | yes            |
-| `morph-implement`     | Execute each task with standard + persona, auto-advance between tasks| no             |
+| `morph-plan`          | Route, scan, interview, write plan.md, plan-check and the plan gate  | yes            |
+| `morph-uiux`          | Optional design branch after the plan gate (mockups + screen checklist) | yes          |
+| `morph-apply`         | Run the plan slices (dispatch, report-check, verify) into the review | yes            |
 | `morph-review`        | Final review report with SHIP/FIX verdict (Gate 3)                   | yes            |
 | `morph-standards`     | Locate and load a specific standard on demand                        | no             |
 

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_use: Use quando for iniciar um novo projeto de LP com o template Umbraco genérico
 user-invocable: true
-cliVersion: "8.47.0"
+cliVersion: "9.1.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_use: Use quando o usuário pedir "use /migrate-lp-to-umbraco {projeto}" ou descrever a necessidade de migrar uma LP para Umbraco
 user-invocable: true
-cliVersion: "8.47.0"
+cliVersion: "9.1.0"
 stacks:
   - umbraco
 ---

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

@@ -1,260 +1,187 @@
 ---
 name: morph-apply
-description: Orquestra a execução autônoma de tasks de uma feature morph-spec. Analisa DAG de dependências em tasks.json e decide adaptativamente entre execução sequencial (auto-advance) ou paralela (Agent dispatch). Termina com morph-review e Gate 3.
+description: Executa as fatias do plano de uma feature morph-spec — dispatch por persona, em ondas paralelas do plan-check, com relatório por fatia — prova a feature com um verify sem filtro e entrega à morph-review (Gate 3).
 version: core
-when_to_use: Use quando chegar a instrução "use /morph-apply" ou "implementar feature" com o Gate 2 aprovado
+when_to_use: Use com o gate do plano aprovado, em "use /morph-apply {feature}" ou "implementar feature"
 user-invocable: true
-cliVersion: "8.47.0"
+cliVersion: "9.1.0"
 ---
 
 # morph-apply
 
 ## Objetivo
 
-Levar toda task pendente a `done` — `verify` da task verde e `doneCriteria` atendido — e fechar
-com `morph-review` + Gate 3.
-
-## Quando invocar
-
-Gate 2 aprovado (`feature.json → approvalGates.plan.approved`), ou o usuário pede "use /morph-apply
-{feature}". Sem argumento: a feature `in_progress` mais recente.
+Toda fatia de `2-plan/checks.json` com relatório final em `3-implement/reports/F{n}.md`, o
+`verify` da feature verde, e a entrega à `morph-review`. O progresso **é** o conjunto de
+relatórios (ausente = pendente, `PARCIAL` na 1ª linha = parcial, senão feito): não há arquivo de
+status para editar.
 
 ## Ritmo
 
 Comando em primeiro plano; o `verify {feature}` que passa do teto de 10 min do Bash vai com
-`run_in_background` e espera a notificação de término. `verify` com exit 3 (`status: "busy"`) já esperou a fila pesada
+`run_in_background` e espera a notificação de término **no mesmo turno**: nunca encerre o turno
+com o verify da feature rodando — o stamp que o Gate 3 lê é o dele. `verify` com exit 3 (`status: "busy"`) já esperou a fila pesada
 pelo timeout dela: no máximo uma chamada nova; persistiu, pare e avise o usuário — a máquina está
 saturada (skill `morph-machine`). Nunca `sleep`/`until` nem retentativa agendada.
 
-## Fluxo
+## 1. Contexto, uma vez
 
-### 1. Carregar contexto
+Read em `2-plan/plan.md` e `2-plan/checks.json` uma vez por sessão (ou depois de um `/compact`):
+o plano está congelado desde o gate, então não releia por padrão — só o trecho que falta.
+Antes do primeiro dispatch: `.morph/config/config.json` sem `project.stack` ou `project.tests` →
+declare-os a partir dos comandos de baseline do `## Contrato de implementação` e commite junto com o
+`.gitignore` que o `plan-check` semeou (`bin/`/`obj/` num projeto .NET) — antes de qualquer código. Não há comando de
+CLI para isso: uma edição no `config.json` na forma de `.morph/framework/schemas/config.schema.json`
+(`project.tests[]` com `id` e `command`; `project.stack` com as tags unidas por `+`, ex. `dotnet+nextjs`;
+mais de uma solução .NET no repositório → `project.backendPath` com a pasta da que o build compila), conferida
+por `morph-spec doctor --full`.
+`morph-spec plan-check {feature}` imprime as **ondas**: fatias de uma onda não dependem uma da
+outra nem tocam o mesmo arquivo, até 4 por onda.
 
-`.morph/config/config.json → trust` e Read em `2-plan/tasks.json` (ids, `dependencies`, `effort`,
-`group`, `status`, `doneCriteria`).
+## 2. Fatiar
 
-### 2. Análise de DAG — sequencial vs paralelo
+- Uma onda por vez, até **4 agentes ao mesmo tempo**, um por fatia, `subagent_type: "morph-{id}"` (o `persona:` da fatia).
+- Duas fatias em voo que escrevem o mesmo arquivo: a segunda vai em worktree (§4), rolling.
+- Fatias em paralelo na mesma árvore commitam pela lista explícita de arquivos (`git add <paths>`), nunca um diretório: `git add api` leva o arquivo que a fatia vizinha acabou de escrever.
+- **Inline** só para fatia pequena no domínio já carregado, com **uma linha de porquê** no relatório.
+  Antes de codar, leia os standards que a fatia fixa. Inline também grava `3-implement/reports/F{n}.md`,
+  no formato abaixo — é ele que conta o progresso.
 
-```
-morph-spec dag {feature}
-```
+O hook `validate-completion` (no Stop) e o `report-check` cobram o relatório pela mesma régua
+(`inspectReport`); conhecer o formato antes evita reescrever o relatório depois de dar a fatia por feita:
 
-Ele lê `dependencies`, `group` e `effort` (S=1, M=2, L=4, XL=8) e imprime a decisão:
-- ≤ 3 tasks → **sequencial**.
-- ≥ 2 fluxos de domínio independentes com peso (backend ‖ frontend) → **um sub-agent por fluxo, em
-  paralelo** (§3b); cadeia longa vai inteira ao agente do fluxo.
-- ≥ 3 raízes independentes de effort ≥ M → raízes em **paralelo**, o resto sequencial.
-- Senão, sequencial com auto-advance. Raiz S roda `inline`.
+```markdown
+# F{n} — {título}
 
-`isolation.recommended: "worktree"` (dois fluxos escrevem o mesmo path) → §3b-w. O DAG decide
-quantas tasks ao mesmo tempo; o `morph-implement` §4 decide quem executa cada uma —
-`DAG: sequencial` não significa "tudo inline". Registre a linha de decisão que o comando imprimiu.
+{2-3 frases: o comportamento entregue, onde mora e como foi provado}
 
-### 3a. Modo Sequencial (auto-advance)
+**Arquivos:** `{path}`, `{path}`
 
-```
-while (true):
-  ready = tasks 'pending' com todas as dependencies 'done' (releia tasks.json)
-  if ready vazio: break
-  task = ready[0]
-  marcar task.status = 'in_progress' (Edit, só campos mutáveis)
-
-  attempt = 0; feedback = null; pronto = false
-  while attempt < 3:
-    attempt += 1
-    // attempt 1: invoke Skill(morph-implement) with task. Nas seguintes, aplique o
-    // feedback direto ao código — reinvoque a skill só depois de /compact ou numa
-    // sessão nova, que descartam o conteúdo dela.
-    implementar (ou corrigir com feedback)
-
-    // OUTPUTS ANTES DO VERIFY: o recorte por task lê `outputs`.
-    atualizar task.outputs em tasks.json (divergiu do plano → `notes` na mesma edição)
-
-    run: morph-spec verify {feature} {task.id} --json
-    if verify.status == 'fail':
-      feedback = verify.feedback; continue        // conta como tentativa
-    // 'busy': ver "Ritmo"
-
-    // cada doneCriteria com a evidência que o prova (teste, arquivo:linha) — do
-    // relatório `reports/{task.id}.md` quando despachada, do seu código quando inline
-    faltando = critérios sem evidência
-    if faltando: feedback = faltando; continue
-    pronto = true; break
-
-  if pronto:
-    // task com `3-implement/evidencias/{id}.md` em `outputs`: confira o arquivo antes do `done`
-    // (morph-implement §5). Em batch paralelo sem isolamento o sub-agente não roda eval — o
-    // ORQUESTRADOR roda, após o batch, `morph-spec verify {feature} --filter {id-do-nó-evals} --skip-e2e --no-persist`
-    marcar task.status = 'done' (Edit; confirme os outputs reais)
-  else:
-    // 3 tentativas sem verify verde + critérios: a única pausa do loop
-    registrar no recap as tentativas e o que faltou
-    AskUserQuestion: "Task {id} sem verify verde e critérios atendidos após 3 tentativas — aceitar, continuar tentando, ou pular?"
-    options: [aceitar (done com ressalva no recap), continuar (+3 tentativas), pular (blocked)]
-```
+**Checks:** C{n} — {teste que prova, ou `arquivo:linha`}
 
-> **O recorte é do loop por task.** `verify {feature} {task.id}` deixa o `group` escolher os nós e
-> os arquivos de teste de `outputs` estreitarem o comando; cada nó aparece em
-> `nodes.tests.runs[]` com `selection` e o motivo. `--filter {ids}` só força a escolha de nós (um
-> filtro que não casa nada é erro de uso, exit 2); `--full` desliga o recorte. A verificação
-> pós-batch e a do Gate 3 rodam **sem filtro**, e `verify {feature}` **nunca recorta**. Detalhe:
-> `.morph/framework/CLI.md`, seção "Suítes de teste".
+**Standards:** `{id}`, `{id}`
+```
 
-> **Não há juiz LLM por task.** O que o código determinístico prova (build, testes, validadores)
-> está no verify; o que ele não prova — o critério do use case — se confere contra o `doneCriteria`,
-> com evidência. Estilo e estrutura são assunto do avaliador do Gate 3, e mesmo lá só como nota.
+`**Arquivos:**` lista todo arquivo criado ou modificado; cada `C{n}` que a fatia `cobre` aparece pelo
+id; relatório que abre com `PARCIAL` não conta como feito. Os relatórios **são** o registro da
+implementação: o `verify` confere a união dos `**Arquivos:**` contra os
+`arquivos:` das fatias (aviso, nunca reprova). `**Standards:**` nomeia os ids que o agente de fato
+consultou (o `report-check` não o exige).
+- Persona não registrada: `general-purpose` com o campo `persona` de `agents.json` colado, e
+  `dispatch-fallback: general-purpose ({id} não registrado)` no relatório.
 
-### 3b. Modo Paralelo (para o subset independente)
+## 3. Dispatch — só o que muda
 
-Escope cada agente ao domínio: `subagent_type: "morph-{task.agent}"` e `task.standards` (carimbados
-pelo `morph-plan`). Plano legado sem `agent`: escolha em `.morph/framework/agents.json` por
-`domains`. Tipo não registrado: `general-purpose` com o campo `persona` colado, e
-`dispatch-fallback: general-purpose ({id} não registrado)` nas `notes`. Cap de 4 agentes ao mesmo
-tempo. **Cole o template literal** — só os campos entre `<>` mudam:
+O contrato fixo (relatório, estado, teste, escopo, `wip`, processos, reuso, mutação e o formato do
+relatório) está no corpo da persona gerada e chega a todo dispatch sem ser colado. O prompt leva:
 
 ```
 dispatch Agent (subagent_type: "morph-{id}") with prompt:
-  contexto: spec.md, use cases da task, description completa, doneCriteria,
-            task.reuse (REUSAR/ESTENDER/CRIAR por conceito), os paths dos alvos
-            de reuso e o que você já leu (`arquivo:linhas` + o trecho)
-  standards: <por standard: id + digest do `standards --find` + as 3-8 regras do
-             .md que ESTA task aplica, coladas; o path só para consulta pontual>
-  instrução: |
-    Implemente esta task (ou cadeia de tasks do fluxo) sem depender do trabalho
-    dos outros agentes deste batch: seu isolamento é de estado e de árvore de
-    trabalho, nunca de conhecimento do codebase. Antes de criar tipo,
-    componente, hook ou serviço NOVO, verifique se já existe: `morph-spec graph
-    explain <nome>` e `graph affected <conceito> --uses-only`; sem grafo
-    (`no-graph`), caia para `grep -rn "<nome>"` e siga — a ausência de grafo
-    nunca bloqueia. Se criar mesmo assim, diga por que em uma linha no relatório.
-
-    Leitura e turnos: cada turno custa ~10 s antes de a tool rodar, e o teto de
-    turnos corta sem aviso. Chamadas que não dependem uma da outra vão no MESMO
-    turno: leia de uma vez todos os arquivos que este prompt lista, dispare os
-    Grep juntos. Use Read/Grep/Glob — nunca `grep`, `sed -n`, `cat`, `find`,
-    `ls` via Bash. Não releia o que este prompt já traz. Em arquivo grande, `Grep`
-    acha a linha e `Read` com `offset`/`limit` lê só o trecho; log de build/teste
-    se lê pelo `Grep` do erro, não inteiro.
-
-    Ferramentas: antes de supor a API de uma biblioteca (MAF, EF Core, Next,
-    shadcn, SDK de provedor), consulte o MCP `context7` (`resolve-library-id` →
-    `query-docs`). Impacto e vizinhança de símbolo vêm do grafo
-    (`morph-spec graph`). 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. O hook `comment-guard` bloqueia a edição que adiciona história,
-    banner ou bloco longo. Não modifique spec.md.
-
-    Contrato do relatório final:
-    1. GRAVE um relatório por task em
-       `.morph/features/{feature}/3-implement/reports/{taskId}.md` ANTES de
-       encerrar — é o retorno autoritativo. 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`), não sua.
-       Testes pelo orçamento: um por pós-condição, um de regressão por bug,
-       variantes numa tabela. NÃO rode teste a cada marco nem faça ciclo
-       red→green: compile e rode SÓ o filtro dos seus testes UMA vez, em
-       primeiro plano, saída em arquivo
-       (`… > .morph/logs/test-last.log 2>&1`). Não rode `morph-spec verify`.
-       Batch SEM isolamento: só compile. Com `isolation: "worktree"`: o mesmo
-       dentro do seu worktree, e o último ato é o commit na branch dele —
-       nunca faça merge.
-    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), 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 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 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.
-
-    Formato do relatório: (1) o que foi feito, em 2-3 frases; **Arquivos:** um
-    item `- \`path\`` por arquivo; **Critérios:** cada doneCriteria — atendido (o
-    teste ou `arquivo:linha` que o prova) ou não (por quê); (4) problemas.
+Fatia F{n} — <título>
+cobre: <cada Cn com o texto literal do cenário e a `prova:`>
+arquivos: <os `arquivos:` da fatia>
+standards: <por id: o digest de `morph-spec standards --find` + as 3-8 regras que ESTA fatia aplica>
+reuso: <as linhas de `## Reuso` que tocam a fatia — conceito, veredito, alvo>
+contexto: <o que você já leu: `arquivo:linhas` + o trecho; nada que o agente tenha de reler>
+relatório: .morph/features/{feature}/3-implement/reports/F{n}.md (com `**Standards:**`: os ids consultados)
+worktree: <só com isolamento>
 ```
 
-**Passo pós-dispatch (batch SEM isolamento):** espere todos e rode `morph-spec report-check {feature} {T1} {T2} … --json`
-com os ids do batch. O bloco `tree` (`dirty`, `diffstat`, `commits`, `markers`) mostra o disco que
-os agentes deixaram; árvore suja sem explicação ou `markers` não vazio vai ao recap. Em
-`report-stale`, **não re-despache** — leia `observed` e atualize o relatório. Leia cada
-`3-implement/reports/{taskId}.md` (a mensagem do agente é atalho). Depois:
-- **`morph-spec verify {feature} --json` uma vez, pós-batch, sem filtro** — os agentes não o rodaram.
-  Vermelho: corrija ou re-despache com `verify.feedback`.
-- Para cada task do batch:
-  - Se verify verde e critérios atendidos (e `3-implement/evidencias/{taskId}.md` gravada, se a task a deve — checagem do §3a): marcar `done` (Edit, só campos mutáveis).
-  - Senão: de volta a `pending` com nota — o loop sequencial (§3a) a retoma.
-
-**`PARCIAL` na 1ª linha = a task não está pronta** — o `report-check` o acusa como `report-incomplete`.
-Retome o MESMO agente por `SendMessage`, com
-`tree.dirty`, `tree.commits` e o que falta; ou re-despache só o que falta a partir do último `wip`.
-
-O template é paritário com o do `morph-implement` §4: mesmas 8 cláusulas e o mesmo formato de
-relatório (racional em `MORPH.md` §6).
-
-### 3b-w. Batch isolado por worktree (quando o dag recomenda)
-
-1. **Dispatch:** o template de §3b com `isolation: "worktree"`. O hook `WorktreeCreate` cria
-   `worktrees/<n>` na branch `morph-task/<n>`, com junctions e `.morph/worktree.env` prontos, a partir
-   de `morph/<feature>` quando a sessão está nela (fora dela, o prompt abre com
-   `git merge --ff-only morph/<feature>`). Infra faltando: o agente roda `morph-spec worktree link --all`.
-2. **Rolling, não por onda:** a cada relatório, `report-check {feature} {taskId}`, `git merge --no-ff
-   <branch>` (conflito → `git merge --abort`, task volta a `pending` com nota), `verify {feature}
-   {taskId}`, critérios, e despache na hora a task que ficou ready sem colidir com as em voo. Cap
-   de 4. O `verify {feature}` sem filtro roda uma vez, quando nada mais está em voo.
-3. **Cleanup:** depois de cada retorno e ao fim, `morph-spec worktree reap --json` remove o worktree
-   `agent-<hex>` que parou limpo e sem commit exclusivo e lista o resto com a razão
-   (`not-a-registered-worktree` no `remove --target` seguinte = o reaper já o levou). O que sobrar:
-   `morph-spec worktree remove --target <path>` — NUNCA `git worktree remove` cru, que atravessa as
-   junctions. `git branch -d morph-task/<n>` das branches integradas.
-4. **Agente morto no meio:** com commit, a branch é retomável; sem, a task volta a `pending`.
-
-O subagent nunca faz merge, e unidades isoladas e não isoladas não se misturam no mesmo batch.
-
-### 4. Conclusão de tasks
-
-Sem tasks pendentes: invoke `Skill(morph-review)`.
-
-### 5. Gate 3
-
-Apresentado, decidido e aprovado por `morph-review` §7. Ao retomar o controle, **não re-apresente
-o gate** nem aprove de novo: siga para o encerramento conforme `gateDecisions.review`.
-
-### 6. Encerramento
-
-- **Contexto antes do `finish`.** Todo `.morph/context/*.md` que descreve um fato que esta feature
-  mudou tem o **corpo** reescrito para o estado novo; o changelog do documento guarda só data e
-  motivo. Commite na branch da feature — o `finish` exige a árvore limpa.
-- **Fechar:** `morph-spec finish {feature} --pr|--merge`, modo escolhido por `AskUserQuestion`
-  (header `"Integração"`). `--pr` arquiva e abre o PR, mas só o merge integra: a feature fica
-  `aguardando-merge` em `list`/`fleet`. Mecânica: `MORPH.md` §2.1/§2.2.
+## 4. Worktree rolling
+
+Com `isolation: "worktree"` o hook `WorktreeCreate` cria `worktrees/<n>` na branch `morph-task/<n>`,
+com junctions e `.morph/worktree.env` prontos (infra faltando: `morph-spec worktree link --all`).
+**Rolling, não por onda:** a cada relatório, `report-check`, `git merge --no-ff <branch>` (conflito →
+`git merge --abort` e a fatia volta a pendente com nota no relatório) e despache na hora a próxima fatia
+que ficou pronta sem colidir com as em voo. Depois de cada retorno, `morph-spec worktree reap --json`
+(`not-a-registered-worktree` no `remove --target` seguinte = o reaper já o levou); o que sobrar sai por `morph-spec worktree remove --target <path> --delete-branch` (já mergeada; o
+`git branch -d` dele recusa trabalho não integrado) — NUNCA `git worktree remove` cru,
+que atravessa as junctions.
+
+## 5. Retomar o controle
+
+`morph-spec report-check {feature} F1 F2 … --json` com as fatias que voltaram. **Leia o arquivo de
+relatório, não a mensagem** — a mensagem final pode não chegar ou vir resumida.
+
+| Veredito | Ação |
+|---|---|
+| `ok` | siga |
+| `report-stale` | **não re-despache**: o agente escreveu depois de relatar; leia `observed` e atualize o relatório |
+| `report-incomplete` + `resume` | `PARCIAL` na 1ª linha = a fatia 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 |
+| `report-incomplete` + `complete-degraded` | complete a partir da mensagem, carimbe DEGRADADO e registre a falha no relatório |
+| `work-landed-report-missing` | não re-despache; grave você o relatório, DEGRADADO |
+| `no-work-no-report` / `report-missing-evidence-unknown` | re-despache uma vez; segunda ausência sem trabalho = escale |
+
+Árvore suja sem explicação ou `tree.markers` não vazio vão ao relatório da fatia.
+
+## 6. Verify da feature, uma vez
+
+Sem fatia pendente nem em voo, **primeiro o contexto** — antes do verify, para que a prova e o Gate 3
+cubram a árvore que vai ao merge. Todo `.morph/context/*.md` que descreve um fato que esta feature
+mudou tem o **corpo** reescrito para o estado novo, nunca empilhado (valor que ainda vale em algum
+lugar diz onde); o changelog do documento guarda só data e motivo. Mudança estrutural
+(`package.json`, `.csproj`, `next.config.*`, `tsconfig.json`, `docker-compose.yml`) atualiza também
+`.morph/context/README.md` (stack, arquitetura, integrações) e `.morph/config/config.json` (stack,
+arquitetura, integrações, paths). **Commite** o trabalho das fatias e essa atualização de contexto e
+config **antes** do verify: o stamp grava o HEAD, e código ou `config.json` commitado depois dele é
+árvore nova — um terceiro verify.
+
+Depois `morph-spec verify {feature} --json`, **sem filtro** — nunca recorte o
+verify da feature. `--filter` é do loop do próprio sub-agente; o Gate 3 e o CI rodam a suíte
+inteira. Nó de teste sem `expectedCount`: acrescente `--record-baseline` a ESTA rodada — ela mede e
+prova de uma vez; nunca um segundo verify só para gravar a baseline. Vermelho: corrija com `verify.feedback` (direto no código, ou re-despachando a fatia dona)
+e rode de novo; **3 tentativas** sem verde → `AskUserQuestion` ("Verify de {feature} vermelho após 3
+tentativas — aceitar com ressalva, continuar tentando, ou parar?").
+
+**Cenário que julga saída de LLM** (`prova: eval`): a evidência é rodar, não ler código. Com nó
+`runner: "evals"`: `morph-spec verify {feature} --filter {id-do-nó-evals} --skip-e2e --no-persist`
+(sonda, não prova de gate). Grave `3-implement/evidencias/{Cn}.md`: o cenário literal, o nó, 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/F{n}.md`: aquele diz o que o agente fez; este prova, rodando,
+que a saída atende ao cenário.
+
+## 7. Review
+
+Verify verde: `Skill(morph-review)`. O Gate 3 é apresentado, decidido e aprovado por ela; ao retomar o
+controle, **não re-apresente o gate** — siga para o encerramento conforme `gateDecisions.review`.
+
+## 8. Encerramento
+
+- **Contexto já foi no §6**, antes da prova. Depois do Gate 3 nada muda `config.json` nem código: a
+  árvore integrada é a revisada. Commite na branch da feature o que faltar (relatórios do review) —
+  o `finish` exige a árvore limpa.
+- **Fechar:** `morph-spec finish {feature} --pr|--merge`, modo por `AskUserQuestion` (header
+  `"Integração"`). `--pr` arquiva e abre o PR, mas só o merge integra: a feature fica
+  `aguardando-merge` em `list`/`fleet`.
+
+## Escalada de escopo
+
+| Situação | Caminho |
+|---|---|
+| Acréscimo pequeno dentro da fatia | registre no relatório da fatia — sem gate a revogar |
+| **Fato errado**: o plano afirma algo que o código desmente, sem mudar escopo | bloco `## Errata` no FIM do `plan.md`, corpo intacto, append-only |
+| **O escopo mudou** | `morph-spec unapprove {feature} plan --reason "..."`, emende, `plan-check`, re-aprove |
+
+Ambiguidade que o plano não cobre não é escalada: resolva pelo lado conservador, registre a decisão sob `## Errata` do `plan.md`
+e siga.
+
+## Arquivo de teste
+
+1. **Analise primeiro** — a IMPLEMENTAÇÃO está errada ou a ESPECIFICAÇÃO do teste está?
+2. **Corrija a implementação primeiro** — o teste é a especificação; confie nele por padrão.
+3. **Só mude um arquivo de teste se a própria expectativa estiver errada.**
+4. **Antes de mudar, explique POR QUE o teste está errado** — qual é o comportamento certo.
+
+## Debugging
+
+Causa raiz antes do conserto: reproduza e leia o erro inteiro; erro conhecido de .NET/Next.js →
+`/morph-troubleshoot <palavras>`; **uma hipótese por vez**, cada uma testada pela menor checagem que
+a refutaria; depois de três consertos falhos, nunca tente um quarto sozinho — `AskUserQuestion`
+com a pergunta de desenho que as falhas levantam; confirme com a mesma checagem que reproduziu.
 
 ## Anti-padrões
 
-- Paralelo com dependência cruzada entre as tasks do batch.
-- Mais de 4 agentes ao mesmo tempo; agente inteiro para raiz S.
-- Sub-agent tocando `tasks.json`, `feature.json` ou o board de sessão.
-- Editar `spec.md` depois do Gate 2, ou `feature.json` à mão.
+- Mais de 4 agentes ao mesmo tempo, ou duas fatias em voo no mesmo arquivo sem worktree.
+- Sub-agente tocando `plan.md`, `checks.json` ou `feature.json`.
+- Re-despachar sobre `report-stale` ou sobre um `PARCIAL` (retome o MESMO agente).
 - Rodar teste fora do `verify` no loop do orquestrador: a prova é o verify.
-
-## Referências
-
-- `.morph/framework/MORPH.md` §6 — contrato do relatório final
-- `morph-spec dag|verify|report-check|worktree reap` — `.morph/framework/CLI.md`
-- `.claude/skills/morph-implement/SKILL.md` §4 — template sequencial paritário
-- `.claude/skills/morph-review/SKILL.md` — Gate 3