Model/packages
Khalim Conn-Kowlessar 74b2c1131f §4 conformance: extend Elmhurst fixtures to 6/6 across (42)..(65)
Populates §4 LINE_42..LINE_65 + per-fixture HW inputs (HAS_BATH,
MIXER_SHOWER_FLOW_RATES_L_PER_MIN, COLD_WATER_TEMPS_C, LOW_WATER_USE,
COMBI_LOSS_OVERRIDE, ELECTRIC_SHOWER_OVERRIDE) in 000477, 000480,
000487, 000516 — values extracted from the Elmhurst U985 worksheets
supplied 2026-05-20. 000474 + 000490 get the same input constants for
uniform parametrization.

Adds electric_shower_monthly_kwh_override to water_heating_from_cert
to unlock 000487 (instantaneous electric shower, no mixer). The
orchestrator's has_shower flag now also accounts for the electric path.

Extends 6 parametrized §4 tests from (000474, 000490) to ALL_FIXTURES
and adds a new ALL_FIXTURES-parametrized e2e test exercising the
orchestrator end-to-end through (42)..(65) for every Elmhurst fixture.
Tolerance on (43)/(44) loosened to 5e-3 to absorb Elmhurst's 4-d.p.
display rounding.

Result: 150/150 tests pass; §1-§4 conform at ≤1e-2 kWh / 5e-3 L for
every fixture. Deferred branches surfaced via overrides:
- PCDB Table 3b combi loss (000474, 000477, 000516)
- Non-time-clock Table 3a combi loss rows (000480, 000487)
- Electric-shower (64a)m derivation from cert codes (000487)

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-05-20 17:29:10 +00:00
..
domain §4 conformance: extend Elmhurst fixtures to 6/6 across (42)..(65) 2026-05-20 17:29:10 +00:00
fetchers added potential file scaffolding: 2026-05-15 10:56:53 +00:00
repos added potential file scaffolding: 2026-05-15 10:56:53 +00:00
utils added potential file scaffolding: 2026-05-15 10:56:53 +00:00
README.md added potential file scaffolding: 2026-05-15 10:56:53 +00:00

Shared packages

Workspace packages consumed by services/*. Each package is its own Python distribution with its own pyproject.toml; services import via the workspace dependency mechanism ({ workspace = true }).

Package Purpose
domain/ Shared domain types — Property, BaselinePerformance, Plan, Scenario, EpcPropertyData, etc. No persistence, no IO, no business logic.
repos/ Persistence layer — one repo per aggregate. Owns the SQL. Depends on domain.
fetchers/ External API clients (gov EPC, Ofgem, Google Solar, etc.). Depend on domain for response shapes.
utils/ Cross-cutting infra — logging, S3, CloudWatch URL builders, SQS task helpers.

Adding a new shared package

Only when a real second consumer materialises. Don't pre-shatter (repos-epc, repos-property, ...) — split when a deployment needs to drop a dep, not before.

See ../ara_backend_design.md §11 for the broader monorepo layout and ../CONTEXT.md for the domain glossary that names the types living in domain/.