@polymorphism-tech/morph-spec 8.0.0 → 8.1.1

package/framework/rules/dotnet-templates.md

@@ -1,86 +1,86 @@
----
-paths:
-  - "**/*.cs"
-  - "**/*.csproj"
-stacks:
-  - dotnet
----
-
-# .NET Code Templates
-
-When implementing .NET features, use these templates as reference patterns.
-Read the template file to see the exact pattern, then generate code following it.
-
-## Scaffold (preferred for new slices)
-
-**Always use scaffold for new VSA slices — never create feature files manually.**
-
-```bash
-morph-spec scaffold dotnet <feature> <slice-name> [--namespace <ns>] [--dry-run]
-```
-
-Examples:
-```bash
-morph-spec scaffold dotnet book create-book
-morph-spec scaffold dotnet book get-book-by-id
-morph-spec scaffold dotnet book update-book
-morph-spec scaffold dotnet book delete-book
-morph-spec scaffold dotnet book get-all-books
-```
-
-Generates 7 files: endpoint, handler, request, response, validator + entity, errors (shared at feature level). Entity/errors auto-skipped if they already exist.
-
-**Only use `template render` for individual files when adding to an existing slice.**
-
-## VSA Feature Templates (Vertical Slice Architecture)
-
-For each new feature slice, follow the patterns in these templates:
-
-| Template | Path | Purpose |
-|----------|------|---------|
-| Endpoint | `.morph/framework/templates/code/dotnet/feature/endpoint.cs.hbs` | IApiEndpoint with MapEndpoint() |
-| Handler | `.morph/framework/templates/code/dotnet/feature/handler.cs.hbs` | IHandler<TRequest, TResponse> |
-| Request | `.morph/framework/templates/code/dotnet/feature/request.cs.hbs` | Sealed record DTO |
-| Response | `.morph/framework/templates/code/dotnet/feature/response.cs.hbs` | Sealed record DTO |
-| Validator | `.morph/framework/templates/code/dotnet/feature/validator.cs.hbs` | FluentValidation AbstractValidator |
-| Entity | `.morph/framework/templates/code/dotnet/feature/entity.cs.hbs` | Domain entity |
-| Errors | `.morph/framework/templates/code/dotnet/feature/errors.cs.hbs` | Error factory |
-
-## Base Abstractions (read once per project setup)
-
-| Template | Path | Purpose |
-|----------|------|---------|
-| IHandler | `.morph/framework/templates/code/dotnet/abstractions/handler.cs` | Handler interface |
-| Result<T> | `.morph/framework/templates/code/dotnet/abstractions/result.cs` | Railway-oriented result |
-| Error | `.morph/framework/templates/code/dotnet/abstractions/error.cs` | Error types |
-| IApiEndpoint | `.morph/framework/templates/code/dotnet/abstractions/api-endpoint.cs` | Endpoint interface |
-
-## Extensions & Pipeline (read once per project setup)
-
-| Template | Path | Purpose |
-|----------|------|---------|
-| Handler Registration | `.morph/framework/templates/code/dotnet/extensions/handler-registration.cs` | Scrutor auto-discovery |
-| Map Endpoints | `.morph/framework/templates/code/dotnet/extensions/map-endpoints.cs` | IApiEndpoint discovery |
-| Result Extensions | `.morph/framework/templates/code/dotnet/extensions/result-extensions.cs` | Match() pattern |
-| Database Config | `.morph/framework/templates/code/dotnet/extensions/database-extensions.cs` | EF Core + Npgsql |
-| Health Checks | `.morph/framework/templates/code/dotnet/extensions/health-checks.cs` | Health endpoints |
-| Validation Decorator | `.morph/framework/templates/code/dotnet/pipelines/validation-decorator.cs` | FluentValidation pipeline |
-| Logging Decorator | `.morph/framework/templates/code/dotnet/pipelines/logging-decorator.cs` | Duration tracking |
-| Exception Handler | `.morph/framework/templates/code/dotnet/exceptions/exception-handler.cs` | ProblemDetails |
-| API Tags | `.morph/framework/templates/code/dotnet/constants/api-tags.cs` | Scalar/Swagger groups |
-
-## Specialized Templates
-
-| Template | Path | Purpose |
-|----------|------|---------|
-| Migration | `.morph/framework/templates/code/dotnet/database/migration.cs` | EF Core migration |
-| Hangfire Job | `.morph/framework/templates/code/dotnet/jobs/job.cs` | Background job |
-| MAF Agent | `.morph/framework/templates/code/dotnet/jobs/agent.cs` | MS Agent Framework |
-| Unit Test | `.morph/framework/templates/code/dotnet/test.cs` | xUnit AAA test |
-| Contracts VSA | `.morph/framework/templates/code/dotnet/contracts/contracts-vsa.cs` | Full slice contracts |
-
-## Usage
-
-1. **Read the template** to see the exact pattern
-2. **Generate code following the same structure** (naming, namespaces, imports)
-3. Or render via CLI: `morph-spec template render <id> <output> '<variables>'`
+---
+paths:
+  - "**/*.cs"
+  - "**/*.csproj"
+stacks:
+  - dotnet
+---
+
+# .NET Code Templates
+
+When implementing .NET features, use these templates as reference patterns.
+Read the template file to see the exact pattern, then generate code following it.
+
+## Scaffold (preferred for new slices)
+
+**Always use scaffold for new VSA slices — never create feature files manually.**
+
+```bash
+morph-spec scaffold dotnet <feature> <slice-name> [--namespace <ns>] [--dry-run]
+```
+
+Examples:
+```bash
+morph-spec scaffold dotnet book create-book
+morph-spec scaffold dotnet book get-book-by-id
+morph-spec scaffold dotnet book update-book
+morph-spec scaffold dotnet book delete-book
+morph-spec scaffold dotnet book get-all-books
+```
+
+Generates 7 files: endpoint, handler, request, response, validator + entity, errors (shared at feature level). Entity/errors auto-skipped if they already exist.
+
+**Only use `template render` for individual files when adding to an existing slice.**
+
+## VSA Feature Templates (Vertical Slice Architecture)
+
+For each new feature slice, follow the patterns in these templates:
+
+| Template | Path | Purpose |
+|----------|------|---------|
+| Endpoint | `.morph/framework/templates/code/dotnet/feature/endpoint.cs.hbs` | IApiEndpoint with MapEndpoint() |
+| Handler | `.morph/framework/templates/code/dotnet/feature/handler.cs.hbs` | IHandler<TRequest, TResponse> |
+| Request | `.morph/framework/templates/code/dotnet/feature/request.cs.hbs` | Sealed record DTO |
+| Response | `.morph/framework/templates/code/dotnet/feature/response.cs.hbs` | Sealed record DTO |
+| Validator | `.morph/framework/templates/code/dotnet/feature/validator.cs.hbs` | FluentValidation AbstractValidator |
+| Entity | `.morph/framework/templates/code/dotnet/feature/entity.cs.hbs` | Domain entity |
+| Errors | `.morph/framework/templates/code/dotnet/feature/errors.cs.hbs` | Error factory |
+
+## Base Abstractions (read once per project setup)
+
+| Template | Path | Purpose |
+|----------|------|---------|
+| IHandler | `.morph/framework/templates/code/dotnet/abstractions/handler.cs` | Handler interface |
+| Result<T> | `.morph/framework/templates/code/dotnet/abstractions/result.cs` | Railway-oriented result |
+| Error | `.morph/framework/templates/code/dotnet/abstractions/error.cs` | Error types |
+| IApiEndpoint | `.morph/framework/templates/code/dotnet/abstractions/api-endpoint.cs` | Endpoint interface |
+
+## Extensions & Pipeline (read once per project setup)
+
+| Template | Path | Purpose |
+|----------|------|---------|
+| Handler Registration | `.morph/framework/templates/code/dotnet/extensions/handler-registration.cs` | Scrutor auto-discovery |
+| Map Endpoints | `.morph/framework/templates/code/dotnet/extensions/map-endpoints.cs` | IApiEndpoint discovery |
+| Result Extensions | `.morph/framework/templates/code/dotnet/extensions/result-extensions.cs` | Match() pattern |
+| Database Config | `.morph/framework/templates/code/dotnet/extensions/database-extensions.cs` | EF Core + Npgsql |
+| Health Checks | `.morph/framework/templates/code/dotnet/extensions/health-checks.cs` | Health endpoints |
+| Validation Decorator | `.morph/framework/templates/code/dotnet/pipelines/validation-decorator.cs` | FluentValidation pipeline |
+| Logging Decorator | `.morph/framework/templates/code/dotnet/pipelines/logging-decorator.cs` | Duration tracking |
+| Exception Handler | `.morph/framework/templates/code/dotnet/exceptions/exception-handler.cs` | ProblemDetails |
+| API Tags | `.morph/framework/templates/code/dotnet/constants/api-tags.cs` | Scalar/Swagger groups |
+
+## Specialized Templates
+
+| Template | Path | Purpose |
+|----------|------|---------|
+| Migration | `.morph/framework/templates/code/dotnet/database/migration.cs` | EF Core migration |
+| Hangfire Job | `.morph/framework/templates/code/dotnet/jobs/job.cs` | Background job |
+| MAF Agent | `.morph/framework/templates/code/dotnet/jobs/agent.cs` | MS Agent Framework |
+| Unit Test | `.morph/framework/templates/code/dotnet/test.cs` | xUnit AAA test |
+| Contracts VSA | `.morph/framework/templates/code/dotnet/contracts/contracts-vsa.cs` | Full slice contracts |
+
+## Usage
+
+1. **Read the template** to see the exact pattern
+2. **Generate code following the same structure** (naming, namespaces, imports)
+3. Or render via CLI: `morph-spec template render <id> <output> '<variables>'`

package/framework/rules/frontend-standards.md

@@ -1,13 +1,13 @@
----
-paths:
-  - "**/*.tsx"
-  - "**/*.css"
-  - "**/*.scss"
-stacks:
-  - nextjs
----
-
-# Frontend Standards
-
-@.morph/framework/standards/frontend/design-system/naming.md
-@.morph/framework/standards/frontend/design-system/animations.md
+---
+paths:
+  - "**/*.tsx"
+  - "**/*.css"
+  - "**/*.scss"
+stacks:
+  - nextjs
+---
+
+# Frontend Standards
+
+@.morph/framework/standards/frontend/design-system/naming.md
+@.morph/framework/standards/frontend/design-system/animations.md

package/framework/rules/infrastructure-standards.md

@@ -1,27 +1,27 @@
----
-paths:
-  - "**/Dockerfile*"
-  - "**/docker-compose*"
-  - "**/.github/**"
-  - "**/coolify*"
-stacks:
-  - docker
----
-
-# Infrastructure Standards
-
-@.morph/framework/standards/infrastructure/docker/coolify-deploy.md
-
-## Infrastructure Templates
-
-| Template | Path | Purpose |
-|----------|------|---------|
-| .NET API Dockerfile | `.morph/framework/templates/infrastructure/docker/dockerfile-api.dockerfile` | Multi-stage .NET |
-| Next.js Dockerfile | `.morph/framework/templates/infrastructure/docker/dockerfile-web.dockerfile` | Multi-stage Next.js |
-| Docker Compose | `.morph/framework/templates/infrastructure/docker/docker-compose.template.yml` | Local dev env |
-| Coolify Config | `.morph/framework/templates/infrastructure/docker/coolify.template.json` | Deployment config |
-| .NET Build CI | `.morph/framework/templates/infrastructure/github/workflows/dotnet-build.yml.hbs` | CI workflow |
-| Docker Push CI | `.morph/framework/templates/infrastructure/github/workflows/docker-build-push.yml.hbs` | Build & push |
-| Deploy Coolify | `.morph/framework/templates/infrastructure/github/workflows/deploy-coolify.yml.hbs` | CD via SSH |
-
-Read the template and adapt to your project structure.
+---
+paths:
+  - "**/Dockerfile*"
+  - "**/docker-compose*"
+  - "**/.github/**"
+  - "**/coolify*"
+stacks:
+  - docker
+---
+
+# Infrastructure Standards
+
+@.morph/framework/standards/infrastructure/docker/coolify-deploy.md
+
+## Infrastructure Templates
+
+| Template | Path | Purpose |
+|----------|------|---------|
+| .NET API Dockerfile | `.morph/framework/templates/infrastructure/docker/dockerfile-api.dockerfile` | Multi-stage .NET |
+| Next.js Dockerfile | `.morph/framework/templates/infrastructure/docker/dockerfile-web.dockerfile` | Multi-stage Next.js |
+| Docker Compose | `.morph/framework/templates/infrastructure/docker/docker-compose.template.yml` | Local dev env |
+| Coolify Config | `.morph/framework/templates/infrastructure/docker/coolify.template.json` | Deployment config |
+| .NET Build CI | `.morph/framework/templates/infrastructure/github/workflows/dotnet-build.yml.hbs` | CI workflow |
+| Docker Push CI | `.morph/framework/templates/infrastructure/github/workflows/docker-build-push.yml.hbs` | Build & push |
+| Deploy Coolify | `.morph/framework/templates/infrastructure/github/workflows/deploy-coolify.yml.hbs` | CD via SSH |
+
+Read the template and adapt to your project structure.

package/framework/rules/neon-standards.md

@@ -1,25 +1,25 @@
----
-paths:
-  - "**/neon/**"
-  - "**/database/**"
-  - "**/*Migration*.sql"
-  - "**/*migration*.sql"
-stacks:
-  - neon
----
-
-# Neon PostgreSQL Standards
-
-@.morph/framework/standards/infrastructure/neon/neon-setup.md
-@.morph/framework/standards/infrastructure/neon/neon-pgvector.md
-@.morph/framework/standards/infrastructure/neon/neon-pgrag.md
-@.morph/framework/standards/backend/integrations/neon-auth/neon-auth.md
-
-## SQL Templates
-
-| Template | Path | Purpose |
-|----------|------|---------|
-| PostgreSQL Migration | `.morph/framework/templates/code/sql/postgresql-migration.sql` | Database migration |
-| PostgreSQL RLS Policy | `.morph/framework/templates/code/sql/postgresql-rls-policy.sql` | Row-level security |
-
-Read the template and adapt to your project structure.
+---
+paths:
+  - "**/neon/**"
+  - "**/database/**"
+  - "**/*Migration*.sql"
+  - "**/*migration*.sql"
+stacks:
+  - neon
+---
+
+# Neon PostgreSQL Standards
+
+@.morph/framework/standards/infrastructure/neon/neon-setup.md
+@.morph/framework/standards/infrastructure/neon/neon-pgvector.md
+@.morph/framework/standards/infrastructure/neon/neon-pgrag.md
+@.morph/framework/standards/backend/integrations/neon-auth/neon-auth.md
+
+## SQL Templates
+
+| Template | Path | Purpose |
+|----------|------|---------|
+| PostgreSQL Migration | `.morph/framework/templates/code/sql/postgresql-migration.sql` | Database migration |
+| PostgreSQL RLS Policy | `.morph/framework/templates/code/sql/postgresql-rls-policy.sql` | Row-level security |
+
+Read the template and adapt to your project structure.

package/framework/rules/nextjs-standards.md

@@ -1,20 +1,20 @@
----
-paths:
-  - "**/*.tsx"
-  - "**/*.ts"
-stacks:
-  - nextjs
----
-
-# Next.js Standards
-
-@.morph/framework/standards/frontend/nextjs/naming-conventions.md
-@.morph/framework/standards/frontend/nextjs/project-structure.md
-@.morph/framework/standards/frontend/nextjs/app-router.md
-@.morph/framework/standards/frontend/nextjs/components.md
-@.morph/framework/standards/frontend/nextjs/data-fetching.md
-@.morph/framework/standards/frontend/nextjs/forms.md
-@.morph/framework/standards/frontend/nextjs/state-management.md
-@.morph/framework/standards/frontend/nextjs/testing.md
-@.morph/framework/standards/frontend/nextjs/nextjs-patterns.md
-@.morph/framework/standards/frontend/nextjs/motion-patterns.md
+---
+paths:
+  - "**/*.tsx"
+  - "**/*.ts"
+stacks:
+  - nextjs
+---
+
+# Next.js Standards
+
+@.morph/framework/standards/frontend/nextjs/naming-conventions.md
+@.morph/framework/standards/frontend/nextjs/project-structure.md
+@.morph/framework/standards/frontend/nextjs/app-router.md
+@.morph/framework/standards/frontend/nextjs/components.md
+@.morph/framework/standards/frontend/nextjs/data-fetching.md
+@.morph/framework/standards/frontend/nextjs/forms.md
+@.morph/framework/standards/frontend/nextjs/state-management.md
+@.morph/framework/standards/frontend/nextjs/testing.md
+@.morph/framework/standards/frontend/nextjs/nextjs-patterns.md
+@.morph/framework/standards/frontend/nextjs/motion-patterns.md

package/framework/rules/nextjs-templates.md

@@ -1,40 +1,40 @@
----
-paths:
-  - "**/*.tsx"
-  - "**/*.ts"
-stacks:
-  - nextjs
----
-
-# Next.js Code Templates
-
-When implementing Next.js features, use these templates as reference patterns.
-Read the template file to see the exact pattern, then generate code following it.
-
-## Scaffold (preferred for new features)
-
-**Always use scaffold for new feature pages — never create feature files manually.**
-
-```bash
-morph-spec scaffold nextjs <feature> [--dry-run]
-```
-
-Examples:
-```bash
-morph-spec scaffold nextjs book
-morph-spec scaffold nextjs user-profile
-```
-
-Generates 4 files: page (Server Component), list component, form component, TanStack Query hook.
-
-**Only use `template render` for individual files when modifying an existing feature.**
-
-| Template | Path | Purpose |
-|----------|------|---------|
-| Server Page | `.morph/framework/templates/frontend/nextjs/page.tsx.hbs` | App Router server component |
-| Client Component | `.morph/framework/templates/frontend/nextjs/client-component.tsx.hbs` | `'use client'` component |
-| Feature Form | `.morph/framework/templates/frontend/nextjs/feature-form.tsx.hbs` | react-hook-form + Zod + shadcn |
-| Custom Hook | `.morph/framework/templates/frontend/nextjs/use-feature.ts.hbs` | TanStack Query hook |
-| Env Config | `.morph/framework/templates/frontend/nextjs/env.mjs.hbs` | T3 Env validation |
-| TypeScript Config | `.morph/framework/templates/frontend/nextjs/tsconfig.json.hbs` | Path aliases |
-| Dockerfile | `.morph/framework/templates/frontend/nextjs/Dockerfile.nextjs.hbs` | Multi-stage build |
+---
+paths:
+  - "**/*.tsx"
+  - "**/*.ts"
+stacks:
+  - nextjs
+---
+
+# Next.js Code Templates
+
+When implementing Next.js features, use these templates as reference patterns.
+Read the template file to see the exact pattern, then generate code following it.
+
+## Scaffold (preferred for new features)
+
+**Always use scaffold for new feature pages — never create feature files manually.**
+
+```bash
+morph-spec scaffold nextjs <feature> [--dry-run]
+```
+
+Examples:
+```bash
+morph-spec scaffold nextjs book
+morph-spec scaffold nextjs user-profile
+```
+
+Generates 4 files: page (Server Component), list component, form component, TanStack Query hook.
+
+**Only use `template render` for individual files when modifying an existing feature.**
+
+| Template | Path | Purpose |
+|----------|------|---------|
+| Server Page | `.morph/framework/templates/frontend/nextjs/page.tsx.hbs` | App Router server component |
+| Client Component | `.morph/framework/templates/frontend/nextjs/client-component.tsx.hbs` | `'use client'` component |
+| Feature Form | `.morph/framework/templates/frontend/nextjs/feature-form.tsx.hbs` | react-hook-form + Zod + shadcn |
+| Custom Hook | `.morph/framework/templates/frontend/nextjs/use-feature.ts.hbs` | TanStack Query hook |
+| Env Config | `.morph/framework/templates/frontend/nextjs/env.mjs.hbs` | T3 Env validation |
+| TypeScript Config | `.morph/framework/templates/frontend/nextjs/tsconfig.json.hbs` | Path aliases |
+| Dockerfile | `.morph/framework/templates/frontend/nextjs/Dockerfile.nextjs.hbs` | Multi-stage build |

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.0.0"
+cliVersion: "8.1.1"
 ---
 
 # create-umbraco-lp

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.0.0"
+cliVersion: "8.1.1"
 ---
 
 # migrate-lp-to-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.0.0"
+cliVersion: "8.1.1"
 ---
 
 # morph-apply
@@ -134,21 +134,12 @@ dispatch Agent (subagent_type: "morph-{id}") with prompt:
     Implemente esta task (ou cadeia de tasks do fluxo) isoladamente.
     Não modifique spec.md, mandate.md.
 
-    Protocolo obrigatório:
-    1. ATO FINAL OBRIGATÓRIO — relatório via SendMessage: chame a tool
-       SendMessage com to:"main" e o relatório completo no content como a
-       ÚLTIMA tool call do seu turno. Sua última mensagem em texto NÃO chega
-       ao orquestrador — só SendMessage chega. Encerre IMEDIATAMENTE depois
-       da chamada: zero texto adicional, zero nova tool call, zero "aguardando
-       confirmação" — o SendMessage É o encerramento, não um passo
-       intermediário.
-       Exemplo literal (última chamada de tool da sua sessão, sem nada depois):
-       SendMessage({ to: "main", content: "Fluxo backend concluído (T2→T7).
-       Sumário: ... Arquivos: src/... Standards: vsa-handler-patterns.
-       Auto-score: 9/10" })
-       Terminar idle sem SendMessage, ou continuar agindo depois dele, é
-       falha de protocolo — cada segundo entre o SendMessage e o fim real do
-       turno é cauda que o orquestrador espera sem necessidade.
+    Contrato do relatório final:
+    1. ATO FINAL — o seu relatório é a sua ÚLTIMA MENSAGEM DE TEXTO: ela é o
+       valor de retorno desta sessão e chega inteira ao orquestrador. NÃO chame
+       SendMessage: ele gera um evento a mais além da notificação de término,
+       custando um turno inútil ao orquestrador. Escreva o relatório e encerre.
+       Relatório oco, ou sem os itens abaixo, é falha de protocolo.
     2. NÃO toque em tasks.json, feature.json, state.json nem no board de sessão
        (TaskCreate/TaskUpdate) — todo estado (status de task, scores, gates) é
        gravado exclusivamente pelo orquestrador.
@@ -158,21 +149,21 @@ dispatch Agent (subagent_type: "morph-{id}") with prompt:
          a verificação é do orquestrador, uma vez, pós-batch (`morph-spec verify`).
        - Batch COM isolamento (você recebeu `isolation: "worktree"`): rode build/test
          DENTRO do seu worktree; commite seu trabalho na branch do worktree como
-         penúltimo ato (antes do SendMessage); reporte a branch + status de build no
+         último ato antes do relatório; reporte a branch + status de build no
          relatório; NUNCA faça merge nem toque na árvore principal.
 
-    Retorne no content do SendMessage:
+    Seu relatório final deve conter:
       - sumário das mudanças
       - arquivos modificados (paths)
       - standard(s) consultado(s)
       - auto-score 0-10 (rubric: completeness, correctness, mandate compliance)
 ```
 
-> 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 cláusulas de protocolo. A única diferença é que aqui múltiplos agentes rodam ao mesmo tempo, um por fluxo independente.
+> Este template é deliberadamente paritário com o template sequencial em `morph-implement` §4: ambos despacham o **subagent registrado do domínio (`morph-{id}`)** com standard escopado e as mesmas cláusulas do contrato do relatório final. 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. O hook `subagent-report-guard` (Stop/SubagentStop) bloqueia uma vez o encerramento de um subagent despachado que não chamou SendMessage, com a instrução da cláusula 1 — o ciclo cobrar-esperar deixa de ser o caminho normal. **Fallback: se mesmo assim um agente ficar idle sem entregar o relatório, cobre-o via SendMessage e registre a falha de protocolo no recap.** Assim que o relatório de um agente chegar (SendMessage como teammate-message), **libere a sessão imediatamente** — chame `TaskStop(task_id: <id/nome do agente retornado pelo dispatch>)` antes de seguir para o próximo agente. Não espere o idle-detector do harness: sem esse `TaskStop`, a sessão fica pendurada minutos até o harness marcá-la idle sozinho e injetar um `idle_notification` vazio de volta nesta sessão. Trate falha do TaskStop (agente já finalizado sozinho) como não-fatal. Depois, sequencialmente:
+Aguardar todos os agentes terminarem — o relatório de cada um chega como o resultado do seu dispatch. Se um relatório vier oco ou sem os itens da cláusula 1, registre a falha de protocolo no recap. Depois, sequencialmente:
 - **Rodar `morph-spec verify {feature} --json` uma única vez, pós-batch** (escopo feature) — 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)`.
@@ -187,7 +178,7 @@ Depois do batch paralelo, executar o restante em modo sequencial (passo 3a).
 Quando o `morph-spec dag {feature}` reporta `isolation.recommended: "worktree"` (dois fluxos paralelos planejam escrever no mesmo path — colisão de `outputs`), despache cada fluxo com o parâmetro `isolation: "worktree"` do tool Agent. Cada agente trabalha numa working tree própria; build/test rodam lá dentro sem colidir.
 
 1. **Dispatch:** mesmo `subagent_type: "morph-{id}"` e standards de §3b, mais `isolation: "worktree"`. Se a stack for Node e faltar `node_modules` no worktree, o agente roda `morph-spec worktree link` (fail-open) antes de testar; se ainda impossível, reporta "verificação: não executada" (o verify pós-merge cobre). O agente commita na branch do worktree e reporta a branch.
-2. **Integração (orquestrador, após todos os relatórios + `TaskStop`):** faça o merge de cada branch reportada, uma por vez, na ordem de chegada — `git merge --no-ff <branch>`. Conflito → `git merge --abort`, marque a task de volta a `pending` com nota "merge conflict — reexecutar sequencial", siga para a próxima branch. Os paths em conflito são exatamente os de `isolation.collisions` do dag.
+2. **Integração (orquestrador, após todos os relatórios):** faça o merge de cada branch reportada, uma por vez, na ordem de chegada — `git merge --no-ff <branch>`. Conflito → `git merge --abort`, marque a task de volta a `pending` com nota "merge conflict — reexecutar sequencial", siga para a próxima branch. Os paths em conflito são exatamente os de `isolation.collisions` do dag.
 3. **Pós-merge:** rode `morph-spec verify {feature} --json` UMA vez (o merge é o novo ponto de integração — verificação compartilhada obrigatória), depois `morph-eval` + `morph-spec score` por relatório, como em §3b.
 4. **Cleanup:** `git worktree remove` + `git branch -d` das branches integradas + `git worktree prune` (fail-open). Branches não integradas ficam e são registradas no recap com o motivo.
 5. **Agente morto no meio:** se commitou, a branch sobrevive (retomável); senão, a task volta a `pending` na lane sequencial. Registre a falha de protocolo no recap.

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

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

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

@@ -4,7 +4,7 @@ description: Avalia a qualidade de uma tarefa ou fase com rubricas graduadas 0-1
 version: core
 when-to-invoke: ao completar uma tarefa ou ao finalizar uma fase de implementação
 user-invokable: false
-cliVersion: "8.0.0"
+cliVersion: "8.1.1"
 ---
 
 # 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.0.0"
+cliVersion: "8.1.1"
 ---
 
 # morph-hotfix
@@ -43,9 +43,7 @@ subagent_type: "morph-scout"
 
 **Fallback** (se `morph-scout` não estiver registrado nos subagent types deste projeto): `general-purpose` com o campo `persona` do agente `scout` colado no prompt, **registrando o fallback nas notes da task**.
 
-Peça ao scout: localizar o root cause provável, os arquivos afetados e o blast radius (o que mais pode quebrar). Ele é read-only (Read/Glob/Grep/Bash somente-leitura) — não escreve código. Inclua as 3 cláusulas de protocolo obrigatório no prompt (template literal em `morph-implement` §4 / `morph-apply` §3b): ato final = relatório via `SendMessage` para `main` como a ÚLTIMA tool call do turno, sem texto ou tool call depois; não tocar `tasks.json`/`feature.json`/`state.json` nem o board de sessão; sem build/test da suíte compartilhada em batch paralelo.
-
-Ao receber o mapa via `SendMessage`, **libere a sessão imediatamente**: `TaskStop(task_id: <id/nome retornado pelo dispatch>)` (trate falha como não-fatal).
+Peça ao scout: localizar o root cause provável, os arquivos afetados e o blast radius (o que mais pode quebrar). Ele é read-only (Read/Glob/Grep/Bash somente-leitura) — não escreve código. Inclua as 3 cláusulas do contrato do relatório final no prompt (template literal em `morph-implement` §4 / `morph-apply` §3b): ato final = o relatório é a última mensagem de texto, sem `SendMessage`; não tocar `tasks.json`/`feature.json`/`state.json` nem o board de sessão; sem build/test da suíte compartilhada em batch paralelo.
 
 ### 3. Hotfix brief (`0-proposal/proposal.md`)
 

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

@@ -4,7 +4,7 @@ description: Guia a execução de cada tarefa de implementação com standard e
 version: core
 when-to-invoke: ao iniciar cada task de implementação listada em tasks.json
 user-invokable: false
-cliVersion: "8.0.0"
+cliVersion: "8.1.1"
 ---
 
 # morph-implement
@@ -58,21 +58,12 @@ Ao iniciar cada task de `tasks.json` — antes de escrever qualquer código. Nor
    Arquivos relevantes: [lista de paths]
    Done quando: [doneCriteria do tasks.json]
 
-   Protocolo obrigatório:
-   1. ATO FINAL OBRIGATÓRIO — relatório via SendMessage: chame a tool
-      SendMessage com to:"main" e o relatório completo no content como a
-      ÚLTIMA tool call do seu turno. Sua última mensagem em texto NÃO chega
-      ao orquestrador — só SendMessage chega. Encerre IMEDIATAMENTE depois
-      da chamada: zero texto adicional, zero nova tool call, zero "aguardando
-      confirmação" — o SendMessage É o encerramento, não um passo
-      intermediário antes de um encerramento "de verdade".
-      Exemplo literal (última chamada de tool da sua sessão, sem nada depois):
-      SendMessage({ to: "main", content: "T{N} concluída. (1) O que foi feito:
-      handler + validator do slice X. (2) Arquivos: src/Features/X/Handler.cs,
-      tests/X/HandlerTests.cs. (3) Problemas: nenhum. (4) Auto-score: 9/10" })
-      Terminar idle sem SendMessage, ou continuar agindo depois dele, é
-      falha de protocolo — cada segundo entre o SendMessage e o fim real do
-      turno é cauda que o orquestrador espera sem necessidade.
+   Contrato do relatório final:
+   1. ATO FINAL — o seu relatório é a sua ÚLTIMA MENSAGEM DE TEXTO: ela é o
+      valor de retorno desta sessão e chega inteira ao orquestrador. NÃO chame
+      SendMessage: ele gera um evento a mais além da notificação de término,
+      custando um turno inútil ao orquestrador. Escreva o relatório e encerre.
+      Relatório oco, ou sem os 4 itens abaixo, é falha de protocolo.
    2. NÃO toque em tasks.json, feature.json, state.json nem no board de sessão
       (TaskCreate/TaskUpdate) — todo estado é gravado exclusivamente pelo
       orquestrador.
@@ -80,14 +71,14 @@ Ao iniciar cada task de `tasks.json` — antes de escrever qualquer código. Nor
       NÃO rode build/test da suíte compartilhada — a verificação
       (`morph-spec verify`) é do orquestrador, uma vez, pós-batch. Em batch
       COM `isolation: "worktree"`, rode build/test dentro do seu worktree,
-      commite na branch do worktree como penúltimo ato (antes do SendMessage)
+      commite na branch do worktree como último ato antes do relatório
       e reporte a branch — nunca faça merge.
 
-   Retorne no content do SendMessage APENAS: (1) o que foi feito em 2-3 frases,
+   Seu relatório final deve conter APENAS: (1) o que foi feito em 2-3 frases,
    (2) arquivos modificados, (3) problemas encontrados e como foram resolvidos,
    (4) auto-score 0-10.
    ```
-   Após receber o retorno: o auto-score é **triagem, não aprovação** — se < 7, re-despache com o feedback específico (ou corrija inline) antes de prosseguir. Em qualquer caso, a task só avança quando `morph-eval` der score ≥ 9 (barra única do MORPH.md §0). **Libere a sessão do sub-agent imediatamente após consumir o relatório** — chame `TaskStop(task_id: <id/nome retornado pelo dispatch>)`. Isso evita que o idle-detector do harness dispare minutos depois e injete um `idle_notification` como teammate-message vazio na sua sessão; trate falha do TaskStop (agente já finalizado sozinho) como não-fatal. Integre o relatório ao recap.md e vá para o passo 7.
+   Após receber o retorno: o auto-score é **triagem, não aprovação** — se < 7, re-despache com o feedback específico (ou corrija inline) antes de prosseguir. Em qualquer caso, a task só avança quando `morph-eval` der score ≥ 9 (barra única do MORPH.md §0). Integre o relatório ao recap.md e vá para o passo 7.
 
    **Se não — siga para o passo 5.**