Current field notes for people who want to follow the work.
HAIFA now has two separate skills for working with anonymized databases: one masks the database, the other audits it independently. The current anonymized Fenix database passed a strict audit with no critical or high-severity findings.
Week twenty-two moved UCV closer to final testing, brought a real live proof of the full UPD upgrade including password conversion, moved the UPD UI toward usable feedback, prepared UIR orchestration, and tightened safe handling of test data.
RZP went through an important validation by consultants who deploy and support Fenix for clients. The key feedback is that the module feels like the original Fenix, so customers will not notice they are using a new technology.
Week twenty-one brought major UCV parity and E2E progress, safe UPD verification on a disposable database, a complete UIR implementation plan, and more precise handling of test data.
Week twenty moved UCV from integrated code toward usable screens, verified vault-based module startup under the Launcher, and expanded the preparation of UPD and UIR.
After migrating to Fenix 10.11, RZP passed the complete E2E test run at 100%. The HAIFA team is therefore preparing to publish this version into the beta channel.
Week nineteen brought a major UCV merge into develop, a confirmed 10.11 auth/vault delta in SPK/SPOL, the first shared installer, and a quiet RZP 10.1 maintenance line.
Week eighteen had a quieter rhythm because of vacations, but it was not empty: the 10.11 auth/vault foundation moved through SPOL, SPK, and RZP, while UCV advanced significantly in a separate working branch.
Week seventeen separated the delivered RZP 10.1 line from the next wave of work: the release branch keeps the stabilized module, while develop moves toward 10.11, SPOL/SPK, UCV, and UPD.
On June 30, 2026, the first completed RZP module migrated from legacy version 10.1 was officially delivered. The project now moves into hotfix mode for RZP, SPOL/SPK upgrade work for 10.11, smaller RZP adaptation work, and continued work on UCV and UPD.
Week sixteen was the final push for RZP before the official June 30 handoff: parity details, reports, E2E tests, and release work were polished, while UCV moved into more concrete implementation and the roadmap opened further streams around 10.11, SPOL, and UPD.
Week fifteen moved RZP from pilot usability toward documented parity: import, allocation, recipe copying, reports, menus, and startup passed stronger test gates; SPOL/SPK gates for the RZP full-path scope were closed, and the E2E catalog grew to 164 scenarios.
The HAIFA team is preparing to hand the first migrated RZP module over to consultants for client pilot deployment by the end of June 2026. This is not the end of the work, but an important move from internal migration toward real-world validation.
Week fourteen formally closed RZP reporting for pilot use, added allocation-recipe checking and copy parity evidence, expanded E2E and golden-master testing, adopted shared progress dialogs, and turned RZP and UCV lessons into broader migration guardrails.
Week thirteen moved RZP forward mainly in printing and reports: more print routines were added, report-content parity was improved, E2E testing grew, menu permissions became more precise, and SPOL added shared dialogs for progress and errors.
NEO_HEF is preparing release management based on MSIX packages, GitHub Releases, and Windows App Installer. The goal is to install finished modules from alpha, beta, and production channels and deliver new versions to clients automatically.
Week twelve brought the first larger implementation wave for UCV, practical stabilization in RZP, new SPOL startup guards for database compatibility and error messages, robotic UI testing, and the first release-management foundation for MSIX distribution.
With the right assignment, fixing bugs with an AI agent can look different: the agent reproduces the issue in the application, fixes it, and provides evidence that the behavior changed.
Week eleven brought another practical step for RZP: allocation recipes ODKUD/KAM, allocation run forms, reporting screens, E2E test orchestration, and the experimental start of UCV.
Week ten moved RZP from individual screen conversion toward verifiable workflows: accounting-data import, distribution, unified search, tests, and shared helper-MDB lifecycle for reports.
RZP now has working automated testing: the automation opens forms, fills in test data, verifies results, and generates a readable report.
RZP has another working part: the cost and revenue accounts codebook with definition editing, record detail, search, and context-sensitive help.
RZP continues to move from converted screens toward working scenarios: owner-dependent codebooks, allocation sentence definition, and GDPR integration.
The new VB6 -> .NET WinForms skill improved the visual fidelity of newly migrated RZP forms, especially appearance and layout. The functionality of the generated visual elements still needs more work.
During the conversion of RZP forms and menus, the team hit the first major failure of the AI agent: the outputs did not follow the original VB6 interface and were not practically usable.
The project moved from a launchable RZP toward the first real consumer of shared layers: login, profiles, master-data forms, user settings, help, and integration boundaries are starting to fit together.
RZP now has another practical part of the shared infrastructure: when launched standalone, it shows a login dialog with database connection profiles.
The migrated RZP module can now be launched in two ways: as a standalone .NET application and from the shared launcher as an embedded window.
NEO_HEF has a shared component ready for Crystal Reports. The first supported mode handles reports over a local MDB database and shows a working path through a separate ReportGenerator.
An overview of the first seven project weeks: from establishing the working foundation to the first significant implementation wave.
The project no longer looks like only analysis and plans: shared infrastructure, first SPOL/SPK parts, RZP integration, login, audit, and reporting layers are being added.
The migration of print outputs in RZP shows why NEO_HEF is not just a mechanical rewrite of forms. Even one reporting flow can become a technical project of its own.
Anyone following the NEO_HEF documentation keeps running into SPOL, SPK, and RZP. That is not accidental: this is where the project proves whether the migration can start safely and in the right order.
The project moves from analysis into execution: an implementation plan emerges, runnable parts are added, and the team verifies that the path can be converted into practice.
The team is gaining a more detailed understanding of the system: analysis is refined, the plan is developed, and critical parts are verified through the first PoCs.
The project moves from simply collecting material into a real analytical phase: the first migration materials, tooling, and targeted analyses appear.
After the import came project hardening: documentation was cleaned up, knowledge started to be structured, and the work received a clearer frame.
The team significantly expanded system coverage in the repository and also established a reference trace of the original state, giving later work firmer support.
The project truly started: the team brought the first major parts of the original system into the repository and prepared the technical base for further migration.
NEO_HEF is not building a new system next to the old one. It relies on controlled module-by-module migration, parallel operation, and a strict repeatable five-phase process.
NEO_HEF is not the development of a new application. It is the technological renewal of a critical ERP system used today by roughly two thousand public-sector organizations.
HAIFA stands for Helios AI Factory. A small team with a big goal: build an AI-first software factory and share the accumulated know-how across the company and the wider group.