mirror of
https://github.com/Hestia-Homes/Model.git
synced 2026-06-08 11:17:27 +00:00
f326e4eb53
The gov-EPC API mapper sets BOTH roof_construction (int) and roof_construction_type (str, derived via _API_ROOF_CONSTRUCTION_TO_STR), but the Elmhurst mapper set only the string — leaving roof_construction None on every site-notes cert. The SAP cascade reads the STRING (so SAP cross-mapper parity always held), but consumers of the int (e.g. domain/sap10_ml/transform.py ML aggregates `main_dwelling_roof_ construction`) silently saw None on the Elmhurst path. New `_elmhurst_roof_construction_int` maps the Elmhurst roof-type code to the same SAP10 int the API lodges (F→1, PN→3, PA→4, PS→8, S/A→7), harvested from the committed Summary fixtures. Unlike the wall map it returns None (not a strict-raise) for unmapped codes: the int is not cascade-load-bearing, so an unknown roof must not block the cert (vaulted 5 / thatched 6 / NR omitted until a fixture surfaces them). The 6 hand-built U985 reference fixtures gain the matching roof_construction int (4/4/3 etc.) so test_from_elmhurst_site_notes_ matches_hand_built_* still asserts structural parity. SAP output is unchanged (cascade reads the string). §4 suite green (2407 passed); the two pre-existing stone-§5.6 sap10_ml failures are unrelated/out of scope. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| addresses | ||
| fuel_rates | ||
| property | ||
| property_baseline | ||
| sap10_calculator | ||
| tasks | ||
| __init__.py | ||
| test_postcode.py | ||