Tickets

The bloom warning was hidden with the box it lived in, at phone width

Raised on 29 July from the bench's own flag, which named it the collapse and bloom warning. CORRECTED THE SAME DAY, and the correction is this seat's error to own. The bench challenged the wording and it was verified against the file rather than taken on trust: there is exactly ONE warning path in this host, a Phyllotaxis check comparing the bloom's outer radius against the reach of its own roll window, and no collapse warning has ever existed here. The collapse warning is a Blender v3_042 feature. The wording came from a stale comment inside the bench's own file, and this seat repeated it without checking the code beneath it. The real fault was narrower and real: the warn line lived inside the Generate box, the phone hid that whole box, so a Phyllotaxis form spilling past its roll window gave no notice in portrait. FIXED in GLAS-web V1_05, which keeps the warn line on a phone while heading, buttons and status stay gone. ALSO CORRECTED: the screenshot cited as evidence was not a degenerate form. Phyllotaxis at Rise 0 is a sunflower head, which is what the Sunflower preset is. Computed independently from the file's own roll window: at 500 points and radius 2 the outer radius is 44.7 m against a threshold of 141.3 m, so the warning was right not to fire and a notice there would have been a false positive.

Superseded language files sit indexed by Google as orphans

Google Search Console shows 20 indexed pages, and among them are superseded language versions - GRAL v0_021 AND v0_022 both indexed, for one. Seven old language files sit on the server with ZERO inbound links, each shadowed by a current version that IS linked: GRAL v0_021 (now v0_022), ARAL v0_001 (v0_002), FWAL v0_008 (v0_009), GALF contract v0_007 (v0_008), MHAL v0_006 (v0_007), PRAL v0_002 (v0_003), TWAL v1_000 (v1_001). They were kept OUT of the sitemap deliberately (one page per language), but Google found them by crawling before that rule existed and holds them until it notices they are orphaned. The effect is stale versions competing with the live ones in search - a visitor could land on an old language definition. SAME CLASS AND SAME FIX as D201's record pages (T036's sibling): a small generator writes each superseded file as a hash-preserving noindex redirect to its current version, so the old URL still resolves, the index consolidates on the live page, and a records/language sync cannot quietly restore the full old page. The bundle's Superseded folders keep the true old content as history, so nothing is lost. NOTE: the current language files must NOT be redirected - only the superseded ones; the pairing is by language stem and highest version. GALF v0_008 has 8 inbound links and stays; only v0_007 redirects.

A correct publish can still read stale: the browser serves a cached Records Hub

Miles posted publish 1_057, clicked the 27 Jul decisions dot on the homepage graph and the Hub answered 0 Decisions on 2026-07-27. The file was right: the Hub inside the zip carried 209 decisions, head D213 and sixteen rows dated 27 Jul, and the deep-link code was verified sound (it reads the date cell, converts 27 Jul 2026 to 2026-07-27, and caps no rows). What the browser served was an older copy showing Decisions 204 and All 548, the 25 July state. Loading the same URL with a version query proved it in one move - the counts came back correct - and a hard refresh cleared it. WHY THIS FILE: records/gaad_records.html is about 1.6 MB, its name never changes, and it changes on nearly every publish, so it is the page a browser is most likely to hold and the page most damaged by holding it. The graph dots and the six stat cards now all point INTO it (D201), so one cached file makes the whole record surface look wrong to a reader while the server is correct. CONSEQUENCE WORTH NAMING: this is a class of defect the checker cannot see. gaad_web_check proves the tree is right before the zip is cut; it says nothing about what a reader's browser then serves, so a publish can pass every check and still read stale. PROPOSED FIX, not yet ruled: the generators that write links into the Hub (build_records_graph.py for the dot deep-links, gaad_site_stats.py for the six stat cards) append a publish-version query, so a new cut busts the cache automatically and the hash still routes as it does today. Alternatives considered: cache headers at the host, which is outside the estate and outside the zip-and-extract deploy; and versioning the filename, which would break every deep link already posted. OPEN QUESTION for Miles: where the version number comes from, since the website publish number lives in WEBSITE_README.txt rather than in a field a generator reads.

Presets are not reconciled: the seed did not make the form, and the two hosts hold different values

Two faults in the preset system, both raised by the bench on 27 Jul and both needing Miles's word rather than a fix. FIRST, PROVENANCE: a genome saved from a preset records rng.seed from the last roll, which never made that form. The seed is provenance under D205 and parameters are authoritative, so the file still rebuilds correctly, but its provenance is a lie about where the form came from - and in a platform whose principle is that decisions become data, a recorded origin that never happened is worse than an absent one. The bench recommends a fixed seed per preset, as the Blender host already has. SECOND, DIVERGENCE: the two hosts' preset values have never matched - Tower 200 instances at Rise 0.45 against 500 at 0.12, Helix 150 against 400, Spire 300 against 400. Six names, six different forms, depending which host you opened. That is either a defect to reconcile or a deliberate difference to rule and record; it is not something to leave undecided, because a preset is the first thing a visitor presses and the two hosts are meant to agree.

The GAAD wordmark has no self-contained vector - both SVG masters import their font over the network

Brand/gaad_logo_wordmark.svg and Brand/gaad_logo_lockup.svg both open with <style>@import url('https://fonts.googleapis.com/css2?family=Space+Grotesk...IBM+Plex+Mono...')</style>, so the letterforms are LIVE TEXT resolved from a webfont at render time rather than drawn geometry. Neither file can therefore be used anywhere self-contained: inside a Claude artifact, inside the GLAS studio page (which build_studio.py FAILS on any off-page reference by design), or in any offline or embedded context. Where the font does not load, the wordmark silently renders in a fallback face, which is worse than not rendering at all because it looks like the brand while not being it. Raised independently by the Code Technician at the bench and by the Specification Owner on the same day: CT hit it building the PNG export, and the Specification Owner had proposed swapping the studio's embedded PNG for the SVG to save 7 KB, which would have shipped exactly this fault to the website. THE CONSEQUENCE TODAY is that the only usable GAAD wordmark is the 461x179 raster PNG, so every embedded use is fixed-resolution and soft on a high-DPI screen, and the estate has no scalable master it can actually ship. FIX: convert the wordmark's text to outlines and save that as the shippable vector, keeping the live-text version as the editable master; or embed the two faces as data URIs inside the SVG. Outlines are the smaller and more robust of the two and cannot ever silently substitute a face. Whichever is chosen, the same treatment is needed for the lockup, and Brand/gaad_logo_export.html should say which file is the shippable one so this cannot be rediscovered a third time.

The AFAL Language file path lives in the scene and evaporates in unsaved sessions

The Language file pointer is stored in the scene, so an unsaved session loses it and Export fails with 'no language file set - point Language file at gaad_afal_language_file' (the A0019 gate). It bit three times in one working session. The path is a tool setting, not scene data, so it should move to add-on preferences where it persists across sessions and files. It also bit once more by accepting the .html VIEW of the language file instead of the .json source, so the fix should add a *.json filter on the picker when the path moves to AddonPreferences. The web host has its own A0019-family catch-up: it still pins language.version to a constant string rather than reading it from the language file.

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. FOURTH DEFECT (26 Jul, Blender side): the AFAL Studio panel shows an inert gene slider as live - blue, draggable, value changing - while it does nothing (the Spiral/Twist gene on Phyllotaxis, unused by the law). The web preview already greys inert genes per species; the Blender panel does not. This is the Blender-side instance of this ticket's rule: its inverse - a dimmed gene must not silently bite, and a live-looking gene must not silently do nothing. Fix: per-species greying of inert gene sliders in the Blender panel, driven by the active-genes truth table, matching the web. Queued for v3_033. Note: the related over-invalidation bug (an inert-slider drag clearing genome identity) is NOT a T032 defect - it is the v3_032 correctness bug fixed under D209 by tying invalidation to active-gene edits. WEB Z-LAW RELAY (26 Jul, found while conforming the web preview): the preview carried an INVENTED Hyperboloid vertical law, z = u*radius*2.4, where the engine truth is z = index*Rise for every species. Fixed - the web now conforms and the canonical float64 evaluator is the single law in that host (D207). The Blender inert-slider instance above was VISIBLY confirmed fixed on the re-imported lineage child g-237c0b (per-species greying, same truth table as the genome writer). Both fixes shipped in the descent release. | RELAYS 5, 6 and 7 (27 Jul 2026, from the bench's fr2). FIFTH, on the web and the INVERSE of the usual case: DEF.active was a second hand-kept copy of the D206 active-gene table and had drifted for four of five species, dimming Taper on Spiral, Cone and Phyllotaxis and Twist on Shell, Cone and Hyperboloid, while the canonical evaluator reads both - so those sliders looked dead and were live, which is arguably worse than the reverse because a user never presses them and never learns the gene exists. Now derived from the one table. SIXTH, in Blender and the bench's own: the RNG Strength slider was wired but SILENT, read only inside create_specimen so it did nothing until the next Grow while the six gene sliders directly above it applied instantly. Found by Miles in the first host run - SPIN PASS, STRENGTH not working. SEVENTH, in Blender: planned species were given light-grey styling but kept a live button's raised gradient and lit top edge, so Miles duly pressed them; now sunk and flat. The bench's reading, which this seat shares, is that all three are one fault with the duplication defects beside them - a truth written down twice, or an appearance and a behaviour that disagree.

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