@polymorphism-tech/morph-spec 7.9.3 → 7.9.4

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.3  
+**Version:** 7.9.4  
 **Requires:** Node.js 22+, Claude Code
 
 ---
@@ -365,4 +365,4 @@ Code generated by morph-spec (contracts, templates, implementation output) belon
 
 ---
 
-*morph-spec v7.9.3 by [Polymorphism Tech](https://polymorphism.tech)*
+*morph-spec v7.9.4 by [Polymorphism Tech](https://polymorphism.tech)*

package/claude-plugin.json

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

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

package/docs/QUICKSTART.md

@@ -197,4 +197,4 @@ morph-spec doctor
 
 ---
 
-*morph-spec v7.9.3 by Polymorphism Tech*
+*morph-spec v7.9.4 by Polymorphism Tech*

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.3"
+cliVersion: "7.9.4"
 ---
 
 # 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.3"
+cliVersion: "7.9.4"
 ---
 
 # 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.3"
+cliVersion: "7.9.4"
 ---
 
 # 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.9.3"
+cliVersion: "7.9.4"
 ---
 
 # 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.3"
+cliVersion: "7.9.4"
 ---
 
 # 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.3"
+cliVersion: "7.9.4"
 ---
 
 # 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.9.3"
+cliVersion: "7.9.4"
 ---
 
 # 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.3"
+cliVersion: "7.9.4"
 ---
 
 # 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.3"
+cliVersion: "7.9.4"
 ---
 
 # 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.9.3"
+cliVersion: "7.9.4"
 ---
 
 # 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.3"
+cliVersion: "7.9.4"
 ---
 
 # morph-standards

package/framework/standards/STANDARDS.json

@@ -941,10 +941,15 @@
         "signature validator",
         "jwks",
         "middleware runtime",
-        "api prefix"
+        "api prefix",
+        "data api",
+        "postgrest",
+        "bypass backend",
+        "direct database access"
       ],
       "anchors": {
         "setup": "#installation--setup",
+        "data-access-boundary": "#data-access-boundary--backend-first-by-default",
         "onboarding": "#onboarding-checklist--do-this-before-testing-login-mandatory",
         "middleware": "#route-protection-middleware",
         "api-prefix": "#api-prefix-convention--server-direct-vs-client-proxy",
@@ -952,7 +957,7 @@
         "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() 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."
+      "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. Frontend never queries Neon directly for business data by default — only its own auth/session SDK; a Data API bypass requires a decisions.md ADR. .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",

package/framework/standards/backend/integrations/neon-auth/neon-auth.md

@@ -2,7 +2,7 @@
 
 > **Scope:** universal
 > **Layer:** 2 (on keyword)
-> **Keywords:** neon auth, better auth, authentication, nextjs, user management, session, JWT, trusted origins, EdDSA, Ed25519, BouncyCastle, signature validator, jwks, middleware runtime, api prefix
+> **Keywords:** neon auth, better auth, authentication, nextjs, user management, session, JWT, trusted origins, EdDSA, Ed25519, BouncyCastle, signature validator, jwks, middleware runtime, api prefix, data api, postgrest, bypass backend, direct database access
 > **Load When:** neon auth or authentication keywords detected
 
 **Verified against:** Neon Auth — @neondatabase/auth + @neondatabase/auth-ui (Better Auth). Last-verified: 2026-07-13.
@@ -37,13 +37,42 @@ Neon Auth provides:
 1. **Database-First**: Auth data lives in `neon_auth` schema — no external service to sync
 2. **Branch Isolation**: Each Neon branch gets isolated users, sessions, and auth config
 3. **Server-First**: Use server-side auth checks with `auth.getSession()`
-4. **JWT for RLS**: Tokens contain `sub` (user ID), `email`, `role: "authenticated"` for database policies
+4. **JWT for RLS**: Tokens contain `sub` (user ID), `email`, `role: "authenticated"` for database
+   policies — used only inside the justified Data API exception path, not by default (see
+   [Data Access Boundary](#data-access-boundary--backend-first-by-default))
 5. **No OIDC discovery**: Neon Auth does **not** expose `/.well-known/openid-configuration` — only the
    raw `/.well-known/jwks.json`. Never assume `options.Authority` alone gives you working discovery on
    the .NET side (see [.NET Backend Integration](#net-backend-integration)).
 
 ---
 
+## Data Access Boundary — Backend-First by Default
+
+The Next.js frontend has exactly one inherent reason to talk to Neon directly: Neon Auth's own
+client SDK (`authClient`, `useSession`, `auth.getSession()`) — that's Better Auth's session/JWT
+mechanism, not a business-data call. Every read or write of application/business data goes through
+the .NET backend instead, either as a server-direct fetch or a client-via-proxy call (see
+[API Prefix Convention](#api-prefix-convention--server-direct-vs-client-proxy) for the mechanics).
+
+**Rule:** the frontend does not query Neon directly for business data — not via a Neon Data API
+(REST-over-Postgres) endpoint, not via a browser-held connection string, not via any other bypass
+of the .NET backend. The .NET backend is the sole gateway to business data, for the same reason
+`architecture/vertical-slice/vertical-slice.md` makes the backend the sole gateway to the database
+in general: handler-level authorization, no business rules duplicated on two sides of the wire, one
+place to audit.
+
+**The exception process:** a feature that genuinely needs the frontend to reach Neon directly for
+business data (for example, via the Neon MCP `provision_neon_data_api` tool) is an exception, not a
+default — treat it exactly like vertical-slice.md's "Stores dedicados (exceção justificada)" clause:
+document the justification in the feature's `decisions.md` before writing the code. A tool being
+available is not, by itself, justification.
+
+See [Row-Level Security Integration](#row-level-security-integration) for how to constrain a
+Data-API-exception session once one exists — those RLS policies are not a signal that the frontend
+should have direct access by default.
+
+---
+
 ## Installation & Setup
 
 ### Install Packages
@@ -299,6 +328,10 @@ export async function GET() {
 
 ## API Prefix Convention — Server-Direct vs Client-Proxy
 
+> Assumes the [Data Access Boundary](#data-access-boundary--backend-first-by-default) rule: all
+> business data routes through the backend by default. This section covers only the *mechanics* of
+> doing so from each render context.
+
 A Next.js app talking to a Neon-Auth-protected .NET backend fetches from **two different places**
 depending on where the code runs:
 
@@ -616,7 +649,13 @@ app.Run();
 
 ## Row-Level Security Integration
 
-Neon Auth JWT tokens are automatically validated by the Data API. The `auth.user_id()` function (via `pg_session_jwt` extension) exposes the authenticated user ID from the JWT `sub` claim.
+> Defense-in-depth on a JWT-scoped Postgres session — the Data API exception above, not a directive
+> to call Neon from the browser for business data by default. See
+> [Data Access Boundary](#data-access-boundary--backend-first-by-default).
+
+When a Data API endpoint is provisioned (the justified exception above), Neon Auth JWT tokens are
+automatically validated by it. The `auth.user_id()` function (via `pg_session_jwt` extension)
+exposes the authenticated user ID from the JWT `sub` claim to any RLS policy on that session.
 
 ```sql
 -- Enable RLS
@@ -673,6 +712,9 @@ Each Neon branch gets its own isolated auth data. This means:
    service silently becomes a phantom `[FromBody]` parameter and crashes the app at startup
 10. **On .NET, never rely on `options.Authority` alone** — Neon Auth has no OIDC discovery document;
     fetch and cache the JWKS yourself and verify EdDSA signatures manually (BouncyCastle)
+11. **Route business data through the .NET backend by default** — the frontend's only inherent
+    reason to talk to Neon directly is its own auth/session SDK; a direct Data API call needs a
+    `decisions.md` ADR (see [Data Access Boundary](#data-access-boundary--backend-first-by-default))
 
 ---
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@polymorphism-tech/morph-spec",
-  "version": "7.9.3",
+  "version": "7.9.4",
   "description": "MORPH-SPEC: NLH (Natural Language Harness) for spec-driven development with Claude Code",
   "keywords": [
     "claude-code",