Review imported assets in the finished feature

An image can be downloaded, stored in the correct folder and referenced by the application while remaining wrong for the finished product. The file exists and the import works, but the screen may still contain temporary artwork whose replacement was never assigned.

That distinction appeared in my January work on Infini-Wizard, an iOS dungeon game. I reported that the original requirements had been implemented and assets imported, while also raising concern about repeated allowances for temporary art. The available record does not establish a final device test or release, and importing the assets was a narrower result than either of those outcomes.

A temporary asset can be useful during development. It lets a worker test dimensions, loading and interaction before the final visual work is ready. The problem begins when a temporary allowance becomes part of the completion evidence without a separate condition for replacing it.

Source file, build output and screen state

Follow an illustrative spell icon from its source file into a running game. Begin with the source file and record where it came from, the permitted use and which version the application uses. Then inspect the transformed file, such as a resized image or atlas entry, and confirm that the build includes the intended version.

Open the game screen where the icon appears. Check it at the size players will encounter, against the actual background and beside the other controls. An image that looks clear in a large preview may become ambiguous when reduced, and a dark edge may disappear against a dark interface.

Now exercise the state changes. Does the selected icon remain identifiable? Does the disabled state remain distinguishable? If the action has a cooldown, can the player tell when it becomes available again? These are product questions that an import check cannot answer.

The same sequence applies to a document illustration or application logo. A file must be correct at its source, correct after transformation and usable in the place where the reader or player encounters it.

If the asset is supplied in several sizes, compare the file selected by the build with the file listed in the inventory, because a correct high-resolution original does not prevent the application from loading an older thumbnail. Keep the exact filename and build version with the captured screen, and repeat the inspection after replacing the temporary image so the approval refers to the displayed asset rather than to a similar file elsewhere in the folder.

What a placeholder approval covers

A prototype task may explicitly accept a placeholder. That acceptance should name the limited purpose, such as testing the layout or confirming that an asset can be loaded. It should also identify the later task that must replace the placeholder before a release decision.

Do not rely on a comment hidden inside the implementation. The reviewer needs to see the outstanding condition without searching every file. If the next worker receives only a completed status, the temporary allowance can be mistaken for approval of the final appearance.

A practical asset inventory can distinguish source acquisition, integration and final review. Those distinctions are useful because a failure at one stage may require a different person or tool. A missing permission cannot be repaired by resizing the image, and a poor small-screen result cannot be repaired by proving the file downloaded successfully.

The build can change an approved image

Suppose the source image is approved, but an automated build trims transparent margins and changes its apparent alignment. The source approval remains valid for the original image. It does not establish that the transformed image is correctly placed in the running application.

The final review needs the delivered version. Record the build and the screen state, then inspect the asset there. If the reviewer cannot open the application on the intended device, disclose the narrower environment that was checked and leave the device-specific behavior unresolved.

Keep the source record and a captured view of its ordinary and disabled states. If either view still uses temporary art, the inventory should say so, and the release checklist should retain the replacement task until the final asset has been inspected in those same states.

Source notes

Drew Wiberg, Infini-Wizard asset and implementation discussion, 26 January 2026. Contemporary author reports retain the unresolved temporary-art concern.

Worked examples and review procedures in this article are instructional applications, not additional historical project results.