Tickets

AFAL web preview: the Growth gene is named Taper on the dial, and it still bites where it is dimmed

Two defects found reviewing the F052 preview, both about the page disagreeing with itself. FIRST, a vocabulary split. The growth law printed on screen says Growth, which is what D197 and the AFAL language call it. The dial immediately beside it is labelled Taper, and its group heading reads 'Growth to Taper'. One variable, two names, on one screen. GAAD's own pitch is that the 1994 words are still the working words, so a gene with two names in the shop window is not cosmetic. SECOND, and worse because it is silent: a gene that is dimmed still changes the form. Each species declares which genes bite, and the others are greyed as unused - but the build applies the module scale taper^(i/(count-1)) to EVERY species regardless of that list. Spiral and Cone both exclude taper from their active genes while carrying defaults of 0.6 and 0.5, so on Spiral the modules run from 1.0 at the base to 0.6 at the tip while the control that does it is greyed out. Proven numerically at count 8: taper 0.6 gives 1.0, 0.93, 0.864, 0.803, 0.747, 0.694, 0.645, 0.6, where taper 1.0 gives a flat 1.0 throughout. Either the gene is active on all five species and must not be dimmed, or it must be forced to 1 wherever it is dimmed. That is a ruling, not a code choice. Fix before the page goes anywhere near the site. THIRD DEFECT, found 25 Jul by the specimen mapping and verified against both code bases: the web preview applies the module scale growth^t to EVERY species unconditionally, while the v3_029 engine holds Hyperboloid's module scale at 1.0 because Growth is the waist ratio there, not a taper. The two copies of the law already disagree on a species - the first live instance of the drift D202 exists to catch, found by paperwork before the conformance test was built. The Hyperboloid rule (scale held at 1.0) is the engine's and stands; the web conforms to it.

Nav still shakes on some page-to-page clicks despite the gutter, height and font-swap fixes

Miles still sees a wobble/shake navigating between pages (e.g. Languages -> The Architecture) after three fixes were applied to 1_040: scrollbar-gutter:stable on every page (sideways shift from the scrollbar), the exact Episodes hero skeleton with About/Architecture heroes lifted to a common 90px so every title lands at the same height, and font-display:optional on all 18 font pages (text re-render on web-font arrival). A residual shake remains. Not yet root-caused; candidates to check next, on the ACTUAL deployed pages rather than the source: the sticky nav's backdrop-filter:blur(10px) repainting on scroll; per-page differences in body/main top padding or max-width that shift the centred column between pages that do and do not carry a right-hand aside (Episodes/Diary have the 220px index column, others do not, so the 1fr main column computes to a different width - a real horizontal jump between those two page groups); a scrollbar-gutter difference between the grid pages and the plain pages; or image/figure reflow on the heavier pages (Architecture SVGs, About diagram) painting after first layout. Reproduce with the deployed site, capture the specific page pair, and measure the shift direction before changing anything.

GALF requires a base relationship vocabulary that does not exist, and the languages have drifted

GALF s6 says triples use 'base or declared relationship types', and adopted amendment A3 says coherence validates triples against a base vocabulary, not natural-language text. No base vocabulary is written anywhere in the contract, and no language declares its extras, so nothing can be validated. Measured 17 Jul across the five language files with relationships: 13 distinct types counted at first - contains, is_a, belongs_to, assembles_into, defines, controls, occupies, becomes, uses, supports, has, holds, and 'is one of', which is natural language and exactly what A3 forbids. has / holds / contains are three words for one idea. CORRECTION, same day: the first count said FWAL carried no relationships. Wrong - FWAL has 11, and the scan missed them because they are four-element rows (source, type, target, RATIONALE), not the three-element triples s6 describes. So the real drift is worse: FWAL alone brings eight more types - responds_to, grows_from, projects_over, anchors, reveals, transitions, frames, reinforces - taking the estate to 21 distinct types, and it carries a fourth element the contract has no place for. Third vocabulary sprawl found in two days after the eleven feature statuses and tickets closed-vs-resolved (D178): the words were never agreed, so each language invented its own. SECOND CORRECTION, same day: the ticket said 'no language declares its extras'. Wrong. THREE of six do - FWAL declares 30 types in relationship_types_declared (every one of its eight so-called drifting types is in that list), GRAL and PRAL each declare is_a. Only TWAL and MHAL declare nothing. FWAL's only undeclared types are belongs_to and defines, and both are base types in v0.008, so they need no declaration. The fault is narrower and sits with the contract, not the languages: there was no base set for a declaration to sit against. What remains: TWAL's has/holds/'is one of' (retired), MHAL declaring nothing, and the open fourth-element question (A0011).

Isolate from Navigator: selected disc did not isolate

Live path Generate -> Navigate -> click disc -> Isolate produced an empty Isolator with the message 'Select a stage in the Generator'. ROOT CAUSE (found via the console message, after two wrong guesses): clicking the disc PLATFORM resolved no stage because only the content BUILDINGS carry gaad_stage_number, not the disc mesh - so target was None and the operator never isolated anything. The requirement: the SELECTED DISC in the Navigator must isolate, independent of the Generator's champion selection. HONEST test-gap also recorded: the v1_007 Validate 'Isolator from Navigator' step passed because it selects a stamped building (select_then(1,...)) and asserts the held-stage record - it never clicks a bare disc nor checks viewport visibility, so it stayed green while the live disc-click path failed.

TWAL platform parity - 9 named gaps from the first Validate Scripts run

Validate Scripts (F030) with LANGUAGE=TWAL on addon v0_100 / generator v0_52: 24 steps, 9 failures - while the same stack scores 24/24 on PRAL (platform stable, wiring did no harm). The 9 fails are one family: TWAL-built objects do not yet carry the platform conventions PRAL objects do. The parity list: (1) engine stamps/genome tags on TWAL stage objects so Backtrack arm/select/commit can find genomes; (2) shared GAAD materials (gaad_palette) on TWAL boxes so Colour GREY/BAUHAUS/BRAND sweeps them; (3) Navigator connectors/discs for TWAL lineages. Fixing (1) unblocks the Backtrack chain (4 fails), (2) the three Colour fails, (3) the Navigator rebuild fail. Route: extend the BlenderAdapter/generator ctx so TWAL objects are stamped and materialed the platform way - in the Connector's adapter, not in TWAL's genome (engine conventions are engine-side). Then add TWAL steps to gaad_assert (the F030 rule) so parity is asserted, not assumed.

GAAD has no ??AL connector contract - languages can be defined but not run through world/stages/lineage

GALF defines what an Architectural Language IS but, by its own s10 rule, must not assume any renderer/builder/engine - so it cannot own the RUNTIME interface GAAD needs to drive a language through Initial Generation -> Breed -> Navigator/Backtrack -> Present Stage inside the world/stage/lineage model. There is currently no named platform-side contract for that socket. Consequence, exposed by the MHAL prototype (0_008): MHAL has a home on the panel but is 'create-form only' - its heritability is a single RNG seed, not a genome, so it has no knowledge of GAAD world, stages or lineage and cannot be bred, mutated or replayed. A seed has no locality (one-bit change rewrites the whole block), which breaks the genotype->phenotype / .CEL lineage model GAAD is built on. PRAL already satisfies the missing contract de facto (it is what the Generator runs today); the gap is that it was never extracted into a named socket the other languages (MHAL, GRAL, FWAL) can implement.

Navigator Report only discovered legacy G### folders - wrote nothing on flat-scheme data

Caught by the F030 proving run (button-test pass, addon v0.99.13): gaad.report ran clean but Reports/gaad_tree_report.html was never written. Root cause: gaad_tree_report_v0_8's find_generation_files only discovered legacy G###/G###.json folders; generator v0_46+ writes flat sN_gNN.json + lineage.json (D132), so build_lineage returned empty and main() bailed before writing. The report-side sibling of T018 - the tree was fixed (v0_8..v0_18), the report was not.

Stale lineage datablocks force .001 names on Navigator rebuild in a lived-in .blend

Found by the F030 Validate Scripts proving run (addon v0.99.05, 08 Jul): rebuilding the Navigator in a session that already held lineage objects leaves stale datablocks holding the canonical names, so new discs pick up numeric suffixes (Lineage_s1_g02_Surface.001). Exact-name matching then missed the suffixed disc, the Backtrack genome select failed, and the pivot/connector steps cascaded. Only reproduces in a lived-in .blend; a fresh file passes.

Present Stage (F025) future enhancements

F025 Present Stage shipped and was kept as-is after Miles's test (addon v0_84, carried in v0_85). Future enhancements are parked here to be specified later: candidate areas include lighting and framing control, output resolution and aspect options, and background choice. Details to be defined.

Navigator: grids visible through stages and materials not honouring Colour mode

First observed 03 Jul 2026 in bundle 0_115 while testing the addon v0_80 / generator v0_42 panel rebuild. Two related issues showed up in the Navigator scene (gaad.tree operator, gaad_tree_v0_6.py) that had been hidden until the Colour Grey mode (D118, D120 era) started producing worlds that looked right in the Generator: (a) MATERIALS - stages in the Navigator render in the D041/D042 aqua Brand cube colour regardless of the world's chosen Colour mode (Grey world in the screenshot shows aqua Navigator). The Navigator's stage rebuild is not reading scene.gaad_colour_mode, or is not using the shared shape materials introduced in generator v0_39/D118. (b) GRIDS - the infinite Blender floor grid and the stage-pitch grid both show through and between stages in the Navigator, breaking the clean composed look the Navigator had before. Framing and background may also need a look. Both issues live in Scripts/gaad_tree_v0_6.py; the Generator scene is unaffected. Fix scope for a later session: read the Colour mode when building Navigator stage materials, use the same GAAD_<Shape>_Material_<Brand|Grey> naming so materials are shared with the Generator; hide the floor grid and pitch grid in the Navigator scene (or draw a bounded ground plane behind the lineage). UPDATE 05 Jul 2026: the COLOUR half is fixed - tree v0_7 uses the shared per-shape mode materials from gaad_palette.py, so the Navigator honours the Brand / Grey choice and the addon's live recolour covers Navigator objects. The through-grids half remains open.

First-run scene shows default Cube/Camera/Light and view not framed to all stages

During testing, Miles saw non-GAAD objects (the Blender startup Cube, Camera and Light) present in the GAAD scene, and the view not zoomed to show all stages on first look. Cause: clear_scene() only removed GAAD's own objects, never the startup defaults; and the empty preview never framed the view (framing is a bpy.ops, unsafe in the Stage Size callback).

Empty stage-platform preview clips at large grids (9x9)

While testing, Miles saw the empty NxN stage platform (Stage Size live preview, before any generation) clipped at the far edge at 9x9. An NxN grid spans (n-1)*100 + 85 m edge to edge (885 m at 9x9), and nothing had raised the viewport's 1000 m default far clip before a generation ran. The generator's frame_all_views already handles this after a run (raising clip_end to at least 10000), which is why a generated 9x9 shows fine - so only the pre-run preview was affected.

Generator -> Navigator switch takes ~7 seconds

Reported by Miles during 0_108 testing: switching from the Generator scene to the Navigator takes about 7 seconds. Diagnosis: the Navigator button rebuilds the whole lineage scene from scratch on every click, and the tree script still used the pre-D106 build path - one bpy.ops primitive per object, two ops calls each (create + transform_apply), a full scene update per call - multiplied across every object of every lineage stage, plus the auto-run report (D035) on top. FIX SHIPPED in gaad_tree_v0_6.py (bundle 0_109), awaiting retest: the fast-geometry helpers are ported verbatim from gaad_generator_v0_34.py and each lineage stage's objects are built as ONE joined mesh with per-primitive material slots - zero bpy.ops in the per-primitive path, identical vertex layouts (parity verified out-of-Blender against the generator's output). Stage surfaces, labels and the title panel are unchanged. Status stays open until Miles confirms the switch time; if the residual cost is the report auto-run, making D035's report optional is the follow-up lever. STATUS NOTE 03 Jul 2026: tree v0_6 (joined-mesh lineage build) shipped in 0_109; Miles has not yet reported the new Generator -> Navigator switch timing. If a noticeable cost remains, the next lever is making the D035 auto-report optional. Tracked in CURRENT_ACTIONS.md.

Blender crash on bulk object deletion - stale depsgraph references

Blender crashes during viewport redraw after GAAD scripts bulk-delete ~200+ objects. Root cause is a Blender core bug: the DEG iterator holds stale references to deleted objects, and DRW_cache_free_old_batches dereferences a null base pointer at offset 0xB8. The scripts already use the safer bpy.data.objects.remove() path (not bpy.ops.object.delete()), but no depsgraph flush is issued between deletion and the next viewport-triggering operation. Affected locations: (1) generator clear_scene() - delete_collection_hierarchy() + orphan cleanup, no depsgraph update before purge_orphans()/frame_all_views(); (2) addon Reset operator Steps 3-5 - bulk remove in a loop, no depsgraph fence before Step 6 scene property writes. Fix: add bpy.context.view_layer.depsgraph.update() after each bulk deletion block and before any operation that could trigger a viewport redraw. Also worth reporting to Blender bug tracker as a legitimate engine-level issue with scripted bulk deletion workflows. CONFIRMED 02 Jul 2026 by a full crash log from Miles (Blender 5.1.2, Windows): EXCEPTION_ACCESS_VIOLATION reading offset 0xB8 in DEG_iterator_objects_next -> DRW_cache_free_old_batches -> view3d_main_region_draw, immediately after Reset GAAD Platform reported 'Emptied 18 objects'. Two earlier resets the same session (123 and 59 objects) survived; the third crashed on a tiny scene - confirming a timing race, not an object-count problem, exactly as diagnosed above. Miles also reported general panel fragility around Generator <-> Navigator scene switching, which widens the same window (the incoming scene bulk-rebuilds while its draw cache is still warming). FIX SHIPPED in gaad_rebirth_addon_v0_66.py (bundle 0_107), awaiting retest: (1) _gaad_safe_state() deselects everything and clears the active object in every scene before any bulk-destructive work, so the draw manager holds no references into objects about to be removed; (2) Reset's three per-object removal loops replaced by single atomic bpy.data.batch_remove() sweeps - one for objects, one for the mesh datablocks and GAAD materials orphaned by the removal (these previously accumulated forever); (3) _gaad_settle() runs view_layer.update() on all scenes plus a tagged 3D-viewport redraw before the operator returns, so the depsgraph is coherent before the next draw instead of racing it; (4) _run_script() brackets every generator/tree/report run with the same safe-state/settle pair, protecting the generator's previous-generation purge and the tree's Navigator rebuild without modifying those scripts; (5) scene-switch operators (gaad.generate, gaad.back_to_generation) settle the incoming scene's depsgraph immediately after context.window.scene changes. Reset logic verified by out-of-Blender dry-run: protected objects kept, strays and Navigator objects gathered into one sweep, shared materials never removed, selection/active cleared first, depsgraph settled after. Status stays open until Miles's in-Blender retest (repeat resets, scene switching, generations at 3x3 and 5x5) passes. STATUS NOTE 03 Jul 2026: multiple long sessions through bundles 0_108-0_110 (13+ generations, repeated resets and scene switches during panel UX testing) with no crash reported since the v0_66/v0_67 fixes - an encouraging signal, but the explicit hammer-test verdict from Miles (repeat resets, aggressive Generator <-> Navigator switching, 3x3 and 5x5 and 9x9 generations) remains outstanding before this closes. Tracked in CURRENT_ACTIONS.md.

ARAL left a dead strip at the front of the stage

Objects never placed in a 24 m band at the front of the ARAL stage. Not random - the LABEL_RESERVE, inherited as-built from generator v0_56: Y placement ran to +32.5 at the back but only -18.5 at the front, reserving room for labels ARAL does not draw.

Mutate xN - first generations burst, and Stop could not be clicked

Two faults in one runner. (1) The first five or so generations of a Mutate xN run fired back-to-back before the pace settled: the modal stepped on every TIMER event, so queued ticks from busy frames each produced a generation. (2) The red STOP banner and the tape-deck Stop were visible but unclickable mid-run: the modal returned RUNNING_MODAL for every event, which swallows mouse clicks, so the kill switch built in v1_016 and v1_017 could not be reached by mouse at all.

ARAL version collision - two different files are called v1_018

Two different aral_prototype_v1_018.py files exist. The real one, cut into bundle 0_134, is the honest placed/skipped status readout. The second, built in the session of 14 Jul (second session), is the pyramid activation - it was written on top of aral_prototype_v1_017, which was what sat in Miles's working folder, because v1_018 had been cut to Live but never saved back to Working. The mismatch WAS flagged at arrival that morning and not chased before building, which is the process failure worth recording. Consequences: (1) the number v1_018 is ambiguous - one file is in Live/Prototype, the other went to 2_Working/Code/Superseded; (2) the live chain (v1_018 pyramid -> v1_019 tape -> v1_020 refinements) does not carry the placed/skipped readout, so that behaviour is absent from the current prototype - captured separately as D169. Nothing is lost: the underlying rolled/skipped data is computed in both chains; only the readout and the numbering diverge.

ARAL mutation flipped shape type even with 'Allow Mutation to Other Types' unchecked

Miles tested v1_009 in Blender: 4 spheres, 'Allow Mutation to Other Types' UNCHECKED, ran Mutate - one sphere became a cube. Root cause: the unchecked branch built a pool of active shapes other than the current one and switched to it, so with two active types (cube+sphere) a sphere could flip to cube. 'Unchecked' meant 'only among active types', not 'frozen', contradicting the label. Fix (aral_prototype_v1_010): shape type only changes when the box is TICKED; unticked freezes shape entirely. Also changed the box to default unchecked (Miles's call). Shape Switch % now only applies when ticked. A real bug (unlike T024). Awaiting Miles test to confirm and close.

TWAL has no language file - readiness level cannot be read from source

TWAL is graduated and Live (T7, D158) with a connector (twal_connector_v1_001.py) and prototype (twal_prototype_v1_001.py) in the bundle, but it has NO GALF-conforming language file (.json) in Languages/. The other five languages (PRAL, GRAL, FWAL, MHAL, ARAL) each have one. Consequence: when the readiness_level field was added to the language files (13 Jul), TWAL could not receive it from a file, so the Architecture page carries TWAL's T7 explicitly rather than reading it from source - the one language whose ladder position is not file-backed. Fix: write a proper TWAL language file (gaad_twal_v1_001.json) conforming to GALF, carrying identity + readiness_level like its peers, so all six are uniform and the page reads all six from source. Deferred to the full-bundle session (Miles, 13 Jul, ~21:15) so tonight's website zip is not blocked.

ARAL Generate/Clear does not sweep stray non-ARAL objects left on stage

After Generate ARAL (Sphere, Collisions 1994), the stage shows the new spheres PLUS red angular cubes left over from a previous run (2.4 growth-generator objects). Miles confirmed in Blender (19:28, 13 Jul): (1) the red pieces are leftovers from a prior run, not created fresh by this Generate; (2) Clear ARAL does NOT remove them; (3) their count does NOT grow across repeated Generates. So this is a SWEEP GAP, not a generation fault or a duplicator: the ARAL rebuild plants new form without sweeping what is already on stage, and Clear ARAL's removal set does not cover this object family. Evidence: screenshot aral_prototype_v1_005, panel Sphere / gravity ON / Collisions 1994. Note: v1_005's own header claims a stray non-ARAL Cube is removed on every Generate - so the intended sweep exists but misses these objects.

Navigator button does not switch scenes against v0_46 lineage data

Found by Miles during 0_123 storage-layer testing (Gen 10, 3x3, addon v0_93 + generator v0_46): pressing Navigator did nothing - no scene switch. Root cause: tree v0_7's build_lineage only discovered the legacy G###/G###.json folders; generator v0_46 writes flat sN_gNN.json + lineage.json (D132), so the lineage came back empty and the script returned BEFORE get_fresh_tree_scene() ran - the Navigator scene was never created or shown, making the button appear dead. Known-interplay risk was flagged at the 0_123 cut ('Navigator will not render new-scheme runs'); in practice the failure was harder than render-nothing - the switch itself died.

Rapid Stage Select stops firing after a Navigator visit or Reset GAAD Platform

During the first F022 test session (addon v0_79) Miles broke Rapid Stage Select: after going to the Navigator or running Reset GAAD Platform (he was not certain which), clicking stage objects no longer bred. Prime suspects: (a) Blender clears bpy.msgbus subscriptions on undo/redo, and heavy operators can push undo steps; (b) the re-entry busy flag could be left set if a fire path is interrupted; (c) Reset rebuilds enough scene state that the watcher or its guards no longer see a valid pick. The v0_79 watcher only re-arms on file load. Fix direction for v0_80: re-arm the msgbus subscription on undo_post/redo_post, on the toggle being switched ON (property update callback), and after Reset; time-out the busy flag so it can never wedge; reproduce Miles's Navigator and Reset paths to confirm which one kills it. UPDATE 06 Jul 2026: hardening BUILT in addon v0_91 (D125). One shared _gaad_rapid_rearm() (clears busy, re-subscribes) now runs on undo_post / redo_post, at the end of Reset GAAD Platform, on file load, and when the toggle is switched ON; the busy flag is timestamped and self-clears after a 2 s timeout so it can never wedge. Statically validated (py_compile + gaad_validate). Status kept OPEN pending Miles's runtime confirmation in real Blender - the chat sandbox cannot run Blender - specifically the repro paths: Navigator visit, Reset, and Ctrl+Z, with Rapid ON.

Next Generation slow at 9x9 (~9s)

Miles reported ~9 seconds per Next Generation at 9x9 (81 stages, ~1,544 design objects) during Blender testing. Root cause: per-stage bpy.ops - the stage surface (primitive_cube_add + transform_apply) and the stage label (text_add) - each forced a full scene re-evaluation, ~240+ ops at 9x9 on a growing scene (quadratic). Fixes: stage labels moved off the generation path to an on-demand panel action (D115, generator v0_36), which alone brought it to ~4s (Miles confirmed); then the stage surface converted to from_pydata (D116, generator v0_38) to remove the last per-stage ops.

Generator silently degraded 6x6..9x9 grids to 3x3

Found while implementing Miles's stage-size preview request, before it ever bit in use: the panel (addon v0_68) offers grids up to 9x9, but the generator's _grid_size() validated n in (2, 3, 4, 5) and silently fell back to 3 for anything larger - an Initial Generation at 9x9 would have built a 3x3 with no error. Root cause: the validation list was written when the panel maxed at 5x5 (D081 era) and was not widened when the enum grew. Resolution (generator v0_35): accepts 2 <= n <= 9. Lesson for the records: when a producer widens a range, grep for the consumers' validation - same class of miss as T009 (a consumer overlooked when a producer changed).

STATUS object count shows 0 with joined variants (v0_33+)

Found by Miles in the same 0_107 test: STATUS read 'Gen 1 | 5x5 | v0_66 | v0_33 | 0' on a fully populated world. The count summed per-object gaad_shape_type properties, which existed on v0_32's one-object-per-primitive build but not on v0_33's joined variants (they carry gaad_object_count and gaad_shape_types instead - a consumer of the old per-object properties missed in the D106 parity check). Resolution (addon v0_67): the count now sums gaad_object_count across variant objects plus the legacy per-primitive count, so old and new scenes both read correctly.

v0_66 regression: Next Generation always reports 'No Stage selected'

Found by Miles testing 0_107 on a 5x5 world: select any stage object, press Next Generation, get 'No Stage selected'. Root cause: the v0_66 T006 fix (_gaad_safe_state) deselects everything and clears the active object before running the generator - but the generator located the champion by reading the live selection (bpy.context.active_object / selected_objects), which had just been wiped. A regression introduced by the crash fix. Resolution (addon v0_67 + generator v0_34): champion identity now travels as DATA, not a live pointer - gaad.generate snapshots the picked Stage's gaad_variant_id / gaad_stage_number into scene properties before the selection wipe; the generator prefers live selection (manual Text-editor runs unchanged) and falls back to the snapshot, consuming and clearing it one-shot so a stale pick is never silently reused. T006 protection fully preserved: nothing stays selected or active through the purge. Verified by out-of-Blender simulation: wipe -> snapshot resolves the champion; no-pick path clears stale snapshots and shows the normal guidance.

Scene rename to 'GAAD Navigator' is only half-applied across addon and README

The lineage-scene rename to 'GAAD Navigator' (D101) is applied inconsistently. gaad_rebirth_addon_v0_64.py contains BOTH 'GAAD Navigator' (11 occurrences) and 'GAAD Design Evolution' / 'Design Evolution' (12 occurrences), so the same scene is labelled two different ways in the UI and HUD. README.txt still describes the scene and its HUD as 'Design Evolution'. In bundle 0_104 the technical spec JSON was corrected to 'GAAD Navigator', which now disagrees with the addon and README. Fix: agree the single canonical name, then apply it consistently across the addon (scene name, HUD text, panel labels), README.txt, and any report scripts, and re-verify in Blender that both scenes read correctly.

Reset GAAD Platform should delete Generations folder contents

When Reset GAAD Platform is pressed, the files and folders inside the \Generations directory are not cleared. Old generation JSON and replay data from the previous run persist on disk, so a new design run inherits stale data. Reset should delete all files and subfolders within Generations\ so the next Create First Generation starts clean on disk as well as in the scene.

18 Stages bug — stage count doubles after Reset + Create First Generation

After Reset GAAD Platform followed by Create First Generation, the HUD showed 18 Stages instead of 9. Root cause: Reset moves Surface objects to the scene root collection so they remain visible after clearing. When the generator's clear_scene() runs, it only removes the GAAD_World collection hierarchy — the orphaned root-level Surfaces survive, and 9 new Surfaces are created on top, doubling the count.

Variant ID labels (e.g. G021_S006) not legible at working camera angles

The per-stage variant ID labels (format Gxxx_Sxxx) are effectively invisible at typical working zoom/angle - same family of problem as the title panel: small flat text on the stage surface, foreshortened and low-contrast (especially on the gold champion stage and pale neutral stages). Fix: raise contrast and likely give the labels a small raised/extruded treatment, or reposition, so they read at a glance. Bundle with T002.

Title panel reads 'AutoCAD retro' - rework to a modern wordmark

The ground title panel (GAAD + version + Generation N) looks dated: thin green outline-style text on a pale grey slab, reading like a 1990s CAD label. Causes: outline-y green text rather than a solid fill; flat pale slab with no presence; green no longer the brand colour now the champion is gold (D042). Proposed direction (to confirm): solid GOLD 'GAAD' wordmark echoing the champion, on a dark Deep-Teal plinth, with version + Generation lines in a quieter off-white. Bundle with T003 as one text-legibility / title pass.

Title panel blocked Next Generation - world would not advance