Design Memory PlatformSTATUS section changed from a multi-line label block to a single compact pipe-separated line: "Gen N | NxN | v_addon | v_generator | object_count". Dots shown for any segment not yet known (before Gen 1: "... | ... | v_addon | ..."). Always visible, not collapsible. Object count formatted with thousands separator.
The CONFIGURATION panel section (script versions, last release) renamed to SETTINGS throughout the addon (draw, register, unregister).
CREATE section rebuilt with five items in order: Initial Generation (renamed from Create First Generation; greyed out after Gen 1), Next Generation (renamed from Create Next Generation, then Start Generation), a separator, Generator (renamed from Design Generator, moved from EXPLORE), Navigator (renamed from Design Tree, moved from EXPLORE), a separator, and Report (renamed from Design Evolution Report, moved from KNOWLEDGE; now runs the report script and opens the HTML in one click).
EXPLORE section renamed to VIEW. Buttons simplified: "3D View" to "3D", "Plan View" to "Plan", "Stage Isolator" to "Stage". New "Perspective" button added below "3D" (see D095).
New operator gaad.perspective_view added: eye-level perspective view of the stage grid, 82 degree tilt, distance 250. Button "Perspective" sits below "3D" in the VIEW section.
Generator writes gaad_stage_size_m and gaad_stage_gutter_m to the scene as custom properties immediately after building the world. Addon reads these properties for display rather than hardcoding the values.
New script gaad_static_check.py added to Scripts/. Checks: blend file present, expected folders present, expected scripts present, expected records present, four-point addon version match, em dash scan, expected panel labels present, expected operators present, HTML records well-formed. Writes a branded gaad_test_report.html to Reports/ and opens it automatically. New operator gaad.run_test and "Test Script" button added to TOOLS.
GAAD confirmed as the underlying platform: one breeding engine, one Records system, one panel, one HUD, shared across all Architectural Languages. Object Collection becomes a language selector (MAL, HAL, GRAL, and future languages) followed by primitives specific to that language. The existing Cube/Pyramid/Dome/Wedge/Cylinder set remains the generic GAAD default for now; formal reclassification as MAL primitives is deferred to a future decision.
New DESIGN LANGUAGE section added to the panel between CREATE and MUTATION, implementing D098. Mutually exclusive selector (single EnumProperty, gaad_design_language) offering Garden Room, Manhattan and Primitives; default Primitives. Garden Room and Manhattan are selectable now but show "Not yet built - no parameters available" since neither language has primitives or generation logic yet. MUTATION section is gated on the selection: shows the existing five sliders only when Primitives is active, otherwise shows "No parameters yet". CREATE buttons remain active regardless of language selected, so the user is never blocked, only informed.
The GAAD panel structure is frozen at v1_0 (GAAD panel mock-up v1_0) and adopted as the locked blueprint of record. The real addon (gaad_rebirth_addon_v0_63) is restructured to match it: STATUS, CREATE, DESIGN LANGUAGE with a Current Design Language selector and seven sub-sections (Getting Started, Knowledge, Objects, Parameters, Evolution Rules, Seed, Initial State), VIEW, DEVELOPMENT, SETTINGS, TOOLS, plus Integrity Check and Collapse Panel at the bottom of GAAD Lab. Where a leaf is not yet functional it is shown wrapped in angle brackets. OBJECT COLLECTION folds into Objects and MUTATION folds into Evolution Rules. A Technical Specification index (gaad_technical_spec) is added under DEVELOPMENT. This milestone bundle jumps to GAAD Development 0_100 to mark its significance. The frozen mock-up is kept as a separate Spec artifact and is never folded into the addon chain.
Several refinements built on the v1_0 spec (bundle 0_101, addon v0_64). Objects and Evolution Rules stay visible after Initial Generation but are greyed out so the run's settings remain inspectable. The GAAD Studio panel is added at the same level as GAAD Lab (CREATE: Initial Generation + Next Generation; VIEW: 3D/Perspective/Plan/Stage; Reset GAAD Platform at the bottom). Collapse Panel is split into Collapse All and Collapse Sections. The tree scene is renamed from 'GAAD Design Evolution' to 'GAAD Navigator' across generator, tree and addon; the HUD titles change to 'Navigator' and 'Generator'; and the report becomes the 'Navigator Report' with GAAD-branded HTML.
The naming of MAL (Manhattan Architectural Language), HAL (House Architectural Language) and GRAL (Garden Room Architectural Language) revealed that GAAD was never just about abstract primitives - it was building a grammar. Object Collection becomes the place where that grammar is selected: the same genetic engine, the same breeding logic, the same Records, expressed through different vocabularies of form. GAAD stops being a single design tool and becomes a platform for architectural languages.
After many iterations and a critical architectural review, the GAAD panel was frozen as the v1_0 spec and built into the real addon (v0_63). To mark the significance, the bundle was advanced to GAAD Development 0_100, and a Technical Specification index was created to map the platform's technical truth across its existing records.
GAAD will not begin by training an AI model. It will first capture structured design knowledge: generations, selections, rejected alternatives, reasons, parameters, context and outcomes. These records become language references for future learning.
Investigate geometry nodes as the object-creation method for HAL and GRAL primitives (and any future Architectural Language), as an alternative to the direct mesh construction the GAAD generator uses from v0_33 (D106: raw vertex/face data joined per variant; before v0_33 primitives were individual bpy.ops objects, with only the dome using bmesh). Evaluated for new languages only; not a retrofit of the existing five GAAD primitives. TRADITIONAL BLENDER MESH (direct mesh/bmesh data) - current GAAD/MAL approach (v0_33, D106). Pros: simple and proven, already working at 9 to 81 stages; since v0_33 primitives are joined into one mesh per variant so object count stays flat as worlds scale (D106); triangle count, vertex count and bounding box are read directly from the mesh with no extra evaluation step; easy to score after the fact by measuring the finished geometry; no Blender version compatibility risk, since mesh/bmesh APIs are stable across versions. Cons: mutation means modifying the mesh directly (move verts, scale, rebuild), which is more code per shape; each shape variant is effectively hand-built logic in the generator; there is no single source of 'the design's parameters' - height, width and similar values must be inferred back out of geometry after building it rather than read directly. GEOMETRY NODES - candidate approach for new languages. Pros: the object's defining parameters live as readable, mutable input sockets (height, footprint, roof pitch), so they are first-class data rather than inferred from a finished mesh; one node graph can express many variants (a single Garden Room graph can become small or large, flat or pitched roof) rather than needing a discrete primitive type per variant; mutation becomes read parameter, mutate value, re-evaluate, which is closer to genuine genetic breeding than mesh editing, and aligns with D038 scoring since parameters can be scored directly without reverse-engineering geometry. Cons: heavier to evaluate at scale - untested whether 81 stages of evaluated geo-node objects stays performant; triangle and vertex counts require evaluating the dependency graph (object.evaluated_get(depsgraph)) rather than reading raw mesh data directly, which is slightly more code and slightly slower per object; more fragile across Blender versions, since geometry node socket APIs have shifted noticeably between 3.x and 4.x releases; steeper authoring cost, since building the node graph itself is more work than writing a bmesh primitive function. Summary: geometry nodes wins on parameter legibility for D038 scoring (clean, directly readable inputs); traditional objects win on measurement simplicity (trivial triangle/vertex counts, no depsgraph evaluation needed). Both are scoreable under D038; they expose different things easily.