feat(kompletnosc_polon): raport kompletności danych wg rozporządzenia POL-on 2026 (FD#437)

[mpasternak]

Co i po co

Raport kompletności danych wymaganych rozporządzeniem MNiSW z 16 czerwca 2026 r. w sprawie danych przetwarzanych w POL-on (Dz. U. 2026 poz. 811, w życie od 30 czerwca 2026 r.). Zgłoszenie FD#437 — prorektor UAFM przysłał rozporządzenie z prośbą o dostosowanie systemu.

Rozpoznanie dało wynik odwrotny do oczekiwanego: BPP nie potrzebuje nowych pól. § 2 ust. 10 rozporządzenia wylicza praktycznie ten sam zestaw danych, który BPP już utrzymuje na potrzeby eksportu do PBN — łącznie z opłatami APC, pełnym blokiem Open Access i flagą artykułu recenzyjnego. Problemem nie jest brak miejsca na dane, tylko brak widoczności, których danych brakuje i przy kim.

Stąd raport, a nie migracja.

Jak to działa

Nowa aplikacja kompletnosc_polon, bez modeli i bez migracji. Trzy decyzje, które warto znać przy review:

Ziarno to para (autor, osiągnięcie), nie sama publikacja. Rozporządzenie umieszcza osiągnięcia w wykazie pracowników — dane wiszą przy człowieku, a każde osiągnięcie niesie własną dyscyplinę z art. 265 ust. 13. Ten sam artykuł u dwóch współautorów to w POL-onie dwa wpisy. Querysety startują więc z through-modeli (Wydawnictwo_Ciagle_Autor itd.).

Nie da się tego oprzeć na widoku Rekord. bpp_rekord_mat nie wystawia opłat APC ani flag ewaluacyjnych PBN, a strony/tom/nr_zeszytu ma jawnie wygaszone (RekordBase, src/bpp/models/cache/rekord.py:192-260). Jedna trzecia wymogów rozporządzenia byłaby przez ten widok niesprawdzalna.

Reguły są danymi, nie kodem. 50 reguł, każda to (kod, typ osiągnięcia, warunek Q, opis, paragraf, waga). Warunek jest obiektem Q, więc jedna definicja służy do liczenia, filtrowania i testu. Paragraf trafia do interfejsu — użytkownik widzi podstawę prawną, nie samo czerwone pole. Waga odróżnia wymogi bezwarunkowe od tych, które rozporządzenie opatruje słowami „jeżeli posiada" / „jeżeli są znane" — raport ich nie zaostrza.

Zakres

Objęte: artykuły (§ 2 ust. 10 pkt 4), monografie (pkt 5), rozdziały (pkt 6), patenty (pkt 1) — te ostatnie częściowo.

Poza zakresem, bo BPP nie ma gdzie tych danych trzymać:

Wymóg	Paragraf
Osiągnięcia artystyczne	pkt 7 — brak modelu w ogóle
Wzory użytkowe, odmiany roślin	pkt 2, 3 — j.w.
Patenty: uprawniony, urząd udzielający, państwa ochrony, data ogłoszenia w WUP, uprzednie pierwszeństwo, streszczenie opisu, tłumaczenie patentu EP	pkt 1 lit. b, d, e, f, h, i, j
ISMN	pkt 5 lit. b
Czy monografia jest przekładem dzieła istotnego	pkt 5 lit. i
Zgłoszenie do oceny eksperckiej KEN i jej wynik	pkt 5 lit. l

Braki patentowe pokrywają się z tym, co niezależnie zgłosiła klientka w FD#449.

Recenzja adwersarialna — co znalazła

Kod przeszedł osobną recenzję przed wystawieniem PR. Znaleziska naprawione w 365fbd5c4, wszystkie zweryfikowane mutacyjnie (cofnięcie poprawki → odpowiadające testy padają):

• Streszczenia zjazdowe audytowane jak artykuły naukowe. Wydawnictwo_Ciagle obejmuje w BPP także PSZ/ZSZ, listy do redakcji, recenzje i komunikaty. Raport żądał od streszczenia konferencyjnego numeru DOI. Uderzyłoby w każdą instalację z bibliografią zjazdową.
• Monografia macierzysta rozdziału nie była sprawdzana nigdy. Komentarz w kodzie twierdził, że jej braki widać przy monografii — ale rodzic trafia do raportu tylko wtedy, gdy sam ma autora z uczelni, a rozdział w monografii zbiorowej pod obcą redakcją takiego rodzica nie ma. Cały pkt 6 lit. a wypadał z audytu.
• Wyciek nazwisk między uczelniami. Widok szczegółów nie zawężał autora do uczelni; slug jest przewidywalny (nazwisko-imie), więc pozwalało to enumerować kadrę obcej instytucji. Teraz 404.
• Trzy luki wobec rozporządzenia: brak reguły na sam tryb dostępu OA, dziura między regułami APC, całkiem pominięta lit. g o konferencjach.
• Luka w testach: wzorzec zerował wszystkie człony koniunkcji naraz, więc dowolny fallback dało się usunąć z kodu przy zielonej suicie.

Recenzja potwierdziła też, że nie ma N+1 (45 zapytań przy 2 i przy 20 autorach), nie ma mnożenia wierszy przez JOIN-y i że wszystkie paragrafy przy regułach wskazują właściwą jednostkę redakcyjną rozporządzenia.

Testy

341 testów w src/kompletnosc_polon/. Każda reguła sprawdzana parą rekordów (kompletny / z brakiem), plus testy „fallback ratuje" na każdy człon koniunkcji, testy ziarna, zakresu, warunkowości OA, uprawnień i multi-tenanta.

Przy okazji naprawiony flake w fixture'ach: Dyscyplina_Naukowa.kod jest unikalny, a generator model_bakery losuje z wąskiego zakresu — test budujący 28 powiązań trafiał w kolizję urodzinową (reprodukowalne przez --count=40).

Dług techniczny — do osobnego zgłoszenia, NIE naprawiany tutaj

W repo są trzy niezgodne definicje okna ewaluacyjnego:

Miejsce	Wartość
ewaluacja_common/const.py	ROK_MIN = 2022, ROK_MAX = 2026
ewaluacja_metryki/models.py:114-120	pola rok_min/rok_max, domyślnie 2022 / 2025
ewaluacja_metryki/tasks.py, utils.py	rok_min=2022, rok_max=2025 w ośmiu sygnaturach funkcji

ROK_MAX mówi 2026, a metryki liczą do 2025. Rozjazd siedzi w domyślnych argumentach, nie we wspólnej stałej, więc jest niewidoczny. Wraz z otwarciem okna 2026+ każde z tych miejsc jest błędne.

Ten PR dokłada OKNO_EWALUACJI = (2026, 2029) w ewaluacja_common jako źródło prawdy wyłącznie dla nowej aplikacji i celowo nie rusza reszty — zmiana domyślnych lat przestawiłaby wyniki liczenia metryk i slotów, czyli zachowanie niezwiązane z tym zgłoszeniem.

Uwagi wdrożeniowe

• Brak migracji.
• Raport na starcie będzie prawie pusty — okno 2026 dopiero się otwiera. Widok jawnie podaje zakres lat i liczbę sprawdzonych powiązań, żeby pustka nie wyglądała jak „wszystko w porządku".
• Raport zależy od ustawionych w słowniku charakterów formalnych pól rodzaj_pbn i charakter_sloty. Rekordy, dla których ich brak, trafiają do osobnej sekcji „nierozpoznany typ osiągnięcia" z linkiem do słownika — nie znikają po cichu.

Projekt: docs/superpowers/specs/2026-07-25-raport-kompletnosci-polon-2026-design.md

Refs FD#437

🤖 Generated with Claude Code

https://claude.ai/code/session_01McWgJYK4c4GSMdsm6P4oXc

[gitguardian]

⚠️ GitGuardian has uncovered 1 secret following the scan of your pull request.

Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

🔎 Detected hardcoded secret in your pull request

GitGuardian id	GitGuardian status	Secret	Commit	Filename
35167251	Triggered	Generic Password	71539ec	src/kompletnosc_polon/tests/test_views.py	View secret

🛠 Guidelines to remediate hardcoded secrets

1. Understand the implications of revoking this secret by investigating where it is used in your code.
2. Replace and store your secret safely. Learn here the best practices.
3. Revoke and rotate this secret.
4. If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.

To avoid such incidents in the future consider

• following these best practices for managing and storing secrets including API keys and other credentials
• install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.

---

^{🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.}