@palbase/backend 40.0.1 → 40.0.3

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@palbase/backend",
-  "version": "40.0.1",
+  "version": "40.0.3",
   "description": "Palbase Backend SDK — class controllers (@Controller/@Get/@Post + @Body/@QueryParams/@Param), error classes, schema DSL",
   "license": "MIT",
   "repository": {

package/template/AGENTS.md

@@ -187,10 +187,10 @@ Relative test imports need the extension (`./note.service.ts`); the scaffold all
 `npm test` answers "is the logic right". It is not the deploy's own validation —
 decorators, return types, SDK major — which answers "would this ship".
 
-**The deploy runs your suites too** — against the CANDIDATE on a throwaway database,
-before anything goes live; one failure and the candidate is discarded.
-`modules/notes/notes.e2e.test.ts` is that kind: `api` (`@palbase/backend/test`) calls the
-module's routes over real HTTP; its signed-in half needs a fixture user `author` (`palbase test-user templates set --file`).
+**The deploy runs your `*.e2e.test.*` suites too** — against the CANDIDATE on a throwaway
+database, before anything goes live; one failure and the candidate is discarded. Unit tests
+beside your code (`note.service.test.ts`) are NOT sent: they need no stack, and a whole CI corpus inside the stack's memory envelope is how a deploy dies instead of answering.
+`modules/notes/notes.e2e.test.ts` is the deploy kind: `api` (`@palbase/backend/test`) calls the module's routes over real HTTP; its signed-in half needs a fixture user `author` (`palbase test-user templates set --file`).
 
 ## Commands
 

package/template/modules/notes/notes.e2e.test.ts

@@ -10,10 +10,16 @@ import { NoteSchema } from "./dto/create.ts";
 // below crosses the real stack — routing, the zod boundary, the auth rail,
 // row-level security — exactly as a shipped app's call does.
 //
-// Every `*.test.ts` in the project travels with a push, and the deploy runs them
-// against the CANDIDATE release, on a throwaway database, before anything goes
-// live. One failure and the candidate is discarded: the release you have keeps
-// serving. So a test here is a gate, and it is worth writing one per module.
+// A test named `*.e2e.test.ts` — anywhere in the project — travels with a push,
+// and the deploy runs it against the CANDIDATE release, on a throwaway database,
+// before anything goes live. One failure and the candidate is discarded: the
+// release you have keeps serving. So a test here is a gate, and it is worth
+// writing one per module.
+//
+// Your UNIT tests stay home: `note.service.test.ts` beside this file measures
+// logic against a stand-in and runs with `palbase test --unit`. A deploy has no
+// use for it, and a large suite of them has a cost — it would run inside the
+// stack's own memory envelope.
 //
 // `api` is configured by whoever runs it — the deploy, or `palbase test --live`
 // against your own stack — and `testRun` says what that run was given. With no