Python rewrite of the Urb/Homemaker stack
Find a file
Claude 3aee813ccd
§39.8: homemaker-py-2v1 connectivity weighting — MEASURED NULL, premise retracted
§38.2 concluded the objective is net-positive on severing a level's
circulation: merging a corridor into a habitable sibling gains x6
(value_inside/value_circulation), while "level N not connected" costs x0.5, so
break-even needs 0.5^w < 50/300, w > 2.58 -- "severing must cost at least 3
fails and costs 1". The arithmetic is right. The premise is wrong.

Shipped anyway, EXPERIMENTAL and default off (byte-identical):
fitness.connectivity_weight_for(value_inside, value_circulation) returns the
smallest weight making severing net-negative -- 3.0 at the defaults, DERIVED
from the rates rather than hard-coded so it tracks them if either is retuned.
conf["connectivity_weight"] takes 1.0 / "auto" / a number and counts each
connectivity failure as w failures in the 0.5^n penalty.

MEASUREMENT: at auto (=3) the §38.2 deletion test does not move at all -- 5/25
rewarded either way, median x0.26 vs x0.27. Reason: the connectivity fail count
is UNCHANGED in every rewarded deletion (115->107 fails but 5->5 connectivity;
107->99 but 3->3; 78->71 but 3->3). Weighting a fail that never fires changes
nothing.

And when a deletion DOES break connectivity, it is already punished. Every such
case, 4 seeds per programme: harbor-house 2 of 32 sampled deletions, both
punished (x0.00, x0.01); maple-court 5 of 32, all punished (x0.58 .. x0.07).
Severing costs 1-2 connectivity fails PLUS the cascade after them, which
already outweighs the x6 gain. The flat rule was never the problem.

Where §38.2 went wrong: the x4.06 "well-daylit circulation leaf" that motivated
the bead was a deletion that did NOT change the connectivity fail count. It was
rewarded for removing the leaf's own quality failures -- §38.1's zero-value
finding -- and I misread it as a pricing mechanism. §38.2 now carries the
retraction inline. Two lessons recorded: a plausible closed-form arithmetic is
not a measurement, and when a fix produces exactly no effect, suspect the
premise before the implementation.

Still standing from §38: §38.1 (buried leaves score zero quality and contribute
no value) and §38.3 (frontage budget) are direct measurements. §39.7 remains
the better lever on the same symptom -- it made the connectivity fails FIRE,
where this would only have made them cost more.

Re-opened as homemaker-py-yql: why level-not-connected persists in the best
layout when severing is already punished. Evidence now points at reachability,
not incentive, and it is newly measurable because §39.7 stopped store cupboards
standing in for corridors.

353 passed (+3 new), same 7 pre-existing fixture failures, lint unchanged.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MJ84Feep79Hhm3E4zZJmnB
2026-08-26 14:15:22 +00:00
.beads §39.8: homemaker-py-2v1 connectivity weighting — MEASURED NULL, premise retracted 2026-08-26 14:15:22 +00:00
.claude Scaffold homemaker-py with validated geometry port 2026-06-10 20:50:20 +01:00
examples §39.7: access requirements become a declared usage: attribute (homemaker-py-sel) 2026-08-26 13:39:41 +00:00
experiments §39.7: access requirements become a declared usage: attribute (homemaker-py-sel) 2026-08-26 13:39:41 +00:00
src/homemaker_layout §39.8: homemaker-py-2v1 connectivity weighting — MEASURED NULL, premise retracted 2026-08-26 14:15:22 +00:00
tests §39.8: homemaker-py-2v1 connectivity weighting — MEASURED NULL, premise retracted 2026-08-26 14:15:22 +00:00
.gitignore bd init: initialize beads issue tracking 2026-06-11 23:27:11 +01:00
AGENTS.md §39.7: access requirements become a declared usage: attribute (homemaker-py-sel) 2026-08-26 13:39:41 +00:00
CLAUDE.md §39.7: access requirements become a declared usage: attribute (homemaker-py-sel) 2026-08-26 13:39:41 +00:00
DESIGN.md §39.8: homemaker-py-2v1 connectivity weighting — MEASURED NULL, premise retracted 2026-08-26 14:15:22 +00:00
pyproject.toml homemaker-py-2g7.5: CP-SAT exact room-code assignment (seeder + reassign op) 2026-08-04 09:19:36 +01:00
README.md §39.7: access requirements become a declared usage: attribute (homemaker-py-sel) 2026-08-26 13:39:41 +00:00

homemaker-layout

Programme-driven building-layout search over slicing trees. A clean-room Python successor to the Perl Urb project, intended to eventually be 100% Python.

Why a rewrite

Urb represents a building as a binary slicing tree where room sizes are derived top-down from division ratios. That makes room area an emergent property of every cut above it, which:

  • gives the genome low locality (a cut near the root rescales every descendant),
  • makes target room sizes nearly impossible to hit, so the gaussian size penalty dominates fitness, and
  • defeats crossover (transplanted subtrees lose their proportions).

homemaker inverts this: leaves carry target dimensions from the programme and division ratios are solved bottom-up for a fixed topology. The evolutionary search then only explores topology + types + adjacency.

Phase plan

  1. Solver experiment: port Urb's geometry, re-solve ratios from programme targets, score the result against the original via the Perl oracle.
  2. Native Python fitness (retire the Perl oracle).
  3. Memetic search: canonical slicing genome + high-locality operators + Nelder-Mead inner loop.
  4. Penalty reshaping: lexicographic (-n_fails, fitness) outer-search comparison.
  5. Representation upgrade: canonical slicing encoding + bottom-up shape feasibility, scaled to larger programmes.
  6. Search-quality experiments (current): a long running series of opt-in levers tried against the harbor-house, health-centre, and programme-house example corpora — leaf-sharing, finish-time cell→room collapse, ruin-and-recreate LNS, 2-opt polish, multi-use/co-located leaves, adjacency-graph and bubble-diagram fitness signals, and more. Most of these are negative/null results kept as opt-in flags or reference code rather than defaults. See DESIGN.md §11 onward for the full, numbered experiment log with methodology and results for each.

Layout

  • src/homemaker_layout/dom.py — read/write Urb .dom YAML into a Node tree.
  • src/homemaker_layout/geometry.py — faithful port of Urb's top-down geometry.
  • src/homemaker_layout/programme.py — parse patterns.config space requirements.
  • src/homemaker_layout/solver.py — bottom-up ratio solve (scipy).
  • src/homemaker_layout/fitness.py — native Python fitness evaluator.
  • src/homemaker_layout/fitness_cmd.pyhomemaker-fitness CLI (drop-in for urb-fitness.pl).
  • src/homemaker_layout/collapse_cmd.pyhomemaker-collapse CLI: finish-time global cell→room relabel of a .dom.
  • src/homemaker_layout/graph.py — leaf-adjacency graph for programme-driven checks.
  • src/homemaker_layout/genome.py — topology genome: base-floor tree + per-storey deltas.
  • src/homemaker_layout/operators.py — high-locality mutation and subtree crossover.
  • src/homemaker_layout/innerloop.py — ratio optimisation inner loop (Nelder-Mead / CMA-ES).
  • src/homemaker_layout/driver.py — memetic search outer loop.
  • src/homemaker_layout/evolve.pyhomemaker-evolve CLI entry point.
  • src/homemaker_layout/oracle.py — legacy Perl shim, kept for cross-validation only.
  • src/homemaker_layout/bubble.py — 3D bubble-diagram adjacency fitness-signal prototype (DESIGN.md §27); validated null, not wired into fitness.py — reference only.

Room codes and reserved names

Leaf types live in three namespaces that share a first character. Only the first is enforced; the other two are conventions the fitness function reads, so a room's spelling can change how it is scored.

1. Generic structural types — C, O, S (reserved). The leaves the search itself creates: C circulation, O outside, S sahn (an outside court that also serves as circulation). Always uppercase. A programme code spelled exactly C, O or S is rejected at load.

2. Programme room codes — anything else, lowercase. k1, b1, cr1, of, and single-character codes like r or t. These may start with any letter: since DESIGN.md §39.4 the generic tests match C/O/S exactly, so naming a room cr1 no longer makes it circulation. (Before that fix it did — and silently dropped it from the required-space check entirely.)

3. Access requirements — the usage: attribute. Every space declares one of living, kitchen, bedroom, toilet, utility, none. Mandatory, no fallback, and a missing or unknown value is a load error. It replaced a first-character convention (b/t/l/k) under which a room silently inherited another room's connectivity rules from its spelling — la1 "Laundry Room" was trimmed as a living room (DESIGN.md §39.7).

spaces:
  la1:
    usage: utility          # controlled, drives engine behaviour
    name: Laundry Room      # free text, building-specific

A usage value exists only where the engine treats it differently, so the vocabulary is closed: a new access class means new code, not new config. Check a programme with:

python experiments/audit_programme_config.py

which reports reserved-name collisions, the usage class each code picks up, and whether each room's size/width/proportion/crinkliness targets are mutually satisfiable at all.