michaleiatrak-star/lex-machina/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).