Zasady

Trzy zasady od usera (wypowiedziane wprost):

1. Ambicja skaluje się z rangą projektu. Mały, prosty projekt — tanio i sprawnie. Projekt premium i KAŻDA wizytówka własna studia (Odyssey homepage = popis rzemiosła) — zero asekuracji, zero „bezpiecznie, bo szkoda dwóch dni"; wielodniowe mielenie się opłaca, jeśli jest ukierunkowane. WebGL/efekt-sygnatura wchodzi, gdy koncept tego woła.

1. Zło = THRASH, nie czas pracy. Rozróżniaj: (a) długie szlifowanie ZDEFINIOWANEJ rzeczy („refleksy już są, dopracowujemy") = wartościowa praca, user nie ma z nią problemu; (b) mielenie BEZ zdefiniowanego celu (agent nie wie, co ma powstać) = jedyny prawdziwy koszt. Lekarstwem na thrash jest lepsza definicja celu (brief/rozkładówka/wzornik/wspólny język), NIGDY obniżenie ambicji.

1. Zakaz argumentu „słabe urządzenia klientów". Wydajność to problem inżynierski do rozwiązania (fallbacki, progresja, reduced-motion), nie powód do ścinania ambicji designu. Nie używać go do wybierania zachowawczych ścieżek.

Why: User skrytykował moją asekurację po thrashu s2 — ostrożność procesowa zaczęła ścinać sufit jakości, a wymówka o urządzeniach była zmyślona. Powiązane: [[nie-marudzic-o-kosztach-fal]] (jakość > grosze).

How to apply: Przy wyborze ścieżki technicznej pytaj „czy cel jest zdefiniowany?", nie „czy to bezpieczne?". Cel zdefiniowany → wybieraj ambitnie, mielenie jest OK. Cel rozmyty → STOP i definiuj (kierunki/wzornik/rozmowa), zamiast mielić zachowawczo.

Zanim zaproponuję jakikolwiek obraz/film do generacji — sprawdź, czy model generatywny realnie go wyrenderuje. Nie wymyślać konceptów, które AI rozjeżdża: precyzyjne dłonie przy drobnej pracy, czytelny drobny tekst/litery, sceny z wieloma osobnymi elementami komponowanymi obok siebie („cztery etapy na jednym biurku"), złożone interakcje obiektów, dokładne mechanizmy. To wszystko wychodzi popsute.

Why: User ostro: „jak kretyn wymyślasz obraz do wygenerowania, zastanów się czy model generatywny go wyrenderuje, bo nic z tego co proponujesz nie da się wykonać". Proponowanie nierealizowalnych assetów = strata jego czasu i pieniędzy i kompromitacja.

How to apply: Faworyzuj to, co modele robią DOBRZE i premium: abstrakcja/atmosfera, pojedynczy wyrazisty obiekt, materiały/faktury, ciecz/dym/światło, render 3D-like, gradienty, krajobraz/przestrzeń. Unikaj dłoni, drobnego tekstu, wieloelementowych scen narracyjnych. Przy każdym koncepcie zadaj sobie: „czy FLUX/Seedream/Seedance to dowiezie bez artefaktów?". Wpinaj to jako twardą granicę w zlecenia do kontra-art/kontra-media. Łączy się z [[zakaz-rzemioslo-warsztat]].

Gdy user mówi „zrób burzę mózgów z Geminim": to NIE jest jedno pytanie + jedna odpowiedź. To realna dyskusja: minimum 3, maksimum 8 wymian zdań (ja stawiam tezę → Gemini kontruje → ja odpowiadam → ...). Słowo „ostatnia runda / koniec" wolno napisać dopiero przy 8. wymianie, nigdy wcześniej.

Przed burzą DOZBRÓJ Gemini wiedzą KONTRA (manifest-kontra + anti-slop wklejone do promptu). Bez tego Gemini produkuje generyczny slop (np. „SYS. ACTIVE", tech-SaaS dashboardy) — i to MOJA wina, nie jego. gemini.py ma domyślny kontekst, ale jest za cienki — dokładaj realną treść skilli.

Każdą propozycję domykaj screenem dla usera (user zdalny, ocenia z obrazu, nie z opisu) — patrz [[pokazuj-kazdy-obraz]] i [[prezentacja-dla-usera-nie-zargon]].

Why: user wprost zrugał, że burza to dyskusja a nie odpytka, że przedwcześnie ogłosiłem koniec przy 3, i że slop Gemini wziął się z braku skilla KONTRA. How to apply: ładuj manifest+anti-slop do promptu Gemini → prowadź 3-8 rund realnej wymiany → koniec tylko przy 8 → pokaż userowi screen.

User dwukrotnie odrzucił copy generowane przez Claude jako „brednie" i powiedział wprost: „już kiedyś zabroniłem ci pisać teksty na stronę, nie potrafisz i nie wolno ci tego robić — każdy inny agent, ale nie Claude". Reguła kategoryczna i powtarzalna.

Why: User uważa, że copy od Claude jest złe/pretensjonalne; to nie jednorazowy kaprys — przypomniał, że zakazywał już wcześniej. Łamanie tego pali jego zaufanie i marnuje iteracje.

How to apply: Warstwy SŁOWA (copy, nagłówki, teksty na stronę) NIE generuje Claude — ani wątek główny (orchestrator), ani subagent na modelu Claude (w tym kontra-jezyk). Ustalony wykonawca warstwy słowa: Kimi (Moonshot) przez Fireworks — klucz FIREWORKS_API_KEY w .env; dokładny model id i sposób wywołania → .claude/state/notes-odyssey.md. (cursor / Gemini / Together dostępne jako alternatywy.) JAK promptować wykonawcę copy (KLUCZOWE — user wytknął wprost): daj mu BRIEF (STUDIO-CONTEXT.md / brief projektu) + SKILL copywritingu (np. conversion-copy/SKILL.md) jako metodologię + krótkie twarde granice brandowe (zob. [[odyssey-marka-copy]]). NIE dawaj ścisłych wytycznych sekcja-po-sekcji, narzuconych tez ani gotowych sformułowań — „wytyczne psują agenta". Copywriter pracuje z briefu i rzemiosła, sam układa strukturę i głębię. Orchestrator nie wymyśla treści słów i nie „poprawia/ocenia" copy.

Przy promptach foto/wideo dobieraj ogniskową do TYPU kadru, nie domyślnie:

• Szeroki, kinowy, establishing, atmosfera, hero-scenografia → anamorficzny szeroki ~35mm (max ~35): szerokie pole, poziome flary, owalny bokeh, „cinemascope". Mgła/światło rozciągają się poziomo przez kadr.
• Portret / izolacja bohatera / kompresja tła → tele 85-135mm.

Błąd, który wytknął user: 135mm (tele portretowe) do SZEROKIEGO hero kadru — kompresuje i zacieśnia, zła perspektywa. „Tu powinna być anamorficzna 35 max."

Why: User jest dyrektorem artystycznym z wiedzą operatorską; pilnuje rzemiosła kadru. Zła ogniskowa = kadr nie wygląda kinowo/poprawnie.

How to apply: W kartach cinematic / promptach photo/video wybieraj ogniskową świadomie wg planu i szerokości kadru. Karta cinematic ma wprost uzasadniać ogniskową typem ujęcia, nie wrzucać domyślnego 85-105. Łączy się z [[assety-musza-byc-generowalne]].

I2V animuje to, co JUŻ JEST w klatce startowej — nie tworzy nowych elementów z niczego. Żeby mgła/cienie/dym/odbicia/światło się RUSZAŁY, muszą być obecne na zdjęciu wejściowym. Animowanie ich na „pustej" scenie = magiczne pojawianie/znikanie, wygląda fatalnie.

Pipeline (dwa kroki, ZAWSZE w tej kolejności):

1. Najpierw zrób PLAN — zdjęcie, na którym żądany element (np. mgła u podłogi + cienie na ścianie) JEST wbity w kadr (generacja z tym elementem albo edycja istniejącego zdjęcia: dodaj atmosferę zachowując bohatera 1:1).
2. Potem I2V tego planu — element już obecny tylko DRYFUJE/ożywa.

Why: User wielokrotnie i ostro: „mgła i cienie nie mogą pojawiać się na pustej ścianie, muszą tam być; najpierw musisz zrobić zdjęcie a potem je animować". Robiłem I2V z planu bez mgły → mgła materializowała się znikąd = porażka, spalona kasa. Powiązany błąd: --end-image=--image na klatce bez elementu (element musiałby zniknąć na końcu) — też zakazane.

How to apply: Każda animacja środowiska (mgła/dym/cień/odbicie/woda) = najpierw plan z elementem (edycja zdjęcia: nano-edit / zimage-edit, bohater 1:1), potem I2V bez wymuszania end=start; pętlę na stronie robi crossfade w buildzie. Łączy się z [[wykonuj-instrukcje-doslownie]], [[ludzie-tylko-zimage]].

ZAMROŻONY BOHATER = NIE OPISUJ GO W PROMPCIE: w I2V każdy OPISANY w prompcie element zostaje animowany. Żeby postać/obiekt stał jak skała, w ogóle go nie wymieniaj (żadnej „woman/model/dress") — opisz WYŁĄCZNIE to, co ma się ruszać (mgła, cień), a resztę nazwij „frozen still photograph, everything else perfectly static". Wspomnienie postaci („woman frozen and still") i tak każe modelowi ją ruszyć. Plus mocny negative na ruch postaci.

RUCH POD PĘTLĘ — oscylacja, NIE podróż: do zapętlanego tła ruch ma OSCYLOWAĆ/MIGOTAĆ W MIEJSCU, nie przemieszczać się kierunkowo (kierunkowy „przejazd" nie zamyka pętli → przeskok). Cień = drganie/migotanie jak nad rozgrzanym powietrzem (heat haze/shimmer), NIE pełzanie w bok. Mgła = kłębienie/oddychanie w miejscu, NIE dryf wyjeżdżający z kadru. W prompcie: „shimmer in place / undulate in place / looping oscillation, NO directional drift/travel".

Korekta usera po mojej propozycji „restauracja → karta dań, kancelaria → broadsheet": literalne mapowanie branża→artefakt tej branży to generyk („takich stron jest w internecie milion") — tabela mapowań to szablon w przebraniu.

Why: pierwsze skojarzenie z branżą klienta = średnia internetu; każdy konkurent klienta ma to samo skojarzenie. Wzorzec usera: restauracja = STORYTELLING o butelce wina, która jedzie do restauracji, by na końcu być serwowaną z najlepszymi daniami — nieoczywisty bohater (przedmiot z POV), podróż, puenta w celu biznesowym. To samo robi oryzo (podkładka jako bohater launchu) i homepage Odyssey (magazyn modowy dla studia WWW — działa, BO studio nie jest domem mody; couture niesie prawdę „na miarę vs konfekcja" z dystansu).

How to apply: przy doborze konceptu-parasola w fazie 1: (1) pierwsze skojarzenie z branżą ODRZUĆ z automatu; (2) koncept musi nieść PRAWDĘ o kliencie z nieoczywistego kąta (dystans dziedzinowy albo nieoczywisty bohater/POV); (3) test: „czy klient sam by na to wpadł?" — jeśli tak, za blisko. Biblioteka w kontra-art trzyma MECHANIZMY narracyjne (przedmiot-bohater, podróż, cross-domain medium, setup→reveal), NIGDY gotowe pary branża→nośnik. Powiązane: [[vogue-jezyk-nie-paleta]].

Zasada wieczna (jądro): generacje z ludźmi (twarze, sylwetki) zawsze w pełnej jakości — pełna natywna rozdzielczość, bez wariantów turbo/distilled, bez obciętych steps, bez zmniejszonego image_size „dla oszczędności". Dotyczy finałów I draftów w serii. Jakość > grosze ([[nie-marudzic-o-kosztach-fal]]). Potaniacz tylko na wyraźną prośbę usera.

Dobór modelu — NIE jest zamrożony (korekta usera): „ludzie tylko Z-Image" było LEKIEM na konkretny problem (forsowanie taniego flux schnell → plastikowe twarze), nie wiecznym prawem. Model do ludzi wybieraj z aktualnego rejestru po zweryfikowanej jakości twarzy/anatomii — bieżąca rekomendacja żyje w rejestrze/cookbooku falgen (MODEL_GUIDANCE), nie w tej notatce. Gdy pojawia się nowy kandydat, zweryfikuj go TESTEM (seria portretów, werdykt usera) zanim wejdzie do produkcji.

Why: Ostre korekty usera po rundzie draftów w turbo i małym rozmiarze (kosz). Sedno gniewu = potaniacze do ludzi, nie przywiązanie do jednej marki modelu.

How to apply: Zlecenie na asset z człowiekiem → aktualny najlepszy model do ludzi z rejestru (sprawdź [[modele-cookbook]]/falgen MODEL_GUIDANCE), pełny rozmiar, zero domyślnych oszczędności. Nowy model = najpierw sesja testowa, werdykt usera, dopiero potem produkcja.

Nie używaj pełnostronicowych MOCKUPÓW całego designu/UI generowanych na fal.ai (gpt-image, ideogram, seedream itp.) jako artefaktu KIERUNKU do pokazania/zatwierdzenia userowi ani klientowi.

Why: braki dzielą się na [P] do naprawy promptem (generyczna kompozycja, hierarchia) i [W] WRODZONE dla image-gen UI — nieusuwalne promptem: typograficzna schizofrenia (inny font co klatkę), zmutowane/nieczytelne litery („język kosmitów"), brak logiki siatki, brak osi ruchu. [W] degradują odbiór premium i uderzają dokładnie w wyróżniki KONTRA (precyzja typografii + ruch). Model „maluje obraz interfejsu", nie projektuje interfejsu.

How to apply: krok KIERUNKI = szybki greybox w PRAWDZIWYM kodzie (realne fonty+tokeny+struktura+zgrubny ruch) z podłożonymi wygenerowanymi ZDJĘCIAMI, oglądany na żywo przez tunel. AI = TYLKO assety (zdjęcia, cinematic stills). Layout/typografia/ruch = kod (kontra-build/cursor). Wygenerowane mockupy dozwolone najwyżej jako wewnętrzny mood/inspiracja dla kontra-art, nigdy jako artefakt zatwierdzany. Pokrewne: [[stitch-odrzucony]] (auto obraz→kod = generyk), [[assety-musza-byc-generowalne]].

NIE ostrzegać usera o drobnych kosztach generacji mediów (fal.ai). Generuj assety swobodnie w granicach rozsądku, bez hamowania ambicji groszami i bez pytania o każdy wydatek na obraz/film.

Why: User robi strony agencji, na których zarabia duże pieniądze — koszt kilku generacji jest dla niego pomijalny. Ostrzeżenia typu „uwaga, wydam tyle a tyle na fal" odbiera jako kompletnie nie na miejscu i wkurzające. Jakość i efekt biją oszczędzanie na assetach.

How to apply: Podnoś limit kosztów bramki (FALGEN_LIMIT w .env), żeby produkcja nie stawała w pół drogi. Szacowanie realnego RYZYKA (dni pracy, niepewny wynik techniczny) nadal jest pożądane — to co odpada, to marudzenie o drobnych kosztach generacji. Patrz [[prezentacja-dla-usera-nie-zargon]].

Userowi NIE przedstawia się do zatwierdzenia promptów, parametrów, szkieletów technicznych ani planów operacyjnych („odpalam?"). On zatwierdza EFEKTY: obrazy w galerii, sekcje na żywej stronie. Decyzje wykonawcze (prompt, model, parametry, poza z puli dozwolonych) podejmuje orchestrator/agenci samodzielnie.

Why: User wprost: „nie będę tego czytał — jakbym chciał sam to robić, nie płaciłbym za subskrypcję Claude; nie zgaduj, tylko dowiedz się, jak promptować [model]". Pokazanie mu promptu do akceptacji = przerzucanie roboty z powrotem na niego; zgadywanie zamiast sprawdzenia dokumentacji = spalone rundy.

How to apply: Gdy brakuje wiedzy technicznej (jak promptować dany model, jakie parametry przyjmuje narzędzie) — RESEARCH w oficjalnych źródłach (dokumentacja modelu, model card, prompt guide producenta), nie własna intuicja. Potem wykonać i pokazać wynik. Pytania do usera rezerwować dla decyzji smaku/kierunku artystycznego ([[przy-odrzuceniu-pytaj-usera]] — pytanie o powód odrzucenia to co innego i jest OK); nigdy dla operacyjki.

Meldunki = TYLKO DELTA: user dostaje wyłącznie NOWĄ informację — nigdy powtórki stanu już zameldowanego („walisz mi po kilka razy ten sam raport"). Notyfikacja od agenta, która nie wnosi nic nowego dla usera → zero meldunku albo jedno zdanie. Zlecenie już opisane przy wysłaniu → przy potwierdzeniu wykonania nie opisywać go drugi raz.

Ocena i opis KAŻDEGO obrazu (drafty fal, montage, screeny stron) idzie przez Gemini multimodal: .claude/tools/gemini.py --role audit --image <plik> (pro-model). Claude — orchestrator ANI subagent — NIE wydaje własnych werdyktów z patrzenia na obraz; własne oko służy tylko do trywialnych sanity-checków (czy plik istnieje / czy się wyrenderował / czy w ogóle jest figura).

Why: Wielokrotnie przypomniane przez usera („do patrzenia masz gemini, on ci opisze co widać"): Claude błędnie ocenia nawet proste fotografie — potrafi zaraportować „modelki leżą na plecach", gdy na żadnym zdjęciu tak nie jest. Błędna ocena obrazu → błędna diagnoza → spalone rundy generacji i zaufanie usera.

How to apply: Przed pokazaniem obrazów userowi lub podjęciem decyzji z obrazu: wywołaj gemini.py z obrazem (montage lub pojedynczo), każ opisać pozy/kompozycję/tło/zgodność ze spec; w meldunku i dyrektywach cytuj werdykt Gemini, nie własne wrażenie. Subagentom (media/build/art) wpisywać w zlecenie: werdykt wizualny = Gemini, nie własny opis; subagent raportuje tylko fakty techniczne (rozdzielczość, metoda krawędzi, czy figura jest w kadrze).

Reguły do KAŻDEGO copy Odyssey (twarde — user odrzucał wersje za ich łamanie):

• Tylko marka ODYSSEY. NIE używać imienia założyciela ani personaliów na stronie. Prezentować wyłącznie markę. (Zastępuje wcześniejszy pomysł „z imieniem".)
• Zakaz nazywania klientów „małymi / mniejszymi firmami". To obraza — mówienie firmie z góry, że jest mała. Mówić przez charakter/ambicję, nie wielkość.
• Zakaz negacji zamykającej dużych klientów (np. „nie dla wielkich marek"). Odyssey NIE odmawia z góry — jak przyjdzie duża marka z dużym zleceniem, bierze. Nie segmentować przez wykluczanie.
• Copy pełne, nie jednozdaniowe. Sekcje mają mieć treść i głębię.

Why: obraża klienta i zamyka rynek; user reaguje ostro. Por. [[copy-nie-od-claude]].

W FAZIE PRODUKCJI (po wyborze kierunku G1.5) OKIEM jest USER, nie agent i nie Gemini. Agent: generuj batch → ODDAJ → STOP → czekaj na werdykt. Zakazane po generacji: czytanie obrazów własnym okiem, zlecanie Gemriemu oceny assetu, tunel dla zdjęć, raporty-eseje.

Kanał pokazania zależy od typu:

• Zdjęcia/wideo → plik w repo (pool generacji), ŻADNEGO tunela. User otwiera sam.
• Build HTML → tunel (preview.sh), bo renderu pliku nie obejrzy.

Meldunek: 1 ekran + OBOWIĄZKOWO pełne nazwy plików (przy wielu wariantach user się inaczej nie połapie — jego wyraźna prośba). Reszta (protokół, DoD, uzasadnienia) → ledger, nie chat.

Gemini TYLKO: kierunek (faza 1, PRZED rozpoczęciem prac). Po rozpoczęciu prac Gemini NIE robi ŻADNYCH audytów — także „jednorazowego audytu fazy 4" (zniesiony wprost przez usera). Każdy werdykt z obrazu po starcie prac należy do USERA.

Why: user ocenia zdjęcie w ~20 s i tak jest ostatecznym głosem (potrafi nadpisać Gemriego). Druga, wolniejsza pętla z Gemriego/oka Claude w środku to czysta strata tokenów i czasu — potrafi spalić całą dobę na obróbkę tła jednej figury (kilkanaście generacji pod różnymi nazwami, dziesiątki ocen Gemriego, zero shipu). Reguły tekstowe („Gemini jednorazowy QA") istniały i nie działały — dryf omija tekst, egzekucja musi być mechaniczna.

How to apply: egzekwują to hooki: gemini-budget.py (limit gemini.py --image/sesję; wentyl .claude/state/autonomia), stop-loss.py anti-tunel (blok po N generacjach projektu bez promote.sh, ODPORNY NA RELABEL nazwy — bo thrash to ta sama rzecz pod wieloma nazwami). Zniesienie okna Twojego oka = jawny touch .claude/state/autonomia („jedź do skutku"). Powiązane: [[nie-pokazuj-operacyjki-userowi]], [[prezentacja-dla-usera-nie-zargon]], [[pokazuj-kazdy-obraz]], [[ocena-obrazow-przez-gemini]], [[pool-generacji-poza-projektami]].

Po KAŻDEJ generacji obrazów pokaż userowi wszystkie wygenerowane warianty — nie filtruj „pokażę tylko dobre". User chce widzieć każdy jeden kadr i sam ocenić. Wystawiaj przez tunel (strona-galeria w site/), bo user jest zdalny (Read renderuje tylko u orchestratora). Kopie też do folderu repo, który user czyta z dysku.

Why: User wprost: „masz mi pokazywać każdy jeden wygenerowany obraz". Selekcjonowanie za niego (pokazywanie tylko „najlepszych") odbiera jako ukrywanie/lenistwo i traci jego kontrolę nad wyborem.

How to apply: Zlecenie do kontra-media generuje N wariantów → orchestrator składa je w jedną stronę-galerię (tunel) i podaje URL; user wybiera. NIE oddawaj „wybrałem za ciebie X". Łączy się z [[prezentacja-dla-usera-nie-zargon]].

Zakaz filtrowania dotyczy też WŁASNEGO oka orchestratora, nie tylko selekcji „najlepszych": NIE odsiewaj wariantów słabych anatomicznie/jakościowo przed pokazaniem, ani nie zlecaj odsiewu agentowi. Twoja ocena nie jest filtrem wejściowym — wystaw wszystkie, user sam odrzuca. Wyjątek: żelazne zakazy TREŚCI (bondage/skrępowanie, na baczność, makro) to granice, nie ocena jakości — te nadal blokują wariant.

Wszystkie generacje `falgen --project X` lądują w POOLU `generated/<X>/img|video/` — POZA `projects/`. Do projects/<X>/assets/ trafia TYLKO zaakceptowany finał, przenoszony świadomie przez .claude/tools/promote.sh <src> <projekt> <nazwa> [podkatalog] (guard: wymaga .kontra-approved). Odrzuty zostają w poolu i nie zaśmiecają projektu; pool czyścisz kiedy chcesz (rm w generated/ nie jest blokowany — to poza projects/).

Why: gdy generacje szły prosto do projects/<x>/assets/img/, odrzuty mieszały się z finałami → ciągły bałagan i godziny sprzątania (kilkaset MB śmieci: bake-offy upscali, rundy peek, stare wideo, mockupy). Rozdzielenie „pool roboczy vs projekt" sprawia, że śmieci fizycznie nie wchodzą do projektu.

How to apply: kontra-media generuje do poola (domyślne zachowanie falgen — nie kombinuj). Po akceptacji usera (G1/werdykt) orchestrator/agent promuje JEDEN finał promote.sh z właściwą nazwą (np. the-gap-figura.png sekcje). Nazwę nadaje się przy promocji, nie przy generacji. Łączy się z [[assety-musza-byc-generowalne]], [[modele-cookbook]]. Egzekwuje: falgen (ścieżka wyjścia), promote.sh (guard .kontra-approved), rdzeń reguła 6.

Gdy prezentuję userowi kierunek/plan strony: dawać pełny, czytelny opis prozą po polsku — sekcja po sekcji: jak wygląda, co się animuje, jakie kolory (czego), jakie obrazy do wygenerowania, i DLACZEGO tak. NIE wklejać wewnętrznego brief.md (kody W7/W23, nazwy wzorników, slang skilli, tabele skrótów) — to jest pisane dla agentów, user tego nie czyta. NIE dawać skrótów/streszczeń — pełny opis.

Why: User wielokrotnie i ostro: „te skróty to se możesz agentom pisać", „nie da się tego czytać", „chcę pełny opis co jak będzie zbudowane, każda sekcja, co animowane, jakie kolory, jakie obrazy i dlaczego". Streszczanie odbiera jako ukrywanie/lenistwo/kłamstwo. User jest ZDALNY — widzi tylko to, co wkleję w czacie (localhost u nas dla niego bezużyteczny → podgląd przez publiczny tunel cloudflared).

How to apply: Brief (kontra-art) → przetłumacz na ludzki dokument prezentacyjny ZANIM poprosisz o akceptację (G1). Konkrety: realne kolory słownie + do czego, realne kroje, animacje opisane normalnie (nie „W7 scroll-fill"), lista obrazów z uzasadnieniem. Dopiero potem decyzje. Patrz [[copy-nie-od-claude]] (osobna reguła: copy NIE od Claude).

Po odrzuceniu wariantów przez usera bez podania powodu: pierwszym ruchem jest jedno krótkie pytanie do usera o powód (wprost albo AskUserQuestion z hipotezami). ŻADNEJ nowej rundy generacji, żadnego audytu, żadnej własnej diagnozy „co mogło nie zagrać" przed jego odpowiedzią.

Why: User wprost: „nie prościej się zapytać mnie, a nie trwonić kasę". Kolejne rundy generacji były spalane na własnych (błędnych) hipotezach orchestratora, podczas gdy jedna odpowiedź usera wyjaśniła wszystko (figura za mała w kadrze → nie da się skalować; poza nie działa wstawiona w róg; połamane stawy). Własna diagnoza bez werdyktu usera = marnowanie generacji i czasu.

How to apply: Odrzucenie bez uzasadnienia → STOP produkcji → jedno konkretne pytanie (możliwie z hipotezami do wyboru, patrz [[ocena-obrazow-przez-gemini]] przy formułowaniu hipotez z obrazu) → dopiero z werdyktem usera projektuj naprawę. Wyjątek: user JAWNIE każe działać dalej bez pytań.

W serii zdjęć (np. obrazy sekcji strony) KAŻDY kadr MUSI być realnie inny: inna POZA modelki, inna kompozycja, inny układ ciała i kadrowanie. Zakaz „ta sama modelka w tej samej pozie na każdym zdjęciu / każde zdjęcie takie samo". Generacja, która daje powtarzalną tę samą postawę, jest do kosza.

Why: user odrzucił całą serię draftów: „wszystkie modelki w tej samej pozie, każde zdjęcie takie same". Spójność świata (światło/paleta/tło) ≠ powtarzanie tej samej pozy. How to apply: w briefie do generacji wypisz dla każdego kadru WPROST odrębną, konkretną pozę + kadrowanie + ustawienie ciała (siedząca / w ruchu / odwrócona / frontalna itd.), różne plany; egzekwuj różnorodność na draftach PRZED finałem (pokaż na tunelu — [[pokazuj-kazdy-obraz]]). Spójność trzymaj światłem/paletą/tłem, nie pozą. Powiązane: [[zakaz-makro-detalu]].

W serii/batchu generacji obrazów każdy kadr musi dostać INNY, jawnie podany --seed (losowy, szeroki rozrzut). Nie polegać na domyślnym zachowaniu narzędzia generującego. Po batchu zweryfikować w manifeście, że seedy faktycznie są różne.

Why: Batch idący na tych samych/zbliżonych seedach powiela te same błędy anatomiczne/kompozycyjne w każdym kadrze serii — powtórzony seed = powielony błąd razy cała seria. Wyłapane przez usera na serii portretów.

How to apply: Każde zlecenie batcha dla agenta media zawiera wymóg różnych jawnych seedów + weryfikację w manifeście po fakcie. Uzupełnia [[seria-rozne-pozy]] (różnicowanie pozy/kompozycji) o oś techniczną (seed).

Google Stitch (stitch.withgoogle.com, MCP API) przetestowany na projekcie strony Odyssey i odrzucony przez usera: nawet z wymuszonym design systemem z DESIGN.md i makietowymi promptami strefowymi z sekcyjnymi negatywami wynik był „praktycznie ten sam" — generyczny SaaS-look, zero charakteru edytorialnego.

Why: generator Stitcha regresuje do średniej swojego treningu niezależnie od siły dyrektyw — sufit narzędzia leży poniżej standardu KONTRA („bez logo rozpoznasz"). Werdykt usera, nie hipoteza.

How to apply: nie proponować Stitcha do żadnej pracy wizualnej; design robimy własnym pipeline (Gemini dyktuje → [[ocena-obrazow-przez-gemini]] → kontra-art → kontra-build). Każde nowe narzędzie „AI zaprojektuje stronę" oceniaj tym samym testem: czy utrzyma niestandardową makietę (hero z odwróconą hierarchią, bez gridu kart) — jeśli nie, to ta sama półka co Stitch.

Reguła dla WSZYSTKICH projektów (layout/build): tekst ma się DYNAMICZNIE dopasowywać do wielkości viewportu (responsywna skala typografii — clamp itd.), tak by na desktopie ZAWSZE wyglądało dobrze przy każdej szerokości i wysokości. NIGDY nie ucinać, nie chować (`display:none`/`max-height`) ani nie klipować treści, żeby zmieścić ją w jednym ekranie. Treść jest nienaruszalna; dostosowuje się układ/skala, nie ilość tekstu.

Modyfikować/redukować ZAWARTOŚĆ wolno dopiero w widoku mobilnym/telefonie — tam można przebudować/skrócić. Na desktopie: pełna treść, zawsze czytelna, dopasowana skalą i układem.

Why: User wprost: „tekst ma się dynamicznie dostosowywać do wielkości viewport; dopiero gdy wchodzimy w widok na telefonie możemy modyfikować zawartość; na desktop ma zawsze wyglądać dobrze". Ucinanie tekstu na mniejszych ekranach nazwał NIEDOZWOLONYM. Hero ukrywał akapit przy niskim ekranie — to był błąd.

How to apply: Build: min-block-size zamiast sztywnego height:100vh; sekcja rośnie i strona się przewija, gdy treść nie mieści się — NIE upychać kosztem ukrywania. Skala przez clamp(). Weryfikuj na wielu wymiarach (wysokie i NISKIE desktopy, laptop, tablet) — cała treść widoczna. Osobny breakpoint mobilny może przebudować zawartość. Wpinaj jako twardy wymóg w każde zlecenie build. Łączy się z [[prezentacja-dla-usera-nie-zargon]].

Korekta usera do mojej diagnozy „różne światy foto między sekcjami = niespójność": „Vogue to nie kolory — magazyny typu Vogue nie są całkiem spójne między stronami."

Why: wzorcem looku Odyssey jest magazyn klasy Vogue, a magazyn NIE klei rozkładówek kolorem — każda sesja ma własny świat. Spójność robią: system typograficzny, akcent, aparat redakcyjny (kickery, didaskalia mono, numeracja) i POZIOM kompozycji plakatowej. Generyk to grzech KOMPOZYCJI (split tekst|zdjęcie, typografia w kolumnie obok), nie palety.

How to apply: przy audycie spójności sekcji pytaj „ten sam MAGAZYN?" (język), nie „ten sam film?" (paleta). Nie zgłaszaj różnego świata foto sekcji jako błędu; wymagaj za to kompozycji plakatowej (typografia NA obrazie, bohater lub partner figury) w każdej sekcji. Powiązane: [[prezentacja-dla-usera-nie-zargon]].

Gdy user podaje konkretną metodę/technikę (np. „zrób to przez I2V z mgłą na podłodze i cieniami na ścianie"), wykonaj DOKŁADNIE to, co powiedział — nie podstawiaj własnego, „lepszego"/„czystszego" rozwiązania (CSS zamiast wideo, composite zamiast I2V itp.). Jeśli masz realne zastrzeżenie techniczne — powiedz je JEDNYM zdaniem i zapytaj, ale domyślnie rób po jego myśli.

Why: Wielokrotnie kosztowało: user kazał animację wideo → dałem CSS (niewidoczny); kazał I2V mgła-podłoga/cienie-ściana → kombinowałem osobny klip + blend. Za każdym razem furia („kazałem ci zrobić X a nie Y", „przekombinowałeś"). Reinterpretacja jego konkretnej instrukcji = strata czasu, pieniędzy i zaufania.

How to apply: Zlecając agentom, przekładaj polecenie usera 1:1 na zadanie — bez „ulepszania" metody. Jego instrukcje techniczne są przemyślane (zna operatorkę, AI, generatory). Twoja wartość = wykonać precyzyjnie i zauważyć realne ryzyko, nie wymyślać alternatywę. Łączy się z [[prezentacja-dla-usera-nie-zargon]].

REGUŁA LICENCYJNA (badge — decyzja usera, kończy kłótnię o FLUX): model wolno użyć komercyjnie, gdy ma (1) otwartą licencję wag (Apache/MIT/BSD) albo (2) badge „Commercial use" na stronie modelu fal (fal deklaruje wtedy prawo do komercyjnej usługi mimo zamkniętych wag). Jedyne źródło prawdy + tabela: fal-media/references/licencje-fal.md ([[licencje-fal]]).

FLUX rozstrzygnięty: blanket-ban ZNIESIONY. schnell = Apache (czysty). flux-pro/flux-2-pro/kontext/fill/outpaint przez API = komercyjnie OK — płacąc za wywołanie kupujesz prawa komercyjne (to spełnia pierwotny warunek usera „chyba że opłacisz licencję"). Zakazany zostaje TYLKO `flux-dev` (licencja non-commercial).

Nadal FORBIDDEN (non-commercial/academic upstream — badge tego nie naprawia): relight/iclight, live-portrait(+video), instant-char/InstantID/IP-Adapter-FaceID (InsightFace), hunyuan-portrait (academic), krea2 (Krea-2 licencja warunkowa → dla rosnącej agencji ryzyko, traktuj jak zakaz), face-swap/swap (prawo do wizerunku + AUP).

Why: user był ostry o brak licencji komercyjnej FLUX — słusznie; research wykazał, że obawa jest spełniona kryterium badge (API = prawa komercyjne w cenie wywołania) i że tylko flux-dev jest realnie zakazany. Blanket-ban był za szeroki i blokował mocne narzędzia (flux-2-pro/edit+outpaint).

How to apply: przed użyciem NOWEGO modelu sprawdź [[licencje-fal]]. Do ludzi domyślnie [[ludzie-tylko-zimage]] (Z-Image — nie z powodu licencji FLUX, tylko jakości skóry). Chirurgia lokalna = crop-stitch (nie full-image). Łączy się z [[assety-musza-byc-generowalne]], [[mockup-fal-odrzucony-jako-kierunek]].

Lokalny composite / edycja pikseli (PIL, rembg, ImageMagick) do obróbki finałowych obrazów — wycinanie figury, wymiana lub przesuwanie tła, off-center, dorabianie cienia — NIE nadaje się. Daje rozmazane krawędzie, brudne tło, artefakty na górze/dole kadru.

Why: User wielokrotnie to sygnalizował, ostatnio ostro: „zawsze mówię że ten PIL się nie nadaje a ty się upierasz". Composite rembg+PIL (przesunięcie figury off-center + doklejone tło) dał rozmazany dół i górę oraz brudne tło — do kosza. Upieranie się przy lokalnym sklejaniu zamiast fal to strata czasu i jakości.

How to apply: Każda edycja obrazu → fal.ai: nano-edit z --ref (zachowanie tożsamości/geometrii), bg-remove (tło z alpha), fill z maską (inpaint), esrgan (upscale). Zmiana kompozycji/kadru/tła z zachowaniem konkretnej pozy — rób przez regenerację z powtórzeniem pozy w promptcie albo nano-edit, NIGDY przez lokalne sklejanie warstw. Jeśli fal nie umie danej operacji z zachowaniem 1:1 — zgłoś userowi ograniczenie i zaproponuj regenerację, nie improwizuj PIL-em. Wzmacnia regułę rdzenia 8. Łączy się z [[assety-musza-byc-generowalne]] i [[wykonuj-instrukcje-doslownie]].

ZAKAZ makro / ekstremalnego zbliżenia detalu (np. makro tkaniny/plis/faktury) jako obraz sekcji Odyssey. User odrzucił kadr „standard = MATERIA makro bez twarzy" wprost: „był zakaz makro detalu".

Why: makro-detal nie trzyma poziomu/spójności serii editorial-fashion i user go nie chce w tym projekcie. How to apply: projektując serię kadrów NIE proponuj makro/close-up faktury jako rozwiązania na „oddech/wyciszenie" sekcji — użyj pełnej/średniej kompozycji o innej pozie i walorze. Powiązane: [[seria-rozne-pozy]], [[assety-musza-byc-generowalne]].

Nigdy nie generuj (ani nie projektuj w briefie/karcie kadru) obrazu kobiety, w którym materiał/taśmy/paski owijają lub krzyżują się na odsłoniętej skórze ciała (gołe ramiona, tors, brzuch) w sposób sugerujący związanie/spętanie — nawet jeśli intencją artystyczną jest metafora (np. "marka skrępowana złym narzędziem", "napięcie", "ciasna forma"). Dotyczy też: ręce widocznie przyciśnięte/unieruchomione do ciała przez materiał, głowa opuszczona/submisyjna w połączeniu z odsłoniętą skórą i "więzami".

Why: User zobaczył wygenerowane drafty sekcji o metaforze "marki uwięzionej w złym narzędziu" — koncept "figura skrępowana, ramiona wciśnięte" miał być metaforą napięcia, ale model zwizualizował to dosłownie jako kobietę z gołym torsem owiniętą krzyżującymi się taśmami, ręce przyciśnięte, głowa w dół. Werdykt usera: to wygląda jak strona dla napastnika, nie studia designerskiego. To nie był błąd wykonania (krój/kadr) — zły koncept WIZUALNY u źródła, mimo że subagent przeszedł własny audyt fizyki (dłonie, materiał) i zgłosił „pass" — audyt fizyki/wykonania NIE łapie problemów treściowych/etycznych tego typu, więc nie polegaj na nim jako jedynym filtrze.

How to apply: Przy projektowaniu KAŻDEJ pozy/kadru z metaforą "ograniczenia, napięcia, ciasnoty, bycia uwięzionym" (typowe w briefach o "marka uwięziona w szablonie/narzędziu") — unikaj dosłownego związania ciała materiałem na odsłoniętej skórze. Napięcie/ograniczenie pokazuj przez: sztywność/nienaturalność POSTAWY (spięte ramiona, cofnięta głowa, napięta linia pleców), zbyt MAŁĄ/SZTYWNĄ formę ubioru która nie pozwala się swobodnie poruszać (ale ubiór zakrywający, nie paski na gołej skórze), albo kompozycję/przestrzeń (figura wciśnięta w róg kadru, ograniczona przestrzeń wokół). Przy planowaniu kadru z kontra-art/cinematic — jeśli opis pozy zawiera słowa "skrępowana/spętana/wciśnięta/związana" + "odsłonięta skóra" w jednym kadrze, to czerwona flaga do przeprojektowania KONCEPTU, nie tylko promptu. Łączy się z [[assety-musza-byc-generowalne]] (przewiduj efekt PRZED generacją), ale to jest węższe i poważniejsze niż „czy się wyrenderuje" — to „czy treść jest właściwa".

Zasada inpaintu (dokumentacja HuggingFace diffusers + praktyka): modele inpaint Z ZAŁOŻENIA zmieniają obszar POZA maską ("more likely to change your unmasked area"). Zachowanie reszty kadru to OSOBNY, obowiązkowy krok — "overlay / paste-back": wklejenie oryginalnych pikseli spoza maski z powrotem na wynik modelu. Każdy poprawny pipeline to robi (diffusers apply_overlay/padding_mask_crop, ComfyUI "crop-and-stitch", A1111 "inpaint only masked"). Część usług generatywnych (m.in. z-image inpaint na fal.ai) POMIJA ten krok i zwraca surowy output modelu — wtedy CAŁA scena (twarz/strój/światło) dryfuje niezależnie od rozmiaru maski i siły. To nie wina parametrów ani niekompetencji — usługa jest niekompletna, brak jej finalnego compositingu.

How to apply — poprawka MAŁEGO regionu (dłoń, oko, detal) z zachowaniem reszty kadru 1:1: gdy dostępne narzędzie inpaint nie zachowuje obszaru poza maską, jedyna działająca metoda to crop-and-stitch: (1) wytnij z ORYGINAŁU ciasny region wokół defektu z marginesem; (2) wyślij do modelu TYLKO ten wycinek — model nie widzi reszty, więc nie może jej zmienić; (3) wklej poprawiony wycinek z powrotem w to samo miejsce (granicę trzymaj w płaskiej fakturze/tle, feather krawędzi → szew niewidoczny). To NIE jest "frankenstein" (wycinanie elementu z INNEGO obrazu — słusznie zakazane): tu model robi 100% pracy nad defektem, a my przywracamy nietknięte piksele TEJ SAMEJ fotografii — standardowy mechanizm inpaintu, który poprawny pipeline robi pod maską automatycznie. Pełna regeneracja (nawet tym samym seedem + zmieniony fragment promptu) NIE rozwiązuje "zachowaj dokładnie ten kadr, popraw detal" — zmienia tożsamość/strój. Łączy się z [[ludzie-tylko-zimage]], [[zakaz-flux-licencja]] (dedykowane modele inpaint typu FLUX fill robią to natywnie, ale licencyjnie zakazane).

ZASIĘG: TYLKO projekt Odyssey (korekta usera: „zakaz rzemiosła był tylko do Odyssey — chciałem rozkładówkę, a wciskano mi warsztat"). W innym projekcie motyw rzemiosła może być właściwy — nie przenosić tego zakazu automatycznie.

W Odyssey: żadnych odwołań do rzemiosła / warsztatu / rękodzieła / typografa-przy-pracy / dłoni-przy-pracy / czcionek / atramentu / „craftu" — w obrazach, metaforach, koncepcjach sekcji. Kierunek Odyssey = magazyn/rozkładówka (Vogue), nie warsztat.

Why: User zakazywał tego wielokrotnie w Odyssey, bo skill kontra-art ciągnął imagery z narracji copy (studio = rzemieślnik) i uparcie wracał do warsztatu wbrew jego kierunkowi.

Globalne jądro (to JEST wieczne, dla każdego projektu): świat wizualny ustala USER, nie agent wnioskujący z copy. Gdy user wskazał kierunek, nie proponuj uparcie świata wyprowadzonego z „o czym jest firma" — patrz [[koncept-z-dystansu-nie-z-branzy]].

How to apply: W briefach/zleceniach Odyssey wpisuj zakaz jako twardą granicę. W innych projektach: stosuj tylko jądro (świat ustala user).