Od pierwszego ekranu do własnej aplikacji online

Efekt: Rozumiesz, co zbudujesz, widzisz pełne demo i masz działające środowisko.

1. 1Demo gotowej aplikacji - Pokaz od A do Z: stworzenie quizu, publiczny link, rozwiązanie, leaderboard i feedback AI.
2. 2Setup i terminal - Node, npm, edytor i podstawy terminala - uruchamiasz projekt lokalnie bez strachu przed czarnym oknem.
3. 3Git i GitHub od podstaw - Repozytorium, commity, .gitignore i wypychanie kodu na GitHub - projekt jest bezpieczny i od pierwszego dnia gotowy do portfolio.
4. 4Jak korzystać z Cursora w kursie - Jak promptować, jak weryfikować kod od AI i kiedy mu nie ufać. AI pomaga, ale to Ty rozumiesz każdą linijkę. Do tego uczciwy rachunek: co jest darmowe, a całe AI w kursie kosztuje kilka złotych.
5. 5Wersje w tym kursie - Scaffold przypina Nuxt 4.5.1, Vue 3.5.40, TypeScript 6.0.3 i tooling. AI SDK dochodzi z pierwszym wywołaniem modelu w M5.4 - każda paczka pojawia się przed użyciem.

Checkpoint: Projekt Nuxt odpala się lokalnie, a kod jest wypchnięty na GitHub.

Efekt: Rozumiesz architekturę: klient, serwer, baza, AI - i dlaczego nie wszystko dzieje się w przeglądarce.

1. 1Mapa aplikacji - Co robi frontend, co backend, co baza i w którym miejscu wchodzi AI - pełny obraz, zanim napiszesz pierwszą linijkę.
2. 2Jak komunikuje się web: HTTP i REST - Request i response, metody GET/POST, status code i JSON - wspólny język frontu i backendu, którego użyjesz w każdym endpointcie projektu.
3. 3Przepływ danych w naszej apce - Twórca → AI → baza → publiczny quiz → ocena na serwerze → attempts → leaderboard. Rysujesz diagram przepływu SWOJEJ apki - i wracasz do niego w każdym kolejnym module.
4. 4Zakres MVP i decyzje projektowe - Co budujemy, czego świadomie nie budujemy i dlaczego: bez kont i logowania, bez ORM-a, bez anti-cheatu i płatności - myślenie o zakresie to umiejętność, nie skrót.

Checkpoint: Potrafisz opisać przepływ danych aplikacji: klient → serwer → baza → AI, i wiesz, co wchodzi w MVP.

Efekt: Poznajesz podstawy Vue i budujesz pierwszy działający ekran: formularz tworzenia quizu ze stanami loading/error.

1. 1Vue od zera - własne komponenty formularza - Budujesz BaseInput, BaseSelect i BaseButton, poznajesz props, v-for oraz defineModel. Komponenty montujesz na stronie i łączysz z ref oraz zdarzeniem submit w następnej lekcji.
2. 2Formularz kreatora (na danych testowych) - Budujesz formularz z ref, v-model, @submit.prevent i walidacją tematu. Tymczasowy mock ma trzy pytania: selektor 3-10 zacznie zwracać pełną liczbę dopiero po podłączeniu AI.
3. 3Stany UI - Do istniejącej walidacji dodajesz computed isLoading, symulację setTimeout, czyszczenie poprzedniego wyniku oraz blokadę pól i przycisku.

Checkpoint: Masz działający ekran tworzenia quizu (temat, poziom, liczba pytań) ze stanami loading/error - na razie na danych testowych. Działa też na telefonie.

Efekt: Rozumiesz, co dzieje się na serwerze, a co w przeglądarce - i wiesz, gdzie w projekcie Nuxt trafia każdy plik.

1. 1Jak Nuxt renderuje: SSR, CSR i universal rendering - Co dzieje się na serwerze, co w przeglądarce, czym jest hydration i dlaczego Nuxt domyślnie renderuje uniwersalnie. Rozumiesz różnicę między SSR a CSR i kiedy która ma sens - to wiedza, która zostaje z Tobą poza tym projektem.
2. 2Struktura projektu Nuxt - Jak Nuxt organizuje pages, components, server i composables. Na żywo podmieniasz a na NuxtLink, usuwasz jawne importy komponentów i konfigurujesz pathPrefix: false.

Checkpoint: Potrafisz wyjaśnić, jak renderuje się Twój ekran (SSR/CSR/hydration), a struktura projektu jest gotowa pod backend.

Efekt: Tworzysz server route, ogarniasz async/await i rozumiesz, dlaczego klucz AI nie może trafić do frontendu.

1. 1Server routes / Nitro - Pierwszy endpoint POST i odczyt danych z żądania (readBody).
2. 2.env i runtimeConfig - Sekrety po stronie serwera, bez publicznych prefiksów.
3. 3async/await i fetch: formularz gada z Twoim serwerem - Jak działa Promise, po co await i jak pobrać dane przez fetch - i moment, w którym klik w formularzu po raz pierwszy dostaje odpowiedź z TWOJEGO backendu.
4. 4Pierwsze wywołanie modelu (z twardym limitem wydatków) - Ustawiasz twardy limit u dostawcy, dodajesz przypięty AI SDK i pierwszy helper getAiModel w server/utils, a potem oglądasz surową odpowiedź.
5. 5Obsługa błędów i debugging - Dodajesz createError 400/500, try/catch i response.ok, czytasz stack trace oraz Network, a wspólne komunikaty trafiają do requestMessages.

Checkpoint: Twój endpoint wywołuje model AI z serwera, a klucz API nie wycieka do przeglądarki.

Efekt: Zamieniasz odpowiedź AI w przewidywalne dane, które aplikacja bezpiecznie zapisze i wyrenderuje.

1. 1TypeScript w 15 minut - tyle, ile potrzebujesz - Czym jest typ, typy podstawowe i po co inferencja - na kodzie projektu, bez teorii dla teorii. Dokładnie tyle TS, żeby Zod i cała reszta kursu były przyjemnością.
2. 2Schemat quizu w Zod - Pytanie, odpowiedzi, poprawna odpowiedź, wyjaśnienie, tag kompetencji i wspólne stałe liczby pytań/odpowiedzi w shared/utils.
3. 3Typy w praktyce (TypeScript z Zod) - Ze schematu Zod dostajesz typy przez z.infer i migrujesz dziewięć plików: lang=ts, typowane propsy, generic BaseSelect i pliki serwera .js→.ts.
4. 4Structured output w praktyce - Model zwraca obiekt przez Output.object. Stałe zasady trafiają do instructions, a niezaufany temat użytkownika pozostaje osobno w prompt.
5. 5Walidacja, retry i pierwszy test jakości - Dodajesz safeParse, wspólny retryUntilSuccess, regułę liczby pytań i pierwszy test node:test. Rozróżniasz strukturę, regułę biznesową i późniejszą ocenę jakości.
6. 6Podgląd quizu (render przez v-for) - Renderujesz pełne pytania przez v-for oraz wprowadzasz pierwsze sloty: BaseCard i BaseButton stają się pojemnikami na treść.
7. 7Ile kosztuje Twój quiz? - Kod ustawia maxOutputTokens i loguje tokeny udanej próby. Cenę liczysz ręcznie z cennika providera; odrzucone retry też kosztuje, choć nie trafia do tego logu.

Checkpoint: Po kliknięciu „Wygeneruj” AI zwraca quiz jako zwalidowane dane i widzisz go na ekranie.

Efekt: Dodajesz bazę, zapisujesz challenge i tworzysz publiczną stronę /c/[slug].

1. 1Postgres i model danych w Supabase - Projektujesz challenges oraz attempts: slug, pytania jsonb, wynik, czas i indeks rankingu. Włączasz RLS bez polityk, dodajesz seed, publishable/secret key i reported_at. Report/delete dochodzi w 7.4; stały okres retencji nie jest zaimplementowany.
2. 2Klient Supabase tylko na serwerze - Dodajesz przypięty supabase-js 2.111.0 oraz singleton getSupabaseClient z guardem konfiguracji. Secret key i klient bazy pozostają wyłącznie po stronie serwera.
3. 3Zapis challenge’u i kopiowanie linku - Zapisujesz challenge przez kontrakt i limit payloadu, ponawiasz kolizję UNIQUE sluga, kopiujesz link i obsługujesz odmowę navigator.clipboard.
4. 4Dynamiczna strona quizu - Routing /c/[slug], useFetch, publiczny schemat bez poprawnych odpowiedzi, wspólny requireValidSlug oraz minimalny flow report/delete dla UGC.

Checkpoint: Wchodzisz na /c/twoj-slug i widzisz quiz pobrany z bazy - bez poprawnych odpowiedzi w przeglądarce. Link otwiera się poprawnie także na telefonie.

Efekt: Budujesz flow gracza i uczysz się, dlaczego scoring musi dziać się po stronie serwera.

1. 1Formularz gracza - Nick, przechodzenie przez pytania, zapisywanie wyborów i pomiar czasu.
2. 2Endpoint submit-attempt i test kontraktu - Frontend wysyła odpowiedzi bez poprawnych. Dodajesz HMAC+nonce dla czasu serwera, atomowy limiter generate/save/attempt oraz test samego attemptResultSchema; endpoint zwróci ten kontrakt po zapisie w 8.4.
3. 3Ocena po stronie serwera i test scoringu - Serwer pobiera challenge i liczy wynik: gradeAnswers używa map, countCorrect używa filter. Obie funkcje dostają mały test.
4. 4Zapis podejścia - INSERT do attempts, parse odpowiedzi oraz idempotentny replay przez hash startToken i UNIQUE.
5. 5Ekran wyniku - Punkty, czas serwera, podsumowanie dobrze/źle i wydzielenie wspólnego BaseSpinner.

Checkpoint: Ktoś rozwiązuje quiz z linku - także na telefonie - a serwer liczy wynik i zapisuje podejście w tabeli attempts.

Efekt: Kończysz produkt: ranking, feedback AI po podejściu i CTA zamieniające gracza w twórcę.

1. 1Leaderboard - Sortowanie po wyniku malejąco i czasie rosnąco, top podejścia dla challenge’u.
2. 2Drugie wywołanie AI - Feedback przez buildFeedbackPrompt generujesz na przycisk, zapisujesz i deduplikujesz. Świeże wywołania mają limit 10/h per IP oraz fallback; globalny cap aplikacji pozostaje backlogiem.
3. 3Feedback jako dane (Zod) - Schemat feedbacku, żeby UI było przewidywalne.
4. 4Composables: powtarzalna logika w jedno miejsce - Wydzielasz useChallengeGeneration: status, błąd i fetch trafiają do composable, topicError zostaje na stronie, a start nowej generacji czyści stary podgląd.
5. 5CTA: gracz → twórca - CTA jest NuxtLinkiem, a jego rdzeń klas współdzieli PRIMARY_BUTTON_CLASSES z BaseButton.

Checkpoint: Po podejściu widzisz leaderboard i feedback AI, a przycisk „Stwórz własny challenge” prowadzi do kolejnego challenge’u.

Efekt: Wdrażasz działające MVP na produkcję - masz publiczny adres, który możesz wysłać komukolwiek.

1. 1Deploy na Vercel (i co robić, gdy build się wywali) - Wypychasz aplikację na produkcję, ustawiasz env i czytasz logi. Rozbrajasz trzy awarie: brakujące env, „lokalnie działa” i wielkość liter. Dodajesz alert kosztowy i wiesz, jak obrócić klucz.
2. 2Test na produkcji i prosty rollback - Przechodzisz cały flow na desktopie i telefonie, sprawdzasz logi, a przy błędzie wracasz do poprzedniego działającego deployu.

Checkpoint: Twoja aplikacja działa pod publicznym adresem na Vercel i cały flow przechodzi także na telefonie - MVP gotowe.

Efekt: Porządkujesz projekt, uczysz się, gdzie abstrakcja realnie pomaga - i piszesz pierwszy test jednostkowy.

1. 1Wydzielanie komponentów - Rozbijasz widok gracza na GameIntro, GameQuestion, GameResult i FeedbackCard, stosujesz props/emits, warianty BaseText/BaseButton oraz sloty BaseCard/BaseList.
2. 2Kolejne composables i czyste helpery - Dodajesz composables timera, kopiowania, submitu, feedbacku i zapisu oraz helpery formatTime/ANSWER_LABELS. Lokalne try/catch zostają tam, gdzie logika nie jest powtarzalna.
3. 3Czytelność i nazewnictwo - Ujednolicasz nazwy stanów i akcji composables, przenosisz trzy testy do tests/ i obejmujesz ten katalog typecheckiem.
4. 4Pierwszy test: scoring pod ochroną (Vitest) - Migrujesz trzy mini-testy node:test do Vitest i dodajesz test zaokrąglenia czasu rankingu; ćwiczysz czerwony → zielony i celowe psucie kodu.

Checkpoint: Kod jest podzielony na czytelne komponenty i helpery, aplikacja działa dokładnie tak samo jak przed refactorem - i potwierdza to pierwszy test scoringu.

Efekt: Dopracowujesz wygląd i odczucia z aplikacji, żeby wyglądała na skończony produkt, nie prototyp.

1. 1Puste i skrajne stany - Dodajesz pending/error/retry/empty leaderboardu, brandowaną stronę 404/500 z clearError oraz wrap-anywhere dla długiego tematu.
2. 2Responsywność: apka w kieszeni - Dopasowujesz mobilne odstępy i ustawiasz pola kreatora w jednej kolumnie przed breakpointem sm; truncate nicka i overflow kodu już istnieją.
3. 3Mikrodopracowania UI - Składasz wcześniejszy CodeBlock+Shiki z Transition, scrollem faz gry i hoverem rankingu. watch obserwuje kod i język, a treść nigdy nie używa v-html.
4. 4Podstawy dostępności - Kontrast, focus-visible, fokus po zmianie fazy, H1 pytania, blokada podwójnego startu, aria-invalid/aria-describedby i role statusów.

Checkpoint: Puste stany, błędy i teksty są dopracowane, a aplikacja jest wygodna także z klawiatury.

Efekt: Pakujesz projekt tak, żeby robił wrażenie w portfolio i na rozmowie o pracę.

1. 1README, które sprzedaje projekt - Opis, funkcje, stack, zrzuty i link do demo - tak, żeby ktoś w 30 sekund zrozumiał, co udało się zbudować.
2. 2Opis do portfolio i CV - Jak opisać ten projekt jednym akapitem i punktami, podkreślając decyzje i umiejętności, nie tylko technologie.

Checkpoint: Repo ma porządne README ze zrzutami, opisem funkcji, stackiem i sekcją „czego nauczył mnie ten projekt”.

Efekt: Feedback AI pojawia się jako częściowe snapshoty obiektu przesyłane przez SSE.

1. 1Streaming odpowiedzi z serwera - Endpoint wysyła SSE partial/done/error, zapisany feedback zwraca pojedyncze done, parser składa ramki, a FeedbackPanel renderuje PartialFeedback.
2. 2Stany i płynność - Guard pustego snapshotu, błąd EOF bez done, czyszczenie partial, reader.cancel i brak retry po pokazaniu części odpowiedzi.

Checkpoint: Feedback wyświetla się strumieniowo, obsługuje done/error i nie zostawia UI w zawieszonym stanie.

Efekt: Rozbudowujesz generator: nowe typy pytań i mocniejszy, bardziej sterowalny prompt.

1. 1Nowe typy pytań - Budujesz unię single/trueFalse/multiple, publiczny kontrakt per wariant, exact-set scoring, UI, migrację starych danych i mieszany seed.
2. 2Inżynieria promptu - Przenosisz prompty do wersjonowanych plików V1/V2 z ACTIVE_, dodajesz typeMode i regułę dla trybów jednoznacznych. Dla mix kod świadomie akceptuje dowolny skład.
3. 3Mini-evals: kontrola jakości generacji - Evale wykrywają duplikaty, brak snippetu/języka, wszystkie poprawne multiple i zbyt krótkie wyjaśnienie; pewne problemy powodują warn i retry.

Checkpoint: Generator obsługuje single, trueFalse i multiple, wersjonowane prompty oraz kodowe evale jakości. Tryb mix jest preferencją promptu, nie gwarancją składu.

Efekt: Dostajesz mapę rozbudowy: konta, historia, płatności, anti-cheat - i wiesz, jak się do nich zabrać.

1. 1Kierunki rozwoju - Logowanie i konta, historia podejść, adaptive learning, płatności, anti-cheat - przegląd z oceną trudności.
2. 2Jak dokładać funkcje bezpiecznie - Praca na branchach, małe kroki i checkpointy - ta sama metoda, którą znasz z kursu, przy dalszym rozwoju.

Checkpoint: Masz konkretny plan, którą funkcję dołożyć jako następną i od czego zacząć.

Efekt: Wgrywasz notatki lub PDF, a AI generuje quiz z TWOJEGO materiału - dotykasz najgorętszego tematu AI 2026 na własnym projekcie.

1. 1Z PDF-a do tekstu i fragmentów - Upload za flagą, unpdf i chunking do 1500 znaków bez overlapu. Deklarowany body >5,5 MiB dostaje wczesne 413, faktyczny plik >5 MiB jest odrzucany po buforowaniu; Vercel ma niższy praktyczny limit.
2. 2Embeddingi i wyszukiwanie - embedMany, pgvector i RPC match_document_chunks; zapis dokumentu/chunków ma rollback, a usunięcie robi cleanup.
3. 3Retrieval do generatora - documentId, embedding tematu i top 4 trafiają do wydzielonej sekcji promptu. Omawiasz indirect prompt injection i zachowanie 404 przy wyłączonej fladze.

Checkpoint: Quiz wygenerowany z wgranego PDF-a, z pytaniami osadzonymi w treści dokumentu.

Efekt: Budujesz minimalny serwer MCP i tworzysz quizy prosto z Cursora - Twoja aplikacja staje się narzędziem dla AI.

1. 1Czym jest MCP - Host, klient i serwer - standard, dzięki któremu AI podłącza się do narzędzi (mówi o nim cała branża).
2. 2Minimalny serwer w TypeScript - Osobny pakiet Node 24/TypeScript wystawia create-challenge przez STDIO i publiczne API bez sekretów. Tool deklaruje koszt/publiczny efekt, ale potwierdzenie zależy od hosta; timeout wynosi 20 s.
3. 3Demo gotowe na świat - SEO i nagłówki - Dodajesz dynamiczne meta/canonical, cover OG 1200×630, ikony, noindex challenge’y, landing i meta błędu oraz nosniff, X-Frame-Options i Referrer-Policy.

Checkpoint: Narzędzie create-challenge działa w Cursorze, a publiczne demo ma komplet SEO/OG i podstawowe nagłówki bezpieczeństwa.