diff --git a/.beads/issues.jsonl b/.beads/issues.jsonl
index a7567f3..c800967 100644
--- a/.beads/issues.jsonl
+++ b/.beads/issues.jsonl
@@ -6,7 +6,7 @@
 {"_type":"issue","id":"homemaker-py-yql","title":"Why do level-not-connected fails persist in the best layout, if severing is already punished?","description":"Re-opened by homemaker-py-2v1 closing NULL (DESIGN.md §39.8). §38.2 claimed the search was PAID to sever the circulation spine; measurement refuted that — every deletion that actually breaks connectivity is already punished (x0.00 to x0.58 across harbor-house and maple-court, 0 of 7 rewarded). So the incentive is correct, yet 'level 0 not connected' and 'level 1 not connected' still survive in evolved-3M-nols-3, the best layout after 1.7M evals.\\n\\nThe evidence now points at REACHABILITY rather than incentive: connected topologies may be hard to construct and hard to hold onto under mutation, not insufficiently rewarded. Worth checking:\\n  - what fraction of constructed seeds start connected at all (§39.7 measured 4/3/5 inaccessible-usable-space fails per 3 seeds, so: not many)\\n  - whether a connected layout, once found, survives mutation or is quickly lost\\n  - whether the constructive seeder's circulation dominating set actually guarantees connectivity, or only approximates it\\n  - whether the §39.7 usage change (39% of adjacency edges now trimmed) makes connectivity materially harder to achieve, which would be a cost of that fix worth quantifying\\n\\nNOTE this is now measurable in a way it was not before §39.7: the fails actually fire on constructed seeds instead of being hidden by routes through store cupboards.","acceptance_criteria":"A measurement distinguishing 'rarely constructed' from 'constructed then lost' for level connectivity, and a named lever for whichever it is.","status":"closed","priority":1,"issue_type":"task","assignee":"Claude","owner":"noreply@anthropic.com","created_at":"2026-08-26T14:13:54Z","created_by":"Claude","updated_at":"2026-08-26T14:37:30Z","started_at":"2026-08-26T14:31:19Z","closed_at":"2026-08-26T14:37:30Z","close_reason":"ANSWERED (DESIGN.md §39.9): constructed, then lost — at construction time, in the resize. _assign_adjacency_aware picks circulation as a CONNECTED dominating set and succeeds every time; _size_divisions_from_targets then moves every wall and destroys it. Measured, 20 seeds/programme: fully-connected seeds harbor 1/20, health-centre 1/20, maple 0/20. Control with proportion_aware=False (no resize): 100% connected on all three. Mechanism confirmed on health-centre: 41 of 49 circulation-to-circulation edges destroyed by the resize, surviving shared walls squeezed to 0.54-1.11 m against door_width=1.2. Same failure mode §37.7 recorded for CP-SAT assignment, never looked for in connectivity, worth 35-95 points.\n\n§39.7 COST CHECK: zero. Identical rates under prefix-inferred vs declared usages — has_circulation never trims C-C edges, so the usage change did not make connectivity harder.\n\nREPAIR MEASURED NEGATIVE: operators.repair_circulation_settled (§37.7's alternating-minimisation fix, bridging by retyping to C after geometry settles) restores 100% connectivity on all three programmes but is a net loss — connectivity fails -0.8..-1.7 while missing-room fails +5.0..+8.5, because each retyped leaf displaces a required room at a 3-5 fail cascade. Kept default off with the write-up.\n\nNEXT LEVER NAMED: preserve the connection during the resize (constrain _size_divisions_from_targets so a shared C-C boundary cannot fall below door_width) rather than rebuild it afterwards at the programme's expense.","dependency_count":0,"dependent_count":0,"comment_count":0}
 {"_type":"issue","id":"homemaker-py-sel","title":"Usage prefixes (b/t/l/k) are a second implicit namespace: 4 corpus rooms get another room's connectivity rules from their spelling","description":"§39.4 separated programme codes from the GENERIC structural types (C/O/S). It did not touch the other namespace sharing the first character: the USAGE prefixes b=bedroom, t=toilet, l=living, k=kitchen. These classify programme codes by first letter and are still prefix-based BY DESIGN (it is how Urb encodes room usage, and unlike the generic rule they never discard a requirement) -- but they are not inert.\\n\\ngraph.has_circulation deletes graph edges from them: a 'bedroom' loses its edges to living/kitchen/bedroom/toilet, a 'toilet' loses its edges to outside/living/kitchen/toilet, and b/t keep their LEAST popular circulation neighbour while l/k keep their MOST popular. fitness.access and the public-access check read them too. So a code that picks one up by accident is silently given another room's connectivity rules -- and connectivity is exactly where §38 located the residual.\\n\\nFour corpus rooms are misclassified by spelling alone:\\n  la1 'Laundry Room'   -\u003e living  (harbor-house, harbor-house-l0, maple-court)\\n  li1 'Library Corner'  -\u003e living  (harbor-house, maple-court)\\n  br1 'Staff Room'      -\u003e bedroom (health-centre)\\n  tr1 'Treatment Room'  -\u003e toilet  (health-centre)\\n\\nMeasured on a constructed health-centre seed: tr1 (as a toilet) has its edge to the adjacent outside space O stripped from the circulation graph; br1 (as a bedroom) has its edge to t10 'Staff WC' stripped. Both feed has_circulation and therefore the 'N inaccessible usable space' / 'level N not connected' fails.\\n\\nReport it with: python experiments/audit_programme_config.py (usage-prefix section).","design":"FINAL SHAPE. usage is a plain ATTRIBUTE of the space definition, mandatory on every declared code, no prefix fallback and NO mapping table.\n\n    spaces:\n      ws1:\n        name: Workshop Space      # free text, building-specific\n        usage: living             # controlled, drives engine behaviour\n\nThe earlier 'usage_classes:' indirection table (binding author-coined names like craft-\u003eliving) is WITHDRAWN. It was wrong three ways: (a) an indirect name-\u003ebehaviour mapping living apart from the thing it describes is exactly the shape of the first-character prefix rule that §39 exists to remove, not relocate; (b) it is 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 in patterns.config is an indirection table; (c) the need it served is already met, because 'programmes are building specific' is about what a room is CALLED and name: is already free text, whereas 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.\n\nRULE THAT FALLS OUT: a usage value exists if and only if the engine treats it differently somewhere. Config selects among behaviours; it cannot invent them. A genuinely new access class means writing code, and at that point the value joins the controlled set for everyone. utility passes this test — not on edge-stripping (identical to bedroom today) but because it is intended to drive derive_interchange_classes; distinct behaviour in a second subsystem is a real difference, an alias is not.\n\nVocabulary: living, kitchen, bedroom, toilet, utility, none. Missing usage on a declared code = load error naming the code. Unknown value = load error.\n\nMutation-safety (the original objection): usage is CODE-level, so usage_of(leaf.type) is looked up fresh on every read exactly as size/width/adjacency already are. Never stamp it on a leaf — 51 sites assign leaf.type, and share/share_type plus the r5a resurrection bug are the precedent for why leaf-level attributes go stale.\n\nAssignments for all 52 corpus codes: experiments/usage_map_proposal.yaml (living 12, bedroom 17, utility 11, toilet 7, kitchen 2, none 3; zero unresolved).","acceptance_criteria":"A programme can declare a room's usage explicitly; the prefix rule applies only where nothing is declared; audit_programme_config reports no unintended usage classification across the corpus; re-baselined with an A/B.","notes":"ALL 52 CORPUS CODES NOW ASSIGNED (experiments/usage_map_proposal.yaml): living 12, bedroom 17, utility 11, toilet 7, kitchen 2, none 3. Zero unresolved.\n\nRulings received: li1 Library Corner + br1 Staff Room -\u003e living (same access requirements); tr1 Treatment Room -\u003e bedroom; la1 Laundry -\u003e utility; zt1 Sterilisation -\u003e utility; ph1 Pharmacy -\u003e bedroom (private room, not public, like an office); n 'Neighborhood' -\u003e bedroom (a communal sleeping area, much like a dormitory); gh1 Greenhouse -\u003e living (grows plants but a living area like a conservatory); ws1 Workshop -\u003e living CONDITIONALLY (building-specific: communal craft room vs maintenance area; both corpus programmes carrying it are communal living facilities).\n\nDESIGN DECISION 1 — utility is a DISTINCT value, not an alias for bedroom. Same edge-stripping today (identical access requirements) but separately declared, because (a) they are very different uses and the config should read truthfully, and (b) it gives programme.derive_interchange_classes (§13/§26, homemaker-py-9o5) a natural axis: bedroom-class and utility-class leaves could be interchangeable DURING search and collapse to their real use at scoring time — exactly the superposition relaxation that machinery already implements. Worth building the usage key with that hook in mind.\n\nDESIGN DECISION 2 — vocabulary controlled but NOT closed. The earlier 'closed enum, unknown value errors' recommendation is withdrawn ('programmes are building specific, so it would be nice to have a controlled vocabulary, but not entirely necessary'). Proposed: the six known names drive engine behaviour; a programme may coin its own (usage: craft) provided it binds it in the same file via usage_classes: {craft: living}. An unbound name is a load error, so naming stays free without ever letting an unrecognised usage fall through to a silent default.\n\nVERIFIED — Brand adjacency point is NOT an engine bug. fitness._evaluate_full runs check_adjacency against graph_base_pre, the UNFILTERED graph, so a declared adjacency requirement is satisfied by a neighbouring room regardless of what has_circulation strips. The stripping only denies ROUTING, which is correct. So 'a toilet adjacent to a bedroom is a positive even if there is no door' is already expressible -- but it is only scored where DECLARED, and 3 of 4 real programmes never declare it: only programme-house has t1 -\u003e adjacency [b1]. harbor-house (t vs r/n), maple-court (t/tt vs r/n) and health-centre (t9/t10 vs tr1) do not. Filed separately as homemaker-py-adj.","status":"closed","priority":1,"issue_type":"bug","owner":"noreply@anthropic.com","created_at":"2026-08-26T10:06:54Z","created_by":"Claude","updated_at":"2026-08-26T13:38:20Z","closed_at":"2026-08-26T13:38:20Z","close_reason":"SHIPPED (DESIGN.md §39.7). usage: is a mandatory plain attribute of the space definition; vocabulary living/kitchen/bedroom/toilet/utility/none; missing or unknown is a load error from both parse paths. Code-level so it survives retype, never stamped on a leaf. has_circulation, fitness.access and the public-access check all key on declared usage; fitness._t0 deleted — no first-character type test remains anywhere. All 107 corpus entries migrated. MEASURED: connectivity model was ~4x too permissive; edges trimmed prefix-inferred vs declared, 3 seeds: harbor 18(9%)-\u003e79(39%), health-centre 12(8%)-\u003e59(40%), maple 53(17%)-\u003e123(39%); inaccessible fails 0-\u003e4, 2-\u003e3, 1-\u003e5. Harbor re-baseline seed 1/20k: 58 (15h/43s) -\u003e 61 (16h/45s), now reporting inaccessible-usable-space x2 plus level 0 and level 1 not connected — the count rose because the objective got honest.","dependency_count":0,"dependent_count":0,"comment_count":0}
 {"_type":"issue","id":"homemaker-py-ut5","title":"Update the 2v1 acceptance target: harbor's 15-fail reference was measured pre-ju3 against the 32-instance effective programme","description":"DESIGN.md 38.7 fixes the acceptance test for homemaker-py-2v1 as 'harbor-house reaches its known 15-fail floor in materially fewer than 1.7M evals, and without level 0/1 not connected'. That 15-fail figure comes from evolved-3M-nols-3, measured before homemaker-py-ju3 against the 32-instance EFFECTIVE programme (cr1/of/st1/st2 silently dropped or mis-parameterised). Against the real 37-instance programme the number will differ, so the target as written is not measurable any more.\\n\\nNeeded: migrate evolved-3M*.dom with experiments/migrate_ju3_rename.py, rescore against the renamed programme, and restate the 2v1 acceptance figure. The 39.3 re-baseline (55 fails, seed 1, 20k evals) is the new near-term reference but is not the long-budget floor.","acceptance_criteria":"evolved-3M*.dom committed and migrated; its post-ju3 fail count recorded in DESIGN.md; the 2v1 acceptance figure restated against it.","status":"closed","priority":1,"issue_type":"task","assignee":"Claude","owner":"noreply@anthropic.com","created_at":"2026-08-26T09:05:23Z","created_by":"Claude","updated_at":"2026-09-04T17:15:54Z","started_at":"2026-09-04T17:00:54Z","closed_at":"2026-09-04T17:15:54Z","close_reason":"Closed","comments":[{"id":"01a04a88-f365-774a-9f49-f6bda0dec0dc","issue_id":"homemaker-py-ut5","author":"Claude","text":"Now concrete and reproducible, since the owner committed the evolved-3M*.dom fixtures (0d4ae7a).\n\ntests/test_collapse_insearch.py::test_collapse_insearch_reproduces_94g_finish_time_result hard-codes 'assert len(f_base) == 15' against examples/harbor-house/evolved-3M.dom. Measured now:\n\n  86 fails at 0d4ae7a (post-39.4, before the ssz crinkliness change)\n  81 fails at 055d710 (after crinkliness: none on utility spaces)\n\nagainst the test's 15. The gap is the 39.4 namespace fix: the 15 was measured when harbor's effective programme was 32 instances because codes like cr1 were being read as generic circulation. The remaining 5 is this session's ssz change, in the expected direction and for the expected reason (utility spaces no longer emit crinkliness fails).\n\nSo this issue now has a failing test attached to it, which is the natural place to land the restated figure.","created_at":"2026-08-28T22:41:24Z"},{"id":"01a04c5b-e1c7-7cf2-a912-f9919cfb8ecb","issue_id":"homemaker-py-ut5","author":"Claude","text":"The failing test attached to this issue is fixed, but NOT by restating the\nfigure -- that is still this issue's job.\n\ntest_collapse_insearch_reproduces_94g_finish_time_result hard-coded both\nendpoints of the §17 result: 15 fails before collapse, 12 after. Its docstring\nsays the guarantee it exists to protect is that in-search collapse reaches the\nSAME layout as finish-time collapse on fixed geometry. Two independent constants\ndo not check that: they can both drift and stay equal, or both hold and mask an\ninequality.\n\nRewritten as test_collapse_insearch_matches_finish_time_collapse, which computes\nboth sides live and asserts they agree, plus that collapse does not make the\nlayout worse. Measured now: 82 -\u003e 58, and finish-time collapse independently\nreaches 58 at iters=3 and iters=6. The invariant holds; only the constants were\nstale.\n\nNote for whoever restates the figure: harbor's evolved-3M-nols-3.dom scores 82\nhere, not the 81 recorded earlier this session. The +1 is the Laundry Room's\ncrinkliness fail returning when the owner ruled laundries occupied and its\ncrinkliness: none declaration was removed (DESIGN.md §38.11).","created_at":"2026-08-29T07:11:25Z"},{"id":"01a06d65-b5f8-7d2b-ab47-0e15f8c59c1f","issue_id":"homemaker-py-ut5","author":"Claude","text":"Done. DESIGN.md gains 39.12; 38.7's acceptance paragraph is annotated in place.\n\nThe bead's premise was stale in one respect: experiments/migrate_ju3_rename.py\ndoes not exist. The rename approach was abandoned during ju3 in favour of\ntightening the matching rule at source (39.3), so evolved-3M*.dom parses\ncorrectly against today's 16-code / 37-instance harbor programme with no\nmigration. Rescored (fails / hard / soft / not-connected / missing instances):\n\n  evolved-3M-nols.dom               69   32h/37s   2   4\n  evolved-3M-nols-3.collapsed.dom   85   42h/43s   2   3\n  evolved-3M-nols-2.dom             87   43h/44s   2   3\n  evolved-3M-nols-3.dom             89   44h/45s   2   3\n  evolved-3M.dom                   145  101h/44s   1  22\n\nSo the \"15-fail floor\" layout scores 89. But those artefacts were evolved\nunder one objective and scored under another, so they are not a floor at all.\nThe 4x3-seed 500k cold-start baseline replaces them as the reference:\n\n  programme-house  1 / 1 / 1    mean 1.0   sd 0.00   MDD(n=3) 0.0\n  health-centre    4 / 9 / 5    mean 6.0   sd 2.65   MDD 6.6\n  harbor-house    33 /43 /42    mean 39.3  sd 5.51   MDD 13.7\n  maple-court     54 /73 /55    mean 60.7  sd 10.69  MDD 26.6\n\nTwo things fell out that matter more than the restated figure:\n\n1. Zero missing-space fails in all twelve runs. The dominant term in the 3M\n   artefacts is not one the live search still fails on.\n2. Crinkliness is 112 of the 321 corpus fails (35%), all soft -- and 9gj says\n   quality_uncrinkliness returns a flat hard 0.0 in exactly that regime. The\n   largest single component of the residual is one the objective cannot\n   descend. 66 of the 84 hard fails are one family: not-adjacent-to (28),\n   inaccessible usable space (20), not connected (18) -- all access topology,\n   mechanism in 39.9, two NULL attempts behind it.\n\nAcceptance test restated as: compare against the baseline table's mean, beat\nit by more than that programme's MDD at n\u003e=3 seeds on the same budget; and\ntreat \"level N not connected\" (present in 10 of 12 runs) as a separately\ntracked standing defect rather than a clause on an unrelated change.","created_at":"2026-09-04T17:09:37Z"}],"dependency_count":0,"dependent_count":0,"comment_count":3}
-{"_type":"issue","id":"homemaker-py-hxi","title":"Circulation is priced as overhead twice, and the shape factors forbid a corridor from being corridor-shaped","description":"Direct consequence of the zero-exposure bug. Measured on a constructed harbor-house seed: deleting a buried O leaf improved the raw score 85x and removed 7 fails; deleting a buried C leaf improved it 62x and removed 6 fails. Programme rooms are held in place ONLY by the missing-space fail cascade, not by contributing value -- deleting a buried k1/da1/m costs +15 fails, so they stay, but nothing positive keeps them. Circulation and outside leaves carry no missing-space requirement, so nothing keeps them at all. Observed live: in a 20k-eval harbor-house run, undivide/core_undivide account for a large share of recorded improvements (16 occurrences in the log) -- the search is literally deleting circulation to score better. This explains three prior negative results as a single mechanism: 18 graded circulation-connectivity (a tie-break signal cannot beat a 60x scalar gradient), 21/22 bridge_circulation (the operator inserts corridor leaves the objective immediately punishes), and the 'level N not connected' hard fails surviving \u003e1M evals in the 3M run.","notes":"Depends on the zero-exposure fix; may need no separate fix if (a)/(c) there restores a value gradient for circulation. Worth re-running the 18 and 21/22 A/Bs afterwards -- both may have been measuring a broken gradient rather than a bad idea.","status":"open","priority":1,"issue_type":"bug","owner":"noreply@anthropic.com","created_at":"2026-08-25T23:14:40Z","created_by":"Claude","updated_at":"2026-09-06T12:49:50Z","dependencies":[{"issue_id":"homemaker-py-hxi","depends_on_id":"homemaker-py-ssz","type":"blocks","created_at":"2026-08-25T23:15:12Z","created_by":"Claude","metadata":"{}"},{"issue_id":"homemaker-py-hxi","depends_on_id":"homemaker-py-2v1","type":"blocks","created_at":"2026-08-26T07:37:47Z","created_by":"Claude","metadata":"{}"}],"comments":[{"id":"01a075b1-c425-70a6-b20c-c4d98e044acf","issue_id":"homemaker-py-hxi","author":"Claude","text":"Owner ruling (2026-09-06), recorded here so this is not just a suspicion:\n\"the weird scoring of outdoor and circulation space ... definitely needs\nfixing\", in the context of abandoning the Perl oracle because \"many of the\nremaining problems have been carried in from the perl\".\n\nMeasured numbers to work from, over the twelve 500k baseline layouts\n(DESIGN.md 39.18), value returned per unit cost by leaf kind:\n\n  outside, ground   7.40   -\u003e  1.64 after 39.18/39.19\n  roof terrace      2.69   -\u003e  0.87\n  room              0.34   -\u003e  0.66\n  circulation       0.02   -\u003e  0.07\n\n39.19 fixed the terrace (owner's ruling: a terrace must not be worth more per\nm2 than a real internal room). Circulation is untouched and remains by a wide\nmargin the worst thing a building can contain -- a corridor returns about a\ntenth of what a room does, while the programme structurally REQUIRES corridors\nto connect anything.\n\nNote the two components, because they need separating:\n  * value_circulation = 50 against value_inside = 300, a 6x rate gap;\n  * mean circulation quality 0.076 under the product aggregation (5 of 7\n    factors bite it, and size 0.270 / crinkliness 0.376 are both harsh on a\n    long thin buried leaf). 39.18 raised that to ~0.21 but the rate gap is\n    untouched.\n\n39.9/39.10 established that \"level N not connected\" survives because the\nresize destroys constructed connectivity, and both repair attempts measured\nNULL. This bead is the other half of that story: even when the search HAS a\nspine, the objective is paying it to delete it.\n\nAny fix here changes what \"good\" means, so it needs the re-baseline\n(homemaker-py-bk9) either before it or alongside it.","created_at":"2026-09-06T07:49:39Z"},{"id":"01a075e1-7722-73db-913f-f2360763df79","issue_id":"homemaker-py-hxi","author":"Claude","text":"CORRECTION to my previous comment on this bead.\n\nI wrote \"even when the search HAS a spine, the objective is paying it to delete\nit\". That restates the premise DESIGN.md 39.8 RETRACTED. 2v1 measured it: of 64\nsampled deletions across harbor and maple, 7 broke connectivity and 0 of those\n7 were rewarded (x0.00 to x0.58). Severing is already net-negative -- it costs\n1-2 connectivity fails plus the cascade, which outweighs the x6 value gain. The\nlow value rate does NOT translate into the spine being deleted, and this bead's\ntitle still says it does.\n\nWhat the measurements do support is different, and narrower. Over the 111\ncirculation leaves in the twelve baseline runs (per-leaf means, not\narea-weighted):\n\n  perpendicular 0.982   fails  0/111\n  proportion    0.710   fails  7/111\n  size          0.539   fails 16/111\n  width         0.772   fails  2/111\n  crinkliness   0.485   fails 29/111\n  access        1.000   fails  0/111\n\n  median corridor 14.3 m2, median aspect 1.67\n\nTwo parameters look wrong, both the same double-charge shape as 39.14 and\n39.18:\n\n1. size_circulation = [0.0, 14.0]. The target area of a corridor is ZERO, so a\n   median 14.3 m2 corridor scores 0.592 on size purely for existing, and\n   anything over 30 m2 fails. Circulation is then penalised TWICE for being\n   overhead: once in value_circulation = 50 (a sixth of a room) and again in a\n   size factor whose optimum is non-existence.\n\n2. proportion_circulation = [1.5, 0.5] caps aspect at 2.57. At the minimum\n   width the factors allow (1.97 m) a corridor may be 5.1 m long before it\n   fails proportion. A corridor is long and thin by nature. Only 7/111 fail it\n   in practice -- but that is the objective having already shaped what gets\n   built, not evidence the cap is right.\n\nRetitle needed: this bead is not \"search is rewarded for deleting the\ncirculation spine\" (retracted) but \"circulation is priced as overhead twice,\nand the shape factors forbid a corridor from being corridor-shaped\".\n\nAny change here still needs the re-baseline (homemaker-py-bk9).","created_at":"2026-09-06T08:41:46Z"}],"dependency_count":2,"dependent_count":0,"comment_count":2}
+{"_type":"issue","id":"homemaker-py-hxi","title":"Circulation is priced as overhead twice, and the shape factors forbid a corridor from being corridor-shaped","description":"Direct consequence of the zero-exposure bug. Measured on a constructed harbor-house seed: deleting a buried O leaf improved the raw score 85x and removed 7 fails; deleting a buried C leaf improved it 62x and removed 6 fails. Programme rooms are held in place ONLY by the missing-space fail cascade, not by contributing value -- deleting a buried k1/da1/m costs +15 fails, so they stay, but nothing positive keeps them. Circulation and outside leaves carry no missing-space requirement, so nothing keeps them at all. Observed live: in a 20k-eval harbor-house run, undivide/core_undivide account for a large share of recorded improvements (16 occurrences in the log) -- the search is literally deleting circulation to score better. This explains three prior negative results as a single mechanism: 18 graded circulation-connectivity (a tie-break signal cannot beat a 60x scalar gradient), 21/22 bridge_circulation (the operator inserts corridor leaves the objective immediately punishes), and the 'level N not connected' hard fails surviving \u003e1M evals in the 3M run.","notes":"Depends on the zero-exposure fix; may need no separate fix if (a)/(c) there restores a value gradient for circulation. Worth re-running the 18 and 21/22 A/Bs afterwards -- both may have been measuring a broken gradient rather than a bad idea.","status":"open","priority":1,"issue_type":"bug","owner":"noreply@anthropic.com","created_at":"2026-08-25T23:14:40Z","created_by":"Claude","updated_at":"2026-09-06T12:49:50Z","dependencies":[{"issue_id":"homemaker-py-hxi","depends_on_id":"homemaker-py-ssz","type":"blocks","created_at":"2026-08-25T23:15:12Z","created_by":"Claude","metadata":"{}"},{"issue_id":"homemaker-py-hxi","depends_on_id":"homemaker-py-2v1","type":"blocks","created_at":"2026-08-26T07:37:47Z","created_by":"Claude","metadata":"{}"}],"comments":[{"id":"01a075b1-c425-70a6-b20c-c4d98e044acf","issue_id":"homemaker-py-hxi","author":"Claude","text":"Owner ruling (2026-09-06), recorded here so this is not just a suspicion:\n\"the weird scoring of outdoor and circulation space ... definitely needs\nfixing\", in the context of abandoning the Perl oracle because \"many of the\nremaining problems have been carried in from the perl\".\n\nMeasured numbers to work from, over the twelve 500k baseline layouts\n(DESIGN.md 39.18), value returned per unit cost by leaf kind:\n\n  outside, ground   7.40   -\u003e  1.64 after 39.18/39.19\n  roof terrace      2.69   -\u003e  0.87\n  room              0.34   -\u003e  0.66\n  circulation       0.02   -\u003e  0.07\n\n39.19 fixed the terrace (owner's ruling: a terrace must not be worth more per\nm2 than a real internal room). Circulation is untouched and remains by a wide\nmargin the worst thing a building can contain -- a corridor returns about a\ntenth of what a room does, while the programme structurally REQUIRES corridors\nto connect anything.\n\nNote the two components, because they need separating:\n  * value_circulation = 50 against value_inside = 300, a 6x rate gap;\n  * mean circulation quality 0.076 under the product aggregation (5 of 7\n    factors bite it, and size 0.270 / crinkliness 0.376 are both harsh on a\n    long thin buried leaf). 39.18 raised that to ~0.21 but the rate gap is\n    untouched.\n\n39.9/39.10 established that \"level N not connected\" survives because the\nresize destroys constructed connectivity, and both repair attempts measured\nNULL. This bead is the other half of that story: even when the search HAS a\nspine, the objective is paying it to delete it.\n\nAny fix here changes what \"good\" means, so it needs the re-baseline\n(homemaker-py-bk9) either before it or alongside it.","created_at":"2026-09-06T07:49:39Z"},{"id":"01a075e1-7722-73db-913f-f2360763df79","issue_id":"homemaker-py-hxi","author":"Claude","text":"CORRECTION to my previous comment on this bead.\n\nI wrote \"even when the search HAS a spine, the objective is paying it to delete\nit\". That restates the premise DESIGN.md 39.8 RETRACTED. 2v1 measured it: of 64\nsampled deletions across harbor and maple, 7 broke connectivity and 0 of those\n7 were rewarded (x0.00 to x0.58). Severing is already net-negative -- it costs\n1-2 connectivity fails plus the cascade, which outweighs the x6 value gain. The\nlow value rate does NOT translate into the spine being deleted, and this bead's\ntitle still says it does.\n\nWhat the measurements do support is different, and narrower. Over the 111\ncirculation leaves in the twelve baseline runs (per-leaf means, not\narea-weighted):\n\n  perpendicular 0.982   fails  0/111\n  proportion    0.710   fails  7/111\n  size          0.539   fails 16/111\n  width         0.772   fails  2/111\n  crinkliness   0.485   fails 29/111\n  access        1.000   fails  0/111\n\n  median corridor 14.3 m2, median aspect 1.67\n\nTwo parameters look wrong, both the same double-charge shape as 39.14 and\n39.18:\n\n1. size_circulation = [0.0, 14.0]. The target area of a corridor is ZERO, so a\n   median 14.3 m2 corridor scores 0.592 on size purely for existing, and\n   anything over 30 m2 fails. Circulation is then penalised TWICE for being\n   overhead: once in value_circulation = 50 (a sixth of a room) and again in a\n   size factor whose optimum is non-existence.\n\n2. proportion_circulation = [1.5, 0.5] caps aspect at 2.57. At the minimum\n   width the factors allow (1.97 m) a corridor may be 5.1 m long before it\n   fails proportion. A corridor is long and thin by nature. Only 7/111 fail it\n   in practice -- but that is the objective having already shaped what gets\n   built, not evidence the cap is right.\n\nRetitle needed: this bead is not \"search is rewarded for deleting the\ncirculation spine\" (retracted) but \"circulation is priced as overhead twice,\nand the shape factors forbid a corridor from being corridor-shaped\".\n\nAny change here still needs the re-baseline (homemaker-py-bk9).","created_at":"2026-09-06T08:41:46Z"},{"id":"01a0774e-3d8f-7ed0-ab69-a583528f470b","issue_id":"homemaker-py-hxi","author":"Claude","text":"Owner ruling: \"I think a corridor could be worth a sixth of a room, this is\nok.\" The rate question is CLOSED -- value_circulation = 50 stands.\n\nAll three of this bead's shape/amount defects are now fixed:\n\n  39.22  proportion_circulation -\u003e None   (no aspect cap; crinkliness is what\n                                           prevents unpleasant corridors)\n  39.23  size_circulation       -\u003e None   (no area cap; the gaussian rewarded\n                                           splitting a corridor by 2.15x)\n  39.24  ratio_circulation      -\u003e None   (duplicates the per-m2 economics)\n\nOn 39.24, the argument that decided it: the score is value/cost, already a\nratio, so the per-m2 economics (50 against a build cost of 200) is ALREADY a\nproportional pressure and not merely an absolute one -- adding corridor moves\nvalue/cost by an amount that depends on how much of the building is already\ncorridor. ratio_circulation said it a second time on a curve where twice the\ncorridor is far more than twice as bad.\n\nCorrection worth recording: my first measurement of this was wrong. I\noverrode ratio_circulation and got scores going DOWN when a \u003c=1 multiplier was\nremoved, which is impossible. Cause: all four corpus programmes DECLARE\nratio_circulation, so the CONF_DEFAULTS value I had changed was never in play\nand I was comparing two different sigmas. Same trap as value_supported in\n39.19 -- a default is not the live value when the configs declare their own.\n\nAlso worth recording against the \"keep it\" case: three of the four programmes\ndeclare a POSITIVE target (harbor/maple 0.08, health-centre 0.10), which makes\nthe term formally two-sided rather than \"less is better\", and a two-sided\ntarget is what a gaussian is for. It does not survive the numbers -- the lower\nside is worth at most 13.3% on the two large programmes against 99% on the\nupper side, and \"a building needs some circulation\" is enforced structurally\nby the access and connectivity checks, which no amount of value can buy off.\n\nMeasured effect, fail sets identical throughout (it was always a value\nmultiplier, never a fail source): +42% to +7712% on the corpus artefacts.\n\nCumulative fail-set effect of 39.22 + 39.23 on the baseline layouts, which are\nunchanged -- these are failures the objective should not have been reporting:\nharbor 33/43/42 -\u003e 32/40/38, maple 54/73/55 -\u003e 51/65/52, health-centre\n4/9/5 -\u003e 3/9/5, programme-house unchanged.\n\nClosing. The wider sweep the ruling asked for is 39.24's table, and what it\nturned up is filed as homemaker-py-dpt.","created_at":"2026-09-06T15:20:11Z"}],"dependency_count":2,"dependent_count":0,"comment_count":3}
 {"_type":"issue","id":"homemaker-py-ssz","title":"Zero-exposure leaves score hard quality=0: the objective assigns no value to any interior room","description":"fitness.quality_uncrinkliness returns a hard 0.0 when a leaf has no daylit wall (area_outside==0 =\u003e crink==0 =\u003e 'if not crink: return 0.0'). Because evaluate_leaf MULTIPLIES factors into quality, and process_storey accumulates 'value += quality * rate * area', such a leaf contributes EXACTLY ZERO value while still adding cost. Measured on the full default construction stack (leaf_sharing, depth_balanced, interior_outside, collapse_insearch), 3 seeds each: harbor-house 46% of interior leaves, health-centre 45%, maple-court 56% are zero-exposure. On a converged 20k-eval harbor-house run (seed 1, 57 fails) 14 of 17 crinkliness fails are zero-exposure, and ~470 m2 of the 721 m2 ground floor plate sits at zero value. This is the mathematically consistent limit of the gaussian (1/crink -\u003e inf), so it is a faithful port, not a porting bug -- but it means the objective's gradient does not describe a good building.","design":"Options, none yet chosen: (a) floor the factor at a small epsilon instead of 0 so buried leaves keep a value gradient and remain rankable; (b) make the gaussian one-sided (clip to 1.0 on the compact side) so being LESS exposed than target is not punished as hard as being over-exposed -- architecturally, a compact well-insulated room is not a defect; (c) exempt circulation/store types from the daylight requirement entirely (uncrinkliness_circulation currently uses the same [5/6, 1.1/3] as habitable rooms, so internal corridors -- completely normal architecture -- are guaranteed failures). Any change here invalidates prior fail-count baselines, so it needs its own A/B and a DESIGN.md section.","acceptance_criteria":"A/B on harbor-house + maple-court at fixed budget showing the chosen variant lowers hard-fail count without inflating soft; DESIGN.md section recording the result; prior baselines re-stated under the new objective.","status":"in_progress","priority":1,"issue_type":"bug","assignee":"Claude","owner":"noreply@anthropic.com","created_at":"2026-08-25T23:14:40Z","created_by":"Claude","updated_at":"2026-08-26T16:34:22Z","started_at":"2026-08-26T16:34:22Z","dependencies":[{"issue_id":"homemaker-py-ssz","depends_on_id":"homemaker-py-2v1","type":"blocks","created_at":"2026-08-26T07:37:47Z","created_by":"Claude","metadata":"{}"}],"comments":[{"id":"01a03ef6-9e45-7a1d-9f3c-3b3f0bd8a98f","issue_id":"homemaker-py-ssz","author":"Claude","text":"Diagnosis reframed and implementation landed (189efdb, DESIGN.md §38.8).\n\n§38.6's null was an artefact of the modes, not evidence about the objective: quality_uncrinkliness reaches `if not crink` before any mode logic that matters, so floor gave buried leaves 0.01, compact_ok contradicted itself (announced compact-is-fine, then returned the floor for the most compact case of all), and exempt_circulation reached at most a third of them. Rescue rates 0%/0%/0%/21-33%. §38.6 also used the pre-§39.4 prefix rule, sweeping programme rooms like cr1 in as circulation.\n\nReal finding: two thirds of buried leaves are spaces that architecturally do not want a window (stores, WCs, plant, corridors, covered courtyards), scored identically with a windowless bedroom. New mode usage_daylight keys the requirement on the declared usage. Fixed-budget search A/B running now; arms are re-scored under stock urb so the permissive modes cannot win by deleting a fail category.","created_at":"2026-08-26T16:45:45Z"},{"id":"01a03f38-06bd-7bb8-8f8b-8144c2ac3364","issue_id":"homemaker-py-ssz","author":"Claude","text":"Fixed-budget A/B done (budget 3000, 3 seeds, both programmes, arms scored under stock urb). NOT A PASS, and n=3 cannot decide it.\n\nPaired hard-fail deltas vs urb -- usage_daylight harbor [0,-1,-10], maple [0,+2,-10]. 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 the soft count rises as much as hard falls (harbor -10h/+9s, maple -10h/+15s); totals harbor 62-\u003e61, maple 120-\u003e125.\n\nSince arms are stock-scored, that is a real trade of hard for soft, not a relabelling. Under the tiered comparator (n_hard primary) it is progress; under this issue's acceptance criterion ('without inflating soft') it is not. That tension is gvb's question too.\n\nusage_daylight stays default off. Higher-power run launched: urb vs usage_daylight only, 10 seeds, both programmes.\n\nDecided regardless of the search A/B: the diagnostic half. Daylight is demanded of two thirds of the buried population that architecturally does not want it, and §38.6's contrary null was an artefact of three modes that never touched those leaves.","created_at":"2026-08-26T17:57:11Z"},{"id":"01a04a89-3805-7419-af9b-7b31a110d898","issue_id":"homemaker-py-ssz","author":"Claude","text":"Shipped the declared per-space crinkliness mechanism (055d710, DESIGN.md §38.10) per the owner's ruling that the daylight requirement is already defined in the crinkliness -- no separate attribute, no usage-keying.\n\nCrinkliness was the only leaf quality factor with no per-space target (size/width/proportion all have one). A space now declares crinkliness: none / [t,s], or omits it for the global target.  clips the compact side only, so a store may be buried but not be a starfish. Backward compatible: absent key = today's behaviour, so behaviour changes only where a config declares.\n\n18 corpus spaces migrated (usage: utility). Crinkliness fails 271 -\u003e 243; not-defects 136 (50%) -\u003e 108 (44%).\n\nREMAINING, and needs a ruling before ssz can close: the last 108 phantom fails are two populations with no spaces: entry --\n  generic C (internal circulation): 85, key uncrinkliness_circulation\n  generic O/S (covered outside, sahn): 23, falls through to uncrinkliness\n\nuncrinkliness_circulation exists as its own key and holds [5/6, 1.1/3], byte-identical to the habitable target -- a key created so corridors could differ, never given a different value. It is now settable to none (tested) but the default is left alone: corridors were not among the groups ruled on and this is 63% of the remainder.","created_at":"2026-08-28T22:41:42Z"},{"id":"01a04a89-964c-7107-b9f6-7597540a9c59","issue_id":"homemaker-py-ssz","author":"Claude","text":"Correction to the previous comment: a shell backtick ate a word. The sentence\nshould read:\n\n  `crinkliness: none` clips the compact side ONLY, it does not switch the\n  factor off. Over-exposure is still penalised, because a crinkly leaf costs\n  envelope whatever it holds. So a store may be buried, but a store may not be\n  a starfish.\n\nEverything else in that comment stands.","created_at":"2026-08-28T22:42:06Z"},{"id":"01a04aa6-d83f-7513-ada7-4a3fee8e804a","issue_id":"homemaker-py-ssz","author":"Claude","text":"RETRACTION. Owner's ruling: corridors need daylight; only rooms not occupied\nfrom day to day (cupboard, store, plant room) do without it.\n\nThat overturns the classification my 61% headline rested on. I had exempted\ninternal circulation, covered courtyards, WCs, laundries and reception on my own\ninference; none of those are exempt. Re-measured with the classification read\nfrom the corpus rather than guessed:\n\n  24 of 271 crinkliness fails (9%) were not defects -- not 136 (50%), not 61%.\n\nI overstated it by about six times by inventing a classification instead of\nasking for one.\n\nConsequences:\n  - uncrinkliness_circulation stays at [5/6, 1.1/3]. Its equality with the\n    habitable target is the CORRECT answer, not an untuned value: corridors want\n    daylight on the same terms as rooms.\n  - corpus declarations narrowed 18 -\u003e 14. usage: utility was too coarse a\n    proxy; it swept in Laundry Rooms and a Sterilisation Room, which are\n    occupied. What remains is storage, plant/mechanical, utilities closets and a\n    records room.\n\nWhat survives unchanged, none of it dependent on the classification: the §38.6\ncritique of the three modes (facts about the code); usage_daylight being\nmis-keyed; the §38.8 A/B yardstick being wrong; and the per-space crinkliness\nmechanism itself, which is the owner's design.\n\nWhat this does to the issue as a whole: the opening measurement (45-56% of\ninterior leaves are zero-exposure) was right, but the reading was wrong. Under\nthis ruling a buried leaf usually IS a defect, so scoring it zero is largely\ncorrect. What remains of the complaint is narrower and is about search mechanics\nrather than truth -- a hard 0.0 cannot rank two bad layouts against each other.\nFiling that separately; it is not the calibration fault this issue spent its\nlength chasing.","created_at":"2026-08-28T23:14:03Z"},{"id":"01a04aae-243a-7f3d-970c-452f19986751","issue_id":"homemaker-py-ssz","author":"Claude","text":"Records Room ruled: it is a store, stays exempt. No config change -- health-centre\nre1 already declares crinkliness: none. The corpus classification is settled at 14\nspaces: storage, plant/mechanical, utilities closets, records room.","created_at":"2026-08-28T23:22:02Z"}],"dependency_count":1,"dependent_count":2,"comment_count":6}
 {"_type":"issue","id":"homemaker-py-tdp","title":"Frontage-budget feasibility bound: harbor-house and maple-court are ~3x short of the exposed wall their own crinkliness constraint demands","description":"Closed-form bound, no search needed. Crinkliness fails when 1/crink \u003e 1.6202 (solving gaussian(x,1,5/6,1.1/3)=FAIL_THRESHOLD), and crink = L*h/A, so every interior leaf needs exposed wall length L \u003e= A/(1.6202*h) -- per storey, A_storey/4.86 metres at h=3. Supply vs demand per storey: harbor-house 54m supplied / 148m needed (2.7x short); maple-court 56m / 162m (2.9x short); health-centre 43m / 41m (feasible); programme-house 24m / 12m (2x surplus). The deficit comes from half the plot perimeter being marked 'private' in harbor/maple -- area_outside skips private/fortified edges. This PREDICTS the corpus fail-count plateau: the two programmes that are frontage-short are exactly the two that plateau (harbor 30-40, maple 74-84 fails), and the two with surplus are the two that effectively solve (programme-house reached 1 fail in a 12k-eval run here). Causal check: relabelling harbor's two private edges as open (identical geometry and programme, perimeter labels only) cut zero-exposure leaves 52%-\u003e19% and seeder crinkliness fails 16.5-\u003e12.0 over 6 seeds.","design":"Ship the bound as a pre-flight check (a 'homemaker-programme-check' style report, or a warning from evolve.py at startup): given a plot and programme, report required vs available frontage and the courtyard area needed to close the gap. This is the cheap, no-ground-truth-needed version of what 2g7.2 objective calibration wanted -- it answers 'is this programme even satisfiable' without needing traced human plans.","acceptance_criteria":"A tool/check that reports the frontage budget per programme dir; DESIGN.md section with the derivation and the corpus table; the plateau programmes flagged as frontage-infeasible-as-specified.","status":"closed","priority":1,"issue_type":"task","assignee":"Claude","owner":"noreply@anthropic.com","created_at":"2026-08-25T23:14:40Z","created_by":"Claude","updated_at":"2026-08-26T16:20:08Z","started_at":"2026-08-26T16:08:13Z","closed_at":"2026-08-26T16:20:08Z","close_reason":"Shipped as `evolve._preflight`, but the headline claim in this issue's title is\nRETRACTED. See DESIGN.md §39.11 (and the partial retraction inserted at §38.3).\n\nWhat was wrong: the \"2.7x / 2.9x short\" figures were computed for a FULLY BUILT\nplot. None of these programmes ask for a fully built plot. Recomputed against\nthe area each programme actually demands (demand / storeys), harbor-house and\nmaple-court are NOT frontage-infeasible -- they need 49 m2 and 22 m2 of\ncourtyard respectively, against 277 m2 and 424 m2 of spare plot. The bound\nitself (L \u003e= A/(1.6202*h)) is sound; it was applied to the wrong quantity.\n\nWhat survives: exactly one corpus programme is infeasible, and not for daylight\nreasons. health-centre demands 240 m2 of floor on a 183 m2 plot (131%). That is\nvisible in the geometry -- every room lands at 0.60x its declared target, 100%\nof them undersized, uniformly. harbor-house and maple-court hit target almost\nexactly (median area / (target * share) = 1.01x), so the plateau is NOT\nexplained by an unsatisfiable brief and remains unexplained.\n\nShipped:\n  - `evolve._preflight(programme_dir)`, run at startup before the run banner.\n    Two closed-form checks: (1) does demanded floor area fit the plot,\n    (2) is there enough daylit wall for it. Advisory only, never blocks a run.\n    Fires on health-centre (both) and harbor-house/maple-court (frontage only);\n    silent on programme-house.\n  - `experiments/diag_exposure_frontage.py frontage` reports the full budget.\n  - DESIGN.md §39.11 with the corrected corpus table; §38.3 marked PARTLY\n    RETRACTED and cross-referenced.\n\nBoth the check and the diagnostic measure plot area and frontage through\n`geometry`, not the raw init.dom corners, so they carry the `wall_outer` inset\nand plot rotation, and \"daylit\" means exactly what `Fitness.area_outside` means\nby it (external boundary, perimeter type not private/fortified). An earlier\nhand-rolled version of these figures skipped the inset and was ~1 m / ~14 m2\noptimistic per plot; the numbers in §39.11 are the corrected ones.\n\nAcceptance criteria 1 and 2 met. Criterion 3 (\"plateau programmes flagged as\nfrontage-infeasible-as-specified\") is withdrawn as false, not deferred.\n","dependency_count":0,"dependent_count":0,"comment_count":0}
 {"_type":"issue","id":"homemaker-py-2g7.4","title":"Exact shape-curve inner loop (Otten/Stockmeyer DP) replacing Nelder-Mead","description":"The classic slicing-floorplan result applied to our exact representation: each leaf's size/width/proportion constraints define a feasible-shape region; these compose bottom-up through the slicing tree as piecewise shape curves, yielding in ONE linear pass (no iteration): (a) whether ANY ratio assignment satisfies all per-leaf shape constraints, and (b) the ratios that realize a chosen point on the root curve. Today the same question costs an 80-eval NM run per child (~all of the 3M-eval budget) and answers it only approximately. Plan: (1) prototype on harbor-house-l0 with a rectangular plot approximation; (2) validate against innerloop.optimise — DP-feasible topologies must score \u003e= NM result when polished, DP-infeasible must never reach 0 shape fails under NM; (3) wire as a PRE-FILTER: prune shape-infeasible children before any native eval, and warm-start NM from DP ratios (or replace NM entirely where the plot is near-rectangular; keep NM as final polish for skew). CAVEATS to model honestly: crinkliness/access/adjacency are NOT in the DP (graph terms, not per-leaf shape) — the DP handles the size/width/proportion family only, which is fine for pruning; equal-offset skew-quad geometry means DP areas are approximate — measure the approximation error on real plots first (harbor plot is a near-rect quad). Expected payoff: 100-1000x cheaper feasibility, turning topology search into enumerate-and-prune and unlocking the racing/MAP-Elites/CP issues. Cf. §34: autodiff failed on wall-clock; this is a different attack — exactness via structure, not gradients.","acceptance_criteria":"on harbor-house-l0: DP verdict agrees with NM-polished shape-fail outcome on \u003e=95% of 200 random topologies; measured speedup \u003e=50x per feasibility decision; approximation error on the skew plot quantified","status":"closed","priority":1,"issue_type":"feature","assignee":"Bruno Postle","owner":"bruno@postle.net","created_at":"2026-08-02T09:15:04Z","created_by":"Bruno Postle","updated_at":"2026-08-02T22:42:15Z","started_at":"2026-08-02T18:39:05Z","closed_at":"2026-08-02T22:42:15Z","close_reason":"Prototype PASS: 99.0% agreement (\u003e=95%), 93.6x speedup (\u003e=50x), approximation error quantified (7.5% bbox overestimate). See DESIGN.md §37.2. Not wired into product this session -- follow-up homemaker-py-6xh filed.","dependencies":[{"issue_id":"homemaker-py-2g7.4","depends_on_id":"homemaker-py-2g7","type":"parent-child","created_at":"2026-08-02T10:15:04Z","created_by":"Bruno Postle","metadata":"{}"}],"comments":[{"id":"019fc645-557c-7351-9349-d693e5eefa2b","issue_id":"homemaker-py-2g7.4","author":"Bruno Postle","text":"Post-close correction (user review): the prototype's rectangular\napproximation used an axis-aligned global bbox for each quad's (w,h) --\ncorrect only by coincidence on harbor-house-l0's near-axis-aligned plot\n(~7.5% area error). A real building's orthogonal walls need not align to\nthe plot's survey/CRS axes; confirmed by rotating the plot 45deg, where\nbbox error jumped to 102%.\n\nFixed: (w,h) now measured from edge lengths (edge0+edge2)/2,\n(edge1+edge3)/2 -- rotation-invariant by construction -- and the\nparent/child composition rule (which dimension sums vs. is shared) is now\nderived EXACTLY from child.rotation parity (verified float-exact\nidentity) instead of the empirical geometric heuristic the closed version\nused (which, tried alone without the parity fix, regressed accuracy\n99.0% -\u003e 95.5%).\n\nRe-validated: 99.0% on harbor-house-l0 unrotated (matches original, 0\nfalse negatives), 100% at 97x speedup on the SAME plot rotated 45deg.\nSee DESIGN.md §37.2 (Correction 1 / Correction 2) for full detail.\nhomemaker-py-6xh (production wiring follow-up) still applies.","created_at":"2026-08-03T06:17:40Z"}],"dependency_count":0,"dependent_count":1,"comment_count":1}
@@ -38,6 +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-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}