Przepisy workflow Vue.js

Przepisy Vue.js dla agentów AI to gotowe prompty, dzięki którym Claude Code, Codex lub Cursor piszą produkcyjny kod w Vue 3.5. Każdy przepis łączy prompt z kontrolą, która dowodzi wyniku: vue-tsc, reguły utraty reaktywności z eslint-plugin-vue, Vitest z Vue Test Utils i skan dostępności w Playwright. Najważniejsze jest przypięcie wersji, bo popularne pakiety Vue różnią się co do wspieranych wersji.

Ta strona jest dla programistów Vue i tech leadów, którzy ustalają konwencje pracy z agentami w zespole. Prosisz agenta o store, a on pisze Vuex w Options API. Prosisz o formularz, a on instaluje @vee-validate/zod, który jako peer deklaruje Zod 3, choć projekt działa na Zod 4. Komponent się renderuje, zdestrukturyzowane pole store’a po cichu przestaje się aktualizować, a nic nie pada, dopóki użytkownik nie zmieni ilości w koszyku.

Co dają ci te przepisy Vue

• Blok przypinający wersje do CLAUDE.md, AGENTS.md lub reguły Cursora, który trzyma agenta przy <script setup>, Pinia 4 i pakietach, które naprawdę są w twoim lockfile’u
• Jedno polecenie verify, które agent uruchamia, zanim zgłosi sukces, więc przeglądasz zieloną bramkę zamiast każdej linii
• Osiem promptów do zadań, o które agentów prosi się najczęściej: typowane komponenty, store’y Pinia, composables, formularze wieloetapowe, długie listy, leniwe trasy, i18n i migracje z Options API, a do tego konfiguracja Storybooka
• Tabelę, która pokazuje, jaka bramka łapie jaką klasę błędów i kto zatwierdza zmianę
• Typowe awarie kodu Vue pisanego przez agenta i sposób wyjścia z każdej z nich

Wersje sprawdzone 2026-09-26

Rejestr npm: vue 3.5.43, pinia 4.0.3, @pinia/testing 2.0.1, pinia-plugin-persistedstate 4.7.1, vue-router 5.3.1, vue-i18n 11.4.12, @vueuse/core 15.0.0, vee-validate 4.15.1, zod 4.6.5, @tanstack/vue-virtual 3.13.39, vue-tsc 3.3.11, eslint-plugin-vue 10.11.1, vite 8.3.1, vitest 5.0.2, @vue/test-utils 2.5.1, storybook 10.6.0, @axe-core/playwright 4.13.0, msw 2.15.0. CLI: Claude Code 2.1.283, Codex CLI 0.157.1.

Najpierw przypnij stos Vue w kontekście agenta

Agenci uczyli się Vue na latach tutoriali do Vue 2, Vuex i Options API oraz na README pakietów sprzed tegorocznych dużych wydań. Wpisz wersje, zakazane wzorce i polecenie „gotowe” do instrukcji, które czyta twoje narzędzie: CLAUDE.md dla Claude Code, AGENTS.md dla Codex i reguła projektu dla Cursora. Claude Code od v2.1.277 czyta też AGENTS.md, gdy projekt nie ma CLAUDE.md.

## Frontend stack (Vue)
- Vue 3.5 with <script setup lang="ts"> only. TypeScript strict. Vite 8, Vitest 5,
  Vue Test Utils 2, Playwright for e2e.
- State: Pinia 4 setup stores. Routing: Vue Router 5. i18n: vue-i18n 11 with legacy: false.
  Utilities: check @vueuse/core before writing a composable (useFetch, useWebSocket,
  useColorMode, useRefHistory already exist).
- Validation: Zod 4 schemas. Do not install @vee-validate/zod (its peer range is Zod 3).
- Never write: Options API in new files, Vuex, `this.$store`, destructuring a store or a
  reactive() object without storeToRefs/toRefs, `as any`, `<Suspense>` for route loading.
- Before you say a task is done, run `npm run verify` and paste the last 20 lines of output.
- Tests find elements by role and label text, never by CSS class.

Poniższe pułapki sprawdziliśmy w opublikowanych pakietach 2026-09-26. W każdej z nich domyślny wybór agenta albo pierwsze znalezione README daje coś, co się instaluje, a potem działa źle:

Agent pisze	Co mówi rejestr 2026-09-26	Napisz zamiast tego
createI18n({ locale: 'en' })	W vue-i18n 11.4.12 legacy domyślnie ma wartość true i jest oznaczone jako „will be removed at vue-i18n v12”	createI18n({ legacy: false, ... }) i useI18n()
npm i @vee-validate/zod przy Zod 4	@vee-validate/zod 4.15.1 deklaruje peerDependencies: { zod: "^3.24.0" }	Walidacja przez safeParse schematu Zod 4 w małym composable, jak w przepisie na formularz poniżej
import { expect } from '@storybook/test'	Pakiet zatrzymał się na 8.6.15; Storybook 10.6.0 dostarcza go jako storybook/test	import { expect } from 'storybook/test'
@storybook/addon-vitest obok Vitest 5	Zakres peer w 10.6.0 to vitest ^3.0.0 || ^4.0.0	Najpierw sprawdź zakres peer, jak w przepisie na Storybooka poniżej
vite-plugin-vue-mcp w aplikacji na Vite 8	Zakres peer w 0.3.2 kończy się na Vite 6	Chrome DevTools MCP lub Playwright MCP podłączone do serwera deweloperskiego
const { items } = useCartStore()	Reaktywność ginie: items to migawka	const { items } = storeToRefs(useCartStore())

Daj agentowi jedno polecenie, które dowodzi zmiany

Dodaj jeden skrypt łączący wszystkie bramki i każ agentowi uruchomić go, zanim zgłosi ukończenie:

{
  "scripts": {
    "verify": "vue-tsc --noEmit && eslint . --max-warnings 0 && vitest run && playwright test --grep @a11y"
  }
}

Ostatni krok uruchamia tylko testy z @a11y w tytule, więc w świeżym projekcie nie trafia w nic, dopóki nie dodasz takiego testu. Zacznij od jednego skanu axe dla strony i dopisuj test dla każdego widoku, który budujesz:

e2e/a11y.spec.ts

import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

test('home page has no axe violations @a11y', async ({ page }) => {
  await page.goto('/');
  const results = await new AxeBuilder({ page }).analyze();
  expect(results.violations).toEqual([]);
});

eslint-plugin-vue 10 ma preset flat/recommended, ale dwie reguły, które łapią najczęstszy błąd agenta w Vue, czyli utratę reaktywności, nie należą do tego presetu. Włącz je sam:

eslint.config.js

import pluginVue from 'eslint-plugin-vue';

export default [
  ...pluginVue.configs['flat/recommended'],
  {
    rules: {
      'vue/no-ref-object-reactivity-loss': 'error',
      'vue/no-setup-props-reactivity-loss': 'error',
      'vue/require-explicit-emits': 'error',
      'vue/no-v-html': 'error',
    },
  },
];

Dodaj w tym samym pliku konfigurację parsera TypeScript (na przykład typescript-eslint). Sposób, w jaki zmuszasz agenta do uruchomienia verify, zależy od narzędzia:

Claude Code

Wpisz regułę do CLAUDE.md jak w bloku powyżej. Żeby ją egzekwować, a nie tylko o nią prosić, dodaj hook Stop, który uruchamia npm run verify i blokuje zakończenie, gdy się nie powiedzie; zobacz automatyzację hookami. W trybie bezobsługowym w CI ten sam prompt przyjmuje claude -p.

Codex

Wpisz regułę do AGENTS.md, który Codex wczytuje na początku sesji. W CI codex exec uruchamia prompt bez interakcji; npm run verify uruchom jako następny krok joba, żeby job padał razem z bramką, niezależnie od tego, co zgłosił agent.

Cursor

Wpisz blok przypinający wersje do reguły projektu w Cursorze (Rules). Cursor Hooks potrafią uruchomić skrypt w określonych punktach pętli agenta, więc bramka nie zależy od tego, czy agent pamięta regułę. Bugbot przegląda potem pull request jako druga opinia, a nie jako bramka.

Wczytaj skille Vue przed pierwszym promptem

Repozytorium vuejs-ai/skills pakuje wiedzę o Vue jako skille agenta: vue-best-practices, vue-pinia-best-practices, vue-router-best-practices, vue-testing-best-practices, vue-debug-guides i create-adaptable-composable. README nazywa je „early experiment” i projektem społeczności, a skill do routera celuje w Vue Router 4, więc traktuj je jak listę kontrolną recenzenta, a nie bramkę.

Claude Code

claude plugin marketplace add vuejs-ai/skills
claude plugin install vue-best-practices@vue-skills

Codex

npx skills add vuejs-ai/skills --skill vue-best-practices

Cursor

npx skills add vuejs-ai/skills --skill vue-best-practices

README radzi zaczynać prompt od „Use vue skill”, bo skill nie zawsze uruchamia się sam. Jeśli chcesz zestawu dla całego Vite i Nuxta, antfu/skills generuje skille vue, pinia, vite i vitest z oficjalnej dokumentacji. Wczytaj jeden zestaw frameworkowy, nie oba: nakładające się skille konkurują o ten sam kontekst. Więcej opcji znajdziesz w najlepszych skillach do frontendu.

Zbuduj typowany komponent ze script setup

Scenariusz: potrzebujesz komponentu nowej funkcjonalności zgodnego z konwencjami zespołu: typowane propsy, typowane emity i testy, które sprawdzają jedno i drugie.

Prompt do skopiowania: typowany komponent Vue 3.5 z testami

Use vue skill. Create src/components/UserCard.vue with <script setup lang="ts">.
Props: user: User (from @/types), showActions?: boolean (default true),
compact?: boolean (default false). Use Vue 3.5 reactive props destructure with
defaults, not withDefaults. Emits with the tuple syntax:
defineEmits<{ edit: [id: string]; remove: [id: string]; select: [user: User] }>().
Template: avatar with alt text, name, email and role badge; compact hides email
and role; showActions renders Edit and Remove as <button> elements with
accessible names. No Options API, no v-html. Write UserCard.test.ts with Vue Test
Utils and Vitest: one test per prop and one per emit, finding buttons by role.
Run npm run verify.

Skąd wiesz, że zadziałało: verify jest zielone, a nazwy testów czyta się jak listę propsów i emitów. Czytaj nazwy testów, nie szablon. Jeśli test szuka elementu po klasie CSS, odeślij go do poprawki.

Zbuduj store Pinia 4, który pozostaje reaktywny

Scenariusz: store koszyka ma przetrwać odświeżenie strony, pozwalać cofnąć ostatnią zmianę i utrzymywać wszystkie komponenty w synchronizacji.

Prompt do skopiowania: setup store Pinia 4 z persystencją i cofaniem

Create src/stores/cart.ts as a Pinia 4 setup store (defineStore('cart', () => {...})).
State: items (CartItem[]), couponCode (string | null), isCheckingOut (boolean).
Getters as computed: totalItems, subtotal, discount, total.
Actions: addItem, removeItem, updateQuantity (minimum 1), applyCoupon (POST
/api/coupons/validate), clearCart, checkout. Persist items and couponCode only,
with pinia-plugin-persistedstate `pick`; never persist isCheckingOut.
Undo: keep a history stack of the last 20 item snapshots; undo() restores the
previous one. Components must read state with storeToRefs, never destructure the
store directly. Tests: use @pinia/testing createTestingPinia with
createSpy: vi.fn and stubActions: false so the actions really run; mock HTTP
with MSW. Cover each action, undo after add and after remove, and a reload that
restores items but not isCheckingOut. Run npm run verify.

Skąd wiesz, że zadziałało: test przeładowania i oba testy cofania przechodzą, a grep -rn "useCartStore()" src/components pokazuje, że każda destrukturyzacja jest owinięta w storeToRefs. stubActions: false ma znaczenie: createTestingPinia domyślnie podmienia wszystkie akcje na atrapy, więc test akcji bez tej opcji przechodzi, choć akcja nigdy się nie wykonuje.

Wydziel composables bez przepisywania VueUse

Scenariusz: dwanaście komponentów powtarza ten sam wzorzec pobierania danych ze stanem ładowania, wyszukiwanie z debounce i sprawdzanie uprawnień.

Pułapką jest to, że agent pisze własne useFetch albo useWebSocket, choć @vueuse/core 15 eksportuje oba, z opcjami przerwania, automatycznego ponownego łączenia i heartbeatu. Każ mu najpierw sprawdzić.

Prompt do skopiowania: composables z wejściami MaybeRefOrGetter

Find the repeated fetch-with-loading, debounced search and permission-check code
in src/components. For each pattern, first check whether @vueuse/core (installed
version in package.json) already exports it; if it does, use it and do not write
a wrapper. Write only what is missing as composables in src/composables/, one per
file: accept MaybeRefOrGetter inputs and read them with toValue() inside watch or
watchEffect, return refs (never a reactive object that callers will destructure),
and clean up timers and listeners with onScopeDispose. Replace the duplicated
code in the components. Tests: mount a small host component per composable with
Vue Test Utils; use fake timers for debounce. Report which patterns you replaced
with VueUse and which you wrote. Run npm run verify.

Skąd wiesz, że zadziałało: raport wymienia każdy wzorzec raz, diff komponentów usuwa więcej linii, niż dodają composables, a vue/no-ref-object-reactivity-loss milczy. Composable zwracający reactive() oblewa tę regułę w chwili, gdy wywołujący go zdestrukturyzuje.

Waliduj formularz wieloetapowy przez Zod 4

Scenariusz: czteroetapowy formularz zamówienia ma blokować „Dalej” przy błędnych polach, zachowywać dane przy powrocie i przetrwać przypadkowe odświeżenie.

Prompt do skopiowania: formularz wieloetapowy ze schematem Zod 4 na etap

Build the checkout form in src/features/checkout/. Steps: Shipping, Billing,
Payment, Review. One Zod 4 schema per step in schemas.ts; the full form type is
the z.infer of the merged schemas. Use z.email(), not z.string().email().
Do not install vee-validate adapters. Write useStepForm(schema, initial) that
returns the step's reactive model, a validate() that calls schema.safeParse and
maps issues to a per-field error record, and isValid. MultiStepForm.vue holds
the step index and provides next/prev/goTo through a typed InjectionKey; next()
runs validate() first. Persist the draft to sessionStorage, excluding card fields.
Each input has a visible label; errors are linked with aria-describedby.
Tests with Vue Test Utils: Next is blocked on an empty step, back keeps values,
a reload restores the draft without the card number, and submit sends the
parsed data once. Run npm run verify.

Skąd wiesz, że zadziałało: cztery testy przechodzą, grep -rn "vee-validate\|string().email" src package.json nic nie zwraca, a skan axe jest czysty. Wykluczenie pól karty to jedyna linia warta ludzkiego spojrzenia, bo błąd w niej zapisuje dane karty w przeglądarce.

Wyrenderuj 50 000 wierszy bez zamrażania strony

Scenariusz: widok logów w panelu administracyjnym ma pokazać 50 000 wierszy z sortowaniem i filtrowaniem.

Wirtualizacja rozwiązuje renderowanie, ale nie sortowanie uruchamiane przy każdym naciśnięciu klawisza. Proś o zmierzony wynik, nie o listę komponentów. Chrome DevTools MCP daje agentowi ślad wydajności działającej strony; konfigurację dla wszystkich trzech narzędzi znajdziesz w automatyzacji przeglądarki przez MCP.

Prompt do skopiowania: wirtualizowana tabela ze zmierzonym wynikiem

Build a generic VirtualTable.vue in src/components/table/ with @tanstack/vue-virtual:
typed columns (ColumnDef<T>), sortable headers with aria-sort, one text filter per
column, a sticky header, and row selection with Shift+click ranges. Keep the source
array in shallowRef; compute filtered and sorted rows once per filter change, not
per render. Mount it on /admin/logs with 50,000 generated rows.
Then, with the chrome-devtools MCP, record a trace while typing "error" into the
message filter and while scrolling to the bottom. Report the longest task in each
trace. Tests: sorting toggles order, filtering narrows rows, Shift+click selects
a range. Run npm run verify.

Skąd wiesz, że zadziałało: liczby ze śladu są w raporcie, a liczba wierszy w DOM podczas przewijania pozostaje bliska rozmiarowi widoku, a nie 50 000. Zachowaj ślad jako punkt odniesienia; testy wydajności pokazują, jak zamienić go w budżet w CI.

Ładuj trasy leniwie i obsłuż nieudany chunk

Scenariusz: każdy widok trafia do pierwszego bundla, a po każdym wdrożeniu część użytkowników widzi pustą stronę, bo ich karta prosi o chunk, którego już nie ma.

Prompt do skopiowania: leniwe trasy z obsługą błędu chunka

Refactor src/router/index.ts (Vue Router 5) so every view except Home is loaded
with () => import('../views/X.vue'). Do not use <Suspense>; show a route-level
loading bar driven by beforeEach/afterEach. Handle stale chunks after a deploy:
listen for the vite:preloadError window event and for router.onError errors from
failed dynamic imports, and reload once to the target route, with a
sessionStorage guard so it never loops. Then run npm run build and list the
emitted chunk for each route with its size. Tests: navigation to each lazy route
renders its heading; a rejected import triggers exactly one reload. Run
npm run verify.

Skąd wiesz, że zadziałało: wynik builda pokazuje jeden chunk na każdą leniwą trasę, a test przeładowania dowodzi działania zabezpieczenia. Dokumentacja Vue wciąż oznacza <Suspense> jako eksperymentalny, dlatego prompt zakazuje go przy routingu.

Dodaj i18n z leniwie ładowanymi językami

Scenariusz: aplikacja ma tylko angielski, a hiszpański i japoński mają się doładowywać na żądanie bez powiększania pierwszego bundla.

Prompt do skopiowania: vue-i18n 11 w trybie Composition API

Set up vue-i18n 11 in src/i18n/index.ts with createI18n({ legacy: false, locale:
'en', fallbackLocale: 'en' }). Only en.json is bundled; es.json and ja.json load
through loadLocale(locale), which dynamically imports the file, calls
i18n.global.setLocaleMessage, sets the locale and updates <html lang>. In
components use useI18n() and t, d and n; do not use this.$t. Add a
LocaleSwitcher.vue that persists the choice to localStorage. Add a test that
fails if any key in en.json is missing from es.json or ja.json, and a component
test that switching to es changes visible text without a reload. Run
npm run verify.

Skąd wiesz, że zadziałało: test zgodności kluczy przechodzi, grep -rn "legacy: true\|this\.\$t" src nic nie zwraca, a build pokazuje es i ja jako osobne chunki. Test zgodności kluczy powstrzymuje następnego agenta przed dodaniem angielskiego klucza bez dwóch pozostałych.

Przenieś komponent z Options API bez zmiany zachowania

Scenariusz: 500-liniowy komponent w Options API z watcherami i modułem Vuex, bez testów, do przeniesienia na <script setup> i Pinia.

Zanim zaczniesz refaktoryzację, przypnij zachowanie testami. Metodę opisują testy charakteryzujące.

Prompt do skopiowania: najpierw charakteryzuj, potem migruj na script setup i Pinia

Step 1, do not touch src/components/OrderDashboard.vue yet: write characterization
tests that pin its current behaviour - rendered output for three prop sets, every
store action it dispatches and when, emitted events, and what happens when props
change. Run them; they must pass against the Options API version. Commit.
Step 2: convert OrderDashboard to <script setup lang="ts"> and move its Vuex
module to a Pinia setup store with the same state, getters and actions. Do not
edit the tests except the store-mounting helper. Do not change props, emits or
markup. Run npm run verify. If a characterization test fails, fix the component,
not the test.

Skąd wiesz, że zadziałało: ciała testów są identyczne w obu commitach (git diff HEAD~1 -- '*.test.ts' dotyka tylko helpera montującego store) i przechodzą w obu. Ten diff to jedyna rzecz do sprawdzenia ręcznie.

Skonfiguruj Storybook 10 z kontrolą dostępności

Scenariusz: nowe osoby w zespole nie potrafią znaleźć istniejących komponentów, a problemy z dostępnością wychodzą dopiero w review.

Instalator zadaje pytania, więc sposób jego uruchomienia zależy od narzędzia:

Claude Code

Najpierw uruchom npm create storybook@latest we własnym terminalu, odpowiedz na pytania (Vue 3 z Vite), a potem przekaż claude poniższy prompt, żeby napisał historie.

Codex

Uruchom npm create storybook@latest sam albo pozwól zrobić to Codexowi i zatwierdź instalację, gdy o nią poprosi, a potem przekaż mu poniższy prompt.

Cursor

W trybie Agent poproś Cursora, żeby uruchomił npm create storybook@latest w swoim terminalu i odpowiedział na pytania, a potem wklej poniższy prompt.

Prompt do skopiowania: historie Storybook 10 z a11y

Storybook 10 is installed with @storybook/vue3-vite. Before adding addons, run
npm view @storybook/addon-vitest peerDependencies and compare the vitest range
with our installed vitest. If ours is outside the range, do not add
addon-vitest; tell me and continue without it. Add @storybook/addon-a11y and set
it to fail on violations. Write stories for Button, TextField, Modal, Card and
VirtualTable: a Default story, one story per variant, and args typed from the
component props. For Modal, add a play function using storybook/test (not
@storybook/test) that opens it, checks focus moves inside, presses Escape and
checks focus returns to the trigger. Reuse the Vite aliases. Run
npm run build-storybook and npm run verify.

Skąd wiesz, że zadziałało: build-storybook kończy się sukcesem, panel a11y nie pokazuje naruszeń w pięciu komponentach, a funkcja play dla Modal przechodzi. Jeśli agent zgłasza niezgodność zakresu Vitesta, to znaczy, że przepis działa: wymuszona instalacja z --legacy-peer-deps jest złą poprawką.

Jak zweryfikować kod Vue od agenta bez czytania każdej linii

Bramka	Co łapie	Gdzie działa	Kto zatwierdza
vue-tsc --noEmit ze strict	Błędne propsy i emity, zgubione typy generyczne, API, których zainstalowana wersja nie ma	pętla agenta, CI	automatycznie
eslint-plugin-vue z regułami utraty reaktywności na error	Zdestrukturyzowane propsy, refy i store’y, które przestają się aktualizować; niejawne emity; v-html	pętla agenta, CI	automatycznie
Vitest + Vue Test Utils + MSW	Zachowanie po każdej akcji użytkownika, łącznie ze ścieżkami błędów i przeładowaniem	pętla agenta, CI	automatycznie; autor przegląda nazwy testów, nie ich ciała
Testy charakteryzujące, niezmienione w trakcie migracji	Dryf zachowania przy refaktoryzacji	pętla agenta, CI	autor sprawdza diff testów
Test zgodności kluczy tłumaczeń	Brakujące tłumaczenia	pętla agenta, CI	automatycznie
Playwright + @axe-core/playwright, dodatek a11y w Storybooku	Brakujące etykiety, pułapki fokusu, kontrast, role	CI	automatycznie; osoba odpowiedzialna za dostępność przegląda nowe wyjątki
Ślad wydajności przed i po	Regresje w zmienionej interakcji	pętla agenta z Chrome DevTools MCP	autor; budżet w CI, gdy to ważne

Człowiek przegląda to, czego bramki nie sprawdzą: kryteria akceptacji, nazwy testów i każdy diff w pliku testowym. Kryteria akceptacji napisz przed promptem; zobacz kryteria akceptacji. Nie pozwól agentowi edytować własnych testów, żeby przeszły; zobacz ochronę wyroczni. O samym pull requeście, czyli kto go zatwierdza i na jakiej podstawie, mówi przegląd pull requestów od agentów.

Kiedy kod Vue od agenta się psuje

• Reaktywność ginie po cichu. Agent destrukturyzuje store, obiekt reactive() albo wynik composable, a UI przestaje się aktualizować po pierwszym renderze. Wyjście: storeToRefs dla store’ów, toRefs lub zwracanie refów z composables oraz obie reguły utraty reaktywności na error.
• Kod z Vue 2 albo Options API w projekcie na Vue 3.5. W nowych plikach pojawiają się this.$store, data(), Vuex i filtry. Wyjście: blok przypinający wersje, skill Vue oraz reguła lintera albo review, które odrzuca Options API w nowych plikach.
• Niezgodności zakresów peer przepchnięte na siłę. Agent dostaje błąd ERESOLVE z @vee-validate/zod albo @storybook/addon-vitest i ponawia instalację z --legacy-peer-deps. Wyjście: zakaż tej flagi w pliku instrukcji i każ agentowi zgłaszać niezgodność, tak jak robi to prompt do Storybooka.
• Testy store’a, które nigdy nie uruchamiają store’a. createTestingPinia domyślnie podmienia akcje, więc test sprawdza, że wywołano atrapę, a ciało akcji nigdy się nie wykonuje. Wyjście: stubActions: false w testach store’a; podmieniaj akcje tylko w testach komponentów.
• Composable, który powiela VueUse. Agent pisze 200 linii logiki ponownego łączenia, którą useWebSocket już ma. Wyjście: linia „najpierw sprawdź @vueuse/core” w instrukcjach i raport „zastąpione czy napisane”, o który prosi prompt do composables.
• Błędy hydratacji albo window po przejściu aplikacji na SSR. Kod, który czyta window lub localStorage na poziomie modułu, pada na serwerze. Wyjście: kod tylko dla przeglądarki trafia do onMounted; bramki SSR dla renderowanej na serwerze aplikacji Vue opisują przepisy Nuxt.
• Testy, które testują atrapę. Agent mockuje composable, który sam napisał, i sprawdza, co zwróciła atrapa. Wyjście: mockuj na granicy HTTP przez MSW i odrzucaj testy, które robią vi.mock na testowanym module.

Dokąd dalej z Vue i agentami

• Przegląd przepisów frontendowych z pozostałymi frameworkami w tej sekcji
• Przepisy Nuxt o renderowaniu po stronie serwera, trasach serwerowych i wdrożeniu, które ta strona zostawia sąsiadowi
• Testy jednostkowe z agentami i testy dostępności o bramkach stojących za verify
• Playwright MCP, żeby agent sprawdzał działającą aplikację, oraz testy end-to-end dla przepływów obejmujących wiele stron
• Wzorce tworzenia API o backendzie, z którego korzystają te komponenty