Python rewrite of the Urb/Homemaker stack
Find a file
Claude 72673a2ebf
homemaker-py-sel: usage is a plain space attribute — drop the mapping table
The proposed top-level `usage_classes:` table (binding author-coined names to
engine behaviour, e.g. craft -> living) is withdrawn. Wrong three ways:

a) Same bug in another costume. An indirect name -> behaviour mapping living
   apart from the thing it describes is exactly the shape of the
   first-character prefix rule. §39 exists to remove that shape, not relocate
   it into a table.

b) Inconsistent with the schema. Every other space property is a plain
   attribute -- name, size, width, proportion, adjacency, level,
   requires_below, count, share, interchange, co_locate -- and no key anywhere
   in patterns.config is an indirection table. Verified across the corpus.

c) The need was already met. "Programmes are building specific" is about what a
   room is CALLED, and name: is already free text. usage: records ACCESS
   REQUIREMENTS, which are not building-specific -- a craft room and a lounge
   have the same ones, which is the entire reason the key exists. The earlier
   draft conflated the two.

So: spaces: ws1: {name: Workshop Space, usage: living} -- one place, no
binding step, no unbound-name error class.

Rule that falls out and is worth keeping: A USAGE VALUE EXISTS IF AND ONLY IF
THE ENGINE TREATS IT DIFFERENTLY SOMEWHERE. Config selects among behaviours; it
cannot invent them. An alias produces no behaviour that the aliased value does
not. `utility` passes the test -- not on edge-stripping, which is identical to
bedroom today, but because it is intended to drive derive_interchange_classes.

No src changes; proposal file only.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MJ84Feep79Hhm3E4zZJmnB
2026-08-26 12:56:12 +00:00
.beads homemaker-py-sel: usage is a plain space attribute — drop the mapping table 2026-08-26 12:56:12 +00:00
.claude Scaffold homemaker-py with validated geometry port 2026-06-10 20:50:20 +01:00
examples §39.4: tighten generic-type matching, reverting the harbor rename 2026-08-26 09:45:28 +00:00
experiments homemaker-py-sel: usage is a plain space attribute — drop the mapping table 2026-08-26 12:56:12 +00:00
src/homemaker_layout §39.4 completion + §39.5 retraction + §39.6: the usage namespace is NOT clean 2026-08-26 10:09:14 +00:00
tests §39.4 completion + §39.5 retraction + §39.6: the usage namespace is NOT clean 2026-08-26 10:09:14 +00:00
.gitignore bd init: initialize beads issue tracking 2026-06-11 23:27:11 +01:00
AGENTS.md §39.4 completion + §39.5 retraction + §39.6: the usage namespace is NOT clean 2026-08-26 10:09:14 +00:00
CLAUDE.md §39.4 completion + §39.5 retraction + §39.6: the usage namespace is NOT clean 2026-08-26 10:09:14 +00:00
DESIGN.md §39.4 completion + §39.5 retraction + §39.6: the usage namespace is NOT clean 2026-08-26 10:09:14 +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.4 completion + §39.5 retraction + §39.6: the usage namespace is NOT clean 2026-08-26 10:09:14 +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. Usage prefixes — b bedroom, t toilet, l living, k kitchen. Still matched by first letter, deliberately: this is how Urb encodes room usage. graph.has_circulation deletes graph edges based on them (a "bedroom" loses its edges to living/kitchen/bedroom/toilet; a "toilet" loses its edges to outside/living/kitchen/toilet), and the access and public-access checks read them too.

So a code beginning with b/t/l/k inherits that room's connectivity rules whether or not you meant itla1 "Laundry Room" is treated as a living room, tr1 "Treatment Room" as a toilet. This is a known wart (homemaker-py-sel, DESIGN.md §39.6); an explicit usage: key is the planned fix. Until then, check any new 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.