homemaker-layout/DESIGN.md

homemaker — Design & Plan

Status: validated direction, pre-implementation. Reviewed against the Urb source 2026-06-12; review findings folded in (see §4.5 evidence note, §4.6 throughput arithmetic, §5 decision 6, §6 port-scope expansion, §7 re-scoped phases, §8). Audience: a fresh session that will break this into bd (beads) tasks (note: no beads database exists yet — run bd init first). Self-contained — assumes no memory of the originating conversation.

---

1. Purpose

homemaker-layout is a clean-room Python successor to the Perl Urb project (/home/bruno/src/urb). Urb models a building as a binary slicing tree and evolves layouts with mutation + crossover, scored against Christopher Alexander–style pattern fitness. Two long-standing problems motivate the rewrite:

1. It doesn't scale — beyond a few rooms, evolution never finds layouts an architect would consider obvious.
2. Local minima — even small programmes converge to poor optima.

The eventual goal is a 100% Python system. During bring-up, Perl Urb is kept as a throwaway fitness oracle behind the .dom file format.

---

2. Constraints that fix the representation

These come from the problem domain and are not negotiable; importantly, they vindicate the slicing tree rather than argue against it:

• Multi-storey with stacked walls. An upper storey retains the storey below, except additional divisions/undivisions. Load-bearing walls must stack ⇒ every cut is a full edge-to-edge guillotine cut. Urb already enforces this via Below-inheritance (an upper quad reads its geometry from the matching quad below).
• Quadrilateral rooms only (no L/Z shapes) — recursive bisection produces exactly this.
• No pinwheel / non-slicing layouts — undesirable for load-bearing construction and adaptability (cf. Brand, How Buildings Learn). This is the one class a slicing tree can't express, and we don't want it anyway.
• Plots are near-rectangular but general convex quadrilaterals (not axis-aligned). Geometry must handle skew; the slicing combinatorics are unaffected.

Conclusion: the slicing tree is the correct phenotype. The rewrite is about the genotype, the search, and the fitness shape — not about leaving the slicing class.

---

3. What we built this session (all committed)

Package src/homemaker_layout/:

• dom.py — .dom YAML ⇄ Node tree. Linkage (parent/below/position), wall_outer inset on load with raw-corner stash for byte-perfect round-trip, emit.
• geometry.py — faithful port of Urb's top-down geometry (Coordinate/Coordinate_a/_b/Area/Length) + Coordinate_Offset wall inset. Memoised (uncached recursion is exponential in depth).
• programme.py — parse patterns.config spaces: into per-code size/width/proportion/adjacency/level/count requirements.
• solver.py — bottom-up division-ratio solver (scipy least_squares). (Outcome: falsified as a standalone component — see §4.2.)
• oracle.py — Phase-1 fitness bridge: write .dom, run urb-fitness.pl, parse .score + .fails.

Experiments in experiments/: dump_areas.{py,pl}, resolve_ratios.py, refine_sweep.py, sweep_failtypes.py, optimize_fullfitness.py.

---

4. Empirical findings (the core of this document)

4.1 Geometry port — VALIDATED

Per-leaf areas computed in Python are byte-identical to Urb across all 35 programme-house .dom files, including the wall inset and multi-storey wall-stacking inheritance. (experiments/dump_areas.{py,pl}.) The infrastructure is trustworthy.

4.2 Bottom-up area-proxy sizing solver — FALSIFIED

The original hypothesis: give leaves target sizes, solve cut ratios bottom-up, let the EA search only topology. Tested by re-solving an evolved candidate's ratios from programme targets and scoring via the oracle.

• resolve_ratios.py on candidate-002: areas recovered accurately (errors collapsed, e.g. t1/t2/t3 from +1.4/+2.4/+4.8 → ~+0.05), and it fixed the original's size failure — but total fitness dropped (0.00737 → 0.00065, 4 fails) because it introduced shape/relational failures.
• refine_sweep.py (warm-start refine of all 34 candidates): 0/34 improved. Total failures 124 → 297 (equal-offset cuts) and 124 → 626 (independent-offset cuts).
• sweep_failtypes.py (failure-type histogram, equal-offset):

  type	area-dominant Δ	shape-aware Δ
  width	+82	+29
  proportion	+35	+7
  crinkliness	+18	+4
  adjacency	+18	+13
  size	−15	+15
  access	+29	+39
  total added	+173	+110

Why it fails: in Urb's fitness, every cut position is simultaneously a size knob and an adjacency/access/shape knob. A solver that optimises only size/shape is blind to access/adjacency and trades them away. Refining a co-evolved local optimum with a partial objective is structurally unable to win, and the 0.5^n failure penalty makes every new failure catastrophic while fixes are only linear. The proxy solver is strictly worse than optimising real fitness. Do not pursue it.

4.3 "Perpendicular" failures were an artifact — RESOLVED

Letting the two ends of a cut float independently produced skewed cuts and many perpendicular failures. Tying the two ends (equal offset, a == b, one DOF per cut) produces near-perpendicular walls on these near-rectangular plots and yields zero perpendicular failures. Equal-offset cuts are the only mode to use. This also halves the variable count and matches the slicing model.

4.4 DOF / over-determination — partially real, not fatal

A topology with R rooms has ~R−1 cut DOF but ~2–3 size/shape constraints per room, so a fixed topology can be over-determined: you cannot always hit area + width + proportion for every room at once (heavy shape weighting traded straight into size, §4.2 table). This limits any single-objective sizing pass — but it is not fatal, because optimising the full objective still found large gains (§4.5). The earlier "infeasibility" worry was overstated.

4.5 Full-fitness frozen-topology optimisation — VALIDATED ✅

Drive the equal-offset ratios with Nelder-Mead against the real oracle fitness (whole objective, no proxy), topology frozen (experiments/optimize_fullfitness.py):

candidate	DOF	original	optimised	gain	fails
2f45907 (best evolved)	7	0.012617	0.015684	×1.24	2→2
candidate-002 (MCP-refined)	6	0.007375	0.012319	×1.67	2→2
c964435 (MCP baseline)	6	0.003667	0.005836	×1.59	3→3

Every design improved 24–67%, none added a failure. Headroom widens on weaker designs. Because the optimiser sees the whole objective (including the 0.5^n penalty), it never trades into a new failure — the cliff that destroys the proxy solver protects the full-objective optimiser.

Implications:

• There is large, unclaimed geometry headroom above every EA design — even the best. Urb's EA under-optimises geometry: source inspection confirms slide() (Mutate.pm:256-269) re-randomises the cut position uniformly across the span — Urb has no fine-tuning geometry operator at all, which fully explains the headroom.
• A full-objective geometry inner loop is genuinely valuable (the proxy solver is not).
• The EA/search should therefore own topology; geometry is delegated to the inner loop. This is the memetic architecture (§5).
• Corroboration for §4.3: Urb's own mutations use equal offsets (Divide($division, $division)) — equal-offset cuts match how every corpus design was generated.

4.6 Oracle throughput (measured)

urb-fitness.pl scores many .dom files per invocation, so the Perl startup (~0.65 s) amortises across a batch and cached fields (e.g. occlusion) persist. Measured on the 35-file corpus: 0.99 s/dom batched vs 1.65 s/dom for a single-file call. The cost is assessment-dominated (~1 s/dom of actual work), so startup amortisation gives ~40% — useful but bounded.

Consequences:

• Batching only helps when evaluations are submitted together — favour population/parallel-evaluating optimisers (CMA-ES, differential evolution, island EA, pattern search) over inherently sequential ones (Nelder-Mead), both inner loop and outer search, so a whole generation scores in one oracle call.
• Do the arithmetic before scoping topology search on the oracle. §4.5 used ~200 inner evaluations per topology ⇒ ~3 min/topology at 1 s/dom. A run comparable to urb-evolve (pop 128 × 768 generations) is years of oracle time; even 32 topologies × 100 generations with a trimmed 50-eval inner loop is ~2 days. Therefore:
  • The oracle supports Phase 1 fully and Phase 2 only as a small-scale proof (tens of topologies, budgets counted in oracle calls).
  • A native Python fitness is effectively a gate for topology search at any real scale — not merely a later optimisation. (It also brings independence, penalty reshaping, and large programmes.)
  • Warm-starting the inner loop from the parent's optimised ratios (Lamarckian inheritance, §5 decision 6) is the main lever for cutting the per-topology cost — with high-locality moves most cuts survive a mutation, so an order-of-magnitude reduction is plausible. Measure this in Phase 1.

4.7 Occlusion-disabled re-baseline (measured 2026-06-12)

With the §6 descope in place (URB_NO_OCCLUSION=1 patch in Urb), the corpus re-baseline (experiments/rebaseline_no_occlusion.py): all 35 scores change (mostly up, ×1.0–×1.24 — daylight terms pin to 1), exactly one failure-set change (458aa8b8 gains two crinkliness fails — expected mechanism: no shading discount on external wall area), batched oracle ~8% faster (0.92 s/dom). New inner-loop reference gains (deterministic seed, budget 400, accept_innerloop.py bars): 2f45907 0.01304→0.02128 (×1.63), candidate-002 0.00808→0.01373 (×1.70), c964435 0.00400→0.00674 (×1.68, fails 3→2); ~35 oracle calls per topology. All Phase-2+ work uses the flag; flag-off numbers above are historical.

4.8 The 0.5^n failure penalty is a first-order pathology

Multiplicative 0.5^n over failure count (a) makes the landscape a cliff (no gradient across the huge zero-feasibility region), (b) rewards fewer flags over better geometry (the original outscored better-sized solved designs purely on flag count), and (c) is representation-independent. Reshaping it (additive / soft / multi-objective Pareto) is a high-leverage change that helps Urb today and homemaker tomorrow.

4.9 Penalty reshaping decision: lexicographic outer search (measured 2026-06-14)

experiments/penalty_reshape.py, URB_NO_OCCLUSION=1, programme-house.

Inner-loop protection (nm_search, budget 80, 3 files × 3 seeds = 9 runs): All runs show n_fails ≤ x0_n_fails. 0/9 regressions. The 0.5^n cliff in the native fitness scalar is unchanged and continues to protect the inner loop.

Outer-search comparison (budget 3000, 3 seeds, seed = 2f45907):

scheme	seed	best	fails	note
lex	0	0.01781	2
lex	1	0.01793	2
lex	2	0.01785	2
scalar	0	0.01781	2	(same outcome)
scalar	1	0.01890	3	trapped by high-score 3-fail design
scalar	2	0.02632	2	(different topology path)

lex mean: 0.01786 / 2.00 fails. scalar mean: 0.02101 / 2.33 fails.

Key result (seed 1): scalar promoted a 3-fail design whose raw score (×0.125 penalty) beat the pool's 2-fail candidates — exactly the §4.8 pathology. Lexicographic comparison (-n_fails first, then fitness) is immune: any 2-fail design beats any 3-fail design regardless of raw score. Within a homogeneous fail tier both schemes are identical (seeds 0 and 2 agree in serendipitous runs where scalar also stays in the 2-fail tier).

Decision: lexicographic. 0.5^n stays in the fitness scalar (inner loop unchanged). Outer search uses (-n_fails, fitness) as comparison key.

4.10 Deceptive level-fix valley and compound operators (measured 2026-06-14/15)

Context: programme-house, Phase 3 native fitness + Phase 4 lex search, seed warmstart-2f4.dom (best Phase-3 result, 2 fails at score 0.032). Goal: reach ≤ 1 fail, beating the Perl optimiser (2–3 fails).

The deceptive valley. The 2-fail state has l1 (living room, min 27 m², required level 0) on level 1. The obvious repair is level_fix: swap l1 with a leaf on level 0. But every single-step level_fix move creates 5+ new fails because the displaced room (t3, the WC) is dropped into an arbitrary slot that violates adjacency, size, and access constraints simultaneously. The lex comparator (-n_fails, fitness) correctly rejects these — but the result is that the 2-fail state appears completely surrounded by ≥ 5-fail states, and the search stalls. This is a textbook deceptive valley: the fitness gradient points away from the global optimum.

Compound operator. mutate_level_compound_fix (added operators.py) escapes the valley by doing two things atomically:

1. Move l1 to level 0 by swapping it with the largest leaf there (the circulation C node, because C is generic and can absorb the swap without producing a new structural failure).
2. Re-insert the displaced t3 by dividing the sibling of that C node (so t3 lands adjacent to C, satisfying the adjacency requirement).

The new split gets division=[0.25,0.25] (giving t3 ≈ 3.4 m², barely in range) and rotation=0 (t3 on the left, adjacent to the C sibling).

The warm_x0 initialization bug. The compound operator sets specific ratios on a newly-created split node. But driver.py was initialising the NM inner loop from parent.ratios, which has no entry for the new node (it was a leaf). warm_x0 defaulted the new node to 0.5, giving t3 ≈ 6.8 m² — a size fail — so NM started at 3 fails instead of 1. Lex then always rejected the compound child; level_compound_fix was completely invisible to the outer search for ~12 000 evals (until warm_x0 was fixed).

The correct fix distinguishes genuinely-new split nodes from stale hidden nodes that become visible after structural mutations (e.g. swap can flip a b.below pointer, revealing pre-writeback division values from a different topology). Only use the child's explicit ratio for node (li, path) if the matching node in the parent was not already divided; everything else falls through to parent.ratios or defaults to 0.5. Fix in driver.py lines 259–267.

Results (50 000 evals each, pop 8, child_budget 80, 4 workers):

seed	event	eval	fails	score
warmstart-2f4	seed	200	2	0.032
warmstart-2f4	level_compound_fix fires	12 280	1	0.000122
warmstart-2f4	level_retype 0/ll<->1/l	17 880	1	0.00497
warmstart-2f4	final	50 040	1	0.00518
compound3-raw	seed (1-fail hand-built)	200	1	0.000118
compound3-raw	level_retype 0/ll<->1/l	18 360	1	0.00383
compound3-raw	final	50 040	1	0.00523

Perl optimiser reference: 2–3 fails.

The two-C topology breakthrough. After level_compound_fix fires, the topology is: level 0 = ll(l1), lr(t2), rl(C), rrl(t3), rrr(O) — but now l1 is at level 0 (correct) and t3 is adjacent to rl(C) (staircase). However l1 is occupying ll, and rl(C) is the staircase core — so t3-adj-C is satisfied via rl, but there is no second C to satisfy staircase independently. Score ≈ 0.000157 (1 fail).

At eval ≈ 18 000, level_retype 0/ll<->1/l (swap the type of ll on level 0 with l on level 1) creates a TWO-C configuration at level 0: ll(C), lr(t2), rl(C), rrl(t3), rrr(O), with l1 moving to level 1. The score jumps 25× to ≈ 0.005. Why two C nodes work:

• ll(C) (bottom-left, 23 m²) satisfies t3-adj-C via geometric contact at the l/r zone boundary with rrl(t3).
• rl(C) (top-right, 8.5 m²) satisfies staircase adjacency via tree adjacency to rrr(O) (its right sibling when r.rotation=3).

Both constraints are simultaneously met because binary-tree sibling adjacency and cross-zone geometric adjacency provide independent paths.

Why 0 fails is geometrically impossible on this programme + plot. l1 needs min 27 m² at level 0. The only space large enough is ll (≈ 23 m², the entire left half of level 0). Putting l1 at ll removes the t3-adj-C provider. The alternative — dividing ll into lll(l1)+llr(C) — gives llr a proportion of ≈ 6:1 (width ≈ 0.73 m), failing both the proportion and width constraints. 0 fails is not achievable on this programme+plot with a binary slicing tree representation; 1 fail is the geometric optimum.

---

5. Validated architecture

Memetic search, full objective throughout:

            ┌─────────────────────── topology search (OUTER) ───────────────────────┐
            │  genome = slicing topology + per-leaf type assignment + per-floor       │
            │           divide/undivide deltas (base floor is master)                 │
            │  operators = high-locality topology moves (see §6)                      │
            │                                                                          │
            │   for each proposed topology:                                            │
            │      ┌──────────── geometry inner loop ────────────┐                     │
            │      │ optimise equal-offset cut ratios (1 DOF/cut) │                     │
            │      │ against the FULL fitness (derivative-free /  │                     │
            │      │ gradient), to convergence                    │                     │
            │      └──────────────────────────────────────────────┘                    │
            │      score = best full-fitness over inner loop                            │
            └──────────────────────────────────────────────────────────────────────────┘
                                   fitness: NATIVE Python (fast), reshaped penalty

Key decisions, all evidence-backed:

1. Geometry = inner optimisation against full fitness (§4.5), not an area proxy (§4.2). Equal-offset cuts, one DOF per free branch (§4.3).
2. Search owns topology only. The base-floor tree is the primary genome; per-floor deltas are a small secondary genome (multi-storey constraint as a regulariser, via Below-inheritance).
3. Prefer population/batch-evaluating optimisers so the batched oracle is efficient (§4.6). A native Python fitness (faithful to Urb, validated against the oracle on the 35-file corpus) gates topology search at scale (§4.6 arithmetic); the oracle suffices for the inner loop and a small-scale topology-search proof only.
4. Reshape the failure penalty (§4.8) — additive/soft or multi-objective — so the search has a gradient and isn't dominated by flag-count. Caution: the 0.5^n cliff is what protects the inner loop from trading into new failures (§4.5); reshaping must not lose that property. Candidate resolutions: keep the cliff inside the inner loop only, lexicographic ordering (failure count first, score second), or genuine multi-objective Pareto. Decide in Phase 4 with measurements.
5. Representation upgrade (later): canonical slicing encoding (normalized Polish expression / skewed slicing tree, Wong–Liu) for redundancy-free, high-locality topology moves; bottom-up shape feasibility checks. Defer until the inner loop + native fitness are in place.
6. Lamarckian geometry inheritance. A child topology's inner loop warm-starts from the parent's optimised ratios (cuts that survive the topology move keep their values; new cuts get heuristic defaults). This is the main cost lever for the memetic loop (§4.6) and a standard memetic design choice (Lamarckian vs Baldwinian — we write the optimised geometry back into the genome). Validate the warm-vs-cold speedup in Phase 1.

What we are not doing: the bottom-up area-proxy solver; independent-offset cuts; non-slicing representations (sequence-pair/B*-tree — excluded by §2).

---

6. Component plan

component	status	notes
dom.py (I/O + linkage)	✅ done	round-trips byte-perfect; keep
geometry.py (port + cache)	✅ done, validated	the trusted geometry kernel
programme.py	✅ done	extend as fitness needs grow
oracle.py (Perl bridge)	✅ done	throwaway; the validation reference
solver.py (area proxy)	⚠️ keep as artifact	falsified; do not build on it
geometry inner loop	❌ to build	full-objective ratio optimiser (DOF = free branches); batch/population so the oracle batches; warm-start support (§5.6)
topology genome + operators	❌ to build	base tree + per-floor deltas; high-locality moves
search driver	❌ to build	memetic EA / SA over topology; small-scale on oracle, full-scale needs native fitness
native fitness	❌ to build	gates topology search at scale (§4.6); port + validate vs oracle; scope is larger than the term list — see below
penalty reshaping	❌ to design	additive/soft or multi-objective; must preserve inner-loop cliff protection (§5.4)
canonical encoding (Polish expr.)	❌ later	representation upgrade once core lands

Urb fitness terms the native port must reproduce (all couple to geometry): size, width, proportion, adjacency, access/inaccessible, crinkliness, perpendicular, level, staircase volume/count, public access, circulation & outside ratios, min internal area. Source of truth: /home/bruno/src/urb/lib/Urb/Dom/Fitness/ProgrammeDriven.pm and the Storey/ Building/Leaf/Base submodules.

Port scope beyond the term list (found by source review — budget for these):

• Daylight + occlusion subsystem — DESCOPED (decision 2026-06-12). Occlusion is orthogonal to building a scalable optimiser. Instead of porting Urb::Misc::Sun/Urb::Field::Occlusion/CIESky, disable it in Urb behind an env flag (quality_daylight → 1 everywhere; Crinkliness/Area_Outside pins the CIEsky_vertical illumination factor to 1 — simple crinkliness = unweighted external wall area / floor area). The boundary-overlap geometry (Dom->Walls) stays in scope; the sky model does not. The native fitness ports simple crinkliness only; a Python occlusion subsystem is rebuilt post-Phase-5 once optimisation is fully native. Flipping the flag changes every score — re-baseline the corpus, the §4.5 table, and gate bars at one clean boundary, and run the Phase-2 urb-evolve benchmark under the same flag.
• The cost denominator. Fitness is value/cost: per-leaf area costs, interior/exterior wall edge costs, boundary costs (Leaf.pm:194-251, Storey.pm:122-147). Cost couples to geometry too.
• Structural failures not in the term list: "edge too long" (>8 m, two variants), "unsupported covered outside", "covered outside above ground", "level N not connected".
• Missing-space failure stacking (ProgrammeDriven.pm:192-212): a missing space generates 2 base failures plus one per size/width/proportion/adjacency/ level requirement — up to ~7 failures. Penalty reshaping (Phase 4) must preserve this hierarchy or the search will happily drop rooms.
• Two-phase graph build: adjacency/level/vertical checks run on the unmerged tree; graphs are rebuilt after Merge_Divided for storey processing (ProgrammeDriven.pm:83-103). Easy to get subtly wrong; the 35-file validation gate will catch it, but anticipate it.
• Known stub to decide on (fidelity-vs-fix, §8.1): has_vertical_connection (ProgrammeDriven.pm:399-423) matches any leaf of the target type anywhere on the level below — no spatial-overlap check. A faithful port reproduces the bug; decide explicitly.

---

7. Phased roadmap

• Phase 0 — diagnostics (done): geometry port validated; proxy solver falsified; full-fitness geometry headroom validated; oracle throughput measured (~1 s/dom batched).

• Phase 1 — geometry inner loop (on batched oracle): full-objective ratio optimiser; use a population/batch optimiser so a generation scores in one oracle call. Reproduce/exceed the §4.5 gains. Integrate as optimise(topology, x0=None) -> (geometry, fitness). Two cheap experiments belong here: (a) warm-vs-cold start — quantify the §5.6 speedup; (b) optimiser bake-off — DOF is only ≈ rooms−1, so batched multi-start pattern search may beat CMA-ES on simplicity; measure, don't commit blind. Gate: match §4.5 gains at materially lower oracle-call budget.

• Phase 2 — topology search, small-scale proof (on batched oracle): base-tree + per-floor-delta genome, high-locality operators, memetic driver wrapping the Phase-1 inner loop. Explicitly small (§4.6 arithmetic): tens of topologies, budgets counted in oracle evaluations, not generations. Compare against urb-evolve from the same seeds/programmes at equal oracle-call budget (urb-evolve has diversity injection/culling baked in, so generations are not comparable). Gate: memetic loop beats equal-budget urb-evolve. Scaling up waits for Phase 3.

  Gate result (homemaker-py-way, 2026-06-13, URB_NO_OCCLUSION=1, budget 2000): experiments/benchmark_vs_urbevolve.py; urb-evolve scores unchanged, memetic scores corrected (patterns.config missing from re-score cwd in first run, fixed in same session).

  seed	system	best@1000	final@2000	fails
  init.dom	memetic	8.84e-10	3.37e-09	18
  init.dom	urb-evolve p16	9.10e-06	9.36e-05	6
  init.dom	urb-evolve p128	4.83e-09	3.27e-05	6
  c964435	memetic	7.65e-03	7.65e-03	2
  c964435	urb-evolve p16	4.00e-03	4.00e-03	3
  c964435	urb-evolve p128	4.00e-03	4.00e-03	3
  2f45907	memetic	2.13e-02	2.13e-02	2
  2f45907	urb-evolve p16	1.30e-02	1.30e-02	2
  2f45907	urb-evolve p128	1.30e-02	1.30e-02	2

  Verdict: 2/3 seeds → REVIEW.

  • Seeded designs (c964435, 2f45907): memetic beats urb-evolve by 1.91× and 1.63×; topology search adds value over the inner-loop-only reference (crossover finds a better topology at eval 372 for c964435).
  • Blank-slate (init.dom): memetic stalls at 18 fails after 2000 evals; urb-evolve reaches 6 fails. The 0.5^n cliff means each fail adds ~2× penalty; 12-fail gap = ×4096. Root cause: single-seed topology mutation chain builds structure one room at a time; urb-evolve's random-population initialisation explores broader topology diversity upfront. Not a regression — this is a scope gap: blank-slate construction is harder than seeded improvement, and addressed separately (random multi-start bootstrap, or Phase 4 penalty reshaping which flattens the fail cliff).
  • The memetic loop is confirmed correct and competitive on the realistic use case (seeded designs). Phase 3 (native fitness) unblocks scaled runs where this gap will also narrow.

• Phase 3 — native Python fitness (gates scaled topology search): first disable occlusion/daylight in Urb behind an env flag and re-baseline (§6 descope note); then port Urb's programme-driven fitness — the §6 "port scope beyond the term list" items (simple crinkliness, cost denominator, structural failures, failure stacking, two-phase graph build). Validate score + failure set against the flagged oracle across the 35-file corpus (float tolerance, identical failure sets). Swap behind the same interface; retire the oracle. Then re-run Phase 2 at scale.

  Gate result (homemaker-py-ccw, 2026-06-13, URB_NO_OCCLUSION=1, budget 20000): experiments/run_search_scaled.py; native fitness only, no oracle. pop_size=16, child_budget=80, seed_budget=300. 71.8 evals/s, 279.8s elapsed.

  programme-house, seed c964435 vs Phase-2 and urb-evolve references:

  seed	system	budget	best	fails
  c964435	memetic Phase-2 (oracle)	2000	7.65e-03	2
  c964435	urb-evolve p16	—	4.00e-03	3
  c964435	urb-evolve p128	—	4.00e-03	3
  c964435	memetic Phase-3 (native)	20000	1.04e-02	2

  Verdict: PASS.

  • Best 1.04e-02 beats Phase-2 oracle run (7.65e-03) by 1.36× and urb-evolve p128 (4.00e-03) by 2.60×; both at 2 fails.
  • Winning topology found at eval 10357 via rotate 1/ll — unreachable within the Phase-2 budget of 2000.
  • Population diverse: 16 members, all at 2 fails (top 15), range 5.99e-03–1.04e-02.
  • Throughput 71.8 evals/s vs ~0.5 evals/s for the batched oracle (≈140× speedup).
  • harbor-house (16 rooms, oracle-impossible): run attempted, results below.

  harbor-house (16 rooms, budget 10000): seed 2b51b05 (best corpus design, 48 fails raw):

  system	budget	best	fails	evals/s
  oracle	—	impossible	—	—
  memetic Phase-3 (native)	10000	3.73e-18	49	15.8

  Search found 3.73e-18 vs seed inner-loop baseline 8.73e-19 (4.3× lift). 638 topologies in 633s. 49-fail landscape: still many fails, but topology search is finding structure (best 3 population members all at 49 fails). The 16-room programme is qualitatively beyond the oracle's capability — this run is only possible with native fitness.

• Phase 4 — penalty reshaping (done, homemaker-py-yg5, 2026-06-14): Decision: lexicographic outer-search comparison (see §4.9). Inner loop unchanged — still uses raw 0.5^n fitness scalar (cliff protection preserved, §5.4). Outer search compares individuals by (-n_fails, fitness): fewer fails always beats more fails; within a tier, compare by score. Implemented in driver.search(use_lex=True). _CHILD_INNER_KW stale sigmas entry also removed (NM default has no sigmas parameter).

• Phase 5 — representation upgrade: canonical slicing encoding (Polish expression) + bottom-up shape feasibility; scale to larger programmes.

Each phase has a concrete go/no-go gate; do not advance on faith.

---

8. Risks & open questions (decisions for the next session)

1. Native-fitness fidelity vs simplification. Port Urb's fitness exactly (maximise comparability) or take the opportunity to clean up known issues (the 0.5^n cliff, the t3 width-default contradiction below, the has_vertical_connection no-overlap stub — §6)? Recommend: port faithfully first (bugs included), validate, then reshape in Phase 4.

2. Programme contradictions exist. e.g. t3 (3 m² WC) inherits the 4 m width_inside default (Fitness/Base.pm:60) — geometrically impossible; the original "passes" only by failing size instead. Confirmed in source. Need a sane width default scaled to area, or per-room widths.

3. Inner-loop optimiser choice — RESOLVED (homemaker-py-d0s, 2026-06-13). Bake-off over 3 files × 4 methods × 3 seeds at budget 200 (experiments/bakeoff_innerloop.py), cold-start, URB_NO_OCCLUSION=1:

   method	x@40	x@80	x@200	s/eval	oracle calls	fails+
   Nelder-Mead	1.45	1.50	1.56	2.05	200	0
   CMA-ES	1.09	1.32	1.41	1.69	18	0
   compass	0.71	0.92	1.48	1.69	12	3
   compass-ms	0.71	0.92	0.92	1.44	13	4

   Decision: keep CMA-ES (already the default) for the Perl oracle era. Nelder-Mead wins quality per eval (+x0.15 at @200) but is inherently sequential — 200 Perl invocations vs 18 for CMA (§4.6 batching matters). Compass stalls on narrow-valley landscapes (2f45907: x0.62 vs x1.30) and introduces fail regressions 3/9 runs. Multi-start compass wastes budget on phase splits.

   Phase 3+ note: once native fitness replaces the oracle, oracle-call count disappears. Revisit Nelder-Mead then — its quality advantage is real. Gradient-based (autograd through native fitness) is also an option.

4. Search algorithm for topology. Memetic GA (keep crossover — now meaningful, since a subtree = a contiguous region) vs simulated annealing (the floorplanning workhorse with M1/M2/M3 moves on Polish expressions).

5. Penalty reshaping vs inner-loop protection — RESOLVED (homemaker-py-yg5, 2026-06-14). Lexicographic outer-search comparison (§4.9). Inner loop unchanged.

6. Other continuous DOF are out of scope for Phase 1 — deliberately. Floor-to-floor height is an Urb mutation (Mutate.pm:279-291, bounded 2.7–3.6 m) and feeds cost and stair fit; stair riser/width similar. Cut ratios dominate. Revisit (+1 DOF per storey) if Phase 2 plateaus.

7. End-state confirmed: 100% Python; Perl oracle is scaffold only.

---

9. How to reproduce (for the next session)

cd /home/bruno/src/homemaker-layout
# deps: pyyaml numpy scipy (shapely networkx for later phases)

# geometry port vs Urb (must be identical):
for d in /home/bruno/src/urb/examples/programme-house/*.dom; do
  diff <(perl -I/home/bruno/src/urb/lib experiments/dump_areas.pl "$d") \
       <(python3 experiments/dump_areas.py "$d") || echo "MISMATCH $d"
done

python3 experiments/resolve_ratios.py        # proxy solver (falsified)
python3 experiments/sweep_failtypes.py       # failure-type histogram
python3 experiments/optimize_fullfitness.py 200   # full-fitness headroom (validated)

Oracle invocation (see oracle.py): cwd = the .dom's directory (so patterns.config is found), perl -I<urb>/lib <urb>/bin/urb-fitness.pl <file>, env DEBUG=1 to defeat the skip-if-newer cache; reads <file>.score and <file>.fails.

---

10. Key gotchas discovered (carry forward)

• Wall inset: the .dom plot is the outer boundary; Urb insets the root by wall_outer on load (Urb::Dom::_deserialise, Dom.pm:458) and offsets back out on save. geometry.offset_quad mirrors it; dom.py stashes raw corners in node_file. Skipping this makes all areas ~14% too large.
• Multi-storey Below-inheritance: an upper quad's coordinates come from the matching quad below; a cut is "owned" by the lowest storey where its path is divided (solver.free_branches selects these). Walls stack for free.
• Geometry must be cached — the pull-based recursion is exponential in depth otherwise (geometry._cache, cleared on dom.load and after each solver mutation).
• Equal-offset cuts (a == b) ⇒ perpendicular walls, 1 DOF/cut. Independent offsets are wrong.
• 0.5^n cliff dominates fitness; it punishes new failures catastrophically (good for the inner loop, brutal for search gradient).
• Oracle ≈ 1 s/dom batched (1.65 s single; assessment-dominated, startup ~0.65 s amortises across a batch). Submit many .doms per call and prefer population optimisers; native fitness is a later speed/scale win, not a gate.

---

11. Phase 6 — topology-search quality for full / multi-storey programmes

Epic: homemaker-py-c4c. Status: scoped 2026-06-17, pre-implementation. This section is the experiment ledger for the epic; each subsection is stubbed now and filled in by the session that runs the experiment (record the command, the numbers, and a one-line verdict, in the style of §4).

11.0 Diagnosis (why this phase exists)

The delivered speedups landed in the two layers that were never the bottleneck. The native fitness (~140× over the oracle, §7 Phase 3) and the geometry inner loop (~1.6×, §4.5/§4.7) both operate within a fixed topology: the inner loop polishes geometry inside a failure tier and, by design, the 0.5^n cliff stops it ever changing the failure count (§4.5: 0-fail-change across the headroom table). But final design quality is dominated by failure count, which is almost entirely a topology property. So faster fitness and better geometry do not move the number an architect would notice.

Topology search on full programmes is the weakness:

• blank-slate programme-house (init.dom): memetic stalls at 18 fails; urb-evolve reaches 6 (§7 Phase 2 verdict).
• harbor-house (16 rooms): out1.dom = 74 fails, generated.dom = 130 fails, both at ~machine-epsilon score; failures dominated by missing-room stacking (each missing room stacks critical + size + width
  • adjacency + level, §6).

Smoking gun: operators.mutate_divide (operators.py:71) types each new leaf at random from programme-codes + C + O. Nothing makes the required programme spaces a constructive invariant, so on a large programme required rooms simply go missing → catastrophic 0.5^n stacking, and the search is a random walk over type assignments with a flat-and-catastrophic gradient in the high-fail regime.

Causal frame for the fixes. The base-floor tree is the master genome; upper storeys are divide/undivide deltas (Below-inheritance); the programme partitions rooms by required level (harbor: 10 on L0, 4 on L1, 2 free). So construction and search should follow the genome's dependency order — credible base floor first, upper floors as deltas, with each floor's required-room set known from the programme. Do not hard-freeze the base when adding floors: that recreates the §4.2 partial-objective trap at the topology level (a base optimised purely as a ground floor can be a bad substrate — the vertical core must stay aligned and load-bearing walls must stack).

11.1 Premise experiment: single-storey harbor (homemaker-py-c4c.1) — DONE

Built examples/harbor-house-l0/ from harbor by retaining only the 10 space codes explicitly marked level: 0 (cr1, ef1, da1, k1, ws1, m×3, la1, st1, me1, of×2 → 13 room instances), pruning adjacencies to the retained codes, and setting single-storey constraints (storey_minimum: 1, storey_limit: 1). The straddling anonymous spaces n/t (no explicit level key) were dropped so the set is an unambiguous single floor. Seeded from the bare plot (init.dom).

• Expectation / decision rule: near-zero fails ⇒ bottleneck is multi-storey coupling (staging is the lever); still stalls (esp. missing) ⇒ per-floor construction itself is the bottleneck (§11.2 required first).

• Command (reproduce):

  URB_NO_OCCLUSION=1 python3 experiments/run_search_scaled.py \
    examples/harbor-house-l0 20000 0 \
    examples/harbor-house-l0/init.dom examples/harbor-house-l0/generated.dom
  

• Result: 20000 native evals across 250 topologies (234 s, 85 evals/s). Best 33 fails, fitness 2.25e-12 — deep in the 0.5ⁿ high-fail penalty regime, with the whole 16-member population stuck at 33–35 fails. The smaller budget-300 smoke run sat at 40 fails; full budget only crept 40 → 33. Not near zero. Fail histogram of the best generated.dom:

  count	category
  13	missing (all 3 m meeting rooms never constructed: required/critical + per-instance size/width/adjacency sub-checks)
  6	adjacency (ws1→c, k1→da1, da1→c, da1→k1, me1→c, la1→c)
  4	access
  4	size
  2	edge too long
  2	crinkliness
  1	proportion
  1	too few stairs — single-storey artifact (staircase_min floored to 1 by the fitness or 1 default; constant across runs)
  33	total

• Verdict: per-floor CONSTRUCTION is the bottleneck, not multi-storey coupling. Even on a single floor with only 13 rooms and zero delta/core-alignment complexity, the search cannot assemble the required room set: the dominant category (13/33 = 39 %) is missing — the counted anonymous space m×3 is entirely absent — and the remaining fails are downstream adjacency/access/size consequences of a room set the mutation operators never managed to construct. This matches the §11.0 prediction's "still stalls (esp. missing)" branch: §11.2 programme-aware construction + missing-room repair is the prerequisite, and staging alone (§11.3) will not rescue it. §11.3 stays blocked on §11.2.

11.2 Programme-aware construction + missing-room repair (homemaker-py-c4c.2) — DONE

Two changes (operators.py, wired in driver.py):

1. constructive_topology — bootstrap seeder that makes the required room set a constructive invariant. It sizes each storey to its required rooms (partitioning by level; level-free rooms distributed round-robin over a shuffled order), plus one circulation C and one outside O per storey, grows the slicing tree to that leaf count, and assigns the types. Stochastic (random splits/rotations, shuffled type→leaf assignment) so a bootstrap batch is still a diverse population. Replaces the random random_topology bootstrap whenever the programme has required spaces.
2. mutate_place_missing — repair operator. Detects a required-but-absent space (graph.check_space_counts) and inserts one by dividing a host leaf into [room | remainder]. Lex-safe host ranking (cf. §4.10): generic O leaves first (unbounded, nothing displaced), then other non-required leaves, circulation/stairs only as last resort; a required room is never displaced. Forced onto the room's required storey when the programme constrains its level. Weight 2.0 in the mutation mix (noops cheaply once complete).

• Gate: missing-type failures collapse to ~0; net-fail improvement vs the blank-slate baseline; no regression on the seeded programme-house 1-fail optimum (§4.10).

• Commands (reproduce):

  # A/B at identical budget+seed (old = git HEAD before this change):
  URB_NO_OCCLUSION=1 python3 experiments/run_search_scaled.py \
    examples/harbor-house 20000 0 examples/harbor-house/init.dom out.dom
  # §4.10 regression: warmstart-2f4 seed, 50000 evals, pop 8, 4 workers
  

• Result (harbor-house, 20000 native evals, seed 0, identical config):

  metric	OLD (random bootstrap)	NEW (constructive)
  seed best fails	163	139
  final total fails	133	105
  missing fails	103 (77 %)	12 (11 %)
  missing-records	22	2
  dominant remaining	missing	crinkliness 27, size 23, access 13, edge 12

  Constructive seeding alone gives a 24-fail head start at the seed (163 → 139) and the run ends at 105 vs 133 (−21 %), with the missing stack collapsed 103 → 12. §4.10 regression: PASS — the warmstart-2f4 seed still reaches a 1-fail population (whole pop 1f at 50 040 evals; place_missing noops harmlessly when the set is complete).

• Verdict: construction works and is necessary, but reframes the bottleneck. Making the required set a constructive invariant removes the catastrophic missing-room stacking that dominated the blank-slate baseline (77 % → 11 % of fails). But a complete 36-room harbor design then carries a large quality-fail load — crinkliness/size/access/edge-too-long packing of two fully-populated floors — that the current geometry inner loop + topology operators reduce only partway in 20k evals. So total fails improve but stay high. The dominant categories are now exactly what §11.4 (graded objective, to navigate the dense quality-fail regime) and §11.3 (staging — build one credible floor at a time instead of cramming both) target; §11.3 is unblocked by this result. A concrete next seeder refinement (filed): the type→leaf assignment is currently random, ignoring adjacency — clustering each room near its required c/neighbour at construction time should cut the adjacency (8) and downstream access (13) fails directly.

  Note on the baseline: DESIGN cited a "74-fail out1.dom", but the on-disk out1.dom is untracked and was overwritten by a prior experiment (it now re-scores to 37 fails; the committed out1.dom.fails of 74 lines belongs to the superseded .dom). The honest, reproducible comparison is therefore the identical-config A/B against the pre-change code (133 fails), not the stale out1.dom number.

11.3 Staged per-floor search (homemaker-py-c4c.3) — DONE

Searches the genome in causal dependency order (driver.search_staged), two stages composed from the existing driver.search:

1. Stage 1 — base floor (40 % of budget). A single-storey programme is auto-derived to a tempdir (programme.write_stage1_programme): the full patterns.config filtered to the storey-0 room set (programme.partition_rooms_by_storey), level: keys dropped, adjacencies pruned to surviving refs, storey_limit/staircase forced to 1. The base is searched on that reduced programme but ranked with a substrate-readiness bonus — key (-n_fails, fitness·(1 + W·readiness)), W=1 — so it is selected as a good substrate, not merely a good ground floor (anti-§4.2). graph.substrate_readiness = core_factor · capacity: full credit for a reserved C leaf ≥ STAIR_MIN_AREA (vertically-alignable core), times min(1, usable_base_area / required_upper_area) (enough divisible footprint for the upper set).
2. Stage 2 — upper floors as deltas (remaining budget). The best base is lifted (operators.lift_base_to_storeys) into a full multi-storey design that preserves the base storey and its inherited core and instantiates each upper storey's required room set by construction (the Stage-2 analog of §11.2 seeding). Deltas are searched with the base kept mutable at low probability (base_p=0.15, threaded through the exploratory ops; place_missing/core_* stay unbiased — repair and core-maintenance must reach the base).

• Gate: staged beats single-stage on harbor at equal budget; reserved-core + readiness prevent the bungalow trap (stage 2 does not carve a core from scratch); no programme-house regression.

• Commands (reproduce, URB_NO_OCCLUSION=1, 20000 evals, seed 0):

  python3 experiments/run_search_scaled.py examples/harbor-house 20000 0 \
    examples/harbor-house/init.dom scratch/ab_single.dom        # single-stage
  python3 experiments/run_staged_search.py examples/harbor-house 20000 0 \
    examples/harbor-house/init.dom scratch/ab_staged.dom         # staged
  

• Result (harbor-house, 20000 native evals, seed 0, identical config):

  metric	single-stage	staged
  total fails	105	95
  crinkliness	27	18
  edge too long	12	8
  proportion	6	4
  width	4	2
  size	25	26
  access	13	18
  missing	8	8
  adjacency	2	2

  Single-stage reproduces the §11.2 baseline exactly (105 fails); staged ends at 95 (−10, −9.5 %). The gain is concentrated in the packing fails staging targets — crinkliness 27→18 and edge-too-long 12→8 — at a small cost in access (+5). Anti-bungalow: confirmed. Every core_divide/core_undivide in the Stage-2 winning lineage is a noop — the core is inherited from Stage 1 and is never carved from scratch. Programme-house regression: PASS — single-storey programmes fall through to plain search; the warmstart-2f4 seed (50000 evals, pop 8, 4 workers) still reaches a whole-population 1-fail optimum (§4.10).

• Verdict: staging helps, modestly, and is the right structural frame. Building one credible, substrate-ready floor first — then upper floors as constructed deltas with an inherited core — beats cramming both floors simultaneously (95 vs 105) without touching the inner loop. The remaining load is the dense quality-fail regime (size/access/crinkliness on two fully-populated floors) that §11.4 (graded objective) targets: with missing already collapsed (§11.2) and the floors now assembled in dependency order, the lever left is navigation within the high-fail plateau, where lex-by-count gives near-zero gradient.

11.4 Graded high-fail objective (homemaker-py-c4c.4) — DONE (negative)

Premise (from Phase 4, §4.9): lexicographic-by-total-count (-n_fails, fitness) gives ~zero selection signal in the high-fail regime because the 0.5^n cliff flattens fitness to ~machine-epsilon, so neighbours at ~49–105 fails look indistinguishable. Proposed fix: a continuous proximity key beneath fail-count and above fitness — (-n_fails, grade, fitness).

Implementation (kept, default-off). fitness._leaf_grade reads each failing per-leaf quality factor (perpendicular/proportion/size/width/crinkliness/access) as proximity-to-satisfaction f / FAIL_THRESHOLD ∈ [0,1) and sums it; Fitness.score_with_grade returns it alongside score/fails. The scalar fitness and the fail count are untouched, so the inner-loop 0.5^n cliff (§5.4) is unaffected — inner-loop 0/9-regression check: PASS (re-ran §4.9 part 1, run_inner_loop_protection, 0/9 regressions). The grade is read once per child off the already-optimised tree in driver._evaluate (one extra native eval, ~1/child_budget) and used only in the outer comparator key, behind search(..., use_grade=True) / search_staged(..., use_grade=True) (default False; threaded to Stage 2 only — Stage 1 keeps its readiness key, §11.3). Structural fails (missing/adjacency/edge-too-long/level/…) score 0 grade, so the missing-space hierarchy (§6) is preserved: grade can never reward dropping a room.

• Commands (reproduce, URB_NO_OCCLUSION=1, 20000 evals):

  USE_GRADE=0 python3 experiments/run_staged_search.py examples/harbor-house 20000 <seed> \
    examples/harbor-house/init.dom scratch/st_lex.dom        # lex baseline
  USE_GRADE=1 python3 experiments/run_staged_search.py examples/harbor-house 20000 <seed> \
    examples/harbor-house/init.dom scratch/st_grade.dom      # lex + grade
  

• Result (harbor-house, staged, 20000 native evals, total fails at budget):

  seed	staged lex	staged lex+grade
  0	95	99
  1	96	98
  2	106	102
  mean	99.0	99.7

  Grade wins 1/3 seeds, loses 2/3, and is slightly worse on the mean — within seed-noise, no escape from the plateau. Single-stage seed 0 is a dead heat (105 = 105). Stage-1 is identical by construction (grade off there); the divergence is entirely in Stage 2, where the grade run stalls early (seed 0: last improvement at 13600/20000 evals, stuck at 99) while lex keeps reducing the count (99→95).

• Why it fails — the premise is falsified by measurement. The cliff is constant within a fail-tier (0.5^n, n fixed), so within a tier reported fitness is value/cost × const and still spans ~6 orders of magnitude (seed-0 Stage-2 history: 1.2e-37 → 4.6e-31 all inside the same descending fail count). The outer comparator only ever compares within a tier (−n_fails dominates across tiers), so lex's secondary fitness key already carries a strong, well-graded signal — exactly the gradient §11.4 assumed was missing. Inserting grade above fitness displaces that working signal: the population fills with high-grade (shallow-fail) incumbents and the fail-reducing restructurings — which transiently deepen other fails and so look worse on grade — are no longer selected. Placing grade below fitness instead would be near-inert (fitness ties are measure-zero in a continuous objective). Either way there is no lever: the high-fail plateau is a topology basin, not a comparator-resolution problem.

• Verdict: reject the graded objective; lexicographic (-n_fails, fitness) stands. The §11.3 staged 95-fail result remains the harbor best. The remaining load is genuinely structural (escaping topology basins), which is what §11.5 (structural niching + restarts) and the 9gp canonical-encoding capstone target — not outer-comparator reshaping. The use_grade flag and score_with_grade are kept default-off for reproducibility and possible reuse (e.g. as a diversity signal under §11.5 rather than a selection key).

11.5 Topology diversity: structural niching + restarts (homemaker-py-c4c.5) — DONE (negative)

Premise (epic diagnosis): the population dedups on the fitness scalar (driver.admit, abs(fitness) within 1e-9) and so has no structural diversity preservation — proposed as the root cause of the blank-slate gap (§7 Phase 2: memetic 18 fails vs urb-evolve 6), a single mutation chain losing to urb-evolve's upfront random-population diversity.

Implementation (kept, default-off). A cheap structural topology signature (genome.signature) string-encodes each storey's tree shape + cut orientations

• leaf types, routed through encode so dead inherited fields canonicalise; it is ratio-invariant (same topology, different geometry → same signature). Two diversity mechanisms, both behind flags on search/search_staged: niche_by_signature holds at most one individual per signature in the population (structural niching, keeping the better of a collision) in place of the fitness-scalar guard; restart_patience=<evals> does a soft restart on stagnation (keep restart_elite incumbents, refill with fresh constructive/random seeds — urb-evolve's upfront diversity as a soft restart). SearchResult gained n_distinct_signatures / diversity_history / n_restarts to quantify diversity over time.

• Commands (reproduce, URB_NO_OCCLUSION=1, 20000 evals):

  NICHE=0 python3 experiments/run_search_scaled.py examples/programme-house 20000 <seed> \
    examples/programme-house/init.dom scratch/ph_before.dom   # legacy dedup (before)
  NICHE=1 python3 experiments/run_search_scaled.py examples/programme-house 20000 <seed> \
    examples/programme-house/init.dom scratch/ph_niche.dom    # structural niching
  NICHE=1 RESTART_PATIENCE=2000 python3 experiments/run_search_scaled.py \
    examples/programme-house 20000 <seed> examples/programme-house/init.dom scratch/ph_restart.dom
  # harbor (staged): swap run_staged_search.py, seed examples/harbor-house/init.dom
  

• Diversity (the secondary criterion) — MET. Niching takes the final population from ~4–6 / 16 distinct topologies (legacy dedup) to 16 / 16; restarts raise distinct topologies seen by ~30 % (≈105–138 → ≈164–186 on programme-house). The signature machinery works exactly as designed.

• Fail count (the gate) — NOT MET. Blank-slate programme-house, total fails at budget (lower is better):

  seed	before (legacy)	niche	niche + restart
  0	11	14	12
  1	11	11	14
  2	15	13	13
  mean	12.3	12.7	13.0

  Harbor-house (staged, seed 0): legacy 95 (reproduces §11.3 exactly), niche 94, niche+restart 108. Across both programmes niching is a tie within seed noise and restarts are strictly worse; nothing approaches the ≤ 6 gate.

• Why it fails — the premise is falsified by measurement. More structural population diversity does not buy lower fails: the legacy dedup already holds 14/16 distinct topologies on harbor (Stage-2 starts from lifted bootstraps), so it was never the diversity bottleneck the epic assumed. Maximal diversity (16/16) with the fixed tournament pressure just diffuses effort — the fitness-scalar dedup's smaller effective population exploits a basin slightly harder. Restarts throw away converging Stage-2 work and regress hardest. The high-fail plateau is a reachability problem (operators + encoding cannot reach the low-fail basins), not a population-management one — the same conclusion §11.4 reached from the comparator side.

• Verdict: reject niching/restarts as defaults; the legacy fitness-scalar dedup stands. niche_by_signature / restart_patience are kept default-off for reproducibility and reuse, and genome.signature is the cheap stand-in that the canonical Polish encoding (homemaker-py-9gp) supersedes. With §11.3–§11.5 all landed, the residual load is genuinely structural: the principled lever is the canonical encoding (associativity collapse (a|b)|c == a|(b|c)) plus richer topology operators, not outer-loop selection/population reshaping.

11.6 Adjacency-aware constructive seeding (homemaker-py-s44) — DONE (positive)

Premise (follow-up to §11.2): constructive_topology instantiated every required room but typed the leaves at random, so rooms landed stranded from circulation. On harbor the seed carried ~29 adjacency-to-c + ~27 per-leaf access + level-inaccessible fails (≈ 56 of the seeder-controllable load; the remaining size/width/proportion/crinkliness fails are geometry, the inner loop's job). The programme confirms the shape: of 16 harbor spaces all 16 require adjacency to c, so the dominant lever is connect every room to circulation.

Implementation (operators._assign_adjacency_aware, default-on). A single circulation leaf cannot border a dozen rooms, and a slicing tree guarantees adjacency only between siblings — so adjacency must be read from the geometric leaf graph, not the tree. The seeder now spends ~one extra leaf per three rooms on circulation, builds the type-independent geometry.leaf_graph, and picks a greedy connected dominating set of circulation leaves (start at the highest-degree leaf, extend along the frontier by most-newly-dominated): every room leaf ends up bordering a connected circulation spine, so adjacency-to-c and access are satisfied by construction at the seed geometry. Rooms are placed on dominated leaves (constraint-hardest first), outside O on the most peripheral leaf; room order and tie-breaks stay stochastic so a bootstrap batch is diverse. Threaded through driver.search(seed_adjacency_aware=True); adjacency_aware flag on constructive_topology (env ADJ in run_search_scaled.py) for the A/B.

• Commands (reproduce, URB_NO_OCCLUSION=1, 20000 evals, single-stage):

  ADJ=0 python3 experiments/run_search_scaled.py examples/harbor-house 20000 <seed> \
    examples/harbor-house/init.dom scratch/hh_adj0.dom        # random assignment (before)
  ADJ=1 python3 experiments/run_search_scaled.py examples/harbor-house 20000 <seed> \
    examples/harbor-house/init.dom scratch/hh_adj1.dom        # adjacency-aware (after)
  

• Seed quality (harbor, 10 seeds, raw seed before optimisation): adjacency-to-c 29.2 → 12.2, per-leaf access 26.6 → 8.3, level-inaccessible 0.4 → 0.2 (≈ 56 → 21 seeder-controllable fails). Geometry fails rise at the raw 0.5-split seed (more, smaller leaves) but are recovered by the inner loop.

• End-to-end (total fails at budget, single-stage, lower is better):

  seed	harbor before	harbor after	prog-house before	prog-house after
  0	105	100	11	10
  1	115	85	11	8
  2	110	87	15	10
  mean	110.0	90.7	12.3	9.3

  Harbor −19.3 fails (−17.5 %), programme-house −3.0 (−24 %). ADJ=0 seed 0 reproduces the §11.2 single-stage 105 baseline exactly (clean control). Notably the adjacency-aware single-stage harbor (mean 90.7, best 85) now beats the §11.3 staged best of 95 — the first Phase-6 fail-count reduction from seeding rather than search machinery.

• Verdict: keep adjacency-aware seeding as the default. It is the first lever in Phase 6 to move the fail count on both programmes. The win is the dominant adjacency-to-c / access load; secondary adjacencies and the staged lift_base_to_storeys upper floors are picked up in §11.7 (homemaker-py-ld5).

11.7 Adjacency-aware lift + secondary adjacencies (homemaker-py-ld5) — DONE (positive)

Two gaps left by §11.6: (a) lift_base_to_storeys — the staged Stage-2 seeder — still typed upper-floor leaves at random, so staged search did not get the adjacency win; (b) secondary adjacencies (k1↔da1, da1↔o, ~4 harbor rooms) were ignored.

Implementation. _assign_adjacency_aware gained a fixed_circ parameter: the dominating-set search is seeded from given circulation leaves, so on an upper floor the spine grows off the inherited vertical core rather than from scratch (preserving the §11.3 anti-bungalow core-alignment invariant). Room placement is now constraint-ordered: codes with the most non-c adjacency requirements are placed first, each onto the open slot that satisfies the most of its requirements against already-typed neighbours (circulation + rooms placed so far), clustering k1↔da1, da1↔o, etc. lift_base_to_storeys(reqs=…, adjacency_aware=True) grows a per-floor circulation budget and calls it with the core as fixed_circ; threaded through search_staged(seed_adjacency_aware=True) (ADJ env in run_staged_search.py).

• Seed quality (harbor lift, 8 seeds, raw seed): adjacency-to-c 16.1 → 7.6, access 16.2 → 7.2 on the lifted upper floor.

• End-to-end (harbor, staged, 20000 evals, total fails at budget):

  seed	staged before (ADJ=0)	staged after (ADJ=1)
  0	95	97
  1	96	78
  2	106	81
  mean	99.0	85.3

  ADJ=0 reproduces the §11.4 staged lex baseline exactly (95/96/106, mean 99.0 — clean control). Staged adjacency-aware is −13.7 fails (−14 %) and is now the best harbor configuration overall: staged baseline 99.0 → single- stage adjacency-aware (§11.6) 90.7 → staged + adjacency-aware lift 85.3 (best 78, seed 1). Staging and adjacency-aware seeding compose: the credible Stage-1 base and the core-seeded upper spine each contribute.

• Verdict: keep adjacency-aware lift + secondary clustering as defaults. Harbor is now ~85 fails, down from the 95/105 plateaus that opened Phase 6. The residual is geometry- and shape-bound (size/proportion/crinkliness on the denser, more-circulation layouts), which is the canonical-encoding / shape-feasibility territory of homemaker-py-9gp.

11.8 Topology diversity × selection pressure, co-tuned (homemaker-py-6zy) — DONE (negative)

Premise (loose end from §11.5): structural niching was A/B'd against the legacy fitness-scalar dedup with selection pressure held fixed at a binary tournament (driver._tournament, k=2). §11.5's own mechanism note named the coupling as the reason for its null — "Maximal diversity (16/16) with the fixed tournament pressure just diffuses effort" — i.e. diversity and pressure are coupled but were varied as if independent: niching widens the population, but k was never sharpened to convert the extra exploration back into exploitation. This issue isolates that coupling — sweep tournament size jointly with niching to test whether sharper selection turns the 16/16 structural diversity into lower fails. The project had already pivoted to the canonical encoding (homemaker-py-9gp); this is a falsification check so the lever is not silently lost, not an expected win (§11.4/§11.5 both located the plateau in reachability).

Implementation (knob only; default-off behaviour unchanged). Exposed tournament_k: int = 2 on search / search_staged, threaded into both _tournament call sites (crossover pair + mutation parent) and all three internal search() calls of the staged path; reuses the §11.5 genome.signature / niche_by_signature machinery unchanged. The experiments harness reads HOMEMAKER_TOURNAMENT_K (mirrors NICHE) in run_search_scaled.py / run_staged_search.py; experiments/run_6zy_ab.sh runs the joint grid (RESUME-able).

• Commands (reproduce, URB_NO_OCCLUSION=1, 20000 evals; blank-slate seed init.dom to match §11.5):

  # grid: NICHE ∈ {0,1} × HOMEMAKER_TOURNAMENT_K ∈ {2,3,4}
  NICHE=0 HOMEMAKER_TOURNAMENT_K=2 python3 experiments/run_search_scaled.py \
    examples/programme-house 20000 <seed> examples/programme-house/init.dom scratch/out.dom
  # harbor (staged): run_staged_search.py, seed examples/harbor-house/init.dom
  bash experiments/run_6zy_ab.sh        # full grid → scratch/6zy/summary.tsv
  

• Diversity (mechanism check) — confirmed biting. niche=on holds the final population at 16/16 distinct topologies at every k; niche=off sits at 4–11/16. The pressure knob is genuinely varied (k=2,3,4). So both levers are live — the null below is not a machinery artefact.

• Fail count (the gate) — no cell beats the baseline. Blank-slate programme-house, total fails at budget over 5 seeds (0–4), mean (sd):

  niche \ k	k=2	k=3	k=4
  off	4.80 (1.60)	6.40 (2.50)	6.00 (2.00)
  on	6.20 (1.72)	7.00 (1.41)	6.60 (1.85)

  The legacy (off, k=2) cell is the best of the six (4.80); every higher-pressure row and every niche=on row is equal-or-worse (6.0–7.0). All differences sit within ~1 sd at 5 seeds, so the grid is a wash — but the central tendency is unambiguous: sharpening k and adding niching both slightly hurt, the opposite of the rescue the premise hypothesised. Harbor-house (staged, seed 0) reinforces it: niche=on is uniformly worse than off at every k (k2 72→83, k3 77→82, k4 67→75); within the niche=on row higher k helps monotonically (83→82→75) but never catches the niche=off row, and the best cell overall (off, k=4 = 67) is a single-seed wiggle within noise of the off, k=2 = 72 baseline.

• Why it fails — the coupling is real but points the wrong way. Sharper selection does not convert the extra structural diversity into lower fails; if anything the 16/16 niched population at high k over-commits the larger spread to a handful of basins and loses the occasional lucky low-fail draw the smaller fitness-scalar population stumbles into. §11.5's "diffuses effort" diagnosis survives co-tuning: the bottleneck is reachability (operators + encoding cannot reach the low-fail basins), so reshaping selection/population pressure cannot recover what the search space does not expose — the same conclusion §11.4 reached from the comparator side and §11.5 from the diversity side.

• Verdict: §11.5 null is robust to selection pressure — reject k>2 and niching as defaults; binary tournament + fitness-scalar dedup stand. tournament_k is kept (default-2) as a reusable knob alongside niche_by_signature. With §11.4/§11.5/§11.8 all negative on the outer loop, the residual is confirmed structural: the principled lever is the canonical encoding + richer topology operators (homemaker-py-9gp), not selection or population management.

12. Phase 7 — scaling validation & residual reduction (post-c4c)

Epic: homemaker-py-leu. Status: opened 2026-06-19. Continuation of the closed Phase 6 (§11). Phase 6 evidence located the leverage in construction / seed quality (§11.6/§11.7 wins) rather than search machinery (§11.4/§11.5 both regressed); the harbor residual is now geometry/shape-bound at ~85 fails. This section is the experiment ledger for Phase 7, same discipline as §11: each subsection records the command, the numbers, and a one-line verdict.

12.1 Larger-than-house benchmark: maple-court (homemaker-py-leu.1) — DONE

Why. Harbor (16 programme entries, 2 storeys) was the biggest real programme in examples/. homemaker-py-9gp's headline claim is scaling >16 rooms and its acceptance criterion demands "a larger-than-house programme" to measure on — so a bigger benchmark is a prerequisite, not optional. Proportion-aware seeding (leu.2) and re-scoped 9gp are both measured against this baseline.

The benchmark. examples/maple-court/ — a three-storey assisted-living / co-housing facility: 26 distinct programme entries / 52 room instances across 3 required storeys (storey_minimum: 3), ~1015 m² target internal area on a ~790 m²/floor plot. It mirrors harbor's structure deliberately — a dominant adjacency-to-c load on nearly every room plus a handful of secondary adjacencies (da1↔k1, da1↔o, lr1/ws1/lo1/gh1/gy1 ↔ o), anonymous interchangeable room families (m×3, t×6, n×4, r×12, em×2, py×2, tt×4), and staircase_min/max: 2. Code letters avoid the generic c/o/s leading-letter trap (those are reserved in fitness.py/graph.py for circulation/outside/sahn): no room code starts with c/o/s, so harbor's quirk of typing Common Room / Storage / Office as quasi-generic (cr1/st1/of) is not reproduced. init.dom is a single O footprint; storeys are built by the search from storey_minimum, exactly as harbor.

Baseline (current default search: adjacency-aware seeding + staged, §11.7). Reproduce (URB_NO_OCCLUSION=1, 20000 evals, staged, ADJ=1 default):

URB_NO_OCCLUSION=1 python3 experiments/run_staged_search.py \
  examples/maple-court 20000 <seed> examples/maple-court/init.dom scratch/mc_s<seed>.dom

seed	total fails	best lineage
0	145	rotate 0/rrlr
1	158	core_undivide noop
2	152	swap 0/rrlllr
mean	151.7

Each run executed exactly 20000 native evals across 250 topologies (~36 min, ~9.1 evals/s) and re-scored native-consistent (→ OK). The best layout (seed 0, 145 fails) was saved as examples/maple-court/generated.dom with its .fails (superseded in §12.2 by the proportion-aware 126-fail layout). The single-stage harness (run_search_scaled.py) also accepts the programme unchanged. The score prints near-zero (0.5^145 fail cliff) — the fail count is the yardstick.

• Verdict: benchmark established at mean 151.7 fails (best 145). As expected for a programme ~3× harbor's room count, the absolute fail floor is well above harbor's ~85; this is the scaling yardstick leu.2 (proportion-aware seeding) and the re-scoped 9gp are measured against. The residual character is the same geometry/shape family flagged at the close of §11.7.

12.2 Proportion-aware constructive seeding (homemaker-py-leu.2) — DONE (positive)

Premise (follow-up to §11.6/§11.7). The constructive seeders grow geometry with uniform [0.5, 0.5] cuts before types are assigned, so the raw seed is "more, smaller leaves" of equal area: a room with a large programme target comes out too small, a small room too big, and the inner loop must recover all of size/width/proportion from scratch. With the adjacency load now cut by seeding (§11.6/§11.7), this geometry residual is the dominant remaining term. Attacking it at the seed — in the proven construction direction — is far cheaper than the 9gp encoding rewrite.

Implementation (operators._size_divisions_from_targets, flag seed_proportion_aware, env PROP, default-on per the A/B below). After the adjacency-aware type assignment (§11.6/§11.7, left exactly as is), each leaf carries a target area — a sized room's programme size; circulation/outside absorb the plot slack (floored at 0.4 × mean room area so a circulation leaf never shrinks below door-width and undoes the §11.6 adjacency win). Because division=[f, f] cuts off left area-fraction f (rotation-independent — verified), bottom-up subtree-target sums compose multiplicatively to give every leaf area ∝ its target. Area alone regressed the raw seed, though: choosing only the cut fraction to hit a target area slices thin slivers with terrible aspect (proportion/width/edge-too-long fails swamp the size gain — measured below). So each cut also picks the rotation (the two distinct cut directions) that makes its two children squarest; rotation depends on realised parent geometry, so the pass runs top-down. Both ratio and rotation derive from the target dims; neither touches topology or type assignment. Threaded through driver.search/search_staged(seed_proportion_aware=…).

• Raw-seed fails (10 seeds, single-stage constructive, before optimisation), area-only vs area+rotation:

  family	harbor before	area-only	area+rot
  geometry	123.0	135.9	99.9
  access/adj	19.1	23.8	20.4
  total	144.1	162.1	123.7

  Area-only makes geometry worse (slivers); area+rotation drops the geometry family on every programme — harbor 123.0 → 99.9 (−19 %), programme-house 13.1 → 8.7 (−34 %), maple-court 200.5 → 164.1 (−18 %). Access/adjacency regresses slightly (rotation shifts the leaf graph the adjacency assignment was computed against): harbor +1.3, prog-house +2.4, maple +3.4 — far smaller than the geometry gain. The size family in particular falls as intended (harbor size 31.4 → 22.0), and proportion flips from a regression to a win (21.3 → 12.8) once rotation is co-chosen.

• End-to-end (total fails at budget, 20000 evals, 3 seeds, PROP=0 vs PROP=1; harbor & maple-court staged):

  seed	harbor PROP=0	harbor PROP=1	maple PROP=0	maple PROP=1
  0	97	72	145	126
  1	78	81	158	148
  2	81	69	152	134
  mean	85.3	74.0	151.7	136.0

  Harbor −13 % (best 69, was 78), maple-court −10 % (best 126, was 145). PROP=0 reproduces the §11.7 staged harbor (85.3) and §12.1 maple baseline (151.7) exactly — clean controls. Proportion-aware seeding is the first Phase-7 lever to move the fail count on the larger-than-house benchmark.

• A storey-count bug surfaced (homemaker-py-cq1). programme-house has storey_minimum: 2 but all rooms level: 0, and n_storeys_required only read level: keys — so the constructive seeder built a 1-storey seed for a 2-storey programme and search_staged fell through to plain search. Fixed (programme.storey_minimum/n_storeys_for; driver.search passes min_storeys to the seeder; search_staged routes on max(level-derived, storey_minimum)). No-op for harbor/maple (level-derived already ≥ storey_minimum); independent win on programme-house (single-stage baseline 8.0 → 5.0 with a correct 2-storey seed).

• programme-house regresses, but it is a convergence-speed artifact, not a worse optimum. On the 6-room programme proportion-aware seeding loses at 20000 evals on every path tested (single-stage 1-storey 8.0→11.7, single-stage 2-storey 5.0→8.3, staged 2-storey 4.3→6.0). The mechanism is a deeper local optimum: the equal-area PROP=0 seed has badly-proportioned leaves, so undivide moves — the route to programme-house's simpler optimum — are accepted as improvements; the well-fitted PROP=1 seed makes undivide an immediate fitness drop (merging two good leaves yields one bad one), walling off the restructuring path. A budget sweep (staged, storey-fixed) shows this is reachability speed, not an asymptotic trap:

  budget	PROP=0 (s0/s1)	PROP=1 (s0/s1)
  20000	4 / 5	8 / 6
  60000	2 / 2	4 / 3
  150000	2 / 0	1 / 10

  PROP=1 reaches 1 fail (seed 0, 150k — beating PROP=0's 2; best-known is 2), so it is not trapped; the gap narrows with budget and crosses over. (Staged splits budget by fraction, so runs at different budgets evolve different Stage-1 bases and are not nested — hence the high variance, e.g. PROP=1 seed 1 swinging 3→10.) The same "deeper basin" that helps where the constructed topology is roughly right (large programmes, scarce budget) delays convergence where the seed must be restructured (small programmes).

• Verdict: keep proportion-aware split sizing, default-on (seed_proportion_aware default True, env PROP=1). It is a measured win on both larger programmes — harbor −13 %, the maple-court scaling benchmark −10 % — exactly the regime Phase 7 targets and the basis the re-scoped 9gp is measured on. The only regression is a small-programme convergence-speed effect that washes out with budget (PROP=1 reaches the known floor), with no evidence of an asymptotic penalty, so default-on is not paid for by a worse optimum anywhere. The win is rotation-and-ratio sizing from target dims; the bare ratio is not enough (area-only regressed). Area sizing assumes total target ≈ plot area; choosing the cut direction for aspect is what makes it pay.

12.3 Re-scoped 9gp: shape feasibility + reachability moves (homemaker-py-9gp)

Re-scoped capstone of the epic (2026-06-19): the original canonical-Polish- expression rewrite was justified partly by a niching signature, but §11.5 falsified niching and genome.signature already supplies the cheap stand-in. The two surviving, evidence-supported parts are landed here as operators on the existing decoded Node tree — no Polish-expression rewrite — each measured independently against the §12.2 leu.2 baseline (maple-court staged 136.0, harbor 74.0). A true canonical encoding is revisited only if the M3 measurement proves associativity valuable at scale.

9gp.1 — shape-feasibility pre-filter (scaling lever). operators. predicted_shape_fails(root, reqs, fit) lays a topology out at its proportion- aware target geometry (reusing _size_divisions_from_targets, §12.2 — the squarest layout the inner loop warm-starts from) and counts the size/width/proportion/crinkliness fails the native fitness reports: a cheap lower-bound proxy for the best shape the topology can reach. driver._evaluate calls it before the inner loop and prunes (1 feasibility eval instead of ~80 inner-loop evals) when the predicted shape fails both exceed a tunable threshold and are ≥ the incumbent's total fails — the second guard makes the proxy safe (a topology whose shape floor is still below the incumbent is never discarded). Pruned individuals are tagged pruned/…, counted as explored topologies but never bred from or ranked, so budget flows to feasible topologies. Seed/bootstrap/restart batches are never filtered (construction invariants must survive). Threaded as search(…, feasibility_filter, feasibility_max_shape_fails) through search_staged; default OFF so the §12.2 controls reproduce exactly (test_feasibility_filter_off_matches_baseline). Env: FEAS=1 MAXSHAPE=<n>.

9gp.2 — M3 Wong-Liu re-association move (reachability lever). operators. mutate_reassociate adds the associativity move (a|b)|c ↔ a|(b|c) on two same-orientation live cuts (both directions, for reversibility): a pure- topology move that preserves the leaf set and types but reaches tree shapes the existing set cannot. M1 (operand swap) is mutate_swap and M2 (single-cut orientation complement) is mutate_rotate; associativity was the missing canonical-slicing move attacking the reachability bottleneck §11.4/§11.5 both fingered. Only live cuts (below is None, as mutate_rotate) are restructured, so dead inherited fields are untouched and encode re-anchors deltas; the two restructured cuts default to 0.5 and the inner loop recovers their ratios. Registered in MUTATIONS; default OFF via enable_reassociate (forces its mutation weight to 0 so the baseline is byte-identical). Env: REASSOC=1.

• Implementation status (this session): both land with unit tests (tests/test_operators.py: reassociate preserves the leaf multiset, changes the signature, noops on perpendicular cuts, stays canonical on the harbor corpus; predicted_shape_fails is non-negative, pure, deterministic. tests/test_driver.py: filter-off reproduces the baseline trajectory; filter-on prunes at 1 eval/topology and never admits a pruned individual). Full suite green (211 passed). A short smoke run on maple-court confirms both paths execute under the real native fitness.

• Calibration (predicted shape-fail floor of the constructive seeds). Over 8 proportion-aware constructive seeds, predicted_shape_fails is maple 121–163 (mean 135.6) and harbor 72–90 (mean 84.6) — essentially equal to the final achieved total fail counts (maple 126–148, harbor 69–81). So the shape floor at the best achievable geometry already accounts for almost the whole residual: independent confirmation of §11.7 that the Phase-7 residual is geometry/shape- bound. MAXSHAPE was set below the incumbent range (maple 100, harbor 55) so the pred ≥ incumbent safety guard is the dominant prune gate (experiments/ run_9gp_ab.sh).

• A/B sweep (DONE — negative). maple-court + harbor, seeds 0/1/2, 20000 evals, staged, total fails at budget:

  programme	seed	baseline	reassoc	feas	combined
  maple-court	0	126	131	129	131
  maple-court	1	148	141	151	142
  maple-court	2	134	146	140	144
  maple-court	mean	136.0	139.3	140.0	139.0
  harbor	0	72	83	82	81
  harbor	1	81	81	80	81
  harbor	2	69	70	69	70
  harbor	mean	74.0	78.0	77.0	77.3

  The baseline controls reproduce the §12.2 leu.2 means exactly (maple 136.0, harbor 74.0) — a clean control, so the negative is real. Every variant is neutral-to-slightly-worse on every programme: reassoc +3.3/+4.0, feas +4.0/+3.0, combined +3.0/+3.3 (maple/harbor). The feasibility filter did prune and explore more topologies in several runs (maple s1/s2 combined 342/319, s2 feas 317 vs the baseline 250) — but the extra topologies did not lower the fail count, and M3 reassociate never produced a win despite reaching new tree shapes.

• Verdict: keep both default-OFF; the Phase-7 residual is NOT reachability- or feasibility-bound. This is the third independent negative on search machinery (§11.4 graded objective, §11.5 niching+restarts, now §12.3 M3 moves + shape pruning), against four positives all from construction/seed quality (§11.2, §11.6, §11.7, §12.2). The associativity move reaches new topologies but they are not better; the shape filter saves budget on topologies whose shape floor already matches the incumbent, but — precisely because the floor ≈ the achieved total (calibration above) — there is no lower-fail basin for that saved budget to find. The geometry/shape residual is intrinsic to the constructed layouts, not a search-reachability deficit. A full canonical Polish-expression rewrite is not justified: its one measurable promise here (associativity reachability) was tested directly and did not pay.

• Residual diagnostic (where the shape fails actually live, maple-court, 6 constructive seeds). A per-leaf breakdown — to test, not assume, what the next lever would be — overturns the obvious "shape-aware placement" guess:

  signal	measured	reading
  plot utilisation (target/plot area)	0.44 (0.28–0.54)	NOT density/area-bound — ample slack
  failing leaves / total	~68 / 73	shape fails are uniform, not concentrated
  dominant factors	crinkliness 346, size 242, proportion 121, width 102	perimeter/area + undersize, both granularity effects

  Because nearly every leaf fails (not a few mismatched ones), the residual is not a room→leaf placement mismatch — there are no well-shaped leaves to place demanding rooms into. The mechanism is over-granular construction: 73 small leaves for 52 rooms at 44 % utilisation gives every leaf a high perimeter/area ratio (crinkliness) and rooms below their target area (size). So the measured candidate lever is construction granularity / leaf shape (fewer, larger leaves; merge or share leaves across same-class rooms; a coarser spine), NOT shape-aware placement and NOT more search machinery. This is a hypothesis with a measured motivation, filed as homemaker-py-c3g — it is unproven and must be A/B'd against the §12.2 baseline before adoption, same discipline as every lever above. It may also be that 52 distinct rooms simply cannot be well-shaped as 52 leaves at this density, i.e. the residual is the geometry floor of the slicing representation; the experiment is what decides.

12.4 Construction granularity A/B (homemaker-py-c3g) — DONE (null) + a noise finding

The c3g hypothesis tested directly. The cheap raw-seed probe (circ-per-room divisor circ_divisor, env CIRCDIV, default 3) confirmed the mechanism but also its catch: a coarser spine lowers the shape floor (maple 135→110, harbor 83→66 as div 3→∞) yet raises access/adjacency by as much, leaving the raw total floor flat-to-worse (maple 198→210, harbor 121→134). div=3 already sits near the total-floor minimum. Because §12.3 showed shape is the hard residual and access/adjacency are cheap to repair, the open question was whether that trade pays end-to-end.

• End-to-end A/B (20000 evals, staged, total fails at budget; div=3 reuses §12.3):

  programme	div=3 (baseline)	div=6	div=8
  maple-court	136.0	137.0	134.3
  harbor	74.0	75.3	—

  Per-seed: maple div6 143/122/146, div8 132/138/133; harbor div6 65/76/85. Every arm is within ±1.7 of baseline — inside the noise floor (below) — with a huge per-seed spread (maple div6 122–146). Null result: coarsening the spine does not pay end-to-end. The raw-probe prediction held — the shape-floor gain is cancelled by access/adjacency damage that is not free to repair after all.

• A reproducibility finding surfaced en route (homemaker-py-xcy, P2 bug) — later RE-DIAGNOSED and FIXED (2026-06-22). The div=3 control gave 129 vs §12.3's 126 for the same maple seed 0. The first diagnosis blamed operators._assign_adjacency_aware iterating id()-ordered Python sets of Nodes — this was wrong. That function already ends every max/min with a unique leaf-idx tiebreak, and its set unions are used only for membership, so order never leaks: constructive_topology(seed=0) is byte-identical across processes for every example programme (stable sha1, e.g. maple e688f744326b). The "sig hashes 4480 vs 16064" was a measurement artifact — Python's builtin hash() of a string is salted per process (PYTHONHASHSEED), so an identical signature hashes to different ints run-to-run (reproduced 51920/5342/59970 for one identical string). Use genome.signature equality or a stable hash, never builtin hash(), to compare topologies. The real cause was parallel-only: driver._run_batch admitted futures via concurrent.futures.as_completed, i.e. in completion order, and admit() is order-sensitive (accrues n_evals per result; keeps the first individual of an equal-key tie as best). A long parallel run diverged 167 vs 161 fails (maple seed 0) — the true source of the ±3..6 "noise". Fix: iterate the futures in submission order (for f in futs: f.result(); all still run concurrently), reproducing the serial admission sequence. After the fix two workers=4 runs are byte-identical (162 fails). Serial (workers=1) was already byte-for-byte reproducible. Implication for the §11/§12 ledger: per-seed numbers are reproducible only at a fixed worker count. Serial≠parallel is expected (children/iteration = 1 vs n_workers changes batch granularity, hence the search), not nondeterminism. Any A/B that compared runs at different worker counts — or any pre-fix parallel run — conflated this with a real effect; sub-±3 effects (the §12.3 +3-4 negatives, the §12.4 ±1.7) should be re-run at a single fixed worker count before being trusted as magnitudes.

• Verdict: keep circ_divisor=3 default; the granularity lever is null. Together with §12.3 this closes the residual-reduction question for now from both sides: neither search machinery (§12.3) nor construction granularity (§12.4) moves the maple/harbor geometry residual beyond noise. The weight of evidence is that the residual is the geometry floor of the slicing representation at this room density — 52 distinct rooms as 52 adjacency-connected leaves inherently incur ~135 shape+access fails. Further progress, if wanted, needs either the determinism fix (to even see sub-±3 effects) or a representational change beyond the slicing tree — not another seed/search tweak at this scale.

13. Phase 8 — lowering the geometry/shape floor (homemaker-py-erc)

Phase 8 runs DIAGNOSTICS FIRST to decide which floor-lowering lever to invest in, then the construction/inner-loop experiments in dependency order. §12.3/§12.4 established the floor is real (search machinery and circulation-granularity both null); the open question is what about the floor — per-leaf slicing tax, or fixable cuts — and where the slack hides (util 0.44 yet rooms undersize).

13.1 Diagnostic A: per-leaf shape-fail vs density/granularity (homemaker-py-erc.1) — DONE

GATES leaf-sharing (erc.3) vs compactness-cuts (erc.5). Reads only; no A/B, no baseline reproduction. Builds the §12.2 constructive seed (adjacency- and proportion-aware), lays it out at the proportion-aware TARGET geometry — the squarest geometry the inner loop warm-starts from, exactly as operators.predicted_shape_fails — then counts size/width/proportion/crinkliness fails per leaf. Script: experiments/diag_leaf_shapefail.py (seeds 0/1/2).

View 1 — cross-programme density sweep (per-leaf rate = shape-fails ÷ leaves):

programme	rooms	leaves	l/room	util	shape	/leaf	siz/lf	wid/lf	prp/lf	crk/lf
programme-house	6	9.0	1.50	0.83	8.0	0.889	0.000	0.519	0.222	0.148
harbor-house-l0	13	13.0	1.00	0.31	19.0	1.462	0.231	0.154	0.487	0.590
harbor-house	37	45.0	1.22	0.50	87.3	1.941	0.519	0.378	0.296	0.748
maple-court	52	73.0	1.40	0.54	134.3	1.840	0.562	0.224	0.251	0.804

Per-leaf shape-fail SATURATES at ~1.8–1.9 once the programme is non-trivial: the tiny 6-room case is the only outlier (0.89, no size fails, high util 0.83), and the three larger programmes cluster at 1.46→1.94 with no dependence on leaves-per-room (which barely moves, 1.0–1.5). Cross-programme "density" here is confounded by plot/room-mix/util (util swings 0.31→0.83), so this view alone cannot separate "intrinsic per-leaf tax" from "more leaves, worse cuts".

View 2 — synthetic granularity sweep, maple-court, room set FIXED, leaf count varied via the c3g circ_divisor knob (the controlled test):

circ_div	leaves	l/room	util	shape	/leaf	siz/lf	wid/lf	prp/lf	crk/lf
2	81.0	1.56	0.46	139.0	1.716	0.477	0.169	0.226	0.844
3	73.0	1.40	0.54	134.3	1.840	0.562	0.224	0.251	0.804
4	68.0	1.31	0.44	126.7	1.863	0.495	0.294	0.289	0.784
6	65.0	1.25	0.47	126.0	1.938	0.554	0.303	0.262	0.821
9	63.0	1.21	0.50	116.3	1.847	0.481	0.280	0.339	0.746

With the programme held fixed, the per-leaf shape-fail rate is FLAT as leaf count varies (1.72–1.94, no monotone trend; if anything a slight rise as you coarsen, since the survivors are bigger but still fail). Crucially TOTAL shape fails track leaf count almost linearly (139 → 116 as leaves 81 → 63), and crinkliness — the dominant factor (crk/lf ≈ 0.75–0.84) — is itself flat per leaf. Each leaf carries a roughly fixed ~1.8 shape-fail tax regardless of how finely the same plot is sliced. The target layout already picks the squarest-aspect cut direction (_size_divisions_from_targets chooses rotation for squarest children), so leaves are already near-optimally shaped and STILL fail at ~1.8/leaf — there is little compactness headroom left to recover at fixed leaf count.

VERDICT — per-leaf shape-fail is FLAT vs slicing density (controlled view 2) → the floor is INTRINSIC to per-leaf slicing, not to cut quality. By the diagnostic's decision rule this prioritises leaf-sharing (erc.3 — fewer leaves for the same rooms is the only lever that moves the floor) and deprioritises compactness-aware cuts (erc.5 — cuts are already squarest and still pay the tax; little headroom at fixed count). Note this is not the §12.4 circ_divisor null: that lever removed CIRCULATION leaves and the shape gain was cancelled by access/adjacency damage; leaf-sharing removes ROOM-leaf count (multi-room leaves) without disturbing the circulation spine, so the access penalty that killed c3g need not apply. Recommendation: close/deprioritise erc.5, advance erc.3.

13.2 Diagnostic B: undersize-despite-slack localization (homemaker-py-erc.2) — DONE

GATES plot-fill construction (erc.4) vs the inner-loop slack-expansion term (erc.6). The §12.3 paradox: plot utilisation ≈ 0.44 (over half the plot "empty") yet rooms are UNDERSIZE. Where is the slack stranded, and at which stage should it be spent? Reads only. Builds the §12.2 constructive seed (whose geometry already sits at the proportion-aware TARGET ratios — the inner-loop warm start, so it is the "before" state), measures per sized-room leaf achieved-vs- target area and a plot accounting, then runs innerloop.optimise (nm, budget 80 = the bootstrap child budget) and re-measures. Script: experiments/diag_slack_localization.py (harbor-house + maple-court, seeds 0/1/2).

programme	state	sizeF	util	tgtFill	ā/t	%und	%ovr	sized%	circ%	out%
harbor-house	BEFORE (target)	23.3	0.50	0.50	1.43	43	12	50	46	4
harbor-house	AFTER (innerloop)	21.7	0.49	0.50	1.40	54	16	49	46	4
maple-court	BEFORE (target)	41.0	0.54	0.44	1.46	42	15	54	43	3
maple-court	AFTER (innerloop)	37.3	0.53	0.44	1.46	42	19	53	44	3

(util = sized-room area ÷ plot; tgtFill = Σ room targets ÷ plot; ā/t = mean achieved/target over sized leaves; %und/%ovr = leaves below 0.9× / above 1.1× target.)

The "56 % empty plot" is a misreading. Sized rooms already occupy ~50–54 % of the plot and hold 1.4–1.5× their aggregate target area (util > tgtFill); the other ~46 % of the plot is circulation, not claimable void (out/uncovered is only 3–4 %). So rooms are over-provisioned in total — there is no unused plot to hand them.

The size fails are pure MALDISTRIBUTION, set by SLICING POSITION not by need. The median room sits right at target (a/t ≈ 1.0), but a long undersize tail (p25 ≈ 0.35, min 0.05) starves while a few giant leaves balloon (max 6.8× harbor, 14.7× maple). Decisively, the same room type with the same target lands at both extremes — harbor r (target 10 m²) appears at 68 m² (6.8×) and 2.3 m² (0.23×); maple n (target 60 m²) appears near target and at 2.7 m² (0.05×). A leaf's area is dictated by its depth/position in the binary slicing tree (ratios multiply down the ancestry), essentially independent of its target; _size_divisions_from_targets sets each local cut proportionally but cannot defeat the multiplicative depth effect. This is the same root cause as §13.1 (the binary-slicing structure), now seen on the size axis.

The inner loop cannot repair it. Over budget 80 the size fails move only −1.6 (harbor) / −3.7 (maple), util is flat-to-down, and %undersize is flat-to- worse (43→54 harbor). On a frozen topology the equal-offset ratio DOF cannot shrink a 14× leaf to feed a starved one without trading into shape fails (the 0.5ⁿ cliff, §4.5, blocks it), and the symmetric size Gaussian (quality_size is gaussian(area, 1, target, σ)) gives no net reward for redistribution.

VERDICT — the slack is depth-driven maldistribution inside the room set, not unclaimed plot, and the inner loop (frozen-topology ratios) provably cannot move it. This falsifies plot-fill construction in the "claim the empty plot" sense (erc.4 as scoped — rooms are already 1.4× over aggregate target; the empty- looking plot is circulation) and deprioritises the inner-loop slack-expansion term (erc.6 — wrong DOF: ratios on a frozen tree cannot undo a depth-set 14× leaf, and the blocker is position not a missing expansion reward). The fix must live UPSTREAM of the inner loop, where leaf area is actually decided: construction that balances tree DEPTH so equal-target rooms land at comparable depth / caps giant leaves (re-scope erc.4 from "plot-fill" to depth-balanced / giant- splitting construction), reinforcing §13.1's call to advance leaf-sharing (erc.3) for the starved tail. Recommendation: re-scope erc.4, deprioritise erc.6.

13.3 Experiment: leaf-sharing / multi-room leaves (homemaker-py-erc.3) — DONE

The lever §13.1 named as the only one that moves the floor: collapse same-code rooms into fewer, larger shared leaves so the per-leaf ~1.8 shape tax is paid once per group instead of once per room. Unlike c3g (§12.4) this removes ROOM-leaf count, not circulation, so the access/adjacency penalty that sank c3g need not apply.

Mechanism — explicit, type-guarded per-leaf multiplicity. A construction stamps leaf.share = k and leaf.share_type = code on each shared leaf (operators._share_rooms groups a sized, multi-instance code into runs of ≤ N = leaf_share_factor; _leaf_mult_from_plan stamps the survivors and _size_divisions_from_targets sizes them to k × target). The fitness honours k only while leaf.type == leaf.share_type (graph.leaf_share), so any retype/undivide silently invalidates a stale share — the mutation operators need no resets, and a small leaf can never retype its way into claiming rooms it does not provide. Two scoring sites, both gated by a default-OFF leaf_sharing key (controls reproduce the §12.2 baseline exactly — 214 tests pass with it off):

• graph.check_space_counts counts coverage (Σ per-leaf k) against req.count, so one shared leaf satisfies several same-code rooms with no missing fail;
• fitness.quality_size centres the size Gaussian on k × target (σ scaled by k). quality_proportion/quality_width need no change — a proportionally-scaled leaf keeps its aspect and only gets wider.

Design history: the first cut recovered k from area (round(area/target)) to avoid genome state, but the §13.2 depth maldistribution left shared leaves below k × target, so round undercounted and 17–44 missing fails leaked back (harbor share3+il: 87.3 total, 16.7 missing; the inner loop could not close it — frozen-topology ratios, §13.2). Switching to explicit share (an undersize shared leaf is present → a light size fail, not a heavy missing fail) closes the leak. Because the phenotype tree is never rebuilt from the genome in the hot path (genome.decode is unused; operators edit dom.Node trees in place), the two Node fields survive the whole search via deepcopy without threading through GNode/encode/decode; .dom serialisation emits share only on a live shared leaf.

Floor probe (experiments/diag_leaf_sharing.py, harbor + maple, seeds 0/1/2) — build the §12.2 seed both ways, score at the seed geometry and again after innerloop.optimise (nm, budget 80) under the same objective. Averaged fails:

programme	mode	leaves	total	missing	size	crink
harbor	OFF +il	45.0	120.3	0.0	21.7	33.7
harbor	share2 +il	31.7	86.0	0.0	15.3	22.0
harbor	share3 +il	25.7	73.3	0.0	12.7	17.7
maple	OFF +il	73.0	194.7	0.0	37.3	58.3
maple	share2 +il	52.0	145.7	0.0	25.7	41.3
maple	share3 +il	47.0	133.0	0.0	21.0	39.3

The floor moves and the leak is closed — share3 cuts the achievable floor −39 % harbor (120.3 → 73.3) / −32 % maple (194.7 → 133.0) with zero missing fails, and the missing did not re-emerge as size fails (size still falls, 22→13 harbor / 37→21 maple). The drop is exactly where §13.1 predicted: shape factors fall with leaf count (harbor leaves 45→26, crinkliness 34→18). Larger leaf_share_factor helps monotonically here (share2 → share3), bounded by leaf_share_max (default 4).

Verdict — leaf-sharing is the floor-mover §13.1/§13.2 called for: −32…−39 % on the achievable floor, no missing-fail leak. The flag is threaded through the staged driver (driver.search/search_staged → constructive_topology / lift_base_to_storeys) and exposed for the A/B via LEAFSHARE/LEAFSHAREFAC in run_staged_search.py (which injects the objective into the inner-loop and final-score fitness, both arms on one programme dir). Smoke-tested end-to-end (harbor, staged, leaf_sharing+factor 3: re-score OK).

End-to-end A/B (experiments/run_leafshare_ab.sh, staged search, 20 000 native evals, seeds 0/1/2, leaf_share_factor=3 vs the default-OFF baseline, final native re-score):

programme	baseline (s0/1/2)	mean	leaf-share f3 (s0/1/2)	mean	Δ
maple-court	129 / 148 / 134	137.0	78 / 89 / 92	86.3	−37 %
harbor-house	72 / 81 / 69	74.0	50 / 52 / 49	50.3	−32 %

VERDICT — leaf-sharing is the first lever to move the Phase-8 floor, and it moves it decisively: −37 % maple / −32 % harbor end-to-end. The default-OFF baseline arm reproduces §12.2 exactly (maple 137.0 vs 136.0, harbor 74.0 vs 74.0), so the gap is the lever, not drift; and the separation is total — every share run beats every baseline run on the same programme (maple worst-share 92 < best-baseline 129; harbor 52 < 69). Fewer leaves also make each eval cheaper, so the share arm runs ~35 % faster at equal budget. This is the §13.1/§13.2 prediction realised: the per-leaf ~1.8 shape tax is intrinsic, so collapsing 52→47 / 45→26 room-leaves is what lowers the floor — and the explicit type-guarded multiplicity (vs the area-derived first cut) is what lets the gain survive without a missing-fail leak. Scoreboard update: this is the 5th win from construction/seed quality and the first floor-mover of Phase 8; it confirms §12.3's thesis that only lowering the geometry floor (not search machinery) can help. Follow-ups: surface leaf_sharing on the homemaker-evolve CLI / as a patterns.config key for production use, sweep leaf_share_factor/max_share, and test the erc.4 depth-balancing synergy (shared leaves at correct absolute area) now that the leak is closed.

13.4 Experiment: depth-balanced construction (homemaker-py-erc.4) — DONE (modest)

The lever Diagnostic B (§13.2) called for. B localized the size fails to depth-driven maldistribution: a leaf's area is the product of cut fractions down its ancestry in the binary slicing tree, so the same-target room lands at 0.05× and 14.7× by slicing position, and the inner loop (frozen topology) provably cannot move it. The fix must live in construction, where leaf area is decided.

Mechanism — depth-balanced tree growth. _grow_leaves grew the tree by splitting a random leaf each step → a random caterpillar whose leaves sit at wildly different depths. The depth_balanced flag instead always splits a shallowest current leaf (operators._leaves_with_depth), growing a near-complete binary tree so all leaves land at comparable depth. The proportion-aware sizing pass (_size_divisions_from_targets) then hits each target with cut fractions near their proportional value instead of compounding fmin/fmax clamp error down a deep spine. Type-agnostic and topology-only — it changes which leaf is split, not the type assignment or the proportional sizing — so it composes with adjacency-aware seeding and leaf-sharing unchanged. Default OFF (214 tests pass with it off); threaded through constructive_topology / lift_base_to_storeys → driver.search/search_staged, exposed via DEPTHBAL in run_staged_search.py.

Floor probe (experiments/diag_depth_balance.py, harbor + maple, seeds 0/1/2) — build the §12.2 seed OFF vs balanced (vs balanced+share3 as the erc.7 preview), score at the seed geometry and after innerloop.optimise (nm, budget 80). dDep = leaf-depth spread (max−min); maxR/minR = max/min achieved/target over sized leaves; %und = fraction below 0.9×target. Averaged:

programme	mode	leaves	total	size	crink	%und	maxR	minR	dDep
harbor	OFF +il	45.0	120.3	21.7	33.7	54.2	12.0	0.1	7.0
harbor	bal +il	45.0	106.0	21.0	31.3	25.0	8.3	0.2	1.0
harbor	bal+sh3 +il	25.7	65.3	11.7	17.3	29.0	4.1	0.3	1.0
maple	OFF +il	73.0	194.7	37.3	58.3	42.3	16.4	0.0	6.7
maple	bal +il	73.0	173.0	37.3	61.7	22.4	6.2	0.2	1.0
maple	bal+sh3 +il	47.0	113.7	22.3	38.7	17.7	7.9	0.4	2.0

The depth spread collapses (7→1) and the giant leaf is tamed — maxR 12.0→8.3 harbor / 16.4→6.2 maple, %undersize 54→25 / 42→22 — at equal leaf count (45 / 73, no rooms removed). The achievable floor drops −12 % harbor (120.3→106.0) / −11 % maple (194.7→173.0) purely from tree shape, with zero missing-fail leak. Most of the total drop is in width/proportion (the giants were the wide, wrong-aspect leaves), not the soft size Gaussian (size barely moves). Crucially it is additive with leaf-sharing: bal+sh3 beats §13.3's share3-alone floor (harbor 65.3 vs 73.3, maple 113.7 vs 133.0) — balancing places the survivors of sharing at correct absolute area, exactly the synergy erc.7 was filed for.

End-to-end A/B (experiments/run_depthbal_ab.sh, staged search, 20 000 native evals, seeds 0/1/2, DEPTHBAL=1 vs default-OFF baseline, leaf-sharing OFF in both arms, final native re-score):

programme	baseline (s0/1/2)	mean	depth-bal (s0/1/2)	mean	Δ
maple-court	129 / 148 / 134	137.0	142 / 126 / 119	129.0	−5.8 %
harbor-house	72 / 81 / 69	74.0	67 / 77 / 71	71.7	−3.2 %

VERDICT — depth-balancing is a real but MODEST standalone lever: −5.8 % maple / −3.2 % harbor, much smaller than the −11/−12 % the seed-floor probe predicted, and the arms OVERLAP (maple balanced worst 142 > baseline best 129; harbor balanced 77 > baseline 69) — not the total separation leaf-sharing showed (§13.3, every share run beat every baseline). The default-OFF baseline reproduces §12.2 exactly (maple 137.0 vs 136.0, harbor 74.0 vs 74.0), so the comparison is clean and the small gap is the lever, not drift. The 20k search erodes most of the seed-floor advantage: the random-caterpillar arm partly catches up via divide/undivide mutations over the budget, so an 11 % lower seed floor realises only ~5 % at convergence. This is the mirror image of the §12.3/§11 thesis — seed quality helps, but here the search recovers enough of the gap that depth-balance alone is marginal, unlike the structural leaf-count cut of §13.3 which the search cannot undo (you cannot mutate 26 leaves back up to 45 cheaply).

Its real promise is the additive floor with leaf-sharing: the probe showed bal+sh3 beats share3-alone by a wide margin (harbor 65.3 vs 73.3, maple 113.7 vs 133.0) because balancing places the survivors of sharing at correct absolute area. The decisive end-to-end test is therefore erc.7 (depth-balance × leaf-sharing synergy + factor sweep), not depth-balance in isolation. Recommendation: keep depth_balanced (default OFF, no test/runtime cost, same leaf count), advance erc.7 to test whether the additive seed floor survives to convergence when stacked on the share lever that the search cannot erode. Scoreboard: a 6th construction/seed lever, but the first Phase-8 lever whose end-to-end gain is materially smaller than its seed-floor gain — a useful calibration of how much seed-floor reduction the staged search actually banks.

13.5 Experiment: leaf-sharing × depth-balancing synergy (homemaker-py-erc.7) — DONE (synergy confirmed)

The decisive test the §13.4 floor probe set up. Depth-balancing was only MODEST standalone (§13.4: −5.8 % maple / −3.2 % harbor, overlapping arms) because the 20k search erodes a tree-shape seed advantage via divide/undivide. But the probe showed bal+sh3 beats share3-alone at equal leaf count (harbor 65.3 vs 73.3, maple 113.7 vs 133.0) — additive on the leaf-COUNT cut the search cannot erode (you cannot mutate 26 leaves back up to 45 cheaply). Question: does that additive seed-floor advantage survive to convergence once stacked on the share lever that the search can't undo?

Setup (experiments/run_synergy_ab.sh, staged search, 20 000 native evals, seeds 0/1/2, final native re-score). Both arms hold LEAFSHARE=1 at factor 3 (the §13.3 winner). The control arm is share-alone (DEPTHBAL=0) and must reproduce §13.3; the experiment arm adds DEPTHBAL=1 (depth-balanced grow). One programme dir per programme — run_staged_search.py injects leaf_sharing into the whole pipeline so both arms score under the same relaxed objective.

programme	share-alone db0 (s0/1/2)	mean	bal+share db1 (s0/1/2)	mean	Δ
maple-court	78 / 89 / 92	86.3	76 / 85 / 86	82.3	−4.6 %
harbor-house	51 / 52 / 49	50.7	41 / 41 / 38	40.0	−21.1 %

The control arm reproduces §13.3 exactly (maple 86.3 = 86.3, harbor 50.7 ≈ 50.3), so the comparison is clean and the gap is the lever, not drift.

VERDICT — the synergy is REAL and SURVIVES to convergence, unlike depth-balance alone. Harbor is decisive: −21 %, every seed improves by 10–11 fails, and the arms are non-overlapping (bal+share worst 41 < share-alone best 49) — the total separation §13.4-standalone never reached. Maple is modest but uniform: −4.6 %, every seed improves (−2 / −4 / −6), ranges overlapping. This is the mirror image of §13.4: there the seed-floor advantage washed out because the search could erode tree shape; here depth-balancing rides on top of the leaf-COUNT cut that the search cannot erode, so balancing the survivors of sharing onto their correct absolute k×target area banks. The probe prediction held — bal+sh3 beats share3-alone end-to-end, not just at the seed.

Factor sweep (experiments/run_sharefactor_sweep.sh, leaf_share_factor 2/4 under bal+share, seeds 0/1/2, vs the factor-3 bal+share above):

programme	factor 2	factor 3	factor 4
maple-court	92.7	82.3	83.3
harbor-house	53.0	40.0	39.7

Factor 3 confirmed as the robust default once depth-balancing is stacked. Factor 2 regresses on both (maple +10.4, harbor +13.0) — too little sharing leaves more, smaller rooms for the depth-balance to fix. Factor 3 and 4 are statistically tied (maple f3 wins by 1.0, harbor f4 wins by 0.3 — both inside seed noise, ranges overlap), so factor 4 buys nothing material and gives up maple while risking larger shared leaves. leaf_share_max (scoring cap, default 4) already credits every multiplicity at factor ≤4 with zero missing-fail leak (final re-score OK in all runs), so it needs no separate sweep at the chosen factor 3.

Recommendation: make depth_balanced + leaf_sharing (factor 3) the default Phase-8 stack (both default OFF today, no test/runtime cost). Scoreboard: the first Phase-8 lever combination whose end-to-end gain (harbor −21 %) exceeds either lever alone (share −32 %→ this stacks a further −21 % on top; depth-balance −3 % alone), confirming the §13.4 thesis that levers the search cannot erode compound where shape levers do not.

13.6 Experiment: interior-O courtyard / light-well seeding (homemaker-py-ld2) — DONE (positive on dense floors)

The construction lever aimed at the erc crinkliness residual directly. The adjacency-aware seeder placed ONE O on the most PERIPHERAL leaf — where the adjacent rooms already have plot facade, wasting the daylight source — while the landlocked rooms (no facade, no uncovered-O neighbour → area_outside ≈ 0 → crinkliness ≈ 0 → fail) get nothing. This arm instead seeds O as INTERIOR light wells (the most-landlocked leaves first, greedily spread so each illuminates a fresh room set) and scales their count with the room count.

Seed diagnostic first (the epic mandate). Decomposing every crinkliness fail in the bal+share seed by side of the gaussian: all are UNDER-exposed (crink < 0.62, landlocked) — zero over-exposed slivers (crink > 21.7). So the residual is genuine under-daylighting, validating the premise (and correcting the epic's loose "high perimeter/area" wording — the failing leaves are starved, not over-walled). The naive default outside_divisor=6 was null (too few/small wells; harbor seed 147→142, crinkliness even rose). Sweeping the divisor found odiv=3 seed-optimal: harbor seed fails 147→129 (−18), maple 219→206 (−14), landlocked fails down — at the cost of more leaves (harbor +4, maple +8). Because it ADDS leaves it carries the §13.4 wash-out risk, so the convergence A/B decides.

Setup (experiments/run_interioro_ab.sh, staged search, 20 000 native evals, seeds 0/1/2, final native re-score). Both arms hold the default stack LEAFSHARE=1 (factor 3) + DEPTHBAL=1. Control is interior-OFF (peripheral O) — must reproduce §13.5 bal+share; experiment adds INTERIORO=1 (odiv=3).

programme	peripheral off (s0/1/2)	mean	interior odiv=3 (s0/1/2)	mean	Δ
maple-court	77 / 85 / 86	82.7	74 / 78 / 89	80.3	−2.8 %
harbor-house	41 / 43 / 38	40.7	28 / 39 / 35	34.0	−16.4 %

The control reproduces §13.5 (maple 82.7 ≈ 82.3, harbor 40.7 ≈ 40.0), so the gap is the lever, not drift.

VERDICT — positive on the DENSE floor, marginal elsewhere. Harbor is the win the issue targeted (it named "harbor-house ~19 rooms/floor" as where the single peripheral O is wasted): −16.4 %, every seed improves (−13 / −4 / −3), arms nearly non-overlapping (interior worst 39 ≈ control best 38). Maple is −2.8 %, within seed noise — two seeds improve, one regresses (+3), ranges overlap. This is the §13.4 pattern: the seed advantage (harbor −18, maple −14) survives roughly a THIRD on harbor but mostly washes out on maple, because a dense floor has enough landlocked rooms that the daylight gain outweighs the added-leaf tax, whereas on the sparser maple the +8 leaves nearly cancel it. Unlike depth-balance-alone (§13.4) which washed out entirely, interior-O holds on the dense floor.

Recommendation: make interior_outside (odiv=3) a default-ON Phase-8 lever (default OFF today). Harbor is decisive and maple is net-neutral (mean still −2.8 %, no programme regresses on mean), so the flip is strictly ≥ on both means and matches the dense-programme target. Follow-up homemaker-py-* flips the default (mirroring pll after erc.7). outside_divisor left at 3 (seed-optimal joint); a finer odiv sweep under convergence is low-prior given maple's marginal response.

§13.7 High-budget harbor floor probe — 71d go/no-go (homemaker-py-71d.1)

The whole Phase-8 construction stack is now default-ON (leaf-sharing factor 3, depth-balanced, interior-O odiv=3, circ_divisor 3, proportion-aware). Cumulative floor vs the §12.2 leu.2 baseline (all under the §13.3 leaf-share-relaxed objective, staged, seeds 0/1/2): maple 136.0 → 80.3 (−41 %), harbor 74.0 → 34.0 (−54 %) — the entire drop from construction levers, zero from search machinery, exactly the epic's thesis.

This probe decides 71d (failure-directed topology-repair operator). 71d's premise: the pre-stack harbor 3M-eval plateau (3m.dom, re-scores to 27 fails) is dominated by 13 crinkliness fails, characterised as landlocked rooms (area_outside == 0 → crink == 0 → quality_uncrinkliness hits the if not crink: return 0.0 branch, fitness.py:355 → guaranteed fail for ALL ratios), repairable only by topology — specifically interior O courtyards / facade access. That fix has since shipped DEFAULT-ON (interior_outside, §13.6), so the premise needs re-measuring on the current stack.

Setup (experiments/probe_harbor_floor.py, harbor-house, full default stack, seed 0, 500 000 native evals, staged, SERIAL — the leaf-share relaxed objective is injected by a parent-process fitness.load_config monkeypatch that does NOT reach ProcessPoolExecutor workers, so every §13.x floor run is serial; see homemaker-py-x3b for the production CLI wiring). The probe re-scores the best and splits each crinkliness fail into landlocked (area_outside == 0, 71d's ratio-invariant target) vs under-exposed (0 < crink < target, reachable by ratios/seeding).

metric	old 3M plateau (pre-stack)	full default stack, 500k
total fails	27	20
crinkliness	13	4
landlocked crinkliness	~13	2
top residual class	crinkliness	edge-too-long (6)

Final residual histogram (20 fails): 6 edge-too-long, 4 crinkliness, 4 size, 2 proportion, 2 width, 2 level-not-connected. Re-score OK (relaxed config consistent end-to-end).

VERDICT — NO-GO on 71d as scoped; interior-O already dissolved its target. The landlocked-crinkliness block 71d was built to repair collapsed from ~13 to 2 of 20 — because interior-O seeding is 71d's named fix (interior O courtyards) and now does it by default. Crinkliness is no longer the dominant class; the residual is small and spread across edge-too-long / size / proportion / width / connected, with no concentrated ratio-invariant block for a targeted repair operator to attack. A deterministic repair operator remains a genuine new operator class (not refuted by the §11.4/§11.5/§12.3 search-machinery losses), but its expected value is now low: its highest-leverage target is gone, and what remains is diffuse. Recommendation: close 71d (and prerequisites 7u5/jrb/u8x) as superseded-by-construction; the floor 71d targeted was lowered by interior-O, not by search machinery — consistent with the epic scoreboard. The deprioritised P4 levers erc.5 (compactness cuts — Diag A: floor is leaf-count not cut-quality, and leaf-sharing over-delivered) and erc.6 (inner-loop slack — Diag B: wrong DOF) close wont-fix on unmet revisit conditions, completing the epic.

Caveat (honest): single seed, 500k not 3M, relaxed config vs the old strict standalone 27 — so the 20-vs-27 total is not a clean apples-to-apples. The robust signal is the composition collapse (crinkliness 13→4, landlocked 13→2), which the §13.6 three-seed data corroborates (interior-O reliably cuts harbor landlocked fails). Follow-up observation, not part of this verdict: edge-too-long is now the single largest harbor class (6) — a candidate seed for any future floor work, distinct from the crinkliness regime Phase-8 addressed.

13.8 Experiment: share-aware edge-too-long cap (homemaker-py-hph) — DONE (positive, harmless)

§13.7's follow-up observation (edge-too-long = harbor's top class, 6 fails) is the seed. Dissection first (experiments/diag_edge_too_long.py on the 500k probe best): the 6 fails are only 2 distinct locations. (1) DOMINANT ~4/6: leaf lllr is a share=3 leaf — one quad holding 3 rooms (247 m², edges 15–17 m, aspect 1.2, NEARLY SQUARE). Its walls exceed the flat 8 m cap purely because it aggregates 3 rooms — a leaf-sharing REPRESENTATION ARTIFACT, not a design flaw. §13.3 relaxed size/missing for shared leaves (quality_size centres on k×target) but edge_cost (fitness.py) and outside_edge_cost still used a flat 8 m regardless of leaf.share — the same §13.3 leak on a different measure. (2) ~2/6: leaf llll, a 1.2 m × 16.7 m sliver (aspect 14) — a REAL narrow-room pathology, already independently caught by width/proportion; its edge-too-long is the wall it shares with lllr. No corridors involved.

Fix. New Fitness._edge_cap(*leaves) scales the 8 m cap by the largest type-guarded leaf_share (graph.leaf_share, §13.3's helper) among the adjoining leaves, mirroring quality_size's k×target; non-shared leaves keep the flat cap. Used by both edge_cost (interior wall, max share of the two leaves) and outside_edge_cost (one leaf). Gated behind a new share_edge_cap config knob (SHAREEDGE env), default OFF, so the §13.x controls reproduce. On the probe best the lever clears all 6 edge-too-long (20→14 total fails); the llll sliver stays flagged via width/proportion.

Setup (experiments/run_shareedge_ab.sh, full Phase-8 default stack LEAFSHARE=1/fac3 + DEPTHBAL=1 + INTERIORO=1/odiv3, staged, 20 000 native evals, seeds 0/1/2, final native re-score). Control SHAREEDGE=0 (flat cap) — must reproduce §13.6/§13.7; experiment SHAREEDGE=1.

programme	flat cap off (s0/1/2)	mean	share-aware on (s0/1/2)	mean	Δ
maple-court	74 / 78 / 89	80.3	73 / 78 / 71	74.0	−7.9 %
harbor-house	28 / 41 / 35	34.7	27 / 39 / 27	31.0	−10.6 %

The control reproduces §13.7 (maple 80.3 exactly, harbor 34.7 ≈ 34.0), so the gap is the lever, not drift.

VERDICT — positive and HARMLESS; recommend default-ON. Both programmes improve on the mean with zero regressions across all 6 seeds: harbor every seed (−1/−2/−8), maple two flat/down + one −18 (seed2). The asymmetry of magnitude (maple's big seed2 swing) is search noise, but the direction is structural: the lever only ever removes a false-positive fail on an aggregate shared leaf — it cannot add one (non-shared leaves are untouched), so it is monotone-harmless on the objective. This is unlike the §13.4-family construction levers that trade leaves for fails; there is no tax to wash out. Recommendation: flip share_edge_cap default-ON for leaf-sharing runs (it is the §13.3 relaxation completed on the wall measure), mirroring the pll/interior_outside default flips. A follow-up issue flips the default + rebaselines the §13.x floor numbers (harbor 34.7→31.0, maple 80.3→74.0 become the new full-stack baseline). Repro: experiments/diag_edge_too_long.py, experiments/run_shareedge_ab.sh.

13.9 Flip share_edge_cap default-ON + rebaseline §13.x floor (homemaker-py-rq2) — DONE

Acting on the §13.8 recommendation. Fitness.__init__ now defaults the share-aware edge cap to self._leaf_sharing when share_edge_cap is unset: under leaf-sharing the cap is ON, mirroring the pll bal+share and §13.6 interior_outside default flips. An explicit share_edge_cap=False still reproduces the pre-flip control arm, so the §13.8 A/B and any §13.x control stay reproducible (run_staged_search.py now pins conf["share_edge_cap"] = share_edge explicitly in both arms; the SHAREEDGE override is preserved). Non-sharing runs (every example patterns.config, where leaf_sharing is absent) are untouched — a control re-score of programme-house reproduces bit-for-bit.

New §13.x full-stack floor (Phase-8 default stack, staged, 20 000 evals, seeds 0/1/2): maple-court 80.3 → 74.0, harbor-house 34.7 → 31.0 — the share-aware arm from §13.8 becomes the baseline. test_edge_cap_flat_when_lever_off_even_with_sharing now pins share_edge_cap=False; test_edge_cap_defaults_on_under_leaf_sharing guards the flip. 222 tests pass.

13.10 Productionise leaf-sharing: per-code share + CLI wiring (homemaker-py-x3b) — DONE

Make the §13.3 lever a first-class, programme-author-controllable feature instead of an experiment-only env var + monkeypatch. Three pieces:

1. Per-code grain (SpaceReq.share). patterns.config spaces accept an optional share: N → SpaceReq.share (int, default 1 = not shareable; a has_share flag distinguishes an explicit share: 1 from the default). operators._share_grain(req, leaf_share_factor) resolves each code's grain from the global selector:

• leaf_share_factor == 0 — per-code opt-in: a code shares iff it sets share: N≥2; this is the safe default-on philosophy (sharing off unless the author asks, per space).
• leaf_share_factor ≥ 2 — global mode: every sized code shares at the factor, with an explicit share overriding (share: 1 opts a code OUT, share: N sets that code's grain to N). Reproduces the §13.3 experiment with no edits to example programmes (so §13.3/§13.9 baselines stay reproducible).

Only sized codes are ever shareable (an unsized c/o/s absorbs slack — no target to centre k rooms on). _share_rooms now groups per resolved grain.

2. End-to-end conf injection. The §13.3 scoring sites gate on a leaf_sharing conf key, but example patterns.config files don't set it — the experiment harness monkeypatched fitness.load_config to inject it. Productionised cleanly: load_config(dir, overrides=None) merges run-level keys last, and driver.search / innerloop.optimise / NativeEvaluator / _fitness_for thread conf_overrides={"leaf_sharing": True} through both the inner-loop scorer and the off-tree grade/feasibility scorer when sharing is on. So the whole pipeline scores under the relaxed objective the shared seed targets, with no monkeypatch and no on-disk edits. (share_edge_cap's §13.9 default-ON-under-sharing derivation in Fitness.__init__ rides along automatically.)

3. CLI. homemaker-evolve gains --leaf-sharing/--no-leaf-sharing (default ON, HOMEMAKER_LEAF_SHARING) and --leaf-share-factor N (default 3, HOMEMAKER_LEAF_SHARE_FACTOR), threaded to driver.search.

Default-OFF parity holds: overrides=None leaves load_config byte-identical and _share_rooms is never reached. Smoke-checked end-to-end on harbor-house (sharing on 37 fails vs --no-leaf-sharing 95 at budget 160). 233 tests pass.

14. Island model: multi-run recombination (homemaker-py-psk) — DONE (null)

Lever (user-proposed). Perl Urb ran the search many times and kept the best, because independent runs settle into different local minima. The Python tool is deterministic per --seed, so the analog is an island model with synchronous migration: run N independent seeds to convergence (Phase A), then PRIME a fresh population with those N converged elites and run a second, crossover-heavy phase (Phase B) to recombine basins. Distinct from §11.5 (c4c.5), which injected fresh random/constructive seeds for raw diversity and landed null — here the migrants are fully-converged elites, high-quality building blocks, so the "diversity does not help" result does not directly refute it. The one untested sub-mechanism: can crossover stack wins across independent basins (run A solved cluster X, run B solved cluster Y, child inherits both)?

Design (experiments/run_island_ab.py). Three numbers per programme, all leaf_sharing OFF so controls track the §12.2 baselines (maple 136 / harbor 74), all on equal actual eval budget (the staged search has a hard ~pop·child·2 bootstrap floor, so we account r.n_evals, never the request):

• bestN@A — best-of-N over Phase A (the FREE reference; these N runs happen anyway — the legitimate descendant of Urb's multi-run habit).
• island — Phase B result: a population primed from the N Phase-A elites via the existing seed_factory+bootstrap path (no new representation), evolved at p_crossover=0.7. Total budget = Phase A + migration.
• bestN@T — best-of-N over N independent runs at the same total per seed (the "N+ longer independent runs" control). THE BAR: island must beat it.

A default-off child_probe hook (driver.search) instruments the deciding mechanism: for every crossover child it records whether the spliced child beats max/min(parent fails). Parent fails are appended to the child lineage as |pf=a,b (only when the probe is set) so the signal survives the ProcessPoolExecutor pickle round-trip an id(root) key cannot.

Result (N=4, master_seed 0, 28160 actual evals/arm, 4 workers):

programme	bestN@A	island	bestN@T	verdict	crossover beat-min-parent
harbor	73	68	67	loses by 1 (within noise)	1 / 65
maple	134	124	116	loses by 8 (decisive)	3 / 63

Verdict: NULL / negative. The island model does not beat best-of-N at equal total budget. On harbor it ties-to-loses inside the parallel noise band; on maple it loses clearly (124 vs 116) — a single longer independent run reached 116 while the migration phase, given the same budget, stalled at 124. The migration phase buys nothing a longer independent run does not.

The mechanistic probe explains why (the deciding diagnostic). Crossover across independently-converged elites almost never synthesizes: of ~64 crossover children only 1/65 (harbor) and 3/63 (maple) beat the better parent, with a best fail-drop of just 2 and 5. This confirms the issue's alignment hypothesis: operators.crossover is area-matched subtree exchange, but two independently evolved trees encode similar arrangements at different paths/areas (the encoding is non-canonical — 9gp closed negative), so the splice is mostly disruptive, not combinatorial, and the inner loop re-solves ratios at the boundary (spliced quality not preserved). The null is therefore mechanistic, not budget.

Noise caveat (carry forward). Phase A is unaffected by the probe, yet harbor seed 2 scored 71 then 73 on byte-identical re-runs — parallel/BLAS non-determinism, the same ±2-3 effect §12.4 flagged. Sub-±3 verdicts under n_workers>1 are noise; both arms here ran at the same worker count so the comparison stays fair, and maple's −8 is safely outside the band.

This is the third search-machinery null after §11.4 (graded objective) and §11.5 (niching+restarts) / §12.3 (M3 + shape filter), against four construction/seed wins (§11.6, §11.7, §12.2, §13.x). best-of-N at the Phase-A budget remains a free, worthwhile habit; a dedicated migration phase is not worth its budget. The residual stays geometry/shape-bound. NOT gated on canonical encoding (9gp closed); the child_probe hook is kept default-off for reuse.