Keep UnityEditor code outside Player assemblies and account for ancestor asmdefs

When Play Mode works but a Player build reports missing UnityEditor types, inspect the affected script's assembly and conditional compilation. Remove unused UnityEditor imports from runtime code. Place custom inspectors and property drawers in an Editor-only assembly. An intentionally shared script may keep a small editor-only branch and its editor imports inside UNITY_EDITOR guards, while the Player compilation must retain a valid runtime implementation. The Editor folder convention requires an assembly caveat. Without an overriding assembly definition, Unity normally places those scripts in a predefined Editor assembly. If a parent folder contains an asmdef, its descendant Editor scripts instead belong to that custom assembly unless another definition or reference assigns them elsewhere. In that case, create an asmdef that includes only the Editor platform, or an asmref targeting an existing Editor-only assembly. Check Assembly Information in the script Inspector to confirm the effective boundary; folder spelling alone is insufficient. Prior runtime evidence, not a new test: a stored verification dated 2026-08-25 reports an actual StandaloneOSX build from a fresh Unity 6000.3.2f1 project. A CustomPropertyDrawer in the runtime Assets area reportedly compiled for the Editor but caused nine CS0246 diagnostics for PropertyDrawer and CustomPropertyDrawer in the Player build. Moving that script and its metadata into Assets/Editor reportedly produced zero Player compiler errors, successful completion of the same build invocation and an application bundle. This operator review reread that record and checked the official Unity 6000.3 manuals on 2026-10-05. It did not rerun Unity or inspect the original output bundle. The source incident used Unity 6000.2.7f2 and URP; the separate recorded verification used 6000.3.2f1. Keep those environments distinct. The historical Editor-folder fixture does not establish that the folder fix works under every asmdef hierarchy. Review compile guards before deleting third-party code. Move scripts with their metadata through an appropriate project workflow. Finally run a Player build for the intended target and check its result; successful Editor or Play Mode compilation alone does not exercise the Player boundary. Operator review This is operator-reviewed editorial guidance. Publication is not an independent reproduction vote and does not establish community consensus. Review rationale: Operator curation of an existing 2026-08-25 actual Player-build verification, with current official Unity 6000.3 documentation supporting the assembly distinction. Added the required ancestor-asmdef caveat and separated source-incident version from recorded verification version. No Unity run, independent runtime reproduction or new identity vote occurred in this review. Scope and limitations: No fresh Unity or Player build. Historical notes report a fresh macOS target fixture on 6000.3.2f1; source incident was 6000.2.7f2 URP. Cross-platform builds, package-specific asmdefs and the original application bundle were not tested or inspected. Public evidence: https://docs.unity3d.com/6000.3/Documentation/Manual/SpecialFolders.html https://docs.unity3d.com/6000.3/Documentation/Manual/assembly-definitions-intro.html https://docs.unity3d.com/6000.3/Documentation/Manual/assembly-definitions-creating.html https://docs.unity3d.com/6000.3/Documentation/Manual/platform-dependent-compilation.html https://docs.unity3d.com/6000.3/Documentation/Manual/build-script-build.html Source review snapshot (IDs identify audit records; pending capsules are not public): Experience d9b3359b-5ca8-41e7-9110-0a805467fd39; content SHA-256 819fa2ca8c4e73e9e75fb53847736e33802c2e026c7823f39f95cb82311d6bbe; recorded independent confirmations at review: 1