Python rewrite of the Urb/Homemaker stack
Find a file
Claude 6405ca1a59
ssz: record the A/B result honestly -- not a pass at n=3
Fixed-budget A/B (3000 evals, 3 seeds, harbor + maple, every arm scored
under stock urb so the permissive modes cannot win by deleting a fail
category).

usage_daylight's paired hard-fail deltas are harbor [0,-1,-10] and maple
[0,+2,-10]. The means (-3.7, -2.7) flatter it: the whole signal is seed 2
in both programmes, and seed 2 is the seed where stock itself does worst.
Two seeds in three are flat or slightly worse. On that seed soft rises as
much as hard falls (harbor -10h/+9s, maple -10h/+15s), so totals go
62->61 on harbor and 120->125 on maple.

Because the scoring is stock, that is a genuine trade of hard failures for
soft ones, not a relabelling -- progress under the tiered comparator, where
n_hard is primary, but a fail against this issue's acceptance criterion
("without inflating soft"). Which yardstick is right is now the live
question, and it is gvb's question as much as ssz's.

usage_daylight stays default off; undecided, not refuted. Higher-power run
(urb vs usage_daylight, 10 seeds) is running.

The diagnostic half stands independent of the search A/B: the objective
demands daylight of two thirds of the buried population that does not want
it, and 38.6's contrary null was an artefact of three modes that never
touched those leaves.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MJ84Feep79Hhm3E4zZJmnB
2026-08-26 17:57:11 +00:00
.beads Frontage feasibility as a pre-flight check; retract the "3x short" claim 2026-08-26 16:20:52 +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 ssz: record the A/B result honestly -- not a pass at n=3 2026-08-26 17:57:11 +00:00
src/homemaker_layout ssz: use the module-level programme import in needs_daylight 2026-08-26 16:46:59 +00:00
tests ssz: daylight is required of rooms that do not need it 2026-08-26 16:45:10 +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 ssz: record the A/B result honestly -- not a pass at n=3 2026-08-26 17:57:11 +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.