Roadmapa

Seskupeno podle vrstvy platformy — od datového základu po provoz. Stejné schopnosti sledované po jednotlivých epicích certifikačního programu jsou níže v sekci Cesta k produkční certifikaci.

Platforma a datový základ

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 — celý katalog i s právním základem každého zdroje je na stránce Funkce. 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. 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.

Šetření: pipeline, integrita, korelace, riziko

1. 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.

2. 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í.

3. 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.

Graf, vyhledávání, zprávy a lidská kontrola

1. 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.

2. Interaktivní obohacování grafu Hotovo

   Graf vztahů se stal interaktivní vyšetřovací plochou (20. 8. 2026): kliknutím na uzel se zobrazí serverem ověřená matice použitelných zdrojů (včetně důvodů, proč zdroj použít nelze), vybrané či všechny použitelné zdroje lze spustit nad ověřenou identitou uzlu — samotného, nebo včetně přímých sousedů s povinným náhledem plánu. Každé spuštění běží jako běžné dceřiné šetření standardní pipeline a pouze přidává nezměnitelná pozorování: snapshot, report ani rizikové skóre původní prověrky se nikdy nepřepisují. Zpoplatněný zdroj vyžaduje výslovné potvrzení, souběžná duplicitní práce je odmítnuta na úrovni databáze a průběh lze sledovat i zrušit. Historie každého uzlu odlišuje „Původní snapshot" od „Interaktivní ověření" a přepínač Snapshot/Rozšířený graf zpřístupňuje sjednocený průzkumný pohled s proveniencí původu každého uzlu, plně rekonstruovatelný z databáze. Následná revize téhož dne (adversariální hardening) opravila souběžné hrany běhu, dolepila klávesovou ovladatelnost plátna a odstranila zbylé UI nekonzistence — bez nové uživatelské schopnosti nad rámec výše popsaného.

Aplikace, API a laboratoř zdrojů

1. API klíče a webová aplikace

   Správa hashovaných API klíčů s oprávněními a revokací (referenční přehled je na stránce API); statický veřejný web (každá veřejná stránka nese kanonickou URL a značku og:site_name, web má soubory robots.txt a sitemap.xml odvozené z jediného seznamu tras, přičemž složka /app je z indexace vyloučena) 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.

2. 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í.

3. 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í — plná referenční dokumentace je na stránce Swagger UI.

4. Zpevnění nástrojů a přehledy šetření Hotovo

   Seznam šetření v aplikaci nově zobrazuje jméno a typ subjektu, barevně odlišené štítky nálezů podle závažnosti a počty důkazů přímo ze seznamového API — bez dalších dotazů na detail. Kontrola připravenosti hlídá verzi vyhledávacího jádra, takže nefunkční vyhledávání se už nemůže schovat za zelený stav. Statické reporty sezení dostaly vyhledávání a graf dokumentační topologie. Testovací prostředí je hermeticky odizolované od skutečného repozitáře (uzavřen celý incident z 13. 8.), validátor záznamů sezení je nově blokující a rychlejší kontrola před odesláním přesouvá plné testy do CI.

Insolvenční program ISIR AAA

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

   Dlouhodobý program AAA hardeningu insolvenční větve (73 etap; kódově kompletní — 72 hotových, poslední etapa čeká jen na živé měření náběhu u vlastníka). 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.

Provoz, vydávání a dokumentace

1. 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.

2. 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. Provozní poznámka (19. 8. 2026): automatické běhy jsou od 15. 8. pozastavené kvůli výpadku fakturace GitHub Actions — do obnovení se testy a důkazy spouštějí lokálně; obnova fakturace je akce vlastníka.

   Podrobný stav insolvenčního programu AAA (identita a pravdivost dotazu, odolnost a limity zdroje, průběžné sledování rejstříku, dokumentová a produktová vrstva) popisuje samostatná položka „Zpřesnění sémantiky insolvenčního rejstříku (ISIR)“ v sekci výše.

3. 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.

4. Nasazení do Kubernetes

   GKE manifesty jsou v repozitáři (namespace, externí secrets, síťové politiky, Redis a Meilisearch, migrační job, api/worker Deploymenty, Gateway route) spolu s ručně spouštěnou release pipeline (21. 8. 2026: vydat lze jen commit, který do main prošel pull requestem se zeleným CI; image se před připnutím nastartuje a ověří) — první ostrý provoz mimo jeden kontejner má kompletní podklad.

5. 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í; přehled je na stránce Architektura a v Dokumentaci.

6. 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). Publikace čeká na zapnutí wiki funkce administrátorem repozitáře.

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. Totéž programové pořadí, seskupené podle schopnosti platformy místo epicu, je v sekci Implementováno výše.

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 (firma → sídlo z ARES → adresní místo → parcela v ČÚZK → offline ověřený report) poprvé prošla živě 20. 8. 2026 po nasazení klíče; první běh odhalil a opravil chybně naslepo napsaný rozsah journey. 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Ě: jedenáct zdrojů živě certifikováno (Hlídač státu i katastr ČÚZK doplněny 20. 8. 2026), jeden čeká na přístupový klíč vlastníka (CEECR API klíč). S klíčem 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.