From 335dd9c1ffdeea940b248bbe6bd8298ad211ebee Mon Sep 17 00:00:00 2001 From: Claude Date: Fri, 28 Aug 2026 22:41:42 +0000 Subject: [PATCH] beads: close bdf, attach ut5's failing test, file 1ue The owner's fixture commit (0d4ae7a) took fresh-clone failures 7 -> 2, so bdf is closed. The 2 remaining are different bugs: - ut5 now has a failing test attached. test_collapse_insearch hard-codes 15 fails for evolved-3M.dom; measured 86 at 0d4ae7a and 81 after the ssz crinkliness change. The gap is the 39.4 namespace fix (the 15 dates from when harbor's effective programme was 32 instances because cr1 and friends were read as generic circulation); the 5 is this session's change, in the expected direction. - 1ue (new): test_classify_fail_tier_covers_full_corpus globs examples/**/*.fails and asserts checked > 0, but those are generated artefacts absent from a clean tree, so it asserts on the developer's working tree rather than on the code. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01MJ84Feep79Hhm3E4zZJmnB --- .beads/issues.jsonl | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/.beads/issues.jsonl b/.beads/issues.jsonl index b011ccc..2fdc8fc 100644 --- a/.beads/issues.jsonl +++ b/.beads/issues.jsonl @@ -3,9 +3,9 @@ {"_type":"issue","id":"homemaker-py-3z0","title":"Preserve circulation connectivity DURING the resize, instead of repairing after it","description":"Named by homemaker-py-yql / DESIGN.md §39.9. The constructive seeder picks circulation as a CONNECTED dominating set and succeeds every time; _size_divisions_from_targets then moves every wall to hit the programme's area targets and destroys it. Measured: 41 of 49 circulation-to-circulation edges lost on health-centre, surviving shared walls squeezed to 0.54-1.11 m against door_width=1.2, taking fully-connected constructed seeds to 1/20, 1/20 and 0/20 across the corpus (100% with the resize disabled).\\n\\nRepairing AFTER the fact was measured and is a net loss (§39.9): operators.repair_circulation_settled restores 100% connectivity but raises missing-room fails by 5.0-8.5 per seed, because every leaf retyped to C displaces a required room at a 3-5 fail cascade. Kept default off.\\n\\nThe fix belongs upstream: constrain the resize so a shared boundary between two circulation leaves cannot fall below door_width. That is an added constraint on an existing solve rather than a new repair pass, and it keeps the programme intact — nothing is displaced, the wall simply is not allowed to close up.\\n\\nWorth checking while there: solver.py already has min_width_generic (default 1.2) keeping generic leaves from collapsing to slivers, which is the same idea applied to leaf WIDTH rather than to a shared BOUNDARY between two specific leaves. The new constraint may belong in the same place.","acceptance_criteria":"Constructed seeds stay \u003e=90% level-connected WITH the resize enabled, without raising missing-room fails; corpus re-baselined.","status":"closed","priority":1,"issue_type":"feature","assignee":"Claude","owner":"noreply@anthropic.com","created_at":"2026-08-26T14:37:48Z","created_by":"Claude","updated_at":"2026-08-26T15:10:30Z","started_at":"2026-08-26T15:02:29Z","closed_at":"2026-08-26T15:10:30Z","close_reason":"MEASURED NULL (DESIGN.md §39.10), and it reframes §39.9. Built operators._size_divisions_preserving_circulation: snapshot every cut, resize, then revert the cuts on the tree path between each circulation pair the resize broke — programme fully intact, only geometry given back. It works on connectivity (harbor 50-\u003e92%, maple 67-\u003e97%, health-centre 8-\u003e17%) but costs area accuracy: constructed-seed fails harbor 96.6-\u003e141.5, maple 141.8-\u003e175.8, size fails roughly double. Also recorded: both halves of the re-cut do damage in different proportions per programme (freezing rotation leaves harbor 71%, health-centre 8%, maple 92%), so a fix must be able to give back either; and a greedy single-cut revert stalls on the plateau where no ONE revert helps though two would, which is why targeting the broken pairs was needed.\n\nThe defence that raw constructed seeds understate the case — the resize is only a warm start, the inner loop should recover — was TESTED AND FAILS. Full search, harbor-house, 12000 evals, seed 1: OFF 43 fails (9 hard, 3 connectivity); ON 65 fails (26 hard, 4 connectivity). Worse on every axis including connectivity itself.\n\nREFRAMING: §39.9's fact stands (the resize destroys 41 of 49 circulation edges) but is NOT ACTIONABLE, because construction-time connectivity does not determine final connectivity. The search discards and rebuilds the seeder's circulation either way; constraining the seed only spends area quality the search cannot recover. Connectivity was never a construction problem, and §39.8 showed it is not an incentive problem either. Both flags stay default off; do not revisit without a new formulation (the standing bubble.py has).","dependency_count":0,"dependent_count":0,"comment_count":0} {"_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":"open","priority":1,"issue_type":"task","owner":"noreply@anthropic.com","created_at":"2026-08-26T09:05:23Z","created_by":"Claude","updated_at":"2026-08-26T09:05:23Z","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":"open","priority":1,"issue_type":"task","owner":"noreply@anthropic.com","created_at":"2026-08-26T09:05:23Z","created_by":"Claude","updated_at":"2026-08-26T09:05:23Z","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"}],"dependency_count":0,"dependent_count":0,"comment_count":1} {"_type":"issue","id":"homemaker-py-hxi","title":"Buried circulation and outside space are negative-value: search is rewarded for deleting the circulation spine","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-08-25T23:14:40Z","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":"{}"}],"dependency_count":2,"dependent_count":0,"comment_count":0} -{"_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":"open","priority":1,"issue_type":"bug","owner":"noreply@anthropic.com","created_at":"2026-08-25T23:14:40Z","created_by":"Claude","updated_at":"2026-08-25T23:14:40Z","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":"{}"}],"dependency_count":1,"dependent_count":2,"comment_count":0} +{"_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"}],"dependency_count":1,"dependent_count":2,"comment_count":3} {"_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} {"_type":"issue","id":"homemaker-py-2g7.3","title":"Hard/soft fail tiering: 'solved' = zero hard fails","description":"Lex-by-total-count treats a crinkly wall the same as a missing room, so search polishes shape taxes instead of fixing structure — the 3M-run best still carries 'level 0/1 not connected' and wrong-level fails after 1.7M evals. Split fails into HARD (missing space, wrong/required level, level connectivity, circulation connectivity, stairs, covered-outside) and SOFT (crinkliness, proportion, size, width, edge-too-long) tiers. Outer comparator becomes (-hard, -soft, fitness); 'solved' is defined as zero hard fails. GUARDS: (1) the inner-loop 0.5^n cliff must keep protecting against trading into new fails (§4.5/§4.9 — rerun the 0/9 inner-loop-protection check); (2) rerun the §4.9 outer A/B: the scheme must not reintroduce the scalar pathology; (3) §11.4 warns comparator reshaping alone does not escape topology basins — the claim here is narrower: budget stops being spent on soft fails while hard fails remain, and reporting becomes meaningful. The tier map lives in fitness.py next to the fail emission sites so new fail strings must declare a tier. Can start before the calibration issue lands but final tier assignments should be reviewed against its findings.","acceptance_criteria":"tiered comparator behind a flag with A/B on harbor+maple (3 seeds, 20k evals): hard-fail count at budget strictly better or equal on mean, no §4.9 regression; report shows hard/soft split","notes":"ACCEPTANCE A/B COMPLETE — PASS (2026-08-02, experiments/tier_ab_2g7_3.py,\nharbor-house + maple-court, 3 seeds, budget 20000, leaf_sharing=True,\nn_workers=4, wall ~2h53m):\n\n harbor-house hard mean: flat 11.67 -\u003e tiered 5.33 (soft 29.00 -\u003e 42.33)\n maple-court hard mean: flat 19.33 -\u003e tiered 14.00 (soft 71.33 -\u003e 87.67)\n\nHard-fail mean strictly better on BOTH programmes at fixed budget — the\nrequired acceptance bar. Soft/total rise as expected (budget redirected from\npolishing shape fails to structural ones). Full per-seed log at\nscratch/tier_ab_2g7_3/log.txt (not committed — scratch output, regenerate via\nthe script if needed).\n\nGuards: (1) inner-loop 0.5^n cliff untouched by construction (no diff to\ninnerloop.py or the existing 0.5**len(failures) line) — not re-measured\nempirically, doesn't need to be. (2) tiered key is still lexicographic, not a\nblended scalar, so structurally immune to the §4.8 scalar pathology;\nencoded as tests/test_driver.py::test_use_tiers_prefers_fewer_hard_over_fewer_total_fails.\n\nDESIGN.md §37.1 written up with full table and rationale. Feature lands\ndefault-off (--use-tiers / HOMEMAKER_USE_TIERS / driver.search(use_tiers=)),\nso no existing reproduction changes.\n\nFollow-on (not blocking, filed separately): convergence-SPEED comparison\n(evals to 0 hard fails, tiered vs flat, same budget) — this A/B measured\nfail composition at a fixed budget snapshot, not time-to-solved.","status":"closed","priority":1,"issue_type":"feature","assignee":"Bruno Postle","owner":"bruno@postle.net","created_at":"2026-08-02T09:14:14Z","created_by":"Bruno Postle","updated_at":"2026-08-02T17:51:18Z","started_at":"2026-08-02T09:58:53Z","closed_at":"2026-08-02T17:51:18Z","close_reason":"Acceptance A/B passed on both harbor-house and maple-court (hard-fail mean strictly better under tiering); guards verified; DESIGN.md §37.1 written up.","dependencies":[{"issue_id":"homemaker-py-2g7.3","depends_on_id":"homemaker-py-2g7","type":"parent-child","created_at":"2026-08-02T10:14:14Z","created_by":"Bruno Postle","metadata":"{}"}],"dependency_count":0,"dependent_count":0,"comment_count":0} @@ -94,7 +94,8 @@ {"_type":"issue","id":"homemaker-py-nyb","title":"High-locality topology operators (mutation + subtree crossover)","description":"DESIGN.md §5, §7 Phase 2, §8.4. Mutation moves: divide/undivide leaf, swap children, rotate cut, retype leaf, per-floor delta edits, storey add/delete (cf. Urb Mutate.pm — but geometry sliding belongs to the inner loop, not the operator set). Crossover: area-matched subtree exchange (a subtree = a contiguous region, so crossover is meaningful — Crossover.pm). Operators must be high-locality: small genome change =\u003e small phenotype change, so warm-started inner loops stay cheap.","acceptance_criteria":"Each operator produces valid genomes (oracle scores them without error); locality measured (mean fitness/geometry perturbation per operator)","status":"closed","priority":2,"issue_type":"feature","assignee":"Bruno Postle","owner":"bruno@postle.net","created_at":"2026-06-11T23:37:27Z","created_by":"Bruno Postle","updated_at":"2026-06-12T13:07:37Z","started_at":"2026-06-12T12:54:23Z","closed_at":"2026-06-12T13:07:37Z","close_reason":"operators.py lands: 7 mutations + area-matched crossover, valid-by-construction via genome.encode repair. 115/115 oracle-valid children; locality measured: geom-pert 0.07-0.33 per op, fitness-pert 0.68-0.99 (0.5^n cliff flags raw moves — warm restart + penalty reshaping confirmed load-bearing). Also fixed dom._link stale below-links on structural mutation.","dependencies":[{"issue_id":"homemaker-py-nyb","depends_on_id":"homemaker-py-k2g","type":"blocks","created_at":"2026-06-12T00:39:36Z","created_by":"Bruno Postle","metadata":"{}"}],"dependency_count":1,"dependent_count":1,"comment_count":0} {"_type":"issue","id":"homemaker-py-k2g","title":"Topology genome: base-floor tree + per-floor deltas + type assignment","description":"DESIGN.md §5.2, §7 Phase 2. Genome = base-floor slicing topology (primary) + per-leaf type assignment + per-floor divide/undivide deltas (Below-inheritance as regulariser; cut owned by lowest storey where its path is divided — §10). Must round-trip to/from dom.py Node trees so the oracle and inner loop consume it directly. Includes storey count and per-floor type overrides.","acceptance_criteria":"Genome \u003c-\u003e .dom round-trip on all 35 corpus files preserves fitness; multi-storey wall stacking preserved","status":"closed","priority":2,"issue_type":"feature","assignee":"Bruno Postle","owner":"bruno@postle.net","created_at":"2026-06-11T23:37:26Z","created_by":"Bruno Postle","updated_at":"2026-06-12T12:52:34Z","started_at":"2026-06-12T10:55:21Z","closed_at":"2026-06-12T12:52:34Z","close_reason":"genome.py encode/decode lands. 35/35 oracle fitness parity after round-trip (flag-on); genome fixed-point + owned-projection tests. Dead-field discovery: corpus upper storeys carry drifted dead divisions (97) and rotations (187) — canonicalised by decode, validated fitness-neutral.","dependency_count":0,"dependent_count":1,"comment_count":0} {"_type":"issue","id":"homemaker-py-d0s","title":"Experiment: inner-loop optimiser bake-off at equal oracle budgets","description":"DESIGN.md §7 Phase 1, §8.3. DOF is only ~rooms-1 (6–7 on corpus). Compare Nelder-Mead vs CMA-ES vs batched multi-start pattern search at equal oracle-call budgets, measuring fitness gained per oracle call and wall-clock (batch-friendliness matters — §4.6). Measure, don't commit blind.","acceptance_criteria":"Table of fitness-per-budget across \u003e=3 candidates; one optimiser chosen and recorded in DESIGN.md","status":"closed","priority":2,"issue_type":"task","assignee":"Bruno Postle","owner":"bruno@postle.net","created_at":"2026-06-11T23:36:59Z","created_by":"Bruno Postle","updated_at":"2026-06-13T08:48:13Z","started_at":"2026-06-12T21:22:15Z","closed_at":"2026-06-13T08:48:13Z","close_reason":"Bake-off complete: CMA-ES confirmed as Phase 1/2 optimiser. NM wins quality per eval but sequential architecture incompatible with batching (§4.6). Compass stalls on narrow valleys. Results in DESIGN.md §8.3 and experiments/bakeoff_innerloop.*","dependencies":[{"issue_id":"homemaker-py-d0s","depends_on_id":"homemaker-py-1p0","type":"blocks","created_at":"2026-06-12T00:39:35Z","created_by":"Bruno Postle","metadata":"{}"}],"dependency_count":1,"dependent_count":0,"comment_count":0} -{"_type":"issue","id":"homemaker-py-bdf","title":"7 tests fail in a fresh clone: evolved-3M*.dom fixtures are referenced but not checked in","description":"On a clean checkout (no local scratch), 'pytest' gives 7 failed / 331 passed / 72 skipped. All 7 trace to missing .dom fixtures that tests reference but the repo does not contain: examples/harbor-house/evolved-3M.dom and evolved-3M-nols-3.dom (the 3M-eval run outputs cited throughout DESIGN.md). tests/test_conn_grade.py raises FileNotFoundError on them (4 tests); tests/test_collapse_insearch.py fails for the same reason (2 tests); and tests/test_fitness.py::test_classify_fail_tier_covers_full_corpus asserts 'checked \u003e 0' but finds zero corpus files to walk, so it fails with 'assert 0 \u003e 0' -- i.e. it is a vacuous test that only appeared to pass on a machine that happened to have the artefacts. Confirmed pre-existing by stashing all local changes and re-running on clean HEAD.","design":"Either commit the two .dom artefacts (they are small YAML), regenerate them from a documented command and commit that, or skip the affected tests via pytest.importorskip-style guards when the fixture is absent. The corpus-walk test should skip rather than assert when it finds nothing, so a fresh clone does not report a false failure -- but only after the fixture question is settled, since making it skip silently would hide real coverage loss.","acceptance_criteria":"pytest is green on a fresh clone with no local artefacts, and test_classify_fail_tier_covers_full_corpus either checks a real corpus or skips explicitly.","status":"open","priority":3,"issue_type":"bug","owner":"noreply@anthropic.com","created_at":"2026-08-25T23:18:02Z","created_by":"Claude","updated_at":"2026-08-25T23:18:02Z","dependency_count":0,"dependent_count":0,"comment_count":0} +{"_type":"issue","id":"homemaker-py-1ue","title":"test_classify_fail_tier_covers_full_corpus passes only on a machine that has already run the scorer","description":"The test globs examples/**/*.fails and asserts checked \u003e 0, but .fails files are generated artefacts written by homemaker-fitness next to the .dom being scored. A clean checkout has none, so the test fails with 'assert 0 \u003e 0' -- it is asserting on the state of the developer's working tree, not on the code.\n\nSplit the two things it is doing: (1) that classify_fail_tier accepts every fail string the evaluator can emit, which should run against fail strings generated in-test from corpus .dom files (or a checked-in fixture list), and (2) the corpus-artefact sweep, which if it is worth keeping should skip rather than fail when no .fails exist.","acceptance_criteria":"The test passes in a fresh clone with no .fails present, and still fails if classify_fail_tier is given an unclassifiable fail string.","status":"open","priority":3,"issue_type":"bug","owner":"noreply@anthropic.com","created_at":"2026-08-28T22:41:25Z","created_by":"Claude","updated_at":"2026-08-28T22:41:25Z","dependency_count":0,"dependent_count":0,"comment_count":0} +{"_type":"issue","id":"homemaker-py-bdf","title":"7 tests fail in a fresh clone: evolved-3M*.dom fixtures are referenced but not checked in","description":"On a clean checkout (no local scratch), 'pytest' gives 7 failed / 331 passed / 72 skipped. All 7 trace to missing .dom fixtures that tests reference but the repo does not contain: examples/harbor-house/evolved-3M.dom and evolved-3M-nols-3.dom (the 3M-eval run outputs cited throughout DESIGN.md). tests/test_conn_grade.py raises FileNotFoundError on them (4 tests); tests/test_collapse_insearch.py fails for the same reason (2 tests); and tests/test_fitness.py::test_classify_fail_tier_covers_full_corpus asserts 'checked \u003e 0' but finds zero corpus files to walk, so it fails with 'assert 0 \u003e 0' -- i.e. it is a vacuous test that only appeared to pass on a machine that happened to have the artefacts. Confirmed pre-existing by stashing all local changes and re-running on clean HEAD.","design":"Either commit the two .dom artefacts (they are small YAML), regenerate them from a documented command and commit that, or skip the affected tests via pytest.importorskip-style guards when the fixture is absent. The corpus-walk test should skip rather than assert when it finds nothing, so a fresh clone does not report a false failure -- but only after the fixture question is settled, since making it skip silently would hide real coverage loss.","acceptance_criteria":"pytest is green on a fresh clone with no local artefacts, and test_classify_fail_tier_covers_full_corpus either checks a real corpus or skips explicitly.","status":"closed","priority":3,"issue_type":"bug","owner":"noreply@anthropic.com","created_at":"2026-08-25T23:18:02Z","created_by":"Claude","updated_at":"2026-08-28T22:41:24Z","closed_at":"2026-08-28T22:41:24Z","close_reason":"Fixed by the owner: 'Add missing test files' (0d4ae7a) checked in the evolved-3M*.dom fixtures. Fresh-clone failures went 7 -\u003e 2, and the 4 conn_grade tests plus one collapse_insearch test now pass.\n\nThe 2 that remain are NOT fixture problems and are tracked separately:\n - test_collapse_insearch_reproduces_94g_finish_time_result -- stale numeric baseline, see homemaker-py-ut5\n - test_classify_fail_tier_covers_full_corpus -- asserts checked \u003e 0 over examples/**/*.fails, which are generated artefacts absent from a clean tree, so the test passes only on a machine that has run the scorer. Filed separately.","dependency_count":0,"dependent_count":0,"comment_count":0} {"_type":"issue","id":"homemaker-py-4ok","title":"run_staged_search.py rescore still MISMATCHes on baseline (LEAFSHARE=0/MULTIUSE=0) arms","description":"Follow-up to homemaker-py-7ua. That fix added collapse_insearch=True to\nrun_staged_search.py's monkeypatched fitness.load_config, but the monkeypatch\nis only installed `if leaf_share or multi_use:`. driver.search_staged has NO\ncollapse_insearch parameter at all -- every internal search() call it makes\nalways inherits collapse_insearch=True unconditionally, regardless of the\nleaf_sharing/multi_use flags. So on a baseline run (LEAFSHARE=0, MULTIUSE=0,\nthe default), fitness.load_config is never patched, and _native_score's\nrescore still silently uses collapse_insearch=False (no example\npatterns.config sets it) -- the exact same MISMATCH the 7ua fix was meant to\neliminate, just on the arm the fix doesn't touch.\n\nConfirmed empirically: `URB_NO_OCCLUSION=1 python3 experiments/run_staged_search.py\nexamples/programme-house 150 0 ...` (no env vars) reports MISMATCH before AND\nafter the 7ua fix, since the patched _load_with_flags function is never\ninstalled for that arm.\n\nMitigating factor: in the small-budget cases tested so far, the fail COUNT\n(what the various run_*_ab.sh harnesses grep as their \"authoritative metric\")\nwas identical between collapse_insearch=True and False rescoring -- only the\ncontinuous score shifted in a low decimal place, which is invisible to those\ngreps. But the underlying mechanism (collapse_global relabels leaf types\nin-place before any check runs, so downstream adjacency/missing/level checks\nsee genuinely different trees) means fail count CAN diverge in principle --\n7ua's own cited historical example (91f: 38 vs 34 fails on a WORKERS=4\nharbor-house run) showed count divergence, albeit confounded with known\nWORKERS parallel non-determinism (homemaker-py-b8g).\n\nFix: make run_staged_search.py's rescore always pin collapse_insearch=True\n(not gated behind leaf_share/multi_use), since search_staged's inner\nevaluator always runs with it regardless of those flags. Simplest: hoist the\n`conf[\"collapse_insearch\"] = True` line out of the `if leaf_share or\nmulti_use:` gate into an unconditional monkeypatch install (or an\nunconditional post-load override in _native_score itself).\n\nAlso worth: audit whether any of run_leafshare_ab.sh / run_9gp_ab.sh /\nrun_c3g_ab.sh / run_depthbal_ab.sh / run_1s3_confirm_staged.sh's BASELINE\narms (which don't set LEAFSHARE/MULTIUSE) had their reported fail counts\nactually affected historically, not just theoretically -- e.g. by rescoring\na few archived .dom outputs (if kept) with the corrected conf and diffing\nfail counts against the published numbers.","status":"open","priority":3,"issue_type":"bug","owner":"bruno@postle.net","created_at":"2026-08-05T11:25:30Z","created_by":"Bruno Postle","updated_at":"2026-08-05T11:25:30Z","dependency_count":0,"dependent_count":0,"comment_count":0} {"_type":"issue","id":"homemaker-py-5bv","title":"CP-SAT post-collapse repair (Fitness.collapse_global's Jacobi+2-opt QAP relaxation)","description":"homemaker-py-2g7.5 item (c), deferred (DESIGN.md §37.7). Fitness.collapse_global (fitness.py:655-847) approximates a finish-time cell\u003c-\u003eroom relabelling QAP with a Jacobi-style fixpoint iteration (_best_assignment, linear_sum_assignment warm-started each round from the previous round's neighbour labels) plus _two_opt_adjacency_polish to escape 2-cycle plateaus. DESIGN.md §25 explicitly considered and rejected OR-Tools for this exact problem 'because the project has no ortools' -- 2g7.5 has now added that dependency (for a simpler, different problem: assignment on a FIXED topology, not this finish-time relabel). This bead: replace or augment collapse_global's Jacobi+2-opt loop with an exact CP-SAT solve of the same cell\u003c-\u003eroom assignment (reusing _collapse_value's per-(leaf,code) value function so both stay consistent), verified safe against the 94g keep-better guard. Riskier than 2g7.5's seeder/reassign work since collapse_global is delicate, heavily tested, and runs inside every in-search eval when collapse_insearch=True (driver.py default) -- correctness and wall-clock regressions would be felt everywhere, not just in an opt-in flag.","status":"open","priority":3,"issue_type":"feature","owner":"bruno@postle.net","created_at":"2026-08-04T07:43:33Z","created_by":"Bruno Postle","updated_at":"2026-08-04T07:43:33Z","dependencies":[{"issue_id":"homemaker-py-5bv","depends_on_id":"homemaker-py-2g7.5","type":"parent-child","created_at":"2026-08-04T08:44:03Z","created_by":"Bruno Postle","metadata":"{}"},{"issue_id":"homemaker-py-5bv","depends_on_id":"homemaker-py-2g7","type":"parent-child","created_at":"2026-08-04T08:44:25Z","created_by":"Bruno Postle","metadata":"{}"}],"dependency_count":0,"dependent_count":0,"comment_count":0} {"_type":"issue","id":"homemaker-py-v4s","title":"driver.search A/B for shapecurve warm-start/prune on real multi-storey programmes","description":"Follow-up from homemaker-py-koo (DESIGN.md §37.6): koo generalised shapecurve.py's DP to handle below-inherited multi-storey trees and validated it (DP-vs-NM agreement/false-negative bar, 200 topologies on the real examples/harbor-house, 99.5% agreement, 0 false negatives, 117.7x speedup, DESIGN.md §37.6). Not measured: the search-level payoff of shapecurve_warmstart/shapecurve_prune on a real multi-storey programme at the 6xh/wkh A/B protocol (budget=2000, seeds 0-4, driver.search mean hard/soft/fitness fails, off vs on). Best sized as a single A/B once homemaker-py-tym (leaf_sharing/co_type modelling in shapecurve.leaf_constraints) also lands, since leaf_sharing defaults True in driver.search and both programme-house and harbor-house require it by default -- measuring the combined win (multi-storey + leaf_sharing) in one pass avoids two partial A/Bs that each only apply with a flag most real runs don't use.","notes":"Depends on homemaker-py-tym landing first for the combined measurement to be meaningful.","status":"open","priority":3,"issue_type":"task","owner":"bruno@postle.net","created_at":"2026-08-03T22:23:50Z","created_by":"Bruno Postle","updated_at":"2026-08-03T22:24:36Z","dependencies":[{"issue_id":"homemaker-py-v4s","depends_on_id":"homemaker-py-tym","type":"blocks","created_at":"2026-08-03T23:24:37Z","created_by":"Bruno Postle","metadata":"{}"}],"dependency_count":1,"dependent_count":0,"comment_count":0}