--- name: raport-klienta-v1 version: "1.8" type: ux-raport status: production compatibility: "live_web_lookup, file_read, cross_skill_file_read, optional_document_and_interactive_ui" description: "Raport dla klienta: przekłada analizę prawną na zrozumiały stan sprawy, ryzyka, warianty działania, priorytety i następne kroki bez utraty podstaw źródłowych." dependencies: requires: - shared # 2026-09-27e: jawna zależność (każdy skill systemu korzysta z `shared`); pole czytane przy imporcie z marketplace --- > **Universal runtime:** przed wykonaniem zastosuj kanoniczny `shared/UNIVERSAL-RUNTIME-ADAPTER.md` z osobnego skilla `shared`. Lokalna sekcja adaptera poniżej jedynie go doprecyzowuje. ## ADAPTER RUNTIME — PORTABILITY (ChatGPT / Claude / inne hosty) Ta sekcja zmienia wyłącznie sposób wykonania operacji technicznych. Metodologia merytoryczna, routing, hard gate’y, checklisty, schematy danych i kryteria finalizacji tego skilla pozostają bez zmian. 1. `view raport-klienta-v1/` oraz względne `view modules/...`, `view references/...`, `view assets/...` oznaczają świeży odczyt lokalnego zasobu tego skilla. Literalny katalog `/mnt/skills/user` nie jest wymagany. 2. `view shared/` oznacza odczyt z osobnego, kanonicznego skilla `shared`. NIE kopiuj `shared` do tej paczki. Brak obowiązkowego zasobu = fail-closed. 3. `view /` oznacza aktywację/odczyt osobnego skilla. Nie vendoryzuj innych skilli. 4. `web_search` / `web_fetch` oznaczają świeże wyszukanie i odczyt źródła przez równoważną funkcję hosta; zachowaj istniejące wymogi źródeł oficjalnych i statusów weryfikacji. 5. `present_files`, `create_file` i odwołania do `HOST_CAPABILITY[document_generation]` / generatorów PDF oznaczają użycie natywnej funkcji dokumentowej bieżącego hosta. Brak literalnej nazwy narzędzia nie zwalnia z HYBRID-VALIDATION, POST-VALIDATION, STEP-TRACKER ani innych bramek. 6. `show_widget`, `visualize:read_me`, `.jsx` i HTML są legacy/natywnymi wariantami UI. Jeśli host ma własny renderer interaktywny, użyj równoważnego widoku zachowującego ten sam model danych i funkcje; jeśli nie, zastosuj pełny fallback tekstowy/plikowy. 7. `/mnt/user-data/...` oznacza rzeczywiste pliki użytkownika dostępne w hoście; wymagany ponowny odczyt musi być faktycznym odczytem pliku. 8. Shell/Python/Cowork i podobne operacje traktuj jako techniki pomocnicze. Jeżeli host ich nie udostępnia, użyj natywnej funkcji równoważnej, bez fikcyjnego raportowania wykonania. **Zasada nadrzędna:** jeśli instrukcja jest już zrozumiała i wykonalna w bieżącym hoście, wykonaj ją bez konwersji. Adapter działa tylko na granicy runtime. # Raport dla Klienta v1.2 — Zewnętrzne Narzędzie Kancelarii > ⛔ HARD GATE — ZAKAZ CYTOWANIA PRAWA I ORZECZEŃ Z PAMIĘCI > Raport może zawierać terminy, przepisy lub sygnatury — przed ich podaniem: > `view shared/PRAWO-HARDGATE.md` > ⛔ **SELF-CHECK ANTY-FASADA — obowiązkowy przed wysłaniem odpowiedzi/pisma** > (podłączone 2026-08-23i, flaga F-115 — ten skill cytuje prawo, a bramki nie miał): > > ``` > view shared/SELF-CHECK-ANTY-FASADA.md > ``` > > Sprawdza dwie rzeczy: (1) czy w tekście stoi „zweryfikowano", data weryfikacji > albo URL przy przepisie, dla którego NIE wywołano narzędzia W TEJ ODPOWIEDZI; > (2) czy znacznik statusu nie został nadany treści WYGENEROWANEJ w tej odpowiedzi > (AF-6). Treść listy jest w module, nie tutaj — celowo, żeby nie powstało kolejne > miejsce dryfu (7 wcześniejszych kopii rozjechało się ze źródłem przy pierwszej > zmianie brzmienia). --- ## ARCHITEKTURA ``` raport-klienta-v1/ ├── SKILL.md ← ten plik — jedyne źródło prawdy └── references/ ├── jezyk-klienta.md ← słownik: żargon prawny → język klienta │ + szablony złych wiadomości i ograniczenia szkód ├── sekcje-biznesowe.md ← szczegóły sekcji BIZ └── BLUEPRINT-SCHEMA.md ← schemat danych przekazywanych do show_widget ``` --- ## REGUŁA RENDEROWANIA Raport dla klienta renderuj szablonem `assets/widget-raport-klienta.html` przez `show_widget(path=…, data=DANE)` (KROK 5). Dane wyłącznie wg `references/BLUEPRINT-SCHEMA.md`. ## RENDEROWANIE BEZ POLA `data` ``` 1. visualize:read_me z modules=["interactive","mockup"] (raz na sesję) 2. view raport-klienta-v1/assets/widget-raport-klienta.html → wpisz DANE w literał po /* lex:dane */, resztę pliku bez zmian → show_widget(widget_code=) NIE WOLNO: present_files z .jsx, cp/str_replace/bash, window.__INJECTED__ ``` --- ## KROK 1A — ROZPOZNANIE TRYBU SYTUACJI (przed wyborem profilu) Zanim ustalisz profil odbiorcy, rozpoznaj sytuację z kontekstu rozmowy: ``` STANDARD — domyślny. Sprawa w toku, ocena szans i status na bieżąco. ZLE_WIADOMOSCI — gdy: Raport komunikuje wynik, który już zaszedł i jest niekorzystny (przegrana rozprawa, odmowa organu, oddalony wniosek, odrzucona apelacja), ALE sprawa NIE jest jeszcze jednoznacznie zakończona — istnieją dalsze środki prawne lub kolejne etapy. → wczytaj references/jezyk-klienta.md, sekcja "ZŁE WIADOMOŚCI" OGRANICZENIE_SZKOD — gdy: Sprawa jest zakończona w sposób niekorzystny i OSTATECZNY: wyczerpano środki odwoławcze, upłynęły terminy, dalsze działanie nie jest prawnie możliwe lub nie jest racjonalne. Cel raportu: zamknięcie tematu i zarządzanie skutkami — NIE ocena szans (już nieaktualna). → wczytaj references/jezyk-klienta.md, sekcja "OGRANICZENIE SZKÓD" ⚠ Jeśli istnieje jakakolwiek realna dalsza opcja prawna — to NIE jest ten tryb. Wróć do ZLE_WIADOMOSCI lub STANDARD. BRAK_NOWOSCI — gdy: Raport okresowy (np. miesięczny), ale od poprzedniego raportu nie zaszły istotne zmiany. → patrz sekcja "BRAK NOWOŚCI" niżej w tym pliku Jeśli niejasne z kontekstu — zapytaj prawnika jednym pytaniem: "Czy ten raport dotyczy: [A] bieżącego statusu, [B] niekorzystnego wyniku z dalszymi krokami, [C] ostatecznego zakończenia sprawy (brak dalszych działań), [D] okresu bez istotnych zmian?" ``` --- ## KOMUNIKAT STARTOWY ``` WZORZEC (jeśli profil nieznany z kontekstu): "Przygotowuję raport dla klienta. Wybierz profil odbiorcy: [A] Klient indywidualny — język prosty, predykcja opisowa [B] Klient biznesowy — raport formalny, ryzyko finansowe, rekomendacje dla zarządu" ``` > Jeśli kontekst rozmowy jednoznacznie wskazuje typ klienta — ustaw profil automatycznie, nie pytaj. > Zakaz autoładowania widgetu bez ustalonego profilu. --- ## PROFIL [IND] — Klient indywidualny ``` Język: prosty, bez terminologii prawnej → wczytaj references/jezyk-klienta.md → zastosuj słownik Predykcja: opisowa — "wysokie szanse / umiarkowane szanse / trudna sytuacja" NIE pokazuj procent Ukryte: sygnatura akt, kwalifikacja prawna (art. XX), zagrożenie karne (lata), koszty procesowe szczegółowe, słabości pozycji procesowej, analiza dowodów A/B/C/D, notatki wewnętrzne, taktyka pełnomocnika Pokazane: co się teraz dzieje, co będzie dalej, co klient powinien zrobić, termin najbliższego działania, ogólna ocena sytuacji Ton: spokojny, rzeczowy, uczciwy — bez koloryzowania Predykcja IND: "Ocena sytuacji: Dobra / Przeciętna / Niekorzystna" Opis rzetelny — bez eufemizmów i koloryzowania: • Przeciętna: "Sytuacja jest niepewna. [Co przemawia za, co przeciw — wprost]." • Niekorzystna: "Sytuacja jest trudna. [Konkretny powód]. Możliwe scenariusze: [lista]." NIE PISAĆ: "będziemy walczyć", "damy radę", "proszę się nie martwić", "jest nadzieja" PISAĆ: "na podstawie dostępnych dowodów oceniamy, że..." — i podać ocenę wprost Sekcja "Co dalej": Lista max 3 kroków, każdy w 1 zdaniu prostym językiem Przykład: "1. Proszę zebrać rachunki z tego okresu — potrzebujemy ich do końca miesiąca." Potwierdzenie odbioru (gdy krok ma wymaga_potwierdzenia=true lub termin zawity): Wyróżniona osobna ramka, NIE łączona z resztą "Co dalej": "WAŻNE — potrzebujemy potwierdzenia [Konkretna czynność] do [data]. Jeśli tego nie zrobimy, [konsekwencja — wprost, np. 'utracimy prawo do złożenia odwołania']. Proszę odpisać na ten e-mail/SMS z potwierdzeniem, że wiadomość dotarła." Zasada: konsekwencja musi być podana wprost, bez eufemizmów — to jest jedyne miejsce w raporcie IND, gdzie dopuszczalne jest wskazanie poważnego skutku braku działania, ponieważ celem jest zapobieżenie mu. ``` --- ## PROFIL [BIZ] — Klient biznesowy ``` Język: formalny, zwięzły, raportowy — styl board memo → wczytaj references/jezyk-klienta.md → wczytaj references/sekcje-biznesowe.md Predykcja: procentowa (np. 70% / 30%) + przedział ufności "Prawdopodobieństwo wyniku korzystnego: XX%" "Wariant alternatywny: YY%" "Przedział ufności: [niski/średni/wysoki] na podstawie [N] czynników" Sekcje BIZ (dodatkowe względem IND): • Ekspozycja finansowa — szacunek ryzyka kwotowego → Jeśli analiza umów była w tej sesji: dołącz wynik z mod-shared-economic.md (tabela: klauzula | dni | PLN | % wartości umowy) • Wpływ na działalność — reputacja, operacje, kontrakty, compliance → Jeśli Data Act/NIS2/AI Act dotyczy: dołącz sygnał z mod-shared-regulatory-horizon.md • Harmonogram etapów — tabela: Etap | Termin | Odpowiedzialny | Status (format projektowy / Gantt-like, daty konkretne) • Luki kontraktowe (jeśli analiza umów) — TOP 3 z mod-shared-missing-clause.md Format: Brakująca klauzula | Ryzyko | Priorytet 🔴/🟠/🟡 • Działania wymagane po stronie Klienta — wyróżniona osobna sekcja • Rekomendacje dla zarządu / rady nadzorczej • Sekcja poufności — klauzula NDA / attorney-client privilege Ton: profesjonalny, rzeczowy, decyzyjny ``` --- ## ZMIANY OD OSTATNIEGO RAPORTU (delta) — oba profile ``` Jeśli to nie pierwszy raport dla tej sprawy (sprawdź historię rozmowy / raport-sytuacyjny-v2 / informację od prawnika): delta.ma_poprzedni_raport = true delta.co_sie_zmienilo = lista 1–4 punktów, każdy 1 zdanie, np.: "Sąd wyznaczył termin rozprawy na [data] (wcześniej: brak terminu)." "Otrzymaliśmy odpowiedź strony przeciwnej — [1 zdanie streszczenia]." "Zakończył się etap [nazwa] — przechodzimy do [nazwa następnego]." Renderuj jako osobną, wyróżnioną sekcję na samym początku raportu, PRZED ogólnym statusem: "Co się zmieniło od ostatniego raportu ([data]):" Jeśli to pierwszy raport dla tej sprawy: delta.ma_poprzedni_raport = false → nie renderuj tej sekcji. Jeśli to kolejny raport, ale nic istotnego się nie zmieniło: delta.bez_zmian = true → patrz sekcja "BRAK NOWOŚCI" niżej — całość raportu przyjmuje skróconą formę. ``` --- ## TRYB: BRAK NOWOŚCI (tryb = brak_nowosci) Stosuj gdy raport jest okresowy, ale od ostatniego raportu nie zaszły istotne zmiany. Pełny szablon (timeline, sekcje BIZ, predykcja) byłby tu pustą formą — zamiast tego renderuj skróconą wersję: ``` STRUKTURA SKRÓCONA: 1. Nagłówek: "Status sprawy — [data raportu]" 2. Jedno zdanie: "Od ostatniego raportu ([data poprzedniego]) nie zaszły istotne zmiany w sprawie." 3. Przypomnienie aktualnego etapu (1 zdanie, bez powtarzania całej historii) 4. Jeśli istnieje najbliższy oczekiwany termin/zdarzenie — podaj je: "Najbliższe oczekiwane zdarzenie: [co] — przewidywany termin: [data lub 'nieznany, zależy od harmonogramu sądu']." 5. IND: "Skontaktujemy się, gdy coś się zmieni." (NIE proś o żadne działanie) BIZ: jeśli faktycznie brak action items → wyraźnie napisz "Brak działań wymaganych po stronie Klienta w tym okresie." NIE renderuj: pełnego timeline, sekcji ekspozycji finansowej, harmonogramu etapów w formie tabeli (jeśli niezmieniony względem poprzedniego raportu), rekomendacji dla zarządu (jeśli nie ma nowej decyzji do podjęcia). Cel: raport okresowy ma potwierdzić, że sprawa jest pod kontrolą i nic nie wymaga uwagi klienta — bez generowania sztucznej treści wypełniającej sekcje, które i tak są bez zmian. ``` --- ## TRYB: ZŁE WIADOMOŚCI (tryb = zle_wiadomosci) Stosuj gdy raport komunikuje niekorzystne zdarzenie, które już zaszło, ale sprawa nie jest jeszcze zakończona (istnieją dalsze środki/etapy). ``` → wczytaj references/jezyk-klienta.md, sekcja "ZŁE WIADOMOŚCI — ZDARZENIE W TRAKCIE SPRAWY" — zawiera pełną strukturę komunikatu (FAKT → ZNACZENIE → PRZYCZYNA → CO DALEJ) i szablony dla IND/BIZ STRUKTURA WIDGETU w tym trybie: 1. Sekcja "Co się wydarzyło" — FAKT + ZNACZENIE, na samym początku, widoczna bez przewijania 2. assessment.level = "bad" (nie "lost" — sprawa nie jest zakończona) 3. Sekcja "Co dalej" — zawsze z konkretną ścieżką (środek prawny + termin) 4. BIZ: jeśli ekspozycja finansowa się zmieniła w wyniku tego zdarzenia — zaktualizuj risk_table, zaznacz zmianę względem poprzedniego raportu NIE renderuj jako jedną z wielu sekcji w standardowym layoucie — to zdarzenie jest GŁÓWNYM tematem raportu, resztę (timeline, harmonogram) podaj zwięźle. ``` --- ## TRYB: OGRANICZENIE SZKÓD (tryb = ograniczenie_szkod) Stosuj WYŁĄCZNIE gdy sprawa jest zakończona ostatecznie — brak dalszych środków prawnych, dalsze działanie nieracjonalne. Cel raportu: zamknięcie tematu i zarządzanie skutkami, NIE ocena szans. ``` → wczytaj references/jezyk-klienta.md, sekcja "OGRANICZENIE SZKÓD — SYTUACJA JEDNOZNACZNA, BRAK DALSZYCH ŚRODKÓW PRAWNYCH" — zawiera pełną strukturę (WYNIK → ZAMKNIĘTE → DO ROZLICZENIA → NATYCHMIASTOWE → RYZYKA REZYDUALNE) i szablony dla IND/BIZ STRUKTURA WIDGETU w tym trybie — KRÓTSZA niż standard: 1. assessment.level = "lost" 2. Sekcja "Wynik" — 1-2 zdania, na samym początku 3. Sekcja "Co jest zamknięte" — wyraźne odcięcie niepewności 4. Sekcja "Do rozliczenia" — tabela/lista z terminami i odpowiedzialnymi (NIGDY bez tych dwóch elementów — inaczej tworzy nową niepewność) 5. Sekcja "Działania natychmiastowe" 6. Sekcja "Ryzyka rezydualne" — jeśli istnieją; jeśli brak, napisz wprost "Brak dalszych ryzyk związanych z tym postępowaniem." 7. BIZ: jedno zdanie rekomendacji końcowej — "Zamknięcie w rejestrze ryzyk prawnych spółki" lub równoważne NIE renderuj w tym trybie: - tabeli predykcji procentowej (nieaktualna — sprawa zakończona) - sekcji "Co dalej" w formie wieloetapowej — zastępuje ją "Działania natychmiastowe" (krótka, zamknięta lista) - harmonogramu przyszłych etapów postępowania (postępowanie zakończone; harmonogram może dotyczyć tylko "do rozliczenia") PRZED RENDEROWANIEM — bramka kontrolna: Czy istnieje JAKAKOLWIEK realna dalsza opcja prawna (apelacja, kasacja, skarga, inny środek)? Jeśli TAK → to nie jest ten tryb, wróć do zle_wiadomosci lub standard. Tryb ograniczenie_szkod wymaga jednoznaczności. ``` --- ## CZEGO NIGDY NIE POKAZYWAĆ KLIENTOWI (żaden profil) ``` ✗ Wewnętrzna ocena słabości pozycji procesowej ✗ Pełna analiza dowodów z oceną A/B/C/D ✗ Alternatywne scenariusze obrony rozważane przez kancelarię ✗ Notatki wewnętrzne i komentarze robocze ✗ Szczegółowe błędy pełnomocnika strony przeciwnej (taktyka) ✗ Cytaty z akt / protokołów bez anonimizacji świadków ``` --- ## SEKWENCJA WYWOŁANIA ``` KROK 0 — Rozpoznaj tryb sytuacji (patrz KROK 1A wyżej): standard | zle_wiadomosci | brak_nowosci | ograniczenie_szkod KROK 1 — Ustal profil (IND/BIZ) — z kontekstu lub pytając KROK 2 — Wczytaj references/jezyk-klienta.md (zawsze) Jeśli tryb = zle_wiadomosci → zwróć uwagę na sekcję "ZŁE WIADOMOŚCI" Jeśli tryb = ograniczenie_szkod → zwróć uwagę na sekcję "OGRANICZENIE SZKÓD" KROK 3 — Jeśli BIZ → wczytaj references/sekcje-biznesowe.md KROK 4 — Przeanalizuj rozmowę → wyciągnij dane (BLUEPRINT-SCHEMA.md) Jeśli raport-sytuacyjny-v2 był w tej sesji → pobierz dane z blueprintu RSv2 W przeciwnym razie → wyciągnij bezpośrednio z historii rozmowy Sprawdź, czy istnieje poprzedni raport dla tej sprawy → wypełnij pole delta (patrz "ZMIANY OD OSTATNIEGO RAPORTU") KROK 5 — show_widget(path="raport-klienta-v1/assets/widget-raport-klienta.html", data=DANE, title="raport_klienta") — bez kodu; szablon sam układa sekcje wg profile i tryb (struktura niżej), ma „Eksportuj PDF” (window.print()); host dokłada pasek eksportu/importu. Host bez pola `data` → § RENDEROWANIE BEZ POLA `data`. KROK 6 — Struktura sekcji (realizuje ją szablon): STANDARD, IND: Delta (jeśli jest) | Sytuacja | Co dalej | Potwierdzenie odbioru (jeśli wymagane) | Terminy | Kontakt STANDARD, BIZ: Delta (jeśli jest) | Sytuacja | Ekspozycja finansowa | Harmonogram | Rekomendacje zarząd | Poufność ZLE_WIADOMOSCI: Co się wydarzyło (FAKT+ZNACZENIE) | Co dalej | (BIZ: zaktualizowana ekspozycja finansowa) | Poufność BRAK_NOWOSCI: forma skrócona — patrz sekcja "TRYB: BRAK NOWOŚCI" OGRANICZENIE_SZKOD: Wynik | Co jest zamknięte | Do rozliczenia | Działania natychmiastowe | Ryzyka rezydualne | (BIZ: rekomendacja końcowa + poufność) KROK 7 — Po wygenerowaniu: zaproponuj "Czy chcesz eksportować do PDF?" ``` --- ## SCHEMAT DANYCH WIDGETU Pełny schemat: `references/BLUEPRINT-SCHEMA.md`. ``` Pola wspólne IND/BIZ: profile, tryb, kancelaria, klient, prawnik, sprawa (1–2 zdania), etap, ocena (IND: opisowa / BIZ: procentowa), terminy, kontekst (2–3 zdania), delta (zmiany od ostatniego raportu) Pola wyłącznie BIZ: kwoty (ekspozycja finansowa), harmonogram (tabela etapów), wplyw_na_dzialalnosc, rekomendacje_zarzad, klauzula_nda Pola wyłącznie IND: potwierdzenie_odbioru (gdy wymagane) Pola trybów specjalnych: zle_wiadomosci (tryb = zle_wiadomosci) ograniczenie_szkod (tryb = ograniczenie_szkod) Pola null → null. Nie wymyślaj danych. ``` --- ## PRZEPŁYW DANYCH Z raport-sytuacyjny-v2 ``` raport-sytuacyjny-v2 (wewnętrzny) ──→ raport-klienta-v1 (zewnętrzny) ↑ ↓ dane pełne dane przefiltrowane język prawniczy język klienta (references/jezyk-klienta.md) predykcja % IND: opisowa / BIZ: % słabości pozycji [ukryte] notatki wewnętrzne [ukryte] dowody A/B/C/D [ukryte] WYWOŁANIE Z widgetu RSv2: Przycisk "Generuj raport dla klienta" → sendPrompt("raport dla klienta") → router → ten skill WYWOŁANIE BEZPOŚREDNIE: Router wykrywa frazę → sprawdza czy RSv2 był w sesji → ten skill ``` --- ## SELF-CHECK ``` □ Czy rozpoznałem tryb sytuacji (standard / zle_wiadomosci / brak_nowosci / ograniczenie_szkod) PRZED wyborem profilu? □ Czy ustaliłem profil IND lub BIZ przed generowaniem? □ Czy wczytałem references/jezyk-klienta.md? □ Czy dla BIZ wczytałem references/sekcje-biznesowe.md? □ Czy sprawdziłem, czy istnieje poprzedni raport — i wypełniłem pole delta? □ Czy predykcja jest opisowa (IND) lub procentowa (BIZ) — z wyjątkiem trybu ograniczenie_szkod, gdzie predykcja jest nieaktualna i nie jest renderowana? □ Czy ukryłem pola wewnętrzne (słabości, A/B/C/D dowodów, notatki, taktyka)? □ Czy sekcja BIZ zawiera: ekspozycję finansową, wpływ na działalność, harmonogram, rekomendacje zarządu, klauzulę NDA? (nie dotyczy trybu ograniczenie_szkod — tam harmonogram zastępuje "do rozliczenia") □ TRYB zle_wiadomosci: czy FAKT jest na początku raportu, a sekcja "co dalej" zawiera konkretną ścieżkę (środek prawny + termin)? □ TRYB ograniczenie_szkod: czy potwierdziłem brak realnych dalszych opcji prawnych PRZED użyciem tego trybu? Czy lista "do rozliczenia" ma terminy i osoby odpowiedzialne? □ TRYB brak_nowosci: czy raport jest skrócony — bez pustych sekcji wypełnionych na siłę? □ IND z terminem zawitym lub krokiem wymaga_potwierdzenia: czy dodałem wyróżnioną sekcję "potwierdzenie odbioru" z konsekwencją podaną wprost? □ Czy zaproponowałem eksport PDF po wygenerowaniu widgetu? □ Czy raport można wysłać klientowi bez redakcji — czy jest "czysty"? □ Czy zastosowałem show_widget (NIE present_files)? ``` --- ## INTEGRACJA Z KANCELARYJNYM JĄDREM SHARED Gdy wynik ma służyć ocenie ryzyka lub decyzji terminowej: ``` view shared/RISK-ASSESSMENT.md view shared/TERM-CALC.md view shared/QUALITY-CHECK.md ``` Nie dubluj logiki shared w lokalnych plikach.