Change log
Co się zmieniło, co jest w budowie, co planuje.
Pierwsza ekspansja poza Polskę. Architektura multi-rejestr była zaprojektowana od pierwszego dnia właśnie z myślą o tym kroku – nowy kraj to nowe źródło danych, ten sam spójny format wyjściowy.
Domena rozszerzona o osoby prawne (legal_person) i powiązany z nimi rejestr KRS wraz z domenami temporalnymi. Katalog wykrywanych zmian urósł z 29 do 49 typów w 8 kategoriach. Doszła cała warstwa finansowa (kapitał, zaległości, egzekucja, zabezpieczenie majątku), własnościowa (udziałowcy, przekształcenia, połączenia i podziały) oraz pełny cykl statusowy – od wszczęcia likwidacji i restrukturyzacji po rozwiązanie i wznowienie działalności. Prace od końca czerwca przez lipiec, wdrożenie na produkcję na początku sierpnia.
Konfiguracja alertów oparta na severity (info → critical), z filtrowaniem po event_class (initialization, change, growth, risk, anomaly, recovery) i kategorii (status, identity, location, activities…). Ustawienia globalne lub per firma z możliwością wymuszenia przez force. Uwaga: zbyt wąski filtr event_class lub category przy niskim progu severity może skutecznie wyciszyć wszystkie powiadomienia.
Każdy z 29 typów zdarzeń otrzymał przypisaną wartość severity, klasę (event_class) i kategorię. Sześć poziomów ważności: info, notice, warning, high, error, critical. Sześć klas semantycznych: initialization, change, growth, risk, anomaly, recovery. Osiem kategorii danych: status, identity, location, ownership, activities, contacts, web_presence, finance.
Spłata zaległości: pole severity dodane do struktury domenowej, zaktualizowane odpowiedzi wszystkich endpointów zwracających zdarzenia (/companies/events, /watchlist/events) oraz przeparsowanie pipeline z przypisaniem severity do historycznych rekordów.
System gotowy. API dostępne publicznie, dokumentacja, pricing, rejestracja.
Błąd w logice wartości zapasowej pola event_date – zamiast daty wykrycia zdarzenia, 100% zdarzeń zwracało activity_start. Naprawione, pipeline przeparsowany ponownie.
Pełny reset i test produkcyjny – 48 godzin parsowania, 2.1M podmiotów, 67M rekordów, 28 GiB danych.
Wszystkie endpointy przetestowane: wyszukiwarka, monitoring, zdarzenia, portfel. Znalezienie błędu.
Uwierzytelnianie, tokeny, portfel, firmy, lista obserwowanych, zdarzenia – każdy endpoint z parametrami, przykładami curl i prawdziwymi odpowiedziami. Cztery przewodniki integracyjne w PL i EN. Przewodniki →
Wyszukiwarka firm i Monitoring firm – pierwsze dwa produkty platformy na produkcji. Wyszukiwarka z filtrowaniem po branży, lokalizacji, kontakcie. Monitoring z asynchronicznym kolejkowaniem do 100 podmiotów na zapytanie i 29 typami wykrywanych zdarzeń. Szczegóły w API Reference →
Integracja Paddle, system kredytowy, middleware autoryzacji. Master Token i tokeny API z granularnym zakresem dostępu.
Pipeline przeniesiony do schedulera. Codziennie w nocy – pobieranie, parsowanie, wykrywanie zmian, generowanie zdarzeń. System zaczął działać bez udziału człowieka.
System wykrywania zmian generujący zdarzenia. 29 typów zdarzeń: zmiany nazwy, adresu, działalności, statusu, upadłości i inne. Każde zdarzenie ma typ, starą wartość, nową wartość i datę wykrycia.
Silos po silosie, typ raportu po typie – czyste przepięcie do domeny. Testy i stabilizacja, codzienne uruchomienia manualne z terminala.
3-etapowy pipeline: pobranie raportów historycznych → pobranie XML, parsowanie do JSON, tworzenie paczek → parsowanie paczek do domeny. Kod był spaghetti – logika w złych miejscach. Przepisanie konieczne. V2 w styczniu.
Warstwa domenowa gotowa – DTO, Writer, Cleaner, Factory, Resolver. Pełne słowniki, testy jednostkowe i integracyjne.
Laravel 12, PHP 8.3, MySQL. Architektura domain-first od pierwszego dnia – DTO, Writer, Cleaner, Factory, Resolver, Event. Decyzja o architekturze multi-rejestr od razu, żeby Francja i kolejne kraje były rozszerzeniem, a nie przebudową. API-first, bez frontu.
Pierwszy kontakt z danymi rejestrowymi w 2017 – zainteresowanie tym co kryje się za publicznie dostępnymi rejestrami firm. Przez osiem lat zbieranie danych z GUS i CEIDG jako projekt poboczny. W 2025 decyzja: zbudować z tego produkt. Rok później – działające API z trzema narzędziami na produkcji.