bruno/homemaker-layout
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

CP-SAT seeding re-measured deterministically: it loses

Browse source 
39.5 concluded the exact CP-SAT seeder beats greedy (harbor 102 -> 92,
maple 156 -> 154). Re-checked because fdp made the arms deterministic and
3qj made the model 7.5x slower. Three findings.

A live bug in the cap, found on the way. solve_room_labels sets a
deterministic work-unit budget (4.0) and a wall-clock backstop, commented
as "a pathological-case backstop only". At 2.0s it had become THE BINDING
CONSTRAINT: 2 of 24 harbor solves returned FEASIBLE not OPTIMAL, wall time
hit exactly 2010 ms, and the deterministic budget was never reached (max
2.483/4.0). Those labellings were suboptimal AND load-dependent -- the wall
clock is exactly the cap 39.5 added the deterministic one to escape. Cause:
38.14's t -> n adjacency makes the model much harder, and the 2s value
dated from when solves took ~124 ms. Raised to 30s; 24/24 harbor and 36/36
maple now OPTIMAL, deterministic budget still in headroom (3.569/4.0).

The verdict reverses. Deterministic, 12 seeds, scored canonically:
  harbor  greedy 1323 (722h)  0.079 s/seed    cpsat 1548 (908h)  1.623
  maple   greedy 1764 (777h)  0.063 s/seed    cpsat 2256 (1213h) 1.327
cpsat loses on both, +225 and +492 fails at ~21x the seeding time,
concentrated in hard fails.

Time and quality have different causes. Removing t -> n from harbor takes
cpsat 1.623 -> 0.193 s/seed (8.4x faster) but it is still +205 vs greedy
(was +225) -- so the adjacency explains the time blow-up and ~9% of the
quality gap; the regression is otherwise pre-existing.

Squaring with 39.5: that section records cpsat returning 194/180/171/182
over four identical 10-seed aggregates before the determinism work. Its
10-fail harbor margin sits well inside a noise band that wide, and was
measured with fdp's id()-ordered room_slots live. The seeder-level claim
was never established rather than overturned. 39.5 annotated in place.

Absolute totals are ~6x 39.5's because the objective has changed, so they
are not comparable to that table; the within-measurement comparison is
like-for-like and is what the verdict rests on.

No default changes: assign_solver was already greedy for 37.7's independent
reason. What changes is that "cpsat wins the seeder A/B" should no longer
be cited as a reason to pursue it.

The cap fix takes the suite from ~4.5 to ~10 min and the tests cannot opt
out, since constructive_topology does not thread the solver limits through.
Filed as homemaker-py-2xk.

Closes homemaker-py-vjd.

Lint at parity (46); tests 384 passed, 0 failed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MJ84Feep79Hhm3E4zZJmnB
This commit is contained in:
Claude 2026-08-29 14:47:36 +00:00
parent e9e7060fb4
commit 03c1c5edcf
No known key found for this signature in database
3 changed files with 93 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

3
.beads/issues.jsonl
View file

@ -37,7 +37,7 @@
{"_type":"issue","id":"homemaker-py-8cs","title":"Experiment: warm-vs-cold start of inner loop (Lamarckian inheritance)","description":"DESIGN.md §5.6, §4.6. Warm-starting a child topology's inner loop from the parent's optimised ratios is the main lever for cutting per-topology cost (~3 min/topology cold). Apply single topology mutations to optimised corpus designs, re-optimise warm (surviving cuts keep values, new cuts get heuristic defaults) vs cold, compare oracle-call counts to convergence at equal final fitness.","acceptance_criteria":"Speedup factor measured across \u003e=10 mutated topologies; decision recorded (expect order-of-magnitude; if \u003c2x, revisit §4.6 Phase-2 scoping)","notes":"Experiment script committed (experiments/warm_vs_cold.py, 1cc86c8) and machinery validated oracle-free; one mutated child scored through the oracle OK. Waiting on homemaker-py-gp2 reference run to finish, then execute under URB_NO_OCCLUSION=1 (3 parents x 400 evals + 12 children x 2 x 200 evals, ~1.5-2 h oracle time). Default budgets: parent 400, child 200; target = evals to 95% of best final.","status":"closed","priority":1,"issue_type":"task","owner":"bruno@postle.net","created_at":"2026-06-11T23:36:58Z","created_by":"Bruno Postle","updated_at":"2026-06-12T11:44:45Z","closed_at":"2026-06-12T11:44:45Z","close_reason":"Measured (URB_NO_OCCLUSION=1, parent budget 400, child 200, 12 single mutations across 3 designs): cold start reached 95% of warm final in 0/12 cases within budget — speedup unbounded at practical budgets; warm finals beat cold finals x1.2-x4 in 12/12; 6/12 warm starts were within 95% at 1 eval (near-neutral mutations). Decision: Lamarckian warm-starting is MANDATORY in the memetic driver (homemaker-py-b39), not an optimisation; cold starts produce strictly worse geometry at equal budget. Note: 2 undivides were exactly fitness-neutral (same-type merge == Merge_Divided equivalence) — locality datum for homemaker-py-nyb.","dependencies":[{"issue_id":"homemaker-py-8cs","depends_on_id":"homemaker-py-1p0","type":"blocks","created_at":"2026-06-12T00:39:34Z","created_by":"Bruno Postle","metadata":"{}"}],"dependency_count":1,"dependent_count":0,"comment_count":0}
{"_type":"issue","id":"homemaker-py-av5","title":"Batched oracle: score many .dom files per invocation","description":"oracle.py currently scores one .dom per urb-fitness.pl call (~1.65 s/dom). DESIGN.md §4.6: batching amortises Perl startup to ~0.99 s/dom and is required so population/batch optimisers can score a whole generation in one oracle call. Extend oracle.py with a batch API: write N .dom files, one perl invocation, parse N .score/.fails pairs. Keep the single-file path for compatibility.","acceptance_criteria":"Batch of 35 corpus files scores in one perl invocation; per-file results identical to single-file calls; measured s/dom reported","status":"closed","priority":1,"issue_type":"task","assignee":"Bruno Postle","owner":"bruno@postle.net","created_at":"2026-06-11T23:36:56Z","created_by":"Bruno Postle","updated_at":"2026-06-12T00:14:06Z","started_at":"2026-06-11T23:50:40Z","closed_at":"2026-06-12T00:14:06Z","close_reason":"score_batch() lands in oracle.py; 35-file corpus parity verified single-vs-batch (1e-12 rel fitness, exact fail sets); 0.98 s/dom batched vs 1.27 single, x1.30","dependency_count":0,"dependent_count":1,"comment_count":0}
{"_type":"issue","id":"homemaker-py-ioe","title":"Is collapse_insearch=True still the right default under the current objective?","description":"The default was flipped OFF -\u003e ON by homemaker-py-1ph (DESIGN.md §20, 2026-07-24) on the strength of a programme-house N=20 sweep: mean 7.95 -\u003e 7.10, 11W/6L/3T, paired t p ~= 0.028. homemaker-py-d86 (§38.18) has now confirmed that verdict was sound FOR ITS OWN ERA -- it reproduces on a pre-iio commit, and the iio stale-share bug is structurally unreachable on that protocol because programme-house declares count: 1 for every code, so no leaf ever carries a share.\n\nBut the objective has changed substantially since, three times over, and all of it after 1ph:\n\n §39.4 the generic-namespace fix -- codes like cr1 were being read as generic\n circulation, so 14% of harbor's programme was silently optional\n §38.10 / §38.11 crinkliness declared per space; 14 corpus spaces now declare\n crinkliness: none\n §38.12 the missing-space cascade no longer weighted by YAML verbosity, a fixed\n 5 fails per missing instance instead of 3-5\n\ncollapse_insearch runs collapse_global inside every fitness eval, and collapse_global's assignment is valued against exactly the quality factors those changes touched. So the ON-beats-OFF margin was measured against an objective that no longer exists. The direction is plausibly unchanged -- but it is currently an assumption carried on a superseded measurement, and it is a DEFAULT, so every run inherits it.\n\nThe protocol and harness already exist: experiments/rerun_1ph_protocol.sh runs programme-house, budget 3000, 4 workers, seeds 1-20, ON vs OFF, both arms finished with --collapse, and takes about 6 minutes.\n\nNote when re-running: n_workers is an algorithm parameter (§38.17), so keep 4 workers to stay comparable with the published protocol, and record it with the result.","acceptance_criteria":"The 1ph protocol re-run at N=20 on the current codebase and objective, with the ON-vs-OFF verdict either reconfirmed or restated; if the margin has moved materially, DESIGN.md §20's default-flip rationale is updated to say so and the default is reconsidered on the new numbers.","status":"closed","priority":2,"issue_type":"task","assignee":"Claude","owner":"noreply@anthropic.com","created_at":"2026-08-29T13:36:18Z","created_by":"Claude","updated_at":"2026-08-29T13:57:45Z","started_at":"2026-08-29T13:36:32Z","closed_at":"2026-08-29T13:57:45Z","close_reason":"Re-validated: the default STANDS, but with two caveats worth carrying\n(DESIGN.md §38.19).\n\nRe-ran the 1ph protocol as published on the current codebase and objective --\nprogramme-house, budget 3000, 4 workers, ON vs OFF, both arms finished with\n--collapse.\n\n N OFF ON W/L/T diff t p\n published 1ph (07-24) 20 7.95 7.10 11/6/3 +0.85 2.38 0.028\n historical re-run (§38.18) 20 8.05 7.10 11/6/3 +0.95 2.59 --\n current objective 20 7.85 7.15 10/7/3 +0.70 1.82 0.069\n current objective 40 7.60 7.03 21/14/5 +0.57 2.01 0.045\n current objective 60 7.58 7.02 29/19/12 +0.57 2.45 0.017\n\nAt N=60: mean diff +0.567 fails/seed, paired t=2.454 (df=59), p=0.0171 exact,\n95% CI [+0.105, +1.029] excluding zero. Wilcoxon signed-rank cross-check agrees\n(p=0.0138), which matters because fail counts are small integers and normality\nis not obvious.\n\nCaveat 1: the effect is about a third smaller than published (+0.57 vs +0.85).\nPartly regression from a slightly lucky N=20 draw, partly plausible real erosion\n-- several fails collapse_global used to clear have been redefined out of\nexistence or made harder by §39.4 / §38.10-12.\n\nCaveat 2, the more useful one: THE PUBLISHED N=20 CAN NO LONGER DETECT ITS OWN\nEFFECT. At exactly the published sample size the current answer is p ~= 0.069, a\nnull by the conventional threshold. Had I run N=20 and stopped, the honest report\nwould have been \"the 1ph verdict no longer reproduces\" and the default would have\nlooked unjustified. It took N=60 to resolve. That is the \"8sh/1ph/qi6/lj3\npattern\" this log already warns about, now biting the flagship result itself.\nAny future re-validation of this default needs N \u003e= 40; N=20 should not be\ntrusted to settle it either way.\n\n§20 annotated in place so a reader of the original claim sees the current figure.\nHarness now takes a seed range (APPEND=1 to extend a sweep); results in\nexperiments/results/ioe_1ph_current_objective.tsv.\n","dependency_count":0,"dependent_count":0,"comment_count":0}
{"_type":"issue","id":"homemaker-py-vjd","title":"cpsat assignment ~7.5x slower after the 3qj adjacency: re-check §39.5's cpsat-vs-greedy verdict","description":"Declaring harbor's t -\u003e n adjacency (homemaker-py-3qj, DESIGN.md §38.14) made the CP-SAT room-labelling model markedly harder. constructive_topology seeding, 3-seed average:\\n\\n harbor greedy 0.06s -\u003e 0.06s (unchanged) cpsat 0.28s -\u003e 2.11s (7.5x)\\n maple greedy 0.03s -\u003e 0.03s (unchanged) cpsat 0.47s -\u003e 1.37s (2.9x)\\n\\nassign_solver defaults to greedy so ordinary runs pay nothing, and mutate_reassign/enable_reassign are opt-in too. But §39.5 concluded cpsat beats greedy on both programmes, and that was measured on a cheaper problem than the corpus now poses. The verdict needs re-checking on quality-per-second, not just quality.\\n\\nAlso worth checking whether cpsat.max_deterministic_time is now being hit, which would mean it is returning early rather than solving -- that would change the quality side of the comparison too, silently.","acceptance_criteria":"cpsat vs greedy re-measured on the current corpus for both solution quality AND wall time; §39.5's verdict either reconfirmed or restated; if max_deterministic_time is being hit, that is recorded and the limit reconsidered.","status":"open","priority":2,"issue_type":"task","owner":"noreply@anthropic.com","created_at":"2026-08-29T10:57:26Z","created_by":"Claude","updated_at":"2026-08-29T10:57:26Z","dependency_count":0,"dependent_count":0,"comment_count":0}
{"_type":"issue","id":"homemaker-py-vjd","title":"cpsat assignment ~7.5x slower after the 3qj adjacency: re-check §39.5's cpsat-vs-greedy verdict","description":"Declaring harbor's t -\u003e n adjacency (homemaker-py-3qj, DESIGN.md §38.14) made the CP-SAT room-labelling model markedly harder. constructive_topology seeding, 3-seed average:\\n\\n harbor greedy 0.06s -\u003e 0.06s (unchanged) cpsat 0.28s -\u003e 2.11s (7.5x)\\n maple greedy 0.03s -\u003e 0.03s (unchanged) cpsat 0.47s -\u003e 1.37s (2.9x)\\n\\nassign_solver defaults to greedy so ordinary runs pay nothing, and mutate_reassign/enable_reassign are opt-in too. But §39.5 concluded cpsat beats greedy on both programmes, and that was measured on a cheaper problem than the corpus now poses. The verdict needs re-checking on quality-per-second, not just quality.\\n\\nAlso worth checking whether cpsat.max_deterministic_time is now being hit, which would mean it is returning early rather than solving -- that would change the quality side of the comparison too, silently.","acceptance_criteria":"cpsat vs greedy re-measured on the current corpus for both solution quality AND wall time; §39.5's verdict either reconfirmed or restated; if max_deterministic_time is being hit, that is recorded and the limit reconsidered.","status":"closed","priority":2,"issue_type":"task","assignee":"Claude","owner":"noreply@anthropic.com","created_at":"2026-08-29T10:57:26Z","created_by":"Claude","updated_at":"2026-08-29T14:47:36Z","started_at":"2026-08-29T14:20:49Z","closed_at":"2026-08-29T14:47:36Z","close_reason":"Re-measured. Three findings (DESIGN.md §38.20).\n\n1. A LIVE BUG IN THE CAP, found on the way. solve_room_labels sets a\ndeterministic work-unit budget (max_deterministic_time=4.0) and a wall-clock\nbackstop, with the comment that the wall clock is \"a pathological-case backstop\nonly\". At its 2.0s value it had become THE BINDING CONSTRAINT: on harbor, 2 of\n24 solves returned FEASIBLE not OPTIMAL, wall time hit exactly 2010 ms, and the\ndeterministic budget was never reached (max 2.483 of 4.0). Those labellings were\nboth suboptimal AND load-dependent -- the wall clock is precisely the cap §39.5\nadded the deterministic one to escape. Cause: §38.14's `t -\u003e n` adjacency makes\nthe model much harder, and the 2s value dated from when solves took ~124 ms.\nRaised to 30s; now 24/24 harbor and 36/36 maple solves are OPTIMAL with the\ndeterministic budget still in headroom (max 3.569/4.0).\n\n2. THE VERDICT REVERSES. Re-measured deterministically (fdp's id()-ordering fix\nmeans the arms no longer differ by memory layout), 12 constructed seeds, scored\ncanonically:\n\n harbor greedy 722h/601s = 1323 0.079 s/seed\n harbor cpsat 908h/640s = 1548 1.623 s/seed\n maple greedy 777h/987s = 1764 0.063 s/seed\n maple cpsat 1213h/1043s= 2256 1.327 s/seed\n\ncpsat LOSES on both, +225 and +492 fails, at ~21x the seeding time, concentrated\nin hard fails.\n\n3. TIME AND QUALITY HAVE DIFFERENT CAUSES. Removing §38.14's `t -\u003e n` from\nharbor: cpsat goes 1.623 -\u003e 0.193 s/seed (8.4x faster) but still +205 vs greedy\n(was +225). So the adjacency explains the time blow-up and ~9% of the quality\ngap; the regression is otherwise pre-existing.\n\nSquaring with §39.5: that section records cpsat returning 194/180/171/182 over\nfour identical 10-seed aggregates before the determinism work. Its 10-fail\nharbor margin (102 vs 92) sits well inside a noise band that wide, and was\nmeasured with fdp's id()-ordered room_slots still live. So the seeder-level\n\"cpsat wins\" claim was never established rather than being overturned. §39.5\nannotated in place.\n\nCaveat stated in the write-up: absolute totals are ~6x §39.5's because the\nobjective has changed (§39.4, §38.10-12), so they are not directly comparable to\nthat table. The greedy-vs-cpsat comparison within this measurement is\nlike-for-like and is what the verdict rests on.\n\nNo default changes -- assign_solver was already greedy for §37.7's independent\nreason, and this reinforces it. What changes is that \"cpsat wins the seeder A/B\"\nshould no longer be cited as a reason to pursue it.\n\nCost recorded and filed as homemaker-py-2xk: the cap fix takes the test suite\nfrom ~4.5 to ~10 min, and the tests cannot opt out because constructive_topology\ndoes not thread the solver limits through.\n","dependency_count":0,"dependent_count":0,"comment_count":0}
{"_type":"issue","id":"homemaker-py-9gj","title":"quality_uncrinkliness returns a flat hard 0.0, so the objective cannot rank two equally-buried layouts","description":"Narrowed remnant of homemaker-py-ssz after the owner's daylight ruling (DESIGN.md §38.11). A buried leaf usually IS a defect -- corridors and WCs included -- so scoring it badly is correct. The residual complaint is not that the value is low, it is that it is FLAT: quality_uncrinkliness returns exactly 0.0 for every zero-exposure leaf, and since evaluate_leaf multiplies factors into quality and process_storey accumulates value += quality * rate * area, two layouts that differ only in how badly buried their rooms are score identically.\n\nSo the objective gives the search no gradient to descend in precisely the region it most needs to escape. This is a search-mechanics problem, not a calibration one, and it should be judged on whether it helps the search escape -- NOT on fail counts, which by construction it will not move (the fails are real and should stay).\n\nNote the trap recorded in §38.9: an arm optimised under a modified objective must not be scored under the objective it modifies, and equally must not be scored under its own. For a pure gradient change that emits the same fail set, stock scoring IS valid -- that is the one case where the yardstick is sound.","acceptance_criteria":"A variant that keeps the fail set byte-identical to stock (every currently-failing leaf still fails) but is monotone in how buried a leaf is; A/B at fixed budget on harbor + maple with enough seeds to see past the one-seed variance that made the §38.8 n=3 result undecidable.","status":"open","priority":2,"issue_type":"bug","owner":"noreply@anthropic.com","created_at":"2026-08-28T23:14:04Z","created_by":"Claude","updated_at":"2026-08-28T23:14:04Z","dependency_count":0,"dependent_count":0,"comment_count":0}
{"_type":"issue","id":"homemaker-py-7b7","title":"health-centre demands 131% of its plot: the programme is unsatisfiable as written","description":"`evolve._preflight` (homemaker-py-tdp, DESIGN.md 39.11) reports health-centre demanding 240 m2 of floor per storey on a 183 m2 plot -- 131%. It is 1 storey (n_storeys_required=1, storey_minimum=1), so there is nowhere for the overflow to go.\n\nThe consequence is visible in every evaluated layout: 100% of rooms come out undersized, uniformly, at a median 0.60x their declared target. No search can fix this -- quality_size is being asked for something the plot cannot supply, so the size gaussian is pinned near-zero across the whole design and contributes no useful gradient. Contrast harbor-house and maple-court, where the seeder hits targets at median 1.01x.\n\nThis is a corpus data problem, not an engine problem. Either the plot is too small or the programme's sizes/counts were estimated too generously (the CLAUDE.md note that all corpus targets were 'estimated many years ago and never changed' applies).\n\nOptions, roughly in order of honesty:\n 1. enlarge the plot in examples/health-centre/init.dom to ~1.4x\n 2. scale down size/count in patterns.config until demand fits with headroom\n 3. raise the storey count so the demand spreads over 2 levels\n 4. leave it and treat health-centre as a deliberate over-tight brief, documented as such\n\nWhichever is chosen, note it in DESIGN.md 39.11 so the pre-flight warning is not read as a bug in the check.","acceptance_criteria":"health-centre's demanded area per storey fits its plot with headroom, OR the programme is explicitly documented as a deliberately over-tight brief; `evolve._preflight` no longer reports it as an unexplained anomaly; median room area / (target * share) on a constructed seed is materially above 0.60x.","status":"closed","priority":2,"issue_type":"bug","owner":"noreply@anthropic.com","created_at":"2026-08-26T16:20:31Z","created_by":"Claude","updated_at":"2026-08-29T10:20:00Z","closed_at":"2026-08-29T10:20:00Z","close_reason":"Fixed per the owner's ruling: enlarge the plot, sized assuming a courtyard\n(DESIGN.md §38.13).\n\nThe plot is a quadrilateral in this engine, so the courtyard is interior space\nthe search carves out, not a hole in the site. Sizing therefore has to allow for\nthree things, only one of which the programme declares: rooms 240 m2, circulation\n~65 m2 (~27%, NOT in demand -- the search creates C leaves), courtyard ~36 m2.\n\nScaled about the polygon centroid by k = 1.4606, chosen so the INSET area (what\nleaves actually get, after wall_outer) lands on 400 m2. Centroid scaling keeps\nthe site's irregular shape and its one private edge -- same site, larger.\n\n plot 183.2 -\u003e 400.0 m2\n rooms / plot 131% -\u003e 60% (harbor's ratio exactly, and harbor works)\n daylit perim 41.5 -\u003e 61.3 m (49.4 needed)\n median room area / (target x share) 0.60x -\u003e 1.00x\n\nThat last figure is the one that matters: 0.60x with 100% of rooms undersized\nwas the geometric signature of the infeasibility, and it is now level with\nharbor/maple at 1.01x.\n\nThe courtyard remains REQUIRED by the geometry rather than merely permitted: a\nroom is at most 1.6202*h = 4.86 m deep before failing crinkliness, so a ~20x20 m\nplot with a daylit ring leaves a 10.3 x 10.3 m, 106 m2 core that cannot reach an\nexternal wall. Enlarging did not remove the pressure that produces a courtyard,\nit made room for one.\n\nevolve._preflight is now silent on health-centre. Unblocks homemaker-py-7xb.\n","dependency_count":0,"dependent_count":1,"comment_count":0}
{"_type":"issue","id":"homemaker-py-3qj","title":"Programmes do not declare bedroom/treatment-room to toilet adjacency, so the Brand adaptability credit is never earned","description":"Established while settling homemaker-py-sel. A toilet adjacent to a sleeping or treatment room is a positive even with no door between them -- Stewart Brand, How Buildings Learn: the building may need it knocked through later, and the adjacency is what makes that possible.\\n\\nThe engine already supports this. fitness._evaluate_full runs graph.check_adjacency against graph_base_pre, the UNFILTERED adjacency graph, so a declared adjacency requirement is satisfied by a neighbouring room regardless of the edges graph.has_circulation later strips for routing. (The stripping is correct on its own terms -- you cannot walk through a bedroom to reach the loo.)\\n\\nBut it is only ever scored where a programme DECLARES it, and only one corpus programme does:\\n programme-house (+ derivatives) t1 -\u003e adjacency: [b1] DECLARED\\n harbor-house t (Bathroom, count 6) vs r / n (sleeping) not declared\\n maple-court t, tt vs r / n not declared\\n health-centre t9 / t10 vs tr1 (Treatment Room) not declared\\n\\nSo three of the four real programmes leave the adaptability credit on the table: the search has no reason to place a WC next to a dormitory or a treatment room, because nothing scores it.\\n\\nThis is programme authoring, not an engine change, and it is independent of the usage-key work -- it can land before or after.","acceptance_criteria":"harbor-house, maple-court and health-centre declare the sleeping/treatment-to-toilet adjacencies their briefs imply; re-baselined so the change in fail counts is attributed rather than absorbed.","status":"closed","priority":2,"issue_type":"task","owner":"noreply@anthropic.com","created_at":"2026-08-26T12:33:39Z","created_by":"Claude","updated_at":"2026-08-29T10:57:25Z","closed_at":"2026-08-29T10:57:25Z","close_reason":"Declared where the brief supports it (DESIGN.md §38.14).\n\n harbor-house t -\u003e n Bathrooms serve the Neighborhoods (communal sleeping).\n Both unpinned, 6 t / 5 n.\n maple-court tt -\u003e r Upper Bathrooms among Individual Rooms, both level 2,\n already 62% adjacent at seed time.\n\nNOT declared, and checking before declaring is what caught these:\n\n maple t -\u003e n is IMPOSSIBLE. Adjacency is evaluated per level (graph_base[li]),\n and maple pins t to level 0, n to level 1. Declaring it would have added six\n permanently unsatisfiable fails. The 0% seed-time rate I measured was a hard\n impossibility, not search difficulty. maple's ground floor has six bathrooms\n and exactly one sleeping room (Clinic Room x1) -- a ground-floor WC in a\n communal building is public, so Brand does not apply to it anyway.\n\n health-centre has no dedicated WC. The owner's ruling on treatment rooms was\n that one \"may give access to a toilet, but this would be a DEDICATED toilet\".\n t9 is a Public WC (x2), t10 a Staff WC; making either dedicated-adjacent to\n tr1 contradicts that. Earning the credit here needs a dedicated WC added to\n the brief -- programme authoring beyond this issue. Filed separately.\n\nBoth declarations are reachable (best of 8 seeds: 2/3 harbor, 2/2 maple), so the\nsearch gets a gradient not a permanent penalty. evolved-3M-nols-3: 84 -\u003e 89\nfails, all five the new requirement.\n\nCost: cpsat assignment got ~7.5x slower on harbor (0.28 -\u003e 2.11s per seed);\ngreedy, the default, is unchanged at 0.06s. Filed as a follow-up since it bears\non §39.5's cpsat-vs-greedy verdict.\n\nTwo tests were over-fitted to the old seeds and were repaired to assert their\nintent rather than relaxed: reassign now sweeps six constructive seeds (seed 0's\nbetter-seeded design legitimately has nothing to improve; 5 of 6 others fire),\nand repair_circulation asserts that repair strictly helps plus a \u003e=85% bar\ninstead of a sampled 100% (measured 25% -\u003e 92%, stable over 6 and 12 seeds).\n","dependency_count":0,"dependent_count":0,"comment_count":0}
@ -97,6 +97,7 @@
{"_type":"issue","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}
{"_type":"issue","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}
{"_type":"issue","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}
{"_type":"issue","id":"homemaker-py-7t1","title":"cpsat solver limits are not threadable from constructive_topology, so tests pay full solve cost","description":"homemaker-py-vjd raised solve_room_labels' wall-clock backstop from 2.0s to 30.0s so the deterministic budget governs (it had silently become the binding, load-dependent cap -- 2 of 24 harbor solves returned FEASIBLE not OPTIMAL). Correct, but the full test suite went from ~4.5 min to ~10 min: the three assign_cpsat tests now dominate it, because the solves that used to be truncated at 2s run to optimality.\\n\\nThe tests cannot opt out. operators.constructive_topology takes assign_solver but does not thread time_limit_s / deterministic_limit through to cpsat.solve_room_labels, so there is no way to ask for a cheaper solve in a test.\\n\\nThread the two limits through constructive_topology (and _assign_adjacency_aware) as optional parameters defaulting to the current values, then have the assign_cpsat tests pass a smaller deterministic_limit. The DEFAULT must not change -- the point is that production solves run to optimality deterministically; only the tests should economise.","acceptance_criteria":"constructive_topology accepts and forwards the solver limits; the assign_cpsat tests use a reduced deterministic_limit and the suite returns to roughly its previous runtime; default limits unchanged and all solves still OPTIMAL in the vjd measurement.","status":"open","priority":3,"issue_type":"task","owner":"noreply@anthropic.com","created_at":"2026-08-29T14:47:36Z","created_by":"Claude","updated_at":"2026-08-29T14:47:36Z","dependency_count":0,"dependent_count":0,"comment_count":0}
{"_type":"issue","id":"homemaker-py-5nw","title":"health-centre has no dedicated WC for the treatment room, so the Brand credit cannot be declared","description":"Split out of homemaker-py-3qj (DESIGN.md §38.14). The owner ruled that a treatment room 'may give access to a toilet, but this would be a dedicated toilet'. health-centre offers only t9 Public WC (count 2) and t10 Staff WC; declaring either adjacent to tr1 would make a public or staff WC dedicated to the treatment room, contradicting the ruling.\\n\\nEarning the adaptability credit here means ADDING a dedicated WC to the brief -- a new space with its own size/usage/adjacency -- which is programme authoring, not a config tweak, and wants the owner's decision on whether the building should have one.\\n\\nRelated: maple-court's level 1 carries four Neighborhoods and no toilet on that level at all, which may be a genuine gap in that brief too.","acceptance_criteria":"Either a dedicated WC is added to health-centre's programme and declared adjacent to tr1, or it is recorded as a deliberate omission; same question answered for maple-court's level 1.","status":"open","priority":3,"issue_type":"task","owner":"noreply@anthropic.com","created_at":"2026-08-29T10:57:27Z","created_by":"Claude","updated_at":"2026-08-29T10:57:27Z","dependency_count":0,"dependent_count":0,"comment_count":0}
{"_type":"issue","id":"homemaker-py-3i3","title":"Is a missing required room correctly weighted at 1/32 of fitness?","description":"Split out of homemaker-py-1i8 (DESIGN.md §38.12), which deliberately fixed only the verbosity dependence and left the magnitude untouched.\n\nA missing required room now costs a fixed 5 fails, so under value *= 0.5 ** len(failures) it is a 1/32 penalty -- 32x the weight of a single crinkliness or proportion fail. Nobody has ever checked that ratio against intent. It may well be right (a missing room is a brief not met, arguably the most serious defect available), but it is currently an accident of how the cascade was built rather than a decision.\n\nThe question is what the objective should SAY, so it wants an owner ruling first and a measurement second: does the cascade's weight crowd out geometry-quality signal in the region where the search actually operates? Note most corpus layouts carry several missing instances at once, so the compounding is steep -- three missing rooms is 1/32768.","acceptance_criteria":"A recorded decision on the intended weight of a missing required room relative to a quality fail, with the cascade's fixed count set to match it; if the answer is 'as-is', that is recorded as a decision rather than left as an accident.","status":"open","priority":3,"issue_type":"task","owner":"noreply@anthropic.com","created_at":"2026-08-29T09:33:24Z","created_by":"Claude","updated_at":"2026-08-29T09:33:24Z","dependency_count":0,"dependent_count":0,"comment_count":0}
{"_type":"issue","id":"homemaker-py-1ue","title":"test_classify_fail_tier_covers_full_corpus passes only on a machine that has already run the scorer","description":"The test globs examples/**/*.fails and asserts checked \u003e 0, but .fails files are generated artefacts written by homemaker-fitness next to the .dom being scored. A clean checkout has none, so the test fails with 'assert 0 \u003e 0' -- it is asserting on the state of the developer's working tree, not on the code.\n\nSplit the two things it is doing: (1) that classify_fail_tier accepts every fail string the evaluator can emit, which should run against fail strings generated in-test from corpus .dom files (or a checked-in fixture list), and (2) the corpus-artefact sweep, which if it is worth keeping should skip rather than fail when no .fails exist.","acceptance_criteria":"The test passes in a fresh clone with no .fails present, and still fails if classify_fail_tier is given an unclassifiable fail string.","status":"closed","priority":3,"issue_type":"bug","owner":"noreply@anthropic.com","created_at":"2026-08-28T22:41:25Z","created_by":"Claude","updated_at":"2026-08-29T07:11:24Z","closed_at":"2026-08-29T07:11:24Z","close_reason":"Fixed. The test globbed examples/**/*.fails and asserted checked \u003e 0, but git\ntracks ZERO .fails files -- they are artefacts homemaker-fitness writes beside a\n.dom. Its own docstring claimed to cover \"every fail string ever emitted into a\nchecked-in native .fails file\", describing files that by design never exist in\nthe repo, so it could only ever pass on a machine that had already run the\nscorer, and failed `assert 0 \u003e 0` in a fresh clone.\n\nSplit into the three things it was conflating:\n\n test_classify_fail_tier_covers_every_fail_the_evaluator_emits\n GENERATES fails by scoring three corpus layouts chosen for breadth of\n failure kinds (harbor evolved-3M-nols-3 + generated, maple generated),\n and requires at least 8 distinct kinds so it cannot silently narrow.\n test_classify_fail_tier_rejects_an_unknown_fail_string\n the guard is only worth something if an unclassifiable string raises.\n test_classify_fail_tier_checks_any_native_fails_artefacts_present\n still sweeps .fails when a working tree happens to carry them, but never\n requires them.\n\nVerified by moving every .fails out of the tree and re-running: passes with none\npresent. Full suite now 376 passed, 0 failed.\n","dependency_count":0,"dependent_count":0,"comment_count":0}

79
DESIGN.md
View file

@ -5886,6 +5886,79 @@ warns about, now biting the flagship result itself: **any future re-validation
of this default needs N ≥ 40, and N=20 should not be trusted to settle it either
way.**
### 38.20 CP-SAT seeding re-measured deterministically: it loses (`homemaker-py-vjd`)
§39.5 concluded, over 6 seeds, that the exact CP-SAT seeder beats greedy
(harbor 102 → 92, maple 156 → 154). Two things have happened since that make it
worth re-checking, and a third turned up on the way.
**First, a live bug in the cap.** `solve_room_labels` sets both a deterministic
work-unit budget (`max_deterministic_time = 4.0`) and a wall-clock backstop
(`max_time_in_seconds`), with the comment that the wall clock "stays as a
pathological-case backstop only". At its 2.0 s value it had stopped being a
backstop and become **the binding constraint**: on harbor, 2 of 24 solves
returned `FEASIBLE` rather than `OPTIMAL`, wall time hit exactly 2010 ms, and
the deterministic budget was never reached (max 2.483 of 4.0). Those two
labellings were therefore both **suboptimal and load-dependent** — the wall
clock is exactly the load-dependent cap §39.5 added the deterministic one to
escape. Cause: §38.14's added `t → n` adjacency makes the model markedly harder,
and the 2 s value dated from when solves finished in ~124 ms. Raised to 30 s so
the deterministic budget governs; all 24/24 harbor and 36/36 maple solves are now
`OPTIMAL`, with the deterministic budget still in headroom (max 3.569 of 4.0).
**Second, the verdict itself.** Re-measured deterministically — `fdp`'s
`id()`-ordering fix means the arms no longer differ by memory layout — over 12
constructed seeds, scored by the canonical evaluator:
| programme | solver | hard | soft | total | s/seed |
|---|---|---|---|---|---|
| harbor-house | greedy | 722 | 601 | **1323** | 0.079 |
| harbor-house | cpsat | 908 | 640 | 1548 | 1.623 |
| maple-court | greedy | 777 | 987 | **1764** | 0.063 |
| maple-court | cpsat | 1213 | 1043 | 2256 | 1.327 |
**CP-SAT loses on both**, by +225 and +492 fails, at ~21× the seeding time. The
gap is concentrated in *hard* fails (+186, +436).
**Third, and it separates two things that looked like one.** §38.14's adjacency
is responsible for the *time* blow-up but almost none of the *quality* gap.
Removing `t → n` from harbor and re-measuring:
| harbor | cpsat − greedy (total) | cpsat s/seed |
|---|---|---|
| with `t → n` | +225 | 1.623 |
| without | **+205** | **0.193** (8.4× faster) |
So the adjacency costs 8.4× the time and about 9% of the quality deficit. The
regression is otherwise pre-existing.
**How this squares with §39.5.** That section's own text records CP-SAT
returning "194 / 180 / 171 / 182 over four identical 10-seed aggregates" before
the determinism work. A 10-fail harbor margin (102 vs 92) sits well inside a
noise band that wide. The measurement was taken with `fdp`'s `id()`-ordered
`room_slots` still live, so **the "cpsat wins" margin was never outside its own
documented noise**. It is restated here rather than contradicted: the honest
position is that the seeder-level claim was never established, and now that the
solver is deterministic it measures the other way.
*(The absolute totals here are ~6× §39.5's because the objective has since
changed — §39.4, §38.10–§38.12 — so these numbers are not directly comparable to
that table. The greedy-vs-cpsat comparison within this measurement is
like-for-like and is what the verdict rests on.)*
**Cost of the cap fix.** The two harbor solves that used to be cut off at 2 s now
run to optimality, and the full test suite goes from ~4.5 min to ~10 min because
the `assign_cpsat` tests dominate it. That is correctness bought with wall time,
and it is the right trade for a default, but the tests should not be paying it —
they cannot currently pass a smaller `deterministic_limit` because
`constructive_topology` does not thread the solver's limits through
(`homemaker-py-2xk`).
**No default changes.** `assign_solver` was already default `greedy` for the
independent reason §37.7 gives, and this reinforces it. What changes is that the
"cpsat wins the seeder A/B" claim should no longer be cited as a reason to
pursue it.
## 39. Config audit: requirements that actively fight the engine (`homemaker-py-ju3`) — measured 2026-08-25
The corpus `patterns.config` targets and `costs.config` values were estimated
@ -6071,7 +6144,11 @@ Re-measured over 6 seeds:
| harbor-house | 102 | **92** | cpsat wins |
| maple-court | 156 | **154** | cpsat wins |
`2g7.5`'s seeder-level result stands. Both `assign_solver` flags remain default
`2g7.5`'s seeder-level result stands. **RESTATED — see §38.20.** This margin
(10 fails on harbor) is inside the ±23-fail noise band this same section
documents below, and it was measured before `homemaker-py-fdp` made CP-SAT's
inputs deterministic. Re-measured deterministically over 12 seeds under the
current objective, cpsat *loses* on both programmes at ~21× the seeding time. Both `assign_solver` flags remain default
off for the independent reason §37.7 gives (it does not survive a full
`driver.search` run).

14
src/homemaker_layout/cpsat.py
View file

@ -45,7 +45,7 @@ def solve_room_labels(
reqs: dict,
neighbors: dict[Hashable, set],
context_types: dict[Hashable, set[str]],
time_limit_s: float = 2.0,
time_limit_s: float = 30.0,
deterministic_limit: float = 4.0,
) -> dict[Hashable, str] | None:
"""Assign each of ``codes`` to one of ``slots``, maximising satisfied
@ -198,6 +198,18 @@ def solve_room_labels(
# ``max_deterministic_time`` is a work-unit budget, independent of machine
# speed and load, so the same inputs give the same answer; the wall-clock
# cap stays as a pathological-case backstop only.
#
# homemaker-py-vjd: that backstop MUST stay well clear of what the
# deterministic budget costs in wall time, or it silently becomes the
# binding cap and takes the load-dependence back. It had. At
# ``time_limit_s=2.0`` harbor-house hit exactly 2010 ms and returned
# FEASIBLE (not OPTIMAL) on 2 of 24 solves, while the deterministic budget
# was never reached (max 2.483 of 4.0) -- so the cap doing the work was the
# wall clock, and those two labellings were both suboptimal AND
# load-dependent. The cause was §38.14's added `t -> n` adjacency, which
# makes the model markedly harder; the 2 s value dated from when solves
# finished in ~124 ms. Raised so `deterministic_limit` governs and the wall
# clock only stops a pathological hang.
solver.parameters.max_deterministic_time = deterministic_limit
solver.parameters.max_time_in_seconds = time_limit_s
status = solver.Solve(model)