From 58fe56eb55e41ad495766836c5c3eb0d94ca7241 Mon Sep 17 00:00:00 2001 From: Claude Date: Sun, 6 Sep 2026 18:11:10 +0000 Subject: [PATCH] bd: record 39.26 progress on homemaker-py-dpt Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01MJ84Feep79Hhm3E4zZJmnB --- .beads/issues.jsonl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.beads/issues.jsonl b/.beads/issues.jsonl index d191d27..e0da0fa 100644 --- a/.beads/issues.jsonl +++ b/.beads/issues.jsonl @@ -38,7 +38,7 @@ {"_type":"issue","id":"homemaker-py-1p0","title":"Geometry inner loop: full-objective equal-offset ratio optimiser","description":"DESIGN.md §5.1, §7 Phase 1. Productionise experiments/optimize_fullfitness.py into homemaker: optimise(topology, x0=None) -\u003e (geometry, fitness). DOF = equal-offset division ratios of free branches (solver.free_branches, lowest-storey cut ownership), clipped to [eps, 1-eps]. Objective = full oracle fitness (never a proxy — §4.2 falsified). Must support warm-start x0 (§5.6) and a population/batch evaluation mode so each iteration scores via one batched oracle call (§4.6).","acceptance_criteria":"Reproduces or exceeds §4.5 gains (x1.24–x1.67, no new failures) on 2f45907, candidate-002, c964435; works as a library call on any corpus .dom","status":"closed","priority":1,"issue_type":"feature","assignee":"Bruno Postle","owner":"bruno@postle.net","created_at":"2026-06-11T23:36:58Z","created_by":"Bruno Postle","updated_at":"2026-06-12T08:46:31Z","started_at":"2026-06-12T00:14:19Z","closed_at":"2026-06-12T08:46:31Z","close_reason":"innerloop.optimise() lands: batched CMA-ES sigma ladder (0.05/0.15, IPOP popsize doubling, deterministic seeding) over equal-offset free-branch ratios vs full oracle fitness; warm-start x0 supported. Acceptance vs unprojected originals: x1.65/x1.66/x1.58 against bars x1.24/x1.67/x1.59, no new failures, 46 oracle calls vs NM's 200. Two near-bar results accepted as reproduced-within-noise (1% tol) — draw spread brackets the single-NM-draw bars; approved by Bruno 2026-06-12. Gotchas: equal-offset projection of legacy unequal cuts loses fitness/adds failures (midpoint projection used); pycma seed=0 means clock-seeded.","dependencies":[{"issue_id":"homemaker-py-1p0","depends_on_id":"homemaker-py-av5","type":"blocks","created_at":"2026-06-12T00:39:33Z","created_by":"Bruno Postle","metadata":"{}"}],"dependency_count":1,"dependent_count":3,"comment_count":0} {"_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-dpt","title":"Scoring-model sweep: the three terms that still look like double counting, and the fail multiplier's curve","description":"DESIGN.md 39.24 swept every term in the objective against the owner's two\ntests -- does it double-count, and is a gaussian the right curve for what it\nmeasures. ratio_circulation failed both and was removed. Four entries were\nfiled rather than changed, because each needs a ruling or a rate change behind\nit first.\n\nSUSPECT 1 -- quality_size's UPPER side. A room larger than its target is\npenalised by a gaussian, while cost already charges floor area at 200/m2.\n39.15 measured that 82% of all size fails are over-target. An oversize room is\nwasteful in proportion to the excess, not quadratically, so the curve is\nprobably wrong too. NOT a simple removal: 39.15 also established that this\nupper half is the main brake on room growth, because with score = value/cost\nand realised scores ~1e-11, adding area always pays unless quality falls. If\nthe upper bound is the wrong instrument then value_inside vs cost inside is\nwhat wants re-examining, and that is a rate ruling.\n\nSUSPECT 2 -- the minimum-internal-area factor in evaluate_building. A\none-sided gaussian below 1.2x the programme's total declared room area. \"Build\nthe rooms you were asked for\" is already said by the missing-space fails\n(hard, 0.5^n each) and again by quality_size per leaf. This is a third\nstatement of the same requirement, at building scale. Check whether it ever\nbinds when the other two do not.\n\nSUSPECT 3 -- the 0.5**n_fails multiplier. Each failure independently halves\nthe building's value. Coherent as a product of independent defects, but it is\nnot \"twice as many failures is twice as bad\", and it is the single largest\nterm in the objective -- a 40-fail layout is scaled by 1e-12. Whether that is\nthe intended curve is an owner ruling, not a measurement. Note 39.8's\nconnectivity_weight_for already derives a weight from the value rates against\nthis exponent, so changing the curve moves that too.\n\nDEAD 1 -- ratio_public_outside and ratio_private_outside. Read in\nevaluate_building but absent from CONF_DEFAULTS and from every corpus\npatterns.config, so the branches never run. Either wire them up with declared\nvalues or delete them; an inert config path that looks live is what 39.20 was\nabout.\n\nDEAD 2 -- the `daylight` quality factor, pinned to 1.0 since the\nURB_NO_OCCLUSION descope (6). It is a factor that can never be anything but 1,\nand 39.18's geometric mean now has to special-case it as never-asked. It\nshould either come back (2g5) or go.\n\nThe DEAD two are safe to act on now. The SUSPECT three are gated on rulings,\nand all of them on the re-baseline (homemaker-py-bk9), since 39.19 onward has\nalready superseded the comparison table.\n","status":"open","priority":2,"issue_type":"task","owner":"noreply@anthropic.com","created_at":"2026-09-06T15:19:52Z","created_by":"Claude","updated_at":"2026-09-06T15:19:52Z","dependency_count":0,"dependent_count":0,"comment_count":0} +{"_type":"issue","id":"homemaker-py-dpt","title":"Scoring-model sweep: the three terms that still look like double counting, and the fail multiplier's curve","description":"DESIGN.md 39.24 swept every term in the objective against the owner's two\ntests -- does it double-count, and is a gaussian the right curve for what it\nmeasures. ratio_circulation failed both and was removed. Four entries were\nfiled rather than changed, because each needs a ruling or a rate change behind\nit first.\n\nSUSPECT 1 -- quality_size's UPPER side. A room larger than its target is\npenalised by a gaussian, while cost already charges floor area at 200/m2.\n39.15 measured that 82% of all size fails are over-target. An oversize room is\nwasteful in proportion to the excess, not quadratically, so the curve is\nprobably wrong too. NOT a simple removal: 39.15 also established that this\nupper half is the main brake on room growth, because with score = value/cost\nand realised scores ~1e-11, adding area always pays unless quality falls. If\nthe upper bound is the wrong instrument then value_inside vs cost inside is\nwhat wants re-examining, and that is a rate ruling.\n\nSUSPECT 2 -- the minimum-internal-area factor in evaluate_building. A\none-sided gaussian below 1.2x the programme's total declared room area. \"Build\nthe rooms you were asked for\" is already said by the missing-space fails\n(hard, 0.5^n each) and again by quality_size per leaf. This is a third\nstatement of the same requirement, at building scale. Check whether it ever\nbinds when the other two do not.\n\nSUSPECT 3 -- the 0.5**n_fails multiplier. Each failure independently halves\nthe building's value. Coherent as a product of independent defects, but it is\nnot \"twice as many failures is twice as bad\", and it is the single largest\nterm in the objective -- a 40-fail layout is scaled by 1e-12. Whether that is\nthe intended curve is an owner ruling, not a measurement. Note 39.8's\nconnectivity_weight_for already derives a weight from the value rates against\nthis exponent, so changing the curve moves that too.\n\nDEAD 1 -- ratio_public_outside and ratio_private_outside. Read in\nevaluate_building but absent from CONF_DEFAULTS and from every corpus\npatterns.config, so the branches never run. Either wire them up with declared\nvalues or delete them; an inert config path that looks live is what 39.20 was\nabout.\n\nDEAD 2 -- the `daylight` quality factor, pinned to 1.0 since the\nURB_NO_OCCLUSION descope (6). It is a factor that can never be anything but 1,\nand 39.18's geometric mean now has to special-case it as never-asked. It\nshould either come back (2g5) or go.\n\nThe DEAD two are safe to act on now. The SUSPECT three are gated on rulings,\nand all of them on the re-baseline (homemaker-py-bk9), since 39.19 onward has\nalready superseded the comparison table.\n","status":"in_progress","priority":2,"issue_type":"task","assignee":"Claude","owner":"noreply@anthropic.com","created_at":"2026-09-06T15:19:52Z","created_by":"Claude","updated_at":"2026-09-06T18:02:58Z","started_at":"2026-09-06T18:02:58Z","comments":[{"id":"01a077ea-c5eb-77ea-9dea-2b3710272612","issue_id":"homemaker-py-dpt","author":"Claude","text":"The two DEAD entries are done (DESIGN.md 39.26), verified as a no-op on every\ncorpus artefact -- each scores identically to its 39.25 measurement.\n\n ratio_public_outside / ratio_private_outside -- read in evaluate_building,\n absent from CONF_DEFAULTS and from every patterns.config, so both branches\n were guarded and never ran. Also retired what fed them: the four\n public_length_*/private_length_* tracking keys and the _public_length /\n _private_length helpers, which had no other caller. NOT touched:\n _public_access, _public_access_outside, _public_access_pins and the\n has_public_access_* flags -- those are live and drive collapse_global's\n preserve_public_access.\n\n the daylight quality factor -- pinned to 1.0 since the URB_NO_OCCLUSION\n descope, never in _GRADED_FACTORS, and 39.18 had to special-case it in\n factor_is_asked as never-asked. Removed. 2g5 would reintroduce a real one.\n\nRemaining, all three needing a ruling or a rate change rather than a\nmeasurement, and all gated on the re-baseline (bk9):\n\n 1. quality_size's UPPER side -- cost already charges floor area, 82% of size\n fails are over-target, and the curve is wrong too (an oversize room is\n wasteful in proportion, not quadratically). Not a simple removal: 39.15\n established this upper half is the main brake on room growth, so the\n value rates want examining first.\n 2. the minimum-internal-area factor -- a third statement of \"build the rooms\n you were asked for\", after the missing-space fails and quality_size.\n Worth checking whether it ever binds when the other two do not; it was\n binding on harbor s0 (x0.920) and programme-house s0 (x0.787) in the\n baseline, so it is not inert.\n 3. the 0.5**n_fails curve -- each failure independently halves the building.\n Coherent as a product of independent defects but not \"twice as many\n failures is twice as bad\", and it is the largest term in the objective.\n Note 39.8's connectivity_weight_for derives a weight against this\n exponent, so changing the curve moves that too.","created_at":"2026-09-06T18:11:10Z"}],"dependency_count":0,"dependent_count":0,"comment_count":1} {"_type":"issue","id":"homemaker-py-ecx","title":"Should an outside leaf's value depend on the daylight it actually delivers?","description":"DESIGN.md 39.17. value_rate gives an outside leaf above ground\nvalue_supported = 300 -- the same rate as an interior room -- against a cost of\n110, so a roof terrace returns 2.7x its cost where a room returns 1.5x. At\nground level an outside leaf takes value_outside = 100 against a cost of 10, a\nreturn of 10x.\n\nNothing in that ties an outside leaf's value to whether it illuminates\nanything. Open space is paid the same wherever it is put.\n\nThe measured consequence: harbor puts 50 m2 of courtyard on its ground floor,\nwhich is frontage-starved (supply/demand 0.62-0.97, 40-55% of its leaves fail\ncrinkliness), and 223 m2 on its first floor, which already has 1.3-1.8x the\nfrontage it needs. Perimeter terraces go the same way, 136 m2 ground against\n521 m2 above. The upper storeys set back into terrace and the ground floor is\npacked to the plot edge.\n\nThis is the same shape as the crinkliness defect 39.14 found -- value pricing\nsomething context-free that cost already charges -- but pointing the other way:\nthere the objective double-charged a good thing, here it pays full price for a\nuseless one.\n\nWorth considering, all default OFF and all needing their own A/B:\n\n* make an outside leaf's value depend on how much interior wall it actually\n illuminates (its shared boundary with uncovered inside leaves), so a\n courtyard wedged among rooms is worth more than a terrace facing nothing;\n* or cap value_supported for an outside leaf whose storey already has surplus\n frontage;\n* or leave value alone and let 773's pre-flight warning do the work, on the\n argument that this is the author's plot to fix, not the objective's.\n\nThe third option is not a cop-out and should be measured against the others:\n39.16 is a standing reminder that the objective's constants have been right\nmore often than the code reading them.\n\nBlocked on nothing, but read 39.14/39.16/39.17 first -- particularly 39.16 on\nwhy \"this constant looks wrong\" has twice turned out to be \"I misread what the\nconstant measures\".\n","status":"open","priority":2,"issue_type":"bug","owner":"noreply@anthropic.com","created_at":"2026-09-05T17:40:34Z","created_by":"Claude","updated_at":"2026-09-05T17:40:34Z","dependency_count":0,"dependent_count":0,"comment_count":0} {"_type":"issue","id":"homemaker-py-773","title":"Why can a slicing tree give only a third of its leaves light on two sides? (Alexander 159 vs the plan form)","description":"DESIGN.md 39.16 relocated the crinkliness residual. The constant is Alexander\n159 \"Light on Two Sides of Every Room\" and it is the best-corroborated number\nin the objective (the gaussian's own crossing and 38.3's frontage bound agree\nat 1.6202 by independent routes). It is not miscalibrated.\n\nWhat the twelve 500k baseline runs show is that the plan form cannot deliver\nwhat the pattern asks. Of 430 graded leaves:\n\n unlit 77 17.9% 100% fail\n one side 208 48.4% 15% fail\n two - corner 87 20.2% 2% fail\n two - opposite 34 7.9% 0% fail\n three or four 24 5.6% 4% fail\n\nTwo or more sides = 33.7% of leaves, and those essentially never fail\ncrinkliness. The whole residual is leaves that did not get it.\n\nA binary slicing tree on a convex plot is structurally stingy with two-aspect\npositions: a rectangular storey has exactly 4 corners, and opposite-wall\nexposure needs a leaf spanning the full depth of the plan. Meanwhile harbor\ndemands 7 rooms with two aspects at their declared size and maple 6\n(audit_programme_config.py, \"at declared target\" column).\n\nThe lever 39.11 already identified from the other direction is courtyards: an\ninternal void turns single-aspect rooms into two-aspect ones, and harbor's\nfrontage gap wants ~49 m2 of it. homemaker-py-7b7 enlarged the health-centre\nplot assuming a courtyard shape for the same reason.\n\nWorth investigating:\n\n* Does the search ever construct a courtyard on its own? Measure O/S leaf\n placement in the baseline artefacts -- interior vs perimeter.\n* Is there a construction or mutation operator that can create one? If the\n seeder never proposes an interior void, no amount of search will find it.\n* Would seeding a courtyard into init.dom for harbor and maple move the\n residual? Cheap to test and directly measurable, and unlike a constant\n retune it does not change what \"good\" means.\n* Does the shape-curve DP (37.2) model two-aspect feasibility at all? If it\n prunes on size/width/proportion only, it will accept topologies that cannot\n be daylit.\n\nThis is the successor to u5q. It is a plan-form question, not a scoring one --\nwhich is the point: 39.15 went looking for wrong magic numbers and found the\nnumbers were right and the geometry was the constraint.\n","status":"closed","priority":2,"issue_type":"task","assignee":"Claude","owner":"noreply@anthropic.com","created_at":"2026-09-05T15:58:13Z","created_by":"Claude","updated_at":"2026-09-05T17:46:53Z","started_at":"2026-09-05T17:31:14Z","closed_at":"2026-09-05T17:46:53Z","close_reason":"Closed","comments":[{"id":"01a072a8-28f8-76f8-96d3-33cb55c8f278","issue_id":"homemaker-py-773","author":"Claude","text":"Answered -- DESIGN.md 39.17. Two of the bead's four premises were wrong.\n\n1. \"Does the search ever construct a courtyard on its own?\" -- YES, and\n plenty. Classifying outside leaves by how much of their own boundary is\n external: harbor 8 courtyards / 273 m2, maple 16 / 404 m2, health-centre\n 13 / 107 m2 over three seeds each.\n\n2. \"Is there an operator that can create one?\" -- moot, see 1. Nothing is\n missing.\n\n3. Courtyards do real work: of 524 lit edges, 44% come from the plot wall,\n 30% from a courtyard, 26% from a perimeter void; a courtyard supplies at\n least one side for 77 of the 145 two-aspect leaves (53%).\n\n4. \"Does the shape-curve DP model two-aspect feasibility?\" -- NO, confirmed:\n shapecurve.py:25 says only size/width/proportion is modelled. Low value to\n fix, since per 38.24/39.12 the DP fires ~8 times in 500k evals.\n\nThe real answer is per-storey. Comparing each storey's demand (sum A_i /\n(1.6202*h)) with the lit wall its leaves actually hold:\n\n harbor ground 0.95/0.97/0.62 fails 14/27, 10/24, 12/24\n harbor first 1.67/1.26/1.75 fails 1/21, 3/18, 2/20\n maple ground 0.96/0.77/0.52 fails 12/27, 11/26, 15/27\n maple first 0.64/0.89/0.92 fails 6/14, 6/15, 5/16\n maple second 1.35/1.25/1.30 fails 1/21, 7/20, 4/24\n health-centre 1.77/1.60/2.07 fails 1/27, 2/24, 0/25\n programme-house 2.07-4.15 fails 0 everywhere\n\nRatio above ~1.2 -\u003e near-zero fails; below 1.0 -\u003e 40-55% of the storey fails.\n\nAnd the open space is on the wrong storey: harbor puts 50 m2 of courtyard on\nthe starved ground floor and 223 m2 on the first floor that already has 1.3-1.8x\nthe frontage it needs. value_rate explains it -- an outside leaf above ground\ntakes value_supported = 300, the same rate as a room, against a cost of 110, so\na roof terrace returns 2.7x cost where a room returns 1.5x, and nothing ties an\noutside leaf's value to whether it illuminates anything.\n\nMost importantly this CORRECTS 39.11, which divided demand evenly across\nstoreys and concluded harbor and maple were frontage-feasible \"with room to\nspare\". Programmes pin rooms to level 0, and the ground floor cannot set itself\nback to buy perimeter:\n\n harbor 347 m2 pinned (50% of plot) needs 71.4 m has 53.0 m SHORT 18.4 m\n maple 414 m2 pinned (54%) needs 85.2 m has 55.0 m SHORT 30.2 m\n health 50 m2 pinned (13%) needs 10.3 m has 61.3 m 51.0 m spare\n prog-house 38 m2 pinned (73%) needs 7.8 m has 22.1 m 14.2 m spare\n\nSame ordering as the corpus fail counts (39.3, 60.7, 6.0, 1.0), and fixed\nbefore any search runs.\n\nShipped: a third _preflight check, advisory like the others, silent on\nhealth-centre and programme-house, with tests/test_evolve_preflight.py\nasserting that and asserting the ground-floor figure exceeds the averaged one\non maple (22 m2 averaged vs 57 m2 actually needed).\n\nLeft open, both objective changes and neither smuggled in: harbor's achieved\nground floor carries ~614 m2 against the 347 m2 pinned, so the search overloads\nthe storey it is short on -- is that rational under the current rates? And\nshould an outside leaf's value depend on the daylight it delivers? The second\nis the same \"value prices what cost already charges, context-free\" shape 39.14\nfound in crinkliness.","created_at":"2026-09-05T17:40:18Z"}],"dependency_count":0,"dependent_count":0,"comment_count":1} {"_type":"issue","id":"homemaker-py-u5q","title":"Calibrate the crinkliness decay: an ordinary 4 m deep room scores 0.395, and sigma=1.1/3 was never justified","description":"DESIGN.md 39.14 made the crinkliness factor one-sided, which removed the\ndouble-charge against cost and the absurd 2.5 m optimum. It deliberately left\nthe other half alone: how steeply quality should decay from the saturation\npoint to the daylight limit.\n\nAt the global uncrinkliness params [5/6, 1.1/3] and the corpus's h = 3 m:\n\n depth 2.5 m q = 1.000 (saturation, now clipped)\n depth 3.0 m q = 0.902\n depth 4.0 m q = 0.395\n depth 4.5 m q = 0.191\n depth 4.86 m q = 0.100 (FAIL_THRESHOLD)\n depth 5.0 m q = 0.076 FAILS\n\nA 4 m deep room is entirely ordinary and it loses 60% of its value. After the\none-sided change, crinkliness is still the harshest of the seven quality\nfactors (area-weighted mean 0.513 vs size 0.536, proportion 0.853, width\n0.928, access 0.962, perpendicular 0.982), and essentially all of what is\nleft comes from this decay.\n\nThe two constants are inherited from Urb without a recorded derivation. The\ntarget 5/6 is now only the saturation point, so what actually needs\njustifying is sigma = 1.1/3, which sets how fast a room loses value as it\napproaches a limit it has not yet breached.\n\nNote the limit itself (1.62 h = 4.86 m) is NOT in question: 39.14 records two\nindependent derivations agreeing on it, the gaussian's own crossing and\n38.3's frontage bound.\n\nOptions worth measuring, all default OFF and all preserving the fail\nboundary:\n\n* widen sigma so the decay is gentler and only bites near the limit;\n* replace the gaussian's approach with a shape that is flat until some\n fraction of the limit and then falls -- i.e. move the saturation point out\n from 2.5 m rather than change the curvature;\n* derive sigma from the daylight rule itself rather than picking it, if a\n defensible derivation exists.\n\nJudge on a search A/B (experiments/ab_9gj_crinkliness.py takes named arms),\nscored under stock, with the fail set asserted byte-identical first.\n\nBlocked on 9gj landing.\n","status":"closed","priority":2,"issue_type":"bug","assignee":"Claude","owner":"noreply@anthropic.com","created_at":"2026-09-05T07:28:07Z","created_by":"Claude","updated_at":"2026-09-05T15:11:19Z","started_at":"2026-09-05T07:38:43Z","closed_at":"2026-09-05T15:11:19Z","close_reason":"Closed","dependencies":[{"issue_id":"homemaker-py-u5q","depends_on_id":"homemaker-py-9gj","type":"blocks","created_at":"2026-09-05T07:28:14Z","created_by":"Claude","metadata":"{}"}],"comments":[{"id":"01a0721a-a650-7456-adce-8b3955707592","issue_id":"homemaker-py-u5q","author":"Claude","text":"Done -- DESIGN.md 39.15. The answer is not a new sigma.\n\nFirst, the reframing that made it answerable: a fail is quality \u003c\nFAIL_THRESHOLD and every factor is a gaussian, so (target, sigma) does not\nexpress a soft preference -- it DEFINES an acceptance interval, target +-\n2.1460*sigma. Sigma is the tolerance that decides failures.\n\nThe blanket hypothesis does not survive. programme-house reaches 1 fail on all\nthree 500k seeds, and on two of them that fail is structural (staircase\nvolume, level 1 not connected), not a quality factor. Where a programme is\ninternally consistent the objective is very nearly satisfiable.\n\nThe specific one does, and it shows 39.1's CLEAN verdict was answering a\nweaker question. audit_programme_config.py swept each spec's whole tolerance\nbox and asked \"is SOME shape feasible\" -- all 67 corpus specs pass. But a\ntolerance is not a design intent. At the DECLARED target area and target\naspect:\n\n harbor-house 7 instances need \u003e=2 exposed sides (cr1, da1, 5 x n)\n maple-court 6 instances (da1, lr1, 4 x n)\n health-centre 0\n programme-house 0\n\nharbor's common room is 80 m2 at aspect 2.0 = 6.32 x 12.65 m, and 6.32 m is\ndeeper than the 4.86 m single-aspect daylight limit. It is feasible only at\nthe bottom of its area tolerance and the top of its aspect one (4.5 x 13.4 m\nat 60 m2) -- satisfiable only by building something other than what was asked\nfor.\n\nThose codes carry the failures. Within-programme (which controls for\nprogramme size, as a cross-programme comparison would not): harbor 13/21\ninstances fail = 62% vs 29/113 = 26% for all other codes; maple 14/18 = 78% vs\n53/172 = 31%.\n\nOf the 112 corpus crinkliness fails: 77 (69%) buried at crink == 0 -\u003e k54;\n17 (15%) too deep with a contradictory-as-declared spec; 18 (16%) other.\n\nSo three declared quantities -- target area, target aspect, daylight limit --\nare jointly contradictory for six specs and nothing said so. The daylight\nlimit is the one with independent support (the gaussian's crossing and 38.3's\nfrontage bound agree at 1.62h by separate routes). The area and aspect targets\nare the author's brief, so the resolution is an author decision -- shrink the\nroom, allow a deeper aspect, or declare it wants a corner -- not a constant\nretuned until the number drops.\n\nShipped: the \"at declared target\" column in audit_programme_config.py, the\ntool CLAUDE.md already sends programme authors to, plus the corner-demand\ncount. Objective unchanged.\n\nRecorded not fixed: 36 of 44 size fails (82%) are rooms LARGER than target,\nwhile cost already charges floor area at 200/m2. Same shape as 39.14's\ndouble-charge but NOT the same case -- crinkliness's surplus side never fires\nas a fail, whereas size's upper bound is the main brake on growth (with\nvalue/cost and scores ~1e-11, growth always pays unless quality falls).\nRemoving it on the analogy would license inflating every room. If it is the\nwrong instrument the value rate is what wants re-examining.","created_at":"2026-09-05T15:05:44Z"},{"id":"01a0724a-f888-7e40-8f93-814c8c3ef744","issue_id":"homemaker-py-u5q","author":"Claude","text":"CORRECTION -- the owner supplied the provenance this analysis was missing, and\nit withdraws part of what I recorded. DESIGN.md 39.16.\n\nThe crinkliness constant is Christopher Alexander, A Pattern Language 159,\n\"Light on Two Sides of Every Room\". 1/crink = A/(L*h) is floor area per metre\nof ILLUMINATED wall over storey height -- it is NOT room depth, and equals\ndepth only for a room lit on one side. So 5/6 * h = 2.5 m is 2.5 m of depth\nPER WINDOW WALL:\n\n lighting peak depth fail edge\n one side 2.50 m 4.86 m\n two opposite sides 5.00 m 9.72 m\n\nA 4 m room scores 0.395 lit on one side and 0.902 lit on two. The factor is\nnot miscalibrated; it is the pattern stated as a ratio.\n\nWithdrawn from 39.14: the \"2.5 m absurd optimum\" reading, and \"the corpus's\nrealised median depth is 2.95 m, the search built what it was paid for\" --\n2.95 was the median A/L, and the corpus's single-aspect leaves are a median\n3.46 m deep, its two-opposite leaves 4.42 m. Ordinary rooms.\n\nWithdrawn from 39.15: calling the six specs \"self-contradictory\". They are\nlarge rooms, and under Alexander a large room IS supposed to need two aspects.\nThe audit column is reporting the pattern working, not a mis-specification.\n\nWhat survives, on a better argument: crinkliness_shape=\"daylight\" still\nstands, because 159 states a MINIMUM and a two-sided gaussian turns a minimum\ninto a target. Of the 133 leaves in the clipped region, 68% are lit on two or\nmore sides, mean quality 0.770 -- rooms docked a quarter of their value for\nsatisfying the pattern well, on top of the exterior_wall/boundary_wall charge\nthose windows already carry in cost.\n\nAnd it relocates the residual. Over the 430 graded baseline leaves: unlit 77\n(100% fail), one side 208 (15%), two-corner 87 (2%), two-opposite 34 (0%),\nthree/four 24 (4%). Light on two sides all but guarantees a pass, and only\n33.7% of leaves get it. The question is not what sigma should be -- it is why\na binary slicing tree on a convex plot can only give a third of its leaves two\naspects. Filed as homemaker-py-773.\n\nMethod note: both errors came from reading a dimensionless ratio as a length.\nThe provenance and the interpretation are now recorded next to the constant in\nfitness.py, not only in DESIGN.md.","created_at":"2026-09-05T15:58:31Z"}],"dependency_count":1,"dependent_count":0,"comment_count":2}