Roadmapa

1. Základ platformy

   FastAPI služba s OpenAPI/Swagger, jednotnou problem+json chybovou obálkou, strukturovaným logováním s korelačními ID, konfigurací a zdravotními endpointy. Doménové kontrakty s odděleným veřejným a interním typem obálek; relační schéma s Alembic migracemi.

2. Dvanáct poskytovatelů dat pro due diligence

   Osm českých zdrojů (ARES, ISIR, obchodní rejstřík (data veřejného rejstříku přes ARES), centrální evidence exekucí, katastr nemovitostí ČÚZK, registr smluv, registr dotací, vnitrostátní sankční seznam ČR) plus čtyři mezinárodní (ověření DPH v EU VIES, globální LEI registr GLEIF, sankční seznam EU a sankční seznam OFAC SDN), vedle deterministického MockProvideru pro testy. Sdílená odolnost: rate limiting, circuit breaker, retry a cache per zdroj. Šetření firmy nyní samo dohledá vlastní katastrální parcelu podle sídla (adresa → kód adresního místa → parcela) a napojí ji přes ČÚZK.

3. Pipeline šetření a kontrola integrity

   Asynchronní běh šetření v ARQ workeru přes stavový automat (queued → collecting → validating → synthesizing → completed/failed/cancelled) a osm kontrol integrity důkazů se stropováním efektivní důvěryhodnosti. Nezávislost zdrojů se počítá přes auditované skupiny závislosti datových zdrojů, nikoli přes počet adaptérů — dva adaptéry čerpající ze stejného upstream datasetu se počítají jako jeden zdroj.

4. Kanonická korelace zjištění

   Sémanticky shodná pozorování od různých poskytovatelů se deterministicky slučují do kanonických zjištění: shoda subjektu na sankčních seznamech EU, OFAC a ČR je jedno kanonické zjištění doložené třemi nezávislými skupinami zdrojů, s úplnou stopou původních důkazů. Zprávy a API uvádějí zvlášť počet důkazů, počet poskytovatelů a počet nezávislých skupin zdrojů — tato čísla se nikdy nezaměňují.

5. Pravdivé pokrytí zdrojů u každého šetření

   Každý dotaz na zdroj končí typovaným výsledkem (nález / bez záznamu / přeskočeno s důvodem / selhání podle třídy) — prázdná odpověď už nikdy nemaskuje chybu. Šetření ukládá historický záznam pokrytí pro každý zdroj (GET /v1/investigations/{id}/coverage) a katalog zdrojů vždy ukazuje všechny nainstalované zdroje včetně stavu zapnutí a konfigurace.

6. Graf, vyhledávání a zprávy

   Kuzu grafová projekce s API pro sousedy, ohraničené dotazy vracející uzly i hrany, cesty, centralitu a detekci vlastnických cyklů — včetně vykreslení grafu přímo v aplikaci; Meilisearch fulltext izolovaný per tenant; zprávy v JSON, HTML a Markdown ukládané jako neměnné artefakty se SHA-256 otisky, ledgerem důkazů a ověřovacím manifestem (ověřitelné offline), generovatelné i z aplikace. Nálezy procházejí auditovatelnou lidskou kontrolou: nezměnitelná historie rozhodnutí s otiskem přesného důkazního podkladu, detekce zastaralých kontrol a konzervativní přenos rozhodnutí mezi opakovanými prověrkami.

7. API klíče a webová aplikace

   Správa hashovaných API klíčů s oprávněními a revokací; statický veřejný web a plně prowirovaná Alpine.js aplikace: seznam šetření, detail s důkazní knihou, vyhledávání, zprávy, vykreslený graf, katalog zdrojů i administrace.

8. Aplikační kokpit /app a laboratoř zdrojů

   Aplikace povýšena z prototypu na produktový kokpit nad všemi implementovanými schopnostmi platformy, se závaznou maticí pokrytí schopností: skutečný přehledový dashboard, formulář nového šetření věrný kontraktu (všech šest druhů subjektů, kontrolní součet IČO, výběr zdrojů podle použitelnosti, hloubka rekurze, idempotenční klíč), živý stav běhu přes autorizovaný SSE stream se zrušením, záložky pravdivosti (pokrytí zdrojů, kanonická zjištění s oddělenými počty, rizikové skóre s poctivou absencí), provenience důkazů včetně metadat shody a stahování surových záznamů, historické hrany v grafu, provozní evidence pouze pro čtení (destruktivní operace zůstávají operátorovi), správa klíčů s vazbou na osobu, expirací a rotací, ověření otisků reportů přímo v prohlížeči a jediný sdílený designový systém s veřejným webem hlídaný testy parity a konzole. Cestou odhalena a opravena regrese bezpečnostní politiky, kvůli které byly aplikační stránky v prohlížeči vynucujícím CSP nefunkční. Na kokpit navazuje interaktivní laboratoř zdrojů: každá karta zdroje na stránce Funkce vede na diagnostickou stránku, kde lze bezpečně spustit skutečný dotaz jednoho zdroje nad zadaným subjektem — se stejnými produkčními limity, s typovaným výsledkem pro každý stav (nález, bez záznamu, chybějící přístupy, zpoplatnění, typované chyby) a bez jakéhokoli zápisu do případů; příklady se předvyplňují z certifikačních specifikací a nikdy se nespouštějí samy, zpoplatněný dotaz vyžaduje výslovné potvrzení vynucené serverem. Slovník výsledků nově rozlišuje lokální frontu od omezení zdrojem: „ve frontě — lokální limit" je stav naší vlastní ochrany zdrojů, nikdy se nepočítá jako selhání zdroje a nikdy nespouští poplach určený pro skutečné upstream omezení.

9. Dokončení API povrchu

   Stránkované seznamy šetření a zpráv, živý katalog zdrojů, průběžný SSE stream stavu běhu a ruční zrušení běžícího šetření.

10. Observabilita a provoz

    Strukturované JSON logování s automatickou redakcí citlivých hodnot, kontrola dostupnosti závislostí (/health/dependencies) a provozní metriky v Prometheus formátu (/metrics) — včetně metrik za jednotlivé zdroje dat (úspěšnost, latence) a přechodů stavu šetření — doplněné provozními runbooky.

11. Vydávací připravenost

    Vícestupňový Docker obraz bez závislosti na root uživateli s vestavěným healthcheckem, ověřený build a smoke test, kontrolní seznam vydání a zdokumentovaný plán rollbacku — včetně hromadné obnovy grafové projekce Kuzu ze zdrojových dat po vydání měnícím schéma grafu.

12. Rozšířená technická dokumentace

    Architektura, datový model, grafový model, kontrakt poskytovatelů a onboarding průvodce pro operátory/analytiky — každý dokument ověřený proti skutečnému kódu, ne přepsaný ze zadání.

13. Generovaná technická wiki

    Technická dokumentace (architektura, datový model, kontrakt poskytovatelů, API, bezpečnost, provoz, onboarding) generovaná přímo z docs/ do GitHub wiki — nikdy ručně editovaná, s vlastní kontrolou souladu (just wiki-check).

14. Rizikové skóre a širší odvozování zjištění

    Souhrnné rizikové skóre počítané po každém běhu šetření z jeho zjištění po integritní kontrole; osm z dvanácti zdrojů nyní odvozuje zjištění přímo ze svého nálezu (aktivní insolvence, zaniklá firma, neprůhledná vlastnická struktura a další); přístupnost aplikace (klávesová navigace, skip odkaz) dořešena.

15. Zpřesnění sémantiky insolvenčního rejstříku (ISIR)

    Dlouhodobý program AAA hardeningu insolvenční větve (73 etap; 67 hotových). Kanonický dokument sémantiky ISIR je ověřený proti oficiální dokumentaci Ministerstva spravedlnosti a UI texty zpřesněné — negativní výsledek je vždy uvedený v rozsahu dotazu, nikdy jako důkaz bezdlužnosti.

    Identita a pravdivost dotazu: IČO se validuje kontrolní číslicí ještě před síťovým dotazem a nález s cizím IČO se odmítá — nikdy se tiše nepřiřadí; datum narození osoby se validuje, posílá do rejstříku a rozpor nález diskvalifikuje; shoda jen podle jména je explicitně slabá identita se sníženou důvěryhodností a lidskou kontrolou. „Bez záznamu" platí jen při výslovném stavovém kódu prázdného výsledku a doložené čerstvosti dat — zastaralý či chybující rejstřík nikdy nevrací „čisto"; každý negativní výsledek nese auditní stopu dotazu a oříznuté sady výsledků se označují jako neúplné.

    Odolnost a limity zdroje: typovaný parser podle oficiální dokumentace služby (žádný únik upstream textu, ohraničený vstup, odmítnutí DTD/entit, property/fuzz testy hranic), typované transportní chyby s explicitní opakovatelností, časové rozpočty s ohraničeným backoffem, oficiální limity ministerstva (3000/den, 50/min) vynucené atomickým rozpočtem sdíleným napříč workery, pojistkový vypínač s jedinou zotavovací sondou a stavem na health endpointu. Lokálně odmítnutý rozpočet se nikdy nevydává za throttling zdroje — zdraví rejstříku degradují jen jeho vlastní odpovědi.

    Průběžné sledování rejstříku: nad zmrazeným kontraktem oficiálního event-feedu (v2.10) stojí typovaný klient, crash-safe append-only replika s kontrolním bodem postupujícím ve stejné transakci, přebuditelné materializované projekce stavu řízení (přírůstkové i úplné přehrání dávají otiskem shodný stav), kanonická identita spisové značky, logická invalidace událostí, jediný vlastník pollingu přes distribuovaný lease a resumovatelný bootstrap s provenienci.

    Dokumenty a produktová vrstva: projekce metadat dokumentů, bezpečný idempotentní downloader s content-addressed úložištěm, extrakce textu s provenienci, konzistenční linkování bodového dotazu s event-feedem, korelace subjektů napříč zdroji, fronta lidské kontroly insolvenčních signálů, sjednocená doménová hranice „debtor intelligence" s povolenými/zakázanými formulacemi, prohledávatelný insolvenční index a čtecí API s kontrakty pro negativní, degradované i detailní odpovědi. Telemetrie s uzavřenými slovníky štítků (bez osobních údajů), verzovaná pravidla alertů s runbooky a výkonnostní baseline. Produktová vrstva je nyní vidět i v aplikaci: fronta lidské kontroly insolvenčních pozorování s nezměnitelnými, osobně atribuovanými rozhodnutími vázanými na přesný důkazní podklad, stránka pravdivého insolvenčního stavu (negativní výsledek vždy v rozsahu dotazu, nikdy jako bezdlužnost) a auditovatelný detail řízení s časovou osou včetně zrušených událostí, dokumenty s ověřením zdrojové adresy a proveniencí projekce.

16. Automatická certifikace a noční důkazy

    Dohled nad platformou běží bez lidského spouštění: průběžná certifikace každých 6 hodin skládá poslední certifikační a drift evidenci do stavu každého zdroje (stárnutí a drift degradují stav, nikdy data), hlídání driftu upstream kontraktů porovnává živé odpovědi s verzovanými baselinami a každou noc se proti aktuálnímu kódu znovu prokazují nejtěžší garance — destruktivní obnova ze zálohy s kryptografickým auditem, zkouška migrací s rollbackem nad reálnými daty a zátěžový důkaz globálního limitu souběhu. Neúspěšný běh je sám o sobě alert; prostředí se ověřuje před testy, takže rozbité CI nikdy neprojde jako tiché „zelené". Obnova commitnuté evidence zůstává vědomým, kontrolovaným krokem.

    Kanonický dokument sémantiky ISIR ověřený proti oficiální dokumentaci Ministerstva spravedlnosti (rozsah rejstříku, limity služby, co nález a ne-nález skutečně dokládá) a zpřesněné texty v UI — negativní výsledek je vždy uvedený v rozsahu dotazu, nikdy jako důkaz bezdlužnosti. Zahájen dlouhodobý program AAA hardening insolvenční větve (73 etap, průběžně): typovaný model výsledků dotazu na zdroj rozšířen o chybové stavy hlášené samotným zdrojem a o odmítnutí nevalidního vstupu; IČO se nyní validuje kontrolní číslicí (mod 11) ještě před jakýmkoli síťovým dotazem a nález s IČO jiné firmy se odmítá — nikdy se tiše nepřiřadí. U osob se datum narození validuje centrálně a posílá do rejstříku, nález s jiným datem narození se odmítá a shoda jen podle jména je explicitně slabá identita: snížená důvěryhodnost, označení entity a zjištění rovnou k lidské kontrole. Odpovědi rejstříku se nově vyhodnocují podle oficiální dokumentace služby: „bez záznamu" platí jen při výslovném stavovém kódu prázdného výsledku a čerstvé synchronizaci dat — zastaralý či chybující rejstřík nikdy nevrací „čisto", ale viditelnou, opakovatelnou chybu zdroje; každý negativní výsledek navíc nese auditní stopu dotazu (identita, rozsah, čerstvost zdroje) a oříznuté sady výsledků se označují jako neúplné — omezený výčet řízení se nikdy nevydává za kompletní. Odvozování zjištění je sladěné s oficiální sémantikou filtru aktivních řízení: záznam vrácený pod aktivním filtrem je dle garance rejstříku aktuálně platný dlužník (dřívější heuristika tiše potlačovala nálezy u obživlých řízení), rozpor s uvedeným datem ukončení jde k lidské kontrole a historické dotazy vracejí jen důkazy, nikdy automatická zjištění. Interní zpracování záznamů rejstříku je plně typované: syrové hodnoty zdroje oddělené od odvozené sémantiky, nová pole zdroje se měřitelně evidují místo tichého ignorování a tvar ukládaných dat je zamčený testem. Selhání přenosu (DNS, spojení, TLS, timeout) končí jako typované, opakovatelné chyby bez úniku textu z upstreamu a každá třída selhání má explicitně určenou opakovatelnost. Sdílená HTTP vrstva má explicitní časové rozpočty, ohraničený backoff s celkovým limitem a politiku respektující kvóty zdroje — přetížený rejstřík se nikdy „nebuší" opakovanými pokusy; TLS ověření nelze v kódu vypnout (hlídané testem). Oficiální limity ministerstva (3000 dotazů denně, 50 za minutu) jsou nyní vynucené za běhu: atomický dvouokenní rozpočet sdílený napříč workery i restarty se čerpá před každým dotazem a vyčerpaný či neověřitelný rozpočet dotaz viditelně odmítne — podmínky zdroje nelze překročit ani při výpadku vlastní infrastruktury. Insolvenční větev má nyní i pojistkový vypínač (circuit breaker): opakovaná selhání zdroje okruh otevřou a další dotazy se viditelně odmítnou, místo aby se do nefunkčního rejstříku bušilo dál; zotavení probíhá jedinou, atomicky drženou zkušební sondou a stav okruhu je vidět na provozním health endpointu. Ne-nález ani odmítnutý vstup okruh nikdy neotevírají — o tom, co je selhání zdroje, rozhoduje jediná sémantická tabulka výsledků. Vyhodnocení „bez záznamu" bylo zároveň opraveno podle živého měření reálné služby: prázdná odpověď rejstříku čas synchronizace vůbec neuvádí, eviduje se proto poctivě jako neuvedený (rejstřík hlásí rozbitou synchronizaci vlastním výslovným stavem) — dříve každý reálný negativní výsledek chybně degradoval na chybu zdroje. Původ (provenance) je nyní symetrický pro všechny tři druhy pozorování: pozitivní nález nese stejný kontext dotazu a parsování jako negativní (operace, režim dotazu, verze zdrojového kontraktu i parseru), typované selhání ukládá svůj bezpečný popis a opakovatelnost přímo k záznamu pokrytí — každé pozorování lze zreprodukovat čistě z uložených dat, bez přístupu k logům. Hranice parseru jsou nově ověřené i generativním (property/fuzz) testováním nad rámec ručních fixtur — „bez záznamu“ nemůže vzniknout z žádného zašuměného či nerozpoznaného vstupu, jen z výslovné prázdné odpovědi rejstříku — a vstup parseru je ohraničený: deklarace DTD/entit a nadměrné odpovědi se odmítají ještě před parsováním (ochrana proti entity-expansion útoku a paměťovým bombám), vždy jako viditelná typovaná chyba. Chování insolvenční větve je nově ověřené i integračně přes celý životní cyklus šetření nad reálnou databází — matice všech osmi výsledků (nález, ne-nález, slabá identita, oříznutí, zastaralost, kvóta, chyba zdroje, chyba parsování) dokládá, co přesně se uloží a co uvidí API; potvrzeno mj., že osamocený insolvenční signál z jediného zdroje vždy končí u lidské kontroly (pravidlo nezávislosti zdrojů), a opakované doručení už dokončené úlohy frontou je nyní elegantní no-op — nikdy neduplikuje důkazy ani záznamy pokrytí. Telemetrie nyní rozlišuje zdravý provoz bez záznamů od degradace: vedle výsledkových čítačů se měří kvalitativní rozměry odpovědí (slabá identita jen podle jména, oříznuté sady, negativa bez uvedeného času synchronizace), stáří synchronizace zdroje, číselný stav pojistkového vypínače i skryté síťové retry — vše s uzavřenými slovníky štítků, bez IČO, jmen či spisových značek. Na telemetrii navazují verzovaná pravidla alertů s vlastníkem, závažností, oknem i runbookem pro každý alert — prahy bez naměřené produkční základny jsou povinně označené jako předběžné (hlídá to validátor, ne slib) a struktura pravidel ze své podstaty neumožňuje, aby do alertu pronikly osobní údaje; rozlišení výpadku zdroje od lokální chyby parseru je pravidlem provozu, ne interpretací. Zpracování nedůvěryhodného XML a transportu je zabezpečené proti zneužití: chování parseru bylo ověřeno empiricky na projektové verzi Pythonu (externí entity se strukturálně nikdy neresolvují, expanze interních entit je odmítnuta ještě před parsováním), tělo odpovědi má strop vynucený už během streamování na transportní vrstvě, insolvenční SOAP klient nikdy nenásleduje přesměrování a žádný log nesmí obsahovat surové tělo odpovědi — vše přibité regresními testy. Vedle bodového dotazu je nyní připravená i cesta k průběžnému sledování rejstříku: oficiální kontrakt event-feedu (verze 2.10) byl nastudován z první ruky a zmrazen včetně dvou záludností, na kterých naivní klienti selhávají, a nad ním stojí úzký typovaný klient — stahuje dávky akcí od kontrolního bodu, poznámky uchovává bajt po bajtu pro budoucí verzované parsování, degradace hlášené zdrojem zviditelňuje místo vyhazování a sdílí veškerou odolnostní infrastrukturu (pojistkový vypínač, kvóty, zabezpečený transport); nic neukládá a nic neinterpretuje — replika a projekce přijdou jako další vrstvy. První z těchto vrstev je nyní hotová: crash-safe replika event-feedu — akce se ukládají do append-only tabulky pod vlastním neměnným sekvenčním ID zdroje a kontrolní bod postupuje ve stejné databázové transakci jako vložení dávky, takže se nikdy nemůže dostat za neuložené události; opakované doručení, překrývající se dávky i restart procesu jsou díky přirozenému klíči a exkluzivní mezi bezztrátové (ověřeno testy s injektovaným pádem nad reálnou databází). Uložené akce tvoří neměnný, jen-přidávací pramen: repository nad nimi záměrně nemá žádnou metodu pro úpravu ani smazání, takže žádná budoucí projekce nemůže přepsat historii zdroje, a u každé akce se drží syrová poznámka i její otisk (SHA-256) pro pozdější ověřitelné přeparsování po opravě parseru či změně schématu. Nad tímto pramenem stojí přebuditelná materializovaná projekce aktuálního stavu řízení: odvozuje se deterministicky z seřazeného proudu akcí, takže ji lze kdykoli zahodit a znovu postavit z pramene byte identicky, přírůstkové i úplné přehrání dávají prokazatelně stejný stav (ověřeno otiskem), a změna verze projektoru automaticky spustí přestavbu. Zatím pracuje na úrovni obálky událostí; hlubší sémantika (strany, role, právní stav) přijde s parserem poznámek za dalším zvýšením verze. Dotazy do rejstříku mají nově sémanticky bezpečnou cache s deduplikací souběžných dotazů — týž dotaz položený vícekrát najednou se na zdroj ptá jen jednou a negativní odpověď se nikdy nepodává jako aktuální, pokud aktuální není. Identita řízení je nyní kanonická a zdrojově podložená: spisová značka se normalizuje deterministicky (varianty v mezerách a lomítku se sloučí do jednoho řízení, původní podoba se zachová pro zobrazení), a nevalidní značka se nikdy tiše nesloučí s platným řízením — je izolovaná zvlášť.

Závazný epicový žebřík: dokončené základy (zeleně) a pořadí dalších kroků (fialově). Pořadí je záměrné: nejdřív prokázat chování proti skutečným zdrojům, pak odolnost, škálování a provozní jistoty — certifikaci produkce nelze přeskočit.

1. EPIC-01 · Exekuční pravda poskytovatelů Hotovo

   Každé volání poskytovatele má pravdivý, uzavřený výsledek (nález / bez záznamu / selhání) — selhání se nikdy nevydává za prázdný výsledek. Sémantika výsledků je vynucená testy napříč všemi 12 poskytovateli.

2. EPIC-02 · Nezávislost důkazů a kanonická korelace Hotovo

   Důkazy existují nezávisle na běhu šetření a korelují se do kanonických nálezů se stabilními sémantickými klíči; integrita důkazů je hlídaná kryptografickou branou.

3. EPIC-03 · Neměnná provenience a artefakty reportů Hotovo

   Surové odpovědi poskytovatelů se ukládají neměnně s oddělenými otisky raw/normalizovaných dat; reporty mají zmrazený obsah, artefakty s SHA-256, podepsaný manifest a offline ověřovač staženého souboru.

4. MINI-EPIC-03.5 · Snapshot izolace, viditelnost a čistý git Hotovo

   Generování reportu běží nad jedním konzistentním snapshotem databáze, viditelnost důkazů je vynucená všude a repozitář po každém commitu konverguje do čistého stavu.

5. EPIC-04 · Lidská kontrola a přenos rozhodnutí Hotovo

   Append-only rozhodnutí kontrolora nad kanonickými nálezy (potvrdit / zamítnout / vyžádat další důkazy), hashované review base, detekce zastarání a konzervativní přenos rozhodnutí mezi běhy. Česká fronta kontroly na /app/review.

6. EPIC-05 · Živá certifikace poskytovatelů Hotovo

   Všech 12 reálných poskytovatelů má verzovanou certifikační specifikaci se sémantickým orákulem a stabilními testovacími subjekty; živé běhy jdou proti skutečným upstreamům bez mocků, včetně plné aplikační větve (efemérní databáze, reálný worker, pravda přepočtená z uložených řádků) a golden běhů s živou korelací napříč sankčními seznamy. Osm zdrojů je certifikováno živě, čtyři čekají viditelně na přístupové údaje; certifikační běh odhalil a opravil i reálné vady (zahraniční společník bez IČO, klasifikace výpadku v odpovědi 200).

7. EPIC-06 · Produkční golden journeys Hotovo

   Kompletní end-to-end cesty přes skutečné služby běží a procházejí: skutečný prohlížeč → šetření v české aplikaci → reálný worker → živí poskytovatelé přes internet → důkazy a korelace → lidské potvrzení nálezu kliknuté v kontrolní frontě → neměnný report → artefakt i manifest stažené prohlížečem a ověřené offline verifikátorem. Journeys podle druhu subjektu: společnost, sankce/osoba, DPH/LEI; katastrální journey čeká viditelně na přístupové údaje ČÚZK. První živý běh odhalil a opravil skutečnou vadu: stahování reportů neneslo autentizační hlavičku.

8. EPIC-07 · Odolnost poskytovatelů Hotovo

   Každý poskytovatel má vlastní revidovanou politiku odolnosti (timeouty, retry rozpočty, backoff s jitterem — žádná univerzální politika; zdroje s oficiální kvótou nikdy neretryují naslepo). Šetření běží s řízenou souběžností při zachování deterministického pořadí zápisů a kooperativního zrušení včetně rozběhnutých dotazů. Deset poruchových režimů (DNS, TLS, timeouty, reset, 429, 500, poškozené tělo…) je deterministicky testováno s pinem, že se selhání nikdy nezmění v „bez záznamu“. Doktrína v docs/RESILIENCE.md, rozhodnutí v ADR 0020.

9. EPIC-08 · Průběžné hlídání driftu kontraktů Hotovo

   Ohraničené živé sondy nad certifikačními specifikacemi porovnávají otisk tvaru odpovědi (JSON klíče, XML namespace, CSV hlavičku) s verzovanou baseline, hlídají sémantické orákulum, typ obsahu, latenci i sérii výpadků upstreamu napříč běhy. Změna kontraktu je alert — přijetí nové baseline je vždy ruční review s odkazem na běh, který ji pozoroval, nikdy automatické přijetí. První živý běh: všech 8 nakonfigurovaných poskytovatelů stabilních, 4 viditelně čekají na přístupové údaje.

10. EPIC-09 · Identita, matching a časová platnost Hotovo

    Sdílená vrstva jmen odděluje zmrazenou normalizaci kanonických klíčů od skládání transliterací pro porovnávání — opravena živě potvrzená falešná negativa sankčního screeningu (pomlčka vs. mezera napříč seznamy EU, OFAC i ČR). Každá shoda nese auditovatelný záznam: přesný dotaz, alias, který shodu naplnil, kanonické jméno záznamu a pravidlo shody. Identifikátory subjektu se obohacují aditivně (pozdější požadavek či autoritativní zásah doplní chybějící, nikdy nepřepíše), vztahy nesou platnost od data zápisu z veřejného rejstříku a vyškrtnutí jednatelé se už nevydávají za aktuální.

11. EPIC-10 · Rekurzivní šetření Hotovo

    Parametr max_depth šetření nyní řídí skutečnou ohraničenou expanzi: firma → osoby → propojené firmy → jejich vlastní sankční, insolvenční a rejstříkové dotazy. Expandují se jen entity se silnou identitou (osoby s ověřeným jménem, firmy s platným IČO), cykly hlídá množina navštívených klíčů, počet dětí omezuje provozní rozpočet pod absolutním stropem v kódu a každá akvizice nese provenienci k hraně, která ji objevila. Pokrytí zdrojů ani počty nezávislých zdrojů se rekurzí neředí; hloubka 1 zůstává přesně dnešní chování.

12. EPIC-11 · Konzistence odvozených úložišť Hotovo

    Tvrzení „Postgres je jediný zdroj pravdy“ je nyní vynucené: jednopříkazový rebuild obou projekcí se skutečnou sémantikou mazání (osiřelé dokumenty i grafové soubory se odstraní), read-only detektor driftu s přesnými počty čtenými z úložišť, verze projekcí, parita viditelnosti nálezů mezi API a vyhledáváním a promítnutí časové platnosti vztahů do grafu. Povinný scénář — znič odvozená úložiště, obnov z Postgres, dostaň sémanticky identické výsledky — prochází proti reálným kontejnerům.

13. EPIC-12 · Testovací matice prostředí a release Hotovo

    Čtyři vrstvy testů s jasným účelem svázané do jediného verdiktu o vydatelnosti: deterministická a integrační vrstva se spouští, živá certifikace a drift se posuzují z commitnuté evidence s pravidlem čerstvosti podle dotčených cest — certifikace ze staršího SHA se nikdy necituje, nově vynuceno strojově. Živé testy neblokují commit, ale blokují vydání; CI si nově vynucuje dostupný Docker, takže integrační vrstva nemůže tiše proklouznout.

14. EPIC-13 · Observabilita a SLO Hotovo

    Provozní řídicí rovina ve dvou polovinách: zdravotní stav poskytovatelů, okruhy a alertní pravidla drží ISIR program; platforma nově měří hloubku a stáří fronty, databázový pool a trvání transakcí a generování reportů (poprvé vůbec) průběžně na /metrics; růst úložiště a zpoždění ISIR repliky z existujícího checkpointu měří provozní snímek na vyžádání. Logy korelují přes ID šetření. Provozní snímek zapisuje i stáří a platnost commitnuté certifikační evidence. Hodnoty SLO se záměrně nevymýšlejí — nejdřív se měří, cíle se odvodí z tvrdých dat.

15. EPIC-14 · Zátěž, kapacita a backpressure Hotovo

    Chybějící globální mez doplněna: limit souběžných dotazů na jeden zdroj platí nově napříč všemi šetřeními i workery (vynucený přes Redis, bezpečný i při pádu procesu) — 500 nových případů už nikdy neznamená 500 souběžných dotazů na ARES; nápor se řadí do fronty, nevyrábí falešná selhání. Deterministický zátěžový test s reálným workerem a zástupnými zdroji měří propustnost, růst žurnálu databáze a chování fronty — první skutečně změřené základní hodnoty platformy. Kapacitní cíle se záměrně neodvozují předem.

16. EPIC-15 · Autentizace a bezpečnostní hardening Hotovo

    Kontrolní rozhodnutí nově nesou identitu konkrétního člověka (klíč vázaný na osobu, e-mail v auditním otisku) — „kdo tento nález potvrdil“ už neodpovídá anonymním klíčem. API klíče umí expiraci a atomickou rotaci, oprávnění k citlivým důkazům je oddělené od správy klíčů, neúspěšné pokusy o přihlášení jsou poprvé měřitelné (viditelný credential stuffing), každá odpověď nese bezpečnostní hlavičky a příchozí tělo požadavku má tvrdý limit. Nový egress guard chrání před SSRF každé budoucí stahování URL z dat, závislosti mají SBOM inventuru a statickou bezpečnostní analýzu. SSO a webové přihlášení zůstávají vědomě odložené — dokumentovaný podklad pro externí bezpečnostní review. Dodatečná oprava (2026-08-13): bezpečnostní politika CSP původně blokovala vyhodnocování výrazů UI frameworku, takže aplikační stránky byly v prohlížeči vynucujícím CSP nefunkční — politika je opravena a novou bránou v testech se každá stránka hlídá na nezachycené chyby v konzoli.

17. EPIC-16 · Certifikace zálohy a obnovy Hotovo

    Obnova je prokázaná vlastnost, ne tvrzení: záloha nese ověřitelný manifest (otisk, revize schématu, počty řádků), obnova šplhá po žebříku kontrol, které selžou zavřeně — včetně pasti tichého rozpadu hypertabulek TimescaleDB, na kterou se explicitně testuje. Destruktivní drill jede přes skutečné operátorské příkazy: důkazy, lidská rozhodnutí i reporty se obnoví bit po bitu, report se ověří offline bez databáze, odvozená úložiště se přestaví a odpovídají identicky. Data zapsaná po záloze prokazatelně chybí — poctivá demonstrace RPO; RPO/RTO se měří za běh, nikdy nedeklarují. Release gate nově soudí commitnutou evidenci obnovy jako samostatnou vrstvu.

18. EPIC-17 · Bezpečnost nasazení a migrací Hotovo

    Migrace se před nasazením zkoušejí na produkčně tvarované kopii dat — včetně měření času každé revize a ověřeného rollbacku nad skutečnými řádky; release gate soudí commitnutou evidenci zkoušky. Souběžné nasazení migrací se serializuje zámkem (závod podů skončí neškodně), destruktivní migrace a prázdné downgrady neprojdou kontrolou kvality bez výslovné výjimky. Produkční proces odmítne nastartovat na vývojových výchozích hodnotách, oba procesy se ukončují elegantně a restart workeru uprostřed šetření prokazatelně neztratí práci — job doběhne přesně jednou. Každý release se identifikuje přesně: otisk kódu, revize schématu, evidence kontraktů zdrojů.

19. EPIC-18 · Produkční akceptace Částečně — čeká na klíče

    Finální brána běží: akceptační drill provedl skutečný prověrkový případ od prázdné databáze přes veřejné API, živé zdroje, lidskou kontrolu s osobní atribucí a offline ověřenou zprávu až po zálohu, obnovu do čerstvého prostředí, opětovné ověření artefaktů a chaos test s typovanými výpadky zdrojů. Verdikt sestavuje jediný příkaz nad commitnutou evidencí — a dnes poctivě říká ČÁSTEČNĚ: osm zdrojů živě certifikováno, čtyři čekají na přístupové klíče vlastníka (ČÚZK vyžaduje osobní registraci, CEECR a Hlídač státu API klíče). S klíči v prostředí je PRODUCTION CERTIFIED opakovaný běh, ne projekt.

20. EPIC-19 · Průběžná produkční certifikace Hotovo

    Certifikace už není jednorázový odznak: pravidelný cyklus skládá poslední commitnutou certifikaci a drift do průběžného stavu každého zdroje (certifikováno › zastaralé › drift › degradováno › blokováno). Stárnutí i změna upstream kontraktu degradují STAV zdroje, nikdy jeho data — provozní pokračování doktríny EPIC-01. Plánovaný běh každých 6 hodin bez sítě, na vyžádání s živou sondou; neúspěšný běh je sám o sobě alert. První cyklus: certifikováno (8 zdrojů, 4 čekají na přístupové údaje). Tím je program EPIC-05→19 implementován od začátku do konce.

1. Kontinuální monitoring

   Plánované opakované běhy šetření a detekce změn nad historií v TimescaleDB: nová insolvence, změna statutárního orgánu, nový sankční záznam. Tady platforma naplní své jméno — progresus znamená sledovat vývoj v čase.

2. Webhooky a integrace

   Push notifikace o dokončení šetření a nových zjištěních do navazujících systémů.

3. Grafový explorer

   Interaktivní analytické dashboardy nad grafem entit (GraphQL vrstva pouze pro explorer — nikdy jako veřejný průchod na surové grafové dotazy).

4. Registry mimo ČR a škálování

   Dnešní katalog pokrývá osm českých zdrojů, celoevropský VIES/GLEIF a sankční seznamy EU a USA; další národní registry rozšíří pokrytí o další jurisdikce. Distribuované zpracování šetření na více workerech.

5. SSO a distribuované trasování

   Keycloak/SSO integrace pro podnikové nasazení nad rámec API klíčů; distribuované trasování (tracing) napříč službami nad rámec dnešního korelačního ID.