diff --git a/.beads/issues.jsonl b/.beads/issues.jsonl index 2bcf2f7..a701cb9 100644 --- a/.beads/issues.jsonl +++ b/.beads/issues.jsonl @@ -27,7 +27,7 @@ {"id":"homemaker-py-1p0","title":"Geometry inner loop: full-objective equal-offset ratio optimiser","description":"DESIGN.md §5.1, §7 Phase 1. Productionise experiments/optimize_fullfitness.py into homemaker: optimise(topology, x0=None) -\u003e (geometry, fitness). DOF = equal-offset division ratios of free branches (solver.free_branches, lowest-storey cut ownership), clipped to [eps, 1-eps]. Objective = full oracle fitness (never a proxy — §4.2 falsified). Must support warm-start x0 (§5.6) and a population/batch evaluation mode so each iteration scores via one batched oracle call (§4.6).","acceptance_criteria":"Reproduces or exceeds §4.5 gains (x1.24–x1.67, no new failures) on 2f45907, candidate-002, c964435; works as a library call on any corpus .dom","status":"closed","priority":1,"issue_type":"feature","assignee":"Bruno Postle","owner":"bruno@postle.net","created_at":"2026-06-11T23:36:58Z","created_by":"Bruno Postle","updated_at":"2026-06-12T08:46:31Z","started_at":"2026-06-12T00:14:19Z","closed_at":"2026-06-12T08:46:31Z","close_reason":"innerloop.optimise() lands: batched CMA-ES sigma ladder (0.05/0.15, IPOP popsize doubling, deterministic seeding) over equal-offset free-branch ratios vs full oracle fitness; warm-start x0 supported. Acceptance vs unprojected originals: x1.65/x1.66/x1.58 against bars x1.24/x1.67/x1.59, no new failures, 46 oracle calls vs NM's 200. Two near-bar results accepted as reproduced-within-noise (1% tol) — draw spread brackets the single-NM-draw bars; approved by Bruno 2026-06-12. Gotchas: equal-offset projection of legacy unequal cuts loses fitness/adds failures (midpoint projection used); pycma seed=0 means clock-seeded.","dependencies":[{"issue_id":"homemaker-py-1p0","depends_on_id":"homemaker-py-av5","type":"blocks","created_at":"2026-06-12T00:39:33Z","created_by":"Bruno Postle","metadata":"{}"}],"dependency_count":1,"dependent_count":3,"comment_count":0} {"id":"homemaker-py-8cs","title":"Experiment: warm-vs-cold start of inner loop (Lamarckian inheritance)","description":"DESIGN.md §5.6, §4.6. Warm-starting a child topology's inner loop from the parent's optimised ratios is the main lever for cutting per-topology cost (~3 min/topology cold). Apply single topology mutations to optimised corpus designs, re-optimise warm (surviving cuts keep values, new cuts get heuristic defaults) vs cold, compare oracle-call counts to convergence at equal final fitness.","acceptance_criteria":"Speedup factor measured across \u003e=10 mutated topologies; decision recorded (expect order-of-magnitude; if \u003c2x, revisit §4.6 Phase-2 scoping)","notes":"Experiment script committed (experiments/warm_vs_cold.py, 1cc86c8) and machinery validated oracle-free; one mutated child scored through the oracle OK. Waiting on homemaker-py-gp2 reference run to finish, then execute under URB_NO_OCCLUSION=1 (3 parents x 400 evals + 12 children x 2 x 200 evals, ~1.5-2 h oracle time). Default budgets: parent 400, child 200; target = evals to 95% of best final.","status":"closed","priority":1,"issue_type":"task","owner":"bruno@postle.net","created_at":"2026-06-11T23:36:58Z","created_by":"Bruno Postle","updated_at":"2026-06-12T11:44:45Z","closed_at":"2026-06-12T11:44:45Z","close_reason":"Measured (URB_NO_OCCLUSION=1, parent budget 400, child 200, 12 single mutations across 3 designs): cold start reached 95% of warm final in 0/12 cases within budget — speedup unbounded at practical budgets; warm finals beat cold finals x1.2-x4 in 12/12; 6/12 warm starts were within 95% at 1 eval (near-neutral mutations). Decision: Lamarckian warm-starting is MANDATORY in the memetic driver (homemaker-py-b39), not an optimisation; cold starts produce strictly worse geometry at equal budget. Note: 2 undivides were exactly fitness-neutral (same-type merge == Merge_Divided equivalence) — locality datum for homemaker-py-nyb.","dependencies":[{"issue_id":"homemaker-py-8cs","depends_on_id":"homemaker-py-1p0","type":"blocks","created_at":"2026-06-12T00:39:34Z","created_by":"Bruno Postle","metadata":"{}"}],"dependency_count":1,"dependent_count":0,"comment_count":0} {"id":"homemaker-py-av5","title":"Batched oracle: score many .dom files per invocation","description":"oracle.py currently scores one .dom per urb-fitness.pl call (~1.65 s/dom). DESIGN.md §4.6: batching amortises Perl startup to ~0.99 s/dom and is required so population/batch optimisers can score a whole generation in one oracle call. Extend oracle.py with a batch API: write N .dom files, one perl invocation, parse N .score/.fails pairs. Keep the single-file path for compatibility.","acceptance_criteria":"Batch of 35 corpus files scores in one perl invocation; per-file results identical to single-file calls; measured s/dom reported","status":"closed","priority":1,"issue_type":"task","assignee":"Bruno Postle","owner":"bruno@postle.net","created_at":"2026-06-11T23:36:56Z","created_by":"Bruno Postle","updated_at":"2026-06-12T00:14:06Z","started_at":"2026-06-11T23:50:40Z","closed_at":"2026-06-12T00:14:06Z","close_reason":"score_batch() lands in oracle.py; 35-file corpus parity verified single-vs-batch (1e-12 rel fitness, exact fail sets); 0.98 s/dom batched vs 1.27 single, x1.30","dependency_count":0,"dependent_count":1,"comment_count":0} -{"id":"homemaker-py-koo","title":"Multi-storey (below-link) support for the shape-curve DP","description":"homemaker-py-6xh item 3 (DESIGN.md §37.2/§37.4). src/homemaker_layout/shapecurve.py's solve()/realise() writes division on every divided node under a single level_root unconditionally -- it has no notion of upper-storey below-inherited (wall-stacked) fixed splits (see solver.free_branches: a branch is free only when b.below is None or not b.below.divided). shapecurve.eligible() currently guards this by requiring len(dom.levels(root)) == 1, so the DP warm-start (homemaker-py-6xh) never fires on multi-storey topologies -- which is most real programmes (e.g. examples/programme-house has storey_minimum=2, examples/harbor-house is multi-storey; only the purpose-built examples/harbor-house-l0 de-risk variant is single-storey). Needs: generalise the DP to run bottom-up per storey, treating below-inherited-and-divided branches as FIXED (their (w,h) contribution comes from the level below's already-realised geometry, not chosen by this level's DP) while still composing correctly through them to size the level's own free branches. Validate against the full (multi-storey) examples/harbor-house, the DP's original but not-yet-attempted target.","status":"open","priority":2,"issue_type":"feature","owner":"bruno@postle.net","created_at":"2026-08-03T17:29:43Z","created_by":"Bruno Postle","updated_at":"2026-08-03T17:29:43Z","dependencies":[{"issue_id":"homemaker-py-koo","depends_on_id":"homemaker-py-2g7","type":"parent-child","created_at":"2026-08-03T18:31:48Z","created_by":"Bruno Postle","metadata":"{}"}],"dependency_count":0,"dependent_count":0,"comment_count":0} +{"id":"homemaker-py-koo","title":"Multi-storey (below-link) support for the shape-curve DP","description":"homemaker-py-6xh item 3 (DESIGN.md §37.2/§37.4). src/homemaker_layout/shapecurve.py's solve()/realise() writes division on every divided node under a single level_root unconditionally -- it has no notion of upper-storey below-inherited (wall-stacked) fixed splits (see solver.free_branches: a branch is free only when b.below is None or not b.below.divided). shapecurve.eligible() currently guards this by requiring len(dom.levels(root)) == 1, so the DP warm-start (homemaker-py-6xh) never fires on multi-storey topologies -- which is most real programmes (e.g. examples/programme-house has storey_minimum=2, examples/harbor-house is multi-storey; only the purpose-built examples/harbor-house-l0 de-risk variant is single-storey). Needs: generalise the DP to run bottom-up per storey, treating below-inherited-and-divided branches as FIXED (their (w,h) contribution comes from the level below's already-realised geometry, not chosen by this level's DP) while still composing correctly through them to size the level's own free branches. Validate against the full (multi-storey) examples/harbor-house, the DP's original but not-yet-attempted target.","notes":"DONE, PASS. Generalised shapecurve.py's DP to handle below-inherited (wall-stacked) multi-storey trees: dom.levels(root) processed bottom-up per storey; a divided node's split is free only per solver.free_branches' own criterion (below is None or undivided there), since geometry.coordinate always mirrors a below-linked node's corners from the storey below regardless of whether that storey's counterpart is divided. New _region_roots walks each storey descending through below.divided spines (nothing to solve there) to find below-fixed leaves (checked directly via the new _leaf_feasible, gridless/exact) and below-fixed-box/free-split fringe nodes -- each solved with the EXACT pre-existing single-region _check/realise, unmodified. _solve_all_levels realises each storey before checking the one above (fixed boxes read off already-realised geometry) and snapshots+restores on any infeasibility, preserving solve()'s all-or-nothing and is_feasible()'s never-writes contracts across the whole multi-storey tree. eligible() now allows any storey count (only leaf_sharing/superpose/max_share/multi_use -- tym's scope -- remain excluded). Validated: experiments/validate_shapecurve_multistorey.py, 200 random 2-storey topologies on the REAL examples/harbor-house (not the l0 de-risk variant), same DP-vs-NM protocol as 2g7.4/wkh -- 99.5% agreement, 0 false negatives, 117.7x speedup (DESIGN.md §37.6). Manual smoke: driver.search with shapecurve_warmstart=True and shapecurve_prune=True both run to completion on examples/harbor-house/init.dom. 4 new/1 renamed tests in test_shapecurve.py, 1 renamed+inverted in test_driver.py. Full suite 397 passed. Follow-up filed: homemaker-py-v4s (driver.search A/B on real multi-storey, blocked on tym).","status":"in_progress","priority":2,"issue_type":"feature","assignee":"Bruno Postle","owner":"bruno@postle.net","created_at":"2026-08-03T17:29:43Z","created_by":"Bruno Postle","updated_at":"2026-08-03T22:25:23Z","started_at":"2026-08-03T20:40:51Z","dependencies":[{"issue_id":"homemaker-py-koo","depends_on_id":"homemaker-py-2g7","type":"parent-child","created_at":"2026-08-03T18:31:48Z","created_by":"Bruno Postle","metadata":"{}"}],"dependency_count":0,"dependent_count":0,"comment_count":0} {"id":"homemaker-py-wkh","title":"DP-exact hard pre-filter: replace/augment predicted_shape_fails with shapecurve's boolean infeasibility","description":"homemaker-py-6xh item 1 (DESIGN.md §37.2/§37.4). The shapecurve DP (src/homemaker_layout/shapecurve.py, promoted from experiments/shapecurve_spike.py) gives an EXACT feasible/infeasible verdict for the size/width/proportion family, currently wired only as an NM warm-start (safe: never prunes). operators.predicted_shape_fails' threshold-based prune (driver._evaluate, feasibility_max_shape_fails/best_n_fails) still uses the older heuristic-count proxy. Using shapecurve.solve's infeasible verdict as an ADDITIONAL/replacement hard-prune signal would be stronger (exact, not a graduated heuristic) but riskier: unlike a bad warm-start, a wrong prune permanently discards a topology that could have beaten the incumbent. DESIGN.md §37.2 measured 0/200 false negatives (DP infeasible, NM reaches 0 anyway) on harbor-house-l0, but that is not a proven bound (the rectangle-vs-skew-quad approximation is a known ~7-12% error source, §37.2). Needs: (a) a design for how the DP's boolean signal composes with the existing pred\u003ethreshold\u0026\u0026pred\u003e=best_n_fails guard, (b) a false-negative-risk validation before enabling by default (a larger/less-rectangular topology sweep than the 200-topology harbor-house-l0 one), (c) a driver.search A/B (evals-to-N-hard-fails) against today's predicted_shape_fails-only filter.","notes":"2026-08-03: Shipped the DP-exact hard pre-filter, DESIGN.md §37.5. Full\ndetails there; summary:\n\n- shapecurve.is_feasible() (new, non-mutating refactor of solve()'s check\n phase) + shapecurve_prune flag in driver._evaluate/search, threaded\n through to `homemaker-evolve --shapecurve-prune` (default off, mirrors\n --shapecurve-warmstart). Composition: DP-feasible vetoes a heuristic\n prune outright (skips predicted_shape_fails entirely); DP-infeasible only\n hard-prunes when the incumbent already has 0 total fails (exact, since\n infeasible proves the shape-fail floor \u003e=1); otherwise defers unchanged\n to the existing predicted_shape_fails threshold. Conservative by design\n per the bead's own risk framing (a wrong prune is unrecoverable, unlike a\n bad warm-start).\n- Validation (bead item b): pointed experiments/validate_shapecurve.py at\n the promoted product module (was still validating the frozen spike) and\n gave it a programme_dir CLI arg; ran the same 200-topology protocol\n against examples/programme-house (a genuinely skewed, non-axis-aligned\n plot, not just a rotated harbor-house-l0): 200/200 agreement, 0 false\n positives, 0 false negatives, 87.4x speedup. Combined with §37.2's\n original 200 on harbor-house-l0: 0/400 false negatives across two\n structurally distinct plots.\n- A/B (bead item c): experiments/ab_shapecurve_prune.py, same protocol as\n 6xh's warm-start A/B (harbor-house-l0, budget=2000, seeds 0-4). Result:\n byte-identical off/on across all 5 seeds -- NULL, not a regression.\n Instrumented root cause: on this benchmark predicted_shape_fails itself\n (pre-existing 9gp.1, not this bead's code) rarely reaches best_n_fails\n organically -- tests/test_driver.py's own test_feasibility_filter_\n prunes_cheaply already had to force it to 999 to observe any real prune\n -- so neither the veto nor the exact-prune branch had an opening to fire\n (spied: 17/17 DP checks infeasible, incumbent total fails never reached\n 0). Not a wkh defect; 9gp.1 is documented as a \"scaling lever\", expected\n to matter at larger programmes/leaf counts than this benchmark, not here.\n\nTests: tests/test_shapecurve.py (+1), tests/test_driver.py (+4). Full\nsuite: 393 passed.\n\nFollow-up (not blocking this close, noted in DESIGN.md §37.5): re-run the\nA/B at a scale where predicted_shape_fails organically prunes to see wkh's\nmarginal value -- the more direct route there is homemaker-py-koo\n(multi-storey) and homemaker-py-tym (leaf-sharing), since today's DP\neligibility already excludes the real \u003e=2-storey, leaf-sharing-default\nprogrammes (programme-house, harbor-house) this would need to be measured\non.","status":"closed","priority":2,"issue_type":"feature","assignee":"Bruno Postle","owner":"bruno@postle.net","created_at":"2026-08-03T17:29:13Z","created_by":"Bruno Postle","updated_at":"2026-08-03T20:08:37Z","started_at":"2026-08-03T18:16:35Z","closed_at":"2026-08-03T20:08:37Z","close_reason":"DP-exact hard prune shipped + validated (0/400 false negatives across 2 plots); A/B measured NULL on harbor-house-l0 for a root-caused, pre-existing reason (9gp.1 rarely engages organically at this scale)","dependencies":[{"issue_id":"homemaker-py-wkh","depends_on_id":"homemaker-py-2g7","type":"parent-child","created_at":"2026-08-03T18:31:46Z","created_by":"Bruno Postle","metadata":"{}"}],"dependency_count":0,"dependent_count":0,"comment_count":0} {"id":"homemaker-py-6xh","title":"Wire shapecurve DP prototype into driver.py as a real pre-filter + NM warm-start","description":"homemaker-py-2g7.4's prototype (experiments/shapecurve_spike.py, DESIGN.md\n§37.2) validated PASS on harbor-house-l0 (99% agreement vs shape-fail-only NM\nover 200 random topologies, 93.6x speedup at grid_n=150, 0 false negatives).\nIt is not yet wired into the product — it's a reference spike only, same\nstatus as experiments/autodiff_spike.py (§34).\n\nTo productionise per the original plan (DESIGN.md §37 point 2):\n- Replace/augment operators.predicted_shape_fails with the DP as driver.py's\n real per-child pre-filter (a single-sample heuristic today; the DP gives an\n exact yes/no plus a realizing ratio point).\n- Warm-start innerloop.optimise's NM from the DP's realised ratios instead of\n (or in addition to) the current proportion-aware target-geometry seed.\n- Multi-storey support: the DP only walks one level's leaves currently;\n below-linked nodes (wall-stacking across storeys) aren't modelled.\n- leaf_sharing/co_type target-adjustment: not modelled in leaf_constraints,\n needed for any programme that uses either (harbor-house-l0 doesn't).\n- Consider replacing the bounding-box leaf approximation with true skew-quad\n polygon algebra to remove the ~7-12% area approximation error identified\n as the root cause of both measured false positives (§37.2) -- or at least\n characterise it on a LESS rectangular plot than harbor-house-l0's\n near-rectangular trapezoid, where the error is likely worse.\n- A/B against the real driver.search: does DP-pre-filter + warm-start beat\n today's predicted_shape_fails + cold/proportion-aware start on wall-clock\n to N hard fails, on harbor-house (full) and/or a less-rectangular plot?","notes":"2026-08-03: Shipped NM warm-start (item 2) + a scoped A/B (item 5), left\nin_progress -- 3 of 5 description items deliberately deferred to new\ntracked beads (see below). Full details + measured numbers: DESIGN.md\n§37.4.\n\nWhat shipped: promoted experiments/shapecurve_spike.py into\nsrc/homemaker_layout/shapecurve.py (fixed a latent numpy.float64-in-division\nbug caught by round-tripping through dom.dumps in the new tests -- the spike\nnever round-tripped and so never caught it). Added shapecurve.eligible()\n(single storey, no leaf_sharing/superpose/max_share/multi_use). Wired into\ndriver._evaluate as an NM warm-start only (never a prune) behind\nshapecurve_warmstart=False default, threaded through driver.search and\nexposed as `homemaker-evolve --shapecurve-warmstart`. A/B\n(experiments/ab_shapecurve_warmstart.py) on harbor-house-l0, budget=2000,\n5 seeds: mean total-fails 16.6 (on) vs 19.6 (off), ~3.5x mean fitness\nimprovement; mean hard-fail count alone was a noise-level wash (4.6 vs 4.4\nat n=5). Tests: tests/test_shapecurve.py (4), tests/test_driver.py (+3).\nFull suite 388 passed.\n\nDeferred to new tracked beads (children of 2g7, per the epic's own\ndependency ordering):\n- homemaker-py-wkh: DP-exact hard pre-filter (item 1) -- replacing\n predicted_shape_fails' heuristic threshold with the DP's exact\n infeasibility verdict. Needed to actually chase \"evals to N hard fails\"\n rather than just improve soft-fail/fitness convergence.\n- homemaker-py-koo: multi-storey (below-link) DP support (item 3) --\n without this, the warm-start never fires on programme-house\n (storey_minimum=2) or full harbor-house, only the purpose-built\n single-storey harbor-house-l0.\n- homemaker-py-tym: leaf_sharing/co_type modelling (item 4) -- without this,\n the warm-start never fires when leaf_sharing=True, which is\n driver.search's own default.\n- homemaker-py-ekc: true skew-quad polygon algebra (the §37.2-quantified\n ~7-12% rectangle-approximation error) -- not a new bead-description item,\n but the explicit \"consider replacing the bounding-box leaf approximation\"\n bullet.\n\nNet: 6xh's own acceptance (a real evals-to-N-hard-fails win over\npredicted_shape_fails + cold/proportion-aware start) is NOT yet met --\ntoday's result is a safe, positive-but-partial step (soft-fail/fitness\nconvergence, not hard-fail convergence, and only on the single-storey\nno-sharing envelope). Keeping 6xh in_progress rather than closing it.","status":"in_progress","priority":2,"issue_type":"feature","assignee":"Bruno Postle","owner":"bruno@postle.net","created_at":"2026-08-02T22:39:46Z","created_by":"Bruno Postle","updated_at":"2026-08-03T17:40:52Z","started_at":"2026-08-03T15:51:29Z","dependency_count":0,"dependent_count":0,"comment_count":0} {"id":"homemaker-py-2g7.9","title":"Parallel best-of-N + racing harness (use all cores, kill stragglers early)","description":"§14 measured islands \u003c= best-of-N, and the 3M runs used workers=1-2 on a 4-core box — independent seeds are the proven shape and we are not even using the local machine. Build a harness: launch N independent search_staged seeds across all cores (processes, not threads — mind the cvw id()-keyed cache bug), checkpoint fail-counts periodically, successively halve (hyperband-style: kill runs above median hard-fail count at each rung, reallocate budget to survivors). Fix/respect homemaker-py-b8g (parallel non-determinism) and homemaker-py-cvw first or work around with process isolation. This multiplies whatever eval cost the shape-curve DP issue achieves; on its own it is a free 4x locally and scales to any box. Report best + variance across seeds (the seed-variance in §12-§13 tables is huge — 78 vs 97 same config — so best-of-N is worth several levers combined).","acceptance_criteria":"harness runs N=16 seeds on 4 cores with racing; at equal total native-eval budget beats the single-seed mean on harbor by at least the observed seed spread; deterministic per-seed replay","status":"open","priority":2,"issue_type":"task","owner":"bruno@postle.net","created_at":"2026-08-02T09:15:58Z","created_by":"Bruno Postle","updated_at":"2026-08-02T09:15:58Z","dependencies":[{"issue_id":"homemaker-py-2g7.9","depends_on_id":"homemaker-py-2g7","type":"parent-child","created_at":"2026-08-02T10:15:58Z","created_by":"Bruno Postle","metadata":"{}"},{"issue_id":"homemaker-py-2g7.9","depends_on_id":"homemaker-py-b8g","type":"blocks","created_at":"2026-08-02T10:16:16Z","created_by":"Bruno Postle","metadata":"{}"},{"issue_id":"homemaker-py-2g7.9","depends_on_id":"homemaker-py-cvw","type":"blocks","created_at":"2026-08-02T10:16:15Z","created_by":"Bruno Postle","metadata":"{}"}],"dependency_count":2,"dependent_count":0,"comment_count":0} @@ -77,8 +77,9 @@ {"id":"homemaker-py-nyb","title":"High-locality topology operators (mutation + subtree crossover)","description":"DESIGN.md §5, §7 Phase 2, §8.4. Mutation moves: divide/undivide leaf, swap children, rotate cut, retype leaf, per-floor delta edits, storey add/delete (cf. Urb Mutate.pm — but geometry sliding belongs to the inner loop, not the operator set). Crossover: area-matched subtree exchange (a subtree = a contiguous region, so crossover is meaningful — Crossover.pm). Operators must be high-locality: small genome change =\u003e small phenotype change, so warm-started inner loops stay cheap.","acceptance_criteria":"Each operator produces valid genomes (oracle scores them without error); locality measured (mean fitness/geometry perturbation per operator)","status":"closed","priority":2,"issue_type":"feature","assignee":"Bruno Postle","owner":"bruno@postle.net","created_at":"2026-06-11T23:37:27Z","created_by":"Bruno Postle","updated_at":"2026-06-12T13:07:37Z","started_at":"2026-06-12T12:54:23Z","closed_at":"2026-06-12T13:07:37Z","close_reason":"operators.py lands: 7 mutations + area-matched crossover, valid-by-construction via genome.encode repair. 115/115 oracle-valid children; locality measured: geom-pert 0.07-0.33 per op, fitness-pert 0.68-0.99 (0.5^n cliff flags raw moves — warm restart + penalty reshaping confirmed load-bearing). Also fixed dom._link stale below-links on structural mutation.","dependencies":[{"issue_id":"homemaker-py-nyb","depends_on_id":"homemaker-py-k2g","type":"blocks","created_at":"2026-06-12T00:39:36Z","created_by":"Bruno Postle","metadata":"{}"}],"dependency_count":1,"dependent_count":1,"comment_count":0} {"id":"homemaker-py-k2g","title":"Topology genome: base-floor tree + per-floor deltas + type assignment","description":"DESIGN.md §5.2, §7 Phase 2. Genome = base-floor slicing topology (primary) + per-leaf type assignment + per-floor divide/undivide deltas (Below-inheritance as regulariser; cut owned by lowest storey where its path is divided — §10). Must round-trip to/from dom.py Node trees so the oracle and inner loop consume it directly. Includes storey count and per-floor type overrides.","acceptance_criteria":"Genome \u003c-\u003e .dom round-trip on all 35 corpus files preserves fitness; multi-storey wall stacking preserved","status":"closed","priority":2,"issue_type":"feature","assignee":"Bruno Postle","owner":"bruno@postle.net","created_at":"2026-06-11T23:37:26Z","created_by":"Bruno Postle","updated_at":"2026-06-12T12:52:34Z","started_at":"2026-06-12T10:55:21Z","closed_at":"2026-06-12T12:52:34Z","close_reason":"genome.py encode/decode lands. 35/35 oracle fitness parity after round-trip (flag-on); genome fixed-point + owned-projection tests. Dead-field discovery: corpus upper storeys carry drifted dead divisions (97) and rotations (187) — canonicalised by decode, validated fitness-neutral.","dependency_count":0,"dependent_count":1,"comment_count":0} {"id":"homemaker-py-d0s","title":"Experiment: inner-loop optimiser bake-off at equal oracle budgets","description":"DESIGN.md §7 Phase 1, §8.3. DOF is only ~rooms-1 (6–7 on corpus). Compare Nelder-Mead vs CMA-ES vs batched multi-start pattern search at equal oracle-call budgets, measuring fitness gained per oracle call and wall-clock (batch-friendliness matters — §4.6). Measure, don't commit blind.","acceptance_criteria":"Table of fitness-per-budget across \u003e=3 candidates; one optimiser chosen and recorded in DESIGN.md","status":"closed","priority":2,"issue_type":"task","assignee":"Bruno Postle","owner":"bruno@postle.net","created_at":"2026-06-11T23:36:59Z","created_by":"Bruno Postle","updated_at":"2026-06-13T08:48:13Z","started_at":"2026-06-12T21:22:15Z","closed_at":"2026-06-13T08:48:13Z","close_reason":"Bake-off complete: CMA-ES confirmed as Phase 1/2 optimiser. NM wins quality per eval but sequential architecture incompatible with batching (§4.6). Compass stalls on narrow valleys. Results in DESIGN.md §8.3 and experiments/bakeoff_innerloop.*","dependencies":[{"issue_id":"homemaker-py-d0s","depends_on_id":"homemaker-py-1p0","type":"blocks","created_at":"2026-06-12T00:39:35Z","created_by":"Bruno Postle","metadata":"{}"}],"dependency_count":1,"dependent_count":0,"comment_count":0} +{"id":"homemaker-py-v4s","title":"driver.search A/B for shapecurve warm-start/prune on real multi-storey programmes","description":"Follow-up from homemaker-py-koo (DESIGN.md §37.6): koo generalised shapecurve.py's DP to handle below-inherited multi-storey trees and validated it (DP-vs-NM agreement/false-negative bar, 200 topologies on the real examples/harbor-house, 99.5% agreement, 0 false negatives, 117.7x speedup, DESIGN.md §37.6). Not measured: the search-level payoff of shapecurve_warmstart/shapecurve_prune on a real multi-storey programme at the 6xh/wkh A/B protocol (budget=2000, seeds 0-4, driver.search mean hard/soft/fitness fails, off vs on). Best sized as a single A/B once homemaker-py-tym (leaf_sharing/co_type modelling in shapecurve.leaf_constraints) also lands, since leaf_sharing defaults True in driver.search and both programme-house and harbor-house require it by default -- measuring the combined win (multi-storey + leaf_sharing) in one pass avoids two partial A/Bs that each only apply with a flag most real runs don't use.","notes":"Depends on homemaker-py-tym landing first for the combined measurement to be meaningful.","status":"open","priority":3,"issue_type":"task","owner":"bruno@postle.net","created_at":"2026-08-03T22:23:50Z","created_by":"Bruno Postle","updated_at":"2026-08-03T22:24:36Z","dependencies":[{"issue_id":"homemaker-py-v4s","depends_on_id":"homemaker-py-tym","type":"blocks","created_at":"2026-08-03T23:24:37Z","created_by":"Bruno Postle","metadata":"{}"}],"dependency_count":1,"dependent_count":0,"comment_count":0} {"id":"homemaker-py-ekc","title":"True skew-quad polygon algebra for the shape-curve DP leaf region (remove ~7-12% rectangle approximation error)","description":"homemaker-py-6xh item (DESIGN.md §37.2, 'Remaining approximation error, root-caused'). src/homemaker_layout/shapecurve.py approximates every quad (leaf or internal) as a rectangle with edge-length-derived (w,h) = ((edge0+edge2)/2, (edge1+edge3)/2) -- exact only for a true rectangle/parallelogram. DESIGN.md §37.2's 200-topology harbor-house-l0 validation root-caused both measured false positives to this approximation specifically (not to global rotation or to the rotation-parity composition rule, both already fixed/verified exact): the DP's own realised point had a leaf whose edge-length-approximated area was comfortably inside its feasible bound but whose true geometry.area (a real, slightly non-parallelogram quad) fell just below the true lower bound -- an ~8-12% gap, the same magnitude as harbor-house-l0's own plot-level residual skew. Needs: either (a) replace the rectangle approximation with true skew-quad polygon algebra (a harder closed-form derivation, or a numerically-solved per-leaf feasible region), or (b) at minimum re-characterise the error's magnitude on a LESS rectangular plot than harbor-house-l0's near-rectangular trapezoid (§37.2 flagged this as untested and likely worse elsewhere) so shapecurve_warmstart's real-world false-positive rate is known before wider rollout.","status":"open","priority":3,"issue_type":"task","owner":"bruno@postle.net","created_at":"2026-08-03T17:30:23Z","created_by":"Bruno Postle","updated_at":"2026-08-03T17:30:23Z","dependencies":[{"issue_id":"homemaker-py-ekc","depends_on_id":"homemaker-py-2g7","type":"parent-child","created_at":"2026-08-03T18:31:51Z","created_by":"Bruno Postle","metadata":"{}"}],"dependency_count":0,"dependent_count":0,"comment_count":0} -{"id":"homemaker-py-tym","title":"leaf_sharing/co_type target-adjustment modelling in shapecurve.leaf_constraints","description":"homemaker-py-6xh item 4 (DESIGN.md §37.2/§37.4). src/homemaker_layout/shapecurve.py's leaf_constraints() uses each leaf's own type's base (target, sigma) params only -- it does not model the leaf-sharing/co_type k-scaling (target*=k, sigma adjustment) that fitness.py's quality_size applies for shared/multi-use leaves. shapecurve.eligible() currently guards this by excluding any run with leaf_sharing/superpose/max_share/multi_use on, so the DP warm-start never fires for those runs -- but leaf_sharing defaults to True in driver.search(), so most real runs are excluded today. Needs: read fitness.py's actual k-scaling formula (quality_size's leaf-sharing branch) and mirror it in leaf_constraints so (amin, amax) reflects a shared leaf's k-multiplied target, then relax shapecurve.eligible's leaf_sharing/max_share guards accordingly (superpose/multi_use may need separate analysis -- check whether either changes the per-leaf target formula the same way share does, or a different one).","status":"open","priority":3,"issue_type":"feature","owner":"bruno@postle.net","created_at":"2026-08-03T17:30:01Z","created_by":"Bruno Postle","updated_at":"2026-08-03T17:30:01Z","dependencies":[{"issue_id":"homemaker-py-tym","depends_on_id":"homemaker-py-2g7","type":"parent-child","created_at":"2026-08-03T18:31:49Z","created_by":"Bruno Postle","metadata":"{}"}],"dependency_count":0,"dependent_count":0,"comment_count":0} +{"id":"homemaker-py-tym","title":"leaf_sharing/co_type target-adjustment modelling in shapecurve.leaf_constraints","description":"homemaker-py-6xh item 4 (DESIGN.md §37.2/§37.4). src/homemaker_layout/shapecurve.py's leaf_constraints() uses each leaf's own type's base (target, sigma) params only -- it does not model the leaf-sharing/co_type k-scaling (target*=k, sigma adjustment) that fitness.py's quality_size applies for shared/multi-use leaves. shapecurve.eligible() currently guards this by excluding any run with leaf_sharing/superpose/max_share/multi_use on, so the DP warm-start never fires for those runs -- but leaf_sharing defaults to True in driver.search(), so most real runs are excluded today. Needs: read fitness.py's actual k-scaling formula (quality_size's leaf-sharing branch) and mirror it in leaf_constraints so (amin, amax) reflects a shared leaf's k-multiplied target, then relax shapecurve.eligible's leaf_sharing/max_share guards accordingly (superpose/multi_use may need separate analysis -- check whether either changes the per-leaf target formula the same way share does, or a different one).","status":"open","priority":3,"issue_type":"feature","owner":"bruno@postle.net","created_at":"2026-08-03T17:30:01Z","created_by":"Bruno Postle","updated_at":"2026-08-03T17:30:01Z","dependencies":[{"issue_id":"homemaker-py-tym","depends_on_id":"homemaker-py-2g7","type":"parent-child","created_at":"2026-08-03T18:31:49Z","created_by":"Bruno Postle","metadata":"{}"}],"dependency_count":0,"dependent_count":1,"comment_count":0} {"id":"homemaker-py-p6t","title":"Convergence-speed A/B for tiered comparator: evals to 0 hard fails, tiered vs flat","description":"homemaker-py-2g7.3 (DESIGN.md §37.1) validated that tiered search (-n_hard,-n_soft,fitness) reaches a strictly lower mean hard-fail count than flat (-n_fails,fitness) at a FIXED budget (20k evals) on harbor-house and maple-court. That measures fail composition at a snapshot, not time-to-solved. The natural follow-up: race the two comparators to '0 hard fails' (or a hard-fail floor) and compare evals/wall-clock to get there, ideally after 2g7.1/2g7.2 ground truth lands so there is a real target to race to instead of an arbitrary floor.","design":"Reuse experiments/tier_ab_2g7_3.py's harness; instead of a fixed budget, run until n_hard==0 or a budget cap, log evals-to-target per seed/scheme, same programmes (harbor-house, maple-court), same 3-seed protocol.","acceptance_criteria":"Report showing evals-to-0-hard-fails (or evals-to-floor) for tiered vs flat, both programmes, 3 seeds; verdict on whether tiering also wins on convergence speed, not just fixed-budget composition.","status":"open","priority":3,"issue_type":"task","owner":"bruno@postle.net","created_at":"2026-08-02T17:51:38Z","created_by":"Bruno Postle","updated_at":"2026-08-02T17:51:38Z","dependency_count":0,"dependent_count":0,"comment_count":0} {"id":"homemaker-py-2g7.10","title":"MAP-Elites archive over (hard-fail profile, leaf count, circulation fraction)","description":"Quality-diversity as the population-level answer to the §4.10 deceptive-valley problem: an archive keeps the elite per behavior niche, so 'transiently worse but structurally different' stepping stones survive — exactly what lex selection provably discards (§11.4's own analysis). DISTINCT from the failed §11.5/§11.8 niching: that kept diverse individuals under ONE selection pressure; MAP-Elites keeps the BEST individual per niche with no cross-niche competition. Descriptors to try: hard-fail category histogram (bucketed), total leaf count, circulation area fraction, storey balance. Emit from the existing genome.signature/score_with_grade machinery (kept default-off for exactly this reuse, §11.4 verdict). Blocked on the shape-curve DP: archive-filling needs cheap evals to be meaningful. Gate honestly per the ledger discipline: 3 seeds, control = current default stack.","acceptance_criteria":"A/B at equal budget (harbor+maple, 3 seeds): archive best hard-fails \u003c= default-stack best on mean; archive demonstrably contains the stepping stone for at least one accepted valley-crossing (traceable lineage)","status":"open","priority":3,"issue_type":"feature","owner":"bruno@postle.net","created_at":"2026-08-02T09:16:00Z","created_by":"Bruno Postle","updated_at":"2026-08-02T09:16:00Z","dependencies":[{"issue_id":"homemaker-py-2g7.10","depends_on_id":"homemaker-py-2g7","type":"parent-child","created_at":"2026-08-02T10:15:59Z","created_by":"Bruno Postle","metadata":"{}"},{"issue_id":"homemaker-py-2g7.10","depends_on_id":"homemaker-py-2g7.4","type":"blocks","created_at":"2026-08-02T10:15:59Z","created_by":"Bruno Postle","metadata":"{}"}],"dependency_count":1,"dependent_count":0,"comment_count":0} {"id":"homemaker-py-2g7.8","title":"LLM operator synthesis (AlphaEvolve-style): evolve mutation-operator code against the A/B harness","description":"Second LLM role, after the repair operator proves the plumbing: let the LLM propose new OPERATOR CODE (python functions with the mutate_* signature) and evaluate candidates with the exact experiment discipline DESIGN.md already enforces (control reproduces baseline, 3 seeds, 20k evals, verdict). The project's ledger of 20+ operator experiments with verdicts is unusually good few-shot material: feed it the §11-§13 history so it learns what already failed (niching, grading, annealing...) and why. Sandbox the generated code; acceptance purely empirical via the harness. This is compute-hungry — schedule after the shape-curve DP lands so each A/B is cheap.","acceptance_criteria":"one synthesized operator survives the standard 3-seed A/B gate on harbor or maple (mean fails strictly better, control reproduces baseline)","status":"open","priority":3,"issue_type":"feature","owner":"bruno@postle.net","created_at":"2026-08-02T09:15:56Z","created_by":"Bruno Postle","updated_at":"2026-08-02T09:15:56Z","dependencies":[{"issue_id":"homemaker-py-2g7.8","depends_on_id":"homemaker-py-2g7","type":"parent-child","created_at":"2026-08-02T10:15:56Z","created_by":"Bruno Postle","metadata":"{}"},{"issue_id":"homemaker-py-2g7.8","depends_on_id":"homemaker-py-2g7.7","type":"blocks","created_at":"2026-08-02T10:15:56Z","created_by":"Bruno Postle","metadata":"{}"}],"dependency_count":1,"dependent_count":0,"comment_count":0} @@ -127,27 +128,27 @@ {"id":"homemaker-py-erc.6","title":"Experiment: inner-loop slack-expansion objective term","description":"Inner-loop counterpart to plot-fill construction. If Diagnostic B shows the inner loop has room to expand leaves into slack but no objective gradient to do so (the scalar rewards hitting target area but not exceeding it where slack exists), add a term/incentive so the ratio optimiser pushes leaf boundaries out to consume neighbouring slack and satisfy size, rather than parking at target.\n\nCONDITIONAL on Diagnostic B: build this only if B localizes the gap to the inner loop (room to expand, no gradient); if B shows construction targets too-small dims, prefer the plot-fill construction sibling. Must preserve the §5.4 inner-loop cliff / §4.9 lexicographic protection — the term sits where it cannot displace the fail-count ordering. A/B vs §12.2 baseline, seeds 0/1/2, 20000 evals, staged, default-OFF. Record DESIGN.md §13.6.","notes":"DEPRIORITISED by Diagnostic B (§13.2). B shows the inner loop CANNOT repair undersize: the slack is depth-driven maldistribution baked into the frozen topology, and the equal-offset ratio DOF cannot shrink a 14x leaf to feed a starved one without trading into shape fails (0.5^n cliff). Wrong DOF and wrong direction — the blocker is slicing POSITION, not a missing expansion reward. Fix belongs upstream in construction/topology (erc.4 re-scoped, erc.3). Keep as a low-priority follow-up only if a depth-balanced construction still leaves a residual size gradient the inner loop could pick up.","status":"closed","priority":4,"issue_type":"feature","owner":"bruno@postle.net","created_at":"2026-06-22T23:16:24Z","created_by":"Bruno Postle","updated_at":"2026-06-28T13:22:22Z","closed_at":"2026-06-28T13:22:22Z","close_reason":"wont-fix (DESIGN §13.7): Diag B (§13.2) showed the inner loop cannot repair undersize (wrong DOF — slicing position, frozen-topology ratios). Superseded by depth-balanced construction (erc.4). Condition unmet.","dependencies":[{"issue_id":"homemaker-py-erc.6","depends_on_id":"homemaker-py-erc","type":"parent-child","created_at":"2026-06-23T00:16:23Z","created_by":"Bruno Postle","metadata":"{}"},{"issue_id":"homemaker-py-erc.6","depends_on_id":"homemaker-py-erc.2","type":"blocks","created_at":"2026-06-23T00:16:47Z","created_by":"Bruno Postle","metadata":"{}"}],"dependency_count":1,"dependent_count":0,"comment_count":0} {"id":"homemaker-py-erc.5","title":"Experiment: compactness-aware cuts (minimize leaf perimeter/area)","description":"Attacks the #1 factor, crinkliness (346) — a per-leaf perimeter/area property DISTINCT from proportion (aspect ratio). Proportion-aware seeding (leu.2) sizes splits but does not bias toward balanced, square-ish subdivision. Add a KD-tree-style 'keep both children compact' cut rule (prefer the cut orientation/position that minimises summed child perimeter/area) in construction.\n\nCONDITIONAL on Diagnostic A: if A shows per-leaf shape-fail is FLAT across densities (floor intrinsic to slicing density), better cuts at the same leaf count will not pay → this should be closed wont-fix in favour of leaf-sharing. Only build if A shows shape-fail RISES with density. A/B vs §12.2 baseline, seeds 0/1/2, 20000 evals, staged, default-OFF. Record DESIGN.md §13.5.","notes":"DEPRIORITISED by erc.1 verdict (§13.1): per-leaf shape-fail flat vs slicing density and cuts already squarest (_size_divisions_from_targets picks squarest rotation) yet still ~1.8 fails/leaf =\u003e little compactness headroom at fixed leaf count. Floor is intrinsic to leaf COUNT, not cut quality. Revisit only if leaf-sharing (erc.3) underdelivers.","status":"closed","priority":4,"issue_type":"feature","owner":"bruno@postle.net","created_at":"2026-06-22T23:16:21Z","created_by":"Bruno Postle","updated_at":"2026-06-28T13:22:17Z","closed_at":"2026-06-28T13:22:17Z","close_reason":"wont-fix (DESIGN §13.7): Diag A (§13.1) showed the floor is intrinsic to leaf COUNT not cut quality; revisit condition was 'only if leaf-sharing underdelivers' but leaf-sharing OVER-delivered (−32…−39%, §13.3). Condition unmet.","dependencies":[{"issue_id":"homemaker-py-erc.5","depends_on_id":"homemaker-py-erc","type":"parent-child","created_at":"2026-06-23T00:16:21Z","created_by":"Bruno Postle","metadata":"{}"},{"issue_id":"homemaker-py-erc.5","depends_on_id":"homemaker-py-erc.1","type":"blocks","created_at":"2026-06-23T00:16:43Z","created_by":"Bruno Postle","metadata":"{}"}],"dependency_count":1,"dependent_count":0,"comment_count":0} {"id":"homemaker-py-2g5","title":"Rebuild occlusion/daylight/sun subsystem in Python (post-Phase-5, after optimisation fully native)","description":"DESIGN.md §6 port scope — a whole subsystem, not a term. quality_daylight (Leaf.pm:281-296) needs Urb::Misc::Sun + Urb::Field::Occlusion (+CIESky); quality_uncrinkliness also takes the occlusion object. Indoor spaces return 1 for daylight; cost is outdoor spaces + crinkliness. Port Sun_horizontal (262980-minute normalisation) and the occlusion wall set from Dom-\u003eWalls.","acceptance_criteria":"Daylight and crinkliness factors match Perl (float tolerance) across the corpus, including multi-storey cases","notes":"Re-scoped 2026-06-12: occlusion disabled in the Urb oracle instead of ported (see homemaker-py-gp2). Native fitness ships with simple crinkliness (illumination factor = 1, in homemaker-py-gnw). This issue is now the eventual Python occlusion rebuild, only after optimisation works entirely in Python. Restores outdoor-daylight and shaded-wall selection pressure.\nReframed 2026-06-17: orthogonal to epic homemaker-py-c4c. This is fitness FIDELITY (restoring daylight + shaded-wall selection pressure to match Perl), not search CAPABILITY — it changes what 'good' means, not the search's ability to find good. It will NOT improve final designs in the sense currently sought. Stays P4, deferred until the topology-search-quality epic lands and optimisation is fully native.","status":"open","priority":4,"issue_type":"feature","owner":"bruno@postle.net","created_at":"2026-06-11T23:38:25Z","created_by":"Bruno Postle","updated_at":"2026-06-17T19:14:48Z","dependency_count":0,"dependent_count":0,"comment_count":0} -{"_type":"memory","key":"correction-to-urb-fitness-bug-memory-bruno-2026","value":"CORRECTION to urb-fitness-bug memory (Bruno, 2026-06-12): 'C' is NOT a 'covered' type — Is_Covered is a geometric predicate (indoor space above). Urb's generic types are canonically UPPERCASE: C=circulation, O=outside, S=sahn (get_space_types qw/C O S/; corpus is 100% uppercase, never 'c'/'o' leaves). The mixed-case designs that fired the latent ratio_type first-match bug were created by homemaker's own operator type pool emitting lowercase 'c'/'o' — fixed: driver/operators now emit uppercase generics only, and class checks use t[0].lower() in 'cos'. The Urb class-sum patch stays as defensive hardening (zero impact on canonical designs). Native port (3y7/gnw): treat type classes case-insensitively, generics canonically uppercase."} -{"_type":"memory","key":"experiment-seeding-pitfall-run-search-scaled-py-s","value":"Experiment seeding pitfall: run_search_scaled.py's default PH_SEED (c964…dom) is a FINISHED programme-house design — passing it warm-starts and floors at ~3 fails, NOT a blank-slate topology search. For blank-slate runs comparable to §11.5/§11.6 baselines, seed from examples/programme-house/init.dom (a bare undivided plot; driver bootstrap auto-triggers only on bare plots). Bit the 6zy sweep — first pass used c964 and falsely showed 3-fail floor across the whole grid."} -{"_type":"memory","key":"experiment-harness-gotcha-the-leaf-sharing-relaxed-objective","value":"Experiment harness gotcha: the leaf-sharing RELAXED objective (§13.3) is injected ONLY by monkeypatching fitness.load_config in the parent process (run_staged_search.py / probe scripts). This is parent-process-only and does NOT propagate into ProcessPoolExecutor workers (n_workers\u003e1), which re-import fitness fresh and score under the STRICT on-disk patterns.config -\u003e r.n_fails MISMATCH (worker strict vs parent relaxed re-score). ALL §13.x floor runs were therefore SERIAL. Any future PARALLEL leaf-sharing experiment will silently mis-score until leaf_sharing lives on disk/CLI (tracked: homemaker-py-x3b). The parallel driver itself is correct; both paths score via load_config(programme_dir)."} -{"_type":"memory","key":"homemaker-py-3l6-fix-leaf-sharing-evolve-runs","value":"homemaker-py-3l6 fix: leaf-sharing evolve runs now auto-finish before write via driver.polish_finish — unfold_shared_leaves() then a warm-started leaf_sharing=False polish search (--polish-budget, default budget//2). Makes the written .dom honest under canonical homemaker-fitness (internal==canonical when leaf_sharing off). Interrupt path forces polish_budget=0 (unfold+rescore only). This is yaa's unfold-then-polish, made automatic; Schedule B annealing is still kpu."} -{"_type":"memory","key":"multi-storey-staircase-consistency-when-dividing-or-retyping","value":"Multi-storey staircase consistency: when dividing or retyping a circulation (C) leaf at one level, the same structural change should be propagated to the matching leaf on ALL other storeys so the stair core path is maintained. The optimizer cannot fix staircase disruptions through trial-and-error geometry alone — it requires a synchronized multi-level operator that applies the same topology change to every storey simultaneously."} -{"_type":"memory","key":"urb-fitness-bug-found-fixed-2026-06-12","value":"Urb fitness bug found+fixed 2026-06-12 (patch in /home/bruno/src/urb, uncommitted): ProgrammeDriven.pm ratio_o/ratio_type grepped case-insensitively over the ratios hash and took the FIRST key — nondeterministic (x4.5 score swings) for designs with mixed-case type classes (both 'c' circulation and 'C' covered). Fixed to SUM the class (matches Is_Circulation//Is_Outside semantics); 35/35 corpus scores unchanged. CRITICAL for homemaker-py-3y7/gnw: the native port must implement class-SUM ratios. Building.pm has the same unpatched pattern (site-driven path, not used by our oracle). Also: the memetic search reward-hacked this bug before the fix — search results predating it are noise artifacts."} -{"_type":"memory","key":"adjacency-in-binary-slicing-tree-is-structural-not","value":"Adjacency in binary slicing tree is structural, not geometric: the inner-loop NM cannot fix topological adjacency failures. Two paths exist: (1) tree-sibling adjacency — a node is adjacent to its sibling in the tree; (2) cross-zone geometric adjacency — leaves from different subtrees that happen to share a boundary. Staircase/adjacency fails require a topology mutation that changes which nodes are siblings or which zones touch. This was proved empirically on programme-house: staircase fail from rot=0 layout could not be fixed by NM but was fixed by level_retype creating a two-C topology (2026-06-14/15)."} -{"_type":"memory","key":"deceptive-valleys-in-topology-search-when-every-single","value":"Deceptive valleys in topology search: when every single-step mutation from a target state passes through a high-fail intermediary (e.g. level_fix displaces a room into 5+ new fails), a compound operator that atomically applies two coordinated changes can escape. Design compound operators to land on the low-fail state directly, bypassing the deceptive gradient. Programme-house example: level_compound_fix atomically moves the level-constrained room AND re-inserts the displaced room adjacent to C in one step (operators.py, 2026-06-14)."} -{"_type":"memory","key":"never-use-corpus-filenames-candidate-001-dom-candidate","value":"Never use corpus filenames (candidate-001.dom, candidate-002.dom, generated.dom, init.dom, etc.) as --output targets when running experiments. These are test fixtures. Always write experimental outputs to scratch/ or a timestamped path. Lesson from 2026-06-14: warm-start runs overwrote candidate-001/002.dom and broke graph tests."} -{"_type":"memory","key":"user-preference-bruno-this-is-a-fedora-system","value":"User preference (Bruno): this is a Fedora system — NEVER install Python packages via pip without asking first; always ask whether to install the rpm via dnf (e.g. python3-cma) before considering pip. Applies to any dependency additions."} -{"_type":"memory","key":"9o5-multi-use-leaves-is-path-a-superposition","value":"9o5 multi-use leaves is path (a) — superposition as SEARCH RELAXATION that COLLAPSES to specific usage at the end, NOT path (b) loose-fit/no-collapse. Bruno's intent: codes with SIMILAR leaf requirements form an interchangeable equivalence class; during evolution the solver doesn't commit which leaf serves which specific usage (smoother landscape, no fighting over exact leaf usage); at the end the layout is CONDENSED to specific usages by brute-forcing the in-class assignment (3 interchangeable usages over 3 leaves = 3! = 6 combinations to check, pick best). 'Derive automatically' compatibility = requirement-similarity grouping. This reverses the issue's stated 'path b preferred' note."} -{"_type":"memory","key":"programme-house-optimisation-result-2026-06-14-15","value":"Programme-house optimisation result (2026-06-14/15): best achievable is 1 fail (l1 wrong level, score ~0.005). 0 fails is geometrically impossible: l1 (min 27m²) must occupy ll (~23m²) at level 0, which eliminates the t3-adj-C provider; dividing ll into lll(l1)+llr(C) gives llr proportion ~6:1 (fails). Python memetic optimizer achieves 1 fail in 50k evals vs Perl optimiser's 2-3 fails. Winning topology: TWO C nodes at level 0 — ll(C) for t3-adj-C via geometric contact, rl(C) for staircase via tree-sibling adjacency to rrr(O). Best .dom: scratch/from-warmstart-fixed.dom and scratch/from-compound3-fixed.dom."} -{"_type":"memory","key":"unfold-strategy-for-shared-leaves-homemaker-py-8iv","value":"Unfold strategy for shared leaves (homemaker-py-8iv, resolved 2026-07-16): use the BALANCED GRID (operators._grow_balanced/_size_subtree_equal), NOT circulation-aware slicing. Slicing a shared leaf perpendicular to its access edge so every child touches the corridor was implemented + A/B-tested and LOST decisively (150k-eval warm-start polish from evolved-3M: slice 41 fails/3.5e-14 vs grid 25 fails/2.4e-09, grid ahead at every milestone). Reason: k rooms all touching one wall are intrinsically thin slices; that geometric debt (proportion/long/width) is unfixable without topology change, while the grid's squarer children let local search re-route access cheaply via level_retype/place_missing/level_fix. Lesson: at the sharing-\u003eno-sharing transition, prioritise squarer children and leave access to local search; do not reintroduce slicing in Schedule B (kpu)."} -{"_type":"memory","key":"warm-x0-initialization-bug-pattern-when-a-topology","value":"warm_x0 initialization bug pattern: when a topology operator explicitly sets division ratios on a newly-created node (e.g. compound_fix sets node.division=[0.25,0.25] for t3), parent.ratios has no entry for that node (it was a leaf). warm_x0 defaults it to 0.5, corrupting the inner loop's starting point and making the operator invisible to lex comparison. Fix: only propagate child ratios for nodes where the parent node was NOT already divided; stale hidden nodes revealed by structural mutations (swap flipping b.below) must NOT contribute their pre-writeback values. See driver.py lines 259-267 (fixed 2026-06-14)."} -{"_type":"memory","key":"homemaker-py-pythonpath-set-pythonpath-home-bruno-src","value":"homemaker-layout PYTHONPATH: package installed as 'homemaker-layout' via pip install -e . so 'import homemaker_layout' works from anywhere without PYTHONPATH. For running tests use 'python -m pytest' from project root /home/bruno/src/homemaker-layout (pyproject.toml adds src/ automatically). Never try pip show homemaker — that's the old homemaker-addon conflict."} -{"_type":"memory","key":"ld2-13-6-interior-o-seed-diagnostic-all","value":"ld2/§13.6 interior-O seed diagnostic: ALL crinkliness fails in the constructed bal+share seed are UNDER-exposed (crink\u003c0.62, landlocked rooms with no facade + no uncovered-O neighbour) — zero over-exposed sliver fails. So the erc crinkliness residual is genuine under-daylighting, validating the interior light-well premise. Default outside_divisor=6 was too sparse (null: harbor 147-\u003e142, crinkliness even rose). odiv=3 is the seed-optimal joint setting: harbor seed fails 147-\u003e129 (-18), maple 219-\u003e206 (-14), landlocked fails drop, at cost of more leaves (harbor +4, maple +8). Because it ADDS leaves it carries the §13.4 wash-out risk; A/B to convergence pending."} -{"_type":"memory","key":"island-model-psk-14-is-a-null-priming","value":"Island model (psk, §14) is a NULL: priming a population from N converged independent elites + crossover-heavy migration does not beat best-of-N at equal total budget (maple island 124 vs control 116). The child_probe instrument shows WHY: area-matched crossover across independently-converged elites almost never synthesizes (1-3 of ~64 children beat the better parent, max drop 2-5) because the slicing encoding is non-canonical (9gp), so splices are disruptive not combinatorial. Search-machinery null #3 after graded-objective and niching/restarts; residual stays geometry/shape-bound."} -{"_type":"memory","key":"proportion-aware-constructive-seeding-leu-2-12-2","value":"Proportion-aware constructive seeding (leu.2/§12.2): sizing seed cuts from target AREAS only regresses (thin slivers wreck aspect); you must ALSO pick each cut's rotation for child squareness. It is a convergence ACCELERATOR via a deeper local optimum around the constructed topology: wins where that topology is roughly right and budget is scarce (harbor -13%, maple -10% at 20k evals) but DELAYS small programmes where the seed must be restructured by undivide (programme-house regresses at fixed budget, yet reaches the floor given budget - speed, not asymptote). Default-on. Also: n_storeys must honour storey_minimum, not just level: keys (programme-house storey_minimum:2, all rooms level:0 - was seeded 1 storey short; cq1)."} {"_type":"memory","key":"collapse-global-94g-and-any-label-usage-optimisation","value":"collapse_global (94g) and any label/usage optimisation CANNOT fix geometry-intrinsic fails. The harbor-house 15-fail best layout contains long-thin cells that are useless whatever room usage is assigned — their width/proportion/crinkliness fails are shape-bound, not label slack. Two consequences: (1) do not over-claim collapse gains — only ~2-3 of that layout's fails are reclaimable relabel slack, the rest are geometry- or building-level bound; (2) the threshold objective must not be tuned to 'pass' a degenerate cell via a permissive room type — a metric-pass on a physically useless space is gaming, not a fix. Real remedies for these are geometry/topology search (cell shape) and circulation placement, filed separately, not the collapse."} -{"_type":"memory","key":"collapse-global-s-jacobi-adjacency-relaxation-homemaker-py","value":"collapse_global's Jacobi adjacency relaxation (homemaker-py-94g) is a synchronous per-round linear-assignment re-solve, which can 2-cycle indefinitely between two labellings that each satisfy ZERO adjacency requirements even though a permutation satisfying ALL of them exists -- proven on a minimal 4-cell chain (p1-q1-p2-q2, two disjoint adjacency pairs p1\u003c-\u003ep2/q1\u003c-\u003eq2) in test_two_opt_polish_escapes_jacobi_plateau. homemaker-py-9wi added Fitness._two_opt_adjacency_polish: a same-level pairwise-swap local search run after the Jacobi fixpoint, gated behind collapse_global(local_search=True) (default off, exposed as homemaker-collapse --local-search). Monotone by construction (a swap is kept only if it strictly increases total reward). Empirically on the 11 harbor-house evolved-*.dom/3m.dom/materialised-3M.dom layouts: 10 matched Jacobi-only exactly, 0 regressed, and evolved-anneal-3M.dom improved 21-\u003e19 fails (fixed a genuine mutual da1\u003c-\u003ek1 adjacency miss the Jacobi loop couldn't reach)."} -{"_type":"memory","key":"strategy-decision-2026-06-12-bruno-occlusion-daylight","value":"Strategy decision 2026-06-12 (Bruno): occlusion/daylight is ORTHOGONAL to building a scalable optimiser. Disable it in Urb (env flag, homemaker-py-gp2) rather than port it; native fitness uses simple crinkliness (illumination factor = 1); rebuild occlusion in Python only after optimisation is fully native (homemaker-py-2g5, now P4). Consequence: all scores change when the flag flips — re-baseline corpus/.score, DESIGN \\$4.5 gains, gate bars at one clean boundary AFTER homemaker-py-1p0 closes; Phase-2 urb-evolve benchmark must run with the same flag."} -{"_type":"memory","key":"cli-tool-style-prefer-python-m-homemaker-module","value":"CLI tool style: prefer python -m homemaker.module --parameters pattern, installable via pip install -e . with pyproject.toml entry_points. Not standalone bin/ scripts."} -{"_type":"memory","key":"run-to-run-reproducibility-in-homemaker-layout-serial","value":"Run-to-run reproducibility in homemaker-layout: serial search (workers=1) is byte-for-byte deterministic; parallel (workers\u003e1) is now deterministic too AFTER fixing driver._run_batch to admit futures in submission order (was as_completed/completion order, bug xcy). Reproducibility holds only for a FIXED worker count — serial vs parallel differ because children-per-iteration is 1 vs n_workers (different batch granularity), which is expected, not a bug. The constructive seeder was NEVER nondeterministic: _assign_adjacency_aware has unique idx tiebreaks; comparing topologies with Python builtin hash() of the signature STRING is invalid (PYTHONHASHSEED salts str hashing per process) — use a stable hash (sha1) or genome.signature equality."} +{"_type":"memory","key":"correction-to-urb-fitness-bug-memory-bruno-2026","value":"CORRECTION to urb-fitness-bug memory (Bruno, 2026-06-12): 'C' is NOT a 'covered' type — Is_Covered is a geometric predicate (indoor space above). Urb's generic types are canonically UPPERCASE: C=circulation, O=outside, S=sahn (get_space_types qw/C O S/; corpus is 100% uppercase, never 'c'/'o' leaves). The mixed-case designs that fired the latent ratio_type first-match bug were created by homemaker's own operator type pool emitting lowercase 'c'/'o' — fixed: driver/operators now emit uppercase generics only, and class checks use t[0].lower() in 'cos'. The Urb class-sum patch stays as defensive hardening (zero impact on canonical designs). Native port (3y7/gnw): treat type classes case-insensitively, generics canonically uppercase."} +{"_type":"memory","key":"deceptive-valleys-in-topology-search-when-every-single","value":"Deceptive valleys in topology search: when every single-step mutation from a target state passes through a high-fail intermediary (e.g. level_fix displaces a room into 5+ new fails), a compound operator that atomically applies two coordinated changes can escape. Design compound operators to land on the low-fail state directly, bypassing the deceptive gradient. Programme-house example: level_compound_fix atomically moves the level-constrained room AND re-inserts the displaced room adjacent to C in one step (operators.py, 2026-06-14)."} +{"_type":"memory","key":"experiment-seeding-pitfall-run-search-scaled-py-s","value":"Experiment seeding pitfall: run_search_scaled.py's default PH_SEED (c964…dom) is a FINISHED programme-house design — passing it warm-starts and floors at ~3 fails, NOT a blank-slate topology search. For blank-slate runs comparable to §11.5/§11.6 baselines, seed from examples/programme-house/init.dom (a bare undivided plot; driver bootstrap auto-triggers only on bare plots). Bit the 6zy sweep — first pass used c964 and falsely showed 3-fail floor across the whole grid."} +{"_type":"memory","key":"homemaker-py-pythonpath-set-pythonpath-home-bruno-src","value":"homemaker-layout PYTHONPATH: package installed as 'homemaker-layout' via pip install -e . so 'import homemaker_layout' works from anywhere without PYTHONPATH. For running tests use 'python -m pytest' from project root /home/bruno/src/homemaker-layout (pyproject.toml adds src/ automatically). Never try pip show homemaker — that's the old homemaker-addon conflict."} +{"_type":"memory","key":"homemaker-py-3l6-fix-leaf-sharing-evolve-runs","value":"homemaker-py-3l6 fix: leaf-sharing evolve runs now auto-finish before write via driver.polish_finish — unfold_shared_leaves() then a warm-started leaf_sharing=False polish search (--polish-budget, default budget//2). Makes the written .dom honest under canonical homemaker-fitness (internal==canonical when leaf_sharing off). Interrupt path forces polish_budget=0 (unfold+rescore only). This is yaa's unfold-then-polish, made automatic; Schedule B annealing is still kpu."} +{"_type":"memory","key":"warm-x0-initialization-bug-pattern-when-a-topology","value":"warm_x0 initialization bug pattern: when a topology operator explicitly sets division ratios on a newly-created node (e.g. compound_fix sets node.division=[0.25,0.25] for t3), parent.ratios has no entry for that node (it was a leaf). warm_x0 defaults it to 0.5, corrupting the inner loop's starting point and making the operator invisible to lex comparison. Fix: only propagate child ratios for nodes where the parent node was NOT already divided; stale hidden nodes revealed by structural mutations (swap flipping b.below) must NOT contribute their pre-writeback values. See driver.py lines 259-267 (fixed 2026-06-14)."} +{"_type":"memory","key":"9o5-multi-use-leaves-is-path-a-superposition","value":"9o5 multi-use leaves is path (a) — superposition as SEARCH RELAXATION that COLLAPSES to specific usage at the end, NOT path (b) loose-fit/no-collapse. Bruno's intent: codes with SIMILAR leaf requirements form an interchangeable equivalence class; during evolution the solver doesn't commit which leaf serves which specific usage (smoother landscape, no fighting over exact leaf usage); at the end the layout is CONDENSED to specific usages by brute-forcing the in-class assignment (3 interchangeable usages over 3 leaves = 3! = 6 combinations to check, pick best). 'Derive automatically' compatibility = requirement-similarity grouping. This reverses the issue's stated 'path b preferred' note."} +{"_type":"memory","key":"multi-storey-staircase-consistency-when-dividing-or-retyping","value":"Multi-storey staircase consistency: when dividing or retyping a circulation (C) leaf at one level, the same structural change should be propagated to the matching leaf on ALL other storeys so the stair core path is maintained. The optimizer cannot fix staircase disruptions through trial-and-error geometry alone — it requires a synchronized multi-level operator that applies the same topology change to every storey simultaneously."} {"_type":"memory","key":"urb-oracle-nondeterminism-urb-fitness-pl-output-varies","value":"Urb oracle nondeterminism: urb-fitness.pl output varies run-to-run from Perl hash-order randomisation — .fails line ORDER shuffles (compare sorted, use oracle.Score.fail_lines) and the score float can flip by ~1 ULP (compare with math.isclose rel_tol=1e-12, never ==). Not a batching artifact; affects single runs too. Matters for the Phase 3 native-fitness parity gate (homemaker-py-uxz)."} +{"_type":"memory","key":"adjacency-in-binary-slicing-tree-is-structural-not","value":"Adjacency in binary slicing tree is structural, not geometric: the inner-loop NM cannot fix topological adjacency failures. Two paths exist: (1) tree-sibling adjacency — a node is adjacent to its sibling in the tree; (2) cross-zone geometric adjacency — leaves from different subtrees that happen to share a boundary. Staircase/adjacency fails require a topology mutation that changes which nodes are siblings or which zones touch. This was proved empirically on programme-house: staircase fail from rot=0 layout could not be fixed by NM but was fixed by level_retype creating a two-C topology (2026-06-14/15)."} +{"_type":"memory","key":"experiment-harness-gotcha-the-leaf-sharing-relaxed-objective","value":"Experiment harness gotcha: the leaf-sharing RELAXED objective (§13.3) is injected ONLY by monkeypatching fitness.load_config in the parent process (run_staged_search.py / probe scripts). This is parent-process-only and does NOT propagate into ProcessPoolExecutor workers (n_workers\u003e1), which re-import fitness fresh and score under the STRICT on-disk patterns.config -\u003e r.n_fails MISMATCH (worker strict vs parent relaxed re-score). ALL §13.x floor runs were therefore SERIAL. Any future PARALLEL leaf-sharing experiment will silently mis-score until leaf_sharing lives on disk/CLI (tracked: homemaker-py-x3b). The parallel driver itself is correct; both paths score via load_config(programme_dir)."} +{"_type":"memory","key":"ld2-13-6-interior-o-seed-diagnostic-all","value":"ld2/§13.6 interior-O seed diagnostic: ALL crinkliness fails in the constructed bal+share seed are UNDER-exposed (crink\u003c0.62, landlocked rooms with no facade + no uncovered-O neighbour) — zero over-exposed sliver fails. So the erc crinkliness residual is genuine under-daylighting, validating the interior light-well premise. Default outside_divisor=6 was too sparse (null: harbor 147-\u003e142, crinkliness even rose). odiv=3 is the seed-optimal joint setting: harbor seed fails 147-\u003e129 (-18), maple 219-\u003e206 (-14), landlocked fails drop, at cost of more leaves (harbor +4, maple +8). Because it ADDS leaves it carries the §13.4 wash-out risk; A/B to convergence pending."} +{"_type":"memory","key":"proportion-aware-constructive-seeding-leu-2-12-2","value":"Proportion-aware constructive seeding (leu.2/§12.2): sizing seed cuts from target AREAS only regresses (thin slivers wreck aspect); you must ALSO pick each cut's rotation for child squareness. It is a convergence ACCELERATOR via a deeper local optimum around the constructed topology: wins where that topology is roughly right and budget is scarce (harbor -13%, maple -10% at 20k evals) but DELAYS small programmes where the seed must be restructured by undivide (programme-house regresses at fixed budget, yet reaches the floor given budget - speed, not asymptote). Default-on. Also: n_storeys must honour storey_minimum, not just level: keys (programme-house storey_minimum:2, all rooms level:0 - was seeded 1 storey short; cq1)."} +{"_type":"memory","key":"strategy-decision-2026-06-12-bruno-occlusion-daylight","value":"Strategy decision 2026-06-12 (Bruno): occlusion/daylight is ORTHOGONAL to building a scalable optimiser. Disable it in Urb (env flag, homemaker-py-gp2) rather than port it; native fitness uses simple crinkliness (illumination factor = 1); rebuild occlusion in Python only after optimisation is fully native (homemaker-py-2g5, now P4). Consequence: all scores change when the flag flips — re-baseline corpus/.score, DESIGN \\$4.5 gains, gate bars at one clean boundary AFTER homemaker-py-1p0 closes; Phase-2 urb-evolve benchmark must run with the same flag."} +{"_type":"memory","key":"collapse-global-s-jacobi-adjacency-relaxation-homemaker-py","value":"collapse_global's Jacobi adjacency relaxation (homemaker-py-94g) is a synchronous per-round linear-assignment re-solve, which can 2-cycle indefinitely between two labellings that each satisfy ZERO adjacency requirements even though a permutation satisfying ALL of them exists -- proven on a minimal 4-cell chain (p1-q1-p2-q2, two disjoint adjacency pairs p1\u003c-\u003ep2/q1\u003c-\u003eq2) in test_two_opt_polish_escapes_jacobi_plateau. homemaker-py-9wi added Fitness._two_opt_adjacency_polish: a same-level pairwise-swap local search run after the Jacobi fixpoint, gated behind collapse_global(local_search=True) (default off, exposed as homemaker-collapse --local-search). Monotone by construction (a swap is kept only if it strictly increases total reward). Empirically on the 11 harbor-house evolved-*.dom/3m.dom/materialised-3M.dom layouts: 10 matched Jacobi-only exactly, 0 regressed, and evolved-anneal-3M.dom improved 21-\u003e19 fails (fixed a genuine mutual da1\u003c-\u003ek1 adjacency miss the Jacobi loop couldn't reach)."} +{"_type":"memory","key":"unfold-strategy-for-shared-leaves-homemaker-py-8iv","value":"Unfold strategy for shared leaves (homemaker-py-8iv, resolved 2026-07-16): use the BALANCED GRID (operators._grow_balanced/_size_subtree_equal), NOT circulation-aware slicing. Slicing a shared leaf perpendicular to its access edge so every child touches the corridor was implemented + A/B-tested and LOST decisively (150k-eval warm-start polish from evolved-3M: slice 41 fails/3.5e-14 vs grid 25 fails/2.4e-09, grid ahead at every milestone). Reason: k rooms all touching one wall are intrinsically thin slices; that geometric debt (proportion/long/width) is unfixable without topology change, while the grid's squarer children let local search re-route access cheaply via level_retype/place_missing/level_fix. Lesson: at the sharing-\u003eno-sharing transition, prioritise squarer children and leave access to local search; do not reintroduce slicing in Schedule B (kpu)."} +{"_type":"memory","key":"urb-fitness-bug-found-fixed-2026-06-12","value":"Urb fitness bug found+fixed 2026-06-12 (patch in /home/bruno/src/urb, uncommitted): ProgrammeDriven.pm ratio_o/ratio_type grepped case-insensitively over the ratios hash and took the FIRST key — nondeterministic (x4.5 score swings) for designs with mixed-case type classes (both 'c' circulation and 'C' covered). Fixed to SUM the class (matches Is_Circulation//Is_Outside semantics); 35/35 corpus scores unchanged. CRITICAL for homemaker-py-3y7/gnw: the native port must implement class-SUM ratios. Building.pm has the same unpatched pattern (site-driven path, not used by our oracle). Also: the memetic search reward-hacked this bug before the fix — search results predating it are noise artifacts."} +{"_type":"memory","key":"user-preference-bruno-this-is-a-fedora-system","value":"User preference (Bruno): this is a Fedora system — NEVER install Python packages via pip without asking first; always ask whether to install the rpm via dnf (e.g. python3-cma) before considering pip. Applies to any dependency additions."} +{"_type":"memory","key":"cli-tool-style-prefer-python-m-homemaker-module","value":"CLI tool style: prefer python -m homemaker.module --parameters pattern, installable via pip install -e . with pyproject.toml entry_points. Not standalone bin/ scripts."} +{"_type":"memory","key":"never-use-corpus-filenames-candidate-001-dom-candidate","value":"Never use corpus filenames (candidate-001.dom, candidate-002.dom, generated.dom, init.dom, etc.) as --output targets when running experiments. These are test fixtures. Always write experimental outputs to scratch/ or a timestamped path. Lesson from 2026-06-14: warm-start runs overwrote candidate-001/002.dom and broke graph tests."} +{"_type":"memory","key":"island-model-psk-14-is-a-null-priming","value":"Island model (psk, §14) is a NULL: priming a population from N converged independent elites + crossover-heavy migration does not beat best-of-N at equal total budget (maple island 124 vs control 116). The child_probe instrument shows WHY: area-matched crossover across independently-converged elites almost never synthesizes (1-3 of ~64 children beat the better parent, max drop 2-5) because the slicing encoding is non-canonical (9gp), so splices are disruptive not combinatorial. Search-machinery null #3 after graded-objective and niching/restarts; residual stays geometry/shape-bound."} +{"_type":"memory","key":"programme-house-optimisation-result-2026-06-14-15","value":"Programme-house optimisation result (2026-06-14/15): best achievable is 1 fail (l1 wrong level, score ~0.005). 0 fails is geometrically impossible: l1 (min 27m²) must occupy ll (~23m²) at level 0, which eliminates the t3-adj-C provider; dividing ll into lll(l1)+llr(C) gives llr proportion ~6:1 (fails). Python memetic optimizer achieves 1 fail in 50k evals vs Perl optimiser's 2-3 fails. Winning topology: TWO C nodes at level 0 — ll(C) for t3-adj-C via geometric contact, rl(C) for staircase via tree-sibling adjacency to rrr(O). Best .dom: scratch/from-warmstart-fixed.dom and scratch/from-compound3-fixed.dom."} +{"_type":"memory","key":"run-to-run-reproducibility-in-homemaker-layout-serial","value":"Run-to-run reproducibility in homemaker-layout: serial search (workers=1) is byte-for-byte deterministic; parallel (workers\u003e1) is now deterministic too AFTER fixing driver._run_batch to admit futures in submission order (was as_completed/completion order, bug xcy). Reproducibility holds only for a FIXED worker count — serial vs parallel differ because children-per-iteration is 1 vs n_workers (different batch granularity), which is expected, not a bug. The constructive seeder was NEVER nondeterministic: _assign_adjacency_aware has unique idx tiebreaks; comparing topologies with Python builtin hash() of the signature STRING is invalid (PYTHONHASHSEED salts str hashing per process) — use a stable hash (sha1) or genome.signature equality."} diff --git a/DESIGN.md b/DESIGN.md index 36b20aa..ce6fa93 100644 --- a/DESIGN.md +++ b/DESIGN.md @@ -4476,3 +4476,108 @@ branch (DP infeasible + `best_n_fails<=0` prunes for 1 eval, skipping `predicted_shape_fails`); the defer branch (DP infeasible + `best_n_fails>0` still consults and obeys `predicted_shape_fails`, unchanged). Full suite: 393 passed. + +### 37.6 `homemaker-py-koo` multi-storey (below-link) support for the shape-curve DP — measured 2026-08-03, ACCEPTANCE: PASS + +**What was built.** `6xh`'s/`wkh`'s own deferred item: the DP's `eligible` +guard excluded any tree with `len(dom.levels(root)) > 1`, so it never fired +on `programme-house`/`harbor-house`'s real ≥2-storey, `leaf_sharing`-default +programmes — the gap both §37.4 and §37.5 flagged as the more direct route to +making either land's win apply day-to-day. `shapecurve.py` now processes +`dom.levels(root)` bottom-up, one storey at a time, instead of assuming a +single free tree. The key fact this is built on: `geometry.coordinate` mirrors +a `below`-linked node's corners from the storey below **unconditionally**, +regardless of whether that storey's counterpart is itself divided — so a +node with `below.divided` True has both its own outer box AND its split +ratio dictated by the (already-realised) storey below (dead variables, +exactly `solver.free_branches`' own free/fixed criterion), while a node +whose `below` is None or undivided has a genuinely free split — and, +critically, that free node's own outer box is *still* pinned by geometry +whenever `below` is not None (only the split inside that fixed box is +unknown). This means every free region the DP has to solve, at every storey, +reduces to the exact same single-region problem the pre-existing (single- +storey) `_check`/`realise` pair already solved — homemaker-py-koo added zero +new curve-composition math, only `_region_roots` (walks a storey's tree, +descending through `below.divided` spines without solving anything there, +collecting the below-fixed leaves and below-fixed-box/free-split fringe +nodes it bottoms out at) and `_solve_all_levels` (the per-storey sequential +driver: realise storey *i*'s free regions before checking storey *i+1*, since +storey *i+1*'s fixed boxes are read off storey *i*'s just-realised geometry, +not chosen; snapshot every storey's divisions up front and restore them +unless every region at every storey was feasible, preserving `solve`'s and +`is_feasible`'s pre-existing all-or-nothing/never-writes contracts exactly). +A below-fixed leaf (no search freedom — its (w, h) is a single known point) +is checked directly against `leaf_constraints` via `LeafBounds.h_range` +(`_leaf_feasible`) rather than routed through the grid-interpolated curve +machinery, avoiding a discretisation error that would otherwise be paid +uselessly, once per below-fixed leaf per storey, on a real multi-storey +building with dozens of wall-stacked rooms. `eligible` now allows any storey +count; only `leaf_sharing`/`superpose`/`max_share`/`multi_use` (still +unmodelled by `leaf_constraints`, `homemaker-py-tym`'s scope) remain excluded. + +**Validation** (`experiments/validate_shapecurve_multistorey.py`, same +protocol as §37.2/§37.5 — DP feasibility vs NM search minimising shape-fail +count directly, shape-fail-count-only comparison, see that module's +docstring for why): 200 topologies against the real, non-de-risked +`examples/harbor-house` (storey_minimum 2, full named-space programme, not +harbor-house-l0's C/O-only single-storey de-risk variant). Each trial starts +from a genuinely 2-storey seed (`operators.mutate_level_add` once on the bare +plot) and grows leaves across BOTH storeys via `driver.random_topology` +(`mutate_divide` picks candidate leaves from every level uniformly), so a +trial topology naturally mixes below-inherited-fixed spines with +below-fixed-box/free-split fringe nodes on the upper storey — exactly +`koo`'s new code path, not a corner case constructed to flatter it: + +| metric | harbor-house-l0 single-storey (§37.2, for scale) | harbor-house multi-storey (this session) | +|---|---|---| +| agreement | 198/200 = 99.0% | 199/200 = **99.5%** | +| false positives (DP feasible, NM can't reach 0) | 2 | 1 | +| false negatives (DP infeasible, NM reaches 0 anyway) | **0** | **0** | +| speedup (grid_n=150, vs 80-eval NM) | 97.2x | **117.7x** | +| DP feasible / NM 0-shape-fail | — | 4/200 / 3/200 | + +Zero false negatives — the property the hard-prune (`wkh`) branch actually +depends on — holds on the real multi-storey target at the same 200-topology +scale as every prior sweep (harbor-house-l0 unrotated 200 + rotated 100 + +re-run smoke 20, programme-house 200, this session's harbor-house +multi-storey 200 — 0 false negatives throughout, 720 topologies total across +the DP's whole validation history). The single false positive +(topology 119, seed 19314526) is consistent with the already-quantified +rectangle-vs-true-skewed-quad approximation error (§37.2) compounding across +two storeys rather than a new defect — not re-investigated to the same depth +§37.2 gave its own two false positives, since the safety-critical direction +(false negatives) is unaffected and the magnitude matches expectation. +Manual smoke test: `driver.search(..., shapecurve_warmstart=True)` and +`driver.search(..., shapecurve_prune=True, feasibility_filter=True, +feasibility_max_shape_fails=0)` both run to completion from +`examples/harbor-house/init.dom` (budget=300, 2 realised storeys in the +result) without error — the full pipeline this bead was blocking, not just +the DP in isolation. + +**Not done in this session** (deliberately out of scope, per the bead's own +framing): a `driver.search` A/B on multi-storey harbor-house at `6xh`/`wkh`'s +budget=2000/5-seed protocol — `koo`'s job was making the DP correct and safe +on multi-storey trees at all, which the DP-vs-NM agreement/false-negative +bar above (the same bar §37.2/§37.5 used) already clears; measuring the +search-level payoff is better sized as its own follow-up once +`leaf_sharing` support (`homemaker-py-tym`, still gating most real programmes +by default) lands too, so one A/B can measure the combined win instead of two +partial ones. `leaf_sharing`/`co_type` modelling and the true skew-quad +(non-rectangle) leaf region remain open, as they were before this session. + +**Verification.** `tests/test_shapecurve.py` (+4 tests, 1 renamed): `eligible` +no longer excludes multi-storey (renamed from +`test_eligible_guards_multistorey_and_sharing`); a 2-storey fixture whose +upper storey is a fresh free split pinned to the whole plot (ground storey +undivided) realises zero shape fails end to end; a mixed fixture (upper +storey a structural copy of the ground storey, i.e. below-fixed, with one +leaf further divided into two brand-new below-free leaves) writes ratios on +exactly `solver.free_branches` and leaves every below-fixed node's own +`division` byte-identical; the same mixed fixture with an intentionally +oversized child type is infeasible and rolls back **every** level, including +the ground storey already realised earlier in the same call, not just the +storey where infeasibility was detected; `is_feasible` never writes on either +multi-storey fixture. `tests/test_driver.py`: the multi-storey warm-start +test renamed and inverted (`test_shapecurve_warmstart_handles_multistorey` +now asserts `shapecurve.solve` **is** called on a multi-storey child, where +it previously asserted the opposite). Full suite: 397 passed. diff --git a/experiments/validate_shapecurve_multistorey.py b/experiments/validate_shapecurve_multistorey.py new file mode 100644 index 0000000..1b73bfb --- /dev/null +++ b/experiments/validate_shapecurve_multistorey.py @@ -0,0 +1,156 @@ +"""Multi-storey validation harness for shapecurve.py (homemaker-py-koo). + +Same protocol as validate_shapecurve.py (DP feasibility vs NM search that +directly MINIMISES shape-fail count, shape-fail-count-only comparison -- see +that module's docstring for why), but for genuinely multi-storey topologies: +each trial starts from a 2-storey seed (``operators.mutate_level_add`` once on +a bare single-leaf plot) and grows leaves across BOTH storeys via +``driver.random_topology``'s ``mutate_divide`` loop (which picks candidate +leaves from every level uniformly, see ``operators._leaves``), so a trial +topology naturally contains a mix of below-inherited-fixed spines and +below-fixed-box/free-split fringe nodes on the upper storey -- exactly the +scenario homemaker-py-koo generalised the DP for. + +Usage: python experiments/validate_shapecurve_multistorey.py [n_topologies] [nm_budget] [grid_n] [programme_dir] +""" + +from __future__ import annotations + +import copy +import sys +import time + +import numpy as np + +from homemaker_layout import dom, driver, fitness as fit_mod, geometry, innerloop, operators, solver +from homemaker_layout import shapecurve as sc + +PROGRAMME_DIR = "examples/harbor-house" +_SHAPE_SUFFIXES = (" size", " width", " proportion") + + +class ShapeFailEvaluator(innerloop.NativeEvaluator): + """Duplicated from validate_shapecurve.py (kept standalone-runnable, like + that script, rather than depending on package-relative imports): scores + -n_shape_fails (ties broken by the real fitness) so nm_search's greedy + hill-climb directly minimises shape-fail count instead of the full + aggregate objective -- see that module's docstring for why this is the + correct apples-to-apples comparison against what the DP claims to solve.""" + + def evaluate(self, xs): + results = [] + for x in xs: + self.apply(x) + root_copy = copy.deepcopy(self.root) + score, fails = self._fit.score_with_fails(root_copy) + n_shape = sum(1 for f in fails if f.endswith(_SHAPE_SUFFIXES)) + proxy_fitness = -n_shape + min(score, 0.999) + results.append(innerloop._NativeScore(fitness=proxy_fitness, fail_lines=fails)) + self.n_evals += len(xs) + self.n_oracle_calls += 1 + return results + + +def _two_storey_seed(programme_dir: str, rng: np.random.Generator, types: list[str]) -> dom.Node: + base = dom.load(f"{programme_dir}/init.dom") + two_storey, _ = operators.mutate_level_add(base, rng, types) + return two_storey + + +def main(n_topologies: int = 100, nm_budget: int = 100, grid_n: int = 150, + programme_dir: str = PROGRAMME_DIR) -> None: + conf, cost = fit_mod.load_config(programme_dir) + fit = fit_mod.Fitness(conf, cost) + types = sorted(fit.spaces.keys()) + + rng = np.random.default_rng(12345) + n_agree = 0 + n_dp_feasible = 0 + n_nm_feasible = 0 + false_positive = 0 # DP says feasible, NM finds a shape fail + false_negative = 0 # DP says infeasible, NM reaches 0 shape fails anyway + dp_time_total = 0.0 + nm_time_total = 0.0 + rows = [] + + i = 0 + attempts = 0 + while i < n_topologies: + attempts += 1 + n_leaves = int(rng.integers(3, 20)) + seed = int(rng.integers(0, 2**31 - 1)) + trng = np.random.default_rng(seed) + seed_root = _two_storey_seed(programme_dir, trng, types) + topo = driver.random_topology(seed_root, n_leaves, trng, types) + dom.link(topo) + if len(dom.levels(topo)) < 2: + continue + if len(solver.free_branches(topo)) < 2: + continue # not enough freedom for a meaningful multi-storey check + i += 1 + + t0 = time.time() + try: + dp_ok, info = sc.solve(topo, fit, grid_n=grid_n) + except Exception as exc: # noqa: BLE001 -- record and keep going + dp_ok, info = None, {"error": repr(exc)} + dp_time = time.time() - t0 + dp_time_total += dp_time + + t0 = time.time() + topo_nm = copy.deepcopy(topo) + geometry.clear_cache() + with ShapeFailEvaluator(topo_nm, programme_dir) as ev: + x0 = ev.x_current + if len(x0) == 0: + nm_shape_fails: list[str] = [] + else: + r = innerloop.nm_search(ev, x0, budget=nm_budget) + nm_shape_fails = [f for f in r.fail_lines if f.endswith(_SHAPE_SUFFIXES)] + nm_time = time.time() - t0 + nm_time_total += nm_time + nm_ok = len(nm_shape_fails) == 0 + + if dp_ok is None: + rows.append((i, n_leaves, seed, "ERROR", nm_ok, dp_time, nm_time, info.get("error"))) + continue + + if dp_ok: + n_dp_feasible += 1 + if nm_ok: + n_nm_feasible += 1 + agree = dp_ok == nm_ok + if agree: + n_agree += 1 + else: + if dp_ok and not nm_ok: + false_positive += 1 + else: + false_negative += 1 + rows.append((i, n_leaves, seed, dp_ok, nm_ok, dp_time, nm_time, len(nm_shape_fails))) + + print(f"topologies: {n_topologies} (attempts {attempts})") + print(f"agreement: {n_agree}/{n_topologies} = {100*n_agree/n_topologies:.1f}%") + print(f" false positive (DP feasible, NM shape-fails): {false_positive}") + print(f" false negative (DP infeasible, NM 0 shape-fails): {false_negative}") + print(f"DP feasible: {n_dp_feasible}/{n_topologies} NM 0-shape-fail: {n_nm_feasible}/{n_topologies}") + print(f"DP total time: {dp_time_total:.2f}s ({dp_time_total/n_topologies*1000:.1f} ms/topology)") + print(f"NM total time: {nm_time_total:.2f}s ({nm_time_total/n_topologies*1000:.1f} ms/topology)") + print(f"speedup: {nm_time_total/dp_time_total:.1f}x") + + print("\nmismatches:") + for row in rows: + if row[3] != row[4] and row[3] != "ERROR": + print(" ", row) + print("\nerrors:") + for row in rows: + if row[3] == "ERROR": + print(" ", row) + + +if __name__ == "__main__": + n = int(sys.argv[1]) if len(sys.argv) > 1 else 100 + budget = int(sys.argv[2]) if len(sys.argv) > 2 else 100 + grid_n = int(sys.argv[3]) if len(sys.argv) > 3 else 150 + prog_dir = sys.argv[4] if len(sys.argv) > 4 else PROGRAMME_DIR + main(n, budget, grid_n, prog_dir) diff --git a/src/homemaker_layout/driver.py b/src/homemaker_layout/driver.py index 07cd482..1fc1288 100644 --- a/src/homemaker_layout/driver.py +++ b/src/homemaker_layout/driver.py @@ -185,9 +185,10 @@ def _evaluate(root: dom.Node, programme_dir, urb_root, x0, budget, inner_kw, # incumbent is never discarded. Pruned individuals are tagged and never admitted. overrides = _overrides_for(leaf_sharing, superpose, max_share, conn_grade, collapse_insearch, multi_use) - # §37.4 shape-curve DP warm-start (homemaker-py-6xh, DESIGN.md §37.2/§37.4): - # when eligible (single storey, no leaf_sharing/superpose/max_share/multi_use - # — none of which the DP models) and no caller-supplied x0 (never override an + # §37.4/§37.6 shape-curve DP warm-start (homemaker-py-6xh/koo, DESIGN.md + # §37.2/§37.4/§37.6): when eligible (any storey count since homemaker-py-koo + # — none of leaf_sharing/superpose/max_share/multi_use, which the DP still + # doesn't model) and no caller-supplied x0 (never override an # explicit Lamarckian warm-start), solve for an exact shape-feasible ratio # point and write it onto the tree in place. `x0=None` below then picks it up # as the inner loop's start point. On infeasible or ineligible, `root` is left diff --git a/src/homemaker_layout/shapecurve.py b/src/homemaker_layout/shapecurve.py index 644ac9f..76ecd6d 100644 --- a/src/homemaker_layout/shapecurve.py +++ b/src/homemaker_layout/shapecurve.py @@ -36,11 +36,35 @@ Explicit scope (see ``eligible``, and DESIGN.md §37.2/§37 point 2): * ``leaf_sharing``/``co_type`` (multi-use leaves) target-adjustment is NOT modelled — ``leaf_constraints`` uses each leaf's own type's base params only. ``eligible`` excludes runs using either. - * Only a single storey is modelled: ``solve`` writes ``division`` on every - divided node under the given level root unconditionally, with no notion - of upper-storey ``below``-inherited (wall-stacked) fixed splits. Calling - it on a multi-storey tree would corrupt wall-stacking. ``eligible`` - excludes multi-storey topologies (``len(dom.levels(root)) > 1``). + +Multi-storey (homemaker-py-koo, DESIGN.md §37.6): ``solve``/``is_feasible`` +take the whole tree's level-0 root and process ``dom.levels(root)`` bottom-up, +one storey at a time. Within a storey, a divided node's split is only a DP +variable (free) when ``solver.free_branches``' own criterion holds (``below`` +is None, or not divided there) -- ``geometry.coordinate`` always mirrors a +``below``-linked node's corners from the storey below regardless of whether +that storey's counterpart is itself divided, so a node with ``below.divided`` +True has BOTH its own outer box AND its split ratio dictated by the (already- +realised) storey below; only a node whose ``below`` is None or undivided +introduces genuine freedom at this storey, and its outer box is nonetheless +already fixed by geometry whenever ``below`` is not None (only the split +inside that fixed box is free). ``_region_roots`` walks each storey's tree, +descending through ``below.divided`` spines (verifying nothing needs solving +there -- their shape is pinned, not searched) until it finds a node that is +either a plain leaf (``below`` not None: fixed point, checked directly by +feeding it through the ordinary single-leaf-curve path) or a genuinely free +subtree root (``below`` None -- always true for the level-0 root and for a +below-undivided fringe node's descendants, since a broken/absent below-chain +never resumes lower in the tree). Each such root is solved with the exact +same single-region ``_check``/``realise`` this module always had -- no +change to that machinery, only to how many independent roots a level +contributes and what box each is pinned to. Storeys are realised strictly +bottom-up (each storey's free regions are written to ``division`` before the +storey above is checked) because upper fixed boxes are read off the storey +below's *realised* geometry, not chosen; ``solve``/``is_feasible`` snapshot +every level's divisions first and restore them if any region anywhere is +infeasible (or always, for ``is_feasible``), so a caller never sees a +partially-mutated tree from a failed or read-only attempt. """ from __future__ import annotations @@ -66,13 +90,12 @@ def eligible(root: dom_mod.Node, leaf_sharing: bool = False, multi_use: bool = False) -> bool: """Is ``root`` inside this DP's validated scope for ``solve``? - Single storey only (no ``below``-inherited wall-stacking to model) and + Any storey count (homemaker-py-koo — ``solve``/``is_feasible`` handle + ``below``-inherited wall-stacking directly, see the module docstring) but none of ``leaf_sharing``/``superpose``/``max_share``/``multi_use`` (none - of which ``leaf_constraints`` models). See the module docstring. + of which ``leaf_constraints`` models). """ - return (len(dom_mod.levels(root)) == 1 - and not leaf_sharing and not superpose - and max_share is None and not multi_use) + return not leaf_sharing and not superpose and max_share is None and not multi_use def _interval_add(a: Interval, b: Interval) -> Interval: @@ -353,43 +376,133 @@ def build_curves_with_children( return Curve(w_of_h=w_of_h, h_of_w=h_of_w) -def _check(level_root: dom_mod.Node, fit, grid_n: int) -> tuple[ +def _check(region_root: dom_mod.Node, fit, grid_n: int) -> tuple[ Feasibility, dict[int, tuple[Curve, Curve]], np.ndarray, float, float]: - w_plot, h_plot = _dims(level_root) + """Solve one independently-free region (a level-0 root, or any node with + no ``below`` link -- see ``_region_roots``): its own outer box, from + ``_dims``, is either the plot itself or already fixed by a below-linked + ancestor; only the subtree's own splits are unknowns here.""" + w_plot, h_plot = _dims(region_root) grid = make_grid(max(w_plot, h_plot) * 1.2, n=grid_n) curves_by_node: dict[int, tuple[Curve, Curve]] = {} - root_curve = build_curves_with_children(level_root, fit, grid, curves_by_node) + root_curve = build_curves_with_children(region_root, fit, grid, curves_by_node) feas = check_feasible(root_curve, grid, w_plot, h_plot) return feas, curves_by_node, grid, w_plot, h_plot -def is_feasible(level_root: dom_mod.Node, fit, grid_n: int = 150) -> bool: - """Read-only DP feasibility verdict: does some equal-offset ratio - assignment clear the size/width/proportion FAIL_THRESHOLD for every leaf? +def _leaf_feasible(fit, leaf: dom_mod.Node) -> bool: + """Exact (gridless) feasibility check for a below-fixed leaf: its (w, h) + is a single known point, not a search, so this skips the grid entirely + rather than routing a degenerate one-point region through ``_check``'s + interpolated machinery (a discretisation error the multi-storey case + would otherwise pay repeatedly, once per below-fixed leaf per storey).""" + w, h = _dims(leaf) + b = leaf_constraints(fit, leaf) + hr = b.h_range(w) + return hr is not None and hr[0] - 1e-6 <= h <= hr[1] + 1e-6 + + +def _region_roots(level_root: dom_mod.Node) -> list[dom_mod.Node]: + """Nodes at which this storey's DP has genuine freedom to search. + + Descends through a ``below.divided`` spine without solving anything + there (module docstring: both the box and the split ratio of such a node + are dictated by the storey below, never chosen here) until it reaches + either a plain leaf (fixed if ``below`` is not None, otherwise an + ordinary free leaf -- only possible at a level-0 root) or a node with no + ``below`` link, whose subtree is composed exactly as the single-storey + DP always has: the level-0 root itself, or a below-undivided fringe node + (a fresh split introduced at this storey; ``geometry.coordinate`` still + fixes ITS OWN outer box from the below leaf it replaces, but nothing + beneath a broken/absent below-link is fixed, so ordinary composition + applies to its whole subtree, see the module docstring).""" + roots: list[dom_mod.Node] = [] + + def walk(node: dom_mod.Node) -> None: + if node.divided and node.below is not None and node.below.divided: + walk(node.left) + walk(node.right) + else: + roots.append(node) + + walk(level_root) + return roots + + +def _divided_nodes(node: dom_mod.Node) -> list[dom_mod.Node]: + if not node.divided: + return [] + return [node] + _divided_nodes(node.left) + _divided_nodes(node.right) + + +def _solve_all_levels(root: dom_mod.Node, fit, grid_n: int, *, commit: bool) -> tuple[bool, dict]: + """Bottom-up per storey (homemaker-py-koo, DESIGN.md §37.6): realise each + storey's free regions before checking the storey above, since an + above-storey's fixed boxes are read off THIS storey's already-realised + geometry (``geometry.coordinate``), not chosen by the DP. Every storey's + divisions are snapshotted up front and restored unless ``commit`` and + every region at every storey was feasible -- ``is_feasible`` always + restores (``commit=False``), matching its pre-existing never-writes + contract; ``solve`` keeps the writes only on overall success, the same + all-or-nothing contract the single-storey version always had. + """ + levels = dom_mod.levels(root) + snapshot = [(n, tuple(n.division)) for lvl in levels for n in _divided_nodes(lvl)] + w_plot, h_plot = _dims(levels[0]) + + feasible = True + n_regions = 0 + for level_root in levels: + if not feasible: + break + for region_root in _region_roots(level_root): + if not region_root.divided and region_root.below is not None: + if not _leaf_feasible(fit, region_root): + feasible = False + break + continue + n_regions += 1 + feas, curves, grid, w, h = _check(region_root, fit, grid_n) + if not feas.feasible: + feasible = False + break + realise(region_root, curves, grid, w, h) + geometry.clear_cache() + + if not commit or not feasible: + for n, d in snapshot: + n.division = list(d) + geometry.clear_cache() + + return feasible, { + "w_plot": w_plot, "h_plot": h_plot, + "n_levels": len(levels), "n_regions": n_regions, + } + + +def is_feasible(root: dom_mod.Node, fit, grid_n: int = 150) -> bool: + """Read-only DP feasibility verdict, across every storey of ``root``: + does some equal-offset ratio assignment clear the size/width/proportion + FAIL_THRESHOLD for every leaf, at every level (homemaker-py-koo)? Unlike :func:`solve`, never writes ``division`` — the hard-prune caller (``driver._evaluate``, homemaker-py-wkh) needs the boolean verdict alone, without the warm-start's tree mutation (kept a strictly separate code path so the two experimental flags, ``shapecurve_prune``/``shapecurve_warmstart``, compose cleanly and can be A/B'd independently).""" - feas, *_ = _check(level_root, fit, grid_n) - return feas.feasible + feasible, _ = _solve_all_levels(root, fit, grid_n, commit=False) + return feasible -def solve(level_root: dom_mod.Node, fit, grid_n: int = 150) -> tuple[bool, dict]: - """End-to-end: compute plot dims, build curves, check root feasibility, - and (if feasible) write realising ratios in place. Returns (feasible, - info) where info carries timing-relevant intermediates for the caller. +def solve(root: dom_mod.Node, fit, grid_n: int = 150) -> tuple[bool, dict]: + """End-to-end, across every storey of ``root`` (homemaker-py-koo): solve + each level bottom-up and, if every level's every free region is + feasible, leave the realising ratios written in place. Returns (feasible, + info) where info carries the overall plot dims and a couple of diagnostic + counts for the caller. - ``level_root`` must be a single storey (see ``eligible``) — the DP has no - notion of upper-storey ``below``-inherited fixed splits and will - overwrite ``division`` unconditionally on every divided node it walks. + On infeasible, ``root`` is restored exactly as passed in — no partial + writes from an earlier, feasible storey are left behind (see + ``_solve_all_levels``). """ - feas, curves_by_node, grid, w_plot, h_plot = _check(level_root, fit, grid_n) - if feas.feasible: - realise(level_root, curves_by_node, grid, w_plot, h_plot) - geometry.clear_cache() - return feas.feasible, { - "w_plot": w_plot, "h_plot": h_plot, - "grid": grid, "h_range_at_w": feas.h_range_at_w, "w_range_at_h": feas.w_range_at_h, - } + return _solve_all_levels(root, fit, grid_n, commit=True) diff --git a/tests/test_driver.py b/tests/test_driver.py index fed60ea..f0f2b22 100644 --- a/tests/test_driver.py +++ b/tests/test_driver.py @@ -333,10 +333,11 @@ def test_shapecurve_warmstart_seeds_ratios_when_eligible(monkeypatch): ) -def test_shapecurve_warmstart_skips_multistorey(monkeypatch): - """homemaker-py-6xh: the DP has no notion of ``below``-inherited - (wall-stacked) fixed splits, so it must never be invoked on a - multi-storey topology — ``shapecurve.eligible`` guards this.""" +def test_shapecurve_warmstart_handles_multistorey(monkeypatch): + """homemaker-py-koo: the DP now models ``below``-inherited (wall-stacked) + fixed splits directly (DESIGN.md §37.6), so ``shapecurve.eligible`` no + longer excludes a multi-storey topology and the warm-start path invokes + it exactly as it would a single-storey one.""" from homemaker_layout import shapecurve def fake_optimise(root, programme_dir, x0=None, budget=200, urb_root=None, **kw): @@ -357,7 +358,7 @@ def test_shapecurve_warmstart_skips_multistorey(monkeypatch): driver.search(multi_root, CORPUS, budget=200, pop_size=2, child_budget=60, seed_budget=60, seed=1, bootstrap=False, shapecurve_warmstart=True, leaf_sharing=False) - assert not solve_calls + assert solve_calls, "shapecurve.solve must be called for an eligible multi-storey child" HARBOR_L0 = Path(__file__).parent.parent / "examples" / "harbor-house-l0" diff --git a/tests/test_shapecurve.py b/tests/test_shapecurve.py index 3265441..643b695 100644 --- a/tests/test_shapecurve.py +++ b/tests/test_shapecurve.py @@ -2,6 +2,7 @@ experiments/shapecurve_spike.py; see DESIGN.md §37.2/§37.4 for the full 200-topology validation this unit scale is a fast smoke check of).""" +import copy from pathlib import Path import numpy as np @@ -28,7 +29,53 @@ def _small_feasible_topology(): return driver.random_topology(seed, 2, rng, ["C", "O"]) -def test_eligible_guards_multistorey_and_sharing(): +def _two_storey_feasible_topology(): + """Level 0: the whole plot as one undivided 'O' room (trivially + feasible, below is always None at level 0). Level 1: an independent + fresh 2-leaf 'C'/'O' topology whose root inherits the *whole plot* as + its fixed box (its below -- level 0's root -- exists but is undivided, + so the root itself is a free-region-root per ``shapecurve._region_roots``, + pinned to the same box ``_small_feasible_topology`` already validates as + shape-feasible for a single storey).""" + base_seed = dom.load(str(HARBOR_L0 / "init.dom")) + level0 = copy.deepcopy(base_seed) + level0.type = "O" + rng = np.random.default_rng(0) + level1 = driver.random_topology(dom.load(str(HARBOR_L0 / "init.dom")), 2, rng, ["C", "O"]) + level0.above = level1 + dom.link(level0) + return level0 + + +def _two_storey_mixed_topology(child_types=("O", "O")): + """Level 0: the same 2-leaf 'C'/'O' topology ``_small_feasible_topology`` + validates. Level 1: an exact structural copy (so its root and both + leaves start out below-inherited/FIXED, wall-stacked on level 0), with + one of its leaves (``target``, id 'l') further divided into two brand + new leaves of ``child_types`` -- a genuine below-fixed-box/free-split + (case B) fringe node nested under a below-fixed-divided (case A) root, + the mixed scenario ``homemaker-py-koo`` adds support for. Returns + ``(root, target)``.""" + seed = dom.load(str(HARBOR_L0 / "init.dom")) + rng = np.random.default_rng(0) + level0 = driver.random_topology(seed, 2, rng, ["C", "O"]) + level1 = copy.deepcopy(level0) + level0.above = level1 + dom.link(level0) + + target = level1.left + target.division = [0.5, 0.5] + target.rotation = 0 + target.left = dom.Node(rotation=0, type=child_types[0]) + target.right = dom.Node(rotation=0, type=child_types[1]) + dom.link(level0) + return level0, target + + +def test_eligible_guards_sharing_not_storey_count(): + """homemaker-py-koo: multi-storey is now handled (below-inherited fixed + splits, DESIGN.md §37.6), so ``eligible`` only guards the still-unmodelled + leaf_sharing/superpose/max_share/multi_use family.""" root = dom.load(str(HARBOR_L0 / "generated.dom")) assert len(dom.levels(root)) == 1 assert shapecurve.eligible(root) @@ -40,7 +87,8 @@ def test_eligible_guards_multistorey_and_sharing(): seed = dom.load(str(HARBOR_L0 / "init.dom")) seed.above = dom.Node(rotation=0) # fake a second storey assert len(dom.levels(seed)) == 2 - assert not shapecurve.eligible(seed) + assert shapecurve.eligible(seed) + assert not shapecurve.eligible(seed, leaf_sharing=True) def test_solve_feasible_root_realises_zero_shape_fails(tmp_path): @@ -110,3 +158,109 @@ def test_is_feasible_agrees_with_solve_but_never_writes(monkeypatch): assert shapecurve.is_feasible(infeasible_root, fit) is False after = [tuple(b.division) for b in solver.free_branches(infeasible_root)] assert before == after + + +# --------------------------------------------------------------------------- # +# Multi-storey (homemaker-py-koo, DESIGN.md §37.6) +# --------------------------------------------------------------------------- # + + +def test_solve_multistorey_feasible_realises_zero_shape_fails(tmp_path): + """A 2-storey topology whose upper storey is a fresh, independently-free + 2-leaf split (pinned to the whole plot, since the ground storey below it + is a single undivided room) round-trips to zero size/width/proportion + fails at every level, exactly like the single-storey case.""" + root = _two_storey_feasible_topology() + fit = _fit() + + feasible, info = shapecurve.solve(root, fit) + assert feasible is True + assert info["w_plot"] > 0 and info["h_plot"] > 0 + assert info["n_levels"] == 2 + + out_path = tmp_path / "realised.dom" + out_path.write_text(dom.dumps(root)) + reloaded = dom.load(str(out_path)) + + _, fails = fit.score_with_fails(reloaded) + shape_fails = [f for f in fails if f.endswith((" size", " width", " proportion"))] + assert shape_fails == [] + + +def test_solve_multistorey_matches_free_branches(tmp_path): + """Mixed fixture: level 1 is a structural copy of level 0 (so its root + and both original leaves are below-fixed) with one leaf further divided + into two brand new 'O' leaves (a below-fixed-box/free-split fringe node + nested under a below-fixed-divided root). ``solve`` must write ratios on + exactly ``solver.free_branches`` -- the pre-existing single-storey + invariant this generalises -- and leave every below-fixed node's own + ``division`` byte-identical, even though it sits on a realised subtree.""" + root, target = _two_storey_mixed_topology(child_types=("O", "O")) + level1 = root.above + fit = _fit() + + all_nodes_before = [(n, list(n.division)) + for lvl in dom.levels(root) for n in shapecurve._divided_nodes(lvl)] + free_before = [b for b in solver.free_branches(root)] + + feasible, _ = shapecurve.solve(root, fit) + assert feasible is True + + # level 1's own root is below-fixed (its below, level 0's root, is + # divided) so it must never appear as a free branch, and 'target' (a + # fresh split introduced only at level 1) must. + assert any(b is target for b in solver.free_branches(root)) + assert not any(b is level1 for b in solver.free_branches(root)) + + for node, before in all_nodes_before: + if any(node is b for b in free_before): + continue + assert node.division == before, "below-fixed node's division must never be written" + + out_path = tmp_path / "realised.dom" + out_path.write_text(dom.dumps(root)) + reloaded = dom.load(str(out_path)) + _, fails = fit.score_with_fails(reloaded) + shape_fails = [f for f in fails if f.endswith((" size", " width", " proportion"))] + assert shape_fails == [] + + +def test_solve_multistorey_infeasible_restores_every_level(): + """When an upper-storey free split is infeasible (a 'C' leaf forced into + a below-fixed box too tall for its proportion/size bounds -- verified by + inspection, not tuned to just barely fail), ``solve`` must roll back + ALL levels, including the ground storey it already realised earlier in + the same call -- not just the storey where infeasibility was detected.""" + root, target = _two_storey_mixed_topology(child_types=("C", "O")) + level1 = root.above + fit = _fit() + + before = { + id(n): list(n.division) + for lvl in dom.levels(root) for n in shapecurve._divided_nodes(lvl) + } + + feasible, _ = shapecurve.solve(root, fit) + assert feasible is False + + after = { + id(n): list(n.division) + for lvl in dom.levels(root) for n in shapecurve._divided_nodes(lvl) + } + assert after == before, "an infeasible upper storey must not leave the ground storey mutated" + + +def test_is_feasible_multistorey_never_writes(): + fit = _fit() + + feasible_root = _two_storey_feasible_topology() + before = [tuple(b.division) for b in solver.free_branches(feasible_root)] + assert shapecurve.is_feasible(feasible_root, fit) is True + after = [tuple(b.division) for b in solver.free_branches(feasible_root)] + assert before == after + + infeasible_root, _ = _two_storey_mixed_topology(child_types=("C", "O")) + before = [tuple(b.division) for b in solver.free_branches(infeasible_root)] + assert shapecurve.is_feasible(infeasible_root, fit) is False + after = [tuple(b.division) for b in solver.free_branches(infeasible_root)] + assert before == after