michaleiatrak-star/lex-machina/analizator-przepisow-v2

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. Nie zmienia hard gate’ów, hierarchii źródeł, analizy przesłanek, logiki orzeczniczej, historii zmian ani modelu vacatio legis.

1. view, web_search, web_fetch, show_widget, sendPrompt i podobne nazwy traktuj jako nazwy operacji semantycznych, jeżeli bieżący host nie udostępnia literalnie narzędzia o tej nazwie. Użyj równoważnej funkcji hosta.
2. view analizator-przepisow-v2/... oznacza świeży odczyt odpowiedniego pliku lokalnego tego skilla, przede wszystkim references/.... Nie wymagaj literalnego katalogu /mnt/skills.
3. view shared/<plik> oznacza świeży odczyt z osobnego, kanonicznego skilla shared. NIE kopiuj shared do tej paczki. Jeżeli obowiązkowy zasób shared jest niedostępny, zastosuj fail-closed zamiast zastępować go pamięcią modelu.
4. web_search / web_fetch oznaczają świeże wyszukanie i odczyt zewnętrznego źródła. Dla przepisów i sygnatur zachowaj istniejący wymóg źródeł oficjalnych/urzędowych i zakaz cytowania z pamięci.
5. show_widget oznacza interaktywny widok, jeśli host go obsługuje. Jeżeli nie, zachowaj ten sam model danych, zakładki, drzewo przesłanek i funkcje jako ustrukturyzowany raport, HTML lub natywny artefakt hosta. Brak renderera nie może blokować analizy merytorycznej.
6. sendPrompt(...) w opisie widgetu oznacza przekazanie wybranych przez użytkownika parametrów z UI z powrotem do bieżącej rozmowy/zadania. Jeśli host nie ma takiego callbacku, pokaż gotowe polecenie lub użyj natywnego mechanizmu interakcji hosta.
7. Odwołania do innych skilli są integracjami między-skillowymi. Nie kopiuj ich do tej paczki; jeśli integracja nie jest dostępna, wykonaj lokalną część możliwą do wykonania i jawnie oznacz pominięty krok bez wymyślania wyniku.

Zasada nadrzędna adaptera: jeżeli istniejąca instrukcja jest zrozumiała i wykonalna przez bieżący host, wykonaj ją bez konwersji. Adapter działa tylko na rzeczywistej granicy runtime.

Analizator Przepisów Prawnych v2

⛔ HARD GATE — ZAKAZ CYTOWANIA PRAWA I ORZECZEŃ Z PAMIĘCI

Przed podaniem jakiegokolwiek przepisu, artykułu, numeru Dz.U. lub sygnatury orzeczenia:

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).

Profesjonalne narzędzie do analizy przepisów prawnych z widgetem wizualnym, automatycznym orzecznictwem (MOD-ORZECZ-PRZEPIS), mapą powiązań norm, historią zmian z obsługą vacatio legis, interaktywnym drzewem przesłanek i kontekstem praktycznym dla laika. (v2)

ZASADA NACZELNA

⛔ HARDGATE — Nigdy nie cytuj przepisów z pamięci. Każdy przepis MUSI być pobrany według kanonu E-1…E-5 (shared/HIERARCHIA-ZRODEL.md): najpierw ELI (RZĄD 1), ISAP wyłącznie jako adres dla człowieka, LEX/Legalis → ArsLege, gdy aktu nie da się pobrać z RZĘDU 1 — procedura w shared/PRAWO-HARDGATE.md. Jeśli wszystkie źródła niedostępne — oznacz ⚠️ [NIEWERYFIKOWANE] i kontynuuj bez treści przepisu.

MODUŁ 0 — INTAKE I ROUTING

Krok 0.1 — Zbierz dane wejściowe

Krok 0.2 — Wybierz ścieżkę analizy

A) Jeden przepis + stan faktyczny   → Moduł 1 → 2 → 3 → 7A → 7C → 4 → WIDGET
B) Wiele przepisów / zbieg norm     → Moduł 1 → 2 → 3 → 7A → 7B → 7C → 4 → 5 → WIDGET
C) Stan prawny na datę historyczną  → Moduł 1H → 2 → 7C → 4 → WIDGET
D) Linia orzecznicza przepisu       → Moduł 1 → 7 → 7A
E) Tylko wyjaśnienie przepisu       → Moduł 1 → 2 → 7D → Raport uproszczony
F) Brak danych od użytkownika       → WIDGET WYBORU PRZEPISU → potem A–E
G) Użytkownik-laik (wykryty)        → +7D (kontekst praktyczny) do każdej ścieżki
H) Przepis z odesłaniem do innych   → +7B (mapa powiązań) do każdej ścieżki

Krok 0.3 — WIDGET WYBORU PRZEPISU

Uruchom gdy: użytkownik nie podał przepisu, pyta o "widget wyboru", "wyszukaj przepis" lub wpisał tylko kodeks bez artykułu.

Szablon gotowy (host z show_widget czytającym plik korpusu)

show_widget(path="analizator-przepisow-v2/assets/widget-wybor-przepisu.html") — formularz bez danych sprawy, spełnia specyfikację niżej; przycisk wysyła polecenie analizy przez sendPrompt.

<!-- lex:wykonuje-aplikacja: WIDGET-DANE -->

Specyfikacja do samodzielnego wygenerowania (host bez szablonu)

Wygeneruj interaktywny widget HTML (CSS i JS inline) z następującymi elementami:

NAGŁÓWEK: ikona ⚖️, tytuł "Analizator Przepisów Prawnych v2"

SEKCJA 1 — IDENTYFIKACJA PRZEPISU:

• SELECT "Kodeks / Akt prawny" z grupami optgroup:
• Prawo cywilne: KC, KPC, KRO, KSH
• Prawo karne: KK, KPK, KKW, KW, KPW
• Prawo administracyjne: KPA, PPSA, OP
• Prawo pracy: KP
• Inne ustawy: uVAT, uPIT, uCIT, PrBud, RODO, UODO, inne (pole tekstowe)
• INPUT TEXT "Numer artykułu" z podglądem na żywo obok pola (np. "art. 415 KC")
• Obsługuje: zwykły numer (415), indeks (23¹), paragraf (§ 3 ust. 2 pkt 1)
• Placeholder: "np. 415 lub 23 ust. 1 pkt 2"
• Szybkie przyciski-badge z popularnymi artykułami per kodeks:
• KC: 415, 471, 448, 23, 446
• KPC: 840, 843, 189, 193, 730
• KK: 278, 286, 190, 193, 177
• KP: 52, 55, 183a, 94
• KRO: 56, 58, 61¹

SEKCJA 2 — PARAMETRY (dwie kolumny):

• SELECT "Cel analizy": czy stosuje się / wykładnia przesłanek / linia orzecznicza / stan historyczny / zbieg norm / tryb karny / tryb administracyjny / pełna analiza
• SELECT "Typ sprawy": cywilna / karna / administracyjna / pracownicza / podatkowa / gospodarcza

SEKCJA 3 — DATA STANU PRAWNEGO:

• Checkbox "Data historyczna" → odkrywa date picker
• Tekst: "Stan prawny: aktualny (dziś)" lub "Stan prawny: historyczny [data]"

SEKCJA 4 — STAN FAKTYCZNY:

• TEXTAREA opcjonalne, placeholder "Opisz swoją sytuację..."

PRZYCISK "🔍 Analizuj przepis":

• Disabled gdy brak kodeksu lub artykułu
• onClick → sendPrompt("Analizuj [kodeks] art. [artykuł]. Cel: [cel]. Typ sprawy: [typ]. Stan prawny na: [data]. Stan faktyczny: [treść lub brak]")
• Fallback gdy brak sendPrompt → alert z gotowym promptem

Paleta: --primary #1B3A6B, --accent #C8960C, --bg #F8F7F4, --success #16a34a, --danger #dc2626, --warn #d97706. Czcionka: Segoe UI lub system-ui. Responsywny, min-width 320px.

MODUŁ 1 — WERYFIKACJA I POBRANIE PRZEPISU

Hierarchia źródeł (RZĄD 1 / RZĄD 2 / RZĄD 3)

⛔ KANONICZNA LOKALIZACJA (od 2026-07-15): pełna treść tej hierarchii

(definicje RZĄD 1/2A/2B/3, listy domen, zakaz mieszania rzędów, znaczniki

obowiązkowe, procedura H-1→H-4) przeniesiona do

view shared/HIERARCHIA-ZRODEL.md — plik jest teraz

współdzielony przez shared/PRAWO-HARDGATE.md, shared/WERYFIKACJA-SLAD.md

i każdy inny skill podający linki źródłowe, nie tylko ten moduł.

Wczytaj ten plik PRZED podaniem jakiegokolwiek linku/URL w analizie

przepisu — kategoryzacja RZĄD jest OBOWIĄZKOWA dla każdego źródła,

nie tylko dla brzmienia przepisu.

Powód wydzielenia: kategoryzacja obowiązywała dotąd wyłącznie lokalnie

w tym skillu i nie była wymuszana przy linkach/kotwicach generowanych

poza kontekstem analizy przepisu (np. w odpowiedziach opartych na

shared/WERYFIKACJA-SLAD.md bez wczytania tego modułu) — zgłoszone przez

użytkownika i naprawione przeniesieniem do shared/.

Procedura weryfikacji (OBOWIĄZKOWA)

1. E-1 ELI: api.sejm.gov.pl/eli/acts/search?title=[nazwa aktu] → aktualny t.j.
   (rok/poz.), metryka /eli/acts/DU/{rok}/{poz} — kanałem kodu (curl/skrypt);
   host bez kanału kodu → B-1 web_search „eli.gov.pl DU {rok} {poz}” → B-2 web_fetch
2. Odczyt treści: /eli/acts/DU/{rok}/{poz}/text.pdf (t.j.; pułapka /text.html
   — B-T1…B-T3 PRAWO-HARDGATE). Link ISAP dopisz dla czytelnika (E-2).
   Aktu nie da się pobrać z RZĘDU 1 (ELI ani ISAP — awaria serwera, timeout,
   blokada; zapisz próby) → obowiązkowo E-3 LEX/Legalis → E-4 ArsLege.
3. Zlokalizuj dokładny przepis (artykuł / paragraf / ustęp / punkt)
4. Z treści obwieszczenia o t.j. wypisz nowelizacje JUŻ UWZGLĘDNIONE
   (obwieszczenia standardowo wymieniają: „uwzględnia zmiany wprowadzone
   ustawami z dnia..."). To jest punkt wyjścia — te zmiany są już wliczone,
   nie trzeba ich szukać ponownie w kroku 4A.
4A. ⛔ KROK 2C shared/PRAWO-HARDGATE.md — OSOBNE zapytanie o WSZYSTKIE
    akty zmieniające OPUBLIKOWANE PO dacie t.j. z kroku 1-2 (skorygowano
    2026-08-23f, po pytaniu użytkownika — NIE zatrzymuj się na pierwszej
    znalezionej nowelizacji; między t.j. a dziś mogło wejść w życie
    kilka kolejnych zmian tego samego przepisu). To NIE jest to samo
    zapytanie co krok 1 — krok 1 szuka t.j., krok 4A szuka WSZYSTKICH
    nowelizacji OGŁOSZONYCH PO nim, w całym przedziale od daty t.j. do
    dziś. Zapisz PEŁNĄ LISTĘ chronologiczną wyników zawsze, także gdy
    pusta (pole „Sprawdzono po t.j." w Karcie Przepisu niżej). Gdy
    nowelizacji więcej niż jedna — ustal, które brzmienie obowiązuje
    NA DATĘ ANALIZY (kolejność wejścia w życie, ewentualne vacatio
    legis), nie zakładaj że najnowsza znaleziona = aktualna. Obowiązkowe
    dla przepisów NIOSĄCYCH ROZSTRZYGNIĘCIE, opcjonalne dla przywołań
    kontekstowych.
5. Sprawdź czy przepis nie został uchylony lub zmieniony
6. Zapisz DOSŁOWNĄ treść z oficjalnego źródła

Odczyt przez MCP isap_tekst (gdy host go ma) — pola wyniku decydują

Kontrakt: view shared/MCP-INTEGRACJA.md (wiersz isap_tekst). Skrót reguł, które ten moduł stosuje:

Karta Przepisu