Przepisy na Nuxt 4 z agentami AI

Przepisy Nuxt dla agentów AI opierają się na trzech ruchach: przypięciu agenta do dokumentacji Nuxt 4 przez oficjalny serwer MCP Nuxt, bo agenci mieszają API Nuxt 3 i niewydanego Nuxt 5; zapisaniu konwencji Nuxt 4 w pliku instrukcji agenta; oraz dowodzeniu każdej zmiany przez nuxt typecheck, @nuxt/test-utils i nuxt build. Przepisy dotyczą Nuxt 4.5.

Ta strona jest dla programistów, którzy pozwalają Claude Code, Codeksowi lub Cursorowi budować aplikację full-stack w Nuxt, i dla tech leada, który musi ufać wynikowi. Funkcja od agenta działa na twojej maszynie, ale strony wylądowały w pages/ zamiast w app/pages/, schemat Zod trafił wprost do readValidatedBody, a plugin uruchamiany także na serwerze czyta document.cookie. Strona działa po nawigacji po stronie klienta, ostrzeżenia o hydracji przewijają się w konsoli, a pierwszy użytkownik, który otworzy głęboki link bezpośrednio, dostaje 500.

Co dają te przepisy Nuxt

• Konfigurację kontekstu, która trzyma agenta przy Nuxt 4, choć dane treningowe (Nuxt 3) i najnowsze dokumenty oraz skille (Nuxt 5) ciągną go gdzie indziej
• Oficjalny serwer MCP Nuxt podłączony do wszystkich trzech narzędzi oraz eksperymentalny moduł MCP dla serwera deweloperskiego
• Siedem promptów do zadań Nuxt, które agenci psują najczęściej: walidowane trasy serwera, pobieranie danych, sesje, renderowanie hybrydowe, Cloudflare Workers, Nuxt Content i zestaw testów
• Tabelę bramek, która zatwierdza zmianę bez czytania każdej linii, i tabelę awarii z krokami naprawczymi

Wersje sprawdzone 2026-09-26

Rejestr npm: nuxt 4.5.2 (latest; tag 3x to 3.21.11), nitropack 2.13.4 z h3 1.15.x, @nuxt/test-utils 4.3.2, @nuxt/content 3.16.1, @nuxt/image 2.1.0, nuxt-auth-utils 0.5.30, nuxt-mcp-dev 0.3.2. Dwie pułapki: tag latest pakietu h3 to 2.0.1-rc.32, więc npm install h3 instaluje serwerowe API Nuxt 5; a gałąź main dokumentacji Nuxt opisuje już Nuxt 5, który jest „still in development” i nie ma wydania pakietu nuxt (są tylko buildy nuxt-nightly).

Jak utrzymać agenta przy dokumentacji Nuxt 4

Agent piszący kod Nuxt korzysta z trzech źródeł, które sobie przeczą. Jego dane treningowe to głównie Nuxt 3, z pages/ w katalogu głównym i data domyślnie równym null. Najnowsze materiały opisują Nuxt 5: Nitro v3, h3 v2 i helpery serwerowe importowane z nuxt/server, które pojawiają się dopiero w Nuxt 4.6. Twój package.json mówi 4.5. Każdy krok poniżej służy temu, żeby wygrało to trzecie źródło.

1. Zapisz reguły Nuxt 4 tam, gdzie każde narzędzie je znajdzie: w AGENTS.md dla Codeksa, w CLAUDE.md dla Claude Code (albo w CLAUDE.md zawierającym @AGENTS.md; od v2.1.277 Claude Code czyta AGENTS.md, gdy nie ma CLAUDE.md) i w projektowej regule (Rule) w Cursorze.

   ## Nuxt rules for this repo (Nuxt 4.5, nitropack 2, h3 1.x)
   - Vue code lives in app/ (app/pages, app/components, app/composables, app/middleware,
     app/plugins). server/, shared/, content/, public/ and nuxt.config.ts stay at the root.
   - Code used by both app and server goes in shared/utils or shared/types.
   - Look up APIs in the Nuxt 4.x docs (Nuxt MCP server, version 4.x). Never apply Nuxt 5
     guidance: no h3 v2 APIs, and no nuxt/server imports until nuxt >= 4.6.
   - createError takes { status, statusText } (statusCode/statusMessage are deprecated).
   - Never add h3 or nitropack to package.json; use the versions Nuxt brings.
   - readValidatedBody / getValidatedQuery take a function: readValidatedBody(event, Schema.parse).
   - useFetch/useAsyncData: data and error start as undefined; branch on status, not pending.
   - No browser globals (window, document, localStorage) in setup, plugins or middleware
     unless guarded by import.meta.client or inside onMounted.
   - Done means: npx nuxt typecheck, npx eslint ., npx vitest run and npx nuxt build pass.

2. Podłącz serwer MCP Nuxt (następna sekcja) i każ agentowi pytać go z filtrem wersji 4.x. Narzędzie list-documentation-pages przyjmuje 3.x, 4.x, 5.x albo all, więc zapytanie bez filtra może zwrócić strony Nuxt 5. Filtr nie przypina wersji: dokumentacja 4.x opisuje już funkcje Nuxt 4.6, takie jak nuxt/server, więc zanim zaakceptujesz oparty na nich kod, sprawdź wersję nuxt w package.json.

3. Sprawdź każdy skill Nuxt przed instalacją. Skill nuxt z antfu/skills sam deklaruje, że „is based on Nuxt 5.x (5.0.0-0), generated at 2026-09-25”. W projekcie na Nuxt 4.5 uczy importów z nuxt/server i h3 v2, więc pomiń go, dopóki nie przejdziesz na Nuxt 5. Skill nuxt-ui z nuxt/ui dotyczy @nuxt/ui v4 i możesz go dodać, jeśli używasz tej biblioteki; zobacz instalowanie i zarządzanie skillami.

4. Pokaż przestarzałe wzorce także recenzentowi. To API, po które agent sięga najpierw:

   Agent pisze	Stan w Nuxt 4.5	Zamiast tego
   pages/, components/, composables/ w katalogu głównym nowego projektu	Układ Nuxt 3; Nuxt 4 ustawia srcDir na app/	app/pages/ i tak dalej; starą aplikację przenieś przez npx codemod@latest nuxt/4/file-structure
   readValidatedBody(event, BodySchema)	h3 1.x oczekuje funkcji walidującej	readValidatedBody(event, BodySchema.parse)
   if (data.value === null) albo pending.value jako flaga ładowania	data i error domyślnie są undefined w Nuxt 4	status.value === 'pending' i data.value === undefined
   import { defineEventHandler } from 'nuxt/server'	Pojawia się w Nuxt 4.6 (4.5.x go nie eksportuje)	Auto-importowany defineEventHandler
   routeRules: { '/blog/**': { isr: 3600 } } na Cloudflare lub Node	isr trafia do CDN tylko na Netlify i Vercelu	swr: 3600 wszędzie indziej
   preset: 'cloudflare-pages' dla nowego Workera	Preset dla Pages	preset: 'cloudflare_module', preset zalecany przez Nitro dla Workers

Jak podłączyć agenta do dokumentacji Nuxt i serwera deweloperskiego

Zespół Nuxt utrzymuje serwer MCP dokumentacji pod https://nuxt.com/mcp, po HTTP i bez uwierzytelniania. Jego narzędzia listują i pobierają strony dokumentacji, wpisy na blogu, przewodniki wdrożeniowe, moduły (z README, zgodnością i statystykami pobrań) oraz changelog. Nagłówek X-MCP-Tools ogranicza zestaw ładowanych narzędzi, co obniża koszt kontekstu; zobacz obniżanie kosztu tokenów MCP.

Claude Code

# Terminal, w katalogu głównym projektu. -s project zapisuje .mcp.json, więc zespół go współdzieli.
claude mcp add -s project --transport http nuxt https://nuxt.com/mcp \
  -H "X-MCP-Tools: list-documentation-pages,get-documentation-page,get-module"

Uruchom /mcp w sesji, żeby potwierdzić, że nuxt jest połączony.

Codex

# Terminal. Zapisuje serwer w ~/.codex/config.toml.
codex mcp add nuxt --url https://nuxt.com/mcp

Uruchom codex mcp list, żeby potwierdzić wpis. codex mcp add nie ma flagi nagłówka (sprawdzone w 0.157.1), więc dopisz nagłówek do utworzonego wpisu, w sekcji [mcp_servers.nuxt]:

~/.codex/config.toml

[mcp_servers.nuxt]
url = "https://nuxt.com/mcp"
http_headers = { "X-MCP-Tools" = "list-documentation-pages,get-documentation-page,get-module" }

Cursor

Dodaj serwer do .cursor/mcp.json w katalogu głównym projektu. To kształt, który dokumentacja Nuxt podaje dla Cursora.

{
  "mcpServers": {
    "nuxt": {
      "type": "http",
      "url": "https://nuxt.com/mcp",
      "headers": {
        "X-MCP-Tools": "list-documentation-pages,get-documentation-page,get-module"
      }
    }
  }
}

Serwer dokumentacji zna Nuxt, ale nie zna twojej aplikacji. Do tego służy moduł nuxt-mcp-dev Anthony’ego Fu (oznaczony „Experimental. Use with caution.”), który dodaje endpoint MCP do serwera deweloperskiego pod http://localhost:3000/__mcp/sse i według README sam aktualizuje konfigurację MCP w VS Code, Cursorze, Windsurfie i Claude Code. Włączasz go przez modules: ['nuxt-mcp-dev'] w nuxt.config.ts. Endpoint używa transportu SSE, który Claude Code nadal obsługuje, ale oznaczył jako przestarzały, więc traktuj go jako wygodę, a nie bramkę. Widok strony z przeglądarki da agentowi Playwright MCP; pozostałe serwery dla serwerów deweloperskich porównuje strona serwery MCP narzędzi deweloperskich frameworków.

Jak walidować trasę serwera przez Zod i sprawdzać sesję

Trasy serwera to miejsce, w którym zderzają się nawyki agenta z Nuxt 3 i Nuxt 5. Trasa poniżej potrzebuje zwalidowanej treści żądania, zalogowanego użytkownika i właściwego kodu statusu dla każdego błędu.

Prompt do skopiowania: walidowana trasa POST

Create server/api/posts.post.ts in this Nuxt 4.5 app (nitropack 2, h3 1.x, Zod 4).
Look up server routes in the Nuxt MCP server with version 4.x first.
- Put the Zod schema in shared/types/post.ts so the form can reuse it: title 3-200 chars,
  content min 10 chars, categoryId uuid, tags max 5 strings, publishedAt optional ISO date.
- Handler: const session = await requireUserSession(event) (nuxt-auth-utils), then
  const body = await readValidatedBody(event, PostInput.parse). Pass the parse function,
  not the schema object.
- Insert with Drizzle through server/utils/db.ts. Return 201 via setResponseStatus.
  A duplicate slug returns createError({ status: 409, statusText: 'Duplicate slug' }).
- Do not add h3 or nitropack to package.json and do not import from nuxt/server.
Tests in test/e2e/posts.test.ts with $fetch and setup from @nuxt/test-utils/e2e:
201 on valid input, 400 on each invalid field, 401 without a session, 409 on a duplicate.
Run npx vitest run --project e2e and paste the output.

Kod 400 przy błędnych danych zwraca samo h3: gdy funkcja walidująca rzuci wyjątek, readValidatedBody zamienia go na 400. Dlatego przekazanie obiektu schematu jest groźne. Wywołanie pada przy każdym żądaniu, a test sprawdzający tylko „jakiś błąd” nadal przechodzi.

Jak pobierać dane bez podwójnych żądań i błędów hydracji

Typowa warstwa danych od agenta to $fetch w onMounted, który pobiera dane dwa razy (na serwerze i w przeglądarce) albo wcale na serwerze. Wzorzec Nuxt to useFetch lub useAsyncData w setup, ze stabilnym kluczem i refem status.

Prompt do skopiowania: typowany composable do pobierania danych

Create app/composables/useApi.ts for this Nuxt 4.5 app.
- useApi<T>(path, options) wraps useFetch with: an explicit key built from the path and
  query, baseURL from useRuntimeConfig().public.apiBase, and an onResponseError hook that
  maps the body to an ApiError { statusCode, message, fieldErrors? } defined in shared/types.
- Return { data, error, status, refresh, clear } unchanged from useFetch. Consumers branch
  on status ('idle' | 'pending' | 'success' | 'error'); data starts as undefined.
- Use useFetch only in setup. For mutations triggered by a click, export
  apiPost/apiPut/apiDelete that call $fetch, then refresh() the affected useApi key.
- Cookies on SSR: rely on useFetch forwarding request headers for relative URLs; for
  $fetch calls that run during SSR, use useRequestFetch().
Tests (test/nuxt/useApi.test.ts, environment nuxt): registerEndpoint to mock /api/posts,
mountSuspended a test component that uses useApi, and assert status goes to 'success',
the ApiError mapping on a 422, and that two components with the same key share one request.

Asercja o wspólnym kluczu ma znaczenie. W Nuxt 4 komponenty, które wywołują useAsyncData lub useFetch z tym samym kluczem, dzielą jeden ref data, error i status, a dokumentacja wymaga spójnych opcji w tych wywołaniach. Composable, który buduje klucze z niestabilnych wartości (nowy obiekt przy każdym renderze), psuje współdzielenie, a sprawdzanie typów tego nie wychwyci.

Jak dodać sesje i middleware tras bez wycieków SSR

Uwierzytelnianie obejmuje trasę serwera, middleware trasy, plugin i composable. Agent myli się na granicy SSR: plugin czytający document.cookie wywraca render po stronie serwera, a middleware ufający stanowi klienta przepuszcza spreparowane żądanie. nuxt-auth-utils trzyma sesję w zapieczętowanym ciasteczku i daje requireUserSession na serwerze oraz useUserSession w aplikacji, co usuwa większość ręcznie pisanego kodu tokenów.

Claude Code

Zacznij w trybie planowania (/plan) i zatwierdź listę plików, zanim powstanie jakikolwiek kod. Po zmianie uruchom /code-review i poproś o listę plików w server/api/, które nie wywołują requireUserSession. W CI uruchom ten sam audyt tylko do odczytu: claude -p "…" --allowedTools "Read,Grep,Glob".

Codex

Uruchom zmianę we własnym worktree, żeby niedokończony plugin nie zepsuł ci serwera deweloperskiego: codex exec --worktree --sandbox workspace-write "…". Potem poproś drugą sesję, tylko do odczytu (codex exec --sandbox read-only), o listę niechronionych tras serwera.

Cursor

Użyj Plan Mode do listy plików, a potem przejrzyj w edytorze diffy app/middleware/auth.ts i trasy logowania. Te dwa pliki zawierają wszystkie decyzje. Zanim zaakceptujesz diff, przeszukaj go pod kątem document. i window..

Prompt do skopiowania: sesje z nuxt-auth-utils

Add email and password auth to this Nuxt 4.5 app with nuxt-auth-utils.
1. npx nuxt module add auth-utils. NUXT_SESSION_PASSWORD (32+ chars) comes from .env
   locally and from the host's secret store in production; never commit it.
2. server/api/auth/login.post.ts: validate with readValidatedBody(event, LoginInput.parse),
   verifyPassword against the stored hash, setUserSession with { user: { id, name, role } }.
   Same 401 message for unknown email and wrong password. Rate-limit 5 attempts per
   email per 15 minutes.
3. server/api/auth/register.post.ts with hashPassword; server/api/auth/logout.post.ts
   with clearUserSession.
4. app/middleware/auth.ts (named): if !loggedIn from useUserSession(), navigateTo
   /login with a redirect query. app/middleware/guest.ts sends logged-in users to /dashboard.
5. Every route under server/api/ except auth/* calls requireUserSession; admin routes also
   check session.user.role on the server. The middleware is UX, not security.
No window, document or localStorage anywhere in plugins or middleware.
Tests (e2e): login sets the cookie, /dashboard redirects anonymous users, a non-admin
gets 403 from a direct request to every admin route, logout clears the session.

Jak wybrać tryb renderowania dla każdej trasy

Strony marketingowe mają być statyczne, panel renderowany po stronie klienta lub przy każdym żądaniu, a blog cache’owany. W Nuxt to jeden blok routeRules, a jedyny fakt, który agent myli, to które reguły honoruje twój hosting.

Prompt do skopiowania: renderowanie hybrydowe pod twój hosting

Configure routeRules in nuxt.config.ts for this Nuxt 4.5 app deployed to
Cloudflare Workers (preset cloudflare_module). Look up rendering in the Nuxt MCP
server with version 4.x first.
- '/', '/pricing', '/about': { prerender: true }.
- '/blog/**': { swr: 3600 }. Do not use isr: it reaches the CDN only on Netlify and Vercel.
- '/dashboard/**': { ssr: false }. '/api/**': { headers: { 'cache-control': 'no-store' } }.
- '/old-pricing': { redirect: { to: '/pricing', statusCode: 301 } }.
Then run npx nuxt build and paste the prerendered route list. Add an e2e test that
fetches / and /blog/hello and asserts the cache-control header of each, and one that
/dashboard returns the SPA shell without server-rendered dashboard markup.

Na Vercelu lub Netlify zamień swr na isr i podaj hosting w prompcie. Nitro przekłada reguły tras na natywne reguły CDN tylko tych dwóch platform.

Jak wdrożyć na Cloudflare Workers z D1 i KV

Preset cloudflare_module w Nitro buduje moduł Workers, a cloudflare.deployConfig: true generuje wrangler.json. Bindingi docierają do kodu serwera przez event.context.cloudflare.env. Dwa klasyczne błędy agenta to preset dla Pages i kolizja nazwy bindingu z Nuxt Content, który domyślnie używa bindingu D1 o nazwie DB.

Prompt do skopiowania: wdrożenie na Cloudflare Workers

Prepare this Nuxt 4.5 app for Cloudflare Workers. Read the Cloudflare deployment docs
page through the Nuxt MCP server first (get-documentation-page, version 4.x).
- nuxt.config.ts: nitro: { preset: 'cloudflare_module', cloudflare: { deployConfig: true,
  nodeCompat: true } }, with a D1 binding named APP_DB and a KV binding named SESSIONS
  declared in the generated wrangler config: d1_databases: [{ binding: 'APP_DB',
  database_name: '<name>', database_id: '<id>' }], kv_namespaces: [{ binding: 'SESSIONS',
  id: '<id>' }]. Ask me for the names and ids; do not invent them.
  Use the binding name APP_DB so it cannot collide with Nuxt Content's default DB binding.
- server/utils/cf.ts: typed accessor useCf(event) returning event.context.cloudflare.env,
  throwing a 500 with a clear message when the binding is missing (it is undefined in
  plain nuxt dev without the Cloudflare dev preset).
- Drizzle with the D1 driver in server/utils/db.ts; migrations with drizzle-kit into
  server/db/migrations.
- Secrets (NUXT_SESSION_PASSWORD and others) go through wrangler secret put, never into
  wrangler.json or nuxt.config.ts.
Verify locally: npx nuxt build, then npx wrangler dev, then run the e2e suite against it.
Do not run wrangler deploy; CI deploys.

O samej platformie Workers (Queues, Durable Objects, limity) przeczytasz we wzorcach serverless; jeśli agent ma zaglądać do twojego konta Cloudflare, zobacz serwer MCP Cloudflare. Wzorce schematów i migracji Drizzle opisują dobre praktyki ORM.

Jak zbudować blog na Nuxt Content 3

Nuxt Content 3 zastąpił API zapytań z v2 kolekcjami deklarowanymi w content.config.ts i odpytywanymi przez queryCollection(), z SQLite pod spodem (na Cloudflare to D1). Agent wytrenowany na v2 pisze queryContent() i <ContentDoc>, których już nie ma.

Prompt do skopiowania: blog na Nuxt Content 3

Add a blog with @nuxt/content 3 to this Nuxt 4.5 app. Look up the collections API in
the Nuxt MCP server (get-module for @nuxt/content) first. Do not use queryContent,
ContentDoc or any v2 API.
- content.config.ts: a blog collection, type 'page', source 'blog/**/*.md', schema with
  Zod: title, description, date, tags (string array), draft (boolean, default false).
- app/pages/blog/index.vue: useAsyncData('blog-list', () => queryCollection('blog')
  .where('draft', '=', false).order('date', 'DESC').all()), paginated 10 per page.
- app/pages/blog/[...slug].vue: queryCollection('blog').path(route.path).first(),
  ContentRenderer, a 404 via createError({ status: 404 }) when nothing matches,
  and useSeoMeta with title and description from the document.
- server/routes/rss.xml.ts returning published posts as RSS 2.0.
Tests: a draft post never appears in the list, the RSS feed, or at its URL; a missing
slug returns 404. Run npx nuxt build and confirm no content build errors.

Jak skonfigurować testy Nuxt, które agent uruchamia za każdym razem

Testy chronią cię tylko wtedy, gdy agent uruchamia je po każdej edycji. @nuxt/test-utils 4.x dzieli pracę na projekty Vitest: zwykłe testy jednostkowe w Node, testy w runtime Nuxt (komponenty, composables, pluginy) w środowisku nuxt oraz testy end-to-end, które budują i serwują aplikację.

Claude Code

Dodaj hook Stop, którego skrypt uruchamia npx nuxt typecheck && npx vitest run i przy błędzie kończy się kodem 2. Błąd wraca wtedy do agenta, zamiast kończyć turę. Zobacz automatyzację hookami.

Codex

Wpisz linię „Done means” z bloku reguł do AGENTS.md i wymagaj wyniku poleceń w końcowej wiadomości. W CI codex exec --sandbox workspace-write -o result.md "…" zapisuje tę wiadomość do result.md, którą zadanie CI może opublikować jako artefakt.

Cursor

Trzymaj linię „Done means” w projektowych regułach (Rules) i uruchamiaj testy w zintegrowanym terminalu po każdym kroku agenta. Stack trace z nieudanego mountSuspended wklej do czatu, zamiast go opisywać.

Prompt do skopiowania: testy z @nuxt/test-utils

Set up testing for this Nuxt 4.5 app with @nuxt/test-utils, Vitest, @vue/test-utils
and happy-dom. Follow the 4.x testing docs from the Nuxt MCP server.
- vitest.config.ts with test.projects: unit (test/unit, environment node), e2e
  (test/e2e, environment node) and nuxt (test/nuxt, created with defineVitestProject,
  environment nuxt). Add "type": "module" to package.json if missing.
- test/nuxt: mountSuspended tests for AppHeader, PostCard and LoginForm; registerEndpoint
  for every API they call; mockNuxtImport only where a composable must be faked.
- test/e2e: setup({ server: true }) and $fetch for two API routes.
- package.json scripts: test (vitest run), test:unit, test:nuxt, test:e2e, typecheck
  (nuxt typecheck, with vue-tsc and typescript as devDependencies).
Never mix @nuxt/test-utils/runtime and @nuxt/test-utils/e2e in one file.
Run all projects and paste the summary. Break one assertion on purpose, show that it
fails, then restore it.

Celowo zepsuta asercja na końcu to najtańszy dowód, że testy w ogóle potrafią nie przejść. Test od agenta, który przechodzi bez względu na kod, jest gorszy niż brak testu.

Jak weryfikować kod Nuxt od agenta bez czytania każdej linii

Czytaj diffy nuxt.config.ts, wszystkiego w app/middleware/ i app/plugins/ oraz każdej trasy serwera, która czyta sesję. Resztę niech udowodnią bramki.

Bramka	Polecenie lub narzędzie	Co się zaświeci na czerwono
Typy	npx nuxt typecheck	Złe typy zwracane z useFetch, import z nuxt/server w Nuxt 4.5, wspólny typ, za którym klient nie poszedł
Lint	npx eslint . z @nuxt/eslint 1.17.0	Nieużywane auto-importy, globalne obiekty przeglądarki tam, gdzie zakazujesz ich przez no-restricted-globals
Testy jednostkowe i runtime	npx vitest run --project unit --project nuxt	Zachowanie composables, stany komponentów, zamockowane endpointy
End-to-end	npx vitest run --project e2e albo Playwright na npx nuxt preview	Obejście autoryzacji, kody statusu, nagłówki cache, przekierowania
Build	npx nuxt build	Błędy prerenderingu, błędy parsowania Nuxt Content, problemy z presetem
Hydracja	Test Playwright, który pada na każdym komunikacie console zawierającym Hydration	Różny markup z serwera i klienta
Bundle	npx nuxt analyze (eksperymentalne)	Zależność, która podwoiła bundle klienta

Programista odpowiedzialny za pull request zatwierdza wyniki bramek i wymienione wyżej pliki; resztę wymusza CI. Jak taki przegląd skalować na zespół, opisuje przegląd pull requestów od agentów, a jak pisać kryteria akceptacji, które kodują twoje testy e2e, pokazuje strona kryteria akceptacji, które agent potrafi zweryfikować.

Kiedy kod Nuxt od agenta się psuje

Objaw	Przyczyna	Naprawa
Każdy POST do nowej trasy zwraca 400	readValidatedBody(event, Schema) z obiektem schematu	Przekaż Schema.parse; dodaj test, że poprawna treść żądania zwraca 2xx, a nie tylko że błędne padają
Nowe strony dają 404	Pliki w głównym pages/, a aplikacja używa app/ (albo odwrotnie)	Przenieś je do app/pages/; trzymaj regułę katalogów w AGENTS.md
Cannot find module 'nuxt/server' albo błędy h3 o event.req	Wskazówki dla Nuxt 4.6+ lub Nuxt 5 (dokumentacja 4.x opisuje już 4.6; gałąź main dokumentacji i skille dla Nuxt 5 opisują 5)	Zanim zaakceptujesz importy z nuxt/server, sprawdź wersję nuxt w package.json; na 4.5 usuń bezpośrednią zależność od h3 i wróć do auto-importów
document is not defined podczas SSR	API przeglądarki w pluginie, middleware lub setup	Osłoń przez import.meta.client, przenieś do onMounted albo nazwij plugin *.client.ts
Ostrzeżenia o niezgodności hydracji	Date.now(), Math.random() lub formatowanie zależne od locale w renderze	Policz wartość na serwerze i przekaż przez useState albo owiń widżet w <ClientOnly>
Strona pokazuje dane z innego żądania	Dwa wywołania useFetch dzielą klucz przy różnych opcjach	Buduj klucze z pełnego URL i query; przy wspólnym kluczu trzymaj identyczne opcje
Strony bloga nigdy się nie odświeżają po isr: true	Bez TTL isr: true trzyma stronę do następnego wdrożenia; poza Netlify i Vercelem isr działa jak swr i nie trafia do cache CDN	Użyj swr z TTL; dodaj test e2e nagłówków cache
Zapytania D1 trafiają do złej bazy po dodaniu Nuxt Content	Oba używają bindingu DB	Zmień nazwę bindingu aplikacji (na przykład APP_DB) i wdróż ponownie

Dokąd dalej z Nuxt i agentami

• Zacznij od przeglądu przepisów frontendowych, gdzie jest konfiguracja przeglądarki i bramek, którą zakłada każdy przepis.
• Wzorce komponentów i Pinia rozwiniesz w przepisach Vue.js.
• Zestaw testów przeglądarkowych za bramką e2e zbudujesz według strony testy end-to-end z agentami.
• Porównaj Nuxt ze stosem Reacta w przepisach optymalizacji Next.js.
• Inne skille do pracy z Vue i Nuxt znajdziesz w zestawieniu najlepszych skilli do frontendu, a aktualną dokumentację reszty stosu da agentom Context7.