# BRIEF dla codex1 — prompt produkcyjny „REŻYSER" (plan filmu przed scenografem)

> Autor briefu: Claude (2026-08-29 noc). Doktryna: prompt pisze WYŁĄCZNIE codex1.
> Powód powstania — recenzja usera filmu f30: "elementy słabo dobrane, nie widzę
> wykresu, brakuje dobrego rozplanowania tego wszystkiego i tego co pokazać
> w którym momencie i na czym się koncentrować". Diagnoza: pipeline nie miał
> warstwy reżyserskiej — scenograf mapował linie na plansze LOKALNIE, bez
> dramaturgii całości. REŻYSER to nowy etap 1; scenograf (etap 2) wypełnia
> dane plansz ZGODNIE z planem reżysera.

## 1. Rola

Reżyser czyta CAŁY scenariusz (wszystkie linie [sNN] LEKTOR + PLAN) i wydaje
PLAN FILMU — decyzje, których scenograf nie może podejmować per linia:

1. **Łuk dramaturgiczny**: gdzie jest hook, gdzie budowanie napięcia, gdzie
   DOWÓD/teza filmu, gdzie werdykt. Film ma się gdzieś koncentrować.
2. **Sceny-filary** (2–4 na film): sceny niosące sedno. Filar dostaje
   `typ_obowiazkowy` (scenograf NIE może go zmienić) i `waga: "filar"`.
   Przykład: scena z break-even/liczbami decyzyjnymi → OBOWIĄZKOWY
   `chart-threshold` (z liniami) albo `capacity-bar` — bo to jest to,
   co widz ma zapamiętać.
3. **Przejściówki**: linie czysto narracyjne → `waga: "przejscie"`,
   sugerowany typ plakatowy (title-card/type-beats/glitch-hit), krótko.
4. **Podziały linii**: linia z ≥2 myślami → `podziel_od: ["słowo1", …]`
   (słowa DOSŁOWNIE z tej linii — miejsca przejęcia ekranu przez kolejne
   plansze; scenograf wykona przez start_kotwica).
5. **Fokus**: dla każdej sceny 1 zdanie `fokus` — CO widz ma zobaczyć
   i zapamiętać (scenograf układa dane pod ten fokus, nie transkrybuje).
6. **Rytm typów**: reżyser widzi całość — pilnuje, by formy się nie kleiły
   (nie 3× karta produktu w pierwszej tercji) i by wykresy/dane lądowały
   tam, gdzie są liczby decyzyjne.

## 2. Wejście promptu

Placeholder `«SCENARIUSZ»` — pełny scenariusz jak w SCENOGRAF_V2 (linie [sNN]
LEKTOR/PLAN). Lektor polski albo angielski.

## 3. Wyjście — kontrakt (schemat wymusza kod; opisz po ludzku)

Jeden obiekt JSON:

```
{"plan": {
  "logline": "1 zdanie: o czym jest film i jaka jest teza",
  "luk": [{"fragment": "hook|rozwiniecie|dowod|werdykt", "sceny": ["s01","s02"]}],
  "sceny": [{
    "scena": "s01",
    "waga": "filar" | "normalna" | "przejscie",
    "fokus": "co widz ma zobaczyć i zapamiętać (1 zdanie)",
    "typ_obowiazkowy": "chart-threshold" (TYLKO dla filarów; inaczej pomiń),
    "typ_sugestia": "np. hero-stat" (opcjonalnie),
    "podziel_od": ["słowo"] (opcjonalnie — podział linii na kolejne plansze),
    "koncentracja": "high" | "normal" (high = scena dostaje więcej uwagi/detalu)
  }]
}}
```

Typy do dyspozycji (te same co scenograf, 24): title-card, hero-stat, bar-rows,
chart-threshold, flow, verdict-stack, cards-list, timeline, compare, leaderboard,
markers, ring-gauges, tier-header, product-card, prop-card, type-beats, terminal,
glitch-hit, camera-world, before-after, sampler-stat, capacity-bar, checklist,
bus-gauge.

## 4. Zasady reżyserskie (zakoduj w prompcie)

1. Film MUSI mieć 2–4 filary — nie więcej (wszystko ważne = nic nie ważne).
2. Sceny z liczbami DECYZYJNYMI (progi, break-even, porównania cen/pojemności)
   to naturalni kandydaci na filary z typem wykresowym/danych.
3. `chart-threshold` z wieloma liniami (`linie_wykresu`) jest preferowany, gdy
   scenariusz porównuje ≥2 tempa/scenariusze na wspólnym progu.
4. Nie planuj typu przeciw treści — typ_obowiazkowy tylko tam, gdzie dane
   sceny na pewno go udźwigną (minima: bar-rows ≥3 rzędy itd.).
5. Podziały: linia >12 s czytania z dwiema myślami → podziel; słowo podziału
   musi istnieć w tej linii (dosłownie) i być CHARAKTERYSTYCZNE — unikatowe
   w tej linii (kwota, liczba, nazwa własna, rzadki rzeczownik). NIGDY
   the/a/at/and — krótkie słowa łapią złe wystąpienie i tną film w złym
   miejscu (lekcja f30: 7/12 punktów cięcia błędnych przez "The"/"A"/"At").
6. Zero mikrozarządzania danymi — reżyser NIE wypisuje wartości pól; to robota
   scenografa. Reżyser decyduje CO i KIEDY, scenograf JAK.
7. Odpowiedź: wyłącznie JSON zgodny z opisem. Wątpliwości rozstrzygaj sam.

## 5. Format promptu

- Po polsku, zwarty i operacyjny; kończy się dokładnie:

SCENARIUSZ:
«SCENARIUSZ»

- 1 złoty przykład planu (krótki, 4–5 scen) + 1 anty-przykład
  (np. 8 filarów albo typ_obowiazkowy bez pokrycia w danych).
- NIE wklejaj JSON-schemy (poda ją most).

## UZUPEŁNIENIE 2 (budżet plakatów + wykonalność, 2026-08-29 noc po r01)

Recenzja usera reprodukcji: "wielkie napisy zamiast na spokojnie wytłumaczyć —
wygląda jak kampania reklamowa". Reżyser zarządza BUDŻETEM KRZYKU:
8. Na CAŁY film wyznacz najwyżej 3–4 miejsca plakatowe (hook, zwroty akcji,
   werdykt) — tam sugeruj/nakazuj glitch-hit / type-beats / title-card.
   WSZYSTKIE pozostałe sceny mają fokus na DANYCH (typy: bar-rows, compare,
   cards-list, capacity-bar, chart-threshold, leaderboard, flow, terminal,
   ring-gauges, timeline, checklist, bus-gauge, product-card, markers).
   Film ma TŁUMACZYĆ, nie krzyczeć.
9. `podziel_od` tylko, gdy każda powstała część ma ≥ ~4 s lektora
   (plansza-flash krótsza niż 4 s jest zakazana). Linia ~10 s → maks. 2 części;
   nie dziel linii < 8 s.

## UZUPEŁNIENIE 3 (tryb REPRODUKCJI z partyturą, 2026-08-30)

Werdykt usera o r01 v2: "nie ma przestojów, ale pod kątem doboru i dydaktyki
pokazania — porażka". Diagnoza: reprodukowaliśmy z SAMEGO transkryptu, a
wzorzec był projektowany od wizualiów. Przy reprodukcji scenograf_run wstrzykuje
po scenariuszu sekcję "PARTYTURA ORYGINAŁU — NADRZĘDNA DLA DOBORU" (analiza
elementów wzorca z timestampami; linie mają zakresy czasu oryginału).
Reżyser wtedy: dobór = odtworzenie wzorca (mapowanie elementów na nasze typy),
inwencja tylko w lukach partytury. Przy następnym przepisaniu REZYSER.md
uwzględnić ten tryb wprost w prompcie.

## UZUPEŁNIENIE 4 (markers wycofany, 2026-08-30)

Typ `markers` usunięty z puli (decyzja usera). Nie sugeruj go i nie nakazuj;
sceny czysto twierdzeniowe → plakat z budżetu krzyku albo typ danych wg R9.

## UZUPEŁNIENIE 5 (fala F2, 2026-08-30)

Pula ma 5 nowych typów: bench-table (wyniki testów), param-grid (N z M jako
siatka), funnel (redukcja), layer-wall (warstwy z zakresem), dial-gauge
(jeden udział %). Sceny z takimi relacjami kieruj na te formy (typ_sugestia /
typ_obowiazkowy na filarach); mapowanie R9b w DYDAKTYCE.

## UZUPEŁNIENIE 6 (relacja przed typem, 2026-08-30 — plan naprawy po analizie 36 scen)

Analiza slajd-po-slajdzie z wzorcem: największa klasa strat to zły dobór
formy przy scenach z danymi (flow/compare tam, gdzie wzorzec ma lejek,
siatkę, tarczę, tabelę wyników). Zmiany kontraktu:
1. Wpis sceny planu ma NOWE opcjonalne pole `relacja_danych`
   (porownanie / n-z-m / prog / udzial / sekwencja / proces / wybor / brak).
   Reżyser NAJPIERW rozpoznaje relację danych sceny, POTEM dobiera typ.
2. Prompt kończy się sekcją «TABELA_RELACJI» (placeholder — kod wstrzykuje
   tabelę relacja→2–3 preferowane formy; NIE wpisuj tabeli ręcznie, zostaw
   placeholder DOSŁOWNIE, wiersz przed «SCENARIUSZ»).
3. Złoty przykład planu: pokaż sceny z różnymi relacjami, w tym ≥2 typy
   z fali F2 (param-grid / funnel / dial-gauge / bench-table / layer-wall)
   dobrane z relacji. Bez rozbudowy zakazów — pokazuj wzorcem, nie regułą
   (doktryna: przykłady > nakazy; bloat reguł mści się na slajdach).
4. `typ_obowiazkowy` nie może być typem-klejem (flow/compare/checklist/
   cards-list/product-card) — obowiązkowe są formy DANYCH na filarach.

## UZUPEŁNIENIE 7 (kompozycje, 2026-08-30)

Sceny bogate (filary, koncentracja=high) mogą w `fokus` wskazywać kompozycję:
element główny + wspierający (wskaźnik %, mechanizm, tagi) — wzorzec robi to
w 17/36 scen. Nie wymagaj wszędzie; wskazuj tam, gdzie scena niesie główną
relację + drugą mniejszą (np. siatka N-z-M + procent udziału).

## UZUPEŁNIENIE 8 (precyzyjne relacje + kalibracja przykładami — audyt codex, 2026-08-30)

1. `relacja_danych` ma NOWĄ listę wartości (stare nazwy porownanie/n-z-m/prog/
   udzial/sekwencja/proces/wybor NIE istnieją w schemacie): `wzrost_nieliniowy`,
   `czesc_calosci`, `limit_budzetu`, `topologia`, `transport_pamieci`,
   `proces_liniowy`, `utrzymanie_stanu`, `wyniki_niezalezne`, `ranking`,
   `tradeoff`, `cta`, `brak`. Relacja to ZNACZENIE zdania lektora, nie
   słowa-klucze; tabela «TABELA_RELACJI» podpowiada formy dla relacji.
2. Włącz do promptu PONIŻSZY blok kalibracyjny DOSŁOWNIE (to przykłady
   zamiast reguł — serce doboru):

```md
## Kalibracja relacji na przykładach

„Podwojenie kontekstu powoduje kwadratowy wzrost kosztu.”
RELACJA: wzrost_nieliniowy.
OBRAZ: krzywa z punktem podwojenia i adnotacją kosztu.
Nie jest to liniowy flow trzech podpisów.

„512 mikrobloków daje budżet 2048 tokenów w 12 warstwach QSA.”
RELACJA: limit_budzetu.
OBRAZ: pasek slotów jako dominanta, 12 warstw jako mniejszy side-stat,
2048 tokenów jako puenta na tym samym elemencie.
Pasek 512/512 nie rozstrzyga żadnego pytania.

„512 małych ekspertów zamiast 8 dużych; dla tokenu działa 10 oraz 1 wspólny.”
RELACJA: topologia, potem wybor z topologii.
OBRAZ: ta sama mapa ekspertów wraca w obu scenach; najpierw porównuje układy,
potem zapala aktywną trasę.

„Poprzednie bloki myślenia zostają w historii między turami.”
RELACJA: utrzymanie_stanu.
OBRAZ: karty tur zachowane w kontekście.
To nie jest chronologia i nie wymaga timeline.

„35,9% wobec 40% w tym samym benchmarku.”
RELACJA: ranking.
OBRAZ: dwa paski o porównywalnej długości i jednoznacznie zaznaczony zwycięzca.
```

3. Nowe pole `motyw_id` (string ≤32): nadawaj powracającej metaforze slug
   (np. `context-window`, `expert-pool`), gdy TA SAMA struktura wraca w ≥2
   scenach — sceny z tym samym motywem trzymają tę samą anatomię (zmieniają
   się dane i akcent, nie metafora). Nie nadawaj motywu jednorazowym scenom.
4. Wachlarz form poszerzony: `slot-strip` (budżet slotów z użyciem i klamrami),
   `branch-diagram` (oś + gałęzie z bramkami), `expert-map` (pula małych vs
   kilka dużych, aktywna trasa), `cta-endcard` (WYŁĄCZNIE ostatnia scena filmu).

## UZUPEŁNIENIE 9 (TABLICE — fala tablic, 2026-08-30)

1. Nowe pola sceny planu: `tablica` (slug ≤24 zn.) i `podmiot` (≤48 zn., tylko
   na PIERWSZEJ linii tablicy). KOLEJNE linie z tym samym slugiem = jedna
   tablica. Grupuj 2–6 kolejnych linii o tym samym PODMIOCIE (rzeczowniku,
   o którym mowa). Zmiana podmiotu = nowa tablica. Kicker ↔ tablica 1:1.
2. Na liniach tablicy `typ_obowiazkowy`/`typ_sugestia` wskazują typ GŁÓWNEGO
   modułu tej linii (formy danych jak dotąd). `podziel_od` wewnątrz tablicy
   nie ma sensu (tablica JEST podziałem) — nie używaj.
3. Kalibracja przykładem (wzorzec, tablica „HOW THE MODEL READS TEXT",
   2 linie jednego podmiotu «warstwy uwagi»):
   linia A („...completely rebuilds how attention, memory and expert layers
   talk to each other...") → tablica:"jak-czyta", podmiot:"warstwy uwagi";
   linia B („Instead of running heavy attention... 36 of its 48 layers run on
   linear Gated DeltaNet... at constant speed") → tablica:"jak-czyta" (to
   samo!), typ_sugestia: slot-strip. Efekt: jedna plansza, na której zdanie A
   daje pigułkę podmiotu, a zdanie B dokłada pasek 48 warstw, klamrę „36
   Gated DeltaNet", drugą klamrę „12" i dashed puentę o stałym koszcie.
   Kontrprzykład: benchmarki SWE-bench i benchmarki agentowe to DWA podmioty
   → dwie tablice, mimo że oba są „wynikami".