9. Reading the Log and the Conversion Report

Every conversion run should be reviewed through two channels: the live log in the converter UI and the generated report files in the output folder. When the HTML report exists, the Open Report and Print Report buttons use it first. These are not optional extras; they are part of the operating workflow.

Information Source	What It Tells You	How to Use It
Conversion Output log	Live progress and immediate messages during the run.	Use it to see which files were processed and whether the run completed normally.
Conversion reports	Persistent text and HTML records of what the converter saw and reported.	Use them for later review, troubleshooting, printing, and communication with other engineers.
Delphi compile output	The authoritative correctness check after generation.	Use it to identify real syntax, unit, and form-reader issues.
Runtime behavior	The final reality check for workflow correctness.	Use it to confirm that the converted application actually behaves acceptably.

v7.0 Atlas report totals: Total issues means warnings, manual-review items, and errors. Informational notices and dry-run notices are shown separately. Dry-run notices are not counted as conversion issues.

Manual review groups: Click the > arrow on each manual-review item to view affected locations and recommended fixes.

Pay special attention to the final run status. The current v7.0 Atlas report flow distinguishes Blocking issues present, Manual review required, and Clean conversion. The generated report now calls out a recommended next step, Distinct files needing attention, and files with conversion errors. Treat blocking issues as stop conditions even if files were generated. Informational messages about external project assets are different: they warn that companion files may still need manual copying or relocation before runtime testing. Mapping-pack runs additionally report loaded packs, third-party conversions, partial conversions, detect-only findings, preserved components, and unknown third-party-looking classes.

The current report also distinguishes between support files that were actually staged into the FMX output directory and support files that were only found in the source root or beside an existing built executable. Read those companion-file notes carefully, because staging a helper file into the output tree is not the same thing as confirming it will deploy beside the final built executable.

If the report and the compiler disagree, the compiler wins. If Code Insight and the real compiler disagree, the compiler wins again. The memo log and report are aids, not replacements for build and run validation.