/health already returned GITHUB_SHA in its response but never logged
it, and the fastapi lambda's Terraform environment never actually set
GITHUB_SHA — so every health check response contained "unknown" in
production. Wire var.github_sha through the fastapi lambda module
(default "unknown" for local/other invocations) via a new
TF_VAR_github_sha env var set from `github.sha` in
_deploy_lambda.yml's Terraform Plan step, and log it on every /health
call so a request in CloudWatch can be tied back to the deploy that
served it.
Also fix the zip-size gate added for PR #1469: putting it in
tests/test_lambda_zip_size.py (run via the Docker-based ddd_tests.yml
suite) broke CI, because Dockerfile.test's build context excludes
deployment/* (.dockerignore), so check_lambda_zip_size.py couldn't
find variables.tf to read zip_excludes from inside that container.
Move the check to its own lightweight workflow,
check_lambda_zip_size.yml, triggered on pull_request into main — a
plain checkout (no Docker build) has the full repo, so the check
works, runs fast, and still gates merges to main before a regression
can roll into the dev deploy.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
deploy_terraform.yml only triggers on push to dev/prod — by the time
it runs, the change has already merged to main and rolled into dev.
That's exactly how the size regression sat undetected for weeks: it
only ever surfaced deep inside terraform apply on dev.
Drop the fast_api_lambda_zip_size_check job from deploy_terraform.yml
and instead add tests/test_lambda_zip_size.py, which runs
backend/app/requirements/check_lambda_zip_size.py as part of the
existing pytest tests/ suite. ddd_tests.yml already runs that suite
on `pull_request: branches: ["**"]`, so this now fails the PR before
anything merges to main, rather than failing the dev deploy after.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The last real archetype on the companion-gap log; the log test now
simulates a future incomplete archetype (warm-air heat pump, Group 5
control deliberately unmapped).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Supersedes the "direct-acting electric drags no control/category" pin:
None does not mean unset — it means inherit the replaced system's value
(ADR-0048 bug class), verified suppressing HHRSH on portfolio 796.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
_u_brick_thin_wall_age_a_to_e's `<= 280` check put an uninsulated solid-
brick wall of exactly 280mm in the "200 to 280mm -> 1.7" row; RdSAP 10
§5.7 Table 13 (spec PDF p.41) shares 280 as an unlabelled edge between
that row and "280 to 420mm -> 1.4", so the table text alone doesn't say
which row owns it.
Found by building cert 100031768368 (280mm exactly, band C) in Elmhurst
and comparing every worksheet line to the calculator: volume/ACH/floor/
doors matched exactly, but the wall didn't (1.70 vs Elmhurst's 1.40)
despite an identical input crosswalk. Initially reverted a first attempt
at this fix when it appeared to regress an already-pinned cert
(217091901, band A, also nominally 280mm, previously "confirmed" at
U=1.70) — but that cert's build script never actually set a wall
thickness field, so its shared Elmhurst assessment had silently
inherited a stale 260mm from an earlier build. Fixed that build script
and rebuilt with the correct 280mm entry: Elmhurst's worksheet now also
gives U=1.40, matching 100031768368 and confirming the fix rather than
contradicting it.
Both certs move to (near-)exact lodged matches: 100031768368 59.12 ->
61.21 (lodged 61, within 0.5); 217091901 60.82 -> 61.59 (lodged 62,
exact). Corpus gauge 77.8% -> 78.6% within-0.5, MAE 0.636 -> 0.627 (14
corpus certs lodge exactly 280mm solid brick). TDD'd, 46 pins + full
suite green (2310 passed).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Golden cert 0330 now reaches band C on the dwelling-sized ASHP alone
(ADR-0049), dropping its solid_floor_insulation companion; cert 0390
still fires three measures, so the per-measure trigger-attribute
assertions move there (and gain the lighting triggers).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
`from_sap_schema_17_1` hardcoded is_dwelling_export_capable=False, so
SAP 10.2 Appendix M1 zeroed the PV export credit on every export-capable
full-SAP cert. Cert 0380-3044-6070-2305-5925 (property 741840, PRD #1435
WS3) now reproduces its lodged 92 exactly (was 89); the existing
19.1.0 pin 10096028301 closes its documented -1 residual (84 -> 85 =
lodged). The full-SAP top-level pv_connection is deliberately NOT
carried: its enum disagrees with the RdSAP one the calculator gates on.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
