Source skeleton export
The intended output is a starting structure for reviewing recovered program information. It is not a claim to recreate the original source tree, build system, comments, or authors’ identifiers.
What a release must document
Section titled “What a release must document”The guide will specify how selected functions, symbols, types, and unresolved dependencies are represented. It must also explain naming collisions, invalid target-language names, missing function bodies, and files that cannot be emitted.
Keep sample identity, application version, export time, and address mapping with the generated output. Separate generated files from original material so a subsequent export cannot overwrite hand-maintained source without review.
Before exporting
Section titled “Before exporting”- VERIFY selection scope and output format.
- VERIFY whether existing files can be overwritten and how that is confirmed.
- VERIFY how failed decompilations and unknown types are marked.
- VERIFY which metadata may disclose sample names, paths, or symbols.
- VERIFY whether the workflow uses a model or any remote processing.
Use symbols and data types to improve the program model first. Conversion is a separate planned feature; neither page promises a recovered, compilable application.