@polymorphism-tech/morph-spec 9.0.0 → 9.2.0

package/framework/standards/backend/dotnet/testing.md

@@ -115,8 +115,12 @@ respectively and the test suite stays green.
 
 ## Test budget
 
-The plan (`morph-plan`) gives each task a budget: **one test per postcondition, plus one
-regression test per bug fixed**. Going above it takes a one-line justification in the task.
+Tests are paid for by **risk, not by new code**. The plan (`morph-plan`) marks each scenario
+with `prova:` and, for a test, a `risco:` (business rule, money, external contract, concurrency,
+data integrity, regression). The budget is **one test per risky scenario, plus the regression test of
+the bug being fixed**; going above it takes a one-line justification on the scenario. A scenario
+without risk — CRUD, DTO, mapping, wiring, constants, layout — is `prova: leitura`: the Gate 3
+verifier proves it by reading the code, and it gets no test.
 
 - **Table before copy.** Scenarios of the same behavior — including its edge cases (null, empty,
   boundary) — are rows of one `[Theory]` (`[InlineData]`/`[MemberData]`), never N `[Fact]` methods
@@ -125,11 +129,13 @@ regression test per bug fixed**. Going above it takes a one-line justification i
   UI copy, tenant config or prose proves the file's version, not behavior. Enforce it with an
   analyzer, a lint rule or a validation at publish time, outside the suite count. The versioned
   prompt case (at most one structural test) is `ai-agents-testing-ai`.
+- **One layer per behavior.** A rule tested in the handler is not tested again through the
+  endpoint or the SQL integration: pick the cheapest layer that bites (wiring is the verifier's).
 - **Shared fixture by default.** Reuse the project's `WebApplicationFactory` fixture, fakes and
   builders. Before writing a new helper, look for the existing one (`morph-spec graph explain
   <Name>`; fallback without a graph: `grep -rn`).
-- **Order is free, proof is not the implementer's:** a bug gets a regression test, and pure logic
-  gets its tests, in whatever order the code comes out. The implementer does not run red→green
+- **Order is free, proof is not the implementer's:** a bug gets a regression test, and a risky
+  scenario gets its test, in whatever order the code comes out. The implementer does not run red→green
   cycles nor mutate production code to watch a test fail; it runs its own filter once before the
   report, and the Gate 3 mutation proof is what shows the test bites.
 - **A surviving mutant** of the Gate 3 mutation proof is killed by tightening an existing assertion

package/framework/standards/backend/dotnet/vsa-handler-patterns.md

@@ -225,13 +225,13 @@ public sealed class SearchBooksHandler(
 When a slice needs concurrency control (`SELECT ... FOR UPDATE`, lease/outbox semantics,
 `DbUpdateConcurrencyException` retry loops) or SQL that LINQ cannot express, write a
 **hand-written, purpose-built store** with intention-named methods (e.g. `OutboxStore.ClaimBatchAsync`,
-`LeaseStore.TryAcquireAsync`) — and document the justification in `decisions.md`.
+`LeaseStore.TryAcquireAsync`) — and document the justification in `plan.md` (`## Decisões`).
 Never a generic-per-entity abstraction.
 
 **Rule of thumb:** everything → `ApplicationDbContext` in the slice. Concurrency or
-specific SQL → dedicated hand-written store + `decisions.md` entry. Never reach for raw SQL
+specific SQL → dedicated hand-written store + `plan.md` (`## Decisões`) entry. Never reach for raw SQL
 (`FromSqlRaw`) unless a query genuinely cannot be expressed in LINQ — and document that
-in `decisions.md`.
+in `plan.md` (`## Decisões`).
 
 ---
 
@@ -307,8 +307,8 @@ builder.Services.AddExceptionHandler<CustomExceptionHandler>()
 | Share handlers across features | Each feature has its own handler, even if similar |
 | Use constructor + field for DI | Use primary constructors: `class Handler(IDep dep)` |
 | Group by technical concern (Controllers/, Services/) | Group by feature: `Features/BookFeature/CreateBook/` |
-| Route data access through any indirection layer | Inject `DbContext` and write LINQ in the slice; dedicated store only with `decisions.md` justification |
-| Use raw SQL (`FromSqlRaw` / `ExecuteQuery(string)`) by default | Use LINQ; raw SQL only with a `decisions.md` justification |
+| Route data access through any indirection layer | Inject `DbContext` and write LINQ in the slice; dedicated store only with `plan.md` (`## Decisões`) justification |
+| Use raw SQL (`FromSqlRaw` / `ExecuteQuery(string)`) by default | Use LINQ; raw SQL only with a `plan.md` (`## Decisões`) justification |
 
 ---
 

package/framework/standards/backend/integrations/hangfire/hangfire-jobs.md

@@ -15,7 +15,7 @@ Background job processing for .NET 10 VSA applications with Hangfire on Neon Pos
 
 ## When to use Hangfire
 
-Hangfire is in the stack **only with a real reason**: work that must survive a process restart, run on a schedule, or be retried later (daily reindex, delayed reminders, retrying a flaky third party). Work that fits in the request (send one email after a signup, index one uploaded document) runs in the slice handler. Record the reason in `decisions.md`.
+Hangfire is in the stack **only with a real reason**: work that must survive a process restart, run on a schedule, or be retried later (daily reindex, delayed reminders, retrying a flaky third party). Work that fits in the request (send one email after a signup, index one uploaded document) runs in the slice handler. Record the reason in `plan.md` (`## Decisões`).
 
 Hangfire provides fire-and-forget, delayed and recurring (cron) jobs, continuations, a dashboard and automatic retries.
 

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

@@ -64,7 +64,7 @@ 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
+document the justification in the feature's `plan.md` (`## Decisões`) 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
@@ -727,7 +727,7 @@ Each Neon branch gets its own isolated auth data. This means:
     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))
+    `plan.md` (`## Decisões`) ADR (see [Data Access Boundary](#data-access-boundary--backend-first-by-default))
 
 ---
 

package/framework/standards/data/nosql/cache/redis.md

@@ -179,4 +179,4 @@ The minute comes from `TimeProvider` (testable with `FakeTimeProvider`), never `
 - Never omit TTL -- unbounded keys fill memory
 - Never wrap the cache in a `XService`/repository class -- cache-aside is three lines in the handler
 - Never return `null` for "not found" -- the handler returns `Result` with `NotFound`
-- Never swallow `RedisConnectionException` in an empty `catch`: a cache outage must be visible (health check + logs). Falling back to the database while Redis is down is a product decision: record it in `decisions.md` and implement it once, at the cache boundary, not per call site
+- Never swallow `RedisConnectionException` in an empty `catch`: a cache outage must be visible (health check + logs). Falling back to the database while Redis is down is a product decision: record it in `plan.md` (`## Decisões`) and implement it once, at the cache boundary, not per call site

package/framework/standards/data/nosql/cosmos-db.md

@@ -3,7 +3,7 @@
 > **Scope:** data-nosql
 > **Layer:** 3 (opcional — nenhuma rule nem persona o carrega; só sob demanda via `morph-spec standards --find`, depois de a decisão existir)
 > **Keywords:** cosmos-db, nosql, document-database, event-store, partition-key, azure-cosmos
-> **Load When:** `decisions.md` already records the choice of Cosmos DB over Neon for a specific store
+> **Load When:** `plan.md` (`## Decisões`) already records the choice of Cosmos DB over Neon for a specific store
 
 **Verified against:** .NET 10 (SDK 10.0.400-preview) + Microsoft.Azure.Cosmos 3.63.2 + Newtonsoft.Json 13.0.4 — every `csharp` block below compiles with `TreatWarningsAsErrors` against the `Result`/`Error` types of `backend-dotnet-result-pattern`. Last-verified: 2026-10-03.
 
@@ -11,7 +11,7 @@
 
 ## Overview
 
-**Cosmos DB is not part of the stack.** The default store is Neon (Postgres) through EF Core, with the `ApplicationDbContext` used directly in the slice. Reach for Cosmos only when a requirement Postgres cannot meet is written down in `decisions.md` (the "why not Neon" included). Everything below applies the stack conventions to that exception: the client is injected straight into the slice handler, ids are `Guid.CreateVersion7()`, expected failures are `Result` values, and classes are `sealed`.
+**Cosmos DB is not part of the stack.** The default store is Neon (Postgres) through EF Core, with the `ApplicationDbContext` used directly in the slice. Reach for Cosmos only when a requirement Postgres cannot meet is written down in `plan.md` (`## Decisões`) (the "why not Neon" included). Everything below applies the stack conventions to that exception: the client is injected straight into the slice handler, ids are `Guid.CreateVersion7()`, expected failures are `Result` values, and classes are `sealed`.
 
 ## When It Can Be Justified
 
@@ -155,7 +155,7 @@ using var feed = container.GetItemQueryIterator<OrderEvent>(
 
 | Do NOT | Do Instead |
 |--------|------------|
-| Pick Cosmos without a `decisions.md` entry | Neon (Postgres) via EF Core is the default store |
+| Pick Cosmos without a `plan.md` (`## Decisões`) entry | Neon (Postgres) via EF Core is the default store |
 | Wrap `Container` in a generic `CosmosRepository<T>` | Inject the keyed `Container` into the slice handler |
 | `try/catch (CosmosException)` for 404/409 | Stream APIs + `StatusCode` → `Result` |
 | `Guid.NewGuid()` for document ids | `Guid.CreateVersion7()` |

package/framework/standards/frontend/admin-app/forms.md

@@ -16,7 +16,7 @@ An admin app has **one** form pattern. It is the base pattern of `nextjs/forms.m
 - **The Zod schema is shared.** The same schema types the form, validates it, and parses the API response (`admin-app/data-table.md` parses the list query with Zod too). One source of truth per entity.
 - **react-hook-form keeps inputs uncontrolled** — a 30-field form does not re-render on every keystroke, which is what `useState` per field does.
 - **shadcn's current form docs are written around it** (`Field`, `FieldLabel`, `FieldError` + `Controller`).
-- **Coexisting styles are the defect this rule exists for.** Measured in a real admin app: three form styles side by side (react-hook-form in some screens, hand-rolled `useState` in others) — three validation behaviours for one product, and a redesign that changed none of them. A screen that needs something the pattern cannot do registers the exception in `decisions.md`; it does not start a fourth style.
+- **Coexisting styles are the defect this rule exists for.** Measured in a real admin app: three form styles side by side (react-hook-form in some screens, hand-rolled `useState` in others) — three validation behaviours for one product, and a redesign that changed none of them. A screen that needs something the pattern cannot do registers the exception in `plan.md` (`## Decisões`); it does not start a fourth style.
 
 ## Core Rules
 

package/framework/standards/frontend/design-system/art-direction.md

@@ -0,0 +1,88 @@
+# Art Direction — Decide What the Screen Is Before Drawing It
+
+> **Scope:** frontend-design-system
+> **Layer:** 3
+> **Keywords:** art direction, concept, visual metaphor, design direction, template look, generic ui, memorable, mobile-first, brand moment
+> **Load When:** ui-designer active, before any component of a new or changed screen
+
+**Verified against:** the `login-ciclo-do-produto` design round (2026-10-06): a correct, plain design was rejected; a second round with a written direction, an HTML prototype and a screenshot self-review was approved on first sight. Last-verified: 2026-10-06.
+
+---
+
+A design that follows the tokens, has every state and passes WCAG can still be forgettable. What made the difference in practice was not talent but order: a direction written before any component, a real prototype, and a critical look at the rendered result. This standard is the first of the three.
+
+---
+
+## Section 1: Write the Direction First
+
+Before the first component, answer four questions in `1-design/direcao.md`:
+
+1. **Concept in one sentence.** What the screen says, not what it contains. *"The login tells the product cycle in scenes while you sign in."*
+2. **Visual metaphor.** The image that organizes the layout. *Stories; a control room; a ticket being stamped; a garden that grows.*
+3. **What makes it memorable.** The one thing someone would describe to a colleague. If nothing, the direction is not done.
+4. **What it must NOT look like.** Name the generic version you are avoiding (Section 4).
+
+Only then pick components. A component chosen before the direction is chosen by habit.
+
+---
+
+## Section 2: Explore Two or Three Directions
+
+For a new screen or a brand moment (login, onboarding, first screen, empty state, success, showcase), write two or three directions that are **distinct**, not three color variations of one layout. For each: concept, metaphor, the mobile idea, the motion idea, and the risk. Recommend one and say why, in terms of the product and the user, not taste.
+
+A changed screen inside an established system may need only one direction, written the same way, with what changes and why.
+
+---
+
+## Section 3: Good and Bad Directions
+
+| Bad direction | Why it fails | Good direction |
+|---|---|---|
+| "Clean, modern login with the logo and a form." | Describes every login. Nothing to remember. | "The panel tells the product cycle in three scenes, stories-style; the form is a sheet the thumb reaches." |
+| "Dashboard with cards for each metric." | Content, not concept. Layout by habit. | "A control room: one hero number the operator acts on, the rest as quiet instruments around it." |
+| "Empty state with an icon and a button." | The default of every kit. | "The empty list is the first page of a notebook: an illustrated first entry shows what a good one looks like." |
+| "Mobile: same layout, stacked." | Mobile derived, not designed. | "Mobile is an app: bottom sheet, thumb-zone actions, the scene compressed to a strip above." |
+
+---
+
+## Section 4: Template Tells to Avoid
+
+Each one is fine in isolation; together they read as "generated". If the screen has three or more, raise it.
+
+- Raw shadcn look: default radius, default gray border, no brand in any surface.
+- A white card centered on a gray background, logo on top, form inside.
+- A generic icon list (three features, three Lucide icons, three lines of copy).
+- Stack-default or AI-tell fonts with no tracking or scale decision (see `premium-finish` Section 1).
+- Flat solid backgrounds with no light, layer or texture.
+- Mobile as the desktop stacked: centered card, tiny targets, actions out of thumb reach.
+- Motion as decoration: everything fades in, nothing tells a sequence.
+- Made-up numbers on illustrative cards (`R$ 12.430`, `98% satisfaction`).
+
+---
+
+## Section 5: Mobile Is Designed, Not Derived
+
+Draw the phone at 390 px as its own composition: bottom sheet for the primary task, actions in the thumb zone, targets of at least 44 px, the brand scene compressed rather than removed. Then check the desktop is not the phone blown up either.
+
+---
+
+## Section 6: Motion With Intent
+
+Motion should tell something (a sequence, a cause, a state change). Pick the lightest tool that delivers it: CSS transition and `@keyframes`, then CSS scroll-driven animation, then Framer Motion, then GSAP with ScrollTrigger and timelines. Budget: 60 fps, only `transform` and `opacity`, no layout thrash, lazy below the fold. `prefers-reduced-motion` gets a composed static version, designed as carefully as the animated one.
+
+---
+
+## Section 7: Prototype and Self-Review
+
+The direction is proved in a rendered prototype, not in prose: `1-design/prototipos/{screen}.html`, self-contained, using the project's REAL tokens read from its token CSS (the design-system doc can be stale), desktop and phone side by side in a device frame, with animated / static / pause controls. Serve it over local HTTP, screenshot at 1280 and 390, judge against this standard and the system bar (hierarchy, contrast, rhythm, mobile, "does it look like a template?"), fix, repeat. The final screenshots sit next to the HTML.
+
+---
+
+## Checklist
+
+- [ ] `direcao.md` answers concept, metaphor, memorable, must-not-look-like
+- [ ] Two or three distinct directions for a new screen or brand moment, one recommended with a reason
+- [ ] Fewer than three template tells on the final screen
+- [ ] Mobile composed at 390 px on its own terms
+- [ ] Motion tells something, with a composed reduced-motion version
+- [ ] Prototype rendered, screenshotted at 1280 and 390, and revised until it passes

package/framework/standards/frontend/design-system/premium-finish.md

@@ -3,9 +3,9 @@
 > **Scope:** frontend-design-system
 > **Layer:** 3
 > **Keywords:** premium, polish, typography, film grain, atmosphere, load-in, scrim, legibility over video, accent
-> **Load When:** ui-designer active, or the brief asks for a premium or high-end feel
+> **Load When:** ui-designer active (every surface), or the brief asks for a premium or high-end feel
 
-**Verified against:** Production landing pages, CSS-only techniques, no runtime dependency. Last-verified: 2026-08-21.
+**Verified against:** Production landing pages, CSS-only techniques, no runtime dependency; app patterns from an approved login prototype (2026-10-06). Last-verified: 2026-10-06.
 
 ---
 
@@ -148,6 +148,78 @@ Finish with fresh eyes: open the page as if you were the client. Whatever looks
 
 ---
 
+## Section 8: Patterns For App Screens
+
+The finish is not only for marketing pages. Login, onboarding, the first screen after sign-up, an empty state and a success moment are brand moments inside the product, and a data screen also has to look designed: elegant density, illustrated empty states, skeletons with shimmer, transitions between states. These patterns come from an app login that was approved on first sight after a plain one was rejected.
+
+### Bottom sheet on mobile
+
+On a phone the form lives in a sheet anchored to the bottom, inside the thumb zone, with the brand scene above it. Never the desktop card centered and shrunk.
+
+```css
+.sheet {
+  position: fixed; inset: auto 0 0 0;
+  padding: 12px 20px calc(20px + env(safe-area-inset-bottom));
+  border-radius: 24px 24px 0 0;
+  background: var(--surface);
+  box-shadow: 0 -12px 40px color-mix(in oklab, var(--brand) 18%, transparent);
+}
+.sheet::before {
+  content: ''; display: block; width: 36px; height: 4px; margin: 0 auto 16px;
+  border-radius: 2px; background: var(--border);
+}
+.sheet button, .sheet input { min-height: 44px; }
+```
+
+### Stories-style progress
+
+A sequence of scenes reads like stories: thin segmented bars at the top, each filling while its scene is on. One keyframe, the delay per segment, and the scene swap keyed to the same delays.
+
+```css
+.stories { display: flex; gap: 4px; }
+.stories span { flex: 1; height: 3px; border-radius: 2px; background: color-mix(in oklab, var(--fg) 20%, transparent); overflow: hidden; }
+.stories span::after {
+  content: ''; display: block; height: 100%; background: var(--fg);
+  transform: scaleX(0); transform-origin: left;
+  animation: fill var(--beat) linear forwards;
+  animation-delay: calc(var(--i) * var(--beat));
+}
+@keyframes fill { to { transform: scaleX(1); } }
+```
+
+### Synchronized highlight by `animation-delay`
+
+When a scene card lights up while its story bar runs, both share `--i` and `--beat`. No JavaScript timer: the browser keeps them in step, and pausing is one `animation-play-state: paused` on the parent.
+
+### Scene cards without real data
+
+A card that illustrates the product cycle shows shapes, icons and labels, never a metric. A made-up number on a real screen reads as a real number ("R$ 12.430 recovered") and becomes a claim nobody can back. Use bars without values, avatars without names, a check without a count.
+
+### Dot grid faded with `mask-image`
+
+Texture for a hero or a sheet backdrop, cheaper than an image and on brand:
+
+```css
+.dots {
+  background-image: radial-gradient(color-mix(in oklab, var(--fg) 22%, transparent) 1px, transparent 1px);
+  background-size: 16px 16px;
+  mask-image: radial-gradient(ellipse at 50% 30%, #000 30%, transparent 75%);
+}
+```
+
+### Static version for reduced motion
+
+`prefers-reduced-motion: reduce` gets a composed still frame (the best scene, every bar full, the highlight on), not the first frame of a stopped animation.
+
+```css
+@media (prefers-reduced-motion: reduce) {
+  .stories span::after { animation: none; transform: scaleX(1); }
+  .scene { animation: none; opacity: 1; }
+}
+```
+
+---
+
 ## Checklist
 
 - [ ] Display font chosen from the brand, not from stack defaults or the AI-tell list
@@ -157,4 +229,7 @@ Finish with fresh eyes: open the page as if you were the client. Whatever looks
 - [ ] Directional scrim plus text-shadow on every text-over-media block
 - [ ] Accent used in three places or fewer
 - [ ] Details swept: scrollbar, selection, hairlines, hover micro-transitions
+- [ ] App screen: mobile designed on its own (bottom sheet, thumb zone, 44px targets), never the desktop stacked
+- [ ] No invented number or data on a real screen
+- [ ] Reduced motion gets a composed static frame
 - [ ] Fresh-eyes pass done, and it does not read as a template

package/framework/standards/frontend/nextjs/testing.md

@@ -17,7 +17,7 @@ Vitest + React Testing Library for component tests. MSW for API mocking. Co-loca
 - ALWAYS use `@testing-library/user-event` for interactions — not `fireEvent`
 - ALWAYS mock the API layer with MSW — never mock `fetch` directly
 - NEVER test implementation details — test what the user sees
-- ALWAYS test the happy path + one error path per component
+- ONLY test a component when a plan scenario with `risco:` lives in it — a component is not a unit of the budget
 
 ## Test File Co-location
 
@@ -103,9 +103,13 @@ export function QueryClientWrapper({ children }: { children: React.ReactNode })
 
 ## Test Budget
 
-The plan (`morph-plan`) gives each task a budget: **one test per postcondition, plus one
-regression test per bug fixed**. Going above it takes a one-line justification in the task. The
-happy path + one error path per component above is that budget applied to a component.
+Tests are paid for by **risk, not by new code**. The plan (`morph-plan`) marks each scenario
+with `prova:` and, for a test, a `risco:` (business rule, money, external contract, concurrency,
+data integrity, regression). The budget is **one test per risky scenario, plus the regression test of
+the bug being fixed**; going above it takes a one-line justification on the scenario. A scenario
+without risk — CRUD, DTO, mapping, wiring, constants, layout — is `prova: leitura`: the Gate 3
+verifier proves it by reading the code, and it gets no test. Rendering, layout and copy are
+`leitura` or `e2e`, never a unit test per component.
 
 - **Table before copy.** Scenarios of the same behavior — edge cases included — are rows of one
   `it.each`/`test.each`, never N `it()` blocks that differ by one value.
@@ -116,8 +120,8 @@ happy path + one error path per component above is that budget applied to a comp
 - **Shared helpers by default.** Reuse the existing wrappers (`test/helpers.tsx`), MSW handlers and
   factories. Before writing a new one, look for it (`morph-spec graph explain <Name>`; fallback
   without a graph: `grep -rn`).
-- **Order is free, proof is not the implementer's:** a bug gets a regression test, and pure logic
-  (formatters, reducers, schema) gets its tests, in whatever order the code comes out. The
+- **Order is free, proof is not the implementer's:** a bug gets a regression test, and a risky
+  scenario (a formatter of money, a reducer with rules, a schema) gets its test, in whatever order the code comes out. The
   implementer does not run red→green cycles nor mutate production code to watch a test fail; it
   runs its own filter once before the report, and the Gate 3 mutation proof shows the test bites.
 

package/framework/standards/infrastructure/neon/neon-pgvector.md

@@ -19,7 +19,7 @@ Stack: .NET VSA + Neon Serverless Postgres. For the end-to-end RAG pipeline (ing
 - ALWAYS call `UseVector()` on the `UseNpgsql(...)` options builder (EF Core); `NpgsqlDataSourceBuilder.UseVector()` is only for raw Npgsql
 - ALWAYS register the `vector` extension in `OnModelCreating` (`HasPostgresExtension("vector")`)
 - Map vector properties as `Pgvector.Vector` -- EF Core does not map `float[]` or `ReadOnlyMemory<float>` to the `vector` column
-- Query through the `ApplicationDbContext` in the slice handler with the `CosineDistance`/`L2Distance`/`MaxInnerProduct` LINQ translations -- no repository class, no raw SQL from C# without a `decisions.md` justification
+- Query through the `ApplicationDbContext` in the slice handler with the `CosineDistance`/`L2Distance`/`MaxInnerProduct` LINQ translations -- no repository class, no raw SQL from C# without a `plan.md` (`## Decisões`) justification
 - IDs come from the app (`Guid.CreateVersion7()`), never from a `gen_random_uuid()` column default
 
 ## Enable pgvector
@@ -39,7 +39,7 @@ CREATE EXTENSION IF NOT EXISTS vector;
 <PackageReference Include="Pgvector.EntityFrameworkCore" Version="0.3.0" />
 ```
 
-`Pgvector.EntityFrameworkCore` 0.3.0 requires `Npgsql.EntityFrameworkCore.PostgreSQL` >= 9.0.1 and brings `Pgvector` (the `Vector` type and the raw-Npgsql plugin) transitively. The configuration below maps each column to the snake_case names of `backend/database/postgresql/database.md` (`embedding`, `created_at`) with `HasColumnName`; without it EF creates `"Embedding"`, `"CreatedAt"` and every SQL snippet below would have to quote PascalCase names. (A project that wants this for every entity can add `EFCore.NamingConventions` and `UseSnakeCaseNamingConvention()` once, instead of per column -- a project-wide decision for `decisions.md`.)
+`Pgvector.EntityFrameworkCore` 0.3.0 requires `Npgsql.EntityFrameworkCore.PostgreSQL` >= 9.0.1 and brings `Pgvector` (the `Vector` type and the raw-Npgsql plugin) transitively. The configuration below maps each column to the snake_case names of `backend/database/postgresql/database.md` (`embedding`, `created_at`) with `HasColumnName`; without it EF creates `"Embedding"`, `"CreatedAt"` and every SQL snippet below would have to quote PascalCase names. (A project that wants this for every entity can add `EFCore.NamingConventions` and `UseSnakeCaseNamingConvention()` once, instead of per column -- a project-wide decision for `plan.md` (`## Decisões`).)
 
 ### Entity Definition
 
@@ -196,9 +196,9 @@ public sealed class SearchDocumentsHandler(
 
 Storing an embedding is an ordinary EF write in the handler that owns the document: `document.Embedding = new Vector(await embeddings.GenerateVectorAsync(text, cancellationToken: ct));` followed by `SaveChangesAsync`. No `UPDATE ... SET embedding` from C#.
 
-### SQL Functions (only with a `decisions.md` justification)
+### SQL Functions (only with a `plan.md` (`## Decisões`) justification)
 
-When the query must live in the database (called from several apps, or a hybrid score the LINQ translation cannot express), a SQL function is acceptable -- record why in `decisions.md`, call it through EF Core with interpolated parameters, and keep the same distance rules:
+When the query must live in the database (called from several apps, or a hybrid score the LINQ translation cannot express), a SQL function is acceptable -- record why in `plan.md` (`## Decisões`), call it through EF Core with interpolated parameters, and keep the same distance rules:
 
 ```sql
 CREATE OR REPLACE FUNCTION match_documents(
@@ -218,7 +218,7 @@ $$;
 
 ## Hybrid Search (Vector + Full-Text)
 
-Blends the vector score with `ts_rank`. Same rule as above: a SQL function, justified in `decisions.md`.
+Blends the vector score with `ts_rank`. Same rule as above: a SQL function, justified in `plan.md` (`## Decisões`).
 
 ```sql
 CREATE OR REPLACE FUNCTION hybrid_search(

package/framework/templates/.idea/morph-templates.xml

@@ -0,0 +1,92 @@
+<templateSet group="MORPH Templates">
+  <template name="morph-pascal" value="{{pascalCase $FEATURE_NAME$}}" description="Convert to PascalCase (UserAuth)" toReformat="false" toShortenFQNames="true">
+    <variable name="FEATURE_NAME" expression="" defaultValue="&quot;FEATURE_NAME&quot;" alwaysStopAt="true" />
+    <context>
+      <option name="OTHER" value="true" />
+    </context>
+  </template>
+
+  <template name="morph-camel" value="{{camelCase $FEATURE_NAME$}}" description="Convert to camelCase (userAuth)" toReformat="false" toShortenFQNames="true">
+    <variable name="FEATURE_NAME" expression="" defaultValue="&quot;FEATURE_NAME&quot;" alwaysStopAt="true" />
+    <context>
+      <option name="OTHER" value="true" />
+    </context>
+  </template>
+
+  <template name="morph-snake" value="{{snakeCase $FEATURE_NAME$}}" description="Convert to snake_case (user_auth)" toReformat="false" toShortenFQNames="true">
+    <variable name="FEATURE_NAME" expression="" defaultValue="&quot;FEATURE_NAME&quot;" alwaysStopAt="true" />
+    <context>
+      <option name="OTHER" value="true" />
+    </context>
+  </template>
+
+  <template name="morph-title" value="{{titleCase $FEATURE_NAME$}}" description="Convert to Title Case (User Auth)" toReformat="false" toShortenFQNames="true">
+    <variable name="FEATURE_NAME" expression="" defaultValue="&quot;FEATURE_NAME&quot;" alwaysStopAt="true" />
+    <context>
+      <option name="OTHER" value="true" />
+    </context>
+  </template>
+
+  <template name="morph-kebab" value="{{kebabCase $FEATURE_NAME$}}" description="Convert to kebab-case (user-auth)" toReformat="false" toShortenFQNames="true">
+    <variable name="FEATURE_NAME" expression="" defaultValue="&quot;FEATURE_NAME&quot;" alwaysStopAt="true" />
+    <context>
+      <option name="OTHER" value="true" />
+    </context>
+  </template>
+
+  <template name="morph-if" value="{{#if $CONDITION$}}&#10;  $END$&#10;{{/if}}" description="Handlebars if block" toReformat="false" toShortenFQNames="true">
+    <variable name="CONDITION" expression="" defaultValue="&quot;condition&quot;" alwaysStopAt="true" />
+    <context>
+      <option name="OTHER" value="true" />
+    </context>
+  </template>
+
+  <template name="morph-if-else" value="{{#if $CONDITION$}}&#10;  $TRUE_BRANCH$&#10;{{else}}&#10;  $FALSE_BRANCH$&#10;{{/if}}" description="Handlebars if-else block" toReformat="false" toShortenFQNames="true">
+    <variable name="CONDITION" expression="" defaultValue="&quot;condition&quot;" alwaysStopAt="true" />
+    <variable name="TRUE_BRANCH" expression="" defaultValue="&quot;&quot;" alwaysStopAt="true" />
+    <variable name="FALSE_BRANCH" expression="" defaultValue="&quot;&quot;" alwaysStopAt="true" />
+    <context>
+      <option name="OTHER" value="true" />
+    </context>
+  </template>
+
+  <template name="morph-each" value="{{#each $ITEMS$}}&#10;  {{this.$PROPERTY$}}&#10;{{/each}}" description="Handlebars each loop" toReformat="false" toShortenFQNames="true">
+    <variable name="ITEMS" expression="" defaultValue="&quot;items&quot;" alwaysStopAt="true" />
+    <variable name="PROPERTY" expression="" defaultValue="&quot;name&quot;" alwaysStopAt="true" />
+    <context>
+      <option name="OTHER" value="true" />
+    </context>
+  </template>
+
+  <template name="morph-service" value="namespace {{NAMESPACE}}.Application.Features.{{pascalCase FEATURE_NAME}}.Services;&#10;&#10;public class {{pascalCase FEATURE_NAME}}Service(&#10;    I{{pascalCase FEATURE_NAME}}Repository repository,&#10;    ILogger&lt;{{pascalCase FEATURE_NAME}}Service&gt; logger) : I{{pascalCase FEATURE_NAME}}Service&#10;{&#10;    public async Task&lt;{{pascalCase FEATURE_NAME}}Dto?&gt; GetByIdAsync(int id, CancellationToken cancellationToken = default)&#10;    {&#10;        $END$&#10;    }&#10;}" description="MORPH .NET Service class template" toReformat="false" toShortenFQNames="true">
+    <context>
+      <option name="C_SHARP" value="true" />
+    </context>
+  </template>
+
+  <template name="morph-repository" value="public class {{pascalCase FEATURE_NAME}}Repository(AppDbContext context) : I{{pascalCase FEATURE_NAME}}Repository&#10;{&#10;    private readonly DbSet&lt;{{pascalCase FEATURE_NAME}}&gt; _dbSet = context.Set&lt;{{pascalCase FEATURE_NAME}}&gt;();&#10;&#10;    public async Task&lt;{{pascalCase FEATURE_NAME}}?&gt; GetByIdAsync(int id, CancellationToken cancellationToken = default)&#10;    {&#10;        $END$&#10;    }&#10;}" description="MORPH .NET Repository class template" toReformat="false" toShortenFQNames="true">
+    <context>
+      <option name="C_SHARP" value="true" />
+    </context>
+  </template>
+
+  <template name="morph-component" value="@page &quot;/{{kebabCase FEATURE_NAME}}&quot;&#10;@inject I{{pascalCase FEATURE_NAME}}Service {{pascalCase FEATURE_NAME}}Service&#10;@inject ILogger&lt;{{pascalCase FEATURE_NAME}}Page&gt; Logger&#10;&#10;&lt;PageTitle&gt;{{pascalCase FEATURE_NAME}}&lt;/PageTitle&gt;&#10;&#10;&lt;div class=&quot;container-fluid&quot;&gt;&#10;    $END$&#10;&lt;/div&gt;&#10;&#10;@code {&#10;&#10;}" description="MORPH Blazor component template" toReformat="false" toShortenFQNames="true">
+    <context>
+      <option name="HTML" value="true" />
+    </context>
+  </template>
+
+  <template name="morph-migration" value="public partial class Add{{pascalCase FEATURE_NAME}} : Migration&#10;{&#10;    protected override void Up(MigrationBuilder migrationBuilder)&#10;    {&#10;        migrationBuilder.CreateTable(&#10;            name: &quot;{{pascalCase FEATURE_NAME}}s&quot;,&#10;            columns: table =&gt; new&#10;            {&#10;                Id = table.Column&lt;int&gt;(type: &quot;int&quot;, nullable: false)&#10;                    .Annotation(&quot;SqlServer:Identity&quot;, &quot;1, 1&quot;),&#10;                $END$&#10;            },&#10;            constraints: table =&gt;&#10;            {&#10;                table.PrimaryKey(&quot;PK_{{pascalCase FEATURE_NAME}}s&quot;, x =&gt; x.Id);&#10;            });&#10;    }&#10;&#10;    protected override void Down(MigrationBuilder migrationBuilder)&#10;    {&#10;        migrationBuilder.DropTable(name: &quot;{{pascalCase FEATURE_NAME}}s&quot;);&#10;    }&#10;}" description="MORPH EF Core migration template" toReformat="false" toShortenFQNames="true">
+    <context>
+      <option name="C_SHARP" value="true" />
+    </context>
+  </template>
+
+  <template name="morph-ts-contract" value="export interface {{pascalCase FEATURE_NAME}} {&#10;  id: number;&#10;  $FIELD1$&#10;}&#10;&#10;export interface Create{{pascalCase FEATURE_NAME}}Request {&#10;  $FIELD2$&#10;}&#10;&#10;export interface Update{{pascalCase FEATURE_NAME}}Request {&#10;  $END$&#10;}" description="MORPH TypeScript contract template" toReformat="false" toShortenFQNames="true">
+    <variable name="FIELD1" expression="" defaultValue="&quot;&quot;" alwaysStopAt="true" />
+    <variable name="FIELD2" expression="" defaultValue="&quot;&quot;" alwaysStopAt="true" />
+    <context>
+      <option name="TypeScript" value="true" />
+    </context>
+  </template>
+</templateSet>