Od zanonimizowanego pliku Excel do analityki HSE dla zarządu. Etap 2: tworzymy autonomiczny interaktywny pulpit HSE z pomocą vibe codingu

SI pomaga zbudować powłokę programu na zanonimizowanym szablonie Excela, a prawdziwa baza robocza wczytywana jest do gotowego pliku HTML już lokalnie, na komputerze użytkownika.

Wprowadzenie

W pierwszej publikacji pokazałem, jak rozwiązaliśmy kwestię bezpiecznego przygotowania danych: zbudowaliśmy lokalne narzędzie do maskowania i nauczyliśmy się uzyskiwać zanonimizowany szablon Excela, który zachowuje strukturę bazy roboczej, ale nie przekazuje prawdziwych danych osobowych do zewnętrznego środowiska SI.

Następne pytanie pojawia się niemal od razu: co dalej zrobić z tym szablonem?

Naszym zadaniem nie było po prostu zbudowanie kilku wykresów. Potrzebne było działające narzędzie analityczne, które można wykorzystać przy przygotowaniu komunikacji kaskadowej i komitetów ds. bezpieczeństwa: zmieniać wybór, schodzić od wskaźnika ogólnego do jednostki, obszaru i konkretnego rekordu, widzieć wąskie gardła i szybko przygotowywać materiał do rozmowy z kierownictwem.

Pozostawał przy tym główny warunek pierwszego etapu: na etapie zewnętrznego opracowania prawdziwa baza robocza zakładu nie trafia do SI.

Dlaczego w ogóle potrzebny był własny pulpit

Nasze dane źródłowe od dawna powstają w postaci cyfrowej. Behawioralne dialogi bezpieczeństwa (BSD) oraz kontrolę ryzyk krytycznych (CRC) kierownicy i specjaliści prowadzą przez firmową aplikację mobilną CoLab. Problemem nie był więc brak danych, lecz kolejny krok — jak szybko zamienić dużą liczbę rekordów w zrozumiałą analitykę zarządczą.

System korporacyjny pozwala przeprowadzić obserwację, wypełnić pola i wygenerować eksport. Głębsze opracowanie analityczne wymaga jednak osobnych prac IT. Przy ograniczonej liczbie specjalistów, terminach i finansowaniu takie zgłoszenia mogą czekać dość długo.

Pierwsze pulpity online oparte na Superset pokrywają podstawowe zadania ilościowe. Do praktycznej pracy to za mało. Gdy kierownik widzi, że przeprowadzono 500 kontroli albo wykryto 70 odchyleń, następne pytanie jest zawsze to samo: gdzie dokładnie to się wydarzyło, dlaczego i jakie konkretne rekordy za tym stoją.

Dlatego autonomiczny pulpit HTML traktujemy nie jako zamiennik korporacyjnych systemów IT, lecz jako szybkie narzędzie przejściowe. Pozwala w krótkim czasie sprawdzić analitykę w praktyce, zrozumieć, które wskaźniki są naprawdę potrzebne i gdzie konieczne jest zejście do danych źródłowych — a dopiero potem sformułować dokładniejsze wymagania dla wdrożenia przemysłowego.

Krok 1. Najpierw zrozumieć dane, a nie pisać program

Jednym z najczęstszych błędów w pracy z SI jest prośba od razu: „Zrób mi pulpit”. Ładny obrazek można dostać szybko, ale wcale nie jest pewne, że da się z niego później korzystać.

Dlatego nasze pierwsze zapytanie do SI było inne. Wgrywaliśmy zanonimizowany szablon Excela i prosiliśmy, by na razie niczego nie programować, tylko przeanalizować strukturę pliku: jakie zawiera arkusze, kolumny i typy danych, które pola są ze sobą powiązane, czego można użyć w filtrach, jakie wskaźniki da się policzyć i gdzie struktura źródłowa może mieć błędy.

W ten sposób SI występuje najpierw jako analityk danych, a nie programista.

Dla behawioralnych dialogów bezpieczeństwa istotne są na przykład data, zakład, wydział, obszar, obserwator, pracownik, rodzaj zachowania, proces, opis i wynik. Zamiast prawdziwego nazwiska SI może widzieć „Pracownik_00001”. Do zbudowania logiki pulpitu prawdziwe nazwisko nie jest jej potrzebne.

Prompt 1 — analiza struktury zanonimizowanej bazy: patrz załącznik na końcu artykułu.

Behawioralne dialogi bezpieczeństwa: od ogólnej liczby do konkretnego rekordu

Kolejnym etapem jest określenie nie zestawu ładnych wizualizacji, lecz pytań zarządczych, na które pulpit ma odpowiadać.

W dialogach behawioralnych ważne jest dla nas, aby widzieć dynamikę, strukturę zaobserwowanych zachowań, jednostki, procesy, powtarzalność odchyleń, pracę obserwatorów oraz możliwość przejścia od ogólnej liczby do konkretnego rekordu.

Dlatego logika budowana jest z góry na dół: zakład → wydział → obszar → rodzaj zachowania → proces → konkretny rekord. Kliknięcie słupka lub wycinka wykresu zmienia wybór i pozwala zobaczyć dokładnie te rekordy, które utworzyły wskaźnik.

Osobno dochodzą wyszukiwanie po pracowniku lub zanonimizowanym identyfikatorze, historia wykrytych odchyleń, ranking jednostek i osób prowadzących BSD, a także eksport bieżącego wyboru do Excela.

Stosuję tu prostą zasadę: jeśli po obejrzeniu wykresu nie wiadomo, jaką decyzję zarządczą on wspiera, to najprawdopodobniej ten wykres nie jest w pulpicie potrzebny.

Prompt 2 i Prompt 5 — struktura pulpitu HSE i interaktywne szczegóły: patrz załącznik na końcu artykułu.

Uzupełnienie o ewidencję czasu pracy: jak zobaczyć ustaloną zalecaną częstotliwość BSD

Następnie zrobiliśmy jeszcze jeden krok. Aby oszczędzić czas i nie tworzyć osobnego narzędzia, ten sam pulpit uzupełniliśmy o ewidencję obecności.

Do prac wykorzystano najpierw zanonimizowany szablon ewidencji, a później — już lokalnie — rzeczywistą ewidencję. Pozwoliło to zobaczyć nie tylko liczbę przeprowadzonych BSD, ale i realizację ustalonej zalecanej częstotliwości.

W istocie porównywaliśmy liczbę faktycznie przepracowanych zmian z liczbą faktycznie przeprowadzonych dialogów bezpieczeństwa. Dzięki temu stało się widoczne, gdzie wymagana częstotliwość jest zachowana, a gdzie powstaje zaległość.

Takie podejście jest szczególnie przydatne dla kierowników wydziałów i obszarów: pulpit pokazuje nie ogólny nakład pracy, lecz realne wykonanie wymagania, ze schodzeniem do jednostki, zawodu i konkretnego pracownika.

To rozszerzenie nie wymagało nowej zasady. Po prostu rozwinęliśmy istniejącą logikę i podłączyliśmy kolejny zbiór danych.

Prompt 6 — analiza BSD z uwzględnieniem faktycznie przepracowanych zmian: patrz załącznik na końcu artykułu.

CRC: to samo podejście, ale dla kontroli ryzyk krytycznych

Ta sama logika dotyczy CRC. Z eksportu źródłowego widać, ile kontroli CRC przeprowadzono i ile z nich zawierało odchylenia. Ale sama liczba nie odpowiada na główne pytanie: na ile wymaganie jest realnie spełniane na każdej zmianie.

W tym celu do pulpitu wczytywane są lokalnie dane CRC i rzeczywista ewidencja czasu pracy za ten sam okres. Po porównaniu widać, kto faktycznie był na zmianie, ile kontroli CRC powinien wykonać i ile wykonał naprawdę.

Na wyjściu otrzymujemy nie tylko liczbę, ale i procent wykonania, niedobór, listę osób, które nie wykonały zadania, a przy rozszerzonej bazie także powiązanie z obszarem, wydziałem, procesem i przyczynami odchyleń.

Wszystkie wykresy pozostają klikalne: od wskaźnika ogólnego można zejść głębiej — do jednostki, następnie do obszaru, dalej do zawodu i wreszcie do karty konkretnego pracownika lub konkretnego rekordu.

Zrzutów ekranu dotyczących CRC w tym artykule nie zamieszczam, aby nie przeciążać materiału. Technicznie stosowana jest ta sama zasada co przy BSD.

Prompt 7 — CRC i rzeczywista ewidencja czasu pracy: obliczanie wykonania i schodzenie do pracownika: patrz załącznik na końcu artykułu.

Krok 2. Pierwszy prototyp i kolejne poprawki

Gdy struktura danych i logika analityki są jasne, można przejść bezpośrednio do vibe codingu.

Zadanie formułuje się wtedy dość konkretnie: stworzyć jeden autonomiczny plik HTML, który otwiera się w zwykłej przeglądarce, zawiera KPI, filtry, interaktywne wykresy i tabelę rekordów źródłowych oraz działa bez instalowania dodatkowego oprogramowania.

Na tym etapie wewnątrz programu nadal wykorzystywane są wyłącznie dane zanonimizowane.

Pierwsza wersja prawie nigdy nie jest ostateczna. Wybierasz zakład — a lista wydziałów pozostaje ogólna. Klikasz wykres — a nie ma zejścia do rekordu. Dodajesz nową funkcję — i jedna z wizualizacji przestaje działać poprawnie. To normalna część prac.

Zamiast przepisywać całą aplikację, zadanie stawia się punktowo: „Zrób filtry zależne”, „Dodaj szczegóły po kliknięciu”, „Popraw tylko wykres nr 6, reszty logiki nie zmieniaj”.

Właśnie tutaj vibe coding jest szczególnie przydatny dla specjalisty, który sam nie jest programistą. Trzeba dokładnie wyjaśnić nie to, jak napisać funkcję, lecz jak program ma się zachowywać wobec użytkownika.

Prompt 3, Prompt 5 i Prompt 8 — utworzenie pierwszego HTML, szczegóły i usuwanie usterek: patrz załącznik na końcu artykułu.

Krok 3. Usuwamy szablon i wczytujemy prawdziwe dane lokalnie

Gdy interfejs i logika zostały sprawdzone na zanonimizowanym szablonie, z wersji końcowej usuwa się dane demonstracyjne. HTML pozostaje powłoką programu.

Dodawany jest do niego przycisk wczytywania Excela. Użytkownik otwiera gotowy plik HTML na komputerze firmowym, wybiera aktualną bazę roboczą, a przeglądarka odczytuje plik i przelicza wskaźniki już w ramach sesji lokalnej.

Schemat końcowy jest więc prosty: gotowy HTML i roboczy plik Excel znajdują się na tym samym komputerze; dane robocze wczytywane są do programu lokalnie i nie trafiają już do zewnętrznego środowiska SI.

Na publikowanym zrzucie ekranu prawdziwe nazwiska są zamazane. To ważne: artykuł ma pokazywać zasadę działania, a nie ujawniać dane osobowe.

Prompt 4 — lokalne wczytywanie roboczej bazy Excel: patrz załącznik na końcu artykułu.

Wczytywanie, dodawanie, reset i kopia offline

Osobnej uwagi wymagały funkcje użytkownika. W praktyce ważne jest nie tylko otwarcie pulpitu, ale i szybkie zarządzanie jego stanem.

Dlatego dodano oddzielne działania: wczytanie nowej tabeli, usunięcie danych do zera, zapis kopii offline i zresetowanie filtrów bez usuwania bazy. To różne scenariusze i muszą być dla użytkownika zrozumiałe na pierwszy rzut oka.

Nagrałem też krótki film demonstracyjny, w którym widać, jak pulpit działa na zanonimizowanym szablonie, jak wykonuje się pełny reset i jak następnie wczytuje się prawdziwe dane. Taki załącznik wideo rozwiewa wątpliwości szybciej niż jakikolwiek opis tekstowy.

Załącznik wideo 1. Nagranie ekranu: od szablonu do bazy roboczej — film znajduje się na końcu artykułu.

Od analityki do rozmowy zarządczej

Główna wartość pulpitu ujawnia się nie na ekranie, lecz na naradzie.

Uzyskane przekroje wykorzystywane są przy przygotowaniu komunikacji kaskadowej oraz komitetów ds. bezpieczeństwa i higieny pracy: od poziomu jednostek po centralny komitet zakładu, który odbywa się co miesiąc.

Na poziomie obszaru widać konkretne rekordy i pracowników. Na poziomie wydziału — powtarzające się problemy. Wyżej — porównanie jednostek i obszary systemowe wymagające uwagi kierownictwa.

Dlatego na komitet trafia już nie samo zdanie „wykonanie — 82 %”, lecz znacznie konkretniejszy obraz: które obszary tworzą niedobór, na których zmianach wymaganie nie jest spełniane, jakie rodzaje odchyleń się powtarzają i które rekordy należy omówić z kierownikiem.

Pulpit pokazuje, gdzie szukać. Przyczynę i decyzję zarządczą nadal określają ludzie.

Narzędzie tymczasowe czy przyszły system przemysłowy

Autonomiczny pulpit HTML nie jest dla nas celem końcowym i nie konkuruje z korporacyjną architekturą IT.

Jego zadaniem jest szybkie przejście drogi od pomysłu produkcyjnego do działającego prototypu analitycznego. Gdy trwa opracowanie rozwiązania przemysłowego, jednostki mogą już korzystać z narzędzia do analiz, a specjaliści dostają praktyczną informację zwrotną o tym, które wskaźniki są naprawdę potrzebne.

Jeśli prototyp potwierdził przydatność, jego logikę znacznie łatwiej przekazać programistom do późniejszej realizacji w JavaScripcie, w Superset albo w innym środowisku korporacyjnym z automatyczną integracją danych.

Innymi słowy, vibe coding nie zastępuje IT. Zdejmuje część niepewności jeszcze przed rozpoczęciem dużego projektu: z góry wiadomo, jakie filtry są potrzebne, dokąd ma sięgać schodzenie w szczegóły, które dane trzeba powiązać i jaki rezultat zarządczy ma otrzymać użytkownik.

Co wyszło na końcu

W efekcie zanonimizowany szablon Excela staje się technicznym mostem między prawdziwą bazą roboczą a SI. SI widzi strukturę danych, pomaga opracować logikę i interfejs, pisze i poprawia kod. Prawdziwa baza pojawia się w narzędziu dopiero wtedy, gdy gotowy HTML jest już na komputerze użytkownika.

Dla specjalisty ds. bezpieczeństwa wyraźnie skraca to drogę od pomysłu do działającego prototypu.

Główna przewaga nie polega na tym, że SI potrafi rysować wykresy. Najważniejsza jest możliwość znacznie szybszego przekształcenia pytania produkcyjnego w narzędzie analityczne, zobaczenia wąskiego gardła i skierowania uwagi kierownika tam, gdzie naprawdę potrzebne jest działanie.

W następnej publikacji chcę przejść od analizy danych do innego kierunku: pokazać, jak SI ze zwykłego pomocnika stopniowo stała się „drugim ekspertem”, który ocenia jakość pięciominutówek bezpieczeństwa i dialogów behawioralnych według kilku niezależnych kryteriów.

Gotowe prompty do stworzenia autonomicznego pulpitu HSE dla BSD i CRC

Zasada praktyczna: do zewnętrznego środowiska SI trafia wyłącznie sprawdzony zanonimizowany szablon. Prawdziwe robocze pliki Excel, ewidencje czasu pracy i dane osobowe podłączane są później, lokalnie, w gotowej powłoce HTML.

Jak prompty wiążą się z artykułem

Prompt 1. Analiza struktury zanonimizowanego pliku Excel

Wgrywam zanonimizowany szablon Excela roboczej bazy HSE.

Na razie niczego nie programuj.

Przeanalizuj:
1. arkusze pliku;
2. nagłówki kolumn;
3. typy danych;
4. pola obowiązkowe i opcjonalne;
5. powiązania hierarchiczne między zakładem, wydziałem, obszarem i innymi poziomami;
6. pola nadające się do filtrowania;
7. pola nadające się do KPI, rankingów i wizualizacji;
8. pola, których można użyć jako stabilnego zanonimizowanego identyfikatora pracownika;
9. potencjalne problemy bazy źródłowej: puste wartości, różne zapisy tej samej jednostki, niejednolite formaty dat, duplikaty, mieszanie tekstu i liczb, niejednoznaczne nazwy kolumn.

Dla bazy BSD ustal osobno, gdzie znajdują się:
- data i godzina;
- zakład;
- wydział;
- obszar / jednostka wewnętrzna;
- osoba prowadząca BSD;
- stanowisko tej osoby;
- pracownik / zanonimizowany identyfikator;
- rodzaj zachowania bezpiecznego lub niebezpiecznego;
- proces / rodzaj prac;
- opis obserwacji;
- wynik lub reakcja.

Po analizie:
- opisz krótko strukturę danych;
- zaproponuj, które powiązania między polami należy zachować;
- wymień wątpliwe miejsca, które trzeba potwierdzić z użytkownikiem;
- dopiero po potwierdzeniu zaproponuj architekturę przyszłego pulpitu.

Nie próbuj odtwarzać zanonimizowanych wartości i nie wyciągaj wniosków o tożsamości konkretnego pracownika.

Prompt 2. Architektura pulpitu behawioralnych dialogów bezpieczeństwa

Na podstawie potwierdzonej struktury zanonimizowanego pliku Excel zaproponuj architekturę autonomicznego pulpitu HSE dla behawioralnych dialogów bezpieczeństwa.

Główna zasada: każda wizualizacja ma odpowiadać na konkretne pytanie zarządcze. Nie dodawaj wykresów tylko dla ozdoby.

Przewidz:
1. kluczowe KPI dotyczące liczby BSD i obserwacji;
2. filtry według okresu;
3. zależną hierarchię zakład → wydział → obszar / jednostka wewnętrzna;
4. filtr według osoby prowadzącej BSD;
5. filtr według stanowiska tej osoby;
6. dynamikę BSD w ujęciu miesięcznym i/lub dziennym;
7. porównanie zakładów;
8. TOP jednostek / obszarów;
9. TOP osób prowadzących BSD;
10. strukturę zachowań bezpiecznych i niebezpiecznych;
11. kategorie obserwacji niebezpiecznych;
12. analizę procesów / rodzajów prac;
13. ranking pracowników, u których zachowanie niebezpieczne odnotowano wielokrotnie;
14. wyszukiwanie po pracowniku lub zanonimizowanym identyfikatorze;
15. historię BSD wybranego pracownika;
16. możliwość sprawdzenia, czy ten sam rodzaj zachowania niebezpiecznego powtarzał się u jednego pracownika w różnych datach, u różnych kierowników lub na różnych obszarach;
17. eksport bieżącego wyboru do Excela.

Dla każdej wizualizacji wskaż osobno:
- na jakie pytanie kierownika odpowiada;
- jakich pól używa;
- dokąd ma prowadzić kliknięcie elementu wykresu.

Najpierw opisz architekturę słowami. Na razie nie twórz kodu.

Prompt 3. Utworzenie pierwszego autonomicznego HTML

Na podstawie uzgodnionej architektury utwórz pierwszą autonomiczną wersję interaktywnego pulpitu HSE.

Wymagania:
1. Wynikiem jest jeden plik HTML.
2. Plik otwiera się w zwykłej przeglądarce bez instalowania dodatkowego oprogramowania.
3. Na etapie prac używaj wyłącznie zanonimizowanych danych demonstracyjnych.
4. Dodaj uzgodnione KPI, filtry, rankingi, wyszukiwanie, interaktywne wykresy i tabelę rekordów źródłowych.
5. Nie używaj backendu.
6. Nie używaj zewnętrznych API.
7. Nie ładuj bibliotek z CDN.
8. Wszystkie potrzebne biblioteki mają znajdować się wewnątrz pliku HTML.
9. Pulpit ma otwierać się i w pełni działać przy wyłączonym internecie.
10. Nie dodawaj telemetrii, analityki odwiedzin ani zapytań sieciowych.
11. Zorganizuj kod tak, aby później dało się usunąć zbiór demonstracyjny i podłączyć prawdziwy plik Excel lokalnie.
12. Nie zmieniaj bez potrzeby istniejących zanonimizowanych identyfikatorów pracowników.

Po utworzeniu:
- wymień zrealizowane funkcje;
- wymień ograniczenia pierwszej wersji;
- wskaż, które funkcje trzeba sprawdzić ręcznie przed dalszymi pracami.

Prompt 4. Lokalne wczytywanie bazy roboczej, reset i kopia offline

Rozbuduj istniejący autonomiczny pulpit HSE.

Cel: po zakończeniu prac dane demonstracyjne mają zostać usunięte z pliku HTML, a prawdziwa baza robocza ma być podłączana wyłącznie lokalnie, na komputerze użytkownika.

Dodaj następujące funkcje.

1. „Wczytaj nową tabelę”
- użytkownik wybiera plik Excel na swoim komputerze;
- plik odczytywany jest przez przeglądarkę wyłącznie lokalnie;
- dane trafiają do pamięci bieżącej sesji;
- KPI, filtry, wykresy, rankingi i tabele są w pełni przebudowywane;
- struktura ustalana jest na podstawie nagłówków kolumn, a nie stałych numerów kolumn;
- w razie braku pola obowiązkowego wyświetlany jest zrozumiały komunikat o błędzie.

2. „Zastosuj filtry”
- przelicz wszystkie wizualizacje dla bieżącego wyboru.

3. „Resetuj”
- wyczyść wyłącznie wybrane filtry;
- przywróć widok całej wczytanej bazy;
- nie usuwaj samych danych.

4. „Usuń wszystkie dane do zera”
- całkowicie usuń wczytany zbiór roboczy z bieżącego stanu aplikacji;
- wyczyść KPI, wykresy, rankingi, tabele, nazwiska / identyfikatory i listy filtrów;
- przywróć HTML do stanu pustej powłoki programu.

5. „Eksportuj wybrane dane do Excela”
- eksportuj wyłącznie bieżący przefiltrowany wybór.

6. „Zapisz kopię offline”
- zapisuj dopiero po wyraźnym działaniu użytkownika;
- jeśli do kopii wbudowywana jest bieżąca baza robocza, pokaż ostrzeżenie, że zapisany plik HTML zawiera dane robocze i musi być przechowywany jako plik poufny;
- podczas zapisu żadne informacje nie mogą być wysyłane siecią.

Jeśli później pojawi się funkcja doczytywania nowych danych:
- najpierw sprawdź strukturę;
- nie twórz duplikatów automatycznie;
- pokaż użytkownikowi, ile rekordów zostanie dodanych, a ile odrzuconych.

Zbiór demonstracyjny usuń z wersji końcowej całkowicie.

Prompt 5. Filtry zależne, klikalność i schodzenie do rekordu

Rozbuduj istniejący pulpit HTML, nie przepisując go w całości.

Potrzebne jest:
1. Uczynienie filtrów zależnymi:
   zakład → wydział → obszar / jednostka wewnętrzna.
2. Po wybraniu zakładu pozostawiaj tylko należące do niego wydziały.
3. Po wybraniu wydziału pozostawiaj tylko jego obszary.
4. Uwzględniaj wybrany okres, osobę prowadzącą BSD i jej stanowisko.
5. Uczyń główne wykresy i rankingi klikalnymi.
6. Po kliknięciu słupka, wycinka, punktu, wiersza rankingu lub pracownika zastosuj odpowiedni wybór do całego pulpitu.
7. Pokazuj rekordy źródłowe, które utworzyły wybrany wskaźnik.
8. Dodaj możliwość powrotu o poziom wyżej lub zresetowania bieżącego szczegółu.
9. Dodaj wyszukiwanie po pracowniku / zanonimizowanym identyfikatorze.
10. Dla wybranego pracownika pokazuj historię BSD w wybranym okresie: daty, jednostki, osoby prowadzące BSD, rodzaje zachowań, procesy i rekordy źródłowe.
11. Osobno pokazuj pracowników, u których zachowanie niebezpieczne odnotowano wielokrotnie.
12. Umożliw zobaczenie powtarzalności tego samego rodzaju zachowania niebezpiecznego, nawet jeśli odnotowali je różni kierownicy lub specjaliści i na różnych obszarach.
13. Eksportuj bieżący wybór do Excela.
14. Nie zmieniaj bez potrzeby już działających funkcji.

Po rozbudowie przeprowadź sprawdzenie regresyjne:
- wszystkie filtry;
- kliknięcia w wykresy;
- wyszukiwanie;
- szczegóły;
- eksport;
- powrót do pełnego wyboru.

Prompt 6. BSD + rzeczywista ewidencja: realizacja ustalonej zalecanej częstotliwości

Dodaj do istniejącego pulpitu tryb analizy BSD z uwzględnieniem faktycznie przepracowanych zmian.

Źródła:
- eksport BSD z Collab;
- ewidencja czasu pracy za ten sam okres.

Na etapie prac używaj wyłącznie zanonimizowanego szablonu ewidencji. Rzeczywista ewidencja ma być podłączana później i tylko lokalnie.

WAŻNE:
nie wymyślaj samodzielnie normy prowadzenia BSD. Przed obliczeniem użytkownik musi podać ustaloną zalecaną częstotliwość, na przykład:
- X BSD na N faktycznie przepracowanych zmian;
- X BSD na okres kalendarzowy / sprawozdawczy;
- inna zasada zakładu.

Logika:
1. Ustal faktycznie przepracowane zmiany na podstawie ewidencji.
2. Urlopu, zwolnienia lekarskiego i innych nieobecności nie licz jako faktycznie przepracowanych zmian.
3. Powiąż zbiór BSD i ewidencję po stabilnym identyfikatorze pracownika, zakładzie, wydziale, obszarze, zawodzie i okresie — zależnie od dostępnych pól.
4. Nie mieszaj identycznych nazwisk / identyfikatorów i zawodów z różnych jednostek.
5. Na podstawie częstotliwości podanej przez użytkownika oblicz oczekiwaną liczbę BSD dla faktycznie przepracowanego czasu.
6. Pokaż:
   - faktycznie przepracowane zmiany;
   - ustaloną zalecaną częstotliwość;
   - faktyczną liczbę BSD;
   - odchylenie od zalecanej częstotliwości;
   - procent wykonania;
   - jednostki i pracowników z zaległością.
7. Dodaj schodzenie w szczegóły:
   zakład → wydział → obszar → zawód → konkretny pracownik → jego rekordy BSD.
8. Umożliw eksport listy pracowników / jednostek z odchyleniem.

Jeśli struktura ewidencji albo zasada częstotliwości są niejednoznaczne, pokaż najpierw wątpliwe przypadki i poproś o potwierdzenie. Nie wykonuj obliczeń przed potwierdzeniem.

Prompt 7. CRC + rzeczywista ewidencja: regularność prowadzenia i odchylenia

Dodaj do pulpitu osobny tryb analizy kontroli ryzyk krytycznych (CRC).

Źródła:
- eksport CRC z Collab;
- rzeczywista ewidencja czasu pracy za ten sam okres.

Na etapie prac używaj zanonimizowanych szablonów. Prawdziwe zbiory mają być podłączane wyłącznie lokalnie.

Logika:
1. Ustal faktycznie przepracowane zmiany każdego pracownika.
2. Urlopu, zwolnienia lekarskiego i innych nieobecności nie licz jako zmian roboczych.
3. Nie wymyślaj samodzielnie normy / wymaganej regularności CRC. Otrzymaj ją od użytkownika jako parametr.
4. Jeśli dla konkretnego procesu potwierdzono wymaganie „1 CRC na faktycznie przepracowaną zmianę”, użyj go dopiero po potwierdzeniu przez użytkownika.
5. Powiąż CRC z faktycznie przepracowanymi zmianami po stabilnym identyfikatorze, zakładzie, wydziale, obszarze, zawodzie, dacie i/lub zmianie.
6. Nie mieszaj identycznych zawodów i identyfikatorów z różnych jednostek.
7. Dla każdego pracownika pokaż:
   - faktycznie przepracowane zmiany;
   - liczbę CRC;
   - zmiany / okresy, w których brakuje CRC względem podanej zasady;
   - odchylenie;
   - procent wykonania.
8. Dodaj schodzenie w szczegóły:
   zakład → wydział → obszar → zawód → pracownik → konkretna zmiana / konkretny rekord CRC.
9. Umożliw eksport listy pracowników lub zmian z odchyleniem.
10. Jeśli w eksporcie CRC są wykryte zagrożenia, ryzyka krytyczne, opisy odchyleń lub przyczyny, pokaż dodatkowo:
   - powtarzalność według obszarów;
   - powtarzalność według procesów;
   - powtarzalność według pracowników;
   - rekordy źródłowe po kliknięciu.

Jeśli struktura danych jest niejednoznaczna, pokaż najpierw zasady dopasowania i wątpliwe przypadki. Nie wykonuj końcowych obliczeń przed potwierdzeniem przez użytkownika.

Prompt 8. Diagnostyka usterek i techniczna autokontrola

Przeprowadź sprawdzenie istniejącego autonomicznego pulpitu HTML.

Na początku nie przepisuj całej aplikacji.

Jeśli po ostatniej zmianie pojawił się błąd:
1. Znajdź konkretną przyczynę.
2. Popraw wyłącznie niezbędny fragment.
3. Nie usuwaj ani nie przepisuj bez powodu już działających funkcji.
4. Po poprawce przeprowadź sprawdzenie regresyjne.

Koniecznie sprawdź scenariusze:
- otwarcie pliku HTML bez internetu;
- wczytanie zanonimizowanego testowego pliku Excel;
- filtry zależne;
- kliknięcia i schodzenie w szczegóły;
- wyszukiwanie po pracowniku;
- eksport wybranego zakresu;
- reset filtrów;
- pełne usunięcie danych;
- ponowne wczytanie innej tabeli;
- zapis kopii offline.

Po sprawdzeniu funkcjonalnym przeprowadź audyt autonomiczności i możliwych kanałów przesyłania / przechowywania:
- fetch;
- XMLHttpRequest;
- WebSocket;
- EventSource;
- sendBeacon;
- zewnętrzne script src;
- CDN;
- zewnętrzne CSS i czcionki;
- API;
- iframe;
- Service Worker;
- localStorage;
- sessionStorage;
- IndexedDB;
- pliki cookie;
- telemetria i analityka.

Wersja końcowa ma:
- w pełni działać przy wyłączonym internecie;
- nie wysyłać siecią zawartości wczytywanych plików Excel;
- nie zapisywać bazy roboczej w sposób ukryty, bez wyraźnego działania użytkownika;
- przy pełnym resecie usuwać dane robocze z bieżącego stanu interfejsu.

Na końcu przedstaw krótki raport:
1. co zostało sprawdzone;
2. jakie usterki znaleziono;
3. co poprawiono;
4. jakie ograniczenia lub ryzyka pozostają.

Zalecana kolejność stosowania

1. Wykonać Prompt 1 i sprawdzić, czy SI poprawnie zrozumiała strukturę zanonimizowanego pliku Excel.
2. Po potwierdzeniu struktury wykonać Prompt 2.
3. Wykonać Prompt 3 i otrzymać pierwszą autonomiczną wersję HTML.
4. W miarę prac używać Promptu 5 do filtrów, kliknięć i schodzenia w szczegóły.
5. Gdy logika jest gotowa, wykonać Prompt 4: usunąć dane demonstracyjne i zorganizować lokalne wczytywanie bazy roboczej, resety, eksport oraz kopię offline.
6. Jeśli potrzebna jest analiza zalecanej częstotliwości BSD, podłączyć Prompt 6.
7. Do CRC i porównania z rzeczywistą ewidencją używać Promptu 7.
8. Po dużych zmianach oraz przed publikacją / przekazaniem użytkownikom wykonać Prompt 8.