bd: sync issues.jsonl (close-out states for erc epic + 71d chain)

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JygRv4n2dcyDQqMiDRe7TN

.beads/issues.jsonl

@@ -3,7 +3,7 @@
 {"id":"homemaker-py-erc.3","title":"Experiment: leaf-sharing / multi-room leaves in construction","description":"Strongest untried construction lever. §12.3 named 'merge or share leaves across same-class rooms' but c3g never tested it — c3g only coarsened the circulation spine (circ_divisor), trading shape gains for equal access/adjacency damage (null). Leaf-sharing is DIFFERENT: it reduces leaf count by collapsing same-class rooms (e.g. several O/storage, or same-type repeated rooms) into a shared leaf, attacking crinkliness(346)+size(242) directly WITHOUT coarsening circulation — so it should dodge the access penalty that sank c3g.\n\nImplementation sketch: in operators.constructive_topology (+ lift path), allow rooms of the same class/type (and compatible adjacency) to be instantiated as one larger leaf rather than one-leaf-per-room, lowering leaves-per-room from ~1.4 toward 1.0 or below. Honour storey_minimum and required-room presence (a shared leaf must still satisfy each merged room's presence/area in the fitness check, or the merge must be limited to rooms the fitness treats as fungible).\n\nTests the deepest open question: whether 52 rooms simply cannot be well-shaped as 52 leaves at this density. A/B vs §12.2 baseline (maple 136.0, harbor 74.0), seeds 0/1/2, 20000 evals, staged; default-OFF toggle so controls reproduce. Record DESIGN.md §13.3.","notes":"A/B DONE (§13.3): staged 20k, seeds 0/1/2, factor 3. maple 137.0→86.3 (−37%), harbor 74.0→50.3 (−32%). Baseline arm reproduces §12.2 exactly (maple 137 vs 136, harbor 74.0 vs 74.0). Total separation: every share run beats every baseline run same-programme. ~35% faster (fewer leaves). First Phase-8 floor-mover; 5th construction/seed win. Closing.","status":"closed","priority":1,"issue_type":"feature","assignee":"Bruno Postle","owner":"bruno@postle.net","created_at":"2026-06-22T23:16:15Z","created_by":"Bruno Postle","updated_at":"2026-06-24T20:51:20Z","started_at":"2026-06-23T21:51:08Z","closed_at":"2026-06-24T20:51:20Z","close_reason":"Closed","dependencies":[{"issue_id":"homemaker-py-erc.3","depends_on_id":"homemaker-py-erc","type":"parent-child","created_at":"2026-06-23T00:16:15Z","created_by":"Bruno Postle","metadata":"{}"},{"issue_id":"homemaker-py-erc.3","depends_on_id":"homemaker-py-erc.1","type":"blocks","created_at":"2026-06-23T00:16:42Z","created_by":"Bruno Postle","metadata":"{}"}],"dependency_count":1,"dependent_count":0,"comment_count":0}
 {"id":"homemaker-py-erc.2","title":"Diagnostic B: undersize-despite-slack localization (construction-target vs inner-loop-fill)","description":"GATES the plot-fill-construction vs inner-loop-expansion decision. The paradox from §12.3: plot utilisation is 0.44 (56% empty) yet size fails are 242 (rooms UNDERSIZE). Where is the slack stranded, and at which stage should it be spent?\n\nMeasure, on constructive seeds for maple-court + harbor (seeds 0/1/2):\n1. After CONSTRUCTION (before inner loop): per-leaf achieved area vs target area, and total occupied vs plot area. Are leaves parked at target with the slack left as unused plot, or is the slack distributed but mis-shaped?\n2. After the INNER LOOP optimises ratios: did size fails drop — i.e. does the ratio solve already expand leaves into slack, or does it have no gradient/incentive to exceed target? Compare predicted_shape_fails (target geometry) vs achieved size fails (post-optimise).\n\nThe §12.3 calibration (floor at TARGET dims ≈ achieved) already hints the inner loop is NOT filling slack — confirm and quantify, and identify whether the gap is (a) construction targets too-small dims given the plot, or (b) the objective gives no reward for exceeding target area. Output: DESIGN.md §13.2.\n\nDECISION RULE: if rooms are parked at target with unused plot → fix in CONSTRUCTION (plot-fill, erc child). If the inner loop has the room to expand but no objective gradient → fix in the INNER LOOP (slack-expansion term, erc child). Reads only; no behaviour change.","notes":"VERDICT (DESIGN.md §13.2): the '56% empty plot' is a misreading. Sized rooms already occupy ~50-54% of plot and hold 1.4-1.5x their aggregate target area (util\u003etgtFill); ~46% of plot is CIRCULATION, not claimable void (out only 3-4%). Size fails are pure MALDISTRIBUTION set by SLICING POSITION: median room at target (a/t~1.0) but long undersize tail (p25~0.35, min 0.05) starves while a few giants balloon (max 6.8x harbor, 14.7x maple). Same type/target lands at BOTH extremes (harbor r t=10: 68m2 \u0026 2.3m2; maple n t=60: ~target \u0026 2.7m2) =\u003e area dictated by binary-tree depth, not target. Inner loop CANNOT repair it: budget-80 size fails move only -1.6/-3.7, %undersize flat-to-worse; frozen-topology ratio DOF + 0.5^n cliff + symmetric size gaussian. =\u003e FALSIFIES plot-fill-as-claim-void (re-scope erc.4 to depth-balanced/giant-splitting construction), DEPRIORITISE erc.6 (wrong DOF). Reinforces erc.3 leaf-sharing for the starved tail. Script: experiments/diag_slack_localization.py","status":"closed","priority":1,"issue_type":"task","assignee":"Bruno Postle","owner":"bruno@postle.net","created_at":"2026-06-22T23:15:42Z","created_by":"Bruno Postle","updated_at":"2026-06-23T21:46:34Z","started_at":"2026-06-23T21:17:07Z","closed_at":"2026-06-23T21:46:34Z","close_reason":"Closed","dependencies":[{"issue_id":"homemaker-py-erc.2","depends_on_id":"homemaker-py-erc","type":"parent-child","created_at":"2026-06-23T00:15:42Z","created_by":"Bruno Postle","metadata":"{}"}],"dependency_count":0,"dependent_count":2,"comment_count":0}
 {"id":"homemaker-py-erc.1","title":"Diagnostic A: per-leaf shape-fail vs density/granularity profile","description":"GATES the leaf-sharing vs compactness-cuts decision. The open question from §12.3: is the shape floor intrinsic to slicing at this leaf density (→ fewer leaves is the only lever), or fixable by better-shaped cuts at the same leaf count?\n\nMeasure: per-leaf shape-fail rate (crinkliness/size/proportion/width, broken out) as a function of leaves-per-room and plot utilisation, across the existing programmes spanning density — harbor (16 rooms) vs maple-court (52 rooms) — and, if cheap, a synthetic sweep that holds the programme fixed while varying leaf count (e.g. reuse the circ_divisor / construction granularity knob already in place to generate coarser vs finer constructive seeds and score predicted_shape_fails per leaf).\n\nReads, does not change behaviour: use operators.predicted_shape_fails + the per-leaf factor breakdown already in fitness.py (the §12.3 residual table was produced this way). Output: a table of per-leaf shape-fail vs density, written into DESIGN.md §13.1.\n\nDECISION RULE (write it into the verdict): if per-leaf shape-fail is FLAT across densities → floor is intrinsic to slicing density → prioritise leaf-sharing (erc child), deprioritise/close compactness-cuts. If it RISES with density → better cuts can pay → keep compactness-cuts. This is a measurement, not an experiment; no A/B, no baseline reproduction needed.","notes":"VERDICT (DESIGN.md §13.1): per-leaf shape-fail is FLAT vs slicing density in the controlled synthetic sweep (maple-court, room set fixed, circ_divisor 2-\u003e9: leaves 81-\u003e63, per-leaf rate 1.72-1.94 with no trend; TOTAL shape fails track leaf count ~linearly 139-\u003e116). Crinkliness dominates (~0.8/leaf) and is flat. Cuts already squarest (_size_divisions_from_targets) yet still ~1.8 fails/leaf =\u003e little compactness headroom at fixed count. Floor is INTRINSIC to per-leaf slicing. =\u003e prioritise leaf-sharing (erc.3), deprioritise compactness-cuts (erc.5). NOT the c3g null: that removed circulation leaves (access damage cancelled gain); leaf-sharing removes ROOM-leaf count without touching the spine. Script: experiments/diag_leaf_shapefail.py","status":"closed","priority":1,"issue_type":"task","assignee":"Bruno Postle","owner":"bruno@postle.net","created_at":"2026-06-22T23:15:40Z","created_by":"Bruno Postle","updated_at":"2026-06-23T21:00:34Z","started_at":"2026-06-23T20:53:52Z","closed_at":"2026-06-23T21:00:34Z","close_reason":"Closed","dependencies":[{"issue_id":"homemaker-py-erc.1","depends_on_id":"homemaker-py-erc","type":"parent-child","created_at":"2026-06-23T00:15:39Z","created_by":"Bruno Postle","metadata":"{}"}],"dependency_count":0,"dependent_count":2,"comment_count":0}
-{"id":"homemaker-py-erc","title":"Phase 8: lower the geometry/shape floor — construction \u0026 inner-loop levers","description":"Continuation of Phase 7 (leu, closed). Phase 7's decisive finding (§12.3 calibration): predicted_shape_fails at the best achievable geometry ≈ the achieved total fail count (maple floor 121-163 vs achieved 126-148). Therefore SEARCH MACHINERY CANNOT HELP — there is no lower-fail basin for the constructed topologies to reach; the floor IS the result. Scoreboard: 4/4 wins from construction/seed quality (§11.2, §11.6, §11.7, §12.2), 0/3 from search machinery (§11.4, §11.5, §12.3). The only way to lower fails is to lower the geometry FLOOR.\n\nResidual decomposition (maple-court, 6 constructive seeds, §12.3): crinkliness 346 + size 242 (undersize) + proportion 121 + width 102, with plot utilisation only 0.44 (56% of plot empty) yet rooms UNDERSIZE. Diagnosed mechanism: over-granular construction — 73 leaves for 52 rooms — every leaf high perimeter/area (crinkliness) and below target area (size). c3g tested ONE granularity lever (circulation-spine coarsening via circ_divisor) → null (shape gain cancelled by equal access/adjacency damage). The other named levers were never tested.\n\nThis epic runs DIAGNOSTICS FIRST to decide which floor-lowering lever to invest in, then the construction/inner-loop experiments in dependency order. Tier-3 search-machinery bets (island model psk, tournament pressure 6zy) are tracked but LOW prior — do not invest there until something moves the floor.\n\nShared protocol (every experiment): A/B on maple-court + harbor, seeds 0/1/2, 20000 evals, staged; controls MUST reproduce the §12.2 baseline (maple 136.0, harbor 74.0); record verdict in DESIGN.md (new §13.x). Same discipline as every lever in §11-§12.","status":"open","priority":1,"issue_type":"epic","owner":"bruno@postle.net","created_at":"2026-06-22T23:14:56Z","created_by":"Bruno Postle","updated_at":"2026-06-22T23:14:56Z","dependency_count":0,"dependent_count":0,"comment_count":0}
+{"id":"homemaker-py-erc","title":"Phase 8: lower the geometry/shape floor — construction \u0026 inner-loop levers","description":"Continuation of Phase 7 (leu, closed). Phase 7's decisive finding (§12.3 calibration): predicted_shape_fails at the best achievable geometry ≈ the achieved total fail count (maple floor 121-163 vs achieved 126-148). Therefore SEARCH MACHINERY CANNOT HELP — there is no lower-fail basin for the constructed topologies to reach; the floor IS the result. Scoreboard: 4/4 wins from construction/seed quality (§11.2, §11.6, §11.7, §12.2), 0/3 from search machinery (§11.4, §11.5, §12.3). The only way to lower fails is to lower the geometry FLOOR.\n\nResidual decomposition (maple-court, 6 constructive seeds, §12.3): crinkliness 346 + size 242 (undersize) + proportion 121 + width 102, with plot utilisation only 0.44 (56% of plot empty) yet rooms UNDERSIZE. Diagnosed mechanism: over-granular construction — 73 leaves for 52 rooms — every leaf high perimeter/area (crinkliness) and below target area (size). c3g tested ONE granularity lever (circulation-spine coarsening via circ_divisor) → null (shape gain cancelled by equal access/adjacency damage). The other named levers were never tested.\n\nThis epic runs DIAGNOSTICS FIRST to decide which floor-lowering lever to invest in, then the construction/inner-loop experiments in dependency order. Tier-3 search-machinery bets (island model psk, tournament pressure 6zy) are tracked but LOW prior — do not invest there until something moves the floor.\n\nShared protocol (every experiment): A/B on maple-court + harbor, seeds 0/1/2, 20000 evals, staged; controls MUST reproduce the §12.2 baseline (maple 136.0, harbor 74.0); record verdict in DESIGN.md (new §13.x). Same discipline as every lever in §11-§12.","status":"closed","priority":1,"issue_type":"epic","owner":"bruno@postle.net","created_at":"2026-06-22T23:14:56Z","created_by":"Bruno Postle","updated_at":"2026-06-28T13:22:26Z","closed_at":"2026-06-28T13:22:26Z","close_reason":"all steps complete","dependency_count":0,"dependent_count":0,"comment_count":0}
 {"id":"homemaker-py-leu.1","title":"Larger-than-house benchmark programme (\u003e16 rooms) + baseline","description":"PREREQUISITE for the whole epic. Harbor (16 rooms) is the biggest real programme in examples/; 9gp's scaling claim ('\u003e16 rooms') and acceptance criterion ('larger-than-house programme') cannot be measured without a bigger one.\n\nBuild a reproducible benchmark programme larger than harbor (target ~24-32 rooms, multi-storey, with a realistic per-level required-room partition and adjacency-to-c load like harbor's). Provide its patterns.config / costs.config (reuse config inheritance, homemaker-py-n5k) and an init.dom, mirroring the examples/harbor-house layout. Wire it into the existing experiment harnesses (run_search_scaled.py / run_staged_search.py) and record a BASELINE total-fail count at a fixed budget for the current default search (adjacency-aware seeding + staged), exactly as §11.6/§11.7 reported harbor. This baseline is the yardstick proportion-seeding and 9gp are measured against.\n\nDeliverable: examples/\u003cnew\u003e/ with configs+init.dom, a documented baseline (seeds 0-2, total fails at budget), recorded in DESIGN.md §12.1 + bead notes.","acceptance_criteria":"A \u003e16-room multi-storey benchmark exists under examples/, runs through the current harness, and has a documented baseline fail count (\u003e=3 seeds) recorded in DESIGN.md.","notes":"Benchmark delivered: examples/maple-court/ (26 entries / 52 rooms / 3 storeys, ~1015 m2 internal, ~790 m2/floor plot). Mirrors harbor's adjacency-to-c load + secondary adjacencies; room codes avoid generic c/o/s leading letters. Baseline (staged adjacency-aware, URB_NO_OCCLUSION=1, 20000 evals): seed0=145, seed1=158, seed2=152, mean=151.7 fails. All native re-score OK. Best (145, seed0) saved as generated.dom. Recorded in DESIGN.md §12.1.","status":"closed","priority":1,"issue_type":"task","assignee":"Bruno Postle","owner":"bruno@postle.net","created_at":"2026-06-19T11:13:59Z","created_by":"Bruno Postle","updated_at":"2026-06-19T12:33:31Z","started_at":"2026-06-19T11:17:25Z","closed_at":"2026-06-19T12:33:31Z","close_reason":"Closed","dependencies":[{"issue_id":"homemaker-py-leu.1","depends_on_id":"homemaker-py-leu","type":"parent-child","created_at":"2026-06-19T12:13:59Z","created_by":"Bruno Postle","metadata":"{}"}],"dependency_count":0,"dependent_count":2,"comment_count":0}
 {"id":"homemaker-py-leu","title":"Phase 7: scaling validation \u0026 residual reduction (post-c4c)","description":"Continuation of the closed c4c epic (Phase 6). Phase 6 evidence is decisive about WHERE leverage lives: the two search-machinery experiments (§11.4 graded high-fail objective, §11.5 niching+restarts) BOTH landed negative and BOTH concluded the high-fail plateau is a REACHABILITY problem (operators+encoding cannot reach low-fail basins), not population-management or objective-shaping. The two wins (§11.6 adjacency-aware seeding, §11.7 adjacency-aware lift) came from CONSTRUCTION/SEED quality. Harbor is now ~85 fails (best 78), down from the 95/105 plateaus; the residual is geometry/shape-bound (size/proportion/crinkliness).\n\nThree gaps block further scaling progress and must be done in order:\n1. There is NO larger-than-house benchmark. Harbor (16 rooms) is the biggest real programme in examples/. 9gp's headline claim is scaling \u003e16 rooms and its acceptance criterion demands 'a larger-than-house programme' to measure on — so a bigger benchmark is a PREREQUISITE, not optional.\n2. Proportion-aware seeding: §11.6 noted the seed uses 0.5 splits -\u003e 'more, smaller leaves' -\u003e geometry fails. Sizing splits from target dims attacks the §11.7 geometry residual directly, in the proven construction direction; cheaper than an encoding rewrite.\n3. 9gp (canonical Polish encoding) must be RE-SCOPED: its 'topology signature for niching' justification is dead (§11.5 falsified niching; genome.signature already exists as the cheap stand-in). The surviving, evidence-supported parts are M1/M2/M3 Wong-Liu moves (reachability) and shape-feasibility pruning (residual + inner-loop budget = scaling).\n\nOrdering rationale: benchmark first (makes scaling measurable for everything downstream), then the cheap proven-direction seeding win (sets the strongest baseline), then the re-scoped canonical-encoding capstone (lands on the best seed, with a benchmark to prove its scaling claim).","design":"Do NOT build search/selection machinery on unmeasured premises — that is exactly what §11.4/§11.5 did and both regressed. Every child lands an experiment with results recorded in DESIGN.md §12.x + bead notes, same discipline as Phase 6. The benchmark child is the root dependency; proportion-seeding depends on it (so the win is measured at scale too); re-scoped 9gp depends on both (best baseline + scaling measurement).","acceptance_criteria":"(1) A reproducible \u003e16-room benchmark exists with a documented baseline fail count; (2) proportion-aware seeding shows a measured fail reduction on harbor AND the new benchmark; (3) re-scoped 9gp lands M1/M2/M3 + shape feasibility and shows measured search improvement on the larger-than-house benchmark.","notes":"EPIC COMPLETE. leu.1 established the \u003e16-room maple-court benchmark (baseline 151.7→ leu.2 136.0). leu.2 proportion-aware seeding: measured win on both larger programmes (harbor -13%, maple -10%), default-on. 9gp (re-scoped): M3 reassociate + shape-feasibility filter landed + measured NEGATIVE — the residual is the geometry/shape floor of the constructed layouts, not reachability/feasibility-bound. Net: Phase 7 reduced the benchmark residual via construction (leu.2) and validated that further search-machinery gains are unavailable (9gp), a 3rd search-machinery negative vs 4 construction wins. See DESIGN.md §12.","status":"closed","priority":1,"issue_type":"epic","owner":"bruno@postle.net","created_at":"2026-06-19T11:13:29Z","created_by":"Bruno Postle","updated_at":"2026-06-21T06:21:30Z","closed_at":"2026-06-21T06:21:01Z","close_reason":"all steps complete","dependency_count":0,"dependent_count":0,"comment_count":0}
 {"id":"homemaker-py-c4c.3","title":"Staged per-floor search (curriculum: credible base floor, then upper floors as deltas)","description":"Search the genome in its causal dependency order. The base-floor tree is the master; upper storeys are deltas (Below-inheritance). The programme partitions rooms by required level (harbor: 10 L0, 4 L1, 2 free), so each floor's target room set is known up front. Today the search discovers both floors simultaneously via random typing + the rare/drastic level_add (weighted 0.2) — an uncontrolled, degenerate version of staging.\nStage 1 — base floor: search the single-storey tree over the level-0 room set, dimensionality reduced (one tree, no deltas).\nStage 2 — upper floors as deltas: seed each upper storey with ITS required room set (via the construction op, homemaker-py-c4c.2), search the deltas; keep the base MUTABLE at low probability so it can adapt to upper-floor pressure.\nCRITICAL non-goal: do NOT hard-freeze the base. A base optimised purely as ground floor is a §4.2-style partial objective and can be a bad SUBSTRATE. Stage 1 objective must include (a) a reserved, vertically-alignable circulation core and (b) a substrate-readiness term: enough divisible area/cut structure to host the level-1 room set later.","design":"Premise gated by homemaker-py-c4c.1: only high-value if single-storey construction already reaches low fails. Substrate-readiness proxy candidates: count of base leaves large enough to subdivide for L1 rooms; presence of a core node with vertical continuity. Stage transition: when stage-1 base hits a fails/score threshold or budget fraction, freeze-soft and open the delta genome. Composes with canonical encoding (homemaker-py-9gp) — deltas are where redundancy/coarse moves hurt most.","acceptance_criteria":"Staged search beats single-stage on harbor-house (best fails/score), measured at equal native-fitness budget and recorded in DESIGN.md §11.x + bead notes. Reserved-core + substrate-readiness shown to prevent the bungalow trap (stage-2 does not have to carve a core from scratch — track core-carving moves). No regression on programme-house.","notes":"DONE. Implemented driver.search_staged (Stage 1 single-storey base over level-0 set with substrate-readiness ranking bonus; Stage 2 upper floors lifted as constructed deltas, base mutable at base_p=0.15). New: programme.{n_storeys_required,partition_rooms_by_storey,write_stage1_programme}, graph.substrate_readiness, operators.{lift_base_to_storeys,_pick_weighted_by_storey,base_p}, driver.search rank_bonus_fn/seed_factory/base_p hooks, experiments/run_staged_search.py, tests/test_staging.py. RESULT (harbor, 20000 evals, seed 0): staged 95 fails vs single-stage 105 (-10, -9.5%); gain in crinkliness 27-\u003e18 + edge 12-\u003e8, small access cost +5. Anti-bungalow CONFIRMED: all Stage-2 core_divide/undivide in winning lineage are noops (core inherited, not carved). Regression PASS: programme-house warmstart-2f4 still reaches whole-pop 1-fail. DESIGN.md §11.3 filled. Remaining high-fail plateau is §11.4 (graded objective) territory.","status":"closed","priority":1,"issue_type":"feature","assignee":"Bruno Postle","owner":"bruno@postle.net","created_at":"2026-06-17T19:01:01Z","created_by":"Bruno Postle","updated_at":"2026-06-18T05:04:48Z","started_at":"2026-06-18T04:25:07Z","closed_at":"2026-06-18T05:04:48Z","close_reason":"Closed","dependencies":[{"issue_id":"homemaker-py-c4c.3","depends_on_id":"homemaker-py-c4c","type":"parent-child","created_at":"2026-06-17T20:01:00Z","created_by":"Bruno Postle","metadata":"{}"},{"issue_id":"homemaker-py-c4c.3","depends_on_id":"homemaker-py-c4c.1","type":"blocks","created_at":"2026-06-17T20:01:00Z","created_by":"Bruno Postle","metadata":"{}"},{"issue_id":"homemaker-py-c4c.3","depends_on_id":"homemaker-py-c4c.2","type":"blocks","created_at":"2026-06-17T20:01:01Z","created_by":"Bruno Postle","metadata":"{}"}],"dependency_count":2,"dependent_count":0,"comment_count":0}
@@ -49,7 +49,7 @@
 {"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-jrb","title":"Bakeoff: repair operator vs baseline on harbor-house","description":"Bake off the failure-directed repair operator against the current baseline on examples/harbor-house (3m.dom config). Seed from the 3M best (3m.dom) and run ~200k evals, multiple seeds. Also sweep child_budget DOWN (e.g. 80 -\u003e 40 -\u003e 20) to test the hypothesis that reallocating evals from ratio-polishing to topology repair lowers fails. Metric: final n_fails and crinkliness/connected/access counts. Reuse experiments/bakeoff_harbor.py pattern.","status":"open","priority":3,"issue_type":"task","owner":"bruno@postle.net","created_at":"2026-06-23T20:40:21Z","created_by":"Bruno Postle","updated_at":"2026-06-23T20:49:55Z","dependencies":[{"issue_id":"homemaker-py-jrb","depends_on_id":"homemaker-py-71d","type":"parent-child","created_at":"2026-06-23T21:49:55Z","created_by":"Bruno Postle","metadata":"{}"},{"issue_id":"homemaker-py-jrb","depends_on_id":"homemaker-py-u8x","type":"blocks","created_at":"2026-06-23T21:40:35Z","created_by":"Bruno Postle","metadata":"{}"}],"dependency_count":1,"dependent_count":0,"comment_count":0}
+{"id":"homemaker-py-jrb","title":"Bakeoff: repair operator vs baseline on harbor-house","description":"Bake off the failure-directed repair operator against the current baseline on examples/harbor-house (3m.dom config). Seed from the 3M best (3m.dom) and run ~200k evals, multiple seeds. Also sweep child_budget DOWN (e.g. 80 -\u003e 40 -\u003e 20) to test the hypothesis that reallocating evals from ratio-polishing to topology repair lowers fails. Metric: final n_fails and crinkliness/connected/access counts. Reuse experiments/bakeoff_harbor.py pattern.","status":"closed","priority":3,"issue_type":"task","owner":"bruno@postle.net","created_at":"2026-06-23T20:40:21Z","created_by":"Bruno Postle","updated_at":"2026-06-28T13:22:12Z","closed_at":"2026-06-28T13:22:12Z","close_reason":"Superseded by construction (DESIGN §13.7): 71d chain closed; interior-O dissolved the landlocked-crinkliness target the bakeoff would have measured.","dependencies":[{"issue_id":"homemaker-py-jrb","depends_on_id":"homemaker-py-71d","type":"parent-child","created_at":"2026-06-23T21:49:55Z","created_by":"Bruno Postle","metadata":"{}"},{"issue_id":"homemaker-py-jrb","depends_on_id":"homemaker-py-u8x","type":"blocks","created_at":"2026-06-23T21:40:35Z","created_by":"Bruno Postle","metadata":"{}"}],"dependency_count":1,"dependent_count":0,"comment_count":0}
 {"id":"homemaker-py-u8x","title":"mutate_repair: failure-directed topology repairs","description":"New operator mutate_repair(parent_root, fails, reqs, rng) in operators.py dispatching on failure class, targeting the leaf id named in each fail string. Priority order = ratio-invariant fails first:\n- crinkliness on L -\u003e retype a geometric neighbour of L to O (interior light well) or reassociate/swap L toward facade (attacks 13)\n- 'level N not connected' -\u003e retype a bridging leaf to C to join circulation components (attacks 2)\n- access on L -\u003e retype a neighbour to C (attacks 1)\n- too few stairs -\u003e core_divide to add aligned vertical core (attacks 1)\nReuse leaf-adjacency graph from _assign_adjacency_aware, plus reassociate/core_divide/retype. Wire into operators.mutate weighting and the driver child-generation path (driver.py:452). Depends on fails being available (parent thread task).","status":"closed","priority":3,"issue_type":"task","owner":"bruno@postle.net","created_at":"2026-06-23T20:40:18Z","created_by":"Bruno Postle","updated_at":"2026-06-28T13:21:55Z","closed_at":"2026-06-28T13:21:55Z","close_reason":"Superseded by construction (DESIGN §13.7): interior-O (default-ON, erc.8) is 71d's named fix (interior O courtyards) and collapsed landlocked crinkliness ~13-\u003e2 of 20 in the high-budget probe. Residual now diffuse, no concentrated ratio-invariant block for a targeted repair operator. Reopen/refile if a future floor probe shows a concentrated ratio-invariant class return.","dependencies":[{"issue_id":"homemaker-py-u8x","depends_on_id":"homemaker-py-71d","type":"parent-child","created_at":"2026-06-23T21:49:53Z","created_by":"Bruno Postle","metadata":"{}"},{"issue_id":"homemaker-py-u8x","depends_on_id":"homemaker-py-7u5","type":"blocks","created_at":"2026-06-23T21:40:33Z","created_by":"Bruno Postle","metadata":"{}"}],"dependency_count":1,"dependent_count":1,"comment_count":0}
 {"id":"homemaker-py-71d","title":"Failure-directed topology-repair operator (harbor-house plateau)","description":"harbor-house plateaus at 27 fails under a 3M-eval run. Fail breakdown of the 3M best (3m.dom): 13 crinkliness, 7 size, 2 edge-too-long, 2 level-not-connected, 1 proportion, 1 access, 1 too-few-stairs.\n\nDiagnosis: ~16 of 27 fails (crinkliness 13, not-connected 2, access 1, stairs 1... actually 17 incl stairs) are INVARIANT to split ratios, but the inner loop (child_budget=80 CMA evals/child) spends essentially all eval budget on ratios. The outer comparator only keeps n_fails (driver.py:259) and operators pick targets at random, so the search reaches these discrete adjacency/daylight fails only by luck.\n\nCrinkliness root cause: a landlocked leaf (no facade edge, no adjacent uncovered O) has area_outside=0 -\u003e crink=0 -\u003e quality_uncrinkliness hits the 'if not crink: return 0.0' branch (fitness.py:339) -\u003e guaranteed fail for ALL ratios. Big rooms (cr1 80m2, da1 60m2, n 60m2) are worst. Fix is interior O courtyards / facade access = TOPOLOGY only.\n\nPlan: read the parent's structured .fails (already computed at driver.py:146, just not stored on Individual) and apply targeted, mostly-deterministic topology repairs per failure class, attacking the ratio-invariant fails the inner loop cannot touch. Reuses reassociate, core_divide, retype, and the leaf-adjacency graph.","notes":"Reparented under erc (Phase 8) as a Tier-3 search-machinery bet, LOW prior per erc's thesis ('search machinery cannot help — the floor IS the result', 0/3 wins from grade/niching/feasibility). Honest framing: this is NOT refuted by that scoreboard — those 3 losses were all selection/pruning changes; none added a TARGETED REPAIR OPERATOR, which is a new class. But do not invest here until a construction lever (erc.3/.4/ld2) moves the floor. Must follow erc's shared protocol: A/B maple-court + harbor seeds 0/1/2, 20k evals staged, control reproduces baseline (maple 136.0, harbor 74.0), verdict in DESIGN.md §13.x.","status":"closed","priority":3,"issue_type":"feature","owner":"bruno@postle.net","created_at":"2026-06-23T20:39:34Z","created_by":"Bruno Postle","updated_at":"2026-06-28T13:21:46Z","closed_at":"2026-06-28T13:21:46Z","close_reason":"Superseded by construction (DESIGN §13.7): interior-O (default-ON, erc.8) is 71d's named fix (interior O courtyards) and collapsed landlocked crinkliness ~13-\u003e2 of 20 in the high-budget probe. Residual now diffuse, no concentrated ratio-invariant block for a targeted repair operator. Reopen/refile if a future floor probe shows a concentrated ratio-invariant class return.","dependencies":[{"issue_id":"homemaker-py-71d","depends_on_id":"homemaker-py-erc","type":"parent-child","created_at":"2026-06-23T21:49:50Z","created_by":"Bruno Postle","metadata":"{}"}],"dependency_count":0,"dependent_count":0,"comment_count":0}
 {"id":"homemaker-py-psk","title":"Experiment: island model — prime population from N independent seeds, crossover-heavy migration phase","description":"User-proposed lever (2026-06-23): the Perl Urb workflow ran the search many times and kept the best because runs settled into different local minima. The Python tool is deterministic per --seed, so the analog is: run N independent seeds (e.g. 16), then PRIME a fresh population with those N converged elites and run a second, crossover-heavy phase — an island model with synchronous migration.\n\nKEY DISTINCTION from prior negatives: this is NOT the §11.5 (c4c.5) niching/restart experiment. Those injected FRESH constructive/random seeds for raw diversity and landed null. Here the migrants are FULLY-CONVERGED elites (each spent a complete budget), so they are high-quality building blocks, not diversity filler. The §11.5 'diversity does not help' result does not directly refute this; the mechanism is different (recombination of converged basins, not exploration).\n\nHONEST PRIOR (against): this is a SEARCH-MACHINERY bet, and the leu/c4c epics are decisive that search machinery keeps landing neutral-to-negative (§11.4 graded objective, §11.5 niching+restarts, §9gp M3 reachability + shape-feasibility filter = 3 search-machinery negatives) while CONSTRUCTION/SEED quality wins (§11.6 adjacency-aware seeding, §11.7 adjacency-aware lift = 4 construction wins). The residual is diagnosed as geometry/shape-bound (size/proportion/crinkliness), not population-management-bound. So baseline expectation is neutral.\n\nWHY IT MIGHT STILL PAY: the one untested sub-mechanism is whether crossover can stack wins across independent basins (run A solved cluster X, run B solved cluster Y, child inherits both -\u003e lower total fails than either parent). That has never been tested with converged migrants.","design":"Control / baseline: 'best-of-N' — run N=16 seeds, take the single lowest-fail/highest-fitness result. This is essentially free (the N runs happen anyway) and is the legitimate descendant of Urb's multi-run habit. The experiment must BEAT best-of-N to count, on equal TOTAL budget (N short runs + migration phase vs N+ longer independent runs).\n\nPhase A: run search() for seeds 0..N-1 at a per-seed budget, collect each result.best.root (.dom).\nPhase B: prime a population from those N elites and continue evolving with high p_crossover (e.g. 0.5-0.8) to stress recombination. Reuse existing machinery — no new representation:\n  - The seed_factory / bootstrap path in driver.search already accepts a custom seed producer; a factory that cycles through the N pre-evolved roots primes the population directly (no fresh construction).\n  - Set bootstrap=True so the N elites are evaluated as the initial population, then the memetic loop runs.\n\nALIGNMENT RISK to measure, not assume: operators.crossover (operators.py:1001) is AREA-MATCHED subtree exchange — it pairs a region of A with the area-closest third of B, with no notion of programmatic/spatial role. Two independently-evolved trees encode similar arrangements with different tree structures (the encoding is not canonical — 9gp closed-negative, abandoned), so the same functional cluster sits at a different path/area/orientation per run. Area-matched splice across independent optima may therefore be disruptive rather than synthesizing, and the inner loop re-solves ratios at the splice boundary (spliced quality not preserved). Instrument: track whether any migration child ever beats max(parent fails) reduction; if crossover children are never net-positive, the null is mechanistic (alignment), not budget.\n\nBenchmarks: maple-court + harbor seeds (the §12.x A/B set), so controls reproduce documented baselines (maple 136.0, harbor 74.0). Record in DESIGN.md (new §12.x) per project convention.\n\nNOT gated on canonical encoding: 9gp is CLOSED with a negative verdict (associativity/reachability tested directly, did not pay). Do not revive the Polish rewrite as a prerequisite.","status":"open","priority":3,"issue_type":"task","owner":"bruno@postle.net","created_at":"2026-06-22T23:06:30Z","created_by":"Bruno Postle","updated_at":"2026-06-22T23:06:30Z","dependencies":[{"issue_id":"homemaker-py-psk","depends_on_id":"homemaker-py-6zy","type":"related","created_at":"2026-06-23T00:06:59Z","created_by":"Bruno Postle","metadata":"{}"},{"issue_id":"homemaker-py-psk","depends_on_id":"homemaker-py-9gp","type":"related","created_at":"2026-06-23T00:07:01Z","created_by":"Bruno Postle","metadata":"{}"},{"issue_id":"homemaker-py-psk","depends_on_id":"homemaker-py-c4c.5","type":"related","created_at":"2026-06-23T00:07:02Z","created_by":"Bruno Postle","metadata":"{}"}],"dependency_count":0,"dependent_count":0,"comment_count":0}
@@ -65,23 +65,23 @@
 {"id":"homemaker-py-8fe","title":"Fix Urb programme width default (upstream of homemaker-py-can fix)","description":"The native fitness fix in homemaker-py-can derives a sane width from sqrt(size/proportion) when a programme space has no explicit width. The same bug exists upstream in Perl Urb: Fitness/Base.pm and ProgrammeDriven.pm fall back to width_inside [4.0, 1.0] for any programme space without an explicit width key. Fix the Perl oracle to match the native behaviour (same sqrt(size/proportion) formula).","status":"closed","priority":3,"issue_type":"bug","assignee":"Bruno Postle","owner":"bruno@postle.net","created_at":"2026-06-13T21:18:19Z","created_by":"Bruno Postle","updated_at":"2026-06-13T22:14:17Z","started_at":"2026-06-13T21:43:33Z","closed_at":"2026-06-13T22:14:17Z","close_reason":"Fixed: get_space_params now derives width from sqrt(size/proportion) when no explicit width key is present. 34/36 corpus files score higher with the fix; all 111 tests pass after rescoring with URB_NO_OCCLUSION=1.","dependency_count":0,"dependent_count":0,"comment_count":0}
 {"id":"homemaker-py-can","title":"Programme width defaults: t3 contradiction (impossible width_inside default)","description":"DESIGN.md §8.2, confirmed in source. t3 (3 m2 WC) has no width spec so inherits width_inside [4.0, 1.0] (Fitness/Base.pm:60) — geometrically impossible; designs 'pass' only by failing size instead. Fix AFTER faithful-port validation (port-faithfully-first policy, §8.1): a sane width default scaled to area (e.g. sqrt(area/proportion)) or per-room widths in patterns.config. Applies to native fitness; optionally upstream to Urb.","acceptance_criteria":"No programme space has a default width incompatible with its target area; corpus re-scored and effect documented","status":"closed","priority":3,"issue_type":"bug","assignee":"Bruno Postle","owner":"bruno@postle.net","created_at":"2026-06-11T23:39:01Z","created_by":"Bruno Postle","updated_at":"2026-06-13T21:21:37Z","started_at":"2026-06-13T21:16:11Z","closed_at":"2026-06-13T21:21:37Z","close_reason":"Fixed in get_space_params: when a programme space has no explicit 'width', derive target from sqrt(size/proportion) instead of falling back to width_inside [4.0, 1.0]. Re-scored 35-file corpus: 32 files improved (+1-121%), 5 files lost spurious width fails. All 109 tests pass. Upstream Perl fix tracked as homemaker-py-8fe.","dependencies":[{"issue_id":"homemaker-py-can","depends_on_id":"homemaker-py-uxz","type":"blocks","created_at":"2026-06-12T00:39:47Z","created_by":"Bruno Postle","metadata":"{}"}],"dependency_count":1,"dependent_count":0,"comment_count":0}
 {"id":"homemaker-py-yg5","title":"Penalty reshaping: replace 0.5^n while preserving inner-loop protection","description":"DESIGN.md §4.7, §5.4, §7 Phase 4, §8.5. The 0.5^n cliff gives the outer search no gradient and rewards flag-count over geometry, but it also PROTECTS the inner loop from trading into new failures (§4.5). One fitness shape cannot naively be both soft outside and cliff-protected inside. Candidates: cliff-inside-inner-loop only, lexicographic (failure count first, score second), additive/soft, multi-objective Pareto. Must preserve the missing-space failure hierarchy (worse to drop a room than to have a poor one). Measure landscape + search outcomes; this helps Urb today too.","acceptance_criteria":"Chosen scheme documented with measurements: search improves while inner loop still never trades into new failures","status":"closed","priority":3,"issue_type":"feature","assignee":"Bruno Postle","owner":"bruno@postle.net","created_at":"2026-06-11T23:39:00Z","created_by":"Bruno Postle","updated_at":"2026-06-14T08:16:14Z","started_at":"2026-06-14T07:55:32Z","closed_at":"2026-06-14T08:16:14Z","close_reason":"Implemented lexicographic outer-search comparison (-n_fails, fitness). Inner loop unchanged (0.5^n cliff protection preserved). Experiment penalty_reshape.py confirms 0/9 fail regressions in inner loop and shows lex avoids the 3-fail trap that scalar hits 1/3 of the time. Fixed stale _CHILD_INNER_KW sigmas entry.","dependencies":[{"issue_id":"homemaker-py-yg5","depends_on_id":"homemaker-py-uxz","type":"blocks","created_at":"2026-06-12T00:39:46Z","created_by":"Bruno Postle","metadata":"{}"}],"dependency_count":1,"dependent_count":0,"comment_count":0}
-{"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":"open","priority":4,"issue_type":"feature","owner":"bruno@postle.net","created_at":"2026-06-22T23:16:24Z","created_by":"Bruno Postle","updated_at":"2026-06-23T21:47:05Z","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.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":"open","priority":4,"issue_type":"feature","owner":"bruno@postle.net","created_at":"2026-06-22T23:16:21Z","created_by":"Bruno Postle","updated_at":"2026-06-23T21:00:46Z","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-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":"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":"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":"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":"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":"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":"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":"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":"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":"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":"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":"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":"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."}
 {"_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":"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":"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":"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":"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":"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":"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":"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":"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":"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":"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":"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."}