@polymorphism-tech/morph-spec 7.9.1 → 7.9.3

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.9.1  
+**Version:** 7.9.3  
 **Requires:** Node.js 22+, Claude Code
 
 ---
@@ -29,7 +29,7 @@ It integrates natively with Claude Code: skills become slash commands, agents be
 Install the CLI globally:
 
 ```bash
-npm install -g @polymorphism-tech/morph-spec
+npm install -g @polymorphism-tech/morph-spec@latest --prefer-online
 ```
 
 Then initialize in your project:
@@ -340,7 +340,7 @@ Windows may block global npm installs without elevated permissions. Options:
 mkdir %APPDATA%\npm-global
 npm config set prefix %APPDATA%\npm-global
 :: Add %APPDATA%\npm-global to your PATH
-npm install -g @polymorphism-tech/morph-spec
+npm install -g @polymorphism-tech/morph-spec@latest --prefer-online
 ```
 
 1. Open a new terminal (the installer adds npm to your PATH automatically)
@@ -365,4 +365,4 @@ Code generated by morph-spec (contracts, templates, implementation output) belon
 
 ---
 
-*morph-spec v7.9.1 by [Polymorphism Tech](https://polymorphism.tech)*
+*morph-spec v7.9.3 by [Polymorphism Tech](https://polymorphism.tech)*

package/claude-plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "morph-spec",
-  "version": "7.9.1",
+  "version": "7.9.3",
   "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

@@ -3,7 +3,7 @@
 ## Setup
 
 ```bash
-npm install -g @polymorphism-tech/morph-spec   # install globally
+npm install -g @polymorphism-tech/morph-spec@latest --prefer-online   # install/upgrade globally
 morph-spec init                                 # initialize project
 morph-spec init --wizard                        # interactive wizard
 morph-spec init --force                         # overwrite existing
@@ -12,9 +12,9 @@ morph-spec doctor                               # health check
 morph-spec --version
 ```
 
-> `npm i -g ...@latest` deu `ETARGET` logo após uma release? O CDN do npm
-> leva alguns minutos para propagar o `latest` — instale com a versão
-> explícita (`npm i -g @polymorphism-tech/morph-spec@X.Y.Z`) ou aguarde.
+> `--prefer-online` faz parte do comando canônico: sem ele, o cache local do
+> npm segura o packument velho por ~5 min após uma release e o install falha
+> com `ETARGET` (o CDN do registry também leva alguns minutos para propagar).
 
 ---
 
@@ -200,4 +200,4 @@ These files are never edited directly. Use CLI commands or `morph-spec update` i
 
 ---
 
-*morph-spec v7.9.1 by Polymorphism Tech*
+*morph-spec v7.9.3 by Polymorphism Tech*

package/docs/QUICKSTART.md

@@ -3,7 +3,7 @@
 ## Install
 
 ```bash
-npm install -g @polymorphism-tech/morph-spec
+npm install -g @polymorphism-tech/morph-spec@latest --prefer-online
 ```
 
 > The installer automatically configures your PowerShell PATH on Windows. If `morph-spec` is not found, open a new terminal window.
@@ -162,8 +162,8 @@ morph-spec state list
 When a new version of `@polymorphism-tech/morph-spec` is published:
 
 ```bash
-# Update the CLI
-npm install -g @polymorphism-tech/morph-spec@latest
+# Update the CLI (--prefer-online bypasses the ~5 min local packument cache)
+npm install -g @polymorphism-tech/morph-spec@latest --prefer-online
 
 # Update framework files in your project
 morph-spec update
@@ -197,4 +197,4 @@ morph-spec doctor
 
 ---
 
-*morph-spec v7.9.1 by Polymorphism Tech*
+*morph-spec v7.9.3 by Polymorphism Tech*

package/framework/CLAUDE.md

@@ -25,7 +25,7 @@ Se não houver feature ativa, pergunte ao usuário qual feature trabalhar.
 - Apresentar gates com o template fixo definido em MORPH.md / morph-plan.
 - Registrar decisões não triviais em `decisions.md`.
 - Aplicar `morph-eval` após cada tarefa; silêncio em score ≥ 9 é o sinal correto. Score < 9 dispara o loop de correção autônomo (re-implementa, sem pausa), não escala ao humano entre tarefas. No Gate 3, o score composto da feature vem do **avaliador independente** despachado pela `morph-review` (persona `evaluator`, contexto fresco) — nunca de auto-avaliação de quem implementou.
-- Incluir as 3 cláusulas de protocolo em todo dispatch de sub-agent (**ato final = relatório via `SendMessage` para `main`** — última mensagem em texto não chega ao orquestrador; não tocar tasks.json/feature.json/board; sem build/test da suíte compartilhada em batch paralelo) — templates com exemplo literal em `morph-implement` §4 e `morph-apply` §3b. O hook `subagent-report-guard` bloqueia uma vez o encerramento de subagent despachado sem SendMessage.
+- Incluir as 3 cláusulas de protocolo em todo dispatch de sub-agent (**ato final = relatório via `SendMessage` para `main` como a ÚLTIMA tool call, encerrando imediatamente depois — zero texto extra, zero "aguardando confirmação"** — última mensagem em texto não chega ao orquestrador; não tocar tasks.json/feature.json/board; sem build/test da suíte compartilhada em batch paralelo) — templates com exemplo literal em `morph-implement` §4 e `morph-apply` §3b. O hook `subagent-report-guard` bloqueia uma vez o encerramento de subagent despachado sem SendMessage. **Ao consumir o relatório, libere a sessão do sub-agent com `TaskStop`** — não deixe o idle-detector do harness ser o único a encerrá-la.
 
 ## Slash commands
 

package/framework/MORPH.md

@@ -236,7 +236,7 @@ Inline (sem dispatch) é aceitável para tasks curtas (effort S/M) **dentro do d
 - Auto-score 0-10 com justificativa em uma linha
 
 **Protocolo obrigatório do sub-agent** (cláusulas que todo prompt de dispatch inclui — ver templates em `morph-implement` §4 e `morph-apply` §3b):
-1. **ATO FINAL: enviar o relatório completo via `SendMessage` para `main` antes de encerrar** — a última mensagem em texto NÃO chega ao orquestrador; só SendMessage chega. Terminar idle sem SendMessage é **falha de protocolo**: o hook `subagent-report-guard` bloqueia o encerramento uma vez com a instrução, e a cobrança do orquestrador via SendMessage é apenas o fallback (registrada como falha no recap). Os templates trazem o exemplo literal da chamada.
+1. **ATO FINAL: enviar o relatório completo via `SendMessage` para `main` como a ÚLTIMA tool call do turno, e encerrar IMEDIATAMENTE depois** — a última mensagem em texto NÃO chega ao orquestrador; só SendMessage chega. Zero texto adicional, zero nova tool call, zero "aguardando confirmação" depois do SendMessage: é o encerramento, não um passo intermediário. Terminar idle sem SendMessage, ou continuar agindo depois dele, é **falha de protocolo**: o hook `subagent-report-guard` bloqueia o encerramento uma vez com a instrução, e a cobrança do orquestrador via SendMessage é apenas o fallback (registrada como falha no recap). Os templates trazem o exemplo literal da chamada.
 2. Não tocar em `tasks.json`, `feature.json`, `state.json` nem no board de sessão (TaskCreate/TaskUpdate) — todo estado é gravado exclusivamente pelo orquestrador.
 3. Em batch paralelo, não rodar build/test da suíte compartilhada — a verificação é do orquestrador, uma vez, pós-batch (alternativa: dispatch com `isolation: "worktree"`, e aí o build roda dentro do worktree).
 
@@ -247,7 +247,7 @@ O sub-agent deve ser autossuficiente com o que você passou. Se precisar de mais
 - Quando o feedback do sub-agent precisaria ser discutido em tempo real — dispatch é assíncrono.
 - Quando a tarefa envolve mudanças de arquitetura que o Orchestrator precisa validar antes de executar.
 
-**Após receber o retorno do sub-agent:** leia o auto-score — ele é **triagem, não aprovação**. Se for < 7, re-despache com o feedback específico (ou corrija inline) antes de avaliar. Em qualquer caso, a task só avança quando `morph-eval` der score ≥ 9 (a barra única do §0); integre o resultado ao recap.md e siga para a próxima tarefa.
+**Após receber o retorno do sub-agent:** leia o auto-score — ele é **triagem, não aprovação**. Se for < 7, re-despache com o feedback específico (ou corrija inline) antes de avaliar. Em qualquer caso, a task só avança quando `morph-eval` der score ≥ 9 (a barra única do §0); integre o resultado ao recap.md e siga para a próxima tarefa. **Libere a sessão do sub-agent imediatamente ao consumir o relatório** — `TaskStop(task_id: <id/nome retornado pelo dispatch>)`, tratando falha (agente já finalizado sozinho) como não-fatal — não espere o idle-detector do harness fazer isso sozinho minutos depois.
 
 > **Anti-padrão a evitar:** implementar múltiplas tasks de domínios diferentes inline, em sequência, na thread principal — "eu já sei o padrão de cada uma". Isso é exatamente o sinal de que o sistema de delegação foi ignorado. Quando uma feature cruza ≥2 domínios, o caminho default é o Orchestrator despachando especialistas, não o Orchestrator virando faz-tudo.
 

package/framework/agents.json

@@ -19,7 +19,8 @@
         "architecture-vertical-slice-vertical-slice",
         "backend-dotnet-result-pattern",
         "backend-dotnet-vsa-handler-patterns",
-        "backend-dotnet-fluent-validation-vsa"
+        "backend-dotnet-fluent-validation-vsa",
+        "backend-integrations-neon-auth-neon-auth"
       ],
       "mcp": ["context7"],
       "persona": "Você é um engenheiro .NET sênior. Pensa em VSA com handlers diretos, result pattern, sealed classes, Guid.CreateVersion7(). Acesso a dados: ApplicationDbContext injetado direto no slice (DbSet<T> já é repository, DbContext já é unit of work); para concorrência ou SQL específico, store dedicado hand-written com justificativa em decisions.md; nunca uma camada de Service/Manager; nunca repository genérico (IRepository<T>/IUnitOfWork). Não usa exceptions como fluxo. Consulta o standard antes de escrever cada slice. Nomeia tudo em PascalCase para tipos, camelCase para parâmetros."
@@ -81,7 +82,8 @@
         "frontend-nextjs-components",
         "frontend-nextjs-data-fetching",
         "frontend-nextjs-naming-conventions",
-        "frontend-nextjs-state-management"
+        "frontend-nextjs-state-management",
+        "backend-integrations-neon-auth-neon-auth"
       ],
       "mcp": ["context7"],
       "persona": "Você escreve Next.js App Router idiomático. Server Components por padrão, Client Components apenas quando há interatividade real. Tailwind + Shadcn + Framer Motion. Tipos via Zod. Nada de getServerSideProps. RSC streaming quando faz sentido."

package/framework/evals/rubrics/architecture.md

@@ -2,6 +2,27 @@
 
 Avalia se a implementação segue o padrão arquitetural definido no spec.md e mandate.md.
 
+## Verificações mecânicas obrigatórias (auto-reprovação se falhar)
+
+Estas duas checagens são objetivas — não dependem de julgamento sobre estilo — e cobrem bugs reais que
+já derrubaram uma app em produção (ver `backend/integrations/neon-auth/neon-auth.md` → "Known Failure
+Modes"). Rode ambas sempre que o diff tocar endpoints minimal API ou fetch de dados cross-camada, mesmo
+que o mandate não as mencione explicitamente. Uma violação em qualquer uma delas é bloqueante — não
+"ressalva" — independente do resto do score de arquitetura.
+
+1. **DI de todo serviço injetado em endpoint.** Para cada parâmetro de tipo serviço em uma lambda de
+   endpoint minimal API (qualquer tipo que não seja `TRequest`, `CancellationToken`, `ClaimsPrincipal`
+   ou um primitivo de rota/query), confirme que existe `AddScoped<T>()` / `AddSingleton<T>()` /
+   `AddTransient<T>()` correspondente em `Program.cs` (ou registro via assembly-scanning). Um serviço
+   não registrado é inferido como `[FromBody]` pelo Minimal API e derruba a app inteira no startup —
+   isso é "Score 1-2", não "Score 5-6 com ressalva", porque não é estilo: é a aplicação não subir.
+2. **Nenhum prefixo de rota reusado para dois propósitos.** Se o projeto tem chamadas server-direct ao
+   backend E chamadas client-side via proxy same-origin, confirme que existem DUAS constantes
+   nomeadas distintas (uma por propósito) e que nenhuma delas aparece do lado errado (grep: arquivos de
+   Server Component só importam a constante server-direct; hooks/Client Component só importam a
+   constante de proxy). Uma única constante reusada para os dois quebra silenciosamente um dos dois
+   caminhos em runtime, sem sinal em build — também bloqueante.
+
 ## Score 9-10 — Exemplar
 
 - Segue o padrão de feature folder rigorosamente: cada feature tem seus próprios handlers, commands/queries, validators e endpoints.
@@ -36,6 +57,8 @@ Avalia se a implementação segue o padrão arquitetural definido no spec.md e m
 - Implementação plana sem estrutura de feature.
 - Dependências circulares ou acoplamento total entre camadas.
 - Requer refatoração antes de qualquer entrega.
+- Qualquer violação das "Verificações mecânicas obrigatórias" acima (DI faltando, prefixo de rota
+  reusado) — teto de score 2 independente de quão bem o resto segue o padrão.
 
 ## Perguntas de avaliação
 
@@ -44,3 +67,7 @@ Avalia se a implementação segue o padrão arquitetural definido no spec.md e m
 3. Objetos de domínio importam de infraestrutura (ORM, HTTP, I/O)?
 4. Se remover esta feature, alguma outra quebra?
 5. O padrão arquitetural descrito no spec.md foi seguido?
+6. Todo serviço injetado numa lambda de endpoint minimal API tem `AddScoped`/`AddSingleton`/
+   `AddTransient` correspondente em `Program.cs`?
+7. Se o diff tem chamada server-direct ao backend E chamada client-side via proxy para o mesmo
+   recurso, elas usam duas constantes de prefixo distintas — nenhuma reusada para o outro propósito?

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.9.1"
+cliVersion: "7.9.3"
 ---
 
 # 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: "7.9.1"
+cliVersion: "7.9.3"
 ---
 
 # 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: "7.9.1"
+cliVersion: "7.9.3"
 ---
 
 # morph-apply
@@ -122,15 +122,20 @@ dispatch Agent (subagent_type: "morph-{id}") with prompt:
     Não modifique spec.md, mandate.md.
 
     Protocolo obrigatório:
-    1. ATO FINAL OBRIGATÓRIO — relatório via SendMessage: antes de encerrar,
-       chame a tool SendMessage com to:"main" e o relatório completo no content.
-       Sua última mensagem em texto NÃO chega ao orquestrador — só SendMessage
-       chega. Não termine idle "aguardando"; o SendMessage É o encerramento.
-       Exemplo literal (última chamada de tool da sua sessão):
+    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 é falha de protocolo.
+       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.
     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.
@@ -149,7 +154,7 @@ dispatch Agent (subagent_type: "morph-{id}") with prompt:
 
 > **Alternativa quando os fluxos tocam os mesmos projetos/arquivos** (ex.: o mesmo csproj de testes compartilhado): despache com `isolation: "worktree"` — cada agente trabalha numa working tree própria e o orquestrador integra ao final. Nesse caso a cláusula 3 vira "rode build/test apenas dentro do seu worktree".
 
-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.** Depois, sequencialmente:
+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:
 - **Rodar a verificação compartilhada uma única vez** (build + suíte de testes do projeto) — os agentes não a rodaram (cláusula 3 do protocolo).
 - Para cada relatório retornado:
   - Aplicar `Skill(morph-eval)`.

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.9.1"
+cliVersion: "7.9.3"
 ---
 
 # 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.9.1"
+cliVersion: "7.9.3"
 ---
 
 # 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.9.1"
+cliVersion: "7.9.3"
 ---
 
 # morph-implement
@@ -59,15 +59,20 @@ Ao iniciar cada task de `tasks.json` — antes de escrever qualquer código. Nor
    Done quando: [doneCriteria do tasks.json]
 
    Protocolo obrigatório:
-   1. ATO FINAL OBRIGATÓRIO — relatório via SendMessage: antes de encerrar,
-      chame a tool SendMessage com to:"main" e o relatório completo no content.
-      Sua última mensagem em texto NÃO chega ao orquestrador — só SendMessage
-      chega. Não termine idle "aguardando"; o SendMessage É o encerramento.
-      Exemplo literal (última chamada de tool da sua sessão):
+   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 é falha de protocolo.
+      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.
    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.
@@ -78,7 +83,7 @@ Ao iniciar cada task de `tasks.json` — antes de escrever qualquer código. Nor
    (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). 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). **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.
 
    **Se não — siga para o passo 5.**
 

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.9.1"
+cliVersion: "7.9.3"
 ---
 
 # 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.9.1"
+cliVersion: "7.9.3"
 ---
 
 # 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.9.1"
+cliVersion: "7.9.3"
 ---
 
 # morph-review
@@ -33,6 +33,15 @@ e o `recap.md` estar atualizado. Normalmente invocada pela skill orquestradora `
    - Se não atendido: registre como "bloqueante" com descrição do gap.
    - Se parcialmente atendido: registre como "pendência" com o que falta.
 
+   **Verificações mecânicas sempre-rodar** (independente do mandate mencionar ou não — cobrem bugs
+   reais já vistos em produção, ver `framework/evals/rubrics/architecture.md` → "Verificações
+   mecânicas obrigatórias"), quando o diff tocar endpoints minimal API ou fetch cross-camada:
+   - Todo serviço injetado numa lambda de endpoint tem `AddScoped`/`AddSingleton`/`AddTransient`
+     correspondente em `Program.cs`. Falha aqui é bloqueante — a app não sobe.
+   - Se há chamada server-direct ao backend e chamada client-side via proxy para o mesmo recurso,
+     confirme que usam duas constantes de prefixo nomeadas distintas, nenhuma reusada para o
+     outro propósito. Falha aqui é bloqueante — quebra silenciosa em runtime, não em build.
+
 4. **Despache o avaliador independente** — o score do Gate 3 nunca é auto-atribuído por quem implementou:
    - Rode a suíte de testes do projeto e capture a **saída real** (não um resumo seu).
    - Gere o **diff da implementação** (`git diff` do range da feature, ou a lista de arquivos do recap.md com seus conteúdos atuais).
@@ -47,19 +56,22 @@ e o `recap.md` estar atualizado. Normalmente invocada pela skill orquestradora `
          seguindo as bandas 0-10 de cada uma.
          NÃO reescreva código. NÃO toque em tasks.json, feature.json nem no board
          de sessão.
-         Protocolo obrigatório — ATO FINAL: antes de encerrar, chame a tool
-         SendMessage com to:"main" e o relatório completo no content; sua última
-         mensagem em texto NÃO chega ao orquestrador — só SendMessage chega.
-         Exemplo literal (última chamada de tool da sua sessão):
+         Protocolo obrigatório — ATO FINAL: 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: zero texto
+         adicional, zero nova tool call, zero "aguardando confirmação".
+         Exemplo literal (última chamada de tool da sua sessão, sem nada depois):
          SendMessage({ to: "main", content: "Review de {feature}: arch=9.0
          contracts=9.5 quality=9.0 tests=8.5 → composto 9.05. Feedback: ..." })
-         Terminar idle sem SendMessage é falha de protocolo.
+         Terminar idle sem SendMessage, ou continuar agindo depois dele, é
+         falha de protocolo.
          Retorne no content: score 0-10 por dimensão, score composto (arch×0.30 +
          contracts×0.25 + quality×0.25 + tests×0.20), e feedback priorizado
          (bloqueantes primeiro) para qualquer dimensão < 9.
      ```
    - **Fallback (tipo não registrado):** se `morph-evaluator` não estiver na sua lista de subagent types, despache `general-purpose` colando o campo `persona` do agente `evaluator` (Read em `.morph/framework/agents.json`) no topo do prompt — e **registre o fallback no review-report** (seção de método).
-   - Os scores por dimensão e o composto do review-report vêm **desse retorno**, não da sua auto-avaliação. O hook `subagent-report-guard` bloqueia uma vez o encerramento do avaliador sem SendMessage; se mesmo assim ele ficar idle sem reportar, cobre via SendMessage antes de prosseguir (fallback).
+   - Os scores por dimensão e o composto do review-report vêm **desse retorno**, não da sua auto-avaliação. O hook `subagent-report-guard` bloqueia uma vez o encerramento do avaliador sem SendMessage; se mesmo assim ele ficar idle sem reportar, cobre via SendMessage antes de prosseguir (fallback). **Assim que o relatório chegar, libere a sessão do avaliador** — `TaskStop(task_id: <id/nome retornado pelo dispatch>)` — para não deixá-lo pendurado até o idle-detector do harness disparar um `idle_notification` de volta a esta sessão.
 
 5. Produza `review-report.md` em `.morph/features/{feature}/4-review/` com:
    - Scores por dimensão (arquitetura, contratos, qualidade, cobertura)

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.9.1"
+cliVersion: "7.9.3"
 ---
 
 # 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.9.1"
+cliVersion: "7.9.3"
 ---
 
 # morph-standards

package/framework/standards/STANDARDS.json

@@ -933,15 +933,26 @@
         "authentication",
         "OAuth",
         "JWT",
-        "session management"
+        "session management",
+        "trusted origins",
+        "EdDSA",
+        "Ed25519",
+        "BouncyCastle",
+        "signature validator",
+        "jwks",
+        "middleware runtime",
+        "api prefix"
       ],
       "anchors": {
         "setup": "#installation--setup",
+        "onboarding": "#onboarding-checklist--do-this-before-testing-login-mandatory",
         "middleware": "#route-protection-middleware",
+        "api-prefix": "#api-prefix-convention--server-direct-vs-client-proxy",
         "dotnet": "#net-backend-integration",
-        "rls": "#row-level-security-integration"
+        "rls": "#row-level-security-integration",
+        "postmortem": "#known-failure-modes-postmortem"
       },
-      "digest": "Use @neondatabase/auth SDK for Next.js. Auth data lives in neon_auth schema — no external provider, no webhooks. Server: createNeonAuth() with NEON_AUTH_BASE_URL + NEON_AUTH_COOKIE_SECRET. Client: createAuthClient(). Pages: AuthView component. Protection: auth.middleware(). .NET: JWT Bearer with Neon Auth authority, NameClaimType=sub. RLS: auth.user_id() via pg_session_jwt."
+      "digest": "Use @neondatabase/auth SDK for Next.js. Auth data lives in neon_auth schema — no external provider, no webhooks. Server: createNeonAuth() with NEON_AUTH_BASE_URL + NEON_AUTH_COOKIE_SECRET. Client: createAuthClient(). Pages: AuthView component. Protection: auth.middleware() with runtime='nodejs' (Edge times out minting the session cookie). Register every dev/preview origin in trusted_origins before testing login. Two named prefix constants (BACKEND_API_PREFIX / PROXY_API_PREFIX) — never share one between server-direct and client-proxy calls. .NET: tokens are EdDSA/Ed25519 (OKP) — Microsoft.IdentityModel.Tokens can't verify OKP keys and there's no OIDC discovery; fetch+cache the JWKS yourself and verify signatures manually via BouncyCastle.Cryptography + TokenValidationParameters.SignatureValidator (must return Microsoft.IdentityModel.JsonWebTokens.JsonWebToken, not JwtSecurityToken — else IDX10506). NeonAuth:BaseUrl is mandatory in appsettings.Development.json (public value). RLS: auth.user_id() via pg_session_jwt."
     },
     {
       "id": "backend-integrations-hangfire-hangfire-jobs",