The last export is not automatically the release. A release is an identifiable package with a known target and recorded checks. Keep the decision small enough that another person can repeat it without access to your memory.
The checklist here is an editorial test plan for your project. It is not a platform certification or a claim that the tutorial assets have been tested in GTA V.
Create the candidate from clean outputs
Export into a fresh directory or deliberately clear only your own staging directory first. Copy the intended game assets into the resource and compare the filenames with your inventory. Old exports should not remain simply because the latest export did not overwrite them.
Keep the matching YMAP, YTYP, drawables, collision and textures together. If you track source in version control, record the revision. If you do not, at least archive a dated source checkpoint and a toolchain note.
Never bundle an entire GTA archive or unrelated third-party assets to make a missing dependency disappear. Identify the dependency and establish that the package is allowed to include it.
State the supported target precisely
Record the GTA edition, intended game build, toolchain and test-server conditions. “FiveM compatible” is less useful than a clearly scoped statement of what you checked.
When supplying both Legacy and Enhanced outputs, give each a separate build record and regression result. Use the edition planning article as a starting point for that organization.
Test four kinds of behavior
Arrival: approach the location from several realistic directions and distances. Include a fresh connection rather than only a resource restart next to the entrance.
Interior transitions: walk through every room connection in both directions. Stop at thresholds and rotate the camera. Use the same route as the portal lesson.
Physical interaction: test floors, steps, entrances and the boundaries the map actually includes. Keep collision results separate from visual results.
Coexistence: run the map alongside the surrounding resources intended for production. Identify overlapping replacements and shared dependencies before distribution.
Choose additional tests based on the features you shipped. An interior with moving doors needs door behavior tests; a plain open workshop does not gain confidence from a checkbox for a feature it does not have.
Make the test record useful
For each issue, store a location, reproduction steps, expected result, actual result and the candidate version. A screenshot can supplement those fields but should not replace them.
Have another person follow the setup instructions without your working directory. If a required filename, registration or resource is missing from the instructions, fix the package or the instructions rather than asking the tester to guess.
Prepare a reversible deployment
Keep the last working resource as a matched package. Write the conditions that would trigger rollback, such as a reproducible blocked entrance or a severe conflict in the intended server configuration.
Use a planned maintenance process for shared servers. Do not validate unfinished collision around active players. After deploying, repeat a short smoke test using the release folder itself.
Include a clear handoff
Ship a readme with installation steps, resource name, target conditions, required dependencies, known limitations and the version. Credit the tools and any assets according to their terms. Provide the original CodeWalker source and download links rather than suggesting that you created the tool.
A good release note can be short: what changed, where to test it, and whether an existing installation needs a different step. The value is repeatability, not a long list of claims.