Khalim Conn-Kowlessar 3580d059ec feat(modelling): drive measure scoping from the Scenario's exclusions ... The measures a run considers should come from the Scenario, not a CLI flag. The live scenario table persists exclusions only (no inclusions column), as a Postgres text-array of exact MeasureType values. - Scenario gains `exclusions: frozenset[MeasureType]` + `considered_measures()` (all measures minus the excluded ones, or None when none are excluded). - ScenarioModel.to_domain parses the `{a,b,c}` exclusions array into MeasureTypes, raising on a token that is not an exact MeasureType value (no high-level category expansion), per the strict-enum convention. - ModellingOrchestrator._plan_for derives the allowlist from the Scenario's exclusions, combined (intersection) with any explicit considered_measures override via the new `combine_considered_measures`. - run_modelling_e2e sources the allowlist from the Scenario; --measures / --exclude-measures become optional overlays (e.g. the technical secondary_heating_removal exclusion the catalogue cannot yet stock). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>		2026-06-16 15:26:25 +00:00
..
__init__.py	refactor(modelling): consolidate scenario + installed_measure into the subpackage	2026-06-03 22:52:35 +00:00
installed_measure_table.py	refactor(modelling): consolidate scenario + installed_measure into the subpackage	2026-06-03 22:52:35 +00:00
plan_table.py	feat(modelling): wire Valuation Uplift onto the Plan	2026-06-04 08:59:04 +00:00
recommendation_table.py	feat(modelling): persist recommendation.material_id from the catalogue	2026-06-04 08:26:58 +00:00
scenario_table.py	feat(modelling): drive measure scoping from the Scenario's exclusions	2026-06-16 15:26:25 +00:00