Aktuální zprávy z bojiště pro ty, koho to zajímá.
HAIFA má dnes dva oddělené skilly pro práci s anonymizovanými databázemi: jeden databázi maskuje, druhý ji nezávisle audituje. Aktuální anonymizovaná databáze Fenixu prošla přísným auditem bez kritických a vysoce závažných nálezů.
Dvaadvacátý týden posunul UCV směrem k finálnímu testování, přinesl skutečný live důkaz plného UPD upgradu včetně převodu hesel, posunul UPD UI do použitelné zpětné vazby, připravil orchestraci UIR a zpřesnil bezpečnou práci s testovacími daty.
RZP prošlo důležitým ověřením konzultanty, kteří Fenix nasazují a provozně podporují u klientů. Nejpodstatnější zpětná vazba zní: modul působí jako původní Fenix, takže zákazník si nevšimne, že používá novou technologii.
Jednadvacátý týden přinesl silný posun UCV v paritě a E2E testech, bezpečné ověření UPD na zahoditelné databázi, kompletní implementační plán UIR a zpřesnění práce s testovacími daty.
Dvacátý týden posunul UCV od integrovaného kódu k použitelným obrazovkám, ověřil vaultové spouštění modulů pod Launcherem a rozšířil přípravu UPD a UIR.
RZP po migraci na Fenix 10.11 prošel kompletními E2E testy na 100 %. HAIFA tým proto připravuje zveřejnění této verze do beta kanálu.
Devatenáctý týden přinesl výrazné sloučení UCV do developu, potvrzenou 10.11 auth/vault deltu ve SPK/SPOL, první společný instalátor a klidnou údržbovou linii RZP 10.1.
Osmnáctý týden měl kvůli dovoleným klidnější rytmus, ale nebyl prázdný: 10.11 auth/vault základ prošel přes SPOL, SPK a RZP, zatímco v samostatné pracovní větvi výrazně pokročilo UCV.
Sedmnáctý týden oddělil předanou linii RZP 10.1 od dalšího vývoje: release větev drží stabilizovaný modul, zatímco develop se překlápí na 10.11, SPOL/SPK, UCV a UPD.
Dne 30. 6. 2026 byl oficiálně odevzdán první hotový modul RZP zmigrovaný z legacy verze 10.1. Projekt se teď přesouvá do hotfix režimu pro RZP, povýšení SPOL/SPK na 10.11, adaptačních úprav RZP a pokračování UCV a UPD.
Šestnáctý týden byl posledním finišem RZP před oficiálním předáním 30. 6.: ladily se paritní detaily, reporty, E2E testy a release proces, zatímco UCV přešlo do živější implementace a roadmapa otevřela další proudy kolem 10.11, SPOL a UPD.
Patnáctý týden posunul RZP od pilotní použitelnosti k doložené paritě: import, rozpouštění, kopie předpisů, reporty, menu a start aplikace dostaly zelené testovací brány; zároveň se uzavřely SPOL/SPK brány pro RZP full-path scope a E2E katalog narostl na 164 scénářů.
HAIFA tým míří k předání prvního migrovaného modulu RZP konzultantům pro pilotní nasazení u klientů do konce června 2026. Není to konec práce, ale důležitý přechod z interní migrace do ověřování v reálném prostředí.
Čtrnáctý týden formálně uzavřel RZP reporting pro pilot, doplnil kontrolu a kopírování rozpouštěcích předpisů, rozšířil E2E a golden-master testování, sjednotil progress dialogy a přenesl zkušenosti z RZP i UCV do globálních migračních pravidel.
Třináctý týden posunul RZP hlavně v tisku a sestavách: vznikly další tiskové rutiny, opravovala se obsahová parita přehledů, posílily E2E testy, zpřesnilo se oprávnění menu a SPOL přidal sdílené dialogy pro průběh a chyby.
NEO_HEF připravuje release management postavený na MSIX balíčcích, GitHub Releases a Windows App Installeru. Cílem je, aby se hotové moduly daly instalovat z kanálů alpha, beta a prod a aby se nové verze dostávaly ke klientům automaticky.
Dvanáctý týden přinesl první větší implementační vlnu UCV, stabilizaci RZP v detailech, nové SPOL brány pro kompatibilitu databáze a chybové hlášky, robotické UI testování a první release-management základ pro MSIX distribuci.
Dobře zadaná oprava chyby může s AI agentem vypadat jinak: agent si chybu sám zreprodukuje v aplikaci, opraví ji a předloží důkaz, že se chování změnilo.
Jedenáctý týden přinesl další praktický posun RZP: rozpouštěcí předpisy ODKUD/KAM, formuláře pro rozpouštění, reportingové obrazovky, E2E testovací orchestraci a experimentální start UCV.
Desátý týden posunul RZP od převodu jednotlivých obrazovek k ověřovaným pracovním tokům: importu účetních dat, rozpouštění, sjednocenému vyhledávání, testům a sdílenému lifecycle pomocných MDB pro reporty.
RZP má funkční automatizované testování: automat otevírá formuláře, vyplňuje testovací data, ověřuje výsledky a generuje přehledný report.
RZP má další funkční část: číselník nákladových a výnosových účtů s editací definic, detailem záznamu, vyhledáváním a kontextovou nápovědou.
RZP se dál posouvá od převedených obrazovek k funkčním scénářům: číselníkům závislým na majiteli, definici rozpouštěcí věty a napojení na GDPR funkce.
Nový VB6 → .NET WinForms skill zlepšil vizuální věrnost nově převáděných formulářů RZP, hlavně vzhled a rozložení. Funkčnost takto vytvořených prvků je ale potřeba dál dotáhnout.
Při převodu formulářů a nabídek RZP narazil tým na první výrazné selhání AI agenta: výstupy se nedržely původního VB6 rozhraní a nebyly prakticky použitelné.
Projekt se posunul od spustitelného RZP k prvnímu skutečnému konzumentovi sdílených vrstev: přihlášení, profily, master-data formuláře, uživatelská nastavení, help a integrační hranice začínají zapadat dohromady.
RZP má další praktickou část společné infrastruktury: při samostatném spuštění se zobrazí přihlašovací dialog s profily databázových připojení.
Migrovaný modul RZP už se dá spustit dvěma způsoby: samostatně jako nová .NET aplikace i ze společného launcheru jako vložené okno.
NEO_HEF má připravenou společnou komponentu pro Crystal Reports. První podporovaný režim řeší sestavy nad lokální MDB databází a ukazuje funkční cestu přes oddělený ReportGenerator.
Přehled prvních sedmi týdnů projektu: od založení pracovního základu až po první výraznou implementační vlnu.
Projekt už nevypadá jen jako analýza a plány: přibývá sdílená infrastruktura, první části SPOL/SPK, RZP integrace, přihlašování, audit i reportovací vrstva.
Migrace tiskových výstupů v RZP ukazuje, proč NEO_HEF není jen mechanický přepis formulářů. I jeden reportovací tok může být samostatný technický projekt.
Kdo sleduje dokumentaci NEO_HEF, naráží stále na SPOL, SPK a RZP. Není to náhoda: právě tady se rozhoduje, jestli se migrace rozjede bezpečně a v dobrém pořadí.
Projekt se posouvá z analýzy do realizace: vzniká implementační plán, přibývají spustitelné části a tým si ověřuje, že cesta jde převést do praxe.
Tým se dostává k podrobnějšímu porozumění systému: zpřesňuje analýzu, rozpracovává plán a ověřuje si kritické části na prvních PoC.
Projekt se posouvá z pouhého sběru podkladů do skutečné analytické fáze: vznikají první migrační materiály, tooling a cílené rozbory.
Po importu přišlo zpevnění projektu: dokumentace se uklidila, znalosti se začaly strukturovat a práce dostala jasnější rámec.
Tým výrazně rozšířil pokrytí systému v repozitáři a založil i referenční stopu původního stavu, takže další práce má pevnější oporu.
Projekt se reálně rozběhl: tým dostal do repozitáře první velké části původního systému a připravil technický základ pro další migraci.
NEO_HEF nestaví nový systém vedle starého. Sází na řízenou migraci po modulech, souběžný provoz a přísně opakovatelný pětifázový postup.
NEO_HEF není vývoj nové aplikace, ale technologická obnova kritického ERP systému, který dnes používají zhruba dva tisíce organizací veřejné správy.
HAIFA znamená Helios AI Factory. Je to malý tým s velkým cílem: vytvořit AI-first továrnu na výrobu software a nasbírané knowhow sdílet do zbytku firmy i celé skupiny.