hyper-games #64 NEXT 4: make a first-compile failure visible rather than silently substituting the built-in generator. TWO SILENT PATHS, and they compound. _recompile_glsl clears cached_glsl_ and then has three early returns. Any of them leaves has_gpu_shader() answering false, dc_worker_cpu on the CPU path, and the map rendering a plausible landscape that is not the graph's -- with nothing in the log. The sharpest is the REFUSAL: proc-nodes' compile_to_glsl_function deliberately returns "" when a node claims GPU support and emits no GLSL, and pushes its own error saying which node. That refusal arrived here and vanished. It now says what the refusal COSTS, which is the half proc-nodes cannot know: the terrain will mesh from a hardcoded gradient-noise -> erosion pipeline that is not your graph. DCTerrain has the other one. A DCTerrainGenerator subclass that does not override get_native_generator() returns null and DCTerrain quietly points generator_ptr_ at its own noise generator, in two places. That generator renders a perfectly good landscape, so the symptom is "the terrain is wrong somehow" and never points at the resource. It now pushes an error naming the resource's class and what to override -- once per transition, because these run on every config propagation and a message per frame is a message nobody reads. VISIBLE HAS TO MEAN ANSWERABLE. A gate cannot see push_error, so three things are bound: DCTerrainGeneratorProcNodes.has_compiled_shader() DCTerrainGeneratorProcNodes.get_last_compile_error() DCTerrain.is_using_builtin_generator() ⚠ AND THE EMPTY STRING WAS AMBIGUOUS. _recompile_glsl only runs from set_graph()/_set(), so a generator nobody has configured has never ATTEMPTED a compile -- and "" made that indistinguishable from "compiled cleanly". The initial value is now "never compiled (no graph has been assigned)". Four states, four answers: never compiled, no graph assigned, a specific failure, or empty for success. My first version of the gate asserted the wrong one of those and went 5/6; the code was right and the expectation was not. demo/compile_failure_gate.gd, 9/9. Mutation-tested: renaming the REFUSED text and flipping using_builtin_generator_ takes it to 7/9, exactly those two cases. ⛔ AND THE FIRST MUTATION RUN WAS A FALSE GREEN. The mutation did not compile, scons said "building terminated because of errors", the .so kept the old code and the gate passed 9/9 against it. A mutation sweep has to check that the BUILD LANDED, not just that the file changed -- the second run confirms the mutant string is in the .so before running the gate. Same species as the stale-library trap in the commit before this one. ⚠ A headless SceneTree script that errors in _init never reaches quit() and hangs rather than exiting. Two runs were lost to that before it was recognised; gate runs are wrapped in `timeout` now. Worth knowing before the next probe. All three targets carry the change (checked by string, not by mtime). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>