Przepisy na Node.js/Express

Przepisy Node.js dla agentów AI to prompty i bramki weryfikacyjne, dzięki którym Claude Code, Codex i Cursor tworzą produkcyjne usługi Express 5 w TypeScripcie: czysty shutdown, walidację wejścia, rotację refresh tokenów, limity żądań, transakcje Prisma odporne na współbieżność, zadania BullMQ i logi z redakcją sekretów. Kod akceptujesz na podstawie wyników bramek, a nie lektury linijka po linijce.

Twoje API w Expressie przechodzi wszystkie testy napisane przez agenta, a potem pierwszy deploy zrywa trwające żądania, dwóch klientów kupuje ostatnią sztukę towaru w tej samej chwili, a refresh token pojawia się jawnym tekstem w wyszukiwarce logów. Kod wyglądał idiomatycznie. Każdy z tych błędów to produkcyjny szczegół, którego testy happy path nigdy nie dotknęły.

Ta strona jest dla programistów, którzy budują backendy Node.js z agentem i chcą przestać przeglądać każdy middleware wzrokiem. Produkcyjne szczegóły trafiają do promptów, a dowód dostarcza maszyna.

Co wyniesiesz z tych przepisów Node.js

• Blok reguł AGENTS.md dla TypeScriptu na Node.js, którego przestrzegają wszystkie trzy narzędzia, oraz bramkę npm run check, którą agent uruchamia, zanim powie „gotowe”
• Siedem promptów do skopiowania: szkielet Express 5 z czystym shutdownem, walidacja i mapowanie błędów, rotacja refresh tokenów, rate limiting, transakcja zamówienia w Prisma, worker BullMQ oraz ustrukturyzowane logi z redakcją
• Tabelę weryfikacji, która mówi, która bramka łapie który błąd, więc czytasz wynik bramek zamiast diffa
• Kroki naprawcze dla sześciu najczęstszych awarii Node.js napisanego przez agenta

Przygotuj konwencje Node.js i bramkę, którą agent musi przejść

Większość pracy wykonują dwa artefakty: plik reguł, który agent czyta przy każdym zadaniu, i jedno polecenie, które kończy się błędem, gdy kod nie jest gotowy. Przygotuj oba, zanim poprosisz o jakikolwiek kod.

1. Przypnij wspieraną wersję środowiska. Według harmonogramu wydań Node.js Node.js 24 jest w fazie Active LTS do 2026-10-20, kiedy przechodzi w Maintenance LTS, Node.js 22 w fazie Maintenance LTS, a Node.js 20 osiągnął koniec wsparcia 2026-04-30. Node.js 26 ma zostać wersją LTS 2026-10-28. Przypnij 24 w .nvmrc i w package.json:

   {
     "type": "module",
     "engines": { "node": ">=24" }
   }

   Jawna wersja powstrzymuje agenta przed obejściami, których aktualny Node.js już nie potrzebuje, na przykład dotenv tam, gdzie działa node --env-file=.env.

2. Dodaj bramkę do package.json. To definicja „gotowe” dla każdego promptu na tej stronie.

   {
     "scripts": {
       "typecheck": "tsc --noEmit",
       "lint": "eslint .",
       "test": "vitest run",
       "check": "npm run typecheck && npm run lint && npm run test && npm audit --omit=dev --audit-level=high"
     }
   }

   Aktualne wersje w npm na 2026-09-26: express 5.2.1, zod 4.6.5, vitest 5.0.2, supertest 7.3.0, pino 10.3.1, bullmq 6.3.9, @prisma/client 7.10.0, testcontainers 12.1.0. Dwa pakiety wymagają uwagi, a sekcja o awariach wyjaśnia dlaczego: instaluj typescript@~6.0.3 zamiast latest, jeśli używasz reguł typescript-eslint opartych na typach, oraz instaluj prisma i @prisma/client w tej samej wersji.

3. Zapisz reguły Node.js w AGENTS.md w katalogu głównym repozytorium. Codex czyta AGENTS.md natywnie; zakładki poniżej pokazują, jak Claude Code go wczytuje i jak Cursor dostaje jego kopię.

   ## Node.js conventions
   - Node.js 24, ESM, TypeScript strict. Express 5, never Express 4 idioms.
   - Express 5 forwards rejected promises from handlers to the error middleware.
     Do not add express-async-errors or a catchAsync wrapper.
   - Named wildcards only: app.all('/*splat', ...), never app.get('*', ...).
   - Config comes from one Zod-validated module, src/config.ts. No process.env
     reads anywhere else.
   - One PrismaClient for the process, created in src/db.ts. Never per request.
   - Every error response uses { error: { code, message } }; no stack traces
     outside development.
   - Tests: Vitest and supertest. Database tests use Testcontainers, not mocks.
   - Never edit an existing test assertion, add .skip, or add .only to make a
     test pass. If a test looks wrong, stop and say why.
   - Done means `npm run check` passes. Paste its last 20 lines in your final message.

Najważniejsze są dwie ostatnie reguły. Pierwsza nie pozwala agentowi osłabiać testów, żeby dojść do zielonego wyniku; w artykule chroń wyrocznię znajdziesz wyjaśnienie, dlaczego to najczęstszy sposób, w jaki praca agenta udaje sukces. Druga zamienia „chyba działa” w dowód, który przeczytasz w dziesięć sekund.

Podłącz reguły i bramkę w każdym narzędziu

Reguły i prompty są identyczne we wszystkich narzędziach. Różni się to, jak każde narzędzie wczytuje reguły, formatuje zmiany i recenzuje wynik.

Claude Code

Claude Code w pierwszej kolejności czyta CLAUDE.md, więc utwórz plik, który importuje wspólne reguły. Składnia @path wstawia plik do kontekstu przy starcie:

@AGENTS.md

Bez pliku CLAUDE.md Claude Code w wersji v2.1.277 i nowszej (oba kanały wydań, stan na 2026-10-12) czyta AGENTS.md bezpośrednio (v2.1.281 na Bedrocku, Google Cloud, Foundry i bramkach LLM; przełącznik w /config → Project instructions); import ma znaczenie, gdy trzymasz też reguły specyficzne dla Claude.

Formatuj każdy plik TypeScript edytowany przez agenta hookiem PostToolUse w .claude/settings.json (wymaga Prettiera w devDependencies: npm install -D prettier):

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "jq -r '.tool_input.file_path' | grep -E '\\.(ts|js)$' | xargs -r npx --no-install prettier --write"
          }
        ]
      }
    ]
  }
}

Daj agentowi wyszukiwanie referencji i diagnostykę przez plugin typescript-lsp z oficjalnego marketplace’u Anthropic. Plugin tylko rejestruje serwer, więc najpierw zainstaluj serwer języka. Przypnij typescript@6: TypeScript 7.0.2 zawiera tylko tsc, bez tsserver, którego serwer języka potrzebuje (sprawdzono 2026-09-26). W terminalu:

npm install -g typescript-language-server typescript@6
claude plugin install typescript-lsp@claude-plugins-official

Zanim otworzysz pull request, uruchom w sesji /code-review, żeby dostać drugą opinię o diffie.

Codex

Codex czyta AGENTS.md bezpośrednio, więc dodatkowy plik nie jest potrzebny. Uruchom zadanie z zapisem w obszarze roboczym i pytaniem o zgodę na wszystko szersze (terminal):

codex -s workspace-write -a on-request "Implement POST /api/v1/orders as described in docs/tasks/orders.md. Done means npm run check passes."

Zrecenzuj gałąź względem main, zanim ją wypchniesz:

codex review --base main

Cursor

Utwórz regułę projektu w ustawieniach Rules Cursora z tą samą listą, ograniczoną do plików *.ts, żeby agent wczytywał ją przy każdym kontakcie z TypeScriptem. Przy wieloplikowych promptach z tej strony używaj Plan Mode, żeby zatwierdzić listę plików przed napisaniem kodu. Niezależne przepisy uruchamiaj w Worktrees, a pull request oddaj do recenzji Bugbotowi.

Zacznij od domyślnego modelu narzędzia i zwiększ poziom effort, zanim zmienisz model; aktualne domyślne modele znajdziesz w przeglądzie modeli.

Zbuduj produkcyjne API na Express 5 z agentem krok po kroku

Każdy krok to jeden prompt i sprawdzenie, które go dowodzi. Wykonuj je po kolei: późniejsze prompty zakładają, że szkielet i moduł bazy danych już istnieją.

Jak wygenerować usługę Express 5, która czysto się zamyka?

Najczęstsze pominięcie w pierwszym podejściu to shutdown. Agent wywołuje app.listen() i nic więcej, więc każdy deploy przerywa trwające żądania i zostawia otwarte połączenia z bazą.

Prompt do skopiowania: szkielet Express 5 z czystym shutdownem

Create an Express 5 service in TypeScript (ESM, Node.js 24). Files:
src/config.ts parses process.env with a Zod schema (PORT, DATABASE_URL, REDIS_URL,
JWT_SECRET min 32 chars, NODE_ENV) and exits with a readable error if it fails.
src/app.ts builds the app without listening: helmet, express.json({ limit: '100kb' }),
GET /healthz returning 200, and the API mounted under /api/v1.
src/server.ts listens on config.PORT and handles SIGTERM and SIGINT once: stop
accepting connections with server.close(), wait for in-flight requests, disconnect
Prisma and Redis, then exit 0. Force exit 1 after 10 seconds with an unref'd timer.
Add src/server.test.ts: start the server on port 0, send a request to a test route
that waits 2 seconds, send SIGTERM mid-request, and assert the request still gets
200 and the process exits 0. Done means npm run check passes.

Dobra odpowiedź ma taki rdzeń:

const server = app.listen(config.PORT);

function shutdown(signal: NodeJS.Signals) {
  logger.info({ signal }, 'shutting down');
  setTimeout(() => process.exit(1), 10_000).unref();
  server.close(async (err) => {
    await prisma.$disconnect();
    await redis.quit();
    process.exit(err ? 1 : 0);
  });
}

process.once('SIGTERM', shutdown);
process.once('SIGINT', shutdown);

Nie musisz tego sprawdzać wzrokiem: test nie przejdzie, jeśli żądanie zostanie zerwane albo proces zawiśnie. Rozdzielenie app.ts i server.ts pozwala też supertestowi sterować aplikacją bez otwierania portu.

Jak uzyskać walidację i odpowiedzi błędów, na których klient może polegać?

Agenci wytrenowani na Expressie 4 owijają każdy handler w catchAsync albo instalują express-async-errors. Express 5 sam przekazuje odrzucone obietnice z handlerów do middleware’u błędów, więc te wrappery to martwy kod, a reguła w AGENTS.md trzyma je z dala od repozytorium.

Prompt do skopiowania: walidacja Zod i jeden handler błędów

Add a users resource at /api/v1/users (list, get, create, update, delete).
Validate body, params, and query with Zod 4 schemas through one validate({ body,
params, query }) middleware. On failure return 422 with
{ error: { code: 'VALIDATION', message, details: [{ path, message }] } } built from
result.error.issues. Define AppError subclasses NotFoundError (404),
ConflictError (409), UnauthorizedError (401), ForbiddenError (403). Write one error
middleware in src/http/errors.ts that maps them, maps Prisma error P2002 to 409 and
P2025 to 404, and returns 500 with a generic message for anything else, logging the
real error. Never send err.message or a stack for a 500 when NODE_ENV is production.
Handlers are plain async functions: no catchAsync, no express-async-errors.
Supertest cases: each status code above, a 500 in production mode whose body
contains no stack, and a rejected promise inside a handler reaching the error
middleware. List the test cases before the code.

Agenci zwykle pomijają właśnie mapowanie błędów Prismy. Bez niego zduplikowany e-mail kończy się kodem 500, a klient ponawia żądanie, które nigdy się nie powiedzie. Test błędu 500 w trybie produkcyjnym dowodzi, że żaden wewnętrzny szczegół nie trafia do klienta.

Jak skłonić agenta do napisania rotacji refresh tokenów, której można ufać?

Kod uwierzytelniania to miejsce, w którym czytanie diffa daje największe poczucie bezpieczeństwa i najmniej realnej pewności. Opisz scenariusze ataku jako testy i to one niech niosą dowód.

Prompt do skopiowania: access tokeny JWT z rotacją refresh tokenów

Implement authentication in src/auth/ using jose for JWTs and argon2 for password
hashes. POST /api/v1/auth/login returns a 15-minute access token (sub, role) and a
refresh token. Store only a SHA-256 hash of each refresh token in a RefreshToken
table with userId, familyId, expiresAt, and revokedAt. POST /api/v1/auth/refresh
issues a new pair and revokes the old token inside one Prisma transaction. If a
revoked refresh token is presented again, revoke every token in its family and
return 401. POST /api/v1/auth/logout revokes the family. requireAuth middleware
verifies the Bearer token and sets req.user; requireRole('admin') returns 403.
Send the refresh token only in an HttpOnly, Secure, SameSite=Strict cookie. Tests:
login, refresh, reuse of a rotated token revokes the family, an expired access
token returns 401, a token signed with another secret returns 401, a user token on
an admin route returns 403, and no log line contains a raw token.

Kluczowy jest test ponownego użycia tokenu. Bez niego implementacja, która nigdy nie unieważnia starego tokenu, przechodzi wszystkie pozostałe przypadki. Jako drugie, niezależne sprawdzenie tego kodu dodaj bramkę bezpieczeństwa, która uruchamia agenta recenzującego przy każdym pull requeście; opcje dla każdego narzędzia opisuje strona o bramkach bezpieczeństwa dla agentów.

Jak ograniczyć liczbę żądań do API w Expressie za load balancerem?

Wygenerowany limiter zwykle działa lokalnie i zawodzi na produkcji na jeden z dwóch sposobów: liczniki żyją w pamięci procesu, więc każda replika przepuszcza pełny limit, albo każde żądanie wygląda, jakby przyszło z adresu IP load balancera.

Prompt do skopiowania: rate limiting ze wspólnym magazynem w Redisie

Add rate limiting with express-rate-limit 8 and rate-limit-redis using the existing
ioredis client, so limits are shared across replicas. Global limiter: 300 requests
per minute per IP, standardHeaders 'draft-8', legacyHeaders false. Login: 5 attempts
per 15 minutes keyed by IP plus lower-cased email. Forgot-password: 3 per hour keyed
by email. Set app.set('trust proxy', 1) because we run behind exactly one load
balancer, and explain in a comment what breaks if that number is wrong. 429
responses use our { error } format. Tests with supertest against a Testcontainers
Redis: the 6th login attempt returns 429 with a RateLimit header, a different email
from the same IP is not blocked, and two app instances sharing one Redis share the
count.

Test z dwiema instancjami dowodzi, że magazyn jest wspólny; test w jednym procesie przechodzi z domyślnym magazynem w pamięci i nie mówi nic o produkcji.

Jak uzyskać transakcje Prisma, które wytrzymają równoległe zamówienia?

Pierwsza próba agenta przy „sprawdź stan, potem zmniejsz” odczytuje stan magazynu, porównuje go w JavaScripcie i zapisuje z powrotem. Dwa równoległe zamówienia odczytują stock = 1 i oba kończą się sukcesem. Zamockowane repozytorium nie pokaże tego błędu; pokaże go tylko prawdziwa baza pod równoległymi żądaniami.

Prompt do skopiowania: transakcja zamówienia, która nie sprzeda za dużo

Implement createOrder(userId, items: { productId, quantity }[]) in
src/orders/service.ts with Prisma 7. Inside prisma.$transaction(async (tx) => ...),
for each item run tx.product.updateMany({ where: { id, stock: { gte: quantity } },
data: { stock: { decrement: quantity } } }) and throw OutOfStockError if count is 0,
so the check and the decrement are one atomic statement. Then create the Order and
OrderItems with unitPrice copied from the product, and compute total with Prisma
Decimal, never JavaScript numbers. Use the single client from src/db.ts. Write an
integration test with @testcontainers/postgresql that applies migrations, sets a
product's stock to 1, fires 10 createOrder calls at once with Promise.allSettled,
and asserts exactly one succeeds, nine reject with OutOfStockError, and stock is 0.

Dwa szczegóły Prisma, których agent może nie znać. Prisma 7 wymaga driver adaptera: klienta tworzy się jako new PrismaClient({ adapter: new PrismaPg({ connectionString }) }) z generatorem prisma-client i plikiem prisma.config.ts, więc ustawienia puli należą do adaptera, a nie do connection stringa. Poza tym 2026-09-26 tag latest w npm dla CLI prisma wskazuje 8.0.0-rc.17, czyli release candidate nowego CLI Prisma dla Prisma Developer Platform, podczas gdy latest dla @prisma/client to 7.10.0. Prisma 8 dostarcza własne skille dla agentów (npx prisma skills sync instaluje je w .claude/skills/, .cursor/skills/ i .agents/skills/), co czyni ją atrakcyjną dla nowych projektów. Wybierz ją świadomie, a nie dlatego, że tak zdecydowało npm install prisma.

Żeby agent czytał prawdziwy schemat zamiast zgadywać nazwy kolumn, podłącz serwer MCP bazy danych do bazy deweloperskiej przez rolę tylko do odczytu. Przewodnik po MCP dla baz danych porównuje serwery i ich przełączniki trybu tylko do odczytu. Nie używaj @modelcontextprotocol/server-postgres: npm oznacza go jako przestarzały.

Jak przenieść wolną pracę do kolejki BullMQ, nie gubiąc zadań?

Pierwsza wersja agenta wykonuje pracę wewnątrz żądania albo ponawia nieidempotentne zadanie i wysyła e-mail dwa razy.

Prompt do skopiowania: worker BullMQ z ponowieniami i czystym shutdownem

Move image processing out of the upload request into BullMQ 6. Install bullmq and
ioredis (ioredis is an optional peer dependency in BullMQ 6). src/queue/images.ts
exports a typed Queue with defaultJobOptions { attempts: 5, backoff: { type:
'exponential', delay: 1000 }, removeOnComplete: 1000 }. src/workers/images.ts runs
a Worker with concurrency 4 on its own ioredis connection created with
maxRetriesPerRequest: null. Make the processor idempotent: it checks whether the
output already exists before it writes. BullMQ has no dead-letter queue: on the
final failed attempt, record the job in a FailedJob table and log at error level.
Schedule the nightly cleanup with queue.upsertJobScheduler, not the old repeat
option. On SIGTERM call worker.close() so active jobs finish. Tests against a
Testcontainers Redis: a job that throws twice then succeeds completes on attempt 3,
a job that always throws lands in FailedJob, and re-running a completed job writes
nothing new.

Test idempotencji sprawia, że ponowienia są bezpieczne. Bez niego ponowienie po timeoucie, który nastąpił już po udanym zapisie, tworzy zduplikowane pliki, e-maile lub obciążenia karty.

Jak uzyskać ustrukturyzowane logi, które nigdy nie ujawniają sekretów?

Pierwsza wersja agenta loguje req.body, więc hasła i tokeny trafiają do wyszukiwarki logów.

Prompt do skopiowania: logowanie żądań w Pino z redakcją

Add pino and pino-http. JSON to stdout in every environment; pretty output only when
NODE_ENV is development. genReqId takes X-Request-Id when present, otherwise
crypto.randomUUID(), and echoes it in the response header. Redact with censor
'[REDACTED]' these paths: req.headers.authorization, req.headers.cookie,
*.password, *.token, *.refreshToken, *.secret. Pass req.log into services instead
of importing a global logger, so every line carries the request ID. Log errors once,
in the error middleware. Tests capture log output through a destination stream and
assert that a login request's logs contain no password or token value and that every
line of one request shares the same reqId.

Test redakcji to jedyny sposób, żeby wiedzieć, że redakcja działa; ścieżka, która nie pasuje do rzeczywistego kształtu obiektu, zawodzi po cichu. Dashboardy, alerty i tracing na bazie tych logów opisują wzorce monitoringu i logowania.

Jak zweryfikować Node.js napisany przez agenta bez czytania każdej linijki?

Czytaj wynik bramek i listy przypadków testowych, a nie diff. Każda bramka poniżej łapie klasę błędów, która w code review wygląda poprawnie.

Bramka	Polecenie	Co łapie
Typy	tsc --noEmit	Niezgodne kształty danych między warstwami, nieobsłużone undefined, literówki w polach
Linter	eslint . z regułami typescript-eslint opartymi na typach	Porzucone obietnice (no-floating-promises), niewłaściwie użyte obietnice w callbackach (no-misused-promises), niebezpieczne any
Testy jednostkowe i HTTP	vitest run z supertestem	Kody statusu, treść błędów, walidacja, redakcja, shutdown
Testy integracyjne	Testcontainers z Postgresem i Redisem	Błędny SQL, brakujące ograniczenia unikalności, wyścigi takie jak nadsprzedaż, wspólne liczniki rate limitu
Zależności	npm audit --omit=dev --audit-level=high	Znane podatności w zależnościach produkcyjnych
Obciążenie	npx autocannon -c 100 -d 30 https://staging.example.com/api/v1/orders na stagingu	Wyczerpanie puli, blokowanie pętli zdarzeń, rosnące zużycie pamięci
Agent recenzujący	/code-review (Claude Code), codex review --base main (Codex), Bugbot (Cursor)	Błędy logiczne i brakujące przypadki, których bramki nie wyrażą

Na szczególną uwagę zasługuje no-floating-promises: obietnica, na którą agent zapomniał dać await, staje się nieobsłużonym odrzuceniem, a Node.js domyślnie kończy proces przy nieobsłużonych odrzuceniach od wersji 15. Mocniejszy dowód, że same testy są dobre, opisuje strona o testach mutacyjnych i sile wyroczni.

Pięć pierwszych bramek uruchamiaj w CI przy każdym pull requeście; plik workflow znajdziesz we wzorcach pipeline’ów CI/CD. Inżynier odpowiedzialny za usługę zatwierdza trzy rzeczy: listy przypadków testowych, zieloną bramkę i wynik testu obciążeniowego. Ludzka lektura trafia do fragmentów oznaczonych przez agenta recenzującego oraz do kodu, który dotyka uwierzytelniania, pieniędzy lub transakcji. Podział tej pracy w zespole opisuje recenzja PR z agentem.

Gdy Node.js napisany przez agenta psuje się na produkcji

Każda z poniższych awarii przechodzi zestaw testów happy path. Każda ma objaw, który wykryjesz, i sposób naprawy, który zastosujesz.

• Nadsprzedaż albo podwójne przetwarzanie pod obciążeniem. Objaw: ujemny stan magazynu, zduplikowane zamówienia lub e-maile po skoku ruchu. Przyczyna: logika „odczytaj, a potem zapisz” poza jedną atomową instrukcją albo nieidempotentne zadanie, które zostało ponowione. Naprawa: dodaj współbieżny test Testcontainers z przepisu o Prisma, a potem użyj promptu: „Find every place that reads a value, decides in JavaScript, and writes it back. Replace each with a conditional update or a row lock, and add a concurrent test for each.”
• Wyczerpanie połączeń. Objaw: żądania wiszą, a potem kończą się timeoutem, choć CPU bazy jest niskie. Przyczyna: new PrismaClient() na żądanie albo na moduł, często dodane, gdy agent tworzy nowy plik. Naprawa: grep -rn "new PrismaClient" src/ musi zwracać jedną linię. Sam grep kończy się kodem 0 w obu przypadkach, więc testem musi być liczba linii: dodaj do scripts wpis "check:prisma": "test $(grep -rn 'new PrismaClient' src/ | wc -l) -eq 1" i dopisz && npm run check:prisma do check, żeby bramka odrzucała drugiego klienta.
• Idiomy Expressa 4 w aplikacji na Expressie 5. Objaw: serwer nie startuje z błędem path-to-regexp „Missing parameter name” albo wrapper catchAsync ukrywa błąd. Przyczyna: dane treningowe zdominowane przez Express 4. Naprawa: użyj promptu: „Migrate this codebase to Express 5 idioms: name every wildcard route (/*splat), delete catchAsync and express-async-errors, and change no behaviour. Done means npm run check passes.”
• Wszyscy naraz dostają limit. Objaw: skok odpowiedzi 429 u wszystkich użytkowników albo błąd walidacji express-rate-limit dotyczący X-Forwarded-For. Przyczyna: brak trust proxy lub wartość niezgodna z liczbą proxy, więc wszyscy klienci dzielą adres IP load balancera. Naprawa: ustaw trust proxy na rzeczywistą liczbę przeskoków i sprawdź w teście, że req.ip to adres klienta, gdy ustawiony jest X-Forwarded-For.
• Instalacja psuje się na tagach wersji. Objaw: npm install kończy się błędem ERESOLVE, bo typescript-eslint 8.70.1 deklaruje typescript <6.1.0, a typescript@latest to 7.0.2, albo wynik prisma generate przestaje pasować do klienta, bo CLI pochodzi z release candidate Prisma 8. Naprawa: przypnij oba pakiety do dokładnych wersji w package.json, zacommituj lockfile i zapisz w AGENTS.md, że agent nie zmienia przypiętych wersji bez pytania.
• Agent osłabia test, żeby dojść do zielonego wyniku. Objaw: poluzowana asercja, usunięty przypadek albo dodane .skip w tym samym diffie co poprawka. Naprawa: przywróć plik testu, powtórz regułę z AGENTS.md i skonfiguruj CI tak, żeby odrzucał pull request zmieniający istniejący *.test.ts bez etykiety test-change.

Uwaga

„Testy przechodzą” to słaby dowód, gdy chodzi o współbieżność w Node.js. Każdy przepis z tej strony przejdzie test pojedynczego żądania, nawet jeśli jest błędny. Traktuj współbieżne testy integracyjne i test obciążeniowy jako część definicji „gotowe”, a nie opcjonalne utwardzanie.

Dokąd dalej z usługami Node.js

• Jeśli repozytorium nie jest jeszcze gotowe na agenta, zacznij od tego: kod gotowy na agenta.
• Zaprojektuj kontrakt API przed handlerami: wzorce tworzenia API.
• Utwardź warstwę danych: dobre praktyki ORM i wzorce migracji baz danych.
• Wdróż usługę: wzorce Dockera i wzorce pipeline’ów CI/CD.
• Zdecyduj, co agent może uruchamiać bez nadzoru: uprawnienia i sandboxing.
• Porównaj z innym stosem backendowym: przepisy na Pythona albo wróć do przeglądu przepisów backendowych.