Tickets

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.

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