Audyt Systemu V4

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 wykonanie operacji technicznych. Tryby audytu, zasady kontroli merytorycznej, map Dz.U., deduplikacji, propagacji zmian, rejestrów i bramek jakości pozostają bez zmian.

1. view audyt-systemu-v4/<plik> oraz względne odwołania do modules/, references/, scripts/ i widgets/ oznaczają świeży odczyt lokalnego zasobu tego skilla. Literalna ścieżka /mnt/skills/user nie jest wymagana.
2. view shared/<plik> oznacza świeży odczyt z osobnego, kanonicznego skilla shared. NIE kopiuj shared do paczki audytora. Brak obowiązkowego zasobu = fail-closed.
3. view <inny-skill>/<plik> oznacza odczyt/aktywację osobnego skilla przez mechanizm hosta. Audyt może kontrolować zależności między skillami, ale nie vendoryzuje ich.
4. web_search / web_fetch oznaczają świeże wyszukanie i odczyt źródła przez równoważną funkcję hosta. Przy audycie prawa zachowaj wymóg źródeł oficjalnych i nie traktuj pamięci modelu jako weryfikacji.
5. present_files, create_file, show_widget, visualize:read_me, Cowork i podobne nazwy są operacjami semantycznymi. Użyj równoważnej natywnej funkcji hosta, jeśli istnieje; jeśli nie, zastosuj tekstowy/plikowy fallback bez fikcyjnego raportowania wykonania.
6. Skrypty w scripts/ mają wykrywać root repo względnie lub z REPO_ROOT/LEX_MACHINA_ROOT; nie zakładaj /mnt/skills/user. Twardy limit wydania pozostaje 200 plików na skill.
7. Audyt treści i narzędzi może raportować Claude-specific lub ChatGPT-specific tokeny jako portability warnings; sama obecność legacy nazwy nie jest automatycznie błędem, jeśli adapter semantyczny zapewnia równoważne wykonanie.
8. Nie ujawniaj prywatnego chain-of-thought jako produktu audytu. Raportuj wykryte fakty, ślady weryfikacji, testy, różnice, ryzyka i rekomendowane poprawki.

Zasada nadrzędna: instrukcje, które są już zrozumiałe i wykonalne w bieżącym hoście, wykonuj bez konwersji. Adapter działa wyłącznie na granicy runtime.

audyt-systemu-v4 — Orchestrator Audytu Systemu Prawnego

Cel

Audyt jakości, spójności i bezpieczeństwa systemu prawniczych skilli AI. Po zakończeniu audytu: obowiązkowa aktualizacja plików references.

⚙️ ZASADA 11 (2026-07-10, STAŁA — nie precedens): Zakres audytu obejmuje wszystkie skille prawne w systemie, nie tylko mapę Dz.U. i skille DR-01 do DR-16. Obejmuje to również skille proceduralne (np. pisma-procesowe-v3, przesluchanie-swiadkow-v2-min90, analizator-dowodow-v3, chronologia-sprawy-v1), gdzie przedmiotem audytu nie jest poprawność numeru aktu prawnego, lecz poprawność i domyślne (nie tylko na żądanie) stosowanie wbudowanych bramek jakości (np. zakazy pytań sugestywnych, wymóg rekonstrukcji tezy, wymóg jawnego potwierdzenia ról/dowodów/tez przed generowaniem treści). Wpis dokumentujący taki audyt trafia do tego samego AUDIT-JOURNAL.md, z jawnym wskazaniem w tytule sekcji, że dotyczy skilla proceduralnego, a nie mapy Dz.U. — żeby FAZA 3 (Dz.U.) nie myliła kontekstów. Ta zasada nie jest jednorazowym wyjątkiem — obowiązuje dla każdego kolejnego audytu, dowolnego skilla w ``.

⚙️ ZASADA 12 (2026-07-16, STAŁA — nie precedens): Audyt map Dz.U. (FAZA 3A–3D) i audyt treści merytorycznej modułów (FAZA 3E, MOD-TRESC-MERYTORYCZNA.md) to dwa odrębne zakresy kontroli, oba obowiązkowe. Aktualizacja numeru/statusu tekstu jednolitego w mapa_dzu/MAPA-AKTOW.md (np. OK → PREV, dodanie nowego wiersza TJ) nie jest równoznaczna ze sprawdzeniem, czy opisowa treść modułu dr-XX/modules/mod-*.md (progi, terminy, definicje, przesłanki) nadal odpowiada aktualnemu stanowi prawnemu. FAZA 3E uruchamia się automatycznie po każdej sesji FAZA 3, w której wykryto zmianę statusu aktu — nie jest opcjonalna i nie wymaga osobnego wywołania. Naruszenie (zamknięcie FAZA 3 bez FAZA 3E mimo wykrytej zmiany) = CRIT.

⚙️ ZASADA 13 (2026-07-17, STAŁA — nie precedens): Ponowna weryfikacja oznaczeń/skrótów prawnych + wytrwałość wyszukiwania + oznaczanie przy każdym użyciu. Pełna treść i uzasadnienie: shared/PRAWO-HARDGATE.md wersja 2.4. Skrót operacyjny na potrzeby audytu:

1. Każde niepotwierdzone źródłowo oznaczenie/skrót prawny, gdy pojawia się PONOWNIE w dalszej części rozmowy jako podstawa wniosku, wymaga NOWEJ weryfikacji — przywołanie z pamięci wcześniejszej hipotezy (nawet własnej) NIE wystarcza i nie podnosi jej do statusu ustalonego faktu.
2. Pierwsze wyszukiwanie bez jednoznacznego potwierdzenia z aktu źródłowego NIE kończy weryfikacji — kontynuuj różnymi zapytaniami (pełna nazwa instytucji/rejestru, synonimy, szersze/węższe ujęcie) zamiast zatrzymywać się na hipotezie prawdopodobieństwa.
3. ⚠️ [NIEWERYFIKOWANE] musi towarzyszyć KAŻDEMU wystąpieniu niepotwierdzonego oznaczenia w odpowiedzi/dokumencie, nie tylko pierwszemu wprowadzeniu.

Przy audycie treści merytorycznej (FAZA 3E) i przy każdym audycie skilli operujących na sygnaturach/repertoriach/oznaczeniach instytucjonalnych — sprawdź zgodność z tą zasadą jako osobny punkt. Naruszenie (powtórne użycie niepotwierdzonego oznaczenia bez ponownej weryfikacji lub bez powtórzonego ⚠️ [NIEWERYFIKOWANE]) = CRIT.

⚙️ ZASADA 14 (2026-07-26, STAŁA — nie precedens): Gradacja źródeł przy weryfikacji merytorycznej (FAZA 3E) — obowiązkowe stosowanie shared/HIERARCHIA-ZRODEL.md (Rząd 1/2A/2B/3), nie tylko przy podawaniu linków użytkownikowi, ale RÓWNIEŻ jako metodologia SAMEJ weryfikacji przy audycie. Ustalone po dwóch transzach FAZA 3E (AUDYT-2026-07-26h/i), na wyraźne polecenie użytkownika.

Procedura, w kolejności:

1. Rząd 1 — ELI, próba pierwsza, zawsze (kanon E-1…E-5, shared/HIERARCHIA-ZRODEL.md, od audytu 6.125). Brzmienie i stan aktu z api.sejm.gov.pl/eli kanałem kodu (text.pdf t.j., /references dla zmian), host bez kanału kodu — B-1 → B-2 na eli.gov.pl. ISAP (isap.sejm.gov.pl) wyłącznie jako link dla człowieka; jego blokada to stan normalny, nie powód do zejścia rzędu.
2. Rząd 2A/2B jako główne potwierdzenie wyłącznie, gdy ELI zawiódł i ISAP (akt niepobieralny z RZĘDU 1 — awaria, timeout, blokada; wynik zapisany): LEX/Legalis, potem lexlege.pl, arslege.pl, prawo.pl i analogiczne z rejestru HIERARCHIA-ZRODEL.md/PORTALE-BRANZOWE-RZAD-2B.md. Traktuj jako wiarygodne dla BRZMIENIA przepisu, ale NIGDY nie zaznaczaj wyniku jako ✅ [VER] tak jakby to był Rząd 1 — użyj oznaczenia zgodnego z shared/WERYFIKACJA-SLAD.md odpowiedniego dla źródła Rządu 2.
3. Rząd 3 (blogi kancelaryjne) — WYŁĄCZNIE jako dodatkowe potwierdzenie zbieżności, NIGDY jako jedyne źródło. Wysoka liczba zgodnych źródeł Rządu 3 (5+) wokół tego samego brzmienia ZWIĘKSZA pewność, ale nie zastępuje braku Rządu 1/2 — jeśli WSZYSTKIE dostępne źródła to Rząd 3, oznacz wynik jako potwierdzony z zastrzeżeniem niższej kategorii źródła, nie jako pełne ✅.
4. Próg potwierdzenia: minimum 2-3 źródła NIEZALEŻNE (różne domeny, różni wydawcy) zgodne ze sobą, zanim twierdzenie modułu zostanie oznaczone jako sprawdzone. Rozbieżność między źródłami = sygnał do DALSZEGO wyszukiwania (inne zapytanie, inny kąt), nie do wyboru jednego źródła arbitralnie (patrz ZASADA 13, pkt 2 — wytrwałość wyszukiwania stosuje się też tutaj).
5. Każdy wynik weryfikacji FAZA 3E w AUDIT-JOURNAL.md wskazuje WYRAŹNIE, z jakiego Rzędu pochodziło potwierdzenie (nie tylko nazwy domen) — np. "potwierdzone w lexlege.pl (Rząd 2B) oraz 5 źródłach Rządu 3" — żeby czytelnik dziennika mógł ocenić siłę dowodową ustalenia bez ponownego sprawdzania.

Naruszenie (oznaczenie twierdzenia jako "zweryfikowane" na podstawie WYŁĄCZNIE jednego źródła Rządu 3, lub bez wskazania Rzędu w ogóle) = WARN, nie CRIT — to zasada jakości dowodu, nie zakaz absolutny jak PRAWO-HARDGATE, ale traktuj ją jako obowiązkową praktykę FAZA 3E.

⚙️ ZASADA 15 (2026-08-20z4, STAŁA — nie precedens; na wyraźne polecenie użytkownika): Historia zmian KAŻDEGO skilla mieszka wyłącznie w osobnym pliku references/CHANGELOG.md. W SKILL.md nie ma sekcji ## CHANGELOG z wpisami — dopuszczalne jest wyłącznie odesłanie do pliku; pole changelog: w YAML pozostaje krótkim skrótem bieżącej wersji (do ~15 linii), nigdy pełną listą wpisów.

Uzasadnienie nie jest porządkowe, tylko funkcjonalne: rozproszenie historii między trzy lokalizacje (korpus SKILL.md, frontmatter, references/) było BEZPOŚREDNIĄ przyczyną fałszywych wyników testu T12 w sesji 2026-08-20z3 — test szukał wpisów w references/, nie znajdował ich (bo leżały w SKILL.md) i raportował luki, których nie było. W pisma-procesowe-v3 groziło to dopisaniem pięciu zmyślonych wpisów. Jedna lokalizacja kanoniczna usuwa całą tę klasę błędu — i ten sam argument dotyczy każdego przyszłego narzędzia, które będzie czytać historię automatycznie.

Egzekwowanie: test T12 (scripts/check_wersje_changelog.py) zgłasza sekcję z wpisami w korpusie jako ⛔, a pole changelog: dłuższe niż 15 linii jako ⚠️. Nowy skill BEZ references/CHANGELOG.md jest dopuszczalny tylko dopóki nie ma historii — przy pierwszym wpisie plik zakłada się od razu.

FAZA 0 — WCZYTANIE REFERENCES (ZAWSZE PIERWSZE)

⚠️ NAPRAWA 2026-08-15 (F-80, wykryta na skutek pytania użytkownika o scheduled task): 15 plików istniało fizycznie na dysku (references/ i scripts/), ale nie było wpisanych do YAML frontmatter powyżej — dokładnie ten sam wzorzec luki, jaki scripts/check_rejestracja_modulow.py wykrywa dla modułów DR (F-33/F-77), tylko dotyczący plików SAMEGO audyt-systemu-v4. Naprawione: wszystkie 15 plików dopisane do references:/scripts: w YAML. Zawierało: SYNC-DZU-AUTOMATYCZNY.md + HARMONOGRAM-CRON.md + FORMAT-RAPORTU-ROZNIC.md (mechanizm automatyzacji wykrywania nowych pozycji Dz.U. — odpowiedź na pytanie o "scheduled task": TAK, istnieje jako gotowy DO ADAPTACJI kod cron/GitHub Actions, ale wymaga wdrożenia przez developera w środowisku z dostępem do api.sejm.gov.pl — Claude w tej sesji czatu nie ma własnego mechanizmu cyklicznego uruchamiania), 3 archiwalne mapy Dz.U., folder raporty-pokrycia-2026-08-13/, oraz 7 skryptów pomocniczych (w tym check_rejestracja_modulow.py — ironicznie, sam był plikiem-sierotą). Szczegóły: AUDIT-JOURNAL.md, wpis AUDYT-2026-08-15h.

Przed jakimkolwiek działaniem wczytaj:

ODCZYT DZIENNIKA (wyłącznie potrzebny fragment — procedura niżej)
view audyt-systemu-v4/references/WARN-OTWARTE.md
view audyt-systemu-v4/references/CHECKLIST-DEDUP.md
USTAL AKTUALNA_MAPA_DZU: wylistuj references/mapa_dzu_YYYY-MM-DD.md,
wybierz plik z najpóźniejszą datą w nazwie i sprawdź, że da się go odczytać
view AKTUALNA_MAPA_DZU

⛔ Nie wczytuj całego AUDIT-JOURNAL.md (ok. 71 tys. linii, ok. 4 MB) — ani w FAZIE 0, ani w 7A. Odczytuj tylko potrzebny fragment:

J=audyt-systemu-v4/references/AUDIT-JOURNAL.md
# najnowszy wpis = najwyższy identyfikator AUDYT-…, nie ostatnia pozycja w pliku
N=$(grep -n '^## AUDYT-[0-9]' "$J" | LC_ALL=C sort -t' ' -k2,2 | tail -1 | cut -d: -f1)
# odczyt najnowszego wpisu: od linii N do nagłówka następnego wpisu
sed -n "${N},$((N+120))p" "$J" | awk 'NR>1 && /^## /{exit} {print}'
# szablon wpisu (tylko przy pisaniu, FAZA 6/7A)
S=$(grep -n '^## SZABLON NOWEGO WPISU' "$J" | cut -d: -f1); sed -n "${S},$((S+38))p" "$J"

Wcześniejsze wpisy czytaj tylko wtedy, gdy zadanie ich wymaga (np. grep -n 'AUDYT-2026-08-15h' "$J" → odczyt zakresu linii tego wpisu).

⛔ Nie wpisuj na stałe daty bieżącej mapy w procedurze. Każda nowa generacja zmienia nazwę pliku; brak dynamicznego wyboru powodował odwołania do usuniętej mapy z 2026-08-21 mimo obecności mapy z 2026-08-26. Brak choć jednego pliku mapa_dzu_YYYY-MM-DD.md albo błąd odczytu najnowszego = CRIT i STOP.

Celem jest ustalenie:

• Jaki był wynik ostatniego audytu (AUDIT-JOURNAL.md → ostatni wpis ## AUDYT-YYYY-MM-DD)
• Czy wprowadzane zmiany dotyczą pojęcia już skatalogowanego w CHECKLIST-DEDUP.md (jeśli TAK → edytuj lokalizację kanoniczną, NIE twórz nowego wpisu — patrz "PROCEDURA UŻYCIA" w CHECKLIST-DEDUP.md)
• Czy edytowany moduł jest na liście modułów >400 linii (NOTA-4 w CHECKLIST-DEDUP.md) — jeśli TAK, rozważ podział "przy okazji"
• Jakie WARN/flagi są otwarte i wymagają zamknięcia — źródło: WARN-OTWARTE.md (ZASADA 10), NIE przeszukiwanie całego AUDIT-JOURNAL.md
• Jaka jest aktualna mapa skilli i Dz.U.

FAZA 0B — INTERAKTYWNY WYBÓR ZAKRESU

Gdy użytkownik wywołuje audyt bez precyzowania zakresu (np. "przeprowadź audyt", "audytuj system"):

1. Wyrenderuj menu wielokrotnego wyboru: show_widget(path="audyt-systemu-v4/widgets/WIDGET-MENU.md") — host czyta kod JSX z pliku; nie przepisuj go.

2. Host bez path: view audyt-systemu-v4/widgets/WIDGET-MENU.md → show_widget z kodem JSX z pliku.

3. Czekaj na wybór użytkownika. Po otrzymaniu — uruchom tylko wskazane fazy/moduły.

Gdy użytkownik podał konkretny tryb lub zakres → pomiń widget, przejdź bezpośrednio do właściwej fazy.

FAZA 0C — ZADANIE CYKLICZNE W COWORK (POZYCJA 11, TYLKO NA ŻĄDANIE)

(dodane 2026-08-15o; od 2026-10-10 wyłącznie na wyraźne żądanie użytkownika.)

⛔ Nigdy nie proponuj zadania cyklicznego automatycznie — ani na końcu audytu, ani po wykryciu Cowork. FAZĘ 0C uruchamia wyłącznie: wybór pozycji 11 menu (widgets/WIDGET-MENU.md, id harmonogram) albo jednoznaczna prośba użytkownika o utworzenie zadania.

Po takim żądaniu sprawdź łącznie:

1. sesja toczy się w Cowork (poza Cowork: poinformuj jednym zdaniem, nie twórz);
2. użytkownik nie ma jeszcze zadania cyklicznego „Cotygodniowa weryfikacja ISAP" w harmonogramie Cowork.

⛔ Warunku 2 NIE zgaduj — Claude nie widzi listy zadań harmonogramu. Bez jednoznacznego potwierdzenia w kontekście: zapytaj jednym zdaniem.

Jeśli oba spełnione → utwórz zadanie dosłownie wg references/SCHEDULED-TASK-COWORK.md (§ 2A Description, § 2B prompt — treść kanoniczna, bez parafrazy). Blok map pokrycia (§ 3 tamże) dołączaj do promptu wyłącznie po zamknięciu flagi F-83; dopóki otwarta — pomiń i odnotuj. Wynik (utworzono / odmowa / już istniało) zapisz w AUDIT-JOURNAL.md jednym zdaniem.

Wariant natywny (harmonogram wbudowany w Cowork, bez infrastruktury developera): references/COWORK-HARMONOGRAM-NATYWNY.md (do 6.146 plik bez odwołania z treści).

Pozycja 11 może być wybrana samodzielnie albo razem z pozycjami audytowymi (wtedy zadanie tworzy się po audycie).

FAZA 0D — KONTRAKT ROUTERA W PREFERENCJACH (POZYCJA 13, od 6.125)

Po wyborze pozycji 13 albo poleceniu „zsynchronizuj pamięć routera”:

1. view references/PAMIEC-TRWALA-ROUTER.md;
2. porównaj preferencje użytkownika widoczne w kontekście z regułami UP-1…UP-6 routera (treść, nie numer wersji);
3. pokaż rozbieżności i proponowany tekst preferencji (≤ 4 linie, bez numeru wersji) do wklejenia przez użytkownika w Ustawienia → Profil;
4. odnotuj wynik w AUDIT-JOURNAL.md, jeżeli host pozwala na zapis.

⛔ Zakaz zapisu bloków dyrektyw do pamięci trwałej hosta. Pomiar z sesji produkcyjnej: klasyfikator pamięci odrzuca treść sterującą zachowaniem modelu — zapis jest niewykonalny z założenia, a ponowienie lub przeformułowanie stanowiłoby obchodzenie zabezpieczenia. Wynik stały: ZAPIS: NIEOBSŁUGIWANE W HOŚCIE.

FAZA 0E — INSTALACJA SERWERÓW MCP (POZYCJA 14; wybór serwerów i klucz CEIDG od 6.152)

Po wyborze pozycji 14 menu („Instalacja serwerów MCP”, plakietka 🖥️ działa w Claude Desktop) albo poleceniu „zainstaluj serwery MCP”. Narzędzie: mcp-servers/instaluj_serwery_mcp.py (ten skill). Przebieg ma trzy tury: (1) lista wyboru → (2) instalacja wybranych + prośba o klucz CEIDG, jeśli wybrano CEIDG → (3) sam klucz w kolejnej wiadomości → uzupełnienie. Tura 3 jest opcjonalna.

⛔ Działa w Claude Desktop. claude.ai w przeglądarce nie uruchamia serwerów lokalnych — tam wynikiem jest plik rozszerzenia do zainstalowania w Desktopie. Nie obiecuj działania w przeglądarce.

0. LISTA WYBORU (tura 1) — zanim cokolwiek zbudujesz. Jedynym źródłem listy jest python mcp-servers/instaluj_serwery_mcp.py --lista (stan 6.202: 16 serwerów w 3 grupach, numeracja stała); nie przepisuj jej z pamięci. Zapytaj jednym zdaniem, które serwery zainstalować:

• host z przyciskami wyboru (np. ask_user_input_v0, limit 3 pytania × 4 opcje): jedno pytanie multi_select na poziomie GRUP z --lista — „Akty prawne i orzecznictwo”, „Rejestry podmiotów (CEIDG wymaga klucza)”, „Podatki, finanse, dane osobowe”, „Wybiorę numerami”. Pojedynczych serwerów nie rozpisuj na przyciski: grupa orzecznicza ma 9 pozycji, więcej niż mieści pytanie (korekta 6.202 — dawny opis „trzy pytania = trzy grupy, ≤4 opcje” był niewykonalny od dodania sn/sp/tk/kio/etpcz). „Wybiorę numerami” → pokaż wynik --lista i poproś o numery;
• host bez przycisków: pokaż wynik --lista i poproś o odpowiedź numerami, nazwami albo „wszystkie”;
• użytkownik od razu napisał „wszystkie” / wymienił serwery → pomiń pytanie. Przy CEIDG zawsze (także w pytaniu z przyciskami — w zdaniu wprowadzającym) podaj link do klucza: https://dane.biznes.gov.pl/pl/portal/034872 (Hurtownia danych CEIDG: „wypełnij wniosek o dostęp i zarejestruj się”, logowanie Profilem Zaufanym; token JWT = klucz API). Po wysłaniu pytania zakończ turę.

1. Ścieżka pomiarem, nie domysłem (tura 2). python mcp-servers/instaluj_serwery_mcp.py --diagnoza. WYBÓR = numery/nazwy z tury 1 (argument --serwery przyjmuje jedne i drugie).

   • kod 0 — „ŚCIEŻKA: --scal-desktop” (komputer z Claude Desktop: Claude Code, terminal lokalny). Jednym zdaniem uprzedź, że skrypt dopisze wybrane serwery lex-* do claude_desktop_config.json i zrobi kopię .kopia-przed-lex; następnie … --scal-desktop --serwery WYBÓR --bez-pytan. Przekaż wynik dosłownie (✅/⛔, ścieżka kopii); poproś o restart Claude Desktop.
   • kod 3 — „ŚCIEŻKA: --mcpb” (piaskownica: claude.ai, czat Desktop, Cowork): … --mcpb <katalog wyjściowy hosta> --serwery WYBÓR → lex-machina.mcpb tylko z wybranymi serwerami (manifest wymienia wyłącznie ich narzędzia); udostępnij plik (present_files). Instrukcja: Claude Desktop → Ustawienia → Rozszerzenia → zainstaluj z pliku. ⛔ Przy kodzie 3 NIGDY nie uruchamiaj --scal-desktop i nie raportuj „zainstalowano”.
   • Bez wykonania kodu: podaj polecenie do uruchomienia u siebie (python <katalog skilla>/mcp-servers/instaluj_serwery_mcp.py --scal-desktop --serwery WYBÓR) — bez fikcyjnego raportu wykonania (adapter hosta, zasada 5).
   • Wybrano CEIDG, a klucza jeszcze nie ma → na końcu odpowiedzi DOKŁADNIE ta treść w sensie: „Klucz CEIDG uzyskasz tu: https://dane.biznes.gov.pl/pl/portal/034872. Gdy go dostaniesz, wklej w kolejnej wiadomości sam klucz — sprawdzę go i uzupełnię instalację o CEIDG.” (Na ścieżce .mcpb dodaj: albo wpisz go sam w polu „Klucz API CEIDG” rozszerzenia.) Bez klucza serwer CEIDG jest nieaktywny — pozostałe działają normalnie.

2. KLUCZ W KOLEJNEJ WIADOMOŚCI (tura 3). Wyzwalacz: wiadomość, której treścią jest (prawie) wyłącznie token JWT (eyJ….eyJ….…), w rozmowie, w której trwa FAZA 0E albo padła prośba z pkt 1. ⛔ Token to dane osobowe — ładunek (base64, nie szyfrowanie) zawiera PESEL, imię i nazwisko:

   • NIE powtarzaj tokenu ani jego fragmentów w odpowiedzi, NIE dekoduj na głos PESEL-u, NIE zapisuj go w pamięci rozmów ani w plikach skilla; w myśleniu nie przepisuj go ponad potrzebę polecenia;
   • zapisz go do pliku POZA katalogiem skilla z uprawnieniami 600 (piaskownica: plik roboczy hosta, np. ~/.ceidg_token; komputer użytkownika: ~/.lex-machina/ceidg.token);
   • … --ceidg-test --ceidg-klucz-plik PLIK (jedno żądanie; 204/200 = działa, 401 = zły lub wygasły → podaj link ponownie i poproś o nowy klucz; 429 → poproś o ponowienie za kilka minut, nie ponawiaj sam);
   • po teście 204/200: • kod 0 → … --scal-desktop --serwery ceidg --ceidg-klucz-plik PLIK (uzupełnia istniejącą instalację wyłącznie o CEIDG; konfiguracja z tokenem ląduje w ~/.lex-machina/, nie w repo); • kod 3 → … --mcpb <katalog wyjściowy> --serwery WYBÓR --ceidg-klucz-plik PLIK → lex-machina-osobisty.mcpb z kluczem wpisanym na stałe (CEIDG dołączany automatycznie). Powiedz wprost: przed instalacją odinstaluj wcześniejsze „Lex Machina”; plik jest OSOBISTY (zawiera token) — nie udostępniać, nie wrzucać do repozytorium; • w piaskownicy usuń plik z tokenem po zbudowaniu rozszerzenia;
   • przypomnij jednym zdaniem, że token pozostaje w historii tej rozmowy (decyzja użytkownika, czy ją usunąć). Brak wybranego wcześniej zestawu (tura 3 bez tur 1–2) → przyjmij „wszystkie”.

3. Kontrola po instalacji (nowa rozmowa w Claude Desktop): narzędzia lex-* widoczne; wywołanie nbp_kurs_waluty dla EUR (jeśli wybrany) zwraca FOUND; ceidg_szukaj_firmy dla NIP spółki → NOT_FOUND z odesłaniem do KRS (dowód, że klucz działa). cbosa_sprawdz_sygnature „III OSK 1959/22” → FOUND zamyka F-213 (z sandboxa Claude CBOSA jest nieosiągalna).

4. Zapisz w AUDIT-JOURNAL.md jednym zdaniem: ścieżka, wybrane serwery, CEIDG tak/nie — bez tokenu.

FAZA 1 — INWENTARYZACJA SYSTEMU

find "${LEX_MACHINA_SKILLS_ROOT:?}" -not -path "*/archive/*" | sort

Jeżeli host nie udostępnia zmiennej, najpierw rozwiąż semantyczny katalog zainstalowanych skilli wg adaptera runtime i użyj jego rzeczywistej ścieżki.

Zbuduj tabelę: skill → liczba plików → rozmiar → status (✅/⚠️/❌).

Porównaj z ostatnim snapshotem z AUDIT-JOURNAL.md (sekcja "STRUKTURA SYSTEMU — SNAPSHOT"). Wykryj: nowe skille, usunięte skille, zmienione rozmiary.

FAZA 2 — WERYFIKACJA ZALEŻNOŚCI

2A — Spójność ścieżek

Dla każdego SKILL.md sprawdź, czy wszystkie view/load odwołania wskazują na istniejące pliki:

grep -r "view " "${LEX_MACHINA_SKILLS_ROOT:?}" --include="*.md" | grep -v archive

Każda ścieżka nieistniejąca = błąd CRIT.

2B — Wersje skilli w cross-referencjach

Sprawdź, czy żaden skill nie odwołuje się do usuniętej wersji innego skilla (np. v1 zamiast v2):

grep -r "przewodnik-prawny-v1\|analiza-sadowa-v5\|pisma-procesowe-v2" \
  "${LEX_MACHINA_SKILLS_ROOT:?}" --include="*.md" | grep -v archive

Dodaj tu wzorce wg historii napraw z references/CHANGELOG.md i references/CHECKLIST-DEDUP.md. (Do 2026-08-20y ta linia odsyłała do SKILLS-MAP-AND-FIXES — pliku USUNIĘTEGO 2026-06-14g i zastąpionego przez CHANGELOG/CHECKLIST-DEDUP/mapa_dzu. Odwołanie przetrwało 2 miesiące i ~90 sesji, bo FAZA 2A sprawdza tylko ścieżki view, a to była nazwa w prozie — wzorzec do uwzględnienia przy rozbudowie testu T6.)

2C — Pole description: OBECNOŚĆ + profil uniwersalny ≤200 znaków

Wczytaj moduł i uruchom procedurę:

view audyt-systemu-v4/modules/MOD-DESCRIPTION.md

Kontrola automatyczna (test T14, zalecana zamiast ręcznego liczenia):

python3 audyt-systemu-v4/scripts/check_description.py "${LEX_MACHINA_SKILLS_ROOT:?}"

Brak pola / pole puste = CRIT (F-130). Długość >200 = CRIT, 181–200 = WARN, ≤180 = OK. To wspólny profil przenośności; nie utrzymuj osobnych opisów per host.

⛔ ROZSZERZENIE 2026-08-24 (F-130). Ta faza sprawdzała dotąd WYŁĄCZNIE długość — i przez to była ślepa na jedyny przypadek, który naprawdę wystąpił: brak pola w ogóle. Skrypt z MOD-DESCRIPTION.md dla takiego pliku wypisywał 0 znaków i klasyfikował go jako ✅ OK. audyt-systemu-v4 — ten plik — był JEDYNYM skillem w systemie bez description:, przez nieustaloną liczbę sesji, i żadna faza tego nie zgłosiła. Naprawione na wskazanie użytkownika.

FAZA 2D — CZYSTOŚĆ KODU (NOWE MODUŁY)

2D-1 — Zbędne interlinie

Wczytaj moduł:

view audyt-systemu-v4/modules/MOD-INTERLINIE.md

Wykonaj procedurę wykrycia → napraw każdy plik z ≥2 kolejnymi pustymi liniami → zapisz wynik do raportu.

2D-2 — Wstawki opisowe

Wczytaj moduł:

view audyt-systemu-v4/modules/MOD-WSTAWKI.md

Wykonaj skan regex → oceń każde trafienie wg tabeli kwalifikacji → usuń tylko jednoznacznie opisowe wstawki → zapisz wynik do raportu.

Zasada obu modułów: zmiany tylko przez str_replace na skopiowanych plikach. Nigdy sed -i na `` (read-only mount).

FAZA 3 — WERYFIKACJA MAPY Dz.U.

Wczytaj AKTUALNA_MAPA_DZU ustaloną w FAZIE 0. Nie wybieraj mapy na podstawie daty zapamiętanej w tym pliku.

3-PULL — Synchronizacja DR-MAPA-AKTOW → ROUTING-MAP → mapa_dzu

⚙️ Protokół pull — wykonaj PRZED 3A gdy zakres audytu obejmuje TRYB DZU lub pełny audyt. Cel: mapa_dzu musi być spójna z tym co faktycznie mają DR-skills.

Krok 1 — Skan DR-MAPA-AKTOW:

# Zebranie wszystkich Dz.U. z lokalnych map DR
grep -h "Dz\.U\." dr-*/MAPA-AKTOW.md | \
  grep -oP "Dz\.U\. \d{4} poz\. \d+" | sort -u

Krok 2 — Porównanie z ROUTING-MAP.md:

# Znalezienie Dz.U. w MAPA-AKTOW które nie są w ROUTING-MAP
# (wykonuj manualnie: porównaj output Kroku 1 z ROUTING-MAP.md)
view prawo-polskie-v2/ROUTING-MAP.md

Krok 3 — Porównanie z mapa_dzu:

# Znalezienie Dz.U. w ROUTING-MAP których brak w mapa_dzu
# Każdy akt w ROUTING-MAP z Dz.U. powinien mieć wpis w mapa_dzu

Krok 4 — Wykrywanie MONITORING ze wszystkich źródeł:

# Znajdź akty z vacatio legis w DR-MAPA-AKTOW
grep -h "OCZEKUJE\|WCHODZI\|vacatio\|wchodzi w życie" \
  dr-*/MAPA-AKTOW.md | sort -u

Każdy wynik Kroku 4 → sprawdź czy jest wpisany do sekcji MONITORING w:

• mapa_dzu_*.md (tabela MONITORING)
• ROUTING-MAP.md (sekcja MONITORING)

Jeśli brakuje → dodaj do obu plików jako ⏳ OCZEKUJE.

3A — Nowe t.j. od ostatniego audytu

Sprawdź w ELI (api.sejm.gov.pl/eli/acts/search, RZĄD 1; ISAP tylko jako link dla człowieka) czy pojawiły się nowe teksty jednolite dla kluczowych aktów:

• KC, KPC, KPK, KRO, KP, KSH, KPA, PB, PrFarm, PIT, CIT, OrdPod, PrNotariat
• Sprawdź Dz.U. poz. > max_poz z ostatniego audytu (aktualnie: > 1079 z 2026 — najwyższa pozycja odnotowana w sesji 2026-08-21)

3B — Aktualizacja statusów

Jeśli znaleziono nowe t.j.:

• Zmień status starego wpisu: OK → PREV
• Dodaj nowy wiersz do tabeli z: rok, poz., akt, typ=TJ, status=OK, skille (wg mapy), uwagi

3D — Akty oczekujące na wejście w życie (MONITORING)

⛔ UZUPEŁNIENIE LEGENDY 2026-08-15p — brakujący znacznik ⚠️ ALERT. Prompt zadania cyklicznego (references/SCHEDULED-TASK-COWORK.md, § 2B krok 4) każe priorytetyzować „wszelkie ⚠️ ALERT z poprzednich audytów". Kontrola wykazała 0 wystąpień tego znacznika zarówno w SKILL.md, jak i w mapie Dz.U. — krok 4 promptu odsyłał do konwencji, której nigdy nie wprowadzono, więc sesja wykonawcza nie miała czego szukać.

Definicja (od 2026-08-15p): ⚠️ ALERT oznacza w kolumnie uwag mapy akt, którego numer okazał się błędny lub sporny i został skorygowany — czyli pozycję o podwyższonym ryzyku nawrotu, wymagającą sprawdzenia w KAŻDYM kolejnym przebiegu, niezależnie od rotacji. Znaczniki ⏳ OCZEKUJE i ⚡ WCHODZI-90DNI dotyczą PRZYSZŁOŚCI aktu (vacatio legis); ⚠️ ALERT dotyczy PRZESZŁOŚCI rejestru (już raz się pomylił).

Pierwsze pozycje kwalifikujące się do oznaczenia: Kodeks morski (F-82 — numer należał do innej ustawy), PIT/CIT/KC (F-84 — stary t.j. nieziejący statusu PREV), KPSW (błędna „poprawka" z 2026-07-02q, patrz wpis 08-15d).

Po weryfikacji nowych t.j. (3A–3B) sprawdź i zaktualizuj tabelę aktów opublikowanych, które nie weszły jeszcze w całości w życie lub wchodzą etapami.

Dla każdego aktu z tabeli MONITORING wykonaj:

1. Sprawdź w ELI (metryka entryIntoForce + przepis o wejściu w życie — DOSTEP-MASZYNOWY-API §2) czy data wejścia w życie minęła lub zbliża się (horyzont: 90 dni).
2. Jeśli akt wszedł w życie → przenieś do tabeli głównej mapy Dz.U. (zmień typ OCZEKUJE → TJ lub NOV), usuń z MONITORING.
3. Jeśli data jeszcze nie minęła → zaktualizuj uwagi, potwierdź termin.
4. Jeśli akt zastępuje inny → odnotuj w kolumnie Zastępuje (nazwa aktu + stary Dz.U.).

Format tabeli MONITORING (prowadzonej w mapa_dzu_YYYY-MM-DD.md, sekcja osobna na końcu pliku):

Reguły statusów MONITORING:

Przy wpisie do raportu (Faza 6) dodaj sekcję ### 4B. MONITORING — akty oczekujące z aktualnym stanem tabeli.

Przy aktualizacji mapa_dzu (Faza 7B) — tabela MONITORING jest aktualizowana razem z tabelą główną, na końcu pliku.

3C — Rozporządzenia "do weryfikacji"

Otwarte WARN z poprzednich audytów:

• WARN-4: Rozp. RM 2020.2437 (progi PZP) — dr-07
• WARN-5b: Rozp. MS 2015.1800 (stawki komornicze) — analizator-dowodow-v3
• WARN-6: Rozp. RM 2008.1656 (prace uciążliwe) — dr-16

Dla każdego: sprawdź online czy istnieje nowszy akt. Jeśli tak → CRIT. Jeśli nie → zamknij WARN jako "zweryfikowane, bez zmian".

FAZA 3E — WERYFIKACJA TREŚCI MERYTORYCZNEJ MODUŁÓW (ZASADA 12)

Odpowiada na pytanie: skoro FAZA 3A–3D wykryła zmianę numeru/statusu aktu — czy treść modułu DR, która o tym akcie coś twierdzi (progi, terminy, definicje, przesłanki), nadal jest zgodna z aktualnym stanem prawnym? To zakres inny niż poprawność numeru Dz.U. w mapie.

Pełna procedura: modules/MOD-TRESC-MERYTORYCZNA.md — wczytaj przed wykonaniem:

view audyt-systemu-v4/modules/MOD-TRESC-MERYTORYCZNA.md

⭐ Mechanizm uzupełniający (dodany 2026-07-26): gdy transza FAZA 3E ujawni, że MODUŁ SAM ostrzegał o nowelizacji, ale nie zastosował jej do własnej treści (wzorzec z AUDYT-2026-07-26l) — uruchom modules/MOD-PROPAGACJA-NOWELIZACJI.md, żeby sprawdzić, czy TA SAMA nieaktualność występuje też w INNYCH plikach systemu (nie tylko w module "domowym" dla danego aktu). Jedna naprawa punktowa nie gwarantuje, że problem nie powtarza się gdzie indziej.

Uruchamia się automatycznie, gdy FAZA 3 (dowolny podtryb) zakończyła się co najmniej jedną zmianą: nowy TJ (3A/3B), pozycja ✅ WSZEDŁ z MONITORING (3D), lub WARN z 3C zamknięty jako "jest nowszy akt".

⭐ Tryb NA ŻĄDANIE (dodane 2026-07-26): FAZA 3E może być też wywołana samodzielnie, bez poprzedzającej zmiany Dz.U. — użytkownik wskazuje konkretny moduł/dziedzinę do pogłębionej weryfikacji merytorycznej ("sprawdź treść modułu X", "kontynuuj audyt merytoryczny"). W tym trybie KROK 1 (identyfikacja modułu) jest zastąpiony wskazaniem użytkownika lub wyborem audytora wg priorytetu (np. najnowsze/najmniej sprawdzone moduły) — reszta procedury identyczna. Każda taka transza to jeden fragment jednego pliku, nie cały system naraz — traktuj jako iteracyjne, nie jednorazowe zadanie.

Skrót procedury:

1. Zidentyfikuj moduł(y) DR opisujące dotknięty akt (kolumna Moduł w MAPA-AKTOW.md).
2. Ustal w ELI (text.pdf aktu zmieniającego) zakres zmiany — które artykuły dodano/zmieniono/uchylono (zakaz cytowania z pamięci — PRAWO-HARDGATE).
3. Skonfrontuj wyłącznie te twierdzenia modułu, które dotyczą zmienionych artykułów (nie cały moduł).
4. Sklasyfikuj: ✅ ZGODNE / ⚠️ WARN-TREŚĆ / ❌ CRIT-TREŚĆ.
5. CRIT-TREŚĆ → napraw treść modułu w tej samej sesji (str_replace na kopii), z adnotacją źródła i datą weryfikacji.

⚙️ Przy KROKU 2/3 stosuj ZASADĘ 14 (gradacja źródeł, patrz sekcja ZASADY KRYTYCZNE pkt 12 i shared/HIERARCHIA-ZRODEL.md) — Rząd 1 pierwsza próba, Rząd 2B główne potwierdzenie gdy Rząd 1 niedostępny wprost, Rząd 3 wyłącznie jako dodatkowe potwierdzenie zbieżności.

Brak zmian Dz.U. w sesji → FAZA 3E pomijana, odnotuj wprost: FAZA 3E: pominięta — brak zmian Dz.U. w tej sesji (NIE dotyczy trybu NA ŻĄDANIE, który działa niezależnie od FAZA 3A-3D).

Wynik trafia do raportu jako ### 4C. TREŚĆ MERYTORYCZNA MODUŁÓW (FAZA 6) oraz — dla CRIT-TREŚĆ naprawionych — do AUDIT-JOURNAL.md z jawnym odróżnieniem od poprawek czysto numeracyjnych (analogicznie do ZASADY 11 dla skilli proceduralnych).

FAZA 4 — TESTY ANTYHALUCYNACYJNE

4A — Zakaz cytowania z pamięci

grep -r "Dz\.U\. [0-9]\{4\} poz\." "${LEX_MACHINA_SKILLS_ROOT:?}" \
  --include="*.md" | grep -v "isap\|weryfikuj\|MAPA\|mapa_dzu\|references\|archive" | head -30

Hardkodowane Dz.U. bez kontekstu weryfikacji = WARN.

4B — PRAWO-HARDGATE obecny

grep -r "PRAWO-HARDGATE" "${LEX_MACHINA_SKILLS_ROOT:?}" \
  --include="*.md" | grep -v archive | head -10

Brak HARDGATE w routerze = CRIT.

FAZA 5 — SCORING

Dla każdego skilla generuj wynik 0–10:

Wynik < 6.0 = skill wymaga naprawy przed użyciem. Wynik ≥ 8.0 = skill zielony.

FAZA 6 — RAPORT AUDYTU

Generuj raport wg szablonu z AUDIT-JOURNAL.md (sekcja "SZABLON NOWEGO WPISU").

Struktura wymaganego raportu:

## AUDYT-YYYY-MM-DD

### 1. STATUS OGÓLNY
### 2. NAPRAWY WYKONANE (CRIT)
### 3. OSTRZEŻENIA (WARN)
### 4. WERYFIKACJA Dz.U.
### 4C. TREŚĆ MERYTORYCZNA MODUŁÓW (FAZA 3E — patrz MOD-TRESC-MERYTORYCZNA.md)
### 5. STRUKTURA SYSTEMU — SNAPSHOT
### 6. WNIOSKI I ZALECENIA

FAZA 7 — AKTUALIZACJA PLIKÓW REFERENCES ← OBOWIĄZKOWE

Po zakończeniu audytu ZAWSZE zaktualizuj pliki references (7A obowiązkowo, 7B i 7C warunkowo — wg opisu każdej podfazy):

7A — Aktualizacja AUDIT-JOURNAL.md

⛔ KOREKTA 2026-08-15p — reguła doprowadzona do zgodności ze stanem faktycznym. Ta sekcja nakazywała dotąd dopisywanie wpisu „na początku listy" i aktualizację stopki. Kontrola pliku wykazała, że przez co najmniej 15 kolejnych sesji (wpisy 08-15a … 08-15o) wpisy były dopisywane na KOŃCU, a stopka *Ostatnia aktualizacja:* nie była ruszana od 2026-06-09 i tkwi w połowie pliku (ok. w. 18383). Kolejność wpisów w pliku jest dziś mieszana (24 przejścia rosnące i 24 malejące na 698 wpisów) — nie jest ani chronologiczna, ani odwrotna.

Reguła z 2026-08-15p (nakazywała dopisywanie na KOŃCU PLIKU) — zastąpiona praktyką od 2026-10-04h. Od wpisu AUDYT-2026-10-04h kolejne wpisy tworzą na końcu pliku blok w kolejności od najnowszego (10-10a, 10-09h, 10-09g, …, 10-04h); stan zmierzony 2026-10-10.

Stopki NIE reanimujemy jako pola do ręcznej aktualizacji — była martwa przez ponad dwa miesiące, co dowodzi, że nikt jej nie utrzymuje. Datę ostatniego audytu odczytuje się z najwyższego identyfikatora wpisu (nie z pozycji w pliku). Istniejącą stopkę w połowie pliku pozostawiono jako artefakt historyczny z adnotacją.

⚠️ Historyczne warianty (nieaktualne, zachowane dla zrozumienia starych wpisów): wpisy sprzed sierpnia 2026 były wstawiane na początku listy; od 2026-08-15p do 2026-10-04g — na końcu pliku.

Reguła kanoniczna (od 2026-10-04h): nowy wpis ## AUDYT-YYYY-MM-DD[litera] wstaw bezpośrednio PRZED dotychczas najnowszym wpisem (najwyższy identyfikator; dziś pierwszy wpis bloku malejącego przy końcu pliku), bez separatora ---. Litera po dacie rozróżnia kilka sesji tego samego dnia (a, b, c…). Nie oglądaj całego pliku — wystarczą numery linii:

J=audyt-systemu-v4/references/AUDIT-JOURNAL.md
grep -n "^## AUDYT-$(date +%Y-%m-%d)" "$J"                     # wolna litera
N=$(grep -n '^## AUDYT-[0-9]' "$J" | LC_ALL=C sort -t' ' -k2,2 | tail -1 | cut -d: -f1)
sed -n "${N},$((N+15))p" "$J"                                  # kontrola miejsca
# nowy_wpis.md: treść wpisu zakończona jedną pustą linią
python3 - "$J" nowy_wpis.md "$N" <<'PY'
import sys
j, w, n = sys.argv[1], sys.argv[2], int(sys.argv[3])
linie = open(j, encoding="utf-8").read().split("\n")
nowe = open(w, encoding="utf-8").read().rstrip("\n").split("\n") + [""]
assert linie[n - 1].startswith("## AUDYT-"), "linia N nie jest nagłówkiem wpisu"
open(j, "w", encoding="utf-8").write("\n".join(linie[:n - 1] + nowe + linie[n - 1:]))
PY
grep -n '^## AUDYT-[0-9]' "$J" | LC_ALL=C sort -t' ' -k2,2 | tail -2   # nowy wpis = najwyższy

⛔ Nie wstawiaj wpisu na początku pliku, w środku ani za ostatnim wpisem bloku malejącego. Nie używaj str_replace na całym pliku (ryzyko REGUŁY 5).

7B — Aktualizacja mapa_dzu_YYYY-MM-DD.md

Jeśli znaleziono nowe t.j. lub zmiany statusów Dz.U.:

⛔ KOREKTA 2026-08-20y/2026-08-26 — ta sekcja kopiowała mapę ARCHIWALNĄ. Polecenie wcześniej wskazywało datę na stałe, więc stawało się błędne przy każdej nowej generacji. Wykonanie FAZY 7B literalnie cofnęłoby mapę o trzy generacje (06-14 → 07-02 → 07-04 → 07-15), kasując ~250 wierszy ustaleń, i to bez żadnego sygnału błędu — nowy plik powstałby poprawnie, tylko z przestarzałą treścią. To DRUGIE wystąpienie tej samej klasy usterki: identyczną naprawę wykonano w 4.4 (2026-06-14g, „12 miejsc w SKILL.md, w tym FAZA 7B"). Reguła stała: przy każdej zmianie mapy aktualnej sprawdź grep -n mapa_dzu SKILL.md i popraw WSZYSTKIE wystąpienia, nie tylko references:.

1. Utwórz nową wersję pliku z datą bieżącą. Źródłem jest wyłącznie AKTUALNA_MAPA_DZU ustalona dynamicznie w FAZIE 0:

cp "$AKTUALNA_MAPA_DZU" \
   audyt-systemu-v4/references/mapa_dzu_YYYY-MM-DD.md

2. Zaktualizuj w nowym pliku:

   • Nagłówek: **Data weryfikacji:** YYYY-MM-DD
   • Zmień statusy OK → PREV dla zastąpionych t.j.
   • Dodaj nowe wiersze do tabeli (na początku, sortuj malejąco po roku/poz.)

3. Zaktualizuj wpis mapy aktualnej w references:. Procedura FAZY 0 i FAZY 3 pozostaje dynamiczna — nie wolno dopisywać tam nowej daty na stałe.

Jeśli brak zmian Dz.U. — plik mapy pozostaje bez zmian, odnotuj w AUDIT-JOURNAL.md:

Dz.U.: brak nowych t.j. — mapa bez zmian (ostatnia: [nazwa AKTUALNA_MAPA_DZU])