@polymorphism-tech/morph-spec 7.5.0 → 7.6.0

package/README.md

@@ -3,7 +3,7 @@
 > Spec-driven development framework for multi-stack projects. Turns feature requests into implementation-ready code through structured, AI-orchestrated phases.
 
 **Package:** `@polymorphism-tech/morph-spec`
-**Version:** 7.5.0  
+**Version:** 7.6.0  
 **Requires:** Node.js 22+, Claude Code
 
 ---
@@ -365,4 +365,4 @@ Code generated by morph-spec (contracts, templates, implementation output) belon
 
 ---
 
-*morph-spec v7.5.0 by [Polymorphism Tech](https://polymorphism.tech)*
+*morph-spec v7.6.0 by [Polymorphism Tech](https://polymorphism.tech)*

package/claude-plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "morph-spec",
-  "version": "7.5.0",
+  "version": "7.6.0",
   "displayName": "MORPH-SPEC Framework",
   "description": "Spec-driven development with 38 agents and 8-phase workflow for .NET/Blazor/Next.js/Azure",
   "publisher": "polymorphism-tech",

package/docs/CHEATSHEET.md

@@ -196,4 +196,4 @@ These files are never edited directly. Use CLI commands or `morph-spec update` i
 
 ---
 
-*morph-spec v7.5.0 by Polymorphism Tech*
+*morph-spec v7.6.0 by Polymorphism Tech*

package/docs/QUICKSTART.md

@@ -197,4 +197,4 @@ morph-spec doctor
 
 ---
 
-*morph-spec v7.5.0 by Polymorphism Tech*
+*morph-spec v7.6.0 by Polymorphism Tech*

package/framework/agents.json

@@ -111,7 +111,7 @@
       "stack": ["dotnet"],
       "standards": [
         "backend-integrations-hangfire-hangfire-jobs",
-        "infrastructure-docker-easypanel-deploy",
+        "infrastructure-docker-coolify-deploy",
         "backend-dotnet-scrutor"
       ],
       "persona": "Você cuida de infra: jobs assíncronos com Hangfire (apenas quando há razão real), deployment, observabilidade. Pensa em retry, idempotência, dead-letter, métricas. Não inventa infra — usa o que o stack já oferece."

package/framework/commands/morph-preflight.md

@@ -1,12 +1,12 @@
 ---
-description: Validate project readiness before deploy — checks specs, contracts, tests, Docker, Neon/PostgreSQL, and EasyPanel configuration
+description: Validate project readiness before deploy — checks specs, contracts, tests, Docker, Neon/PostgreSQL, and Coolify configuration
 argument-hint: [feature-name]
 allowed-tools: Read, Bash, Glob, Grep
 ---
 
 # Pre-Flight Check for Deployment
 
-Validates project readiness before deploying to Docker/EasyPanel + Neon/PostgreSQL.
+Validates project readiness before deploying to Docker/Coolify + Neon/PostgreSQL.
 
 ## Usage
 
@@ -153,10 +153,10 @@ test -f .env.example && echo "OK" || echo "MISSING .env.example"
 
 ---
 
-### 6. EasyPanel Configuration
+### 6. Coolify Configuration
 
 **What it checks:**
-- Services correctly defined for EasyPanel
+- Application correctly defined in Coolify (source repo, Dockerfile path, port)
 - Health check endpoints exist (`/health` or `/healthz`)
 - Port mappings match Dockerfile EXPOSE
 
@@ -164,8 +164,13 @@ test -f .env.example && echo "OK" || echo "MISSING .env.example"
 ```bash
 # Verify health endpoint exists in code
 grep -rn "MapGet.*health" src/ --include="*.cs"
+
+# Verify Coolify config placeholders were filled in (local file only)
+grep -E "REPLACE_WITH_" coolify.json 2>/dev/null && echo "✗ coolify.json still has unfilled placeholders" || echo "✓ coolify.json configured"
 ```
 
+> Coolify has no MCP/CLI — its API is only reachable via SSH into the VPS. `morph-preflight` never does this itself; it only checks the project's local files. Live verification against the running instance is a manual step for whoever holds VPS access.
+
 ---
 
 ## Example Output
@@ -178,7 +183,7 @@ MORPH Pre-Flight Check: Deployment
   Dockerfile: Valid multi-stage build (API + Web)
   Docker Compose: Valid configuration
   Secrets: No hardcoded credentials found
-  EasyPanel: Health endpoint found at /healthz
+  Coolify: Health endpoint found at /healthz
 
 Summary: 6 passed, 0 failed, 0 warnings
 

package/framework/rules/infrastructure-standards.md

@@ -3,14 +3,14 @@ paths:
   - "**/Dockerfile*"
   - "**/docker-compose*"
   - "**/.github/**"
-  - "**/easypanel*"
+  - "**/coolify*"
 stacks:
   - docker
 ---
 
 # Infrastructure Standards
 
-@.morph/framework/standards/infrastructure/docker/easypanel-deploy.md
+@.morph/framework/standards/infrastructure/docker/coolify-deploy.md
 
 ## Infrastructure Templates
 
@@ -19,9 +19,9 @@ stacks:
 | .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 |
-| EasyPanel Config | `.morph/framework/templates/infrastructure/docker/easypanel.template.json` | Deployment config |
+| 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 EasyPanel | `.morph/framework/templates/infrastructure/github/workflows/deploy-easypanel.yml.hbs` | CD webhook |
+| 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/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: "7.5.0"
+cliVersion: "7.6.0"
 ---
 
 # create-umbraco-lp
@@ -82,17 +82,31 @@ UMBRACO_ADMIN_PASSWORD=<gerada>
 UMBRACO_GLOBAL_ID=<uuid-gerado>
 ALLOWED_ORIGINS=http://localhost:3000
 REVALIDATE_SECRET=<gerado>
+FRONTEND_URL=http://localhost:3000
 LEADS_INTEGRATION=<integração-escolhida>
 ```
 
+`FRONTEND_URL` (junto com `REVALIDATE_SECRET`) alimenta o `RevalidateOnPublishHandler` do
+backend: a cada publish no Umbraco, ele chama `/api/revalidate` do frontend sozinho, em
+código — não depende de configurar nada em Settings > Webhooks no backoffice. **Em
+produção, atualize `FRONTEND_URL` para o domínio público real do frontend.**
+
 E gera `backend/appsettings.Development.json` com o bloco Unattended install do Umbraco (usando o email/senha computados pelo script). Isso significa que um projeto recém-scaffoldado **auto-instala no `dotnet run`** — sem necessidade de rodar o instalador UI manualmente.
 
 E escreve `frontend/.env.local` com:
 ```
 NEXT_PUBLIC_UMBRACO_URL=https://localhost:44324
+NEXT_PUBLIC_SITE_URL=http://localhost:3000
 REVALIDATE_SECRET=<mesmo-secret>
 ```
 
+`NEXT_PUBLIC_SITE_URL` é usada por `robots.ts`/`sitemap.ts`. **Em produção, precisa ser
+setada como Build Variable no Coolify** — o `Dockerfile` do template
+declara `ARG NEXT_PUBLIC_SITE_URL` (e `ARG NEXT_PUBLIC_UMBRACO_URL`) justamente para isso;
+sem marcar como Build Variable, a env var não chega ao `next build` e o `robots.txt`/
+`sitemap.xml` publicam o domínio placeholder do template (`minha-landing-page.com.br`) em
+produção — já aconteceu num projeto real.
+
 > **Nota de overwrite:** se `.env` já existe, `new-lp.ps1` prompta (Read-Host) para sobrescrever — portanto, uma execução não-interativa em um diretório que já tem `.env` vai bloquear na prompt. Execute em um scaffold fresco, ou responda à prompt interativamente.
 
 > **Nota importante:** `ALLOWED_ORIGINS` é gravado com `http://localhost:3000` pelo script independentemente do que foi informado no passo 1. Se o usuário especificou um domínio de produção, a forma de aplicá-lo depende do modo de execução:
@@ -229,9 +243,15 @@ Antes de fazer deploy ou entregar o projeto ao cliente:
 - [ ] Delivery API responde com o node `lpHome` populado: `/umbraco/delivery/api/v2/content?contentType=lpHome&take=1`.
 - [ ] `.env` contém `ALLOWED_ORIGINS` com o domínio de produção correto (separado por vírgula se múltiplos).
 - [ ] `UMBRACO_GLOBAL_ID` é único para este projeto (gerado pelo script — não reutilizar de outro projeto).
-- [ ] SEO: preencher título, descrição e OG image no backoffice (campos do node `lpHome`).
+- [ ] SEO: preencher no backoffice, aba SEO do node `lpHome` — Page Title, Meta Title, Meta Description, **Social Image** (1200x630, sem ela não há `og:image` e o link não gera preview no WhatsApp/redes), Canonical Url (só a URL, sem tag HTML).
+- [ ] Favicon: preencher o campo **Favicon** no backoffice (aba Configuration) — `app/icon.tsx`/`apple-icon.tsx` já leem esse campo dinamicamente; sem ele, cai no favicon estático genérico do template.
+- [ ] `NEXT_PUBLIC_SITE_URL` **e** `NEXT_PUBLIC_UMBRACO_URL` setadas como **Build Variable** no provedor (não só runtime) — conferir `robots.txt`/`sitemap.xml` em produção com o domínio real após o primeiro deploy.
+- [ ] `FRONTEND_URL` + `REVALIDATE_SECRET` setadas no backend em produção (revalidação automática pós-publish via `RevalidateOnPublishHandler`) — testar: publicar algo no backoffice e conferir no log do backend a linha `RevalidateOnPublish: cache do frontend invalidado após publish.`
+- [ ] No Index: confirmar que está **desligado** no backoffice antes de ir pra produção (o campo é opt-in pra esconder do Google, não deveria vir ligado por padrão).
 - [ ] Variáveis sensíveis (`UMBRACO_ADMIN_PASSWORD`, `REVALIDATE_SECRET`, tokens de integração) não estão commitadas no repositório (`.env` deve estar no `.gitignore`).
 - [ ] Em produção com Docker Compose: `docker-compose up --build` e confirmar que backend e frontend sobem com as variáveis do `.env`.
+- [ ] `browserslist` presente em `frontend/package.json` — já vem do template; só confirmar que não foi removido/sobrescrito durante a customização.
+- [ ] Se o cliente vai subir fotos de câmera/celular pelo Media Picker (galeria, hero, etc.): confirmar que `ResizeLargeMediaUploadsHandler` está registrado em `backend/Program.cs` (já vem do template) — sem ele, upload cru de 10+ MB pode virar 500 intermitente sob concorrência no otimizador do Next. Setar `MEDIA_BACKFILL_SECRET` em produção se for preciso reprocessar mídia já publicada (ver seção "Mídia" do README do template).
 
 > **Nota Docker — `LEADS_INTEGRATION` e `SEED_DEMO_CONTENT`:** o `docker-compose.yml` **não** injeta essas duas variáveis no container do backend. Mesmo que estejam no `.env`, o seed sempre inicializa `leadIntegration` como `"none"` no boot Docker. Isso é esperado: o editor deve configurar a integração manualmente no backoffice após o primeiro boot. Se precisar seeding automático da integração via Docker, adicione a variável na seção `environment` do serviço `backend` em `docker-compose.yml` manualmente.
 

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: "7.5.0"
+cliVersion: "7.6.0"
 ---
 
 # migrate-lp-to-umbraco
@@ -100,6 +100,16 @@ O objetivo desta etapa não é "entender" a LP, é **capturar tudo o que é nece
 - Registrar o `sha256` de cada asset (vira a base da paridade de checksum no passo 6).
 - **Não reencodar nem otimizar** nenhum asset — qualquer reencode quebra a paridade.
 
+**SEO/GEO da origem — capturar para semear, não perder no lift:** a paridade visual não
+cobre isso sozinha — um lift perfeito que esquece o SEO da origem entrega uma LP idêntica
+visualmente mas invisível pra buscadores/IA no dia 1. Capturar da origem:
+- `<title>`, `<meta name="description">`, `<link rel="canonical">`.
+- Open Graph: `og:title`, `og:description`, `og:image` (baixar a imagem, idealmente 1200x630).
+- JSON-LD (`<script type="application/ld+json">`) — schema completo, se existir.
+- Favicon (todos os tamanhos/formatos disponíveis) e `apple-touch-icon`.
+- `robots.txt` e `sitemap.xml` da origem — confirmar se há regras além do default (bots de IA bloqueados? outras URLs?).
+- `llms.txt` da origem, se existir.
+
 **Formulário de captação** — campos presentes, validação no frontend, endpoint atual, integração de CRM/leads.
 
 **Origem apenas por URL (fallback):** se não houver código-fonte, scrapear o HTML renderizado, extrair o CSS computado dos elementos e baixar todos os assets referenciados (incluindo fontes). O lift parte do markup renderizado + CSS computado.
@@ -268,7 +278,22 @@ sectionNode.SetValue("videoFundo", mediaJson);
 
 Coloque os assets de seed em `backend/seed-assets/` (imagens, vídeos, ícones da LP de origem).
 
-**O que vai no SeedContentHandler:** textos de inauguração, mídia local (arquivos em `seed-assets/`), ordem das seções, configuração inicial. O conteúdo fica editável no backoffice após o primeiro boot — o seed é apenas o estado inicial.
+**Semear também o SEO/GEO capturado no passo 1** — não deixar em branco pra "o editor preencher depois" (isso já causou um site indo pro ar sem `og:image`, com favicon genérico e apontando pro domínio errado no sitemap num projeto real):
+
+```csharp
+content.SetValue("pageTitleSeo", "<título da origem>");
+content.SetValue("titleSeo", "<og:title da origem>");
+content.SetValue("descriptionSeo", "<meta description da origem>");
+content.SetValue("canonicalUrlSeo", "<URL canônica de produção>"); // só a URL, sem tag HTML
+content.SetValue("noIndexSeo", false); // é Mandatory=false a partir do fix de 2026-07-02 — não deixar true
+content.SetValue("jsonLDSchemaSeo", OrigemJsonLd); // JSON-LD capturado da origem, se existir
+// imageSeo (og:image) e favicon: importar como media (mesmo padrão de CreateOrGetMedia)
+// e setar via MediaPicker3, igual ao padrão de mídia acima.
+```
+
+`imageSeo` (1200x630) e `favicon` alimentam `app/icon.tsx`/`apple-icon.tsx` e o `<meta property="og:image">` automaticamente — não precisam de nenhum código extra no frontend, só o seed correto.
+
+**O que vai no SeedContentHandler:** textos de inauguração, mídia local (arquivos em `seed-assets/`), ordem das seções, configuração inicial, **e o SEO/GEO capturado no passo 1**. O conteúdo fica editável no backoffice após o primeiro boot — o seed é apenas o estado inicial.
 
 **O que NÃO vai no SeedContentHandler:** tokens de integração (GHL API Key, webhook URL). Esses ficam no nó `leadsConfig` que o operador preenche diretamente no backoffice após o boot (ver passo 5).
 
@@ -298,12 +323,58 @@ Copiar as variáveis de design da origem para `frontend/src/app/globals.css` no
 }
 ```
 
-Atualizar os `<link>` de Google Fonts em `frontend/src/app/layout.tsx` para carregar as fontes corretas.
+**Fontes — auto-hospedar, nunca `<link>` externo pro Google Fonts:** um `<link rel="stylesheet"
+href="https://fonts.googleapis.com/css2?...">` no `<head>` é render-blocking (round-trip
+externo antes de qualquer paint) e, combinado com `font-display: swap`, causa CLS quando a
+fonte troca depois do primeiro paint — foi 1.680ms de render-blocking estimado e 0.221 de CLS
+medidos num caso real (Barone_LP). **Não usar `next/font/google`** aqui (diferente do passo 4
+de `create-umbraco-lp`, que pode usar): o nome de família que ele gera é escopado/diferente do
+literal da origem, e o gate de paridade (passo 6b.2) compara `font-family` computado
+byte-a-byte contra a origem — `next/font` quebra esse check.
+
+O fix correto, que preserva a paridade:
+1. Buscar a CSS real do Google pra descobrir as URLs `.woff2` (`curl` na mesma URL que iria no
+   `<link>`) — geralmente **um arquivo por família+estilo já cobre todos os pesos estáticos**
+   usados (Google costuma reaproveitar o mesmo arquivo pra weight 400/500/600/700 de uma fonte
+   não-variável). Baixar só o subset `latin` (`unicode-range: U+0000-00FF, ...`) — cobre toda
+   acentuação do português (á, ã, ç, é... estão em U+00C0-00FF).
+2. Salvar os `.woff2` em `frontend/public/fonts/`.
+3. Declarar `@font-face` em `globals.css` (ou no arquivo de tema) com o **mesmo `font-family`
+   literal da origem** (`'Cormorant'`, `'Jost'`, etc. — não o nome gerado por uma lib) e
+   `font-display: optional` (não `swap`) — `optional` só troca pro custom font se ele chegar
+   quase instantaneamente; senão fica no fallback pra aquela visita, evitando o reflow visível
+   que gerou o CLS.
+4. `<link rel="preload" href="/fonts/arquivo.woff2" as="font" type="font/woff2" crossOrigin="anonymous">`
+   no `<head>` do `layout.tsx`, sem nenhum `<link>` pro domínio do Google.
+
+Verificar ao final: `getComputedStyle(el).fontFamily` no elemento de heading do hero deve
+retornar **a mesma string literal que a origem** (ex.: `"Cormorant, Georgia, serif"`) — só a
+origem do arquivo mudou (de `fonts.gstatic.com` pra same-origin), não o nome da família.
 
 #### 4d. Componentes frontend dos módulos novos
 
 Para cada módulo novo, criar o componente em `frontend/src/components/modules/NomeSection.tsx` **a partir do componente da origem copiado verbatim** — colar o JSX/markup/classes/CSS da origem e trocar só os literais de conteúdo por `data.*`:
 
+> **Exceção deliberada ao verbatim — imagens de mídia do Umbraco:** o componente `Picture`
+> lifted da origem provavelmente emite um `<img>` cru. Pra qualquer `src` que vier do Media
+> Picker (URL do backend, editável no backoffice — diferente de um asset estático em
+> `/public`), usar `next/image` (`fill`, com o container já dimensionado) desde o primeiro
+> lift, não um `<img>` cru. Isso **não** quebra o gate de paridade (passo 6b.3 só faz checksum
+> de assets em `/public`, nunca de URLs de mídia) — pelo contrário, sem isso qualquer foto que
+> o cliente trocar depois no backoffice chega crua (fotos de câmera/celular fácil 10+ MB) e
+> vira lento ou 500 sob concorrência (ver seção "Mídia" no README do template).
+>
+> **Pitfall a checar nesse lift:** `next/image fill` aplica `position/height/width` **inline**
+> no `<img>` renderizado — isso vence qualquer regra de classe (`.minha-grade img { height:
+> 116%; margin-top: -8% }`, por exemplo) que a origem use pra efeitos de oversize/parallax/zoom
+> em cima de um `<img>` cru, mesmo que a regra continue no CSS lifted verbatim. Se a origem tem
+> algum truque desses (imagem deliberadamente maior que o container + margin negativo, comum
+> em seções com parallax scroll-scrub), a troca pra `fill` abre um vão visível onde a "sobra"
+> da imagem deveria estar. Fix: `!important` na propriedade de classe que está sendo vencida
+> (normalmente só `height`) — é uma das poucas justificativas legítimas pra `!important`, já
+> que é o único jeito de vencer um inline style que você não controla diretamente. Checar isso
+> na hora do lift, não esperar aparecer como bug visual depois.
+
 ```tsx
 // Padrão: componente com 'use client', recebe { data: SectionProps },
 // faz cast para o tipo tipado, e lê props via data.property.
@@ -365,6 +436,12 @@ Objetivo: **provar** que a LP migrada é idêntica à origem. Com o lift verbati
 
 **Hierarquia do gate:** os checks **determinísticos** (6b) são o **bloqueio**. O **screenshot diff** (6c) é **corroboração secundária** — nunca o bloqueio único, porque font hinting/antialiasing diferem entre ambientes mesmo com CSS byte-idêntico.
 
+> Os dois pontos do passo 4c (fontes auto-hospedadas) e 4d (`next/image fill` pra mídia do
+> Umbraco) não são drift de paridade — são a paridade **certa** pedindo um detalhe extra de
+> implementação. O checksum de assets (6b.3) só cobre `/public`; o estilo computado (6b.2)
+> continua batendo porque `font-family` fica literal. Nenhum dos dois deveria fazer o gate
+> falhar quando bem aplicados.
+
 #### 6a. Boot + checklist manual (sanidade)
 
 ```bash
@@ -403,7 +480,9 @@ A migração é "exata" quando **todos** são verdade:
 - **6c screenshot diff** abaixo da tolerância em todos os breakpoints (mobile/tablet/desktop).
 - Todas as seções renderizam com conteúdo real (não placeholders) e na ordem da origem.
 - Formulário envia lead com sucesso para a integração configurada (testar com dado real em staging; `--demo-seed` popula a home com módulos de demonstração via `SEED_DEMO_CONTENT=true`, não envia lead de teste).
-- Backoffice: editar um campo de texto, publicar — a mudança reflete na página (revalidação por tag ou ISR) **sem** alterar o markup/estilo renderizado.
+- Backoffice: editar um campo de texto, publicar — a mudança reflete na página **em produção, sem precisar de deploy manual** (o `RevalidateOnPublishHandler` do backend chama `/api/revalidate` sozinho; só funciona com `FRONTEND_URL`/`REVALIDATE_SECRET` setados) e **sem** alterar o markup/estilo renderizado.
+- SEO/GEO da origem migrado, não perdido: `curl` a home de produção e conferir `<title>`, `<meta description>`, `og:image`, canonical e JSON-LD batendo com o que foi capturado no passo 1 — e que o favicon do browser não é o ícone genérico do template.
+- `robots.txt`/`sitemap.xml` de produção apontam pro domínio real (não o placeholder `minha-landing-page.com.br` do template) — só acontece se `NEXT_PUBLIC_SITE_URL` foi setada como Build Variable no provedor.
 - Nenhuma chave de API ou token aparece em arquivo versionado.
 
 ## Anti-padrões
@@ -415,7 +494,7 @@ A migração é "exata" quando **todos** são verdade:
 - Não saltear o smoke-boot (passo 3) — problemas de ambiente devem ser detectados antes de portar conteúdo.
 - Não reutilizar `customHtmlSection` para tudo — módulos dedicados permitem edição granular no backoffice e ISR por tag.
 - **Não reinterpretar layout/CSS nem "limpar" o markup** — portar verbatim; o módulo Umbraco só embrulha o mesmo markup da origem. Rebuild = drift.
-- **Não reencodar nem otimizar assets** na migração — quebra a paridade de checksum (6b) e altera o render.
+- **Não reencodar nem otimizar assets da origem** (o que vai pra `/public`/`seed-assets`) na migração — quebra a paridade de checksum (6b) e altera o render. Isso **não** se aplica a imagens que vêm do Media Picker do Umbraco (ver passo 4d) — essas não são asset da origem, não entram no checksum, e otimizá-las via `next/image` é o comportamento correto, não uma violação de paridade.
 - **Não assumir o tema do template** — portar o Tailwind/`@theme` (e as fontes) da origem; a mesma classe utilitária renderiza diferente entre versões/temas.
 - **Não tratar o screenshot diff como gate único** — o bloqueio são os checks determinísticos (6b); o diff visual é secundário.
 

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: "7.5.0"
+cliVersion: "7.6.0"
 ---
 
 # morph-apply

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: "7.5.0"
+cliVersion: "7.6.0"
 ---
 
 # 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: "7.5.0"
+cliVersion: "7.6.0"
 ---
 
 # morph-eval

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: "7.5.0"
+cliVersion: "7.6.0"
 ---
 
 # morph-implement

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

@@ -4,7 +4,7 @@ description: Guia a produção dos três artefatos de planejamento de uma featur
 version: core
 when-to-invoke: ao iniciar a fase plan de uma feature, após o Gate 1 (proposal aprovado)
 user-invokable: true
-cliVersion: "7.5.0"
+cliVersion: "7.6.0"
 ---
 
 # morph-plan

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

@@ -4,7 +4,7 @@ description: Orquestra a fase de proposta+plano de uma feature morph-spec. Encad
 version: core
 when-to-invoke: ao receber instrução "use /morph-proposal" do usuário, ou ao iniciar uma nova feature
 user-invokable: true
-cliVersion: "7.5.0"
+cliVersion: "7.6.0"
 ---
 
 # morph-proposal

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

@@ -4,7 +4,7 @@ description: Conduz a fase de revisão e produz o review-report.md para o Gate 3
 version: core
 when-to-invoke: ao iniciar a fase review, após todas as tasks de tasks.json estarem com status `done`
 user-invokable: true
-cliVersion: "7.5.0"
+cliVersion: "7.6.0"
 ---
 
 # morph-review

package/framework/skills/core/morph-stack-scan/SKILL.md

@@ -4,7 +4,7 @@ description: Varre o codebase existente, detecta stack atual, compara com o stac
 version: core
 when-to-invoke: ao iniciar uma feature em projeto brownfield (codebase já existente)
 user-invokable: true
-cliVersion: "7.5.0"
+cliVersion: "7.6.0"
 ---
 
 # morph-stack-scan

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

@@ -4,7 +4,7 @@ description: Localiza e carrega um standard específico do STANDARDS.json sob de
 version: core
 when-to-invoke: quando precisar consultar um standard específico durante a implementação
 user-invokable: true
-cliVersion: "7.5.0"
+cliVersion: "7.6.0"
 ---
 
 # morph-standards

package/framework/standards/STANDARDS.json

@@ -1495,9 +1495,9 @@
       "digest": "Vitest for unit tests, React Testing Library for component tests. Mock next/navigation with vi.mock. Test Server Actions with direct function calls. Use MSW for API mocking in component tests. Playwright for E2E tests against running app. Never test implementation details — test user behavior and output."
     },
     {
-      "id": "infrastructure-docker-easypanel-deploy",
-      "name": "easypanel deploy",
-      "path": "infrastructure/docker/easypanel-deploy.md",
+      "id": "infrastructure-docker-coolify-deploy",
+      "name": "coolify deploy",
+      "path": "infrastructure/docker/coolify-deploy.md",
       "category": "infrastructure",
       "subcategory": "docker",
       "tags": [
@@ -1508,17 +1508,20 @@
         "docker"
       ],
       "aliases": [
-        "easypanel",
+        "coolify",
         "docker deploy",
         "self-hosted",
         "VPS deployment",
-        "docker compose"
+        "docker compose",
+        "coolify api",
+        "ssh deploy"
       ],
       "anchors": {
-        "setup": "#easypanel-service-config",
-        "deployment": "#zero-downtime-deploys"
+        "setup": "#coolify-service-config",
+        "deployment": "#zero-downtime-deploys",
+        "ssh": "#triggering-a-deploy-via-ssh--api"
       },
-      "digest": "Create app in EasyPanel from container registry image. Configure environment variables in EasyPanel UI — not in Dockerfile. Use EasyPanel's managed Postgres/Redis for databases. Configure /health endpoint for health checks. Enable HTTPS via Let's Encrypt automatically. Use EasyPanel volumes for persistent storage."
+      "digest": "Coolify is the self-hosted Docker PaaS. No MCP/CLI exists — all access is via SSH into the VPS, hitting the Coolify API at localhost:8000/api/v1 with a server-side token (never printed, never leaves the SSH session). Configure environment variables in Coolify UI/API — not in Dockerfile. Configure /health endpoint for health checks. HTTPS via Let's Encrypt automatic (Traefik). Redeploys trigger via GET /deploy?uuid={uuid} over SSH."
     },
     {
       "id": "infrastructure-neon-setup",
@@ -1657,6 +1660,75 @@
         "edit-workflows": "#iterative-editing-workflows"
       },
       "digest": "Guidelines for generating project images with Gemini Image MCP — prompt patterns, aspect ratios, design-system-aware prompts, iterative editing, and assets.md format."
+    },
+    {
+      "id": "ai-agents-durable-workflows-hitl",
+      "name": "durable workflows hitl",
+      "path": "ai-agents/durable-workflows-hitl.md",
+      "category": "ai-agents",
+      "subcategory": null,
+      "tags": [
+        "ai-agents",
+        "maf",
+        "workflow",
+        "durability"
+      ],
+      "stacks": [
+        "dotnet"
+      ],
+      "aliases": [
+        "durable workflow",
+        "checkpoint",
+        "checkpointing",
+        "human in the loop",
+        "hitl",
+        "requestport",
+        "requestinfoevent",
+        "resume workflow",
+        "long running workflow",
+        "approval workflow",
+        "icheckpointstore"
+      ],
+      "anchors": {
+        "when": "#quando-usar-este-standard",
+        "hitl": "#human-in-the-loop-via-requestport",
+        "checkpointing": "#checkpointing--durável-sem-depender-de-azure",
+        "durable-task": "#azure-durable-task-extension--escape-hatch-not-default"
+      },
+      "digest": "HITL via RequestPort — a workflow node that pauses and waits for an external (human) response via RequestInfoEvent. Checkpointing is GA and Azure-free: CheckpointManager.CreateInMemory() for tests, CreateJson(FileSystemJsonCheckpointStore) for local-disk durability, or a custom ICheckpointStore (recommended against the project's own Postgres). Microsoft.Agents.AI.DurableTask (Azure Durable Task Scheduler) is documented as an escape hatch only, not adopted as default."
+    },
+    {
+      "id": "ai-agents-vector-data-extensions",
+      "name": "vector data extensions",
+      "path": "ai-agents/vector-data-extensions.md",
+      "category": "ai-agents",
+      "subcategory": null,
+      "tags": [
+        "ai-agents",
+        "maf",
+        "rag",
+        "vector-data"
+      ],
+      "stacks": [
+        "dotnet"
+      ],
+      "aliases": [
+        "microsoft extensions vectordata",
+        "vectorstorecollection",
+        "vector store abstraction",
+        "data ingestion",
+        "ingestion pipeline",
+        "semantic kernel connectors exception",
+        "pgvector connector",
+        "vectorstorewriter"
+      ],
+      "anchors": {
+        "naming-trap": "#a-pegadinha-de-nomenclatura-crítico--leia-antes-de-tudo",
+        "maturity": "#maturidade-atual-verificado-2026-07-06",
+        "decision-matrix": "#decision-matrix--custom-pgvector-vs-vectordata",
+        "data-ingestion": "#microsoftextensionsdataingestion-preview--pipeline-pattern-para-adoção-futura"
+      },
+      "digest": "Microsoft.Extensions.VectorData.Abstractions (GA) is the provider-agnostic vector-store abstraction; Microsoft.Extensions.DataIngestion (preview) is the companion ETL pipeline. Concrete connectors (Postgres, Qdrant, SQL Server...) ship under Microsoft.SemanticKernel.Connectors.* package names despite having nothing to do with Semantic Kernel — an explicit exception to ai-agents-setup's SK ban. Default RAG storage stays ai-agents-rag-custom-pgvector; adopt VectorData only for genuine multi-backend portability, since the Postgres connector is still prerelease."
     }
   ],
   "sharedAliases": {